Satellite-Assisted Disrupted Communications: IoT Case Study

Abstract

In recent years, the space industry has witnessed a resurgence, characterized by a notable proliferation of satellites operating at progressively lower altitudes, promising extensive global coverage and terrestrial-level data transfer speeds, while remaining cost-effective solutions. In particular, Wireless Sensor Networks (WSNs) can benefit from the wide coverage of space infrastructure due to their extensive deployment, disrupted communication nature, and the potential absence of terrestrial support. This study explored the utility of Low-Earth Orbit (LEO) satellite constellations as a communication infrastructure for interconnecting “smart” devices via ground stations in Internet of Things (IoT) scenarios. To this end, we designed and implemented a series of experiments conducted within the OMNeT++ simulator, utilizing an updated iteration of the original Open Source Satellite Simulator (OS3) framework. Our research encompassed an IoT Case Study, incorporating authentic sensor data sourced from the Smart Santander testbed. Throughout our experimentation, we investigated the impact of the constellation design parameters such as the number of satellites and orbital planes, as well as the inter-satellite link configuration on the obtained Round-Trip Time (RTT) and packet loss rates.

1. Introduction

In the dynamic landscape of modern technology, satellite utilization has become fundamental for various critical applications. Communication infrastructure based on satellite technology has emerged as a cost-effective solution, serving not only isolated regions where the establishment of terrestrial networks proves infeasible but also providing a viable alternative in emergency scenarios. In addition, the versatility of satellite services is exceptional [1], encompassing a diverse array of applications including military purposes, remote sensing, Earth observation, space exploration, maritime operations, agriculture, and communication provision over the Internet [2,3].

The existing literature has extensively explored the influence of space design parameters on satellites [4,5], including implementations in the Objective Modular Network Testbed in C++ (OMNeT++) [6] and protocol evaluation in space environments [7]. However, limited works have integrated real measurements from Internet of Things (IoT) devices and have demonstrated scenarios for satellite communications such as those described in the present effort.

To this end, our research focused on the communication of IoT devices via satellite constellations. We aimed to evaluate the reliability and effectiveness of satellite constellations across diverse IoT scenarios with regard to the Round-Trip Time (RTT) and data loss. We investigated the potential use of space infrastructure, in particular, Low-Earth Orbit (LEO) satellite constellations positioned at a 600 km altitude, as a viable substitute for the communication among ground stations or, more broadly, among any real-time sensitive “smart” device capable of generating and transmitting data. Assuming that communication is feasible, wherein these devices can establish connectivity with the satellite infrastructure, satellites can prove beneficial in diverse scenarios, including environmental emergencies or situations requiring enhanced security measures [8]. In particular, LEO satellite constellations can play a significant role in the smart city and IoT scenarios, which are characterized by intermittent or disrupted communications. These constellations can serve as a primary communication channel in remote areas where terrestrial infrastructures are impractical or can act as backup links [9] in situations involving compromised or damaged equipment.

We posit a hypothesis suggesting that denser constellations with enabled inter-satellite links would yield improved results in terms of RTT and data loss. Across the majority of our experiments, the aforementioned hypothesis was confirmed, as we observed a reduction of the mean and range RTT with lower ping loss when we increased the number of satellites and enabled inter-satellite links. However, notable exceptions have emerged with sensors exhibiting superior performance in constellations comprising fewer satellites. Therefore, we concluded that in certain cases, the position of the ground nodes relative to the satellites’ orbit prevailed as a major factor and significantly influenced the results in comparison to the effect of the number of satellites.

Our major contributions are listed below.

• We analyzed the influence of the satellites’ design parameters, e.g., the number of ground stations, satellites, planes, and inter-satellite links, on the reliability (i.e., the RTT and packet loss) of the ground-to-satellite connections.
• We demonstrated two scenarios involving the utilization of LEO satellite constellations for the communication among the IoT devices.
• We performed a Case Study, in which we integrated the real data obtained from the Smart Santander sensors into OMNeT++ to examine the transmission to the testbeds located in the EU and the U.S.

The remainder of this paper is organized as follows: In Section 2, we outline the related work, focusing on the relevant research areas and the implementations in OMNeT++. Section 3 describes our experimentation methodology, including the configuration of our experiment setup and the concepts of the examined scenarios. In Section 4, we detail certain significant experimental parameters and the scenarios involved, while in Section 5, the results of those scenarios are delineated. In Section 6, we summarize the results of the experiments and identify the limitations and future steps. Finally, in Section 7, we present our concluding remarks.

2. Related Work

The evaluation of space infrastructure has gained increasing attention, due to the significant role of satellites, Unmanned Aerial Vehicles (UAVs), drones, and ad hoc networks in facilitating the communication among IoT devices within the Edge–Cloud environment. In Table 1 a summary of the related literature works has been provided, focusing on the research areas of: (i) smart cities, (ii) IoT relays, (iii) space communication, and (iv) Delay-Tolerant Networking (DTN).

Existing literature works have leveraged OMNeT++ across diverse network domains, including 4G, 5G, Mobile Ad hoc Networks (MANETs), Vehicular Ad hoc Networks (VANETs), ad hoc Wireless Sensor Networks (WSNs), Peer-To-Peer networks (P2P), etc. These works have implemented network protocols and standards primarily by utilizing the INET framework [10]. INET evolved from the IPSuite originally developed at the University of Karlsruhe, providing detailed protocols such as the Transmission Control Protocol (TCP), Internet Protocol versions 4 and 6 (IPv4 and IPv6), Ethernet, Ieee802.11, and Open Shortest Path First (OSPF). INET also serves as a starting point for the implementation of novel networking paradigms such as Software-Defined Networking (SDN), Named Data Networking (NDN) and Information-Centric Networking (ICN).

In the context of smart city scenarios, several studies have utilized OMNeT++. An approach for rapid VANETs was presented in [11], incorporating OMNeT++ with the Vehicles In Network Simulation (VEINS) and Simulation of Urban Mobility (SUMO) frameworks to simulate traffic scenarios using maps imported from OpenStreetMap (OSM). In [12], the implementation of VANET broadcasting algorithms and the potential issues of actual devices were addressed, using OMNeT++, SUMO, and Google Earth. A version of the INET framework for Vehicle-To-Everything (V2X) communications was considered in [13], aiming at a substantial reduction in the computational time in city-scale scenarios. In [14], the focus shifted to enhancing the performance of the Ad hoc On-demand Distance Vector (AODV) and Optimized Link State Routing (OLSR) protocols in high-density urban areas, by proposing a vehicle-node density parameter. Authors in [15] discussed strategies to improve the road safety and traffic management through a Variable Speed Limit (VSL) implementation via VANETs and overcome the challenges associated with traditional systems, using OMNeT++, SUMO, and VEINS. Furthermore, in [16,17], specific enhancements in the packet delivery of routing protocols were investigated, focusing on AODV and MANET devices respectively.

Regarding OMNeT++ implementations for relays, various works showcased the utilization of this framework. The authors in [18] introduced the BEEDRONES framework for the data collection in UAV-aided WSNs, aiming to enhance the WSN lifetime and optimize the data quality by minimizing spatial correlation. In [19], a lightweight distributed detection scheme was introduced to defend against flooding attacks in the “Internet of Drones” environment. In [20] a spatial querying scheme aided by the sky caching concept was presented, involving a flying drone. Regarding the implementation of ships as relays, a particular example of the Synthetic Aperture Radar with error control was implemented in [21], displaying encouraging outcomes with respect to the Bit and Packet Error Rate, window size, and system efficiency. Additionally, the work by [22] proposed a simulation framework concerning the energy consumption and communication protocols in Maritime Surveillance Sensor Networks to facilitate information acquisition. Finally, in [23] the evaluation of a relay-aided device-to-device alternative method was described, to support short-distance direct communications in scenarios with suboptimal channel links and limited coverage.

Furthermore, several noteworthy space-related endeavors that utilize OMNeT++ have been undertaken. Various protocols and mechanisms have been tested in the context of satellite communications such as the IEEE 802.15.4 standard for WSN devices [24], the Digital Video Broadcasting standards (DVB-RCS and DVBS2) [25], Carrier-sense multiple access with collision avoidance (CSMA/CA) back-off distribution functions [26] and novel (MAC and MANET) routing solutions [27,28]. In addition, the authors in [29] introduced a Satellite Network Simulation Platform for testing communication protocols such as DTN concepts. Furthermore, network jamming scenarios have been evaluated by implementing prevention algorithms for defense, as explored in [30], as well as the trade-offs associated with the satellite-to-ground and satellite-to-satellite communications, specifically focusing on their impact on the energy consumption [28].

Subsequently, certain studies investigated the impact of space design parameters on metrics such as the delay, without employing simulations in OMNeT++. In [4,31], the system architecture of constellation designs was analyzed, estimating the total throughput and minimizing the required ground stations, while [31] attempted to optimize the number of satellites in ultra-dense LEO constellations to satisfy backhaul requirements. In addition, existing studies examined the effect of satellite design parameters and challenges. In particular, the authors of [32,33,34] analyzed the architecture of inter-satellite link paths with [33] focusing on Mega-constellation networks and [34] outlining trends and future prospects in the space laser communication scheme. In [5,35,36,37] the impact of different constellation sizes and orbit inclinations have been explored, regarding hop-count metrics and comparing them with the ground fiber networks. Finally, the work by [38] investigated certain routing issues in a Starlink constellation, evaluating the end-to-end latency with multi-path options, while [39] provided an overview of integrating LEO constellations into 5G and B5G systems.

Moreover, in the challenging networking scenarios characterized by disruptive communications and delay, DTN has demonstrated its value as a valuable solution [3,40,41]. Addressing a spectrum of inter-networking challenges, DTN protocols have been comprehensively explored in [32]. Some notable scenarios included the Ring Road Network approach [42] and a multi-hop DTN relay system [7]. These scenarios utilized LEO satellites as “data mules” to efficiently transfer data during overflights to areas lacking Internet connectivity on Earth or beyond. Hence, any unsent data was stored for future flights to reduce the end-to-end latency of the delivered message. Focusing on urban environments, authors in [43] introduced a reference routing protocol for DTN-capable nodes, aiming to extend the Internet coverage in highly-dense environments, while in [44], DTN applications in existing infrastructure of public transport networks were investigated. Moreover, the work by [45] concentrated on practical experimentation to validate the effectiveness of DTN solutions in different scenarios, considering the routing in space. Finally, the SPICE testbed is presented in [46], serving as a state-of-the-art DTN testbed for satellite and space communications, relying on the Bundle Protocol to support multiple DTN implementations and various underlying and overlying protocols.

While certain literature studies focus on simulating and analyzing space-terrestrial communication scenarios with OMNeT++, they exhibit a limited emphasis on the incorporation of real-world testbed data into the simulation environment. This distinction is essential to ensure the accuracy of simulation results, as real-world measurements provide valuable insights into the practical performance of communication systems. In the context of IoT Case Study scenarios, the evaluation of various parameters impacting the reliability of space-terrestrial communications is crucial. Therefore, the integration of real-world measurements into simulations and the thorough examination of relevant parameters can enhance the relevance and applicability of the findings to practical scenarios.

Table 1. Summary of literature works.

Research Area	Papers	Focus	OMNeT++
Smart Cities	[11,12,13,14,15,16,17]	Implementations for VANET, V2X communications & Integration with other frameworks e.g., SUMO, VEINS	Yes
IoT relays	[18,19,20,21,22,23]	UAV/Drone frameworks for WSNs, security, energy consumption	Yes
Space related	[24,25,26,27,28,29,30]	Examine protocols and standards impact in the context of satellite communications e.g., routing, CSMA/CA etc.	Yes
Space related	[4,5,31,32,33,34,35,36,37,38,39]	Impact and optimization of space design parameters on throughput, end-to-end latency etc.	No
DTN related	[3,7,32,40,41,42,43,44,45,46]	DTN communication protocols and solutions in dense environments	No

Table 1. Summary of literature works.

Research Area	Papers	Focus	OMNeT++
Smart Cities	[11,12,13,14,15,16,17]	Implementations for VANET, V2X communications & Integration with other frameworks e.g., SUMO, VEINS	Yes
IoT relays	[18,19,20,21,22,23]	UAV/Drone frameworks for WSNs, security, energy consumption	Yes
Space related	[24,25,26,27,28,29,30]	Examine protocols and standards impact in the context of satellite communications e.g., routing, CSMA/CA etc.	Yes
Space related	[4,5,31,32,33,34,35,36,37,38,39]	Impact and optimization of space design parameters on throughput, end-to-end latency etc.	No
DTN related	[3,7,32,40,41,42,43,44,45,46]	DTN communication protocols and solutions in dense environments	No

3. Methodology

The section provides an overview of our experimental methodology, including a generic description of the investigated scenarios. We have conducted two sets of experiments to assess the impact of various experimentation parameters, including the number of satellites and the presence of inter-satellite links within LEO constellations, on the mean and range of the RTT as well as the ping loss. These experiments investigated different constellations and topologies in the IoT/smart-city scenarios where sensors transmit pings to various ground stations around the globe. The position of each ground station was specifically defined by their exact geographical longitude and latitude. We highlighted the potential relevance of the aforementioned parameters in the context of networking communications, especially when confronted with disruptive network conditions. In the first scenario, a topology where sensors communicate with ground stations located in the EU and the U.S. was examined. Subsequently, we explored an IoT Case Study (scenario 2) where the data from real sensors located in the Smart Santander testbed [47] and obtained within the Rewire project [48] were imported into OMNeT++. This experiment extended over 24 h, during which different testbeds in the EU and the U.S. received pings, according to the real sensors’ timestamps derived from .csv files.

The coverage area or footprint of a satellite is illustrated as a circular area on the surface of Earth, indicating the zone within which satellites can communicate with ground stations. The primary variables affecting the footprint are: (i) the elevation angle (${ϵ}_0$), (ii) the nadir angle (${\alpha }_0$), (iii) the central angle (${\beta }_0$), (iv) the slant range (d)–i.e., the distance from a satellite to a ground station, and (v) the satellite altitude above the surface of the Earth (H), while $Re$ = 6378 × 10${}^3$ m is the constant distance from a ground station to the Earth’s center. In

Table 2. The coverage of satellites (in %) per elevation angle (${ϵ}_0$) (in ${}^{\circ }$) and per altitude (in km).

	Satellite Altitude
Elevation ( ${\mathit{ϵ}}_{\mathbf{0}}$)	160 km	500 km	600 km	700 km	800 km	900 km	1000 km	1500 km
0${}^{\circ }$	1.22	3.63	4.30	4.94	5.57	6.18	6.78	9.52
2${}^{\circ }$	0.89	3.04	3.64	4.24	4.82	5.39	5.95	8.54
4${}^{\circ }$	0.66	2.54	3.09	3.64	4.17	4.70	5.22	7.66
6${}^{\circ }$	0.49	2.12	2.62	3.12	3.61	4.10	4.58	6.86
8${}^{\circ }$	0.37	1.78	2.23	2.68	3.13	3.57	4.02	6.15
10${}^{\circ }$	0.28	1.50	1.90	2.30	2.71	3.12	3.53	5.50
25${}^{\circ }$	0.06	0.46	0.62	0.80	0.98	1.17	1.37	2.39
40${}^{\circ }$	0.02	0.17	0.24	0.31	0.38	0.47	0.55	1.03

, the coverage area at different satellite altitudes and elevation angles is calculated by applying the related equations below (where r = H + $R_e$) and utilizing trigonometry as featured in Figure 1:

$${ϵ}_0+{\alpha }_0+{\beta }_0={90}^{\circ }$$

(1)

$$d\ast \cos {ϵ}_0=r\ast \sin {\beta }_0$$

(2)

$$d\ast \cos {\alpha }_0=R_e\ast \sin {\beta }_0$$

(3)

Applying the cosines law, on the largest triangle we obtain:

$$r^2=R_e^2+d^2-2\ast R_e\ast d\ast \cos (90+{ϵ}_0)$$

(4)

Observing the large sub-triangle, we calculate the $sin{\alpha }_0$ which depends on the elevation angle according to Equation (5). Consequently, the maximum coverage can be achieved for elevation angle ${ϵ}_0$ = 0 → cos${ϵ}_0$ = 1.

$$sin{\alpha }_0=\frac{R_e}{R_e+H}\ast \cos {ϵ}_0$$

(5)

The surface of the coverage area is calculated by Equation (6), where h is the height of the spherical cap:

$$S_{Coverage}=2\ast \pi \ast R_e\ast h$$

(6)

From the smallest triangle built including the ${\beta }_0$ angle:

$$cos{\beta }_0=\frac{R_e-h}{R_e}=1-\frac{h}{R_e}\Rightarrow \frac{h}{R_e}=1-\cos {\beta }_0$$

(7)

Finally, from Equations (6) and (7) we can express the satellite’s footprint as a percentage of the Earth’s surface area:

$$Coverage(\%)=\frac{S_{Coverage}}{S_{Earth}}=\frac{2\ast \pi \ast R_e\ast h}{4\ast \pi \ast R_e^2}=\frac{1}{2}\ast (1-\cos {\beta }_0)$$

(8)

Given the elevation angle and the satellites’ altitude, we generate Table 2. From this table, we can calculate the satellite footprint i.e., 0.62% for a 25${}^{\circ }$ elevation angle and 600 km constellation, which will serve as the communication range in our experiments. Therefore, if a ground station is identified as the next hop of a satellite transmission, as determined by the Dijkstra algorithm, and is located within the communication range of the satellite, the transmission is feasible and is subsequently executed.

4. Experiments

In this section, we detailed the significant experimentation parameters and the two demonstrated scenarios. The primary tool employed for simulating the experiments is OMNeT++. Specifically, our study utilizes the Open Source Satellite Simulator (OS3) framework, a popular and mature tracking library implemented in OMNeT++ and INET to simulate and visually represent various forms of satellite-based communications by importing authentic satellite trajectories and even meteorological data. The original version of OS3 [49] encountered challenges regarding the outdated documentation and compatibility with up-to-date versions of OMNeT++ and INET. To address these issues, our experiment was constructed based on an updated version of the OS3 framework. For a comprehensive view of the framework please refer to repositories [6,50] and paper [51] in which authors provide a detailed description of the design and implementation, while also describing simulation scenarios using LEO satellite constellations.

In this section, we describe some significant parameters for the experiments as well as the discussed experimentation scenarios. The simulations were executed on a laptop equipped with an Intel Core i7 CPU, running Ubuntu 16.04 LTS. The software stack included OMNeT++ v4.5.2, INET v4.3, and the updated OS3 framework [6,50,51].

4.1. Experimentation Parameters

We established ground stations, denoted as MCC (Mission Control Center), to serve as wireless ground hosts. They send pings as PingApps nodes from the INET framework [52] and the quantity of these nodes is determined by the numOfMCCs variable. These stations initiate ping requests, with the first ping transmitted at the specified startTime parameter. In terms of ground station positioning, the framework incorporated a modified transmission model from INET that integrates actual coordinates (longitude, latitude, and altitude) of the nodes and calculates the actual distances and propagation delays across the 2D OMNeT++ map, facilitated by the IntegratedCanvasVisualizer submodule.

We conducted simulations involving diverse satellite constellations positioned at an altitude of 600 km, with 25${}^{\circ }$ elevation angle, mirroring the characteristics of Starlink satellites at this altitude [53]. The ground-to-ground station communication were ruled out as the purpose of the work is to investigate satellite-assisted communications. According to Table 2, these satellites exhibit a coverage percentage of approximately 0.62% of the Earth’s surface. Given the known radius of the Earth ($Re$ = 6378 × 10${}^3$) we calculate the radius of the satellite’s footprint, i.e., approximately 1008 km. This radius is transformed into the 2D OMNeT++ environment through the representation of the communicationrange parameter, a constant value across all our experiments given the consistent 600 km altitude of the satellites. The fullDuplex parameter is also enabled, allowing nodes to simultaneously transmit and receive data, functioning as transceivers. The satellites in our experiments served as wireless hosts, but mobile, orbiting the Earth at an altitude of 600 km. According to the OS3 model, two methods are employed to construct constellations: (1) utilizing .txt files containing current satellite constellation data and (2) creating an entirely new constellation based on predefined standards. The former method leverages the original OS3 framework, utilizing Two-Line Element (TLE) sets of data that can be downloaded from [54] and imported. We opted for the latter method, designing our satellite constellation with specific parameters from the updated OS3 version [50] since a primary goal of this study was to analyze the influence of satellite design parameters on the reliability of satellite communications in different scenarios. Therefore, some of the already existing TLE data might limit our work which led us to “hard-code” the number of satellites (numOfSats), number of planes, satellites per plane (satPerPlane), and the intersatelliteLink parameter (which is described below).

Moreover, the updateInterval variable served as granularity to signal mobility state changes. A smaller updateInterval enhances result accuracy and smoothness by allowing the identification of a greater number of alternative route paths. However, this improvement comes with corresponding drawbacks, including increased complexity in terms of routing (resulting in larger routing tables) and longer execution times for the experiments. Particularly, in denser constellations, the runtime becomes noticeable since the reconfiguration of routes and the construction of larger network topology graphs require significant time. As the simulation topology was updated based on the updateInterval parameter, the Dijkstra’s shortest path algorithm was invoked, edges were created for nodes located within the communication range, and edge weights were assigned to determine the feasibility of a connection. In case of viable connections, the propagation delay was set as the edge weight, otherwise an infinite weight was assigned to the edge. Subsequently, each route was added to each node’s routing table. Upon changes in the topology according to the updateInterval, relevant parameters that require updates were reconfigured, such as satellite positions and node routing tables. When the topology changes (in the next updateInterval), any relevant parameter that required update was reconfigured such as satellite positions and node routing tables.

Finally, the intersatelliteLink parameter enabled the communication among satellites with some preconditions such as the compatibility of links within each satellite [50]. In this context, satellites placed on the same plane or neighboring planes communicated even with the absence of a ground station between them. On the contrary, while disabled, the placement of a ground station between satellites was mandatory to achieve communication under these conditions.

4.2. Experimentation Scenarios

The following subsections outline the two experiment scenarios. The former describes an IoT experiment where deployed sensors communicate between the EU and the U.S. The second scenario entails simulating communication among real sensors positioned in Smart Santander and existing testbeds in the EU and the U.S. The actual geographical location of these sensors was incorporated in the configuration file (.ini) of OMNeT++ to guarantee the precision of the results. In both scenarios and their respective experiments, we captured snapshots (refer to Figure 2 and Figure 3) and illustrate diagrams of the RTT over time and ping loss over time.

4.2.1. Scenario 1: IoT Sensors for EU-EU and EU-U.S. Communication

In this subsection we investigated a scenario where sensors located in the EU transmit to ground stations in different regions (in EU and U.S.), exploring the impact of varying satellite numbers in a constellation on the mean RTT and ping loss. Two examples were implemented, deviating only the number of satellites in the constellation: the first with 360 satellites (i.e., 6 satellites per plane, 60 satellites per plane), and the second with 600 satellites (i.e., 10 satellites per plane, 60 satellites per plane). Initially, we examined the scenario with 150 satellites, identifying the absence of established communication links and consequently, we doubled the number of satellites in the constellation. Within the topology, 16 sensors were positioned, with 5 in the U.S. transmitting pings to an MCC in the EU, 5 in the EU following the reverse path, and 6 engaged in EU-to-EU communications. Additionally, 11 MCCs were incorporated, with 5 of them functioning as ships to facilitate alternative routes among the satellites of different planes through the intersatelliteLink parameter. The sendInterval was set to 300 s (i.e., 5 min) and the updateInterval at 100 s to achieve a balance between suitability and reduced execution time. Finally, the simulation time limit was set to 24 h to demonstrate a complete day of transmissions. The average distance between sensors and ground stations in EU and U.S. is $5320.82$ km, while the EU-to-EU distance is $2881.52$ km. The simulation parameters of Scenario 1 are detailed in

Table 3. Simulation parameters of Scenario 1.

numOfMCCs	11
Senders	Sensors[0…4], Sensors[5…9], Sensors[10…12], Sensors[13...15]
Receivers	MCC[6], MCC[5], MCC[7], MCC[8]
Ships	5
numOfSensors	16
numOfSats	1st experiment 360, 2nd experiment 600
Planes	1st experiment 6, 2nd experiment 10
satPerPlane	60
enableInterSatelliteLinks	true
updateInterval	100 s
sendInterval	300 s
sim-time-limit	24 h

.

4.2.2. Scenario 2: IoT Sensors from Smart Santander Transmitting to Existing TestBeds

In this scenario, the data generated from a set of sensors within the Smart Santander testbed (obtained from the Rewire project [55,56]) were utilized to construct an IoT experiment. The timestamps from the actual sensors’ metrics (saved in .csv files) were parsed in OMNeT++ with a Python script (that reads the .csv files and parses the respected values), to simulate their communication with various testbeds in the EU and the U.S. through satellite communications. Our experiments examined the impact of both the satellite number in a constellation on the mean RTT and ping loss, as well as the effects of the interSatelliteLink parameter. The detailed simulation parameters for Scenario 2 are provided in

Table 4. Simulation parameters of Scenario 2.

numOfMCCs	26
Senders	see Table 5
Receivers
Ships	7
numOfSensors	10
numOfSats	1st experiment 360, 2nd experiment 600, 3rd experiment 900
Planes	1st experiment 6, 2nd experiment 10, 3rd experiment 15
satPerPlane	60
enableInterSatelliteLinks	true/false
updateInterval	60 s
sendInterval	.csv files of each sensor
sim-time-limit	24 h

.

Among the available sensors, both static and mobile, we acquired data for 10 stable sensors for our simulations, with their real measurements recorded on 3 December 2022. Five (5) of them are located in parking slots monitoring the arrival and departure of vehicles, while the remaining sensors are distributed across the city, capturing diverse measurements such as battery level, temperature, illuminance, and sound pressure level. Therefore, the sensors placed in parking slots have limited to no periodicity in their transmissions (i.e., Sensors[5–9]) while the remaining maintain close to constant sendInterval (i.e., Sensors[0–4]) with some displaying proportional changes in the initial sendInterval, such as intervals of 10 min, 20 min, and 30 min.

Table 5. Characteristics of sensors and simulation variables for Scenario 2.

Sensors/Senders	SensorId	Receivers	Distance (in km)	Start_Time sim (min)	Start_Time (h:min)	Last_Time (h:min)	Sim_Time (h)
Sensor[0]	9	MCC[20]	840.84	2	1:00	23:55	24
Sensor[1]	24	MCC[9]	2232.52	1	0:59	23:59
Sensor[2]	53	MCC[14]	947.06	2	1:00	23:5
Sensor[3]	90	MCC[17]	1029.30	2	1:00	23:54
Sensor[4]	110	MCC[13]	543.94	0	0:58	23:56
Sensor[5]	213	MCC[5]	5320.82	506	9:24	17:57
Sensor[6]	146	MCC[18]	935.35	714	12:52	23:32
Sensor[7]	19	MCC[21]	1196.81	242	5:00	18:42
Sensor[8]	1	MCC[22]	1794.49	5	1:03	17:41
Sensor[9]	135	MCC[24]	874.42	358	6:58	23:58

describes the characteristics of the 10 selected sensors in relation to the simulation parameters and the actual sensors’ ID. The earliest start time of data transmission, specifically at time 0:58, is taken as the reference point (time 0), corresponding to the initial measurement from Sensor[4]. Subsequently, all the remaining sensors initiate their transmissions by following the timer of Sensor[4], e.g., Sensor[1] has a startTime of 1 min since its transmission started at 0:59.

Furthermore, the number of the distinct ground stations was increased to 26 by incorporating MCCs that mirror certain real testbeds located in Europe. Their names and coordinates (longitude and latitude) are outlined in

Table 6. MCC testbeds and features of Scenario 2.

MCC	Location	Coordinates	Name
MCC[5]	USA	50.334241, −74.0060	-
MCC[8]	Athens/Greece	37.970833, 23.725110	NETMODE
MCC[9]	Xanthi/Greece	41.130036, 24.886490	-
MCC[13]	Barcelona/Spain	41.346176, 2.168365	OFELIA
MCC[14]	Malaga/Spain	36.719444, −4.420000	Triangle
MCC[15]	Antwerp/Belgium	51.260197, 4.402771	CityLab
MCC[16]	Smart Santander/ Spain	43.462776, −3.805000	smartSantander
MCC[17]	Dublin/Ireland	53.342686, −6.267118	IRIS
MCC[18]	Amsterdam/Netherlands	52.377956, 4.897070	ExoGENI
MCC[19]	Volos/Greece	39.366669, 22.933332	NITOS
MCC[20]	Geneva/Switzerland	46.204391, 6.143158	IoT Lab
MCC[21]	Ljubljiana/Slovenia	46.056947, 14.505751	LOG-a-TEC
MCC[22]	Warsaw/Poland	52.237049, 21.017532	PL-LAB
MCC[23]	Paris/France	48.864716, 2.349014	EdgeNET&Grid’5000
MCC[24]	Monaco/France	43.6155, 7.0550	R2lab

, while the actual distances between the sending Sensor and its corresponding MCC destination are presented in Table 5. We should note that MCC[5] and MCC[9] do not correspond to actual testbeds but are included for experimental purposes.

5. Results

In this section, we investigated the performance of different satellite constellations with regards to the RTT and ping loss across two IoT scenarios.

5.1. Scenario 1: IoT Sensors for EU-EU and EU-U.S. Communication

Upon comparing the two experiments in Scenario 1, hlthe 600 satellite constellation resulted in nearly continuous curves with distinct periodicity and more compressed RTT ranges (see Figure 4). In addition, a lower range and mean RTT, as well as decreased or even eliminated ping losses for every Sensor were observed within the 600 satellite experiment (refer to Figure 5). Specifically, every sensor besides Sensor[0] in the 360 satellite constellation provided ping loss in the range of 0–4.89%, whereas the 600 satellite constellation resulted in nearly eliminated loss (0–0.69%). Even for Sensor[0], in which the received pings were limited, likely due to collision issues arising from simultaneous transmissions, the ping loss was reduced from 70.48% to 69.09%.

5.2. Scenario 2: IoT Sensors from Smart Santander Transmitting to Transmitting to Existing TestBeds

Figure 6 illustrates the mean and range of RTTs, as well as the received pings and ping loss for each sensor and satellite constellation. Since every sensor communicates with different destination nodes, a direct comparison among sensors may lack significance. Therefore, we evaluate and compare the transmissions of each sensor across the different constellations.

In all experiments within Scenario 2, the range of the RTT is more compressed when the intersatelliteLinks parameter was enabled (see Figure 7), primarily due to the less frequent satellite-to-MCC connections. Consequently, we generally observed a higher mean RTT with intersatelliteLinks disable. We also noticed similar values of the mean RTT in certain Sensors with and without the intersatelliteLinks parameter. The most likely explanation can be found by examining the location of the destination nodes, wherein the connection between the sender and the receiver was established through one satellite, utilizing practically no intersatelliteLinks, although they were enabled. Moreover, Sensor[5] was identified as a distinctive case, communicating with its destination (located in U.S.) primarily with intersatelliteLinks enabled and only without them through a constellation of 900 satellites.

Regarding the received pings, noteworthy observations have surfaced. While some sensors followed the expected pattern—where an increase in planes and satellites in the constellation corresponded to an increase in received pings (e.g., Sensor[0,4])—others exhibited an inversely proportional relationship (e.g., Sensor[1,3]) and some demonstrated mix results (e.g., Sensor[2]). For the latter case, Sensor[2] received more pings within the 360 satellite constellation compared to the 600 one, but fewer pings in contrast to the 900 satellite constellation. We attribute the results of Sensors[2,3,6] both to the possible occurrence of occupied communication channels but also to the topology of the experiment.

A potential indicator of the occupied communication channels case could be the significant variations in the RTT. In such occasions, transmissions may take longer to reach the destination because they either attempt a more distant idle path or transmit at a subsequent point in time when a communication channel is available, utilizing the “store-and-forward” mechanism. Both scenarios contribute to longer RTTs, which are observable in RTT/time diagrams. This phenomenon was noticeable in Figure 7c for Sensor[2], where the RTT values were increased even up to six times at certain time points and then returned to their average values.

On the contrary, the ping loss experienced by Sensor[3] can be attributed to the positioning of the ground station in relation to the orbits and satellites within the constellation. Specifically, Sensor[3] transmitted from Smart Santander to a testbed in Ireland, a communication link that was challenging to establish with the specific type of constellation (i.e., planes and satellites per plane), the satellites’ communication range and the related preconditions as described in Section 4.1. This is observed in the simulation snapshot depicted in Figure 6.

6. Discussion

Throughout our experiments, we investigated the impact of the number of satellites in a constellation on the resulting RTT and ping loss. While the topology of each experiment, particularly the location of the sender(s) and the receiver(s) on the map compared to the satellite constellation (planes, satellites, orbits, etc.), plays a crucial role, in the majority of our experiments, increasing the number of satellites typically led to a reduction in the generated RTT and ping loss. Therefore, an inversely proportional relationship was detected. This observation aligns with the notion that larger constellations of satellites may more efficiently utilize available routes and paths between the sender and receiver. Moreover, in experiments where the intersatelliteLink parameter was enabled, an additional reduction in the RTT and ping loss was noticed. This indicates that the utilization of inter-satellite links contributes to further optimizing communication performance in the simulated scenarios.

Regarding the effect of inter-satellite links, our findings revealed consistently compressed range values for the RTT across all experiments involving active inter-satellite links. In fact, the minimum, maximum and mean RTT values exhibited reduced values when compared to scenarios without the intersatelliteLink parameter (refer to Figure 7). This outcome is attributed to the interconnection of satellites within the same plane, resulting in shorter propagation delays, as opposed to higher propagation delays due to the more frequent connections of space and ground. As mentioned, inter-satellite links proved beneficial, serving as the sole alternative in scenarios where no ground station existed between a distant sender and receiver such as the case of Sensor[5] in Scenario 2. This was illustrated in Figure 6 where transmissions between Sensor[5] and the ground station in U.S. became impossible when the intersatelliteLink parameter was disable, specifically in constellations comprising of 360 and 600 satellites.

Surprisingly, we observed cases where the presence of inter-satellite links resulted in higher ping losses. Specifically, in Scenario 2, Sensor[8] (see Figure 6) exhibited lower ping losses when the intersatelliteLink parameter was disabled. For instance, in the case of the 600 and 900 satellite constellations with inter-satellite links, there was a 13% increase in ping loss compared to the case where inter-satellite links were disabled.

The primary limitations of our study can be attributed to the selection of the methodology and the nature of the real data acquired. At first, since ground-to-ground communications were excluded from this study, some possibly optimal results due to the more reliable ground communication i.e., better RTT or packet loss were not examined in the involved scenarios. In addition, although the “hard-coded” satellite design parameters—i.e., number of planes, satellites per plane etc.—allowed us to examine the impact of those design parameters on RTT and packet loss, real TLE sets of data were not used. Finally, since we integrated real data in OMNeT++, some experimentation results were limited by the frequency (i.e., timestamps) of the measured values. For instance, in certain sensors of scenario 2, a higher volume of data might led to more accurate or even surprising results with regards to the RTT and ping loss. One instance might have included notably higher RTTs due to the occupancy of some channels or a higher packet loss for the same reason.

In future work, there are various parameters that can be alternated and evaluated, including different constellation designs such as pure TLE-based satellites, variations in the orbits, number of planes and satellites, adjustments to angles of elevation, and modifications to satellite altitudes. Additionally, the exploration of advanced mechanisms could be valuable for optimization purposes. Examples of such mechanisms involve the implementation of algorithms for routing, queuing, and traffic management, as well as the integration of congestion control mechanisms or techniques like the “store-and-forward”. Furthermore, the implementation of DTN and protocols such as the NDP (Neighbor Discovery Protocol), specifically tailored for satellite infrastructures, could be considered as part of future research endeavors. Moreover, in our experiments we utilize “Ships” as relays which operate as the rest of the ground stations, establishing or enhancing the communication between sender(s) and receiver(s). Their utilization should be investigated in detail regarding the technical specifications and applicability of such a proposal within the context of satellite-based communication systems. To conclude, while the advantages of inter-satellite links are apparent, there is a tradeoff conserning the cost and complexity of satellites. The implementation and maintenance of inter-satellite links contribute to the overall complexity and cost associated with satellite systems, aspects that were not considered or analyzed in the present work but need to be carefully evaluated in the context of any satellite communication deployment.

Finally, the extension of satellite or -in general- space utilization opens up numerous novel research areas. Ships, drones, UAVs, and any “smart” devices with suitable characteristics can play vital role in various scenarios. For instance, the deployment of micro/nano satellites or drones with a designated purpose can influence the communication resilience and security in smart-city and IoT scenarios. These devices can serve as relays, contributing to communication continuity or enhancing security in situations where communication infrastructures are jammed, compromised, or under attack. Equipped with specific and secure instructions, these satellites or drones can act as connection bridges, offering temporary solutions to potential issues, such as addressing a security breach in the communication infrastructure.

7. Conclusions

This paper investigated the application of LEO satellite constellations at an altitude of 600 km for the communication among smart devices in IoT scenarios. Our experiments validated the initial hypothesis, indicating the existence of an inversely proportional relationship between the number of satellites and the resulting RTT and ping loss. The introduction of inter-satellite links further contributed to the reduction of mean and range RTT, as well as ping loss. Nevertheless, there were instances where the placement of ground stations and satellites emerged as a dominant factor, leading to improved communication even with a lower number of satellites in the constellation. Additionally, cases were observed where an occupied communication channel resulted in a temporary and substantial increase in the RTT, affecting the overall performance of the communication. We plan to further explore the utilization of satellites, UAVs or VANETs in case studies where DTN solutions are applicable and identify trade-offs on IoT deployments.