Content uploaded by Roger Birkeland
Author content
All content in this area was uploaded by Roger Birkeland on Nov 04, 2018
Content may be subject to copyright.
Freely-Drifting Small-Satellite Swarms for
Sensor Networks in the Arctic
Roger Birkeland1and David Palma2
1Department of Electronic Systems, Norwegian University of Science and Technology
(NTNU), Trondheim, Norway.
roger.birkeland@ntnu.no
https://orcid.org/0000-0002-0740-8442
2Department of Information Security and Communication Technology, Norwegian University
of Science and Technology (NTNU), Trondheim, Norway.
david.palma@ntnu.no
http://orcid.org/0000-0003-3931-0068
Abstract. Satellite communications have been widely used to provide connec-
tivity around the world. However, regions such as the Arctic still have limited
coverage, despite the need to monitor this region. Currently, several sensors are
deployed in the Arctic, but are limited by poor and costly connectivity. Constel-
lations of small-satellites, or CubeSats, have been proposed in order to overcome
this lack of connectivity, offering an alternative to typical satellite solutions. How-
ever, these constellations face challenges in their deployment and in orbital station
keeping. In this paper, we propose a simpler deployment of small-satellites, in the
form of a drifting swarm, integrated with networking protocols widely used in the
Internet of Things (IoT). A realistic setup is considered, evaluating this solution
taking into account the position of sensor nodes, ground stations and the dynam-
ics of such a drifting swarm. The topology evolution of the small-satellite swarm
is studied and all its link characteristics are emulated using a real network stack
and protocols. The obtained results prove the feasibility of the proposed solution
and show that a freely-drifting satellite swarm, with three small satellites, out-
performs more costly solutions. Our results also show that by using standardised
networking protocols, a satellite architecture with two ground-stations connected
over the internet, can reduce the average end-to-end time of a request from 88
to 38 minutes. The obtained results motivate the use of freely-drifting swarms of
small-satellites for reaching sensor nodes in remote locations, as well as the use
of IoT protocols for improved performance.
Keywords: IoT, Arctic, CubeSat, satellite swarms, network emulation, CoAP,
WSN, sensor networks
1 Introduction
The use of new satellite technologies will be instrumental in order to bring connec-
tivity 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 in-
clude the Arctic region, where several types of sensor networks are required for better
understanding 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 minutes.
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 communi-
cation 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
[29,21,5]. 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 seconds, which corresponds to a velocity difference of
1m/sand 8m/srespectively. It is assumed that a velocity difference of ±4m/sbetween
launched satellites is feasible with deployers currently in use. By selecting differences
of +4m/sand +8m/s, a highly dynamic swarm with good coverage properties can be
created [6].
The positions of satellites in freely-drifting swarms that cannot be controlled. How-
ever, with careful planning, this solution can outperform more costly and complicated
constellation deployments [6]. For example, a fixed constellation where satellites main-
tain 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 be shown that a swarm of three small-satellites with dif-
ferent 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 proto-
cols that ensure interoperability and interconnect multiple communication technolo-
gies. 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 clus-
ters of nodes, mobility, together with the spareness of nodes, compromise the estab-
lishment of an end-to-end path between source and destination nodes. This intermit-
tent connectivity limits the utilization of standard Internet protocols such as TCP or
UDP, requiring different approaches such as point-to-point store-and-forward seman-
tics. 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. How-
ever, this suffices for many sensor networks that, despite gathering simple data (e.g.
temperature, wind speed, status messages) are important for supporting remote loca-
tions.
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 require-
ments have been defined by working groups from the Internet Engineering Task Force
(IETF), such as the Routing Over Low power and Lossy networks (ROLL)3and the
Constrained RESTful Environments (CORE)4.
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 Net-
works of Resource-constrained Nodes (6lo) working group5, 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 a 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 initialy giving the indivudial 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. Fig. 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.
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
3https://tools.ietf.org/wg/roll
4https://datatracker.ietf.org/wg/core/
5https://datatracker.ietf.org/wg/6lo/
will look like a “perfect” uniformly distributed constellation (uniform). These config-
urations will not last long, as the satellites constantly continue to drift, and eventually
they will again converge, overlapping, and the cycle repeats itself.
Fig. 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.
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 omni-directional
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 bitrate 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, light-weight
networking protocols are also considered, namely 6LoWPAN, which introduces sev-
eral 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 simul-
taneously communicate with the ground station and sensor nodes, though not necessar-
ily 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.
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 pe-
riods 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 con-
sidered. 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 [3,2].
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 testbed 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 char-
acteristics of available communication between them. Emulation is achieved by using
Fig. 2. Map showing where all nodes and ground stations are placed. KSAT Svalbard and Vardø
are used as typical ground station locations, the rest are sensor nodes.
operating-system-level virtualisation, also known as containers, for allowing a com-
plete 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 emu-
lation tool [23] together with custom scripting tools for enabling an evolving network
topology, where links are adapted throughout the emulation time, following the calcu-
lated 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 is-
sue 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 re-
lay requests/responses between them. The evaluation also focuses on understanding the
performance differences between sensor nodes in distinct conditions. In particular, it fo-
cuses 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 pro-
posed networking concept, where link availability varies according to the chosen orbits
and target areas. This topology and details about link availability was 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.6576. 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 eparameters 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. How-
ever, 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 con-
stellation 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 bitrate and delay of each
link is 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 inter-
faces were based on Linux nl802154 physical layer7. This allowed assessing the per-
formance 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
6Since the TLEs strictly are not valid for more than a few weeks, the resulting orbits must be
interpreted as representative examples only.
7http://wpan.cakelab.org/
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 be-
tween ground stations and sensor nodes, using the small-satellites and proxies. These
requests followed a random uniform distribution between 60 and 180 seconds. The cho-
sen 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 con-
stant, 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 tree main configurations, overlapping,trailing and uniform. Addi-
tionally, a weighted average approximation of the overall network performance is in-
cluded, 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 ( ¯
e2e), as well as the highest value
(e2e∗). Additionally, the ¯
ACK and ACK∗parameters respectively represent the average
and the highest duration from a request being received in a ground station and acknowl-
edged 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 rep-
resentative 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 re-
laying 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
minutes, 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
GRSrepresents 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 com-
pared against the constantly uniform distribution of two small-satellites (column 2 Sats).
Table 1. Performance in hh:mm:ss for Vardø
Overlapping Trailing Uniform Swarm 2 Sats
Avg. end-to-end ( ¯
e2e) 01:42:38 01:29:02 01:15:35 01:28:48 01:44:05
Avg. time to ACK ( ¯
ACK)01:01:27 00:53:46 00:45:56 00:52:48 01:06:49
Max time to ACK (ACK∗) 06:40:44 06:19:37 06:15:04 06:24:36 06:45:33
Avg. e2e at Rossøya ( ¯
e2eRoss) 01:17:59 00:59:43 00:53:55 01:03:00 00:57:37
Max e2e at Rossøya (e2e∗
Ross) 06:22:54 06:07:20 06:05:12 06:11:24 06:28:47
Avg. e2e at GRS(¯
e2eGRS) 01:52:32 00:59:43 01:31:17 01:27:36 02:20:15
Max e2e at GRS(e2e∗
GRS) 09:51:25 06:07:20 09:29:19 08:28:48 10:02:20
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 ( ¯
e2e) when requesting and re-
ceiving data from a remote sensor-node. This becomes more noticeable when analysing
average time for receiving a first acknowledgement from a satellite node ( ¯
ACK), which
is representative of the time a request waits until it is served. However, due to the posi-
tioning 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 so-
lution. 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 configura-
tions, 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 vs.58 minutes. 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 per-
formance 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 constel-
lation, 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
Overlapping Trailing Uniform Swarm 2 Sats
Avg. end-to-end ( ¯
e2e) 00:47:32 00:37:59 00:28:48 00:37:12 00:37:28
Avg. time to ACK ( ¯
ACK) 00:30:27 00:20:41 00:07:43 00:19:12 00:15:29
Max time to ACK (ACK∗) 01:24:16 01:09:10 00:27:44 01:00:00 00:44:52
Avg. e2e at Rossøya ( ¯
e2eRoss) 00:33:14 00:22:52 00:10:59 00:21:36 00:19:15
Max e2e at Rossøya (e2e∗
Ross) 01:32:21 01:35:41 01:36:24 01:34:12 01:39:56
Avg. e2e at GRS(¯
e2eGRS) 01:16:46 01:05:27 01:06:34 01:09:00 01:15:13
Max e2e at GRS(e2e∗
GRS) 06:44:01 06:09:04 07:07:45 06:40:12 07:24:59
When comparing Svalbard against Vardø, the former outperforms the latter in al-
most 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
Overlapping Trailing Uniform Swarm 2 Sats
Avg. end-to-end ( ¯
e2e) 00:48:04 00:38:13 00:29:27 00:38:24 00:37:57
Avg. time to ACK ( ¯
ACK) 00:29:43 00:20:24 00:07:12 00:18:36 00:15:09
Max time to ACK (ACK∗) 01:24:18 01:31:13 01:31:29 01:28:48 01:31:48
Avg. e2e at Rossøya ( ¯
e2eRoss) 00:34:04 00:24:13 00:13:01 00:23:24 00:19:15
Max e2e at Rossøya (e2e∗
Ross) 02:52:12 01:50:53 01:36:25 02:06:00 01:39:57
Avg. e2e at GRS(¯
e2eGRS) 01:16:02 01:06:04 01:02:38 01:07:48 01:15:04
Max e2e at GRS(e2e∗
GRS) 06:44:02 06:09:06 07:07:46 06:40:12 07:25:00
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 net-
work 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 impor-
tant to highlight that the ground station Svalbard is only required whenever no coverage
is available at Vardø.
Comparing the proposed drifting swarm with the 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 impor-
tant to stress the importance of using a standardised networking solution, such 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 Arc-
tic 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 com-
parable 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 motivate the deployment of more satellites in orbit, increasing cov-
erage and reducing service degradation.
It was shown that the latitude and longitude between sensor nodes and ground sta-
tions 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 cover-
age, 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 re-
gion 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 demon-
strated 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.
Acknowledgement
This work was partially funded by the European Union’s Horizon 2020 research and in-
novation programme under the Marie Skłodowska-Curie Grant Agreement No. 699924,
SINet.
Bibliography
[1] Aalborg University (2014) AAUSAT3. URL http://www.space.aau.dk/aausat3/, on-
line
[2] Berge J (2017) Mare incognitum - arctic abc project summary. online, nFR projects 244319
and 245923
[3] Berge J, Geoffroy M, Johnsen G, Cottier F, Bluhm B, Vogedes D (2016) Ice-tethered ob-
servational platforms in the arctic ocean pack ice. IFAC-PapersOnLine 49(23):494 – 499,
DOI http://dx.doi.org/10.1016/j.ifacol.2016.10.484, URL http://www.sciencedirect.
com/science/article/pii/S2405896316320742
[4] Birkeland R (2014) An overview of existing and future satellite systems for arctic commu-
nication. In: Proceedings of ESA Small Satellites Systems and Services 2014
[5] Birkeland R (2014) Proposal for a satellite communication payload for sensor networks in
the arctic area. In: Proceedings of the 65th International Astronautical Congress
[6] Birkeland R (2017) Freely drifting cubesat constellations for improving coverage for arctic
sensor networks. In: 2017 IEEE International Conference on Communications (ICC), pp
1–6, DOI 10.1109/ICC.2017.7997293
[7] Birkeland R, Palma D, Zolich A (2017) Integrated smallsats and unmanned vehicles for
networking in remote locations. In: Proceedings of The 68th International Astronautical
Congress
[8] Bormann C, Hartke K, Shelby Z (2014) The Constrained Application Protocol (CoAP).
RFC 7252, DOI 10.17487/rfc7252, URL https://rfc-editor.org/rfc/rfc7252.txt
[9] Burleigh SC, Farrell S, Ramadas M (2008) Licklider Transmission Protocol - Specification.
RFC 5326, DOI 10.17487/rfc5326, URL https://rfc-editor.org/rfc/rfc5326.txt
[10] Chakrabarti S, Montenegro G, Droms R, james woodyatt (2017) IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines.
RFC 8066, DOI 10.17487/RFC8066, URL https://rfc-editor.org/rfc/rfc8066.
txt
[11] Foundation PS (2017) Python 3.5.3 documentation. online, URL https://docs.python.
org/3.5/
[12] Graphics A (2016) Stk. Online, URL http://www.agi.com/products/stk/, accessed
April 2016.
[13] Insider T (2015) Spacex is working on a ’pizza box’ that should scare
your internet company. Online, URL http://www.techinsider.io/
spacex-satellite- program-brings- global-internet-access-2015-9
[14] Iridium Communications Inc (2014) Iridium communications. URL https://iridium.
com/ProductList.aspx?productCategoryID=9, accessed 15.12.2014
[15] ITU (2015) Technical characteristics for a VHF data exchange system in the VHF maritime
mobile band. URL https://www.itu.int/rec/R-REC- M.2092, recommendation ITU-R
M.2092-0
[16] Kelso DT (1998) Frequently asked questions: Two-line element set format. Available at
https://celestrak.com/columns/v04n03/
[17] Merkel D (2014) Docker: Lightweight linux containers for consistent development and de-
ployment. Linux J 2014(239), URL http://dl.acm.org/citation.cfm?id=2600239.
2600241
[18] Norwegian Space Centre (2015) Satkom i Arktis (ASK). Online, URL http://www.
romsenter.no/Fagomraader/Satellittkommunikasjon/\Satkom-i- Arktis-ASK,
accessed June 2015
[19] OneWeb (2015) Oneweb homepage. online, URL http://oneweb.world/, accessed Oc-
tober 2015
[20] Palma D, Zolich A, Jiang Y, Johansen TA (2017) Unmanned aerial vehicles as data mules:
An experimental assessment. IEEE Access 5:24,716–24,726, DOI 10.1109/ACCESS.2017.
2769658
[21] Puig-Suari J, Zohar G, Leveque K (2013) Deployment of CubeSat Constellations Utilizing
Current Launch Oppertunities. In: 27th Annual AIAA/USU Conference on Small Satellites
[22] Rhodes B (2015) Pyephem home page. URL http://rhodesmill.org/pyephem/, ac-
cessed October 2015
[23] Salopek D, Vasi´
c V, Zec M, Mikuc M, Vaˇ
sarevi´
c M, Konˇ
car V (2014) A network testbed for
commercial telecommunications product testing. In: 2014 22nd International Conference
on Software, Telecommunications and Computer Networks (SoftCOM), pp 372–377, DOI
10.1109/SOFTCOM.2014.7039061
[24] Sanctis MD, Cianca E, Araniti G, Bisio I, Prasad R (2016) Satellite communications sup-
porting internet of remote things. IEEE Internet of Things Journal 3(1):113–123, DOI
10.1109/JIOT.2015.2487046
[25] Scott K, Burleigh SC (2007) Bundle Protocol Specification. RFC 5050, DOI 10.17487/
rfc5050, URL https://rfc-editor.org/rfc/rfc5050.txt
[26] Tanganelli G, Vallati C, Mingozzi E (2015) Coapthon: Easy development of coap-based iot
applications with python. In: 2015 IEEE 2nd World Forum on Internet of Things (WF-IoT),
pp 63–68, DOI 10.1109/WF-IoT.2015.7389028
[27] Thubert P, Hui J (2011) Compression Format for IPv6 Datagrams over IEEE 802.15.4-
Based Networks. RFC 6282, DOI 10.17487/RFC6282, URL https://rfc-editor.org/
rfc/rfc6282.txt
[28] Whitaker J (2017) Basemap Matplotlib Toolkit 1.0.8 documentation. online, URL http:
//matplotlib.org/basemap/
[29] Zohar GG (2013) Ad-hoc regional coverage constellations of cubesats using secondary
launches. Master’s thesis, Faculty of California Polytechnic State University, San Luis
Obispo
