Keywords

1 Introduction

With the wide application of space technology and the diversification of spacecraft functions, space communication has evolved from spacecraft-ground to inter-satellite links. The information exchange relationship within and between the spacecraft is increasingly complicated. The unified information network service requires the multi-spacecraft, multi-application process in spacecraft, and multi-user task coordination. It requires integrated network communication among devices to provide reliable operation and management for the integrated network [1]. For this reason, CCSDS has extracted the concepts of sub-package telemetry (TM), sub-package remote control (TC) and advanced on-orbit system package (AOS). The latest research results in this area is standard space packet protocol (SPP), it solved the limitation that packet utilization standard (PUS). The PUS service is too closely related to TM and TC, only focused on satellite-earth link interaction [2]. The SPP can enable space missions to efficiently transmit space application data with different types of characteristics in a network including satellite-ground and inter-satellite links, and can realize interconnection and intercommunication between spacecraft and spacecraft under CCSDS standards.

This paper studies the application of space packet protocol, explores and proposes data exchange strategies among satellite, earth, inter-satellite and intra-satellite information nodes, which is helpful to promote the unification of protocol and information sharing, promote the integration of resources in various fields, and improve the space application capability and efficiency.

2 The Concept of Space Packet Protocol

2.1 Architecture

In the traditional spacecraft on-board data network, space packet protocol is located at the network layer. The subnet protocol only includes the on-board subnet protocol, which uses packet service, memory access service, equipment discovery service, etc. to realize SOIS data service, uses the convergence sublayer to realize the mapping between data link and data service, and uses 1553B, space wire and other on-board subnet protocols to realize the data link layer and physical layer. With the joining of intra-satellite links, the subnet protocol is extended to UDP/IP and other internet protocols. As the carrier of asynchronous message transmission and other services in the application support layer, the space packet protocol can realize the subscription and distribution of messages in the space internet and on-board equipment networks.

The interaction process of space packets in the network is shown in Fig. 1. The path from the source to one or more destination through the subnet is called the logical data path (LDP) [8]. The path id, including the source, the terminal and one or more subnets, authenticates each LDP uniquely. When the application data passes through the LDP subnet, the protocol provided by the subnet layer is used. The accessor carries the subnet when the path is inside the spacecraft and accesses the space subnet when the path passes through the space internet. The protocols used in the on-board subnetwork and the space subnetwork are independent of each other, and the logical data paths between the subnetworks can be configured and implemented through the management system to map the relationships between the protocols.

Fig. 1.
figure 1

Space packet interaction process

Full size image

2.2 Protocol Characteristics

The protocol data unit used by the space packet protocol is a space packet. Except that the packet header is mandatory, including the packet version number, the packet identification domain, the packet sequence control domain, and the packet data length. The user application process rather than the lower subnet transmission mechanism completely determines the contents of the space packet secondary header and the data domain. However, if different users define different package contents, when sharing information among users, they must learn the package formats of other users and provide interactive support operation methods.

2.3 Addressing Mechanism

The space packet main header only contains the application process identifier (APID) as the path identifier, and only the 16 - bit APID can be used as the address identifier for data routing within the spacecraft. However, when transmitting in the space subnet, the limitation of the value range of the APID will be highlighted. Therefore, the space package protocol establishes an APID naming domain for each spacecraft. Every APID is unique only in one spacecraft and can be defined repeatedly among the different spacecraft. The lower subnet protocol determines the value of the APID naming domain. If the IP protocol is used as the protocol of the space subnet, the IP address can be used as the APID naming domain. If the AOS link protocol is used, the main channel identifier consisting of the transmission frame version number and the spacecraft identifier can be used as the APID naming domain.

APID is used as the addressing mark of the LAN in the satellite, while the APID naming domain expands the address range of the user application process in the integrated network. Because space packets are transmitted in one direction, APID can subscribe, publish, and identify application messages between on-board devices, between different spacecraft, and between the ground and spacecraft. However, the subnet protocol is not necessarily unidirectional, so when the user application process initiates the message transmission between subnets, the destination address must be mapped according to the configuration information.

3 Space Packet Protocol Application Method

Due to the development process, PCM remote control system and CCSDS standard remote control space link protocol [9] are mainly used in the uplink of spacecraft space-to-ground links, AOS [10] is mainly used in the spacecraf-ground to inter-satellite links, and the adjacent space link protocol is being preliminarily applied. The internal communication bus of the spacecraft also presents diversified development trends, including 1553B bus and CAN bus at low speed, 1394 bus, SpaceWire bus and Ethernet bus at high speed. When different spacecrafts interoperate or share information, space packet protocol, as a protocol data unit with the smallest granularity, has the advantages of good compatibility with various protocols, small resource overhead and flexible customization, and can assume the responsibility of generalization of interfaces between spacecraft in various fields. The following analyzes and illustrates the application methods of space packet protocol from the perspective of compatibility between different layers of space packet protocol and network architecture.

3.1 Interaction with Onboard Subnets

The on-board subnet provides a set of entities defined by SOIS for supporting the network layer’s space packet protocol and the application support layer, including the data service sublayer, the convergence sublayer, the data link layer and the physical layer. The packet service of the data service sub-layer can provide the transmission function of the space packet through the aggregation sub-layer. The aggregation sub-layer completes the analysis and conversion of user process identification APID to the specific address of the data link in the space packet, and carries out the communication between the sub-network nodes through the data link layer and the physical layer.

When designing the information-flow of spacecraft, the scope of APID should be divided according to the structural characteristics of spacecraft in different fields. When the spacecraft routes space packets, it can map to different terminal addresses according to the value of APID, thus realizing the correspondence between APID and application process in the terminal.

The main head of a space packet is used to distinguish between a space packet and a remote control packet based on a packet type. However, with the development of intelligent spacecraft, the space packet type in satellite is no longer limited to remote sensing and control, and various types of payload data or user data appeared. The logical path direction, data domain format, and the processing method of different packet types are quite different. Therefore, it is necessary to add a packet type extension field to represent different data types together with the packet type field in the main header. There are two implementations for the packet type extension field, one is to occupy the high position of the APID, and the other is to define it in the secondary header. It is more reasonable to define the packet type extension domain in the secondary header. In order to comply with the agreement of the advanced on-orbit data system, the packet type is expanded as 4 bits high and the packet type as 1 bit low, forming a packet type field of 5 bits. The reserved value of ‘00000’ represents the TM packet, while ‘00001’ represents the TC packet, providing (25–1) extended identifiers for other data types in the spacecraft for identifying remote sensing image data, autonomous navigation data, asynchronous message management data, etc. The definition of the main header of the transmitted space packet in the on-board subnet is shown in the following Fig. 2.

Fig. 2.
figure 2

Packet header format

Full size image

3.2 Interaction with Space Subnets

The space packet protocol uses APID to perform simple network topology routing in the satellite. In the space internet scene, the space packet protocol uses the naming domain in the space subnet protocol to address complex networks. No matter using IPoC or DTN technology, when the source system of spacecraft A initiates message transmission to the terminal system of spacecraft B, it is necessary to specify not only the application process identification and data type of the terminal system, but also the address of the terminal system in the network. For the source system, the address may be generated by the registration and subscription managers in the asynchronous messaging service, or it may be due to customized heartbeat data or collaboration data conventions between spacecraft constellations.

However, when spacecraft nodes of various TC and TM systems are interconnected with ground nodes, the mapping between named domains becomes extremely difficult. The PCM TC system, TM link protocol and AOS TM protocol adopted in low-speed satellite-ground link do not contain destination address identification. Increasing IP and other network layer protocol fields under the limited satellite-ground link channel rate will result in increased encapsulation overhead. In order to connect the low-speed link with the high-speed link, the method of storing a copy of the named domain in the secondary header of the space packet can be used. Each space packet stores the network destination address in the secondary header. When the link without the network layer and the link with the network layer carry out packet relay, the named domain in the secondary header is used for routing and mapping. When the link with the network layer carries out packet relay, the named domain of the network layer is directly used for routing.

For the selection of the named domain, in order to realize forward compatibility, the communication link of the traditional measurement and control system uses SCID as the named domain, and the high-speed communication link uses IP address as the named domain. When relaying between the low-speed link and the high-speed link, the control center constructs and manages the mapping relationship between SCID and IP address. However, in the era of space internet, the 8-bit spacecraft identification SCID is far from meeting the needs of network addressing. On the premise of not changing the SCID field definition, the 4-bit spacecraft type extension field can be added to the secondary pilot to solve the dilemma.

It should be pointed out that when the spacecraft uses the time-triggered Ethernet bus, each device of the spacecraft will have an independent IP address, and each device will form a sub-network on the device, while each device will form a space sub-network, and each device will become a network node in the space internet. The data domain of the space packet encapsulated in the IP packet carries out message transmission inside and between the spacecrafts. If the space packet is transmitted inside the spacecraft, the source address and the destination address in the packet sub-header are filled into the satellite, and the mapping between the APID and the IP address realizes the intra-satellite routing.

The secondary leader after adding the network layer addressing copy is shown in Fig. 3. The contents of the packet sub-header are specified by the source end user of each path id and notified to the end user through asynchronous message service.

Fig. 3.
figure 3

Package sub-header format

Full size image

3.3 Interaction with the Application Support Layer

In the application support layer, space packets can be used as service carriers regardless of command and data acquisition service, time access service, file and packet storage service, message transmission service, and device enumeration service.

Command and data acquisition service uses TC space package and TM space package to register the analog quantity, temperature quantity and subset of command transmission of the equipment with APID. The application program only needs to access the data domain of the space package in device data pool service according to the configuration information, and does not need to care about the physical location information of the device. The on-board network layer automatically initiates the routing of space packets in the on-board subnetwork and the space subnetwork, and converts the on-board subnetwork into communication with the destination terminal. The file and package storage service enables users to access storage areas across devices or spacecraft according to LDP paths. When the spacecraft adds equipment, the equipment enumeration service allocates the global virtual equipment identification to provide mapping between the virtual equipment identification and the APID. When the equipment is revoked, the relevant application process identification in the equipment is deleted at the same time.

The asynchronous message service (AMS) provides a complete set of registration and management mechanism for the transmission of various types of space packets in space- ground integrated network. When an application process node wants to join the network, it first obtains the registrar’s address in the spacecraft from the configuration server and registers the APID and the APID named domain with the registrar. The registrar updates its member information and informs the configuration server, registrars of other spacecraft in the inter-satellite network, and other application process nodes of the spacecraft of the access address of the application process. Other application process nodes notify their own access information to the new node. At this point, the new application process can learn the addresses of any devices in the on-board subnet and the inter-satellite subnet, thus completing the invitation, transmission, group sending, subscription and publishing operations based on APID and its named domain addressing.

4 Verification

The global navigation system is composed of dozens of satellites, which often have inter-satellite communication links, and can measure and control all satellites through limited ground stations. For remote sensing satellites, a limited number of ground stations means a limited observation time, because remote sensing satellites generally do not need to form constellations. The spacecraft network protocol based on space package proposed in this paper can enable remote sensing satellites, navigation satellites and ground stations to support each other at the network layer of the spacecraft network, thus enabling all kinds of satellites to cooperate with each other and give play to their respective advantages (Fig. 4).

Fig. 4.
figure 4

Space packet protocol application

Full size image

When the ground user initiates the TC operation of the spacecraft, any satellite node can be selected to inject the TC space package according to the visibility. The earth-visible satellite node extracts the space packet APID naming domain, selects the link network to route to the destination node according to the space internet network layer protocol, the destination node identifies the space packet APID, searches for corresponding equipment through an addressing mechanism, transmits the equipment-borne subnet to the terminal system, and executes the instruction unit in the space packet by the application process in the terminal system.

When the remote sensing satellite and navigation satellite work together, the spacecraft and gateway learn the APID naming domain of service providers and service requestors through asynchronous message transmission services to form address routing tables in configuration servers, registrants, and nodes. At the same time, service demanders need to bind the auxiliary guide of the space package and the analysis rules of the data domain generated by the service provider’s application process.

5 Summary and Suggestions

The network protocol based on space packet proposed in this paper will inevitably become the basis of interactive support in future space-based networks due to its small field overhead, strong scalability, good compatibility with link protocols at various stages, and taking into account the characteristics of low-speed and high-speed link performance. Due to the flexible application of the space packet protocol, there are differences in the current use methods in various models. This paper starts with the application methods of the space packet protocol, makes clear the characteristics and the addressing mechanism of the space packet protocol, and studies the interaction methods between the space packet protocol and the carrier subnet, the space subnet and the application support layer. It is suggested that in future spacecraft design in various fields, the space packet protocol should be adopted to construct the integration network interoperability model of space and ground to achieve the goal of resource integration and interactive support among different types of spacecraft.