Federated Satellite System Experiment
This page currently provides an overview of the Federated Satellite Systems, it is under development the software to integrate the protocols to create, manage and close the federations.
Introduction
The concept of FSS was introduced by Professor A. Golkar in [1]. FSS are spacecraft that engage in opportunistic collaboration throughout their mission lifecycle, allowing them to share resources, capabilities, and data in a manner that enhances their overall operational efficiency and mission success. The concept, enhances the collaboration between satellites designed for different purposes, with the aim of enhancing mission capabilities. However, this new paradigm not only seeks to promote cooperation between satellites to improve mission capacities but also proposes a novel business model based on the opportunistic consumption of resources by different satellites. Nevertheless, the scope of this thesis relays on the technical aspects of the FSS.
It is essential to understand the various steps required to create a federation. The three main processes are Negotiation, Consumption, and Closure. Additionally, in, three types of FSS are defined according to the satellite architecture and the functions they perform within the aforementioned processes: (1) centralized FSS, consist of satellites acting as nodes exclusively dedicated to the negotiation and distribution of resources, as well as the process of terminating the federation. (2) negotiated FSS, consist of satellites acting as intermediary Unlike the former, these nodes only manage the negotiation process. And (3) distributed FSS: This architecture does not require nodes dedicated to any specific process. This means that the satellites themselves, which have the capability to federate, are responsible for managing all three processes. This thesis focus on the last architecture. Figure 1 illustrates the three architectures.
Given the processes described above and the various architectures, the need to define the necessary protocols to ensure their correct development arises. The Distributed FSS architecture require that all the nodes shall be able to manage the three processes (Negotiation, Consumption, and Termination). Two protocols are defined in [2] and [3]: OSADP and FeDeCoP. OSADP aims to efficiently manage the dissemination and handling of publications of available resources. On the other hand, FeDeCoP is designed to be in charge of managing the negotiation phase once a publication is received, manage the consumption o the resources published, and close the federation.
To validate the feasibility of the FSS, first simulation tools were developed. An implementation of the protocols was developed for the DSS-SIM simulator [2]. After obtaining satisfactory results on simulated scenarios, the Federated Satellite Systems Experiment (FSSExp) was conducted. This experiment consisted of creating a federation using stratospheric balloons equipped with payloads that integrated the OSADP and FeDeCoP protocols [3].
After the successful results from the FSSExp [3], the technology demonstration in orbit was carried out with the FSSCat mission. This mission was a precursor to a constellation of federated small satellites for Earth observation. The mission was equipped with a multi-spectral optical payload and a dual microwave payload, which included a GNSS-Reflectometer and an L-band radiometer with interference detection and mitigation capabilities. These satellites were capable to measure soil moisture, ice extent, and ice thickness, as well as detecting melting ponds on ice. Furthermore, they were equipped with radio/optical inter-satellite links to test key technologies and techniques for future satellite federations [4], [5].
Now that the context has been introduced, it is time to present the experiment of this mission. Reproduce the FSSExperiment as shown in Figure 2, consist of create a federation between two PocketQube platforms in order to download data. This data will be either telemetry or the one generated by the PL.
References
[1] Alessandro Golkar and Ignasi Lluch i Cruz. The federated satellite systems paradigm: Concept and business case evaluation. Acta Astronautica, 111:230–248, 2015.
[2] Joan A Ruiz-De-Azua, Anna Calveras, and Adriano Camps. A novel dissemination protocol to deploy opportunistic services in federated satellite systems. IEEE Access, 8:142348–142365, 2020.
[3] Joan A. Ruiz-de Azua, Nicola Garzaniti, Alessandro Golkar, Anna Calveras, and Adriano Camps. Towards federated satellite systems and internet of satellites: The federation deployment control protocol. Remote Sensing, 13(5), 2021.
[4] European Space Agency. FSSCat mission, 2023. Available: https://earth.esa.int/eogateway/missions/fsscat.
[5] A. Camps, A. Golkar, A. Gutierrez, J.A. Ruiz de Azua, J.F. Munoz-Martin, L. Fernandez, C. Diez, A. Aguilella, S. Briatore, R. Akhtyamov, and N. Garzaniti. FSSCat, the 2017 Copernicus Masters’ “ESA Sentinel Small Satellite Challenge” winner: A federated polar and soil moisture tandem mission based on 6U CubeSats. In IGARSS 2018 – 2018 IEEE International Geoscience and Remote Sensing Symposium, pages 8285–8287, 2018.
Protocols
This Chapter contains the Description of the two protocols needed to implement the FSS
Opporunistic Service Availability Dissemination Protocol
State of the Art
The Opporunistic Service Availability Dissemination Protocol (OSADP) generates resource publications and transmits it periodically whenever the resource is available. These packets are broadcast using User Datagram Protocol (UDP), as it is non-connection oriented protocol. The protocol itself dictates the steps that should be taken by the nodes that receive these publications.
The efficient dissemination of resource availability is a core aspect of OSADP. It is achieved through a decentralized publish-subscribe mechanism. The protocol is designed to notify as many satellites as possible about available services without saturating the network with redundant messages. Inspired by propagation methods from protocols like BATMAN and BMX6, OSADP [1] employs a node-by-node propagation technique. Each satellite processes the publication packet upon receipt, deciding whether to consume the resource or to forward the publication to its neighbors.
OSADP’s publication process is controlled by parameters like the Hop Limit (HL), which restricts the number of hops a publication can make within the network. Additionally, the publication packet contains information, including the type of service, provider identifier, and the estimated service lifetime, allowing satellites to make informed decisions regarding resource consumption and federation participation. This information allows the protocol to incorporate mechanisms to manage the propagation of publications. It prevents unnecessary duplication and ensures that only relevant publications are forwarded.
In conclusion, the protocol aims to manage publications efficiently and can be considered complete either when the publication is discarded or when the receiving node communicates back to the originating node its intention to form a federation. At this juncture, the negotiation phase for resource consumption begins, transitioning the communication to the Transmission Control Protocol (TCP) as per the processes outlined in the FeDeCoP protocol.
The management of the publications is detailed in [1]. However, the state diagram that must be implemented on the satellite is presented in Figure 1. The state diagram illustrates the flow of the protocol as it manages service publications. Starting in the Idle state, the system either updates its service table or checks received publications. If a new service is available or a publication contains new information, the system updates the table and may publish the information. If a service is extinguished or blocked, the system returns to the Idle state, ready for the next event. This process ensures efficient management and dissemination of service availability.
Packet Structure
In [13] the structure of the packet used in the publication process is shown. This packet shall be transmitted using non-oriented connection protocols such as UDP. Figure B.1 from [1] shows the packet fields. In addition, Figure 2 presents the packet fields and their description. From this Figure, we can retrieve the size of the packet, which is (12 bytes).
Information from OSADP packets is used to determine the next steps to be taken by the receiving node. To do so, the protocol works with the Service Table (ST). Each node generates a ST. Figure 3 shows the structure of the service table. The ST is a table that stores information about the services available in the network. It is updated whenever a publication is received. It is organized by providers. Each provider contains different services. Each service has associated different service entry tables.
References
[1] Joan A Ruiz-De-Azua, Anna Calveras, and Adriano Camps. A novel dissemination protocol to deploy opportunistic services in federated satellite systems. IEEE Access, 8:142348–142365, 2020.
Federated Deployment Control Protocol
State of the Art
The Federation Deployment Control Protocol (FeDeCoP) aims to manage the formation, maintenance, and dissolution of federations. As satellite networks become more complex and resource management grows increasingly critical, FeDeCoP provides a structured approach to leverage unused satellite resources through collaboration between satellites.
FeDeCoP is a protocol that addresses the technological gap left by the OSADP. While OSADP handles the publication of available services across satellite networks, it does not manage the subsequent steps required to establish a federation. FeDeCoP define a set of directives that rule the establishment of federations, ensuring a reliable and consistent process.
The protocol operates as a connection-oriented protocol, built upon TCP. It is essential for maintaining the high reliability required for the transactions involved in satellite resource management. The protocol’s operation can be divided into three distinct phases: (1) Negotiation, (2) Consumption, and (3) Closure. Figure 1 illustrates the state diagram of the protocol, with its phases and transactions.
Negotiation Phase: The negotiation phase is initiated when a satellite requests a service that has been previously published by another satellite in the network. Upon receiving a publication, the interested satellite (customer) sends a request to the service-providing satellite (provider). This request includes critical information such as the type and quantity of the resource required, which is then evaluated by the provider. If the provider can meet the requested conditions, it responds with an acceptance packet, finalizing the negotiation. This phase when the terms of the federation are established. The exchange of packets during this process follows a three-way handshake, ensuring the reliability of the connection. The packets exchanged are the request and acceptance.
Consumption Phase: Once the negotiation is successfully completed, the protocol transitions to the consumption phase. This phase governs the current use of the resources agreed upon during the negotiation. The behaviour of this phase is the following: The costumer send a data packet to the provider. Once the provider manages correctly the packet (depending on the service), it replies to the costumer with an acknowledgement packet. In other words, the transmission mechanism follows a stop-and-wait Automatic Repeat Request (ARQ) procedure. Despite not optimizing the communications, it ensures the reliability of the data transmission.
Closure Phase: The closure phase marks the end of the federation, triggered when the resources are fully consumed or are no longer available. This phase involves a three-way handshake similar to the one used during the negotiation phase, ensuring that all parties involved in the federation acknowledge the termination. To do so, they exchange close and acknowledgement packets. The closure process is critical for releasing resources and resetting the system to its initial state, ready for future federation opportunities. Overall, the FeDeCoP protocol plays a crucial role in enhancing the efficiency and effectiveness of satellite networks by enabling dynamic federations. Through its structured phases—Negotiation, Consumption, and Closure—it ensures that resources are allocated, utilized, and released in a controlled and reliable manner.
References
[1] Joan A. Ruiz-de Azua, Nicola Garzaniti, Alessandro Golkar, Anna Calveras, and Adriano Camps. Towards federated satellite systems and internet of satellites: The federation deployment control protocol. Remote Sensing, 13(5), 2021.