Delay tolerant networks
This presentation is the property of its rightful owner.
Sponsored Links
1 / 48

Delay Tolerant Networks PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Delay Tolerant Networks

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]


Probabilistic routing2

Probabilistic routing

>

>

>>


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]


Delay tolerant networks

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


Back up slides

Back up slides…


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


  • Login