Keywords

1 Introduction

With the development of human space technology, human’s life has gradually become closely connected to space information. Constructing satellite-centered systems integrating various civilian and military applications, combined with the vigorous development of space information networks is expected to be an important direction [2, 10, 17]. However, past satellite systems organized by function-customized satellites are only able to serve a specific group of users. Besides, the lack of a multi-user and multi-task management mechanism incurs the tough problem of resource sharing and application coordination [19]. To date, how to efficiently design management and control protocols for heterogeneous satellite network to realize information sharing and application collaboration has been a difficult problem in academia and the reasons are as follows. 1) Heterogeneity between different satellite systems. For example, there are great distinctions between UAVs (unmanned aerial vehicles) systems in near space and satellite systems in deep space with regard to movement patterns, resource attributes and service types. One single protocol cannot fit to all networks. 2) High dynamic in satellite networks. The time-varying characteristic of the network topology conduces no stable end-to-end links. Furthermore, protocols for time-varying networks are recognized as calculation-consumption and hard to reduce complexity as well. 3) Function-specialized payloads. The onboard payloads are designed to achieve a specific task since manufactured. Thus, the quality and standard of data respectively generated by satellite systems are not uniform, which poses great challenges to the design of cross-network resource management protocols. 4) The difficulty in maintenance and function upgrade for satellites in orbit. Onboard payloads cannot be modified once the satellite is launched. In response to inflexibility, resource management and control protocols need to be reconfigurable. Undoubtedly, satellite networks lack effective means of resource sharing and demand for better flexibility. Novel network architecture and network management and control methods are anxiously yearned improve the sharing and reconfiguration capabilities of satellite networks.

Software defined networking (SDN), a new network architecture that separates the control and data forwarding plane, has aroused great interest in applying SDN to spatial information networks with its openness, flexibility and programmability [6]. Applications of SDN into satellite networks have many notable advantages. 1) The unified access and management of heterogeneous networks can be attained through customized southbound interfaces (SBIs). Furthermore, the management of satellite resources under different granularity can be accomplished by redesigning actions of SBIs. 2) The operation of distributed routing protocols on each satellite node is not necessitated under the circumstance of the SDN’s centralized control. In the meantime, central SDN controllers are able to optimize cross-network resource allocation under the global network view [5]. 3) The separation of control and forwarding planes, and the programmability in the control plane enable fast deployment of network function. To the best of our knowledge, many researchers have investigated the software-defined spatial information network and achieved a series of outcomes. In the aspect of routing strategy design, authors in [18] proposed a hybrid of centralized and distributed routing strategy based on SDN, aiming to optimize the delay of data transmission between quantum satellites. In terms of the placement of SDN controllers, the work in [11] adapted to dynamic changes and reduced the establishment time of service flows in large-scale low-orbit satellite constellations, by means of dynamically choosing satellite controllers. The work in [1] introduced the concept of SDN/NFV in the gateway cluster to maximize the bandwidth of the fronthaul link regarding the strategy of gateway selection. With regard to the reliability optimization of SDN-based control links, authors in [3] improved the reliability of control links by jointly optimizing the power allocation of the gateways and the access scheme of control links. However, the aforementioned literatures mainly focus on the network control strategy based on SDN framework. Researches on the implementation of SDN into satellite networks, that is, researches on SBIs’ adaption, are severely lacking. The work in [8] studies the signaling system of the satellite-ground hybrid network proposed a signaling scheme adapting to the dynamic environment. Authors in [4] applied the idea of multi-granularity hierarchical label proposed in [8] to extensions of the OpenFlow, and took advantages of the multi-flowtable provided in the OpenFlow to achieve multi-granular control of satellite resources. However, the work in [8] only conducts a theoretical analysis and does not design a practical signaling scheme which can be used in specific satellite scenarios. Shortcomings in literature [4] lies in problems of high protocol complexity and low protocol efficiency, though, the existing OpenFlow is extended according to specific satellite scenarios.

This paper is committed to analyzing the applicability and redesigning a SBI for the management and control in heterogeneous satellite networks. The main contribution of this paper is to propose a layered architecture of the OpenFlow extension to realize real-time monitoring of network performance, and to improve network flexibility and reconfigurablity. The remaining parts of this article are organized as follow. Section 2 takes a heterogeneous network composed of sensing/relay hybrid satellites as an example to analyze the applicability of the OpenFlow. Section 3 first demonstrates the SBI design norms featuring layered structure, and then presents a paradigm of achieving real-time monitoring for dynamic heterogeneous satellite networks based on the OpenFlow. Section 4 summarizes the whole work and gives a conclusion.

2 Problem Analysis

The OpenFlow, one of the widely-used SBIs standardized by ONF (Open Network Foundation), is responsible for signaling interaction between SDN controllers and SDN-supported switches. However, the OpenFlow is designed for management and control for wired networks such as Ethernet. For example, OpenFlow1.0, the first version of the standardized SBI, features the 12-tuple that forms the header field of the flow table. This 12-tuple represents L2-L4 protocol fields of Ethernet, including physical port number, MAC (Media Access Control) address, IP address, VLan ID and etc. Thus, the OpenFlow can only process IP data packets [9], which is only one aspect of the limitations of applying the OpenFlow into satellite networks. This section below will take a specific satellite scenario as an example to systematically analyze the applicability of the OpenFlow in a satellite network.

2.1 Applicability Analysis Towards Hybrid Satellite Networks

The hybrid satellite scenario is composed of 3 low-orbit remote sensing satellites and 3 relay satellites orbited in geostationary position, as shown in Fig. 1. Assuming that the hybrid heterogeneous network adopts the SDN architecture and is used to complete remote sensing tasks, the OpenFlow should meet the functional requirements of the remote sensing observation task during all the process from task generation stage to task execution stage.The workflow of the hybrid network to perform remote sensing tasks is as follows.

Fig. 1.
figure 1

A scenario of hybrid satellite constellations.

Full size image

Information Acquisition and Maintenance Stage. When there is no task arrival, each controllable satellite need to set up control channel with the central controller (CC, CC lies in the data center shown in Fig. 1). After control messages are successfully exchanged, the CC needs to maintain keep-alive information (e.g., satellite position and battery remaining energy), resource attributions including the number of communications/remote sensing payloads and their parameters, as well as the real-time status of resource occupancy.

Mission Planning Stage. When receiving a task request of remote sensing, the CC needs to obtain the knowledge of observing capabilities from each remote sensing satellites in real time, such as satellite A is equipped with hyper-spectral radar while B is equipped with SAR radar. Then, considering mission requirements, a single or a group of satellite are arranged by CC to perform the remote sensing mission, and the strategy for transferring the data stream is dispatched to the corresponding satellite node using flowtables.

Mission Execution Stage. Observation data starts to flow into the remote sensing satellite once mission is being executed. Data is regarded as a “network stream” by SDN, and its forwarding direction is decided by matched flow entries. Owing to the fact that there is possibility no gateway is visible, the data stream tend to remain stored inside the switching satellite or be forwarded to relay satellites via microwave or laser links. When it comes to data transmission between relay satellites and ground, it is vital to select appropriate frequency and access scheme to prevent signal interference.

From the perspective of task execution, it is worth noted that the high dynamic and wireless communication in satellite network make it quite different from wired networks. The existing SBIs cannot meet the functional requirement of satellite workflow, which is explained below.

1) Overheads induced by controllers are too heavy. In the SDN network, all the forwarding strategies of the switch are dispatched and updated by central controllers, which induces a huge overhead. There are many studies on reducing overhead in the terrestrial network, such as [12, 13]. Due to the satellite mobility, the number of satellite under the control will dynamically change, and the overhead problem will become more severe.

2) Unique service types and resource attributions. Compared with the Ethernet, satellite systems have its inherent TT&C (Telemetry, track and Command) services [15], which creates new service requirements. In addition, satellites, different from power-supported switches, are resource-limited systems. Therefore, the Openflow is forced to add additional statistical information, including the remaining battery power of the satellite, the number of idle communication devices and other system constraints.

3) Multi-granularity resource management with time constraints. In Ethernet, all SDN switches are standardized characterized by port number, throughput and etc. and network topology is fixed. Thus, the CC can uniformly schedule data traffic distributed on each link. However, resources in satellite network are complex and hard to uniformly describe. Besides, the trait of time-varying and delay-nondeterministic network make the flowtable valid only if it successfully reaches its destination node before network changes. Thus, the management ability with multiple granularity is required for SBIs.

4) Needs for new actions in protocols. Due to the lack of end-to-end reliable links, a store-and-forward communication strategy (e.g. the bundle protocol [14]) is often applied in satellite scenarios. This requires SBIs to support the actions of the bundle protocol. As the satellite transmission protocol matures, the SBI will be confronted with support for more new actions.

5) Huge distinctions between wireless and wired communication in MAC. One of the essential functions for MAC in Ethernet is to realize topology discovery and logically form a tree through LLDP (Link Layer Discovery Protocol) [7]. Due to the limitation of transmission power, directional antennas has been widely used, which causes the satellite network to not only perform topology discovery in MAC, but also perform real-time frequency selection and link allocation [16].

Apart from the above reasons, small-scale satellite constellations are unable or unnecessary to implement the whole network functions of Ethernet due to their limited on-board processing capabilities. Therefore, there exists redundancy in the OpenFlow design in regard with satellite networks. In summary, the OpenFlow cannot adapt to the dynamics of satellite scenarios, resource heterogeneity, and the characteristics of wireless communication, and cannot achieve unified management and control of satellite resources with multi-granularity.

3 The Extension of the OpenFlow for Heterogeneous Satellite Networks

3.1 Framework for the OpenFlow Extension

Based on the analysis in Sect. 2, we can derive that the OpenFlow cannot be applied into wireless and dynamic scenarios, and cannot conduct actions such as link and wavelength allocation. In order to solve the above problems, the most intuitive way to extend the SBI is to add resource labels existing in satellite networks into the OpenFlow’s header filed. Since the OpenFlow1.2, it has canceled the fixed-length matching field and replaced it with OXM (OpenFlow eXtensible Match) with a TLV structure. The protocol user can write any number of OXM TLVs into the structure of ofp_match to realize the expansion of header fields. Therefore, we can write all kinds of resource attributions, microwave/laser port information, and frequency information into the header field of the OpenFlow to realize the control of heterogeneous satellite networks. However, the solution above have the defect of high complexity in the protocol design. Satellites have not been standardized, thus, load types and resource capabilities possessed by various satellites are not the same. If information for all kinds of satellite is added to the header field, it will be very large and the match speed of flow table slows down, causing the decrease in switch throughput. Besides, There might be cases where the header field proposed by one satellite system is invalid to that of another satellite systems.

To tackle with the problem of high complexity, the complexity of OpenFlow is moved to the upper level in this paper, and a method of building an intermediate layer on top of the protocol is proposed to realize the adaptation of the SBI, and the management and control of the heterogeneous satellite network at a minimum cost. This paper takes into account that there are both commonalities and characteristics between different types of satellites. The common parts among satellites are the main and usual parts for network decision makers, such as the satellite’s idle communication bandwidth, remaining battery capacity, available storage space, etc. The characteristics of satellites are reflected in the specific resource requirements for specific tasks. For example, remote sensing tasks for real-time observation of a certain area require to identify the time window of the observation, or a certain communication task demands for laser communication and requires a reasonable allocation of wavelength. When there is no task with specific resource requirements, the obtainment of characteristic information is unnecessary, causing the deletion of characteristic information from the header field. The relationship between commonalities and characteristics resembles the relationship between the parent and the child. Part of the characteristics can be calculated from the commonalities. Figure 2 gives two examples of the relationship between the two types of information. The position information of a single satellite can be described by the Kepler’s six elements. The position information and the energy consumption model, combined with the remaining energy at a certain time can constitute a “general satellite” model. Assuming that there is a remote sensing task, the attribute parameters of the above three commonalities can calculate the time window within which the satellite can observe the targeted area. In another example describing the satellite communication capabilities, we can use transmission bandwidth and the number of transponders to define the communication capabilities of general satellites. When the network needs to make use of one specific microwave/laser communication scheme, we can use the conversion to generate specific portal types. It can be learned that we can acquire and maintain the commonalities on a regular basis, and when there is a need for specific tasks, we can obtain the characteristics like a “on-off” switch.

Fig. 2.
figure 2

The relationship between characteristics and commonalities.

Full size image

Based on the ideas above, this paper proposes a SBI design framework, as shown in Fig. 3. The SBI is composed of THE extended OpenFlow and an intermediate layer above it. The extended OpenFlow treats any type of satellite as a general satellite, maintains the common information in real time according to the general satellite model, and reports the common information of the satellite to the middle layer. What the middle layer maintains is commonality/characteristic information, and it will decide whether to convert the commonality information into specific characteristic information and send it to the CC according to the needs of tasks. The advantage of the above architecture is that the complexity of the OpenFlow is low, and the access of heterogeneous satellite networks can be achieved without modifying the OpenFlow. Adaptations towards heterogeneous satellite networks is mainly completed in the middle layer. The feature of this part is on-demand, that is, common information will be further transformed into characteristic information required for task execution and delivered to the CC only when resource scheduling should be performed at a certain granularity or cross-network resource collaboration is needed.

Fig. 3.
figure 3

A framework for SBIs design.

Full size image

3.2 The Extension of the OpenFlow Ased for General Satellite Model

This section gives a paradigm of the OpenFlow extension, iin order to meet the management and control requirements of heterogeneous satellite networks. Although the design ideas described in Sect. 3.1 reduce the complexity of protocols, more attributions originating from general satellite model are needed to add in the header field in the OpenFlow. First, it is assumed that the resource state, the satellite position and time label together constitute a general satellite model. And the resource state can be categorized into these three aspects of communication, calculation, and storage. Since the satellite’s maximum resource capacity and the location at any time can be stored in the CC in advance, real-time information of satellite resources is more valuable and should be acquired through the OpenFlow. OpenFlow1.3 and later versions use the “experiment” type to implement user-defined controller management messages. This paper extends the Experimenter Multipart message to obtain real-time resource status information of the general satellite model in real time and the code is shown below.

figure a

4 Conclusion

This paper systematically analyzes the applicability of the OpenFlow in heterogeneous satellite networks, and concludes that the existing OpenFlow has obvious defects in terms of protocol overhead, applicable scenarios, and protocol functions. Aiming at the significant problem of protocol inefficiency caused by directly adding satellite resource information to the protocol header field, this paper proposes a layered framework for SBIs design, in which we build an intermediate layer on top of the existing OpenFlow. The intermediate layer realizes the information exchange of coarse-grained general satellite model and the fine-grained one. it reduces the complexity of the OpenFlow for the function extension, and the on-demand working mode of the intermediate layer significantly improves the protocol efficiency. Besides, the layered architecture makes it unnecessary to change the internal implementation of the OpenFlow when a heterogeneous satellite network is accessed. Finally, based on the proposed design ideas, this paper gives a paradigm of the OpenFlow extension, which serves as a exploratory work for achieving unified resource management in software-defined satellite networks.