Taking ad-hoc literally: route-less routing in multi-hop wireless - - PowerPoint PPT Presentation

1 SFU, February 20, 2006

Computing Science

Taking “ad-hoc” literally: route-less routing in multi-hop wireless networks

Pawel Gburzynski Department of Computing Science University of Alberta & Olsonet Communications

2 SFU, February 20, 2006

Computing Science

What this is about

• I believe that we have something that works,

and nobody else does it that way

• Academic research in certain areas (notably the

“soft” part of telecommunication) is quite a bit detached from reality

• Small is nice
• Committees and consortia are not particularly

good at thinking small, i.e., standards hurt the small and sometimes kill it altogether

3 SFU, February 20, 2006

Computing Science

How to turn a bunch of nodes into a network? Wire them!

4 SFU, February 20, 2006

Computing Science

The wireless medium is broadcast (not just a wire)

No wires, no infrastructure, mobility, low cost

Ethernet Hidden terminal

5 SFU, February 20, 2006

Computing Science

Prevailing wisdom

The (somewhat confused) optimization criteria:

➔number of hops (delay) ➔spatial reuse (throughput) ➔quality of service (loss) ➔power control (durability)

The problem: routing, i.e., how to emulate wires?

➔given a source and destination, find the best path ➔then forward the packets along that path ➔oh, and be prepared that some of those virtual

wires may disappear on you as you go along

6 SFU, February 20, 2006

Computing Science

Two schools

Proactive: (DSDV, WRP, CGSR):

➔constant background activities aimed at detecting

and maintaining routes in case they are needed Reactive: (AODV, DSR, TORA, ABR, ARA):

➔detect routes as they are needed; maintain them

while they are being used The bureaucracy must resort to some broadcasting (its intermediate goal is to identify node neighborhood), but point-by-point is considered the way to go.

7 SFU, February 20, 2006

Computing Science

This only makes (some) sense if DATA is considerably longer than RTS.

MAC tries to help (802.11)

A B C D RTS CTS DATA ACK A B C D E F The handshake does help sometimes, but it also messes things up on more than one occasion.

8 SFU, February 20, 2006

Computing Science

Suppose packets are short

• The handshake is useless for collision avoidance.
• Data-link-level

encapsulation introduces a significant overhead.

• Are the ACKs really that important? Owing to the

uncertainties related to route discovery, the application will not depend on them anyway.

• Aren't we losing something by trying to lay those

virtual wires where they don't seem to fit very well?

D S T D S T

9 SFU, February 20, 2006

Computing Science

TARP: Tiny Ad-hoc Routing Protocol

• No route discovery, no route maintenance, no

bureaucratic traffic, all packets originate at the application

• No layers, no encapsulation, no framing overhead
• Automatic trade-off: footprint/quality of routes
• Parameterizeable and tunable to network density,

mobility, traffic patterns (automatically and by the application)

• Performance

demonstrated in a working implementation (commercial product).

10 SFU, February 20, 2006

Computing Science

Controlled flooding

am I the recipient? receive and forget YES NO rule 1 drop rule 2 drop rule n drop too many hops? NO

The rules are driven by caches. If no information is available in the cache, the rule fails.

rebroadcast fail fail fail YES drop

11 SFU, February 20, 2006

Computing Science

A sample rule: DD

packet signature in cache? NO fail entry expired? YES YES NO drop

One can experiment with the replacement policy, e.g., make the expiration time proportional to the expected distance from the destination.

12 SFU, February 20, 2006

Computing Science

Packet header

D destination Bits S source s session tag 4 n packet number 5 k version (retransmission count) 4 L hop number limit 5 h hops so far 5 H target hop count 5 mf forward focus 2 mb backward focus 2 32

13 SFU, February 20, 2006

Computing Science

The SPD rule

S D R [S, D, HSK, HDK] cached h h H < HSK + HDK ?

YES drop

H < mf (HSK + HDK ) H < mb (HSK + HDK ) Also, fail every once in a while, with frequency inversely proportional to H - (HSK + HDK ).

14 SFU, February 20, 2006

Computing Science

Path convergence

S D S D S D

15 SFU, February 20, 2006

Computing Science

Other rules

Diversifying among multiple paths of the same length:

➔using noise level in the neighborhood as a factor in

SPD

➔late rule evaluation – just before the physical

transmission (combined wit LBT) Taking the power into account:

➔affecting the cost metrics (not only hops) ➔eliminating short paths with poor quality

The abominable layering gets in the way!

16 SFU, February 20, 2006

Computing Science

Listen for a retransmission of your packet?

Fuzzy ACKs

How can you be reasonably confident that your forwarding duties have been fulfilled? t

packet packet DIFS SIFS fuzzy ack

Only sent if the node is not going to drop the packet. Once again, layering does not help a lot!

17 SFU, February 20, 2006

Computing Science

Performance

0.8 0.85 0.95 1 1.05 1.1 100 200 300 400 500 Pause tim e Total Nodes = 25 Total Sources = 8

PDF DSR AODV DSDV TARP

18 SFU, February 20, 2006

Computing Science

How do we program small devices?

From scratch: theoretically most efficient, practically tedious and/or messy (certainly not very effective). Some “platforms” do exist, e.g., TinyOS (see also SmartDust). For my taste, they are too much into consortium/committee type of a “solution.” What is the problem? Why can't we use Java (just kidding)?

19 SFU, February 20, 2006

Computing Science

Multiple processes/threads

code data stack

x

shared, ROM (flash) needed anyway gets in the way

How to have threads without a stack for each of them? E.g., TinyOS has no threads, only:

• callbacks (event handlers) and
• “tasks” (non-preemptible chunks of code)

20 SFU, February 20, 2006

Computing Science

A thread in PicOS

process (sniffer, sess_t) char c; entry (RC_TRY) data->packet = tcv_rnp (RC_TRY, efd); data->length = tcv_left (packet); entry (RC_PASS) if (data->user != US_READY) { wait (&data->user, RC_PASS); delay (1000, RC_LOCKED); release; } ... entry (RC_LOCKED) ... entry (RC_ENP) tcv_endp (data->packet); signal (&data->packet); proceed (RC_TRY); endprocess (1)

21 SFU, February 20, 2006

Computing Science

PicOS's footprint

process process process process

RAM

shared stack

private data

• 20 bytes of RAM per process
• 64 bytes of (global) stack goes a long way
• we have a non-trivial mesh system based on

MSP430F148 (with 2KB of RAM per node)

22 SFU, February 20, 2006

Computing Science

A historical note

LANSF: Local Area Network Simulation Facility (1987) SMURPH: a more friendly (OO) version with a library

• f models (1993)†

†P. Gburzynski, Protocol design for local and metropolitan area networks, Prentice Hall,

1996.

SIDE: SMURPH with extensions for programming real-life systems (1996) PicOS: threads based directly on SMURPH/SIDE processes (2003) SMURPH: augmented by an open-ended model of wireless channels (2006)

23 SFU, February 20, 2006

Computing Science

A code fragment in SMURPH

Transmitter:: perform { state NPacket: if (S->ready (MinPL, MaxPL, FrameL)) proceed Transmit; else { Client->wait (ARRIVAL, NPacket); Bus->wait (ACTIVITY, Busy); } state Transmit: Transmitting = YES; Competing = YES; Bus->transmit (Buffer, XDone); Bus->wait (COLLISION, SenseCollision); state Busy: Bus->wait (EOT, SenseEOT); Bus->wait (COLLISION, SenseCollision); state XDone: Bus->stop (); Transmitting = NO; Competing = NO; Buffer->release (); proceed SenseEOT; ...

24 SFU, February 20, 2006

Computing Science

TCV plugin model

the micro the kernel pluggable transceiver interface (TCV) application TARP MAC radio phy radio API plugs TCP/IP?

25 SFU, February 20, 2006

Computing Science

Plugin interface

typedef struct { int (*tcv_ope) (int, int, ...); int (*tcv_clo) (int, int); int (*tcv_rcv) (int, address, int, int*, tcvadp_t*); int (*tcv_frm) (address, int, tcvadp_t*); int (*tcv_out) (address); int (*tcv_xmt) (address); int (*tcv_tmt) (address); int tcv_info; } tcvplug_t;

how to open a session how to close a session preprocessing upon reception application packet boundary preprocessing for output after packet transmission

• n timeout

26 SFU, February 20, 2006

Computing Science

Open issues

✔ Rules for power control ✔ MAC ✔ High-fidelity simulation (not quite the kind

everybody else is doing)

✔ Libraries of rules (e.g., for different types of

networks)

✔ More self-tuning ✔ Application development (IDE)

27 SFU, February 20, 2006

Computing Science

Acknowledgments

Wlodek Olesinski Wladek Olesinski

• riginated the idea of TARP

(around 2000), founded Olsonet Jacek Maitan Lockheed M&S supported SMURPH and SIDE (1992-1994), suggested PicOS Piotr Rudnicki helped design LANSF (1989) Ashik Rahman studied TARP's performance, helped with fuzzy ACKs (2005)