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

Interesting...

[Sheetrock]

It's good to see chessboard mechanics being applied to mesh routing. It's a problem that is worth the effort put into the solution, as to properly exploit over-the-air transmission there needs to be a system to take into account bandwidth scarcity and proximity considerations.

Granted, a lot can be done with increased selectivity in transceivers and protocols designed specifically not to walk on each other's signals, but having a system that can measure and dynamically employ the relative signal strength of nearby equipment to form an optimal network under suboptimal conditions is what it's all about.

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...

[_ph1ux_]

"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 wrote a white paper on a system very similar to this. The difference that I had was that I was calling for a system with a blend of thin and fat APs.

Thin APs would be deployed as the transit system - overthe long expanses where there was no uplink to the internet.

Fat APs would be deployed in a perimiter around an uplink (a hot spot)

The thin APs were just mesh relays. The Fat APs would use NBAR (Network based application recognition) on steroids to examine traffic and requests.

As traffic came through it would be looked at to determine if it was accessing a service that was locally available, and redirected to the appropriate location. Basically a modified DNS. Also a local cache would be near each uplink which would provide clients access to cached pages to minimize the traffic that required being backhauled to the internet.

The DNS-like system would allow for hotspots to present network services to the clients in their proximity. For example, you could redirect DNS quesries to a local DNS server - rather than backhauling it accross your uplink. Most would say "why would you redirect DNS?" well the reason is that the requests could be coming from a client that was far out on the mesh who wouldnt have to have a dhcp dns server address given to him.

the other interesting aspect of this is that a browser advert system could be developed such that banner ads on a browser could be proximity based. So that businesses within a certain radius of the user would be presented through a common banner - and the advertised businesses would change based on where the user was.

Other services could be presented in the modified DNS where a hotspot could advertise to clients whether it had printing kiosks or other services available.

I talked to airspace about this - at the time I was looking for someone that could do the NBAR in asics - but there was discussion on how deep into the packet you needed to go. Force10 had the most compelling hardware for this...

Re:No simulation...

[Andy Dodd]

As one of the other replies to your post mentioned, for streaming applications such as VOIP and streaming video, ACKs are not used at all and the protocol is designed to be somewhat tolerant of outright packet loss. (Usually some form of forward error correction that is capable of operating at the packet level instead of the link level.)

In situations where the packet loss on links is relatively high (e.g. wireless links), it would probably make sense to do node-to-node ACKs for data that needs to be sent reliably though. If the probability that a packet traverses a link is 0.9, the probability that a packet will traverse N hops is 0.9^N - Thus for networks with many hops (likely for mesh networks), node-to-node ACKs would be a Very Good Thing. (I think this is one reason why X.25 and AX.25, which is a modified version of X.25 meant specifically for amateur radio uses, use node-to-node ACKs.)

An HTTP cache at each node would be VERY interesting, although it could potentially increase latency significantly for new requests not in the cache system.

Plus VOIP can't be cached anyway. As time goes on, data on the Internet is becoming less and less cacheable.

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.