PRoPHET+: An Adaptive PRoPHET- Based Routing Protocol for Opportunistic Network Ting-Kai Huang, Chia-Keng Lee and Ling-Jyh Chen

What is Opportunistic Network Delay-Tolerant Network Ad-hoc like structure without fully connected path Situations: Mobile Sensors Military Operations Rural Areas

Routing Protocols in Intermittently Connected Network Epidemic Routing Deliver data to all encountered nodes Limit resources by hop counts Disconnected Transitive Communication Utility function to determine connected node that is closest to destination. Interrogation-Based Relay Routing Topology based.

Prophet Probabilistic Routing Protocol using History of Encounters and Transitivity for Intermittently Connected Network Improve delivery rate of messages by keeping buffer usage and communication overhead at a low level. Assumes that nodes move in a predictable behavior. Transfers data when Delivery Predictability Value is higher at other node.

Shortcomings of Prophet Data may be lost when Data node fails (out of power w/ no recharging opportunity)‏ Buffer size full (Prophet uses FIFO)‏ Short duration contact Data to destination may be delayed due to Transmitting to nodes that does not visit the location of the destination node often

Motivation Why improve Prophet Most popular routing protocol in Opportunistic Network. What to improve in Prophet Reduce Data loss Reduce Single Point of Failures Reduce Transmission Delays

Prophet+ Deliverability value based on Prophet's predictability value in addition to: Remaining Buffer/Storage Remaining power Bandwidth Popularity When a node wants to send data Determine data size. Query all connected nodes for log files. Calculates deliverability value using log files.

Buffer/Storage Motivation Main Motivation Reduce chance of data loss from FIFO Too much incoming data Self generated data Side Benefit May reduce chance of single point of failure Data sent to other nodes as data begins to fill.

Buffer/Storage All nodes define a threshold B thresh Sender Node receives: B remain :buffer/storage size remaining till B thresh Perform: The lesser the storage space remaining, the lesser the score.

Determining Threshold Nodes log an arbitrary amount of time of storage usage average. Set the threshold so that self generated data does not cause storage/buffer to become full.

Power Motivation Main Motivation Nodes w/ no recharge Increase uptime of specific nodes. Increase success of delivery. Side Benefit Reduce Single Point of failure

Remaining Power/Power Consumption – No Recharge Sender receives A ratio value: Potential receiver does The computation of

Bandwidth Motivation Reduce chance of corrupt packet during transmission due to contact time. Reduce chance of power wasting

Bandwidth Sender Compute score Values > 1 are set to 1.

Popularity Motivation Load balancing Decrease burden on specific nodes. Longevity of nodes Heavily related to Buffer/Power issue but Buffer and Power ensure minimal data loss. Popularity is an independent property when Buffer/Power are not issues. Longer time to transmit due to more data in queue. Single point of failure.

Popularity Potential Receiver Logs number of times it has received and transmitted data in a certain amount of time Sender Receives popularity log The greater the P, the lesser the score.

Simulation Test each property individually  Compare (property+prophet) to prophet Evaluate results to determine weights for each property Run a comparison between Prophet and the (combined weight of each property + prophet) ‏

Simulation Extension of DTNSIM  Java Based  Discrete event simulator for DTN environment Performance metrics  Successful data delivery ratio  Delay performance Scenarios  Real world wireless traces Haggle(Infocom’ 05) ‏‏

Simulation Trace Name Haggle DeviceiMote Network TypeBluetooth Duration (days)4 Devices Participating274 Number of Contacts28,250 Avg # Contacts/pair/day0.27

Parameter Settings Number of sender-receiver pairs: 20 pairs Number of Packets/Pair: First 40% of simulation time with a Poisson rate of 900 sec/packet generated. iMote ~150 packets Packet size: 10MB Deliverability= 0.5 property Prophet

Results: Prophet +Power

Results: Prophet +Buffer

Results: Prophet + Bandwidth

Results: Prophet + Popularity

Prophet v.s. Scores (initial weight)

Results: Prophet + Popularity

Conclusion PRoPHET+: Design a score function, which consider buffer, power, bandwidth, popularity and predictability. Has lower delay and higher successful delivery rate.

Thank You!