Tag: cwdp

Tri-Band Radio Trap: Common Pitfalls of Multi-Radio Wi-Fi Access Points

With the arrival of Wi-Fi 7, nearly all vendors now offer access points supporting multiple 5 GHz or 6 GHz radios on a single access point. This advancement gives wireless engineers the powerful tool they’ve sought for years to tackle capacity challenges. But with great power comes great responsibility. In this post, let’s look at the new pitfalls these access points introduce and why using access points in traditional 2.4/5/6 or 5/6 mode by default makes more sense.

The Perception Trap: More capacity – fewer APs?

When engineers mention more radios per AP, management’s first question is often: “Can we use fewer access points and save money?” On paper, more active radios should mean higher capacity and better user experience. But in enterprise Wi-Fi, capacity is not where you begin—it’s coverage that matters first. Design for primary and secondary coverage (with redundancy for failures and roaming), and only then layer additional APs for capacity in high-density areas as needed. This principle should continue to be the foundation for WiFi designs. While in some environments you might reduce AP count with dual-band multi-radio APs, in others—especially non-high-density, closed rooms—coverage and desired redundancy will still determine the deployment count.

The POE Trap: Powering All Those Radios

Enabling multiple radios (dual 5 GHz or 6 GHz, for instance) often requires 802.3bt (> 30W) PoE. Running in lower power (PoE+) mode might drop radios to two streams instead of four, which still provides extra capacity but with trade-offs. More active radios mean a bigger power draw from switches, which can strain port- and chassis-level PoE budgets. Always double-check that your switches can supply the required power before enabling all radios.

The RRM Trap: Interference & Channel Planning

To enable more radios on the same band, vendors restrict radios to specific UNI-bands to avoid adjacent channel interference. For example one radio may be confined to use UNI-1 and UNI-2 and other radio to UNI-2E and UNI-3. In this case, the number of available channels for reuse becomes fewer in the environment. If every AP runs two radios in the same band, managing co-channel interference becomes difficult, and efficient channel planning may be difficult to achieve. You may end up with more co-channel contention, negating the benefits of increased AP capacity.

The Backhaul Trap: Uplink Bottlenecks

With more capacity per access point, there’s a high probability of exceeding 1 Gbps of aggregate throughput across the multiple radios. This means the wired Ethernet connection between the switch and each AP can quickly become a bottleneck, if only standard 1 Gigabit links are in use. If deploying tri-band multi-radio APs, it’s critical to ensure that the backhaul—switch ports, cabling, and AP uplinks—can support higher throughput to avoid undermining wireless performance gains. Consider upgrading to 2.5 or 5 Gigabit Ethernet options where increased capacity is required.

In summary, operating tri-band access points in single-radio on a single-band mode by default—and enabling software-defined radios for additional bands only when justified—helps address capacity constraints without falling into the common traps of backhaul bottlenecks, power limitations, RRM complexity, or misaligned coverage. This careful, needs-driven approach gets the best value from today’s powerful multi-radio hardware without introducing unnecessary risks.

Reinventing WiFi Deployment for Scale

Disclaimer

This post assumes the reader has context of my first blog in the series, Reinventing WiFi Design for Scale. If not, I strongly recommend reading it first for important context and foundational concepts. To keep things simple this post focuses on access points and ignores wireless LAN controllers.

Challenges of Deployment at Scale

WiFi deployment – the installation of access points is the second phase of wireless network implementation. At this point the designs have been completed and necessary hardware procured. At scale, often tens of thousands of access points are installed every year as part of new builds or lifecycle management. The main challenges of deployment at scale can be categorized into 1. Inventory Management 2. Installation 3. Provisioning and 4. Validation, There are different ways to address each of these challenges. The solutions provided in this blog are meant to serve as a basis for building your own framework that fits your use case.

1. Inventory Management

The cookie-cutter designs created for new builds or lifecycle replacements provide an estimate of the hardware requirements for the year. In most cases, hardware is ordered in bulk once or twice a year to take advantage of volume discounts, and all equipment is typically shipped to a central warehouse. As inventory arrives, it is critical to document all MAC addresses, serial numbers, and claim codes (if applicable for your vendor). The cookie-cutter designs specify the exact model and quantity of access points and antennas required for each site scheduled for deployment that year. Use this data to assign inventory per site and prepare shipments that align with the installation schedule. Importantly, this inventory management system should be accessible through a UI to warehouse support resources, installers, and engineering teams, ensuring smooth coordination and visibility throughout the deployment process. This could be as sample as an excel file saved in cloud or a specialized software built for inventory management purposes. Having API access to inventory management can also help engineering with provisioning step that is described later.

When it’s time to deploy, ship the site-specific inventory from the central warehouse to the individual install locations. Access points should be labeled with their designated name and number (more on this later), which can occur at the warehouse or immediately prior to installation onsite. Labeling at the site, handled by installers, is recommended—it offers flexibility if last-minute changes or swaps are necessary and helps ensure accurate placement during the install process.

Maintaining an inventory management system can often be complicated and is certainly outside the skillset of a wireless network engineer. If this is not an option, at a minimum one can create a framework in which the install teams complete an excel worksheet containing below details

  • Name
  • MAC address
  • Serial number
  • Claim codes
  • Access point model
  • Antenna model
  • Install height
  • Allocated site
  • Ship date
  • Install date
  • Switch name
  • Switch port ID
  • Patch panel name
  • Patch panel port ID

The install teams can communicate the completed document with details either through an email or any file sharing methods. The fields in this worksheet can be used for provisioning.

2. Installation

The second challenge with deployment at scale often comes from the fact that the installation can take place across different time zones and often during non business hours. Depending on the size of the team, it may not be possible to provide engineering resources available for support. The worst case scenario is installers wont have anyone to contact with questions that might arise or for validation during the install and the best case scenario is the availability of Network Operations Center (NOC) with enough skilled staff that has 24×7 coverage. In both cases, wireless engineers need to create runbooks and install guides that provides answers to the most frequently asked questions. As described under “Pilot” and “General Availability” sections in the first blog Reinventing WiFi Design for Scale , developing such effective install guides requires constant conversations with install teams during the pilot phase where the cookie cutter design is being deployed in a geographically diverse handful of sites.

Here are some details that need to be included in installation guide package to minimize the errors in the field

  • High resolution design map indicating access pointlocation and name. The design should map should contain legend that distinguishes APs of different model with/without antenna combinations.
  • Worksheet containing the fields described in the earlier section. If none of them are populated, include a guide to scan the details from the hardware and complete the worksheet.
  • Installation procedures that include mounting height, AP/antenna orientation, label requirements (if not done in warehouse), step-by-step mounting instructions with photos, cable standard specifications and length limitations, cable slack requirement and grounding requirements if applicable

The runbook package should contain

  • Patching instructions like distribution of APs across multiple switches in the same IDF
  • Cable test validation between access point and patch panel and from patch panel to the switch prior to access point mounting
  • Basic validation criteria based on LED patterns on the access point and the required troubleshooting steps

The runbooks should also include instructions on how to communicate updated worksheets for proper access point provisioning. Once installation procedures are established, the next step is provisioning.

3. Provisioning

This step often happens at the same time or just prior to installation. This is one step where wireless engineers come with different solutions depending on the level of expertise in automation. I must call out that basic scripting skills is a requirement to be a wireless network engineer at scale even if the company has resources to hire automation experts / software developers to assist the network engineering team. I will describe a couple options that can be leveraged at various levels of automation skillset.

The first one is what can a wireless network engineer do to provision at scale with only basic scripting/programming skills. This is primarily considered backend development skill. At this level wireless engineers are comfortable with writing scripts that can make API calls and handle errors appropriately. Automation through API calls is one of the big reasons why cloud vendor deployments have grown exponentially over the years. One can write a script to take the excel worksheet that the warehouse/installers complete for a site as input to the script and provision the access points. Alternate options include making this script available on a shared resource like a jump server to support staff and NOC engineers who can trigger it based on runbooks. If the inventory management system supports data ingestion through APIs, then this manual process of someone sending in an updated worksheet and someone else triggering the script is not needed. The script can be developed to run periodically and do API calls to inventory management system to get the latest updates and trigger provisioning accordingly.

The second option requires a certain level of front end UI (User Interface) development skill. In this approach, the engineer develops a UI where installers/support engineers can upload the worksheet and initiate provision with a click of a button. This will mask the backend and adds a layer of abstraction that enhances the user experience for all parties involved. In case of more automated interaction with inventory management, once can leverage the UI to provide the status updates on provisioning for each site.

The challenge, then, is developing a provisioning process based entirely on worksheet data. At a high level, most vendors require settings such as radio profiles, device profiles, SSID mappings, VLAN configurations, and radio/channel parameters—but these are not directly mapped from the worksheet. A standardized naming convention for access points allows scripts or UI tools to reliably apply the correct settings to each group.

Just like cookie cutter designs have repeatable grid patterns, access point names or numbers should contain patterns that group settings together. For example, if the deployment requires all the mentioned settings to be applied by type of AP, internal antenna APs can have an expression like “IAP” and external antenna APs “EAP.” The script could use regex matching of these access point names or numbers mapped to corresponding configuration settings. If there are external antenna APs with different gain levels, their names could include “EAP7db” or “EAP8db” to further segment these groups.

Different AP sequence numbers can be used to distinguish groups of access points—for instance, IAPs might have numbers starting with 100, and EAPs with 200, and so on. It all depends on the use case, but the key idea is leveraging the access point name or number as the central key to configuration deployment.

4. Validation

Provisioning sets the stage for validation, ensuring each site meets performance and reliability standards before completion. In addition to basic validation through LED patterns on access points, it is always a good idea to provide installers with insights into the access point status (offline vs online / provisioned vs unprovisioned etc). This can be as simple as providing restricted read access to the access point status page (if you have cloud vendor) or a simple phone call to NOC or a more complicated but effective solution of custom developed UI depending on what fits best. After confirmation on provisioning installers can connect to different SSIDs to ensure the APs are working as expected. Additionally it would be ideal to have a post deployment validation survey done a day or two after the install is completed. Giving this bake time before the survey allows for the network RRM to converge on a more or less final channel and transmit power levels. The validation survey serves few purposes

  1. Ensure the coverage is within the design guidelines/expectations
  2. Identify any installation errors like improper AP/antenna orientation or loose connection between access point and antenna
  3. Provides a snapshot of the environment right after deployment that can be used as reference in future troubleshooting scenarios
  4. Final sign off before the install vendors can move on to the next site

Surveying every site in-house is not realistic at scale. Because of this, it is essential to include post-deployment validation surveys as part of the scope of work for installation vendors. When selecting vendors, ensure they are not only capable of installing access points but also have the skills and tools to perform accurate wireless surveys. This approach maintains quality and consistency across high-volume deployments while freeing internal resources for strategic oversight.

That’s a wrap for the tips on deploying Wi-Fi at scale. In the next post, I’ll focus on managing large-scale networks effectively, including details on data collection and building custom dashboards for real-time insights and operational efficiency.

Reinventing WiFi Design for Scale

Disclaimer

This post assumes readers already understand fundamental Wi-Fi design concepts outlined in the Certified Wireless Design Professional (CWDP) curriculum. It focuses on how those concepts evolve and adapt to large-scale deployments.

Challenges of Design at Scale

WiFi design—the placement of access points—is the foundation for delivering a reliable network experience. To build an effective design, one must understand network requirements, device counts, throughput needs, building materials, and physical and virtual constraints on hardware installation. Site surveys and stakeholder meetings provide important details used in wireless design tools.

These fundamentals remain the same regardless of scale. The primary challenge at large scale is managing hundreds of sites, often spread worldwide, making it impractical to survey every site or meet all stakeholders directly. These sites often include retail stores, distribution centers, and remote offices, each with unique constraints that shape the design.

The key to tackling scale is not to focus on the differences between sites, but to take a counterintuitive approach and find the similarities across them. Any company that has successfully scaled did not do so by treating every building or site as unique. Instead, creating standard templates lies at the heart of business expansions.

While there may be multiple templates, hundreds of sites can ultimately be grouped into just a few categories. These templates might be based on factors such as the size of the location, the nature of the business conducted there, or other criteria specific to the organization. Regardless of the basis, templates always exist.

The first task is to identify how many “types” of sites there are instead of counting “how many” individual sites. After establishing these categories, the next step is to hold stakeholder meetings focused on understanding the key requirements for each site type.

Site surveys should be performed on at least one location of each site type to analyze floor layouts, building materials, areas of high user density, critical business application zones, and other relevant factors. This approach enables the creation of scalable designs that address the needs of multiple sites efficiently.

Cookie cutter designs often receive criticism for being either over-engineered or under-engineered, both of which can result in suboptimal network performance. However, the key to making things work at scale is to build the most efficient cookie cutter designs. The goal should be to develop standardized a.k.a cookie cutter designs that balance efficiency, cost, and performance—designs that can be consistently deployed across many sites without compromising the user experience.

Easier said than done isn’t it?

Creating Optimal Cookie Cutter Wireless Designs That Work

The best approach to creating Wi-Fi designs for large-scale deployments can be attributed to a quote from Abraham Lincoln:
“If I had six hours to chop down a tree, I’d spend the first four sharpening the axe.” You’ll understand why by the end of this blog.

Start by analyzing floor plans and identifying key work streams with unique connectivity requirements. This means assessing user density, client device counts and types, the nature of the applications in use, and identifying the stakeholders who can provide critical information. All of this groundwork should be done before setting foot on-site for a survey walkthrough. Arriving at a site survey well-prepared and informed will make data collection more efficient and focused, allowing for a stronger design.

The workstreams and use cases identified before the survey will often shape the specific tasks requiring attention during the site visit. For example, some areas may have stationary desktops with wireless cards—devices that don’t roam but demand high throughput. Other areas could see constant roaming from handheld devices but have modest throughput requirements. There are countless variations, and recognizing these ahead of time will allow for more targeted data collection.

During the site survey, several tasks are essential:

  • Identify wall locations, types, and attenuation levels.
  • Assess possible AP mounting methods while noting building constraints.
  • Document unique challenges for each workstream, including roaming needs, throughput levels, and required application SLAs.

These fundamentals remain consistent at any scale. Up until this point, designing WiFi for a single site or many follows the same best practices. However, once the survey data is in hand and analysis begins, the approach diverges from traditional “best practices” .

In large-scale projects, a sustainable solution comes from using what can be called “grid patterns” for AP layouts. This means applying standard formulas or guidelines to group similar workstreams and requirements. For instance, in a retail context, merchandise, grocery, and checkout zones may be grouped together, allowing for a repeatable access point grid—such as installing APs in a 50 ft x 50 ft pattern across those areas. Specialized zones, like high racks, might warrant a directional antenna and a custom pattern, but such areas also often follow consistent layouts across multiple sites.

The fewer repeatable patterns used in the design, the more scalable and easily managed the deployment becomes. Is this approach over-engineered? In some ways, yes. But a cost-benefit analysis typically reveals this as an optimal use of resources—streamlining installation, cabling, switch planning, and ensuring the network can flexibly address both current and foreseeable needs.

For example, even if the checkout area requires 100 scanners and the grocery zone currently has no client devices, the same standardized pattern for both zones might introduce some interference and suboptimal cost of deployment but it ensures future coverage if digital displays or new IoT devices are later introduced—saving considerable time and money on redesigns or retrofits in the long run.

Of course, “over-engineering smartly” depends on balancing cost with sound requirement analysis. It isn’t about adding capacity everywhere, but rather sizing for grouped, real-world needs, as informed by thorough stakeholder meetings and up-front planning. This is exactly why the “sharpening the axe” quote makes sense in large-scale WiFi design. Investing time in up-front analysis, requirement gathering, and template planning ensures that the site survey and subsequent design steps are efficient and effective.

Now that the site survey is complete and all necessary information is collected, the next challenge is scaling the solution. My approach breaks this process into three deliberate steps:

1. Proof of Concept (PoC):
Suppose there are 500 sites matching a specific template. The first step is to pick a single site to serve as the proof of concept for the new design. At this stage, an overbuilt, over-engineered wireless network is not just acceptable, but preferable. The PoC environment should offer the flexibility needed to experiment—turning APs on and off, changing configurations, and studying design performance across different scenarios.

At scale, it’s often impossible to control every client device type on the network. At a minimum, focus PoC testing on your controllable devices—especially corporate laptops, handhelds, or specific IoT equipment—to ensure the least/most capable/important devices perform as expected while stationary and roaming. Run intended applications on representative devices in both mobility scenarios and involve stakeholders in real-time testing, so they can confirm that network performance meets their needs throughout the process.

KPIs to monitor during the PoC can include:

  • Channel utilization
  • Client count distribution across APs
  • Connection/roaming success and failure rates
  • RSSI (signal strength) levels for client devices

Depending on the complexity of your network and vertical, this list may be longer—additional KPIs could include measurable application throughput, latency, and packet loss, as well as error rates for specific device types.

The goal of the PoC is to rigorously test and ensure the most optimal cookie cutter design possible for real-world demands, not to save costs or move quickly. Only once all critical applications and devices perform as required, key stakeholders sign off, and metrics consistently meet or exceed defined targets should the project be considered ready to move on to the Pilot phase. This iterative approach allows for fine-tuning grid layouts and coverage, leading to a highly optimized cookie cutter design.

2. Pilot:
With an optimized design in hand, the next phase is pilot deployment across a diverse group of sites—typically five to ten, depending on overall scale. The goal here is to expose any remaining variability between sites, such as unexpected differences in building construction or ceiling heights due to local regulations. By piloting in geographically and structurally varied locations, you can verify whether the template design holds or if adjustments are needed. This phase is critical for identifying edge cases and ensuring repeatability before moving to mass deployment.

During the pilot, ensure that KPI performance at each site aligns with what was observed in the PoC phase, making adjustments as necessary if discrepancies appear. It is essential to catch and address issues at the PoC or pilot stage, as these phases are designed to test your design assumptions under real-world conditions. Sometimes, unexpected problems may challenge your original assumptions—embracing these discoveries early on allows for refinement and prevents costly errors at scale. Failing fast and iterating in the pilot phase leads to a robust, scalable deployment, ensuring efficiency and minimizing surprises during mass rollout.

At this stage, much of the stakeholder conversations are with install teams and vendors who will ultimately be responsible for large-scale deployments. Gather their direct feedback on the pilot process, including what worked well and what obstacles or inefficiencies they encountered. This candid input can reveal practical issues that might otherwise go unnoticed, from hardware compatibility concerns to logistical bottlenecks. Documenting both positives and negatives from these stakeholders ensures that lessons learned are incorporated before General Availability, leading to smoother and more successful future rollouts.

3. General Availability (GA):
After validating the design through PoC and pilot testing, the solution moves to general availability. This is where thorough documentation and runbooks become indispensable. Detailed installation guides should specify part numbers, bracket types, mounting heights, access point orientation, and any other requirements to minimize field errors.

This documentation must include feedback from install teams and vendors collected during pilot deployments. Their insights reveal practical deployment challenges and efficiencies that improve the guides for real-world conditions. Incorporating this feedback reduces mistakes, builds installer confidence, and speeds up deployments, resulting in predictable and successful large-scale rollouts.

Summary

The path to successful large-scale WiFi deployments lies in:

  1. Strategic thinking about scale – Focus on similarities, not differences between sites
  2. Systematic validation – Use the three-phase approach to thoroughly test before broad deployment
  3. Standardization with flexibility – Develop grid patterns that can accommodate reasonable variations
  4. Documentation and process – Create clear runbooks that enable consistent execution

Spend ample time “sharpening the axe”—gather requirements, analyze site types, and test thoroughly with PoC and pilot stages. Only after rigorous testing and validation should you roll out the design broadly, armed with the right tools and knowledge for success.

A good Wi-Fi design is about getting four things right..!!

Becoming a good Wi-Fi design professional requires extensive knowledge in different aspects of networking and also some areas of project management. The 400+ pages of CWDP book from CWNP teaches you exactly that. From requirement gathering & analysis to post implementation validation, the CWDP curriculum is designed to make you a well rounded design professional. But are there nuggets to achieving good Wi-Fi design? In this blog post, I explain why nailing four fundamentals is the key to achieving this.

Choice of Access Points

Selecting the right access point drives the entire design process. This sounds a lot easier than done. So how can we get the first step of the process right. Access points are typically two types, the ones with internal omnidirectional antenna and the others with connections to external antenna. Choosing between the two types needs a thorough requirement analysis. Is the goal to provide coverage or capacity? The main intent of coverage design is to be able provide good signal without taking into consideration of how many clients connect. Coverage design works well for guest only or other networks where the WiFi performance is not critical. Access points with internal omnidirectional antennae are a great fit for this purpose. But WiFi performance is more critical in today’s world than ever. That is where capacity design comes into play. Capacity planning requires an understanding of the number of clients expected to be on the network, the applications that will be used and the throughput SLA requirements per user or device based on these applications. Ideally it should also contain room for growth in number of devices in the future. Capacity planner from Andrew is great resource to determine how many access points are needed to meet the capacity requirements. The type of access point for capacity design really depends on the number of required access points and the layout. High density spaces like auditorium, large conference rooms, lecture halls etc, where the number of client devices is high per square foot, using access points with directional external antennae will be highly beneficial. Office spaces with well spaced desks layout can work with APs with omnidirectional antennae. But as the scale increases (devices, additional floors), use of directional antennae may be required for creating smaller coverage cells. I have a blog post that explains the need for these antennae in modern enterprises. This should help in choosing the correct type of access point for your deployment.

Location of Access Points

Once the required types of access points are determined for the deployment, the next step would be determine the ideal placement of these access points on the floor plan. This can be done in a couple of ways. One design survey method is the AP on a stick method. This process involves placing AP in the actual environment, taking the readings from a site survey software and determining the correct placement for optimal signal. The clear to send blog has very good content on how to perform this type of surveys. It is important to note that this is not a scalable way of determining the AP locations. The second method called predictive design is a scalable solution. This requires use of site survey software like Ekahau Pro or iBWave Wi-Fi to identify the ideal AP placements. Most predictive site survey software comes with default attenuation values for walls and other obstacles in the environment. It is recommended to do a combination of both survey methodologies to make the design more accurate. AP on a stick method can be performed in parts of the environment to determine the attenuation values of different obstacles and input these into the site survey software to improve accuracy in the predictive models. As a rule of thumb, never place APs in the hallways and always try to leverage the walls to reduce cell size especially when omnidirectional antennae are in use. The AP placement should not solely depend on the coverage but also client density for capacity designs. High density spaces will require more number of access points in closer proximity than other areas. Designs that involve placing APs every ‘x’ feet might miss some obstacles that prevent signal penetration. Shotgun implementations like adding APs where people need it can result in over engineering and these are only few of the many reasons why determining ideal AP placements is the second fundamental one needs to get right to achieve required performance.

Channel Planning

With continuous improvements to the proprietary Radio Resource Management (RRM) protocols, many vendors today recommend using auto channel settings in any environment. This may not necessarily result in optimal performance. Coming up with a good channel plan that would reduce adjacent and co-channel interference is an important step in achieving better results. 20 MHz channels are widely recommended in enterprise environment. But each case is unique and needs to be evaluated accordingly. Perhaps, there is an area in the environment with clients performing file transfers frequently and can benefit from 40 MHz channels in the area. The environment might be closer to an airport that results in frequent channel switching when using default RRM settings. Such environments could benefit from disabling some of the DFS channels. 2.4 GHz range is better than 5 GHz considerably. So some 2.4 GHz radio might have to be turned off to reduce interference. Even on 5 GHZ channels, channel 36 will have better range than channel 165 although the difference is not too considerable. Some clients may not have support for all channels. All these factors need to be taken into account in the design phase to be able to deliver more predictable performance. Static channel assignment yields best results but performance when using RRM and device profiles with appropriate settings do not fall far off as well. More than anything, using RRM vs static channel assignment is a question of scalability. In any case, coming up with a channel plan manually or using auto channel assignment options on the predictive survey tools will give better insights into what the actual coverage and channel overlap is going to be post deployment.

Transmit Power Setting

One of the frequently overlooked setting is the transmit power on the access point radios. Using default RRM settings can be quite catastrophic in some cases. Especially when access points are transmitting at high power, the network can face multiple issues in the form of interference, asymmetric uplink/downlink connections, hidden node issues etc. Customizing Tx level in the RRM settings can yield best results without having the need to set static power levels on all access points. The ideal maximum Tx power at which APs transmit should be equal to the transmit power of least capable most important device in the environment and the minimum Tx power should be equal to the power at which all APs can provide required minimum coverage. Predictive site survey tools give you the ability to simulate coverage at different power levels and this will help in determining these values that need to be configured on RRM to make best use of it.

There a ton of other requirements for successful planning, implementation and validation of a good WiFi network but the design is always at the core of it. It is the foundation on which the entire process is built on and getting these four fundamentals right is the key to an optimal design.