Chapter 5

Phase 2: Implementation

Overview

Phase 2 of WIA-COMM-005 turns the Phase 1 data formats into something an integrator can call over HTTPS. A satellite-internet service has three physical parts: gateways on the ground, terminals at the customer, and satellites between them. Each part has its own RF constraints, so the interface surface is shaped by those constraints. A coverage query makes sense only because terminals must know where to point. Link-budget telemetry exists because Ka-band signals fade in rain. A latency endpoint exists because the choice between LEO, MEO and GEO is largely a choice about round-trip time. This chapter follows that order: ground segment first, then the terminal and the radio link, then latency, and finally the endpoints that expose all of it.

5.1 Ground Segment: Gateways and Teleports

A gateway station is where the satellite network meets the terrestrial internet. Users never talk to a gateway directly. Their traffic goes up to a satellite and comes back down at a gateway, which hands it to the backbone. The standard describes gateways with the following envelope:

ParameterSpecified range
Antenna diameter3-13 meters
Uplink bandKa-band, 27.5-30 GHz
Downlink bandKa-band, 17.7-20.2 GHz
Data rate10-100 Gbps per gateway
Gateways needed10-50 globally

A gateway has four jobs: connecting to the internet backbone, aggregating traffic from many terminals, managing the network, and carrying telemetry and control. Because it aggregates traffic, a failed gateway affects every terminal routed through it. Gateway count and placement are therefore reliability decisions as well as capacity decisions.

The standard breaks a gateway site (a teleport) into three layers.

The same hardware list shows why placement matters. Every packet crosses the terrestrial interface once on the way out and once on the way back, so the standard's guidance is to site gateways near internet exchange points (IXPs), with low latency to major data centers. It also asks for diverse geographic distribution and for regulatory-friendly jurisdictions. Geographic spread has a second benefit that comes from the physics of Ka-band. Heavy rain is usually a local phenomenon, so a network with several gateways can steer traffic toward a site under clear sky when one site is in a storm. The regulatory criterion is just as practical. A gateway needs spectrum licensing and a legal basis for landing traffic, and the operator has to be able to meet lawful-intercept obligations (see the Standards Compliance section).

Technical Foundation

The next two sections cover the physical layer an implementer must model: the terminal's antenna and modem, the arithmetic of the link budget, and the delay that results from the chosen orbit.

5.2 The User Terminal and the Link Budget

The terminal uses a phased-array antenna with no moving parts. The specified array is 30-60 cm across for Starlink-class terminals and 50-70 cm for OneWeb-class terminals. It has roughly 1,000-2,000 antenna elements, scans ±60° from zenith, and supports dual circular or linear polarization. Steering is done electronically by applying a phase shift between neighboring elements:

θ = arcsin(λ × Δφ / 2πd)

θ  = steering angle
λ  = wavelength
Δφ = phase shift between elements
d  = element spacing

Beam steering matters to the API because a LEO satellite crosses the sky quickly. The terminal has to know which satellites will be visible, at what elevation, and for how long, and then re-point the beam. The coverage-prediction endpoint described in section 5.4 supplies exactly that data.

The modem uses DVB-S2X with QPSK, 8PSK, 16APSK and 32APSK modulations. Forward error correction is LDPC. The specified code rates run from 1/4 up to 9/10 (1/4, 1/3, 2/5, 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9, 9/10), and symbol rates are 100-500 Msps. The service levels are:

MetricValue
Download100-500 Mbps
Upload20-50 Mbps
Latency (LEO)20-40 ms
Power: idle20-50 W
Power: active50-150 W
Power: peak100-200 W

The power figures matter for mobile installations such as vehicles, vessels and aircraft, where the terminal runs from a limited supply.

The downlink budget is the sum of gains and losses between the satellite's transmitter and the terminal's demodulator:

P_rx = EIRP_sat - L_path - L_atm - L_rain + G_rx - L_rx
TermMeaningSpecified range
EIRP_satSatellite effective radiated power50-60 dBW
L_pathFree-space loss, 20 log₁₀(4πd/λ)165-175 dB
L_atmAtmospheric absorption0.5-2 dB
L_rainRain fade1-10 dB, depending on frequency and climate
G_rxTerminal antenna gain35-40 dBi
L_rxReceiver losses1-2 dB

The standard gives received power as -90 to -110 dBm. Note that EIRP is expressed in dBW and received power in dBm, so any code that combines them must convert (the two scales differ by 30 dB). Mixing the units is one of the most common errors in link-budget software. The signal-to-noise ratio follows from the noise floor N = kTB, where k is Boltzmann's constant (1.38 × 10⁻²³ J/K), T is the system noise temperature (100-300 K) and B is the bandwidth in hertz. Typical values are 15-25 dB in clear sky and 5-15 dB during rain fade.

The uplink budget has the same structure with the roles reversed. The terminal's EIRP is 35-45 dBW, free-space, atmospheric and rain losses fall in the same ranges as the downlink, and the satellite's receive antenna gain is 25-30 dBi. The uplink is the weaker side because a small terminal cannot match the power of a satellite transmitter. That is why upload rates are a fraction of download rates.

The link is kept alive by adaptive coding and modulation (ACM). When SNR falls, the modem moves to a more robust modulation and code rate. It gives up throughput to keep the link up. The standard's three-point example illustrates this:

ConditionModulation and code rateThroughput
Clear sky32APSK, rate 9/10500 Mbps
Light rain16APSK, rate 3/4300 Mbps
Heavy rainQPSK, rate 1/2100 Mbps

A dense constellation such as 32APSK carries more bits per symbol but needs a high SNR. QPSK at rate 1/2 carries far less but survives a deep fade. Operators watch this behavior through the link-budget telemetry described in section 5.4: when the modem repeatedly steps down, the dashboard shows a fading event.

5.3 Latency and Its Optimization

Latency is the main reason to choose a low orbit. The standard breaks LEO round-trip time into three components:

Propagation delay: 2 × (550 km / 300,000 km/s) = 3.7 ms
Ground processing: 5-10 ms
Network routing:   5-15 ms
Total:             20-40 ms

The point of the breakdown is that physics is a small part of the total. Propagation to a satellite at 550 km altitude and back costs under 4 ms. Most of the budget goes to processing and routing, which is the part software can change. Other orbits and fiber compare as follows:

PathRound-trip time
LEO20-40 ms
MEO100-150 ms
GEO500-600 ms
Fiber (1000 km)10-15 ms

Three techniques bring latency down. The first is inter-satellite links (ISL). Traffic travels through the space mesh and avoids multiple ground hops, which the standard credits with reducing latency by 50-70%. The second is edge computing: CDN nodes are placed at gateways and popular content is cached in space, so some requests never need the full path to a distant origin. The third is protocol tuning. TCP BBR (Bottleneck Bandwidth and RTT), QUIC and custom congestion control all address a known weakness. Loss-based congestion control interprets the fades and handovers of a satellite link as congestion and slows down needlessly.

Market Analysis

Satellite-internet operators compete on measurable figures, and the standard makes those figures part of the contract. Conformant operators publish performance benchmarks every quarter: median round-trip time per region, 95th-percentile RTT, sustained throughput per terminal class, handover success rate, and fade-event MTBF (mean time between failures). These benchmarks feed customer choice and regulatory reports. The latency-optimisation endpoint supports a related comparison. It returns the predicted minimum RTT between two locations using the constellation's ISL topology, so a dashboard can set satellite latency beside a terrestrial alternative on one specific route instead of quoting a generic average.

Industry Applications

The standard identifies three deployment patterns that recur in production, and each one stresses a different part of the API.

Standards Compliance

Phase 2 draws on a set of established references: ISO 24113 for space-debris mitigation, CCSDS 502.0-B for orbital ephemeris messages, CCSDS 132.0-B for the TM space data link protocol, the ITU-R Radio Regulations, the 3GPP NTN specifications, IETF RFC 8446 (TLS 1.3) and RFC 8785 (JSON canonicalization). Compliance also has a legal dimension that no technical document can ignore. A satellite network crosses every sovereign boundary, and some jurisdictions require lawful intercept: CALEA in the United States, ETSI ES 201 671 in the EU, and the Protection of Communications Secrets Act in Korea. An operator declares such a requirement in its discovery document. Sessions in that jurisdiction then emit a notice envelope when they start, while the intercept itself happens on a separate signed channel that logs every access. Reproducible testing is supplied by a public conformance suite that exercises each endpoint and protocol exchange, and a reference container serves mock data for integrators. Within the 1.x line, existing envelopes and endpoints stay reachable and keep their documented status codes. Hosts may add optional fields but may not remove any.

Implementation Considerations

5.4 The Endpoint Surface

Four endpoints form the core of Phase 2, and every host advertises its configuration at the discovery path /.well-known/wia-satellite-internet.

POST /satinternet/v1/terminal/register     # register a user terminal
GET  /satinternet/v1/coverage/{lat}/{lon}  # coverage at a location
POST /satinternet/v1/handover/request      # request a handover
GET  /satinternet/v1/link/{id}/budget       # link-budget telemetry

The coverage endpoint accepts a location and returns the visible-satellite list with predicted elevation, predicted link quality and the next visibility window. It is the input both to antenna pointing and to operations dashboards. A worked request for central Seoul looks like this:

GET /satinternet/v1/coverage/37.5665/126.9780
Accept: application/json

→ 200 OK
{
  "wia_satinternet_version": "1.0.0",
  "location_iso6709": "+37.5665+126.9780/",
  "current_visible_satellites": 22,
  "predicted_minimum_visibility_seconds": 3600,
  "predicted_minimum_link_quality_db": 18.5,
  "next_visibility_window": null
}

Location is expressed in ISO 6709 notation. The predicted minimum link quality of 18.5 dB sits inside the clear-sky SNR range given earlier, which is a useful sanity check on the numbers. The next visibility window is null here, which fits a point that already has satellites overhead. Coverage envelopes are republished every minute for active service areas, and consumers cache them for 60 seconds. Polling faster than that gains nothing.

The link-budget endpoint returns the quantities from section 5.2: transmit power, antenna gain, free-space path loss, atmospheric loss, rain-fade margin and noise figure. For active links it is updated roughly every minute, so an operations team can see a fade event developing instead of discovering it from complaints. The handover endpoint is a write operation that starts a handover. Handover sequences and fade events are long-running, so they report completion by webhook. The callback carries the full signed envelope with HMAC verification, which lets a receiver check that the payload is authentic before acting on it.

Limits depend on who is calling:

Endpoint classDefault limitKeyed by
Public reads (coverage, operator info)60 requests/minSource IP
Authenticated control (terminal control, handover request)10 requests/minTerminal

These limits are advisory and vary per operator, and the discovery document declares the real values. A client should read them from discovery instead of hard-coding them. Other conventions make retries safe. An Idempotency-Key header prevents duplicate writes when a registration or handover request is retried after a timeout. Errors come back as RFC 9457 problem documents, the structured error format used across the WIA family. For audit and regulatory inspection, each host also exposes a bulk export of all link, handover and conjunction-warning records within a time window, carrying a Merkle root commitment so a reader can verify that nothing was omitted.

The recommended path for a first deployment is incremental. Stand up the reference container, run the test suite against it, then replace mock backends with real ones one endpoint at a time. Add audit-log replication, onboard a single trusted peer, then expand to more peers and go to production with warning-envelope subscription. The standard notes that a first deployment following this path reaches production in about 90 days, and that later jurisdictions reuse the same machinery with per-jurisdiction policy overlays.

Future Outlook

Several trends already visible in the specification will shape later revisions. The 3GPP NTN specifications point toward closer alignment between satellite access and mobile networks, and the modem section already lists 5G NR alongside DVB-S2X. Inter-satellite links shift more routing decisions into space, which raises the importance of the latency-optimisation endpoint. Mobility use (Pattern C) puts pressure on handover budgets. None of these changes would break the 1.x commitment, because optional fields and new envelopes can be added without removing anything that integrators rely on.

Summary

5.5 Chapter Summary and Transition to Phase 3

This chapter followed a packet from the customer to the internet. At the customer end, a phased-array terminal steers its beam electronically. The modem uses DVB-S2X modulation with LDPC coding. The link budget (EIRP, free-space loss, atmospheric and rain loss, antenna gain and noise) sets the achievable SNR, and adaptive coding and modulation trades throughput for resilience as rain fade deepens, with 500 Mbps in clear sky and 100 Mbps in heavy rain in the standard's example. Gateways connect the constellation to the backbone, and their placement near IXPs, geographic diversity and licensing environment decide both latency and availability. The round-trip budget shows that orbital propagation is only a few milliseconds of a 20-40 ms LEO round trip. The rest comes from ground processing and routing, which ISLs, edge caching and congestion control can reduce.

The Phase 2 endpoints expose this physics. Terminal registration, coverage prediction, handover requests and link-budget telemetry carry the quantities an operator needs. Rate limits, idempotency keys, problem documents and signed webhooks keep the calls safe to retry, and the bulk export together with the lawful-intercept notice supports audit. Three deployment patterns (urban backup, rural primary service and mobility) show which endpoints each kind of customer leans on most.

Everything here describes a single operator's host answering requests. The next chapter moves to Phase 3, where the same envelopes are carried in protocol exchanges that cross trust boundaries. Handover sequences, fade notifications and compliance records have to move between parties that do not share a single administrator, and the Phase 2 surface is the foundation for those exchanges.