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."
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....
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.
Yes, but the issue is what happens when the network density increases. There is only so much spectrum you can use for bandwidth, so if me, my next door neighbour, the whole street and their dog have a wireless link, our connection speeds all go down big time. This is the reason that cellphone networks sometimes have problems placing your call, even with digital compression. You thought contention on a wired network is bad? You'd better just be hoping this doesn't catch on as spectrum is *VERY* limited.
"To any truly impartial person, it would be obvious that I am right."
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
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--
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.
You don't happen to work there, do you?
So does Anonymous Coward have good karma?
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/