## 3 Stratospheric Balloon Campaign Overview  
As part of the verification plan of the FeDeCop, a stratospheric balloon campaign was conducted. This campaign was designed to evaluate the performance of the proposed protocols and their flexibility to deploy federations with different services. In particular, the main types of federations that have been deployed were (1) to download data from a balloon to another (i.e., download service), and (2) to balance stored data between balloons (i.e., storage service). Three stratospheric balloons and a ground station were used to test these characteristics of the proposed design. From now on, the balloons are identified as Balloon A, Balloon B, and Balloon C. Each of these balloons was equipped with a model of the FSSExp payload [19; 20], properly integrated for the stratospheric conditions. Figure 5 presents the payload and the subsystems that conform it: (1) the Radio Frequency Inter-Satellite Link (RF-ISL) board, (2) the On-Board Computer (OBC), and (3) the Long Range (LoRa) payload (related to another experiment). The RF-ISL board is a device that is used to establish the needed communications links between the stratospheric balloons, and the downlink contact with the ground station. It provides a half-duplex interface working at 437.35 MHz and 58 kHz of bandwidth. A Gaussian Minimum-Shift keying (GMSK) modulated signal is transmitted with 31.2 dBm of power, and it transports packets coded with Reed-Solomon. Its reception gain is 12.5 dB, and it has a 230 K of system temperature. The transmission rate is 9.6 kbps. Apart from the FSSExp, the balloons were equipped with additional subsystems, such as a battery, a Global Positioning System (GPS) receiver, among others. The configuration between the different nodes changed depending on each federation type that was deployed. In the case of the download service, the ground station established downlink contacts with a balloon which were used to download data from other balloons. This sharing of the downlink capacity enabled the retrieval of data from other balloons that were not directly reachable from the ground station. The sequence of actions conducted in this type of federations is represented in Figure 6 and detailed as follows. First, (1) the ground station connects to one of the stratospheric balloons (i.e., Balloon A). After the connection handshake, Balloon A starts to download data until it transfers all the generated packets. At this moment, (2) Balloon A publishes the availability of the downlink contact using the OSADP protocol. This publication is received by another balloon (i.e., Balloon B), which decides to establish a federation. For this reason, (3) Balloon B transmits a request of the service, triggering the negotiation phase of the federation. Once this phase is accepted by Balloon A, the roles of both balloons are defined: being Balloon A as the service provider, and Balloon B as the customer. At this moment, (4) the balloons start the federated phase in which the customer sends its data to the service provider to be downloaded. After the  
Figure 5: FSSExp payload with its subsystems once integrated. correct download, the service provider notifies the customer of the correct data transfer. This federation remains active until the contact with the ground station ends (i.e., service ending) or until the customer does not need the service anymore. At this moment, the closure phase finishes the connection, and each balloon goes back to its nominal operations (i.e., generating data). As a result, Balloon B has additional downlink opportunities to transmit data to the ground. On the other type of federation, the balloons were able to balance the storage level by exchanging data over a federation. Unlike the previous case, no ground station was triggering the publication of the service. Instead, the balloon itself decided to publish the storage service if it detected that the storage level is below a certain threshold.