I’ve seen a lot of installations for the spanish government that request virtual WLAN Cells. (Meru networks can do it but there is a expensive solution)
This is a WLAN with a controller and a lot of APs working like only one. All APs with the same channel frequency, the same MAC and the same AP Mode. You can put more than one ESSID per CELL.
With this you can reduce roaming time to 0, supporting roaming while you use VoIP services with any phone.
Well roaming seamlessly is a client feature, NOT an AP feature. I haven’t testet what you are asking for, but it would be easy to do so just by setting 2-3 AP’s with some distance between them, with same SSID/MAC etc. bridge them all together and see how things perform.
I want virtual wireless accesspoint. I need to create only one big AP with 10 RB411A. I need to put all APs in the same channel with the same mac. This is for reduce roaming time to 0. I need to make roaming between APs while I use VoIP.
I think what he’s asking for is Dumb APs, where a controller handles all the traffic directly at the MAC layer, while the APs are literally an RF <> CAT5/CAT6 converter. I believe Meru’s system does this, where all wireless traffic received by the dumb APs gets forwarded directly to the controller where it is then decoded into Ethernet traffic.
In other words, the controller becomes the access point, and each dumb AP is just an antenna. This allows the whole system to run on one channel (since there is only 1 radio doing the de/modulation) with 1 MAC address. The client is fooled into thinking there is just 1 access point, and the controller chooses the AP with the strongest signal for each packet received.
I’ve never seen these systems in practice, but in theory this means your entire WLAN shares 54Mbits between all its dumb APs… might be good for voice (low bandwidth + 0ms roaming), but quite horrible for anything else.
I doubt it… that needs a total redesign from the ground up. For example, the Ethernet ports on the Meru dumb APs are not really Ethernet, they are just using the CAT5 cable to send RF traffic back to the controller, where it is then decoded into Ethernet.
The Ethernet ports on MikroTik equipment (and all the hardware supported by Mikrotik) is Ethernet, wireless traffic is demodulated by the wireless card, not even by the Mikrotik software… this alone is a no-go to having a controller-based, single-MAC system with Mikrotik.
What IS possible (but I highly doubt it) is to have a ‘managed fat AP’ system, with one MikroTik router like an RB1000 controlling the configuration of all attached MikroTik access points.
Huh? The Meru’s and Cisco/Airospace do not work like that.
They use Atheros chipsets the same as Mikrotik support, how they work is that the radio passes EVERYTHING to the CPU on the board, which then encapsulates it and sends it to the controller which handles the registration and so on.
In concept it is very easy to do.
very easily, the AP’s run a cut down OS and CAN select what channel the radio card is on, but the actual data frame is encapsulated into UDP and sent across the LAN to the controller. The controller treats the remote AP as if it is a WLAN interface on the local box and does all the WPA/WEP and so on.
I used to be the SE for Airospace in this country before they were purchased by Cisco and that is exactly how they work.
I am guessing with the new Atheros drivers this would be easier than ever. Just pipe the raw device into a tun device accross to the “controller” where it does the reverse and creates a virtual wlan adaptor.
What you’re talking about is managed APs, sometimes called ‘thin’ APs. From your explanation, I am guessing this is how Cisco does it. Meru (or some other vendor, I’m confused now ) uses a different approach, they call it Virtual Cell technology.
From their website:
APs do not operate as stand-alone wireless Ethernet hubs; instead, they operate as a coordinated system of antennas, maximizing parallelism in transmission while minimizing co-channel interference
There’s even a white paper describing it further http://www.merunetworks.com/pdf/whitepapers/Virtual_Cells_WP4_0705.pdf. A quick read in fact reveals that my original explanation is still valid. I may have been technically incorrect on the details, but it is still correct to say that the APs are all synchronised by the controller and just act as antennas. This is what the original poster requested, NOT managed/thin APs and a controller.
Sidenote: strange how Meru does not mention the hidden node problem on their whitepapers..
Very ambitious project should MT decide to implement, This would be a very very interesting feature. I could actually see a reason for having a L6 Controller license with these abilities. (Tully, think of the new / more profitable licensing model you could use for this type of setup)
This (if done right, and in conjunction with NStream + polling) would really be a very serious advantage over every other wireless product on the market, including canopy (if you factor in all the power and other features of MT on top of this).
I honestly don’t see any breakthrough in using something like this. Piping traffic back to a central controller is a waste of resources (controller would need to handle total throughput of APs * 2), and at best this could be useful to use Dual nStreme with separate RBs (eg. 2* RIC/522 units with 1 RB1000 doing Dual nStreme with them).
After all, most of us with WISPs here are already doing that. We use PPPoE from our clients to a central controller. In effect, all our client traffic is going back to a central controller in raw form.
What other advantages are there exactly? Controller-based systems with all data piped back to a central controller have been partly successful mainly due to their AP management features. In fact, most vendors that used to evangelise the pipe-everything-back-to-a-central-controller idea have now started switching to the idea of using the controller just for AP management, security log processing and other management features. The ethernet data goes straight to where it has to go. This change was mainly brought about by the requirements of 802.11n, because having a single controller powerful enough to handle multiple 300Mbps streams at wire speed was unfeasable. In my opinion, they also just realised it doesn’t make sense in the real world.
And I want to remind you that the original poster’s idea was not to pipe raw DATA, but to pipe raw RF (including errors, collisions, non-802.11 data, etc) back into a controller. Then the controller can use the raw RF data to judge which AP to use for the same stream, on a per-packet basis.
As for Canopy, it does not pipe everything back centrally, it just has powerful management software to control the devices in the field. It eliminates co-channel interference by using GPS synchronisation.
Finally, it is clear to me that what most MT users really want is some form of centralised router management. The Dude is an excellent start, but it is limited to monitoring the routers. Now that ROS has an API, maybe MT should start working on a The Dude Deluxe which allows centralised and automated control of ROS.
) uses a different approach, they call it Virtual Cell technology.