# Multi-Layered Satellite Communications Systems for Ultra-High Availability and Resilience
## 5 Results: Findings from Simulations and Testbed Activities
### Simulation Studies
The end-to-end delay is defined as the total delay from the UT via the satellite(s) to the GW. Results for the simulations are shown in Figures 6-9. Figures 6 and 7 present the cumulative distribution function (CDF) of the end-to-end delay and packet loss percentage when the packets were routed only via the GEO layer. In our scenario, about 20% of the packets went only via one GEO satellite, i.e., the source UT and destination GW were located under the same GEO satellite. The end-to-end delay was then around 265 ms. The rest of the packets used a GEO-GEO ISL to reach the other satellite that served the destination GW. The delay was then around 515 ms. In individual UT-GW traffic flows, the jitter (as standard deviation from the mean end-to-end delay of the flow) was between 0.02-0.04 ms.  
UTs located in polar areas did not have a connection to the GEO satellite, hence they had 100% packet loss. Otherwise, there were some single packets lost due to bad reception, i.e., a too-high bit error rate. The results were quite similar regardless of the GW location used. Figure 8: End-to-end delay for UDP when packets are routed via LEO only or via both LEO and GEO. Packets going through GEO layer have clearly longer delays due to long hops between LEO and GEO vs. multiple hops in LEO only. Routing was based on [PERSON]’s shortest path algorithm with number of hops as the link cost metric. Figure 9: Packet loss for UDP traffic flows between UT-GW pairs in LEO or GEO+LEO layers. UTs in polar areas are now served by LEO satellites. Figures 8 and 9 present the same statistics for the case when packets were routed only via a LEO layer. Now the average end-to-end delay was 71 ms, with a minimum of 7.3 ms (source and destination under the same LEO satellite) and a maximum of 156 ms (source and destination on the other sides of the Earth). If the GEO layer was also enabled, some packets used the LEO-GEO ISLs and GEO satellites to reach the other side of the Earth with fewer hops than using only the LEO-LEO ISLs. The average delay increased then to 91 ms with a minimum of 9.1 ms and a maximum of 891 ms. Additionally, the jitter increased. For example, a traffic flow in a pure LEO case had a jitter of 31 ms, but, with LEO+GEO, the jitter was 130 ms. The packet loss varied between 0.3-9%. The polar areas were now served by the LEO satellites. We can conclude that the following lessons were learned from the simulations:  
* We simulated GEO and LEO partly separately, which was possible due to different routing policies for delay and jitter-sensitive traffic. Delay-sensitive traffic was routed only via LEO and jitter-sensitive via GEO. * SCNE has an ideal global routing protocol that results in similar behavior as the routing protocol proposed in [47]; the only difference is that, in the beginning, the control messages delivering the computed routes are not modeled in SCNE. Additionally, the mobility management is ideal in SCNE; more reality could be added by modeling the real control messages for it. * The expected benefits of the GEO and LEO layers were present in the simulation results: GEO provided a smaller jitter than LEO, while LEO provided a shorter delay. LEO can serve also polar areas. The results from our own measurements over the OneWeb LEO satellite constellation and the Viasat GEO satellite provide similar findings. However, additional delays are introduced in practical systems due to non-ideal routing mechanisms. * The packet loss was a little bit higher in LEO due to access gaps during LEO-LEO handovers. In SCNE, the handover is seamless (zero delays in switching between satellites) but not lossless. Packets already on the air will be missed if the destination makes a handover at the same time. * The link cost metric in MLSS should not be the number of hops. Or, at least, the GEO hop should have a much higher cost than LEO hops since the distance and delay in GEO is about 36 times greater than that in LEO. Further, the link cost metric could also consider the buffer status to avoid congestion.