A First Look at Starlink Maritime on Cruise Ships

A First Look at Starlink Maritime on Cruise Ships Jinwei Zhao* , Kousar Malekinasab* , Jianping Pan

arXiv:2611.07191v1 [cs.NI] 4 Nov 2026

University of Victoria Victoria, BC, Canada {clarkzjw, kovvy, pan}@uvic.ca

Abstract—Low-Earth-Orbit (LEO) satellite networks are reshaping maritime connectivity, offering much lower latency and higher capacity than traditional geostationary (GEO) links. As a single user terminal (UT) cannot serve hundreds to thousands of passengers, a cruise ship often deploys several UTs behind an onboard multi-WAN router for aggregated capacity and load balancing. Consequently, passenger connectivity depends not only on the satellite links but also on how the router distributes sessions among UTs. In this paper, we measure Starlink maritime connectivity on two cruise ships of different scales, Utopia of the Seas near the Bahamas in December 2025 and Silver Muse in the Adriatic Sea in July 2026, combining UT telemetry, inside-out measurements from a passenger device, and outsidein measurements from cloud servers near Starlink Points of Presence (PoPs). We find that the onboard network, rather than the satellite links, largely determines the passenger experience, as cruise lines rate limit each passenger device. Moreover, the public IP address of a passenger device changes not only at PoP handovers but also within the same PoP. Furthermore, while the country code reported by the UT reflects the maritime jurisdiction of the ship, the serving PoP follows neither this jurisdiction nor geographic proximity alone, suggesting factors beyond the distance-based PoP boundaries observed in Starlink aviation. To the best of our knowledge, this is the first systematic study of Starlink on commercial cruise ships, complementing prior land mobile and in-flight measurements. Index Terms—LEO satellite networks, Starlink, maritime, measurement

I. I NTRODUCTION Low-Earth-Orbit (LEO) satellite networks, such as SpaceX Starlink and Eutelsat OneWeb, have reshaped Internet connectivity at sea [1], [2]. As the leading LEO provider, Starlink is increasingly adopted by cruise lines to replace their geostationary (GEO) links, which suffer from hundreds of milliseconds of latency and a limited capacity shared among hundreds to thousands of passengers on board. To provide sufficient capacity, a cruise ship can choose among three options that differ in scale and dedicated resources. First, it can install a dedicated Starlink Bonded Gateway (previously known as “Community Gateway”), which scales up to 20 Gbps of symmetric throughput with additional antennas [3]. Royal Caribbean, for instance, has deployed one with 10 Gbps on Star of the Seas [4]. However, it requires a group of four or more dedicated parabolic gateway antennas and a Transit Service subscription, with pricing available only on request [5]. Second, Bonded Starlinks groups six or more Starlink Performance user terminals (UTs) under a Dedicated * Both authors contributed equally to this work.

Service subscription, providing up to 2.4 Gbps downlink and 600 Mbps uplink with a dedicated Ku-band beam allocation that reduces contention with other users in the same service cell [5]. Third, and most commonly, a ship deploys multiple off-the-shelf UTs on standard maritime subscriptions behind an onboard multi-WAN router such as Peplink [6], where the UTs may share the capacity of each service cell with other users, especially near the coast and in ports. Starlink maritime connectivity on a cruise ship differs from that of residential, land mobile, and aviation users in both mobility and scale. First, a ship travels for days across territorial seas and international waters, yet moves slower than a land vehicle and far slower than an aircraft, which crosses the boundaries between Starlink Points of Presence (PoPs) within hours. At open sea, a large cruise ship also offers a clear sky and a stable platform, unlike a land vehicle that frequently encounters transient obstructions or an aircraft whose terminals must cope with rapid attitude changes and air turbulence [7], [8]. When berthed, however, a ship may stay for hours next to structures that block part of the sky. Second, a ship shares its UTs among far more users. While a residential or vehicle UT serves a few users and a widebody aircraft serves a few hundred passengers with two aero terminals, a cruise ship often serves hundreds to thousands of passengers through an operator-managed network with per-user rate limits. These differences leave several aspects of Starlink maritime connectivity unexplored. For a ship that sails close to PoP boundaries or stays berthed for hours, it remains unclear how Starlink associates the ship with its PoPs, whether the public IP address of a passenger device remains stable, and whether the 15-second satellite handover, well studied for fixed users, remains the main source of performance degradation at sea. For passengers sharing multiple UTs, it is also unclear to what extent the experience of a passenger is determined by the satellite links rather than by the onboard network. Prior maritime studies measure a single UT near the coast [9]– [11], while in-flight studies cannot access UT telemetry, as the gRPC interface is blocked on aircraft [7], [12]. To address these gaps, we measured two cruise ships of different scales with the same methodology: Utopia of the Seas on a voyage from Port Canaveral, Florida, to the Bahamas in December 2025 (Fig. 1), and Silver Muse for 132 hours during a voyage in the Adriatic Sea in July 2026 (Fig. 2). On each ship, a single passenger device that stayed in a cabin recorded the UT status, GPS location, and outage history through the gRPC interface of the Starlink UT, looked up the

US (United States) XZ (international waters) BS (Bahamas) Territorial sea limit (12 nmi) Starlink PoP (Miami)

28°N

129.222.48.125 (dish a07) 129.222.49.83 (dish 8fa) Other (8 addresses) Territorial sea limit (12 nmi) Starlink PoP (Miami)

27°N

26°N UT switch a07→8fa 12-17 23:37Z (18:37 UTC−5) 25°N

UT switch a07→8fa 12-17 23:37Z (18:37 UTC−5)

(a) Country code

81°W

80°W

(b) Public IPv4 79°W

78°W

77°W Start / end

76°W

81°W

UT switch

80°W

79°W

78°W

77°W

76°W

Data gap > 10 min

Fig. 1: Voyage of Utopia of the Seas, December 16–19, 2025: (a) country code and (b) public IPv4 address.

45°N

(a) Country code

(b) Serving PoP

(c) Public IPv4

44°N

43°N

42°N

41°N 12°E

HR (Croatia) XZ (international waters) IT (Italy) ME (Montenegro) 12 nmi limit

14°E

16°E

Sofia Milan 12 nmi limit PoP handover PoP location

18°E

12°E Start

14°E End

150.228.111.89 (Sofia) 212.105.152.243 (Milan) 209.198.139.203 (Sofia) Other (5 addresses)

16°E

18°E

12°E

14°E

16°E

18°E

Data gap > 10 min

Fig. 2: Voyage of Silver Muse, July 6–12, 2026: (a) country code, (b) serving PoP, and (c) public IPv4 address.

public IP address, and measured the round-trip time (RTT) to the Starlink gateway at the PoP. Meanwhile, cloud servers near the serving PoPs measured the RTT to the public IP address of the UT, providing an independent outside-in view that excludes the onboard Wi-Fi. Our main contributions are as follows. We find that the country code reported by the UT reflects the maritime jurisdiction of the ship, whereas the serving PoP follows neither this jurisdiction nor the distance to the PoPs alone, and can change even at berth. • We show that, without the “anycast users” feature, the public IP address of a passenger device changes not only at PoP handovers but also within the same PoP, when the onboard router moves the device to another UT or even when neither the serving PoP nor the UT changes. • We show that the onboard network, rather than the satellite links, largely determines the passenger experience, as it adds about 8–9 ms of latency at the median and a much longer tail, while per-user rate limits cap the throughput of a passenger device. With access to UT telemetry, which is blocked on aircraft [7], we also show that the outside-in RTT closely matches the UT-reported PoP latency. • We find that most outages at sea are brief, obstructed outages concentrate in ports, and an outage can last until the next scheduled satellite handover, yet an outage of one UT does not necessarily interrupt a passenger flow.

•

II. R ELATED W ORK Starlink measurement. Starlink has been studied extensively from stationary UTs under the control of the researchers, covering its access network and satellite links [13], [14], transport [15], [16], application performance [17], [18], and largescale outside-in probing [19], [20]. For mobile users, including in-flight connectivity [7], [12], the PoP assignment can be approximated by a distance-based Voronoi diagram [7], [21], although the measured PoP boundaries deviate notably from geographic proximity in places [7]. A cruise ship, however, spends many hours in ports, does not keep its public address across PoPs, and shares several UTs among its passengers behind a router they cannot control. Maritime connectivity. Hossain et al. measured a fixed UT at coastal sites on land in Texas for throughput prediction [9], which Li et al. extended to latency [10], and Denizer et al. compared Starlink and 5G on a research vessel in coastal waters, finding similar Starlink performance at sea and on land [11]. These studies focus on the end-to-end performance of a single UT under the control of the researchers. To the best of our knowledge, no prior work has systematically studied Starlink maritime connectivity on commercial cruise ships, where multiple UTs behind a multi-WAN router serve thousands of passengers and the PoP association and handover of the ship remain unexplored.

gRPC to the serving UT every 0.5 s

Passenger device

Guest Wi-Fi

TABLE I: Measurement Overview

ping public IP of the UT

UT 1

PoP 1

Cloud server

UT n

PoP m

Cloud server

Onboard router

Passenger capacity Sailing region Measurement period Measurement hours Serving Starlink PoPs Passenger device Throughput tests

Utopia of the Seas

Silver Muse

5,668 [22] Bahamas Dec 16–19, 2025 83.5 Miami Mini PC –

632 [23] Adriatic Sea Jul 6–12, 2026 131.7 Sofia, Milan Laptop (VM) iPerf3

ping every 10 ms to the gateway of the serving PoP

Fig. 3: Path from a passenger device on a cruise ship to the Starlink PoPs and our measurement setup

III. M EASUREMENT M ETHODOLOGY In this section, we describe the measurement methodology applied on both ships, as shown in Fig. 3. A passenger device in a cabin collects UT telemetry and inside-out measurements over the guest Wi-Fi, while cloud servers near the serving PoPs collect outside-in measurements toward the public IP address of the serving UT. Table I summarizes the two voyages. A. Voyages and Onboard Network Utopia of the Seas sailed from Port Canaveral, Florida, to the Bahamas and back, and our measurement covered the voyage from December 16, 01:18 to December 19, 12:51 UTC in 2025 (83.5 hours, Fig. 1). Silver Muse sailed a round trip from Venice, and our measurement started mid-voyage near Dubrovnik and covered the Bay of Kotor, Bari, Dubrovnik, Hvar, Zadar and the return to Venice, from July 6, 17:11 to July 12, 04:54 UTC in 2026 (131.7 hours, Fig. 2), with stays of at least 9 hours at each port of call. Utopia of the Seas and Silver Muse sailed at a median speed of 15 and 11 knots, reaching up to about 25 and 16 knots, respectively. A passenger device joins the guest Wi-Fi through a captive portal and stays in the cabin throughout the voyage, so the UT that carries its traffic depends mainly on the load balancing policy of the onboard router. On both ships, the local network does not support IPv6, and the open HTTP port of the local gateway identifies it as a Peplink router. Unlike on Starlinkequipped aircraft [7], [12], the gRPC interface of the UTs was accessible from the local network on both ships. It shows that the UTs are flat high-performance UTs (hp1_proto0 or hp1_proto1) with a BUSINESS_PLUS subscription. The gRPC interface also exposes the GPS location of the UT. B. Inside-out Measurements 1) UT telemetry: The passenger device records the UT status and GPS location through the gRPC interface every 0.5 seconds. As the router distributes the gRPC session among the UTs, the dish ID and hardware revision identify the UT behind it. On Utopia of the Seas, the gRPC session reached 11 UTs in total, but two of them carried most of our traffic, while the others appeared in only a few responses. On Silver Muse, the gRPC session reached 3 UTs in total, one of which handled 99.94% of the requests, while the other two appeared

only briefly around PoP handovers. The UT also exports its outage history with the cause, start timestamp, and duration of each outage. 2) Public IP address and serving PoP: The device looks up its public IP address about every 5 seconds and maps it to a serving PoP by the longest prefix match against the Geofeed and PoP assignments published by Starlink [7]. Our traceroute measurements further show that each UT has a public IPv4 address without carrier-grade network address translation (CGNAT), which makes it reachable from the Internet. During our measurements, the UTs on Utopia of the Seas were associated only with the Miami PoP (mmmiflx1), and those on Silver Muse only with the Sofia (sfiabgr1) and Milan (mlnnita1) PoPs. 3) Latency: Instead of the CGNAT gateway 100.64.0.1 used for residential users [13], the device sends ICMP pings every 10 ms to the Starlink gateway of its current public IP prefix, e.g., 209.198.138.1 for 209.198.138.0/23. 4) Throughput: On Silver Muse, we additionally measured the uplink and downlink throughput between the passenger device and a cloud server near the serving PoP with iPerf3 over a single TCP stream, using both the BBR and CUBIC congestion control algorithms. Each test lasts 60 seconds, followed by a 60-second idle period. We did not run systematic iPerf3 tests on Utopia of the Seas. On both ships, the gRPC interface also reports the throughput of the UT, which aggregates the traffic of all passengers it serves. C. Outside-in Measurements Cloud servers near the Miami, Sofia and Milan PoPs send ICMP requests every 10 ms to the public IP address of the router attached to the UT serving the passenger device. Unlike the anycast router addresses of the Starlink aviation service [7], the public address changes at a PoP handover and may also change within the same PoP. We therefore follow the address changes observed by the passenger device and only use the server near the serving PoP toward the current address. As these ICMP probes terminate at the router, they exclude the onboard network and Wi-Fi. D. Ethics All inside-out measurements were collected from our own devices as regular passengers who purchased the onboard WiFi plan. We did not capture the traffic of other passengers or attempt to bypass the per-user rate limits. We identified the onboard Peplink router only from the HTTP service of the

8fa

Downlink (Mbps)

0 200 0 50 0

100

60

110

Inside-out (ping) Inside-out (gRPC)

50

Outside-in (ping)

50 0 200

RTT (ms)

a07

Latency (ms)

50

a07→8fa 12-17 18:37 UTC−5

Uplink (Mbps)

Latency (ms) Downlink (Mbps) Uplink (Mbps)

100

0

40

30

50 20 0

Dec 16

Dec 17

Dec 18

Dec 19

Jul 08

Date (UTC−5, 2025)

Jul 10

Jul 12

Date (UTC+2, 2026)

(a) Utopia of the Seas

(b) Silver Muse

Milan

Sofia

Miami

(c) RTT by serving PoP

Fig. 4: UT telemetry on both ships and RTT to the serving PoP.

41.4°N Milan → Sofia ≈20:42 UTC+2

41.3°N

41.2°N

41.1°N

Sofia Milan 12 nmi limit PoP handover Data gap > 10 min

16.7°E

16.8°E

Sofia → Milan ≈07:42 UTC+2 ship at berth 06:43–18:34

16.9°E

17°E

17.1°E

17.2°E

Fig. 5: PoP handovers of Silver Muse in Bari, switching to Milan while berthed and back to Sofia after departure.

local gateway and did not attempt to access its management interface. We used the gRPC interface of the UTs only for read-only requests of their status, location and outage history. The outside-in measurements consist only of ICMP probes toward the public IP address of the ship during the voyages. IV. M EASUREMENT F INDINGS In this section, we present our measurement results on the maritime jurisdiction reflected by the country code of the UT, the PoP association and public IP address assignments, the load balancing of the onboard router among UTs, and the latency and throughput of a passenger device. The gRPC telemetry captures the state of the satellite link, the inside-out measurements capture what the passenger device experiences over Wi-Fi, and the outside-in probes serve as an independent cross-check that excludes the onboard network. A. Jurisdiction and PoP Association Fig. 1(a) and Fig. 2(a) show the country code reported by the UT along the two voyages. The country code changes exactly when the ship crosses the 12-nautical-mile (nmi) territorial sea limit. Within a territorial sea, the UT reports the ISO 3166-1 two-letter code of the coastal state, i.e., US (United States) and

BS (Bahamas) for Utopia of the Seas, and HR (Croatia), IT (Italy) and ME (Montenegro) for Silver Muse, while beyond the limit, it reports XZ, the code that UN/LOCODE assigns to installations in international waters [24]. However, the serving PoP changes neither with the country code nor with the distance to the PoPs alone. For mobile users on land and in the air, the PoP boundaries can be approximated by a distance-based Voronoi diagram, with visible deviations hypothesized to stem from the peering capacity, subscriber density and load balancing of each PoP [7], [21]. Utopia of the Seas was served only by the Miami PoP throughout the voyage, in US and Bahamian waters as well as in international waters, consistent with the observation that the Miami PoP serves a large part of the Caribbean [7]. Silver Muse was served by the Sofia and Milan PoPs in turn, with five PoP handovers events as shown in Fig. 2(b). Fig. 5 zooms into the two PoP handovers near Bari, Italy. The ship berthed at 06:43 local time, and the PoP handover from Sofia to Milan followed at about 07:42 while the ship was still at berth. The gRPC session briefly reached another UT for tens of seconds, and the original UT kept the Milan address after the session returned, showing that a PoP handover happened for the original UT. As neither the position nor the jurisdiction of the ship changed, this handover was triggered on the network side. The PoP handover back to Sofia occurred at about 20:42, two hours after the ship left the port at 18:34 and after it had already crossed the 12-nmi limit into international waters. These observations suggest that the PoP assignment of Starlink maritime service also depends on network-side factors beyond the position of the ship. B. UT Load Balancing and Public IP Address The onboard router distributes passenger sessions among the UTs for load balancing, and the UT serving our device can be inferred from the dish ID in the gRPC response. On Utopia of the Seas, the gRPC session reached 11 UTs in total, but two of them, a07 and 8fa,1 carried most of our traffic, with 1 We keep only the last three characters of each dish ID for privacy.

Throughput (Mbps)

8

BBR CUBIC

7.84 6.83

6 4

n=912

n=398

4.50 n=738

4.56

n=460

2 0 Downlink

Uplink

Fig. 6: TCP throughput of a passenger device on Silver Muse.

continuous runs of up to 14.8 and 11.0 hours, respectively. The serving UT of our device changed from a07 to 8fa on December 17 at 18:37 local time, while the ship was at sea, and 8fa served the device for most of the rest of the voyage as shown in Figs. 1(b) and Fig. 4(a). The public IP address can change in three different cases. First, as neither ship had the “anycast users” feature used in Starlink aviation service [7], every PoP handover gives the UT a new address from one of the GeoIP prefixes associated with the new PoP. Second, the address changes within the same PoP when the router moves the device to another UT. For example, all 10 addresses observed on Utopia of the Seas belong to the Miami PoP, and the address of our device changes along with its serving UT. Third, the address can change even when neither the serving PoP nor the serving UT changes. C. UT Telemetry and Latency Fig. 4(a) and Fig. 4(b) show the UT telemetry of the two ships in local time. On both ships, the UT-reported latency to the PoP (pop_ping_latency_ms) has a baseline of about 20 ms throughout the voyage. The throughput reported by the UT aggregates the traffic of all passengers it serves, and shows a clear diurnal pattern that follows the local time and thus the activity of passengers, with the lowest traffic from midnight to dawn. The median throughput per UT was 66.6 Mbps downlink and 24.2 Mbps uplink on Utopia of the Seas, and 27.6 Mbps downlink and 16.0 Mbps uplink on Silver Muse, rising to 132.8 Mbps and 52.0 Mbps, and to 82.8 Mbps and 36.7 Mbps, at the 99th percentile. Averaged over the busiest 60 s, a single UT sustained up to 162.0 Mbps downlink and 71.2 Mbps uplink on Utopia of the Seas, and 139.2 Mbps downlink and 52.4 Mbps uplink on Silver Muse. These values are aggregate statistics of the traffic the UT carried, which reflect passenger demand rather than the capacity of the link. The higher throughput on Utopia of the Seas is likely because it is a much larger ship that serves many more passengers. Fig. 4(c) compares three RTT measurements for each serving PoP. The inside-out ping from the passenger device to the PoP gateway, the UT-reported latency through gRPC, and the outside-in ping from the cloud server near the PoP to the public address of the UT. On Silver Muse, the UTreported PoP latency has a median of 18.3 ms with Sofia and

18.9 ms with Milan, and the outside-in RTT has a median of 19.4 ms and 20.1 ms, respectively. The outside-in RTT thus closely matches the PoP latency reported by the UT, with a median only 1.1 ms and 1.2 ms higher. This small difference comes from the terrestrial paths between the PoPs and the cloud servers in nearby data centers, which only the outside-in ping traverses. In contrast, the inside-out ping has a median of 26.7 ms and 27.5 ms and a 95th percentile of 41 ms and 44 ms, respectively. A passenger device thus experiences about 8–9 ms of additional latency at the median due to the onboard Wi-Fi and local network, along with much higher variation. On Utopia of the Seas, the UT-reported PoP latency and the outside-in RTT have medians of 21 ms and 22.8 ms, respectively, while the inside-out ping has a median of 27 ms, similar to that on Silver Muse but a much longer tail, with a 95th percentile of 110 ms, possibly due to contention on the guest Wi-Fi and congestion in the onboard network. Therefore, the onboard network, rather than the satellite link, largely determines the passenger experience. Moreover, consistent with previous studies [7], the inside-out and outside-in latency measurements show the same minimum RTT pattern caused by the scheduled satellite handovers every 15 seconds. Furthermore, as the outside-in RTT closely matches the UTreported PoP latency on both ships, outside-in measurements provide a representative view of the satellite link that excludes the onboard network, a comparison that is not possible on aircraft, where the gRPC interface of the UT is blocked [7]. D. Single-User Throughput Fig. 6 shows the throughput of our passenger device on Silver Muse, measured with iPerf3 using BBR and CUBIC. The downlink throughput with BBR has a median of 7.84 Mbps and a maximum of 9.38 Mbps, while CUBIC achieves a lower median of 6.83 Mbps, consistent with previous findings that loss-based congestion control such as CUBIC performs worse over Starlink [15], [16]. The uplink throughput is tightly concentrated at a median of 4.50 Mbps with BBR and 4.56 Mbps with CUBIC. These results suggest that both the downlink and uplink throughput are capped by the onboard router according to the purchased Wi-Fi plan, rather than by the satellite links. For comparison, the aggregate traffic of a single UT on Silver Muse reached 82.8 Mbps downlink and 36.7 Mbps uplink at the 99th percentile. As hundreds of passengers share a few UTs, such per-user limits help the cruise line manage the shared throughput according to passenger demand and the Wi-Fi plans they purchased. E. UT Outages Fig. 7 summarizes the outage history of the UTs by cause. Most outages last about 1 s or less, except for SKY_SEARCH, which lasts several seconds while the UT searches the sky for satellites after a reboot and, in some cases, after a severe OBSTRUCTED event. We exclude BOOTING outages from Fig. 7, since they come from reboots of the UT rather than outages related to the satellite link. Silver Muse recorded 364 outages in 131.7 hours, far more than the 44 outages of Utopia

Count

Duration (s)

Silver Muse

Utopia of the Seas

R EFERENCES

101 100 10−1 200

175 86

0

OW _D NO

11

84 31

17

2

1

1

K N TS ED GS CH IN IN SA OW CT AR NL _P O_ KN SE RU O N _ N T N Y S U SK OB

Fig. 7: Outages reported by the UTs.

of the Seas in 83.5 hours. Utopia of the Seas recorded no OBSTRUCTED outages, whereas most of the 84 on Silver Muse occurred while the ship was berthed at the Port of Dubrovnik in Croatia, next to a bridge that likely blocked part of the line-of-sight of the UT. From the obstruction maps reported by the UT, we extract the relative SINR and the ID of the connected satellite [8], and find that outages of different causes may be part of a single event. For example, on July 9, 2026, while Silver Muse was berthed at the Port of Dubrovnik, the relative SINR dropped sharply at 09:33:49 local time, followed by about 6 s of consecutive OBSTRUCTED, NO_SATS and NO_DOWNLINK outages. Although the UT switched satellites several times through dynamic beam switching [8], [25], the link did not recover until the next scheduled handover at 09:33:57, when the UT switched to another satellite. V. C ONCLUSION In this paper, we measured Starlink maritime connectivity on two cruise ships of different scales, combining UT telemetry, inside-out measurements from a passenger device, and outside-in measurements from cloud servers near the serving PoPs. We found that the PoP handovers of a ship follow neither its maritime jurisdiction nor the distance-based approximation of PoP boundaries, suggesting additional network-side factors. The public IP address of a passenger device changes not only at PoP handovers but also within the same PoP, as the onboard router moves the device among UTs. The onboard Wi-Fi and per-user rate limits are the main bottlenecks of the passenger experience. Most outages at sea are brief and obstructed outages concentrate in ports, while an outage can last until the next scheduled satellite handover, yet an outage of one UT does not necessarily interrupt a passenger flow. Further analysis of the impact of obstructions and dynamic beam switching, and of multiple UTs behind an onboard router, such as their aggregated throughput and how load balancing mitigates packet loss and outages, is left to future work. Acknowledgment: We thank Lei and Marc for facilitating the measurements on both ships. This work was supported in part by NSERC, CFI and BCKDF.

[1] “Starlink Business | Maritime,” https://starlink.com/business/maritime. [2] “Satellite Connectivity Solutions for Maritime | Eutelsat,” https://www.eutelsat.com/satellite-services/maritime. [3] “Starlink | Transit,” https://starlink.com/business/transit. [4] “Starlink Progress Report 2025,” https://starlink.com/publicfiles/starlinkProgressReport 2025.pdf. [5] “What is Starlink Dedicated Service for Enterprise? - Starlink Help Center,” https://starlink.com/support/article/2d582f65-f744-529d268a-6e2e9f777c68. [6] “Multi-Starlink Bonding with Peplink SpeedFusion,” https://www.peplink.com/solutions/starlink-solutions-page/. [7] J. Zhao and J. Pan, “Measuring Starlink Aviation Around the World,” in Proceedings of the 2026 ACM Internet Measurement Conference, Oct. 2026, pp. 1118–1132. [8] J. Zhao, J. Baude, A. Ahangarpour, V. K. Devulapalli, S. G. L. Divakarla, Z.-L. Zhang, and J. Pan, “Demystifying Starlink Network Performance under Vehicular Mobility with Dynamic Beam Switching,” arXiv:2601.13790, Jan. 2026. [9] M. M. Hossain, X. Liu, H. H. Lou, R. Wang, and K. F. Rabbi, “Predictive Model for Starlink Maritime Performance Using MultiHorizon RandomForest,” in 2026 IEEE 16th Annual Computing and Communication Workshop and Conference, Jan. 2026, pp. 1464–1473. [10] R. Li, M. M. Hossain, X. Liu, and R. Wang, “A Dual-task Prediction Model for Starlink Maritime Performance,” in 2026 IEEE 5th International Conference on AI in Cybersecurity, Feb. 2026, pp. 1–5. [11] B. Denizer, N. Dohse, and O. Landsiedel, “FjordLink: Comparison of Starlink and 5G Networks for Teleoperated Vessel Control,” in Proceedings of the 2025 3rd Workshop on LEO Networking and Communication, Sep. 2025, pp. 8–14. [12] H. D. Jang, M. Varvello, A. Raman, and Y. Zaki, “From GEO to LEO: First Look Into Starlink In-Flight Connectivity,” in Proceedings of the 2025 ACM Internet Measurement Conference, Nov. 2025, pp. 952–962. [13] J. Pan, J. Zhao, and L. Cai, “Measuring a Low-Earth-Orbit Satellite Network,” in 2023 IEEE Annual International Symposium on Personal, Indoor and Mobile Radio Communications, Sep. 2023, pp. 1–6. [14] J. Pan, J. Zhao, and L. Cai, “Measuring the Satellite Links of a LEO Network,” in 2024 IEEE International Conference on Communications, Jun. 2024, pp. 4439–4444. [15] L. Jiang, Y. Zhang, Y. Hu, Y. Cui, and X. Zhang, “StarTCP: Handoveraware Transport Protocol for Starlink,” in Proceedings of the 8th AsiaPacific Workshop on Networking, Aug. 2024, pp. 169–170. [16] V. Kamel, J. Zhao, D. Li, and J. Pan, “StarQUIC: Tuning Congestion Control Algorithms for QUIC over LEO Satellite Networks,” in Proceedings of the 2nd International Workshop on LEO Networking and Communication, Nov. 2024, pp. 43–48. [17] A. Raman, M. Varvello, H. Chang, N. Sastry, and Y. Zaki, “Dissecting the Performance of Satellite Network Operators,” Proc. ACM Netw., vol. 1, no. CoNEXT3, pp. 15:1–15:25, Nov. 2023. [18] N. Mohan, A. E. Ferguson, H. Cech, R. Bose, P. R. Renatin, M. K. Marina, and J. Ott, “A Multifaceted Look at Starlink Performance,” in Proceedings of the ACM Web Conference 2024, May 2024, pp. 2723– 2734. [19] L. Izhikevich, M. Tran, K. Izhikevich, G. Akiwate, and Z. Durumeric, “Democratizing LEO Satellite Network Measurement,” Proc. ACM Meas. Anal. Comput. Syst., vol. 8, no. 1, pp. 13:1–13:26, Feb. 2024. [20] B. Wang, X. Zhang, S. Wang, L. Chen, J. Zhao, D. Li, and Y. Jiang, “A Large-Scale IPv6-Based Measurement of the Starlink Network,” in 2026 IEEE Conference on Computer Communications, May 2026, pp. 1–10. [21] S. Wang, J. Zhao, Y. Feng, Z. Yu, J. Pan, and D. Koutsonikolas, “A Cross-US View of Starlink’s PoP and Satellite Assignment Strategy to Mobile Users,” in Proceedings of the ACM SIGCOMM 2026 Conference, Aug. 2026, pp. 1946–1952. [22] “Utopia of the Seas: Size & Specs | Royal Caribbean Cruises,” https://www.royalcaribbean.com/guides/utopia-of-the-seas-size. [23] “Silver Muse Luxury Cruise Ship,” https://www.silversea.com/ships/silver-muse.html, Sep. 2026. [24] “Directory | UN/LOCODE,” https://unlocode.unece.org/directory. [25] Starlink, “Starlink Beam Switching,” https://www.starlink.com/updates/starlink-beam-switching.

Related documents

• Transport Layer Performance Combining Multipath and Network Coding in Mobile Satellite Networks#1215312
• Joint and Streamwise Distributed MIMO Satellite Communications with Multi-Antenna Ground Users#1343525
• Opportunities for Direct-to-Cell Polarization MIMO in the Downlink of a LEO Satellite Footprint#1483184
• Starfield: Demand-Aware Satellite Topology Design for Low-Earth Orbit Mega Constellations#1537149
• The Benefits of Low-Earth Orbiting Satellite Technology for the International Community: Can the Potential be Realized#493962