This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Wi-Fi design and deployment

In-depth information and best practices for designing and deploying wireless networks.

1 - Wi-Fi design guides

Comprehensive Wi-Fi design guides for various environments. Learn best practices for optimal wireless performance.

1.1 - Warehouse

Warehouse Wi-Fi deployment best practices.

Warehouse environments present unique challenges in Wi-Fi design, due to factors like high ceilings, metal shelving, dynamic inventory levels, and environmental conditions. This guide offers a comprehensive approach to designing robust and reliable Wi-Fi networks tailored to warehouse environments.

Challenges

  • Large spaces: Warehouses often have vast, open areas that require extensive coverage. Each AP typically covers a larger area, ranging from 3,000 to 8,000 square feet (900 to 2500 square meters), compared to smaller indoor environments.

Example of a large open warehouse space

  • Tall structures and obstacles: The height of warehouse ceilings and storage racks, combined with heavy shelving and large equipment, adds complexity to coverage planning. These factors create physical obstructions that can interfere with signal propagation.

Example of tall ceilings and storage racks

Example of tall storage racks

  • Variable Climate Control: Temperature-controlled areas such as refrigerated or freezer zones create challenging RF conditions. Extreme cold, insulated walls, and sealed doors can alter signal propagation, cause condensation on equipment.

  • AP mounting and cable management: Due to the unique warehouse layout, finding suitable mounting locations for APs can be difficult. Additionally, planning for power and data cable runs needs to account for both vertical space and potential obstacles.

  • Inadequate indoor APs: Standard indoor APs often struggle to cover the long distances and large spaces typical of warehouses. This necessitates the use of more powerful, specialized APs.

  • While APs utilizing external antennas, also known as connectorized APs, may offer more flexibility, they add both hardware and labor costs. They also introduce the potential for greater risk during installation and future maintenance.

Key design considerations

  • Warehouse size: The overall square footage will dictate the number of APs needed for adequate coverage.

  • Ceiling height: Taller ceilings require higher-powered APs or more APs to ensure signals reach the ground.

  • Rack height: The space between the AP and the top of rack impacts how the signal propagates.

  • Client density: The number of devices that will be connected to the network at any given time impacts both throughput requirements and the number of APs needed to handle traffic. In warehouses, device density is typically much lower than in an office space, but coverage still needs to support scanners, handhelds, and IoT devices reliably.

  • Location or wayfinding: If the design includes location-based services (e.g., asset tracking or employee navigation), this must be factored into the network’s design to ensure accuracy and reliability.

  • Types of goods stored: Different materials and objects stored on shelves can influence signal strength due to varying levels of radio interference.

  • Hostile Environmental Conditions: Unlike office buildings, many warehouses are partially exposed to the elements and lack consistent heating or cooling across the entire space. This subjects networking equipment to greater temperature fluctuations and harsher conditions. An example of an additional challenge that is not uncommon is the presence of bird or rodent nests in rafters or eaves.

Example of storage

  • Layout and content changes: Warehouses are dynamic environments where layout and inventory can change frequently. The Wi-Fi design should be adaptable to these changes, ensuring reliable coverage even as the space evolves.

  • Outdoor areas: If the design extends beyond the warehouse building (e.g., docks, yard spaces), outdoor APs or mesh networks may be necessary.

  • Client types: Different types of devices, such as scanners, tablets, forklifts, and mobile phones, may have varying power requirements and need to be considered when designing the network.

These factors should be considered to create a robust and scalable Wi-Fi design that accommodates the unique challenges of warehouse environments.

AP placement strategies

There are two main options for HPE Aruba Networking Access Points placement: ceiling mounting and wall mounting. Each method has pros and cons, and in some cases, one may not even be feasible depending on the environment.

Ceiling mount

Ceiling placement is often the ideal choice for warehouse environments, offering several advantages:

  • Better Coverage: Ensures more uniform coverage along the floor, reducing RF propagation, especially in the 2.4 GHz range.
  • Less Interference: Minimizes signal obstruction from moving equipment or products.
  • Staggered Placement Flexibility: Works well with staggered AP placement, where adjacent aisles benefit from coverage despite no AP being directly overhead.
  • Ideal for Large Spaces: Ceiling mounts are more adaptable for large warehouses, providing broader coverage and easier access for maintenance.

Ceiling mount pattern

5 GHz band coverage of ceiling mounted omnidirectional APs (AP-565) at 10 m (32 ft) above ground level.

To understand the color-to-coverage mapping, refer to Visualization settings and heatmap.

Wall mount

While wall mounting is often a secondary option, this method can still be effective in certain situations, such as when ceiling placement isn’t possible. However, wall mounting comes with some limitations:

  • Focused Coverage: Typically targets coverage down a single aisle, but may struggle to provide consistent coverage across the warehouse.

  • Potential Interference: Walls can block RF signals, and moving equipment (like pallets) might cause signal shadowing, roaming issues or RF pollution across aisles.

  • Use Case: Best suited when ceiling mounting isn’t an option, or when aisle-specific coverage is needed.

Wall Mount Pattern

5 GHz band coverage of wall mounted directional APs (AP-567) at 10 m (32 ft) above ground level.

Staggered placement

Whether using ceiling or wall mounts, staggering APs (placing APs in alternating aisles) helps improve coverage. For ceiling-mounted APs, staggered placement ensures that every other aisle gets signal from adjacent APs. In wall-mounted setups, APs on opposite walls cover alternating aisles for the same effect.

Signal Spread: 3 AP case study

When comparing the signal propagation of wall-mounted versus ceiling-mounted 3 APs, note that the wall-mounted AP shows significantly more signal bleed along the walls compared to the ceiling-mounted AP.

2.4 GHz and 5 GHz bands coverage of wall mounted three directional APs (AP-567) in the center.

5 GHz coverage of wall mounted three directional APs (AP-567) in the center.

5 GHz coverage of ceiling mounted three omnidirectional APs (AP-565) in the center.

AP height and rack spacing considerations

AP height: AP height is a critical aspect when APs are ceiling mounted. The first consideration regarding AP height is that as mounting height increases, path loss also increases. This effect depends on both the AP model and the antenna pattern. With omnidirectional antennas, for example, the signal-to-noise ratio (SNR) typically decreases directly beneath the AP as height increases.

Example: AP is positioned closer to the floor, resulting in a stronger signal directly beneath the AP.

Rack spacing: The space between the AP and the top of the rack plays a crucial role in determining the path loss geometry through the rack. Generally, increasing this gap allows the RF signal to better propagate into adjacent aisles. However, if the height becomes too great, directional antennas may be necessary to maintain optimal coverage.

Access point mounted lower above ground level and closer to the top of rack.

AP is mounted higher, leading to a lower SNR at ground level.

Access point mounted higher above ground level and higher above the top of rack

This reduction in signal strength can lead to coverage gaps and roaming issues for client devices.

5 GHz band coverage of omnidirectional APs at 10 m (32 ft) above ground level with -45 dBm signal.

5 GHz band coverage of omnidirectional APs at 25 m (82 ft) above ground level with -58 dBm signal.

The heatmap clearly shows a noticeable drop in overall SNR. This decrease is primarily due to the omnidirectional APs focusing their RF signal more horizontally, rather than directing the signal downward toward the client devices.

Directional vs omnidirectional APs

For ceilings over 15 meters (50 ft), using APs with directional antennas helps direct most of the RF energy downward, improving SNR for clients. This setup ensures that clients maintain a strong connection and are less likely to reach their roam thresholds prematurely, only triggering roaming when necessary.

5 GHz band coverage of omnidirectional APs at 25 m (82 ft) above ground level with -58 dBm signal.

5 GHz band coverage of directional APs at 25 m (82 ft) above ground level with -47 dBm signal.

RF path loss and attenuation

In warehouse environments, RF path loss and attenuation are significantly influenced by shelving and racking structures. Metal racks and densely packed inventory can cause substantial signal degradation, with attenuation levels varying based on materials and stocking density.

Shelving impact

The biggest challenge in warehouse RF planning is the shelving, as shelving acts as a significant barrier to RF propagation. Shelving units can attenuate signals to varying degrees from one aisle to the next, creating coverage gaps.

When planning AP placement, consider the height of the racks in relation to the ceiling and the AP position. This is crucial for understanding how RF will propagate over and between the shelves into the aisles.

RF signals from an AP positioned directly above an aisle will cover that aisle effectively. However, adjacent aisles will experience attenuation as the signal travels through the racks and materials. The more material stored and the larger the rack configuration, the greater the RF loss.

The level of attenuation is determined by the materials stored and the specific layout of the racks. Additionally, increasing the spacing between APs across aisles can lead to RF gaps, reducing coverage in the areas between the racks.

Shelving & RF Path Loss

Impact of rack RF attenuation

When designing with the assumption that enough RF can pass through each shelf, and opting to skip every other aisle, the 3-dimensional nature of path loss through the shelving can result in significant coverage gaps. Additionally, this design lacks redundancy, meaning there’s no backup coverage if an AP fails.

Example 1:

Rack RF attenuation at 2.5 dB/m. Omni-directional APs are mounted at every other aisle at 10 m (32 ft) above ground level, with shelves also at 10 m (32 ft) tall.

Some aisles have good coverage, while others experience poor but still sufficient coverage.

Rack RF attenuation at 5 dB/m. Omni-directional APs are mounted at every other aisle at 10 m (32 ft) above ground level, with shelves also at 10 m (32 ft) tall.

When shelves store materials that severely attenuate RF, coverage across more aisles becomes weaker.

Rack RF attenuation at 2.5 dB/m. Omni-directional APs are mounted at every other aisle at 10 m (32 ft) above ground level, with shelves also at 10 m (32 ft) tall. An AP failure in the middle results in coverage gaps.

When an AP fails, there’s no fallback coverage, leaving large gaps where signal strength is insufficient.

AP selection

Using outdoor APs

Warehouse environments often lack full environmental control, with extreme temperatures near the ceiling, potential leaks, precipitation, and the presence of animal and insect deposits. These conditions can be tough on standard APs, making outdoor-rated models a better option for many warehouse setups.

Outdoor APs are designed to withstand harsh conditions, with weatherproofing that allows the outdoor APs to survive wider temperature extremes—even in environments like refrigerators and freezers. Outdoor APs also feature more suitable antenna solutions and higher radio power levels, making the APs ideal for covering larger areas at the taller heights typically found in warehouses.

In addition, outdoor APs and their mounting solutions are built to be more rugged and can be staged, provisioned, and installed quickly and securely. Unlike indoor APs, outdoor APs don’t require costly enclosures or external antennas, which saves on both hardware and installation time. This results in less risk, easier long-term maintenance, and lower total cost of ownership.

Using indoor or connectorized APs

While using indoor APs may be necessary as a cost-saving measure, recognizing the limitations they impose is important. Indoor APs generally have lower transmit power, which can restrict coverage and effectiveness in larger or more complex environments like warehouses.

Indoor APs should be considered only when coverage requirements are met and the warehouse has consistent temperature conditions.

APs that utilize external antennas aka connectorized APs, which allow for the use of external antennas, can help mitigate some of the coverage issues by better shaping the RF signal. However, this approach comes with additional challenges. The extra hardware costs for the external antennas, the labor required to install and configure the antennas, and the risk of cabling issues can make connectorized indoor APs not only more expensive but also less effective overall.

Older guidelines often suggested that the link budget between an AP and client should be balanced by setting the AP power level close to that of the client. However, with modern MIMO (Multiple Input Multiple Output) APs, as well as technologies like TxBF (Transmit Beamforming) and MRC (Maximal Ratio Combining), this approach is no longer as critical.

Even when the AP operates at or near maximum transmit power, the link budget remains sufficient to maintain a reliable connection with the client. These advanced technologies allow for more efficient use of the available RF power, ensuring that signal quality is preserved across the link.

As a result, there is often no need to significantly reduce AP power in most cases. In fact, maintaining higher AP power can help ensure better coverage, especially in larger or more complex environments, without negatively affecting the overall link budget.

AP power comparison

Design & deployment process

The warehouse deployment process can be broken down into three distinct phases. To ensure a consistent and successful deployment follow the process:

Phase 1: Predictive site survey

The first phase involves gathering data to create a predictive model for the wireless network design.

  • Obtain scaled drawings: Acquire scaled drawings (preferably PDFs) of areas to be covered, including racking layout, walls, ceiling height, and rack height/depth in each area.
  • Review existing wireless Deployment: Obtain layout of current wireless deployment: AP models, antenna types, placement, installation heights, Intermediate Distribution Frame (IDF), current configuration (power, channel plans, bands).
  • Gather Information on Planned Client Devices: Collect details on client devices and use cases (e.g., handheld scanners, VoWiFi phones, laptops), including device type, band capability, model, and firmware level.
  • Teleconference with Stakeholders: Review gathered information, address coverage issues or functional concerns with the current deployment, discuss warehouse use (e.g., types of goods stored) and seasonal operational variations.
  • Create a model of existing coverage:
    • Use a modeling tool like Ekahau, hamina, etc to create a model of existing coverage based on current AP models and antenna types.
  • General criteria summary:
    • Primary AP Coverage: -65 dBm (or -60 dBm for voice).
    • Secondary AP Coverage: -72 dBm (failover).
    • Assume closed doors and solid walls based on construction type.
  • Attenuation areas for racking:
    • Dry goods/unknown: 3 dB/m.
    • Liquids: 10 dB/m.
  • Create a model of proposed coverage: Place APs based on existing locations, adjust positions or add new ones to meet best practices for coverage.
  • Stakeholder review: Hold another meeting to review the existing and proposed predictive models, address areas to evaluate in Phase 2 (Physical Site Survey).

Phase 2: Physical site survey

This phase validates Phase 1 information and allows for adjustments based on real-world conditions.

  • Site walkthrough:
    • Walk the warehouse to verify data from Phase 1, using laser tools to confirm dimensions.
    • Verify racking layout, aisle lengths, widths, racking heights, depths, ceiling height, AP installation heights.
    • Confirm compatibility of proposed AP locations with warehouse layout and confirm IDF locations.
    • Ensure all existing APs are active and functioning.
  • Photographic documentation:
    • Take photos of representative AP installation types and proposed locations.
  • Passive survey:
    • Use a modeling tool to conduct a passive survey of existing coverage by walking all aisles and collecting data.
  • AP on a stick survey:
    • Mount an Aruba AP as representative of future installation and perform a passive survey using a test SSID.
    • Purpose: gather data to demonstrate improvements in coverage compared to the existing design.

Phase 3: Design of record

This final phase compiles all data into a comprehensive plan for installation.

  • Document the design:
    • Title the document and include site information (name, address, contact details).
  • Review of existing deployment:
    • Include a layout of each floor showing AP locations and IDFs (no heatmap required).
    • Provide predictive coverage of the existing layout at -65 dBm (primary coverage) and -72 dBm (secondary coverage).
    • If applicable, include measured survey data from site walk.
  • Review site walk data:
    • Include additional data gathered during the physical survey and review discrepancies or changes.
  • Review of proposed deployment:
    • Provide layout of each floor with proposed AP locations and IDFs (no heatmap required).
    • Show predictive coverage at -65 dBm (primary coverage) and -72 dBm (secondary coverage).
    • Review measurements taken during the physical survey with proposed APs.
  • Final summary:
    • Summarize the design, highlighting key decisions and elements from the process.

By following this structured approach across all three phases, the wireless network deployment is thoroughly planned, validated, and documented, ensuring a successful installation in the warehouse environment.

Visualization settings and heatmap

The thresholds of the signal can be selected in coverage visualization tools like Ekahau or Hamina. These colors on the floor plan represent adequate coverage for a client. Below are the settings used to create the images in this document.

Red: -64 dB coverage threshold

Green: -53 dB

Grey: -67 dB to -70 dB

The EIRP set for 5 GHz band radio is set to 200 mW.

Ekahau coverage setting

Best Practices

  • AP selection and mounting

    • Use outdoor omnidirectional APs and directional APs with industrial AP mounts for easy installation, enhanced security, and simplified setup.
    • Ceiling height considerations
      • Use outdoor omnidirectional for warehouses with ceiling heights of 10-15 meters (45-50 ft) and under.
      • Use outdoor directional APs for warehouses with ceiling heights above 15 meters (50 ft).
  • AP placement and coverage

    • Place at least one AP per aisle. Depending on aisle length, more than one AP may be required.
    • Ensure APs are spaced according to design guidelines.
    • Maximize separation
      • Position APs to maximize the distance from the top of warehouse racks to optimize signal and reduce interference.
    • Ceiling-based coverage
      • Create cellularized coverage from the ceilings for optimal RF performance.
      • Minimize wall mounting of APs unless necessary to avoid unwanted RF propagation throughout the warehouse.
  • Design guidelines for AP spacing

    • For outdoor omnidirectional APs:
      • Maintain a spacing of 50-65 meters (150 - 200 ft) between APs along the same aisle or perimeter.
    • For outdoor directional APs:
      • For ceiling heights of up to 10-15 meters (45-50 ft), maintain spacing of 40-50 meters (130 - 160 ft) between APs.
      • For ceiling heights above 15 meters (50 ft), increase spacing to 50-65 meters (150 - 200 ft) between APs.

These guidelines ensure optimal coverage, performance, and scalability for warehouse networks.

AP selection recommendation

When designing a wireless network for a warehouse, approaching AP placement with the unique requirements of different areas in mind is essential, as each zone may have specific AP types and coverage objectives. Below is a general approach to AP placement:

  • High racking zones

    • AP model selection: Use outdoor omnidirectional APs for racking heights up to 10-15 meters (45-50 ft). Use outdoor directional APs for racking heights greater than 15 meters (50 ft).
    • Placement strategy: Place APs in a staggered pattern and close to the ceiling, ideally positioned in every aisle or every other aisle, depending on the types of goods stored and the required coverage. Adjust spacing as needed, ensuring proper coverage for the different rack heights and aisle lengths.
  • Perimeter and load/unload areas AP placement: Install an AP approximately every 50 meters (150 ft) along the perimeter, focusing on areas with load in/load out activity, where movement is frequent. Strategically place APs on aisles that are empty or position the APs at the far end of busy aisles to optimize coverage and minimize interference.

  • Open areas

    • AP model selection: Use outdoor omnidirectional APs for ceiling heights up to 10-15 meters (45-50 ft). Use outdoor directional APs for ceiling heights greater than 15 meters (50 ft).
    • Placement strategy: Install APs on a grid pattern, with spacing of approximately 50-65 meters (150-200 ft). This ensures broad coverage and reduces the risk of coverage gaps in larger, open spaces.
  • Outdoor AP placement

    • AP model selection: Use outdoor directional APs for outdoor areas.
    • Placement strategy: Wall-mount the APs, ensuring APs are oriented outward, away from the building to cover the surrounding perimeter. Space APs along the outer walls, placing the APs approximately every 50 meters (150 ft) in a linear arrangement to ensure consistent outdoor coverage.
  • Office area AP placement AP model selection: Typically, use indoor omnidirectional APs for office areas, depending on the required coverage and density.

By organizing the AP placement strategy by zone type and considering the specific needs of each area, this approach ensures comprehensive and efficient coverage throughout the warehouse. Always adjust placement based on site specifics, including racking height, aisle width, and warehouse layout.

1.2 - Large public venue

Information and guidance for wireless architects wanting to deploy high-density Wi-Fi in Large Public Venues.

Drawing from over 15 years of Wi-Fi industry experience, leadership, and real-world deployment, the Wi-Fi design guide for large public venues provides data-driven guidance for those looking to deploy Wi-Fi in a large public venue (LPV). These design insights come from deployments across universities, stadiums, arenas, and experiences running conferences such as HPE Discover, Atmosphere, and more.

The purpose of this guide is to assist those interested in LPV with the process of understanding the scope and magnitude of planning which goes into LPV design. This guidance, paired with the online LPV rough order of magnitude (ROM) calculator, provides an initial assessment of the hardware and software required for an LPV project. The guidance provided herein should serve as a starting point, allowing for the establishment of baseline requirement gathering and guiding the reader on how to have meaningful discussions about the specific deployment needs for an LPV installation.

For complex scenarios or corner cases that fall outside these baseline guidelines or are not covered in this guide, please contact your account team for customized recommendations.

1.2.1 - Network design fundamentals and criteria for large public venues

Essential design criteria and planning considerations for wireless architects deploying Wi-Fi networks in stadiums, arenas, convention centers, and other high-capacity venues. Covers seating capacity analysis, device take rates, coverage strategies, access point placement, and throughput requirements for optimal network performance.

This topic presumes the reader possesses an advanced knowledge level of Wi-Fi deployments and RF design. This guide aims to bring the most relevant design considerations and factors relevant to high-density and large public venues, either indoors or outdoors.

Some of the common, high-density design criteria for a wireless network design can be broken down into the metrics mentioned here. Designing a high-density wireless network must consider critical environmental and technical factors beyond just the seating capacity of the venue and an estimation of how many devices will need Wi-Fi connectivity.

Metric Definition Typical Value
Seating capacity Number of people the facility can hold. Varies
Take rate Percentage of seating capacity with an active Wi-Fi device. 20% - 100%
Seats or area covered per AP How many square meters (or square feet) or seats each AP must serve – essentially the effective size of a radio cell. Varies
Associated devices per radio The design target of how many associated devices should be served by each radio on an AP. Varies
AOS version How the venue size or high-density areas can determine what version of AOS should be recommended. Varies
Radio type Depending on the region where the venue is located can determine which radio(s) and frequency band(s) will be used. Varies
Gateways What determines whether gateways should be used. Varies
Access points and antennas Which access points (APs) and antennas should be used at the venue. Varies
Coverage strategy Multiple coverage strategies exist and in certain LPV environments multiple strategies must be used. How to determine whether to use underseat or overhead coverage. Varies:
  • Overhead
  • Underseat
  • Mixed
Expected throughput How to calculate a per device expected throughput and the total system throughput of the Wi-Fi deployment. 1 - 4 Mbps
Venue Type of venue, roof, areas Varies

The first couple of metrics are self explanatory and help the network planner achieve a rough estimate of AP count, but that does not provide the complete design or answer for all of the considerations that must be weighed for an LPV deployment.

There are several assumptions this guide and the online calculator make which might not align perfectly to the project you are pursuing. Based on the previously mentioned considerations, the following assumptions are listed:

Seating capacity

  • HPE Aruba Networking recommends any venue with less than 10,000 users use an overhead mounting scheme.

  • Venues large enough for more than 10,000 users may have a mixture of overhead and underseat access points. The LPV rough order of magnitude calculator will allow an engineer to choose between the two methodologies.

Take rate

  • Due to the ubiquitous nature of Wi-Fi and smart devices, today’s take rate (total number of unique users) may range from 20% and 100% depending on the venue type and network usage expected.

  • Remember that network utilization will grow over time and best to scope a venue based on the customer’s expected growth of function, utilization and ultimately usage 2-3 years into the future. Far better to err on the side of extra capacity than less.

Seats or areas covered per AP

  • Based on experience, HPE Aruba Networking assumes that with an overhead mounting deployment in a large public venue, each AP radio will service up to 200 clients.

  • If underseat AP placement is used, HPE Aruba Networking assumes 60 clients per radio for under seat AP placements.

  • The online LPV ROM calculator uses these values as the default. The tool allows these variables to be changed based on the actual venue’s requirements.

Associated devices per radio

Determining the optimal number of devices per radio is crucial for maintaining network performance in high-density environments. While access points have maximum association limits, effective design requires operating well below these thresholds.

  • Underseat placement - design for the actual seat count covered by each AP.
  • Overhead placement - design for ~150 devices per radio based on expected take rate.

Understanding these design parameters allows you to calculate realistic association expectations and properly size the network infrastructure for sustained performance under actual operating conditions.

Underseat placement

For underseat placement, design for 100% take rate of the seats covered by each AP radio. The number of expected clients per radio should match the seat count per AP. For example, if the design covers 60 seats per AP, plan for 60 clients per AP radio.

Overhead placement

Overhead mounted access points typically cover larger areas than underseat deployments. Each overhead AP generally serves 150-200 seats, but client associations are calculated based on expected take rate rather than the total seat count the AP covers. The actual number of connected devices will depend on venue type and user behavior patterns, where ~150 active associations per radio is a starting point in the design.

Radio type

  • Due to current bifurcation of 6 GHz regulatory adoption at the time of writing between 500 MHz or 1200 MHz decisions, 6 GHz radio usage in LPV will only be applied to countries with 1200 MHz of unlicensed frequency for 6 GHz use.

  • All other regions will default to 5 GHz radio usage for LPV.

Gateways

Several factors will dictate whether gateways will be used or not. The key deciding factors for gateways/controllers are:

  • Any solution designed with an AOS-8 architecture.

  • Any solution involving Dynamic Segmentation.

  • In the case of an AOS-10 based network architecture, any solution with more than 500 Access Points or more than 5000 clients, whichever comes first.

To simplify design decisions and maximize the performance, HPE Aruba Networking recommends the 9240 Gateway model be used. This provides HPE Aruba Networking’s most powerful hardware gateway and can provide throughput and connectivity options that any large venue may require.

Gateways can be clustered together to provide additional capacity and redundancy. Cluster sizes can vary from a 6-node cluster with AOS-10 or clusters with up to 12 nodes when utilizing AOS-8.

This scaling is very important and can be further simplified by stating that at least one pair of HPE Aruba Networking 9240 gateways be used per 32,000 devices.

As a best practice, network capacity should be engineered to 80% of maximum limits to provide adequate headroom for traffic spikes, device growth, and optimal performance under real-world conditions.

Refer to the Validated Solution Guide (VSG) capacity planning for sizing and planning of gateways at scale.

Access points and antennas

Based on HPE Aruba Networking’s experience in real-world, large public venues hosting thousands of concurrent users, this guide and the online LPV ROM calculator tool default to a number of Access Points from the AP-5xx/AP-6xx/AP-7xx series, based on venue location and area being served.

As previously stated, based on 6 GHz adoption, all US Deployments will default to 6 GHz capable access points. Because of the nature of 6 GHz this eliminates having to worry about backwards compatibility or legacy devices, further simplifying design considerations.

HPE Aruba Networking recommends using directional antennas where possible, to focus coverage on high-density areas, to improve signal quality and reduce interference.

United States deployments

  • If indoors, with underseat placement, AP-6xx series Access Points will be used in conjunction with external antennas, specifically AP-ANT-312 antennas.

  • If indoors, mounted overhead, the AP-679 model will be used with integrated antennas allowing for both narrow and wide antenna patterns.

  • If outdoors, with underseat placement, the AP-654 with AP-ANT-312 external antennas will be used.

  • If outdoors, mounted overhead, then AP-679 with integrated directional antennas will be used.

  • Suites and concession stands typically require an AP per location, the AP-635 will be the default selection for these types of areas. These are presumed to provide either overhead or side coverage.

  • Gates in to and out of the venue are often high-density locations in and of themselves. In these cases, an overhead mounted AP-677 will be suggested by default.

For all other Rest of World Deployments, 5 GHz radios will be used by default due to current adoption and ratification rates for 6 GHz usage. As adoption and ratification increases, the calculator can be modified to reflect these new opportunities to deploy in 6 GHz.

Rest of world deployments

  • Indoor, underseat, external antennas, AP-5xx series with AP-ANT-312.

  • Indoor, overhead, external antennas, AP-574 with AP-ANT-5314.

  • Outdoor, underseat, external antennas, AP-518 with AP-ANT-312.

  • Outdoor, overhead, external antennas, AP-574 with AP-ANT-5314.

  • Suites and concession stands require an AP per location, an AP-5xx series access point will be the default selection for these types of areas. These are presumed to provide either overhead or side coverage.

  • Gates in to and out of the venue are often high-density locations in and of themselves. In these cases, an overhead mounted AP-577 will be suggested by default.

Use of AP-6xx series access points and 6 GHz frequencies in rest of the world deployments must follow the target country’s respective 6 GHz outdoor regulations.

Type of venue

Another key consideration will be the type of venue. Based on the venue, areas, expected traffic flow, capacity, and expected usage.

Common venues

Common examples of high-density, large public venues include the following:

  • Large meeting rooms

  • Lecture halls and auditoriums

  • Convention center meeting halls

  • Hotel ballrooms

  • Stadiums, arenas, and ballparks

  • Concert halls and amphitheaters

  • Casinos

  • Airport concourses

  • Passenger aircraft and cruise ships

  • Places of worship

  • Financial trading floors

Each example includes some common design criteria as well as unique challenges and considerations.

  • Venue layout - document the physical and architectural characteristics of the venue, which can impact signal propagation.

  • User density and distribution - understand how users are distributed across the venue, as density impacts interference and capacity needs. What is the anticipated user flow through the venue? Certain areas may need more or less coverage and capacity depending on how users are expected to flow through the area.

  • Assess network infrastructure - routing/switching architecture, system services, for example the venue’s internet connection, MAC/ARP limitations, DHCP/DNS performance, etc.

  • Real-world factors - adjust for real-world factors such as signal quality, interference, and user movement. Typically, real-world throughput is about 50-70% of theoretical maximums. Also consider protocol overheads from operations like MAC layer acknowledgments and beacon transmissions.

  • Environmental overheads - account for additional environmental factors like RF noise and non-Wi-Fi interference that may impact performance.

  • High-density areas should never be designed for peak single-client burst rate. VHD areas are designed to provide a low, common throughput like 1 Mbps or 4 Mbps to all clients. While occasionally possible to hit the peak if the network is not busy, the baseline assumption for any high-density network is that the channel is very congested and average device throughput is much lower than the peak rate.

  • Use 20 MHz channel widths as the baseline configuration. 40 MHz channels should only be considered in certain advanced situations which are out of scope for this page. This narrower channel width brings down the peak data rate dramatically (from 780 Mbps to just 86.7 Mbps for a typical 1SS 802.11ac smartphone).

  • Most client devices are only 1 SS or 2 SS capable, and many will operate at 1 SS when the battery is low to conserve battery life. This is expected across modern devices due to physical size and battery power constraints.

Venues with a movable roof

While stadiums with roofs that open and close can introduce some complexities, a robust and flexible Wi-Fi solution that maximizes the 6 GHz band advantages can still be achieved by factoring in a few key considerations:

  • Position APs and antennas strategically to account for the changing environment when the roof opens or closes. Consider that the roof position will affect signal propagation and reflection.

  • Understand that opening the roof changes the RF environment significantly. Have strategies in place to deal with signal diffraction and attenuations when the roof is closed.

  • Evaluate how different roofing materials, both in open and closed positions, impact RF signals. Metal or concrete structures could reflect or absorb 6 GHz signals.

  • Implement infrastructure that can withstand any vibrations or movements caused by the mechanism opening and closing the roof.

  • Apply dynamic frequency selection to adapt to potential changes in interference patterns caused by the transient nature of the stadium’s roof.

  • Design network plans that minimize interference from other sources, including cellular networks or microwave links.

  • Plan for seamless handover and transition between APs as users move into areas with differing roof statuses (open vs. closed), ensuring consistent high-quality connectivity.

  • Utilize wider channel availability in 6 GHz to support more users and high-bandwidth applications.

1.2.2 - Radio frequency planning and channel optimization

RF design guidelines covering frequency band selection (2.4 GHz, 5 GHz, 6 GHz), channel width optimization, interference mitigation, and coverage strategies. Includes detailed analysis of overhead versus underseat access point placement, channel planning methodologies, and channel reuse techniques for maximum capacity.

The frequency band utilized will directly affect the total system throughput (TST) based on the number of available channels in each country based on that country’s regulatory adoption of the band.

While the 2.4 GHz band has been approved for use in most countries, the number of non-overlapping channels in this band makes 2.4 GHz unusable for LPV deployments. 2.4 GHz is not taken into consideration for any LPV planning.

Most HPE Aruba Networking access points include a 2.4 GHz radio but this radio is recommended to be disabled for client usage in large public venue deployments due to insufficient non-overlapping channels for high-density environments. While the 2.4 GHz band may optionally be repurposed for specialized applications like IoT devices or handheld scanners in targeted areas, 2.4 GHz should remain disabled for general client access. Legacy 2.4 GHz-only clients should be decommissioned in favor of 5 GHz-capable devices.

Customers should look to leverage both the 5 GHz and 6 GHz bands to increase capacity. The 5 GHz band offers more non-overlapping channels than 2.4 GHz, and 6 GHz provides even more, reducing interference and allowing more simultaneous connections.

Today’s current state of technology is based on Wi-Fi 7. The latest 802.11be standard builds upon the previous standard of 802.11ax and can operate across the 2.4 GHz, 5 GHz, and 6 GHz frequency bands.

Using 5 GHz

Available since the release of 802.11a in 1999, 5 GHz became widely adopted around the world. This band can now provide up to 28 non-overlapping 20 MHz wide channels, when including U-NII-4.

Using 6 GHz

6 GHz capable access points provide significantly increased capacity and with the 6 GHz band can handle more devices simultaneously without sacrificing performance, making them perfect for very high-density environments like conference centers, stadiums, and other public venues.

Wi-Fi 6, Wi-Fi 6E, or Wi-Fi 7 access points benefit from higher data rates, improved efficiency, and reduced latency. Wi-Fi 6E extends these benefits into the 6 GHz spectrum, offering more channels and less congestion. Wi-Fi 7 can also leverage 6 GHz.

Previously unused, the 6 GHz frequency range offers a vast amount of clean, uncongested spectrum. This means more bandwidth, less interference, and lower latency leading to significantly faster speeds and more reliable connections.

6 GHz offers wider channels, up to 320 MHz are possible and can deliver multi-gigabit speeds in a single collision domain with no overlap from other Basic Service Sets. In the LPV setting, there will be many Basic Service Sets using the same collision domain preventing scaling out and deploying wider channel widths.

This means optimizing Wi-Fi performance for tens of thousands of users in a large public venue requires careful balancing of throughput, capacity, and interference when selecting channel widths from 20 MHz to 320 MHz.

Channel width

5 GHz

Channels can be bonded together to increase the channel bandwidth, but historically any LPV deployment should use 20 MHz channels. This includes any deployment with more than 14 access points in a single area. The primary goal is to provide clients with separate collision domains to improve performance and user experience in the LPV setting.

6 GHz

Channel width selection depends on multiple deployment specific factors requiring careful evaluation at each implementation. Use appropriate channel widths (20, 40, 80, 160 or 320 MHz) based on the specific use case, AP density, regulatory constraints, and available spectrum of the environment to balance increased throughput with potential interference.

Careful consideration of the expected use of the network will help influence this design decision. Some main points to consider are listed below.

Utilizing narrower channels can minimize interference from overlapping channels, thus enhancing overall network stability and performance. While having more channels helps with capacity, each individual channel provides lower throughput compared to wider options, which might not be ideal for high-bandwidth applications.

In general, bonded channels should not be used in high-density areas such as large public venues.

Take for example a large public venue with over 50,000 visitors, 20 MHz non-overlapping channels at 6 GHz are significantly better than 80 MHz bonded channels because.

  • Capacity and density - the primary challenge in such a dense environment is user density, not necessarily raw speed for individual users. 20 MHz channels allow you to serve many more concurrent users. Think of this like lanes on a highway. More, narrower lanes (20 MHz) allow more cars (users) to travel simultaneously than fewer, wider lanes (80 MHz), even if the wider lanes technically allow for faster speeds. With 50,000+ users, maximizing the number of simultaneous connections is crucial.

  • Interference mitigation - in a crowded 6 GHz spectrum, interference is a significant concern. 20 MHz channels are less susceptible to interference than 80 MHz channels. A narrower channel is less likely to be impacted by adjacent channel interference or other radio frequency noise. With 80 MHz channels, a single interfering signal can disrupt a much larger chunk of the spectrum, impacting more users.

  • Reduced channel contention - with more, narrower channels, the likelihood of channel contention (multiple devices trying to use the same channel simultaneously) is reduced. This translates to a smoother, more reliable experience for users.

  • Simplified network management - managing a network with numerous 20 MHz channels is generally easier than managing a smaller number of wider channels, especially in a dense environment. It provides more granular control and flexibility for network optimization.

  • Lower latency - while 80 MHz could offer lower latency under ideal conditions, in a real-world, high-density scenario, the increased contention and interference are likely to result in higher latency for many users. 20 MHz channels, while not as fast individually, would likely provide a more consistent and lower latency experience for the majority of users due to less congestion.

40 MHz channels represent a middle ground between 20 MHz and 80 MHz, and while they might seem like a compromise, they are still less suitable than 20 MHz channels for a large public venue with 50,000+ simultaneous users.

Consider the following:

  • Capacity still a concern - while using 40 MHz channels offers more capacity than 80 MHz, they still provide less capacity than 20 MHz channels. In a venue with such a high user density, maximizing the number of concurrent connections remains the top priority. 40 MHz channels simply don’t offer enough “lanes” on the Wi-Fi highway to handle that many users efficiently.

  • Increased interference risk - 40 MHz channels are still more susceptible to interference than 20 MHz channels. In a crowded 6 GHz spectrum, this increased risk can lead to performance degradation and dropped connections for a significant number of users.

  • Device compatibility - while more 6 GHz devices will likely support 40 MHz than 80 MHz, there might still be some devices that only support 20 MHz. Sticking with 20 MHz ensures the widest possible compatibility and allows the maximum number of users to connect.

  • Diminishing returns - while 40 MHz offers a theoretical speed increase over 20 MHz, the real-world benefit in a dense environment is likely to be minimal. The increased contention and interference will likely negate any potential speed gains, and may even result in lower overall performance for many users.

  • Network management complexity - managing a network with a mix of 20 MHz and 40 MHz channels can add complexity to network planning and optimization, especially in a large venue. Sticking with a consistent channel width (20 MHz) simplifies management and allows for more predictable performance.

Additional considerations:

  • Increased reuse distance - Using 80 MHz or 40 MHz channels reduces the number of radio channels by bonding them together.

  • Thermal noise floor increases by 3 dB with each doubling of channel width. This means higher SINRs - 20 MHz channels experience up to 6 dB more SINR than 80 MHz channels for the same data rate, and up to 3 dB more SINR than 40 MHz channels.

  • Higher performance - distributing 25 users each across four different 20 MHz channels delivers better results than placing 100 users on a single 80 MHz channel.

In a large public venue with 50,000+ users, prioritizing capacity and reliability over raw speed is paramount. 20 MHz channels offer the best balance of these factors, ensuring a usable and consistent Wi-Fi experience for the vast majority of visitors. While 80 MHz might seem attractive on paper, this approach is simply not practical or scalable for such a dense user base.

40 MHz channels might seem like a good compromise, they ultimately fall short of meeting the demands of such a large public venue with 50,000+ users. Again, the priority in such an environment is maximizing capacity and ensuring reliable connectivity for the majority of users. 20 MHz channels remain the most effective solution for achieving this goal.

Spatial efficiency is critical. When large numbers of users are present, optimizing channel utilization and providing the most dense coverage as possible, requires the solution architect to consider small channel sizes.

HPE Aruba Networking recommends not to use bonded channels in high-density areas unless the anticipated network and channel reuse dictates use.

Recommendations

Given the scenario of a large public venue with 50,000 users, choosing the correct channel width depends on usage patterns and network goals:

  • Opt for 40 MHz channels if the focus is on maximizing throughput for fewer but bandwidth-intensive applications. 40 MHz is ideal where high-speed internet access for streaming and media-rich applications is critical, and the network can be managed to limit interference. However, we cannot opt for 40 MHz because the capacity is too high for effective channel reuse at 40 MHz channel width. Careful consideration, at a smaller venue size than the scenario, could be performed to evaluate if 40 MHz channel width is feasible. Please contact your account team for a more in depth conversation about this topic.

  • Opt for 20 MHz channels since the aim is to maximize user capacity and ensure robust connectivity across a highly dense user base, reducing interference and improving overall user density management. This setup can better handle a large number of devices performing less data-intensive activities, like browsing and social media usage.

A hybrid approach may be most effective, dynamically adjusting channel width based on coverage area type, user distribution, usage patterns, and real-time network conditions. However, the network design must maintain consistent channel widths across the ESS. Inconsistent channel widths cause clients to prefer BSSes with wider channels over those with better signal quality, as channel width ranks higher in BSS selection criteria than signal strength.

Different areas of a large public venue cam vary greatly in the coverage and capacity required. Ticketing areas, gates, concessions, concourses and bowl areas all have different requirements. Advanced network management tools and careful planning can optimize channel utilization effectively in such a large venue.

Channel plans

All channel plans can be categorized according to three criteria.

  1. Dynamic vs. static

    • A dynamic channel plan is one that can change in response to external events, such as interference or system load.
    • In a static channel plan, the channel numbers are fixed and should not change.
  2. Global vs. local

    • A global channel plan uses the same channel list for all APs that terminate on the system.
    • A local channel plan uses different channel lists for different groups of APs on the same system.
  3. Repeating vs. non-repeating

    • A channel plan is repeating if the same channel number is used more than once in the same coverage area.
    • A channel plan is non-repeating if the same channel number cannot be reused in the same coverage area.

Most indoor WLANs are dynamic, global, and repeating.

Typical examples for high-density.

  • Global and non-repeating

    • University building with multiple adjacent lecture halls, with all channels available but no individual lecture hall can use the same channel more than once. Could be static or dynamic depending on exact configuration method used.
  • Local and repeating

    • Outdoor stadium with the bowl area using outdoor-only channels and the suites and concourses using indoor-only channels.

    • Large arena bowl area with fixed channel assignments that uses DFS channels for capacity, while only non-DFS channels are in use in other parts of the facility.

  • Static, local, non-repeating

    • A concert hall with two dedicated ticketing APs at entry gates on channels 36 and 149. Every gate features an identical setup.

    • Stadium press box with four dedicated APs that are hard-coded to channels that cannot be used in the bowl seating area.

    • A convention center with a “house” channel dedicated to presenters that exists on one AP in the front of every individual meeting room (and nowhere else).

  • Dynamic, global, non-repeating

    • A press area with six APs that can use any channel but no channel can be used more than once.

Coverage strategies

Additional assumptions will be made based on the coverage strategy used. As stated, this guide and the online LPV rough order of magnitude calculator tool only accounts for overhead or underseat deployments. However, due to the variations of large public venues, certain considerations must be made. Each area of the LPV must be assessed individually and only one coverage strategy per area is recommended.

There is adjacent channel interference (ACI) and co-channel interference (CCI) in virtually every high-density deployment. So long as minimum separation distances are observed, ACI can be safely ignored in most high-density areas of 10,000 seats or less.

Remember that AP to AP spacing when using directional antennas, the AP’s should be no closer than 2 meters or 6.5 feet. Access Points utilizing integrated antennas should be spaced never less than 5 meters or 16 feet apart.

Overhead coverage

APs are placed on a ceiling, catwalk, roof, or other mounting surface directly above the users to be served. Depending on the height difference, one can use APs with integrated antennas or connectorized APs with specially chosen external antennas. In either case, the direction of maximum gain is oriented downward. This must not exceed 30 meters (100 ft).

Side coverage

APs are mounted to walls, beams, columns, or other structural supports that exist in the space to be covered. Generally, APs are placed no more than 4 m (13 ft) above the heads of the crowd to be served. Either directional or downtilt, omnidirectional antennas can be used, with the direction of maximum gain aimed sideways with a shallow down-angle.

Floor coverage

This design creates picocells using APs mounted in, under, or just above the floor of the coverage area. This strategy is the only one that can allow for RF spatial reuse of channels inside a room of 1,000 $m^2$ (10,700 $ft^2$) or less. In general, picocells use APs with integrated antennas to minimize the required space under the seat.

Additional coverage considerations

  • Venue design - the physical layout and construction materials of the venue can influence which approach is more effective.

  • User density and behavior - high user density can favor underseat installations due to their ability to minimize interference, whereas overhead APs might be superior in less dense scenarios.

  • Cost and scalability - underseat solutions can be more costly due to the number of APs required and installation complexity but might provide superior service in capacity-demanding environments.

  • Temporary deployments - underseat placement can be used more readily in temporary coverage areas versus mounting Access Points overhead.

  • Future-proofing - overhead solutions might more easily accommodate the integration of future technology updates with less disruption.

In general, the decision between overhead and underseat APs should be tailored to the specific requirements and conditions of the venue. In many cases, a hybrid approach leveraging both methods in strategic locations can provide the most robust and comprehensive coverage, balancing coverage quality and capacity while considering installation and maintenance logistics.

Overhead coverage

  • Overhead coverage is a good choice when uniform signal is desired everywhere in the area.

  • APs with integrated antennas may be used when the area’s ceilings are less than 10 meters or 33 feet high. For open spaces with minimal signal attenuation, consider integrated directional antennas for better control of signal propagation.

  • If the ceilings are higher than 15 meters/50 feet use of external antennas should be used. If questions persist, consult with your account team for further consultation.

  • No RF spatial reuse is possible with overhead coverage because of the wide antenna pattern and multipath reflections.

  • In multi-floor venues, stagger the Access Points in each room underneath and do not place access points directly above one another.

  • Floors generally absorb more RF energy than walls (10-15 dB is a typical range).

Advantages:

  • Line-of-sight coverage - overhead mounting typically ensures better line-of-sight to users, reducing signal obstructions such as furniture or people.

  • Wider coverage area - generally provides a broader coverage area, making overhead coverage more effective for covering large open spaces.

  • Reduced physical interference - less likely to be blocked by objects or people, which can be particularly advantageous when utilizing higher frequency bands like 5 GHz and 6 GHz.

  • Reduced reflection - higher placement can help minimize signal reflection and refraction that are common when signals interact with fixtures, furniture, or people, which is a significant consideration at higher frequencies due to their limited penetration abilities.

  • Easier maintenance access - easier to access for maintenance and upgrades without interfering with seating or crowd movement.

Disadvantages:

  • Potential for higher contention - if not adequately planned, can lead to more overlapping coverage areas, which can increase contention and interference.

  • Installation complexity - may require complex installations in venues with high ceilings or other architectural constraints.

Side coverage

  • Wall, beam, and column installations with side-facing coverage are very common in high-density areas.

  • To reduce both Adjacent Channel Interference (ACI) as well as Co-Channel Interference (CCI), mount all the AP’s on one wall facing the same direction.

  • Signal bleed outside of the desired coverage area is wasted as compared to overhead coverage.

  • When mounting back-to-back, ensure proper channel separation to avoid interference. For access points configured with 20 MHz channel width, maintain a minimum of 40 MHz separation between radio channels. For example, use channels 36 and 44 rather than 36 and 36 or 36 and 40.

  • Signal levels will be lower in the center of the room than on the sides.

APs mounted on walls need to take into account other APs mounted on the other side of the wall.

Underseat coverage

  • Should be used high-density areas with more than 10,000 seats.

  • Underseat places APs create Picocells and that allows for a much higher radio density compared to overhead or side coverage schemes.

  • Picocell designs leverage the natural human body loss that occurs to RF signals as they pass through a crowd (also known as “crowd loss” or “crowd effect”).

  • Significant increases in total system throughput are possible because of increased RF spatial reuse.

  • Because higher AP densities can be achieved, cell sizes can be as small as between 60-75 seats. This guide and the online LPV rough order of magnitude calculator use a default of 60 seats for underseat designs.

  • APs should be evenly distributed and spaced to provide more uniform signal coverage in the area. Strive to make AP-to-AP distances as equal as possible.

  • Minimum AP-to-AP spacing should never be less than 2 m (6.5 ft) when using external directional antennas.

  • Minimum AP-to-AP spacing should never be less than 5 m (16 ft) when using integrated antennas.

Advantages:

  • Proximity to users - placement nearer to users can enhance the quality of the connection due to reduced signal path length and attenuation.

  • Reduced Co-Channel interference (CCI) - signal is more contained and less likely to interfere with surrounding cells, effectively compartmentalizing coverage.

  • Targeted coverage - ideal for environments where the seating arrangement is fixed and dense, allowing for precise coverage planning.

Disadvantages:

  • Physical obstructions - signals can be impeded by human bodies, furnishings, and other physical barriers, especially detrimental for higher frequency bands.

  • Maintenance Challenges - harder to access for repairs or upgrades, as these might disrupt seating arrangements or require special scheduling during unoccupied times.

  • Smaller cell size - each AP typically covers a smaller area, requiring careful planning to ensure comprehensive coverage without gaps.

1.2.3 - Bandwidth planning and capacity calculations

A performance planning methodology for calculating access point requirements, client capacity per radio, and total system throughput. Covered topics include bandwidth allocation formulas, real-world throughput expectations, and capacity planning considerations for supporting thousands of concurrent users in large venues.

One of the key success criteria of a high performance, Wi-Fi network is the expected system performance and amount of bandwidth available to users and applications.

Number of access points

Once considered, a simple formula can help you estimate the number of access points required for a high-density deployment:

$AP\ count = 5/6\ GHz\ radio\ count = \displaystyle\frac{Associated\ device\ capacity\ (5/6\ GHz)}{Max\ associations\ per\ radio}$

In this example, you can simply calculate how many radios of a certain type will be required. Max associations per radio as stated earlier calculated at 60 users per radio for underseat placement of the access point or if mounted overhead, one radio per 200 clients.

Number of clients per access point

Clients per access point are both a design decision as well as a hardware limitation. While the following values represent maximum client association counts for certain platforms, designs should target significantly lower client counts to ensure optimal performance and user experience. You must always check the product data sheet to verify what the maximum allowed associations is per radio.

  • AP-67x - max 512 associated client devices per radio (1024 total)

  • AP-654 - max 1024 associated client devices per radio (2048 total)

  • AP-518 - max 512 associated client devices per radio (1024 total)

  • AP-574 - max 512 associated client devices per radio (1024 total)

  • AP-635 - max 512 associated client devices per radio (1024 total)

The online LPV rough order of magnitude calculator by default calculates 60 client devices per radio when placed underseat and 200 client devices per radio when mounted overhead. These numbers can be tailored to the venue’s density requirements.

Bandwidth per client

Calculating the bandwidth per client is simply a matter of taking the channel’s available bandwidth and dividing by the anticipated number of clients per radio/channel.

This is not a perfect calculation and doesn’t take into account any of the real world conditions such as interference, congestion, distance, channel width, etc and one can easily take approximately 25% off that total because of lost airtime due to the nature of Wi-Fi communications. HPE Aruba Networks uses the term “Goodput” to define the actual amount of useable bandwidth minus the overhead, protocol limitations, and other factors like distance that can reduce the actual usable throughput.

Setting realistic expectations about Wi-Fi speeds is important - focus on whether the solution will provide a useable experience for the venue’s needs rather than theoretical numbers.

Associated device capacity

The associated device capacity (ADC) count and associated device per radio count are more important factors than bandwidth per client in designing a high-performance, high-density WLAN which meets the customers demands today and throughout the expected service life of the network. Depending on the type of venue, associated device capacity will vary. For example, a university lecture hall may have close to a 100% take rate versus a concert hall may have less than a 25% take rate.

This formula may provide a rough AP count, but will not guarantee a high-performance, high-density wireless LAN. This AP count still is not considering key performance metrics such as per-user bandwidth requirements or radio cell size. These two metrics can increase the number of access points truly required to deliver the correct design for the customer’s requirements.

In fact, high-density WLAN in large public venues must be designed with growth in mind. A high-density WLAN should be designed knowing that adoption increases over time and that the Associated Device Capacity number impacts much more than just the number of radios needed for a given band, but also all the upstream network infrastructure that will be required such as address space, ARP cache size, forwarding/bridge table size, DHCP lease binding database size, firewall sessions, public IP addresses for NAT/PAT, captive portal sessions, system licenses, HA dimensioning, and so on.

Other criteria such as the maximum associated devices on a particular radio can vary based on the model access point chosen.

Computing the total system throughput for a Wi-Fi network involves multiple considerations, including the Wi-Fi technology in use, the spectrum available, the environment, and user behavior. There are two main throughput numbers to be concerned with, Per AP Throughput and the Aggregate throughput across all APs.

To calculate a Per AP throughput, simply multiply the estimated per-client throughput by the number of supported users per AP. This can vary by AP Model and can be verified by checking the device’s datasheet.

Total system throughput

The basic mathematical formula to compute the aggregate throughput or the total system throughput is as follows:

$\displaystyle{Total\ system\ throughput\ (TST) = Channels \times Average\ channel\ throughput \times Reuse\ factor}$

Where:

  • Channels = Number of channels in use by the high-density network.

  • Average Channel Throughput = Weighted average goodput that is achievable in one channel by the expected mix of devices for that specific facility.

  • Reuse Factor = Number of RF spatial reuses possible. For all but the most exotic high-density networks, this is equal to 1, which means no RF spatial reuse.

  • Assume a 5 GHz deployment with 9 channels, an average channel throughput of 50 Mbps, and no RF spatial reuse, the TST would be 450 Mbps: $9\ Channels \times 50\ Mbps \times 1\ Reuse = 450\ Mbps$.

Additional channel throughput considerations

  • Channel throughput depends heavily on the number of stations that attempt to use the channel simultaneously.

  • Collisions and MAC-layer inefficiencies reduce overall capacity as more and more devices contend (compete) for medium access.

  • Single-client throughput represents peak goodput performance measured during a speed test on a clean channel without other users present.

  • Multi-client throughput is the weighted average goodput that is achievable in one channel by the expected mix of devices in a particular high-density area.

  • Channel throughput can be further reduced by many impairments including misbehaving client devices, CCI, ACI and non-Wi-Fi interference.

  • Real-world environments are rarely so pristine.

Another example calculation

Assume each access point can effectively deliver 100 Mbps of real-world throughput and support 50 users efficiently.

If 1,000 APs are deployed strategically throughout the venue:

  • Each AP can support 100 Mbps.

  • Total throughput for all APs is $1,000\ APs \times 100\ Mbps/AP = 100,000\ Mbps\ or\ 100\ Gbps$.

Then for each AP supporting 50 users:

  • User throughput equals $100\ Mbps \div 50\ users = 2\ Mbps/user$.

1.2.4 - Security practices and network protection for LPV

Security hardening recommendations for large public venue networks including network segmentation, access control configuration, infrastructure protection, and threat mitigation strategies. Addresses common vulnerabilities in high-density guest networks and provides specific configuration guidelines for secure deployments.

Large public venues which offer open guest networks in high-density areas are natural targets for casual and malevolent hackers. This list of network hardening options is considered a best practices and is recommended:

  • If possible, do not configure a Layer 3 interface on wireless user subnets (including secure subnets) unless a captive portal is being used and redirect is required. The gateway or controller should be Layer 2 only on all wireless subnets into which users can be placed.

  • Do not configure the gateway or controller to be the default gateway for any user subnet.

  • Place the DHCP server on a Layer 3 separated subnet and use DHCP relay.

  • Avoid configuring the gateway or controller as the DHCP relay for any user subnet.

  • Configure the validuser ACL to allow the configured and known user subnets, and disallow those IP addresses or IP address ranges that should be protected such as default gateways for each subnet, DNS, DHCP, captive portal, etc.

  • The guest role should explicitly disallow connection to network infrastructure elements via TCP ports 22 and 4343.

  • The guest role should explicitly disallow telnet, SSH, and other protocols that are not required for guest services.

  • Enable ARP spoof prevention on the default gateway for wireless user subnets and also on the controller if there is an L3 address on any wireless user VLANs.

  • Use a dedicated infrastructure subnet to connect all Wi-Fi gateways or controllers, APs, and servers.

  • Use ClearPass for administrator authentication using RADIUS and/or TACACS. Monitor the logs.

  • Use an IDS solution to monitor infrastructure and user subnets for suspicious activity.

  • Shutdown all unused Ethernet interfaces on the gateway/controller.

  • Monitor for rogue and potential rogue devices in Central and on the gateway or controller.

  • Enable “enforce-dhcp” in AAA profiles to prevent users from being able to assign static addresses and gain access to disallowed networks or spoof network resources.

1.2.5 - LPV calculator instructions

Instructions for using the interactive LPV design calculator. The calculator can be used to estimate equipment requirements, costs, and configurations for deploying LPV Wi-Fi networks. The calculator can also simplify complex design decisions by incorporating best practices, regional frequency regulations, coverage strategies, and capacity requirements into automated bill-of-materials generation.

Designed to assist with the effort for generating a rough order of magnitude (ROM) design, the LPV ROM calculator utilizes the assumptions in the previous pages along with the LPV team’s years of experience and best practices to generate a bill of materials that can be used for ROM purposes.

Getting started

The first question is the country where the LPV resides. This helps the calculator by determining the primary radio to be used at the venue. This will also help compute the venue’s total system throughput.

The ROM calculator takes all of the previous design criteria mentioned and default assumptions into consideration. As there are a variety of large public venues with various density requirements, the tool allows for key assumptions to be modified.

Basic starting information required for the calculator.

The country determines which frequency band to use. When the United States is chosen, the calculator will provide a solution set based on 6 GHz. If Rest of World is selected, the calculator will default to the 5 GHz band.

Coverage strategy

The key determining factor in coverage strategy to be used is the expected take rate of visitors and their devices. Venues with less than 10,000 seats are recommended to use an overhead coverage strategy. The reasons and concerns were specified previously.

Venues with more than 10,000 seats may incorporate a variety of coverage strategies depending on the number and types of areas the venue may contain. The calculator will allow modeling of both overhead and underseat coverage of an LPV and also a mixed environment in the case of a more complicated venue layout. Implementing an underseat coverage strategy, the LPV ROM calculator will initially target 60 seats per radio. Overhead coverage strategies assume a default of 200 seats to be covered per radio.

These default values and other calculator defaults can be changed under the Advanced Deployment Options.

Advanced options can be chosen to tune the calculator.

Here the number of clients/seats can be modified to reflect the number of seats to that will be planned for either overhead or underseat coverage.

Other advanced options include the maximum number of clients per controller or gateway, the maximum number of access points per switch, and switch capacity preference. Due to maximum Ethernet cable lengths most LPV environments will typically connect no more than 20 access points to a single switch. Also, depending on the expected usage of the area, more or less wired ports may need to be provided possibly for kiosks or other types of device access. To allow for further flexibility in the deployment the calculator allows for the selection between 24 and 48 port access switches.

The calculator will suggest either a 24 port or 48 port HPE Aruba Networking 6300M switch.

Additional coverage requirements

Large public venues often have areas which require different amounts of Wi-Fi network capacity and may require different coverage strategies to serve them. Examples of areas requiring special handling include:

  • Entrance gates, usually exhibit a predictable and very high flow of traffic as visitors enter and then traverse the venue.

  • Suites, common to sporting arenas and some other venues, require special handling as the suites could be reserved for corporate or private customers.

  • Press or broadcast booths, quite often require dedicated planning to handle the potential higher network usage from people in the area.

  • Concession areas which are often dispersed throughout large public venues. Typically found outside of the main event or bowl area of the venue and may require additional consideration.

Depending on the venue type, areas designated for purposes like event registration or event support could be calculated as a suite or gate with the online calculator.

To simplify design considerations, these areas default to a single AP per area. The calculator allows planning for a set number of each type of area, adding the additional access points to the estimate. If density requirements dictate more than a single AP in any one of the areas, make sure to adjust the number entered accordingly.

Setting the number of special coverage areas in the calculator.

All additional gate, suite, or concession areas, regardless of region, will default to either the AP-635 or AP-677.

Example output

Here is the calculator output from a large public venue modeled on the following criteria:

  • Country: United States
  • Coverage strategy: underseat & overhead
  • Underseat seating capacity: 50,000
  • Overhead capacity: 2,500
  • Number of gates: 8
  • Number of suites: 24
  • Number of concessions: 40

Example output from the LPV ROM Calculator.

The calculator provides a reasonable, rough order of magnitude of the size of this example LPV project and can provide sufficient information to answer some of the initial questions that may arise.

2 - Wi-Fi generations

Explore the key features and benefits of the latest generations of Wi-Fi technology, Wi-Fi 6, Wi-Fi 6E, and Wi-Fi 7.

The primary communication through Wi-Fi networks is between access points (APs) and clients (STAs) over unlicensed spectrum. At the core of Wi-Fi is a media access control (MAC) protocol called carrier sense multiple access with collision avoidance (CSMA/CA). This protocol allows APs and clients to listen, sense, backoff, and transmit one at a time like one would in a face to face conversation by performing clear channel assessments (CCA).

CSMA/CA enables back and forth communication using radio frequency signals to modulate and demodulate bits across the air. The reliability, efficiency, and performance of Wi-Fi based network communication is coupled to the efficacy of APs and clients contending and competing for access to the RF medium, one after another.

IEEE 802.11 and Wi-Fi generations

The Wi-Fi Alliance introduced a generation numbering scheme to simplify technology differentiation and improve user awareness of features across amendments to the IEEE 802.11 standard. This naming convention reduces the need to memorize the meanings of numerous amendments, instead using Wi-Fi followed by a generation identifier.

While the Wi-Fi generations correspond to amendments to the IEEE 802.11 standard, these two terms serve different purposes. The generation identifiers denote specific Wi-Fi Alliance certification programs, which include subsets of features defined in the corresponding IEEE 802.11 specification.

Wi-Fi generation IEEE amendment Significance Bands of operation Wi-Fi security
Wi-Fi 4 802.11n MIMO/MCS 2.4 GHz, 5 GHz WEP/TKIP prohibited
Wi-Fi 5 802.11ac MU-MIMO/Speed 5 GHz Open, WPA2
Wi-Fi 6 802.11ax OFDMA 2.4 GHz, 5 GHz Open, WPA2, OWE (opt.), WPA3 (opt.)
Wi-Fi 6E 802.11ax 6 GHz 6 GHz OWE, WPA3
Wi-Fi 7 802.11be MLO 2.4 GHz, 5 GHz, 6 GHz (opt.) Enhanced Open, WPA3, GCMP-256, Beacon Protection

These pages aim to provide insights and impact to proper design, deployment, and optimization for the latest generations of Wi-Fi.

2.1 - Wi-Fi 6

Overview of the IEEE 802.11ax standard, information on features and benefits of Wi-Fi 6, technical specification, and implementation guidelines.

Wi-Fi 6 (802.11ax) marks a fundamental shift in wireless networking design, prioritizing efficiency and scalability rather than solely increasing raw speed. Where previous standards focused on maximum data rates, Wi-Fi 6 implements sophisticated mechanisms that enhance performance in dense, multi-client environments.

Building upon the 802.11ac foundation, Wi-Fi 6 delivers several key technical advancements:

  • Enhanced modulation schemes with 1024-QAM, increase data rates by 25% in high SNR environments.
  • OFDMA technology enables concurrent multi-user transmissions for both downlink and uplink traffic.
  • Expanded MU-MIMO capabilities support up to 8 simultaneous users and adds support for UL MU-MIMO.
  • Advanced power-saving mechanisms including individual Target Wake Time (i-TWT) extend battery life substantially.

The 802.11ax amendment continues to improve sophistication of 802.11 modulation techniques.

These innovations address critical challenges in modern wireless networks: high client density, diverse application requirements from IoT to video streaming, and deterministic performance needs in mission-critical deployments.

Subsequent sections detail each feature’s technical specifications, implementation considerations, and performance benefits across various use cases.

Increased modulation complexity

Quadrature amplitutde modulation (QAM) encodes data by manipulating both the amplitude and phase of carrier waves. Each point in the QAM constellation represents a distinct symbol, with each symbol encoding multiple bits of information. Higher-order QAM schemes allow more bits to be encoded per symbol, increasing spectral efficiency.

Building on digital modulation schemes in 802.11ac of up to 256-QAM, 802.11ax supports up to 1024-QAM. This means that each RF symbol represents one of 1024 possible combinations of amplitude and phase as illustrated in figure below. The move from 256-QAM to 1024-QAM increases number of bits carried per OFDM symbol from 8 to 10. This can result in up to a 25% increase in PHY data rates and can be attained in clean environments with a high signal to noise ratio (SNR).

64-QAM

256-QAM

1024-QAM

The key determinants of PHY data rate are:

  • Channel width. Available channel widths are 20 MHz, 40 MHz, 80 MHz, 80 + 80 MHz, and 160 MHz. Wider bandwidths allow use of more subcarriers, for example there are 242 subcarriers in a 20 MHz channel and 996 subcarriers in an 80 MHz channel (hence OFDMA terms RU242 and RU996).

  • Modulation and coding. 802.11ax extends the modulation and coding scheme adding 1024-QAM options with coding rates of 3/4 and 5/6. All earlier options are still available, and are used if SNR is too low to sustain highest achievable rate.

  • Subcarrier changes. The fast fourier transform (FFT) length was increased from 64 in 802.11ac to 256 in 802.11ax for 20 MHz. This results in a decrease in subcarrier spacing and an increase in number of data subcarriers. These factors contribute to a 10% increase in efficiency over the previous generation.

  • Symbol duration. Symbol duration was increased to 13.6 ns, 14.4 ns, and 16 ns. Extended symbol durations result in increased efficiency due to availability of more data tones compared to older standards.

  • Guard interval. Guard intervals are necessary to avoid multipath reflections of one symbol from arriving late and interfering with next symbol. Extended guard interval durations of 1600 ns and 3200 ns have been introduced in addition to 800 ns from 802.11ac. Longer guard intervals allow for better protection against signal delay spread in outdoor environments. These could also potentially increase effective range of wireless outdoors.

All above factors contribute to increased PHY data rate and efficiency. Following is a table with 802.11ax data rates for a single spatial stream full-bandwidth client. Note the rates double with 2 spatial streams, triple with 3, and so on until maximum number of spatial streams supported by specification. The included guard intervals (GI) for rates listed below are 1600 ns (1.6 μs) and 800 ns (0.8 μs).

Spatial Streams MCS index Modulation type Coding rate PHY rate (in Mbps)
20 MHz 40 MHz 80 MHz 160 MHz
1.6 μs GI 0.8 μs GI 1.6 μs GI 0.8 μs GI 1.6 μs GI 0.8 μs GI 1.6 μs GI 0.8 μs GI
1 0 BPSK 1/2 8 8.6 16 17.2 34 36 68 72
1 1 QPSK 1/2 16 17.2 33 34.4 68 72.1 136 144
1 2 QPSK 3/4 24 25.8 49 51.6 102 108.1 204 216
1 3 16-QAM 1/2 33 34.4 65 68.8 136 144.1 272 282
1 4 16-QAM 3/4 49 51.6 98 103.2 204 216.2 408 432
1 5 64-QAM 2/3 65 68.8 130 137.6 272 288.2 544 576
1 6 64-QAM 3/4 73 77.4 146 154.9 306 324.4 613 649
1 7 64-QAM 5/6 81 86 163 172.1 340 360.3 681 721
1 8 256-QAM 3/4 98 103.2 195 206.5 408 432.4 817 865
1 9 256-QAM 5/6 108 114.7 217 229.4 453 480.4 907 961
1 10 1024-QAM 3/4 122 129 244 258.1 510 540.4 1021 1081
1 11 1024-QAM 5/6 135 143.4 271 286.8 567 600.5 1134 1201

OFDMA

Orthogonal Frequency Division Multiple-Access (OFDMA) is a transmission technique which enables multiple devices to share same Wi-Fi channel at same time through use of subchannels. Wi-Fi was first major consumer technology to adopt OFDM in 1999, and was subsequently used by 3GPP community when designing LTE and now 5G. In turn, Wi-Fi 6 and 6E adopted OFDMA technology from other wireless technologies like WiMAX and LTE.

With OFDMA, multiple clients can simultaneously share a Wi-Fi channel during same transmit opportunity (TxOP) instead of having to take turns. OFDMA enables transmission on a 20 MHz channel up to nine clients at once, versus four as in 802.11ac (with MU-MIMO). This scales linearly as channel width increases i.e. 18 clients for 40 MHz and 37 clients for 80 MHz channels. And when needed, a single client can also use entire channel ensuring better client density does not come at a cost of peak performance. Notably, OFDMA is bidirectional, bringing uplink multi-user capability to Wi-Fi for first time.

Take into consideration a scenario where AP must send data to 3 clients. In 802.11ac Single User (SU) operation, AP would contend for medium and then send three packets consecutively as shown in figure below. Whereas in 802.11ax with OFDMA, transmissions for these 3 client devices are assigned a fractional channel and then sent to all 3 clients simultaneously (during same TxOP).

Illustration of OFDMA Operation

To summarize, downlink OFDMA (DL OFDMA) allows access point to bundle several frames together with a single preamble, in different sub-channels in a single transmit opportunity (TxOP). Clients can then tune their radios to respective sub-channels to receive their transmissions.

Benefits of OFDMA:

  • OFDMA helps in reducing latency between client and Access Point (AP).

  • OFDMA helps in reducing contention overhead which means that there is very little deterioration in capacity as number of clients increases. This is helpful in high density environments because OFDMA improves network capacity and efficiency.

  • 802.11ax also improves performance for legacy generations. As more Wi-Fi 6 devices enter market and uses OFDMA to reduce airtime consumption, there is more usable airtime leftover for earlier Wi-Fi generations.

Applications and use cases

Voice over Wi-Fi

One of top use cases for OFDMA is Voice over Wi-Fi (VoWi-Fi). In high density environments, where a lot of users are contending for medium access, can result in increased latency and jitter. These factors can cause gaps in re-creation and playback of voice leading to an undesirable user experience. OFDMA also enables strong QoS mechanism by enabling AP to control medium access for both DL and UL. This can eliminate need for individual medium contention and enables the AP to schedule grouped transmissions in one transmit opportunity (TXOP). That is how OFDMA allows AP to better control latency and jitter. With 802.11ax, AP can assign frequent, short transmission opportunities so AP can transmit and receive packets without need to buffer them. OFDMA can be helpful in low-bandwidth streams like Voice over Wi-Fi (VoWi-Fi) by reducing latency and jitter thus improving call quality.

Internet of Things

Important metrics for an Internet of Things (IoT) device include data rate, scalability, range, power consumption, security and ease of configuration. OFDMA divides transmissions across frequency domain and smallest unit of allocated bandwidth can be as small as 2 MHz. This allows more individual devices to be reliably supported on an AP and thus fulfills a critical IoT requirement, scaling. Unlike most of mainstream Wi-Fi applications, IoT devices usually use lower speed connections, often in sub-Megabit range. OFDMA addresses first three requirements of this sector - data rate, scale and range. OFDMA allows sub-channelization which reduces data rates to ~2 Mbps. This inherently helps in improving range of IoT devices.

In addition to this, Wi-Fi 6 also offers various power-save features like TWT, Receive Operating Mode Indication, Transmit Operating Mode Indication, etc. along with 20 MHz-only clients to addresses most of basic requirements for encroaching into IoT Markets.

Video and factory automation applications

OFDMA is ideal for latency sensitive applications like video and factory automation applications. OFDMA enables several to many low-bandwidth streams to be transmitted in parallel. This can aid in reducing latency and jitter.

DL MU-MIMO improvements in Wi-Fi 6 and 6E

Multi-user Multiple-Input, Multiple-Output (MU MIMO) is a multi-user capability, originally introduced in 802.11ac for downlink traffic. MU-MIMO technology improves network capacity by allowing multiple devices to transmit simultaneously, making use of multipath spatial channels.

802.11ax introduces some new enhancements to existing 802.11ac downlink (DL) MU-MIMO. The number of users in a group is expanded up to eight users for MU-MIMO operation. Due to this advancement, now even with devices in single stream mode, MU-MIMO throughput can be doubled over single user operation. The improvement of increasing size of downlink multi-user MIMO groups can result in more efficient operation.

In addition to these improvements, 802.11ax allows uplink (UL) OFDMA as part of sounding protocol, which is more efficient than using single user transmission of feedback used for sounding protocol in 802.11ac.

All these factors can lead to increased capacity and efficiency aimed to be useful for high-bandwidth applications like mission-critical voice calls and video streaming.

Power-save enhancements

Wi-Fi 6 introduces various enhancements to already existing power-save modes. These new and improved power-save mechanisms allow longer sleep intervals and scheduled wake times for client devices. These enhancements were adopted to address power consumption issue mainly for handheld and battery powered devices and are targeted towards emerging IoT markets.

Target Wake Time (TWT)

Target Wake Time (TWT) is a power saving mechanism that was introduced in 802.11ah. A schedule (service period) can be negotiated between each client (station) and corresponding AP, which allows client to sleep for long periods of time and wake up at pre-scheduled (target) times to exchange information with the associated AP. TWT also significantly reduces small and inefficient control frame traffic that clients are required to use regularly to poll AP for buffered frames (PS-Poll or U-APSD). A client can greatly improve power savings with TWT if the client has a known deterministic traffic pattern like an Internet of Things (IoT) environmental sensor that only report sensor data every so often.

There are two types of TWT agreements.

  • Individual TWT (i-TWT) is negotiated between an AP and each client to agree on parameters such as wake time, interval, and duration. This enables clients to specify when and how often to wake up.

  • Broadcast TWT (b-TWT) is negotiated between an AP and a group of clients where target wake time parameters such as beacon and listen intervals are advertised in beacon frames. Clients will wake during the service period (SP) and contend for medium access. b-TWT may be used over i-TWT for the purpose of simplicity and less management frame overhead.

In addition to reducing contention between clients, use of TWT may also contribute to taking full advantage of other novel mechanisms in IEEE 802.11 universe, such as multi-user transmissions and coexistence in high-density WLAN scenarios. TWT operation is ideal for IoT devices which communicate infrequently. TWT can improve client power savings and reduces airtime contention with other clients.

Example of Individual TWT agreement.

20 MHz-only operation

20 MHz-only operation feature was specifically introduced for IoT markets. The feature seeks to reduce complexity, leading to low-power, lower-cost chips. Such devices are capable of operating in both 2.4 GHz and 5 GHz bands and also support nearly all Wi-Fi 6 mandatory features.

Receive operating mode indication

Receive operating mode indication enables client (station) to adapt to number of active receive chains and channel width for reception of subsequent PPDUs by using a field in MAC header of a data frame. This mechanism reduces overhead compared to 802.11ac as there is no additional Operating Mode Notification management frame exchange as there is in 802.11ac.

Transmit operating mode indication

This allows client devices (stations) to dynamically adapt their transmit capabilities like channel width and maximum number of spatial streams.

UL/DL flag in every preamble allows to identify frames as transmitted by an AP or client device. This helps client devices to switch off their radio circuitry as soon as they see an uplink bit in preamble.

Backward compatibility

Like previous generations of Wi-Fi, 802.11ax (Wi-Fi 6) is backward compatible and fully supports legacy 802.11a/b/g/n/ac clients. An 802.11ax access point (AP) communicates with each client device using only the protocols supported by that client. Legacy clients capable of 802.11a/b/g/n/ac can associate with an 802.11ax AP but cannot utilize 802.11ax specific features.

Communication remains limited to the most recent Wi-Fi standard supported by the client device. For example, an 802.11ac client associating with a Wi-Fi 6 AP uses only features defined in the 802.11ac Wi-Fi standard. Mixed environments with both Wi-Fi 6 and legacy clients do allow Wi-Fi 6 clients to leverage advanced features such as OFDMA and 1024-QAM.

While 802.11ax includes newer higher-efficiency techniques and frame formats that can only be decoded by other 802.11ax devices, continued support of VHT, HT and older 802.11 equipment is an integral part of standard.

802.11ax radios will communicate with other 802.11ax radios using High Efficiency (HE) OFDM symbols and Physical Protocol Data Unit (PPDU) formats. As far as compatibility with clients is concerned, they can communicate with 802.11a/g, 802.11n (HT) and 802.11ac (VHT) clients using 802.11a/g/n/ac formatted PPDUs. When 802.11ax-only OFDMA conversations are occurring, RTS/CTS mechanism may be used to protect legacy receivers during period when HE transmissions are underway.

This ensures that an 802.11ax AP is a good neighbor to adjacent to older APs while fully embracing all of generations of client devices that exist in environment. 802.11ax has a number of features for co-existence, but main one is extension of an 802.11n/ac technique: The first 20 μs of 11ax preamble uses 802.11a preamble. Non-802.11ax equipment can read first 20 μs and identify that channel will be occupied for a given time, and therefore can avoid transmitting simultaneously with high efficiency frame. Non-802.11ax devices communicating with an 802.11ax AP will still require the entire channel for transmission rather than sharing channel resources through OFDMA subcarrier allocation.

Protection, dynamic bandwidth, and channelization

802.11ax inherits dynamic bandwidth operation and protection mechanisms from 802.11ac standard. There have not been any new modifications to these mechanisms in 802.11ax. 6 GHz aside which is covered in Wi-Fi 6E, channelization for 802.11ax has changed little since introduction of 802.11ac.

When an 802.11ac or 802.11ax AP using an 80 MHz channel is operating in neighborhood of an older AP, or a network that is only using a 20 MHz or 40 MHz channel, newer generation AP must avoid transmitting simultaneously with a station in neighboring network. The question is how this can be achieved without permanently reducing channel bandwidth from 80 MHz.

The solution can be found by answering following questions.

  1. How can a station (AP or client) wanting to operate at 80 MHz, warn older stations to stay off air while transmitting in 802.11ac or 802.11ax mode, which 802.11n and older cannot decode?
  2. How will 802.11ac or 802.11ax station know that full channel is clear of other stations’ transmissions?
  3. How can bandwidth usage be optimized if, for instance, an older station is transmitting in just 20 MHz of 80 MHz channel?

Illustration of dynamic bandwidth operation with an 80 MHz channel

Sending a warning to other stations to stay off air is achieved by request to send (RTS) frames. The 802.11ac station sends out multiple parallel RTS protection frames in each 20 MHz channel in the bonded set, at rates an 802.11a or 802.11n clients can understand. The multiple RTS frames use duplicate, quadruplicate, or octuplicate transmission. Before sending RTS, clear channel assessment (CCA) is performed to ensure no transmissions in progress are heard. On receiving RTS frame, older stations know how long to wait for 802.11ac transmission.

Next, the recipient runs a CCA in each of 20 MHz channels. The RTS frame format is extended so that the originator can indicate channel options and replies with a clear to send (CTS) response to indicate whether transmissions in progress are heard from any neighboring network. If not, originator transmits data frame using full bandwidth (80 MHz in this example).

However, if the recipient does find transmissions in progress on any secondary channel, recipient can still continue responding with CTS, while indicating which primary channels are clear (20 MHz or 40 MHz). Then, originator can transmit using only the usable part of 80 MHz channel. This may force a reduction in channel width from 80 MHz to 40 MHz or even 20 MHz, but frame will be transmitted using airtime that would otherwise be unused. This feature is called dynamic bandwidth operation.

Dynamic bandwidth optimization is constrained by 802.11ac and 802.11ax definitions of primary and secondary channels. For each channel, such as an 80 MHz channel, one 20 MHz channel (subchannel) is designated as primary. This is carried through from 802.11n, and in networks with a mix of 802.11ac or 802.11ax, and older clients, all management frames are transmitted in this channel so that all clients can receive them.

The second part of 40 MHz channel is called secondary 20 MHz channel. And 40 MHz of wide channel that does not contain primary 20 MHz channel is secondary 40 MHz channel. Data transmissions can be in primary 20 MHz channel, 40 MHz channel including primary 20 MHz channel, or full 80 MHz channel, but not in other channel combinations.

Illustration of dynamic bandwidth and channelization with an 80 MHz channel

Additionally, introduction of wide band channels, especially 80 + 80 MHz channels, requires some changes to channel switch announcement (CSA) frame. CSA is used by an AP to inform associated clients when the AP is about to switch channels after radar has been detected in current channel. CSA was first introduced in 802.11h as part of dynamic frequency selection (DFS). Otherwise, operation of DFS remains unchanged with 802.11ac and 802.11ax.

Wi-Fi 6 (802.11ax) represents an advancement in Wi-Fi aimed at delivering improved efficiency and performance in dense environments with many connected devices. This page describes considerations and deployment strategies for Wi-Fi 6 networks, focusing on key features that enhance efficiency, speed, and battery life.

Unlike the previous 802.11ac standard that primarily focused on increasing data rates, Wi-Fi 6 introduces technologies borrowed from other wireless technology that fundamentally improve how wireless networks handle multiple simultaneous connections. By implementing features like Orthogonal Frequency Division Multiple Access (OFDMA), enhanced Multi-User MIMO (MU-MIMO), and Target Wake Time (TWT), network administrators can enhance both network capacity and client device performance.

Configuration

In general, the recommendation is to use default settings for 802.11ax (HE) unless directed to change per TAC.

High efficiency (HE)

All 11ax specific features fall under High Efficiency (HE) profile in AOS-8 or the SSID profile in AOS-10. Enabling the High Efficiency parameter enables all the 802.11ax features on the radio. Users can utilize Wi-Fi 6 features like TxBF, HE supported higher MCS rates (10 and 11), HE OFDMA, MU-MIMO, TWT, etc.

High Efficiency is enabled by default and is recommended to keep enabled to reap the benefits of 802.11ax.

HE OFDMA

HE OFDMA is enabled by default and is recommended to keep enabled for increased efficiency and reduced latency. OFDMA is best for applications leveraging smaller packet sizes (IoT, Voice applications, etc.) and is suitable for low bandwidth applications.

Transmit beamforming (TxBF)

802.11ax employs an explicit beamforming procedure, similar to that of 802.11ac. Under this procedure, the beamformer (AP) initiates a channel sounding procedure with a Null Data Packet. The beamformee (client) measures the channel and responds with a beamforming feedback frame, containing a compressed feedback matrix. The beamformer uses this information to compute the antenna weights in order to focus the RF energy toward each user which can result in an increased MCS rate.

TxBF is enabled by default. In most deployments, we recommend to keep TxBF enabled for performance benefits in applicable scenarios. In certain very high density deployments, you may consider disabling to minimize sounding overhead.

Downlink MU-MIMO is enabled by default and is recommended to keep enabled in configuration as DL MU-MIMO can lead to increased capacity and enable higher speeds per user in applicable scenarios. DL MU-MIMO for applications that larger packets (video, streaming, etc.) and is suitable for high bandwidth applications.

TWT

A new power saving features offered by Wi-Fi 6 is Target Wake Time (TWT). This feature allows for clients to “wake up” at negotiated times rather than waking up for every beacon.

TWT is enabled by default and is recommended to keep enabled as i-TWT allows capable clients to request specific wake up time to AP, so that clients can go to sleep for longer time than normally and save power.

2.2 - Wi-Fi 6E

Overview of the IEEE 802.11ax standard operating in the unlicensed 6 GHz band, information on features and benefits of Wi-Fi 6E, and implementation guidelines.

Wi-Fi 6E introduces 6 GHz band support using Wi-Fi 6 technology based on IEEE 802.11ax. The 6 GHz band allows for up to 1200 MHz of additional spectrum for unlicensed Wi-Fi use. Wi-Fi 6E introduces new methods in legacy bands to discover 6 GHz networks and comes with new baseline security requirements of WPA3 or Enhanced Open.

2.2.1 - Features and benefits

Features and benefits of Wi-Fi 6E.

In 2020, the Wi-Fi Alliance announced Wi-Fi 6E, which extends Wi-Fi 6 into the 6 GHz spectrum. Adding Wi-Fi 6 to the 6 GHz band offers several advantages over Wi-Fi in the 2.4 GHz and 5 GHz bands. The Federal Communications Commission (FCC) then made history by opening up 1200 MHz for unlicensed use by technologies like Wi-Fi.

The iterations of Wi-Fi have done a remarkable job with backwards-compatibility over the years, but come at a cost of carrying and accommodating legacy protocols and reduced bandwidth efficiency. The 6 GHz band does not accommodate Wi-Fi technologies older than Wi-Fi 6. The band allows Wi-Fi 6E to operate without the constraints of legacy protocols, enabling improved bandwidth and latency. Crucial to understand and note, Wi-Fi 6E shares unlicensed spectrum with other technologies which might be operating at the same time. In certain scenarios, Wi-Fi 6E APs must perform frequency coordination through a frequency coordinator prior to medium access for minimized interference with licensed incumbent users of the spectrum.

Regulations in the 6 GHz band

Spectrum allocation is a regulatory function, and rules can be different at varying national levels. This page covers regulations in the FCC and ETSI regulatory domains; most countries will follow one or the other of these models, potentially with minor national variations.

Channels

The FCC unlicensed grant in 6 GHz is 1200 MHz of spectrum, compared to 83.8 MHz in the 2.4 GHz band and 570 MHz in sections of 5 GHz (FCC). After a 20 MHz guard band at the low end, usable 6 GHz spectrum starts at 5.945 GHz and continues up to 7.125 MHz. This allows for 59 channels at 20 MHz width, 29 at 40 MHz, 14 at 80 MHz, or 7 at 160 MHz (the maximum channel width supported by Wi-Fi 6E).

FCC channel distribution for 6 GHz.

The number of wide channels in 6 GHz is especially significant, as gaps in allocated spectrum in the 5 GHz band limit 80 MHz channels to 6 (seven if we include U-NII-4) and 160 MHz channels to 2 (3 if we include U-NII-4), and wide channels are necessary for the highest data rates.

The FCC designates four sub-bands across the 1200 MHz of 6 GHz: U-NII-5, U-NII-6, U-NII-7, and U-NII-8. These sub-bands are significant because they contain different incumbent types (covered in a section below), so while indoor APs will have uniform power limits across the entire 1200 MHz, there are differing restrictions for higher power and outdoor use across the sub-bands.

ETSI channel distribution for the lower half of the 6 GHz band

The rules from European regulators are not the same as from the FCC. They have taken a more cautious approach, allowing operation in just the lower 500 MHz of the band (480 MHz after the 20 MHz guard band), the equivalent to U-NII-5. This is primarily due to caution over spectrum sharing approaches like the FCC’s Automated Frequency Coordination (AFC) which is necessary to protect incumbents from interference from 6 GHz unlicensed transmitters.

A consequence of this caution is that European countries will restrict 6 GHz operation to indoor WLANs initially. Decisions on extending into the upper part of the 6 GHz band and allowing outdoor and higher-power operation have been deferred, for now.

Many other countries worldwide are in the process of adopting the 6 GHz band for unlicensed use; most of them are expected to follow either the FCC (1200 MHz) or ETSI (lower 500 MHz) approaches, with minor deviations possible for national regulation.

Incumbents

While the 6 GHz band is continuous and channelized across the entire 1200 MHz, existing non-Wi-Fi technologies are active in all sub-bands of 6 GHz. To allow new users into the bands without disrupting the operation of incumbents, spectrum-sharing models are required; new users can be allowed to transmit only when they will not cause interference to incumbents.

However, there is no requirement in the 6 GHz band for special in-band sensing of incumbent transmissions, similar to the Dynamic Frequency Selection (DFS) mechanism used in parts of the 5 GHz band for radar avoidance. Instead, the 6 GHz band uses two spectrum-sharing techniques. Where possible to identify incumbent users in the vicinity of an unlicensed transmitter, power and frequency options are restricted to stay clear of the incumbents. Alternatively, where specific knowledge of nearby incumbents is unavailable, power levels must be kept low enough to ensure they will never cause interference, even in the worst case.

For U-NII-5 running from 5.925 to 6.425 GHz and U-NII-7 from 6.525 to 6.875 MHz, the most important incumbents are point-to-point, licensed radio links used by service providers and private communications for utility companies and others. These links are licensed by the FCC and included in a database known as the Universal Licensing System (ULS). As they are point-to-point, they have narrow-beam antennas, often on tall masts, and can reach for tens of kilometers. The ULS database contains tens of thousands of these links, along with their location (transmitter and receiver, giving direction), frequency, and other characteristics. The FCC allows two spectrum sharing models for these sub-bands. At a low power threshold, and indoors only, unlicensed radios can transmit anywhere. Meanwhile, outdoor locations and higher-power transmitters are allowed where a calculation based on the ULS database shows they will not interfere with incumbents.

The spectrum sharing protocol for high-powered or outdoor unlicensed transmitters requires them to contact a central AFC server, which uses their location and transmit power to calculate whether any of the licensed incumbents in the ULS database might be affected and identifies safe power and frequency parameters.

In other sub-bands, U-NII-6 and U-NII-8, the incumbents are more difficult to coordinate, as they include mobile transmitters, and also temporary links used by local TV stations for outside broadcasts. These bands are less suited for spectrum sharing because the usage patterns are more dynamic, so outdoor, high-power transmitters are not allowed.

The protection of incumbents, and differing views of how to solve this problem, shapes regulators’ approach to opening the 6 GHz band to unlicensed transmitters. Some national regulators are following the FCC approach and introducing spectrum-sharing mechanisms to ensure new unlicensed services can use the spectrum without causing interference, while others are shelving the question by addressing only the lower part of the 6 GHz band, without more complex spectrum sharing arrangements like the FCC’s AFC.

Equipment classes for 6 GHz unlicensed operation

The FCC wants to allow 6 GHz networks to have the best possible performance while ensuring that licensed incumbents are not adversely affected. The FCC policy achieves their goal by defining four separate operating classes for 6 GHz equipment: Low Power Indoor (LPI), Standard Power (SP), Very Low Power (VLP) and Client Devices. VLP is not in scope for this page.

Equipment classes for 6 GHz for the FCC domain. Client rules vary per regulatory.

Low power indoor

The most common class for Wi-Fi 6E access points (APs) is low power indoor (LPI). These will be the familiar home or enterprise campus APs. By definition, these APs are shielded by buildings, to some extent, so the signal ’leaking’ outside will be attenuated, which allows safe operation across the band at a power level similar to today’s indoor Wi-Fi APs.

Low power indoor (LPI) AP characteristics:

  • Fixed indoor only
  • PSD 5 dBm/MHz
  • No antenna connectors
  • No weatherproofing
  • Wired power

The limiting power level for LPI APs is not defined in absolute dBm, as for the lower bands, but at 5 dBm/MHz spectral density. This method of limiting allows an increase of 3 dB for every doubling of channel bandwidth, which gives approximately 18 dBm EIRP for a 20 MHz channel, and up to 27 dBm for a 160 MHz channel in Wi-Fi 6E. Note that spectrum is never perfectly flat and actual maximum EIRP may be further restricted as to not exceed regulatory limits or by hardware limits.

Channel width PSD (dBm/MHz) Maximum EIRP (dBm) Relative noise floor (dBr) EIRP-NF
20 5 18 0 18
40 5 21 +3 18
80 5 24 +6 18
160 5 27 +9 18
320 (Wi-Fi 7) 5 30 +12 18
Device class Band Maximum EIRP PSD
Low power indoor AP U-NII-5, U-NII-6, U-NII-7, U-NII-8 30 dBm 5 dBm/MHz
Client connected to low power indoor AP U-NII-5, U-NII-6, U-NII-7, U-NII-8 24 dBm -1 dBm/MHz

The FCC can apply this rule because incumbent links are generally narrow band compared to Wi-Fi channels. This is advantageous to Wi-Fi network because noise increases proportionally with channel bandwidth. SNR will remain similar for different channel widths, given maximum transmit power levels, hardware capability, and environmentals are the same.

Low power indoor (LPI) APs can operate across the whole 1200 MHz band, as their transmit power is considered safe for all incumbents after building exit loss is subtracted and attenuated. To ensure that these indoor-only units are not used outdoors, or with external high-gain antennas (which have the potential to cause interference), the FCC provides a list of physical requirements for certifying a LPI AP:

  • No connectors for external antennas
  • No battery-powered operation
  • Not weatherized

The current rules from European regulators allow only Low Power Indoor (LPI) APs; outdoor mounting is not allowed and transmit power (EIRP) is limited to 23 dBm. Some countries deviate from this value, but only by one or two dBm.

Standard power

APs mounted outdoors, or indoors operating at higher power than LPI, are subject to ‘Standard Power’ (SP) rules. This is because they may interfere with incumbents and, because they would not otherwise be aware of the risk of interference, they must check periodically with the AFC for channel availability.

Standard power (SP) AP characteristics:

  • Fixed indoor/outdoor
  • EIRP 36 dBm max
  • Controlled by an AFC database
  • Automated geolocation
  • Pointing angle restriction

The AFC query protocol is defined by the Wi-Fi Alliance and consists of an inquiry message from the AP and a response from the AFC server. The most important information in the inquiry is the AP’s geolocation. In exchange for latitude, longitude, antenna height (above ground level) and some other information in an inquiry message, the AP or controller receives a response containing the set of channels or frequency ranges and the maximum power levels that will not cause interference.

The transmit power of a standard power AP can be as high as 36 dBm EIRP. Because of the increased risk of interference to incumbents, standard power APs are only allowed in the U-NII-5 and U-NII-7.

Number of channels available for standard power (FCC):

Number of channels Channel bandwidth
41 20 MHz
20 40 MHz
9 80 MHz
4 160 MHz

Client devices

As with the lower sub-bands, client devices are expected to be limited in geography by APs. If there is no AP signal, devices must not transmit or attempt connection. Therefore, we assume the AP is transmitting in an authorized manner, and the client can adjust client transmit power and channel with reference to the AP. Refer to the respective regulatory in your locale for rules regarding client devices.

6 GHz operation

One attractive feature of the 6 GHz band is that there are no older Wi-Fi devices that need to be accommodated. Wi-Fi has done a remarkable job with backwards-compatibility over the years, but these efforts come at a cost of carrying legacy protocols and reduce bandwidth efficiency. The initial Wi-Fi 6E release sets a high bar with the new baseline of Wi-Fi 6 (802.11ax).

Devices using the 6 GHz band must use Wi-Fi 6 standards, must conform to WPA3 or Enhanced Open security, and cannot offer older security options like WPA2 and Open modes. For WPA3-Enterprise, the differences are slight and exclude some combinations of WPA2-Enterprise security protocols that could expose vulnerabilities, but these combinations were never configurable on most enterprise class APs. The pre-shared key options for WPA2 are significantly changed and improved with WPA3-Personal, and a new ‘Enhanced Open’ standard replaces Open mode to ensure that over-the-air transmissions are encrypted even without authentication of the client device or the network. These mandates are in line with the Wi-Fi 6 standard, without allowance for backwards-compatibility for older client devices.

The Wi-Fi Alliance has introduced a limited number of new features in Wi-Fi 6E, many previously optional features are now mandatory, with two goals:

  • Improved airtime efficiency. In crowded areas, much of the available airtime is taken up with AP discovery frames such as beacons, probe requests, and probe responses. This detracts from airtime efficiency, so several features allow client devices to discover target APs and channels with fewer frames on the air.

  • Faster AP discovery. Although the large number of new channels is a significant advance, client devices would take a long time to step through each channel, transmitting probe requests and awaiting replies to find a suitable AP. Therefore, new features aim to improve the speed and efficiency of AP discovery

The features are classified as ‘in-band’ and ‘out of band’, meaning the client device discovers APs on the 6 GHz channel where they transmit, or on another channel in a lower band, 2.4 GHz or 5 GHz.

In-band AP discovery features

The traditional way for a client device to discover a suitable AP for connection is to tune its radio to a 20 MHz channel, transmit a number of probe requests, wait on-channel for ~20 msec for probe responses from APs operating on that channel, then tune to the next channel and repeat. This takes time, may result in jitter or data loss as the device is away from its serving AP, and reduces battery life through extra frame transmissions. In addition, the probe requests and responses on the air reduce throughput for other user traffic.

For some time, the industry has been working towards passive scanning where devices learn about other APs and their serving channels through Neighbor Reports. This allows the device to switch to the new channel, reducing time off-channel and frames on the air, but can require up to 102 msec off-channel waiting for the next beacon transmission. This last issue is mitigated in the Neighbor Report by a beacon offset time value, allowing efficient passive scanning, but only in cases where an AP provides comprehensive Neighbor Reports in the beacon or probe response.

As a new, greenfield band, 6 GHz offers an opportunity to mandate features that reduce acquisition time, improve battery life, and avoid excess frames on the air. Several existing and new features improve 6 GHz AP discovery in all these areas.

Technique Airtime efficiency Faster AP discovery Notes
Preferred Scanning Channels (PSCs) Yes Starting with channel 5, one in every four 20 MHz channel is designated for beacons and discovery
Beacon Changes Yes Remove information elements for older generations: add some parameters to Wi-Fi 6 operations and configuration information elements
Multi-BSSID (MBSSID) Beacon Yes For multiple Virtual APs on a single radio, transmit one beacon with elements for VAP deltas, rather than multiple beacons.
Rules for Probing Yes No probing in non-PSC channels unless a beacon is received. Restricted probing in PSC channels
Unsolicited Probe Responses Yes Short AP announcement every 20 msec (vs 102 msec for a beacon)
FILS Announcements Yes Short AP announcement every 20 msec (vs 102 msec for a beacon)

Preferred scanning channels

Starting with channel 5, every fourth 20 MHz channel is designated for scanning, and APs should align their transmitting channels with Preferred Scanning Channels (PSCs) when using wider channel widths.

Preferred Scanning Channels across the 1200 MHz band of 6 GHz

For wider channels, the ‘primary’ 20 MHz channel where the beacon is transmitted should align with a PSC where possible. This achieves two goals.

  1. Client devices searching for a suitable AP must to scan at most 15 channels to find a beacon or other advertisement.
  2. Ensures that non-PSC channels are not burdened by beacons, probe requests or responses, and thus can transfer the maximum possible user data.

To enforce good behavior, several rules are in place to reduce excessive probing and encourage client device designers to optimize their probing algorithms.

For example, a client device should not transmit (e.g. probe requests) in a non-PSC channel unless the client has learned that an AP is present, either by listening for 802.11 frames or through one of the mechanisms explained here. Even in PSC channels, wildcard probe requests are restricted, and the rate at which probes can be sent is limited.

Probe request rules:

Type of Probe Request Condition to Send Probe Request Purpose
Destination Address BSSID SSID
Broadcast Wildcard Wildcard Not Allowed Ban indiscriminate probe responses from all BSSs from all ESSs.
Broadcast Wildcard SSID Not more than 1 per 20 ms. Probe ESS but with reduced frequency.
Broadcast BSSID/Non-transmitted BSSID Not more than 3 per 20 ms. Probe specific BSS with reduced frequency.

Beacon changes

The beacon itself can be shortened in time and complexity because there are no existing Wi-Fi devices operating in the 6 GHz band. 6 GHz takes advantage of opportunities for house cleaning, forgoing transmissions that would only be of interest to older equipment. An example is the backwards-compatibility in the form of ‘capabilities’ and ‘operation’ information elements. Because, for example, a Wi-Fi 4 device is not programmed to understand Wi-Fi 5 parameters, beacons in the 5 GHz band must include the older Information Elements (IEs) in addition to newer ones added for subsequent generations.

Wi-Fi 6 (802.11ax HE) beacon example in 5 GHz

Wi-Fi 6E (802.11ax HE) beacon example in 6 GHz

The greenfield nature of 6 GHz allows these older elements to be dropped, saving time on the air and improving bandwidth efficiency. The example above shows that the HT and VHT operations and capabilities IEs are removed, and those values that are not superseded are added to the equivalent HE (Wi-Fi 6) IEs.

The ‘operations’ IEs are announcements from the AP about the transmission channel and are part of the beacon, probe response, association response, and re-association response frames. The ‘capabilities’ IEs list the options that APs and devices can use, and are transmitted in the information elements listed above and also the equivalent requests from client devices. Other modifications to the beacon include the rate at which the elements are transmitted: no pre-Wi-Fi 6 rates are allowed, forcing higher rates, shorter durations, and better bandwidth efficiency.

Multiple BSSIDs in one beacon

This feature was introduced as optional in 802.11v-2011 and was not initially implemented in clients or APs. For Wi-Fi 6E, clients are required to support multiple BSSIDs.

Multiple BSSIDs in one beacon

Where many SSID/BSSIDs are advertised on the same radio, as is commonplace in residential and enterprise WLANs, previously, each BSSID or virtual AP had to transmit its beacon separately. If an wanted to transmit four SSIDs, four separate beacons were transmitted in each 102.4 msec beacon interval, and many IEs were duplicated across beacons.

With the multiple BSSID feature, the common elements are transmitted once, and a separate information element is appended with the values unique to each virtual AP, now termed a ’non-transmitted’ BSSID.

The “new” beacon is considerably shorter, improving WLAN efficiency. However, this method may not be universally applied. For example, a limit on the beacon size may restrict the number of multiple BSSIDs to a maximum of 4, so when more than 5 SSIDs are used, multiple MBSSID beacons are still necessary to support the multiple BSSID feature. Thus, more than 4 SSIDs are split into multiple MBSSID sets.

Example of three SSIDs in one MBSSID frame with transmitted (ACME) and non-transmitted BSSIDs (ACME_6GHz and ACME_Guest)

Unsolicited probe responses

Unsolicited probe responses (UPR) function like mini beacons. While the usual beacon interval is 102.4 msec, unsolicited probe responses can be transmitted every 20 msec. The increased rate enables clients to decide whether the AP is suitable for connection through fast passive scanning rather than active probing or passive discovery of neighbor APs through reduced neighbor reports. The unsolicited probe response allows a client, rather than tuning to a channel and transmitting some probe requests and waiting ~20 msec for responses, to listen passively for just 20 msec and be sure the client has heard all BSSIDs on that channel. Unsolicited probe responses can contain the same information elements as a ’normal’ probe response, but they are transmitted to the broadcast address.

FILS announcements

Fast initial link setup (FILS) is a complete protocol for AP discovery, authentication, and handover that was introduced in 802.11ai and the Wi-Fi Alliance optimized connectivity certification. FILS was aimed particularly at public networks but was not widely adopted. FILS announcements act as mini beacons, transmitted every 20 msec. Each announcement frame contains the information necessary for a client device to decide whether the AP is suitable for connection.

FILS discovery information elements

FILS announcements can also incorporate reduced neighbor reports to advertise the channels of other APs of the same network. The ‘short SSID’ can optionally be substituted for the SSID in the FILS announcement. This value is a (non-reversible) hash of a full SSID.

FILS announcements and unsolicited probe responses serve similar purpose. Only one or the other would normally be required. Starting in AOS-8.11 and AOS-10.5, FILS announcements are the default advertisement for 6 GHz channels when capable HPE Aruba Networking APs are operating as single-band 6 GHz only (without 2.4 GHz or 5 GHz operation enabled). When the capable AP is operating in a multi-band state, FILS advertisement in 6 GHz is automatically disabled to conserve airtime. This is not configurable.

Example of FILS frames captured over the air (OTA) and shown in Wireshark

Out-of-band (OOB) AP discovery

The techniques mentioned above allow a client to scan the 6 GHz band to discover APs in-band. But most 6 GHz APs will operate as multi-band, where non-6 GHz radios can be coordinated, enabling a client scanning 2.4 GHz or 5 GHz can learn about a 6 GHz AP without tuning the radio to, or scanning, 6 GHz.

Technique Airtime efficiency Faster AP discovery Notes
Reduced Neighbor Report (RNR) Yes Yes Included in beacons, and probe responses, identifies neighbors BSSIDs normally with the same SSID, in same or other bands
ANQP Access Network Query Protocol Yes Yes Pre-association frame exchange that allows an access point to provide information on neighbor BSSIDs.

Reduced neighbor report

The reduced neighbor report (RNR) was initially developed for use with the FILS discovery protocol, but use is expanded for 6 GHz operation. When associated at 2.4 GHz or 5 GHz, the client can listen for BSSIDs containing RNR information elements and discover the channels where 6 GHz neighbor APs, in the same physical unit or separate units, are transmitting. This allows clients to move directly to the target 6 GHz channel.

  • List networks on adjacent radios or neighboring APs
  • Supports faster 6 GHz BSS discovery
  • Includes a relative offset for target beacon transmission time
  • Found in existing passive/active scanning through beacon or probe response frames.
  • No configuration and is automatically appended to all BSSes on 2.4 GHz and 5 GHz radios on capable APs.

Reduced neighbor report information element

The reduced neighbor report IE is included in the beacon and probe response frames of the lower-band (2.4 GHz or 5 GHz) BSSID. The report includes fields for each neighbor BSS, if transmitting the same SSID in the 6 GHz band, along with channel and beacon offset.

The operating class and channel number refer to tables in IEEE 802.11 listing all possible channel widths and center frequencies. For 6 GHz, this guides the client device to the correct channel out of the possible 59 at 20 MHz, 29 at 40 MHz, etc. With this information, the client device can parse the RNR from a 2.4 GHz or 5 GHz BSSID and go directly to the channel in the 6 GHz band to find an equivalent SSID/BSSID.

The target beacon transmission time (TBTT) information in the reduced neighbor report refers to the beacon offset in time. The TBTT is measured in time units of 1.024 msec, and allows the client device to schedule an accurate time to go off-channel from the current AP and passively scan the beacon of the 6 GHz BSSID, subsequently authenticating if desired.

The full neighbor report could be used in place of the RNR, as a superset of the RNR information is contained with-in, but the standard promotes the latter because the RNR is shorter and more efficient. Reduced neighbor reports are supported on 6 GHz capable HPE Aruba Networking APs starting in AOS-8.9.

Example of a RNR IE found in a 5 GHz beacon frame pointing to a BSS on the same AP operating with the same SSID and 80 MHz channel width

Access network query protocol

The access network query protocol (ANQP) is a pre-association exchange protocol initially added for Passpoint operation. ANQP allows a client device to query an AP about capabilities such as Passpoint, information about the venue, and identity providers that can be reached for authentication. When used for 6 GHz WLANs, ANQP conveys a full neighbor report for 6 GHz BSSIDs that may be in the same WLAN, whether using the same SSID or different SSIDs. Transmitting the neighbor report element over ANQP rather than directly in the beacon or probe responses is more efficient, as air time is not consumed unless the client device requests the neighbor report.

In a multi-band network, BSSIDs in the lower bands (2.4 GHz or 5 GHz) could advertise ANQP capability, and multi-band client devices could request neighbor reports via ANQP, allowing them to discover full SSID, BSSID, channel and beacon offset information without leaving the lower band to receive or transmit in the 6 GHz band.

Automatic frequency coordination

The 6 GHz bands contain incumbent users, and for higher power or outdoor operation with standard power APs, the FCC requires that incumbents are protected from interference from unlicensed 6 GHz users, including Wi-Fi. Some areas of the band are not allowed, even under automatic frequency coordination (AFC) control. The available channels for higher power or outdoor operation are from 5945-6425 MHz and 6525-6875 MHz, the U-NII-5 and U-NII-7 bands.

Channels available for standard power under AFC in 6 GHz

Fortunately, the majority of incumbent, such as point-to-point fixed service, users are known, as they are licensed and their details are listed in the ULS database, maintained and updated by the FCC.

The general architecture for automatic frequency coordination (AFC) centers on an AP, or group of managed APs, generating an inquiry message that includes respective location, elevation, and indications of the desired transmit power levels, channels or frequencies for transmission. The AFC uses this information as input to algorithms along with ULS data of licensed links and a terrain map. Some AFC operators may add building outlines to their terrain map to identify RF shadows. The response from the AFC to the AP inquiry will include a range of channels or frequencies that are available, and the AP, or RRM can pick from this list and transmit. The FCC will license a number of AFC service providers. APs must check with an AFC at least every 24 hours to receive fresh information.

The general concept of AFC calculations is as follows. Each licensed receiver’s location, antenna pattern, elevation above ground, and sensitivity are taken from the ULS database and used to plot contours defining zones of interference for given transmit power levels. The example above shows one contour calculated for interference to the antenna A; another plot would be generated for antenna B.

As the antennas for point-to-point links are usually very high-gain, these plots are shaped like a keyhole, with a short-distance circle around the back for sidelobe sensitivity and a long path down the antenna boresight.

The contour is significant because any Wi-Fi transmitter within the contour and above the power threshold for which the contour is calculated would cause interference at the fixed link’s receive antenna and should not be allowed at that location, frequency, and transmit level.

Many plots or contours must be calculated and plotted depending on the power of the interfering signal, and terrain is taken into account to determine line-of-sight conditions or whether high ground obscures the path. AFCs may pre-calculate the contours to reduce response delays. The diagram above shows a set of contours from an AFC, calculated for different power levels for a single fixed link receiver.

The response from an AFC to an AP inquiry message may be either a list of available channels, or available frequency ranges, along with the maximum power levels available, or both. The graphical example shows how such information might be displayed on an AFC client application. The top row is a frequency range response, giving power spectral density limits for the various ranges. The lower levels show channel availability by transmit power level (coloring is not part of the AFC response). The example clearly shows fixed links near the location, and that these effectively exclude a number of channels in the response. The AP would only be allowed channel assignment from channels allowing viable operation.

Because AFC operation is not permitted in the U-NII-6 and U-NII-8 bands, the results shown in the diagram for those frequencies are invalid.

Note that the AFC does not grant a particular frequency to the AP; the AFC just indicates those channels, frequencies, and power levels that will not cause interference to incumbents. There is no attempt to allocate specific channels or coordinate different channels for neighboring APs or WLANs from the AFC provider. Those tasks are left up to the AirMatch RRM service.

2.2.2 - Planning and deployment

Planning and Deployment for Wi-Fi 6E.

Wi-Fi 6E is Wi-Fi 6 (IEEE 802.11ax PHY/MAC) operating in the 6 GHz band offering up to double or triple system capacity compared to previous generations. Note the 6 GHz band is not available in every regulatory domain (region). Ensure you comply with your local regulatory requirements before deploying Wi-Fi 6E.

Key design principles

  1. Enable 6 GHz by creating a multi-band SSID rather than creating a 6 GHz only SSID.
  2. Choose Enhanced Open for guest networks, WPA3-Personal for passphrase networks, and WPA3-Enterprise for 802.1X corporate networks.
  3. Assess your client device mix before enabling compatibility modes for WPA3 or Enhanced Open. Prefer to disable transition mode to improve security.
  4. Test new security modes like WPA3 and Enhanced Open in a controlled environment before widespread deployment.
  5. Consider enabling 802.11r (Fast Transition) for WPA3-Enterprise security modes.
    • Fast roaming can significantly reduce delays in service when a client transitions between neighboring APs and is crucial for latency sensitive applications like telephony (Voice over Wi-Fi).
  6. Plan for a capacity based design with overlapping primary and secondary coverage targets verified by end user devices.
    • In capacity based deployments, AP density may increase 0-10% in key usage areas. Survey, check, and validate for 6 GHz.
    • Coverage based deployments must be revisited and redesigned.
  7. Plan channel widths per band based on RF layering strategy and regulatory domain allocations.
    • For FCC (or other 1200 MHz domains) this generally means 20 MHz in 2.4 GHz, 20 or 40 MHz in 5 GHz, and 80 MHz in 6 GHz.
      • With sufficient channel reuse (low density), 160 MHz channel width can be used in 6 GHz.
      • With limited channel reuse (high density), like in large public venues, 40 MHz channel width in 6 GHz is desired.
    • For Europe (or other 500 MHz domains), this generally means 20 MHz in 2.4 GHz, 20 or 40 MHz in 5 GHz, and 40 MHz in 6 GHz.
  8. Disable lower management rates in all bands to reduce management frame overhead.
    • For example, removing 1, 2, 5.5, 6, 9, and 11 Mbps rates (across applicable bands) and possible based on coverage and client requirements.

Security requirements

Prior to Wi-Fi 6E, the first Wi-Fi generation to enforce security requirements with the introduction of a new PHY/MAC was Wi-Fi 4 (802.11n). Clients are penalized to 802.11a/b/g speeds when using wired equivalent privacy (WEP) or temporal key integrity protocol (TKIP).

Wi-Fi 6E operation in 6 GHz also introduces new required baseline security requirements. Wi-Fi Protected Access 3 (WPA3) or Enhanced Open are mandatory for Wi-Fi 6E deployments and adoption.

Legacy security protocols are not allowed in 6 GHz:

  • Open authentication
  • WEP, TKIP, WPA
  • WPA2

This means existing SSID deployments using WPA2-Enterprise (802.1X) or WPA2-Personal security modes cannot be enabled for 6 GHz.

This forces either configuration changes to existing SSIDs or new SSID deployment and client migrations.

Security mode options for 6 GHz:

  • Enhanced Open (OWE)
    • Leverages opportunistic wireless encryption (OWE) to replace Open System Authentication
    • Diffie-Hellman exchange encrypts all wireless traffic
    • Offers encryption without user authentication
    • MFP required
  • WPA3-Personal (SAE)
    • Simultaneous authentication of equals (SAE) replaces the one-way key generation found in WPA2-PSK with a Diffie-Hellman like key exchange
    • Hash-to-element (H2E) required for SAE PWE derivation as an industry response to the Dragonblood vulnerability
    • MFP required
  • WPA3-Enterprise
    • AKM:5 key management (SHA-256); CCMP-128 ciphers; MFP required
  • WPA3-Enterprise with GCM-256
    • AKM:5 key management (SHA-256); GCMP-256 ciphers; MFP required
  • WPA3-Enterprise 192-bit (CNSA)
    • AKM:12 key management (SHA-384); GCMP-256 ciphers; MFP required; strong EAP-TLS methods only (no mix and match, no PEAP)

Clients

Wi-Fi 6E support requires both driver and operating system support.

Recommendation is to always know and understand the capabilities of the clients being serviced by the APs in order to configure and plan accordingly.

Minimum versions required:

Software updates can improve the capabilities enabled by hardware. Recommend to periodically check release notes and update client OS and drivers.

SSID planning

With Wi-Fi 6E traditional dual-band enterprise SSID layouts must be considered for how they might evolve into a tri-band deployment.

Consider this deployment approach prior to Wi-Fi 6E.

2.4 GHz 5 GHz
Corporate (802.1X) Corporate (802.1X)
BYOD (802.1X) BYOD (802.1X)
Guest (Open) Guest (Open)
IoT (PSK)

Potential strategy after migrating to Wi-Fi 6E.

2.4 GHz 5 GHz 6 GHz
Corporate (802.1X) Corporate (802.1X)
BYOD (802.1X) BYOD (802.1X)
Guest (OWE) Guest (OWE)
IoT (PSK)

Multi-band SSIDs are recommended for the following reasons.

  • Traditional active/passive scanning does not scale well when adding up to 59 more 20 MHz channels in 6 GHz. HPE Networking APs automatically append Reduced Neighbor Reports (RNRs) to out-of-band (OOB) BSSes in 2.4 GHz and 5 GHz. When the client scans in 2.4 GHz or 5 GHz, the RNR acts as a seed telling the client exactly where to discover a 6 GHz network.
  • APs operating with a single radio and a 6 GHz-only will force clients to do in-band discovery which is a much slower discovery process and may cause a poor connection experience.
  • Multi-band SSIDs provide a fallback band when the 6 GHz band is not available due to pending frequency coordination (AFC) bring up or expiration.

In the majority of cases, multi-band SSIDs should restrict bands to 5 GHz and 6 GHz. In other words, use the infrastructure to restrict where clients can connect. This is due to the BSS selection (discovery and association) being primarily up to the client, however, after connection HPE Networking ClientMatch can be used to influence (nudge) the client to a more optimal band. For example, place 2.4 GHz only IoT clients on a 2.4 GHz only SSID. Place tri-band capable clients on a 5 GHz + 6 GHz multi-band SSID.

There are some options to consider when deciding whether to create a new SSID or modify the configuration of an existing SSID to enable 6 GHz.

Migrate all security modes

Migrate security modes of all SSIDs to WPA3-Enterprise, WPA3-Personal, or Enhanced Open (OWE) with a multi-band SSID across 5 GHz and 6 GHz.

If transition mode is disabled, this will remove all legacy client support and is applicable for certain greenfield deployments or pop-up event networks like HPE Discover where users are professionals who typically refresh their BYOD devices often.

Proceed with caution and understand the client population.

Single SSID approach

Band specific SSIDs

This option is to create a new SSID for exclusively for 6 GHz support.

Dual SSID approach

SSID-A dedicated to WPA3-only devices and 5 GHz + 6 GHz bands. Disable transition mode.

SSID-B dedicated to WPA2 and legacy devices on the 2.4 GHz and/or 5 GHz bands. This allows support for WPA2-only clients to connect and minimizes any impact of operational parameters with WPA3-transition causing client bugs due to poor implementation or outdated drivers.

This approach adds an additional SSID which does increase management frame overhead, but can be negated by trimming lower basic rates. In general, aim to keep the number of SSIDs per AP low.

Existing SSIDs

Certain SSIDs like Hotspot 2.0 passpoint SSIDs such as eduroam recommend a single multi-band SSID. This approach should be taken for other federated SSIDs like Govroam, OpenRoaming, Cityroam, etc.

Before:

Bands Security SSID
2.4 GHz + 5 GHz WPA2-Enterprise eduroam

After:

Bands Security SSID
5 GHz + 6 GHz WPA3-Enterprise eduroam

Transition mode may be enabled to maintain support for WPA2-Enterprise only clients. Test in a controlled environment before widespread deployment.

AP planning

Propagation loss of 6 GHz vs 5 GHz is similar, 1-2 dB, when comparing free space path loss (FSPL). Real world tests show an additional 3-6 dB difference depending on the frequency location in the 6 GHz band and measurement points.

An industry study also shows propagation loss through different common building materials will have different effect. For example, brick has a much larger impact than drywall. Plan to increase AP density for 6 GHz when interior walls are composed of thick, dense materials.

In existing high-density deployments there may be no changes required for AP placement, but depends on the effective power levels for 6 GHz compared to 5 GHz. Factors include channel width, LPI, and SP depending on the regulatory domain. As an example, in the FCC domain under LPI rules, an 80 MHz channel width achieves higher EIRP than a 20 MHz channel because the more restrictive limit is based on power spectral density (PSD) rather than total power.

In general, the recommendation is to always place APs close to users with an unobstructed view. For example, do not place APs above ceilings. Prioritize placing APs in critical areas such as conference or training rooms. APs in hallways may not sufficiently provide 6 GHz coverage and will require to be moved in room.

Always survey, test, and validate using target end user client devices before widespread deployment.

Channel planning

With up to 59 additional channels, there are two main channel width selection choices depending on regulatory domain.

graph TD;
    reg("Regulatory domain")
    fivehundo("500 MHz")
    twelvehundo("1200 MHz")
    twenties("20 MHz or 40 MHz")
    eighties("80 MHz or 160 MHz")
    reg-->fivehundo;
    reg-->twelvehundo;
    fivehundo-->twenties;
    twelvehundo-->eighties;

If the regulatory domain allows up to 1200 MHz, 80 MHz is recommended for most deployments as each channel will line up with a preferred scanning channel (PSC) which will optimize both in-band (PSC) and out-of-band (RNR) scanning.

Channel width # of channels in 1200 MHz
20 MHz 59
40 MHz 29
80 MHz 14
160 MHz 7

If the regulatory domain is restricted to the lower 500 MHz of the 6 Ghz band, 40 MHz channel width is recommended.

Channel width # of channels in 500 MHz
20 MHz 24
40 MHz 12
80 MHz 6
160 MHz 3

These recommendations primarily focus on Low Power Indoor (LPI) deployments.

For Standard power (SP) deployments, use 40 MHz channel width or 20 MHz if AP density is high (such as in LPV). Note that channel availability depends on frequency coordination.

Channel width # of channels in U-NII-5 + U-NII-7
20 MHz Up to 41
40 MHz Up to 20
80 MHz Up to 9
160 MHz Up to 4

Automatic frequency coordination

In general, 6 GHz usage falls under two categories.

  1. Low power indoor (LPI) - no frequency coordination.
  2. Standard power (SP) - frequency coordination mandatory.

Standard power APs need to be able to self-locate and submit geolocation information to an AFC provider. HPE Aruba Networking APs use a Frequency Coordination Orchestrator (FCO) service in Central to communicate with AFC.

Geolocation information can be collected in two different methods by HPE Aruba Networking APs.

  1. Positional data collected by the APs GPS/GNSS radio.
  2. An AP can leverage positional data broadcasted from a neighboring AP in AOS-8.13 and AOS-10.8 or later.

Multiple gigabit throughput planning

The maximum PHY rate on a given channel is determined by the channel width, RF environment, and MCS rates used by the client(s).

In the best case scenario, with the widest channel width and highest order MCS rate, these PHY data rates are possible.

Radio chains Wi-Fi 5 Wi-Fi 6/6E
1 0.8 Gbps 1.2 Gbps
2 1.7 Gbps 2.4 Gbps

The maximum data rate a client is capable of is determined by the client capabilities such as number of radio chains, maximum MCS rate and channel width supported on both sides of the link, of course along with the ideal RF conditions (SNR and EVM) to sustain those rates. Most clients have one or two radio chains. Consider that mobile clients with two radio chains sometimes disable one of two chains to conserve battery life.

The maximum throughput a single AP is capable of is determined by similar factors across each of the radios.

5 GHz
channel width
6 GHz
channel width
Total bandwidth Multiple gigabit capable Channel reuse
20 MHz 40 MHz 60 MHz No Yes
20 MHz 80 MHz 100 MHz No Yes*
40 MHz 80 MHz 120 MHz Yes Yes*
40 MHz 160 MHz 200 MHz Yes Yes*
80 MHz 160 MHz 240 MHz Yes No
160 MHz 160 MHz 320 MHz Yes No

In the majority of deployments, 2.4 GHz cannot be considered in AP system capacity planning due to limited channel reuse in the crowded ISM band.

Multiple gigabit needs are determined by the configured channel widths along with environmental and traffic patterns. Aggregate data throughput on a tri-band tri-radio AP can easily exceed 1 Gbps under certain conditions.

For example, in environments with a single client per band each using maximum channel widths and rates, multiple gigabit throughput can be achieved during saturation testing.

However, consider target traffic usage patterns and expectations and active client count. As the client count increments on the same channel, throughput is reduced due to the contention based mechanisms in the 802.11 protocol.

  1. Each client must wait the channel to become idle before transmitting (listen before talk)
  2. When a channel is busy, each client picks a random backoff timer from a contention window and waits that many slot times before transmitting. If a collision occurs, the window size increases, spreading out retry attempts to reduce further collisions.

Thus, each additional client on a given AP reduces throughput and extends transmit opportunity (TXOP) durations as clients content for the medium.

Multiple APs on different channels are a way to scale, up to the channel reuse limits in the neighboring area with the goal of minimizing co-channel interference as much as possible.

Additionally, expected traffic usage patterns are an important characteristic to consider when determining multi-gigabit to the AP is a requirement.

Power sourcing

Additional radios and capabilities come with increased power requirements. Tri-radio APs require more power than dual-radio APs — 802.3at/CL4 or better required. The AP-650 is the only series which can operate and combine two 802.3af/CL3 sources. 802.3bt/CL6 is recommended for new deployments.

AP series PoE standards PoE redundancy
600R No No
600H 802.3bt, 802.3at, 802.3af No
610 802.3at, 802.3af No
630 802.3bt, 802.3at Failover
650 802.3bt, 802.3at, 802.3af(x2) Sharing
670 802.3bt, 802.3at No

Intelligent power monitoring

Intelligent power monitoring or IPM is a method for controlling power usage of HPE Aruba Networking APs. The approach actively measures power usage and dynamically adapts the power budget and restrictions.

When IPM is disabled, static power management will apply reductions in order to not exceed worst case limits and stay within the confines of the power budget.

When IPM is enabled, dynamic power management allows the AP to enable full functionality and performance in the majority of cases.

Enabling IPM will allow for, in most cases, most features when tri-radio APs are powered by a 802.3at/CL4 PSE.

Recommendation is enable IPM.

2.3 - Wi-Fi 7

Overview of the IEEE 802.11be standard, information on features and benefits of Wi-Fi 7, technical specification, and implementation guidelines.

Wi-Fi 7 builds on previous generations supporting the 2.4 GHz, 5 GHz, and 6 GHz bands based on IEEE 802.11be. Wi-Fi 7 brings Multi-Link Operation (MLO) to Wi-Fi for the first time enabling devices to communicate on multiple links to the same AP. Additionally, Wi-Fi 7 improves speed with higher order MCS rates (4096-QAM) and latency with QoS features like restricted Target Wake Time (r-TWT), Stream Classification Service (SCS), and Triggered Uplink Access (TUA). Wi-Fi 7 comes with additional baseline security requirements of GCMP-256 and Beacon Protection.

2.3.1 - Features and benefits

Features and Benefits of Wi-Fi 7.

Wi-Fi 7 is a Wi-Fi Alliance certification program based on the IEEE 802.11be amendment aiming to improve latency, reliability, and performance over previous Wi-Fi generations. Work on the specification began in 2019, and the certification program launched in January 2024.

This generation targets use cases requiring high data bandwidth, low latency, and reliability, such as extended reality (VR/MR/AR), real-time applications, gaming, and cloud computing.

Wi-Fi 7 introduces a key feature called multi-link operation (MLO) for improved link reliability, 4096-QAM for higher peak PHY data rates, wider channel widths in 6 GHz, and enhanced QoS with features like stream classification service (SCS).

Like previous generations, Wi-Fi 7 uses techniques to ensure backward compatibility across all bands to provide connectivity for previous generations of clients.

Key features

Wi-Fi 7 builds and extends on the capabilities of previous generations to increase throughput, reduce latency, and enhance reliability.

  • Wi-Fi 7 can also leverage the 6 GHz band introduced by Wi-Fi 6E.

  • Multiple link operation (MLO) enables channel aggregation and failover, enabling clients connecting to Wi-Fi 7 access points to combine or alternate between links across multiple frequency bands (can also be two links in the same band). Traffic can be sent over the link with lower latency or traffic could be split between links for parallel transmission. If one of the links is congested or interference occurs, traffic can be shifted seamlessly to another more stable link to improve the connection robustness.

  • 4096 QAM (quadrature amplitude modulation) provides potentially higher peak data rates by enabling a 12-bit symbol to more densely embed greater amounts of data than before through MCS 12 and 13.

  • Channel bonding up to 320 MHz bandwidth in 6 GHz doubles the capacity of 160 MHz supported by Wi-Fi 6. The increase in bandwidth can reduce delays and improve overall transmission rates.

  • Improvements to OFDMA introduced in Wi-Fi 6 through Multi Resource Units (MRU).

  • Preamble puncturing helps accommodate and co-exist with interference in wide channels by allowing the 20 MHz subchannels containing interference to be disabled within wide channels. This is sometimes called a punctured transmission. Puncturing helps work around interference or other requirements while still enabling the remainder of wide channels to function for transmit and receive.

  • QoS improvements with triggered uplink access (TUA) using the stream classification service (SCS) framework.

  • Power saving enhancements to target wake time with restricted target wake time (r-TWT) providing a level of medium access protection in a restricted service period (SP).

Technology comparison

Wi-Fi 6 Wi-Fi 6E Wi-Fi 7
IEEE amendment 802.11ax 802.11ax 802.11be
Bands of operation 2.4, 5 6 2.4, 5, 6
Channel width 20, 40, 80, 160 20, 40, 80, 160 20, 40, 80, 160, 320
Modulation OFDM, OFDMA OFDM, OFDMA OFDM, OFDMA

6 GHz support

Like Wi-Fi 6E, Wi-Fi 7 also uses the 6 GHz band to increase capacity by using up to 1200 MHz of unlicensed spectrum depending on regulatory.

20 MHz-only operation

Wi-Fi 7 allows for 20 MHz-only operation which is aimed at IoT markets similarly as the same feature in Wi-Fi 6. 20 MHz-only operation allows for reduced implementation complexity, leading to low-power, lower-cost chips. Such clients can operate in 2.4 GHz, 5 GHz, and 6 GHz bands and support most of the mandatory Wi-Fi 7 features.

Increasing modulation complexity

Payloads in Wi-Fi are encoded using a technique called quadrature amplitude modulation (QAM) which encodes data by manipulating both the amplitude and phase of carrier waves. Each point in the QAM constellation represents a distinct symbol, with each symbol encoding multiple bits of information. Higher-order schemes allow more bits to be encoded per symbol, thus increasing spectral efficiency.

Building on digital modulation schemes in 802.11ax of up to 1024-QAM, 802.11be supports up to 4096-QAM. This means that each RF symbol represents one of 4096 possible combinations of amplitude and phase. The move from 1024-QAM to 4096-QAM increases number of bits carried per OFDM symbol from 10 to 12. This can result in up to a 25% increase in PHY data rates depending on environmental and capability support on both sides of the link.

256-QAM

1024-QAM

4096-QAM

Modulation and coding

802.11be adds a 12-bit symbol for 4096-QAM with coding rates of 3/4 and 5/6. The previous PHY rates remain available and are used during rate shifting when signal quality is insufficient to sustain higher rates.

Spatial Streams MCS index Modulation type Coding rate PHY rate (in Mbps)
20 MHz 40 MHz 80 MHz 160 MHz 320 MHz
1.6 μs GI 0.8 μs GI 1.6 μs GI 0.8 μs GI 1.6 μs GI 0.8 μs GI 1.6 μs GI 0.8 μs GI 1.6 μs GI 0.8 μs GI
1 0 BPSK 1/2 8 8.6 16 17.2 34 36 68 72 136 144
1 1 QPSK 1/2 16 17.2 33 34.4 68 72.1 136 144 272 288
1 2 QPSK 3/4 24 25.8 49 51.6 102 108.1 204 216 408 432
1 3 16-QAM 1/2 33 34.4 65 68.8 136 144.1 272 282 544 576.5
1 4 16-QAM 3/4 49 51.6 98 103.2 204 216.2 408 432 816.7 864.7
1 5 64-QAM 2/3 65 68.8 130 137.6 272 288.2 544 576 1088.9 1152.9
1 6 64-QAM 3/4 73 77.4 146 154.9 306 324.4 613 649 1225 1297
1 7 64-QAM 5/6 81 86 163 172.1 340 360.3 681 721 1361 1441
1 8 256-QAM 3/4 98 103.2 195 206.5 408 432.4 817 865 1633.3 1729.4
1 9 256-QAM 5/6 108 114.7 217 229.4 453 480.4 907 961 1814.8 1921.6
1 10 1024-QAM 3/4 122 129 244 258.1 510 540.4 1021 1081 2041.7 2161.8
1 11 1024-QAM 5/6 135 143.4 271 286.8 567 600.5 1134 1201 2268.5 2402
1 12 4096-QAM 3/4 146 155 293 310 613 649 1225 1297 2450 2594
1 13 4096-QAM 5/6 163 172 325 344 681 721 1361 1441 2722 2882

Note both 3.2 μs guard interval and BPSK-DCM are excluded from the table.

320 MHz channel width

Wi-Fi 7 adds support for 320 MHz channel width. Support is advertised in the control field of the EHT operation information element. Inside this element there is an operating class field which defines radio parameters such as channel width. The operating class for 320 MHz channel width is 137.

Note the out-of-band reduced neighbor report element in 2.4 GHz or 5 GHz may report operating class of 131 (20 MHz), 132 (40 MHz), 133 (80 MHz) or 134 (160 MHz) instead of 137. This is for interoperability with legacy clients which do not know of operating classes introduced in newer generations.

To better line up with differing countries regulatory spectrum allocations, there are two sets.

  1. 320 MHz-1 with channels 31, 95, and 159.
  2. 320 MHz-2 with channels 63, 127, and 191.

Technology advancements

  • EHT MU PPDU format used for all non-triggered transmissions.

  • EHT TB PPDU format used for all triggered transmissions.

  • New universal SIG (U-SIG) field to bring forward compatibility to the EHT preamble via new version independent fields. Duplicated in every 20 MHz sub-channel. U-SIG includes version-independent and version-dependent bits.

  • DL/UL OFDMA are adopted from Wi-Fi 6 as is.

  • Dynamic MU Spatial Multiplexing Power Save (SMPS) to allow clients to turn off a receive chain to reduce power consumption.

  • Packet extension gives additional Rx processing time for features like 4096-QAM.

  • Wi-Fi 7 adds support for multiple resource units (MRU) in orthogonal frequency division multiple access (OFDMA). This enables small or large multiple RUs to be allocated to the same client. The ability for clients to use MRUs enables more efficient and flexible usage of the available channel when using OFDMA.

  • Preamble puncturing with static and dynamic puncturing to disable 20 MHz subchannels for wide channel bandwidths when there is narrow interference. This feature along with MRU enables punctured transmissions around the disabled subchannels.

  • Compressed BA (C-BA) 256/512 bits to provide the ability to acknowledge (ACK) multiple MPDUs in a single block ack (BA).

  • Restricted target wake time (r-TWT) enables restricted service periods for clients to have better medium access for latency sensitive traffic. r-TWT provides more precise wake-up intervals and shorter durations to improve power consumption.

  • Triggered uplink access (TUA) optimization provides improved channel access through a scheduled period for latency sensitive uplink (UL) traffic. APs use the stream classification service (SCS) request frames from clients to schedule according to the requested QoS parameters.

  • BPSK-DCM (dual carrier modulation) provides a 1-bit low rate MCS (14 and 15) with higher range, robustness, and interference mitigation at the cost of speed. These are optional rates.

Multi-link operation (MLO) is a key mandatory feature of Wi-Fi 7 enabling, for the first time in Wi-Fi, clients to associate and transmit and/or receive over more than one link or band at a time to a single AP.

A MLO-capable device is referred to as a multi-link device (MLD). In the MLD framework, the links can be across multiple bands or with-in the same band.

The primary benefit of multi-link operation is communication between to multi-link devices on non-overlapping frequency.

  • Improved reliability and robustness. A client can seamlessly alternate between links when one of the links degrades without re-associating.
  • Improved support for lower latency by fast failover between links or aggregating links.
  • Higher aggregate throughput. Certain, optional, MLD types can leverage and combine multiple links at the same time, potentially improving throughput.

All Wi-Fi 7 clients are required to support basic multi-link operation (MLO) over multiple links with the ability to discover, authenticate, (re)associate, (re)setup of links, and support of multi-link control (MLC) frames.

Architecture

Multi-link operation (MLO) architecture splits the multi-link device (MLD) into two MAC layers.

Upper MLD (U-MAC) functions:

  • (Re)association is at this layer
  • Security association (PMKSA)
    • SN/PN assignments for unicast frames
    • Unicast encryption/decryption
  • Link selection based on TID mapping
  • Block ACK score boarding for unicast frames
Lower MLD (L-MAC) functions:
  • Channel access
  • Control frames such as RTS and CTS
    • Block ACK (BA) sent in sync with upper MLD score boarding
  • Beacons
  • Broadcast frame transmission, encryption, decryption
  • Power save state

MLO management

For any disruptive AP operations (link removal, new configuration, etc.) there are 2 methods available to manage MLO operation.

  1. Multi-link reconfiguration (AP removal)

    • Multi-link reconfiguration is stateless and enables the stop and restart data traffic activity on one or more links. This may lead to client reassociation to the same AP with ‘other links’ and depends on the client implementation.
  2. Advertised traffic identifier (TID) to link mapping (T2LM)

    • Advertised TID-to-link mapping is stateful and can disable data traffic on a link for a short duration after which the link is reenabled and maintains client association.
    • Used when AP needs to temporarily disable a link in a multi-link setup
    • Similar idea to multi-link reconfiguration, client can use remaining link to avoid reassociation.
    • When the AP brings the link back. The client can reuse.

Load balancing

AP MLDs can help influence link usage through BSS transition management frames (query, request, response) where the AP recommends one or more links for the client to operate on. This link recommendation feature provides clients the option to more quickly switch to links with less interference and spend less time contending for the medium on a link with more interference.

The AP MLD must signal BSS critical updates (operational parameters) to client MLDs through a BSS parameters change count (BPCC). This update framework enables the client to track updates on all links by monitoring management frames on one link. Thus, clients can determine if they need to look for updated parameters on the link where a critical update occurred.

Examples of critical updates include:

  • Channel switch announcements (CSA)
  • Broadcast target wake time (b-TWT)
  • Modification of HT, VHT, HE, or EHT operation elements

MLO MAC addressing

MLO devices have two types of MAC addresses. A MLD MAC and a per-link MAC.

The client (STA) MLD MAC (p) address and AP MLD MAC (m) address are addressable over the local network meaning they are used for resolving ARPs.

The MAC addresses for each link, (w), (x), (y), (z) are ’link local’ and not used to populate address fields in frames sent beyond their respective boundaries.

Certain HPE Aruba Networking CLI show commands are enhanced to show both MLD and per-link MAC addresses.

show ap association mlo
show ap debug client-table mlo

Device types

There are different types of MLD operation device types offer varying capabilities. The MLD type a client supports can be influenced by the bands presented by the ESS. For example, if all three 2.4 GHz, 5 GHz, and 6 GHz bands are presented, the client could support one type when setting up a MLD with 2.4 GHz and 6 GHz links, but a different type when setting up a MLD with 5 GHz and 6 GHz.

Number of radios Concurrent Tx on multiple links Concurrent Rx on multiple links Tx on a link(s) and Rx on other link(s) simultaneously Simultaneous carrier sense on multiple links Spatial stream switching capability between links MLD device type
1 (single radio (SR)) NO NO NO NO NO Multi-link single radio (MLSR)
1 (single radio (SR)) NO NO NO ✅ (Enhanced) Enhanced multi-link single radio (EMLSR)
>=2 (multi radio (MR)) ✅ (Simultaneous Tx Rx (STR)) NO Simultaneous transmit receive multi-link multi-radio (STR MLMR)

A multi-link single radio (MLSR) device is a MLD which switches links to operate on any one link at a time. A MLSR MLD is not able to do carrier censing on multiple links at once. The MLSR client MLD controls the link for downlink traffic from the AP mld using power save (PS) polling.

An enhanced multi-link single radio (EMLSR) device is a MLD which can only transmit (Tx) to or receive (Rx) data frames from another MLD on a single link. The enhanced part of EMLSR is the ability to carrier sense on multiple links at the same time.

Carrier sense on each link is accomplished using a single spatial stream (radio chain). If the AP MLD needs to transmit a data frame to an EMLSR device on one of the links, the AP initiates a control frame exchange (RTS, MU-RTS). While the AP MLD receives the CTS frame on the target link, the EMLSR device reconfigures the radio to switch over the spatial streams from other links to be ready for data reception.

No need to reconfigure or transition radio chains between links.

Security requirements

The following security parameters for Wi-Fi 7 are required in all bands for Wi-Fi 7 connections:

  • Security modes
    • WPA3-SAE-GDH (AKM:24/FT AKM:25) when using WPA3-Personal
    • Hash-to-element (H2E) for SAE PWE derivation required when using WPA3-Personal
    • Enhanced open when using open networks
  • Beacon protection to enable clients to verify the integrity of beacon frames
  • GCMP-256 ciphers
  • PMF (802.11w)

Beacon protection

The december 2020 update of WPA3 introduced an optional feature called beacon protection to protect against active attacks attempting to exploit clients through forged signaling information to nudge clients to rogue APs. Wi-Fi 7 requires beacon protection to enable the AP to provision clients with integrity keys during security association.

A beacon integrity group temporal key (BIGTK) is used for beacon frame protection. The beacon integrity packet number (BIPN) is the BIGTK packet number used to calculate the MIC in the MME.

The BIGTK is then distributed to the client in message 3 of the 4-way handshake and group key handshake. The client is then enabled with information to validate, and further act on, integrity checks.

The management MIC (MME) element is appended to the beacon frame as the last element preceding the FCS providing message integrity to protect group addressed management frames and protected beacon frames from forgery and replay.

GCMP-256

GCMP is based on the GCM of the AES encryption algorithm. GCM protects the integrity of the MPDU and provides data confidentiality, integrity, and replay protection. AES processing used with-in GCMP-256 uses AES with a 256-bit key, hence GCMP-256. Wi-Fi 7 clients must support GCMP-256 as a unicast cipher.

PMF

PMF was introduced in 802.11w-2009 as an optional feature to provide integrity and encryption mechanisms for certain management frames. Wi-Fi 7 connections must use PMF. Learn more about PMF.

SAE-GDH

When using WPA3-Personal and Wi-Fi 7, the client must use simultaneous authentication of equals (SAE) with group dependent hashing (SAE-GDH) in all bands. The AKM selectors for SAE-GDH are AKM:24 and Fast Transition (802.11r) AKM:25.

The Diffie-Hellman (DH) group used will determine the hash algorithm / elliptic curve. Group selection is determined by support on both sides of the link and client preference during the commit phase of SAE.

DH group Hash algorithm Requirement
21 SHA-512 / 521-bit ECC Optional
20 SHA-384 / 384-bit ECC Optional
19 SHA-256 / 256-bit ECC Mandatory

Comparatively, previously WPA3-Personal with AKM:8 used the same SHA-256 hash algorithm for all DH groups.

MLD security

After association, the client (STA) MLD and AP MLD derive keys via the 4-way handshake. The entire handshake performed on a single link.

The pairwise master key (PMK) is derived using the MLD MAC addresses on both, the client MLD and the AP MLD. The PMK is used for generating PTK which is used for encrypting unicast frames. Same PTK is used across all the links setup in an multi-link association between an AP MLD and a client (STA) MLD.

Groupwise Transient Key (GTK) is unique per-link for all the links in the AP MLD. Each link uses its own GTK to encrypt groupcast frames.

There are new elements added in Message 2 and 3 of the existing 4-way key handshake to convey MLD MAC address to generate keys and per-link GTKs. Encryption of data frames does not require knowledge of link selection.

Multiple resource units

802.11be adds support for multiple resource units (MRU) where the previous generation only supports single resource units (RU). In Wi-Fi 6, clients could only use one resource unit at a time. In Wi-Fi 7, clients can use multiple adjacent or non-adjacent resource units.

Preamble puncturing

Preamble puncturing was introduced in IEEE 802.11ax (Wi-Fi 6) as an optional method to more efficiently use wider channel widths in the presence of narrow interference.

There are two types of puncturing.

  1. Static puncturing
  2. Dynamic puncturing

Wi-Fi 7 introduces static puncturing as mandatory in the 6 GHz band. Puncturing requires a minimal channel width of 80 MHz enabling clients to avoid using portions of 80 MHz, 160 MHz, or 320 MHz channels. Puncturing is not supported when the AP is operating on 20 MHz or 40 MHz channel widths.

Puncturing along with multiple resource units (MRU) enables flexible use of the remaining non-punctured channel bandwidth. OFDMA MRU distribution is then allocated in the available subchannels around the punctured subchannel.

The AP includes a disabled subchannel bitmap present in the EHT operation parameters and disabled subchannel bitmap in the EHT operation element.

Example puncturing the second to last 20 MHz subchannel using a Google Pixel 8 generating traffic via iPerf

Puncturing removes the PHY preamble which is normally duplicated for each 20 MHz subchannel of the bonded set. The resolution of puncturing is always in 20 MHz channel width increments e.g., 20 MHz or 40 MHz.

2.3.2 - Planning and deployment

Planning and Deployment for Wi-Fi 7.

Wi-Fi 7 (IEEE 802.11be PHY/MAC) operates in the 2.4 GHz, 5 GHz, and 6 GHz bands introducing new features and improvements over Wi-Fi 6 and 6E.

Key design principles

  1. For 6 GHz band guidance, refer to the Wi-Fi 6E planning and deployment guidelines. Wi-Fi 7 builds on Wi-Fi 6E requirements.
  2. Create a dedicated SSID for Wi-Fi 7 to enable new features without disrupting legacy clients. For federated SSIDs (eduroam, Govroam, OpenRoaming), modify the existing SSID with staged testing.
  3. Configure MLDs to advertise 5 GHz + 6 GHz bands only. Reserve 2.4 GHz for legacy clients on a separate SSID to avoid unpredictable link selection.
  4. Choose Enhanced Open for guest networks, WPA3-Personal for passphrase networks, and WPA3-Enterprise for 802.1X corporate networks. Wi-Fi 7 requires GCMP-256 unicast ciphers and Beacon Protection across all bands.
  5. Assess your client device mix before enabling WPA3-Personal mixed mode (sae-sub-mode). Prefer GCMP-256 only operation where client support allows.
  6. Do not design for 100% coverage at 4096-QAM MCS rates. Hyper-dense AP placement creates excessive co-channel interference. Balance coverage targets against channel reuse.
  7. Mount APs below ceilings with an unobstructed RF path to clients. Match AP and antenna type (omnidirectional vs. directional) to the environment and density requirements.
  8. Plan for a capacity-based design with overlapping primary and secondary coverage zones. Brownfield deployments may require 0–10% more APs in high-usage areas.
  9. Use 802.3bt/CL6 PoE for new deployments. Enable Intelligent Power Monitoring (IPM) to maximize feature availability on 802.3at/CL4 powered APs.
  10. Ensure cabling plant supports Power over Ethernet (PoE) and speed requirements.
  11. Always survey, test, and validate with target client devices before widespread deployment.

AP planning

Wi-Fi 7 introduces two new MCS rates for 4096-QAM. When planning new deployments, avoid designing for complete coverage at signal levels required for these highest-order modulation rates. Doing so leads to hyper-dense AP placement and excessive co-channel interference (CCI). Instead, take a balanced approach that optimizes channel reuse within your regulatory domain.

AP placement is important which means do not place APs above ceilings. They need to have an unobstructed view to the end users. Be strategic about AP models, omnidirectional vs. directional APs and antennas, and place APs strategically to take advantage where possible.

AP placement and antenna selection

Plan to mount APs below the ceiling with an unobstructed RF path to client devices. Avoid above-ceiling or above-obstruction installations, which will attenuate signal and waste radiated power.

Deliberately plan AP and antenna selection:

  • Omnidirectional APs or antennas may be used for carpeted office spaces where 360 degree coverage is ideal. A trade off can be increased co-channel interference in high to hyper dense deployments.
  • Directional APs or antennas help focus energy in high-density areas, reduce signal bleed into adjacent rooms and spaces, and lower co-channel interference.

Match antenna type and AP model to the environment - what works in a carpeted office won’t be suitable for a warehouse or outdoor deployments.

Design philosophy

Plan for a capacity-based design with overlapping primary and secondary coverage zones. For brownfield deployments, this may mean adding 0–10% more APs in targeted locations such as conference rooms, training rooms, or atriums where coverage or capacity was previously insufficient.

Validation

Always survey, test, and validate with deployed end user devices before widespread deployment.

Security

Similar to the security requirements that came Wi-Fi 6E, Wi-Fi 7 also requires use of WPA3 or Enhanced Open along with some additional changes.

Wi-Fi 7 requires clients to support GCMP-256 unicast ciphers and Beacon Protection. These changes affect all bands instead of just the 6 GHz band like with Wi-Fi 6E.

WPA3-Personal

Wi-Fi 7 updates to WPA3-Personal include:

  • GCMP-256 unicast ciphers
  • Beacon Protection
  • Hash-to-element (H2E) for PWE derivation in all bands
  • SAE with group dependent hashing (GDH) using AKM:24 and (FT AKM:25 supported starting in AOS-10.8)

The sae-sub-mode configuration for WPA3-Personal controls legacy, mixed-mode, or GCMP-256 only operation.

There is a transition mode and sae-sub-mode configuration which enables support for different combinations of security parameters.

SAE sub mode Key management Unicast cipher advertisement Broadcast Integrity Protocol Effect
legacy AKM:8
(FT-AKM:9)
CCMP-128 BIP-CMAC-128 Legacy mode operating with greatest interoperability
mix-mode AKM:8+24
(FT-AKM:9+25)
CCMP-128
GCMP-256
BIP-CMAC-128 Mixed mode supporting legacy and new
gcm256-only-mode AKM:24
(FT-AKM:25)
GCMP-256 BIP-GMAC-256 Restrict to Wi-Fi 7 only, no interop with legacy

Transition mode support will enable support for WPA2-Personal only devices by advertising legacy WPA2-PSK AKMs and make protected management frames optional in the 2.4 GHz and 5 GHz bands. Note that transition mode is not supported with the sae-sub-mode is set to gcm256-only-mode. Recommendation is to migrate away from transition mode to prevent downgrade attacks.

SSID planning

New SSID approach

A new SSID is recommended. Create a dedicated SSID for Wi-Fi 7 clients. This offers the following benefits:

  • Enable Wi-Fi 7 features (MLO, 4096-QAM, etc.) without affecting legacy clients
  • Roll out incrementally and validate behavior before broader adoption
  • Isolate troubleshooting if issues arise

Existing SSID approach

An existing SSID can be modified to support Wi-Fi 7, but changing the security type on a live network may disrupt legacy clients. Particularly in BYOD environments where you don’t control the device configuration.

This approach may be necessary for federated SSIDs such as eduroam, Govroam, or OpenRoaming, where the solution provider typically mandates a single SSID. In these cases, careful planning and staged testing are essential to understand the impact on existing clients before committing to production changes.

MLO consideration

With Multi-Link Operation (MLO), the client, not the AP, determines which links to use during setup. When the AP MLD advertises all three bands, clients may select different link combinations at association:

If all three 2.4 GHz, 5 GHz, and 6 GHz bands are presented to a client, the client may choose different link combinations at different association times.

Possible tri-band link combinations
2.4 GHz + 5 GHz
2.4 GHz + 6 GHz
2.4 GHz + 5 GHz + 6 GHz
5 GHz + 6 GHz

In most deployments, reserve 2.4 GHz for legacy 2.4 GHz only clients. Configure the SSID to advertise on only 5 GHz + 6 GHz bands. This can avoid unpredictable link selection and keeps 2.4 GHz from being inadvertently used by high-performance clients.

Power Sourcing

Additional radios and capabilities come with increased power requirements. Tri-radio APs require more power than dual-radio APs — 802.3at/CL4 PoE or better required. 802.3bt/CL6 PoE is recommended for new deployments.

Intelligent Power Monitoring

Intelligent power monitoring or IPM is a method for controlling power usage of HPE Aruba Networking APs. The approach actively measures power usage and dynamically adapts the power budget and restrictions.

When IPM is disabled, static power management will apply reductions in order to not exceed worst case limits and stay within the confines of the power budget.

When IPM is enabled, dynamic power management allows the AP to enable full functionality and performance in the majority of cases.

Enabling IPM will allow for, in most cases, most features when tri-radio APs are powered by a 802.3at/CL4 PSE.

Recommendation is enable IPM.

3 - Wi-Fi security

In-depth information and best practices for securing wireless networks.

3.1 - Security modes

Discover details around WPA3 and Enhanced Open security modes, details of the ciphers, key management, and features behind them, and best practices for implementation.

In an increasingly interconnected world, secure and reliable Wi-Fi communication is a must-have. Across home offices to industrial environments to enterprise networks, Wi-Fi has become a crucial part ofmobile connectivity. As the reliance on Wi-Fi networks has grown, so has the security to protect and ensure privacy for sensitive data.

Enhanced Open and Wi-Fi Protected Access version 3 (WPA3) are the current advancements in Wi-Fi security standards from the Wi-Fi Alliance (WFA), designed to address weaknesses of their predecessors WPA2 and Open networks. The security modes sections aim to provide insights into Enhanced Open and WPA3 networks with HPE Aruba Networking deployments, exploring key components, practical implications, and best practices. Deployment considerations and compatibility aspects will be discussed.

Authentication and key management (AKM)

The security solutions used in Wi-Fi networks are defined by the IEEE 802.11 standards and Wi-Fi Alliance. Each security protocol has a specific authentication and key management (AKM) suite type (number).

The standard defines AKM suite selectors with a format of OUI:N where N represents the suite type. The standards based AKMs are denoted by an OUI of 00-0F-AC. For example, the suite selector for WPA3-Personal (wpa3-sae-aes) is 00-0F-AC:8. The corresponding pages refer to 00-0F-AC:N as AKM:N.

The Wi-Fi Alliance (WFA) defines security certifications by AKM, cipher suites, and Protected Management Frame (PMF) combinations. The following is used to indicate the different authentication types defined in the standard and their corresponding Wi-Fi Alliance certification program label:

WFA Mode IEEE AKM Description
WPA2-Enterprise AKM:1 IEEE 802.1X with SHA-1
WPA2-Personal AKM:2 Pre-Shared Key (PSK)
WPA3-Enterprise AKM:5 IEEE 802.1X with SHA-256
WPA3-Personal AKM:8 Simultaneous Authentication of Equals (SAE)
WPA3-Enterprise 192-bit AKM:12 IEEE 802.1X with SHA-384 using CNSA Suite compliant ciphers and EAP method
Enhanced Open AKM:18 Opportunistic Wireless Encryption (OWE)
WPA3-Personal AKM:24 Simultaneous Authentication of Equals (SAE) with a variable hash algorithm depending on Diffie-Hellman (DH) group (SHA-256, SHA-384, or SHA-512)

Wi-Fi Alliance programs

This section details the specifications defined by the Wi-Fi Alliance security certifications. A following section will map them to the security modes implemented by HPE Aruba Networking in AOS.

Enhanced Open

The Wi-Fi Alliance Enhanced Open specification defines the following:

  • Enhanced Open based on Opportunistic Wireless Encryption (OWE) defined in RFC 8110 (AKM:18)

WPA3

The Wi-Fi Alliance WPA3 specification defines the following:

  • WPA3-Personal (AKM:8, Wi-Fi 7 uses AKM:24)
  • WPA3-Personal Transition (AKM:2 + AKM:8)
  • WPA3-Enterprise Only (AKM:5)
  • WPA3-Enterprise Transition Mode (AKM:1 + AKM:5)
  • WPA3-Enterprise 192-bit mode (AKM:12)

Corresponding AOS security modes

Wi-Fi Alliance Mode AOS Key Management AOS Security Mode (opmode)
Enhanced Open Enhanced Open enhanced-open
WPA3-Personal WPA3-Personal wpa3-sae-aes
WPA3-Enterprise WPA3-Enterprise (CCM 128) wpa3-aes-ccm-128
Not defined by WFA WPA3-Enterprise (GCM 256) wpa3-aes-gcm-256
WPA3-Enterprise 192-bit WPA3-Enterprise (CNSA) wpa3-cnsa

6 GHz operation

Wi-Fi 6E is Wi-Fi 6 ‘extended’ to include the 6 GHz band. Extending operation into the 6 GHz band was an opportunity to leave behind some of the legacy requirements which exist for operation in the 2.4 GHz and 5 GHz bands.

The Wi-Fi Alliance (WFA) made the decision to require WPA3 or Enhanced Open as the minimum security modes allowed in the 6 GHz band.

The following legacy security modes not allowed in 6 GHz operation include:

  • WPA2-Enterprise or the corresponding transition mode*
  • WPA2-Personal or the corresponding transition mode*
  • Open, WPA version 1, TKIP, or WEP

Terminology

The following terminology is used throughout the various security mode sections. For additional information, refer to sources mentioned below.

  • AKM – Authentication and Key Management
  • BSS – Basic Service Set
  • CNSA – Commercial National Security Algorithm
  • DH – Diffie-Hellman
  • Enhanced Open – Wi-Fi Alliance certification based on OWE protocol
  • FT - Fast (BSS) Transition for improving handoff between APs
  • IEEE – Institute of Electrical and Electronics Engineers
  • OWE – Opportunistic Wireless Encryption
  • MFP – Management Frame Protection (see PMF)
  • MFPC – Management Frame Protection Capable
  • MFPR – Management Frame Protection Required
  • PMF – Protected Management Frame (see MFP)
  • PMK – Pairwise Master Key
  • RSNE – Robust Security Network Element
  • SAE – Simultaneous Authentication of Equals protocol used by WPA3-Personal
  • WFA – Wi-Fi Alliance
  • Wi-Fi 6 – Based on IEEE 802.11ax (HE)
  • Wi-Fi 6E – Wi-Fi 6 extended to include the 6 GHz band
  • Wi-Fi 7 – Based on IEEE 802.11be (EHT)
  • WPA2 – Wi-Fi Protected Access version 2
  • WPA3 – Wi-Fi Protected Access version 3

Sources and references

  • IEEE 802.11-2016
  • IEEE 802.11-2020
  • RFC 5759 – Suite B Certificate and Certificate Revocation List (CRL) Profile
  • RFC 6460 – Suite B Profile for Transport Layer Security (TLS)
  • RFC 6379 – Suite B Cryptographic Suites for IPsec
  • RFC 7268 – RADIUS Attributes for IEEE 802 Networks
  • RFC 8110 – Opportunistic Wireless Encryption
  • WPA3 Specification version 3.0
  • WPA3 Specification version 3.1
  • WPA3 Specification version 3.2

Decoder ring

Security Mode
(opmode)
AKM Hash Algorithm FT AKM Cipher Suite Group Management PMF
WPA3 Personal(1)
Transition Mode Enabled
(wpa3-sae-aes)
2.4 / 5 GHz:
AKM:2
AKM:8
6 GHz:
AKM:8
2.4 / 5 GHz:
SHA-1
SHA-256
6 GHz:
SHA-256
2.4 / 5 GHz:
AKM:4
AKM:9
6 GHz:
AKM:9
CCM-128 BIP-CMAC-128 2.4 / 5 GHz:
MFPR=0 MFPC=1
6 GHz:
MFPR=1 MFPC=1
WPA3 Personal(1)
Transition Mode Disabled
(wpa3-sae-aes)
2.4 / 5 / 6 GHz:
AKM:8
2.4 / 5 / 6 GHz:
SHA-256
2.4 / 5 / 6 GHz:
AKM:9
CCM-128 BIP-CMAC-128 2.4 / 5 / 6 GHz:
MFPR=1 MFPC=1
WPA2 Enterprise(2)
(wpa2-aes)
2.4 / 5 GHz:
AKM:1
2.4 / 5 GHz:
SHA-1
2.4 / 5 GHz:
AKM:3
CCM-128 N/A 2.4 / 5 GHz:
MFPR=0 MFPC=0
WPA3 Enterprise(3)
(wpa2-aes + MFP-R)
2.4 / 5 GHz:
AKM:5
2.4 / 5 GHz:
SHA-5
2.4 / 5 GHz:
AKM:3
CCM-128 BIP-CMAC-128 2.4 / 5 GHz:
MFPR=1 MFPC=1
WPA3 Enterprise CCM 128
Transition Mode Enabled(4)
(wpa3-aes-ccm-128)
2.4 / 5 GHz:
AKM:1
AKM:5(5)
6 GHz:
AKM:5
2.4 / 5 GHz:
SHA-1
SHA-256(5)
6 GHz:
SHA-256
2.4 / 5 / 6 GHz:
AKM:3
CCM-128 BIP-CMAC-128 2.4 / 5 GHz:
MFPR=0 MFPC=1
6 GHz:
MFPR=1 MFPC=1
WPA3 Enterprise CCM 128
Transition Mode Disabled(4)
(wpa3-aes-ccm-128)
2.4 / 5 / 6 GHz:
AKM:5
2.4 / 5 / 6 GHz:
SHA-256
2.4 / 5 / 6 GHz:
AKM:3
CCM-128 BIP-CMAC-128 2.4 / 5 / 6 GHz:
MFPR=1 MFPC=1
WPA3 Enterprise GCM 256
(wpa3-aes-gcm-256)
2.4 / 5 / 6 GHz:
AKM:5
2.4 / 5 / 6 GHz:
SHA-256
2.4 / 5 / 6 GHz:
AKM:3
GCMP-256 BIP-GMAC-256 2.4 / 5 / 6 GHz:
MFPR=1 MFPC=1
WPA3-Enterprise CNSA (192-bit)
(wpa3-cnsa)
2.4 / 5 / 6 GHz:
AKM:12
2.4 / 5 / 6 GHz:
SHA-384
(6) GCMP-256 BIP-GMAC-256 2.4 / 5 / 6 GHz:
MFPR=1 MFPC=1
  1. wpa3-sae-aes with AKM:24 is not yet supported in AOS.
  2. wpa2-aes is not typically deployed with PMF due to lack of support by WPA2 clients.
  3. wpa2-aes with PMF configuration set as required removes AKM:1 (802.1X with SHA-1) and adds AKM:5 (802.1X with SHA-256) which is effectively WPA3 only. Please review caveats on the WPA3-Enterprise page.
  4. Transition mode for WPA3-Enterprise CCM 128 is supported starting in AOS 8.11 and 10.5. Transition mode has no effect on operation in AOS 8.10 and 10.4.
  5. WPA3-Enterprise CCM 128 with transition mode enabled adds AKM:5 (802.1X with SHA-256) in the 2.4 GHz and 5 GHz bands starting in AOS 8.11 and 10.5. When transition mode is disabled, AKM:1 (802.1X with SHA-1) is not advertised.
  6. There is no compatible FT AKM for CNSA.

See the following subpages to learn more:

3.1.1 - WPA3-Enterprise

802.1X with CCM 128, GCM 256, and CNSA security levels.

HPE Aruba Networking offers three different modes of operation for WPA3-Enterprise: CCM 128, GCM 256, and CNSA.

  • CCM 128 offers the widest compatibility, including WPA2-certified clients when deployed in transition mode.
  • GCM 256 restricts to WPA3-certified clients that support GCMP-256 ciphers.
  • CNSA (192-bit) constrains the available options used with WPA3-Enterprise with the intent to raise the bar of attack sophistication making CNSA suitable for some of the highest levels of data protection.

WPA3-Enterprise CCM 128

WPA3-Enterprise CCM 128 meets the requirements for two modes of operation for WPA3-Enterprise as specified by the Wi-Fi Alliance.

  • “WPA3-Enterprise transition mode” which advertises key management for both WPA2-Enterprise and WPA3-Enterprise clients and sets PMF to optional (when operating in the 2.4 GHz and 5 GHz bands).
  • “WPA3-Enterprise only mode” which advertises key management for only WPA3-Enterprise configured clients and requires PMF (across all bands of operation). This is the behavior when transition mode configuration is explicitly disabled.

WPA3-Enterprise CCM 128 in transition mode (default behavior) advertises or negotiates the following capabilities in beacons, probe response, or association in the 2.4 GHz and 5 GHz bands of operation:

  • AKM suite selectors include 00-0F-AC:1 (802.1X with SHA-1) and 00-0F-AC:5 (802.1X with SHA-256).
  • Protected Management Frames are capable and automatically set as optional (MFPR=0 and MFPC=1).
  • This mode supports both WPA2-Enterprise only clients to connect with WPA2 (AKM:1) and WPA3-Enterprise capable clients to connect with WPA3 (AKM:5).

WPA3-Enterprise CCM 128 with transition mode disabled (WPA3-Enterprise only mode) advertises or negotiates the following capabilities in beacons, probe response, or association in the 2.4 GHz and 5 GHz bands of operation:

  • AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
  • Protected Management Frames are required and automatically set as mandatory (MFPR=1 and MFPC=1).
  • This mode only supports WPA3-Enterprise capable client connection with WPA3 (AKM:5).

When operating in the 6 GHz band, WPA3-Enterprise CCM 128 is automatically set as “WPA3-Enterprise only mode”, and advertises or negotiates the following capabilities in beacons, probe response, or association:

  • AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
  • Protected Management Frames are required and automatically set as mandatory (MFPR=1 and MFPC=1).
  • This mode only supports WPA3-Enterprise capable client connection with WPA3 (AKM:5).

WPA3-Enterprise CCM 128 advertises or negotiates the following ciphers in all modes of operation in beacons, probe response, or association:

  • Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).

AOS 8.11+ and 10.5+

The behavior for WPA3 Enterprise CCM 128 in AOS 8.11 and 10.5 or later is as follows:

  • Support for transition mode is introduced for WPA3-Enterprise CCM 128.
  • When transition mode is enabled (default), the behavior is as follows:
    • 2.4 GHz and 5 GHz operation:
      • Both 00-0F-AC:1 (802.1X with SHA-1) and 00-0F-AC:5 (802.1X with SHA-256) are advertised in the RSNE.
      • Capable clients can negotiate using WPA2 or WPA3. Client picks which.
      • PMF is optional (MFPR=0 and MFPC=1).
    • 6 GHz operation:
      • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
      • PMF is required (MFPR=1 and MFPC=1).

WPA3-Enterprise Transition Mode (CCM 128) RSNE example

  • When transition mode is disabled, the behavior for WPA3-Enterprise CCM 128 is as follows:
    • 2.4 GHz and 5 GHz operation:
      • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
      • WPA2-Enterprise only clients will not connect. Transition mode disabled forces WPA3 connections.
      • PMF is required (MFPR=1 and MFPC=1).
    • 6 GHz operation:
      • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
      • PMF is required (MFPR=1 and MFPC=1).

WPA3-Enterprise Only (CCM 128) RSNE example

AOS 8.10 and 10.4

The behavior for WPA3 Enterprise CCM 128 in AOS 8.10 and 10.4 is as follows:

  • Transition mode configuration has no effect on operation.
  • 2.4 GHz and 5 GHz operation:
    • 00-0F-AC:1 (802.1X with SHA-1) is advertised in the RSNE.
    • PMF is optional (MFPR=0 and MFPC=1).
  • 6 GHz operation:
    • 00-0F-AC:5 (802.1X with SHA-256) is advertised in the RSNE.
    • PMF is required (MFPR=1 and MFPC=1).

Workaround

If there is a requirement to restrict connectivity to “WPA3-Enterprise Only Mode” while using CCMP-128 ciphers on AOS 8.10 or 10.4 deployments, consider the following workaround and caveats:

  • The WPA2-Enterpise security mode (wpa2-aes) with PMF configured as mandatory (MFPR=1 and MFPC=1) effectively uses WPA3-Enterprise (AKM:5) for key management instead of WPA2-Enterprise (AKM:1).
  • Use cases for this workaround:
    • “WPA3-Enterprise Only Mode” with no support for legacy WPA2-Enterprise clients.
    • AOS 8.10 or 10.4 deployments.
    • 2.4 GHz or 5 GHz operation.
  • To deploy this workaround two configurations are required.
      1. Security mode set as WPA2-Enterprise (wpa2-aes)
      1. PMF set as mandatory (MFPR=1 and MFPC=1)
      • Instant 8 configuration for MFP via CLI (mfp-capable and mfp-required parameters), Central template group, or Central REST API.
      • AOS 8 configuration for MFP via WebUI, CLI, or local REST API.
      • AOS 10 configuration for MFP via Central REST API.
  • Caveats:
    • This workaround does not support 6 GHz operation.
    • AOS 8 forwarding mode caveats:
      • PMF operation for Wi-Fi 5 APs requires use of decrypt-tunnel forwarding mode.
      • PMF operation in tunnel forwarding mode is supported starting with Wi-Fi 6 APs.
    • When this workaround is deployed and a capable deployment is being upgraded to an 8.11 release, upgrade to at least 8.11.2.1 or later due to a multicast encryption mismatch bug (AOS-243060) present in earlier 8.11 releases.

Example AOS 8.10 configuration for WPA3 only key management in 2.4 GHz or 5 GHz bands using wpa2-aes + mfp-capable + mfp-required:

wlan ssid-profile "ACME_1X_WPA3"
essid "ACME_1X_WPA3"
opmode wpa2-aes
mfp-capable
mfp-required
!

Example AOS 8.10 verification:

(MCR) [mynode] #show wlan ssid-profile ACME_WPA3_Enterprise
SSID Profile "ACME_1X_WPA3"
---------------------------
Parameter                                               Value
---------                                               -----
SSID enable                                             Enabled
ESSID                                                   ACME_1X_WPA3
Encryption                                              wpa2-aes
Enable Management Frame Protection (for WPA2 opmodes)   Enabled
Require Management Frame Protection (for WPA2 opmodes)  Enabled

WPA3 only CCM 128 workaround example beacon frame.

When this workaround is configured and supported, the following capabilities are advertised or negotiated in beacons, probe response, or association in the 2.4 GHz or 5 GHz bands:

  • AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
  • Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
  • Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

When this workaround is configured and not supported, such as by Wi-Fi 5 APs in tunnel mode on AOS 8, the following capabilities are advertised or negotiated in beacons, probe response, or association in the 2.4 GHz or 5 GHz bands:

  • AKM suite selector as 00-0F-AC:1 (802.1X with SHA-1).
  • Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Protected Management Frames are disabled (MFPR=0 and MFPC=0).

After some period of workaround implementation and a new deployment requirement arises for 6 GHz operation, for example when 6 GHz capable hardware is added, consider the following software upgrade and configuration migration order to maintain consistency in advertised key management:

  • First
    • AOS 8: Upgrade to 8.11.2.1 or later.
    • AOS 10: Upgrade to 10.5 or later.
  • Second
    • Change the security mode from WPA2-Enterprise (wpa2-aes) to WPA3-Enterprise CCM 128 (wpa3-aes-ccm-128).
    • Disable transition mode to disable support for WPA2 clients using AKM:1. This is neccessay because transition mode configuration for WPA3-Enterprise CCM 128 is supported starting in 8.11 and 10.5 and is enabled by default advertising both AKM:1 and AKM:5.
  • Third
    • AOS 8: Configure “Allow 6GHz band” on respective VAP.
    • AOS 10: Enable 6 GHz band in respective WLAN configuration.

Best practices

WPA3-Enterprise is suitable for use cases where WPA2-Enterprise was used prior because of Protected Management Frames and when AKM:5 (SHA-256) is negotiated the key length is increased. It is encouraged to disable weak EAP methods such as PEAP-MSCHAPv2, CHAPv1, PAP, etc., and consider using a stronger EAP method such as EAP-TLS.

Consider disabling transition mode to limit attack vectors. When PMF is disabled or not used by a client, attackers can spoof management frames from an AP to attack an associated client through Denial of Service (DoS) or attacker-in-the-middle techniques.

Consider deploying WPA3-Enterprise and WPA2-Enterprise on different individual VAPs.

WPA3-Enterprise GCM 256

Introduced in AOS 8.5, WPA3-Enterprise with 256 bits enables GCMP-256 cipher suites without requiring CNSA compatible EAP. This mode is also referred to as WPA3-Enterprise Non-CNSA.

The following is advertised and negotiated in beacons, probe response, and association:

  • AKM suite selector as 00-0F-AC:5 (802.1X with SHA-256).
  • Pairwise cipher suite selector as 00-0F-AC:9 (GCMP-256).
  • Group data cipher suite selector as 00-0F-AC:9 (GCMP-256).
  • Group management cipher suite selector as 00-0F-AC:12 (BIP-GMAC-256).
  • Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

WPA3-Enterprise GCM 256 RSNE example

Best practices

This security mode is suitable for use-cases where WPA2-Enterprise was used prior because of Protected Management Frames and stronger ciphers than CCM 128.

Use this security mode if the client population is under administrative control and knowledge of client support for GCMP-256 with AKM:5 is known.

Weak EAP methods such as PEAP-MSCHAPv2, CHAPv1, PAP, etc., should be disabled and client connections moved to using a stronger EAP method such as EAP-TLS.

The client population must support the defined security parameters as transition mode is not allowed for WPA3-Enterprise GCM 256.

WPA3-Enterprise CNSA (192-bit)

WPA3-Enterprise CNSA (192-bit) enforces CNSA Suite security standards for enterprise Wi-Fi networks.

The following is advertised and negotiated in beacons, probe response, and association:

  • AKM suite selector as 00-0F-AC:12 (802.1X with SHA-384).
  • Pairwise cipher suite selector as 00-0F-AC:9 (GCMP-256).
  • Group data cipher suite selector as 00-0F-AC:9 (GCMP-256).
  • Group management cipher suite selector as 00-0F-AC:12 (BIP-GMAC-256).
  • Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

WPA3-Enterprise CNSA (192-bit) RSNE example

Other notes of importance:

  • Requires a CNSA Suite compatible EAP-TLS cipher suite (RFC 6460):
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 using p384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 using p384 and RSA > 3k bits
    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 using RSA > 3k bits
  • TLS v1.2 or later is required.
  • Key length must be greater than 3072 bits. The signing keys have the same key length requirements.
  • Certificate chain validation is mandatory.
  • EAP termination is not supported. EAP termination is when EAP tunnel termination is moved upstream from the RADIUS server to the controller or AP. WPA3-Enterprise 192-bit (CNSA) expects that a RADIUS server is used, and policy is enforced by the RADIUS server. This means CNSA Suite compatible 802.1X happens between client and RADIUS server based on the authenticator indicating which AKM is negotiated between client and AP.

WPA3-Enterprise CNSA (192-bit) is supported by HPE Aruba Networking ClearPass (CPPM) starting in version 6.8 and supports the following RADIUS attributes from RFC 7268:

  • WLAN-Reason-Code (185) 
  • WLAN-Pairwise-Cipher (186)
  • WLAN-Group-Cipher (187)
  • WLAN-AKM-Suite (188)
  • WLAN-Group-Mgmt-Cipher (189)

Best practices

This security mode is suitable for use-cases where WPA2-Enterprise was used prior because of Protected Management Frames, increased key length, stronger ciphers, and requirement of CNSA Suite compatible EAP-TLS methods.

This is primarily focused on customers such as government, finance, and other industries who require a high level of security.

The client population must support the defined security parameters as transition mode is not allowed for WPA3-Enterprise CNSA (192-bit).

3.1.2 - WPA3-Personal

Improving the security of password secured Wi-Fi networks.

Offline dictionary attacks against WPA2-Personal have been widely known for well over two decades. They were discovered shortly after the inception of WPA2-Personal. Certain venues offer free Wi-Fi networks using a shared and public password. Some incorrectly believe Wi-Fi traffic is secure when WPA2-Personal is used. With PSK, the password directly derives a master key and knowledge of the password enables decryption, replay, and forgery of data frames.

sequenceDiagram
    Note over Client,AP: Discovery
    Note over Client,AP: Open System Authentication
    Note over AP,Client: Association
    Note right of Client:PMK generation:<br>PMK=PBKDF2(HMAC-SHA-1,<br>Password,SSID,4096,256)
    Note over AP,Client: 4-way handshake

Protocol

Originally introduced for mesh security in IEEE 802.11-2016, the Simultaneous Authentication of Equals (SAE) protocol replaces the Pre-Shared Key (PSK) implementation found in WPA2-Personal with a password-based authentication method resistant to dictionary attacks.

Users will find a similar experience with SAE and PSK as they are both password provisioned. However, there are major implementation differences in the security protocol.

For those venues who intend to offer better data protection for their users, SAE offers a more secure password-based option than a shared and public PSK. This is because the master key (PMK) resulting from SAE is not solely based on the password.

With SAE, the password is used in a zero-knowledge proof cryptographic function to derive a unique pairwise master key (PMK) per client. The password is used to index a secret point on an elliptic curve. The point on the curve becomes the generator for use in a cryptographic exchange.

sequenceDiagram
    Note over Client,AP: Discovery
    Client->>+AP:PWE = f(password)<br>m,n ← random<br>N = -n * PWE<br>SAE Authentication Commit
    AP->>+Client:PWE = f(password)<br>i,j ← random<br>J = -j * PWE<br>SAE Authentication Commit
    Client->>+AP:SAE Authentication Confirm<br>S = m * ((i+j) * J)<br>PMK = KDF(S, label)
    AP->>+Client:SAE Authentication Confirm<br>S = i * ((m+n) * N)<br>PMK = KDF(S, label)
    Note over AP,Client: Association
    Note over AP,Client: 4-way handshake

This means the password or password-derived data is never sent over the air. Unlike with WPA2-Personal (PSK), knowledge of the password cannot decrypt SAE encrypted data frames. The PMK is needed to decrypt SAE encrypted data frames and the only parties that know the PMK are the client and AP which performed SAE. This means the SAE protocol is resistant to active, passive, and dictionary attacks.

WPA3-Personal only mode

WPA3-Personal advertises or negotiates the following capabilities in beacons, probe response, or association:

  • AKM suite selector as 00-0F-AC:8 (SAE).
  • Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
  • Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

WPA3-Personal (SAE) illustration of operations

WPA3-Personal transition mode

WPA3-Personal may be deployed in transition mode that allows both SAE clients and PSK clients to connect to the same Basic Service Set (BSS), which is a mixed mode of operation. The beacon or probe response contains an AKM list in the RSNE which will contain both PSK (AKM:2) and SAE (AKM:8).

This means the password is shared between WPA2-Personal and WPA3-Personal. The WPA2-Personal network is still vulnerable to all the classic issues. If an attacker gains knowledge of the password by attacking WPA2-Personal, they will get access to the network, but will not be able to decrypt WPA3-Personal sessions. Downgrade attacks from WPA3-Personal to WPA2-Personal are also possible.

Due to the same BSS servicing both WPA2-Personal (PSK) and WPA3-Personal (SAE) clients, Protected Management Frames are optional (MFPR=0 and MFPC=1) for WPA3-Personal Transition networks.

WPA3-Personal in Transition Mode advertises or negotiates the following capabilities in beacons, probe response, or association:

  • AKM suite selectors include 00-0F-AC:2 (PSK) and 00-0F-AC:8 (SAE).
  • Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
  • Protected Management Frames are optional (MFPR=1 and MFPC=0).

WPA3-Personal Transition Mode RSNE example

Hash-to-Element (H2E)

Hash-to-element (also referred to as hash-to-curve or direct hashing) is a cryptographic method for generation of the password element (PWE) which replaces the weaker and original hunting-and-pecking (also referred to as looping) method for SAE. With hash-to-element, WPA3-Personal is further resistant to side-channel attacks and timing attacks.

SAE H2E capability can be found in beacon and probe response frames in the extended RSN capabilities field of the RSN eXtension element (RSNXE).

RSNXE example

Status code 126 found in the authentication frame from the client indicates which method is used.

SAE authentication frame example

PWE derivation behavior starting in AOS 8.10 and 10.4:

  • Operation in the 2.4 GHz and 5 GHz bands:
    • Hash-to-element (H2E) is preferred but allows hunting-and-pecking if the client does not support H2E.
  • Operation in the 6 GHz band:
    • Enforces use of H2E and does not allow hunting-and-pecking.

Support for hash-to-element (H2E) is mandatory for WPA3 certified devices.

Clients have been supporting H2E since 2021:

Best practices

For use-cases where WPA2-Personal was used before, WPA3-Personal is a suitable replacement to provide better security, even when a non-complex password is used. WPA3-Personal provides stronger data encryption and protection than WPA2-Personal.

WPA3-Personal is also suitable for use-cases where WPA2-Personal is no longer allowed such as with 6 GHz operation and Wi-Fi 7 connectivity.

3.1.3 - Enhanced Open

Securing Open networks with automated encryption and PMF.

Wi-Fi networks with Open security transport and pass data in the clear offering no encryption or protection from passive eavesdroppers.

Enhanced Open provides unauthenticated data encryption and protects data from sniffers.

Protocol

Open security is one of the original IEEE 802.11 access methods for connecting clients to APs. Open uses an authentication architecture called Open System Authentication (OSA). OSA offers no encryption. When utilized independently, OSA permits WLAN access to any client.

sequenceDiagram
    Note over Client,AP: Discovery
    Note over Client,AP: Open System Authentication
    Note over Client,AP: Association

Enhanced Open adds automatic encryption without requiring credentials. Enabling private communication between client and AP. Encryption is provided by Opportunistic Wireless Encryption (OWE) defined in RFC 8110. With OWE, the client and AP performs an unauthenticated Diffie-Hellman key exchange which results in a unique pairwise secret key (PMK). The resulting key is used in a 4-way handshake post association to generate the traffic encryption keys.

sequenceDiagram
    Note over Client,AP: Discovery
    Note over Client,AP: Open System Authentication
    Client->>+AP:Association request with<br>Diffie-Hellman parameter<br>X (public key)
    Note left of AP:PMK generation:<br>y←random<br>Y=y*g<br>S=y*X<br>PMK=KDF(S,label)
    AP->>+Client:Association response with<br>Diffie-Hellman parameter<br>Y (public key)
    Note right of Client:PMK generation:<br>x←random<br>X=x*g<br>S=x*Y<br>PMK=KDF(S,label)
    Note over AP,Client: 4-way handshake

The resulting benefit is a Wi-Fi network more secure than a shared and public PSK (WPA2-Personal) because OWE is not susceptible to a passive attack which results in an attacker being able to eavesdrop, forge, and replay frames on the network. Enhanced Open is also easier to deploy because there is nothing to provision. There is no password.

Enhanced Open only mode

Enhanced Open advertises or negotiates the following capabilities in beacons, probe response, or association:

  • AKM suite selector as 00-0F-AC:18 (OWE).
  • Pairwise cipher suite selector as 00-0F-AC:4 (CCMP-128), 00-0F-AC:8 (GCMP-128),00-0F-AC:9 (GCMP-256), or00-0F-AC:1 (CCMP-256) could be negotiated.
  • Group data cipher suite selector as 00-0F-AC:4 (CCMP-128).
  • Group management cipher suite selector as 00-0F-AC:6 (BIP-CMAC-128).
  • Protected Management Frames are mandatory (MFPR=1 and MFPC=1).

Enhanced Open (OWE) RSNE example

Enhanced Open transition mode

Enhanced Open Transition Mode (OWETM) offers a backwards compatible transition from unencrypted Open Wi-Fi networks. OWETM provides the ability for non-OWE clients (Open) and OWE capable clients to connect to the same Wi-Fi network.

This is accomplished by creating and broadcasting two Basic Service Sets (BSSes) with separate beacons for each. Both BSSes point at the other through the OWE Transition Mode Vendor IE.

  • BSS-1 for Open for non-OWE clients with the IE to indicate BSS-2.
  • BSS-2 for “hidden” OWE with a zero length SSID (hidden) and the IE to indicate BSS-1.

Enhanced Open (OWE) Transition Mode RSNE example

The beacon and probe response frames of the Open BSS includes an OWE Transition Mode IE to encapsulate the BSSID and SSID of the OWE BSS.

  • The Open BSS and associated clients do not benefit from Protected Management Frames or data encryption.

The beacon and probe response frames from the OWE BSS include an OWE Transition Mode IE to encapsulate the BSSID and SSID of the Open BSS.

  • The beacon frame from the OWE BSS will be zero length and includes the OWE Authentication and Key Management (AKM) selector (00-0F-AC) of AKM:18 in the RSNE.
  • PMF is required (MFPR=1 and MFPC=1) for the OWE BSS.
  • The OWE client benefits from both encryption and PMF.

The OWE client discovers the OWE AP by using active or passive scanning.

MAC authentication

When using Enhanced Open and authorizing connecting devices using a MAC authentication method, note that the client association will be rejected if the MAC authentication returns a REJECT message on the authentication attempt. This is a change in behavior when compared against an Open network where the client device would stay associated and be left assigned in the logon user role. The MAC authentication service used by an Enhanced Open network will need to always allow the authentication attempt and return the appropriate user role for the session to continue, whether that be a user role that enforces a captive portal, allows full access to the network, or otherwise configured.

Best practices

Enhanced Open is suitable for use-cases such as captive portals, coffee shops, cafés, schools, enterprises, public venues like airports, stadiums, etc., anywhere that encryption is needed but identity and authentication is not.

3.1.4 - Troubleshooting

Useful CLI commands for security mode verification.

AOS 8

(MD) # show ap association  
(MD) # show ap bss-table  
(MD) # show ap essid  
(MD) # show ap owe-tm-info  
(MD) # show auth-tracebuf mac <client-mac>  
(MD) # show dot1x supplicant-info <client-mac> <bssid>  
(MD) # show dot1x supplicant-info pmkid  
(MD) # show log security  
(MD) # show wlan ssid-profile <profile-name>

AOS 10

(AP) # show ap association  
(AP) # show ap bss-table  
(AP) # show ap debug client-table  
(AP) # show ap debug mgmt-frames mac <client-mac>  
(AP) # show clients debug advanced  
(AP) # show log security  
(AP) # show network  
(AP) # show network <profile-name>

3.2 - Security features

In depth information about WLAN security features.

3.2.1 - Protected management frames

Learn about the significance of IEEE 802.11w Protected Management Frames in Wi-Fi networks, enhancing security by providing data integrity for and protecting a subset of management frame exchanges from potential attacks.

The IEEE 802.11w-2009 amendment (now part of IEEE 802.11-2020) introduced Protected Management Frames (PMF) which addresses the protection of robust management frames. Prior to WPA3 and Enhanced Open, most management frames are not encrypted. Since Wi-Fi is a broadcast medium, any device can eavesdrop or participate as a legitimate or rogue client. Securing management frames also is equally important as data frames. Without PMF, all management frames are sent unprotected in the open. PMF protects a set of robust management frames and augments privacy protections already in place for data frames (802.11i). WPA3 and Enhanced Open require use of PMF.

PMF is also referred to as Management Frame Protection (MFP). When discussing whether Protected Management Frames are optional or required, the terms MFPR (required) and MFPC (capable) will be used. Their configuration options are discussed below. Throughout the security mode sections the terms PMF and MFP may be used interchangeably. In the context of HPE Aruba Networking, these terms mean the same thing.

Three possible configurations exist for Protected Management Frames:

Configuration Parameters PMF Capable Client Non-PMF Client
Disabled MFPR=0/MFPC=0 No benefit No benefit
Capable (Optional) MFPR=0/MFPC=1 Protection benefit No benefit
Mandatory (Required) MFPR=1/MFPC=1 Protection benefit Cannot connect

Protected Management Frames help secure robust management frames against various attacks. The key security objective is to protect against passive eavesdropping, prevent forgery of unicast and multicast action frames, allow replay detection, and prevent stations from masquerading as another station.

PMF protects against forged disassociation and de-authentication frames post association.

Example of a client dropping an unprotected deauthentication frame.

Examples of protected robust action frames include:

  • Channel Switch Announcements
  • QoS
  • ADDBA Negotiation
  • Block ACK
  • Radio Measurement
  • Security Association (QA) Query
  • Wireless Network Management

Support for Protected Management Frames is advertised in the RSN Capabilities of the RSNE which can be found in beacons, probe responses, and association responses.

RSN Capabilities example showing Management Frame Protection Required and Capable parameters set to enabled (MFPR=1 and MFPC=1).

AOS specifics:

  • PMF is not user configurable for WPA3 or Enhanced Open security modes. MFPR (Required) and MFPC (Capable) configuration is automatic.

3.3 - Wireless Intrusion Detection & Protection

A deeper look at network securing technologies and how they come together to create the HPE Aruba Networking Wireless Intrusion Detection & Protection System. This feature includes both detection and prevention for the wireless network.

The HPE Aruba Networking Wireless Intrusion Detection & Protection System (WIDS & WIPS) is a network security feature that monitors wireless networks for unauthorized access points, clients, and abnormal traffic patterns. WIDS & WIPS detects rogue and interfering access points, providing real-time alerts and detailed reports to safeguard the integrity of the wireless network. Attacks are not only detected but also classified, contained, and recorded in a seamless sequence that can automatically handle security events.

When security events are discovered, HPE Aruba Networking Central can alert the security team of possible threats and provides essential information needed to locate and manage those threats.

WIDS & WIPS operates at the radio frequency level, with various deployment modes to suit different environments — Access Point (AP) mode for client service, and Air Monitor (AM) mode with an emphasis on security. While standard AP mode suffices for most security needs, environments demanding higher security may opt for AM mode, especially for wireless containment.

HPE Aruba Networking Central provides an effective defense strategy against rogues and other forms of wireless intrusion:

  • Performs multiple types of wireless scans.

  • Correlate the results of the various scans to consolidate all available information about identified devices.

  • Classifies the discovered devices based on rules that are customized to an organization’s security needs.

  • Generates automated alerts and reports for IT containing key known information about unauthorized devices, including the physical location and switch port whenever possible.

  • Deploys containment mechanisms to neutralize potential threats.

3.3.1 - Use cases

Use cases and the WIDS framework for helping safeguard the wireless network.

The primary use cases that HPE Aruba Networking WIDS aims to solve include:

  • Network security threats: WIDS helps organizations mitigate and prevent security threats within their network by addressing the need to identify and respond to various threats, such as rogue devices with unauthorized access, before the network’s integrity can be compromised.

  • Device visibility: Many organizations struggle with maintaining visibility into the devices connected to their network. WIDS provides the capability to see all devices in real-time, which is essential for tracking, locating and managing authorized and unauthorized devices.

  • Zero trust security: The Zero Trust security model, which assumes that no device should be trusted by default, has gained traction. WIDS aligns with this approach by continuously inspecting and verifying the trustworthiness of devices, even after they gain network access.

  • Scalability: As organizations grow, their network security needs to scale accordingly. WIDS is designed to scale with the organization, making it suitable for both small and large enterprises.

  • Compliance requirements: Various industries and regulatory bodies have strict compliance and data security requirements. WIDS aids in achieving compliance by ensuring that all wireless devices connecting to the network meet security and policy standards.

    As an example, the PCI Data Security Standard requires that all organizations accepting credit or debit cards for purchases protect their networks from attacks via rogue or unauthorized wireless APs and clients. This applies even if the merchant has not deployed a wireless network for its own use.

    Vertical examples:

    • WIDS helps retailers and other covered organizations comply with these requirements. WIDS Rules also enable companies to set up automated, prioritized alerts that can be emailed to a specified distribution list the instant that rogues are detected.

    • Hospitals use WIDS Rules to protect patient data as well as protect IT and medical systems. They need to know if rogues exist on their network along with critical medical devices use for patient care.

Key features & advantages

The solution improves network security, manages compliance requirements, and reduces the cost of manual security efforts.

Feature Benefit
Wireless scanning that leverages existing Access Points and AM sensors Time and cost savings. Eliminates the need to perform walk-arounds or to purchase additional RF sensors or dedicated servers.
Default or Custom Rules-based threat classification Time and resource savings. Allows staff to focus on the most important risk mitigation tasks. Comprehensive device classification that’s tailored to the organization means less time spent investigating false positives.
Automated alerts Faster response times. Alerts staff the instant a rogue is detected, reducing reaction times, and further improving security.
Rogue AP location and switch/port information Faster threat mitigation. Greatly simplifies the task of securing rogue devices and removing potential threats.
Reporting Reduced regulatory expense. Comprehensive rogue and audit reports helps companies comply with various industry standards and regulatory requirements.
IDS event management Single point of control. Provides you with a full picture of network security. Improves security by aggregating data for pattern detection.
Manual and automated containment Continuous security. Improves security by enabling immediate action even when network staff is not present.

Wireless threat protection framework

The threat protection framework defines a continuously repeating process consisting of multiple phases: discover, classify, contain, and alert and audit.

The wireless threat protection framework circular process.

3.3.2 - RF scanning methods

HPE Aruba Networking Access Points, Gateways, and Central can work together to scan the environment for the detection of threats to the wireless network.

Scanning

Radios in an HPE Aruba Networking AP can be configured to scan the wireless network in three different modes: Access Point (AP) mode, Air Monitor (AM) mode, and Spectrum Monitor mode. Each mode is designed to prioritize different tasks.

Radio Mode Serve Clients IDS/Rogue Detection IDS/Rogue Channels Scanned Wireless Containment Spectrum Analysis
AP Yes Yes All regulatory channels Best effort Client serving channel only
Air Monitor No Yes All regulatory + Rare channels Yes No
Spectrum Monitor No Yes All regulatory + Rare channels No Yes, All Channels

Access point mode

Radios in AP mode focus on serving clients and pushing wireless traffic but they also perform IDS detection. Most wireless administrators use this mode in their networks. The information provided by the APs is the basis for detection. IDS detection occurs while the AP is serving clients, ensuring full IDS attack detection within the network. The off-channel scanning will find rogue devices and IDS attacks originating from outside of the network.

AP mode scanning operation

Typically, an AP will perform off channel scanning every 10 seconds for slightly less than 100 milliseconds per channel. This allows the AP to monitor the surroundings without missing beacons and causing connectivity problems for clients. Off-channel scanning has multiple use cases in addition to WIDS/WIPS.

Scanning all regulatory domain channels is recommended. That will include any valid channel in any regulatory domain, not just the regulatory domain of the AP. This is recommended since attackers typically don’t feel the need to follow the law. Detection of a malicious device can be performed on a channel outside the AP’s regulatory domain but the AP cannot perform containment on the channels outside of the assigned regulatory domain. The AP can be restricted to scan just the channels within the assigned regulatory domain but this is not recommended for security conscious customers.

APs use a bucketing based algorithm for channel scanning. When an AP boots up, the channels are classified into two different buckets- regulatory and non-regulatory channels. The regulatory channels are scanned more frequently than the non-regulatory channels. A third bucket of “active” channels is populated as the AP scans and detects channels with wireless traffic. The active bucket is scanned more frequently than the regulatory and non-regulatory channels. This allows the AP to spend the most time on channels where a threat is more likely than on other channels with a lower likelihood of threats.

The APs primarily protect the channel to which they are assigned; APs can additionally be configured to conduct an off-channel scan approximately every 10 seconds for a period of about 100 ms to look for any WIDS events.

A representation of how a radio in AP mode will go off-channel for scanning.

Due to the adaptive nature of the scanning algorithm, answering the question of “how much time is required to scan all channels?” is relatively difficult. Typically, all channels will be scanned at least once in less than an hour, with active channels getting scanned much more frequently.

Air Monitor mode

Air Monitors (AMs) are dedicated to wireless security. They do not serve clients and hence do not need to be deployed at the same density as APs. In most cases, a 4:1 or 5:1 ratio of APs to AMs is recommended if containment is needed, but that varies heavily based on AP density, environment, and the types of WIDS/WIPS features enabled.

AM mode scanning operation

AMs use a channel scanning algorithm similar to that of APs but use a fourth bucket of classification for ‘rare’ channels. In raw frequency, that is 2412 through 2484 MHz and 4900 through 5895 MHz in 5 MHz increments. Rare channels include the 4.9 GHz spectrum which is a licensed public safety band in many countries. The 6 GHz band is scanned from 5945 MHz through 7125 MHz, with channel scanning done every 20 MHz using the group scanning technology to be able to catch the maximum channel width supported by the radio.

Due to the analog nature of wireless, we have found that the natural bleed through of RF signals will allow us to find rogues that are configured in between standard channels by scanning every 5 MHz. The channels scanned by an AM are configured in the AM scanning profile which is part of the radio profile.

Scan dwell times are based on the bucketing system. When in AP mode, the off-channel dwell time is quite short to minimize impact for serving client devices and allow for the regular sending of beacons. Since the AM is not serving clients and no beacons are being sent, the AM does not need to be on any particular channel regularly.

Air Monitors (AMs) continuously scan all channels based on an algorithm that divides the RF channels into three buckets (active, regulatory, and rare). The AM will spend ~500 ms on active channels, ~250 ms on regulatory channels, and ~100 ms on rare channels.

A representation of how a radio in Air Monitor mode will utilize different buckets for channel scanning.

The exact channel that is scanned will be chosen randomly. The dwell times listed above are slightly randomized to ensure that a rogue cannot predict exactly when it can and cannot transmit to avoid detection.

AMs scan the active channels more frequently than regulatory channels, which are scanned more frequent than rare channels. The exact time to cycle through all the channels varies due to the algorithm noted above. To scan through all regulatory channels can take approximately 5 minutes. The APs and AMs can demodulate, monitor, and detect IEEE 802.11 standards and protocols.

Channels will be promoted to the active channel list at any time based on the detection of Wi-Fi activity. If no activity is seen for a significant period, the channel will be demoted back to the original bucket.

Spectrum monitor

Wireless networks operate in environments with electrical and radio frequency devices that can interfere with network communications. Microwave ovens, cordless phones, and even adjacent Wi-Fi networks are all potential sources of continuous or intermittent interference. The APs that support the spectrum analysis software module and configured in spectrum monitor (SM) mode are able to examine the radio frequency (RF) environment in which the Wi-Fi network is operating, identify interference, and classify the source of the interference. An analysis of the results can then be used to quickly isolate issues with packet transmission, channel quality, and traffic congestion caused by contention with other devices operating in the same band or channel.

AP radios operating in SM mode will gather spectrum data but do not service clients. Each SM will scan and analyze the spectrum band serviced by the SM’s radio. An AP radio in hybrid AP mode will continue to serve clients as an access point while also analyzing spectrum analysis data for the channel the radio uses to serve clients. The option for recording of the data from both types of spectrum analysis devices is available, which allows for saving of that data for later playback and analysis.

Wired rogue AP detection and correlation

The gateway has a few different methods to assist with determining whether or not an AP discovered on the network is a rogue.

The most basic method is a +/- 1 last octet MAC address check if traffic that has been on the wire and seen wirelessly. If wired traffic is observed with a MAC address that is within 1 digit of the wireless MAC, that device will be tagged as a wired rogue. Example, MAC addresses 64-16-4A-54-E4-72 and 64-16-4A-54-E4-71 would be detected as a rogue device.

There are a few more sophisticated methods as well. The APs and AMs will monitor traffic detected over the air and determine if that traffic originated on the wired network by checking if the wireless traffic matches any of the known wired gateway MAC addresses. The list of known wired gateway MAC addresses is built up by the gateway, APs, and AMs. For this functionality to operate correctly, all client facing VLANs need to be trunked to either the gateway, an AP, or an AM. While traffic needs to be trunked only to one AP or AM for the detection to work, the recommendation is to trunk the VLANs to all of the APs or AMs that are deployed. Wired containment requires this setup and is discussed in the chapter regarding containment.

Central will check the bridge forwarding tables and the ARP tables to gather rogue information from the network. The bridge forwarding table gives the mapping of wired MAC addresses to switch ports. The ARP table gives a mapping of wired MAC addresses and IP addresses. Central will then correlate the list of wired MAC addresses with everything that has been heard over the air. If two MAC addresses are within a configurable offset, they will be considered the same device and linked together.

For best results the recommendation is that only the attack detection that is worth investigating is turned on. Security-minded customers may choose the High option. The High option does not enable every event that can be detected by the HPE Aruba Networking system. For example, NetStumbler detection is not turned on by default. NetStumbler detection means that a client device is running an old scanning system and does not necessarily mean that the network was compromised. Custom settings can be chosen that allow the administrator to enable or disable every attack detection individually if they choose to do so.

3.3.3 - Detection

A overview of infrastructure and client intrusion detection and various configurable levels available within HPE Aruba Networking Central.

Infrastructure intrusion detection

Detecting attacks against the infrastructure is critical for avoiding attacks that may lead to a large-scale DoS attack or a security breach. HPE Aruba Networking Central offers a suite of signature selections to help detect attacks against the WLAN infrastructure, which consists of authorized APs, the RF medium, and the wired network.

An authorized or valid AP is defined as an AP that belongs to the WLAN infrastructure. The AP is either an HPE Aruba Networking AP or a third-party AP. The WIDS application automatically learns about authorized HPE Aruba Networking APs.

For a full list of AP classifications, refer to the Classification topic.

Client intrusion detection

Generally, clients are more vulnerable to attacks than APs. Clients are more likely to associate with a malicious AP due to the client’s driver behavior or a misconfigured client. Monitoring of authorized clients is important to track their associations and to detect any attacks raised against them.

Client intrusion detection includes, but is not limited to the following:

Detecting attacks against clients: An attacker can perform an active DoS attack against an associated client or perform a replay attack to obtain the keys of transmission which could lead to more serious attacks.

Monitoring authorized clients: Since clients are easily tricked into associating with unauthorized APs, tracking all misassociations of authorized clients is very important.

An authorized client is a client authorized to use the WLAN network. For HPE Aruba Networking Wireless Operating System (AOS) , an authorized client is called a valid client. AOS automatically learns a valid client. A client is determined to be valid if associated to an authorized or valid AP using encryption; either Layer 2 or IPsec.

For a full list of client classifications, refer to the Classification topic.

Levels of detection

The detection settings on HPE Aruba Networking Central for both infrastructure and clients can set to the different levels depending on the security requirements of the organization.

  • High - Enables all the available detection mechanisms

  • Medium - Enables most of the important detection mechanisms

  • Low - Enables the most critical detection mechanisms

  • Off - Disables all detection mechanisms

  • Custom - Allows the selection of desired detection mechanisms

3.3.3.1 - Infrastructure event detection levels and signature descriptions

Infrastructure event detection levels and signature descriptions provide a concise overview of the detection levels and detailed descriptions for events related to wireless clients. These classifications help in understanding and managing the severity of events within a wireless network. Detection levels range from low to high, indicating the potential impact of client-related incidents. Signature descriptions offer specific details about the nature and characteristics of each event, aiding in prompt identification and appropriate response to potential issues in the wireless environment. Together, these features enhance network administrators’ ability to proactively address client-related events for improved network security and performance.

Infrastructure event detection levels

The available detection levels that can be configured for infrastructure events.

Low

  • Detect AP Spoofing

  • Detect Windows bridge

  • IDS signature - de-authentication broadcast

  • IDS signature - de-association broadcast

Medium

  • Detect ad hoc networks using valid SSID – Valid SSID list is auto configured based on the AP configuration.

  • Detect malformed frame large duration

High

  • Detect AP impersonation

  • Detect ad hoc networks

  • Detect valid SSID misuse

  • Detect wireless bridge

  • Detect 802.11 40 MHz intolerance settings

  • Detect active 802.11n greenfield mode

  • Detect AP food attack

  • Detect client flood attack

  • Detect bad WEP

  • Detect CTS rate anomaly

  • Detect RTS rate anomaly

  • Detect invalid address combination

  • Detect malformed frame – HT IE

  • Detect malformed frame association request

  • Detect malformed frame – auth

  • Detect overflow IE

  • Detect overflow EAPOL key

  • Detect beacon wrong channel

  • Detect devices with invalid MAC OUI

  • Detect ghost tunnel server attack

Infrastructure events - names and descriptions

A listing of the available infrastructure event signatures along with the description from the user guide and engineering.

Detect 802.11n 40 MHz Intolerance Setting

When a client sets the HT capability intolerant bit to indicate that it is unable to participate in a 40 MHz BSS, the AP must use lower data rates with all its clients. Network administrators often want to know if there are devices that are advertising 40 MHz intolerance, as this can impact the performance of the network.

This would be enabled to indicate if any clients have set the intolerance bit when HT40+ ESSIDs are configured or monitored. When clients have the intolerance bit set, it can diminish the channel throughput. This is not a security related issue. Recommend Disable.

Detect Active 802.11n Greenfield Mode

When 802.11 devices use the HT operating mode, they cannot share the same channel as 802.11a/b/g stations. Not only can they not communicate with legacy devices, but the way they use the transmission medium is different, which would cause collisions, errors, and retransmissions.

This can generate verbose alerts if a nearby WLAN is broadcasting in Greenfield mode. Greenfield though is very rare anymore. Recommend Disable.

Detect Ad hoc Networks

An ad hoc network is a collection of wireless clients that form a network amongst themselves without the use of an AP. As far as network administrators are concerned, ad hoc wireless networks are uncontrolled. If they do not use encryption, they may expose sensitive data to outside eavesdroppers. If a device is connected to a wired network and has bridging enabled, an ad hoc network may also function like a rogue AP. Additionally, ad hoc networks can expose client devices to viruses and other security vulnerabilities. For these reasons, many administrators choose to prohibit ad hoc networks.

This can generate VERY verbose alerts, as things like printers, mobiles with Ad hoc enabled, etc. are enabled. Recommend disable unless there is firm control of the devices within the WLAN coverage area where an Incident Response Team can investigate and remediate alerts, or if the environment is a high-security customer where policy dictates that Ad hoc devices be detected.

Detect Ad hoc Network Using Valid SSID

If an unauthorized ad hoc network is using the same SSID as an authorized network, a valid client may be tricked into connecting to the wrong network. If a client connects to a malicious ad hoc network, security breaches or attacks can occur.

While this should be more rare than basic Ad hoc detection, as it would require the Ad hoc network to be configured with a valid ESSID, which while it should be rarer, would indicate malicious intent. Recommend enable for any security conscious customers.

Detect AP Flood Attack

Fake AP is a tool that was originally created to thwart wardrivers by flooding beacon frames containing hundreds of different addresses. This would appear to a wardriver as though there were hundreds of APs in the area, thus concealing the real AP. An attacker can use this tool to flood an enterprise or public hotspots with fake AP beacons to confuse legitimate users and to increase the amount of processing need on client operating systems.

If large reports of client disconnects are a concern, this can be enabled. This can be a high false-positive signature depending on the thresholds configured. False alarms can happen if APs or gateways reboot and the signature re-triggers. It can also trigger a false alert if the AP/AM table is full (254 BSSIDs seen, which can be increased but consumes more AP processing power). Recommend enable for any high security conscious customer.

Detect AP Impersonation

In AP impersonation attacks, the attacker sets up an AP that assumes the BSSID and ESSID of a valid AP. AP impersonation attacks can be done for man-in-the middle attacks, a rogue AP attempting to bypass detection, or a honeypot attack.

This is a very explicit type of attack where a bad actor is spoofing a valid ESSID/BSSID. If proper security is in place (WPA2 using RADIUS and valid certs with validation enabled, etc.), the risk is minimal. WPA2-PSK should use VERY strong passphrases. Open SSIDs would be vulnerable. Recommend disable unless there are managed WLANs that are ‘Open’, or the customer is a high security conscious customer.

Detect Wireless Hosted Network

If enabled, this feature can detect the presence of a wireless hosted network.

When a wireless hosted network is detected this feature sends a “Wireless Hosted Network” warning level security log message and the wlsxWirelessHostedNetworkDetected SNMP trap. If there are clients associated to the hosted network, this feature will send a “Client Associated To Hosted Network” warning level security log message and the wlsxClientAssociatedToHostedNetworkDete cted SNMP trap.

Detect WIFI-Direct P2P Groups

AOS now supports the detection and containment of devices associated to Wi-Fi Direct groups. Wi-Fi Direct is a form of a Wireless Hosted Network and shares many of the same features and concepts with Wireless Hosted Networks, such as:

  • The concepts of a Hosted Network group and group leader.

  • The softAP put up as a BSS that clients may associate with.

  • The derivation of the BSSID of the softAP, although different devices behave differently.

  • The ability for devices to BOTH be connected to WLAN Infrastructure and host a Wireless BSSID simultaneously.

  • The ability for a device to allow sharing, or access from one network to the other.

Detect AP Spoofing

An AP Spoofing attack involves an intruder sending forged frames that are made to look like they are from a legitimate AP. It is trivial for an attacker to do this since tools are readily available to inject wireless frames with any MAC address that the user desires. Spoofing frames from a legitimate AP is the foundation of many wireless attacks.

Can be used by attackers to force client rekeying, to more quickly determine an encryption key (ala with weak WPA2-PSK). Recommend enable.

Detect Bad WEP

This is the detection of WEP initialization vectors that are known to be weak. A primary means of cracking WEP keys is to capture 802.11 frames over an extended period and searching for such weak implementations that are still used by many legacy devices.

WEP should no longer be in use anywhere. Recommend disable unless the goal is protection of an antiquated WEP-based WLAN.

Detect Beacon Wrong Channel

In this type of attack, an intruder spoofs a beacon packet on a channel that is different from that advertised in the beacon frame of the AP.

Prone to false positives as it can trigger when nearby or monitored WLANs change channels often (which is VERY common), would only be applicable if seen in VERY large quantities, and even then, is likely a false positive. Recommend disable.

Detect Client Flood

There are fake AP tools that can be used to attack wireless intrusion detection itself by generating a large number of fake clients that fill internal tables with fake information. If successful, it overwhelms the wireless intrusion system, resulting in a DoS.

Can be enabled but is generally an attack on the WIDS. Similar to AP Flood, and can result in false positives. If enabled, thresholds should be enabled up to 150. Recommend disable unless a high security conscious customer.

Detect RTS Rate Anomaly

The RF medium can be reserved via Virtual Carrier Sensing using a clear to send (CTS) transaction. The transmitter station sends a Ready To Send (RTS) frame to the receiver station. The receiver station responds with a CTS frame. All other stations that receive these CTS frames will refrain from transmitting over the wireless medium for an amount of time specified in the duration fields of these frames. Attackers can exploit the Virtual Carrier Sensing mechanism to launch a DoS attack on the WLAN by transmitting numerous RTS and/or CTS frames. This causes other stations in the WLAN to defer transmission to the wireless medium. The attacker can essentially block the authorized stations in the WLAN with this attack.

Very common false positive, generally indicative of bad client drivers, and requires the baselining of the known client environment to know what is ’normal’ versus what is ‘abnormal’. Is mostly a DoS-based type of attack to disrupt transmission. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect CTS Rate Anomaly

The RF medium can be reserved via Virtual Carrier Sensing using an RTS transaction. The transmitter station sends a RTS frame to the receiver station. The receiver station responds with a CTS frame. All other stations that receive these RTS frames will refrain from transmitting over the wireless medium for an amount of time specified in the duration fields of these frames. Attackers can exploit the Virtual Carrier Sensing mechanism to launch a DoS attack on the WLAN by transmitting numerous RTS and/or CTS frames. This causes other stations in the WLAN to defer transmission to the wireless medium. The attacker can essentially block the authorized stations in the WLAN with this attack.

Very common false positive, generally indicative of bad client drivers, and requires the baselining of a known client environment to know what is ’normal’ versus what is ‘abnormal’. Is mostly a DoS-based type of attack to disrupt transmission. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect Device with a Bad MAC OUI

The first three bytes of a MAC address, known as the MAC organizationally unique identifier (OUI), is assigned by the IEEE to known manufacturers. Often, clients using a spoofed MAC address do not use a valid OUI and instead use a randomly generated MAC address.

Very verbose false positives. Triggered by both virtual-MACs as well as the proliferation of new MAC Address OUIs being constantly released. Recommend disable.

Detect Invalid Address Combination

In this attack, an intruder can cause an AP to transmit deauthentication and disassociation frames to all its clients. Triggers that can cause this condition include the use of broadcast or multicast MAC address in the source address field.

This is a DOS-type of attack to the WLAN. Malformed frames can trigger this, bad client drivers, neighboring bad APs, etc. Very high false positive rates, generally NOT a security threat. Recommend disable unless customer is a high security conscious customer where all client devices are managed, tested, and tracked.

Detect Overflow EAPOL Key

Some wireless drivers used in access points do not correctly validate the EAPOL key fields. A malicious EAPOL-Key packet with an invalid advertised length can trigger a DoS or possible code execution. This can only be achieved after a successful 802.11 association exchange.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Overflow IE

Some wireless drivers used in access points do not correctly parse the vendor-specific IE tags. A malicious association request sent to the AP containing an IE with an inappropriate length (too long) can cause a DoS and potentially lead to code execution. The association request must be sent after a successful 802.11 authentication exchange.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Malformed Frame Association Request

Some wireless drivers used in access points do not correctly parse the SSID information element tag contained in association request frames. A malicious association request with a null SSID (that is, zero length SSID) can trigger a DoS or potential code execution condition on the targeted device.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Malformed Frame Auth

Malformed 802.11 authentication frames that do not conform to the specification can expose vulnerabilities in some drivers that have not implemented proper error checking. This feature checks for unexpected values in an Authentication frame.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Malformed Frame-HT IE

The IEEE 802.11n HT (High Throughput) IE is used to convey information about the 802.11n network. An 802.11 management frame containing a malformed HT IE can crash some client implementations, potentially representing an exploitable condition when transmitted by a malicious attacker.

Recommend disable unless HPE Aruba Networking WIDS is an overlay. Will likely show false positives for poorly performing clients, or very dense client environments. Only enable if HPE Aruba Networking WLAN is the overlay, and customer is high security conscious.

Detect Malformed Frame Large Duration

The virtual carrier-sense attack is implemented by modifying the 802.11 MAC layer implementation to allow random duration values to be sent periodically. This attack can be carried out on the ACK, data, RTS, and CTS frame types by using large duration values. This attack can prevent channel access to legitimate users.

Recommend disable. Will likely show false positives for poorly performing clients, or very dense client environments, as other vendor’s APs often send Large Duration frames. Leads to large duration to an extended hold down timers.

Detect Misconfigured AP

A list of parameters can be configured to define the characteristics of a valid AP. This feature is primarily used when non-HPE Aruba Networking APs are used in the network, since the HPE Aruba Networking gateway cannot configure the thirdparty APs. These parameters include WEP, WPA, OUI of valid MAC addresses, valid channels, and valid SSIDs.

Recommend disable unless there is a 3rd party WLAN being monitored. May often show false positives from poorly performing clients or dense client environments. May catch an AP spoofing in different location. If enabled, it’s only for high security conscious customers with controlled physical environments, and limited neighboring WLANs.

Detect Windows Bridge

A Windows Bridge occurs when a client that is associated to an AP is also connected to the wired network and has enabled bridging between these two interfaces.

Recommend enable for security conscious customers. Should generally be a low false positive alert.

Detect Wireless Bridge

Wireless bridges are normally used to connect multiple buildings together. However, an attacker could place (or have an authorized person place) a wireless bridge inside the network that would extend the corporate network somewhere outside the building. Wireless bridges are somewhat different from rogue APs, in that they do not use beacons and have no concept of association. Most networks do not use bridges – in these networks, the presence of a bridge is a signal that a security problem exists.

Recommend enable, though non-HPE Aruba Networking wireless bridges must be marked as ‘Valid’. Does not trigger on ArubaOS Mesh but may trigger on other vendor’s mesh solutions.

Detect Broadcast Deauthentication

A deauthentication broadcast attempts to disconnect all stations in range. Rather than sending a spoofed deauth to a specific MAC address, this attack sends the frame to a broadcast address.

Recommend enable, may require on-site troubleshooting to narrow own source.

Detect Broadcast Dissociation

By sending disassociation frames to the broadcast address (FF:FF:FF:FF:FF:FF), an attacker can disconnect all stations on a network for a widespread DoS.

Recommend enable, may require on-site troubleshooting to narrow own source.

Detect NetStumbler

NetStumbler is a popular wardriving application used to locate 802.11 networks. When used with certain NICs, NetStumbler generates a characteristic frame that can be detected. Version 3.3.0 of NetStumbler changed the characteristic frame slightly.

Recommend disable, is not a common threat vector anymore.

Detect Valid SSID Misuse

If an unauthorized AP (neighbor or interfering) is using the same SSID as an authorized network, a valid client may be tricked into connecting to the wrong network. If a client connects to a malicious network, security breaches or attacks can occur.

Recommend enable.

Detect Wellenreiter

Wellenreiter is a passive wireless network discovery tool used to compile a list of APs along with their MAC address, SSID, channel, and security setting in the vicinity. It passively sniffs wireless traffic, and with certain version (versions 1.4, 1.5, and 1.6), sends active probes that target known default SSIDs.

Recommend disable, as it’s based on WEP and WEP should NOT be in use anymore.

3.3.3.2 - Client event detection levels and signature descriptions

Client event detection levels and signature descriptions provide a concise overview of the detection levels and detailed descriptions for events related to wireless clients. These classifications help in understanding and managing the severity of events within a wireless network. Detection levels range from low to high, indicating the potential impact of client-related incidents. Signature descriptions offer specific details about the nature and characteristics of each event, aiding in prompt identification and appropriate response to potential issues in the wireless environment. Together, these features enhance network administrators’ ability to proactively address client-related events for improved network security and performance.

Client event detection levels

The available detection levels that can be configured for client events.

Low

  • Detect valid client mis-association

Medium

  • Detect Disconnect Station Attack

  • Detect Omerta Attack

  • Detect FATA-Jack Attack

  • Detect Block ACK DoS

  • Detect Hotspotter Attack

  • Detect unencrypted valid client

  • Detect Power Save DoS Attack

High

  • Detect EAP rate anomaly

  • Detect rate anomaly

  • Detect Chop Chop Attack

  • Detect TKIP Replay Attack

  • IDS signature – Air Jack

  • IDS signature – ASLEAP

  • Detect ghost tunnel client attack

Client events - names and descriptions

A listing of the available client event signatures along with the description from the user guide and engineering.

Detect Block ACK DoS

The Block ACK mechanism that was introduced in 802.11e, and enhanced in 802.11n D3.0, has a built-in DoS vulnerability. The Block ACK mechanism allows for a sender to use the ADDBA request frame to specify the sequence number window that the receiver should expect. The receiver will only accept frames in this window. An attacker can spoof the ADDBA request frame causing the receiver to reset its sequence number window and thereby drop frames that do not fall in that range.

Very prone to false positives from low SNR clients, as well as other mobile devices with poor client driver behavior. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect ChopChop Attack

ChopChop is a plaintext recovery attack against WEP encrypted networks. It works by forcing the plaintext, one byte at a time, by truncating a captured frame and then trying all 256 possible values for the last byte with a corrected CRC. The correct guess causes the AP to retransmit the frame. When that happens, the frame is truncated again.

Recommend disable, as this attack is based on WEP and WEP should NOT be in use anymore.

Detect Disconnect Station Attack

A disconnect attack can be launched in many ways; the result is that the client is effectively and repeatedly disconnected from the AP.

Prone to false positives based on how some clients disassociate/disconnect from Wi-Fi. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect EAP Rate Anomaly

To authenticate wireless clients, WLANs may use 802.1X, which is based on a framework called Extensible Authentication Protocol (EAP). After an EAP packet exchange, and the user is successfully authenticated, the EAP-Success is sent from the AP to the client. If the user fails to authenticate, an EAP-Failure is sent. In this attack, EAP-Failure or EAP-Success frames are spoofed from the access point to the client to disrupting the authentication state on the client. This confuses the clients state, causing it to drop the AP connection. By continuously sending EAP Success or Failure messages, an attacker can effectively prevent the client from authenticating with the APs in the WLAN.

Prone to false positives in EAP environments. If proper security is in place (WPA2 using RADIUS and valid certs with validation enabled, etc.), the risk is minimal. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining.

Detect FATA-Jack Attack structure

FATA-Jack is an 802.11 client DoS tool that tries to disconnect targeted stations using spoofed authentication frames that contain an invalid authentication algorithm number.

Recommend enable unless WIDS is monitoring open/public WLAN networks.

Detect Hotspotter Attack

The Hotspotter attack is an evil-twin attack which attempts to lure a client to a malicious AP. Many enterprise employees use their laptop in Wi-Fi area hotspots at airports, cafes, malls etc. They have SSIDs of their hotspot service providers configured on their laptops. The SSIDs used by different hotspot service providers are well known. This enables the attackers to set up APs with hotspot SSIDs in close proximity of the enterprise premises. When the enterprise laptop client probes for hotspot SSIDs, these malicious APs respond and invite the client to connect to them. When the client connects to a malicious AP, several security attacks can be launched on the client. Airsnarf is a popular hacking tool used to launch these attacks.

Recommend disable, especially for dense WLAN environments or when the monitored WLAN is within/surrounded by many neighboring WLANs. Very high false positives, and most threats are covered by other WIDS signatures.

Detect a Meiners Power Save DoS Attack

To save on power, wireless clients will “sleep” periodically, during which they cannot transmit or receive. A client indicates its intention to sleep by sending frames to the AP with the Power Management bit ON. The AP then begins buffering traffic bound for that client until it indicates that it is awake. An intruder could exploit this mechanism by sending (spoofed) frames to the AP on behalf of the client to trick the AP into believing the client is asleep. This will cause the AP to buffer most, if not all, frames destined for the client.

High false positives are possible in dense environments or where clients roam rapidly in short periods of time. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining, as clients are very PS-Poll aggressive.

Detect Omerta Attack

Omerta is an 802.11 DoS tool that sends disassociation frames to all stations on a channel in response to data frames. The Omerta attack is characterized by disassociation frames with a reason code of 0x01. This reason code is “unspecified” and is not used under normal circumstances.

While exact device identification is impossible due to the nature of the attack, general localization of the alert is possible. Recommend enable.

Detect Rate Anomalies

Many DoS attacks flood an AP or multiple APs with 802.11 management frames. These can include authenticate/associate frames, which are designed to fill up the association table of an AP. Other management frame floods, such as probe request floods, can consume excess processing power on the AP.

Prone to false positives in dense environments, or areas where large numbers of clients and/or APs are located. Recommend disable unless customer is a high security conscious customer that is willing to tune the thresholds based on client baselining, as clients are very PS-Poll aggressive.

Detect TKIP Replay Attack

TKIP is vulnerable to replay (via WMM/QoS) and plaintext discovery (via ChopChop). This affects all TKIP usage in WPA and WPA2. By replaying a captured TKIP data frame on other QoS queues, an attacker can manipulate the RC4 data and checksum to derive the plaintext at a rate of one byte per minute. By targeting an ARP frame and guessing the known payload, an attacker can extract the complete plaintext and MIC checksum. With the extracted MIC checksum, an attacker can reverse the MIC AP to Station key and sign future messages as MIC compliant, opening the door for more advanced attacks.

Would only be enabled if there is a TKIP-based SSID being monitored. All SSIDs now should be WPA2-based (using AES instead of TKIP). Recommend disable unless customer has a TKIP-based SSID WLAN.

Detect Unencrypted Valid Clients

An authorized (valid) client that is passing traffic in unencrypted mode is a security risk. An intruder can sniff unencrypted traffic (also known as packet capture) with software tools known as sniffers. These packets are then reassembled to produce the original message.

Recommend enable, unless one of the monitored WLANs are open. Should not be enabled where Open SSIDs are being monitored as it will generate a large number of alerts.

Detect Valid Client Misassociation

This feature does not detect attacks, but rather it monitors authorized (valid) wireless clients and their association within the network. Valid client misassociation is potentially dangerous to network security. The four types of misassociation monitored are:

  1. Authorized Client associated to Rogue: A valid client that is associated to a rogue AP.

  2. Authorized Client associated to External AP: An external AP, in this context, is any AP that is not valid and not a rogue.

  3. Authorized Client associated to Honeypot AP: A honeypot is an AP that is not valid but is using an SSID that has been designated as valid/protected.

  4. Authorized Client in ad hoc connection mode: A valid client that has joined an ad hoc network.

Recommend enable for any high security conscious customers where clients should NOT be connecting to non-HPE Aruba Networking or non-Monitored WLAN SSIDs.

Detect AirJack

AirJack is a suite of device drivers for 802.11(a/b/g) raw frame injection and reception. It was intended to be used as a development tool for all 802.11 applications that need to access the raw protocol. However, one of the tools included allowing users to force all users off an AP.

Recommend disable, except maybe for very high security conscious customers.

Detect ASLEAP

ASLEAP is a tool created for Linux systems used to attack Cisco LEAP authentication protocol.

Recommend disable unless the HPE Aruba Networking WIDS is an overlay monitoring a Cisco WLAN that uses LEAP.

Detect Null Probe Response

A null probe response attack has the potential to crash or lock up the firmware of many 802.11 NICs. In this attack, a client probe-request frame will be answered by a probe response containing a null SSID. Several popular NIC cards will lock up upon receiving such a probe response.

Recommend disable unless large numbers of disconnects are seen with an unknown cause. Most modern NICs are NOT vulnerable.

3.3.4 - Classification

Definitions and methods of classification used to protect the network.

Upon detection, APs and client devices must be accurately classified to determine whether they are valid, interfering, or rogues.

Terminology

APs and clients that are discovered during scanning of the wireless channels are classified into different groups.

AP definitions

Classification Description
Authorized An AP that is part of the enterprise providing WLAN service.
Neighbor A neighboring AP is when the BSSIDS are known. Once classified, a neighboring AP does not change the classification.
Interfering An AP that is seen in the RF environment but is not connected to the wired network. An interfering AP is not considered a direct security threat since it is not connected to the wired network. For example, an interfering AP can be an AP that belongs to a neighboring office’s WLAN but is not part of your WLAN network.
Rogue An unauthorized AP that is plugged into the wired side of the network.
Suspected Rogue A suspected rogue AP is an unauthorized AP that may be plugged into the wired side of the network.
Contained An AP for which  DoS is enabled manually.

Client definitions

Classification Description
Authorized Any client that successfully authenticates with a valid AP and passes encrypted traffic.
Contained Any clients for which DoS is enabled manually.
Interfering A client associated to any AP and is not valid.

Methods

A discovered device is classified into one of the above definitions by the following methods:

  • Internal heuristics

  • Device level classification

  • Rule-based calssification

  • Manual classification

Device level classification

Device classification is a combination of cloud processing and edge processing. By default, HPE Aruba Networking access points can continuously monitor the network and discover rogue access points without intervention from Central. Central classification, when enabled, takes precedence.

Internal heuristics

The internal heuristics works by checking if the discovered AP is communicating with a wired device on the customer network. This is done by matching the  MAC address of devices that are on the discovered AP’s network with that of the user’s wired network. The MAC of the device on the discovered AP’s network is known as the Match MAC.

Match methods

The match methods are:

  • Plus One - The MAC address detected correlates with the MAC address of an already detected device, with the last bit of the MAC address being one more than that of the Match MAC.

  • Minus One - The MAC address detected correlates with the MAC address of an already detected device, with the last bit of the MAC address being one less than that of the Match MAC.

  • Equal - The match was against the same MAC address.

  • OUI - The match was against the manufacturer’s OUI of the wired device.

Match types

Eth-Wired-MAC

The MAC addresses of wired devices learned by an AP on the Ethernet interface.

GW-Wired-MAC

The collection of Gateway MACs of all managed devices.

AP-Wired-MAC

The MAC addresses of wired devices learned by monitoring traffic out of other valid and rogue APs.

Config-Wired-MAC
The MAC addresses that are configured by the user, typically that of well-known servers in the network.
Manual

User-triggered classification.

External-Wired-MAC

The MAC address matched a set of known wired devices that are maintained in an external database.

Mobility-Manager

The classification was determined by the mobility manager.

Classification-off

AP is classified as rogue because classification has been disabled, causing all non-authorized APs to be classified as rogue.

Propagated-Wired-MAC

The MAC addresses of wired devices learned by an AP other than the AP that used the information for classifying a rogue.

Base-BSSID-Override

The classification was derived from another BSSID, which belongs to the same AP that supports multiple BSSIDS on the radio interface. For HPE Aruba Networking OUIs, if the base BSSID of a beacon matches the base BSSID of a known valid BSSID then the new BSSID is not considered to be valid.

AP-Rule

A user-defined AP classification rule has matched.

System-Wired-MAC

The MAC addresses of wired devices learned on the managed device.

System-Gateway-MAC

The Gateway MAC addresses learned on the managed device.

Rule-based classification

Rules available for classification is dependent on the environment being used and is different for AOS 8 vs AOS 10.

Mobility conductor (AOS-8)

AP classification rule configuration is only performed on a Mobility Conductor. A rule is identified by the ASCII character string name (32 characters maximum). The AP classification rules have three possible specifications.

SSID of the AP

Each rule can have up to 6 SSID parameters. If one or more SSIDS are specified in a rule, an option of whether to match any of the SSIDs or not match all the SSIDs can be specified. The default is to check for a match operation.

SNR of the AP

Each rule can have only one specification of the SNR. A minimum and/or maximum can be specified in each rule, and the specification is in SNR (dB).

Discovered-AP-Count or the number of APs that can see the AP

Each rule can have only one specification of the Discovered-AP-Count. Each rule can specify a minimum or maximum of the Discovered-AP-count. The minimum or maximum operation must be specified if the Discovered-AP-count is specified. The default setting is to check for the minimum discovered-AP-count.

Central (AOS-10)

WIDS rules in Central work in conjunction with the WIDS Module on the AP. While the APs are not dependent on Central to detect rogue events, Central classifications take precedence over device level classifications.

With WIDS in Central, administrators can create a detailed definition of what constitutes a rogue device, and quickly act on a rogue AP for investigation, restrictive action, or both.

AP classification rule configuration is performed on Central. There are three default rules available to help classify rogue and suspected rogue devices, with the ability to create custom rule sets based on different criteria such as detecting AP count, SSID value, time spent on the network, etc. The Rule Classification Criteria page describes all the available criteria that are configurable in Central.

Manual classification

With this method, the wireless administrator monitors the IDS events and manually re-classifies one or more devices to a particular definition such as Interfering, Suspected Rogue or Rogue.

Classification hierarchy

WIDS uses a hierarchy to classify detected devices:

  1. Interfering

  2. Suspected Rogue

  3. Rogue

  4. Neighbor (Known Interfering)

  5. Manually Contained (DoS)

  6. Valid

In the lifecycle of a monitored AP, the classification can only be promoted (i.e., go higher in the list) and can never be demoted (i.e., reduced to a lower value).

This same behavior also applies to the custom rules. For example, if a neighbor AP is already classified as Rogue, then any subsequent rule match will never demote the classification to Suspected Rogue.

WIDS classifications for detected infrastructure devices.

3.3.5 - Protection

How containment works, and types of infrastructure and client containment options offered by HPE Aruba Networking Central.

WIDS offers a wide selection of protection features to protect the network against the threats detected. Device detection and classification are the first steps in securing the network environment from unauthorized wireless access. Adequate measures that quickly shut down intrusions are critical in protecting sensitive information and network resources.

Intrusion protection features support containment of an AP or a client device. In the case of an AP, all the clients that are connected or attempting to connect to the AP are disconnected. In the case of a client, the client’s association to an AP is targeted.

The following containment mechanisms are supported:

  • Wired containment - When enabled, APs generate ARP packets on the wired network to contain wireless attacks.

This feature enables containment from the wired side of the network. The basic wired containment feature isolates layer-3 APs whose wired interface MAC addresses are the same as (or one character off from) their BSSIDs. The enhanced wired containment feature can also identify and contain an AP with a preset wired MAC address that is completely different from the AP’s BSSID. In many non-HPE Aruba Networking APs, the MAC address the AP provides to wireless clients as a gateway MAC is offset by one character from its wired MAC address. This enhanced feature allows AOS to check to see if a suspected Layer-3 rogue AP’s MAC address follows this common pattern.

Recommend enable. Wired rogue detection is based on MAC pattern assumption and is a valid mechanism to protect your wired network from rogues. Both Security and Legal should be consulted and approval given before it is enabled in the network.

  • Wireless containment - When enabled, the system attempts to disconnect all clients that are connected or attempting to connect to the identified access point.

Infrastructure intrusion protection options

The following are the protection options that can be enabled in HPE Aruba Networking Central against infrastructure intrusion events.

Protection Against Rogue Containment

By default, rogue APs are not automatically disabled. Rogue containment automatically disables a rogue AP by preventing clients from associating to the AP.

This option is disabled by default, as this has far reaching implications regarding the FCC and possible fines. Both Security and Legal should be consulted and approval given before it is enabled in the network. Tarpitting should be the preferred method of containment.

Protecting SSIDs

Protect SSID enforces that valid/protected SSIDs are used only by valid APs. An offending AP is contained by preventing clients from associating to the AP.

This can be a problem for Govroam and eduroam, as just two examples. This should not be enabled as the behavior has far reaching implications regarding the local regulatory body and possible fines. Both Security and Legal should be consulted and approval given before enabling this functionality.

Protection Against AP Impersonation

Protection from AP impersonation involves containing both the legitimate and impersonating AP so that clients cannot connect to either AP.

Should not be enabled, can be disruptive. If enabled, it should only be done when all AP impersonation alerts have been verified.

Protecting Against Ad Hoc Networks

Protection from an ad hoc network involves containing the ad hoc network so that clients cannot connect to the offending device.

If needed, this feature should be enabled with caution as there could be an impact to WLAN quality as much of the airtime would be spent de-authenticating ad hoc devices.

Legacy options in AOS 8

Protecting 40 MHz 802.11n High Throughput Devices

Protection from AP(s) that support 40 MHz HT involves containing the AP such that clients cannot connect.

Recommend to disable, has HUGE implications. Is a legacy setting and should never be enabled.

Protecting 802.11n High Throughput Devices

Protection from AP(s) that support HT involves containing the AP such that clients cannot connect.

Recommend to disable, has HUGE implications. Is a legacy setting and should never be enabled.

Protection Against Misconfigured APs

Protect Misconfigured AP enforces that valid APs are configured properly. An offending AP is contained by preventing clients from associating to the AP.

Should not be enabled except in high security areas where no other BSSIDs/ESSIDs can be seen (only in isolated WLAN environments where there are no neighboring buildings). Has far-reaching implications where neighboring WLANs could be disrupted. Approved non-HPE Aruba Networking WLANs would need to be marked as Valid.

Protection Against Wireless Hosted Networks

Clients using the Windows wireless hosted network feature can act as an access point to which other wireless clients can connect, effectively becoming a Wi-Fi HotSpot. This creates a security issue for enterprises because unauthorized users can use a hosted network to gain access to the corporate network, and valid users that connect to a hosted network are vulnerable to attacks or security breaches. This feature detects a wireless hosted network, and contains the client hosting this network.

This should be disabled, as this has far reaching implications regarding the FCC and possible fines. Both Security and Legal should be consulted and approval given before this is ever enabled at any customers site.

Protecting Against Suspected Rogue Containment

By default, suspected rogue APs are not automatically contained. In combination with the suspected rogue containment confidence level, suspected rogue containment automatically disables a suspect rogue by preventing clients from associating to the rogue device.

This should be disabled, as this has far reaching implications regarding the FCC and possible fines. Both Security and Legal should be consulted and approval given before this is ever enabled at any customers site. This is the most dangerous of containment as suspect rogue alerts are only based on confidence levels and can easily be misconfigured.

Client intrusion protection options

The following are the protection options that can be enabled in HPE Aruba Networking Central against client intrusion events.

Protecting Valid Stations

Protecting a valid client involves disconnecting the client if associated to a non-valid AP.

Recommend disable. If looking to enable, Great care should be used here to make sure no valid clients that associate to the monitored WLAN could associate to another non-valid WLAN. If hotspots, restaurants, etc. are nearby, there is a good chance a valid station could go off-site and associate to the non-valid.

Protecting Windows Bridge

Protecting from a Windows Bridge involves containing the client that is forming the bridge so that the client cannot connect to the AP.

Recommend disable, unless Detect Windows Bridges are seen, and investigations show they are not false-positives.

Containment on APs vs. AMs

APs in both Access Point mode and Air Monitor mode detect and mitigate possible security threats in a wireless network.

APs can perform wireless containment, but they will prioritize client traffic over containment. This is a very important distinction and the reason why Air Monitors (AMs) are recommended if wireless containment is enabled. For example, if an AP is serving clients on Channel 36 and there is a rogue on Channel 48 the AP will not change channels to contain the rogue. If the rogue happens to be on channel 36, the AP will perform wireless containment while serving clients.

AMs in contrast will alter their scanning algorithm when containing to make sure they visit the channel where containment is occurring frequently. They will continue to scan for additional threats on other channels.

Both APs and AMs support containment of rogue APs and prevent clients from associating with rogue APs. They tarpit or deauthentication containment frames if any of the following criteria is met:

  • When an AP is marked for Denial-of-Service (DoS), a single broadcast deauthentication frame is sent for disassociation and if stations do not honor the broadcast message, two unicast deauthentication frames are sent to disassociate the station from the AP and vice versa.

  • To disassociate a valid station from the non-valid AP, a unicast deauthentication frame is sent from the station’s MAC address to the AP and vice versa.

  • AP impersonation is active, and it disassociates all stations from the invalid AP by sending unicast deauthentication frames.

3.3.6 - Configuring, Monitoring and Reporting WIDS

A summary of steps for configuring WIDS classification rules, monitoring WIDS events and reporting threats.

Configuring WIDS

Captured below are the typical configuration workflows for WIDS in HPE Aruba Networking Central. For step-by-step instructions, refer to the Central user documentation.

Enabling rule classification

To enable WIDS, navigate to the Configuration option under the Security tab, and enable the toggle to start monitoring for Rogue APs and create classification rules.

Configuration gear under Security

Toggle to enable WIDS rules

Follow the Central user documentation for step-by-step instructions on enabling WIDS rules.

Configuring rules

After enabling WIDS in the UI, the set of three default classification rules will take effect and a maximum of 32 custom rules can be configured. Multiple conditions can be defined in a single rule, and they are all used with an “AND” operand, which means that a rule will only be applied if all the criteria in that rule are matched.

List of default rules. Click on + to create a custom rule

Add one or more conditions to the custom rule

Follow the Central user documentation for step-by-step instructions on creating and configuring custom rules.

Rule ordering matters as rules are evaluated from top to bottom in the custom rule list. Whenever a rule match is found, that rule is executed and no further rule evaluation takes place. Ordering of the rules from lower classifications to higher classifications is important for proper operation. If a neighbor AP gets manually classified by the administrator, then no rules will be evaluated for that AP. If the classification rule selects a non-final state classification (i.e., Interfering or Suspected Rogue), then AP rogue detection algorithms will continue to be applied at the edge where further monitoring of the AP may result in the determination that the AP is in fact a rogue and have the classification updated accordingly.

Monitoring WIDS events

Rogue events

The Rogues tab provides a list of all the APs that have been detectd in the network and their corresponding classifications.

Example of a rogue classification

The Central user documentation captures more details on interpreting rogue events and device classifications.

WIDS events

The IDS tab provides a list of potential threats detected by HPE Aruba Networking access points at the infrastructure and client levels.

Example of a potential client level threat

Central consolidates multiple attacks within a single event to reduce noise. Each displayed event corresponds to a specific MAC address, where multiple events (if generated) are aggregated for each of those MAC addresses.

  • Multiple APs reporting the same event

  • Several attacks against the same MAC address

Use the Central user documentation for instructions on interpreting each of the different fields in the event view.

Generating WIDS alerts

Wireless administrators can set up alerts for different types of infrastructure and client attacks. For instructions, check out the Central user documentation.

Generating WIDS reports

HPE Aruba Networking Central provides administrators the ability to generate reports for IDS events. For details on creating reports, refer to the Central user documentation.

3.4 - Client authentication options and operations

This section covers RADIUS Authentication for secure user access, RADIUS Accounting for tracking network usage, and Captive Portals for controlling access via web-based logins.

3.4.1 - RADIUS accounting

An explanation of RADIUS accounting behavior in AOS-10 deployments, capturing general differences with AOS-8, and specifically with Acct-Multi-Session-Id and Acct-Session-Id behavior during fast roaming.

RADIUS accounting is a method of collecting resource consumption data to be forwarded to a RADIUS server. This data can be used for trend analysis, capacity planning, billing, auditing, and cost analysis. The Network Access Server (NAS) is a RADIUS client responsible for passing user accounting information to the RADIUS server. The server receives this request and returns a response to the NAS.

In AOS-8 campus deployments, RADIUS accounting messages are always sent directly from the controller that functions as the NAS. When a client device roams between APs, the controller continues sending interim updates without the need for a stop and a new start message.

In AOS-10 deployments, the accounting behavior differs based on the deployment scenario:

  1. Bridge mode - A deployment with only APs.
  2. Tunneled and mixed modes - Deployments that involve gateways.

For RADIUS accounting in AOS-10, two key attributes are explored.

  1. Acct-Multi-Session-Id: Identifier remains constant across related sessions, such as during client roaming and links multiple events into a single logical session for seamless tracking.
  2. Acct-Session-Id: Unique identifier changes with each new session, such as when a client re-authenticates with a different AP, helping to track individual session events.

Bridge mode - no roaming

In bridge mode without client roaming, each access point (AP) handles traffic forwarding directly to the local VLAN where the client resides. The AP acts as the NAS for the client, and is responsible for initiating and managing RADIUS communications.

Bridge mode communication without client roaming.

In this scenario, RADIUS accounting messages are sent by the AP. Since there is no roaming involved, a single Acct-Session-Id is used for the duration of the connection, and no changes to the Acct-Multi-Session-Id is necessary.

Accounting start: When the client connects to the AP, the AP sends a ‘Start’ message to the RADIUS server.

A Wireshark capture showing Accounting-Request “Start” sent from AP (NAS):10.82.74.202 to the RADIUS server:10.82.75.11

Accounting interim update: If interim updates are enabled, the AP sends an ‘Alive’ update to the RADIUS server.

A Wireshark capture showing Accounting-Request “Alive” sent from AP (NAS):10.82.74.202 to the RADIUS server:10.82.75.11

Accounting stop: When the client disconnects with the AP, a ‘Stop’ message is sent from the AP to the RADIUS server.

A Wireshark capture showing Accounting-Request “Stop” sent from AP (NAS):10.82.74.202 to the RADIUS server:10.82.75.11

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 15:15:14.651  rad-acct-start   ->                  1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -   
Nov  4 15:23:32.051  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -       
Nov  4 15:24:06.517  eap-logoff   ->                      1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -    
Nov  4 15:24:06.517  dot1x-timeout *                      1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            11  512  station timeout
Nov  4 15:24:06.527  rad-acct-stop   ->                   1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -    
AP-8-635# show clock                  

Current Time     :2024-11-04 15:24:32
AP-8-635#

Tunnel mode - no roaming

In tunnel mode without client roaming, traffic from the client is tunneled from the AP to the gateway. The gateway acts as a RADIUS proxy and forwards authentication and accounting requests for all tunnel-mode clients. To learn more about Tunnel forwarding mode, refer to Tunnel Forwarding.

In this configuration, RADIUS accounting messages originating from the AP is sent to and forwarded by the gateway, ensuring consistent tracking and accounting of client sessions. Since there is no client roaming involved, the accounting behavior is straightforward, with a single Acct-Session-Id and Acct-Multi-Session-Id assigned and maintained for the duration of the client’s session.

Tunnel mode RADIUS communication without client roaming.

Accounting start: When a client associates to an AP, an accounting ‘Start’ request is sent from the AP and forwarded by the gateway to the RADIUS server.

A Wireshark capture showing Accounting-Request “Start” forwarded by the gateway (RADIUS Proxy):172.30.32.21 to the RADIUS server:10.82.75.11.

Accounting interim update: If interim updates are enabled, the gateway forwards an ‘Alive’ update to the RADIUS server.

A Wireshark capture showing Accounting-Request “Alive” forwarded by the gateway (RADIUS Proxy):172.30.32.21 to the RADIUS server:10.82.75.11.

Accounting stop: When the client disconnects from the AP, an accounting ‘Stop’ request is sent from the AP and forwarded by the gateway to the RADIUS server.

A Wireshark capture showing Accounting-Request “Stop” forwarded by the gateway (RADIUS Proxy):172.30.32.21 to the RADIUS server:10.82.75.11.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 15:38:32.494  rad-acct-start   ->                  26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -   - 
Nov  4 15:38:33.605  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:7c:71                    -   -   
Nov  4 15:41:36.080  eap-logoff   ->                      26:08:2c:70:91:b9  74:9e:75:41:7c:71                    -   -    
Nov  4 15:41:36.081  dot1x-timeout *                      26:08:2c:70:91:b9  74:9e:75:41:7c:71                    11  512  station timeout
Nov  4 15:41:36.093  rad-acct-stop   ->                   26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -   -    
AP-8-635# show clock

Current Time     :2024-11-04 15:42:06
AP-8-635#  

Mixed mode - no roaming

In mixed mode with no client roaming, both tunneled and bridged client sessions rely on the gateway as the RADIUS proxy. In this scenario, with no client roaming, Acct-Session-Id and Acct-Multi-Session-Id remain stable, simplifying RADIUS accounting and maintaining a consistent session context throughout the client’s connection. To learn more about mixed mode, refer to Mixed Forwarding.

Bridged client sessions

When the mixed mode WLAN client session is handled as bridged, client traffic is bridged at the AP level, with user VLANs assigned directly on the AP. However, the gateway still forwards all RADIUS communications as the proxy, including accounting messages.

RADIUS communication in a mixed mode WLAN with a bridged client session without client roaming.

Accounting start: When a client associates to an AP, an accounting start request is sent from the AP and forwarded by the gateway to the RADIUS server.

A Wireshark capture showing Accounting-Request “Start” forwarded by the gateway (RADIUS Proxy):172.30.32.22 to the RADIUS server:10.82.75.11.

Accounting interim update: If interim updates are enabled, the gateway forwards an ‘Alive’ update to the RADIUS server.

A Wireshark capture showing Accounting-Request “Alive” forwarded by the gateway (RADIUS Proxy):172.30.32.22 to the RADIUS server:10.82.75.11.

Accounting stop: When the client disconnects from the AP, an accounting ‘Stop’ request is sent from the AP and forwarded by the gateway to the server.

A Wireshark capture showing Accounting-Request “Stop” forwarded by the gateway (RADIUS Proxy):172.30.32.22 to the RADIUS server:10.82.75.11.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 16:40:10.729  rad-acct-start   ->                  ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -  
Nov  4 16:40:10.950  rad-acct-int-update   ->             ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72                    -    -  
Nov  4 16:41:47.646  rad-acct-stop   ->                   ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -  

Tunneled client sessions

For mixed mode WLAN client sessions handled as tunneled, the gateway acts as the RADIUS proxy, with the gateway’s IP address used as the NAS IP. RADIUS accounting messages for these clients is forwarded by the gateway, centralizing session and accounting management.

RADIUS communication in a mixed mode WLAN with a tunneled client session without client roaming.

Accounting start: When a client associates to an AP, an accounting ‘Start’ request is sent from the AP and forwarded by the gateway to the RADIUS server.

A Wireshark capture showing Accounting-Request “Start” forwarded by the gateway (RADIUS Proxy):172.30.32.22 to the RADIUS server:10.82.75.11.

Accounting interim update: If interim updates are enabled, the gateway forwards an ‘Alive’ update to the RADIUS server.

A Wireshark capture showing Accounting-Request “Alive” forwarded by the gateway (RADIUS Proxy):172.30.32.22 to the RADIUS server:10.82.75.11.

Accounting stop: When the client disconnects with the AP, an accounting ‘Stop’ request is sent from the AP and forwarded by the gateway to the server.

A Wireshark capture showing Accounting-Request “Stop” forwarded by the gateway (RADIUS Proxy):172.30.32.22 to the RADIUS server:10.82.75.11.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  4 16:40:10.729  rad-acct-start   ->                  ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -   
Nov  4 16:40:10.950  rad-acct-int-update   ->             ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72                    -    -  
Nov  4 16:41:47.646  rad-acct-stop   ->                   ba:bd:6f:c2:d6:50  74:9e:75:41:7c:72/__gw_172.30.32.22  -    -  

Bridge mode with roaming

In bridge mode with client roaming, user traffic is locally bridged to the VLAN at each AP. As the client moves between APs, each AP independently acts as the NAS for its connected clients and handles RADIUS communications.

RADIUS Accounting Behavior: When a client roams from one AP to another, the new AP takes over as the NAS, and a new RADIUS accounting start message is generated by this AP. The initial AP sends an accounting stop message to indicate the AP’s end of session management for that client. This ensures accurate tracking and accounting of client sessions across multiple APs.

Bridge mode RADIUS communication when a client roams from AP-1 to AP-2.

Typically, each new connection triggers a change to the Acct-Session-Id, while a consistent Acct-Multi-Session-Id can link these related events for session continuity tracking.

Here’s how accounting messages are exchanged during a client roam from one AP to another:

Accounting start with the Initial AP: When the client connects to the initial AP, the AP sends an accounting start message to the RADIUS server. This message includes updated information about the AP the client is connected to.

A Wireshark capture showing Accounting-Request “Start” from the initial AP:10.82.74.202 to the RADIUS server:10.82.75.11.

Similarly, for interim updates:

A Wireshark capture showing Accounting-Request “Alive” from the initial AP:10.82.74.202 to the RADIUS server:10.82.75.11.

Accounting stop for Initial AP: After the client has roamed, the AP sends an Accounting stop message for the session associated with the initial AP (AP-8-635). This closes out the session tied to that AP.

A Wireshark capture showing Accounting-Request “Stop” from the initial AP:10.82.74.202 to the RADIUS server:10.82.75.11.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  5 16:52:54.440  rad-acct-start   ->                  1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -    
Nov  5 16:56:13.211  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -    
Nov  5 17:01:13.804  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70            -   -    
Nov  5 17:04:30.932  rad-acct-stop   ->                   1a:3a:2c:f7:f5:75  74:9e:75:41:7c:70/clearpass  -   -    
AP-8-635# 

Note the multi Acct-Session-Id: val=26082C7091B9-1730847899 and the Acct-Session-Id : val=749E75417C71-26082C7091B9-672AA529-2D70E

Accounting start from the new AP: Once, the client connects to the new AP, the AP sends an Accounting Start msg for the new session with the new AP (AP-3-635).

A Wireshark capture showing Accounting-Request “Start” from the new-ap:172.30.32.31 to the RADIUS server:10.82.75.11.

Interim updates will proceed from the new AP as usual.

A Wireshark capture showing Accounting-Request “Alive” from the new-ap:172.30.32.31 to the RADIUS server:10.82.75.11.

Buffer trace of this process:

AP-6-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  5 17:04:43.601  rad-acct-start   ->                  1a:3a:2c:f7:f5:75  74:9e:75:41:79:70/clearpass          -   -    
Nov  5 17:05:25.700  rad-acct-int-update   ->             1a:3a:2c:f7:f5:75  74:9e:75:41:79:70                    -   -      
AP-6-635# 

Acct-Session-Id and Acct-Multi-Session-Id Behavior: If the roam is a fast roam, the Acct-Multi-Session-Id remains the same, indicating the same client session. However, the Acct-Session-Id changes to reflect the transition to a new AP.

Acct-Multi-Session-Id on the Initial AP : val=1A3A2CF7F575-1730854373
Acct-Multi-Session-Id on the New AP : val=1A3A2CF7F575-1730854373

Acct-Session-Id on the Initial AP : val=749E75417C70-1A3A2CF7F575-672ABDE6-6B51D
Acct-Session-Id on the New AP : val=74975417970-1A3A2CF7F575-672ACOAB-92AFB

Tunnel mode with roaming

In tunnel mode with client roaming, traffic from the client is tunneled from the AP to the gateway. The gateway acts as a RADIUS proxy and forwards authentication and accounting requests for all tunnel-mode clients.

RADIUS Accounting Behavior: When a client roams from one AP to another, the user designated gateway (UDG) forwards a new RADIUS accounting start message reflecting the updated AP information and an accounting stop message for the initial AP.

Tunnel mode RADIUS communication when a client roams from AP-1 to AP-2.

For fast roaming scenarios, the Acct-Multi-Session-Id remains consistent, linking all related session events to the same logical session, while the Acct-Session-Id changes to reflect the new session context. Here’s the accounting messages being exchanged:

Accounting start with the Initial AP: As the client connects to the initial AP (AP-8-635), the gateway (UDG) forwards an Accounting start message to the RADIUS server. This message includes updated information about the AP the client is connected to.

A Wireshark capture showing Accounting-Request “Start” from the initial User Designated Gateway (UDG):172.30.32.21 to the RADIUS server:10.82.75.11.

Similarly, for interim updates:

A Wireshark capture showing Accounting-Request “Alive” from the initial User Designated Gateway (UDG):172.30.32.21 to the RADIUS server:10.82.75.11.

Accounting stop for initial AP: After the client has roamed, the gateway forwards an Accounting stop message for the session associated with the initial AP (AP-8-635). This closes out the session tied to that AP.

A Wireshark capture showing Accounting-Request “Stop” from the initial User Designated Gateway (UDG):172.30.32.21 to the RADIUS server:10.82.75.11.

Buffer trace of this process:

AP-8-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
Nov  5 15:07:21.187  rad-acct-start   ->                  26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -    - 
Nov  5 15:11:01.515  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:7c:71                    -    - 
Nov  5 15:11:09.949  rad-acct-stop   ->                   26:08:2c:70:91:b9  74:9e:75:41:7c:71/__gw_172.30.32.21  -    -   
AP-8-635#  

Note the multi Acct-Session-Id: val=26082C7091B9-1730847899 and the Acct-Session-Id : val=749E75417C71-26082C7091B9-672AA529-2D70E

Accounting start from the new AP: Once the client connects to the new AP, the gateway (UDG) forwards an Accounting Start msg for the new session with the new AP (AP-3-635).

A Wireshark capture showing Accounting-Request “Start” from the User Designated Gateway (UDG):172.30.32.21 to the RADIUS server:10.82.75.11.

Buffer trace of this process:

AP-3-635# show ap debug auth-trace-buf

Auth Trace Buffer
-----------------
                                                                                                                        
                                                                                                                        
Nov  5 15:11:10.176  station-up *                         26:08:2c:70:91:b9  74:9e:75:41:25:d0                    -  -  wpa2 aes
Nov  5 15:11:10.189  rad-acct-start   ->                  26:08:2c:70:91:b9  74:9e:75:41:25:d0/__gw_172.30.32.21  -  -  
Nov  5 15:11:10.190  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:25:d0                    -  -  
Nov  5 15:14:35.753  rad-acct-int-update   ->             26:08:2c:70:91:b9  74:9e:75:41:25:d0                    -  -  
AP-3-635#   

A Wireshark capture showing Accounting-Request “Alive” from the UDG: 172.30.32.21 to the RADIUS server:10.82.75.11.

Acct-Session-Id and Acct-Multi-Session-Id Behavior: If the roam is a fast roam, the Acct-Multi-Session-Id remains the same, indicating it pertains to the same client session. However, the Acct-Session-Id changes to reflect the transition to a new AP.

Acct-Multi-Session-Id on the Initial AP : val=26082C7091B9-1730847899
Acct-Multi-Session-Id on the New AP : val=26082C7091B9-1730847899

Acct-Session-Id on the Initial AP : val=749E75417C71-26082C7091B9-672AA529-2D70E
Acct-Session-Id on the New AP : val=749E754125D0-26082C7091B9-672AA60E-2DD81

This approach in tunnel mode allows the RADIUS server to track the client’s AP changes while keeping the session continuous through the Acct-Multi-Session-Id.

Mixed mode with roaming

In mixed mode when a client roams, both tunneled and bridged client sessions rely on the gateway as the RADIUS proxy. In this scenario, when a client roams the Acct-Session-Id changes while the Acct-Multi-Session-Id remains the same, simplifying RADIUS accounting and maintaining a consistent Acct-Multi-Session-Id throughout the client’s connection. To learn more about mixed mode, refer to Mixed Forwarding.

Summary

Scenario Acct-Multi-Session-Id Behavior NAS
Bridge with no roaming Acct-Multi-Session-Id and Acct-Session-Id remain the same AP
Tunnel with no roaming Acct-Multi-Session-Id and Acct-Session-Id remain the same Gateway
Mixed with no roaming Acct-Multi-Session-Id and Acct-Session-Id remain the same Gateway (for both types)
Bridge with roaming Acct-Multi-Session-Id remains the same, Acct-Session-Id changes AP
Tunnel with roaming Acct-Multi-Session-Id remains the same, Acct-Session-Id changes Gateway
Mixed with roaming (bridge & tunnel) Acct-Multi-Session-Id remains the same, Acct-Session-Id changes Gateway (for both types)

In summary, a consistent Acct-Multi-Session-Id across a client’s session, including during roaming, provides several benefits. The Acct-Multi-Session-Id enables seamless tracking of a user’s activity, ensuring that all session data is unified even if the client moves between APs. This simplifies session management, billing, and accounting, as all activity is associated with one session, reducing administrative complexity. Additionally, security monitoring is enhanced by creating a clear and consistent record of user activity across the network.

4 - Network operations

Guidance on network operations for wireless networks.

4.1 - DHCP for APs

In-depth guidance on using DHCPv4 options across AP modes and setting up DHCP servers on various devices.

All HPE Aruba Networking Access Points implement a DHCP client as a means of dynamically obtaining IPv4 addressing along with other network configuration parameters. The information provided by a DHCP server is used by the APs to provide the necessary information required to communicate over an IPv4 network and influence the AP mode through standard and vendor specific options.

Comprehensive guidance on using these options, example configurations for multiple devices, and packet captures reference is provided.

4.1.1 - Option implementation

Standard and vendor-specific DHCP options for different modes of access points.

Vendor class identifier

All HPE Aruba Networking Access Points implement DHCP option 60 vendor class identifier (RFC 2132) to sends a specific identifying string to the DHCP server in discovery and request packets. The string value that is forwarded to the DHCP server is dependent on the AP mode.

Type Vendor Class Identifier
AOS-10 AP ArubaAP
AOS-8 Instant AP ArubaInstantAP
AOS-8 Campus AP ArubaAP
AOS-8 Unified AP ArubaInstantAP

Vendor-specific options

HPE Aruba Networking access points support vendor-specific options that can be provided in offer and acknowledgement packets. The type of vendor-specific option that is supported by an AP is dependent on the AP mode. For example an AOS-8 instant Mode AP or an AOS-10 AP can be supplied with HTTP Proxy server information (option 148) while an AOS-8 campus mode AP or an AOS-8 unified AP can be supplied mobility controller information (option 43).

4.1.1.1 - AOS-10

Standard and vendor-specific DHCP options for AOS-10 access points.

Standard forwarded options

The standard options that are supplied by AOS-10 based APs to a DHCP server in discovery and request packets can be used by the DHCP server to supply specific return options.

Code Description Notes/Example
61 Client Identifier The base MAC address of the AP. Example: 8c:9c:d8:ca:73:20
60 Vendor Class Identifier The option 60 value sent by AOS-10 based APs. Example: ArubaAP

The standard and vendor-specific DHCP options that are requested by AOS-10 based APs in discovery and request packets tell the DHCP server which options are supported and can be returned to the APs.

Code Description Notes/Example
55 Parameter Request List
  • 1 (Subnet Mask)
  • 3 (Router)
  • 4 (Time Server)
  • 6 (Domain Name Server)
  • 12 (Host Name)
  • 15 (Domain Name)
  • 28 (Broadcast address)
  • 42 (Network Time Protocol)
  • 43 (Vendor-Specific Information)
  • 60 (Vendor Class Identifier)
  • 66 (TFTP server name)
  • 148 (Proxy Server Information)

Standard return options

The standard DHCP options that can be returned to AOS10-based APs from a DHCP server in offer and acknowledgement packets:

Code Description Format Notes/Example
1 Subnet Mask IP Address The subnet mask assigned by the DHCP server. Example: 255.255.255.0
3 Router IP Address The default gateway assigned by the DHCP server. Example: 10.0.2.1
6 Domain Name Server IP Address A list of DNS servers assigned by the DHCP server (in order of preference). Example: 10.0.2.2
15 Domain Name String The domain name assigned by the DHCP server. Example: arubanetworks.local
42 Network Time Protocol Servers String IP addresses or FQDNs of one or more NTP servers. Example: 10.0.2.50

Vendor-specific return options

The Vendor-Specific DHCP option 148 can be returned to AOS10-based APs for Zero Touch Provisioning (ZTP) via an HTTP proxy server when Activate or Central are accessible through the proxy.

HTTP Proxy

Code Description Format Notes/Example
148 Proxy Server Information String HTTP proxy server IP/FQDN, Port, Username and Password.
  • Example: server=10.0.2.100, port=8080, username=ap1, password=Secure@123
60 Vendor Class Identifier String Must be applied with option 148. Mandatory Value: ArubaAP

4.1.1.2 - AOS-8 unified

Standard and vendor-specific DHCP options for AOS-8 unified access points.

Vendor-specific options are supported by HPE Aruba Networking Unified Access Points using the factory defaulted configuration.Unified Access Points are shipped with a special manufacturing image (reduced functionality) and follow a specific discovery process to connect to a controller-based or controller-less network.

When a unified AP first initializes, it behaves in the same way as an AP operating in instant mode. The standard and vendor-specific DHCP options that are supported mirror what has been captured in the AOS-8 Instant section. Likewise if a Unified AP has been converted into campus mode, the standard and vendor-specific DHCP options that are supported mirror what has been captured in the AOS-8 Campus section. The operating mode determining the DHCP options that are supported.

Campus mode conversion

The vendor-specific DHCP options can be leveraged to convert AOS-8 unified APs into AOS-8 campus mode. When a unified AP boots up, it sends Option 60 as ArubaInstantAP to the DHCP server for identification. The server can modify the AP’s operating mode to campus by returning option 60 as ArubaAP along with Option 43, which points to a mobility controller.

Code Description Format Notes/Example
43 Vendor Specific Information String Mobility Controller IP Address. Example: 10.0.2.15
60 Vendor Class Identifier String Must be supplied with option 43. Mandatory value: ArubaAP

4.1.1.3 - AOS-8 campus

Standard and vendor-specific DHCP options for AOS-8 campus mode access points.

Standard forwarded options

The standard options that are supplied by AOS-8 campus-based APs to a DHCP server in discovery and request packets can be used by the DHCP server to supply specific return options.

Code Description Notes/Example
61 Client Identifier The base MAC address of the AP. Example: 8c:9c:d8:ca:73:20
60 Vendor Class Identifier The option 60 value sent by campus-based APs. Example: ArubaAP

The standard and vendor-specific DHCP options that are requested by AOS-8 campus-based APs in discovery and request packets tells the DHCP server which options are supported and can be returned to the APs.

Code Description Notes/Example
55 Parameter Request List
  • 1 (Subnet Mask)
  • 3 (Router)
  • 4 (Time Server)
  • 6 (Domain Name Server)
  • 12 (Host Name)
  • 15 (Domain Name)
  • 28 (Broadcast address)
  • 42 (Network Time Protocol)
  • 43 (Vendor-Specific Information)
  • 60 (Vendor Class Identifier)

Standard return options

The standard DHCP options that can be returned to AOS-8 campus-based APs from a DHCP server in offer and acknowledgement packets:

Code Description Format Notes/Example
1 Subnet Mask IP Address The subnet mask assigned by the DHCP server. Example: 255.255.255.0
3 Router IP Address The default gateway assigned by the DHCP server. Example: 10.0.2.1
6 Domain Name Server IP Address A list of DNS servers assigned by the DHCP server (in order of preference). Example: 10.0.2.2
15 Domain Name String The domain name assigned by the DHCP server. Example: hpe.com

Vendor-specific return options

The Vendor-Specific DHCP option 43 can be returned to AOS-8 campus-based APs to discovery a mobility controller.

Mobility controller discovery

Code Description Format Notes/Example
43 Vendor Specific Information String Mobility Controller IP Address. Example: 10.0.2.15
60 Vendor Class Identifier String Must be supplied with option 43. Mandatory value: ArubaAP

4.1.1.4 - AOS-8 instant

Standard and vendor-Specific DHCP options for AOS-8 instant mode access points.

Standard forwarded options

The standard options that are supplied by AOS-8 instant-based APs to a DHCP server in discovery and request packets can be used by the DHCP server to supply specific return options.

Code Description Notes/Example
61 Client Identifier The base MAC address of the AP. Example: 8c:9c:d8:ca:73:20
60 Vendor Class Identifier The option 60 value sent by instant-based APs. Example: ArubaInstantAP

The standard and vendor-specific DHCP options that are requested by AOS-8 instant-based APs in discovery and request packets tells the DHCP server which options are supported and can be returned to the APs.

Code Description Notes/Example
55 Parameter Request List
  • 1 (Subnet Mask)
  • 3 (Router)
  • 4 (Time Server)
  • 6 (Domain Name Server)
  • 12 (Host Name)
  • 15 (Domain Name)
  • 28 (Broadcast address)
  • 42 (Network Time Protocol)
  • 43 (Vendor-Specific Information)
  • 60 (Vendor Class Identifier)
  • 66 (TFTP Server Name)
  • 148 (Proxy Server Information)

Standard return options

The standard DHCP options that can be returned to AOS-8 instant-based APs from a DHCP server in offer and acknowledgement packets:

Code Description Format Notes/Example
1 Subnet Mask IP Address The subnet mask assigned by the DHCP server. Example: 255.255.255.0
3 Router IP Address The default gateway assigned by the DHCP server. Example: 10.0.2.1
6 Domain Name Server IP Address A list of DNS servers assigned by the DHCP server (in order of preference). Example: 10.0.2.2
15 Domain Name String The domain name assigned by the DHCP server. Example: hpe.com
42 Network Time Protocol Servers String IP addresses or FQDNs of one or more NTP servers. Example: 10.0.2.50

Vendor-specific return options

The vendor-specific DHCP option 148 can be returned to AOS-8 instant-based APs for Zero Touch Provisioning (ZTP) via an HTTP proxy server when Activate or Central are accessible through the proxy.

HTTP Proxy

Code Description Format Notes/Example
148 Proxy Server Information String HTTP proxy server IP/FQDN, Port, Username and Password.
  • Example: server=10.0.2.100, port=8080, username=ap1, password=Secure@123
60 Vendor Class Identifier String Must be applied with option 148. Mandatory Value: ArubaInstantAP

4.1.2 - Server configuration

DHCP server configuration examples for AOS-10, instant, and campus mode access points across various devices.

AOS-10 mobility/branch gateways

AOS-10 access points

HTTP Proxy

AOS-8 mobility controllers

AOS-8 Unified/Campus mode access points

Mobility controller discovery

    ip dhcp pool vlan77
        domain-name hpe.com
        dns-server 192.168.10.5 192.168.10.6
        default-router 192.168.77.1
        network 192.168.77.0 255.255.255.0
        option 60 text ArubaAP
        option 43 ip 192.168.72.15

AOS-CX switches

AOS-10 access points

HTTP Proxy

    dhcp-server vrf default
      pool vlan77
        default-router 192.168.77.1
        dns-server 192.168.10.5 192.168.10.6
        domain-name hpe.com
        option 42 ip 192.168.77.15
        option 148 ascii "server=192.168.66.30,port=8080,username=ap1,password=aruba123"
        option 60 ascii "ArubaAP"
        range 192.168.77.100 192.168.77.200 prefix-len 24
        exit
      enable

AOS-8 instant mode access points

HTTP Proxy

    dhcp-server vrf default
      pool vlan77
        default-router 192.168.77.1
        dns-server 192.168.10.5 192.168.10.6
        domain-name hpe.com
        option 42 ip 192.168.77.15
        option 148 ascii "server=192.168.66.30,port=8080,username=ap1,password=aruba123"
        option 60 ascii "ArubaInstantAP"
        range 192.168.77.100 192.168.77.200 prefix-len 24
        exit
      enable

AOS-8 unified/campus mode access points

Mobility controller discovery

    dhcp-server vrf default
      pool vlan77
        default-router 192.168.77.1
        dns-server 192.168.10.5 192.168.10.6
        domain-name hpe.com
        option 43 ip 192.168.72.15
        option 60 ascii “ArubaAP”
        range 192.168.77.100 192.168.77.200 prefix-len 24
        exit
      enable

ISC DHCP server

AOS-10 access points

HTTP Proxy

    # Global Options
    option iap-proxy code 148 = text;
    
    # Scope Example
    subnet 192.168.77.0 netmask 255.255.255.0 {
            range 192.168.77.100 192.168.77.250;
            option routers 192.168.77.1;
            option domain-name "hpe.com";
            option ntp-servers 192.168.77.15;
            option vendor-class-identifier "ArubaAP";
            option iap-proxy "server=192.168.66.30,port=8080,username=ap1,password=aruba123";
    }

AOS-8 instant mode access points

HTTP Proxy

    # Global Options
    option iap-proxy code 148 = text;
    
    # Scope Example
    subnet 192.168.77.0 netmask 255.255.255.0 {
            range 192.168.77.100 192.168.77.250;
            option routers 192.168.77.1;
            option domain-name "hpe.com";
            option ntp-servers 192.168.77.15;
            option vendor-class-identifier "ArubaInstantAP";
            option iap-proxy "server=192.168.66.30,port=8080,username=ap1,password=aruba123";
    }

AOS-8 unified/campus mode access points

Mobility controller discovery

     # Global Options
    option controllerip code 43 = ip-address;
    
     # Scope Example
    subnet 192.168.77.0 netmask 255.255.255.0 {
            range 192.168.77.100 192.168.77.250;
            option routers 192.168.77.1;
            option domain-name "hpe.com";
            option vendor-class-identifier "ArubaAP";
            option controllerip 192.168.72.15;   
    }

Microsoft DHCP server

AOS-10 access points

HTTP Proxy

Scope Option 148

Scope Option 60

AOS-8 instant mode access points

HTTP Proxy

Scope Option 148

Scope Option 60

AOS-8 unified/campus mode access points

Mobility controller discovery

Scope Option 43

Scope Option 60

4.1.3 - Reference

Wireshark packet captures of DHCP discover and offer packets for AOS-10, instant, and campus mode access points.

DHCP discover packet decodes

AOS-10 access points

DHCP discover

Option 61- client identifier field

Option 60- vendor class identifier field

Option 55- parameter request list

AOS-8 instant mode access points

DHCP discover

Option 61- client identifier field

Option 60- vendor Class Identifier Field

Option 55- parameter request list

AOS-8 campus mode access points

DHCP discover

Option 61- client identifier field

Option 60- vendor class identifier field

Option 55- parameter request list

DHCP offer packet decodes

AOS-10 access points

DHCP offer

Option 60- vendor class identifier field

Option 148- HTTP proxy server

AOS-8 instat mode access points

DHCP offer

Option 60- vendor class identifier field

Option 148- HTTP proxy server

AOS-8 campus mode access points

DHCP offer

Option 60- vendor class identifier field

Option 43- mobility controller discovery / campus conversion