Measuring the OneWeb satellite network

Generated with AI.

The emergence of Low Earth Orbit (LEO) satellite networks has revolutionized global connectivity by delivering low-latency, high-throughput Internet access to remote, rural, and underserved regions, connecting some of the most isolated areas in the world.

While Eutelsat's OneWeb operates the second-largest commercial LEO satellite network, its real-world network performance remains largely unexplored by researchers, due to its targeted enterprise and government markets. In this study, we conduct a comprehensive analysis of the OneWeb network, using both the 'inside-out' measurements from controlled user terminals (UTs) in North America and 'outside-in' measurements targeting publicly accessible OneWeb UTs on the Internet.

This blog post highlights the key findings of our paper published in the Network Traffic Measurement and Analysis Conference 2025 (TMA'25):

Overview of the OneWeb satellite network

As the second-largest commercial LEO satellite constellation, OneWeb differs significantly from Starlink in several key aspects. Figure 1 illustrates both the Starlink and OneWeb satellite constellations. As of August 2025, Starlink operates over 8,000 satellites, most of which are positioned in orbits at an altitude of 550km with a 53° inclination. A smaller number of satellites are placed at inclinations of 70° or 97.6° to serve high-latitude regions.

In contrast, OneWeb operates around 650 satellites, at an altitude of 1,200km, distributed across 12 near-polar orbital planes with an inclination of 87.9°. Consequently, this configuration provides the densest satellite coverage in polar regions, whereas coverage becomes sparser near the equator.

As of August 2025, OneWeb's ground infrastructure consists of 29 Points-of-Presence (PoPs) and 40 SNPs worldwide, as illustrated in Figure 2. Note that we only consider OneWeb PoPs listed under the PeeringDB ASN800 interconnection facilities. Another PoP in Almaty, Kazakhstan, was reportedly established but is not listed on PeeringDB as of August 2025. Due to the lack of ISLs, additional SNPs must be constructed to cover remote service regions, such as in French Polynesia, Fiji, Mauritius, and Saint Helena.

OneWeb latency and satellite handover behaviour

When network packets are transmitted from the UT to a satellite, the satellite selects a landing SNP based on its beam coverage. The network packets then travel through terrestrial fibre networks to the associated home-PoP before reaching the Internet.

Our OneWeb UT in the Midwestern USA is associated with the OneWeb PoP in Ashburn. This strategic location positions our UT roughly in the middle between the Santa Paula SNP in the west and the Southbury SNP in the east. We approximate the round-trip time (RTT) over the ground fibre from the west coast to the Ashburn PoP to be around 50 to 60ms, using public Internet probes on the RIPE Atlas platform.

A key finding of our study reveals that the absence of ISLs introduces significant challenges for OneWeb to maintain seamless latency transition between satellite handover events, a direct consequence of switching between sparsely distributed SNPs.

Specifically, we identified and characterized three types of handovers that may trigger SNP handover events:

1. Inter-orbital plane, inter-satellite handover
2. Intra-orbital plane, inter-satellite handover
3. Intra-satellite, inter-beam handover

Figure 3 provides an example of the inter-orbital plane, inter-satellite SNP handover behaviour.

At approximately 02:36:52 (UTC) on December 6 2024, the UT's connected OneWeb satellite switched from ONEWEB-0227 to ONEWEB-0321. We can see that this reduced the latency (minRTT) from around 100ms to 50ms.

Figure 4 shows the relative locations of the UT and other entities at the time of the measurements. Before the handover event, ONEWEB-0227 selected the Santa Paula SNP in the west. This means that the packets traversed through the terrestrial fibre networks more than halfway across the continental US, introducing an additional 50 to 60ms RTT. After the handover event, ONEWEB-0321 selected the Southbury SNP in the east, consequently reducing the minRTT by nearly half.

Zooming out to a longer duration, Figure 5 reveals a 24-hour latency heatmap, highlighting the periodic and predictable pattern of SNP handover events. Although the phase of the bimodal latency pattern shifts slightly each hour due to the Earth's rotation affecting satellite orbital planes, this regularity suggests the potential of using Machine Learning algorithms to predict network performance and optimize transport and application layer performances.

OneWeb throughput performance

To measure the OneWeb throughput performance, we use a single iPerf3 TCP/UDP flow with different congestion control algorithms, targeting a virtual machine co-located near the OneWeb Ashburn PoP. We repeat each iPerf3 test with a 60-second duration at three-hour intervals across a five-day period. The session duration and repeat interval are selected as a balance between data diversity and the limited 100GB monthly data allowance, after which the throughput is throttled to 1Mbps.

As illustrated in Figure 6, while OneWeb generally fulfils the throughput guarantee, the exact performance is dependent on different transport layer protocols and congestion control algorithms. It can sustain a UDP stream at the target bitrate. In contrast, the TCP performance varies depending on the specific congestion control algorithms employed, with BBR showing the best result among others.

For more details about this work, check out our research paper published in the IEEE/IFIP TMA'25 proceedings. You can also find the dataset and tools on GitHub, and more related works on LEO network research from our lab at UVic.

Jinwei Zhao is a second-year PhD student at the University of Victoria, Canada, who focuses on measuring the performance of LEO networks such as Starlink and OneWeb, and application performance such as adaptive video streaming.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.