October 2026 check: which specification should a mission use? NASA's public LunaNet specification page, checked on October 16, 2026, lists Version 5, published online on February 7, 2025. It also links a separate signal-in-space recommended standard for the Augmented Forward Signal. A mission procurement should identify those documents explicitly rather than ask only for a terminal that is “LunaNet compatible.” The revision and the services implemented are part of the requirement. The framework is developed collaboratively by NASA, the European Space Agency and the Japan Aerospace Exploration Agency. It covers both Direct With Earth links and lunar relay communications, as well as positioning, navigation and timing. That is a wider scope than a satellite constellation: a mission can use common interfaces even when different organizations supply its ground links, relay windows and navigation signals. A published interface is not an operating service The specification defines how systems can cooperate. It does not itself put a relay in orbit, reserve capacity, guarantee south-pole coverage or certify a particular receiver. Those claims need separate evidence from the service provider and the mission's own integration tests. Four questions before buying a lunar terminal Which baseline? Record the specification revision and applicable signal document in the interface agreement. A roadmap for a future revision is not a released technical baseline. Which services? Separate data transport, timing and navigation requirements. Support for one should not be treated as proof of all three. Which coverage? Test the planned orbit, terrain mask, antenna pointing and communications schedule against the actual landing site or rover route. Which failure behavior? Specify what happens to commands and stored science data when a link disappears, and how service resumes without losing message priority. These are engineering and procurement checks, not new performance guarantees from NASA. They make the standards discussion measurable: a provider should show which interface it implements, and a customer should show that the resulting service meets its mission needs. Two compatible terminals can still have an unusable link if power, geometry or scheduling is wrong. The distinction is especially important near the lunar south pole. A shared protocol cannot remove a crater wall from an antenna's line of sight. A relay can solve that problem only during the periods when it is visible and available. Navigation similarly depends on signal geometry and timing quality, not simply on a receiver carrying the correct label. Source checked October 16, 2026: NASA's LunaNet Interoperability Specification page . This refresh also corrects the earlier Version 5 PDF link to NASA's published 2025 baseline. The Moon will not get a simple copy of Earth's internet. It needs a communications and navigation system that can work across long distances, blocked lines of sight, weak power budgets, moving spacecraft, surface assets, and multiple national programs. LunaNet is NASA's answer to that problem. The easiest way to understand LunaNet is as a standards layer for lunar operations. It is meant to let orbiters, landers, rovers, relays, astronauts, science payloads, and ground networks exchange data, timing, position, and alert messages without every mission needing a custom one-off communications deal. AI-generated image LunaNet is a services framework for lunar communications, navigation, timing, and alerts. Why the Moon needs a network Apollo could rely on direct links between Earth and a small number of spacecraft. Artemis is different. NASA, commercial lander providers, international partners, science teams, and future service companies are all planning assets that may operate at the same time. Some will be in lunar orbit. Some will sit near the south pole. Some will drive behind terrain where Earth is not visible. Some will need timing precise enough to support navigation. Some will need emergency alerts when a solar storm or operational hazard changes the plan. A mission-by-mission communications model does not scale well in that environment. Every custom link adds integration work, spectrum planning, operations staffing, and failure points. A shared framework gives mission designers a clearer target: design to known services, known interfaces, and known expectations for how data moves between the Moon and Earth. That is the core LunaNet idea. NASA describes the architecture around networked services rather than a single satellite or single relay provider. The framework is intended to support networking, positioning, navigation, timing, science utilization, detection, and information services as the lunar environment becomes busier. Comms Data paths between surface, orbit, and Earth PNT Position, navigation, and timing support Alerts Hazard and operational warning services Standards Interfaces many providers can implement It is not one lunar Starlink LunaNet is sometimes described casually as lunar internet, but that shorthand can mislead. The important thing is not a single branded constellation. It is the service model. A relay satellite, a surface terminal, a ground station, a navigation beacon, or a commercial provider could all participate if they implement the agreed interfaces and services. That distinction matters for the cislunar economy. The Moon will probably have a mixed communications market. NASA's Deep Space Network and Near Space Network will still matter. Commercial relays may handle routine traffic. International systems may serve their own missions and interoperate where policy allows. Surface users will need local coverage around landing zones, science sites, and resource targets. A standards layer lets those pieces become more than isolated pipes. The same logic applies to navigation. Earth has GPS because a dedicated constellation broadcasts timing signals that receivers can use to compute position. The Moon has no equivalent operational utility today. LunaNet points toward a future where lunar users can obtain timing and navigation support from a networked set of assets instead of depending only on Earth-based tracking and mission-specific calculations. The practical test A lunar network becomes valuable when a new mission can arrive and use existing services with less custom integration. The measure is not whether the architecture sounds elegant. The measure is whether it lowers operations cost and reduces mission risk. What has to work The first requirement is coverage. South pole terrain is difficult. Ridges, crater rims, permanently shadowed regions, and low Sun angles all complicate antenna placement and direct Earth links. A rover that drives into a scientifically interesting shadowed region may lose line of sight to Earth. A relay architecture can keep that rover connected, but only if the orbit, antenna geometry, and service schedule match the mission's real route. The second requirement is timing. Navigation is not only about maps. It depends on clocks, signal timing, reference frames, and error budgets. If surface vehicles, orbiters, landers, and astronauts are going to use shared position services, the system has to define how timing is generated, distributed, trusted, and corrected. The third requirement is graceful failure. Lunar users cannot assume constant broadband service. Power may be limited. Terrain may block a link. A relay may be temporarily unavailable. Dust, thermal swings, radiation, or pointing errors can degrade performance. A useful network has to support store-and-forward behavior, priority handling, fallback modes, and clear expectations for which messages get through first. Service What it does Why it matters Networking Moves data between lunar users, relays, and Earth Lets missions share infrastructure instead of building isolated links Position and timing Provides reference signals and location support Supports rover routes, landing