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 SFU, February 20, 2006 1
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 SFU, February 20, 2006 2
Computing Science How to turn a bunch of nodes into a network? Wire them! SFU, February 20, 2006 3
Computing Science No wires, no infrastructure, mobility, low cost The wireless medium is broadcast (not just a wire) Ethernet Hidden terminal SFU, February 20, 2006 4
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 SFU, February 20, 2006 5
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. SFU, February 20, 2006 6
Computing Science MAC tries to help (802.11) RTS A B C D CTS DATA ACK This only makes (some) sense if DATA is considerably longer than RTS. The handshake does help A B C D sometimes, but it also F messes things up on more E than one occasion. SFU, February 20, 2006 7
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 SFU, February 20, 2006 8
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). SFU, February 20, 2006 9
Computing Science Controlled flooding NO NO drop am I the too many rule 1 recipient? hops? fail YES YES drop rule 2 drop receive and fail forget drop rule n The rules are driven by caches. If no information is available in fail the cache, the rule fails. rebroadcast SFU, February 20, 2006 10
Computing Science A sample rule: DD packet YES entry NO drop signature in expired? cache? NO YES One can experiment with the replacement fail policy, e.g., make the expiration time proportional to the expected distance from the destination. SFU, February 20, 2006 11
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 m f forward focus 2 m b backward focus 2 32 SFU, February 20, 2006 12
Computing Science The SPD rule S D R cached [S, D, H SK , H DK ] drop YES h H < H SK + H DK ? h Also, fail every once in a while, H < m f (H SK + H DK ) with frequency inversely proportional to H - (H SK + H DK ). H < m b (H SK + H DK ) SFU, February 20, 2006 13
Computing Science Path convergence D D D S S S SFU, February 20, 2006 14
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! SFU, February 20, 2006 15
Computing Science Fuzzy ACKs How can you be reasonably confident that your forwarding duties have been fulfilled? Listen for a retransmission of your packet? fuzzy ack Only sent if the node t packet packet is not going to drop SIFS DIFS the packet. Once again, layering does not help a lot! SFU, February 20, 2006 16
Computing Science Performance DSR 1.1 Total Nodes = 25 AODV Total Sources = 8 1.05 1 PDF 0.95 DSDV TARP 0.85 Pause tim e 0.8 0 100 200 300 400 500 SFU, February 20, 2006 17
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)? SFU, February 20, 2006 18
Computing Science Multiple processes/threads code shared, ROM (flash) data needed anyway x gets in the way stack 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) SFU, February 20, 2006 19
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) SFU, February 20, 2006 20
Computing Science PicOS's footprint process process process process RAM private data shared stack ● 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) SFU, February 20, 2006 21
Computing Science A historical note LANSF: Local Area Network Simulation Facility (1987) SMURPH: a more friendly (OO) version with a library of models (1993) † 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) † P. Gburzynski, Protocol design for local and metropolitan area networks, Prentice Hall, 1996. SFU, February 20, 2006 22
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; ... SFU, February 20, 2006 23
Computing Science TCV plugin model application TARP MAC TCP/IP? API plugs pluggable transceiver interface (TCV) phy the kernel the micro radio radio SFU, February 20, 2006 24
Computing Science Plugin interface preprocessing upon reception typedef struct { int (*tcv_ope) (int, int, ...); how to open a session int (*tcv_clo) (int, int); how to close a session int (*tcv_rcv) (int, address, int, int*, tcvadp_t*); int (*tcv_frm) (address, int, tcvadp_t*); int (*tcv_out) (address); application packet boundary int (*tcv_xmt) (address); preprocessing for output int (*tcv_tmt) (address); after packet transmission int tcv_info; on timeout } tcvplug_t; SFU, February 20, 2006 25
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) SFU, February 20, 2006 26
Computing Science Acknowledgments studied TARP's performance, Ashik Rahman helped with fuzzy ACKs (2005) Wlodek Olesinski originated the idea of TARP Wladek Olesinski (around 2000), founded Olsonet supported SMURPH and SIDE Jacek Maitan (1992-1994), suggested PicOS Lockheed M&S helped design LANSF (1989) Piotr Rudnicki SFU, February 20, 2006 27
Recommend
More recommend
