The Moon still has no GPS, no cell towers, and no always-on data network. Every mission that heads there today has to fight for contact time, especially near the south pole and on the far side. LunaNet is NASA's effort to change that by setting the technical rules for a shared lunar communications and navigation layer. This is not one spacecraft or one contract. It is a framework that lets NASA systems, commercial relay satellites, and partner agencies exchange data in compatible ways. Since this article was first published, that framework has moved a step closer to hardware, with NASA's Lunar Communications Relay and Navigation Systems project continuing interoperability testing and Intuitive Machines pushing toward its first Lunar Data Network satellite. AI-generated image Concept art of a lunar lander routing data through orbital relay satellites. Credit: AI-generated What's New Since March NASA's LCRNS program continues validating relay interoperability for south-pole missions, LuGRE's lunar GPS experiment has become a real proof point for lunar navigation, and Intuitive Machines is preparing the first node in its commercial Lunar Data Network. LunaNet is still early, but it is no longer just a white paper. Why the Moon Needs Its Own Network Layer Apollo-era communications assumed short missions at low-latitude landing sites with direct visibility to Earth. Artemis and the broader cislunar economy are aiming somewhere much harder. The south pole has the water ice, the lighting advantages, and the strategic attention, but it also has terrible geometry for direct communications. Craters block line of sight. Ridges create intermittent links. Permanently shadowed regions can cut a rover off completely. Navigation is the second half of the problem. Earth orbit spacecraft can lean on GPS. Lunar vehicles cannot. Landers, rovers, and orbiters currently stitch together position estimates from star trackers, inertial systems, terrain-relative navigation, and periodic Earth contact. That works for isolated missions. It works poorly for a future with frequent cargo flights, crewed sorties, autonomous construction gear, and commercial surface operations all sharing the same region. 3 Core service buckets, relay, PNT, and timing 1.25M Miles from Earth covered by NASA's Near Space Network service region 2025 Year LuGRE got the first GNSS fix on the Moon 2026 Year NASA is tying relay testing more directly to Artemis-era operations What LunaNet Actually Is LunaNet is best understood as a standards stack, not a single network owner. NASA's LunaNet Interoperability Specification tells relay providers and users how to exchange data, time, and navigation services in a common way. That matters because the lunar network is unlikely to be built by one government alone. NASA, ESA, JAXA, commercial operators, and defense-adjacent providers all want pieces of the architecture. The logic is familiar. On Earth, internet users do not care which company owns every fiber segment between points A and B. They care that the system works end to end. LunaNet aims for that same kind of interoperability, but in a much harsher environment where delays are longer, geometry is awkward, and every kilogram launched still matters. NASA's Lunar Communications Relay and Navigation Systems, or LCRNS, is the programmatic bridge between the specification and real services. LCRNS is meant to support Artemis, science missions, robotic campaigns, and eventually routine surface activity by building commercial relay capacity into NASA's Near Space Network. LunaNet components in plain English Layer What it does Why it matters Relay services Moves voice, telemetry, commands, and science data between lunar users and Earth Keeps assets connected when Earth is below the horizon PNT services Provides positioning, navigation, and timing references Lets landers and rovers locate themselves without constant ground intervention Interoperability rules Defines compatible interfaces, signals, and performance expectations Allows multiple providers to serve the same lunar user base The 2026 Shift, From Concept to First Commercial Nodes The biggest change since late March is that the conversation is getting less theoretical. NASA's LCRNS project page now emphasizes interoperability validation through its Interoperability and Performance Testbed, a hardware-in-the-loop setup designed to emulate a universal lunar user terminal and verify that commercial relay services actually meet the LunaNet and service-requirement specs. That matters because the first serious commercial contender is no longer hypothetical. Intuitive Machines is developing a five-satellite Lunar Data Network to provide communications relay plus navigation services for the lunar south pole and low lunar orbit. Technical papers and NASA-linked materials describe the first satellite, LDN-1, as the opening node in that network, with partial service preceding a fuller constellation rollout. In other words, LunaNet is starting to look like what broadband constellations looked like in their early terrestrial phase: one standards effort, one anchor customer, one first-generation operator, then a race to scale before demand spikes. Why LDN-1 matters The first satellite does not create a full lunar internet by itself. What it does create is a real test of whether a commercial relay can deliver useful south-pole coverage, integrate with NASA's service model, and prove that LunaNet-style interoperability can survive contact with actual hardware. LuGRE Changed the Navigation Side of the Equation The strongest recent proof point for lunar navigation did not come from a relay satellite. It came from LuGRE , the Lunar GNSS Receiver Experiment developed by NASA and the Italian Space Agency. After landing on the Moon in 2025, LuGRE recorded the first navigation fix on the lunar surface using signals from GPS and Galileo. That was more than a nice demo. It showed that weak Earth-originating GNSS signals can still contribute to position solutions on and around the Moon. NASA's navigation team now explicitly points to LuGRE as groundwork for operational lunar GNSS systems, which feeds directly into LunaNet's PNT ambition. The Moon does not need a copy-paste GPS constellation tomorrow if it can combine relay signals, augmented timing, and harvested GNSS signals into a workable navigation layer. This lowers risk for early missions. A relay architecture that offers ranging, timing, and cross-support from Earth-originating GNSS can give future operators better autonomy without waiting for a massive dedicated lunar navigation buildout on day one. Where the Bottlenecks Still Are The hard part is not writing the specification. It is getting enough compatible hardware into useful orbits, proving performance at the poles, and keeping service economics attractive for both government and commercial customers. The first operators will have to sell a market that is still forming. Coverage is also not binary. One relay can improve conditions for some trajectories and regions. A real network, especially one supporting crews, rovers, logistics landers, and fixed surface assets at the same time, needs redundancy. That means multiple nodes, multiple providers, and clear service expectations when an asset is behind terrain or in a degraded geometry window. Then there is governance. Interoperability is partly technical and partly political. If the United States, Europe, Japan, and commercial firms all field compatible systems, the lunar economy gets a shared backbone. If they drift into semi-compatible silos, operators will face higher costs and more integration headaches just when mission tempo starts to climb. Bottom Line LunaNet is still early infrastructure, but it is moving in the right direction. NASA now has a clearer validation path through LCRNS, commercial relay hardware is nearing flight, and LuGRE has shown that lunar navigation can borrow from Earth's GNSS systems instead of