Performance Evaluation of Delay Tolerant Network Protocols to Improve Nepal Earthquake Rescue Communications

This paper evaluates the performance of Delay Tolerant Network (DTN) routing protocols in a simulated Nepal earthquake rescue scenario, demonstrating their effectiveness in distress message transmission while highlighting critical trade-offs between reliability and resource utilization to guide future emergency communication designs.

The Gist

Imagine a massive earthquake has just hit a city. The power is out, cell towers are smashed, and the roads are blocked. In this chaos, the normal way phones talk to each other (like sending a text that instantly zips to a tower) is broken. People are trapped, and rescue teams are trying to find them, but they can't talk to each other.

This paper is about a special kind of "digital messenger" system called a Delay Tolerant Network (DTN) that works when the internet is dead. The researchers asked: How do we get a "Help Me!" message from a trapped person to a rescue team when there is no direct connection?

Here is the breakdown of their experiment, explained simply with some everyday analogies.

1. The Setup: A Digital Simulation of Disaster

The researchers didn't wait for a real earthquake to test this. Instead, they built a virtual world inside a computer that looked exactly like the 2015 Nepal earthquake.

• The Players: They created different types of "characters" in their simulation:
  • Victims: Trapped people with low-power phones (like Bluetooth). They are scattered everywhere.
  • Rescue Teams: People on foot with better tablets.
  • Trucks & Drones: Fast-moving vehicles that can carry messages over long distances.
• The Goal: The victims need to send an SOS signal. Since they can't reach a cell tower, their phones have to pass the message to the nearest person (a neighbor, a rescuer, or a drone), who then passes it to someone else, until it finally reaches a rescue command center. This is called "Store-Carry-Forward." Think of it like a game of "Telephone," but instead of whispering, you physically carry a note until you meet someone who can take it further.

2. The Contenders: Two Different Strategies

The researchers tested two different ways to pass these notes around.

Strategy A: The "Epidemic" Protocol (The Panic Spreader)

• How it works: Imagine a person with a note meets anyone. They immediately make a copy of the note and give it to that person. Then, that person meets someone else and makes another copy.
• The Analogy: It's like a viral meme or a rumor spreading in a crowded room. Everyone copies the message and shouts it to everyone they see.
• The Problem: In a small room, this works great. But in a huge, chaotic disaster zone, everyone starts copying the message so fast that their pockets (memory buffers) get full. They run out of space to hold the notes. Eventually, they have to throw away the most important notes just to make room for new, less important ones. The system gets clogged, and the message never gets delivered.

Strategy B: The "Spray-and-Wait" Protocol (The Controlled Distributor)

• How it works: This strategy is more disciplined. When a person gets a message, they are only allowed to make a limited number of copies (say, 16 copies total). They "spray" these copies out to a few people they meet, and then they stop copying. They just "wait" to see if one of those people finds the rescue team.
• The Analogy: Imagine a teacher handing out flyers. Instead of giving a flyer to everyone in the school (which would be chaotic), they give 16 flyers to 16 specific students and tell them, "You are now responsible for passing this to the principal." It's controlled and efficient.

3. The Results: Who Won?

The researchers ran the simulation for 12 hours (the "Golden Rescue Period" where every minute counts).

• The Epidemic Protocol (The Panic Spreader):

  • Success Rate: Terrible. Only about 15% of the messages got through.
  • Why? The network got so clogged with copies that the devices ran out of memory. It was like a traffic jam where every car is trying to merge at once; nothing moves.
  • Waste: It wasted massive amounts of battery and data trying to send millions of unnecessary copies.

• The Spray-and-Wait Protocol (The Controlled Distributor):

  • Success Rate: Amazing. About 95% of the messages got through.
  • Why? By limiting the copies, it kept the network clean. The messages didn't get lost in the noise. Even with small memory buffers (like a cheap phone), it worked perfectly.

4. The Big Lesson: Quality Over Quantity

The most important finding of this paper is that having more storage space doesn't fix a bad strategy.

Even when the researchers gave the "Panic Spreader" (Epidemic) huge amounts of memory (like upgrading from a small phone to a giant hard drive), it still failed because the strategy itself was too messy.

However, the "Controlled Distributor" (Spray-and-Wait) worked perfectly even with very small memory.

• The Takeaway: In a disaster, you don't need expensive, high-tech hardware with massive storage. You need smart algorithms that know how to manage resources carefully. A simple, smart plan beats a powerful, chaotic one every time.

5. What's Next?

The authors suggest that while this worked for earthquakes, future research should look at other disasters like fires (where smoke and heat change how people move) and focus on saving battery life so that phones don't die before the rescue arrives. They also want to test this on real drones and robots, not just in computer simulations.

In a nutshell: When the world breaks, the best way to send a message isn't to shout it as loud and as often as possible. It's to pass it carefully, with a plan, ensuring that the message survives the journey to the people who can help.

Technical Summary

Here is a detailed technical summary of the paper "Performance Evaluation of Delay Tolerant Network Protocols to Improve Nepal Earthquake Rescue Communications."

1. Problem Statement

In the immediate aftermath of catastrophic natural disasters, such as the 2015 Nepal earthquake, traditional communication infrastructure (cell towers, power grids) often collapses, creating a "disconnected" environment where end-to-end connectivity is impossible.

• The Challenge: Rescue operations rely on the timely transmission of distress signals (SOS) from survivors to rescue teams. However, the dynamic nature of the environment, node mobility, and limited resources (battery, buffer storage) make standard Mobile Ad Hoc Network (MANET) protocols ineffective.
• The Specific Issue: There is a critical need to identify which Delay Tolerant Network (DTN) routing strategies can maximize the delivery probability of distress messages while minimizing resource consumption (bandwidth, energy, and buffer space) in a resource-constrained, high-congestion disaster scenario.

2. Methodology

The authors conducted a simulation-based study using a pseudo-realistic use case modeled after the 2015 Nepal earthquake in Kathmandu.

• Simulation Environment:

  • Duration: 12 hours (covering the critical "golden rescue period").
  • Map: 4500m x 3400m, representing a mix of urban and rural disaster landscapes with collapsed infrastructure.
  • Node Groups: Four distinct categories of edge nodes were modeled with specific movement patterns and hardware capabilities:
    1. Victims: Divided into three density groups (sparse, dense, built-up). They use low-power Bluetooth interfaces and have limited storage.
    2. Rescue Teams: Equipped with both Bluetooth and high-speed interfaces; distributed evenly initially.
    3. Trucks & Drones: Divided into groups covering different areas (Group A: broad coverage; Group B: dense area focus) with varying speeds and high-speed interfaces.
  • Communication Interfaces: Two interfaces were simulated:
    • Bluetooth: 2 Mb/s, 120m range.
    • High-Speed: 10 Mb/s, 500m range.
  • Traffic Model: Victims randomly broadcast SOS signals every 60–120 seconds to simulate the flood of distress calls in the early rescue phase.

• Protocols Evaluated:

  1. Epidemic Routing: A "flood-based" approach where nodes exchange all messages upon contact. It aims for maximum reachability but consumes high resources.
  2. Spray-and-Wait: A controlled approach where a limited number of message copies (set to 16 in this study) are "sprayed" into the network, followed by a "wait" phase where nodes forward only if they meet the destination. This aims to balance delivery rate and resource usage.

• Experimental Variables:

  • Comparison of the two protocols across different metrics.
  • Sensitivity analysis by varying the buffer size of rescue team nodes (10MB, 50MB, 100MB).

3. Key Contributions

• Realistic Disaster Modeling: The study moves beyond theoretical models by incorporating specific Kathmandu population density data, heterogeneous node types (drones, vehicles, humans), and realistic movement patterns (pedestrian paths, roads, shops).
• Multi-Criteria Performance Analysis: The paper evaluates protocols not just on delivery rate, but on a holistic set of metrics including delivery probability, average delay, hop count, buffer time, and overhead ratio (resource efficiency).
• Buffer Sensitivity Insight: It provides empirical evidence on how increasing buffer size affects (or fails to affect) different routing strategies in a disaster scenario, challenging the assumption that "more storage" always equals "better performance."

4. Key Results

The simulation yielded significant performance differences between the two protocols:

• Delivery Probability:

  • Spray-and-Wait: Achieved a 94.63% delivery rate (458 out of 484 messages).
  • Epidemic: Achieved only 15.50% delivery rate (75 out of 484 messages).
  • Analysis: Epidemic routing suffered from network congestion collapse. The uncontrolled flooding filled node buffers rapidly, causing valid messages to be dropped due to lack of space.

• Resource Efficiency (Overhead):

  • Epidemic: Generated massive overhead with an Overhead Ratio of ~45,794. This means over 45,000 invalid transmissions were required to deliver a single message.
  • Spray-and-Wait: Maintained a healthy overhead ratio of 15.4, demonstrating efficient resource utilization.

• Latency and Hops:

  • Epidemic: Showed deceptively low latency (avg 405s) and high hop counts (up to 93 hops). However, this was an illusion; the few messages that arrived were short-distance or dropped quickly. Most messages requiring long-distance travel were lost.
  • Spray-and-Wait: Showed higher average latency (1,237s) but consistent delivery. Messages traveled an average of 3.2 hops, indicating a stable and efficient path.

• Impact of Buffer Size:

  • Increasing the buffer size for Epidemic routing (from 10MB to 100MB) resulted in negligible improvement in delivery probability (rising only from 12.8% to 15.9%).
  • Spray-and-Wait maintained a stable 94.63% delivery rate across all buffer sizes, proving it is robust even on devices with limited storage (e.g., 10MB).

5. Significance and Conclusion

• Protocol Selection: The study conclusively demonstrates that Spray-and-Wait is superior to Epidemic routing for earthquake rescue scenarios. It offers a critical trade-off: sacrificing a small amount of speed for a massive gain in reliability and resource conservation.
• Hardware Implications: The results suggest that in disaster zones, algorithmic efficiency is more critical than hardware capacity. Simply equipping rescue teams with larger storage buffers does not solve the congestion issues caused by flood-based routing; intelligent routing strategies are required.
• Future Directions: The authors propose extending this research to fire scenarios (which have different movement dynamics) and integrating energy-efficient mechanisms (like E3F and SmartCharge algorithms) to extend the battery life of survivor devices. They also suggest physical validation using the MODiToNeS platform.

Summary: In the context of Nepal earthquake rescue communications, controlled replication strategies (Spray-and-Wait) significantly outperform uncontrolled flooding (Epidemic) by preventing network collapse, ensuring high message delivery rates, and operating effectively on resource-constrained edge devices.