Delay-Tolerant NetworksDelay-Tolerant Networks

Acknowledgements: Most materials presented in the slides are based on the tutorial slides made by Dr. Ling-Jyh Chen, Dr. Kevin Fall and Dr. Thrasyvoulos Spyropoulos.

““Legacy” NetworksLegacy” Networks

Internet, Telephone network Wired or fixed links

A SUCCESS STORY!

Wireless Networks: CellularWireless Networks: Cellular

Cellular Networks: Wired backbone + wireless last link

A SUCCESS STORY for voice/SMS! Internet? (GPRS): not really (low bandwidth + high price)

Wired Backbone

Wireless Last Hop

Wireless Networks: WiFiWireless Networks: WiFi

802.11, wimax

Still: only wireless local-loop

Higher bandwidth than cellular: 54Mbps

Much cheaper/KB

Wireless Networks: WiFi (2)Wireless Networks: WiFi (2)

Only Partial Coverage: HOTSPOTS

No real “mobile computing”!

Wireless Networks: Wireless Networks: Ad-hoc and Sensor NetworksAd-hoc and Sensor Networks

Self-organized: no wired infrastructure Peer-to-peer: nodes are routers Examples: sensor nets; disaster recovery, etc.

Disaster Recovery Target Tracking

Wireless NetworksWireless NetworksAd Hoc and Sensor Networks (2)Ad Hoc and Sensor Networks (2)

The past approach: “apply the successful and well understood Internet paradigm to ad hoc networks also”

Assume existence of explicit links (strong enough SINR) Establish end-to-end paths

Mobility might change these paths: re-establish them

S D

End-to-end path

nodelink

Wireless NetworksWireless NetworksAd Hoc and Sensor Networks (3)Ad Hoc and Sensor Networks (3)

Ad-hoc Networks: A success story?

NOT REALLY!

No real ad hoc application (killer app) out there except maybe some military networks

Why? Most wireless networks are NOT like the Internet!

The “Internet” AssumptionsThe “Internet” Assumptions

E2E path doesn’t have really long delay Reacting to flow control in ½-RTT effective Reacting to congestion in 1-RTT effective

E2E path doesn’t have really big, small, or asymmetric bandwidth

Re-ordering might happen, but not much End stations don’t cheat Links not very lossy (<1%) Connectivity exists through some path

Even MANET routing usually assumes this

More Internet AssumptionsMore Internet Assumptions

Nodes don’t move around or change addresses Easy to assign addresses in hierarchy Thought to be important for scalability

In-network storage is limited Not appropriate to store things long-term in network

End-to-end principle Routers are “flakier” than end hosts

Non-Internet-Like NetworksNon-Internet-Like Networks

Random and predictable node mobility Military/tactical networks (clusters meet clusters) Mobile routers w/ disconnections

Big delays, low bandwidth (high cost) Satellites Exotic links (deep space comms, underwater

acoustics) Big delays, high bandwidth

Busses, mail trucks, delivery trucks, etc.

Challenged NetworksChallenged Networks

Intermittend/scheduled/opportunistic links High error rates/low usable capacity Very large delays Different network architectures

Characteristics 1: Path and Link Characteristics 1: Path and Link characteristicscharacteristics

High latency, low data rate e.g. 10 kbps, 1-2 second latencies Asymmetric data rates

Disconnection Non-faulty disconnections

• Motion

• Low-duty-cycle operation

Routing subsystem should not treat predictable disconnections as faults and can use this information to pre-schedule messages

Long queueing times Conventional networks rarely greater than a second Challenged network could be hours or days due to disconnection

Characteristics 2: Network ArchitecturesCharacteristics 2: Network Architectures

Interoperability considerations Networks may use application-specific framing

formats, data packet size restrictions, limited node addressing and naming etc.

Security End-to-end approach not attractive

• Require end-to-end exchanges of keys• Undesirable to carry traffic to destination before

authentication/access control check

Characteristics 3: End System CharacteristicsCharacteristics 3: End System Characteristics

Limited longevity Round-trip time may exceed node’s lifetime making

ACK-based policies useless Low duty cycle operation

Disconnection affects routing protocols Limited resources

Affects ability to store and retransmit data due to limited memory

IP Routing May Not WorkIP Routing May Not Work

E2E path may not exist Lack of many redundant links Path may not be discoverable (e.g., fast oscillations) Traditional routing assumes at least one path exists,

fails otherwise Routing algorithm solves wrong problem

Wireless broadcast media is not an edge in a graph Objective function does not match requirements

• Different traffic types wish to optimize different criteria• Physical properties may be relevant (e.g., power)

IP Routing May Not WorkIP Routing May Not Work

E2E path may not exist Lack of many redundant links Path may not be discoverable (e.g., fast oscillations) Traditional routing assumes at least one path exists,

fails otherwise Routing algorithm solves wrong problem

Wireless broadcast media is not an edge in a graph Objective function does not match requirements

• Different traffic types wish to optimize different criteria• Physical properties may be relevant (e.g., power)

Inter-Planetary Internet (IPN)Inter-Planetary Internet (IPN)Networking in SpaceNetworking in Space

Existing satellite networks for deep space missions: Proprietary, not that efficient, one for each mission

NASA/JPL: “Extend the idea of Internet in outer space” One reusable network for all missions Gain from experience already acquired

Extending the Internet in SpaceExtending the Internet in Space

Long Propagation Delays vs.Long Propagation Delays vs.“Chatty” Internet Protocols“Chatty” Internet Protocols

Propagation Delay is much larger than transmission time! (minutes around our solar system)

Internet protocols are “chatty”

TCP:

S: “Hi! You want to talk?” (SYN) 20min

R: “Sure! Let’s establish a session” (SYN+ACK) 20min

S: “Ok, let’s go for it!” (ACK) 20 min

…..

(slow start phase)

S: “Can you send me the pic of Mars?”

…..

TCP chatinessTCP chatiness

More than 3h for one 1MB pic!

transmission time (1MB/128Kbps) = 1min !!!

Idea: “Bundles”Idea: “Bundles”

Bundle: Application-meaningful message Contains all necessary info packed inside one

“bundle” (atomic message) Next hop has immediate knowledge of storage and

bandwidth requirements

Optional ACKs Depending on class service

Goal: Avoid chattiness Minimize number of propagation delays “paid”

Intermittent ConnectivityIntermittent Connectivity

No more links! Now we have “contacts”

Contact 1:

“Dish A sees earth Sat B from 12:30h to 12h:45h”

Contact 2:

“Sat B sees rover C on mars from 17:30h to 18:30h”

Idea: Store-Idea: Store-CarryCarry-and-Forward-and-Forward

Store a bundle for a looong period of time. Forward when the next contact is available

Hours or even days until appropriate contact.

Postal system: “move packages from one storage place to another (switch intersection), along a path that eventually reaches the destination”

How is this different from Internet routers’ store-and-forward?

1) Persistent storage (hard disk, days) vs memory storage (few ms)

2) Wait for next hop to appear vs. wait for table-lookup and available outgoing routing port

Store-Carry-and-Forward (2)Store-Carry-and-Forward (2)

3

S

D

1

2

45

7

8 10

11

12 13

14

1615

Store-Carry-and-Forward (3)Store-Carry-and-Forward (3)

Store-Carry-and-Forward (4)Store-Carry-and-Forward (4)

DTN vs End-to-end Internet OperationDTN vs End-to-end Internet Operation

Networking in SpaceNetworking in SpaceHeterogeneityHeterogeneity

Heterogeneous networks to interconnect Link delay, asymmetry, error rate, reliability mechanism

Different protocol stack + Different node capabilities

Examples:

Earth’s Internet: short delays, low error rate, TCP reliability

Sensor network at Mars: short delays, high error rate, data aggregation at sink(s)

Satellite backbone: long delays, high error rate, LTP (lightweight transport protocol)

Boundles: A Store and Forward OverlayBoundles: A Store and Forward Overlay

What About Retransmission?What About Retransmission?Custody TransfersCustody Transfers

Error rates can be high in wireless links What if a retransmission is needed?

Contact 1: “Dish A sees earth Sat B from 12:30h to 12:45h”

Contact 2: “Sat B sees rover C on mars from 17:30h to 18:30h”

Contact 3: “Dish A sees Sat B again in one week”

It’s better that B takes “custody” of message and retries sending it itself

Custody Transfer (2)Custody Transfer (2)

Custody Transfer (3)Custody Transfer (3)Moving the Retransmission Point CloserMoving the Retransmission Point Closer

Benefits of hop-by-hop vs. end-to-end error control

For paths with many lossy links re-Tx requirements are much higher for end-to-end (linear vs. exponential)

E.g. 3 links each with error 1-p: (hop-by-hop) 3/p extra bandwidth (end-to-end) 3/(p^3) extra bandwidth

Retransmission overhead is increased by long propagation delays

Regions and DTN GatewaysRegions and DTN Gateways

DTN gateways are interconnection points between dissimilar network protocol and addressing families called regions e.g. Internet-like, Ad-hoc, Mobile etc.

DTN gateways Perform reliable message routing & security checks Store messages for reliable delivery Resolve globally-significant name tuples to locally-resolvable names

for internal destined traffic

Name Tuples: two variable length portions Region name

• Globally-unique hierarchically structured region name• Used by DTN gateways for forwarding messages

Entity name• Resolvable within the specified region, need not be unique outside

it E.g. { internet.icann.int, http://www.ietf.org/ }

NamingNaming

Delay Tolerant Networks (DTN)Delay Tolerant Networks (DTN)

Kevin Fall (~2002): “maybe these idea is not only useful for deep space networks”

DTN: Very Brief HistoryDTN: Very Brief History

DTNRG chartered as IRTF research group (end of 2002) Chair: Kevin Fall (Intel Research Berkeley)

Architecture evolved from deep-space-focused Interplanetary Internet project Funded by DARPA 1999-2002 IRTF Group IPNRG retired when DTNRG formed

DTN became a DARPA program in 2004

11+ Internet draft

Implementation: simulator (DTNSIM) and Linux codes (DTN2)

Intermittent Connectivity:Intermittent Connectivity:The Technical ArgumentThe Technical Argument

Wireless links are not like wires!

S D

End-to-end path

node

link

Intermittent Connectivity:Intermittent Connectivity:The Technical ArgumentThe Technical Argument

Intermittent Connectivity may appear because of: p propagation effects: shadowing, deep fades

A

B

B

B

X

Intermittent Connectivity:Intermittent Connectivity:The Technical Argument(2)The Technical Argument(2)

Intermittent Connectivity may appear because of:

Propagation effects, shadowing, deep fades

Mobility: paths change too fast; huge overhead for maintenance

AC

B

C

Intermittent Connectivity:Intermittent Connectivity:The Technical Argument(2)The Technical Argument(2)

Intermittent Connectivity may appear because of:

Propagation effects, shadowing, deep fades

Mobility: paths change too fast; huge overhead for maintenance

Power: nodes shut down to save power or “hide”

A B

C

B

Save power (e.g. sensor)

Low probability of detection (LPD) (e.g. army node)

Intermittent ConnectivityIntermittent ConnectivityThe Economical ArgumentThe Economical Argument

Maybe it’s cheaper to not assume connectivity rather than enforce it

Rural areas (countryside, freeways) : overprovision of base stations?

OR just live with a sparse network and “episodic” connectivity?

Sensor Networks (attached on animals): Enough Tx power for connectivity? ($100/node)

Very low power nodes? (e.g. RFID, $1/node)

Wireless Connectivity: A Different ViewWireless Connectivity: A Different View

S

DX Xpath

disruption!

S

DX

Xpath disruption!

S D

End-to-end path

nodelink

Applications: Sensor Networks for Applications: Sensor Networks for Habitat MonitoringHabitat Monitoring

ZebraNet (Princeton) Biologists want to learn animal habits

Size of herds Mobility patterns (running, sleeping, grazing) Daily habits (watering)

Attach “tracking collars” on animals Current technology surprisingly inefficient

Satellite trackers: high energy, low bit rate GPS trackers: often have to retrieve collar for data Sensor nodes with wireless radios?

Applications: Sensor Networks for Applications: Sensor Networks for Habitat Monitoring (2)Habitat Monitoring (2)

Increase power for connectivity? Considerably reduce lifetime of network! (power law) What about obstacles?

Live with a sparse network (connected clusters) Use DTN principles to carry traffic towards sink

Z

ZZ

Z

ZZ

Z

Z Z

Z

Herd of zebras(range of few meters)

Herd of zebras(range of few meters)

base station

Vehicular NetworksVehicular Networks“Drive-Thru Internet”“Drive-Thru Internet”

Vehicle-to-roadside (base station, sensors)

Vehicular NetworksVehicular Networks“Drive-Thru Internet” (2)“Drive-Thru Internet” (2)

Asynchronous operation: OK for e-mail! Web caching; Local information; download news Enough bandwidth even at high speeds!

write email

Internet

send email

send emailemail reply

email reply

Vehicular Networks (VANETs)Vehicular Networks (VANETs)Vehicle-to-Vehicle Networks Vehicle-to-Vehicle Networks

Accident Prevention Traffic Reports Can be combined with Vehicle-to-Roadside

Why Vehicular DTN Networks?Why Vehicular DTN Networks?

Gradual deployment => initially sparse network

Even dense deployments: Paths change too fast! Before enough time to be discovered

An exampleAn example

UCLA’s Vehicular Sensor Network

Internet to Remote CommunitiesInternet to Remote Communities

Internet to underdeveloped countries/remote villages

Rural Kiosks (shared among villagers) Sell/buy agricultural products Banking/Transactions with government Land Titles (Hernando Soto)

Satellite: low bandwidth, expensive Microwave links: expensive, unreliable(?) Dial-up: low bandwidth, unreliable (?) Power network: UNRELIABLE!

Internet to Remote Communities Internet to Remote Communities (2)(2)

Email, cached/asynchronous services Use: Village bus, postman’s vehicle, passing cars

Equip with radio, antenna, and storage Use: dial-up, satellite, microwave links when available

Internet to Nomadic CommunitiesInternet to Nomadic Communities

The SAAMI nomadic community of Lapland

Application: Underwater NetworksApplication: Underwater Networks

Acoustic signal: short range; longer prop delays Environmental sensors: Information collected

by mobile base stations, or even animals equipped with transceivers (e.g. whales)

Tactical (military) NetworksTactical (military) Networks

Communicating beyond enemy lines Need to retain connectivity despite jamming,

losses Powering down nodes (LPD/LPI)

Ad-Hoc Networks (revisited)Ad-Hoc Networks (revisited)

DTN is not only for “extreme” networks Maybe it can be used to achieve real “mobile

computing” without the need for a connected network

Why?Why?

Hotspots Now we have to “look for” the hotspot Mobile computing = the user moves until he can

compute!! Extend Access Point (WiFi) connectivity with ad-hoc

subnetworks Data maybe available at local peers

Establish a peer-to-peer network between local nodes

Local news/info may be available at a node nearby Peer-to-peer wireless

Pocket Switched NetworksPocket Switched Networks

HAGGLE project (www.haggleproject.org) Conference Campus

Summarizing:Summarizing:Delay Tolerant Architecture for WirelessDelay Tolerant Architecture for Wireless

A necessity: Deep space communications, underwater

networks Remote, underdeveloped areas

A choice: Sensor networks Vehicular networks

Extension: Peer-to-peer wireless

Protocol Design: A Paradigm ShiftProtocol Design: A Paradigm Shift

Current protocols are problematic for “challenged environments”

Too many assumptions do not hold

Need new protocols that take the realities of these emerging wireless environments as starting points; no ad-hoc fixes

Security and Application IssuesSecurity and Application Issues

Security: avoid using infrastructure Public Key: need a connected server which will

map name-to-public-key Reputation Systems: revoking a certificate

might take a very long time

Application: must be delay tolerant Network is delay tolerant; what about users?? Applications, interfaces with persistence

More about Security IssueMore about Security Issue

Problems: Secure opportunistic channel establishment Mutual opportunistic authentication Protection from overrun entities PKI works poorly if connectivity is poor

Approach using Hierarchical Identity Based Crypto (HIBC) IBC: generate public key based on a string (e.g.,

address) but private key must be generated by private key generator

HIBC: cooperating hierarchy of PKG’s No lookup required to find disconnected node’s

public key

More about Security Issue (2)More about Security Issue (2)

Bootstrap New user communicates w/PKG over secure

channel to get initial key pair Can also used tamper-resistant device Reversal of accumulated source route used for PKG

to reach new node Use of Time

Add datastamp to public key ID’s helps to minimize compromise time if device is lost

Time-based keys instead of CRL’s (Certificate Revocation List)

• Fail-safe vs fail-insecure (CRLs)

RoutingRouting

Legacy RoutingLegacy Routing

Graph: G = {V,E} V: set of nodes E: set of links w(e): E→

cost function (capacity, energy, queue size)

Routing (S,D):

path PSD = {v0,…,vi,…,vN: vi V, v0 = S, vN = D}

such that eii+1E

and i

1iiP

)w(eminSD

Legacy RoutingLegacy RoutingProactive Protocols (table-driven)Proactive Protocols (table-driven)

Link-state, distance vector Obtain global topology information (Topology Updates)

Dijkstra’s, Bellman-Ford algorithm Calculate minimum cost paths Distributed algorithms

Dijkstra’s algorithm Shortest paths from A to V-{A}

Initialization: cost C(A)=0, C(v) = ; set Q = {empty}

Loop: pick v Q: C(v) is minimum; Q = Q + {v}

if C(v) + wvj < C(j) => C(j) = C(v) + wvj

Terminate: when Q = V

Example of Dijkstra’s AlgorithmExample of Dijkstra’s Algorithm

D

B

C

A

4 2

36

1

L(B)=4

L(C)=6

L(D)=L(A)=0

Step 1

B

D

C

A

4 2

36

1

L(B)=4

L(C)=5

L(D)=6L(A)=0

Step 2

B

D

C

A

4 2

36

1

L(B)=4

L(C)=5

L(D)=6L(A)=0

Step 3

L(D)=6

B

D

C

A

4 2

36

1

L(B)=4

L(C)=5

L(A)=0

Step 4

Legacy RoutingLegacy RoutingReactive ProtocolsReactive Protocols

DSR, AODV

Step 1) Flood Route Request message (RREQ)

Step 2) Nodes that forward RREQ append their ID on header

Step 3) The path that reaches D first = “shortest path”

Step 4) Send back Route Reply (RREP) with reverse path from that found in header

If path breaks Repeat route discovery Or fix locally if other subpaths available are known (route

maintenance)

Legacy Routing for DTNLegacy Routing for DTN

S

D

Proactive Routing(DSDV, OLSR)

Flood Periodic Topology Updates (UPD)

S learns next hop to D

UPD reaches only same cluster as D!

UPD

UPD UPDUPD

UPD

S

D

Reactive Routing(DSR, AODV)

Flood Route Request (REQ) S waits for reply from D

REQ reaches only same cluster as S!

REQREQREQ

REQ

DTN RoutingDTN Routing

Graph is disconnected and/or time-varying

G(t) = {V, E(t)}

G = {V,C}, C = set of contacts ci

ci = {vi,vj,tstart,tfinish,bandwidth,prop. delay,…}

Types of ContactsTypes of Contacts

Scheduled contacts E.g. satellite links, message ferry All info known

Probabilistic contacts Statistics about contacts known E.g. mobility model, or past observation+prediction Bus relay, sensors with random wake-up schedule

Opportunistic contacts Not known before it occurs E.g. a tourist car that happens to drive by the village

Routing: Scheduled NetworksRouting: Scheduled Networks

DTN Routing for Scheduled DTN Routing for Scheduled ContactsContacts

Problem Setting:

Set of contacts ci

Set of storage capacities bci:vi V → Set of messages mi = {s,d,t,m}

Future traffic demand

Evaluation Metrics

Messages Delivered

Average Delay (why?) Connected with message drops

Connected with throughput

Knowledge OraclesKnowledge Oracles

Problem 1) Assume we know data about (“oracle”)

Contacts Summary (Oracle) Statistics about all contacts (frequency, duration, capacity); e.g. contact time cij occurs every T minutes

Contacts (Oracle) Specific info about all contacts; e.g. contact cij(t1), cij(t2), cij(tn)

Queuing (Oracle) Info about all queue sizes Q(nij,t) (all nodes and all times)

Traffic Demand Oracle Info about all future traffic demand m1 = {s1,d1,t1,m1}, m1 = {s2,d2,t2,m2},etc.

Problem 2) Implement each oracle (centralized/distributed)

Routing Algorithm ClassesRouting Algorithm Classes

Zero Knowledge No oracles used; only current/local view available Worst-case performance (baseline)

Complete Knowledge All oracles used + buffer (resource) information Optimal performance (for comparison only)

Partial Knowledge Explore tradeoffs of using only some of the

available oracles

Routing with Zero KnowledgeRouting with Zero Knowledge

Oracles used: None

Algorithm: First Contact Look at currently available contacts Choose one in random or first that comes up

Performance: Random Routing Random walk on time-varying connectivity graph Cycles, oscillate between nodes, dead-end

Routing with Partial KnowledgeRouting with Partial Knowledge

Computing minimum cost (“shortest”) paths

Delay: Transmission Propagation Queuing = Waiting for contact + waiting for queue

to drain

Link weight w(e,t) = message arriving at edge e at time t, is predicted to arrive at end of e at time t + w(e,t)

Modify Dijkstra’s algorithm

Minimum Expected Delay (MED) Minimum Expected Delay (MED) AlgorithmAlgorithm

Oracles used: Contact Summary

Edge cost = average waiting time average contact wait + transmission + propagation

Regular routing => minimize average path delay

Downsides: No reaction to congestion Ignores a good link even if it is available

Dijkstra with time-varying costsDijkstra with time-varying costs

Pseudo-code

t"

t

s)}t,Q(e,(mx)dxc(e,|min{t"s)m,t,(e,t'

Dijkstra with time-varying costs (2)Dijkstra with time-varying costs (2)

Message size = m

Edge Capacity = c(e,t)

Edge Propagation Delay = d(e,t)

Queue backlog = Q(e,t,s)

w(e,t) = w’(e,t,m,s) = t’(e,t,m,s) – t + d(e,t’)

Dijkstra’s with Time-varying CostsDijkstra’s with Time-varying CostsExampleExample

D

B

C

A

cAB=(5,7),(13,16),(20,22)…

L(B)=5

L(C)=9

L(D)=L(A)=0

Step 1 Time = 0

cAC(9,10),(14,17),(25,26),…

cBD=(3,4),(11,15),(26,28)…

cCD=(6,7),(13,15),(23,25)…

cBC=(7,10),(14,15),(26,30)…

wAB(0) = 5

wAC(0) = 9

Dijkstra’s with Time-varying Costs (2)Dijkstra’s with Time-varying Costs (2)ExampleExample

D

B

C

A

cAB=(5,7),(13,16),(20,22)…

L(B)=5

L(C)=9

L(D)=L(A)=0

Step 1 Time = 5

cAC=(9,10),(14,17),(25,26),…

cBD=(3,4),(11,15),(26,28)…

cCD=(6,7),(13,15),(23,25)…

cBC=(7,10),(14,15),(26,30)…

wBC(5) = 2wAC(5) = 6

L(C)=7

L(D)=11

Earliest Delivery (ED)Earliest Delivery (ED)

Oracles used: Contacts Q(e,t,s) = 0

Ignores queuing info Ignores buffer occupancy Source routing

ED is optimal if:1. Low traffic rates (e.g. 1 msg)2. Or infinite bandwidth and buffer

Problems If an edge is missed due to lack of bandwidth => may

result in disastrous behavior

Earliest Delivery with Local Earliest Delivery with Local Queuing (EDLQ)Queuing (EDLQ)

Oracles used: Contacts PLUS: look at local queues for choosing paths:

e = (s,*) Q(e,t,s) = data queued for e at time totherwise Q(e,t,s) = 0

Problems: Buffer overflow Potential loops (not consistent topology view

between nodes when running Dijkstra)

Earliest Delivery with Global Earliest Delivery with Global Queuing (EDAQ)Queuing (EDAQ)

Oracles used: Contacts, Queuing Q(e,t,s) = data queued for e at time t at node s Source routing

Requires bandwidth reservation (ensure that no later arrivals change the experienced queue size) How is this to be implemented? Current queuing knowledge depends on reservations

up to now Still no bandwidth

Variations and Practical Variations and Practical ConsiderationsConsiderations

Re-computing routes for ED (earliest delivery) Message might miss contact due to queuing If missed => re-compute remaining shortest path (at

intermediate node) Implementing queuing oracle with local info

Local queuing keeps track of messages it forwards and their path

Extrapolate (expected) queue sizes at other nodes (based on capacity and traffic assumptions)

Message/Path splitting Message fragmentation Multi-path routing (e.g. for MED algorithm)

Routing with Complete KnowledgeRouting with Complete Knowledge

What are we missing?? Buffer constraints Future traffic demand

How do we solve this?Multi-commodity flow problem: balance flows over linksDynamic version: balance flows over contacts

We can formulate a Linear Program for the problem in hand note: variable space might grow exponentially

Routing with Complete Knowledge (2)Routing with Complete Knowledge (2)

Many ideas from graph theory and network flow problems Optimize some metric (e.g. average path cost) While abiding to constraints (e.g. link/buffer

capacities)

Transport Networks with time-varying graphs Quickest transshipment of cargo with time-varying

links (e.g. a periodic cargo flight) Dynamic Network Flows

Rather difficult problems in general

Performance ComparisonPerformance Comparison

A network of (20) city buses with radios Varying traffic load

Conclusion 1: ED(-,LQ,AQ) algorithms better Conclusion 2: ED algorithm optimal for small loads

Performance Comparison (2)Performance Comparison (2)

Large bandwidth => ED is optimal Small bandwidth => ED closer to MED

Performance Comparison (3)Performance Comparison (3)

Higher transmission range => more contacts => easier to route

Smaller buffer space => ED* schemes perform better

Performance Comparison (4)Performance Comparison (4)

Practical Routing for DTNsPractical Routing for DTNs

How to implement Oracles

The contact oracle:

No need to assume full knowledge

MED: expected contact delay (average over all future contacts)

MEED: estimate future contact delay, based on past contacts (sliding window)

MEED Algorithm MEED Algorithm (Minimum Estimated Expected Delay)(Minimum Estimated Expected Delay)

Keep history of past contacts

Maintain running average Sliding window Large window => slow reaction to changes Small window => too many updates, oscillations

Link-state epidemic dissemination Whenever a contact changes significantly (x% form

previous estimate) => flood topology update packet

Link-state Topology => Epidemic Link-state Topology => Epidemic DisseminationDissemination

Message vector i Table with topology updates from nodes NSi

Two nodes meet: exchange message vectors NSA and NSB

Exchange topology updates not in common until NSA=NSB

Flood new topology updates further

Calculating the Routing PathCalculating the Routing Path

Eventually topology updates from all nodes (global topology) – not all equally “fresh”

Source Routing? Intermediate hops might have more recent info than source

Hop-by-Hop Routing? What if an infrequent contact (large expected wait) arrives first?

Per-contact routing = assign current contact cost 0

Example of MEED routingExample of MEED routing

Link AB (path ABD) are better on average than link AC (path ACD)

But if at time t link AC is up, then ACD is better! (per contact routing)

Link-state DTN Routing: Link-state DTN Routing: ConclusionConclusion

Link-state overhead: O(N2) If node mobility not restricted everyone sees

everyone else, eventually

Can be an interesting approach IFF:- Nodes are static: e.g. sensor with wake-up

schedule- Topology changes infrequently/network is dense

BUT: If mobility pattern does not have enough structure (e.g. IID) then it degenerates to random forwarding

Extensions?Extensions?

How to extend to keep track of

1) average queuing

2) average traffic requirements

Approximate other algorithms EDLQ EDAQ LP?

Message FerryingMessage Ferrying

A sparse network of “production” nodes Nodes may be static (e.g. sensors) => how to

bridge partitions? Nodes may be mobile, but slow => long delays

waiting for a contact to occur may take time

Solution: Use specialized nodes (DataMules or Message Ferries) to carry traffic between production nodes Ferries are always mobile No energy considerations

Message FerryingMessage Ferrying1. Enforce Ferry Trajectory1. Enforce Ferry Trajectory

Robots, unmanned aerial vehicles (UAVs) Li al ‘03, Zhao et al ’04

S

D

DataMule

DataMule

DataMule

DataMule

The problem: design optimal trajectories

Message FerryingMessage Ferrying2. Use Existing Trajectories2. Use Existing Trajectories

Scheduled mobility: Uncontrolled but predictable mobile nodes (e.g. city buses) Jain et al. ’04

S

D

Predict ferry mobility Optimal use of available ferry bandwidth Production node trajectory

Message Ferrying: The Problem Message Ferrying: The Problem SpaceSpace

Ferry mobility1. Designed for non messaging reasons (buses)2. Optimized for message transfer (robots)

Production node mobility Static vs. Mobile

Number of ferries Single vs. Multiple ferries

Ferry relaying: Yes/No

Node Relaying Node-to-ferry vs. node clustering

Ferries for non-messaging Ferries for non-messaging reasonsreasons

No explicit trajectory design + known schedules=> could apply principles from earlier presented algorithms (e.g. ED, MED, etc.)

No trajectory design + no/limited knowledge of schedules

=> use opportunistic routing, e.g. epidemic (later)

Focus on trajectory design cases

Static Nodes + Single FerryStatic Nodes + Single Ferry

bij = traffic (rate) requirement from node i to j

Ferry route L of length |L|

Ferry speed f: ferry cycle T = |L|/f

= average delay for traffic from i to j Wait for ferry: T/2f Upload data (queuing at node): f(ferry in range, upload rate) Wait for destination (on ferry): T/2f Download data to recipient: f(ferry in range, download rate)

average delay for all traffic

Lijd

ji,ij

ji,

Lijij

L

b

db

d

Static Nodes + Single Ferry (2)Static Nodes + Single Ferry (2)

Problem: find trajectory L, such that:

-

- while satisfying traffic matrix B = {bij}

Lij

Ld min (Delay Problem)

(Bandwidth Problem)

Delay ProblemDelay Problem

Assume infinite/enough bandwidth for bij

All data uploaded when encountered

,such that L passes by all nodes

Step 1: TSP approximation algorithms

Step 2: Local optimization

Lij

Ld min

If bij = bji => dL= |L|/f

Delay Problem = Traveling Salesman Problem (NP-complete)

Traveling Salesman ProblemTraveling Salesman Problem

Given a (connected) weighted graph Find a path that:

Visits all nodes exactly once And has a minimum cost

Bandwidth ProblemBandwidth Problem

Increase route (local detour) to satisfy bandwidth requirement

Minimize amount of increase (Linear Program)

minimize

subject to

i

jj

i sx|L|

2r)W(x

Path extension for i

Tx rate

Traffic demand of i (per cycle)

0 iij

jji x 2rW,|L|sxsWx

i

ix

Optimal Trajectory Design:Optimal Trajectory Design:The online problemThe online problem

Previous case: traffic requirements known in advance => offline, optimal solution

What if traffic requests arrive on-demand

Problem: design trajectory to optimally serve existing requests Minimize message drop rate Minimize expected delivery delay

Mobile Nodes + Single FerryMobile Nodes + Single Ferry

Ferry has a predefined route, which is known Nodes decide when to move close to the ferry

to upload data (Node-Initiated Message Ferrying, NIMF)

Task (e.g. sensing) Receiver

Mobile Nodes + Single Ferry (2)Mobile Nodes + Single Ferry (2)

Goal 1: minimize time not performing task E.g. time moving = time not sensing

Goal 2: minimize message drop ratio While “working”, outgoing messages accumulate in

buffer => buffer overflow While not going to ferry, incoming messages

accumulate in ferry => buffer overflow Messages have TTL => if not delivered in time they

are dropped

When to Move Towards Ferry? When to Move Towards Ferry?

Keep msg drop rate low: Di(t) = msg drop rate at i (outgoing)

Df->i(t) = msg drop rate for i at ferry (incoming)

Gi = msg arrival rate at i

Gf->i = msg arrival rate at ferry for I

(Di(t) + Df->i(t))/(Gi+ Gf->i) > (condition 1)

Keep fraction of time not performing task low:

(task time)/(total time) > w (condition 2)

Shortcomings of NIMFShortcomings of NIMF

What if node task is correlated with message delivery? e.g. task = sensing data that needs to be periodically

transmitted to a sink Conditions 1 and 2 may not be able to be

satisfied at the same time! WHY?

How are the nodes mobile? Robots? A person decides to move close to the bus?

Static Nodes + Multiple FerriesStatic Nodes + Multiple Ferries

Case 1: No ferry interaction

Case 2: Ferry relaying Ferries can exchange data with each other Synchronization between ferries

Case 3: Node relaying Node overhead for storing inter-relay traffic

Ferry Trajectory Design Ferry Trajectory Design

Phase 1: Assign nodes to ferries Phase 2: Choose path for each ferry

Phase 3: Fine tune route to meet traffic demand

Single-Route Algorithm (SIRA)Single-Route Algorithm (SIRA)

All nodes follow the same route Constant speed and distance No interaction

Phase 1: all nodes to all ferries

Phase 2,3: similar to single ferry step 1: Traveling Salesman approximation step 2: Local delay optimizations (waitm = wait1/m)

step 3: minimum route extension to satisfy traffic

Ferries

Multi-Route Algorithm (MURA)Multi-Route Algorithm (MURA)

Different Routes + no Relaying

Algorithm:Step 1: assume n ferries – assign one to each

nodeStep 2: estimate ED (expected delay) and

reassign until m ferries and ED minimumStep 3: refine assignment for end-to-end

feasibilityStep 4: calculate optimal route for each ferry

independently

Estimating ED (expected weighted Estimating ED (expected weighted delay)delay)

Calculate weighted delay per route Say route with k relays

Route delay is a tuple (E*,E’) E* = excess capacity E’ = expected delay if capacity is met a = total data rate = service rate of route = 0.5 k W

μa if ),a-μ

a)(1

k

1L(1

μa if 0,E

μa if 0,

μa if μ),aL(1E

'

*

(Re)assigning Nodes to Routes(Re)assigning Nodes to Routes

Re-assign based on 4 operations – goal is to get m ferries and minimum ED

Op.1) overlap (i,j): extend one route to include node of other

Op.2) merge (i,j): combine routes i,j into one; ferries = ki+kj

Op.3) merge-(i,j): combine routes i,j into one; ferries = ki+kj-1

Op.4) reduce(i): ki = ki - 1

(Re)assigning Nodes to Routes(Re)assigning Nodes to Routes

Problem 1: sender-destination not in same route Problem 2: route traffic demand > route capacity

Continue overlap/merge until assignment is feasible…OR

The algorithm

Node Relaying Algorithm (NRA)Node Relaying Algorithm (NRA)

Multi-hop routing:

node S ferry fi node r ferry fj node D

Bound number of hops to maintain throughput (Gupta et. al)

Overhead on relaying nodes

Node Relaying Algorithm (NRA) (2)Node Relaying Algorithm (NRA) (2)

For each S-D pair nij: geographic routing => path of cells (e.g. C2,C3,C4)

Overlap operation between Cx,Cy => shared node is relay Assign ferries: 1 to each cell -> add extra ferry to highest EWD

Ferry Relaying Algorithm (FRA)Ferry Relaying Algorithm (FRA)

Data is relayed between ferries => no node relaying

Similar to NRA algorithm…until last step After routes are calculated per cell, need to

synchronize between cells (not easy)

Performance Analysis Performance Analysis with Multiple Ferrieswith Multiple Ferries

Some simulation results show that MURA (non-relaying) has the best performance

Is it because of the extra resources required by message relaying?

Is it because of the specific algorithms chosen for relaying (i.e. could find better ones)

Does it depend on traffic pattern? if uniform traffic, and no traffic weights, wouldn’t MURA routes need to cover ALL nodes??

Multiple Ferries with Independent Multiple Ferries with Independent but Known Routesbut Known Routes

Ferry mobility is not related to data delivery (e.g. bus of networks) Hence, it cannot be changed

Calculate inter-ferry contacts based on their mobility schedules

Apply algorithms like MED, ED, etc. Maybe even MEED, or some opportunistic

routing if schedules are not fully deterministic (e.g. traffic jam, etc.)

Summarizing: DTN RoutingSummarizing: DTN Routing

Scheduled/Known Contacts: Modified Dijkstra Algorithm (time-dependent weights)Dynamic Flow Problems

Enforced Contacts with Specialized Nodes (Ferries):Design of Optimal Mobility Paths (TSP)Optimal Assignment of Ferries

Opportunistic Contacts? Contacts not known in advance No extra nodes; only the mobility of the nodes themselves

is available

Routing: Opportunistic Routing: Opportunistic NetworksNetworks

Routing with Scheduled ContactsRouting with Scheduled Contacts

Graph is disconnected and/or time-varying Set of contacts C: known Set of nodes V: known

A

C

B

D

D

Tx Range

(B,D) = {10,12},{19,21}

(C,D) = {8,10},{15,17}

D

(B,D) = {10,12},{19,21}

(C,D) = {8,10},{15,17}

Tx Range

D

Routing with Unknown ContactsRouting with Unknown ContactsOpportunistic RoutingOpportunistic Routing

Graph is disconnected and/or time-varying Set of contacts C: unknown! Set of nodes V: often unknown too!

A

C

B

D

D

Tx Range

(B,D) = ??

(C,D) = ??

D

WHERE IS D?

D

WHERE IS D?

D

WHERE IS D?

Epidemic RoutingEpidemic Routing

Give a message copy to every node encountered essentially: flooding in a disconnected context

A

C

B

D

D

EF

D

D

D

D

Epidemic Routing (2)Epidemic Routing (2)Message VectorsMessage Vectors

Node A encounters node B

Dest ID Seq. Num.

D 0

G 1

F 0

Dest ID Seq. Num.

D 0

E 0

F 0

F 1

Message Vector of A Message Vector of B

(G,1)

(E,0),(F,1)

Epidemic Routing (2)Epidemic Routing (2)Message VectorsMessage Vectors

After message exchange

Dest ID Seq. Num.

D 0

E 0

F 0

F 1

G 1

Dest ID Seq. Num.

D 0

E 0

F 0

F 1

G 1

Message Vector of A Message Vector of B

EncountersEncounters

Two nodes “encounter” each other when they are inside Transmission Range

How do they know?

Beacons: periodically transmit a “HELLO” message to discover neighbors e.g. Bluetooth association

Implications:

1. Some encounters might be missed

2. Encounter not immediately when in range

Encounter => MSG vector exchange (+other info)

Delay of Epidemic RoutingDelay of Epidemic Routing(a coloring problem analog)(a coloring problem analog)

S

D

1

2

2

T1 = 1 red → any blue

T2 = any of 2 red → any blue

K

1iiT

M

1K1M

1ED

M nodes

I.I.D. mobility

Epidemic Routing PerformanceEpidemic Routing Performance

Delay for Epidemic Routing

0

1000

2000

3000

4000

5000

6000

7000

de

live

ry d

ela

y (

tim

e u

nit

s) epidemic

optimal

Transmissions for Epidemic Routing

0

20000

40000

60000

80000

100000

120000

140000

160000

tota

l tra

ns

mis

sio

ns

epidemic

optimal

Redundant copies reduce delay But: too much redundancy is wasteful and often

disastrous (due to contention)

increasing traffic increasing traffic

Too many transmissions Plagued by contention

Randomized Flooding (Gossiping)Randomized Flooding (Gossiping)

“Spread” the message with a probability p ≤ 1 p = 1) epidemic p = 0) direct transmission

D

E

D

Outcome < p) Give a copy

D

Outcome > p) Don’t give copy

K-neighbor EpidemicK-neighbor Epidemic

Each node receiving a copy, can copy it again up to K times

F

E

D

D

G

J

K = 2

D

Already given 2 copies!Node E cannot fwd more

Flooding-based SchemesFlooding-based Schemes

Can reduce the transmissions of epidemic With some penalty on delay!

Given long enough time, all nodes receive a copy Still flooding-based!

Let’s re-think the problem. Must we flood everyone (or almost everyone)?

Single-copy vs. Multi-copy Single-copy vs. Multi-copy routing strategiesrouting strategies

“Single-copy”: only a single copy of each message exists in the network at any time

“Multi-copy”: multiple copies of a message may exist concurrently in the network

Single-copy Multi-copy

+ lower number of transmission

+ lower contention for shared resources

+ lower delivery delay

+ higher robustness

Choosing A Next HopChoosing A Next Hop

A local and intuitive criterion: A forwarding step is efficient if it reduces the expected distance from destination

usually: reduction of expected distance => reduction of expected hitting time

Efficient Routing : Ensure that each forwarding step on the average reduces distance or hitting time with destination

A

Destination

B

C

Direct transmissionDirect transmission

Forward message only to its destination simplest strategy minimizes transmissions

S

C

B

D

D

EF

D

The Delay of Direct TransmissionThe Delay of Direct Transmission

EM: expected meeting time 2 nodes starting from stationary distribution EM > ED: EM is a lower bound on delay!

ET: expected hitting 1 node is static (with position from uniform distribution

SD

D

D

Randomized routingRandomized routing

A node forwards message to a new node with probability p; NO Duplication! It’s Hand-over!

A

C

B

D

D

EF

D

D

D

RandomizedRandomizedWhy Transmitting is Faster Than Not!Why Transmitting is Faster Than Not!

Transmission Speed is Faster than Node’s Speed!

A

CB

D

D

F

DD

D

Why Transmitting is Faster Than Not!Why Transmitting is Faster Than Not!

ETD

AB dB

EATD = ET(d)

2

1)ET(d1)ET(dTE DB

Randomized

PAB = ½ PBA = ½

tX(Y): time since X last saw Y

Indirect location information diffused with node mobility

smaller timer closer distance For most mobility models

Utility-based RoutingUtility-based Routing

A

D

BtB(D) = 100

t(D) = 0

t(D) = 26

t(D) = 68

tA(D) = 138

t(D) = 218

Last encounter timers

D D

Utility UX(Y) = f(tX(Y))

Policy: forward to B iff UB(D) > UA(D) + Uth

Utility-based Routing (cont’d)Utility-based Routing (cont’d)

Result 1: Utility-based routing has a larger expected delay reduction than the simple randomized policy

ETD

AB dB

EATD = ET(d)

2

1)ET(d1)ET(dTE DB

Randomized

1)ET(d)P(11)ET(dPTE BABADB

Utility-based

PAB = ½ PBA = ½ PAB < ½ PBA > ½

tA(D) = 20

Problems with Utility RoutingProblems with Utility Routing

Timer values are good indicators of proximity only if their value is small.

Timers/utility updated only when destination is found If source’s (relay’s) neighbors happen to have larger timers, message gets

stuck for a long time

A

D

tA(D) = 20

tA(D) = 200

tA(D) = 20

Transitivity IdeaTransitivity Idea

If A sees B, and B has recently seen D, then A is probably close to D too. update tA(D) when A encounters B

• cache of most fresh entries for scalability

(dAB): expected time to cover distance dAB

tA(D) = tB(D) + (dAB)

(dAB) = (dAB)2 (random walk)

(dAB) = dAB (random waypoint)

No transitivity Transitivity

PDF of timer value of A for D, when A is far from D

Seek and FocusSeek and FocusA hybrid routing strategyA hybrid routing strategy

Set of node utility values: A time-varying, probabilistic utility-field with the global maximum at destination

Utility-based routing is a greedy search of the field Issue: message often gets stuck at local maxima

Seek and Focus

Seek phase: If current utility is below Uf perform randomized forwarding (quickly look for a “good lead”)

Focus phase: If current utility is above Uf perform utility-based routing for at most Tf time units (follow the lead)

Re-seek phase: If no better relay is found for Tf, perform randomized routing for at most Tseek or until a better relay is found (if stuck at local maximum, do “perimeter search”)

Oracle-based optimal Oracle-based optimal algorithmalgorithm

Assume all future movements are known Then, the algorithm picks the sequence of

forwarding decisions that minimizes delay

Note that flooding (multi-copy strategy) has the same delay as this algorithm when there is no contention

Effect of ConnectivityEffect of ConnectivityRandom Walk (“local” model)Random Walk (“local” model)

Delivery Delay (Random Walk)

10

100

1000

10000

100000

40 (8.6%) 50 (14.8%) 60 (27.7%) 70 (52.9%) 80 (79.2%)

Tx Range (connectivity %)

tim

e u

nit

s (L

OG

SC

AL

E)

Transmissions (Random Walk)

0

100

200

300

400

500

600

700

800

40 (8.6%) 50 (14.8%) 60 (27.7%) 70 (52.9%) 80 (79.2%)

Tx Range (connectivity %)

tran

smis

sio

ns

(per

msg

)

randomizedutility (no trans)utility (trans)seek&focus (trans)optimal

Randomized has smallest delay But, with order(s) of magnitude more transmissions

Utility-based with transitivity performs very few transmissions But, with up to 10x worse delay than randomized Without transitivity things are even worse

Seek & Focus achieves both low delays (close to randomized) and low transmissions (slightly higher than utility-based)

randomized

randomized

Y-axis: Transmissions per msg

X-axis: Tx Range (Connectivity)Increasing connectivity Increasing connectivity

Y-axis: Delivery delay (LOG SCALE)

utility

utility

seek&focus

seek&focus

optimal

Effect of Connectivity Effect of Connectivity Random Waypoint (non-local)Random Waypoint (non-local)

Delivery Delay (Random Waypoint)

10

100

1000

10000

30 (5.7%) 40 (8.6%) 50 (14.8%) 60 (27.7%) 70 (52.9%)

Tx Range (connectivity %)

tim

e u

nit

s (L

OG

SC

AL

E)

Transmissions (Random Waypoint)

0

20

40

60

80

100

120

140

30 (5.7%) 40 (8.6%) 50 (14.8%) 60 (27.7%) 70 (52.9%)

Tx Range (connectivity %)

tra

ns

mis

sio

ns

(p

er

ms

g)

randomutility (no trans)utility (trans)seek&focusoptimal

Randomized not fast for non-local mobility models A bad forwarding decision is costly Still high transmissions

Utility-based has good delays and low transmissions Choice of the right transitivity function is important! No transitivity, or wrong transitivity (e.g. random walk) is really bad.

Seek & Focus achieves even better delays Yet, with slightly more transmissions

randomized

randomized

utility

utility

Single-copy Strategies:Single-copy Strategies:Lessons LearnedLessons Learned

Utility-based forwarding can be a good routing primitive ONLY IF utility function is correctly designed!

(transitivity + mobility model stats) Seek and Focus (hybrid) is the best candidate if

a single-copy routing scheme has to be used can fix some of the utility-based routing shortcomings

BUT, best single-copy strategy still an order of magnitude slower than optimal!

2-hop Scheme2-hop Scheme

Source gives a copy to any relay encountered Relays can only give copy to destination

Src

C

B

Dst

D

EF

D

D

D

Relay C cannot FWD to B

Relay C can FWD to Dst

2-hop Scheme Performance2-hop Scheme Performance

How many transmissions?

(M-1)/2 Delay?

T1 = time until source meets any node (M-1)

T2 = time until source meets any node (M-2) epidemic: time until 2 red meet any of M-2 (smaller)

BUT: a relay node may meet destination in the meantime!

1)ED(nnM

1nMETED(n) 1n

Rem. Delay after n copies

Prob{next node not DST)

Controlled Replication Controlled Replication (“Spraying”)(“Spraying”)

2-hop scheme uses (M-1)/2 copies Still a lot! Only half of epidemic

Limit number of copies to L (small, fixed) Transmissions = L!

L = 2) Achieves O(1) per node capacity and deals with Kumar’s and Gupta’s conjecture (capacity →0) (Grossglauser et al. ‘01)

L > 2 and L = O(1): (constant L) Still capacity gain Transmissions << M Multi-path diversity to reduce delay (Spray & Wait)

Source SprayingSource Spraying

Only source can give a copy (like 2-hop)

Start with L copies; give one to L-1 first relays met

Delay (Src Spray) > Delay (2-hop) Assuming no contention!

Tree-based SprayingTree-based Spraying

Use forwarding tokens; SRC starts with L tokens When L = 1, can only forward to DST

Src

C

B

Dst

D

EF

D

D

D

DL = 4

L = 2

L = 2

L = 1

L = 1

L = 1L = 1

Tree-based Spraying (2)Tree-based Spraying (2)

I.I.D. movement => Binary is optimal (nj = j/2) Heterogenous => high complexity

L

L-n1n1

j

j-nj nj

Binary Spraying = Time-limited Binary Spraying = Time-limited EpidemicEpidemic

Do epidemic spreading until time T

After T, switch to direct transmission

If T = ETL then the same as token-based (on average Remember: ETL = time until epidemic “covers” L

nodes

Replication Method MattersReplication Method Matters

1. Efficient spraying becomes more important for large L

2. Few copies suffice to achieve a delay only 2x the optimal!

(analysis)

Delay of Spray and Wait

0

500

1000

1500

2000

2500

3000

3500

4000

5 10 15 20

L (# of copies)

tim

e u

nit

ssource spray and waitbinary spray and waitoptimal

100x100 network with 100 nodes

Effect of Traffic LoadEffect of Traffic Load

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

To

tal T

ran

smis

sio

ns

random-floodutility-floodseek&focusspray&wait(L=16)spray&wait(L=10)

(Rand. Way. - 500x500 grid, 100 nodes, Tx Range = (Rand. Way. - 500x500 grid, 100 nodes, Tx Range = 10)10)

Transmissions Delay

Low traffic >10x epidemic

3-4x other multi-copy

same as epidemic

1.4-2.2x other schemes

High traffic 1.8-3.3x same as above

increasing traffic

0

500

1000

1500

2000

2500

3000

3500

4000

4500

epidemic

random flood

utility flo

od

spray&wait(L=10)

spray&wait(L=16)

seek&focus

Del

iver

y D

elay

(ti

me

un

its)

increasing traffic

0

500

1000

1500

2000

2500

3000

3500

4000

4500

epidemic

random flood

utility flo

od

spray&wait(L=10)

spray&wait(L=16)

seek&focus

Del

iver

y D

elay

(ti

me

un

its)

increasing trafficincreasing traffic

Covered by Relay 1

3

Spray and Wait: A good scenarioSpray and Wait: A good scenario

S

D

1

2

4

5

6

7

8

9

10

11

12 13

14

1615

Relays are highly mobile

Relays routes are uncorrelated

Covered by Relay 2

3

Spray and Wait: A bad scenarioSpray and Wait: A bad scenario

S

D

1

2

4

5

6

7

8

9

10

11

12 13

14

1615

Relays move slowly

Relays move locally and are correlated

Node S’ community Node D’s community

Spray & Wait PerformanceSpray & Wait Performance

Spray and Wait has desirable performance

IF nodes move frequently around the network (e.g. VANETs, a mesh network over city buses, etc.)

But, Spray and Wait may get in trouble if nodes’ mobility is restricted inside a local area nodes’ mobility is extremely slow (e.g. human

mobility)

Spray & FocusSpray & Focus

1st Phase: Binary Spraying like Spray & Wait

2nd Phase: Utility-based routing with transitivity for each copy

Advantages: still: few transmission + redundant copies plus: take advantage of good transmission

opportunities copies don’t get stuck in local neighborhood

Effect of Connectivity: Random WalkEffect of Connectivity: Random Walk

0

10

20

30

40

50

60

70

utility-flo

od

random-flood

spray&wait

spray&focusTra

nsm

issi

on

s (t

ho

usa

nd

s)

K = 15 (7.8%)

K = 20 (14.9%)

K = 25 (35.9%)

K = 30 (68%)

K = 35 (92.5%)

0

500

1000

1500

2000

2500

3000

epidemic

utility-flo

od

random-flood

spray&wait

spray&focus

De

liv

ery

De

lay

(ti

me

un

its

)

TransmissionsTransmissions Delivery DelayDelivery Delay

utility-fl

ood

random-fl

ood

spray &

wait

spray &

focus

epidemic

utility-fl

ood

random-fl

ood

spray &

wait

spray &

focus

Transmissions: still ~10x improvement for both protocols Spray & Wait is slow: suffers from locality of movement Spray & Focus is the fastest:

Takes advantage of locality Close-to-optimal (unless very low transmission range)

fastest

slow!

(500x500 square, 100 nodes)(500x500 square, 100 nodes)

Heterogeneous ScenariosHeterogeneous Scenarios

Community (local) Nodes

Base Stations (pstatic)

Fast/Mobile Nodes (pfast)

pL(i)

1-pL(i)

stay inside community

1-pR(i)

Roam around network(infrequent)

Community (local) Nodes

Base Stations (pstatic)

Fast/Mobile Nodes (pfast)

pL(i)

1-pL(i)

stay inside community

1-pR(i)

Roam around network(infrequent)

Effect of Connectivity: Effect of Connectivity: Community-based Mobility Community-based Mobility

(cont’d)(cont’d)

Delay Improvement by Spray and Focus

0

5

10

15

20

25

40 (8.6%) 50 (14.8%) 60 ( 27.7%) 70 (79.2%)

Transmission Range (Connectivity %)

Del

ay(S

W)

/ Del

ay (

SF

) Scenario 1

Scenario 2

Scenario 3

Scenario 1: Homogenous

Community nodes (100%)

Scenario 2: Two types of nodes

Community nodes (90%)

Roaming nodes (10%)

Scenario 3: Four types of nodes

Community nodes (40%)

Local nodes (40%)

Roaming nodes (10%)

Static nodes (10%)

Spray Routing: SummarizingSpray Routing: Summarizing

“Non-local” mobility models: Spray and Wait 10x fewer transmissions AND smaller delay! Spray and Focus has similar performance; but we

don’t really need it

“Local” mobility models: Spray and Focus Spray and Wait is slow Spray and focus has close-to-optimal performance

Why does spraying work? Law of diminishing returns for number of copies used

ImprovementsImprovements

Smart Replication Who should get the copies?

Other Utility Functions Energy Mobility Trustworthiness GPS location Queue Size Hybrid

An Analytical FrameworkAn Analytical FrameworkWhy do we need it?Why do we need it?

Confirm our previous observations Predict performance under a larger range of

settings

Use this theory for system-design e.g. choose the right number of copies for Spraying

approaches

An analytical framework for An analytical framework for “mobility-assisted routing”“mobility-assisted routing”

Component 1) Hitting and Meeting Times: the basic building block; depends on mobility model; calculated for: random walk, random direction, random

waypoint, and a new model

Component 2) Multiple copies

Component 3) Forwarding a message

“Plug n’ calculate”: calculate the delay of any scheme by combining the right components

Performance AnalysisPerformance AnalysisAn Analytical FrameworkAn Analytical Framework

Assumptions Network area:

• Random walk: grid (torus) – discrete movement• Waypoint-based models: square (torus) – continuous movement

Infinite bandwidth, infinite buffers calculate delivery delay

Notation: M: number of nodes N: network area K: transmission range (small enough to have partial

connectivity ) EATB: expected hitting time from A to B ET: expected hitting time starting from stationary distribution EM: expected meeting time between two nodes starting from

stationary distribution

Random WalkRandom WalkHitting Time (Tx Range K ≥ 0)Hitting Time (Tx Range K ≥ 0)

Hitting time ET = EXTA (EM still equal to ET/2)

X

Y

A(K)

K = 3

1) EXTA = EXTY - EATY

2) EXTY = cNLogN

3)

N 12

2K2TE

K

1K

YA

12

2K2cLogNNET

K

1K

p = 0.25

Random Direction (Random Waypoint)Random Direction (Random Waypoint)Hitting TimeHitting Time

Movement is a set of “epochs”

Method: 1. Probability that any given epoch

hits the destination

2. Expected number of such epochs (geometric)

3. Multiply by the expected duration of each epoch Te

epochstart

epoch finish

D

N

N

K

LS

N

2KLPhit

2KL

N

P

1N

hite

eT2KL

NET

4. EM: divide by (normalized) relative

speed between S and D, vr

rv

ETEM

]|]vE[|

|]vvE[|

S

DS

Modeling Epidemic SpreadingModeling Epidemic SpreadingCase Study: Epidemic Routing/OptimalCase Study: Epidemic Routing/Optimal

S

D

M nodes

Tx Range = K

1-M

EM

2)-2(M

EM1

2

21)-(M

HEM ED 1M-

opt

where HM-1 is the

harmonic sum

HM 1 1

ii1

M 1

Modeling Epidemic SpreadingModeling Epidemic SpreadingMarkov Chains (Probabilistic Model)Markov Chains (Probabilistic Model)

Epidemic Routing

2-hop Routing

N+1: nodes1/: meeting timestate i: i copiesstate A: DST found

Prob(ii+1,t) = (N-i)*i*t

Modeling Epidemic Spreading: Modeling Epidemic Spreading: Fluid Models (Deterministic)Fluid Models (Deterministic)

Assume N (num. of nodes) I(t) = average number of “infected” nodes at time t

(1) P(t) = P(Td <t) CDF of delivery delay

P(t+dt)-P(t) = Prob{t ≤ Td ≤ t + dt}

= Prob{DST meets one of nI(t) infected nodes in [t,t+dt]} * Prob(Td>t)

= E[Prob(DST meets nI(t) | nI(t)] * (1-P(t))

= E[nI(t)dt]*(1-P(t))

= I(t) * (1-P(t)) dt

=> (2)

I I)(N λ(t)I '

P)(1 I λ(t)P '

Modeling Epidemic Spreading (2): Modeling Epidemic Spreading (2): Fluid Models (Deterministic)Fluid Models (Deterministic)

Ordinary Differential Equations (ODEs) Or systems of ODEs Sometimes PDEs, too.

Solve (1) for I(t) – it’s a separable ODE

Replace I(t) in (2) and solve for P(t)

Expected Delay

λNt1)e(N1

NI(t)

λNte 1)(N

NP(t)

1)λ(N

lnNP(t))dt(1ET

0

d

Modeling Message ForwardingModeling Message ForwardingCase Study 2: Randomized algorithmCase Study 2: Randomized algorithm

D

q: probability of Tx jump

q =

1-q: probability of random walk jump

f(K)

f(K): average transmission distance

Average jump length:

D = 1 – q + q f(K)

p • P(at least one node within range)

Approximate actual message movement with a random walk performing D independent 1-step jumps at each time slot

Note: This walk is slower than the actual walk would reach destination later, on the average

Define an appropriate martingale to show that:

1D

ED 2ED dt

rnd

Destination movement

Message movement

Note: D + 1 ≥ 2 randomized is faster than direct transmission

Random Direction/Waypoint: Similar procedure gives exact result

Message Forwarding (cont’d)Message Forwarding (cont’d)Case Study 2: Randomized algorithmCase Study 2: Randomized algorithm

Utility-based algorithms Utility-based algorithms (no transitivity) (no transitivity)

0 1 2 r-1 r r+1r-2 r+2r-K r+K N

Prob{node with higher utility within range AND node is closer to D}txp

txp

Prob{node with higher utility within range AND node is farther than D}

p: probability of no forwarding => random walk step

p p p

pppppp

p p p

D

EDutil is simply the expected hitting time from stationarity to a state ≤ K

*Similar procedure for seek and focus without transitivity

Source Spray and WaitSource Spray and Wait

Let ED(i) denote the expected remaining delay after i copies are spread

Clearly EDsw(src) = ED(1) ED(1) can be calculated through a system of recursive equations

EDdt

i(M- i)

Time until a new node is found

If not destination, add extra term

iM

1iM

P(not destination)

If new node found by source, forward another copy

1)ED(ii

1

ED(i)i

1i

If found by relay, do nothing

Expected remaining delay after i copies are spread

ED(i)

If destination, stop

A similar recursion procedure gives the delay of Optimal Spray and Wait

Case Study: Choose the Number of Case Study: Choose the Number of Copies for Spray and WaitCopies for Spray and Wait

Exact delay not in closed form Derive a bound in closed form This is an upper bound for any Spray and Wait algorithm

EDsw ES M L 1

M 1 EW

Spray Phase Wait Phase

Probability a wait phase is needed

1L

1i iM

EM ES

L

EM EW

Bound is tight for L<<M

Choosing L to achieve specified Choosing L to achieve specified delaydelay

Suppose we want to achieve EDsw= EDopt for some >1

We choose the minimum L that satisfies

1)-(M

HEM =

L

EM

1M

1LM iM

EM 1M-1L

1i

1.5 2 3 4 6 8 10

Lmin 21 13 8 6 4 3 2

Some values (for M=100):

Upper bound on EDsw EDopt

What If Network Parameters Are What If Network Parameters Are Unknown?Unknown?

Estimation of M (200x200 grid)

050

100150200250300350400

0 1000 2000 3000 4000

number of samples

M v

alu

e

Actual M = 200

Estimated M

1M

EMT1

Applies to any mobility model with exponential meeting times

Method:

2M

1

1M

1 EMT2

12

12

2TT

3T2TM

ˆEstimator:

To compute Lmin we need to know M

Use meeting times statistics and do online estimation

Routing: Other IssuesRouting: Other Issues

Epidemic Routing: Wasted ResourcesEpidemic Routing: Wasted Resources

Epidemic routing hands over a copy to every node encountered…

Even after the message has been delivered!

After the destination is encountered by at least one relay, no need to keep other copies around anymore Unnecessary transmissions (energy, throughput) Valuable buffer space

Reducing Resource WasteReducing Resource Waste“Dis-infection Schemes”“Dis-infection Schemes”

After one copy has been delivered:

1. Inform other nodes to stop spreading more copies No need to give extra copies to “non-infected”

nodes

2. Remove copy from buffers Clear up buffer space of infected nodes

Full EraseFull Erase

When encountering the destination => delete message from buffer

Node may get a copy again!

A

C

B

dst

D

EF

D

D

D

D

Delete local copy

XD

IMMUNEIMMUNE

Delete packet AND maintain an antipacket msg id: e.g. (src,dst,seq) Implies that node is recovered

A

C

B

D

D

EF

D

D

D

D

Delete local copy

XB

Recovered Node msg: (S,D,0)

No new copy to recovered nodes

D

IMMUNE-TXIMMUNE-TX

Propagate anti-packet to already infected nodes

A

C B dst

D

EF

D D

D

D

Delete local copy

XB

Recovered Node msg: (S,D,0)

No new copy to recovered nodes

C

C recovered!msg: (S,D,0)

D Avoided this Tx

VACCINEVACCINE

Propagate anti-packet to ANY node encounter Vaccinate susceptible nodes

A

C dst

D

EF

D

D

BNo new copy to recovered nodes

C

C recovered!msg: (S,D,0)

Vaccinate E

D

E

Avoid this Tx, too

SIR ModelSIR ModelEpidemiologyEpidemiology

I: infected nodes Nodes with a copy, and no anti-packet

R: recovered nodes Nodes with an anti-packet

S: susceptible nodes (S = N – I – R) Haven’t ever received a copy or anti-packet

SIR Model: ODEsSIR Model: ODEs

Immune:

Immune-TX

λI(t)R'

I λ-I R)-I-(N λ(t)I '

1)λI(R(t)R'

1)I(R λ-I R)-I-(N λ(t)I '

Total number of transmissionsTotal number of transmissions

E[Tx] = limt{I(t) + R(t)} – I(0)

Immune

λI(t)R'

I λ-I R)-I-(N λ(t)I '

1I(0) 1,-R-I-N

dR

dI

NR1)eN(I(R) R

N]1)eN[(limR(t)lim0I(t)lim R

ttt

NR(t)limt10N

1-NE[Tx]

Total Number of TransmissionsTotal Number of Transmissions

IMMUNE-TX

1)λI(R(t)R'

1)I(R λ-I R)-I-(N λ(t)I '

1R

11)R-(NRI(R)

2

2

52NN3-NE[Tx]

2

Performance of Buffer Performance of Buffer ManagementManagement

The more aggressive the recovery scheme

1) the less the total transmissions (ignoring overhead of antipackets)

2) the smaller the buffer occupancy

Queuing PoliciesQueuing Policies

Limited buffer space Nodes with little memory (e.g. sensors) Nodes might offer only a small chunk of memory for

3rd party traffic

What if a message has to be dropped?

Queuing Policies (2)Queuing Policies (2)

When new packet arrives on buffer and buffer is full:

Droptail drop it if buffer is full

Drophead drop the oldest packet in buffer (most hops or least

time to TTL expiration) rational(?): large time in the network => little chance

to be delivered before TTL expires Drophead-sp (source-prioritized)

Don’t drop a source packet for an arriving relay packet

Queuing Policies: PerformanceQueuing Policies: Performance

Drophead: fast infenction, high packet loss for small buffers

Drophead-sp: slower infenction, higher delivery ratio

buffer droptail dropheaddrophead

(sp)

5 0.97 0.22 0.05

10 0.95 0.03 0.0

20 0.90 0.002 0.0

QoS ProvisionQoS Provision

Multi-type traffic: what about traffic of different priorities (e.g. emergency messages vs. advertisements)

Multiple queues? Different forwarding policies

E.g. never drop type A for type B

Different routing policies?

Reducing the overhead of epidemic:Reducing the overhead of epidemic:Network CodingNetwork Coding

So far we were not changing packets’ content Replication Forwarding Drops

Coding may combine one or more packets

x1

x2

x3

Outgoing links

Incoming links x1

x2

x3

Store-and-forward

x1

x2

x3

Reducing the overhead of epidemic:Reducing the overhead of epidemic:Network CodingNetwork Coding

So far we were not changing packets’ content Replication Forwarding Drops

Coding may combine one or more packets

Outgoing links

Incoming links x1

x2

x3

Network Coding

f(x1,x2,x3)

Coding Packets: A simple exampleCoding Packets: A simple example

XOR: The simplest combination: 2121 xx)x,f(x

1 0 1 1msg x1:

0 1 1 0msg x2:

1 1 0 1f(x1,x2):

De-coding Packets: A simple De-coding Packets: A simple exampleexample

Assume node that send x1 receives the coded packet f(x1,x2)

1 0 1 1msg x1:

0 1 1 0msg x2:

1 1 0 1f(x1,x2):

Butterfly Network: Store-and-Butterfly Network: Store-and-ForwardForward

Two sources: S1, S2 R1,R2: receive traffic from both S1 and S2

S1 S2

R2R1

x1 x2

x1

x1

Time 1x2

x2

Time 2

x1Time 3

x1

x2

3 units: received x1,x2

x2

Time 4

4 units: received x1,x2

Butterfly Network: Network Butterfly Network: Network CodingCoding

Two sources: S1, S2 R1,R2: receive traffic from both S1 and S2

S1 S2

R2R1

x1 x2

x1

x1

Time 1x2

x2

Time 2

Time 3

3 units: received x1,x2

3 units: received x1,x2

21 xx

21 xx 21 xx

Network Coding for WirelessNetwork Coding for Wireless

Broadcast nature of medium: natural ground for network coding

A BC

B x1A x2

B x1

A x2 B x1A x2

No coding: delay = 4

Network Coding for WirelessNetwork Coding for Wireless

Broadcast nature of medium: natural ground for network coding

A BC

B x1A x2

B x1

A x2

Coding: delay = 3

21 xx 21 xx 21 xx

Linear Network CodingLinear Network Coding

m packets n linear combinations

b1 = a11x1+ a12x2+…+ a1mxm

b2 = a21x1+ a22x2+…+ a2mxm

……………………………….

bn = an1x1+ an2x2+…+ anmxm

independent linear combinations ≥ m Centralized choice of coefficients => Decode!

Distributed) ai random and independent => decode (prob 1)

Network Coding for Challenged NetsNetwork Coding for Challenged NetsThe modelThe model

Set of nodes V N(u): {iV: i neighbor of u} Set of sources S V (m = |S|) Messages: xi, i=1,…,m

xi = [xi1, xi2,…, xiM], M symbols F2k = (0,2k-1)

K > 8 to ensure independence for random coding

Encoding vectors: gi = [gi1, gi2,…, gim], m symbols F2

k

Encoding matrix G:

row i = (gi1,…,,gim | , ,…, )

m

1jj1ij xg

m

1jj2ij xg

m

1jjMij xg

Encoding vector

gi*Gi (Gi= ith symbols of all xi}

Encoding Matrix: ExampleEncoding Matrix: Example

1 0 0 5 4 1 2

1 1 1 6 3 2 2

- - - - - - -

g1=[1,0,0]

g2=[1,1,0]

M = 4 (symbols per message)Encoding vectors (2)

Encoding matrix G at node 1

m = 3 messages in total

Each message contains M = 4 symbols in F8

Encoding Matrix: ExampleEncoding Matrix: Example

1 0 0 5 4 1 2

1 1 1 6 3 2 2

0 1 1 3 7 3 4

g1=[1,0,0]

g2=[1,1,0]

Encoding matrix G at node 1

m = 3 messages in total

Each message contains M = 4 symbols in F8

g2=[0,1,1]

New encoded message arrived: increase rank of matrix G?

No! Linearly dependent with 1,2 (x3 = x1 XOR x2 (mod 8))

Encoding Matrix: ExampleEncoding Matrix: Example

1 0 0 5 4 1 2

1 1 1 6 3 2 2

1 0 1 2 4 1 0

g1=[1,0,0]

g2=[1,1,0]

Encoding matrix G at node 1

m = 3 messages in total

Each message contains M = 4 symbols in F8

g2=[1,0,1]

New encoded message arrived: increase rank of matrix G?

Yes! 3 linearly dependent vectors (Gaussian elimination)

Network Coding for Challenged Nets:Network Coding for Challenged Nets:ForwardingForwarding

At time t-dt node i receives an innovative message/vector

With probability d: send (gi(t),yi(t)) = ri(t)*Gi(t) ri(t) = random vector (in F2

k) Like gossiping: instead of forwarding new message,

forward a linear combination of all messages currently in buffer!

All nodes in N(i) receive (gi(t),yi(t)) If not innovative discard If innovative, add to matrix G and do same process

Need at most m innovative messages to decode Can probably decode some elements before that!

Performance of Network CodingPerformance of Network Coding

Increase Delivery Ratio: better utilize forwarding opportunities

Increase average delay (have to wait for multiple messages to be received

Generation Management:Generation Management:Which messages to code Which messages to code

together?together? Assume infinitely large network with a

percentage of nodes being sources

Do we code messages from all sources??Coding matrix G will be huge!Delay until all messages decoded

Code messages of subsets of sources together How do we choose subsets??

Code multiple messages of same source How many generations??

Network Coding GainsNetwork Coding Gains

Generation management: Larger generations Better coding gains (throughput, energy, delivery) Larger potential end-to-end delay, complexity

Related nodes in same generation?

Types of traffic Multiple single-source single-destination messages One source-one destination, multiple messages Many sources-one destination Multiple one source-many destinations messages

(multicast, broadcast)

End-to-end vs. hop-by-hop decodingEnd-to-end vs. hop-by-hop decoding

1) Decoding of messages at end nodes This is what we were looking at so far Issues with generation management Potentially long/unbounded delays

2) Opportunistic Network (De-)Coding Keep track of neighbors messages Code only if next hop can decode

x1

x2

x3

f(x1,x2,x3)

x1

x3x1

x2

x3

f(x1,x2,x3)

x1

x2

Erasure CodingErasure Coding

Provide better fault-tolerance by adding redundancy without the overhead of strict replication (e.g., Reed-Solomon, Gallager, Tornado, and IRA codes)

Applications: P2P, overlay routing, WSN, data storage, etc.

Erasure CodingErasure Coding

(r=2, n=4)

A B C D

A-1

A-2

A-3

A-4

B-1

B-2

B-3 C-1

C-4

D-1

A B C D

A-1

A-2

A-3

A-4

B-1

B-2

B-3

B-4

C-1

C-2

C-3

C-4

D-1

D-2

D-3

D-4

Lossy Lossy ChannelChannel

Layered Multiple Description Coding (LMDC)Layered Multiple Description Coding (LMDC)

Layered coding

Unequal erasure coding

Video Web Document

LMDC ExamplesLMDC Examples

Transport Layer Issues in DTNsTransport Layer Issues in DTNs

TCP offers: Ports

Still used by the overlay bundle layer

Sequencing Still there, but for bundles

Connection Impossible in most DTN cases

Reliability Late ACKs. Large RTT.

Congestion Control Very difficult to get up-to-date congestion info in partitioned

environments;

Reliability in DTNs:Reliability in DTNs:“Hop-by-Hop”“Hop-by-Hop”

Each message copy forwarded is acknowledged by the next hop

This holds also if multiple message copies are propagated (e.g. epidemic)

Hop-by-hop reliability has minimum delay No need to wait for end-to-end ack

BUT: Hop-by-hop reliability does not guarantee end-to-end reliability

Reliability in DTNs:Reliability in DTNs:“Active Receipt”“Active Receipt”

Intermediate node may: lie, shut down, break down.

Active receipt: generated by destination when it receives the message

Active receipt = new message Other nodes route it as a normal message

Epidemic spreading of receipt to guarantee acknowledgement ACK size < MSG size => less overhead Vaccinates/Cures other nodes encountered in the

meantime (essentially VACCINE)

Reliability in DTNs:Reliability in DTNs:“Passive Receipt”“Passive Receipt”

Active receipt: floods two messages Often, most overhead is MAC access

“Passive Receipt”:

- generated by destination when it receives the message

- can only be passed to infected nodes (essentially IMMUNE-TX)

Plus: less overhead than active receipts Minus: larger delay than active receipts

Reliability in DTNs:Reliability in DTNs:“Network-Bridged Receipt”“Network-Bridged Receipt”

Assume complementary network:

DTN + (low bandwidth, connected network)

Cellular network

DTN network: send bulky data (with delay tolerance; e.g. ftp)

Cellular network: send immediate small ACK Could even be used for disinfection(?)

Reliability in DTNsReliability in DTNs

What else could we try?

Where is each approach applicable?

What is the penalty of late ACKs? What about ACKing multiple messages

Can we take advantage of mobility/social structure to improve?

Congestion Control in DTNsCongestion Control in DTNs

Connected Network

D

Buffer Full

D

D

D

D D

Message Drop!

Congestion Notification

Cut back send rate!

S D

Congestion Control in DTNsCongestion Control in DTNs

Disconnected Network

D

Buffer Full

D

D

D

D

Message Drop!

Congestion Notification

Cut back send rate! D

D

D

S

DDDD

No Congestion! Irrelevant Notification! Unnecessarily reduce throughput! May not see S

Mobility ModelsMobility Models

Random WalkRandom Walk

All nodes perform independent random walks Move to any neighboring location with probability ¼

p = 0.25

Uniform stationary distribution torus: on boundary reflect on other side

Brownian Motion as an extension Normal distribution increments

Random WaypointRandom Waypoint

Choose a point in the network uniformly Choose speed randomly

Pause for a random amount of time Choose another point uniformly and repeat

Pause

Random DirectionRandom Direction

Random Waypoint has some problems Non uniform stationary distribution: concentration in

center If not started from stationary distribution =>

convergence issues: slowly drifting from uniform to center

Random Direction1. Choose direction uniformly in 360o

2. Move for exponential amount of time3. Reflect or turn-around on boundary

Uniform Stationary Distribution

Other ModelsOther Models

Manhattan Model All nodes move within restricted street

borders Grid structure (vertical and horizontal

streets, like Manhattan) Stop lights?

Freeway Model Nodes move on lanes of one line; lanes

in both directions Potentially other crossing freeways Speed considerations between nodes in

same lane Group Mobility

Subset of nodes associated with a leader

Followers make move based on leader’s move

Impact of Mobility Model on Impact of Mobility Model on PerformancePerformance

A study comparison between DSR, AODV, TORA, and DSDV under Random Waypoint All routing protocols (proactive and reactive)

Showed DSR was better overall

Comparison for different mobility models (Rand. Waypoint, Freeway, Manhattan, etc.)

Winner depends on mobility model; AODV actually better in more cases

Some Common Assumption of Some Common Assumption of Synthetic Mobility ModelsSynthetic Mobility Models

No location preference Uniform choice of destination Uniform stationary distribution

IID node mobility Every node is doing the same Statistically equivalent

Real-life MobilityReal-life Mobility

Community (local) Nodes

Base Stations (pstatic)

Fast/Mobile Nodes (pfast)

pL(i)

1-pL(i)

stay inside community

1-pR(i)

Roam around network(infrequent)

Community (local) Nodes

Base Stations (pstatic)

Fast/Mobile Nodes (pfast)

pL(i)

1-pL(i)

stay inside community

1-pR(i)

Roam around network(infrequent)

Common Mobility Models:Common Mobility Models:What is Wrong?What is Wrong?

Location preference? Nodes don’t visit all locations equally frequently Usually: spent most of the time in a small subset of locations

(e.g. office, house, library, etc.)

Identical node behavior? Different nodes; some more mobile than others Vehicles vs. pedestrians; first-year student vs. graduate student

Does time play any role? Morning: commute to work Noon: lunch Weekend-vs-week

What else? Social relationships

Traces From Real Wireless Networks Traces From Real Wireless Networks

WLAN (WiFi) traces Collect logs from deployed WLANs in campuses Association(s) between user node and Access

Point(s) (AP)

Traces of contacts between different wireless nodes (ad hoc mode) PDAs carried around by users Logs of different encounters (e.g. PDA associations)

DTN: We Care About ContactsDTN: We Care About Contacts

Contact traces => we get this directly

WLAN traces: translate Node-AP associations into Node-Node associations Same AP at the same time => contact Not always true What happens between APs?

Public DTN TracesPublic DTN Traces

ZebraNet Bus trace (SF, Toronto, DieselNet) Campus trace (UCSD, Dartmouth, MIT) Conference trace (Infocom, SIGCOMM) Enterprise trace (Intel, IBM)

http://crawdad.org

Traces: What Have We Learned?Traces: What Have We Learned?

Location/Node preference Tend to see specific locations/nodes, more often

than other Node Heterogeneity

Some nodes see all locations/nodes; others a small subset

Behavior over time Different for different time of day, day of week, etc. Periodic behavior

Community-based MobilityCommunity-based Mobility

Capture Location Preference

local

Ci

Community (e.g. house, campus)

pL(i)

1-pL(i)

Rest of the networkRoam outside community(Rand. Direction or Waypoint)

pR(i)

stay inside community

Continue roaming 1-pR(i)

Community-based Mobility (2)Community-based Mobility (2)

Capture Node Heterogeneity Each node may have a different community

local roam

pL(i)1-pL(i)

1-pR(i)

pR(i)

Node i

local roam

pL(j)1-pL(j)

1-pR(j)

pR(j)

Node j

Community-based Mobility (3)Community-based Mobility (3)

Multiple Communities (house, office, library, cafeteria)

House(C1)

Community (e.g. house, campus)

p11(i)

p12(i)

Rest of the network

p21(i)

OfficeC2

LibraryC3

p23(i)

p32(i)

Community-based Mobility (4)Community-based Mobility (4)

Multiple Communities (house, office, library, cafeteria)

C1 C2

p11(i)

p12(i)

p21(i)

p22(i)

C4C3

p32(i)

p43(i)

p24(i)

Inter-Community Mobility? Intra-Community Mobility?

Community-based Mobility (5)Community-based Mobility (5)

Capture time-dependent behavior t = {morning, noon, weekend,…}

C1 C2

p11(i)(t)

p12(i)(t)

p21(i)(t)

p22(i)(t)

C4C3

p32(i)(t)

p43(i)(t)

p24(i)(t)

Mobility ProfileMobility Profile

Macroscopic View of Mobility

Node i: {π(i)(C1), π(i)(C2),…, π(i)(Cn)}

Approach 1: Route towards most popular communities (e.g. geographic routing)

Approach 2: {π(i)(C1), π(i)(C2),…, π(i)(Cn)} = coordinates in an n-dimensional space

Route to nodes whose distance is small in this n-dimensional space

Multi-tiered CommunityMulti-tiered Community

Roaming outside local community is not uniform either! Move further away from local community with

decreasing probability

Tier 1

Tier 2

Tier 3

Tier 4

p12(i)(t)

p13(i)(t)

p14(i)(t)

Inter-contact TimesInter-contact Times

Time between subsequent encounters with the same node

Consecutive transmission opportunities to a given node

Contact-based trace measurements: what is the distribution of inter-contact times? WLAN traces (Dartmouth, UCSD) Inter-node (ad hoc mode) traces (Cambridge,

Toronto)

CCDF for Inter-contact TimesCCDF for Inter-contact Times

LOG-LOG plots Straight line in log-log plot => power law/heavy-tailed (slope = exponent)

CCDF for Inter-contact Times (2)CCDF for Inter-contact Times (2)

WLAN traces: similar behavior

Power Law DistributionsPower Law Distributions

P[X > x] = x-a

Infinite variance a < 2: infinite mean There is a high probability that some very large

values will be drawn if X is sampled sequentially Contrast: exponential decay variables

Very large values: almost improbable

Most of the mobility models (synthetic) presented so far had exponential tails

Power Law Distributions: Power Law Distributions: ComplicationsComplications

Theory: most analysis (Markov, ODEs, combinatorics) assumes exponential tail Essentially for X1,X2,…,Xn IID and exponential

E[min{X1,X2,…,Xn}] = EX / n

Protocol Performance Opportunistic routing: give a copy randomly Depending on the exponent (a) any opportunistic

protocol (e.g. direct transmission, 2-hop, spray&wait) may have infinite delay!

But is it REALLY Heavy-tailed?But is it REALLY Heavy-tailed?

Power-law only within a range of CCDF What about the rest of the tail (artifact of experiments, or not

power-law really)?

Lognormal Seems Fit Better Lognormal Seems Fit Better

Inevitable Censorship in MeasurementsInevitable Censorship in Measurements

5x10^3

0.4

6.6x10^6

0.06

Survival CurveSurvival CurveP(T>t)

6x10^4

0.2

UCSD trace

censored datacensored data

Self-Similarity TestSelf-Similarity Test

Hurst values are located between [0.5,1] Time-Variance Plot, R/S Plot, Periodogram Plot, Whittle

Estimator

Social NetworksSocial Networks

Social NetworksSocial Networks

Social Network: who interacts with whom? Who is a “friend” of whom?

Graph model: Vertices = humans, Weighted Edges = strength of interaction

Social Network-based Mobility Social Network-based Mobility ModelModel

1. Create (simulation) or Derive (from existing info – e.g. department affiliation) a social network among all nodes

2. Assign nodes to communities according to social network

3. Assign communities to locations

4. Induce mobility based on social network

Communities in Social NetworksCommunities in Social Networks

Social networks have high clustering co-efficient Interaction Matrix = Connectivity Matrix

For all weights > threshold => assume a connected link

Identify Communities: Find nodes that connect communities (intuition: shortest paths go through these)

Community 1 Community 2 Community 3

Communities in Social NetworksCommunities in Social Networks

Social networks have high clustering co-efficient Interaction Matrix = Connectivity Matrix

For all weights > threshold => assume a connected link

Identify Communities: Find nodes that connect communities (intuition: shortest paths go through these)

Community 1 Community 2

B: connects 1,2

Mapping Communities to Mapping Communities to LocationsLocations

Assume a grid with different locations of interest Geographic consideration might gives us the candidate locations

Mobility Between CommunitiesMobility Between Communities

pc(i) = attraction of node i to community/location c

p2(B)(t)

p1(B)(t)

C}{j

w

p Cjij

(i)C

p3(B)(t)

Social Network-based Mobility ModelSocial Network-based Mobility Model

Can reproduce similar behavior to (heavy-tailed) traces Inter-contact times Contact durations

Some issues Nodes move only between specific (community)

locations Different social graph weights depending on time of

day Evolve social graph weights

Social Networks for Information Social Networks for Information DisseminationDissemination

Social networks are often better to find information that is location, community, or time-specific!

Small World and Scale-Free properties Separation/diameter is smaller than random networks

Query can often be answered quicker through peers Example: “where is a good Thai restaurant in Nice?”

Approach 1: Find PC => Google => look websites that rate restaurant => hope the one suggested IS actually good

Approach 2: Ask friend who lives in Nice (he might now, or have heard, or ask another friend) What if we could do this wirelessly also?

PeopleNet ArchitecturePeopleNet Architecture

Cellular Networks (WiMaX) as main infrastructure

Bluetooth peer-to-peer networks (WiFi – ad hoc)

Users transmit querys Request query: “who knows/has X?” (ticket to

Monaco rally) Offer query: “I have/know Y”

Queries are tagged according to some subject (e.g. sports, finance, news, etc.)

PeopleNet Architecture (2)PeopleNet Architecture (2)

A query is sent to a subset of locations/base stations that have been assigned to the given query type Geography might play a role: e.g. “where is the

closest local bookstore?” A few users receive the query through

infrastructure, and propagate further using peer-to-peer messages

If a “match” is found, requesting user is notified (SMS, email)

Further IssuesFurther Issues

Research IssuesResearch Issues

Routing Buffer Management Power Management Auto-Configuration Network Reliability

Free-riders Black holes Worm holes

Information Security Data Encryption

Real-world applications (and killer applications) Underwater Networks, Vehicular Networks, People Networks,

Scientific Monitoring Networks, etc.