A Network That Can Wait
Store and Forward turns waiting into a network operation. Once routes can cross time as well as space, satellites, vehicles, and disconnected machines become part of the same fabric.
The Internet has a weird assumption buried deep inside it: somewhere between you and the other side, a path exists now. Packets can get dropped, BGP can take a bad turn, and Wi-Fi can disappear for three seconds. We have decades of machinery for surviving all of that. Most of it treats lost connectivity as a temporary malfunction.
What if nothing is broken? What if the network is doing exactly what it was built to do, but the next link in the route will not exist for another forty minutes? That sounds like a space networking problem, and it is. It is also an increasingly useful way to think about networks on Earth.
Recommendation ITU-T Y.3232, approved August 13, 2026 and currently listed as prepublished, covers Store and Forward for IMT-2020 networks and beyond across fixed, mobile, and satellite systems. The satellite details matter, but the architectural admission underneath them matters more: communication does not require an end-to-end path to exist at one moment in time. Obvious once you say it. Still not how most networks behave.
When the path does not exist
Take a satellite in low Earth orbit. At time t1, it passes over a sensor in the Pacific. The service link between the sensor and satellite is available, but the satellite cannot see a ground gateway. Later, at t2, the satellite reaches a gateway. By then the sensor has gone over the horizon. There was never a continuous path between the two endpoints.
Ordinary networking looks at t1 and reports that the destination is unreachable. Store and Forward can use the half of the route that exists, keep the data in onboard storage, then finish the route when the feeder link appears. 3GPP's NTN work describes this as a service for delay-tolerant communication when user equipment (UE) has satellite coverage without a simultaneous active feeder link to the ground. Release 19 standardized this architecture for EPS, so it should not be read as a general 5G Core or NR Store and Forward implementation. Downlink runs the sequence in reverse.
The route is no longer only a sequence of interfaces. It becomes a sequence of interfaces plus time. That is a much bigger change than putting a larger buffer on a satellite.
Routers normally hate time
A conventional router wants to get rid of your packet almost immediately, which is a good design. RAM is finite, queues are dangerous, and long queues turn congestion into terrible latency. Putting persistent storage in the forwarding path sounds like the kind of proposal that gets a tense design review. The machine works because a packet's lifetime inside it is tiny.
Store and Forward changes that contract. A network node may intentionally own data for seconds, minutes, or hours. It needs policy, onboard storage, knowledge about future connectivity, and a scheduler that decides what leaves during each contact window.
Storage is suddenly part of forwarding. So are storage pressure, expiration, contact prediction, and delivery probability. Orbital mechanics can affect whether a message moves. A normal packet router mostly asks where something should go next. A temporal router also asks when it can go, how long it may stay, which future contact should spend capacity on it, and what gets deleted when storage fills up. This starts to look less like packet switching and more like distributed systems.
3GPP’s Stage 1 requirements already name a retention period, storage quota, forwarding priority, and acknowledgment policy for Store and Forward data. TS 23.401 also defines an optional estimated uplink delivery time from the UE to the ground network. Those are not all generic application APIs, and 3GPP does not define every scheduling algorithm behind them. They still make the shift concrete: time, storage, and policy have entered the network contract.
The topology needs time in the model. A useful shorthand is:
An edge can have an availability indicator a_ij(t), capacity C_ij(t), and a probability p_ij(t) that the predicted contact will actually happen. Suppose satellite A holds 20 MB and will see a gateway in 51 minutes. Satellite B is reachable over an inter-satellite link in four minutes and expects gateway contact in eleven. Sending through B might arrive sooner, but it spends link capacity, storage, and risk on another node. The route calculation is now a scheduling problem over a time-varying graph.
That framing makes continuous terrestrial connectivity look like a convenient special case. We are used to graphs where enough useful edges are almost always available. Store and Forward is for the rest of the world.
A moving hard drive can be a network
Once storage is allowed between two parts of a route, movement can provide connectivity. A satellite is one example, but the primitive is much simpler:
Imagine a weather station with no cellular service. Every twelve hours, a delivery truck passes within Wi-Fi range and collects 400 MB. Two hours later, the truck reaches a depot and uploads over fiber. The truck was part of the network in the literal engineering sense: it carried information between disconnected components.
We used an even simpler version before most places had reliable Internet. Software updates and datasets could be copied onto floppy disks and carried to another machine. There was no radio in that hop, but the principle was the same: storage crossed a gap because something moved it. FidoNet added modems and scheduled calls to the pattern. Bulletin board systems held mail, dialed a neighboring node, exchanged queues, and let later calls carry the messages onward. A network needed a mailbox and a future contact, not every endpoint online at once.
The latency is awful. The bandwidth is better than it sounds. Moving 400 MB every twelve hours gives an average payload transport rate, before protocol overhead, of about:
A vehicle that exchanges 100 GB during a short local contact once per day averages roughly 9.3 Mbit/s before protocol overhead. There is no continuous communications infrastructure between the endpoints, yet a useful amount of data moves. Increase local storage and contact speed and the numbers improve quickly.
We normally put networking and logistics in separate boxes because electrons move faster than trucks. That distinction gets blurry when cost matters more than latency. Telecom coverage usually comes from infrastructure density: install enough towers that a device can almost always see one. A moving Store and Forward network needs enough useful contacts instead. A train can collect telemetry along a rail corridor. A fishing vessel can drain ocean buoys. A farm vehicle can carry soil data home while doing work it already had to do. None of those machines needs to pretend it has a live Internet connection. It needs a storage contract and a future delivery contract.
Most data has a deadline, not a latency target
This architecture fits sensors unusually well because a lot of machine traffic does not need a response in milliseconds. Transformer temperature, reservoir level, soil moisture, container condition, seismic traces, and weather measurements are often useful for hours. The measurement has a deadline. Treating that deadline as if it were an interactive latency target wastes scarce capacity.
The application already knows the useful facts:
The network should be able to know them too. Then it can save an expensive immediate path for an emergency instead of spending it on a soil reading that an irrigation planner will not inspect until sunrise. This is the network version of realizing that not every compute job belongs in the interactive queue.
Disaster networks make the same point with higher stakes. A fire, earthquake, hurricane, or attack can split working local networks into islands. Restoring continuous backhaul is still the goal, but useful communication should not have to wait for it. A drone that crosses a neighborhood mesh every twenty minutes can drain medical requests, missing-person reports, and outgoing photos, then inject maps and updates on its next pass. That is bad broadband and useful networking.
The queue needs more than byte counts. A medical request can have priority 100. An evacuation map can expire after conditions change. A family photo can wait. A software update can consume only spare capacity. Once the network understands deadlines and value, it can fail in a much more useful way than treating every queued byte as equal.
Durable networks want durable software
There is an uncomfortable software implication here. A lot of application architecture assumes that communication means a live conversation between two computers: connect, request, wait, respond, close. That model works beautifully on a continuous network. It gets awkward when the response may arrive through another interface four hours later.
Store and Forward pulls software toward durable messages. Instead of asking a process to call service B now, an application could submit an object with a delivery contract:
Eventually it gets a durable result:
That interface resembles a database transaction or job queue more than a socket. It has to care about identity, deduplication, expiration, ordering, acknowledgments, authorization, quotas, replay, and replication. Some of those problems already live in messaging systems and Delay Tolerant Networking protocols. Moving persistence down into the network makes the boundary thinner.
It also changes how applications report state. A spinning “offline” icon is too crude when the system has accepted the object and predicts delivery during the next contact window. Software needs to distinguish accepted, stored, scheduled, forwarded, delivered, expired, and rejected. Once a node can hold your data for hours, observability and custody matter as much as connectivity.
Delay is a state, not a failure
Internet software likes to collapse delay and failure into one bucket. A request times out, a TCP session disappears, or a host cannot be reached, so the operation failed. A network with known intermittent connectivity has at least three operational states:
Those states lead to different decisions. If orbital prediction says a message has a 99.8 percent chance of reaching a gateway within 37 minutes, “unreachable” is not especially useful. The destination is reachable in time. Estimated delivery time becomes part of the API rather than a bit of UI decoration.
An application could ask for a delivery distribution:
Now it has options. Send an emergency message through an expensive immediate path. Put routine telemetry on the cheap temporal path. Replicate something important across both. Connectivity becomes an optimization problem instead of a boolean.
There is an economic layer hiding in that choice. Once traffic can wait, future bandwidth can be cheaper than bandwidth right now. Electricity markets already price time this way. A kilowatt-hour during a demand spike and the same energy at night can have very different prices. Network capacity can work the same way.
Those numbers are illustrative, but the service class is real. Machines produce huge amounts of data with wildly different values of time. A human message that says SEND HELP and a terabyte of agricultural imagery should not compete under one latency policy. The scheduler should know what waiting is worth.
Earth is already intermittently connected
Delay Tolerant Networking often gets presented as the thing we will need after leaving Earth, as if terrestrial networking were a solved and continuously connected baseline. It is not. Oceans, polar regions, deserts, mountains, farms, mines, airspace, disaster areas, and long infrastructure corridors all have gaps. Once machines become the majority of network participants, human-quality broadband looks like an even stranger default requirement.
A vibration sensor does not need Netflix. A shipping container does not need Zoom. A wildfire camera does not need to keep a TCP connection to Virginia open all day. Each one needs enough communication to complete its mission, which is a different optimization target.
Y.3232 is about convergence between terrestrial and satellite networks, and the related 3GPP work focuses on satellites, service links, feeder links, regenerative payloads, inter-satellite links (ISLs), storage policy, and Store and Forward procedures. The underlying primitive is more general. A node receives information without a current path to the destination. It keeps the information while the world changes, then forwards it when a useful edge appears.
Cars, ships, aircraft, drones, satellites, phones, robots, and trains can all take part if they have the right compute, storage, movement, and radio. The network stops being a static fabric built around moving endpoints. Some of those endpoints become the fabric.
A route through spacetime
Radio moves information through space. Storage moves it forward through time.
We usually draw a network on a plane: nodes and lines, with time left out of the picture. For an intermittent network, draw time vertically. A stored message is not stuck. It is moving forward in time inside one node until the next edge appears.
The vertical segments are as real as the radio links. Storage transports information through time. Radio transports it through space. A complete route can use both.
That is the useful mental model in Y.3232. The point is bigger than satellites with larger buffers. It is a network where waiting is an operation. Once waiting becomes legal, connectivity can be assembled from pieces that never existed simultaneously. A lot more of the physical world becomes networkable without covering every square kilometer in continuous infrastructure first.
We spent the last fifty years making packets move faster. There is another axis available. Sometimes the cheapest packet is the one that knows how to wait.