12 Delay-Tolerant Networks: Disconnected Operations

emerging-paradigms

adhoc

dtn

12.1 Start With the Decision

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

12.2 Route Overview

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

12.3 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

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
Answer
Answer
Answer
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

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, custody transfer decisions, and multiple opportunistic contacts.

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

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

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

Test your understanding of DTN fundamentals.

Quiz: Store-Carry-Forward Principle

Test Your Understanding

Question 1: What is the fundamental assumption that distinguishes DTN from traditional TCP/IP networking?

a) DTN assumes faster hardware is available b) DTN assumes no end-to-end connected path exists at any single moment c) DTN assumes all nodes are stationary d) DTN assumes unlimited bandwidth is available

Answer

b) DTN assumes no end-to-end connected path exists at any single moment. Traditional TCP/IP requires a continuous path from source to destination; packets are dropped if the path breaks. DTN fundamentally accepts that disconnection is the norm and uses store-carry-forward to deliver data despite having no simultaneous end-to-end connectivity.

Question 2: In the store-carry-forward paradigm, what does the “carry” phase involve?

a) Compressing data to reduce packet size b) Encrypting data for secure transmission c) A mobile node physically transporting buffered data while moving d) Forwarding packets through a series of routers

Answer

c) A mobile node physically transporting buffered data while moving. This is what makes DTN unique: data literally travels inside a device (person, vehicle, animal) as it moves through the physical world. The three phases are: store (buffer locally), carry (physically move), forward (transfer to another node upon contact).

Question 3: Why would traditional routing protocols (DSDV, DSR, ZRP) fail in a wildlife tracking deployment where GPS-collared animals roam 5-20km apart?

a) The protocols are too slow for animal movement speeds b) Animals cannot carry routing hardware c) No continuous radio path exists between distant animals, so route discovery fails immediately d) The protocols consume too much energy for animal collars

Answer

c) No continuous radio path exists between distant animals. With radio range of ~100m and animals 5-20km apart, there is no connected multi-hop path. DSDV cannot maintain routing tables across partitions, DSR route discovery floods fail because they cannot reach disconnected segments, and ZRP has the same limitation. Only DTN’s store-carry-forward works: data waits until animals physically encounter each other.

12.8 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. 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.

A wild animal wearing a wide GPS tracking collar with a visible antenna and battery/electronics module — 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 BLE (10 mA TX, 6 mA RX, 1 uA sleep)
Contact duration:           45 seconds average (watering hole overlap)
Radio data rate:            250 kbps (802.15.4)
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. With spray-and-wait, a source creates L=6 copies and distributes them to the first L/2 = 3 contacts. 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 3 other elephants' copies at any time
                              3 x 14 days x 2,112 bytes = 88,704 bytes
Total buffer required:        29,568 + 88,704 = 118,272 bytes ~ 128 KB
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 distributes L/2 = 3 copies in first
                            3 contacts (1 copy per contact)
Wait phase:                 Each copy holder waits for base station contact

Checkpoint: Contact and Buffer Budget

You now know:

The elephant example generates 2,112 bytes/day with headers and needs about 128 kB after 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 spray-and-wait creates three wait-phase copies, trading extra storage for shorter expected delivery delay.

Step 4 — Expected delivery latency (Groenevelt model):

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

Expected delivery delay (spray phase + wait phase):
  T_spray = H(L/2) / (N x lambda_ee)
          = H(3) / (80 x 1/18)
          = (1 + 1/2 + 1/3) / 4.44
          = 1.833 / 4.44
          = 0.41 hours (25 minutes to distribute 3 copies)

  T_wait  = 1 / (L/2 x lambda_eb + (N-L/2) x lambda_ee x lambda_eb / ...)
          ~ 1 / (3 x 1/100.8)    (simplified: 3 copies seeking base)
          = 33.6 hours = 1.4 days

  Total expected delay: 0.41 + 33.6 = 34.0 hours ~ 1.4 days

This is acceptable for ecology research where weekly data collection was the prior baseline.

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 energy (89.7% of budget). The DTN radio component adds only ~0.36% overhead, confirming that store-carry-forward is extremely energy-efficient — the radio sleeps >99.99% of the time.

Step 6 — Delivery reliability analysis:

With L=6 copies and 3 base stations:
  P(at least one copy reaches base within 14 days):
  P(single copy fails) = e^(-14 x 24 / 100.8) = e^(-3.33) = 0.036
  P(all 3 wait-copies fail) = 0.036^3 = 4.6 x 10^-5
  P(delivery) = 1 - 4.6 x 10^-5 = 99.995%

  For 80 elephants x 48 readings/day x 365 days = 1,401,600 readings/year
  Expected lost readings: 1,401,600 x 4.6 x 10^-5 = 64 readings/year (0.005%)

Putting Numbers to It

For spray-and-wait routing with $L$ copies among $N$ nodes and $M$ base stations, delivery probability follows an exponential contact process. The expected delivery delay for a single copy is:

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

where $\lambda_{eb}$ is the elephant-to-base contact rate ( $1/100.8$ hr $^{-1}$ in our case). With $L=6$ copies, this gives $T_{wait} = 33.6$ hours.

The probability that all $L/2$ wait-phase copies fail to reach the base within deadline $D$ is:

$P_{fail} = \left(e^{-\lambda_{eb} \times D}\right)^{L/2} = \left(e^{-\frac{14 \times 24}{100.8}}\right)^3 = 4.5 \times 10^{-5}$

This exponential decay means each additional copy provides diminishing returns: $L=2$ gives 96.4% delivery, $L=4$ gives 99.87%, $L=6$ gives 99.995%, but $L=8$ only improves to 99.9998%.

Decision: Use spray-and-wait with L=6, 256 kB SPI flash buffer, 5-minute BLE discovery beacons. Expected delivery latency of 1.4 days with 99.995% reliability is well within ecology research requirements. The 3-year battery lifetime has a 38.9x safety margin.

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

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

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

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 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

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

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 final part closes the route from Disconnected Ad Hoc Networks through Key Takeaway. Return to Delay-Tolerant Networks: Design Principles or continue from the emerging-paradigms module index.