Comment 1 for bug 360692

Here's a description of Meru's Virtual Cell technology:

What is Virtual Cell?
By default, access points on the same channel share a BSSID when you create an
ESSID. This allows the formation of a Virtual Cell, which is a group
of access points
on the same channel sharing the same BSSID. You can disable access points on the
same channel from sharing the same BSSID, which prevents the formation
of a Virtual
Cell. If you prevent access points on the same channel from sharing
the same BSSID,
each access point has its own unique BSSID.

The per-station-bssid feature assigns each station its own unique, link-local
BSSID, called a Meru SSID of MSSID, which a station keeps throughout the Virtual
Cell. It is permissible to have a mix of ESS profiles that use both shared and
per-station BSSID implementations of Virtual Cell.
Types of Virtual Cell
                             Shared BSSID Vcell
                             Per-station BSSID Vcell

Per-station BSSID Vcell OVERVIEW for AP200:

Starting in release 3.4, there is a new method to support the Meru
Virtual Cell (VC) functionality called "per-station-bssid". The
primary difference between "per-station-bssid" and the traditional VC
method (called "shared-bssid" in the web interface and ioscli) is that
"per-station-bssid" modifies the beacon behavior so that only one AP
will send beacons for a given BSSID - i.e. rather than all APs
supporting the same essid/channel pair beaconing for that BSSID . The
original method of VC will continue to be supported and a single
controller will be able to simultaneously support essids configured to
use the new "per-station-bssid" along with essids configured to use
the original VC method.

The "per-station-bssid" is supported in the AP 201 and 208 in 3.4. A
future release will support the AP 300 series. There is no planned
per-station BSSID support for the AP 150.

SUITABLE DEPLOYMENTS

"Per-station-bssid" is well-suited for any deployments that make heavy
use of wireless stations with the Intel 3945 chipset. The
interoperability issues between the Intel 3945 chipset and the
original implementation of Meru's Virtual Cell functionality was one
of the primary reasons for the new virtual cell implementation.

Along with the specific Intel 3945 issue, there have been a handful of
other, more minor, interoperability issues with other
chipsets/supplicants because of how the original VC method was
implemented.

SOME NUTS AND BOLTS

                                  "per-station-bssid" works by
generating a unique BSSID for each station that comes onto the
network.
                                  Beacons are sent from that generated
BSSID at the configured beacon interval of the associated ESSID
profile. So, in contrast to the original VC method, where an air
capture would show n beacons per beacon interval from a given BSSID, n
equal to the number of APs supporting that BSSID, a per-station BSSID
air capture will show 1 beacon per beacon interval from an individual
station's BSSID.
                                  Beacons will be generally
transmitted at the individual station's unicast transmission rate (but
no higher than 24M by default), which will almost always be much
higher than the rate used in the original VC method (lowest base
rate). So, though there will be a beacon per station, the beacons will
go out at a much higher rate than the ESSID's lowest base rate. This
greatly reduces the air time consumed by beacons compared with the
original VC implementation and allows this method to scale.
                                  When there are no stations
associated to an ESSID configured to use "per-station-bssid", there
will be no per-station-bssids generated and consequently no beacons
over the air.
                                  Beacons start from any newly
generated BSSID after one of two events: 1) there is a Probe Request
from a station with a specified SSID string or 2) an 802.11 Auth
Request to a specified BSSID. Probe Requests without a specified SSID
string result in Probe Responses from all supported ESSIDs within RF
range, each from a newly generated per-station-bssid. The station is
then expected to either send either 1) a Probe Request with a
specified SSID string or 2) an 802.11 Auth Request to that newly
generated BSSID to get the beacons started.
                                  Beacons from a per-station-bssid do
not contain the associated SSID string and therefore air sniffing
utilities and other utilities that use SSID strings within beacons for
any purpose will not see those SSID strings. The purpose of this is to
prevent other stations from sending Probe Requests or 802.11 Auths to
another station's per-station-bssid.
                                  As a station moves and is detected
to be better served by a different AP, handoff will occur to the new
AP and the station's individual BSSID will move with it to the new AP.

CAVEATS

                                  Per-station BSSID SHOULD NOT be used
in conjunction in predominantly B-radio client environment and
especially not B phones. The reason is that the beacon streams are
transmitted at the current data rate of the station (e.g. if a station
is transmitting at 11M, the beacons go at 11M generally). An
environment with lots of B clients means lots of beacon streams at 11M
or less. That consumes a lot of air time leading to poorer performance
for data clients and poor audio for phones. Using per-station BSSID
with G phones is fine and has been shown to work in the field at
multiple customer sites.
                                  Because of the way
"per-station-bssid" has been implemented, the maximum number of
stations using a "per-station-bssid" ESSID that can supported on a
single AP has gone from 128 to 63. So, if there is a coverage area
served by a single AP today where there might be in excess of 63
stations, another AP may be added into that area to support the
wireless station population.
                                  The 63 maximum cited above is the
case where the AP in question is supporting just one ESSID, where that
ESSID is configured to be "per-station-bssid". The exact calculation
to determine how many stations a given AP can support given multiple
ESSIDs is as follows:

Define "n" to be the number of entries from "show ess-ap" output
related to this AP.
Define "m" to be the number of stations on this AP using a
"per-station-bssid" ESSID.
n + m must be <=64.

So, for example, suppose a customer has configured a single essid and
has only B or G stations. With that configuration, the "show ess-ap"
output will have only two entries per AP, one for the A radio and one
for the B/G radio. Since the customer cares only about B/G stations,
the A radio ess-ap entries may be removed. What is left is a single
ess-ap entry for each AP, so "n" = 1. So, 63 stations may associate to
each AP as 1 + 63 <= 64.

As a more complex example, suppose a customer needs to support 4
ESSIDs, three traditional VC ESSIDs and 1 per-station-bssid. Also
suppose the customer needs to support both A and B/G stations and so
cannot remove the A radio ess-ap entries. Lastly, suppose the customer
needs to support all ESSIDs on every AP (worst case). So, "n" in this
case will be 8, 4 B/G ess-ap entries + 4 A ess-ap entries for each AP.
So, "m" may be a maximum of 56 and so 56 stations could associate to
each AP in this example.