Learning Objectives

• Differentiate between autonomous AP and controller-based WLAN architectures
• Understand the split-MAC model and which functions run on the AP vs controller
• Recognize the trade-offs between cloud-managed and on-premises controller deployments

Two Architectures

Wi-Fi networks can be built using two fundamentally different architectures:

Autonomous APs — Each AP operates independently. It handles all functions locally: beaconing, client authentication, encryption, bridging, and management. Configuration is applied per-AP via CLI, web interface, or SNMP. Autonomous APs are common in small offices, home networks, and low-density deployments.

Controller-based APs (Lightweight APs) — The APs are "thin" — they handle only real-time 802.11 frame processing (beaconing, probe responses, encryption, and forwarding). All management, configuration, and decision-making happens on a central controller or in the cloud. The AP discovers the controller via DHCP, DNS, or CAPWAP discovery, downloads its configuration, and stays connected through a control tunnel.

The Split-MAC Model

In a controller-based architecture, 802.11 functions are split between the AP and the controller:

The AP retains real-time MAC functions — beaconing, frame encryption, ACK generation, and channel scanning — because these require microsecond-level timing that cannot tolerate controller round-trips. The controller handles management and coordination — authentication, association, roaming decisions, and configuration — where latency of tens or hundreds of milliseconds is acceptable.

Control and Data Tunneling

Lightweight APs communicate with the controller using CAPWAP (Control and Provisioning of Wireless Access Points), defined in RFC 5415. CAPWAP creates two tunnels:

• Control tunnel (UDP 5246, DTLS-encrypted) — Carries configuration, management, and statistics between the controller and AP
• Data tunnel (UDP 5247, optional DTLS encryption) — Carries client data traffic between the AP and controller

The data tunnel can operate in two modes:

• Local (or bridge) mode — Traffic is bridged directly onto the local wired network at the AP; the data tunnel carries only management traffic
• Central (or tunnel) mode — All client traffic is encapsulated and sent to the controller, which forwards it onto the wired network. This is useful for guest traffic, compliance, and centralized firewall enforcement

Cloud vs On-Premises

| Aspect | On-Premises Controller | Cloud-Managed | |--------|----------------------|---------------| | Location | Physical appliance or VM in data center | SaaS controller (Meraki, Aruba Central, Mist) | | Management | Single pane, local UI, direct API | Web dashboard, mobile app, cloud API | | CAPWAP tunnel | AP → controller over LAN/WAN | AP → cloud via internet (DTLS tunnel) | | Latency dependency | Low (AP and controller on same LAN) | Medium (AP must have internet access) | | Resiliency | Controller redundancy (N+1, N+N) | Cloud provider SLA, local survivability mode | | Licensing | Perpetual + support contract | Subscription (per-AP per-month) |

Cloud-managed Wi-Fi has become dominant for new deployments, especially in distributed environments like retail, education, and hospitality. The trade-off is dependency on internet connectivity — if the cloud is unreachable, cloud-managed APs typically enter a survivability mode using cached configuration.

Key Takeaways

• Autonomous APs handle all functions locally; lightweight APs split work with a controller
• The split-MAC model assigns real-time functions to the AP and management functions to the controller
• CAPWAP tunnels carry control and data traffic between APs and controllers
• Cloud-managed Wi-Fi offloads the controller to a SaaS platform but depends on internet connectivity
• Local (bridge) mode forwards traffic at the AP; central (tunnel) mode sends all traffic through the controller