41 Delay-Tolerant Networks for IoT

iot

wireless-sensor-networks

mobility-sensing

41.1 In 60 Seconds

41.1.1 Let Data Wait Without Losing Its Story

A park ranger walks past remote river monitors once each week. There is no continuous path from the valley to the office. Each monitor can store a reading, the ranger’s device can carry it, and the office can receive it later. The useful question is whether that delay still supports the environmental decision.

Name the claim before choosing this pattern. State the oldest acceptable reading, which events may expire, how much can be stored, who carries custody, and how copies are recognized. Keep source, event time, unit, quality, and expiry with every reading. Urgent danger that cannot wait needs another local or immediate path.

Then disturb the contact plan. Miss one ranger visit. Fill a monitor’s storage. Repeat a transfer. Change the carrying device’s clock. Deliver an older copy after a newer one. Check loss, order, duplicates, energy, and the visible age at the office. Record who follows up when an expected contact does not occur.

Carry-later delivery cannot promise a live path or a fixed arrival time without measured contact evidence. It is honest when the decision can wait and the record preserves meaning. The deeper sections compare direct, limited-copy, flooding, and history-based forwarding, plus custody, storage, safety, and security limits.

The field record should answer: What can wait? How long can it wait? What must never wait? Who carries the data? When is contact expected? How much can each device hold? Which copy is the first useful copy? When does a record expire? Who investigates a missed visit? What safe action stays at the source?

Use a calendar as part of the test. Miss one planned contact. Arrive early. Arrive late. Use a different ranger. Lose one carrying device. Fill one store. Restore an old copy. Check whether the office sees source time rather than carry time. Check whether a duplicate changes a report. Keep the missed-contact alert separate from the delayed science record.

The strongest design admits where waiting is safe and where it is not. A weekly water trend may survive. A fire warning may not. Put urgent action near the event or provide another path. Use carry-later delivery for evidence whose value remains after the measured delay, and test that claim again when routes or seasons change.

A delay-tolerant network lets a WSN or IoT system move data even when no end-to-end path exists at the moment the data is created. A node stores the message, a person, vehicle, animal, robot, buoy, or mobile sink carries it through the environment, and the message is forwarded when a useful contact occurs.

Good DTN review starts with the monitoring claim. The claim should say what delay is acceptable, what data can expire, which contacts are expected, how buffers are protected, which routing rule controls copies, who owns missed contacts, and what evidence proves the system is not silently losing stale or duplicated readings.

41.2 Learning Objectives

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

Explain store-carry-forward as a WSN evidence claim rather than a slogan.
Decide when a DTN pattern fits better than continuous multi-hop routing or always-on backhaul.
Compare direct delivery, limited-copy forwarding, flooding, and history-informed forwarding without overclaiming their results.
Review contact, buffer, custody, freshness, duplicate, energy, and security evidence for a DTN deployment.
Build a DTN evidence record with an owner, accepted delay, known limits, and retest triggers.

41.3 Delay-Tolerant IoT Networks

41.4 Start With the Delay Claim

The first review question is not “which DTN protocol?” It is “what delay can the sensing decision tolerate?” DTN is useful only when the decision can wait for intermittent contact. A soil trend, wildlife track, maintenance log, or remote clinic batch can often wait. A fire alarm, hazardous gas alert, active safety interlock, or emergency shutdown usually cannot.

Accepted delay State the maximum age of data that still supports the decision. Separate routine trend review from alerting.

Contact opportunity Name the people, vehicles, animals, drones, ships, or mobile sinks that create contacts, and how often those contacts are expected.

Custody boundary State when a node may delete a message, when it must retain a copy, and what evidence proves a handoff succeeded.

Freshness boundary Define time-to-live, expiration, and whether old readings should be uploaded, summarized, or discarded.

Copy boundary Limit how many copies can exist and how duplicates are detected when multiple carriers reach the same gateway.

Operations boundary Assign who responds when contacts stop happening, buffers fill, batteries drain, or gateways miss expected uploads.

If the system cannot state those boundaries, it is not ready for a DTN claim. It may still be a useful experiment, but the learner should not accept it as a reliable production design.

41.5 DTN Review Route

To challenge DTN Review Route, examine the visual at Figure 41.1. Its Data and Claim labels reveal WSN delay-tolerant network review route.

WSN delay-tolerant network review route from data claim through accepted delay, contact evidence, buffer and custody, routing choice, freshness and duplicates, operations response, decision, and retest trigger. — Figure 41.1: WSN delay-tolerant network review route

Within Figure 41.1, compare Data—which marks preserved information—with Claim, which names a responsibility. Then inspect Accepted because it names a responsibility. Placing Data before Accepted reveals the dependency in WSN delay-tolerant network review route. The DTN Review Route evidence record should retain Claim.

The route is a loop. A changed route schedule, new carrier behavior, firmware update, gateway move, larger payload, shorter reporting deadline, new data sensitivity, or missed-contact incident can reopen the decision.

41.6 Store-Carry-Forward Evidence

The next Store-Carry-Forward Evidence step depends on DTN store-carry-forward sequence. Read Figure 41.2 first, focusing on Store-Carry-Forward in a DTN and Store.

Four-stage DTN store-carry-forward sequence where a source stores a bundle, a carrier moves with it, forwards it during a brief encounter, and a relay delivers it to a base station. — Figure 41.2: DTN store-carry-forward sequence

Three labels control the Figure 41.2 visual: Store-Carry-Forward in a DTN names a responsibility; Store names a responsibility; Source collar marks information entry. Placing Store-Carry-Forward in a DTN before Source collar reveals the dependency in DTN store-carry-forward sequence. For Store-Carry-Forward Evidence, retain Store when applying this result.

The budget starts at sampling time, not upload time. A record can spend time waiting in the source buffer, waiting for a carrier contact, transferring during a short encounter, waiting in the carrier buffer, waiting for gateway contact, and waiting for backend processing. A successful transfer can still fail the sensing claim if the record is too old for the decision.

Keep three ages separate during review. Measurement age is the time since the sensor observed the condition. Custody age is the time since the current holder accepted responsibility for the message. Dashboard age is the time since the backend last received or displayed the record. A wildlife-movement study may tolerate large measurement age for historical analysis, while a trail safety dashboard may tolerate old custody age only for archive review. Each claim needs a named age limit.

Store-carry-forward has three evidence points. Each point can fail independently.

Store The sensing node or local gateway keeps messages safely until contact. Review buffer size, power loss behavior, message age, encryption, and deletion rules.

Carry The mobile carrier moves through useful places. Review route regularity, contact windows, environmental constraints, safety, and whether mobility assumptions are still true.

Forward The message transfers when contact occurs. Review radio range, handshake time, retry behavior, custody receipt, duplicate control, and gateway upload evidence.

A DTN design can look good on paper while failing because contact time is too short, the carrier bypasses a stop, a buffer fills before the next visit, the gateway clock drifts, or a node deletes data after an unverified handoff. The review should make those failure modes visible.

41.7 Intermittent Contact Routing

DTN forwarding rules trade delivery confidence against storage, airtime, energy, duplicate work, and privacy exposure. Avoid treating one rule as universally best.

Direct delivery The source keeps the message until it meets the destination or gateway. This is simple and low overhead, but delay can be long and missed contacts can block delivery.

Limited-copy forwarding A bounded number of copies are handed to selected carriers. This improves delivery chances while keeping buffer, airtime, and duplicate risk reviewable.

Flooding Messages are copied broadly across contacts. This can be appropriate for rare high-importance messages, but it can exhaust buffers and expose sensitive data.

History-informed forwarding Messages move toward carriers with stronger observed contact history. This depends on stable mobility and useful encounter records.

Mobile sink collection A planned carrier visits static nodes and retrieves stored readings. Review route coverage, stop duration, gateway health, and missing-zone alerts.

Hybrid forwarding Routine data uses limited copies while exceptional data gets a different rule. Review the trigger carefully so emergency-style copying is not used for every message.

The accepted rule should follow the data claim. Trend data can usually tolerate tighter copy limits. Rare safety-relevant messages may justify more aggressive forwarding only if the system also reviews energy, congestion, and privacy consequences.

Before accepting a routing rule, review copy count, time-to-live, payload size, and queue policy as one shared resource budget.

Design dial	What it improves	What it risks	Evidence needed
More copies	Higher chance that one carrier reaches a gateway	More buffer pressure, duplicate work, energy use, and exposure	Copy count, duplicate merge rule, and delivery gain versus overhead
Longer TTL	More time for rare contacts to occur	Stale records can crowd buffers or be mistaken for current data	Accepted delay, expiration label, and stale-dashboard behavior
Larger payload	More detail per encounter	Transfer may not complete in the contact window	Payload-size test with discovery, security, retry, and confirmation overhead
History-informed forwarding	Copies move toward carriers with better encounter history	History can become stale after route or season changes	Recent contact ledger and retest trigger for mobility changes

41.8 Contact and Buffer Evidence

A DTN is only as strong as its contact evidence and buffer discipline. Review should include observed or tested contacts, not just assumed movement.

Ask these questions:

Which node, carrier, or gateway is expected to meet which other component? How long does a useful contact last, and how much payload can be transferred in that window? What happens when a carrier misses a planned route or arrives with a full buffer? Can a node prove that custody transferred before deleting its local copy? Are old readings expired or marked stale before a dashboard treats them as current? Are duplicates, repeated reports, and partial transfers visible to the backend? Are identifiers, locations, and payloads protected while data is carried?

For expected encounters, record a contact-and-custody ledger with enough detail to expose missed, partial, stale, or unsafe transfer claims.

Review field	Evidence to collect	Failure it exposes
Contact window	Observed duration, discovery time, association time, handshake overhead, and usable payload bytes	The carrier passes close enough to detect but not long enough to finish transfer
Buffer margin	Queued messages, maximum age, free storage, dropped-message counter, and power-loss behavior	Old or large batches silently evict newer or more important data
Custody receipt	Message id, source copy state, carrier acceptance, gateway confirmation, and retry rule	A source deletes after an interrupted or unconfirmed handoff
Freshness label	Measurement time, transfer time, gateway time, expiration rule, and dashboard age label	Delayed readings are displayed as current evidence
Route owner	Expected visit pattern, missed-contact alert, maintenance response, and retest trigger	No one notices when route behavior, payload size, or gateway health changes

Contact evidence should be checked after route changes, seasonal access changes, different participant behavior, gateway relocation, antenna changes, larger payloads, or firmware updates.

41.9 DTN Evidence Record

A list cannot settle DTN Evidence Record alone. Inspect Figure 41.3, where Delay and Claim make WSN delay-tolerant network evidence record concrete.

WSN delay-tolerant network evidence record showing delay claim, contact evidence, buffer and custody, routing rule, freshness rule, duplicate control, security boundary, owner, and retest trigger. — Figure 41.3: WSN delay-tolerant network evidence record

At Figure 41.3, Delay names a responsibility; moving to Claim shows how it names a responsibility. The Contact label names a responsibility. Retaining both Delay and Contact makes WSN delay-tolerant network evidence record auditable. The running DTN Evidence Record argument therefore preserves Claim.

Claim: State the data age and decision the DTN path is allowed to support.

Evidence: Attach contact observations, buffer limits, transfer tests, custody behavior, freshness rules, duplicate handling, and security boundaries.

Decision: Accept, narrow, reject, or retest the DTN claim with an owner and response plan.

Retest: Name the route, payload, policy, firmware, gateway, carrier, or incident change that reopens review.

The record should be understandable by networking, operations, and data users. A dashboard user must know when data is delayed, stale, missing, duplicated, or outside the accepted claim.

41.10 Worked Review: Wildlife Collar Uploads

A wildlife study uses collars that store location summaries and upload when an animal passes near a water-station gateway. The team wants to use the data for movement-pattern research, not live animal rescue.

Review the claim:

Delay fit Pattern research can accept delayed uploads if the dashboard labels data age. Live intervention would require another communication path.

Contact evidence Water-station visits should be observed across seasons. A dry-season route may not prove wet-season contact behavior.

Buffer evidence The collar should retain enough summarized readings for expected contact gaps, with visible age and dropped-message counters.

Custody evidence The collar should not delete records until the gateway confirms receipt. Duplicate uploads should be merged by message id and timestamp.

Finding: accept the DTN path for delayed movement research if the record includes contact observations, buffer capacity, receipt confirmation, data-age labeling, and a field response when expected gateways stop seeing uploads. Reject any live-response claim unless another path is reviewed.

41.11 Worked Review: Clinic Data Mule Route

A rural clinic network stores daily sensor and inventory records on local kiosks. A scheduled vehicle passes clinics and uploads batches to a district gateway when it returns.

Review the claim:

Delay fit Daily reporting can fit DTN if dashboard users see collection time and missing-clinic status. Urgent clinical alerts need a separate channel.

Route evidence The vehicle route, stop duration, kiosk Wi-Fi range, and transfer completion should be tested with the real payload size.

Failure evidence The record should show what happens when the vehicle misses a clinic, the kiosk loses power, or the gateway is offline.

Security evidence Records carried on the vehicle should be encrypted, access-controlled, and deletable only after verified upload.

Finding: accept for non-urgent batch reporting with clear missing-data status, custody receipts, retries, and an operations owner. Narrow the claim if the team wants real-time surveillance or emergency response.

41.12 Common DTN Review Mistakes

Calling delayed data live A DTN path can be useful and still not be current enough for alerts, dispatch, or safety control.

Counting contacts without transfer evidence Passing near a gateway is not enough. Contact duration, radio behavior, retries, and payload completion matter.

Ignoring buffer pressure Longer gaps, larger payloads, duplicate copies, or failed handoffs can silently fill storage and drop old data.

Deleting without custody proof If a node deletes after an unverified transfer, the system can lose data while reporting no obvious fault.

Using flooding as a default Broad copying can waste power, fill buffers, duplicate work, and expose sensitive payloads.

Forgetting operations ownership Someone must own missed contacts, stale dashboards, gateway repair, route changes, and retest decisions.

41.13 Review Checklist

Use this checklist before accepting a DTN path in a WSN or IoT deployment.

Claim and delay Accepted data age, decision scope, excluded live uses, and time-to-live rules are explicit.

Contact evidence Expected contacts, contact duration, route behavior, missed-contact detection, and season or schedule assumptions are recorded.

Storage and custody Buffer limits, power-loss behavior, handoff receipts, deletion rules, and retry behavior are tested.

Routing and copies Copy limits, forwarding rule, duplicate detection, congestion risk, and emergency exceptions are justified.

Security and privacy Payload encryption, carrier access, identifiers, location sensitivity, and lost-device response are covered.

Operations handoff Owner, dashboard status, maintenance response, missing-data alerts, and retest triggers are named.

41.14 Knowledge Check: Delay Fit

41.15 Knowledge Check: Custody Boundary

41.16 Copy and Freshness Budget

41.17 Matching: DTN Review Evidence

41.18 Ordering: DTN Review Route

41.19 Summary

Delay-tolerant networking is a useful WSN and IoT pattern when useful data can wait for intermittent contacts. The review should not stop at naming store-carry-forward. It should prove that storage, mobility, forwarding, custody, freshness, copy limits, security, and operations ownership fit the decision being made.

Use DTN for delayed evidence such as trend summaries, field logs, batch uploads, and mobility-assisted collection. Narrow or reject DTN claims when the data must support live alarms, immediate control, or decisions that cannot tolerate stale or missing readings.

41.20 Key Takeaway

Delay-Tolerant Networks for IoT should treat people, delay, consent, data quality, custody, privacy, intermittent connectivity, and deployment evidence as part of the sensing architecture.

41.21 Concept Relationships

DTN extends Human-Centric Sensing when people, vehicles, animals, or carried devices act as mobile carriers. DTN can support MWSN Types and Mobile Entities when static nodes rely on mobile sinks or data mules. DTN review complements WSN Mobile Coverage Optimization because mobility can improve collection while introducing route and contact bias. DTN forwarding must still respect WSN Communication evidence: radio range, traffic load, acknowledgments, and gateway behavior.

41.22 What’s Next

Human-Centric Sensing and Participatory Sensing connect DTN with human-carried and participatory sensing patterns. Participatory Sensing examines intentional human data contribution and platform evidence. WSN Mobile Sinks reviews production mobile collection paths and operations handoff.