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!