![](https://csdnimg.cn/release/download_crawler_static/15166039/bg3.jpg)
IEEE Proof
158 network. Yang et al. [10] proposed an architecture (SDS-BI-
159 SIS) for space information systems that is based on software
160 defined radio technology to resolve the current drawbacks of
161 the construction of space information systems, and dis-
162 cussed its new features. They also discussed the payloads of
163 the software-defined satellites. [9], [4], and [10] only adopted
164 SDN in their frameworks. All of them adopted a hierarchical
165 architecture and satellite networking. However, they
166 focused on space networks without considering the space-
167 terrestrial integrated scenario. All of the three papers did not
168 deploy prototype and only [9] had experiments.
169 Feng et al. [11] proposed a networking scheme for Opera-
170 tionally Responsive Space (ORS). The scheme is a space-
171 ground integrative network and is deployed by OpenFlow
172 and network virtualization. It was provided an agility and
173 flexible solution for emergency response in a new way.
174 Kapovits et al. [12] presented a hierarchical reference ser-
175 vice delivery architecture and highlighted its potential role
176 in selected satellite terrestrial integration scenarios. [11] and
177 [12] adopted SDN in the design of the framework while
178 NFV was not considered. [11] and [12] took space-terrestrial
179 integrated scenario into consideration. However, [12] did
180 not adopt the hierarchical architecture. Satellites only per-
181 formed bent-pipe forwarding and satellite networking was
182 not considered. None of them have experiments or proto-
183 types to validate their architecture.
184 Bertaux et al. [5] investigated how SDN, network virtual-
185 ization, and NFV can enhance satellite architecture through
186 practical use cases, such as SDN-based site diversity. Their
187 work provides us appropriate testing scenarios. Ferrs et al.
188 [6] provided a detailed description of the benefits that
189 SDN/NFV technologies can bring into satellite communica-
190 tions towards 5G through the analysis of scenarios and
191 use cases. These articles adopted SDN and NFV in space-
192 terrestrial scenario but SDN and NFV are mainly applied in
193 the terrestrial segment. Bent-pipe satellites are deployed in
194 space, and the space segment only acts as a transmission
195 channel. In addition, the virtualized Network Service Func-
196 tions (NSFs) are only deployed in the satellite hubs or in the
197 dedicated terrestrial satellite-related processing network
198 that connects to satellite hub. There are still no experiments
199 or prototypes to support the proposed concept.
200 In this paper, we focus on the integrated space-terrestrial
201 scenario. We adopt a hierarchical networking method and
202 SDN performs control function not only in terrestrial net-
203 work, but also in space network. We deploy the virtualized
204 NSFs in both satellite-related components (satellite gate-
205 ways) and satellite-unrelated components (data centers) to
206 form an integrated NSF chain. In addition, we have imple-
207 mented a prototype and conducted experiments to validate
208 the proposed framework.
209 3 SERVICE FRAMEWORK
210 In this section, we give an overview of SERvICE. SERvICE is
211 based on SDN and NFV. The characteristic of centralized
212 control of SDN simplify processing tasks of satellites. By
213 separating the data plane and control plane of each satellite,
214 satellites only need to implement the simplest forwarding
215 function. We use OpenFlow as the southbound interface
216 protocol because it is widely used in the SDN-related
217controller and switch. We use NFV to create the satellite-
218related VM-based NSFs. The reason is that NFV is a topol-
219ogy-independent and flexible method to deploy NSFs. It is
220easier to configure the NSFs, such as adding/ deleting/
221opening/ closing/ migrating NSFs in a flexible way. We just
222need to manipulate the VMs according to the strategies. SER-
223vICE contains three planes: Management Plane, Control
224Plane and Forwarding Plane. The three planes are divided
225based on function, rather than location. This will help to
226merge the space-terrestrial network. Multiple benefits can be
227expected from the combination of the space network and ter-
228restrial network, such as increased network resilience and
229improved QoS for end users.
230The system structure and the interactions among the
231functions of SERvICE are illustrated in Fig. 1. The rounded
232rectangles represent the entities and the planes while the
233rectangles represent the functions. The detailed introduc-
234tions are as follows.
2353.1 Management Plane
236The Management Plane here acts as the orchestrator of the
237whole satellite communication network, including space
238networks part and terrestrial networks part. The manage-
239ment entity in Management Plane is the Satellite Network
240Management Center (SNMC). Since the processing capabil-
241ity on satellites is limited, we place SNMC in the backbone
242network. The function of the SNMC can be divided into two
243parts. One part is resource registration and inquiry, and the
244other part is to create strategies, such as routing, security,
245accounting, QoS, and resource management. SNMC makes
246strategies depending on the information collected by the
247GEO satellites and the controller in the terrestrial networks
248and user’s needs. These strategies are sent to the Control
249Plane to steer the traffic. Here, we will introduce the Man-
250agement Plane in three parts: the unified naming and
251description of entities in the whole satellite communication
252network, the registration and inquiry of the resources, and
253the management strategy making.
2543.1.1 Naming
255Unified and reasonable naming of resources can promote a
256better integration of the space networks and the terrestrial
257networks.
Fig. 1. The system structure and functions of SERvICE.
LI ET AL.: SERVICE: A SOFTWARE DEFINED FRAMEWORK FOR INTEGRATED SPACE-TERRESTRIAL SATELLITE COMMUNICATION 3