Ad-hoc Networking
Why mesh? Why ad-hoc? Requires no central authority (no access points); extreme flexibility Self-organizing into local micro- networks based on the population of users rather than the availability of pre-deployed infrastructure Good for network applications driven by personal proximity rules
What is wrong with “popular” commercial solutions? First of all, they don’t really work: Bluetooth is mostly for building small personal hubs: arcane pairing rules and no flexible multi-hoping make true ad-hoc impossible WiFi is essentially AP-oriented; as an ad-hoc solution, it is too costly, too cumbersome, power hungry, and unsuitable for most of the applications we have in mind ZigBee has been mostly used in one-hop networks; it doesn’t scale very well to true ad - hoc
What is wrong with “popular” commercial solutions? Second of all, they are isolated networking solutions (design layers) trying to provide standards and cater to unknown applications (that somebody else must build) Complete and rigid application-independent “ networking stack ” cannot be effective and small at the same time Being devised by committees and consortia, they try to accommodate too much and tend to be large and messy
Ad-hoc networks built around the popular commercial solutions … … are all based on point -to-point forwarding … … i.e., setting up hop -by- hop “paths” in the network Unfortunately, there are no such things as “paths” in wireless – one can only pretend
How do they work? Here is a network
How do they work? Suppose that some two nodes, call them A and B, want to exchange packets B A
How do they work? The network must identify a path, i.e., an exact sequence of B intermediate nodes to forward those packets A
How do they work? This involves lots of distributed negotiations, evaluations, and B bookkeeping A
Details depend on the scheme Reactive: only look for a path when a specific connection is required Proactive: constantly negotiate paths for all possible (or anticipated) connections to be ready in advance These two generic approaches trade complexity (overhead) for responsiveness
Once the path has been established … B A
Once the path has been established … B A
Once the path has been established … … the packet will be addressed on each hop to the single, specific, B pre-determined, next node A
Why is this bad? The procedure for discovering the path(s) is tricky and complex The nodes must remember some descriptions of all active (pro-active?) paths passing through them If one node on a path fails, the path becomes broken (its fixing may be as complex as finding a new path) Mind you: we are wireless (possibly mobile); nodes come and go
This approach is a legacy of wired networking People like to think in terms of simple connections, like wires …
This approach is a legacy of wired networking … and, if the links are in fact wires, and the nodes don’t move, that idea B works quite well (see the stationary Internet) A
But there are no wires in the wireless world! B A
But there are no wires in the wireless world! You never send your packet to the precisely one next hop node (you B only think you do!) A
Also, the illusory links are not as reliable as wires Which path is better? The one with fewer hops appears more attractive, B but longer hops are less reliable A
Then, as we have already noticed, the nodes are not nailed down … … and may disappear (or fail for many legitimate reasons) B A
Broken paths must be detected and recovered from B A
Broken paths must be detected and recovered from … which takes effort and time, possibly traded for space and B bandwidth (if you prefer to be pro- active) A
Broken paths must be detected and recovered from Note that the new “best” path may be drastically different from the B previous one, e.g., A
The problem is inherent and laden with tradeoffs If you are proactive, your objective is to maintain up to date information about all or anticipated possible paths If you are reactive, you should expect longish hiccups while your paths are being discovered and/or recovered Wisdom requires memory – in proportion to the number of paths the node may be involved in (its amount scales more than linearly to the total number of nodes) Timely (up-to-date) wisdom requires traffic, which wastes bandwidth and power
Such schemes do not fit the poor reliability model of ad-hoc systems P-P paths are contrived and brittle: you either have a (full) path, or have no path at all (note that the remnants of a broken path may be completely useless) Nodes are inherently unreliable. Don’t whine about it! This is OK! This is their charm! Just learn to avoid contrived and fragile solutions, i.e., ones whose global integrity depends on the reliability of a single component!
The wireless medium is broadcast …
The wireless medium is broadcast … … so the point -to-point links are purely imaginary … B A
The wireless medium is broadcast … … so when a node sends something (intended to the single next hop B neighbor), all its neighbors will hear that A
The P-P schemes view this as a nuisance that must be fought … … through various collision avoidance techniques that isolate “uninterested” neighbors from the one supposedly “linked” to the sender Those techniques only work (somewhat) if data packets are long; they are useless when sending small amounts of data … … and, of course, they complicate the messy scheme even more
The notorious 4-way handshake B A A B C D RTS CTS DATA E ACK What if the packet you have to send is comparable in size to RTS/CTS/ACK? Then, we have the “exposed terminal” problem Then, we have the “RTS chain” problem
Here’s a scheme that does away with the superstition: TARP The broadcast nature of the medium is a feature, not a flaw! No wires! Deal with it! Instead of wasting time, memory, and bandwidth on discovering and recovering the illusory paths, you should be sending the damn packets! Wisdom will emerge as the regular, useful, packets propagate and are overheard by all the nodes than can rightfully hear them No single item of that wisdom is critical (in the sense that the fate of an elaborate “connection” would entirely depend upon it)
The simple idea: I am A and I have a packet addressed to B; never heard of B before; what to do? A P-P scheme would say: hey, let’s send some queries around and wait until everybody learns exactly how to go TARP says: let’s send the packet right away I do have to send it eventually, right? no matter where I think it goes, all my neighbors will hear it anyway, right? so why bother with the queries?
This is a difference in paradigm; the forwarder’s dilemma: ? P-P TARP Where should I forward the Should I transmit (broadcast) packet? the packet? How can I learn the identity Will I help when I do that? of the next node on the path? Won’t my assistance be How do I make sure to know redundant? that identity at all times?
TARP is extremely proactive in the cheapest, most natural sense: ? P-P TARP I cannot forward unless I know I cannot stop forwarding unless I exactly how and when: am sure my help is not needed: I must explicitly receive the Nobody tells me what to packet first receive: I receive what I hear Then I must know where to I forward packets by default send it next Unless I have learned that I am not helpful
In simple words: P-P is obsessive about learning how to help It has to be obsessive, because it cannot forward at all unless it has the knowledge The knowledge is brittle and elaborate (it relates to a volatile path within the mesh) The knowledge must be complete to be of value
In simple words: TARP is not so obsessive about learning when not to help It doesn’t have to be obsessive, because the lack of knowledge is not as harmful Partial knowledge is meaningful! A better informed node will use less bandwidth … … which means that any node can help, according to its means
In its vanilla version, this approach amounts to flooding A broadcasts its packet If the node receiving the packet is B, the packet has made it Otherwise, the node re-broadcasts the packet (to all its neighbors) Well, this one is scary indeed: it never stops and does flood the network. Here are two easy fixes: Do not re-broadcast a packet that you have already handled a short while ago Do not re-broadcast stray packets (ones that have made too many hops)
TARP does connote with flooding (boo!), but don’t let them fool you! There is no way to get something for nothing! All those complicated P-P schemes need flooding at least for path discovery! When TARP knows nothing, it starts by naive flooding; when they know nothing, they are down to (necessarily naive) flooding, too; so we are even there But we can do much better than that!
TARP is driven by a chain of rules Received packet ignore rule 1 don’t know ignore Am I the No rule 2 recipient ? don’t know Yes ignore rule N Receive don’t know Rebroadcast Ignore
Recommend
More recommend
