Empirical Analysis of Heterogeneous Multi-Orbit Satellite Networks for Communication Resilience in Island Regions

Abstract

Integrating Geostationary (GEO), Medium Earth Orbit (MEO), and Low Earth Orbit (LEO) satellite systems offers a promising solution for enhancing communication resilience in disaster-prone island regions. However, effective integration via Software-Defined Wide Area Networks (SD-WANs) faces challenges due to the heterogeneous stochastic characteristics of these links. This study presents a comprehensive performance benchmark of GEO, MEO, and LEO satellite links based on long-duration empirical campaigns conducted in Taiwan. Our findings quantify critical integration hurdles, specifically the “long-tail” latency distribution in LEO links induced by frequent handovers and significant TCP throughput degradation modeled by the Mathis equation. Furthermore, empirical tests demonstrate that simplistic link aggregation across these heterogeneous orbits results in severe packet reordering and goodput collapse. Based on these results, we propose a conceptual resilience-oriented SD-WAN architecture incorporating intelligent failover thresholds and application-aware routing policies. This work provides foundational data and a design framework to guide the future development of robust multi-layered satellite communication systems for disaster management.

1. Introduction

For island nations surrounded by water, communication lifelines are exceptionally vulnerable. In the event of large-scale natural disasters or man-made incidents that disrupt submarine cables, maintaining both domestic and international connectivity becomes a paramount challenge [1]. Multi-orbit satellite communications, leveraging Geostationary (GEO), Medium Earth Orbit (MEO), and Low Earth Orbit (LEO) constellations, offer a versatile solution. However, effectively harnessing these disparate resources is a complex task.

Specifically, the complexity arises from the fundamental heterogeneity in physical link characteristics and the resultant transport-layer anomalies. Integrating GEO, MEO, and LEO links involves bridging RTTs that span from 500 ms to under 50 ms. These disparities disrupt standard TCP Retransmission Timeout (RTO) estimation and induce severe packet reordering [2,3]. Furthermore, the stochastic nature of LEO links, characterized by frequent handovers and terrestrial routing shifts, introduces ‘bursty’ jitter and packet loss distinct from the relatively static error profiles of GEO systems [4,5]. Naive aggregation of such diverse links typically leads to Head-of-Line (HoL) blocking at the receiver’s reordering buffer, causing goodput collapse even when aggregate physical bandwidth is sufficient [6]. Therefore, the scheduling algorithm must solve a non-convex optimization problem by balancing throughput maximization against latency constraints and jitter mitigation.

The objective of this research is not to present a fully realized, integrated system, but rather to perform the critical foundational analysis required before such a system can be successfully designed and deployed. While the potential of SD-WANs to manage multiple links is acknowledged [7], a significant knowledge gap exists regarding the quantitative performance and specific challenges associated with integrating satellite links that have vastly different characteristics. Without this foundational data, any attempt at integration risks being inefficient or even counterproductive.

This paper addresses this gap by:

1.

Conducting long-duration, empirical performance benchmarking of GEO, MEO, and LEO satellite links to establish a reliable performance baseline.

2.

Quantifying the key technical challenges, such as latency instability and TCP throughput degradation, that any integration strategy must overcome.

3.

Proposing a conceptual system architecture and a set of SD-WAN policy design considerations derived directly from our empirical findings.

By providing this foundational analysis, we aim to equip network architects and emergency response planners with the data-driven insights needed to design and build effective and resilient multi-orbit satellite communication systems.

2. Communication Resilience Challenges in Island Nations

For overseas communication, island nations primarily rely on submarine cables. Submarine cables offer stability and high bandwidth characteristics; however, they can be interrupted due to natural disasters or human factors, resulting in a loss of external communication. Inter-island communication typically depends on submarine cables, microwave links, or limited satellite bandwidth. Internal communication, conversely, primarily relies on fixed networks, a limited number of microwave links, and mobile networks, with mobile networks still requiring fixed network infrastructure for backhaul [8,9].

In recent years, the intensification of global climate change and plate movement has led to frequent natural disasters, including typhoons and earthquakes, exacerbating the communication challenges faced by island nations such as the Philippines, Indonesia, Taiwan, Palau, Tonga, and Okinawa. The January 2022 volcanic eruption on the seafloor near Hunga Tonga-Hunga Ha’apai island damaged Tonga’s submarine cable, resulting in a complete disruption of Tonga’s domestic and international phone and internet communications and delaying full restoration for weeks [10]. Taiwan’s 2009 Typhoon Morakot, also known as the August 8th Flood, brought torrential rainfall that damaged communication infrastructure across numerous townships and villages in southern Taiwan. In Xiaolin Village, massive landslides buried the entire community, resulting in a complete loss of communication and preventing rescue units from gaining real-time situational awareness [11]. In 2015, Typhoon Soudelor caused communication outages in New Taipei City’s Wulai District [12] and severed external communication for the Heliu community in Taoyuan City’s Fuxing District [13]. The 2011 Great East Japan Earthquake caused widespread damage and disruption to communication facilities. The earthquake and tsunami destroyed telecommunication buildings and equipment, affecting approximately 1.5 million fixed-line circuits [14].

Following major disasters, communication disruption severely impedes the transmission of disaster relief information, hindering precise decision-making and resource allocation by external rescue efforts. Satellites offer several advantages, including being unaffected by geographical constraints, providing good mobility, and being flexible and quick to install. These capabilities enable quick deployment to required locations during emergencies to provide communication services, thereby facilitating timely disaster relief and coordination efforts for government and civilian entities, making them an optimal choice [15]. With the advancements in disaster rescue technologies and satellite communications, traditional voice-based command systems have become increasingly insufficient in large-scale disaster zones. To perform rapid assessments or overcome damaged transportation infrastructure, rescue units deploy drones to capture real-time images of affected areas. However, to ensure operational continuity under adverse conditions such as heavy fog or smoke where optical sensors fail, future architectures are envisioned to augment this with wireless-based sensing. Following the principles of Integrated Sensing and Communication (ISAC), Channel State Information (CSI) can be used to reconstruct environment images through ray tracing [16]. By fusing these radio-frequency images with real-time visual feeds, the system achieves superior resilience, allowing rescue units to maintain a clear operational picture. These data streams are transmitted via LEO satellite broadband to the disaster response command center, where experts or AI systems can quickly analyze the situation and formulate response strategies. For example, following the April 2024 Hualien earthquake in Taiwan, the strongest earthquake in nearly 25 years, roads leading to the damaged Shakadang Trail were severely impacted, with ongoing aftershocks and landslides preventing personnel from entering. Special search and rescue teams immediately deployed drones to capture aerial footage of the disaster zone, assess damage, and determine the potential presence of survivors to plan rescue operations. Because mobile communication was interrupted, using LEO satellites in the Tianxiang area allowed special search and rescue teams to transmit drone-captured footage from heavily affected areas back to the forward command post via the local LEO satellite user terminal during initial rescue operations, significantly enhancing efficiency and compensating for the limitations of satellite phones, which only support voice communication. At the same time, LEO satellites enabled over 300 stranded individuals at the Silks Place Taroko hotel, located Taroko National Park, to access the internet and communicate with the outside world [17].

3. Multi-Orbit Satellite Technology Overview

Communication satellites operate in various orbits, including GEO, MEO, and LEO. Satellites in different orbits possess distinct technical characteristics that require specific consideration in deployment planning. To elucidate the integration challenges addressed in this study, the overall system architecture and the specific link characteristics are illustrated in Figure 1.

As shown in Figure 1, the system architecture comprises a transmitting end (Island UT/SD-WAN) and a receiving end (Remote Server). The transmitter executes a traffic distribution policy $\mathsf{\Phi }=\{{\varphi }_{geo},{\varphi }_{meo},{\varphi }_{leo}\}$ to dynamically allocate data flows across three heterogeneous satellite links: Low Earth Orbit (LEO, OneWeb), Medium Earth Orbit (MEO, SES), and Geostationary Earth Orbit (GEO, ST-2). The receiver is equipped with a Packet Reordering Buffer to handle out-of-order packets caused by significant latency differences before final traffic aggregation.

Figure 1 further details the distinct theoretical throughput limitations of each orbit. The LEO link exhibits the lowest Round-Trip Time (${\tau }_{leo}$) but suffers from higher packet loss probability ($p_{leo}$) due to handover dynamics, where TCP throughput follows $T_{leo}\propto 1/\left({\tau }_{leo}\sqrt{p_{leo}}\right)$. The MEO link offers medium latency (${\tau }_{meo}$) with consistent packet loss characteristics ($p_{meo}\approx Constant$), where throughput is similarly constrained by the loss-dependent congestion window, following $T_{meo}\propto 1/\left({\tau }_{meo}\sqrt{p_{meo}}\right)$. Conversely, the GEO link provides negligible packet loss ($p_{geo}\to 0$) but high latency (${\tau }_{geo}$), resulting in RTT-limited throughput ($T_{geo}\propto 1/{\tau }_{geo}$).

The right side of Figure 1 highlights the critical challenge: since ${\tau }_{geo}\gg {\tau }_{meo}>{\tau }_{leo}$, multipath transmission inevitably induces packet reordering. The total effective throughput is calculated as $T_{total}=\sum T_i·(1-P_{err})$, representing the net aggregation after accounting for the composite error rate.

A comparative summary of these orbital characteristics is provided in

Table 1. Comparative Analysis of GEO, MEO, and LEO System Architectures.

Parameter	GEO (ST-2)	MEO (SES O3b mPOWER)	LEO (OneWeb) [18]
Satellite Orbit Altitude (km)	35,786 [15]	8063 [19]	1200
Number of Orbits	1	1	12
Satellites per Orbit	1	13 (Total Planned) [20]	49
Beam Coverage	Wide (Regional) [21]	Flexible beam sizes	1667 × 65 km
Beam Capacity	N/A (Transponder-based)	Dynamic ratio *	400/80 Mbps
(Forward/Return)		(Up to 10 Gbps per link) [22]
User Link Frequency	10.95–12.75/14.0–14.5	17.7–20.2/27.5–30.0	10.7–12.7/14.0–14.5
(DL/UL) (GHz)

* Total beam throughput is dynamically allocated. Forward-to-Return ratios (e.g., 1:1, 3:1, 1:3) are flexible [23].

. The parameters listed are derived from the specific commercial platforms analyzed in this study: ST-2 for GEO, SES O3b mPOWER for MEO, and OneWeb for LEO. These specifications are compiled from operator technical disclosures and ITU filings.

3.1. GEO Satellites

GEO satellites operate in a circular orbit 35,786 km above the Earth’s equator and appear relatively fixed in the sky to ground users due to their synchronous movement with the Earth’s rotation [15]. GEO ground antennas must be directed towards a particular azimuth angle to align with the satellite. A single GEO satellite provides a large coverage area, making it suitable for point-to-point communications, including domestic and inter-island links. Taiwan currently utilizes the ST-2 satellite [24], and VSAT (Very Small Aperture Terminal) systems can also be established to enhance the efficiency of these communications [15], as shown in Figure 2. GEO satellites are commonly used for television relay, broadcasting, and communication.

However, their greater distance from Earth demands higher transmission power and larger antennas, making terminals less portable while increasing latency and bandwidth costs [25]. Despite these trade-offs, GEO satellites offer superior reliability in challenging environments. Unlike LEO constellations where satellite visibility varies, GEO satellites maintain a fixed orbital position. In tropical and sub-tropical regions, this ensures a consistently high elevation angle, making the link less susceptible to intermittent blockage from terrain like canyons or valleys [26]. Consequently, as long as a clear line of sight is established, GEO systems can provide highly dependable communication services.

3.2. MEO Satellites

SES currently operates the only global commercial communication satellites in MEO, that is, 8063 km from the Earth’s surface, providing stable data connectivity [19]. SES maintains a worldwide network of ground stations. When submarine cable communication is disrupted, SES can land local traffic directly at overseas ground stations and Points of Presence (PoPs), serving as a vital conduit for international communication. The SES MEO satellite network architecture is illustrated in Figure 3. Furthermore, the inherent stability of SES communication makes it suitable as a backup network for domestic communications, functioning effectively as mobile network backhaul or providing redundancy for core network infrastructure [27].

The SES constellation operates through two main segments: the terrestrial network and the space-based satellites. Through the terrestrial network, operators can remotely monitor and control the O3b mPOWER gateway equipment deployed on the ground. The SES Adaptive Resource Control (ARC) system, developed specifically for the next-generation O3b mPOWER Medium Earth Orbit (MEO) constellation, is the core software platform that dynamically manages and optimizes both satellite and ground resources [19]. To ensure real-time communication and control, SES uses a dedicated MPLS line, illustrated by the dashed line in Figure 3 to ensure seamless coordination and immediate operations between the satellites and ground equipment [27].

MEO systems, composed of non-synchronous satellite constellations, are designed with multiple satellites to provide redundancy, thus exhibiting high network resilience. MEO satellite reception features a moderate elevation angle. Currently, SES MEO services are available in Taiwan [28].

3.3. LEO Satellites

Low Earth Orbit (LEO) non-geostationary satellites operate at altitudes below 2000 km from the Earth’s surface. Most Starlink satellites are positioned at approximately 550 km, while OneWeb satellites operate at around 1200 km. And Amazon’s Kuiper system is at altitudes ranging from 590 to 630 km [29].

OneWeb has officially launched services in Taiwan. The constellation consists of 12 orbital planes containing 49 satellites each. Each satellite projects 16 beams covering areas of 1600 km × 65 km. The system operates in the 10.7–12.7 GHz range for downlink and 14.0–14.5 GHz for uplink communications. Transmission latency will be comparatively longer for island nations without locally deployed SNPs and relying instead on overseas SNPs for landing services [18].

OneWeb’s network architecture connects user terminals (UTs) to satellites through dedicated links, while satellites communicate with ground infrastructure via strategically located SNPs. The terrestrial segment employs MPLS technology and international Points of Presence to offer two service types: direct satellite-to-ground connections (OneWeb Site Connectivity) and integration with existing customer networks (OneWeb Interconnect). This network architecture is illustrated in Figure 4.

Due to their proximity to Earth, LEO satellites offer advantages such as low latency, high bandwidth, and relatively lower costs. These features make them well-suited for internet-related services like video conferencing, web browsing, large data transfers, and real-time applications. LEO terminal equipment is compact, lightweight, and energy efficient. It can be powered by portable power banks and easily transported using standard vehicles, allowing for rapid on-site deployment and immediate satellite broadband connectivity. The system can deliver continuous broadband service over extended durations with a small diesel generator. In a submarine cable outage, many UTs can be deployed to establish communication links with international networks, serving as critical channels for connecting to the overseas internet.

However, because of the satellites’ low altitude, the satellite reception elevation angle is small, necessitating terminal equipment deployment in relatively open areas and, thereby, imposing higher environmental constraints.

4. Foundational Performance Benchmarking

To inform the design of an integrated system, a comprehensive understanding of each constituent link’s baseline performance is essential. We conducted long-duration, intensive testing to compare the performance of the ST-2 GEO satellite, the SES MEO satellite, and the OneWeb LEO satellite.

4.1. Test Methodology

The testbed for this study utilized the FortiGate-61F appliance, which natively supports SD-WAN functionality with five types of priority rules: Source IP, Sessions, Spillover, Source–Destination IP, and Volume. However, due to the limited controllability of FortiGate’s built-in priority rule execution, we adopted a manual approach to ensure that the test traffic followed the intended routing paths for experimental accuracy. The conceptual layout of this testbed is depicted in Figure 5.

1.

Source IP: Traffic is divided equally between SD-WAN members. Sessions that start at the same source address use the same route.

2.

Sessions: The traffic is distributed based on the number of sessions that are connected through the member.

3.

Spillover: The highest priority member is used until bandwidth exceeds ingress and egress thresholds. Additional traffic is sent through the next SD-WAN member.

4.

Source-Destination IP: Traffic is divided equally. Sessions that start at the same source IP address and go to the same destination IP address use the same route.

5.

Volume: The workload is distributed based on the number of packets that are going through the member.

For iPerf testing, SD-WAN rules were manually configured to force packets with specific destination ports to traverse designated WAN interfaces. For example, traffic with destination port 5300 was prioritized to use the LEO interface, followed by MEO and then GEO; port 5301 prioritized MEO, then LEO, then GEO; and port 5302 prioritized GEO, then LEO, then MEO. As illustrated in Figure 5, the physical topology connects each satellite UT to a dedicated WAN interface (WAN1-3) on the SD-WAN appliance. This physical isolation allows for precise per-port monitoring and policy enforcement.

For Speedtest measurements, routing was controlled by source IP. Specific source IP addresses were mapped to preferred interfaces: Source IP 1 prioritized LEO, then MEO, then GEO; Source IP 2 prioritized MEO, then LEO, then GEO; and Source IP 3 prioritized GEO, then LEO, then MEO.

The tests were conducted over multiple days to capture a wide range of operational conditions. We utilized Ookla’s Speedtest (Server ID 18445) for general performance metrics and a self-hosted iPerf3 server for protocol-specific analysis. To establish a representative baseline for standard commercial deployments, the Linux-based test client employed the default CUBIC congestion control algorithm. While newer algorithms like BBR are known to perform better in high-latency environments, CUBIC remains the default in most commercial operating systems and was chosen to represent a “worst-case” scenario for COTS equipment. No kernel-level TCP optimizations or Performance Enhancing Proxies (PEP) were applied, ensuring the results reflect the performance of typical Commercial Off-The-Shelf (COTS) equipment. The satellite service plans were configured with the following downlink/uplink rates: GEO at 10/10 Mbps, LEO at 100/20 Mbps, and MEO at 50/20 Mbps. Outliers were filtered from the test results using the 1.5× IQR rule to ensure data integrity. It should be noted that the testing period (12–23 April 2025) was predominantly characterized by clear to cloudy weather. Analysis of the filtered outliers revealed a strong correlation with intermittent rainfall events, consistent with known Ka/Ku-band rain fade characteristics.

4.2. Empirical Results and Analysis

To establish a reliable performance baseline, we first individually measured the performance of each satellite link. The test results, presented as Cumulative Distribution Functions (CDFs) in Figure 6 and detailed in Table 2, reveal critical performance characteristics that directly impact the integration strategy.

• Latency Distribution Analysis: As expected, the GEO link exhibited extreme stability. Its CDF curve is nearly vertical, indicating that the vast majority of packets arrive within a negligible deviation from the median of 515.98 ms. In contrast, the LEO latency distribution exhibits a much shallower slope and a distinct “long tail.” While the median LEO latency is lower at 203.58 ms, the gradual rise of the curve confirms significant variability, with the 99th percentile ($P_{99}$) extending to 303.88 ms. This volatility is a critical design constraint.

Latency fluctuations within the OneWeb LEO constellation are primarily attributed to frequent handover mechanisms, including intra-plane and inter-plane (beam-to-beam) handovers and SNP handovers. Notably, the handover between SNPs constitutes the predominant factor inducing significant latency variations. This is not merely due to changes in the slant range between the satellite and the SNP; the impact is exacerbated in regions lacking local SNP deployment, such as Taiwan. In such scenarios, an SNP handover necessitates a reconfiguration of the terrestrial backhaul path. As the connection shifts to a different SNP, the routing trajectory—from the new SNP through the PoP back to Taiwan—is altered, thereby driving substantial variations in latency.

In addition to satellite-related factors, the latency of non-geostationary satellite systems is also closely tied to the design of the terrestrial network. There is no OneWeb SNP in Taiwan. OneWeb maintains two Points of Presence (PoPs) located in Northeast Asia (Japan) and Southeast Asia (Singapore), configured in a redundant active-standby architecture to ensure end-to-end service availability and resiliency. All OneWeb traffic destined for Taiwan is routed through these PoPs before being transported to the domestic network. For Taiwan service, the path is: Taiwan→LEO Satellite → SNP (e.g., Thailand, Guam, or Japan) → PoP (e.g., Singapore) → International Submarine Cable → Test Server (Taipei).

As shown in Figure 7, we observed the OneWeb service’s PoP for the test User Terminal change from Japan to Singapore. This terrestrial routing change led to a significant drop in latency, dropping the median round-trip latency from 259.85 ms (via the Japan PoP) to 155.97 ms (via the Singapore PoP), as detailed in Table 3. Additionally, the differences between the LEO latency test results in Table 2 and Table 3 are due to the use of MTR and Speedtest, respectively, which measured latency to different destination IPs. Due to the commercial COTS setup, precise orbital ephemeris data was unavailable to correlate exact timestamps with specific satellite IDs. However, the observed latency shifts (approx. 100 ms) correlate strongly with terrestrial routing path changes (SNP switching) rather than beam handovers. Throughout OneWeb’s service period in Taiwan, approximately 60–65% of satellite traffic has been routed through the Thailand SNP, while Japan handles 5–10% and Guam accounts for roughly 30%. Since the Thailand SNP handles the majority of Taiwan’s satellite traffic and is geographically closer to Singapore, routing through the Singapore PoP significantly reduces latency for services back to Taiwan.

This highlights a crucial finding: for island nations, the choice of PoP location and the presence of a local SNP are dominant factors.OneWeb has set up an SNP in Queensland, Australia, and using Speedtest measurements taken there show a latency of 75 ms. From these results, it is evident that establishing an SNP is critical for latency. For island nations, when deploying a dedicated local SNP, it is essential to evaluate whether the local traffic volume is sufficient to justify the high construction costs. If the service provider decides not to establish a dedicated local SNP, it must utilize overseas SNPs. In such cases, we should ideally place PoP locations near the SNP that handles primary satellite traffic to minimize latency.The terrestrial routing differences for all three orbits are visualized in Figure 8.

MEO latency was measured at a median of 428.68 ms. Its CDF curve is similarly positioned to the right due to its own non-local terrestrial path: Taiwan → MEO Satellite → Ground Station (Perth, Australia) → SES PoP (Australia) → International Submarine Cable → Test Server (Taipei). Therefore, any SD-WAN policy must not rely on a static latency value for LEO; it requires real-time, continuous monitoring to adapt to these significant, policy-driven shifts in terrestrial routing.

• Jitter Analysis: The steep, step-like nature of the GEO and MEO CDFs demonstrates low and stable jitter, with 99th percentile ($P_{99}$) values remaining below 1.04 ms. In contrast, LEO exhibited a much more gradual slope and significant tail instability, where jitter spiked to 52.38 ms at the 99th percentile—a sharp increase from its median of 10.13 ms. This finding suggests that without proper mitigation (e.g., jitter buffers configured by the SD-WAN), LEO links may be unsuitable for high-quality real-time voice and video streams, even with their high bandwidth.
• Bandwidth Stability: While all links generally met their provisioned bandwidth, the LEO throughput CDF showed considerable variability in the lower percentiles, occasionally dropping below 60/5 Mbps. This underscores the need for an SD-WAN policy that can dynamically shift traffic if the primary LEO link’s performance degrades temporarily.

Figure 8. Visualization of Multi-Orbit Terrestrial Backhaul Paths for Taiwan. Both LEO and MEO links rely on overseas ground stations (SNPs) and PoPs, introducing significant terrestrial latency, whereas the GEO ST-2 link utilizes an in-country VSAT Hub.

Figure 8. Visualization of Multi-Orbit Terrestrial Backhaul Paths for Taiwan. Both LEO and MEO links rely on overseas ground stations (SNPs) and PoPs, introducing significant terrestrial latency, whereas the GEO ST-2 link utilizes an in-country VSAT Hub.

Table 2. Baseline Performance and Stability Matrix (Derived from Individual Link Testing).

Metric	GEO (ST-2)	MEO (SES)	LEO (OneWeb)	Unit
Service Plan
Provisioned Bandwidth (DL/UL)	10/10	50/20	100/20	Mbps
Latency & Stability (from Speedtest)
Median Latency ($P_{50}$)	515.98	428.68	203.58	ms
95th Percentile Latency ($P_{95}$)	516.01	443.49	299.75	ms
Peak Latency ($P_{99}$)	516.04	443.52	303.88	ms
Median Jitter ($P_{50}$)	0.06	1.12	10.13	ms
95th Percentile Jitter ($P_{95}$)	0.06	1.53	40.81	ms
Peak Jitter ($P_{99}$)	1.04	2.57	52.38	ms
Downlink Throughput (from iPerf3)
Median TCP Throughput ($P_{50}$)	3.67	10.70	33.95	Mbps
Median UDP Throughput ($P_{50}$)	10.00	46.30	100.00	Mbps
TCP Efficiency (TCP Throughput/Provisioned BW)	36.7	21.4	33.9	%
Packet Loss (from iPerf3 UDP Test)
Average Download Packet Loss Rate	0.04	8.16	5.24	%
Average Upload Packet Loss Rate	0.09	13.29	10.55	%

Note: Data represents baseline performance measured individually. See Figure 9 for aggregated performance metrics. The LEO measurements in this baseline table were conducted via the Japan PoP routing path. See Table 3 for a comparison with the Singapore path.

Table 2. Baseline Performance and Stability Matrix (Derived from Individual Link Testing).

Metric	GEO (ST-2)	MEO (SES)	LEO (OneWeb)	Unit
Service Plan
Provisioned Bandwidth (DL/UL)	10/10	50/20	100/20	Mbps
Latency & Stability (from Speedtest)
Median Latency ($P_{50}$)	515.98	428.68	203.58	ms
95th Percentile Latency ($P_{95}$)	516.01	443.49	299.75	ms
Peak Latency ($P_{99}$)	516.04	443.52	303.88	ms
Median Jitter ($P_{50}$)	0.06	1.12	10.13	ms
95th Percentile Jitter ($P_{95}$)	0.06	1.53	40.81	ms
Peak Jitter ($P_{99}$)	1.04	2.57	52.38	ms
Downlink Throughput (from iPerf3)
Median TCP Throughput ($P_{50}$)	3.67	10.70	33.95	Mbps
Median UDP Throughput ($P_{50}$)	10.00	46.30	100.00	Mbps
TCP Efficiency (TCP Throughput/Provisioned BW)	36.7	21.4	33.9	%
Packet Loss (from iPerf3 UDP Test)
Average Download Packet Loss Rate	0.04	8.16	5.24	%
Average Upload Packet Loss Rate	0.09	13.29	10.55	%

Note: Data represents baseline performance measured individually. See Figure 9 for aggregated performance metrics. The LEO measurements in this baseline table were conducted via the Japan PoP routing path. See Table 3 for a comparison with the Singapore path.

Figure 9. Aggregation performance: Cumulative Distribution Functions (CDF) of Multi-Session Aggregated SD-WAN Upload/Download Throughput and Concurrent Latency Under Simultaneous GEO, MEO and LEO Links.

Figure 9. Aggregation performance: Cumulative Distribution Functions (CDF) of Multi-Session Aggregated SD-WAN Upload/Download Throughput and Concurrent Latency Under Simultaneous GEO, MEO and LEO Links.

Table 3. Impact of Terrestrial PoP Routing on LEO Latency Distribution.

CDF Metric	LEO (via Japan PoP)	LEO (via Singapore PoP)	Latency Reduction ($\mathsf{\Delta }$)
Median Latency ($P_{50}$)	259.85 ms	155.97 ms	103.88 ms
Tail Latency ($P_{95}$)	359.33 ms	262.80 ms	96.53 ms

Table 3. Impact of Terrestrial PoP Routing on LEO Latency Distribution.

CDF Metric	LEO (via Japan PoP)	LEO (via Singapore PoP)	Latency Reduction ($\mathsf{\Delta }$)
Median Latency ($P_{50}$)	259.85 ms	155.97 ms	103.88 ms
Tail Latency ($P_{95}$)	359.33 ms	262.80 ms	96.53 ms

4.3. Theoretical Analysis of TCP Throughput Degradation

To theoretically validate our empirical observations regarding TCP performance drops over LEO and GEO links, we employ the macroscopic model of TCP throughput, which is widely known as the Mathis equation [30]. The steady-state throughput T of a TCP connection can be approximated as:

$$T\approx {\displaystyle \frac{MSS}{RTT·\sqrt{p}}}·C$$

(1)

where $MSS$ represents the Maximum Segment Size, $RTT$ is the Round-Trip Time, p is the packet loss rate, and C is a constant (typically $\sqrt{3/2}$).

Our empirical data reveals the distinct bottlenecks for each orbit:

• GEO scenario: While p is negligible ($p\to 0$), the dominant factor is the large $RTT$ (≈516 ms). As $T\propto 1/RTT$, the theoretical throughput is inherently capped regardless of available bandwidth.
• MEO scenario: The empirical results for MEO present a unique case validating the Mathis model. Although MEO latency (≈428 ms) is lower than GEO, the measured packet loss rate p was high (≈8%). According to Equation (1), TCP throughput is inversely proportional to $\sqrt{p}$. This substantial loss factor p severely penalized the TCP throughput, resulting in the lowest TCP efficiency (21.4%) among all three orbits as observed in Table 2. This confirms that even with stable latency, non-negligible packet loss is detrimental to standard TCP streams.
• LEO scenario: Although $RTT$ is significantly lower (≈200 ms), our measurements indicate a fluctuating packet loss rate p (average 5.24%) due to handover dynamics and terrestrial routing variations. Since $T\propto 1/\sqrt{p}$, even minor spikes in packet loss cause the TCP congestion window to collapse aggressively. This collapse is intrinsic to loss-based algorithms like CUBIC, which misinterpret the stochastic packet loss characteristic of LEO handovers as a signal of network congestion. Consequently, the algorithm aggressively reduces the transmission rate in accordance with the Mathis model, failing to utilize the full link capacity.

This theoretical relationship correlates with our iPerf3 results (see Figure 10 on page 13), confirming that naive integration without TCP acceleration PEP or loss-based path selection yields suboptimal spectral efficiency.

5. Proposed Architecture for Multi-Orbit Integration

Based on the foundational data, it is clear that simply connecting multiple satellite links to an SD-WAN device is insufficient. A carefully designed architecture and intelligent policies are required.

5.1. Conceptual System Architecture

We propose the conceptual architecture shown in Figure 5. In this model, all satellite UTs connect to a central SD-WAN appliance. The SD-WAN controller, a key component, continuously monitors the health of each satellite link (measuring latency, jitter, packet loss). It uses this real-time data to execute predefined routing policies, managing traffic flow between the end-user devices and the remote network. This centralized intelligence refers to session-level steering based on real-time link health thresholds, rather than packet-level scheduling. It is important to note that the processing overhead introduced by the SD-WAN controller is typically in the microsecond range (<1 ms). Given that satellite link latencies range from 50 ms to 500 ms, this additional processing delay is negligible and does not impact the overall system performance. While this approach effectively segregates flows to avoid reordering penalties, the development of custom transport-layer proxies to actively resolve TCP CUBIC inefficiencies is reserved for future extended studies.

5.2. Challenges in Simplistic Link Aggregation

One might assume that aggregating the bandwidth of all three links would yield the sum of their capacities. To evaluate this, we activated all links simultaneously on the SD-WAN testbed. Figure 9 shows that the raw aggregated capacity of the three links can reach a peak of 170.43 Mbps when different sessions are specifically arranged on each link. However, if only a single session is evenly distributed across LEO, MEO, and GEO, the aggregated capacity is expected to decrease because the significant latency differences cause packet reordering, which leads the TCP congestion control algorithm to interpret it as packet loss.

As illustrated by the distinct separation in the Latency CDFs in Figure 9, the vast median latency gap between LEO ($P_{50}=202.37$ ms) and GEO ($P_{50}=515.98$ ms) remains fragmented. This means a simple packet-based load balancing strategy would lead to severe out-of-sequence packet arrival at the destination. For TCP-based applications, this triggers unnecessary duplicate acknowledgments and retransmissions, potentially causing the connection’s effective throughput to collapse [6,31]. This finding serves as a critical warning: naive bandwidth aggregation across high-latency-variance links is counterproductive for most applications. The SD-WAN must employ more sophisticated, session-aware, or application-aware routing rather than simple per-packet load balancing.

6. Design Considerations for SD-WAN Integration Policies

The empirical data from Section 4 and the challenges identified in Section 5 directly inform the design of effective SD-WAN policies.

6.1. General SD-WAN Policy Strategies

SD-WAN offers flexible and efficient network connectivity, and its configuration strategies typically fall into two categories: dynamic path selection based on real-time network quality and static routing based on organizational application requirements. The former dynamically allocates traffic according to the current quality of each WAN interface, such as available bandwidth, latency, and packet loss rate, to select the optimal path for new connections. The latter assigns differentiated routing policies to specific applications or IP addresses, ensuring reliability and performance for critical services. In practice, organizations tailor their SD-WAN strategies to their operational needs and application scenarios to maximize network efficiency [7].

In real-world deployments, the performance characteristics of satellite communications differ significantly from those of terrestrial networks. In a multi-orbit satellite environment, SD-WAN policy design must account for these unique attributes. For example, LEO satellites offer the highest bandwidth and lowest latency but tend to have higher packet loss rates, making them suitable for applications such as video conferencing that require high bandwidth and low latency. In contrast, GEO satellites provide lower bandwidth and higher latency, but typically exhibit lower packet loss, making them more appropriate for the reliable delivery of critical text messages.

Therefore, SD-WAN strategies in multi-orbit satellite scenarios should be application-driven, matching the requirement of each application to the most suitable satellite link. It is worth noting that the implementation complexity of such policies scales linearly ($O\left(N\right)$) with the number of satellite orbits involved. While reducing the architecture to only one or two orbits (e.g., LEO and GEO) would simplify the SD-WAN configuration, it would fundamentally limit the system’s ability to balance bulk transfer needs against latency-sensitive and reliability-critical traffic.

6.2. The Critical Role of Protocol-Specific Performance

Our iPerf3 tests (see Figure 10 on page 13) further underscore the need for protocol-aware routing. The results quantify the dramatic performance gap between UDP and TCP over satellite links. The UDP throughput CDF rises steeply near the provisioned bandwidth limit, indicating consistent high performance. In contrast, the TCP curve exhibits a significantly shallower slope and is shifted to the left. This visualizes how TCP throughput is significantly lower and more unstable due to its inherent sensitivity to latency and packet loss [9].

In addition to throughput, the packet loss rate is a crucial metric for evaluating satellite link performance. We conducted UDP packet loss measurements using iPerf, with each test lasting one minute and repeated every ten minutes. The results, as summarized in Figure 11, reveal several important trends:

1.

Loss Magnitude: The packet loss patterns differ significantly. LEO exhibits an average download loss of 5.24%, which is non-trivial but lower than the MEO test link. However, the LEO loss is “bursty” (concentrated in handover intervals), whereas GEO maintains a near-perfect 0.04% average.

2.

MEO Behavior: Our MEO test link showed a higher average loss (8.16% DL/13.29% UL). Unlike LEO, this loss was consistent throughout the test duration (indicated by the steep vertical rise in the CDF), suggesting a constant link constraint rather than dynamic instability. It is important to interpret the MEO packet loss data within the context of our experimental setup. While MEO constellations are theoretically capable of near-zero loss transmission (similar to fiber-in-the-sky), our empirical results in Table 2 recorded an average packet loss of approximately 8–13%. Unlike the stochastic and bursty loss observed in LEO links due to handovers, the MEO loss profile was remarkably consistent (as shown in Figure 11). This suggests that the observed loss is likely attributable to specific rate-limiting policies or congestion at the terrestrial backhaul points rather than orbital dynamics. However, this high constant loss significantly impacts TCP efficiency, providing a critical stress test for the resilience analysis.

3.

Impact: While LEO’s average loss is lower, its variability means TCP congestion controls often trigger aggressively during handover spikes, causing the “sawtooth” throughput performance observed in Figure 10.

For real-time services such as voice and video, packet loss has a lower impact compared to latency and jitter, as these applications are designed to tolerate some degree of loss.

Consequently, GEO links, with their minimal packet loss, are better suited for reliable data transmission, while LEO and MEO links, with their lower latency, are more appropriate for real-time services despite their higher packet loss rates.

Figure 11. Link Reliability: Cumulative Distribution Functions (CDF) of Packet Loss Rates for GEO, MEO, and LEO Links.

Figure 11. Link Reliability: Cumulative Distribution Functions (CDF) of Packet Loss Rates for GEO, MEO, and LEO Links.

This implies that an effective SD-WAN policy should not treat all traffic equally. Forcing TCP-heavy applications (like file transfers or web browsing) across multiple high-latency paths is inefficient. Instead, the system should be designed with specific strategies in mind.

6.3. Strategy 1: Intelligent Failover for High Availability

The primary goal in a disaster scenario is resilience, not maximum speed. An intelligent failover policy is paramount.

• Design: The SD-WAN is configured to utilize the best-performing link (typically LEO) as the primary connection.
• Thresholds: Guided by the empirical performance bounds in Figure 6, failover thresholds (e.g., LEO latency $>300$ ms) are defined to trigger application-aware routing. High-bandwidth streams are offloaded to the MEO link; despite exhibiting a higher average packet loss ($8.16\%$) than LEO, the MEO link sustained a median UDP throughput of $46.30$ Mbps, significantly outperforming GEO. Conversely, critical control signaling is rerouted to the GEO link, prioritizing its quasi-error-free transmission ($0.04\%$ loss) to ensure delivery reliability.
• Benefit: This approach maximizes service continuity by aligning link characteristics with application needs—maintaining throughput for bulk data via MEO while guaranteeing message delivery for critical operations via GEO.

6.4. Strategy 2: Application-Aware Routing for Quality of Service (QoS)

For non-critical scenarios or when multiple links are stable, application-aware routing can optimize user experience.

• Design: The SD-WAN identifies traffic by application type.
• Policies: (1) Real-time Traffic (VoIP, Video Conferencing): Route exclusively over the link with the lowest latency and jitter (typically LEO, provided it is stable). Do not split these sessions across multiple links. (2) Bulk Data Transfer (FTP, Cloud Backup): Route over the link with the highest available bandwidth (MEO or LEO), or consider routing over GEO if other links are congested, as these applications are less sensitive to latency. (3) General Web Browsing (TCP-heavy): Assign to a single, stable link to avoid the TCP out-of-sequence issue.
• Benefit: This approach maximizes the utility of each link’s unique characteristics, ensuring that application performance is aligned with link capabilities.

6.5. Impact of Dense Constellations and Emerging Protocols

Future developments in satellite constellations and transport protocols will further influence integration strategies. Densely deployed LEO constellations (e.g., Starlink) combined with local Points of Presence (PoPs) are expected to reduce the “long-tail” latency observed in our OneWeb tests by minimizing terrestrial backhaul distances. While this improves baseline QoS, the fundamental heterogeneity between GEO and LEO orbits will persist, necessitating the continued use of intelligent routing policies. Furthermore, emerging transport protocols such as QUIC and Multipath TCP (MPTCP) offer mechanisms to mitigate some transport-layer anomalies. QUIC’s stream-based architecture can reduce the impact of Head-of-Line (HoL) blocking compared to standard TCP, while MPTCP allows for dynamic sub-flow management. However, even with these protocols, the extreme latency disparity ($\mathsf{\Delta }\approx 300$ ms) between GEO and LEO links poses a challenge for reordering buffers, reinforcing the need for the application-aware steering strategies proposed in this study.

7. Conclusions and Future Work

This study conducted a foundational performance analysis of GEO, MEO, and LEO satellite links, providing essential, empirically-derived data for designing resilient communication systems in island regions. Our contribution is not a finished product, but the critical groundwork required for one. We have quantified the performance variability of multi-orbit links and demonstrated the significant pitfalls of naive integration strategies, particularly those concerning TCP performance and out-of-sequence packet issues.

Based on these findings, we have proposed a conceptual SD-WAN integration architecture and outlined key design considerations for intelligent routing policies, such as smart failover and application-aware routing. While validated on OneWeb and SES, these architectural principles are orbit-agnostic and extendable to other constellations such as Starlink (LEO) as they become available. These data-driven insights provide a necessary framework for network engineers to move beyond simplistic aggregation toward truly resilient and efficient multi-orbit networks.

The crucial future work is to build upon this foundation. The next phase involves implementing the proposed architecture and policies in a lab environment. This will allow for the validation and refinement of the failover thresholds and application-routing rules discussed herein and the measurement of the precise performance of the integrated system under simulated real-world failure conditions. This will ultimately pave the way for robust field deployments in disaster-prone regions.