Slashdot Mirror
Wireless Mesh Networks
Roland Piquepaille writes "Robert Poor is CTO of Ember Corporation. He contends that point-to-point or point-to-multipoint networks typical of industrial wireless communications systems have limited scalability and reliability. 'In contrast, wireless mesh networks are multihop systems in which devices assist each other in transmitting packets through the network, especially in adverse conditions. You can drop these ad-hoc networks into place with minimal preparation, and they provide a reliable, flexible system that can be extended to thousands of devices.' The article is pretty technical and contains several illustrations and a case study about the deployment of a wireless mesh network in a water treatment plant. Check this column for Poor's conclusions or read this Sensors article if you have more time."
The only way to make something like this work is to have a solid L3 encryption system between the remote and the head end - intermediate stations will certainly get snooped.
IPsec is the way to go, but its still something of a hassle on IPv4. I've seen a lot of noise about mesh networks - this isn't really going to take off until IPv6 gets moving under its own power - perhaps another five years.
I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
Well, I'll buy it as working for a small business but you would find it very difficult to have a big network as all of the network chatter takes up an increasing amount of spectrum. This is the same problem P2P networks have (a similar arch) and they can only solve it by having a network that cannot see all nodes. This is not a good idea for a wider net for obvious reasons.
"To any truly impartial person, it would be obvious that I am right."
You can find a couple of demonstrations of how mesh networks can actually work and be implemented in cities and companies on MeshNetworks' homepage. Very cool how the p2p works....
A smart routing protocol for many-to-many wireless connections is critical for the growth of metropolitan wireless networks.
If anybody in Sydney, Australia is interested in joining a wireless network, check out Sydney Wireless.
"Smoking helps you lose weight - one lung at a time" -- A. E. Neumann
In their WBT article "The Unwired soldier," authors Allen H. Kupetz and K. Terrell Brown introduce their concept of the 'Wal-Mart Soldier' and explain how "every soldier's communication device will be an individual network element with a unique IP address. All the network devices on the battlefield - including those embedded in tanks or other vehicles - will instantly form, heal, and update the network as users come and go. That is, they will associate in an ad hoc manner."
"But unlike cell-based solutions," the authors write, "network coverage and service levels will improve when soldier density increases. Network resources are also better utilized because networks are self-balancing as well. The soldier's subscriber device can hop to distant network access points, away from points of congestion, shifting network capacity to where the demand is."
Here's the really wild part, though: "Finally, this technology will function as a PAN (personal area network), a LAN (local area network), and a WAN (wide area network), simultaneously. This means that the same network can connect a soldier to the squad/platoon, to the battalion, and to a fully mobile division. This is critical to meeting the functionality requirements of the FCS program. It is the equivalent of Bluetooth, 802.11, and 3G converging, but in a single network, with a single device."
They also point out (before you ask!) that "The next-generation soldier's communication device has not yet been chosen. There are several DARPA/DoD projects operating simultaneously, all of which have a communications device component. These include the "Warfighter Information Network - Tactical" (WIN-T), "Future Combat Systems" (FCS - formerly known as Future Ground Combat Systems), "Small Unit Operations/Situational Awareness System" (SUO/SAS), and the "Joint Tactical Radio System - Programmable, Modular Communications System" (JTRS-PMCS)."
Which turns a laptop or PC system into a Linux based mesh routing access point and thin client. They also sell hardware boxes. Get the bootable ISO here - build 22 is recommended.
you would find it very difficult to have a big network as all of the network chatter takes up an increasing amount of spectrum
This is not so, although the articles doesn't really make that clear --- the aggregate bandwidth of these networks grows as the number of nodes increases in density and in geographical extent.
The reason why this is so is that in a wireless mesh network, RF coverage is purposely restricted by turning down the power automatically and/or by dynamic channelization using frequency, time, or code (spread spectrum) multiplexing. This in effect gives you a dynamic cellular type of architecture, with channel reuse in non-adjacent cells.
And that of course is why it's called a mesh network --- it's not a fully connected network of nodes (which would be non-scalable and bandwidth-limited), but a mesh in which locality is strong so that nodes only hear and connect to their nearest neighbours, so each new locale contributes bandwidth to the overall aggregate capacity instead of eating up yet another slice of a dwindling pie.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Has someone done any simulations on the behaviour of these mesh networks as the number of nodes increases, without an increase in the number of connected (with one foot in each domain) nodes?
Also, will the "max flow min cut" theorem come into play at some point? Will some poor sod who happens to be the "cut point" get hammered beyond belief by having to route all packets?
It looks to me (and I could be totally wrong here, its been known to happen quite often) that this "mesh networks" craze is similar in vein to the "P2P" and "distributed computing" crazes that came along a couple of years ago.
Mesh wireless networks sound good in theory, kinda like microkernel OS's ;p, but in practice they have been unworkable to this point. Nokia bought a company, whose name I can't remember, for this type of product, Nokia called it Rooftop. The previous company had spent more than 4 years in development, and Nokia pumped in enough cash to add another year or so, but the product was a technical failure. Our company was already experienced deploying wireless systems (Alvarion/Breezecom and Orninoco) so we liked what Nokia had to say about the product and we gave it a try. The system proved to be totally unusable, the customer prem equipment often couldn't figure out which way to send traffic if the node it was previously using went away. I don't think that a mesh system is totally unworkable, but I do think its more complicated than most people think. Nokia has already removed the info from their site, but
google cache here
Tessco was Nokia's reseller on the line and they still have info and pics on it here
We are deploying a city-wide 802.11b network as we speak, and although it 'eliminates the need for expensive cell towers', we are able to get on top of two well-placed high rises and cover a good portion of the area. Less equipment expense for us is ALWAYS a good thing.
:(
We would not be able to afford getting rights in all the places needed to make this feasible. Heck, the hassle of GETTING the rights needed would be make this prohibitive.
Karma: Chameleon (mostly due to the fact that you come and go).
... has been running for several months in Kingsbridge, Devon (UK), based on 'off the shelf' hardware, and free software downloadable from LocustWorld.com. There is also a bootable ISO that turns any PC into a Mesh node without overwriting any of the local data! You can download it here - Build 22 is recommended
If you assume a 2 dimensional distribution, the total power transmitted can remain the same, reguardless of the number of nodes.
--Mike--
Ok then...as I can understand it (and maybe I'm missing the point here), for objects in the mesh to assist in carrying its traffic, you have to entrust them to be part of its infrastructure. This leads to the obvious question: would you allow just anyone to put their router (or device that acts like a router and does god knows what else) between you and your endpoint? For that matter, would you trust a network made entirely of network devices that everyone and their brother contributed, with those devices able to come and go like thieves in the night?
:)
It seems to me that a mesh network would inherently place trust in all users, in a world where it's clear that all users should not be trusted, just some...and there's no way yet to sort out the good from the bad. Even if you restricted the use/deployment of the network to a single organization, it still poses an absolute nightmare that an insider could subvert the functions of a node.
I love the notion of minimal centralization (if any) and the fault tolerance that can come with it, but I think that the security risk is waaaaaay too great.
One day, when all connections between points (I doubt this day will come, btw) are encrypted, this could work, but only as long as the mesh itself could detect and isolate the source of DoS behavior against the rest of the net. Remember, encryption keeps information secret, but it doesn't keep anyone from just plain breaking stuff
For your security, this post has been encrypted with ROT-13, twice.
Having watched him operate for several years, it seems that Rob Poor thinks that simply by 1) talking about mesh networks for several years, 2) building a half-assed mesh simulator for his M.S. thesis that didn't even work, 3) blustering his way through a Ph.D. on the strength of that old simulator, 4) raising VC for an ill-posed attack on a very difficult problem, and 5) sitting on topic committees that have many fine lunches and dinners at consortium expense, he will somehow gain insight into a problem that he still doesn't even understand.
But if you really want to believe the hype, then perhaps you'll be impressed by the advanced level of technical sophistication evidenced by this presentation on his website. Don't forget your free sample of PIC code that shows us all how gosh-dang simple it is to be a radio engineer! Want to build a mesh? Just sprinkle a few thousand PICs in the environment and they'll self-organize into a network through the emergent properties of entrainment!
It seems so obvious; why didn't we think of that?
My biggest problem with this type of network is the battery life. Sure, maybe the logistics of the network architecture are sound or whatever, but if my cell phone or my laptop is constantly rebroadcasting packets whenever it's in range of the network, then I'm pretty sure there'll be a substantial drain on my battery life. Maybe when battery life is basically a non-issue this type of network will be feasible, but until then, bleh!
__________________________________________
Take comfort in your ignorance.
Grandmaster Plague
It seems that every node must be "connected", that is every node must "touch" every other node. Is that the way this technology works? I couldn't tell from the article. If so, it doesn't look like this type of network will scale very well. (Much like p2p networks...they work around this problem by limiting the amount of nodes any other node can see). I remember talking about this type of network (and its limitations) in college in a graph theory class.
-ted
-ted
Let me make a few comments, since Rob happens to be my uncle. He's got a PhD from MIT's Media Lab, and, among other things, used to work at NeXT, so trust me he knows what he's doing. Most comments here question scalability and security, so I'll address those. As some have pointed out, it's a MESH, so the nodes only see other, nearby nodes. The Ember nodes are inexpensive devices (I have a swag version on my fridge downstairs, it's small), if there is a bottleneck you add another one. These devices, as I understand it, are aimed at firms trying to do LAN-type of things where laying cable or fiber is expensive. However, a lot of such places already are wired for power, which was questioned by one poster.
As for security, again, under the scenarios I am familiar with, these devices are local and low-power, so you'd have to be onsite to snoop. But, the Ember nodes are flexible, low-level devices, so you run what you want over them. I don't see why that wouldn't enclude any type of encryption.
Granted, I don't work for Ember (IANAEE), but that's my understanding of it.
This is not about networking PC/PDA it is about replacing the wires going from a sensor to the PLC. If you don't know what a PLC is this article is not aimed at you. The example they used is sensors in a piping tunnel that would block a standard ceneral base staion radio approach. It is about conneting less than a hundred signals from a fixed location going back to another fixed location.
It is about accepting some additional data loss for not hving to run copper or fiber to the sensors. It seems to me it would be of most use to a temporary installation or spread out sensor array where lighting could take out your PLC.
The main issue at stake here is that each node in the ad-hoc network is both a router and a network node in itself. Consider an ad-hoc network I am participating in when I am riding a bus. Let us say I am watching a thriller on DVD on my device locally. All of a sudden, my two neighboring co-passengers start streaming video from each other's devices and suck up so much bandwidth (and therefore processing power) from my device that my DVD starts to jump right at the climax of the movie. Clearly, this is quite unacceptable.
In general, if Device A relays some packets on Device B's behalf, then Device B should give it some number of credits that Device A can use in the future to have Device B repay the favor. In choosing an ad-hoc route, the protocol which routes packets through ad-hoc networks must take into account not only how much each device is contributing to the network, but also how equipped they are in terms of processing power, current battery level and the like.
Been there, done that. I designed a wireless tactical network based on this idea back in 1995 or 1996. What I discovered is that it's tricky to get routing right if you use a broadcast type of protocol where each node automatically retransmits anything it hears, because the network quickly gets swamped with retransmissions unless you're careful about the timing of retransmissions. The other way to do it (which I implemented) is to exchange routing information throughout the network - sharing information on which nodes any particular node can hear - then it becomes easy to route packets efficiently through the network.
APRS does a similar sort of thing as the former - it uses a decaying algorithm to determine when to retransmit messages, and so (mostly) avoids the congestion problems inherent in such a design.
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
A friend of mine worked on the Grid Project over at MIT's LCS department...sounds pretty interesting -- they have some test networking set up:
http://www.pdos.lcs.mit.edu/grid/
No. Actually the bandwidth is not finite. In fact it scales up proportional to the number of nodes if the nodes are reasonably smart.
The idea of a fixed pie of bandwidth is based on the Shannon limit and the idea that radio waves go infinite distance.
In real life the radio waves get absorbed, attenuate with distance and the Shannon limit only applies between any two nodes in the network- it does not represent a fundamental limit for the network.
It's a bit like sound in an office. If there's lots of walls around the sound gets absorbed and everyone can talk to each other and pass messages around.
The failure here seems to be not appreciating that people will all want to connect to certain nodes, as they supply the (wired) bandwidth.
Yeah, but that's a problem we have already on the internet, and the protocols already divide the bandwidth up fairly.
And if the cells get smaller, the amount of routing hops increases
Yeah, but not much. The number of hops goes up with the square root of the number of nodes; so a network with a thousand nodes has 30 hops; and that's a huge wireless network. 30 hops might be a lag of 60ms.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"