12 Delay-Tolerant Networks: Disconnected Operations

emerging-paradigms

adhoc

dtn

12.1 Start With the Decision

This section: Start With the Decision

Sparse node density : Nodes too far apart for single-connected component 2.

12.2 Route Overview

This section: Route Overview — This is part 2 of 2.

This is part 2 of 2. Review Delay-Tolerant Networks: Design Principles for the preceding evidence.

12.3 Learning Objectives

This section: Learning Objectives

Test disconnected ad hoc networks with a concrete scenario and pass criteria.
Validate custody transfer is not delivery with a concrete scenario and pass criteria.

12.4 Chapter Roadmap

This section: Chapter Roadmap

Disconnected Ad Hoc Networks
Store-Carry-Forward Principle
Mobile Summary: Store-Carry-Forward
Checkpoint: Store-Carry-Forward Fit
DTN vs Traditional Networking
DTN Contact Window Calculator
Knowledge Check
Quiz: Store-Carry-Forward Principle
Test Your Understanding
DTN Buffer Sizing for Tracking
Checkpoint: Contact and Buffer Budget
Putting Numbers to It
Concept Relationships
See Also
Interactive Quiz: Match Concepts
Interactive Quiz: Sequence the Steps
Common Pitfalls
Why Internet Design Fails DTN
DTN vs Delay-Insensitive Apps
DTN Buffer Management
Custody Transfer Is Not Delivery
Label the Diagram
Code Challenge
Summary
What’s Next
Key Takeaway

12.5 Disconnected Ad Hoc Networks

This section: Disconnected Ad Hoc Networks — Traditional routing protocols (DSDV, DSR, ZRP) assume a connected path exists between source and destination.

Time: ~10 min | Difficulty: Intermediate | Unit: P04.C01.U01

Traditional routing protocols (DSDV, DSR, ZRP) assume a connected path exists between source and destination. This assumption fails in many IoT scenarios.

12.5.1 Connected vs Disconnected Networks

Disconnected Network Causes:

Sparse node density: Nodes too far apart for single-connected component
Node mobility: Moving nodes create temporary islands
Sleep scheduling: Duty-cycling creates temporal disconnections
Harsh environment: Obstacles, terrain block connections
Failure: Node/link failures partition network

Traditional Protocols Fail:

DSDV: Can’t maintain routes across partitions
DSR: Route discovery fails if no connected path
Packets dropped at partition boundaries

12.5.2 Delay-Tolerant Networks (DTN)

Delay-Tolerant Networks enable communication across disconnected networks using store-carry-forward paradigm.

Inspect Figure 12.1 from the source buffer through the mobile carrier to the base station. The contact windows occur only at the first handoff and final delivery; between them, the carrier moves through a disconnected region while persistent storage protects the bundle.

Four-stage DTN store-carry-forward diagram showing a source storing a bundle, a mobile carrier receiving it during a contact window, the carrier moving across a disconnected region, and a later contact delivering the bundle to the base station. — Figure 12.1: DTN store-carry-forward phases from source buffer to destination delivery

The four stages in Figure 12.1 explain why an end-to-end route is unnecessary: store before the first partition, forward during a short encounter, carry across the gap, and deliver at a later encounter. Buffer capacity and expiry policy therefore replace continuous reachability as the immediate design constraints.

Store-Carry-Forward Principle

Mobile Summary: Store-Carry-Forward

Store: Keep the bundle in persistent local storage instead of dropping it.
Carry: Let the device, vehicle, animal, or person move with the bundle.
Forward: Transfer the bundle during a short contact window.
Deliver: The final carrier reaches a base station, gateway, or destination node.

The Bundle Protocol packages application data into self-contained bundles that can survive long storage periods and multiple opportunistic contacts. Some DTN architectures also use optional custody-transfer mechanisms; accepting custody is not final delivery.

Store: : Intermediate nodes buffer packets (store in local memory)

Carry: : Mobile nodes physically transport packets while moving

Forward: : When encountering new nodes, forward buffered packets

Key Difference from Traditional:

Traditional: Immediate hop-by-hop forwarding
DTN: Opportunistic forwarding when contact opportunities arise
Tolerates disconnections by accepting storage delays

Typical contact sequence:

The source records data and stores it as a bundle.
A mobile carrier enters radio range during a contact window.
The source forwards the bundle to the carrier.
The carrier physically moves toward another region.
A later contact with a base station or better relay completes delivery.

DTN Application Scenarios:

Wildlife tracking: Animals carry sensors, transfer data when near base stations
Vehicular networks: Cars carry messages between disconnected road segments
Rural IoT: Mobile collectors (buses, delivery vehicles) gather sensor data
Disaster recovery: Intermittent connectivity due to infrastructure damage
Space networks: Planetary exploration with extreme propagation delays

Blueprint Bina, Architecture and system-design domain expert

Checkpoint: Store-Carry-Forward Fit

You now know:

DSDV, DSR, and ZRP assume connected paths; they fail when partitions cannot exchange route messages.
DTN preserves the bundle locally, carries it on a mobile node, and forwards it during a later contact.
The correct fit is a delay-tolerant mission: wildlife tracking, vehicular networks, rural IoT, disaster recovery, or space networks.

DTN vs Traditional Networking

12.6 DTN Contact Window Calculator

This section: DTN Contact Window Calculator — The calculator gives the contact budget.

Estimate how much data can be exchanged during an opportunistic DTN contact:

The calculator gives the contact budget. The checks below ask the same question without sliders: can a future contact and local buffer keep the data useful?

12.7 Knowledge Check

This section: Knowledge Check — Test your understanding of DTN fundamentals.

Test your understanding of DTN fundamentals.

Quiz: Store-Carry-Forward Principle

Test Your Understanding

12.8 DTN Buffer Sizing for Tracking

This section: DTN Buffer Sizing for Tracking — Scenario: A conservation team deploys GPS collars on 80 elephants across a 2,500 km^2^ wildlife reserve in Amboseli, Kenya.

Scenario: A conservation team deploys GPS collars on 80 elephants across a 2,500 km^2^ wildlife reserve in Amboseli, Kenya. Each collar collects GPS coordinates every 30 minutes and must deliver data to 3 base stations positioned at watering holes. Elephants encounter other elephants or base stations opportunistically. Design the DTN buffer, estimate delivery latency, and calculate the required battery budget.

The collar photo grounds the sizing assumptions in a constrained field device: the antenna, electronics enclosure, and battery must carry both sensing and opportunistic relay work. Each 32-byte record waits locally until another collar or one of the three base stations creates a usable contact window.

An African wild dog walks across rocky ground wearing a broad tracking collar, with another wild dog following behind. The photo shows the collar on the animal but does not reveal its antenna, battery, or electronics. — A GPS tracking collar of the kind this worked example sizes a DTN buffer for. The collar carries its own radio and battery, storing each 32-byte GPS reading until an opportunistic contact with another collared animal or a base station lets it relay the data onward. Photo: Kengitau254, CC BY-SA 4.0

Use the pictured collar as the boundary for the calculation below. Its buffer must survive the 4.2-day average base-station interval and the extra copies created by spray-and-wait, while its radio budget must cover brief exchanges without assuming a continuously reachable route.

Given parameters:

GPS reading size:           32 bytes (lat/lon/time/battery)
Collection interval:        30 minutes (48 readings/day)
Average inter-contact time: 18 hours (elephant-to-elephant)
Average elephant-to-base:   4.2 days (based on movement patterns)
Message copies (spray-and-wait): L = 6 copies per reading
Radio: CC2650 dual-mode BLE/IEEE 802.15.4; discovery uses BLE advertising/scanning and payload transfer uses IEEE 802.15.4 after an explicitly designed mode switch.
Contact duration:           45 seconds average (watering hole overlap)
Assumed payload PHY rate:   250 kbps
Battery: 3.6V D-cell lithium (19,000 mAh)
Collar lifetime target:     3 years

Step 1 — Per-collar daily data generation:

Own data:     48 readings/day x 32 bytes = 1,536 bytes/day
With headers: 48 x (32 + 12 byte DTN header) = 2,112 bytes/day

Step 2 — Buffer sizing for spray-and-wait (L=6):

Each collar carries its own data PLUS replicas received from other elephants. In source spray-and-wait with L=6 total copies, the source keeps one copy and gives one copy to each of five distinct elephant contacts. These six holders then wait for direct base-station contact. Each collar may carry copies for multiple other elephants.

Maximum delivery delay:       14 days (worst case before data expires)
Own data buffered:            14 days x 2,112 bytes = 29,568 bytes
Relay data from contacts:     Estimated 5 other elephants' copies at any time
                              5 x 14 days x 2,112 bytes = 147,840 bytes
Total buffer required:        29,568 + 147,840 = 177,408 bytes ~ 173 KiB
CC2650 RAM: 20 KB (insufficient) -> use external 256 KB SPI flash

Step 3 — Contact capacity analysis:

Data per contact window:    45 sec x 250 kbps / 8 = 1,406,250 bytes
                            (far exceeds buffer size -- not a bottleneck)
Spray phase:                Source keeps one copy and transfers the other
                            5 copies to five distinct contacts (six holders)
Wait phase:                 All six holders wait for base station contact

This section:

Checkpoint: Contact and Buffer Budget

You now know:

The elephant example generates 2,112 bytes/day with headers and needs about 173 KiB after five relay copies.
A 45 second contact at 250 kbps can move 1,406,250 bytes, so contact capacity is not the bottleneck in this scenario.
L=6 source spray-and-wait leaves six holders, including the source, after five relay transfers.
Under the stated independent-contact assumptions, the simplified spray-plus-wait phase means sum to about 17.97 hours; this is not measured field performance.

This section: — This simplified phase sum excludes base-station delivery during spraying and is not measured field performance.

Step 4 — Illustrative source-spray phase sum:

For spray-and-wait with L copies among N=80 elephants and 3 base stations:

Mean inter-contact rate (elephant-elephant): lambda_ee = 1/18 hr^-1
Mean inter-contact rate (elephant-base):     lambda_eb = 1/(4.2 x 24) hr^-1
                                                       = 1/100.8 hr^-1

Illustrative source-spray phase sum (independent exponential pair contacts,
no base delivery during spraying):
  T_spray = 18/79 + 18/78 + 18/77 + 18/76 + 18/75
          = 1.17 hours (five new relays)
  T_wait  = 100.8/6 = 16.8 hours (six holders)
  Sum of phase means = 1.17 + 16.8 = 17.97 hours (~0.75 day)

This simplified phase sum excludes base-station delivery during spraying and is not measured field performance. Compare it with delivery requirements only after validating detected-contact rates.

Step 5 — Energy budget for 3-year lifetime:

Radio contacts per day:     ~1.3 (1/18 hr inter-contact x 24 hr)
TX per contact:             2,112 bytes own + ~2,112 bytes relay = 4,224 bytes
TX time per contact:        4,224 x 8 / 250,000 = 0.135 seconds
RX time per contact:        ~0.135 seconds (receiving relay data)
Discovery beacon (BLE):     Every 5 min, 1 ms at 10 mA = 0.01 mAs each
                            288 beacons/day x 0.01 mAs = 2.88 mAs/day

Daily energy:
  TX:       1.3 contacts x 0.135 s x 10 mA = 1.755 mAs
  RX:       1.3 contacts x 0.135 s x 6 mA  = 1.053 mAs
  Beacons:  2.88 mAs
  GPS:      48 fixes x 30 mA x 1 s = 1,440 mAs  (dominates!)
  Sleep:    86,400 s x 1 uA = 86.4 mAs
  MCU wake: 48 x 3 mA x 0.5 s = 72 mAs
  ----------------------------------
  Total:    1,604 mAs/day = 0.446 mAh/day

3-year budget: 0.446 x 1,095 days = 488 mAh
Battery:       19,000 mAh (D-cell lithium)
Margin:        19,000 / 488 = 38.9x safety factor

GPS acquisition dominates this nominal ledger (89.8% of included charge). It omits receiver scanning, BLE/IEEE 802.15.4 mode switching, and failed discovery attempts, so its 38.9x value is not a demonstrated field battery margin. Measure and include these costs before making battery or delivery claims.

Step 6 — Delivery reliability analysis:

After all six copies have been distributed, assume each holder independently reaches a base at aggregate rate 1/100.8 h^-1 and every contact is detected. For a further 14 days of waiting:
  P(all six miss) = exp[-6 x 336/100.8] = exp(-20) = 2.061 x 10^-9
  P(delivery during that wait interval) = 99.9999998%

  For 80 elephants x 48 readings/day x 365 days = 1,401,600 readings/year
  This idealized conditional miss rate corresponds to 0.00289 misses/year.

A 14-day deadline measured from reading creation needs the spray time and any delivery during spraying included separately. This conditional model result is not field reliability or a count of actual lost readings.

This section:

Putting Numbers to It

After all $L$ source-spray copies have been distributed, assume independent exponential base contacts at rate $\lambda_{eb}$ per holder. The mean wait for at least one detected base contact is:

$T_{wait} = \frac{1}{L \times \lambda_{eb}}$

where $\lambda_{eb}$ is the per-holder elephant-to-base contact rate ( $1/100.8$ hr $^{-1}$ here). With $L=6$ holders, this gives $T_{wait} = 16.8$ hours after spraying.

For a further 14-day wait interval after spraying, the probability that all $L$ holders miss every detected base contact is:

$P_{fail} = \left(e^{-\lambda_{eb} \times 336}\right)^L = e^{-L \times 336/100.8}$

For this conditional wait model, $L=2$ gives 99.873% delivery, $L=4$ gives 99.99984%, $L=6$ gives 99.9999998%, and $L=8$ gives about 99.9999999997%. These are ideal model outputs, not field reliability or 14-day-from-creation guarantees.

This section: — Decision: Use spray-and-wait with L=6 and a 256 kB SPI flash buffer.

Decision: Use spray-and-wait with L=6 and a 256 kB SPI flash buffer. A five-minute beacon period cannot justify the assumed 45-second contacts: even with continuous receiver scanning, a randomly timed contact contains a beacon at most 45/300 = 15% of the time. Measure a beacon-and-scan schedule before claiming field delivery latency, reliability, or a three-year battery margin; receiver scanning is absent from the energy budget.

Historical context: Wildlife-tracking DTN work such as ZebraNet demonstrated the core design pattern used here: animals store sensor data, exchange it opportunistically, and eventually deliver it when one carrier reaches a collection point. The exact delivery ratio depends on mobility, contact rate, radio range, buffer size, and copy policy, so field deployments should validate those parameters with local movement traces before choosing $L$ .

12.9 Concept Relationships

This section: Concept Relationships

Key relationships to keep straight:

Store-carry-forward enables communication when no continuous end-to-end path exists.
Opportunistic forwarding transfers data only during brief contact windows.
The DTN paradigm treats disconnection as normal, not as a TCP/IP-style failure condition.
Buffer management determines how long data can survive extended storage periods.
Contact prediction uses mobility patterns to improve forwarding decisions.

12.10 See Also

This section: See Also

DTN Epidemic Routing - Flooding-based delivery strategies
DTN Social Routing - Context-aware forwarding optimization
DTN Applications - Real-world deployments and use cases
Ad Hoc Routing: Reactive (DSR) - Connected network on-demand routing
Multi-Hop Fundamentals - Foundation for relay communication

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

Common Pitfalls

This section: Common Pitfalls — The exercises checked the mechanics; the audit panel checks the arithmetic before epidemic or social routing adds copy policy and contact prediction.

Why Internet Design Fails DTN

DTN violates fundamental Internet assumptions: end-to-end paths may not exist, ACKs may take hours, and connections close between packets. TCP/IP protocols fail in DTN environments. DTN requires designing around contact opportunities rather than continuous connectivity.

DTN vs Delay-Insensitive Apps

DTN is not a way to make any application work with delays. Applications must be designed to function with minutes-to-hours of delivery delay. Email works in DTN; real-time video does not. Identify which components of your application are delay-tolerant before deciding to use DTN.

DTN Buffer Management

DTN nodes accumulate messages waiting for delivery opportunities. Without systematic buffer management (priority queues, TTL enforcement, drop policies), storage fills and new important messages cannot be accepted. Buffer management is a first-class design concern in DTN, not an optimization.

Custody Transfer Is Not Delivery

Custody transfer means the receiver takes responsibility for delivery — but if all nodes holding custody of a message exhaust their buffers or fail before delivery, the message is lost. DTN custody transfer improves reliability over hop-by-hop but does not provide absolute delivery guarantees.

Label the Diagram

Code Challenge

The exercises checked the mechanics; the audit panel checks the arithmetic before epidemic or social routing adds copy policy and contact prediction.

12.11 Summary

This section: Summary

This chapter introduced the fundamentals of Delay-Tolerant Networks:

Disconnected Networks: Traditional routing protocols (DSDV, DSR, ZRP) fail when no continuous path exists between source and destination, which occurs in sparse deployments, high mobility, sleep scheduling, and harsh environments
DTN Paradigm: Unlike traditional networking that assumes connectivity, DTN assumes disconnection is normal and designs around it using store-carry-forward
Store-Carry-Forward: The core DTN mechanism where nodes buffer packets locally (store), physically transport them while mobile (carry), and transfer them opportunistically when encountering other nodes (forward)
Key Distinction: DTN isn’t “slow networking” - it’s intermittent connectivity networking where latency is the accepted price of operation in infrastructure-less environments
Application Scenarios: Wildlife tracking, vehicular networks, rural IoT, disaster recovery, and space communications all benefit from DTN’s tolerance of disconnection

12.12 What’s Next

This section: What’s Next

Study epidemic routing algorithms: DTN Epidemic Routing
Explore social routing for DTN: DTN Social Routing
Learn about DTN applications: DTN Applications
Compare with reactive ad hoc routing: DSR Fundamentals and Route Discovery
Compare emerging network deployment choices: Deploying Ad-Hoc Networks

12.13 Key Takeaway

This section: Key Takeaway — DTN fundamentals start with the assumption that end-to-end paths may not exist.

DTN fundamentals start with the assumption that end-to-end paths may not exist. Store-carry-forward behavior, contact opportunities, delivery deadlines, and buffer policy define whether the network can meet the mission.

12.14 Continue Your Route

This section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to Delay-Tolerant Networks: Design Principles or continue from the emerging-paradigms module index.

Find help

Search reviewed answers

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed 2026-10-16

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed 2026-10-16

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed 2026-10-16