Building the Moon’s Internet, GPS and Clock

Part 12 of 32 · Series date: September 7, 2026

You know the feeling. The map on your phone stops loading just as the road splits.

Now imagine that the road is a set of tire tracks across the Moon. The next ridge hides the base. There is no passing driver to ask.

That imagined moment shows why lunar travel needs three services we often blur together: a way to send messages, a way to know where we are, and a shared way to measure time.

The Moon needs all three. It does not yet have the everyday coverage that people expect from a phone on Earth.

A signal needs a path

Radio waves can travel through space, but solid terrain can block a direct route. A crater wall may hide an antenna's view. The Moon itself blocks direct contact between Earth and much of the far side.

A relay can help. It receives a signal and passes it on, much like a person carrying a message around a corner.

ESA's Moonlight program is designed to provide lunar communications and navigation services. The idea is to let future missions use shared support instead of building a full private network each time. ESA: Moonlight

That could make small missions easier to design. It also creates a new question: How well can they operate when the shared service is unavailable?

Earth satellites have already reached the Moon

On Earth, navigation satellites broadcast signals that let a receiver work out its position. The receiver needs precise information about timing and the satellites' locations.

In March 2025, the NASA–Italian LuGRE experiment on Blue Ghost received signals from GPS and Europe's Galileo system on the lunar surface. It also achieved a navigation fix. That was a real demonstration using Earth-orbiting satellites. NASA: Navigation signals received on the Moon

It does not mean a normal phone can navigate everywhere on the Moon. LuGRE used purpose-built equipment at a particular site. Future missions may combine those signals with dedicated lunar services, local maps, cameras, and other tools.

NASA's LunaNet work sets out agreed approaches for lunar communications and navigation. Its specification helps define how services and users can fit together. NASA: LunaNet specification

The word “specification” may sound dry. It is how two teams avoid discovering that their devices speak different languages after launch.

A clock is part of the map

Imagine asking a friend how far away a sound came from. If you know its speed and travel time, you can estimate the distance.

Radio-based navigation uses a much faster signal, so timing errors matter a great deal. Clocks are therefore part of the location system, not just a way to schedule lunch.

Time also keeps science useful. If two instruments record the same event, researchers need to know whether their time stamps can be compared.

There is a deeper twist: gravity and motion affect how clocks compare. Lunar timekeeping must account for those effects when linking Moon clocks to Earth clocks. NIST has studied how to do that for a shared lunar time system. This is more than choosing a time zone. NIST: What time is it on the Moon?

The everyday purpose is simple: measurements made in different places should agree on when something happened.

Otherwise a precise-looking answer can still be wrong.

Slow down before the link drops

Return to our imagined rover near the ridge. A sensible vehicle should not depend on a constant stream of steering instructions from Earth.

It could use local sensors to avoid a rock, stop if the route is unclear, and preserve enough information to report what happened. The human operator could set a goal while the machine handles some short, local tasks.

That is a possible design approach, not a claim that all lunar rovers already do it. The degree of autonomy must fit the machine and the consequences of a mistake.

The same idea applies inside a habitat. A lost video call should not stop the equipment that controls the air.

Good networks support local judgment. They do not replace it.

Not every message can wait its turn

A family video, a science file, and a rover warning can all travel as data. They should not have the same place in line.

Imagine a busy network carrying a large batch of images. A rover then reports a fault. A sensible design would give that urgent message a path through, even if the images take longer to arrive.

The reverse can happen too. A rover may keep collecting useful data while its link is down, then send the files when contact returns. But it needs enough storage and clear rules for what to keep.

These are design choices, not claims about a finished lunar network. They show why a strong signal alone is not the whole service. The network must move the right information soon enough for someone—or some machine—to act on it.

Trust the message, not just the signal bars

A strong signal can carry bad information. A sensor can fail. A clock can drift. A command can come from the wrong source.

NIST's space cybersecurity work treats command systems and navigation data as things that need protection from both deliberate and accidental disruption. NIST: Cybersecurity for the space domain

For a base, this suggests basic questions. Is the sender trusted? Is the message current? Does it match other measurements? What happens if the answer is no?

Reliability means more than keeping a connection open. It means knowing what to believe.

The first ordinary call home

The network's greatest achievement may eventually look routine. A crew member sends a clear video to a school. A rover uploads a map. A scientist downloads a year's measurements without having to invent a new communications system.

That is how infrastructure changes a place. It removes some of the effort from each new task.

At the ridge, the rover's link returns. Its stored science files begin to move. An urgent status report goes first.

Later, when the work is done, a crew member makes a call home.

A good network would have room for both kinds of message: the one that keeps the mission moving and the one that reminds a person why coming home matters.