A few meanderings on AirGroup & its new Auto-associate feature...
Auto-association allows AirGroup users to discover nearby AirGroup servers. Auto-association ensures that all the AirGroup users associated to an AP-group, AP-FQLN, or AP and its neighbors discover the AirGroup servers. An administrator can enable auto-association for each AirGroup server separately and configure AP-name, AP-group, or AP-FQLN for auto-association.
I understand that I can setup individual policies per individual airgroup servers based on MAC Address.
Auto-association can be enabled for a complete service, which allows all the AirGroup servers who advertise that service to be auto-associated with the configured parameter.
Or, I can specify auto-association based on airgroup service, i.e. all AirPlay servers or GoogleCast servers.
Auto-association ensures that all the AirGroup users associated to an AP-group, AP-FQLN, or AP and its neighbors discover the AirGroup servers. Administrator can also configure location-based policies for AirGroup devices. For example, administrator can configure if an AirGroup server is visible over a broader area than auto-association configuration. In location-based configuration, administrator can configure AP names, AP groups, and AP FQLNs. Location-based policy configuration limits the AirGroup server’s visibility to AirGroup users who are associated to configured APs, its neighbors, AP-groups, or AP-FQLNs. ... Administrator can choose whether to consider the neighborhood of the configured AP names.
How does one determine which APs would be considered neighbors? Specifically, how does the airgroup sub-system define an APs "neighbors"? There doesn't appear to be any configurable method to define which APs are one hop away (via PL or SNR).
I realize that I can use the command "show ap arm neighbors" to view a list of neighbors that a given AP sees; however, that provides a numbers for one hop & two hop APs based on which additional options are passed to the command (active | direct | relevant | valid).
Which of these does the airgroup subsystem use to determine what AP neighbors would be allowed to see AirGroup servers?
It would be really nice to be allowed to configure a threshold to determine / force which APs would be considered neighbors. Perhaps something along the lines of a PL threshold?
Ultimately, I guess, this harks back to the creation of coverage circles or areas which take into account Tx power settings and what not - going back to the Indoor 802.11n VRD.
Ah...
Could I define the same AP-FQLN for an arbitrary group of APs as a way to limit AirGroup services available in a given classroom or area? So say a classroom contains 3 APs, can I place those APs in the same AP-FQLN & define an "airgroupservice auto-associate ap-fqln classroom_x" to essentially limit airgroup services to that location?
We're looking to enable AirGroup features to provide our student population services that they'd expect would just work, "like @ home". For residence halls, it could be a simple matter of enabling certain AirGroup Services and limiting them via AP-Group. However, for administrative buildings in which a department may only wish to allow specific users or services to specific areas a little more though and planning needs to be exhorted.
At the moment, we want to avoid implementing a registration system via CPPM; however, if the need ever arrises to allow specific groups of people access to AirGroup Services then we may take a look at that or the shared user, group, or role list feature.
I'm curious to know what others are doing to provide AirGroup services?
Thanks,