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.