1 Delay Tolerant Networks Arezu Moghadam PhD Candidacy Talk 12/18/2007.
-
date post
19-Dec-2015 -
Category
Documents
-
view
215 -
download
1
Transcript of 1 Delay Tolerant Networks Arezu Moghadam PhD Candidacy Talk 12/18/2007.
1
Delay Tolerant Networks
Arezu MoghadamPhD Candidacy Talk12/18/2007
2
Networking expansion
Internet
Internet
B-ISDN
ATM
OSI
Pervasivecomputing
Sensornetswireless DTN
P2Poverlays
CDNPub/sub
1990
2000
Applicationsrule!
1980 1970
3
Interplanetary communication
Ref: [1] Picture: http://www.intel-research.net/berkeley
4
ZebraNet (a real life application)
Data
Data
DataStore-and-forward communications
Data
Tracking node with CPU, FLASH, radio and GPS
Sensor Network Attributes ZebraNet Other Sensor Networks
Node mobility Highly mobile Static or moderate mobile
Communication range Miles Meters
Sensing frequency Constant sensing Sporadic sensing
Sensing device power Hundreds of mW Tens of mW
http://www.princeton.edu/~mrm/zebranet.html
First deployment in 2004 in Kenya
5
DTN characteristics Internet environment
End-to-end RTT is not large.
Some path exists between endpoints.
E2E reliability using ARQ works well.
Packet-switching is the right abstraction.
DTN characteristics Very large delays. Intermittent and
scheduled links. Different network
architectures. Conversational
protocols fail. No ARQ.
Ref: [2], [3]
6
Agenda
Architecture Routing Multicast Implementation Conclusion
7
Architectural requirements Asynchronous message delivery. Naming
Tuples (names): ordered pairs (R, L) No ARQ Reliability
At least Hop-by-hop. Type of links
Scheduled vs. non-scheduled. Contact, an opportunity to transfer the data.
Predictable vs. opportunistic.
Ref: [2], [3], [6]
8
Reliability End-to-end vs. per-
hop reliability. Custody transfer
Not delete a message until delivery to another custodian.
Head of line blocking. Even “always on”
link is blocked.
S R
A
B
Data
Persistent message storage
Intermittent link
“Always on” link
R provides store-and-forward service
Ref: [4]
9
Suggested architectures Sequential heterogeneous
regions interconnected by gateways.
ParaNet Users access more than
one network over one device.
Different paths for signaling and data.
Challenges Routing, transport
protocol, naming, security over multiple paths and etc.
Interplanetary or satellite
Interplanetary or satellite
SensorsSensors
InternetInternetGW
GW
GW
Bus route
Ref: [2]
10
Suggested architectures Sequential heterogeneous
regions interconnected by gateways.
ParaNet Users access more than
one network over one device.
Different paths for signaling and data.
Challenges Routing, transport
protocol, naming, security over multiple paths and etc.
DTNStore and forward
DTNStore and forward
Lightweight cellular network for signaling
Data or control information over satellite
Ref: [5]
11
Agenda
Architecture Routing Multicast Implementation Conclusion
12
Routing Challenges Routing objectives:
Minimize delay Maximize throughput
Per-hop routing vs. source routing. No end-to-end path
MANET’s routing protocols fail. Proactive and reactive
Store-carry-forward Storage constraints
No Topology knowledge Time varying connectivity graph
Ref: [8]
13
Routing Models
Flooding based protocols Epidemic [18], Erasure coding [11]
Knowledge based routing Oracle [8], Message Ferrying [15], [16],
Practical routing [9] Probabilistic routing
PROPHET [13], RPLM [12], MaxProp [14], MobySpace [10]
14
Flooding based routing Epidemic [18]
Exchanging summary vectors (hash values).
Erasure coding [11] Use r relays wait for
one or rxk relays and wait for k
Message can be decoded if k relays make it to the destination.
>
15
Knowledge based routing
))(),(,),(( tdtcvue nn
An oracle which provides topology info. Contacts, buffer
constraints, traffic demands… [8]
Partial topology info. Message ferrying [15],[16]
Using history to predict future topology. Practical routing [9]
S
u
x
w
v
D
Each edge is a contact meaning an opportunity to transfer data.
16
Routing with global knowledge
Oracle; source of knowledge about topology How much knowledge to achieve an acceptable delay. Modified Dijkstra with time varying edge costs. Source routing. The more knowledge the better performance. (too obvious!) Not realistic!
MED(Minimum Expected
Delay)
Modified Dijkstra alg with time varying costs based on average edge waiting time.
Contact summery (avg. waiting time until next contact)
>>Ref: [8]
17
Routing with partial knowledge Message ferrying
Ferries broadcast their situation.
Ferry route design to minimize drops NP hard reduced to TSP.
Practical routing Instead of contact
schedules uses contact history.
Per-contact routing vs. per-hop routing.
MF: Sparse MANETswith different deployment areas
12
3
4
Ref: [15] , [16]
Scalability: How increasing number of mobilenodes affects number of ferries?
>>
18
Routing with partial knowledge Message ferrying
Ferries broadcast their situation.
Ferry route design to minimize drops NP hard reduced to TSP.
Practical routing Instead of contact
schedules uses contact history.
Per-contact routing. Update the graph upon
contact changes.
Practical routing:Source: A dest: D
Per-hop or per-source: A-B-DPer-contact: A-C-D (don’t wait for B)
A
B C
D
8
22
3
A
B C
D
0
2
3
2
Ref: [9] >>
19
Probabilistic routing
B C
.5 .5
Estimate delivery likelihood. Initially assign a
delivery probability to each node.
Update upon meeting a node based on some criteria.
Link state routing to disseminate probability tables.
A
B
C
DA C D
.4 .1 .5 B C
.6 .4
A B D
.4 .2 .4
Ref: [10], [12], [13], [14]
20
Probabilistic routing
B C
.5 .5
Estimate delivery likelihood. Initially assign a
delivery probability to each node.
Update upon meeting a node based on some criteria.
Link state routing to disseminate probability tables.
A
B
C
DA C D
.4 .4 .2 B C
.6 .4
A B D
.4 .4 .2
Ref: [10], [12], [13], [14]
21
Probabilistic routing
MobySpace [10] Closest mobility pattern. How?(Dimension could grow dramatically!?)
PROPHET [13] Delivery predictability
RPLM [12] Routing with persistent link modelingCost window
MaxProp [14] Delivery probabilityCost of using each node as relay
>>
>
>
22
Issues of the probabilistic routing.
Covered No a priori knowledge of contacts. Storage constraint and buffer management. Network wide acks to free up buffer space or provide reliable delivery.
Not covered What initial values to start with to converge to reasonable delivery probabilities? What if nodes change their habits. How adaptive? No mathematical proof of efficiency of the routing algorithms.
Packets with hop counts < thresh Sorted by hop count
High rank Low rank
Packets with hop counts > thresh Sorted by delivery likelihood
Packets transmitted from here Packets deleted from here
Ref: [14], [12]
23
Mobility model and performance analysis
Node mobility characteristic better performance analysis.
Algorithms developed for specific scenarios. Random with core aided nodes. Community based. Mixture of RWP and ferries.
Ref: [17], [7]
24
Performance evaluation
Model objective
Delivery ratio
Delay Message redundancy
Knowledge
Flooding High Low(the least)
High Buffer congestion
Zero
Knowledge based
MF the highest (even higher
than ER)
Moderate Low Provided to the algorithm
Probabilistic Close to ER with tendency in
mobility
Close to ER with tendency in
mobility
Moderate Memory(learning from
past)
Ref: [7], … , [17]
25
Agenda
Architecture Routing Multicast Implementation Conclusion
26
Multicast requirements and challenges. Disaster recovery, battlefield…
Distribution of news to a group of users; Who is the recipient?
Group membership changes during data transfer. Routing is the most challenging problem. Multicast semantics
Temporal membership: each message contains a membership interval.
Delivery interval as well as membership interval. Current member: receiver should be a member at
delivery time.
Ref: [19]
27
Routing models.
S
R2R1
Broadcast-based routing(BBR)
Epidemic routing to all nodes [19]
R1
R2
S
Group-based routing(UBR)
Forwarding group [19]
28
Routing models contd…R
R
R R R
F
MFER; MF with Epidemic routing [20]
R
R
R R R
F
MFGR; MF with group routing [20]
S
R1
R2
Tree-based routing(TBR)
Along the spanning treecontaining all receivers [19]
>>
29
Performance
Model objective
Delivery ratio
Delay Message redundancy
Topology Knowledge
Flooding High (the best)
Low High Buffer
congestion
Not required
Tree based Moderate High Low Required
MF
ER
GR
close to ER Low High Ferry location
Moderate (large group close to ER)
Moderate Low Ferry location
Ref: [21] , [20] , [19]
30
Agenda
Architecture Routing Multicast Implementation Conclusion
31
TEK system Searching WWW using
email. Email-based
communication protocol. TEK server located at MIT. TEK client a Java proxy
server. Batched requests are
emailed to the server.
ISP
TEKServer
WebBrowser
TEK Proxy
TEK Client
WWW
WWW
MIT
Remote
Store-and-
forward
Store-and-
forward
Ref: [23] , [25], [22]
Req
Rep
32
7DS Based on epidemic
routing. Utilizing opportunistic
contacts to pass email messages.
Basic platform to develop store-and-forward applications.
InternetInternet
Ref: [26]
33
Agenda
Architecture Routing Multicast Implementation Conclusion
34
Conclusions and future directions A killer application!
Implementation efforts have been limited to specific not everyday life applications.
When Joint tactical radio system becomes available? [25] ParaNet!?
Challenges: topology estimation and routing. So far research focus on predictable network topologies. Knowledge based approaches requiring a global view of
the network are unrealistic. Hybrid of MF with probabilistic routing!? Absence of real world mobility patterns in algorithms
evaluations. Security issues still not discussed! Lack of common APIs to abstract DTN.
35
References
Papers list
36
Back up slides…
37
Probabilistic routing criteria PROPHET
Delivery predictability calculation. Routing with Persistent Link Modeling (RPLM)
Monitors link connectivity to calculate its cost. Dijkstra to find a minimum cost path.
MaxProp Assigning a cost value to each destination based on
probability. Priority queue younger messages higher chances.
MobySpace MobyPoint each node’s coordinates or mobility pattern. Distance on each axes probability of contacts or presence
in a location.
38
Routing with global knowledge Message arrival time at a
node must be predicted. Predicted arrival time is
used to determine the cost
At light load ED performance comparable to EDAQ and EDLQ.
Heavy traffic results in congested queues Algorithms with queue knowledge are the winners.
MED Dijkstra with time varying costs based on average edge waiting time.
Contact summery (avg. waiting time until next contact)
ED(Earliest delivery)
Dijkstra’s with time varying costs based on edge waiting time.
Contacts(no knowledge
of queues)
EDLQ(ED with
local queue)
ED with local queuing information.
Contacts + (data queues
for the contact at the current
time)
EDAQ ED with global queuing information.
Contacts + Buffer (queue
sizes across entire topology)
LP Linear programming
All + traffic
39
VANETS Propagation of location
specific information. Directional propagation
protocol Custody transfer protocol Inter-cluster routing
protocol Intra-cluster routing
protocol Routing based on local
parameters and TTL Routing in the absence of a
global naming scheme. Ex: traffic data to cars 5
miles away…
H T
HT HT
West
East
40
PROPHET Delivery predictability is calculated at each
node for all destinations B; P(A,B) When node A encounters node B the
parameter P(A,B) is updated.
Packet transfer if delivery predictability at new node is higher than current one.
kold
initoldold
baPbaP
PbaPbaPbaP
),(),(
)),(1(),(),(
41
Link Cost History Idea is cost is related to the
duration of connectivity.
Link with high transitions will get connected soon.
Compared with PROPHET Single forwarding Multi-forwarding
PROPHET doesn’t differentiate between carriers X and Y.
transitonji
N
r
rjiwindowt
ji N
TTC
Transitionji
,
1,_cos
, 1
)(1,
42
Erasure Routing Transforms a message of n
blocks to a message of > n blocks.
Receiver can recover the original message from a subset of blocks
Fraction of the required blocks is the ratio r.
1/r blocks are necessary Instead of propagating among r
relays as in srep distributes them among rk
Whether to use r relays and wait for one to succeed or to use rk relays and wait for k to succeed?
Worst case scenario
43
Practical routing MEED Minimizing estimated expected delay. Using the contact history instead of contact schedule. Nodes record connection and disconnection periods over a
sliding window. Propagating link state table. Per-contact routing instead of source or per-hop routing.
A
B C
D
8
22
3
A
B C
D
0
2
3
2
44
Practical routing simulation
Wireless LAN traces converted into a DTN scenario
Nodes are connected when associated to the same AP
45
Message Ferrying – Single Node Initiated MF
The ferry moves according to a specific route Nodes make proactive movement to meet up with ferry Message drops: buffer overflow or message time out Nodes task time vs. meeting the ferry
Ferry Initiated MF Long range radios in nodes. Service_Request Location_Update
Ferry trajectory control based on minimizing message drop rate along the path.
NP-hard problem Nearest Neighbor Traffic aware
)/())()(( fi
nididi GGTtmtD
k
i
s
l
fi
ni
Pi
ltDltDD1 0
00 ))()((
46
Message Ferrying – Multiple To allow scalability
in traffic load Single ferry single
point of failure Different scenarios
No interaction Ferry relaying Node relaying
Designing the ferry routes to minimize weighted delay.
nji ij
nji ijijdD
,1
,1
47
Ferry route design Assigning nodes to ferries to
minimize weighted delay. Optimization problem with
BW constraints The higher the data rate the
longer the route length.
48
Multicasting with MF Long-duration partitions
makes multicast forwarding structure spanning all group members difficult.
Hybrid approach for Ferry initiated MC Message Ferry with
Epidemic Routing Message Ferry with Group
Routing Adaptive Scheme