9.3 Access Points, Controllers and Client Devices

Objective 3.8 asks you to recognize the boxes and radios in a WLAN, not to design control-plane scaling. Domain 4 covers centralized versus distributed forwarding, tunnels, QoS marking, and vendor extras. Stay here on what each device is for, how you would choose it on a bill of materials, and what breaks at install time if you treat a phone like an AP.

OpenExamPrep treats these as independent engineering facts for CWNA study. Vendor GUI names change; the roles do not.

Access points: autonomous versus lightweight

An access point is an 802.11 STA that also serves as the BSS hub: it beacons an SSID/BSSID, authenticates and associates clients, bridges wireless MSDUs toward the DS, and usually terminates or forwards Ethernet on the wired side. Two management models dominate existing deployments.

Autonomous (standalone, fat, thick) AP. The AP holds its own SSID list, security settings, RF channel/power, and often local switching. You log into that AP (HTTPS, SSH, or a small GUI) or push config with a script. Autonomous APs still exist in branches, labs, and small offices. Scaling pain is real: 50 autonomous APs means 50 config files, 50 firmware plans, and no built-in RF coordination unless you add a manager.

Lightweight (thin) AP. The radio hardware is still an AP, but coordinated configuration, RF policy, and often roaming/security context live on a WLAN controller or a cloud controller that plays the same role. Historically this used LWAPP then CAPWAP; other vendors use proprietary or cloud APIs. For CWNA device awareness: the lightweight AP cannot be treated as a complete standalone BSS manager. If it cannot reach its controller (or cloud) and has no local-mode fallback you enabled, it may fail to serve SSIDs, fail to update policy, or operate in a degraded image. Exact failover behavior is a Domain 4 architecture topic — here, know the dependency.

Do not memorize one vendor’s “local mode versus flex mode” table in this section. Those forwarding choices are Domain 4. Device selection question: do you need a box that survives without a controller, or a fleet that must share RF and policy?

Physical install awareness still matters for both models: PoE class versus AP draw (Domain 4 budget math), antenna ports matched to the SKU (internal vs external), ceiling orientation, and whether the SKU is indoor, outdoor, or industrial enclosure.

WLAN controllers

A WLAN controller (WLC) is the central appliance or VM that lightweight APs join. At a device level it provides:

• Inventory and image — which APs are joined, which AP image they run.
• RF coordination hooks — channel/power algorithms initiated from the controller (the algorithm details are later).
• Shared WLAN policy — SSIDs, security profiles, AAA pointers.
• Roam/security context so a STA moving AP-to-AP inside the same mobility group does not look like a brand-new unknown (again, depth in security and architecture domains).

A controller is not a replacement for an Ethernet access switch, a DHCP server, or a firewall. It is a WLAN control and (in some designs) data concentrator. If a question says “which device assigns channels to 200 thin APs and pushes one SSID profile,” the controller (or cloud controller) is the answer. If the question says “which device provides 30 W at the Ethernet jack,” that is a PSE/switch, not the WLC.

Controllers come as hardware appliances, virtual machines, and embedded controllers on a switch or on a “controller AP.” The exam cares that the function exists, not that you recite a SKU.

Wireless network management systems (WNMS)

A WNMS is the management plane product that watches and configures many WLAN devices over time. It may sit above controllers (legacy: NMS talking to several WLCs) or it may be the cloud dashboard that also acts as controller. Jobs you should be able to name:

• Monitoring — AP up/down, client counts, alarms, some RF health.
• Configuration at scale — templates, firmware trains, certificate/PKI hygiene.
• Planning / inventory — floor plans, AP placement records, sometimes survey import.
• Reporting and audit — who changed which SSID, compliance exports.

WNMS is easy to confuse with a controller. Shortcut: controllers (or cloud-controller functions) are what APs join to become a coordinated WLAN; WNMS is how humans and automation operate that fleet day to day. A small autonomous network might have WNMS and no WLC. A large campus might have both. Neither is a protocol analyzer and neither is a spectrum analyzer — those are validation tools in Domain 6.

Wireless bridges and mesh APs

Wireless bridge. Two (point-to-point) or more (point-to-multipoint) 802.11 devices connect network segments, not a pile of user laptops. Root/non-root, workgroup bridge, and outdoor bridge SKUs appear in vendor catalogs. Install awareness:

• You need RF LOS / Fresnel discipline from Domain 1, not just “both ends see an SSID.”
• Throughput is shared on the channel; a bridge carrying a 1 Gbps Ethernet hope on a 40 MHz 5 GHz link will not deliver 1 Gbps application throughput.
• Security and spanning-tree/loop behavior on the wired sides are part of a sane install; CWNA expects you to know the device role, not to design STP.

Mesh AP. A mesh node uses 802.11 (vendor mesh or 802.11s-style) as backhaul to a root / portal AP that has Ethernet to the DS. Dual-radio mesh can dedicate 5 GHz to backhaul and 2.4 GHz to clients; single-radio mesh splits airtime between backhaul and access — a common install mistake when someone hangs a cheap single-radio mesh unit and expects indoor-AP client capacity.

Mesh selection checklist: hop count, root placement on real Ethernet, whether weatherized hardware is required, and whether client SSIDs should even be enabled on backhaul radios. Mesh is not “a controller in the ceiling.” Mesh is an AP role with a wireless uplink.

Client devices: STA radios, adapters, and Tx power

Everything that associates is a station (STA) with a radio subsystem: phone, laptop, tablet, scanner, printer, badge tap, IoT sensor, USB stick, or a mini-PCIe/M.2 module soldered to a motherboard. The adapter (NIC) determines:

• Bands and PHYs — 2.4-only IoT versus tri-band HE laptop.
• Antenna count / MIMO — 1×1 USB dongle versus 2×2 or 3×3 laptop.
• WMM, 11k/v/r, PMF support — roam and power-save features from 9.2 only work if the client implements them.
• Transmit power and EIRP — the number that surprises installers.

APs are designed as infrastructure radios: better antennas, higher conducted power within the regulatory limit, often 2–4 chains. A phone may sit at roughly 10–16 dBm conducted with a tiny antenna buried next to a battery. A laptop card might be 13–17 dBm. An indoor AP might use 15–20+ dBm plus antenna gain. Exact values vary by SKU and region; the pattern is what CWNA tests: do not assume a symmetric link. Surveying downlink RSSI from the AP to a professional adapter can look excellent while a low-power scanner fails uplink ACKs — hidden as “coverage holes” that are really client Tx limits.

Install awareness, not architecture

When you specify devices:

• Match AP SKU to environment (ceiling omni vs hallway directional vs outdoor mesh root).
• Budget PoE and switch ports separately (Domain 4 will quantify).
• Confirm client population — if 80% are phones, design for their Tx power and roam, not for your laptop survey NIC.
• Use WNMS to keep firmware and RF templates consistent; do not confuse it with a packet capture tool.
• Use bridges/mesh only when Ethernet or fiber cannot land; they consume spectrum that indoor APs would rather give to clients.

On the exam

• Autonomous = config on AP; lightweight = AP joins controller/cloud.
• WLC coordinates joined APs; it is not the PoE switch.
• WNMS operates and monitors the fleet.
• Bridge extends a segment; mesh backhauls an AP over wireless.
• Clients differ in adapters and Tx power; uplink-limited links are normal.

Key Takeaways

• Pick AP management model (standalone vs controller-joined) before you hang hardware.
• Controllers and WNMS solve different questions — join/policy versus operate/monitor.
• Bridge and mesh are RF uplinks, not magic extra Ethernet.
• Always size the design to the weakest STA radio, not to the AP datasheet.