Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Wireless Networking Hardware

Linux-based Mesh Router Aims at VoIP and Video 42

Posted by CmdrTaco from the thats-a-lotta-fancy-networking dept.
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."
This discussion has been archived. No new comments can be posted.

Linux-based Mesh Router Aims at VoIP and Video More

Linux-based Mesh Router Aims at VoIP and Video

Comments Filter:

  • Interesting... (Score:4, Interesting)

    by Sheetrock ( 152993 ) on Sunday March 06, 2005 @09:50AM (#11858316) Homepage Journal
    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.

  • VOIP and Video (Score:5, Funny)

    by selectspec ( 74651 ) on Sunday March 06, 2005 @09:54AM (#11858326)
    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.
    • But to have your phone call drop [...] because the chief decides to microwave your omlett or the lady next door uses her hair dryer would suck.

      How is that any different than using a cell-phone? People exaggerate 802.11 drop-outs, and there's a great deal of money from phone companies under-estimating cell-phone drop-outs. I'll take 802.11 VoIP, rather than a standard cell-phone any day...
      • I'm not convinced that people are exaggerating. If we walk between our TV computer and our wireless router, the video gets choppy. God forbid someone decides they want to microwave some popcorn..

        • If we walk between our TV computer and our wireless router, the video gets choppy.

          Apples and Oranges.

          Wireless has to slow-down when there is interference... at which point, there is apparently not enough bandwidth for your streaming video. As VoIP uses a fraction the bandwidth that streaming video does, it's not as much of a problem.

          In addition, it sounds very much like you have a low-power 802.11 devices (the power varies greately) and are operating them near their maximum range in the first place (and

          • Oh, the fact that the router is a refurb Microsoft and the network card is an old b adapter certainly contribute to the problem. That said, it's really quite remarkable watching the video die the moment someone gets up.
      • Ever try to use a cell phone in a hotel? It usually sucks, especially in a big hotel with lots of walls. Interestingly enough however, cellphones also use two bandwidths. Your phone broadcasts your message at 45 Mhz lower than the tower.

  • No simulation... (Score:5, Interesting)

    by wowbagger ( 69688 ) on Sunday March 06, 2005 @09:55AM (#11858329) Homepage Journal
    "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... (Score:5, Insightful)

      by drwho ( 4190 ) on Sunday March 06, 2005 @10:13AM (#11858382) Homepage Journal
      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.
    • Granted there are seperate channels for up and down links, but the channel, or actually radio, is only able to send or receive at any given moment. In this example, one is swicthing for the front end and the other is switching for the back end. None the less, by definition half duplex. It would need a total of 4 radios; 2 of which only listen and 2 that only receive to be full duplex.

    • Re:No simulation... (Score:4, Interesting)

      by _ph1ux_ ( 216706 ) on Sunday March 06, 2005 @12:53PM (#11859275)
      "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...

      • Good ideas ph1ux -- and I say this because they are somewhat similar to some of mine ;)

        If you start thinking in terms of DOCUMENTS instead of PACKETS, then distributing non-realtime content gets really interesting - I've come up with a bunch of algoritms for intelligent, distributed caching.

        I wish there was some place better than slashdot to discuss all this: there are too many people asking things like "what is a mesh router?" for me to feel comfortable getting really technical.

        Well, we have a mailing l

    • Re:No simulation... (Score:4, Interesting)

      by Andy Dodd ( 701 ) <atd7@c[ ]ell.edu ['orn' in gap]> on Sunday March 06, 2005 @01:02PM (#11859313) Homepage
      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.
    • "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's the so-called best-effort delivery: it's all about hope ;)
  • Excuse my ignorance, but what is a mesh router? How is it different than a normal router?

  • GPL violation? (Score:2, Insightful)

    by Husgaard ( 858362 )

    Asked how the kernel extension is licensed, Dacosta said, "We'd be happy to provide it to anyone once we get it working, although I'd question its value without a full development environment, which we probably will not offer."

    So according to the manufacturer, this stuff does not work...

    The GPL clearly states that when code derived from GPL code or linked with GPL code is distributed, this code must be released under a GPL license. There is no exception for non-working code.

    It looks to me like the

    • Re:GPL violation? (Score:2, Insightful)

      by Anonymous Coward
      Are they distributing it right now in non-working stage? If not, they're under no obligation to release the code.
    • This is probably a summary of other posts: this is only a production _announcement_, not a product _release_: they have no obligation to offer GPL code until they start offering binaries at the _release_.
    • Does source code = full developement envirement? Or does it involve other things like possibly...tech support, or maybe a pretty GUI interface for probramming the thing? What are you saying here? Ok, so they don't release it(which they don't have to until they release the product, as pointed out by others). Can they then stop me from extracting and using or improving it myself? Or do I need a court order to reverse engineer it? So someone does it anonymously. Game over, man. We'll see how well GPL holds up
  • Will the processor being used actually support 4 802.11a or g channels? I am willing to be that the overhead of the OS + the overhead with the packet processing (signal vs noise) and finally raw data processing and routing will likely cripple one with 4 radios.

    802.11n will likely prove the real backbone of mesh networking in the next year.

  • Glad to see reuse of Amateur Packet Radio ideas (Score:5, Interesting)

    by Phil Karn ( 14620 ) <karn&ka9q,net> on Sunday March 06, 2005 @12:30PM (#11859143) Homepage
    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? (Score:5, Interesting)

    by meinrath ( 775421 ) on Sunday March 06, 2005 @02:10PM (#11859781) Homepage
    I've commented on the math [wifinetnews.com] 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 [cuwireless.net], FreiFunk [freifunk.net] 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.
  • ...if we had wireless network interface hardware that operated in some other part of the spectrum than the 2.4GHz and 5.8GHz license free 802.11x, which is already so swamped with traffic around here that it's now more useless than CB radio was in the late 1970's - early 1980's when 18 bazillion people were trying to talk all at the same time on the same rf channels.

Slashdot Top Deals

/earth: file system full.

Close