41 Delay-Tolerant Networks for IoT
delay-tolerant networks, DTN for IoT, store carry forward, data mule, mobile relay, WSN mobility sensing
41.1 In 60 Seconds
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
Use Figure 41.1 to keep the store-carry-forward claim tied to review evidence.
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
Store-carry-forward is a delay ledger, not just a three-word pipeline. Use Figure 41.2 to follow a bundle across the useful evidence timestamps.
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
Use Figure 41.3 to summarize the review decision.
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.