How Starlink Works: LEO Satellite Internet

Starlink is a low Earth orbit (LEO) satellite constellation operated by SpaceX under AS14593. Unlike geostationary satellites parked at 35,786 km, Starlink satellites orbit between 340 and 614 km altitude, delivering round-trip latencies of 25-60 ms — comparable to terrestrial cable and DSL connections. The system currently comprises over 6,000 active satellites across multiple orbital shells, making it the largest satellite constellation in history by a wide margin. From a networking perspective, Starlink is building a parallel internet backbone in space, complete with BGP peering, IXP presence, and an evolving routing architecture that operates across a mesh of laser inter-satellite links.

Understanding how Starlink works means understanding the intersection of orbital mechanics, RF engineering, and internet routing — and why the constraints of each domain produce the network characteristics that show up when you query AS14593 in a looking glass.

Orbital Architecture: Shells and Planes

Starlink's constellation is organized into multiple orbital shells — groups of satellites at a specific altitude and inclination. Each shell serves a different coverage purpose and operates under different regulatory authorizations. The design is not arbitrary; it is driven by physics and the FCC/ITU licensing constraints that govern spectrum use at each altitude.

Shell Configuration

The primary operational shells as of 2026:

• Shell 1 (Gen1): 550 km, 53° inclination — The original workhorse shell. Roughly 1,584 satellites in 72 orbital planes of 22 satellites each. The 53° inclination provides coverage from approximately 53°N to 53°S latitude, which covers the vast majority of the world's population. This is the shell most Starlink subscribers connect to.
• Shell 2 (Gen1): 540 km, 53.2° inclination — Additional capacity layer close to Shell 1, with 1,584 satellites in a similar configuration. Slightly different altitude prevents conjunction risks with Shell 1.
• Shell 3 (Gen1): 570 km, 70° inclination — Extends coverage to higher latitudes (Alaska, Northern Canada, Scandinavia, Southern Chile). 720 satellites in 36 planes.
• Shell 4 (Gen1): 560 km, 97.6° inclination (sun-synchronous) — Polar orbits providing coverage to the highest latitudes, including polar regions. 348 satellites.
• Gen2 shells: 340-614 km, various inclinations — SpaceX has authorization for up to 29,988 Gen2 satellites at altitudes between 340 km and 614 km, dramatically increasing capacity density. Gen2 satellites launched on Starship are larger, with greater throughput per satellite.

Each satellite completes an orbit in roughly 90-95 minutes, traveling at approximately 7.5 km/s. This means any given satellite is overhead for only 2-8 minutes before it moves beyond range and a handoff to the next satellite occurs. The entire constellation is in constant motion relative to the ground — a fundamental difference from GEO systems where a single satellite can serve a fixed footprint indefinitely.

Orbital Mechanics Constraints

The choice of LEO altitude is a tradeoff between three competing factors:

• Latency — Lower altitude means shorter signal path and lower latency. At 550 km, the one-way propagation delay from ground to satellite is roughly 3.6 ms (speed of light in vacuum). The total round trip including ground-to-satellite, satellite processing, satellite-to-ground-station, and terrestrial backhaul typically lands between 25 and 60 ms. At GEO altitude (35,786 km), the propagation delay alone is ~240 ms one-way, making real-time applications painful.
• Coverage footprint — Higher altitude means each satellite covers a larger area on the ground. A Starlink satellite at 550 km has a coverage cone roughly 1,000 km in diameter (the precise number depends on minimum elevation angle). A GEO satellite covers roughly one-third of Earth's surface. This is why GEO constellations need only 3-4 satellites for global coverage while Starlink needs thousands.
• Orbital decay and debris — Lower orbits experience more atmospheric drag. At 550 km, a dead satellite deorbits within roughly 5 years due to drag alone, which is a deliberate safety feature — if a satellite fails, atmospheric drag ensures it reenters and burns up rather than becoming permanent debris. Satellites at 1,200 km (OneWeb's altitude) take decades to deorbit naturally. This is why SpaceX chose to lower their originally planned 1,100-1,300 km shells to 550 km after regulatory pressure regarding space debris.

The User Terminal: Dishy McFlatface

The Starlink user terminal — colloquially "Dishy" — is a phased array antenna that electronically steers its beam to track satellites as they pass overhead. There is no mechanical dish movement in the current rectangular and Gen 3 models (the original round dish had a small motor for initial orientation). The antenna contains over 1,200 individual antenna elements that adjust their phase to direct the beam toward whichever satellite is currently serving the connection.

Phased Array Design

Phased array steering works by varying the timing (phase) of the signal at each antenna element. By precisely controlling the phase offset between elements, the array creates constructive interference in the desired direction and destructive interference elsewhere — effectively "pointing" the antenna without physically moving it. The Starlink terminal operates in Ku-band (10.7-12.7 GHz downlink, 14.0-14.5 GHz uplink), which provides a reasonable balance between bandwidth availability and rain fade susceptibility.

Each terminal runs a custom Linux-based operating system and contains a full network stack including its own routing table. The terminal handles beam tracking, satellite handoffs, channel assignment, and encapsulation of user traffic into Starlink's proprietary framing protocol. From the user's perspective, the terminal presents a standard Ethernet or Wi-Fi interface — all the satellite complexity is abstracted away.

Handoffs

Because each satellite passes overhead in 2-8 minutes, the terminal must frequently hand off from one satellite to the next. This is conceptually similar to cellular handoffs but occurs far more frequently and across much larger distances. The terminal continuously evaluates signal quality from visible satellites and transitions to the best candidate. During Gen1 operation, these handoffs occasionally caused brief (100-500 ms) interruptions. As the constellation has matured and the handoff algorithms have been refined, disruptions during handoffs have become largely imperceptible for TCP-based applications, though they can still affect real-time protocols sensitive to jitter.

Laser Inter-Satellite Links

The most architecturally significant development in Starlink's network is the deployment of laser inter-satellite links (ISLs). Starting with the v1.5 satellites in late 2021 and now standard on all new launches, each satellite carries laser terminals that form point-to-point optical links with neighboring satellites. Each satellite typically has four laser terminals — two connecting to adjacent satellites in the same orbital plane (along-track) and two connecting to satellites in neighboring orbital planes (cross-track).

Why Lasers Matter for Routing

Without ISLs, every Starlink packet must follow a path of: user terminal → satellite → ground station → terrestrial internet. The satellite is merely a "bent pipe" relay. This architecture means the ground station must be within the satellite's footprint, which limits coverage to areas within roughly 500 km of a ground station. Over oceans, deserts, and polar regions — where ground stations cannot be placed — service is impossible.

With ISLs, packets can hop across multiple satellites before descending to a ground station. A user in the middle of the Atlantic Ocean can connect to a satellite overhead, which relays the traffic across several ISL hops to a satellite that is over land near a ground station. This enables truly global coverage, including over oceans and remote regions.

But the routing implications go deeper. Light in vacuum (or rather, in the near-vacuum of space) travels at c — approximately 299,792 km/s. Light in a terrestrial fiber optic cable travels at roughly 0.67c (about 200,000 km/s) due to the refractive index of glass. This means that for sufficiently long paths, routing through Starlink's laser mesh is actually faster than routing through terrestrial fiber. The crossover point is roughly 3,000 km — for paths longer than this, the space route has lower latency than the fiber route. For a London-to-Tokyo path (~9,500 km), the theoretical latency advantage of the space route is on the order of 15-20 ms round trip.

This has serious implications for latency-sensitive applications like high-frequency trading, real-time gaming, and video conferencing. SpaceX has not been shy about marketing this capability, and financial firms have reportedly explored Starlink for low-latency intercontinental connectivity.

ISL Routing Challenges

Routing over a mesh of laser links on moving satellites is a non-trivial problem. The network topology changes continuously as satellites move relative to each other. Cross-track links between satellites in adjacent orbital planes experience the most variation — the distance and angle between linked satellites change as they move along their respective orbits, and the links must be temporarily broken near the poles where orbital planes converge and satellites from different planes come too close together or move too quickly relative to each other.

SpaceX has not published details of their ISL routing protocol, but the constraints strongly suggest a link-state routing protocol with frequent topology updates, likely computed centrally on the ground and uploaded to satellites. The routing tables must account for the deterministic (orbital-mechanics-driven) topology changes, which are predictable minutes to hours in advance, as well as stochastic events like satellite failures or laser link degradation.

Ground Station Architecture

Starlink operates a global network of ground stations (SpaceX calls them "gateways") that connect the satellite constellation to the terrestrial internet. Each ground station contains multiple parabolic antennas (typically 4-8 per site) that communicate with satellites passing overhead using Ka-band frequencies (17.8-18.6 GHz downlink, 27.5-30.0 GHz uplink). The higher Ka-band frequencies used for gateway links provide more bandwidth than the Ku-band used for user terminals.

Ground stations are strategically placed to maximize the number of satellites that have at least one ground station within their footprint at any given time. In the continental United States, ground stations are spaced roughly 500-800 km apart. Each ground station connects to the terrestrial internet via fiber backhaul to a Starlink peering point or directly to an IXP.

POP and Peering Infrastructure

Starlink operates Points of Presence (PoPs) in major data center markets where it terminates ground station backhaul and peers with other networks. AS14593 (SpaceX/Starlink) has steadily expanded its peering footprint since its initial deployments. You can observe its routing behavior by looking up AS14593 in the looking glass — the AS path data reveals which networks Starlink peers with and where.

Starlink's peering strategy has evolved as the network has matured. In the early days (2020-2021), Starlink traffic was largely handed off to transit providers — the AS paths were longer and Starlink prefixes were seen behind upstream transit ASNs. As Starlink built out its own PoP infrastructure and established direct peering at IXPs like the Seattle Internet Exchange (SIX), Equinix exchanges, and DE-CIX, the AS paths shortened. Today, many eyeball networks see AS14593 as a direct peer or one hop away, similar to a mid-sized ISP.

IP Addressing and BGP Announcements

Starlink operates under AS14593, which is registered to Space Exploration Technologies Corporation. The ASN was originally used for SpaceX corporate infrastructure but now primarily serves Starlink subscriber traffic. Examining the prefixes announced by AS14593 reveals the scale of the operation:

• IPv4 space — Starlink announces a growing set of /14 through /20 prefixes. SpaceX has acquired significant IPv4 space to serve its subscriber base, including blocks obtained from ARIN and via market purchases. The IPv4 allocation challenge is real — with millions of subscribers each needing at least one public address (or CGNAT), Starlink's IPv4 appetite is substantial.
• IPv6 space — Starlink assigns /56 prefixes to subscriber terminals, which is standard practice for ISPs. IPv6 deployment has been active from relatively early in Starlink's service.
• CGNAT — Like most large ISPs, Starlink uses Carrier-Grade NAT (RFC 6598, 100.64.0.0/10) extensively. Many subscribers share public IPv4 addresses behind CGNAT. You can identify CGNAT usage by examining the IPv4 address assigned to a Starlink terminal — if it falls in the 100.64.0.0/10 range, the subscriber is behind CGNAT.

When you look at AS paths to Starlink prefixes, you will typically see AS14593 as the origin AS, with the AS path length depending on where your vantage point peers. From a major IXP where Starlink has direct peering, the path is simply the peer's ASN followed by 14593. From a more remote network, you might see one or two transit ASNs in between.

Routing Architecture Inside Starlink

The internal routing architecture of Starlink is not publicly documented, but the constraints of the system and observable behavior allow informed analysis.

The Ground Segment

On the ground, Starlink's PoPs run standard BGP to peer with other autonomous systems. The PoPs connect to ground stations via fiber. Each ground station manages the satellite-to-ground RF links for the satellites currently within its coverage area. The ground control infrastructure also computes routing tables for the satellite mesh, since the orbital mechanics make the topology deterministic and predictable — the ground can pre-compute the laser link topology and routing tables for the next several orbital periods and upload them to the satellites.

The Space Segment

Each satellite is essentially a router with RF interfaces (for ground communication) and optical interfaces (for laser ISLs). The routing problem on the satellite mesh is unique in networking: the topology is highly dynamic (links forming and breaking as satellites move), but the dynamics are deterministic — you can predict the topology at any future time with high accuracy because orbital mechanics is well-understood physics, not stochastic network behavior.

This determinism enables an approach quite different from traditional link-state or distance-vector routing. Rather than converging reactively to topology changes, the system can pre-compute forwarding tables for each satellite at each point in its orbit and upload these tables in advance. The satellite simply loads the appropriate table at the appropriate time. This is closer to segment routing or source routing than traditional hop-by-hop forwarding — and it avoids the convergence delays that plague conventional routing protocols during topology changes.

Traffic Engineering

The satellite mesh must also solve a traffic engineering problem. Not all laser links have the same capacity or the same loading. Links between satellites over densely populated areas carry more traffic than links over oceans. Links near the poles, where orbital planes converge, are shorter in duration and must handle handoffs more frequently. The ground-based control plane must distribute traffic across available paths to avoid congestion on hot links while minimizing latency.

This is analogous to how terrestrial networks use BGP communities and traffic engineering to steer traffic across multiple available paths, but the timescales and dynamics are different. A terrestrial TE decision might be stable for hours or days; a satellite mesh TE decision must adapt on the timescale of orbital periods (90 minutes) as traffic patterns shift relative to the constellation.

Latency Characteristics

Latency is Starlink's primary advantage over GEO satellite systems and the reason it can deliver a user experience comparable to terrestrial broadband. The latency budget for a typical Starlink connection breaks down as follows:

• User terminal to satellite (RF uplink): ~3-4 ms at 550 km altitude
• Satellite processing and switching: ~1-2 ms per hop
• Satellite to ground station (RF downlink): ~3-4 ms
• Ground station to PoP (fiber backhaul): 1-10 ms depending on distance
• PoP to destination (terrestrial internet): varies, same as any ISP

Total one-way latency with a direct satellite-to-ground-station path (no ISL hops): 8-20 ms, yielding round-trip times of 20-40 ms in optimal conditions. With one or two ISL hops (increasingly common as the laser mesh fills in), add 1-2 ms per hop. Real-world measurements consistently show 25-60 ms RTT for most subscribers, which is competitive with DOCSIS cable and DSL services.

Compare this with GEO satellite services like HughesNet or Viasat, where the 35,786 km altitude imposes a minimum RTT of roughly 480 ms from physics alone (2 x ground-to-satellite-to-ground at the speed of light), and real-world RTTs are typically 550-700 ms. The difference is not incremental — it is the difference between a usable and an unusable internet connection for interactive applications.

Latency Variation and Jitter

One area where Starlink still differs from terrestrial connections is jitter. Terrestrial fiber connections typically have very consistent latency (sub-millisecond jitter). Starlink latency varies due to several factors: changing satellite distance as it moves across the sky (distance to a satellite at 25° elevation is significantly longer than to one directly overhead), handoff events between satellites, weather-related signal degradation requiring more aggressive error correction, and congestion in oversubscribed cells.

Under congestion — which occurs when too many users are served by the same satellite beam — latency can spike to 100-200 ms as the scheduler queues packets. This is the satellite equivalent of cable network congestion during peak hours, and it has become more noticeable in areas where Starlink has aggressively sold subscriptions beyond the constellation's local capacity.

Capacity and Throughput

Starlink's total system capacity is determined by the number of satellites, the bandwidth per satellite, and the frequency reuse factor across the constellation.

Per-Satellite Capacity

Each Gen1 v1.5 satellite has an estimated throughput of roughly 17-23 Gbps. Gen2 Mini satellites (launched on Falcon 9) are estimated at 40-60 Gbps. Full-size Gen2 satellites designed for Starship launch are expected to exceed 80-100 Gbps per satellite. These are total satellite capacity figures — shared across all users served by that satellite at any given time.

Capacity per User

The capacity available to each user depends critically on the number of users sharing a satellite beam. A satellite with 20 Gbps of capacity serving 1,000 simultaneously active users can deliver 20 Mbps per user. Serving 200 active users, the same satellite can deliver 100 Mbps each. This is the fundamental capacity constraint of any shared-medium wireless system, and it explains why Starlink's per-user performance varies significantly by location — users in rural areas with few neighbors get much better throughput than users in suburban areas where Starlink adoption is dense.

SpaceX manages this through cell-based capacity management. The service area is divided into hexagonal cells, and each cell has a capacity budget based on the number of satellite beams covering it. When a cell becomes oversubscribed, SpaceX either deprioritizes new subscribers in that cell, offers "best effort" tiers, or waitlists new signups. This is directly analogous to how a cable operator manages capacity on a DOCSIS node or how a cellular carrier manages sectors.

Spectrum and Regulatory Challenges

Starlink operates in several frequency bands, each with its own regulatory landscape:

• Ku-band (10.7-12.7 / 14.0-14.5 GHz) — Primary user terminal band. Shared with incumbent fixed satellite service (FSS) operators and terrestrial fixed services. ITU coordination is required to prevent interference with GEO satellites in the same band. The EPFD (equivalent power flux density) limits imposed by ITU regulations constrain how much power Starlink can beam toward the ground in directions that might interfere with GEO satellite reception.
• Ka-band (17.8-18.6 / 27.5-30.0 GHz) — Used for gateway (ground station) links. Higher frequency provides more bandwidth but is more susceptible to rain fade. During heavy rain, Ka-band links can lose several dB of signal margin, requiring the ground station to reduce data rates or switch to a different satellite.
• V-band (37.5-42.5 / 47.2-51.4 GHz) — Planned for future high-capacity gateway links. Even more bandwidth available but even more rain fade sensitivity.
• E-band (71-76 / 81-86 GHz) — Under consideration for direct-to-cell services and next-generation ground links.

The regulatory environment is a patchwork. Each country's telecommunications regulator must independently authorize Starlink to operate. This has resulted in significantly different availability timelines — Starlink launched in the US and Canada first, expanded to Europe and Australia, and has been slower to gain approval in countries with more protective telecommunications policies or where incumbent operators have lobbied against it. Some countries (notably Russia and China) have prohibited Starlink entirely.

ITU Coordination and GEO Interference

The most contentious regulatory issue is coordination between LEO and GEO systems. GEO satellite operators (Viasat, SES, Intelsat) have lobbied aggressively at the ITU and national regulators to impose strict power limits on LEO constellations to protect their systems from interference. The argument is that thousands of LEO satellites collectively produce an "aggregate interference" floor that degrades GEO satellite reception, even if each individual LEO satellite's emissions are within limits.

SpaceX has countered that their system is designed to avoid GEO interference through beam avoidance (not transmitting toward the GEO arc), power control, and frequency coordination. The regulatory battles are ongoing and have real implications for Starlink's capacity — stricter EPFD limits mean lower transmit power, which means either lower data rates or more satellites needed to achieve the same coverage.

Comparison with GEO and MEO Systems

Starlink's LEO approach represents a fundamentally different set of engineering tradeoffs compared to traditional satellite internet:

GEO satellites have one fundamental advantage: simplicity. A single satellite can cover a vast area with no handoffs, no inter-satellite routing, and a 15-20 year operational lifespan. Each GEO satellite (e.g., Viasat-3 at ~1 Tbps capacity) is a massive, expensive, complex spacecraft — but you only need a few of them. The tradeoff is latency that makes real-time applications effectively impossible, and capacity that must be shared across the entire visible footprint (roughly one-third of Earth's surface).

Starlink inverts this tradeoff: cheap, mass-produced satellites with short lifespans, requiring constant replenishment launches, but delivering latency that is competitive with terrestrial broadband. The economic bet is that SpaceX's reusable launch capability (Falcon 9 and Starship) makes the continuous launch cadence sustainable.

Starlink's BGP Behavior in Practice

Observing AS14593 from a BGP looking glass reveals several interesting characteristics:

Prefix Announcements

Starlink's announced prefixes can be categorized into subscriber blocks (residential and business users), infrastructure blocks (ground stations, PoPs, corporate), and anycast addresses for DNS and other services. The subscriber blocks are the largest and grow as SpaceX acquires more address space to serve its expanding user base.

AS Path Characteristics

Looking at how other networks reach Starlink prefixes reveals the peering topology. From well-connected vantage points, you will see short AS paths — often just one transit AS between the observer and AS14593, or direct peering with no intermediary. From less-connected networks, the paths are longer and may traverse tier-1 transit providers.

The AS path data also reveals Starlink's upstream transit relationships. While Starlink has aggressively expanded its peering, it still purchases transit from major providers for routes it cannot reach directly. The mix of transit and peering is visible in the AS path diversity — routes to Starlink from different vantage points traverse different intermediate ASNs depending on whether that vantage point reaches Starlink via peering or transit.

Route Stability

One concern with satellite-based ISPs is route stability. If the satellite network has outages or reconfigurations, this could cause BGP route flapping visible in the DFZ (Default-Free Zone). In practice, Starlink's BGP announcements are relatively stable because the BGP sessions run on the ground — between Starlink's terrestrial PoPs and its peers. The satellite segment is internal to AS14593 and its dynamics are not exposed to external BGP. This is architecturally equivalent to how a terrestrial ISP's internal OSPF or IS-IS reconvergence does not cause external BGP churn — the satellite network is the internal routing domain, and BGP only sees the stable edge.

Geolocation Challenges

IP geolocation for Starlink addresses is notoriously inaccurate. Traditional geolocation databases map IP addresses to locations based on which ISP owns them and where that ISP's infrastructure is located. For a terrestrial ISP, a customer's IP address is typically assigned from a block associated with a nearby PoP, so geolocation is reasonably accurate. For Starlink, a subscriber in rural Montana might egress through a ground station in Seattle and be assigned an IP from a block registered to SpaceX's headquarters in Hawthorne, California. Geolocation databases see the IP and report it as being in California or Washington, not Montana.

This has practical consequences for content delivery. CDN servers that select edge locations based on client IP geolocation may send Starlink users to the wrong edge, increasing latency. DNS-based CDN steering (where the CDN's authoritative DNS returns different IPs based on the resolver's location) is similarly affected if the Starlink subscriber uses a DNS resolver at the ground station location rather than a local resolver.

Direct-to-Cell and Future Services

SpaceX is expanding Starlink beyond traditional dish-based service to direct-to-cell — connecting standard, unmodified cell phones directly to Starlink satellites. This service, launched in partnership with T-Mobile in the US and various carriers globally, initially supports text messaging and is expanding to voice and data.

From a networking perspective, direct-to-cell introduces additional complexity. The satellite must emulate a cell tower, implementing the 3GPP radio interface (LTE/5G) in space. The satellite connects to the partner carrier's core network via ground stations, and the traffic is routed through the carrier's AS — not through AS14593. This means direct-to-cell traffic is not visible as Starlink traffic in BGP; it appears as traffic from the partner carrier's network.

The Bigger Picture: LEO Constellations and Internet Routing

Starlink is the largest but not the only LEO constellation. Amazon's Project Kuiper (not yet operational as of early 2026, but launching test satellites), OneWeb (operational, focused on enterprise and government), and various Chinese constellations (GuoWang, G60) are all building or planning LEO systems. Each will have its own ASN, peering relationships, and routing characteristics.

As LEO constellations mature, they represent a potential shift in internet routing architecture. Today, intercontinental traffic flows primarily through submarine cables. If LEO laser meshes can offer lower latency than fiber for long-haul paths (and the physics says they can), some portion of latency-sensitive traffic may migrate from submarine cables to satellite networks. This would show up in BGP as changing AS path preferences — networks might prefer a path through a satellite ASN over a path through a submarine cable operator's ASN if the satellite path offers lower latency.

This is not theoretical. Financial trading firms already pay significant premiums for marginally lower latency on intercontinental paths. If Starlink or a competitor can offer a London-Tokyo or New York-Tokyo path that is 10-20 ms faster than the best fiber path, the economic incentive to route through the satellite network is substantial.

Observe It Yourself

You can explore Starlink's presence in the global routing table directly:

• AS14593 — SpaceX / Starlink — View Starlink's BGP announcements, upstream providers, and peering relationships
• AS13335 — Cloudflare — A major CDN and DNS provider that peers with Starlink at multiple locations
• AS15169 — Google — Another network with extensive Starlink peering, used by many Starlink subscribers for DNS (8.8.8.8)
• AS16509 — Amazon / AWS — Kuiper's parent company and a significant destination for Starlink traffic

Use the BGP Looking Glass to look up Starlink's announced prefixes and examine the AS paths. Compare paths to Starlink from different vantage points to see where Starlink peers versus where it buys transit. Traceroute to Starlink IP addresses to observe the ground station egress points and the latency characteristics that the LEO architecture produces.