Keywords

1 Introduction

The use of new satellite technologies will be instrumental in order to bring connectivity to remote areas currently considered out-of-service, where it is challenging to provide communication coverage due to the lack of infrastructures [4]. Such areas include the Arctic region, where several types of sensor networks are required for better understanding of the Arctic ecosystem and its role in climate change. Moreover, with the evolution of the Internet of Things (IoT) and its global use for instrumenting the world, novel Information and Communication Technologies (ICTs) need to be considered.

In this paper, we evaluate an innovative use of ICTs, integrating IoT methods and protocols with polar-orbiting satellites, for providing communication coverage in the Arctic region. We show how a three-node swarm of freely drifting small satellites (i.e. the position of satellites, relatively to each other, changes with time) can be used to relay data from a sensor node deployed in remote locations. Standardised protocols such as the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) and the Constrained Application Protocol (CoAP) [8] are used.

The main contribution of this work is the performance analysis of such swarm as part of an IoT network, using real implementations of IoT protocols in an emulated environment. Different network architectures are compared by varying the number of ground stations and their positions. We show that by defining an IP-compliant satellite architecture with two ground stations, we are capable of reducing the average end-to-end time of a request from 88 to 38 min.

An overview of satellite communications in the Arctic as well as of networking technologies for heterogeneous systems is presented in Sect. 1.1. This is complemented by the proposal of a networking solution that integrates a swarm of small satellites and currently existing IoT protocols in Sect. 2.

The evaluation methodology used to assess the performance of the proposed concept is included in Sect. 3, followed by the analysis and discussion of the obtained results in Sect. 4. Finally, concluding thoughts are presented in Sect. 5.

1.1 Satellite-Based Networking in Remote Locations

Satellite communication services are scarcely available in high-latitude regions, such as the Arctic. In fact, broadband services from satellites in geostationary orbit (GEO) are of limited practical use above 75° North and non-existing above 81° North. As for narrowband services, the most used public available option that supports two-way communication is Iridium [14]. Different initiatives have been proposed to fill this gap. Examples are the Norwegian Highly Elliptical Orbit (HEO) broadband project [18], or the narrowband VHF Data Exchange System (VDES) [15]. The latter is primarily intended for maritime ship communications and e-navigation aids.

Tailor-made LEO small-satellite communication systems can be considered as a solution to solve the coverage gap in remote locations. These small-satellite communication systems do not aim to cover a broad set of end users, but can be used to support a selected, time-limited, mission.

The Arctic and Antarctic regions might also benefit from general Internet coverage, as proposed by some mega-constellation solutions [13, 19]. However, this approach, in addition to requiring a broadband HEO system, also requires the deployment of small and local base stations for ground communications. Additionally, direct sensor node-to-satellite communication might not be possible, but these systems might offer a service to a group of larger sensor nodes. However, deploying such base stations in remote locations still remains a challenge, compromising the feasibility of this solution, and details about coverage or the technical properties of the required ground terminals are still unknown.

1.2 Small-Satellite Swarms

The concept of freely drifting swarms is discussed in [6], where also the configuration giving the shortest coverage gaps is identified. Deployment strategies are discussed in [5, 21, 29]. By carefully selecting the relative velocity differences between members in the swarm, the satellites will enter orbits with slightly different orbital periods, differing for example between 2.4 and 19 s, which corresponds to a velocity difference of 1 and 8 m/s, respectively. It is assumed that a velocity difference of ±4 m/s between launched satellites is feasible with deployers currently in use. By selecting differences between +4 and +8 m/s, a highly dynamic swarm with good coverage properties can be created [6].

The positions of satellites in freely drifting swarms cannot be controlled. However, with careful planning, this solution can outperform more costly and complicated constellation deployments [6]. For example, a fixed constellation where satellites maintain a constant distance between each other will require complex and costly attitude and orbital determination and control systems, including thrusters, in order to perform station keeping.

In addition to the cost-savings on hardware and launching all the satellites of a swarm in one mission, it has been shown that a swarm of three small satellites with different speeds can improve coverage up to 80% of the time, when compared against a constellation of two small satellites uniformly positioned in one orbit [6].

The number of satellites in the following emulations is selected in order to more easily show how the scenarios compare with each other.

2 Proposed Concept

2.1 Small-Satellite Sensor Networks

Nowadays, computer networks rely on heterogeneous technologies, including satellite communications, to guarantee a multitude of services in different types of devices and conditions. For this reason, Internet infrastructures are based on standardised protocols that ensure interoperability and interconnect multiple communication technologies. Similarly, satellite communications and their link to the IoT and sensor networks depend on standardised protocols in order to be widely adopted [7].

Despite the potential of using satellite links for reaching remote and isolated clusters of nodes, mobility, together with the spareness of nodes, compromise the establishment of an end-to-end path between source and destination nodes. This intermittent connectivity limits the utilization of standard Internet protocols such as TCP or UDP, requiring different approaches such as point-to-point store-and-forward semantics. Such approaches have been proposed in the past, known as Delay or Disruptive Tolerant Networks (DTNs), which are built on top of protocols such as Bundle [25] and Licklider [9].

Satellites can cover larger areas, but usually only provide a modest data rate. However, this suffices for many sensor networks that, despite gathering simple data (e.g. temperature, wind speed, status messages), are important for supporting remote locations.

In addition to application-specific data, considered networking approaches must also take into account signalling data (e.g. routing and management). Such signalling data should have a small overhead, particularly in resource-constrained conditions such as the ones envisaged in small-satellite swarms or in sensor networks. Similar requirements have been defined by working groups from the Internet Engineering Task Force (IETF), such as the Routing Over Low power and Lossy networks (ROLL)Footnote 1 and the Constrained RESTful Environments (CORE).Footnote 2

The growing importance of IPv6 has also been considered for satellite networks [24], allowing the support of a large number of mature and standardised features that build on IP (e.g. security and reliability). Even though this approach seems to introduce too much overhead for constrained settings, existing initiatives such as the IPv6 over Networks of Resource-constrained Nodes (6lo) working group,Footnote 3 handle this problem. In fact, it has been shown that 6lo achieves reduced overheads and that IPv6 can operate in narrowband communication links, common in sensor networks and small satellites.

Projects such as the Arctic ABC project [3], where various sensor nodes are to be deployed on the ice and drift there for years, are used as use cases or missions relevant for this work. In this context, the proposed small satellite deployment is meant to support communication infrastructure required by these sensor nodes. This includes transmitting housekeeping and environmental data back to the scientists on a regular basis.

2.2 Properties of Small-Satellites Swarm

Deploying a freely drifting swarm by initially giving the individual satellite different velocities at deployment provides the simplest and cheapest solution for deployment, allowing a single launch to release several nodes that can be given different relative velocities.

Such a swarm will be clustered immediately after its deployment, with the satellites virtually overlapping and resulting in, assuming a single shared frequency channel, a network with the same apparent capacity as if it only had one satellite. However, due to their different velocities, the satellites will drift relatively to each other while still in the same orbital plane. Figure 1 shows how the swarm can develop over time. Also, it must be noted that the satellites seem to be overlapping from the observer on ground. In orbit, the distance between them will be large. Since they have different velocities, they will also have different orbits and orbital heights.

Fig. 1
figure 1

Example of what a swarm of three satellites can look like at different times. Top: Just after deployment. Middle: Overlapping coverage. Bottom: Uniform separation

Full size image

After some weeks or months, depending on their orbital periods, the satellites will practically follow one another (trailing). Later on, at one moment in time, the swarm will look like a “perfect” uniformly distributed constellation (uniform). These configurations will not last long, as the satellites constantly continue to drift, and eventually they will again converge, overlapping, and the cycle repeats itself.

Since the proposed concept resorts to a freely drifting swarm in order to provide connectivity, it is important to investigate how swarm dynamics, in particular in the overlapping, trailing and uniform stages, influence network performance. Since the use of CubeSats or other small satellites is envisioned, the satellite payload should be quite simple, but still flexible to meet mission requirements. Additionally, sensor nodes in remote locations will most likely be constrained, and the amount of data that can be transmitted will be limited by power at the nodes. For these reasons, and in order to ease antenna pointing requirements, sensor nodes considered to the use of omnidirectional antennas. The depending on the capabilities of the chosen satellite bus, the satellite can be assumed to have antennas with some directivity. This also relates to the frequency band used. The VHF/UHF band is considered a likely option, as it is possible to close the link between a non-pointing sensor and a satellite. The 400 MHz UHF band is for example used by the ARGOS system. From this, a selection of the bit-rate follows. 20 kbps is used in the emulations. The bit-rate is chosen to a conservative value, in order to support low-power sensor nodes. Aligned with the described constraints, lightweight networking protocols are also considered, namely 6LoWPAN, which introduces several compression mechanisms for achieving reduced overhead [10, 27], while being IP compatible. Moreover, the CoAP protocol is used with its feature of proxying requests in order to reach sensor nodes through satellite nodes, while using UDP and providing an easy translation to HTTP-based requests.

2.3 Ground Stations

Despite the importance of satellites’ topology, the understanding of nodes’ positions on Earth is crucial. Sensor nodes can possibly be located in many different locations such as in the oceans or on the ice. However, the placement of ground stations is highly dependent on existing infrastructures, as they are the connection points to the Internet.

Figure 2 shows a map including five relevant locations for the placement of both nodes and ground stations. Two ground stations are considered, one placed in Vardø, in Northern Norway and another at Svalbard. The locations currently operate real ground stations for many missions, so the infrastructures are in place. Having ground stations this far north (Svalbard and Vardø) allows satellites with polar orbits to be able to simultaneously communicate with the ground station and sensor nodes, though not necessarily in all passes. In addition, a ground station at Svalbard will typically see all passes for a polar-orbiting satellite, whereas a ground station placed considerably further away from the pole will not. However, operating in Svalbard, a remote island with harsh climate, has additional costs when compared with a ground station on the mainland.

Fig. 2
figure 2

Map showing where all nodes and ground stations are placed. KSAT Svalbard and Vardø are used as typical ground station locations, and the rest are sensor nodes

Full size image

Vardø will experience long gaps in communication with the satellites. These gaps last several hours as the ground station is out of reach by all satellites in the orbit plane for several consecutive orbits. As one moves closer to the equator, these outage periods increase. Therefore, by using spatially distributed ground stations, for instance connected through the Internet, the total access time can be increased. For example, placing a ground station at the Troll station in Antarctica would increase the spatial distribution, but additional operational costs have to be accounted for.

2.4 Sensor Nodes

When considering the target area of Arctic exploration, many locations can be considered. This is decided by the mission purpose, as defined by the respective end user for the mission. In this paper, three locations were chosen, one at Rossøya, north of Spitsbergen, and two in the Fram Strait (GR_North) and (GR_South). The Fram Strait, between Greenland and Svalbard, is the region where drifting nodes, for example from the Arctic ABC project, are expected to end up [2, 3].

In order to assess the network performance with different coverage conditions, the sensor nodes are placed in locations where all satellite passes are visible (Rossøya and GR_North), as well as locations where not all passes are available (GR_South). Due to the East–West separation between GR_south and Vardø especially, their outage periods will not completely overlap. This means that in order to set up a link between these nodes, a total gap larger than the gap for any of the individual network nodes will occur. The situation will get worse when the East–West separation increases. This can be mitigated by adding ground stations either further north (to see all passes and reduce the ground station gap), or by placing a new ground station closer to the sensor node longitude (to increase the overlap of their outage periods).

3 Evaluation Methodology

In order to realistically evaluate the feasibility of using a freely drifting swarm of small satellite nodes as part of a sensor network, a hybrid test bed was established, combining both simulation and emulation. The used solution is capable of emulating not only several satellite nodes, but also sensor devices and ground stations, as well as the characteristics of available communication between them. Emulation is achieved by using operating system-level virtualisation, also known as containers, for allowing a complete execution of real software tools and network protocols. Specifically, Ubuntu 16.04 docker containers [17] were used, created with a modified version of the Imunes emulation tool [23] together with custom scripting tools for enabling an evolving network topology, where links are adapted throughout the emulation time, following the calculated contact periods between ground nodes, satellites and sensor nodes.

The performed evaluation included a combination of ground stations—Svalbard, Vardø and Svalbard with Vardø—used to reach the small satellite nodes and to issue data request towards three sensor nodes. When two ground stations were used, they were assumed to be connected to each other over the Internet, being able to relay requests/responses between them. The evaluation also focuses on understanding the performance differences between sensor nodes in distinct conditions. In particular, it focuses on a sensor node in Rossøya, which will observe all satellite passes, and another at GR_south, which does not.

The network performance was evaluated from the user’s perspective, meaning that the end-to-end response time is measured from the instant that a user makes a request until it receives a response. From this perspective, the satellite link availability for an arbitrary node is unknown, and therefore, requests were issued randomly (cf. 3.2). If needed, these requests were buffered at the ground station, following a delay-tolerant approach, until a satellite was within range.

3.1 Satellite Swarm Simulation

The topology of a swarm, and the position of its satellites, defines the state of the proposed networking concept, where link availability varies according to the chosen orbits and target areas. This topology and details about link availability were determined by using Python [11] and pyepem [22] library for astronomical computations, combined the basemap library [28] for creating maps and defining the nodes to be considered in link availability calculations. The contact times between satellites, ground stations and sensor nodes were calculated using these libraries together with realistic information about the nodes and regions of interest specified in Sect. 2. From this calculation, a time-step list was generated, including details about link properties (i.e. one-way delay and bit-rate) between all the considered nodes. For each time-step, we assume that the satellite link is capable of delivering loss-free communication, with a set bit-rate and within the specified delay as calculated as free-space propagation delay. Additionally, satellites will not have inter-satellite links for connectivity between themselves in any of the evaluated scenarios.

All performed calculations were based on the Two-Line Element (TLE) [16] set of AAUSat-3 [1], with epoch 13 Feb 2014 12:35:42.657.Footnote 4 The TLE was retrieved by using the Systems Toolkit (STK) [12], and for scenarios with more than one satellite, this TLE was modified in order to simulate satellites with different orbital periods. For each instance of the EarthSatellite object in pyephem , the orbits-per-day and eccentricity e parameters were changed accordingly.

Since the topology of a freely drifting swarm continuously changes over time, a continuous emulation of the network would also be required over a large period of time that can span from 40 to 180 days [6], in order to cover all possible configurations. However, available literature shows that three discrete configurations are representative of these swarms, which correspond to the periods when the satellite nodes are uniformly distributed, overlapping and trailing each other. We chose these three configurations, over a period of approximately one day, corresponding to 14 complete passes over all the selected nodes, for emulating the network performance under different conditions. The obtained results are presented in Sect. 4 and compared against a two-satellite constellation statically configured in a uniform distribution.

3.2 Networking and Communication Emulation

The evaluation of networking performance was achieved through emulation [20], by dynamically configuring the links between each node. Links between nodes have a dedicated Linux network namespace, isolating them from other traffic. Additionally, based on the input from the satellite swarm simulation, the bit-rate and delay of each link are configured by using Linux qdiscs. For this purpose, the tbf and netem qdiscs were used.

In order to mimic the constrained nature of satellite links, the used network interfaces were based on Linux nl802154 physical layer.Footnote 5 This allowed assessing the performance of IPv6 over narrowband links, using 6LoWPAN. For the same reason, the CoAP protocol was used for exchanging data between the sensor nodes and ground stations, through the satellites. CoAPthon was the chosen implementation [26], which was slightly modified to hold requests/responses whenever no link was available. The implemented behaviour is similar to that expected by a DTN protocol, but no routing protocol was used. Instead, routes were established taking into account the information about satellites and their orbits, reducing control overhead.

Data requests were randomly generated for emulating traffic being exchanged between ground stations and sensor nodes, using the small satellites and proxies. These requests followed a random uniform distribution between 60 and 180 s. The chosen destination for each request also followed a random uniform distribution, so that all sensor nodes were equally used. In addition, the payload size of each reply was constant, with a total of 512 bytes per response, which can correspond to several types of sensor network applications.

4 Results

Following the proposed evaluation methodology, the presented results for the drifting swarm include its three main configurations, overlapping, trailing and uniform. Additionally, a weighted average approximation of the overall network performance is included, where each of the configurations is given the same weight. This is a conservative approximation, as the swarm will be in a state between trailing and uniform distribution (i.e. shorter coverage gaps) for longer periods than it will be in the overlapping state. We therefore state that in practice, the three-satellite swarm network should perform better than this approximation.

In this section, the network performance of the proposed drifting swarm focuses on the average time taken from request to response \( (e\bar{2}e) \), as well as the highest value (e2e∗). Additionally, the \( A\bar{C}K \) and ACK∗ parameters, respectively, represent the average and the highest duration from a request being received in a ground station and acknowledged by a satellite. This interval is, in most cases, identical to the time-to-next-pass; however, in some special cases it is not. For example, requests being made on the very end of a pass may be received by a satellite, but the confirmation may be not transmitted before the link between the ground station and the satellite fails.

This can influence the minimum and maximum times, and it makes the average ACK worse than the time-to-next-pass; therefore, it should be interpreted as time-to-next-useful-pass. All ACK values are seen from the issuing ground station, independently of which node the request is for.

The minimum end-to-end results are not presented in this work as they are not representative of the overall performance being evaluated. This results from instants where sensor nodes and the ground stations are both in view of the satellite, resulting direct relaying and in a minimum e2e and ACK close to zero. For similar reasons, the maximum end-to-end results are also not presented, since they reflect only the maximum end-to-end of GR_South, which was purposely positioned so that coverage outages would occur.

The presented e2e and ACK arithmetic means are, respectively, within ±11 and ±8 min, with a 95% confidence interval.

4.1 Vardø Ground Station

The results obtained for Vardø, as the only available ground station, are shown in Table 1. In this table, the subscript Ross stands for the sensor node deployed at Rossøya, while GRS represents a node at GR_South. The column-labelled Overlapping corresponds to the measured network performance when the three drifting small satellites overlap each other. Similarly, columns Trailing and Uniform, respectively, represent the periods when a small satellite immediately succeeds another and when they are uniformly distributed between themselves. Finally, the Swarm column represents the overall performance of the proposed satellite network considering its different topologies, which can be compared against the constantly uniform distribution of two small satellites (column 2 Sats).

Table 1 Performance in hh:mm:ss for Vardø
Full size table

As expected, the network performance improves when the constellation spreads and the swarm of small satellites becomes uniformly distributed. Such improvement is shown by the arithmetic mean of the end-to-end time \( (e\bar{2}e) \) when requesting and receiving data from a remote sensor node. This becomes more noticeable when analysing average time for receiving a first acknowledgement from a satellite node \( (A\bar{C}K) \), which is representative of the time a request waits until it is served. However, due to the positioning of the ground station and ground nodes, with respect to the orbit of the satellite nodes, the worst-case scenario between passes is similar for the different stages of the swarm, as expected.

In addition to the existence of outage periods for the nodes too far south to see all passes, other factors have also influenced the measured performance of the proposed solution. Since the performed evaluation used real networking conditions and protocols, processing delays and concurrency between requests originated additional degradation for a few requests. In fact, the unexpected difference in maximum end-to-end time for GR_South, when comparing the Trailing configuration with the other two configurations, is explained by a request being received before the outage at Vardø occurs. The request can only be completed when this period has passed and the satellite is available again.

Finally, and following the motivation for the proposed approach, the obtained results demonstrate that a simpler deployment of three drifting small satellites outperforms a constellation of two uniformly distributed small satellites. In fact, for a heterogeneous positioning of sensor nodes, the proposed solution is, on average, better even in its worst stage, with overlapping satellites. For more limited coverage of remote locations, where satellite orbits are perfectly aligned with the sensor nodes and avoid non-overlapping outage periods, the proposed solution has a slightly higher end-to-end average than the static two-satellite constellation, 63 versus 58 min. However, this is negligible when considering all the advantages from the proposed swarm, which can make use of simpler hardware and allows for more easier and cost-efficient deployment and operation.

4.2 Svalbard Ground Station

The results for the topology using the Svalbard ground station are shown in Table 2, including the same previously described metrics. Similarly to Vardø, the registered performance improves as the swarm becomes uniformly distributed, which is in agreement with defined hypothesis. Additionally, the swarm’s overall performance, considering all its different states, is comparable to the results obtained by the two-satellite constellation, which also improved with the ground station placed at Svalbard. This overall improvement is mostly due to simultaneous coverage of sensor nodes and the ground station, which results in the relaying of requests and responses with minimal delay.

Table 2 Performance in hh:mm:ss for Svalbard
Full size table

When comparing Svalbard against Vardø, the former outperforms the latter in almost all conditions. This is verified for both the proposed solution and the two-satellite constellation, as it solely depends on the ground station’s positioning. However, when considering the sensor node located at GR_South, the observed improvement is not so pronounced, due to the East–West separation that also affected Vardø (c.f. Sect. 2).

4.3 Vardø and Svalbard Ground Stations

As previously discussed, well-placed ground stations may improve the performance of satellite networks, as verified with Svalbard, but it depends on existing infrastructures and may imply increased costs. The scenario with both Vardø and Svalbard ground stations aims at achieving a trade-off between existing options, taking advantage of the chosen IP-based networking protocols. For this scenario, Vardø and Svalbard were connected through a dedicated link, routing requests and responses through the shortest-existing path to a satellite node. In order to distribute load, the same amount of requests were generated in Vardø and Svalbard, meaning that this link was only used when one had no satellite coverage. The obtained results are presented in Table 3 following the same metrics used for the previous scenarios.

Table 3 Performance in hh:mm:ss for Vardø and Svalbard
Full size table

By combining the two ground stations, improvements are registered in all cases, when compared against only using Vardø. This is verified not only for the overall network performance, but also when considering sensor node GR_South. As expected, these results are very similar to the ones obtained by Svalbard alone, which shows that no degradation occurs from operating with two ground stations. However, it is important to highlight that the ground station Svalbard is only required whenever no coverage is available at Vardø.

Comparing the proposed drifting swarm with the two-satellite constellation, similar performances can be observed. The constellation follows a similar orbital plan and therefore equally benefits from using the ground stations. However, it is important to stress the importance of using a standardised networking solution, such as IP-based protocols, in order to take advantage of spatially distributed ground stations.

5 Conclusions

A swarm of freely drifting small satellites was used to provide connectivity in the Arctic region. The proposed solution considered realistic settings for sensor nodes deployed in remote locations and the use of real implementations of IoT protocols. A performance evaluation was conducted using a network emulator combined with real small satellite orbits.

The network performance of a freely drifting swarm of three satellites was comparable to a fixed constellation of two satellites. This was achieved without requiring complex station-keeping hardware and operational procedures that constellations do, making the swarm solution cheaper both to build and operate. The resulting approach saves resources and motivates the deployment of more satellites in orbit, increasing coverage and reducing service degradation.

It was shown that the latitude and longitude between sensor nodes and ground stations must be considered when planning a satellite-supported network. This will have a strong impact on end-to-end time to retrieve data as a node, while under satellite coverage, may not be reachable in all passes. However, in remote locations, the operational cost and placement of ground stations impose limitations, which motivate the use of mainland solutions instead. Bearing this in mind, and focusing in the Arctic region, we suggested using a hybrid approach with two ground stations, one in the mainland at Vardø and a second one at Svalbard.

Obtained results proved that at Svalbard’s privileged positioning for the Arctic region Vardø is outperformed. However, by simultaneously using both ground stations, resorting to Svalbard only for limited periods of time when Vardø is out of coverage, a performance similar to only using Svalbard is achieved. This approach was demonstrated by employing currently existing IoT protocols, namely 6LoWPAN and CoAP, which match the requirements of sensor networks of constrained nodes.

The obtained results further motivate the use of freely drifting small satellites, as well as employing standardised networking solutions for interconnecting nodes. This allows establishing a global sensor network of satellite-enabled devices with extended coverage.