11 Delay-Tolerant Networks: Design Principles

11.1 Start With the Decision

The ranger’s boat may carry stored records to a base station hours later. Write the delivery promise before choosing a route.

11.2 Route Overview

This is part 1 of 2. Continue with Delay-Tolerant Networks: Disconnected Operations.

11.3 Part Objectives

• Test disconnection comes first with a concrete scenario and pass criteria.
• Validate dtn is not just slow networking with a concrete scenario and pass criteria.

11.4 Start Simple

Design for the Gap as Normal Service

Picture a ranger collecting river readings where no end-to-end radio path exists. A protocol is a shared set of rules for exchanging data. A payload is the useful content inside a message. Latency means the time from making that message to the result that matters.

The ranger’s boat may carry stored records to a base station hours later. Write the delivery promise before choosing a route. Name the source, message identity, creation time, expiry, size, storage owner, possible carrier, contact window, priority, receiver, and late-use rule.

Test a missed meeting, a full store, low power, a damaged record, a duplicate hand-off, the wrong clock, a carrier that returns late, and recovery after restart. Check that the final user can tell when and where the reading was made. Eventual arrival is not enough if the record is too old or has lost meaning.

Keep urgent river or worker safety local when contact is absent. The delayed path can carry history and planned work, but it cannot promise an immediate reply.

This opening does not promise one delay or delivery chance. Practitioner builds the contact and storage record. Under the Hood examines custody, buffer pressure, expiry, routing choices, energy, duplicates, and the limits of movement as a path.

Use a simple field drill before release. Make three records at known times. Let the first carrier miss its meeting. Fill part of the store with low-value data. Give one record a short life and one a long life. Send one record twice. Then bring a second carrier into range.

The result should be easy to read. Staff should see which record is new, which is late but useful, which expired, which was repeated, and which still waits. Storage use and power should remain visible. The final user should know the source time, not only the arrival time.

Run the drill again after a route, clock, record shape, priority, store size, or carrier plan changes. Keep failed runs because they show where the delivery promise ends. Name the person who can clear old data, change priority, or accept a late result. If that person or rule is missing, the delayed service is not ready.

Close with five plain checks. Can the source save the full record? Can the carrier tell new data from old data? Can the next stop reject a bad copy? Can the final user see the source time? Can the team clear low-value data before the store fills?

Run the checks with no contact for the longest planned gap. Then allow one brief contact. Count what moves and what stays. A good result does not mean all data arrives at once. It means each choice follows the stated age, rank, space, and power rules.

Start with devices that have to pass useful data before any fixed network is guaranteed. In DTN Store-Carry-Forward, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.

11.5 Start With a Network That Is Usually Broken

A delay-tolerant network assumes that end-to-end connectivity may not exist when a message is created. A node stores data, carries it through time and space, and forwards it when contact finally appears.

That idea fits wildlife sensors, rural links, disaster response, ships, vehicles, and remote field work. Start with one message that cannot be delivered now. The DTN story is how the system protects it until delivery becomes possible.

11.6 Learning Objectives

By the end of this chapter, you will be able to:

• Explain DTN Concepts: Describe Delay-Tolerant Networks and their fundamental assumptions about disconnection
• Analyze Disconnected Scenarios: Identify IoT applications where continuous connectivity is unavailable and justify DTN suitability
• Apply Store-Carry-Forward: Implement the core DTN paradigm for intermittent connectivity in real deployments
• Distinguish DTN from Traditional Routing: Compare DTN approaches with connected ad hoc protocols and evaluate when each is appropriate

11.7 Disconnection Comes First

If you only need the intuition, this layer is enough: DTN works when a packet cannot follow a continuous path. A node stores the bundle, carries it while moving, and forwards it during a later contact.

That changes the design question. In a connected IP network, the first question is often "which next hop can carry this packet now?" In a DTN, the first question is "what state must survive until a useful contact appears?" The message needs an identity, a destination, a creation time, an expiration rule, and enough priority context for a future carrier to decide whether it deserves buffer space.

A good mental model is a traceable handoff chain. A sensor may create a bundle at noon, a vehicle may collect it at sunset, another gateway may receive it the next morning, and the application may still accept it because the measurement is late but useful. The same design is wrong when the data loses value in seconds, when storage cannot survive the gap, or when the operator cannot explain what happens after a missed contact.

This is why DTN chapters should talk about time as a normal part of routing. The path is not just a set of radios; it is a sequence of storage intervals and contact opportunities. A store-carry-forward design is ready to discuss only when the team can name the expected delay range and the application consequence of arriving outside it.

Checkpoint: Disconnection Frame

You now know:

• DTN starts from the assumption that no simultaneous end-to-end path may exist.
• Store-carry-forward turns storage intervals, mobility, and later contact windows into the path.
• The first design question is what state must survive until contact appears.

11.8 Practitioner: Build the Delivery Record

A DTN design should start with one bundle class and a delivery promise. Wildlife GPS summaries, disaster status reports, and rural kiosk messages can tolerate delay, but each still needs a record that proves the delay is acceptable and bounded.

The delivery record should be concrete enough for a field review. Name the bundle identifier scheme, payload size range, producer, destination endpoint, maximum useful age, priority, privacy sensitivity, and duplicate-handling rule. Then name the storage owner at each stage: source node, mobile carrier, relay cache, gateway, or application server. If ownership is vague, stale bundles tend to accumulate because every device assumes another device is responsible for cleanup.

Contact evidence turns the design from a story into an engineering budget. For example, a 20-second contact at 50 kbit/s can move at most about 125 kB before protocol overhead, retries, and radio setup time. If the daily payload is larger than the contact budget, the design needs compression, prioritization, more contacts, a higher-rate link, or a decision to drop low-value bundles. The record should include a replay test for missed contacts, full buffers, duplicate arrivals, and expired data.

Finally, make the record operational. Put the bundle fields, contact assumptions, and failure actions in the same runbook operators use after deployment. When a field technician sees an expired bundle counter rising or a carrier returning with a full buffer, the runbook should say whether to change TTL, reduce sampling, add storage, change the collection route, or escalate the application requirement.

11.9 Buffers Become the Network

In connected routing, a packet mostly lives in transit. In DTN, the packet may spend most of its life inside node storage. That makes buffer management, custody transfer, expiration, and contact prediction first-class network behavior rather than implementation details.

The buffer is not just a cache. It is a queue with durability, ordering, and deletion semantics. The implementation has to survive power loss during a write, keep enough metadata to resume after reboot, and avoid admitting a new bundle that forces out a more valuable one without following the configured drop rule. This is why persistent storage wear, flash capacity, and metadata integrity belong in the network review.

Custody is also a policy boundary, not a magic guarantee. A receiver that accepts responsibility may allow the sender to reclaim storage, but that receiver can still lose power, fill its buffer, miss the next contact, or expire the bundle before delivery. Practical systems therefore keep acknowledgement state, retry limits, and delivery reports separate from the physical act of copying bytes. A copied bundle is not necessarily a delivered bundle.

Contact prediction can be simple or sophisticated, but it must be testable. A bus schedule, a satellite pass table, a patrol route, historical encounter logs, or received-signal observations can all drive forwarding choices. The under-the-hood review should ask what evidence updates that prediction and what the system does when the prediction is wrong. Without that rule, the same bundle may be carried by the wrong node while a better carrier passes nearby.

• Persistent storage: bundles must survive sleep cycles, movement, reboot, and long gaps between contacts.
• Custody transfer: a receiver may take responsibility so the sender can reclaim storage, but custody does not guarantee success.
• Time-to-live: stale bundles should expire before they crowd out higher-priority or fresher messages.
• Contact economics: every contact window has limited time, bandwidth, energy, and competing bundles.

11.10 Prerequisites

Before diving into this chapter, you should be familiar with:

• Ad Hoc Routing: Proactive (DSDV): Understanding proactive routing protocols helps contextualize why traditional approaches fail in disconnected networks and how DTN fundamentally differs from table-driven routing
• Ad Hoc Routing: Reactive (DSR): Knowledge of on-demand routing and route discovery mechanisms provides the foundation for understanding why DTN requires store-carry-forward instead of immediate path establishment
• Ad Hoc Routing: Hybrid (ZRP): Zone-based routing concepts introduce the idea of handling disconnected network partitions, which DTN extends with mobility and opportunistic forwarding
• Multi-Hop Fundamentals: Multi-hop networking concepts and relay node behavior are essential background for understanding how DTN leverages mobile nodes as data carriers
• Networking Basics: Fundamental networking concepts, addressing, and packet forwarding provide the baseline understanding for how DTN modifies traditional end-to-end communication

We just separated intermittent connectivity from ordinary slow networking. Next, turn that distinction into disconnected ad hoc mechanics: why connected protocols fail, and what replaces them.

11.12 Continue to the Next Part

Carry this evidence into Delay-Tolerant Networks: Disconnected Operations, which begins with Disconnected Ad Hoc Networks.