Руководство По Проектированию для Cisco Cisco Aironet 350 Mini-PCI Wireless LAN Client Adapter

As stated above, H-REAP deployments typically consist of only a handful of APs at a given location. 
Cisco maintains strict guidelines regarding the number and placement of APs to achieve the highest level 
of location accuracy. As such, although it is possible to obtain location information from H-REAP 
deployments, the level of accuracy can vary greatly across remote location deployments. Therefore, it is 
unlikely that the Cisco optimal location accuracy specification can be achieved in a typical H-REAP 
deployment unless Cisco’s stated location design recommendations can be followed. For more 
information, see the following URL: 

For WLANs that are centrally switched, the H-REAP handles QoS is the same way as standard LAPs. 
Locally switched WLANs implement QoS differently. 

For locally switched WLANs with WMM traffic, the AP marks the dot1p value within the dot1q VLAN 
tag for upstream traffic. This happens only for tagged VLANs, not the native VLAN.

For downstream traffic, the H-REAP uses the incoming dot1p tag from the locally switched Ethernet and 
uses this to queue and mark the WMM values associated with frames destined to a given user across the 
RF link.

The WLAN QoS profile is applied both for upstream and downstream packets. For downstream, if an 
802.1p value that is higher than the default WLAN value is received, the default WLAN value is used. 
For upstream, if the client sends an WMM value that is higher than the default WLAN value, the default 
WLAN value is used. For non-WMM traffic, there is no CoS marking on the client frames from the AP.

For more information see 

Cisco strongly recommends that appropriate queuing/policing mechanisms be implemented across the 
WAN to ensure proper handling of traffic based on its DSCP setting. An appropriate priority queue 
should be reserved for LWAPP control traffic (which is marked DSCP CS6) to ensure that an H-REAP 
does not inadvertently cycle between connected and standalone modes because of congestion. 

Although it is possible for any WLC within the campus to support H-REAPs, depending on the number 
of branch locations and subsequently the total number of H-REAPs being deployed, it makes sense (from 
an administrative standpoint) to consider using a dedicated WLC(s) to support the H-REAP deployment. 

H-REAPs typically do not share the same policies as the LAPs within a main campus; each branch 
location is essentially an RF and mobility domain unto itself. Even though a single WLC cannot be 
partitioned into multiple logical RF and mobility domains, a dedicated WLC allows branch-specific 
configuration and policies to be logically separate from the campus. 

If deployed, a dedicated H-REAP WLC should be configured with a different mobility and RF network 
name than that of the main campus. All H-REAPs joined to the “dedicated” WLC become members of 
that RF and mobility domain. 

From an auto-RF standpoint, assuming there are enough H-REAPs deployed within a given branch (see 

), the WLC attempts to auto manage the RF coverage associated 

with each branch.

There is no advantage (or disadvantage) by having the H-REAPs consolidated into their own mobility 
domain. This is because client traffic is switched locally. EoIP mobility tunnels are not invoked between 
WLCs (of the same mobility domain) where client roaming with H-REAPs is involved.