PRoPHET+: An Adaptive PRoPHETBased 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 Bthresh Sender Node receives: Bremain :buffer/storage size remaining till Bthresh Perform: VB Bremain packetsize Bthresh The lesser the storage space remaining, the lesser the score. Determining Threshold Nodes log an arbitrary amount of time of storage usage average. Bthresh Btotal Bself 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: Vp Premain Preceive Psend Pthresh Ptotal Pthresh = # of pkts in the buffer * Psent Potential receiver does The computation of Pthresh Bandwidth Motivation Reduce chance of corrupt packet during transmission due to contact time. Reduce chance of power wasting Bandwidth Sender Compute score VA potential receiver' s max transmission rate VA sender's max transmission rate 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 # of transmissions P Max # of transmissions Sender Receives popularity log VO 1 P 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 Performance metrics Java Based Discrete event simulator for DTN environment Successful data delivery ratio Delay performance Scenarios Real world wireless traces Haggle(Infocom’ 05) Simulation Trace Name Haggle Device iMote Network Type Bluetooth Duration (days) 4 Devices Participating 274 Number of Contacts 28,250 Avg # Contacts/pair/day 0.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 + 0.5 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!