Building a navigation network around the Moon

Terrain creates a geometry problem before a data-rate problem

ESA’s Moonlight description gives special attention to the lunar south pole, where terrain and lunar curvature can block a direct path between a surface user and Earth. Orbiting relay infrastructure can provide a different line of sight. A stronger transmitter cannot reliably solve a solid ridge lying between two antennas. The network therefore has to be designed around where signals can travel, not simply around how much data an individual radio could carry.

The same geometric issue affects navigation. A receiver estimates position from observations whose directions matter. Several signals arriving from almost the same direction constrain some components of position poorly, even if each range measurement is precise. A practical constellation must consider the changing view from the surface, interruptions, and the time over which a vehicle must keep navigating without an update. Coverage maps and uncertainty estimates are consequently more useful engineering outputs than an isolated best-case accuracy figure.

A navigation receiver measures time as well as distance

Radio ranging connects travel time to distance through the speed of light. As an illustrative calculation, a ten-nanosecond timing offset corresponds to roughly three metres of light travel. This does not mean every timing offset directly becomes a three-metre final position error; the estimator, geometry and other measurements determine the result. It does show why clocks and synchronization cannot be treated as peripheral details in a navigation service.

A receiver also has its own imperfect clock. Its observations can contain both a geometric range and a clock offset, along with instrumental and environmental effects. A useful navigation solution must separate or jointly estimate these quantities. On Earth, mature satellite systems provide the signals, reference times and operational monitoring needed to do this continuously. Lunar infrastructure must establish equivalent agreements for a different environment, including periods when direct Earth tracking is unavailable or inconvenient.

Interoperability is a technical contract between providers

NASA identifies LunaNet Interoperability Specification Version 5 as current, published online on February 7, 2025. The framework is developed with ESA and the Japan Aerospace Exploration Agency. It covers communications and positioning, navigation and timing for operations in transit to, around and on the Moon. Its purpose is to let service providers participate in a cooperative network through agreed standards and interfaces. This is a specification for compatible services, not the launch announcement for a single spacecraft.

Compatibility has several layers. A receiver must recognize a usable signal, interpret its information correctly and understand which coordinate and time references apply. Operators must also know when a service is available and what reliability its advertised information supports. A design can pass an electrical interface test while still failing at the meaning of the transmitted data. Interoperability tests should therefore exercise complete service behavior, including outdated information and interrupted links, rather than stopping when two radios exchange a packet.

A correction message without a clear time tag illustrates the problem. Its numerical value might be perfectly well formed, yet a receiver cannot safely decide how to use it if it does not know when it was valid. Even a valid time tag needs an agreed reference and a representation of uncertainty. Software tests can deliberately delay or reorder messages to reveal whether those assumptions are handled consistently. These are ordinary distributed-system concerns appearing inside a precision navigation problem. The radio link provides transport, but shared semantics determine whether the transported information improves the user’s position estimate or quietly makes it worse.

NovaMoon adds an anchored reference on the surface

ESA’s October 2026 NovaMoon description proposes a lunar surface reference station with co-located ranging instruments, clocks and navigation equipment. It would generate differential corrections for Moonlight and other services, supporting a target of sub-metre positioning around the south pole. Those are mission objectives, not measured on-Moon performance. The proposed station would also contribute to realizing a lunar reference frame and lunar reference time.

A reference station helps because some errors can be estimated where the station’s location is well known, then communicated to users. But a correction is only useful within the assumptions under which it was generated. Its age, geographic validity and uncertainty matter. Surface anchoring introduces additional questions: how precisely is the station tied to the reference frame, how stable is its installation, and can its clock continue operating through the local environment? Improving a radio measurement does not remove the need to characterize the physical place from which it was made.

A payload demonstration reduces uncertainty without finishing qualification

In September 2025, an ESA NAVISP project presented a tested engineering breadboard for a future Moonlight navigation payload. The official report lists timing, signal generation, antenna, tracking and command, very-long-baseline interferometry transmission, and laser retroreflector elements. It says the work informed achievable performance and the payload’s mass, power, size, environmental and interface needs. A breadboard is valuable evidence about a concept, but it is not an operational navigation satellite.

Moving toward flight requires the concept to tolerate launch and the intended space environment. Components that behave well on a bench may need different packaging, thermal paths or radiation protection. Hardware and software must also cooperate with the spacecraft bus rather than a laboratory supply and desktop computer. Engineers use successive models because each one answers a different uncertainty: whether the principle works, whether interfaces close, whether environmental margins hold, and whether a production unit matches the qualified design.

A current architecture must not inherit an obsolete schedule

The 2024 Moonlight launch announcement expected Lunar Pathfinder operations in 2026. The newer October 2026 NovaMoon page instead describes Lunar Pathfinder as planned to launch in 2027. The later statement is the appropriate schedule reference here. This is a concrete example of why infrastructure analysis must distinguish an earlier program announcement from the current status of hardware. A planned date is not evidence that the planned service became available.

Changing schedules also affect user missions. A lander designed around a relay that is not yet present needs another communications and navigation strategy, or a revised mission plan. Interfaces can remain useful even when a deployment moves, because they let engineers prepare compatible terminals and test equipment. Nevertheless, mission assurance depends on checking which services will actually exist at the time of use. A technically elegant future constellation cannot serve as a present operational dependency without that evidence.

The convincing demonstration will connect all the layers

A meaningful end-to-end test would join the satellite signal, the user receiver, the timing and frame definitions, service messages, and a vehicle’s navigation estimator. It would examine performance through interruptions and changing geometry. Surface corrections would need their own integrity and aging checks. These are proposed evaluation priorities derived from the architecture, not results reported by the cited sources.

The current development is interesting precisely because it extends beyond launching navigation transmitters. Lunar navigation needs a stable shared description of where and when a measurement occurred, together with hardware that can maintain that description under operational conditions. Moonlight, LunaNet and the proposed NovaMoon payloads address connected parts of that requirement. Their eventual success should be judged by whether independent missions can obtain trustworthy, compatible service when they need it, with understandable limits, rather than by treating a future network diagram as a network already in use.