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.