A Software Defined Framework for Integrated Space ... - IEEE Xplore

IEEE TRANSACTIONS ON MOBILE COMPUTING,

VOL. 17,

NO. 3,

MARCH 2018

703

SERvICE: A Software Defined Framework for Integrated Space-Terrestrial Satellite Communication Taixin Li, Student Member, IEEE, Huachun Zhou, Hongbin Luo , Member, IEEE, and Shui Yu , Senior Member, IEEE Abstract—The existing satellite communication systems suffer from traditional design, such as slow configuration, inflexible traffic engineering, and coarse-grained Quality of Service (QoS) guarantee. To address these issues, in this paper, we propose SERvICE, a Software dEfined fRamework for Integrated spaCe-tErrestrial satellite Communication, based on Software Defined Network (SDN) and Network Function Virtualization (NFV). We first introduce the three planes of SERvICE, Management Plane, Control Plane, and Forwarding Plane. The framework is designed to achieve flexible satellite network traffic engineering and fine-grained QoS guarantee. We analyze the agility of the space component of SERvICE. Then, we give a description of the implementation of the prototype with the help of the Delay Tolerant Network (DTN) and OpenFlow. We conduct two experiments to validate the feasibility of SERvICE and the functionality of the prototype. In addition, we propose two heuristic algorithms, namely the QoS-oriented Satellite Routing (QSR) algorithm and the QoS-oriented Bandwidth Allocation (QBA) algorithm, to guarantee the QoS requirement of multiple users. The algorithms are also evaluated in the prototype. The experimental results show the efficiency of the proposed algorithms in terms of file transmission delay and transmission rate. Index Terms—Network function virtualization, quality of service, software defined network, space and terrestrial networks

Ç 1

S

INTRODUCTION

communication is one of the most important parts of modern communication systems. Due to the advantages of global coverage, mobility, and scalability, satellite networks can provide global efficient broadcast or multicast services anywhere anytime. Satellite communication has been widely used in voice service, navigation, military, telemetry, and live television [1]. However, current and emerging satellite applications and services are becoming increasingly complex and demanding. It is hard for the traditional satellite communication networks to achieve effective service delivery only relying on space networks. Therefore, it is necessary to combine the satellite networks and terrestrial networks to form an integrated space-terrestrial satellite communication networks. But there lacks a unified management. Satellite networks and terrestrial networks are always relatively isolated and heterogeneous, without sharing a unified management. But separate ATELLITE

T. Li, H. Zhou, and H. Luo are with the School of Electronic and Information Engineering, and National Engineering Lab for Next Generation Internet Interconnection Devices, Beijing Jiaotong University (BJTU), Haidian District, Beijing 100044, China. E-mail: {14111040, hchzhou, hbluo}@bjtu.edu.cn. S. Yu is with the School of Information Technology, Deakin University, Burwood, Vic 3125, Australia. E-mail: [email protected]. Manuscript received 3 Aug. 2016; revised 16 May 2017; accepted 20 July 2017. Date of publication 27 July 2017; date of current version 2 Feb. 2018. (Corresponding author: Huachun Zhou.) For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference the Digital Object Identifier below. Digital Object Identifier no. 10.1109/TMC.2017.2732343

management system is a significant obstacle in data transmission and service delivery in the scenario of integrated space-terrestrial satellite communication networks. In addition, we have noticed a recent trend that the revenue of satellite services, including traffic engineering and fine-grained QoS guarantee, account for about 60 percent of the satellite industry [2], [3]. Therefore we mainly consider traffic engineering and QoS guarantee in this paper. Traditional satellite communication systems are not agile and efficient in providing traffic engineering and QoS guarantee because of the following characteristics. 1)

Slow configuration. In traditional satellite networks, a satellite is configured by the ground station only when it flies over the station, which causes very long time to configure the whole networks. This characteristic does not allow one to manage the satellite in real time, including real-time collection of network status and implementing dynamic management strategies. 2) Inflexible traffic scheduling. Traditional satellite networks employ a decentralized management architecture, scheduled link allocation, and static routing strategies, which make it difficult to support flexible traffic scheduling, and changing needs of users. 3) Coarse-grained QoS guarantee. The QoS strategies are at the level of satellite links. The tenants cannot enjoy customized satellite services. The requests of tenants cannot be satisfied dynamically. There have been some researches that focused on designing new satellite network frameworks [4], [5], [6]. Bao et al.

1536-1233 ß 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See ht_tp://www.ieee.org/publications_standards/publications/rights/index.html for more information.

704


VOL. 17,

NO. 3,

MARCH 2018

Experiments

Prototype

TABLE 1 The Comparison of Related Framework

SERvICE Tang et al. [9] OpenSAN [4] SDS-BI-SIS [10] Feng et al. [11] Kapovits et al. [12] Bertaux et al. [5] Ferrus et al. [6]

Consider SDN

Consider NFV

p p p p p p p p

p p p

Hierarchical Framework p p p p p

[4] separate the data plane (satellite infrastructure) from the control plane (GEO group) to provide satellite networks with high efficiency and fine-grained control. Bertaux et al. [5] investigated how SDN and NFV can enhance satellite architecture through practical use cases. Ferrus et al. [6] provided a detailed description of the benefits that SDN and NFV can bring into satellite communications through the analysis of scenarios and use cases. These papers have done inspiring jobs. But they mainly focus on mechanisms in space networks or terrestrial networks separately. In addition, for lack of necessary experiments or prototypes, the proposed frameworks are not well validated in those papers. In this paper, we propose a SDN [7] and NFV [8] based integrated space-terrestrial satellite communication networks framework, SERvICE. SERvICE adopts a multi-layer structure that contains Management Plane, Control Plane, and Forwarding Plane. The three layers are divided based on function, rather than location. In this way, SERvICE is merged into a unified system. SERvICE is implemented in a large and real Linux-based prototype, which contains more than 40 nodes and is supported by a state-level program. The prototype is implemented to validate the feasibility of SERvICE and the functionality of the prototype. We adopt DTN [13] in the space networks and deploy OpenFlow [14] in both space networks and terrestrial networks. The experiments show that SERvICE can achieve flexible traffic engineering for the integrated space-terrestrial networks, of which agile configuration is the basis. The proposed QoS algorithms take bandwidth, delay and packet loss rate into consideration among multiple users and the experimental results show that they can achieve the goal of fine-grained QoS guarantee. Our main technical contributions in this work are as follows.

We propose a novel three-layer integrated-space satellite communication framework, SERvICE, based on SDN and NFV. The three layers are divided based on function, rather than location. Space networks and terrestrial networks are merged into a unified system. SERvICE can achieve on-demand and serviceoriented data transmission and service delivery. We implement SERvICE in a real and large prototype, which has more than 40 nodes with the help of DTN and OpenFlow. To the best of our knowledge, we are the first ones to deploy OpenFlow over DTN. We provide evaluation analysis to validate the

Role of satellites network network network network network bent-pipe bent-pipe bent-pipe

Space-terrestrial integrated p p

p p p

p p

p

functionality of the prototype and the feasibility of SERvICE. The results of the experiments show that SERvICE can achieve agile control and flexible satellite network traffic engineering. We propose two QoS-oriented heuristic algorithms, QSR and QBA, to provide fine-grained QoS guarantee among multiple users. The first algorithm takes QoS parameters, such as bandwidth, delay and packet loss rate into consideration to create a QoS routing solution for satellite networks. The second algorithm aims to create a bandwidth allocation solution for satellite networks among tenants with different service types. We evaluate the proposed algorithms in the prototype and the experimental results show that the heuristic algorithms can achieve the goal of QoS guarantee among multiple users. The rest of the paper is organized as follows. Section 2 reviews the related work. Section 3 briefly describes the components of SERvICE and provides an analysis to promote better understanding. Section 4 provides implementation of the prototype and description of the validation experiments conducted on the prototype. Section 5 presents the proposed QoS-oriented algorithms. Section 6 presents the tests of the proposed heuristic algorithms and the experimental results. In Section 7, we provide a further discussion about the study. Finally, Section 8 sums up the paper.

2

RELATED WORK

Recently, with the emerging application of SDN and NFV technologies in multiple areas, for example, in datacenter networks [15], in radio access networks [16] and in optical networks [17], our ideas for designing state-of-the-art satellite network frameworks are widened greatly. There are also some articles in applying the idea of SDN and/or NFV in satellite networks, which have many achievements and serve as an inspiration. The comparison of these frameworks is shown in Table 1. In [9], the authors proposed a software defined satellite network architecture, which introduced the benefits of applying SDN in satellite networks and pointed out the challenges to be solved. In [4], OpenSAN, a software defined satellite networks architecture is proposed to provide satellite networks with high efficiency, fine-grained control, as well as flexibility. OpenSAN has separated the data plane (satellite infrastructure) from the control plane (Geosynchronous Earth Orbit (GEO) group), which provides excellent ideas in designing the multi-layer space

LI ET AL.: SERVICE: A SOFTWARE DEFINED FRAMEWORK FOR INTEGRATED SPACE-TERRESTRIAL SATELLITE COMMUNICATION

network. Yang et al. [10] proposed an architecture (SDS-BISIS) for space information systems that is based on software defined radio technology to resolve the current drawbacks of the construction of space information systems, and discussed its new features. They also discussed the payloads of the software-defined satellites. [9], [4], and [10] only adopted SDN in their frameworks. All of them adopted a hierarchical architecture and satellite networking. However, they focused on space networks without considering the spaceterrestrial integrated scenario. All of the three papers did not deploy prototype and only [9] had experiments. Feng et al. [11] proposed a networking scheme for Operationally Responsive Space (ORS). The scheme is a spaceground integrative network and is deployed by OpenFlow and network virtualization. It was provided an agility and flexible solution for emergency response in a new way. Kapovits et al. [12] presented a hierarchical reference service delivery architecture and highlighted its potential role in selected satellite terrestrial integration scenarios. [11] and [12] adopted SDN in the design of the framework while NFV was not considered. [11] and [12] took space-terrestrial integrated scenario into consideration. However, [12] did not adopt the hierarchical architecture. Satellites only performed bent-pipe forwarding and satellite networking was not considered. None of them have experiments or prototypes to validate their architecture. Bertaux et al. [5] investigated how SDN, network virtualization, and NFV can enhance satellite architecture through practical use cases, such as SDN-based site diversity. Their work provides us appropriate testing scenarios. Ferrs et al. [6] provided a detailed description of the benefits that SDN/NFV technologies can bring into satellite communications towards 5G through the analysis of scenarios and use cases. These articles adopted SDN and NFV in spaceterrestrial scenario but SDN and NFV are mainly applied in the terrestrial segment. Bent-pipe satellites are deployed in space, and the space segment only acts as a transmission channel. In addition, the virtualized Network Service Functions (NSFs) are only deployed in the satellite hubs or in the dedicated terrestrial satellite-related processing network that connects to satellite hub. There are still no experiments or prototypes to support the proposed concept. In this paper, we focus on the integrated space-terrestrial scenario. We adopt a hierarchical networking method and SDN performs control function not only in terrestrial network, but also in space network. We deploy the virtualized NSFs in both satellite-related components (satellite gateways) and satellite-unrelated components (data centers) to form an integrated NSF chain. In addition, we have implemented a prototype and conducted experiments to validate the proposed framework.

3

SERVICE FRAMEWORK

In this section, we give an overview of SERvICE. SERvICE is based on SDN and NFV. The characteristic of centralized control of SDN simplify processing tasks of satellites. By separating the data plane and control plane of each satellite, satellites only need to implement the simplest forwarding function. We use OpenFlow as the southbound interface protocol because it is widely used in the SDN-related

705

Fig. 1. The system structure and functions of SERvICE.

controller and switch. We use NFV to create the satelliterelated VM-based NSFs. The reason is that NFV is a topology-independent and flexible method to deploy NSFs. It is easier to configure the NSFs, such as adding/ deleting/ opening/ closing/ migrating NSFs in a flexible way. We just need to manipulate the VMs according to the strategies. SERvICE contains three planes: Management Plane, Control Plane and Forwarding Plane. The three planes are divided based on function, rather than location. This will help to merge the space-terrestrial network. Multiple benefits can be expected from the combination of the space network and terrestrial network, such as increased network resilience and improved QoS for end users. The system structure and the interactions among the functions of SERvICE are illustrated in Fig. 1. The rounded rectangles represent the entities and the planes while the rectangles represent the functions. The detailed introductions are as follows.

3.1 Management Plane The Management Plane here acts as the orchestrator of the whole satellite communication network, including space networks part and terrestrial networks part. The management entity in Management Plane is the Satellite Network Management Center (SNMC). Since the processing capability on satellites is limited, we place SNMC in the backbone network. The function of the SNMC can be divided into two parts. One part is resource registration and inquiry, and the other part is to create strategies, such as routing, security, accounting, QoS, and resource management. SNMC makes strategies depending on the information collected by the GEO satellites and the controller in the terrestrial networks and user’s needs. These strategies are sent to the Control Plane to steer the traffic. Here, we will introduce the Management Plane in three parts: the unified naming and description of entities in the whole satellite communication network, the registration and inquiry of the resources, and the management strategy making. 3.1.1 Naming Unified and reasonable naming of resources can promote a better integration of the space networks and the terrestrial networks.

706


We define Resource IDentifier (ReID) to name the resources. ReID is comprised by two parts, Service IDentifier (SeID) and Satellite IDentifier (SaID), that is, ReID ¼ fSeID; SaIDg:

(1)

SeID is for the distinction of different kinds of NSFs that are deployed dynamically in terrestrial networks, for example, Network Address Translation (NAT), Performance Enhancing Proxy (PEP), Intrusion Detection Systems (IDS), Virtual Private Network (VPN) proxy, FireWall (FW), Accounting and Service Classifier (SC). SaID is for the distinction of different kinds of satellites. Communication satellites can be divided into many kinds according to various standards. For example, they can be classified to TV broadcasting satellite, maritime communication satellite, aeronautical communication satellite and military communication satellite according to the service type. Therefore, it is necessary to allocate different SaIDs for the identification of one or one group of satellites.

3.1.2 Resource Registration and Inquiry The registration and inquiry function is responsible for the registration of the information of terrestrial NSFs and satellites. It also answers requests of users. In terrestrial networks, NSFs announce their information (including SeID, function descriptions, and versions) to the local controller when they are turned on in the nodes that provide NSFs. The NSFs are deployed in the form of Virtual Machines (VMs). The service information is forwarded to the SNMC after it is cached in the local database of the controller. This method enables the local controller to provide service-related information to the SNMC for strategies making. The NSFs inquiry request is not limited to accurate SeID but it can be the description of NSFs. In space networks, the status information of satellites (including SaID, available bandwidth, packet loss rate and transmission delay) is collected to SNMC and stored in a database. When the requests of users arrive at the SNMC, the SNMC makes appropriate routing strategies or QoS strategies according to the requests of users and the type of data. Of course, strategy making is based on the satellite status information stored in the SNMC. 3.1.3 Management Strategies The management strategy function makes proper global strategies about routing, security, QoS and resource management according to the registration information from NSFs in terrestrial networks, the status information from satellites in space networks and Type of User (ToU) and Type of Service (ToS) from the request of users. There are several algorithms running in this part and we can say that this function is the core of the whole framework. We will introduce QoS-oriented algorithms in Section 5 as an example to show how this function makes strategies. In this way, we create the Management Plane in a useroriented and service-oriented method, laying the foundation of the QoS-based data transmission and service delivery in the integrated space-terrestrial satellite communication networks.

VOL. 17,

NO. 3,

MARCH 2018

3.2 Control Plane The function of the Control Plane can be divided into two parts. One part is collecting link status information and also information from the NSFs, then sending them to the SNMC. The other part is distributing the forwarding rules (flow tables) to the Forwarding Plane according to the strategies made by the SNMC. The control entity in the Control Plane is the controllers in GEO satellites and the controllers in Data Centers (DCs) and Satellite Gateways (SGs). The Control Plane consists of two parts, space networks and terrestrial networks. 3.2.1 Space Networks We place controllers on GEO satellites considering the global view of the whole network. GEO satellites collect link status among satellite networks and send it to the SNMC for management via the connection between them. Meanwhile, instructions from the SNMC are translated and then distributed to satellites by GEO satellites. When strategies from the SNMC arrive at GEO satellites via the connection between them, the controller transforms the instructions into the form that forwarding devices can recognize and sends them to Medium Earth Orbit (MEO) and Low Earth Orbit (LEO) satellites. 3.2.2 Terrestrial Networks We deploy SG controllers (marked as C-SGs), and DC controllers (marked as C-DCs) in the terrestrial segment. The function of terrestrial controllers can be divided into two parts. One part is collecting the registration information of local NSFs then sending the information to the SNMC. The controller maintains the local service information in the database, such as service type and location. The other part is distributing the instructions that come from the SNMC to the routers and switches. Then, the controller steers the traffic among the NSFs that selected by the SNMC. 3.3 Forwarding Plane The entities in the Forwarding Plane can be divided into two parts. One part is the entities in space networks, including MEO satellites and LEO satellites. The other part is the entities in terrestrial networks, including routers, switches, and SGs. The function of the forwarding entities in the space network is to forwarding data under the control of the GEO satellites. There are two functions of the entities in terrestrial component of the forwarding plane. One function is to forward data according to the instructions of the local controller. The other one is to host the VM-based NSFs. 3.3.1 Space Networks We decouple the control decisions from forwarding hardware and only leave forwarding function on MEO and LEO satellites. LEO satellites are responsible for receiving user data and forwarding the data to the parent MEO satellite. MEO satellites are responsible for receiving the data that LEO satellites send and forwarding the data to user via the Inter Satellite Links (ISLs) among MEO satellites. When the traffic coming from LEO/MEO satellites arrives, MEO satellites reserve bandwidth for the traffic and forward the traffic according to the instructions received from GEO satellites.


707

TABLE 2 Parameters of the Multi-Layer Framework

GEO satellites MEO satellites LEO satellites

Orbit height/km

Running period/h

Number of satellites

36,000 10,390 895.5

24 6 12/7

1x3 2x5 6x11

Orbit inclination/ 0 45 90

3.3.2 Terrestrial Networks We deploy satellite-related NSFs in DCs and SGs in the Forwarding Plane to process the data received from satellites or to be sent to the satellites. We borrow the idea of NFV to deploy NSFs. NSFs are embedded in VMs that are deployed in DCs and SGs. The deployment and configuration strategies of NSFs are decided by the SNMC. That is, the SNMC sends instructions to steer the satellite data among specific NSFs. 3.4 Analysis of Agility In this section, we aim to analyze the agility of the space component of SERvICE. Here, agility means that the configuration instructions should be distributed in near-real-time, keeping pace with the rapid change of the demand of users and network status. We think that agility is the precondition of flexible satellite network traffic engineering and finegrained QoS guarantee. To show the agility of network configuration deployment and updating in SERvICE, we adopt the three-layer constellation named Tr [18]. We deploy Tr in the Satellite Tool Kit (STK) [19]. The parameters listed in Table 2 are based on the Tr. As introduced in [18], the constellation has 66 LEO layer satellites (LEO1 LEO66), 10 MEO satellites (MEO1 MEO10), and 3 GEO layer satellites (GEO1 GEO3). The constellation can achieve the following design objectives: (1) Higher layer satellites cover all of the lower layer satellites (or ground stations). (2) The number of satellites and orbits is minimal. These design objectives satisfy our need for a constellation: hierarchical satellite coverage and simple system. We set two ground stations, Beijing (116 E, 40 N) and Washington (77 W , 39 N). The connections among satellites are illustrated in Fig. 2. As is shown in Table 2, the orbit inclination of the GEO satellites is 0 degree, therefore, the GEO satellites are actually geostationary orbit satellites. Three GEO satellites keep continuous connections to ground stations. Beijing station contacts one GEO satellite and Washington station contacts the other two. MEO layer satellites keep continuous connections not only to GEO layer satellites, but also to LEO layer satellites. At the same time, LEO layer satellites cover all the ground stations continuously. We compare the configuration instructions complete update time of all the LEO satellites in SERvICE with that in the traditional satellite structure in this simulation environment. To make the problem easier to analyze, we make three assumptions. (1) We do not consider transmission delay, queuing delay and forwarding delay, but consider propagation delay. (2) We do not consider the instructions forwarded via the ISLs among the LEO satellites when testing the traditional way. We aim to test how long it will take for all the LEO satellites to be completely updated. Here, the update operation is completed only when all the LEO

Fig. 2. 3D multi-layer framework.

satellites are updated. (3) We make another assumption that there is no handoff during propagation delay. For example, ground station sends instruction at 0 o’clock, and we think that the connection situation at 0 o’clock is the same as the situation of the moment instructions arrive at satellites. Both Beijing station and Washington station upload configuration updating instructions at 0 o’clock, 2 o’clock, 4 o’clock, 6 o’clock, 8 o’clock, 10 o’clock, 12 o’clock, 14 o’clock, 16 o’clock sequentially. Two stations send the same configuration instruction at the same time, while the instructions sent at different time are not the same. The instructions of previous and next time period won’t affect each other. In the traditional satellite structure, the satellites receive the instructions only when they fly over the ground station. Therefore we record the moments that the satellites first set up connections with the ground stations. Then we compare these moments of all the LEO satellites and find out the latest one as the complete update time of the traditional structure. Because the higher layer satellites cover all the lower layer satellites, the updating delay of SERvICE is actually the propagation delay. We calculate the propagation delay between GEO satellites and the ground station satellites, as well as GEO satellites and LEO satellites at the updating moment. Then we add the two delays for each LEO satellite and choose the biggest one as the complete update time in SERvICE. The configuration completely updating delay is shown in Fig. 3. We can see that the updating delay of SERvICE ranges from 290 ms to 320 ms, which is about 90000 times less than that of the traditional structure. The reason is that SERvICE has a different control structure with that of the traditional satellite network. The coverage capability of the GEO satellite is much stronger than that of the ground station. More satellites can receive the instructions at the same time in SERvICE than that in the traditional satellite network. We can conclude from the simulation above that the configuration instruction update time can be largely reduced

Fig. 3. Time interval of complete update.

708


Fig. 4. Illustration of the prototype.

by using SERvICE. Of course, increasing the number of ground stations in the traditional structure would also largely reduce the updating delay, but the economic costs will become large. Leveraging ISLs among LEO satellites can also achieve the goal of distributing instructions. But we should notice that the number of LEO satellites in the routing will increase heavily with the expansion of the LEO constellation. The probability of link handover will increase with the increase of ISLs. The blocking probability will increase as a result. In addition, the total transmission delay, queuing delay and forwarding delay may be relatively long.

4

IMPLEMENTATION

To validate SERvICE and also evaluate its performance, we built a Linux-based prototype. In this section, we first describe the prototype implementation, followed by two experiments to validate the feasibility of SERvICE and the functionality of the prototype.

4.1 Prototype Implementation We implement SERvICE in a prototype as shown in Fig. 4. All of these nodes are implemented in five high-performance servers with the help of network virtualization technologies [20]. The servers we use are DELL PowerEdge R720 rackmount servers with Intel Xeon E5-2609 CPU, 32G memory and 1 TB hard-disk storage. We create the nodes using Kernel-based Virtual Machine (KVM) [21] and OpenStack [22]. Because the nodes are VMs, we can create or modify the topology flexibly. We keep the terrestrial network topology unchanged and change the space network topology in the following experiments. We will introduce the prototype in two parts. 4.1.1 Terrestrial Networks As is shown in Fig. 4, the terrestrial networks mainly contain SNMC, SGs, C-SGs, DC switches (aggregation switches and access switches), C-DCs, servers, and users. We adopt fat-tree-like topology [23] when implementing two small DCs. Fat-tree topology is a special type of Clos

VOL. 17,

NO. 3,

MARCH 2018

topology [24], which is a topology built up from multiple stages of switches, providing extensive path diversity. The small data center network contains four OpenFlow enabled switches and four servers. The four OpenFlow enabled switches are divided into two layers, the aggregation layer and the access layer. We also implemented POX controller [25] in every DC network. POX is a popular lightweight controller for OpenFlow networks and we use POX for the reason that it is written in python and is convenient to add functions in it. We deploy the DTN protocol stack in space networks because DTN is designed for the scenes where end-to-end transmission is not guaranteed. Therefore, DTN suits the space networks. We use the TCP/IP protocol stack in the terrestrial network because it is used in the terrestrial networks in most cases. To facilitate protocol conversion between the space and terrestrial networks, we develop a DTN-TCP/IP bidirectional conversion and deploy this function on the SGs. We borrow the idea of NFV to deploy the NSFs, which is introduced in our previous work [26]. The NSFs are embedded in VMs running on the SGs and DC switches. We deploy the classifier on the SGs and deploy firewall, VPN proxy, and NAT on DC switches. We take advantage of the capacity of Open vSwitch (OVS) [27], which provides L2 connection and flow management to implement these functions. We deploy OVS switches (v2.5.0) in the VMs and manipulate the flow rules to change the OVS switch into the classifier, FW, VPN proxy, and NAT, which match well with the controller. Let’s consider the classifier. The OVS-based classifier matches different packets and set appropriate ToS for the packets at SGs according to the strategies from SNMC.

4.1.2 Space Networks The space networks we create contains GEO satellite nodes, MEO satellite nodes, and LEO satellite nodes. The number of each kind of satellite nodes and the topology can be changed on demand. POX controller is embedded on GEO satellite node. We add a monitor module in the POX to collect the link status. We deploy OVS in the MEO and LEO satellite nodes. OVS is used to achieve two goals. One is to cooperate with the controller to collect the link information. The other one is for the MEO satellites to forward data under control of the GEO satellite. In addition, OVS is used to reserve bandwidth for different traffic based on the QoS queue mechanism. To make the emulation representative of a realistic scenario, two points of settings are made in the prototype as follows. a) Links: To make our prototype a real scenario, we simulated the real delays of satellite networks. We build the proposed three-layer GEO-MEO-LEO satellite architecture based on the constellation named Tr introduced in [18] in Satellite Tool Kit (STK) and the parameters are listed in Table 2. Then, we get the link delay from STK as shown in Table 3. Here, we do not consider the delay between SNMC and the SGs. We approach the real link delay and data rate of space link in the prototype with the help of Linux Traffic Control tool. b) Transmission: We implement DTN in the satellite networks to meet the need of high transmission delay with the help of Interplanetary Overlay Network (ION) [28].


709

TABLE 3 Parameters of Link Delay

GEO satellites MEO satellites LEO satellites SGs SNMC

GEO satellites \ 86 ms \ \ 120 ms

MEO satellites 86 ms 66 ms 50 ms \ \

LEO satellites \ 50 ms \ 3 ms \

SGs \ \ 3 ms \ 0 ms

SNMC 120 ms \ \ 0 ms \ Fig. 6. Performance of the bundle tunnel mechanism.

Adopting the idea of store-and-forward, DTN utilizes Bundle to transmit data and utilizes a convergence layer called Licklider Transmission Protocol (LTP) [29] to provide retransmission mechanism. ION is an implementation of DTN architecture and is designed to enable inexpensive insertion of DTN functionality into embedded systems. We deploy OpenFlow (v1.0) over ION (v3.3.1) by a method of tunnel. That is, OpenFlow data is transmitted in a bundle tunnel when the controller (GEO satellite) sets up connection to switches (MEO satellites) and when controllers send instructions to switches. The encapsulation format of the bundle tunnel is shown in Fig. 5. Because DTN is implemented by ION in an overlay way, the first half of the bundle tunnel header is the same as normal IP packets. The difference is that there is a 4-byte LTP header, a 14-byte Primary Bundle header, and a 5-byte Payload header before the payload data field due to the protocol stack of DTN. The signaling data of the OpenFlow signaling packets between controller and switches are taken out and then encapsulated in payload data. The performance of this bundle tunnel mechanism is shown in Fig. 6. We conduct an experiment to test the tunnel processing delay and the connection delay between controller and switch for ten times. The one-way transmission delay is 86 ms according to Table 3. We define the time between the generation of OpenFlow packet and corresponding bundle packet as the tunnel processing delay. The average tunnel processing delay is about 3.25 ms. We define the time between switch sending the first bundle tunnel packet to controller and the connection of switch-tocontroller being established as the connection delay. The average connection delay is about 1.32s.

4.2 Experiments and Analyses To validate the functionality of the prototype and the feasibility of SERvICE, we design two scenes of data transmission in the integrated space-terrestrial satellite communication networks. These experiments can also validate that SERvICE supports flexible traffic engineering. Here, flexible means that the traffic should be steered among the satellites and the switches smoothly and timely. The routing strategies should not be fixed or chosen in a pre-allocated way. The SNMC

Fig. 5. Encapsulation format of the bundle tunnel.

should make the routing strategies according to the requests of users and the network status flexibly. We conduct two experiments in the prototype. The topology of the space network is shown in Fig. 7. We implement one GEO satellite, ten MEO satellites, and three LEO satellites in space network. The topology of the terrestrial topology is the same as the terrestrial part in Fig. 4. SG1 keeps connections to LEO1 as well as LEO2, and SG2 keeps connection to LEO3.

4.2.1 Traffic Engineering in the Space Network The first experiment is to show the flexible traffic engineering in the space network using SERvICE. A user wants to upload data to a server in DC1 via the space network and requires high bandwidth. The SNMC makes routing strategies and GEO steers the traffic among the satellites. However, due to the bad weather, the Packet Loss Rate (PLR) of the path increases. SNMC then arranges a new path to achieve better transmission quality. In the experiment, we allocate 500 KBps for the bandwidth of the satellite link to simulate a bandwidth-limited environment. We configure the flow table of the OVS switches to change it into classifier, FW, and NAT. Then, we send data from the user to server continuously to simulate the scene that an end-user uploads files to a DC server. The normal Bit Error Rate (BER) of satellite link is 106 . According to the formula of BER-to-PLR, PLR ¼ 1 ð1 BERÞpacketlength , the packet length of the bundle packet is 1500 bytes, therefore the normal PLR of satellite link is 0.15 percent. Data is sent to LEO3 via SG2. The classifier in SG2 allocates appropriate ToS to the packets. The GEO satellite steers the traffic along the path with high bandwidth according to the strategies from SNMC (specific strategies will be introduced in Section 5). Then the data are sent to Server1 via SG1 and DC1 switches and processed by FW and NAT at DC1 switches.

Fig. 7. Topology of the space network.

710


Fig. 8. Data rate before and after Handoff.

At the beginning of the transmission, the allocated path is USER! SG2! LEO3! MEO10! MEO8! MEO7! MEO5! MEO3! MEO4! LEO1! SG1! EdgeRouter1! Switch1! Switch3! Server1. However, due to the weather factor, the transmission quality of the path becomes bad, which causes high BER and PLR. We set gradually increasing PLR to simulate bad weather between LEO1 and SG1. We use a shell script based on Linux Traffic Control tool to change the PLR of satellite link by 0.15, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, and 5 percent, respectively and orderly every 22 seconds. SNMC collects this situation and makes a new traffic engineering strategy about steering the data via a new path. Then the strategy is sent to GEO satellite and is distributed to MEO satellites. The data sent from user is then forwarded via a new path, which is USER! SG2! LEO3! MEO10! MEO8! MEO7! MEO5! MEO3! MEO4! LEO2! SG1! EdgeRouter1! Switch1! Switch3! Server1. We use goodput to describe the data rate of the payload stored in the local cache from the perspective of the application layer. We can see from Fig. 8 that due to the retransmission mechanism of LTP caused by packet loss, the goodput varies in a big range. Sometimes the goodput is very small because the link is occupied by retransmitted packets and few new data are received by the peer node. As time passing by, the goodput of the link becomes lower and lower. When the PLR reaches 5 percent, the transmission path is switched to a new one. The PLR stays at 0.15 percent, and the goodput stays at about 500 KB/s. The user can utilize the allocated link capacity completely and enjoy a better QoS experience. We define the handoff delay as the time from SNMC sending the handoff instruction to the controller’s signals arriving at MEO satellite. The handoff delay in the experiment is about 206 ms, which is the sum of the link delay from SNMC to MEO satellite, SNMC! GEO satellite! MEO satellite.

4.2.2

Traffic Engineering in the Space-Terrestrial Network The second experiment is to show the flexible traffic engineering in the space-terrestrial network of SERvICE. A server in DC2 transfers some data to the server in DC1. At first, the traffic is forwarded in the terrestrial network via the backbone network. However, one of the switches in the path breaks down. SNMC then arranges a new path and steers the traffic in the space network. In the experiment, we allocate 500 KBps for the bandwidth of the terrestrial link and 300 KBps for the satellite

VOL. 17,

NO. 3,

MARCH 2018

Fig. 9. Throughput of terrestrial transmission and space-terrestrial transmission.

link. The packet loss rate of the satellite link is set to 1.5 percent. Then, we send data from the server8 in DC2 to the server1 in DC1 continuously to simulate the scene of data exchange among datacenters. At first, the allocated path is Server8! Switch8! Switch6! EdgeRouter2! Switch2! Switch3! Server1. But Switch2 breaks down at 100 seconds. C-DC1 collects this situation and tells the SNMC. The SNMC arranges a new path and C-DC1 steers the traffic along the new path: Server8! Switch8! Switch5! EdgeRouter1! Switch1! Switch3! Server1. However, Switch5 breaks down at 200 seconds. C-DC2 collects this situation and tells the SNMC. The SNMC arranges a new path for the traffic to transmit via the satellite links. The path is Server8! Switch8! Switch6! EdgeRouter2! SG2! LEO3! MEO10! MEO8! MEO7! MEO5! MEO3! MEO4! LEO2! SG1! EdgeRouter1! Switch1! Switch3! Server1. We can see from Fig. 9 that there is no obvious change at the first handoff (Switch2 breaks down) because the handoff process is very fast. The throughput falls to about 300 KBps at the second handoff (Switch5 breaks down) because the traffic is forwarded to the satellite links. The transmission quality is affected because there is packet loss in the satellite links. According to the two experiments introduced above, we can conclude that SERvICE does have feasibility and the prototype does have functionality. Flexible traffic engineering can be achieved in SERvICE. In addition, flexible traffic engineering can be used for smart traffic offloading and load balancing in SERvICE. Resilience can also be increased because satellite links can provide additional bandwidth to divert traffic from congested areas.

5

QOS GUARANTEE ALGORITHMS

In this section, we present the proposed QoS-oriented heuristic algorithms, the QSR algorithm and the QBA algorithm. The algorithms are deployed in the SNMC and mainly focus on the fine-grained QoS guarantee in the space networks.

5.1 Network Modeling The problem of proposing performance requirements to more than two parameters, which are independent from each other, is a NP-complete problem [30]. When studying QoS guarantee, it is required to propose performance requirements to several parameters at the same time, such as bandwidth, delay and packet loss rate. QoS guarantee in


satellite networks considering multiple parameters, such as bandwidth, delay and packet loss rate, is a NP-complete problem [31]. Therefore we propose a heuristic algorithm to achieve fine-grained QoS guarantee in satellite networks. Here, fine-grained means that the QoS strategies should be at the level of user, application, flows, even packets, meeting the requests of tenants dynamically. The fine-grained strategies are deployed not only on the border nodes, but also on the intra-domain nodes. We represent the satellite networks as a weighted graph and denote it by Gs ¼ ðN s ; Ls Þ, where N s is the set of nodes in the satellite networks and is partitioned into GEO satellites N s ðGÞ, MEO satellites N s ðMÞ and LEO satellites N s ðLÞ, (i.e., N s ¼ N s ðGÞ [ N s ðMÞ [ N s ðLÞ. Ls is the set of links between two nodes in satellite networks. We use the LEO satellites as the access satellites and the forwarding process mainly depends on the ISLs among MEO satellites because we prefer not to leave too much forwarding burden on the LEO satellites. Therefore, according to the framework design described in Section 3, Ls ¼ Ls ðG; MÞ [ Ls ðM; LÞ [ Ls ðM; MÞ (e.g., Ls ðG; MÞ denotes the link between GEO satellites and MEO satellites). li;j 2 Ls is the links between two nodes i and j. According to the information collected by GEO satellites, the satellites with the same SaIDs are divided into groups. If the SNMC decides that the user data should be transmitted in the satellite network, an appropriate satellites group is selected according to the types of the uses. We define three ToS, namely ToS ¼ ftos1 ; tos2 ; tos3 g. tos1 identifies the data that needs the highest priority, which means that tos1 traffic needs high bandwidth, low packet loss rate, short delay and low jitter. The tos1 traffic may be sent by the users in government, military, or the applications such as video conference, or the tenants that have paid much to the operators. tos2 identifies the data that need real-time transmission but need very low bandwidth. The instruction data, or signal data, or point-of-sale data may be marked as tos2 . tos3 identifies the traffic that is delay-tolerant but needs high bandwidth. The file transmission data, or database querying data can be marked as tos3 . Our focus is on QoS guarantee considering different ToS in the same group.

5.2 QSR Algorithm We suppose that there are m MEO satellites in the selected GROUP and two LEO satellites as the ingress node and egress node. We define ci;j as link connection factor. ci;j is set 0 when there is no available connection between node i and node j; ci;j is set 1 when there is available connection between node i and node j. We define Cmðmþ2Þ ¼ ðci;j Þmðmþ2Þ as the connection matrix, Bmðmþ2Þ ¼ ðbi;j Þmðmþ2Þ as the available bandwidth matrix, Dmðmþ2Þ ¼ ðdi;j Þmðmþ2Þ as the link-delay matrix, and Pmðmþ2Þ ¼ ðpi;j Þmðmþ2Þ as the packet-loss matrix. bi;j , di;j and pi;j are the available bandwidth, delay and packet loss rate between node i and j respectively. Here, the link delay means the propagation delay between satellites. The packet loss rate measures the transmission quality of the satellite link. According to Cmðmþ2Þ , we define PATH ¼ fpath1 ; path2 ; path3 ; . . . ; pathk g as the optional paths from the ingress LEO satellite to the egress LEO satellite. There are k optional paths totally and

patha ð14a4kÞ is the ath optional the weight factor 2 w11 w12 W33 ¼ 4 w21 w22 w31 w32

711

path. We define W33 as 3 w13 w23 5; w33

(2)

w11 þ w12 þ w13 ¼ 1, w21 þ w22 þ w23 ¼ 1 and w31 þ w32 þ w33 ¼ 1. For example, w11 means the weight factor of available bandwidth of tos1 , w12 means the weight factor of link delay of tos1 , w23 means the weight factor of packet loss rate of tos2 . We also suppose that there are n hops of the ath optional path. According to Bmðmþ2Þ , Dmðmþ2Þ and Pmðmþ2Þ , we define patha ðBÞ ¼ fba1 ; ba2 ; ba3 ; . . . ; ban g, patha ðDÞ ¼ fda1 ; da2 ; da3 ; . . . ; dan g and patha ðP Þ ¼ fpa1 ; pa2 ; pa3 ; . . . ; pan g, where bar ð14r4nÞ, dar ð14r4nÞ and par ð14r4nÞ are the available bandwidth, delay and packet loss rate of rth hop in the ath optional path, respectively. Because bar , dar , and par have different dimensions, we should normalize them. We take the normalization of ba1 as an example ba1 ¼

ba1 min14r4n bar : max14r4n bar min14r4n bar

(3)

In this way, we get normalized bar , dar and par , respectively. We define decision matrix U11k ¼ ðu1a Þ1k , U21k ¼ ðu2a Þ1k , and U31k ¼ ðu3a Þ1k , ð14a4kÞ for tos1 , tos2 and tos3 , respectively. We take u1a as an example and we can get u2a and u3a likewise. u1a is the decision factor of tos1 , and we choose the biggest one as the appropriate path u1a ¼ w11

n X

bar w12

a X

r¼1

dar w13

n X

r¼1

par :

(4)

r¼1

We also define the adjustment factor Q to reduce the effect of a bottleneck link in available bandwidth, delay and packet loss rate min14r4n bar a max14r4n dar Pn a ; QD ¼ Pn ; a r¼1 br r¼1 dr max14r4n par QaP ¼ Pn a r¼1 pr

QaB ¼

u1a ¼ w11 QaB

n X

bar w12 QaD

r¼1

w13

QaP

n X

a X

dar

r¼1

par

(5)

(6)

:

r¼1

We can get u2a and u3a likewise. We take QaB as an example to explain how it can reduce the effect of bottleneck link in available bandwidth when choosing the appropriate path. We suppose that bax ð14x4nÞ is the minimum of bar QaB ¼

min14r4n bar bax Pn a ¼ Px1 P n a a a r¼1 br r¼1 br þ r¼xþ1 br þbx

1 : ¼ Px1 P ð r¼1 bar þ nr¼xþ1 bax Þ=bax þ 1

(7)

Let us see what the effect QaB have on u1a . The smaller bax is, the smaller QaB will be. It can be proved that the bigger max14r4n dar and max14r4n par are, the bigger QaD and QaP

712


will be. Therefore u1a will become smaller and we have less possibility to choose it. We define paths as the selected proper path.

Algorithm 1. QSR Algorithm Input: SaID, ToU, ToS; Status information of satellite networks; Output: Satellite networks QoS routing solution; 1: for there are new requests do 2: Compare SaID with ToU; 3: if SaID meet ToU then 4: Add the satellite to GROUP ; 5: end if 6: end for 7: Generate Cmðmþ2Þ , Bmðmþ2Þ , Dmðmþ2Þ and Pmðmþ2Þ ; 8: PATH Cmðmþ2Þ ; == Generate PATH according to Cmðmþ2Þ . 9: patha ðBÞ ðBmðmþ2Þ \ PATHÞ; patha ðDÞ ðDmðmþ2Þ \ PATHÞ; patha ðP Þ ðPmðmþ2Þ \ PATHÞ; 10: bar bar , dar dar , par par ; == Normalization. a 11: Use formulas (5) to get QB , QaD , and QaP ; 12: Set W33 ; == Set the weight matrix for tos1 , tos2 , and tos3 . 13: if ToS=tos1 then 14: Use formulas (6) to get u1a , choose maxu1a ; 15: else if ToS=tos2 then 16: Use formulas (6) to get u2a , choose maxu2a ; 17: else 18: Use formulas (6) to get u3a , choose maxu3a ; 19: end if 20: return Satellite networks QoS routing solution;

The basic procedure of the QSR algorithm is shown in Algorithm 1. It accepts SaID, ToU, ToS and the status information of satellite networks, such as bandwidth, delay and packet loss rate as input. After receiving the users request, we compare SaIDs of all the satellites to select proper satellites into GROUP . Then, we generate Cmðmþ2Þ , Bmðmþ2Þ , Dmðmþ2Þ and Pmðmþ2Þ for the satellites in GROUP . We list the optional paths from the ingress LEO satellite to the egress LEO satellite hop by hop according to the connection matrix Cmðmþ2Þ and put the optional paths into PATH. Then, we will get the available bandwidth, delay and packet loss rate of every hop in every optional path, and put them into patha ðBÞ, patha ðDÞ and patha ðP Þ respectively. After normalizing every kind of parameters, and calculating the adjustment factors, we handle different ToS. We assign the weight matrix W33 with proper value according to the strategies of SNMC. After that, we calculate decision factors for every optional path in every ToS, and then choose the proper path paths for the traffic with different ToS.

5.3 QBA Algorithm QSR focuses on choosing a proper path for the traffic with different ToS. It is possible that there are relatively too many users who have need of bandwidth on one or several link. The bandwidth of these links of the selected paths is the best choice but can still not satisfy the request of the user. Considering that there may be users, who have no or lower priority to request for bandwidth, but still occupy too much bandwidth, it is relatively unfair for the users who

VOL. 17,

NO. 3,

MARCH 2018

have higher priority (for example, tos1 ), but request for bandwidth late. To handle this problem, we propose QBA to negotiate and share bandwidth among the users. QBA is based on the results of QSR. Here, we take tos1 as an example. We define paths ¼ fbs1 ; bs2 ; bs3 ; . . . ; bsn g as the available bandwidth for the selected of the rth hop path. bsr ð14r4nÞ is the available bandwidth tos1 tos1 ; ab of the selected path. apathtos1 ðBÞ ¼ abtos1 1 2 ; ab3 ; . . . ; tos1 tos1 abn g. abr ð14r4nÞ is the allocated bandwidth of the rth hop of the selected path to a tos1 user. repathtos1 ðBÞ ¼ tos1 tos1 tos1 . rebtos1 reb1 ; rebtos1 2 ; reb3 ; . . . ; rebn r ð14r4nÞ is the requested bandwidth of rth hop of the selected path to a tos1 user. Similarly, we get apathtos2 ðBÞ, apathtos3 ðBÞ, repathtos2 ðBÞ, and repathtos3 ðBÞ. To meet the bandwidth request of different ToS users, we define F ¼ f’tos1 ; ’tos2 ; ’tos3 gð’tos1 > ’tos3 > ’tos2 Þ as the negotiation factor. Then, we can get 8 tos1 tos1 > < abr ¼ ’tos1 rebr tos2 (8) abr ¼ ’tos2 rebtos2 r > : tos3 tos3 abr ¼ ’tos3 rebr The restriction is X X X abtos1 þ abtos2 þ abtos3 ¼ bsr ð14r4nÞ: r r r

(9)

Algorithm 2. QBA Algorithm Input: ToS, paths from QSR; Output: Satellite networks bandwidth allocation solution; 1: Set F; == Set the negotiation factors for tos1 , tos2 , and tos3 . 2: for new arrives do P requestP 3: if rebtos1 þ rebtos3 < bsr then r r tos1 tos1 tos3 4: abrP ¼ rebr ; abrP ¼ rebtos3 r ;P s 5: if rebtos2 rebtos1 rebtos3 then r 4br r r tos2 tos2 6: abrP ¼ rebr ; P tos1 P tos3 s 7: if rebtos2 > bP rebr P rebr then r r 8: abtos2 ¼ bsr rebtos1 rebtos3 r r r ; 9: end if 10: end if P P s 11: else if rebtos1 þ rebtos3 r r 5br then tos2 12: Use formulas (8) and (9) to get abtos1 and abtos3 r , abr r ; 13: end if 14: end for 15: return Satellite networks bandwidth allocation solution;

The basic procedure of the QBA algorithm is shown in Algorithm 2. It accepts ToS and the results of QSR as input. First, we set the negotiation factor according to the strategies of SNMC. As defined before, the traffic tos1 have the highest priority for requesting bandwidth, and the traffic tos2 have the lowest priority. Therefore ’tos1 > ’tos3 > ’tos2 should be considered when setting the negotiation factor. When a new request arrives, all the requests (including the requests of the ongoing traffic) are checked. If the sum of all the requested bandwidth of tos1 and tos3 is smaller than the available bandwidth, the allocated bandwidth of tos1 and tos3 is equal to the requested bandwidth. Then, if all the requested bandwidth of tos2 is not bigger than the residual bandwidth, the allocated bandwidth of tos2 is equal to the


713

to MEO2-5. Two LEO satellites are marked as LEO1 and LEO2. We take the links that stay connected from 10:00 am to 10:30 am as the links in the test topology. The setting of the link delay is based on the distance between the connected satellites. The bandwidth of the different links is the randomly chosen from 500 KBps to 2 MBps. The packet loss rates of the different links are randomly chosen from 0.2 to 1.5 percent. The data are classified and allocated appropriate ToS at SGs according to the strategies from SNMC.

Fig. 10. Experimental topology.

requested bandwidth. On the contrary, the allocated bandwidth of tos2 is equal to the residual bandwidth. If the sum of all the requested bandwidth of tos1 and tos3 is no less than the available bandwidth, there should be a negotiation among all the requests on this link. After that, we can get the final QoS-oriented bandwidth allocation solution. To sum up, the proposed heuristic algorithms take multiple parameters into consideration and arrange QoS routing and allocate bandwidth for the users with multiple types of service. In addition, QSR adopts the adjustment factor Q to reduce the effect of bottleneck link in available bandwidth, delay and packet loss rate; QBA adopts the negotiation factor F to handle the problem of bandwidth allocation among users considering types of service. Furthermore, the proposed algorithms adopt hop-based strategies, which is appropriate for DTN-based satellite networks.

6

EXPERIMENTAL EVALUATION

In this section, we conduct experiments about the proposed fine-grained QoS-oriented algorithms, QSR and QBA, in our prototype to verify the efficiency of the algorithms.

6.1 Experimental Topology The experimental topology is shown in Fig. 10. The topology is based on the Tr constellation. We simulate the Tr constellation in STK to get the connection information and distance between the connected satellites. We mark two orbits of MEO satellites as MEO1-1 to MEO1-5 and MEO2-1

Fig. 11. Routings of SPF strategy and QSR strategy.

6.2 Experimental Results The experiments are divided into two parts, one for QSR and the other for QBA. 6.2.1 Experiments of QSR To test QSR, we send a 20 Mbit file from LEO1 to LEO2 under different strategies to test the performance of QSR by comparing it with the Shortest Path First (SPF) strategy. The routing of SPF is shown in Fig. 11a, LEO1! MEO11!MEO2-2!MEO2-3!LEO2. The routings of QSR are shown as Figs. 11b, 11c, and 11d. We test three traffic flows with different service types: tos1 , tos2 , and tos3 . According to QSR, we set the weight factor matrix of bandwidth, delay, and packet loss rate for tos1 , tos2 , and tos3 as 2 3 0:33 0:33 0:33 0:8 0:1 5: W33 ¼ 4 0:1 0:8 0:1 0:1 We use adjustment factor QaB , QaD , Qap to get the decision factors u1a , u2a , and u3a . Then, the paths for tos1 , tos2 , and tos3 are decided. The path for traffic tos1 is LEO1!MEO1-1!MEO21!MEO1-2!MEO2-3!LEO2. The path for traffic tos2 is LEO1!MEO1-1!MEO2-1!MEO1-5!MEO2-3!LEO2. The path for traffic tos3 is LEO1!MEO1-1!MEO22!MEO1-2!MEO2-3!LEO2. The normalized values bar , dar and par of the selected paths for tos1 , tos2 , and tos3 are shown in Fig. 12. SPF always chooses the path that has the shortest delay. Therefore the normalized delay of SPF is the smallest. But other parameters of SPF are the worst. The traffic tos1 requires

714


VOL. 17,

NO. 3,

MARCH 2018

Fig. 12. Different normalized parameters of SPF strategy and QSR strategy.

Fig. 14. Comparison of the file transmission delay of SPF strategy and QSR strategy.

good qualities in all three parameters. All of the three parameters of tos1 are the second best among SPF, tos2 , and tos3 . The traffic tos2 requires short delay. Therefore the normalized delay parameter is the smallest. The traffic tos3 requires high bandwidth. The normalized bandwidth parameter is much bigger than others. Fig. 13 shows the comparison of the file transmission rate of SPF and QSR. We collect the transmission rate at each hop along the path of SPF, tos1 , tos2 , and tos3 . We can see that although the number of hops of SPF is minimal, the transmission rate is the lowest. Because SPF always chooses the link that has the shortest delay, the other link parameters are affected dramatically. Among tos1 , tos2 , and tos3 , the transmission rate of tos1 is slightly higher than that of tos2 . The transmission rate of tos3 is the highest because the path of tos3 has the highest bandwidth. Fig. 14 shows the comparison of the file transmission delay of SPF and QSR. We set the payload size of bundle packets to 300, 500, 700, 900, 1100, and 1300 Bytes to test the file transmission delay. We send a 20 Mbit file from LEO1 to LEO2 and define the time of completely receiving the file at LEO2 as the file transmission delay. The delay tends to be small as the payload become bigger. We can see that although SPF chooses the path with the shortest delay, other link parameters are the worst. Retransmission of bundle packets of traffic SPF is very serious, therefore the transmission delay is the highest. Although the traffic tos3 has the highest bandwidth, other link parameters are bad. Therefore the transmission delay of traffic tos3 is the highest among tos1 , tos2 , and tos3 . The transmission delay of traffic tos2 is the smallest because the link delay and packet loss rate are the smallest among tos1 , tos2 , and tos3 . The retransmission packets of traffic tos2 are the fewest.

Fig. 15 shows the file transmission delay of QSR with/ without adjustment factor. We get the QoS routing solutions with and without adjustment factor for tos1 , tos2 , and tos3 respectively. As we can see from Fig. 11, the path for traffic tos1 without the adjustment factor is LEO1!MEO11!MEO1-5!MEO2-3!LEO2; the path for traffic tos2 without the adjustment factor is LEO1!MEO1-1!MEO2-2!MEO23!LEO2; the path for traffic tos3 without the adjustment factor is LEO1!MEO1-1!MEO2-2!MEO1-3!MEO2-3!LEO2. We can see from Fig. 15 that, the file transmission delay of traffic tos1 , tos2 , and tos3 with the adjustment factor is smaller than those without the adjustment factor. Because the adjustment factor can reduce the effect of bottleneck link in available bandwidth, delay and packet loss rate.

Fig. 13. Comparison of the file transmission rate of SPF strategy and QSR strategy.

6.2.2 Experiments of QBA To test QBA, we set the total bandwidth of the link to 800 Kbytes and send traffic tos1 , tos2 , and tos3 . We take the transmission rates of tos1 , tos2 , and tos3 (500, 200, and 500 KB/s) as the requested bandwidth of traffic tos1 , tos2 , and tos3 respectively. We first conduct the experiment without the bandwidth allocation strategy in QBA. At first, we only send the traffic tos1 and tos2 . We can see from Fig. 16 that both of the traffic can be sent at full speed. We then send the traffic tos3 at 10s. The transmission rates of traffic tos1 and tos2 fall to about 370 and 130 KB/s and the transmission rate of tos3 is about 300 KB/s. The traffic tos1 ends at about 41s and then, transmission rates of traffic tos2 and tos3 rise to 500 and 200 KB/s. The bandwidth satisfaction rates (allocated bandwidth/requested bandwidth) of traffic tos1 , tos2 , and tos3 are 74, 65, and 60 percent, respectively when all three kinds of traffic transmit in the link. According to the initial settings, traffic tos1 and tos3 require high bandwidth while traffic tos2

Fig. 15. File transmission delay with or without adjustment factor.


Fig. 16. Transmission rate without bandwidth allocation.

Fig. 17. Transmission rate with bandwidth allocation.

do not. The requests of bandwidth are not satisfied without bandwidth allocation. Then, we conduct the experiment with the bandwidth allocation strategy in QBA. We set the negotiation factor ’tos1 , ’tos2 , and ’tos3 to 0.9, 0.1, and 0.66. The requested bandwidth of traffic tos1 , tos2 , and tos3 is 500, 200, and 500 KBps. First, we only send the traffic tos1 and tos2 . We can see from Fig. 17 that both of the traffic can be sent at full speed. Because the requested bandwidth of traffic tos1 and tos3 (totally 500 KBps) is smaller than the available bandwidth (800 KBps). The requested bandwidth of traffic tos2 (200 KBps) is smaller than the residual bandwidth (300 KBps). We then send the traffic tos3 at 10s. The requested bandwidth of traffic tos1 and tos3 (totally 1000 KBps) is bigger than the available bandwidth (800 KBps), therefore there should be a negotiation among the traffic. The negotiation results can be seen from Fig. 17. The transmission rates of traffic tos1 and tos2 fall to about 450 and 20 KB/s and the transmission rate of tos3 is about 330 KB/s. The traffic tos1 ends at about 29s and then, transmission rates of traffic tos2 and tos3 rise to 500 and 200 KB/s. The bandwidth satisfaction rate of traffic tos1 , tos2 , and tos3 are 90, 10, and 66 percent respectively when all three kinds of traffic transmit in the link.

8

7

[1]

FURTHER DISCUSSION

In this paper, we have proposed SERvICE to achieve flexible satellite network traffic engineering and fine-grained QoS guarantee. There are some directions and challenges that could be further explored. We list some important ones as follows. First, centralized control structure will bring some safety problems, for example, the control link can be attacked. Some safety and disaster recovery mechanism should be proposed in SERvICE. Second, the changing topology and fine-grained strategies will bring scalability problem. The processing capability and storage space are limited in satellite nodes. Therefore, strategies about aggregation and simplification of the flow tables should be studied in SERvICE. Third, the monitor module in GEO satellite collects and updates the link status periodically. The QoS strategies may change frequently because of the mobility of satellites. Therefore, the balance between the update period and management overhead is necessary to be studied. Fourth, more proper scenes should be designed and further experiments should be conducted to valid SERvICE. More attention should be paid to strategies or algorithms deployed in the management plane so that it can handle more complicated situations.

715

SUMMARY

In this paper, we have presented an integrated spaceterrestrial satellite communication network framework, SERvICE. SERvICE supports fine-grained QoS guarantee and flexible traffic engineering agilely. We have implemented a prototype and evaluated SERvICE in the prototype to validate the feasibility of SERvICE and the functionality of the prototype. Furthermore, we have proposed two QoS-oriented heuristic algorithms, QSR and QBA, providing a QoS routing solution and a bandwidth allocation solution. The experimental results show that they can achieve the goal of QoS guarantee.

ACKNOWLEDGMENTS This work was supported in part by the National High Technology of China (“863 program”) under Grant No. 2015AA015702, NSAF of China under Grant No. U1530118, National Basic Research Program of China (“973 program”) under Grant No. 2013CB329101, and NSFC of China under Grant No. 61232017 and 61422101

REFERENCES

[2] [3] [4]

[5] [6] [7]

[8]

[9]

D. J. Bem, T. W. Wieckowski, and R. J. Zielinski, “Broadband satellite systems,” IEEE Commun. Surveys Tuts., vol. 3, no. 1, pp. 2–15, Jan.–Mar. 2000. “World Bank. GDP Growth (annual %),” May 2017, http://data. worldbank.org/indicator/NY.GDP.MKTP.KD.ZG “2017 SIA State of Satellite Industry Report,” Jul. 2017, http:// www.sia.org/annual-state-of-the-satellite-industry-reports/2017sia-state-of-satellite-industry-report/ J. Bao, B. Zhao, W. Yu, Z. Feng, C. Wu, and Z. Gong, “OpenSAN: A software-defined satellite network architecture,” ACM SIGCOMM Comput. Commun. Rev., vol. 44, no. 4, pp. 347–348, 2014. L. Bertaux, et al., “Software defined networking and virtualization for broadband satellite networks,” IEEE Commun. Mag., vol. 53, no. 3, pp. 54–60, Mar. 2015. R. Ferr us, et al., “SDN/NFV-enabled satellite communications networks: Opportunities, scenarios and challenges,” Phys. Commun., vol. 18, pp. 95–112, 2016. B. A. A. Nunes, M. Mendonca, X. N. Nguyen, K. Obraczka, and T. Turletti, “A survey of software-defined networking: Past, present, and future of programmable networks,” IEEE Commun. Surveys Tuts., vol. 16, no. 3, pp. 1617–1634, Jul.–Sep. 2014. R. Mijumbi, J. Serrat, J. L. Gorricho, N. Bouten, F. De Turck, and R. Boutaba, “Network function virtualization: State-of-the-art and research challenges,” IEEE Commun. Surveys Tuts., vol. 18, no. 1, pp. 236–262, Jan.–Mar. 2016. Z. Tang, B. Zhao, W. Yu, Z. Feng, and C. Wu, “Software defined satellite networks: Benefits and challenges,” in Proc. IEEE Comput. Commun. IT Appl. Conf., 2014, pp. 127–132.

716


[10] X. N. Yang, J. L. Xu, and C. Y. Lou, “Software-defined satellite: A new concept for space information system,” in Proc. 2nd Int. Conf. Instrum. Meas. Comput. Commun. Control, 2012, pp. 586–589. [11] J. Feng, L. Jiang, Y. Shen, W. Ma, and M. Yin, “A scheme for software defined ORS satellite networking,” in Proc. IEEE 4th Int. Conf. Big Data Cloud Comput., 2014, pp. 716–721. Kapovits, S. Covaci, C. Ververidis, V. Siris, and M. Guta, [12] A. “Advanced topics in service delivery over integrated satellite terrestrial networks,” in Proc. 7th Adv. Satellite Multimedia Syst. Conf. 13th Signal Process. Space Commun. Workshop, 2014, pp. 92–98. [13] S. Burleigh, et al., “Delay-tolerant networking: An approach to interplanetary internet,” IEEE Commun. Mag., vol. 41, no. 6, pp. 128–136, Jun. 2003. [14] A. Lara, A. Kolasani, and B. Ramamurthy, “Network innovation using OpenFlow: A survey,” IEEE Commun. Surveys Tuts., vol. 16, no. 1, pp. 493–512, Jan.–Mar. 2014. [15] S. Jain, et al., “B4: Experience with a globally-deployed software defined WAN,” ACM SIGCOMM Comput. Commun. Rev., vol. 43, no. 4, pp. 3–14, 2013. [16] A. Gudipati, D. Perry, L. E. Li, and S. Katti, “SoftRAN: Software defined radio access network,” in Proc. 2nd ACM SIGCOMM Workshop Hot Topics Softw. Defined Netw., 2013, pp. 25–30. [17] A. N. Patel, P. N. Ji, and T. Wang, “QoS-aware optical burst switching in OpenFlow based software-defined optical networks,” in Proc. 17th Int. Conf. Opt. Netw. Des. Model., 2013, pp. 275–280. [18] F. Long, Satellite Network Robust QoS-Aware Routing. Berlin, Germany: Springer, 2014. [19] Satellite Tool Kit (STK). (2017, May). [Online]. Available: http:// www.agi.com [20] N. M. K. Chowdhury and R. Boutaba, “A survey of network virtualization,” Comput. Netw., vol. 54, no. 5, pp. 862–876, 2010. [21] Kernel Virtual Machine (KVM). (2017, May). [Online]. Available: http://www.linux-kvm.org [22] OpenStack. (2017, May). [Online]. Available: https://www. openstack.org/ [23] C. E. Leiserson, “Fat-trees: Universal networks for hardwareefficient supercomputing,” IEEE Trans. Comput., vol. C-100, no. 10, pp. 892–901, Oct. 1985. [24] A. Singh, et al., “Jupiter rising: A decade of clos topologies and centralized control in Google’s datacenter network,” ACM SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 183–197, 2015. [25] POX. (2017, May). [Online]. Available: http://sdnhub.org/ tutorials/pox/ [26] T. Li, H. Zhou, and H. Luo, “A new method for providing network services: Service function chain,” Opt. Switching and Netw., vol. 26, pp. 60–68, 2017. [27] Open vSwitch. (2017, May). [Online]. Available: http://www. openvswitch.org [28] S. Burleigh, “Interplanetary overlay network: An implementation of the DTN bundle protocol,” in Proc. 4th IEEE Consum. Commun. Netw. Conf., 2007, pp. 222–226. [29] M. Ramadas, S. Burleigh, and S. Farrell, “Licklider transmission protocol—specification,” Internet Engineering Task Force (IETF) Network Working Group, RFC 5326, Sep. 2008, http://www.ietf. org/rfc/rfc5326.txt [30] M. R. Gary and D. S. Johnson, Computers and Intractability: A Guide to the Theory of NP-Completeness. San Francisco, CA, USA: Freeman, 1979. [31] F. Kuipers, P. Van Mieghem, T. Korkmaz, and M. Krunz, “An overview of constraint-based path selection algorithms for QoS routing,” IEEE Commun. Mag., vol. 40, no. 12, pp. 50–55, Dec. 2002. Taixin Li (S’17) received the BS degree in telecommunications engineering from Beijing Jiaotong University (BJTU), in 2013, and then entered the National Engineering Lab for Next Generation Internet Interconnection Devices, BJTU. Currently, he is working toward the the PhD degree in telecommunications and information system at BJTU, China. His research interests include next generation internet, service function chain, software defined networking, delay tolerant networking, and satellite networking. He is a student member of the IEEE.

VOL. 17,

NO. 3,

MARCH 2018

Huachun Zhou received the BS degree from the Peoples Police Officer University of China, in 1986, the MS degree in telecommunication automation, and the PhD degree in telecommunications and information system from Beijing Jiaotong University (BJTU), in 1989 and 2008, respectively. In October 1994, he joined the Institute of Automation Systems, BJTU, where he is a lecturer. From Apr. 1999 - Sep. 2009, he was a senior engineer in the School of Electronic and Information Engineering, BJTU, and at the Network Management Research Center, BJTU. From Oct. 2009 to now, he has been a professor in the National Engineering Lab for Next Generation Internet Interconnection Devices, BJTU. He has authored more than 40 peer-reviewed papers and he is the holder of 17 patents. His main research interests include the area of mobility management, mobile and secure computing, routing protocols, network management, and satellite network.

Hongbin Luo (M’07) received the BS degree from the Beijing University of Aeronautics and Astronautics, China, in 1999, and the MS (with Hons.) and PhD degrees in communications and information science from the University of Electronic Science and Technology of China (UESTC), in June 2004 and March 2007, respectively. In June 2007, he joined the School of Electronic and Information Engineering, Beijing Jiaotong University, where he is a professor. From Sep. 2009 -Sep. 2010, he was a visiting scholar in the Department of Computer Science, Purdue University. He has authored more than 50 peer-reviewed papers in leading journals (such as the IEEE/ ACM Transactions on Networking and the IEEE Journal on Selected Areas in Communications) and conference proceedings. In 2014, he won the Second Class National Invention Award and the National Science Fund for Excellent Young Scholars from the National Natural Science Foundation of China (NSFC). He is now an associate editor of the IEEE Communications Letters and the KSII Transactions on Internet and Information Systems. He has served as a TPC member of IEEE GLOBECOM, IEEE ICC, IEEE HPSR, and many others. His research interests include the wide areas of network technologies including routing, Internet architecture, and optical networking. He is a member of the IEEE.

Shui Yu (M’05-SM’12) is currently a senior lecturer of the School of Information Technology, Deakin University. He is a senior member of the IEEE, and a member of the AAAS and ACM, the vice chair of the Technical Committee on Big Data Processing, Analytics, and Networking of the IEEE Communication Society. Dr Yu’s research interests include security and privacy in networking, big data, and cyberspace, and mathematical modelling. He has published two monographs and edited two books, more than 150 technical papers, including top journals and top conferences, such as IEEE TPDS, IEEE TC, IEEE TIFS, IEEE TMC, IEEE TKDE, IEEE TETC, and IEEE INFOCOM. Dr. Yu initiated the research field of networking for big data in 2013. His h-index is 25. He actively serves his research communities in various roles. He is currently serving the editorial boards of IEEE Communications Surveys and Tutorials, IEEE Transactions on Computational Social Systems, IEEE Access, IEEE Journal of Internet of Things, IEEE Communications Magazine, and a number of other international journals. He has served more than 70 international conferences as a member of the organizing committee, such as the publication chair for IEEE GLOBECOM 2015 and 2017, IEEE INFOCOM 2016 and 2017, the TPC co-chair for IEEE BigDataService 2015, IEEE ITNAC 2015, and the executive general chair for ACSW 2017. " For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.