Linux-based Mesh Router Aims at VoIP and Video

An anonymous reader writes "A startup in Santa Clara, Calif. is shipping a Linux-based mesh router aimed at VoIP and video. The Mesh Dynamics Module uses multiple radios -- along with custom real-time Linux extensions -- to create a duplexing backhaul network said to improve bandwidth more than 64 times over conventional mesh technology. Normal, single-radio access points function in a half-duplex manner, a limitation that reduces bandwidth by 50 percent for each hop in the mesh. Mesh Dynamics is attempting to solve this problem by dedicating separate radios to upstream and downstream traffic of a 'backhaul' network that relays traffic between mesh nodes, thus simulating full-duplex operation."

Comments

VOIP and Video

[selectspec]

I'm not so sure that VOIP and video are good applications for this mesh product. Clearly the mesh product sounds like a better way to provide your hotel guests with IP connectivity. But to have your phone call drop or pr0n cut off because the chief decides to microwave your omlett or the lady next door uses her hair dryer would suck.

No simulation...

[wowbagger]

"thus simulating full duplex"

If there are separate channels for uplink and downlink, this is not simulating full duplex, it IS full duplex.

However, this makes me wonder about something. Compare this with another wireless mesh network - AX.25 (amatuer radio packet). In AX.25, rather than an end-to-end ack, each node acks the packet upon receipt, then forwards the packet to the next hop - thus acks need only move one hop.

Now, while this does increase the complexity of each node's processing (for example, how do you handle it when a packet has been accepted by a node, but that node cannot deliver the packet to the next hope), it cuts the delay on moving freight.

Now, TCP has a means to work around this (the TCP ack window), but it makes me wonder - would it be beneficial to a node system like this to have a protocol-layer store and forward system?

For example, what if each node ran a HTTP cache, and when a client requests a page, each node in the chain from client to server buffered the data so that any drop-outs and/or turnaround delays would have a minimal effect on the transfer?

I wonder which would have the greater effect upon throughput - full duplex, or caching? And would both have an even greater effect?

Re:No simulation...

[drwho]

To do VOIP properly, should shouldn'act ack at all -- its more important that packets arrive on time than a small percentage get dropped.

In general, though, the ideas behind ax.25 are good, and maybe should be applied to other aspects of mesh networks.

if the language sounds clumsy, please excuse me, it's sunday morning and I haven't had my coffee yet!

BTW, I am working on adapting MIT roofnet mesh software/protocol to doing VOIP, we have a project with wind-powered nodes. Not to production yet, not even close. But if you're interested drop me some mail.

routing

[way2trivial]

http://en.wikipedia.org/wiki/Wireless_mesh_network

Glad to see reuse of Amateur Packet Radio ideas

[Phil Karn]

Back in the 1980s, I published a paper at the ARRL Computer Network Conference on a "Collision-free Network" that used separate radio channels in a mesh network. Each node had its own assigned frequency to which its neighbors listened, and since no one else (within range) transmitted on each frequency, collisions couldn't occur. It also meant that each node could operate in full duplex. I actually built such a node near my house, and it worked pretty well. Of course, we were hobbled by the slow radios of the day.

I mention this just in case these guys have tried to patent my old idea. Wouldn't be the first time some company has tried to claim sole credit for something done a decade or two earlier by radio hams.

Might I Suggest Free Open Source Mesh Routing?

[meinrath]

I've commented on the math that Mesh Dynamics uses to justify their system on several occasions -- needless to say, it's wrong and overstates degradation. More importantly, their systems is _extremely_ expensive. Meanwhile, groups like CUWiN, FreiFunk and others are developing free open source mesh networking systems. CUWiN's software (and, for full disclosure, I cofounded and coordinate the project) can be downloaded by anyone, it's under an open source license, and everything (including the developers' environment) is freely available. We haven't implemented multi-radio solutions yet -- mainly because the bandwidth degredation hasn't been bad enough to justify it. But to do so, we're only talking about a few weeks of work -- which can be done by anyone who wants to add the feature -- and then you'd have a system that does the same thing as Mesh Dynamics, but is freely avaialable to anyone who wants it.