Network Engineering FAQ
Direct answers from Ekahau ECSE certified survey engineers and the multi-CCIE bench — survey methodology, pricing, deliverables, vendor coverage, and dispatch, on fixed-fee SOW terms.
WiFi Hotshots is a vendor-agnostic enterprise network engineering firm serving enterprise customers, enterprise architects, infrastructure buyers, and network engineering teams across Southern California and the broader US market. These frequently asked questions cover the design, procurement, and delivery decisions buyers face across ten enterprise networking disciplines.
Ekahau ECSE — Certified Survey Engineer on every engagement
Multi-CCIE engineering bench
Fixed-fee SOW — no T&M surprises
25 years of enterprise networking leadership
This is the central network engineering FAQ for WiFi Hotshots — the engineer-written answers we send to IT directors, network architects, and procurement teams when they ask the same question twice. If you are scoping an Ekahau wireless site survey, comparing predictive versus AP-on-a-Stick methodology, deciding between Cisco Catalyst 9800 and Juniper Mist for a refresh, or simply trying to get past hourly-billing vendor quotes, the answers below are the same ones we would give you on a scope call.
For a full picture of the practice, start at the enterprise wireless services hub or review our engineering credentials and certifications. When you’re ready to scope a specific project, send the floor plans — we return a written fixed-fee SOW within three business days of the scoping call.
Ekahau Site Survey Methodology
Every WFHS wireless engagement runs on the Ekahau Connect platform — predictive design in Ekahau AI Pro, field measurement with Ekahau Sidekick 2. The following questions cover the engineering mechanics behind that workflow: what each survey type actually measures, which version of Ekahau we’re running, what the Sidekick 2 does differently than the original, how we approach 6 GHz channel selection, and what roaming thresholds we design to for voice-grade networks.
What’s the difference between predictive and AP-on-a-Stick surveys?
A predictive survey uses Ekahau AI Pro to model RF propagation through a calibrated floor plan. No physical measurement occurs — the software simulates signal paths through assigned wall materials and produces coverage heatmaps and an AP placement plan against a design target (‑67 dBm RSSI for data, ‑65 dBm for voice-grade).
It is fast and accurate for standard drywall-and-stud construction.
An AP-on-a-Stick (APoS) survey mounts a production-model AP on a telescopic pole at the intended deployment height — 12–18 ft for ceiling tile, 25–40 ft for high-bay warehouse or arena — and the Ekahau Sidekick 2 captures real RSSI, SNR, and noise floor measurements as the surveyor walks the floor.
Most WFHS engagements use both: predictive for initial design and AP count, APoS for validation in buildings with atypical attenuation (seismic shear walls, lead-lined imaging suites, dense steel racking, CMU block, or where as-built drawings are known to be unreliable).
How does Ekahau AI Pro differ from its predecessor?
Ekahau AI Pro is the current design and analysis module within the Ekahau Connect platform — it replaces the legacy Ekahau Site Survey product lineage. The AI Pro workflow adds automated AP placement recommendations against a design profile (coverage, capacity, roaming), automated floor-plan scaling from reference distances, and faster ray-trace computation on large multi-floor projects.
The underlying methodology — floor plan calibration, wall-material attenuation assignment, passive survey import, hybrid predictive-plus-measured models — is identical.
If you have an older Ekahau project file (.esx) from a prior engineer, AI Pro opens it directly; we routinely take a client’s five-year-old Ekahau file, recalibrate wall materials against a current scan, and re-run the model without starting from scratch.
Do you use the Ekahau Sidekick 2 for every engagement?
Yes, for every engagement that includes on-site measurement. The Ekahau Sidekick 2 attaches to the survey laptop by USB-C and runs a multi-radio scanner across 2.4, 5, and 6 GHz simultaneously with an integrated spectrum analyzer, GPS,
and battery pack — covering the full 2,400–7,125 MHz range. The original Sidekick was 2.4/5 GHz only; the Sidekick 2 is what makes Wi-Fi 6E and Wi-Fi 7 validation possible in a single walk.
Predictive-only engagements (where the client explicitly opts out of field validation, accepting the predictive model as the final deliverable) do not require the Sidekick because no measurement is taken.
We strongly recommend against predictive-only on anything other than a greenfield tenant build-out with reliable drawings and standard construction.
How do you handle 6 GHz, Wi-Fi 6E, and Wi-Fi 7 designs?
6 GHz design centers on three choices: power class, channel width, and AFC coordination. Indoor enterprise APs default to LPI (Low Power Indoor, max 5 dBm/MHz PSD) with no external antennas and no battery-powered APs per FCC Part 15 Subpart E. Standard Power (up to 36 dBm EIRP) requires AFC coordination against the FCC incumbent database and is allowed in UNII-5 and UNII-7 only.
The US 6 GHz band offers 59 non-overlapping 20 MHz channels, 29 × 40 MHz, 14 × 80 MHz, 7 × 160 MHz, and 3 × 320 MHz (Wi-Fi 7, non-overlapping).
For Wi-Fi 7, MLO (Multi-Link Operation) lets a client associate on 5 and 6 GHz simultaneously — the near-term value is redundancy and faster roaming, not aggregate-throughput multiplication. 4K-QAM and 320 MHz channels deliver measurable gains only within close range at SNR ≥ 38–40 dB, which is rarely achieved in enterprise.
We design to realistic client behavior, not to marketing peak rates.
What roaming and voice-grade targets do you design to?
For data networks: ‑67 dBm primary coverage RSSI at cell edge, 25 dB SNR minimum (30 dB preferred for sustained high MCS), 15–20% cell overlap at the ‑67 dBm contour, and co-channel APs at least 19 dB weaker than the serving AP.
For voice-grade networks (Spectralink Versity, Vocera Smartbadge, Ascom Myco, Zebra TC-series push-to-talk): ‑65 dBm throughout — including elevators, stairwells, bathrooms — with 25 dB SNR absolute minimum, 20–25% cell overlap, packet error rate under 1%, and jitter under 30 ms.
Roaming target is under 50 ms total handoff time, which requires 802.11r fast BSS transition enabled on the voice SSID; a full 802.1X roam without FT or OKC is 200–800 ms and breaks voice.
We validate these with active iPerf3 throughput tests and a roaming test client against a MOS trace across the walking route.
Pricing, Scope, and Engagement Model
Every WFHS engagement is quoted as a fixed-fee SOW — no hourly billing, no open-ended estimates, no change orders without written client sign-off. The next five questions cover the economics of that model: what drives cost, why we refuse to bill T&M, what happens when the survey surfaces something outside original scope, and how we coexist with your existing VAR or hardware channel.
What does a wireless site survey cost?
Every engagement is priced as a fixed-fee SOW. Scope variables that drive cost: total square footage, number of floors, number of buildings, construction type (standard drywall-and-stud versus poured concrete, CMU block, lead-lined imaging suites, seismic shear wall retrofits, or high-bay warehouse racking), required survey type (predictive only, AP-on-a-Stick validation, or combined predictive-plus-validation), off-hours or maintenance-window requirements, and whether a formal post-install validation report is in scope.
We return a written SOW quote within three business days of the scoping call of receiving floor plans and a scope description.
Send floor plans to sales@wifihotshots.com or call (844) 946-8746. No engagement begins without the client signing off on the fixed-fee price first.
Why fixed-fee SOW instead of hourly?
Hourly billing puts the risk on the client — the longer the vendor spends, the more the client pays, which aligns vendor incentives with the wrong outcome. Fixed-fee SOW puts the risk on us. If the survey takes longer than we scoped, that is our problem, not the client’s line item. It also means the procurement conversation is about scope and deliverables, not about unit rates per engineer grade.
Our SOWs enumerate the exact deliverable set (Ekahau project file, per-band heatmap exports, BOM, installation runbook, post-install validation report), the exact walkable area, and the exact number of measurement waypoints — so the client and WFHS agree on completion criteria before a single pole is assembled.
That’s the operational definition of a fixed-fee engagement, and it is non-negotiable on our side.
What if the survey uncovers issues outside the original scope?
The fixed-fee SOW covers the defined scope. If the survey uncovers something outside that scope — an ERRCS public-safety coverage gap requiring a licensed BDA integrator, a structured cabling deficiency that has to be remediated before APs can be installed, a DAS antenna placement conflict, or a switch PoE capacity shortfall — we document the finding in the validation report with the specific location, the nature of the issue, and the engineering path forward.
We then issue a separate change-order estimate for any additional WFHS scope.
Where the finding is outside wireless engineering (ERRCS installation, electrical work, structural penetrations), we refer to the appropriate licensed contractor.
The client is never billed above the SOW total without a signed change order in advance.
Do you resell hardware or only design?
WFHS is a vendor-agnostic engineering services firm. We design, survey, validate, and migrate — we do not carry Cisco, Aruba, Juniper Mist, Ruckus, or Extreme SKU inventory on our books, and we do not mark up hardware.
Every bill of materials we produce is itemized down to AP model, mount type, antenna selection, PoE class, and cable length per drop, so the client can procure through any VAR or direct-partner channel that suits their purchasing agreements.
This matters structurally: when your engineer and your hardware reseller are the same company, there is a financial incentive to recommend whichever platform carries the best margin this quarter.
Separating the two removes that incentive.
Clients sometimes move to a WFHS-recommended platform that their incumbent VAR does not carry; that is a procurement problem, not an engineering one.
Can we use our existing VAR for procurement?
Yes, and most clients do. We routinely deliver the final BOM in a format compatible with Cisco Partner CCW, Aruba Marketplace, Juniper Partner Advantage, Ruckus OneCloud, or Extreme partner portals so your existing VAR can quote directly from it. If your VAR requires an MSRP cross-reference or SmartNet/support-contract line items layered in, we include those.
The engineering deliverable (design, heat maps, validation report, project file) is independent of the procurement channel — you can quote the same BOM to three VARs in parallel and pick the one with the best terms.
WFHS does not collect a referral fee from any VAR, so we have no preference about who sells you the hardware.
The one exception: if your VAR is also promising to do the design work themselves, it is worth reading that proposal carefully — a VAR-led design is typically keyed to the SKUs the VAR carries.
Floor plans, device counts, and a scope description are all we need to quote — most engagements are returned as a written fixed-fee SOW within three business days of the scoping call.
Deliverables, Documentation, and Design Warranty
The document set a client receives at the close of an engagement is where fixed-fee SOW either holds up or falls apart. The questions below cover exactly what lands in your hands on the last day: which files, in which formats, at what granularity, and whether the design stands behind the validation measurements. Short answer up front: yes, you get the raw Ekahau project file, and yes, there is a design warranty.
What documents do we receive at engagement close?
Every engagement ships with: the Ekahau project file (.esx) for future re-use or re-validation; annotated heatmap exports per frequency band (2.4, 5, 6 GHz) per floor, showing RSSI, SNR, secondary coverage (802.11k neighbor list), and co-channel interference overlay;
a vendor-agnostic AP bill of materials with AP model, mount type, antenna selection, PoE class requirement, and cabling length per drop; an installation runbook for the contractor (AP placement drawing in AutoCAD or PDF overlay, cable pathway map, switch port assignment, VLAN/SSID configuration notes); and a post-install validation report with passive heatmap confirmation, iPerf3 throughput results, 802.11r handoff timing, and MOS trace data for voice-grade engagements.
The deliverable set is identical regardless of AP vendor.
The documentation is formatted for a 10-year shelf life — the next engineer who opens it does not need to be briefed.
Do we get the raw Ekahau project file?
Yes. Every engagement ships with the Ekahau .esx project file in the final deliverable package. This includes the calibrated floor plans, wall-material attenuation assignments, AP placement coordinates, passive survey measurements, and all heatmap layers. The client owns the file.
If you engage a different engineering firm three years from now, they open the .esx directly in Ekahau AI Pro and pick up where we left off — no re-surveying from zero, no retracing our methodology, no vendor lock-in on the project data.
Several competitor firms hand over PDF reports only and retain the project file.
That is not our model. The documentation belongs to the client; we keep a backup copy for support purposes only.
What’s in a post-install validation report?
The post-install validation report documents the installed network against the as-designed target. It contains: passive heatmaps per band per floor confirming ‑67 dBm primary coverage and 25 dB SNR at cell edge; active iPerf3 bidirectional throughput measurements per floor or per major zone;
802.11r fast BSS transition handoff timing captured by a roaming test client (target under 50 ms); MOS (Mean Opinion Score) trace data for voice-grade engagements along the full walking route; a gap register listing any area below target RSSI, SNR, or roaming threshold, with the specific AP or configuration change recommended for remediation; and a channel plan audit confirming no co-channel interference above the threshold.
The report is formatted so a health-system IT governance committee, a district audit team, or a future engineer can pick it up without context and know exactly what the network does today.
Is there a design warranty?
Yes. WFHS stands behind the AP count, AP placement, channel plan, and configuration recommendations in every design we produce. If post-install validation reveals a coverage gap at an installed AP that was not predicted by our design (i.e., the predictive model or the APoS validation missed it), we remediate the design at no additional cost — that can mean a revised AP placement, an added AP, or a channel/power change.
The warranty applies to design and placement, not to construction changes made after the survey (post-design tenant build-out, walls added, ceiling materials swapped, furniture reconfiguration) or to hardware defects, which are covered by the vendor’s manufacturer warranty.
If construction changes the environment after design, we revalidate as a separate engagement, not as a warranty event.
Vendors and Platforms We Work Across
Vendor-agnostic is a claim a lot of firms make. For WFHS it means something specific: the same deliverable set, the same survey methodology, and the same engineering bench across Cisco Catalyst 9800, Meraki MR, Aruba Central and ArubaOS 10, Juniper Mist, Ruckus SmartZone / RUCKUS One, and Extreme ExtremeCloud IQ. We do not resell any of them, and we have no volume commitments with any of them. The next four questions cover platform coverage, bias, per-vendor capability, and legacy-controller migration.
What controllers and platforms do you support?
The full enterprise vendor matrix: Cisco Catalyst 9800 (on-prem and cloud) running IOS-XE 17.12.x / 17.15.x; Cisco Meraki MR (cloud-managed only); Aruba Central (cloud-managed) and on-prem 9240 / 9240XM gateways for compliance-constrained deployments; Juniper Mist (cloud-only,
with Marvis AI and the SLE framework covering Time-to-Connect, Throughput, Coverage, Capacity, Roaming, Successful Connects); Ruckus SmartZone (vSZ, SZ100, SZ300) and the newer RUCKUS One cloud platform; Extreme ExtremeCloud IQ with Universal Hardware persona selection.
We also cover Cisco WLC 9800 HA-SSO pairing, Aruba Instant AP (IAP) controllerless clusters for small deployments, and Flex-mode versus Local-mode design decisions for Catalyst 9800 branches.
If your platform is not on that list, ask — we have likely seen it at a prior engagement.
Are you biased toward a particular vendor?
No. We earn no referral fee, margin kickback, or rebate from any AP vendor. Every design is driven by client constraints: existing controller estate, licensing structure, client device mix (if the fleet is heavily 2.4 GHz legacy, that narrows the design space), compliance posture (cloud-management tolerance, HIPAA, PCI DSS 4.0, gaming regulatory separation),
and operational preferences (in-house expertise on a specific platform is worth more than a marginally better technical match on one the team does not know).
We will tell a client the honest answer: Juniper Mist is the best AIOps experience today, Cisco Catalyst 9800 is the best choice for a pure on-prem requirement, Aruba Central strikes a reasonable middle ground.
Those are engineering opinions, not a sales pitch.
Do you work with Cisco Catalyst 9800, Meraki, Aruba, Juniper Mist, RUCKUS, and Extreme?
Yes, all six, across design, survey, migration, and post-install validation. Cisco Catalyst 9800 engagements frequently include HA-SSO configuration and Advantage-tier licensing decisions (AVC, application policy, DNA Center/Catalyst Center integration). Meraki engagements address Co-termination versus Per-Device Licensing (PDL) migration, which is a one-way decision. Aruba Central engagements cover Foundation versus Advanced subscription tiers (Advanced includes AIOps and UXI integration).
Juniper Mist engagements use the Marvis assistant for post-install SLE monitoring.
Ruckus engagements address the SmartZone to RUCKUS One migration path and ChannelFly versus static channel planning. Extreme engagements cover Universal Hardware persona selection and CoPilot AIOps add-ons. The survey methodology is platform-independent; the configuration and deployment work is not.
What if we’re on a legacy controller — can you migrate?
Yes. Common migration paths: Cisco AireOS WLC (5508, 8540, 3504) to Catalyst 9800; Aruba Mobility Conductor (formerly Mobility Master) / Controller (AOS 8) to ArubaOS 10 on Aruba Central or on-prem 9240; Ruckus ZoneDirector or legacy SmartZone to RUCKUS One.
Migration scope covers: configuration export and translation, SSID policy re-mapping (role-based access, PPSK, 802.1X with cert-based auth), roaming settings (802.11k/v/r) normalized across the new platform, AP join sequencing to avoid mass outage, and controller-version staging for phased cutover.
Where the existing AP hardware is not compatible with the target platform (for example, older Cisco 1600/2600/3600 APs cannot join a Catalyst 9800), the migration is combined with an AP refresh in the same SOW.
We also handle controller-version-only upgrades (AireOS 8.5 to 8.10) where the hardware stays but the code base moves.
Service Area and Dispatch
WFHS dispatches from Valencia (Santa Clarita Valley) across Southern California without mileage charges and across the United States for multi-site national rollouts. Because dispatch cadence and site-specific RF constraints (desert heat, marine-layer corrosion, DFS-heavy coastal zones, airport-proximity spectrum congestion) vary by geography, the questions below address primary service area, out-of-region engagements, dispatch timing, and airport / DFS-specific survey conditions.
What’s your primary service area?
Southern California, dispatched from Valencia in the Santa Clarita Valley. No mileage charge within Los Angeles, Orange, Ventura, Riverside, San Bernardino, San Diego, or Kern counties. That includes the Los Angeles metro, Santa Clarita Valley, San Fernando Valley, Antelope Valley, Inland Empire, Orange County, San Diego, Palm Desert, and Bakersfield. Engagements across multiple regions are coordinated from a single SOW and single point of contact — not repriced per region.
Do you work outside Southern California?
Yes — national rollout is a core WFHS capability. We have executed multi-site engagements spanning 1,000+ retail locations across the continental United States, distribution center programs across regional DC hubs, and multi-campus wireless design across academic medical centers and public university systems. Out-of-region engagements include travel time and expenses built into the fixed-fee SOW (not billed separately and not marked up).
For nationwide store rollouts or DC programs, we coordinate a single engineering lead across all sites so the design methodology, channel plan, SSID architecture, and deliverable format are identical from site one to site 1,000.
Reference clients are discussed by vertical and scale (national discount retail chain, national pet retail chain, top-tier academic medical center), not by name.
How fast can you dispatch?
For Southern California, typical lead time from signed SOW to on-site mobilization is 5–10 business days depending on scope size and off-hours window requirements. Emergency and disaster-recovery engagements — temporary wireless for a production outage, a lost MDF after a fire event, or event/disaster connectivity — can dispatch within 24–72 hours when the situation warrants; those are handled under a separate emergency-connectivity SOW template with a rapid-mobilization rate.
Nationwide out-of-region dispatch is 7–14 business days for normal scope and 48–96 hours for emergency.
We do not stage gear in every major metro; emergency response calls assume air freight of Sidekick 2 kits and pole hardware as part of the mobilization.
What about DFS and airport-proximity survey work?
DFS (Dynamic Frequency Selection) and airport-proximity engagements need careful channel planning. UNII-2A (channels 52–64) and UNII-2C (100–144) are DFS bands requiring a 60-second Channel Availability Check before first use and a 30-minute Non-Occupancy Period after any radar detection. Near airports, Terminal Doppler Weather Radar (TDWR) on channels 120, 124, 128 triggers frequent radar events — we typically design away from TDWR-adjacent DFS channels or plan for automatic backup-channel failover.
Some client fleets (older IoT devices, legacy scanners, certain VoIP handsets) omit DFS channels from their scan list entirely; if the fleet mandates, we design to UNII-1 and UNII-3 only (9 non-DFS 20 MHz channels plus 5 GHz UNII-3) and accept the reduced channel count.
For Los Angeles, Ontario, John Wayne, Long Beach, and San Diego airport-adjacent engagements, we survey with a TDWR-aware channel plan and validate post-install against radar-induced failover events.
Still Have a Question? Scope a Call.
Email sales@wifihotshots.com or call (844) 946-8746 — we return written fixed-fee SOW responses, not multi-week proposal cycles.
WiFi Hotshots is a minority-owned, engineer-led network services firm with 25 years of enterprise networking leadership. The practice runs on Ekahau Connect with Ekahau ECSE certified survey engineers and a multi-CCIE bench — every engagement a fixed-fee SOW, vendor-agnostic across Cisco Catalyst 9800, Meraki, Aruba, Juniper Mist, RUCKUS, and Extreme, and documented to a standard your operations team can reference for the life of the infrastructure.
Whether you’re scoping an Ekahau wireless site survey across a single building, a multi-campus healthcare refresh, a 1,000+ store nationwide rollout, or a Wi-Fi 7 greenfield design for a new-build headquarters, the methodology and deliverable set are identical: measure first, design to data, validate before the invoice closes.
WiFi Hotshots FAQ — Further Reading
The questions on this page are the cross-discipline essentials that buyers raise before they have settled on a service line. Each link below describes what readers go on to ask after this FAQ hub once the project takes shape — the discipline-specific design decisions, the standards each architecture is sized to, and the deliverable schema each engagement closes against — not the destination service line in the abstract.
- Enterprise wireless engineering — the discipline behind every survey, methodology, vendor-coverage, and dispatch question on this FAQ: predictive design in Ekahau AI Pro and field measurement with Ekahau Sidekick 2 against the −67 dBm primary / −65 dBm voice RSSI targets, 25 dB SNR thresholds, sub-50 ms roaming via IEEE 802.11r Fast BSS Transition, and Wi-Fi 7 MLO design per Wi-Fi Alliance CERTIFIED 7; the next layer of detail readers ask after the methodology and pricing answers.
- Campus LAN refresh — the wired access fabric every AP terminates on, where readers go after the controller-and-platform questions: IEEE 802.3bt Type 4 (90 W) PoE delivery per IEEE 802.3bt-2018, multigig 2.5/5/10GBASE-T per IEEE 802.3bz, MACsec link-layer encryption per IEEE 802.1AE-2018, and EVPN-VXLAN core uplinks per IETF RFC 8365 — the fabric the access edge questions on this FAQ ultimately resolve into.
- Data center fabric design — the spine-leaf core readers ask about after the deliverables and design-warranty questions: EVPN-VXLAN overlay per IETF RFC 7348, RFC 7432, and RFC 8365, RoCEv2 lossless transport per IBTA RoCEv2 Annex A17, microsegmentation policy planes (Cisco ACI ESG, NSX-T DFW, Arista MSS-Group), and Base-16 MPO-16 trunk infrastructure per ANSI/TIA-568.3-E for 400G / 800G optics — the layer of design questions that follow once a project moves past the WLAN edge.
- SD-WAN fabric design and migration — the WAN edge readers ask about when the FAQ vendor-coverage answers move into multi-site rollout territory: per-app SLA-class probing for jitter and packet-loss thresholds, IPsec / IKEv2 underlay tunnels per IETF RFC 7296, BFD timer convergence on dual-carrier transport, application-aware path selection on SIP signaling vs RTP media, and SASE PoP handoff for inline DLP / CASB / ZTNA inspection rather than backhauling to a regional firewall stack.
- Network security architecture — the policy fabric readers ask about after the segmentation and compliance-posture questions on this FAQ: 802.1X EAP-TLS supplicant authentication per IETF RFC 5216, MACsec link encryption per IEEE 802.1AE-2018, WPA3-Enterprise SAE handshake per Wi-Fi Alliance WPA3, NIST SP 800-207 zero-trust architecture verification per NIST SP 800-207, and the vendor matrix (Cisco ISE, Aruba ClearPass, Forescout, Mist Access Assurance, Palo Alto, Fortinet, Zscaler, Netskope) the post-authentication enforcement decision rides on.
- Unified communications migrations — the voice and video architecture readers reach when the FAQ roaming-budget and 802.11r answers move into Wi-Fi calling, MTR-certified room systems, and contact-center cutover scope: SIP-TLS signaling per IETF RFC 5630, SRTP media encryption per IETF RFC 3711, STIR/SHAKEN inbound-attestation per IETF RFC 8224 and RFC 8226, MOS preservation per ITU-T G.107 E-model, and one-way latency budgets per ITU-T G.114.
- Structured cabling — the physical-layer plant readers ask about once the FAQ deliverables and per-port AP placement answers turn into a real horizontal-and-fiber BOM: Cat 6A channel certification per ANSI/TIA-568.2-E, bundled-cable thermal de-rating per ANSI/TIA TSB-184-A for dense AP-and-camera bundles, MPO trunk infrastructure per ANSI/TIA-568.3-E, administration and labeling per ANSI/TIA-606-D, and BICSI 002-2024 data-center infrastructure design.
- AI-ready infrastructure — the GPU and inference fabric readers ask about when the FAQ Wi-Fi 7 MLO and 802.3bt PoE answers turn into the next-generation cluster scope: RoCEv2 lossless transport per IBTA RoCEv2 Annex A17, NVIDIA Spectrum-X and Arista Etherlink AI fabrics, OS2 single-mode fiber for 400GBASE-FR4 / 800GBASE-FR4 trunks, Ultra Ethernet Consortium 1.0 readiness on Tomahawk 5 silicon, PFC and ECN policy on the leaf, and the campus-DCI-uplink bandwidth that determines whether AI inference reaches user-facing endpoints without saturating the campus core.
WiFi Hotshots Engineering References
Technical claims on this page are cited against the following primary sources. RF coverage targets (‑67 dBm primary, ‑65 dBm voice, 25 dB SNR) are consistent with Cisco Meraki Site Survey Guidance, Aruba Campus VRD, and Cisco Catalyst 9800 configuration guidance. 802.11r fast BSS transition and sub-50 ms voice-grade roaming behavior per IEEE 802.11r standard and the Cisco 802.11k/v/r configuration reference.
Ekahau Sidekick 2 specifications per Ekahau Sidekick 2 product page. Ekahau AI Pro workflow per Ekahau AI Pro product page. 6 GHz power class definitions (LPI, VLP, Standard Power, AFC) per FCC Part 15 Subpart E, FCC 6 GHz unlicensed opening, and FCC Standard Power 6 GHz authorization. Wi-Fi 7 certification and MLO per Wi-Fi Alliance CERTIFIED 7. CWNP design methodology per CWNP CWDP certification.