delay tolerant networks
Download
Skip this Video
Download Presentation
Delay Tolerant Networks

Loading in 2 Seconds...

play fullscreen
1 / 48

Delay Tolerant Networks - PowerPoint PPT Presentation


  • 163 Views
  • Uploaded on

Delay Tolerant Networks. Arezu Moghadam PhD Candidacy Talk 12/18/2007. Networking expansion. CDN Pub/sub. P2P overlays. Pervasive computing. Sensor nets. wireless. DTN. Internet. 2000. Applications rule!. 1990. Internet. ATM. 1970. 1980. B-ISDN. OSI.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Delay Tolerant Networks' - marlo


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
delay tolerant networks

Delay Tolerant Networks

Arezu Moghadam

PhD Candidacy Talk

12/18/2007

networking expansion
Networking expansion

CDN

Pub/sub

P2P

overlays

Pervasive

computing

Sensor

nets

wireless

DTN

Internet

2000

Applications

rule!

1990

Internet

ATM

1970

1980

B-ISDN

OSI

interplanetary communication
Interplanetary communication

Ref: [1]

Picture: http://www.intel-research.net/berkeley

zebranet a real life application

Tracking node with CPU, FLASH, radio and GPS

Data

Store-and-forward communications

Data

Data

Data

ZebraNet (a real life application)

First deployment in 2004 in Kenya

http://www.princeton.edu/~mrm/zebranet.html

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.

DTN characteristics

Ref: [2], [3]

agenda
Agenda
  • Architecture
  • Routing
  • Multicast
  • Implementation
  • Conclusion
architectural requirements
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]

reliability

Persistent message

storage

A

Data

S

R

B

Intermittent link

“Always on” link

R provides store-and-forward service

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.

Ref: [4]

suggested architectures

Interplanetary or satellite

GW

Internet

GW

Sensors

GW

Bus route

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.

Ref: [2]

suggested architectures1

Data or control information over satellite

DTN

Store and forward

Lightweight cellular network for signaling

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.

Ref: [5]

agenda1
Agenda
  • Architecture
  • Routing
  • Multicast
  • Implementation
  • Conclusion
routing challenges
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]

routing models
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]
flooding based routing
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.

>

knowledge based routing

u

v

S

w

D

x

Knowledge based routing
  • 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]

Each edge is a contact meaning

an opportunity to transfer data.

routing with global knowledge
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!

Ref: [8]

>>

routing with partial knowledge
Routing with partial knowledge

MF: Sparse MANETs

with different deployment areas

  • 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.

1

2

3

4

Scalability: How increasing number of mobile

nodes affects number of ferries?

>>

Ref: [15] , [16]

routing with partial knowledge1

D

D

2

2

2

2

B

C

B

C

3

8

3

0

A

A

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-D

Per-contact: A-C-D (don’t wait for B)

>>

Ref: [9]

probabilistic routing
Probabilistic routing
  • 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

C

B

D

Ref: [10], [12], [13], [14]

probabilistic routing1
Probabilistic routing
  • 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

C

B

D

Ref: [10], [12], [13], [14]

issues of the probabilistic routing
Issues of the probabilistic routing.

High rank

Low rank

Packets with hop counts < thresh

Sorted by hop count

Packets with hop counts > thresh

Sorted by delivery likelihood

Packets transmitted from here

Packets deleted from here

  • 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.

Ref: [14], [12]

mobility model and performance analysis
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]

performance evaluation
Performance evaluation

Ref: [7], … , [17]

agenda2
Agenda
  • Architecture
  • Routing
  • Multicast
  • Implementation
  • Conclusion
multicast requirements and challenges
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]

routing models1

Group-based routing

(UBR)

Broadcast-based routing

(BBR)

R2

R1

R2

R1

S

S

Epidemic routing to all nodes [19]

Forwarding group [19]

Routing models.
routing models contd

R

F

Tree-based routing

(TBR)

R

R

R

R

R1

MFER; MF with Epidemic routing [20]

R2

R

F

S

R

Along the spanning tree

containing all receivers [19]

R

R

R

MFGR; MF with group routing [20]

Routing models contd…

>>

performance
Performance

Ref: [21] , [20] , [19]

agenda3
Agenda
  • Architecture
  • Routing
  • Multicast
  • Implementation
  • Conclusion
tek system
TEK system
  • Searching WWW using email.
  • Email-based communication protocol.
  • TEK server located at MIT.
  • TEK client a Java proxy server.
  • Batchedrequests are emailed to the server.

Remote

TEK Client

Req

ISP

Web

Browser

TEK

Proxy

Store-and-forward

WWW

Rep

TEK

Server

MIT

Ref: [23] , [25], [22]

slide32

Internet

7DS
  • Based on epidemic routing.
  • Utilizing opportunistic contacts to pass email messages.
  • Basic platform to develop store-and-forward applications.

Ref: [26]

agenda4
Agenda
  • Architecture
  • Routing
  • Multicast
  • Implementation
  • Conclusion
conclusions and future directions
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.
references
References
  • Papers list
probabilistic routing criteria
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.
routing with global knowledge1
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.
vanets

H

T

T

T

H

H

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…

West

East

prophet
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.
link cost history
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.
erasure routing
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
practical routing

D

D

2

2

2

2

B

C

B

C

3

8

3

0

A

A

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.
practical routing simulation
Practical routing simulation
  • Wireless LAN traces converted into a DTN scenario
  • Nodes are connected when associated to the same AP
message ferrying single
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
message ferrying multiple
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.
ferry route design
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.
multicasting with mf
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
ad