Delay-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” Networks

 Internet, Telephone network

 Wired or fixed links

 A SUCCESS STORY!
 Wireless Networks: Cellular

 Cellular Networks: Wired backbone + wireless last link

Wireless Last Hop

Wired
Backbone

 A SUCCESS STORY for voice/SMS!

 Internet? (GPRS): not really (low bandwidth + high price)
Wireless Networks: WiFi

 802.11, wimax
 Still: only wireless
local-loop
 Higher bandwidth
than cellular:
54Mbps
 Much cheaper/KB
 Wireless Networks: WiFi (2)

 Only Partial Coverage: HOTSPOTS

 No real “mobile computing”!

 Wireless Networks:
Ad-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 Networks
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
End-to-end path

S D

node
link

 Mobility might change these paths: re-establish them

 Wireless Networks
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” 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 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 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 Networks

 Intermittend/scheduled/opportunistic links
 High error rates/low usable capacity
 Very large delays
 Different network architectures
 Characteristics 1: Path and Link
characteristics
 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 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 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 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 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)
Networking 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 Space
 Long Propagation Delays vs.
“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 chatiness

More than 3h for one 1MB pic!

transmission time (1MB/128Kbps) = 1min !!!
 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 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-Carry-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)

1
12 13 D

S
14

2 16
11 15
3
4 7
5
8 10
Store-Carry-and-Forward (3)
Store-Carry-and-Forward (4)
DTN vs End-to-end Internet Operation
 Networking in Space
Heterogeneity
 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 Overlay
 What About Retransmission?
Custody 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 (3)
Moving 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 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/ }
Naming
 Delay Tolerant Networks (DTN)

 Kevin Fall (~2002): “maybe these idea is not only

useful for deep space networks”
 DTN: 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:
The Technical Argument
 Wireless links are not like wires!

End-to-end path

S D

node
link
 Intermittent Connectivity:
The Technical Argument
 Intermittent Connectivity may appear because of: p
 propagation effects: shadowing, deep fades

X
A B
B
 Intermittent Connectivity:
The Technical Argument(2)
 Intermittent Connectivity may appear because of:
 Propagation effects, shadowing, deep fades
 Mobility: paths change too fast; huge overhead for maintenance

C
A B
 Intermittent Connectivity:
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”

C
Save power
(e.g. sensor)
A B

Low probability of detection (LPD)

(e.g. army node)
 Intermittent Connectivity
The 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 View

End-to-end path

S S
X
S D
DD
X path
path X
disruption!
disruption!

node
link
 Applications: Sensor Networks for
Habitat 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
Habitat Monitoring (2)
Herd of zebras
Herd of zebras
Z (range of few meters)
(range of few meters)
Z Z Z
Z
Z Z

Z
Z
Z base station

 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
 Vehicular Networks
“Drive-Thru Internet”
 Vehicle-to-roadside (base station, sensors)
 Vehicular Networks
“Drive-Thru Internet” (2)
Internet
email reply send email

send email
email reply
write email

 Asynchronous operation: OK for e-mail!

 Web caching; Local information; download news
 Enough bandwidth even at high speeds!
 Vehicular Networks (VANETs)
Vehicle-to-Vehicle Networks

 Accident Prevention
 Traffic Reports
 Can be combined with Vehicle-to-Roadside
 Why Vehicular DTN Networks?

 Gradual deployment => initially sparse network

 Even dense deployments: Paths change too

fast! Before enough time to be discovered
 An example

 UCLA’s Vehicular Sensor Network

 Internet 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 (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 Communities

 The SAAMI nomadic community of Lapland

 Application: 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) Networks

 Communicating beyond enemy lines

 Need to retain connectivity despite jamming,
losses
 Powering down nodes (LPD/LPI)
 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?

 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 Networks

 HAGGLE project (www.haggleproject.org)

 Conference
 Campus
 Summarizing:
Delay 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 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 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 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)

 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)