The idea, explained
A satellite internet connection is not simply a long Wi-Fi link. A user terminal sends an uplink to a visible satellite. The packet may travel down immediately to a gateway or cross one or more inter-satellite links before reaching a gateway connected to the wider internet. The return packet follows a corresponding path back to the user. The physical route, available capacity and operator’s routing decisions all affect delay and reliability.
Orbit height matters because radio signals travel at approximately the speed of light. A lower satellite shortens the space portion of the path, but height alone does not determine the user experience. The signal may travel diagonally rather than straight upward, wait for transmission capacity, cross multiple satellites, pass through a distant gateway, and then traverse terrestrial fibre. Processing, congestion and retransmissions add more delay.
LEO creates a special routing problem: the routers are moving. A ground terminal’s currently visible satellite eventually moves toward the horizon, so the connection must hand off to another satellite. Inter-satellite and ground links can appear or disappear as orbital geometry changes. Some of these changes are predictable from orbital schedules; equipment faults and weather-related radio conditions are not. RFC 9717 describes satellite topology as continually moving and proposes using scheduled connectivity information with existing routing mechanisms. It is an informational architecture, not an Internet standard or a description of any particular commercial network.
Scale adds another challenge. A constellation may contain thousands of nodes. If every small link change were announced everywhere, routing updates could overwhelm the network. Hierarchical routing groups nearby satellites so local changes remain local while summarized information supports longer paths. Gateways also need enough radio and terrestrial capacity because they connect space traffic to the planetary internet.
Ground infrastructure therefore remains essential. Antennas schedule contact windows, send commands, receive downlinks and hand data to compute and storage systems. AWS Ground Station illustrates this operational layer: it supports uplink, downlink, telemetry, tracking and command, plus delivery of received data to cloud compute or storage. Consumer access networks differ in purpose, but they rely on the same broad idea that space links and terrestrial systems must work together.
Follow a worked example.
Consider an idealized comparison that isolates propagation distance. Assume a user and gateway are directly below the same satellite and ignore slant angle, processing, queues and terrestrial travel.
For a LEO satellite 550 km high, the user-to-satellite-to-gateway path is 550 + 550 = 1,100 km one way. A round trip is 2,200 km. Using 299,792 km/s for light speed, the theoretical propagation time is 2,200 ÷ 299,792 = 0.00734 seconds, or about 7.3 milliseconds.
For a geostationary satellite 35,786 km high, the corresponding round trip is 4 × 35,786 = 143,144 km. The theoretical time is 143,144 ÷ 299,792 = 0.477 seconds, or about 477 milliseconds.
This does not predict a real service’s measured latency. A real LEO route is longer than the vertical example and includes handoffs, scheduling, routing, gateway placement and terrestrial networks. The calculation shows only why a lower orbit can reduce one major component of delay. It does not prove that every LEO connection is faster than every terrestrial or geostationary alternative.
Where people get stuck
Common misconception: once a terminal can see a satellite, the internet path is direct, fixed and controlled only by distance. In reality, the satellite is one moving router in a larger system. Gateway availability, inter-satellite links, congestion, routing policy, failures and the terrestrial path can dominate performance. Another mistake is treating an informational architecture such as RFC 9717 as a mandatory standard or as documentation for a proprietary constellation.
Now try it yourself.
1. Check the core idea
Why can a LEO network still experience interruptions or high latency even though its satellites are much closer to Earth than a geostationary satellite?
Reveal the answer & reasoning
Lower altitude reduces propagation distance, but it does not remove the rest of the system. Satellites move relative to users, requiring handoffs; links and capacity change; packets may cross several satellites or use a distant gateway; and terrestrial congestion and processing remain. A robust design must predict scheduled topology changes, reroute around failures, provide enough gateway capacity and measure the complete end-to-end path rather than orbit height alone.
Why this was added
The existing library explains terrestrial web requests and distributed systems but does not teach how moving satellite constellations, gateways, handoffs and propagation distance shape internet service.