13 DTN Epidemic Routing
13.1 Start Simple
Start with devices that have to pass useful data before any fixed network is guaranteed. In DTN Epidemic Routing, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.
13.2 Start With a Message That Spreads by Contact
Epidemic routing uses contact opportunities aggressively. When two nodes meet, they compare what messages they carry and exchange missing copies so delivery odds rise through replication.
That simple rule can rescue data in disconnected IoT environments, but it can also consume buffers, energy, and airtime quickly. Start with one message copy, then watch how every contact multiplies both opportunity and cost.
13.3 Flooding as DTN Trade-off
Epidemic routing is a delay-tolerant networking strategy for places where an end-to-end path may not exist when a message is created. Nodes store a message, carry it while disconnected, and forward a copy when they meet another node that does not already have it. The design goal is high delivery opportunity, not low overhead.
The important question is not whether epidemic routing can spread a message. It can. The important question is whether the deployment can afford the copies, contact time, buffer space, energy, and stale-message cleanup that flooding creates.
A clean overview starts by naming what the extra copies are buying. In a wildlife collar network, a replicated sighting may be acceptable because the next gateway contact is uncertain and the payload is small. In a battery-powered alarm system, the same replication pattern may be reckless if urgent alarms must share a short contact with routine sensor logs. Epidemic routing is therefore a policy choice about delivery probability, delay tolerance, and resource burn.
The common mistake is to treat epidemic routing as ordinary wireless broadcast. It is not a one-hop flood that disappears when the transmission ends. Each accepted copy becomes stored state with an owner, an expiration rule, and a chance to create more copies at the next encounter. The reader should be able to answer three questions before any diagram looks convincing: who may carry the payload, when does a copy stop spreading, and what lower-value work is displaced when the contact window is full?
Store
A node keeps messages locally because no continuous route is assumed. Buffer policy is part of the routing design, not an implementation detail.
Carry
Movement, schedules, patrols, buses, people, animals, or drones create future contact opportunities. Mobility is the transport path.
Forward
During a contact, nodes exchange summary vectors, request missing messages, and transfer copies that are still eligible to spread.
Routing doctrine: use epidemic routing when delivery is more important than conserving every byte, but only with explicit TTL, copy, buffer, priority, and cleanup limits.
13.4 Bound Flooding Before Fielding
A practical epidemic design needs a control record. Without it, each message can continue occupying buffers and airtime long after it has stopped being useful. The record should say which messages may replicate, how many copies are allowed, when stale copies expire, and which messages are dropped first when storage is tight.
Start the record at the contact exchange. Each node needs an inventory method, often called a summary vector or message manifest, that says which bundle or payload identifiers it already carries. The receiving node then requests only missing, still-eligible items. That step matters because a ten-second contact can be wasted by duplicate transfers if the nodes do not compare inventories before sending payload bytes.
Next, write the transfer order as an operator-visible rule rather than a hidden implementation guess. Emergency observations may go before routine logs; soon-expiring payloads may go before long-lived ones; large payloads may be deferred unless enough contact time remains. The rule should also define what happens when two limits conflict, such as a high-priority message that is already widely replicated or an old message that is the only copy left.
Do not approve epidemic routing from a delivery-only simulation. The same run must report copy count, buffer occupancy, expired payloads, contact-window use, and energy-sensitive transmissions.
13.5 Copy Growth as Resource Model
Epidemic routing behaves like a resource amplifier. One message can become many stored copies. The upper bound is shaped by node count, contact pattern, TTL, copy budget, duplicate suppression, buffer policy, and delivery acknowledgements. This is why the routing decision must be evaluated as a storage, energy, and airtime decision.
At contact time the protocol is an anti-entropy exchange: two nodes compare message identifiers, calculate the set difference, then schedule transfers from the missing eligible set. The exact encoding can vary by implementation, but the state machine should be explicit: discover peer, exchange inventory, choose candidates, transfer payloads, update local metadata, and record partial-transfer failures. If any step is invisible in logs, field debugging quickly becomes guesswork.
Duplicate suppression is as important as replication. A node that receives a payload must record enough identity information to avoid accepting the same copy again under a different contact. A delivered-message acknowledgement or deletion signal can also spread through later contacts so carriers purge copies that no longer need to exist. If the system cannot propagate that cleanup state, the TTL and buffer-drop policy become the only brakes on copy growth.
The resource model should be calculated with worst plausible contact patterns, not only average behavior. High-contact carriers can become buffer hot spots because they meet many peers and receive many copies. Low-contact nodes can hold stale payloads until the TTL expires. A simulator acceptance run should therefore report per-node maximum buffer occupancy, copy count distribution, expired bytes, delivered bytes, contact utilization, and energy-sensitive transmissions, then compare pure epidemic routing with a bounded alternative such as Spray and Wait or PRoPHET-style probabilistic forwarding when overhead is too high.
Pure Epidemic
Every useful contact can create another copy. This is simple and robust, but it scales poorly unless TTL and buffer policy are strict.
Spray And Wait
The source or early carriers distribute a fixed number of copy tickets, then carriers wait for direct delivery or a configured forwarding rule.
Context-Aware Forwarding
History, social contact, schedule, destination likelihood, or priority can decide which contacts deserve a copy.
Review formula: worst-case storage pressure grows with messages created during the TTL window, average copy count, payload size, and how unevenly copies land on high-contact nodes. If this number is not bounded, the routing design is not ready.
13.6 Summary
Epidemic routing improves delivery opportunity in delay-tolerant networks by copying messages during opportunistic contacts. It is useful when connectivity is intermittent and delivery matters more than minimal overhead. It is dangerous when treated as free flooding. A defensible design records summary-vector behavior, TTL, copy budgets, buffer drop rules, contact-window priority, and delivery-versus-overhead evidence before field deployment.
13.7 Key Takeaway
Use epidemic routing as a bounded DTN delivery strategy, not as unbounded flooding: every copy must have a lifetime, a storage budget, and a reason to exist.
13.8 See Also
Review store-carry-forward behavior before choosing a replication strategy.
Compare epidemic flooding with forwarding that uses contact history or social utility.
Place epidemic routing in field scenarios where contacts are delayed or scheduled.
Connect routing choice to deployment evidence, ownership, and retest triggers.