14 Wi-Fi Network Topologies

14.2.1 Beginner Architecture Pieces

14.2.6 Infrastructure Mode Is The Default, Not The Only Mode

Every card above describes infrastructure mode: stations normally exchange traffic through an access point, which manages association and access to the distribution system. Wi-Fi also defines an ad-hoc mode (an Independent BSS, or IBSS), where there is no access point. Stations communicate directly when in range and still use distributed channel-access rules to share the medium.

Ad-hoc mode is worth naming precisely so a design cannot borrow infrastructure-mode assumptions by accident. IBSS has no AP association or AP-backed distribution service, so two nodes that drift out of direct range can lose contact instead of roaming to a covering AP. Wi-Fi Direct is a separate peer-to-peer arrangement with a group owner, not an IBSS. For either design, review joining, security, addressing, and what happens when a third device needs the link. Almost every architecture in this chapter assumes infrastructure mode because an AP provides the planned access and distribution path.

14.2.7 Beginner Example

A warehouse scanner, fixed freezer sensor, ceiling camera, and maintenance tablet may all use Wi-Fi, but they do not prove the same architecture. The scanner needs route and roaming evidence, the freezer sensor needs installed-location and reconnect evidence, the camera needs sustained traffic and backhaul evidence, and the tablet needs support and segmentation evidence.

14.2.8 Overview Knowledge Check

14.3.1 How It Works: Architecture Review

First, List device classes. Separate fixed sensors, mobile scanners, cameras, gateways, handheld tools, and maintenance clients because each class has different evidence needs. Next, Map access and backhaul separately. Identify where devices associate, which APs carry them, and how AP traffic reaches required services. Then, Name mobility behavior. Decide whether devices are stationary, reconnect after sleep, move slowly, roam while active, or recover after AP failure. After that, Review airtime and traffic. Look for retry pressure, bursty firmware updates, camera streams, polling intervals, and shared-channel effects. Finally, Record security and operations. Include credential ownership, segmentation, onboarding, revocation, monitoring, logs, and support responsibility.

14.3.2 Intermediate Example

A factory adds Wi-Fi sensors to an existing staff network. The weak recommendation is “use the existing SSID.” A reviewable recommendation separates the sensor SSID or policy boundary, installed coverage evidence, reconnect behavior after sleep, AP capacity at the installed locations, backhaul reachability to the broker, and the owner of credential rotation and troubleshooting.

14.3.3 Architecture Ledger

14.3.4 Practitioner Knowledge Check

14.4.1 How A Station Actually Joins A BSS

Association is not a single event; it is a short sequence of frames, and a stalled deployment usually stalls at one specific step in that sequence. A station first finds candidate access points, either passively by listening for beacon frames each AP sends at a common interval of about 100 ms (each beacon advertises the SSID, supported rates, and transmission parameters), or actively by sending probe requests and collecting probe responses from APs that answer. When several access points answer for the same SSID, the station picks one using signal quality such as SNR and its own selection policy, not simply the first responder.

Once a candidate is chosen, the authentication sequence depends on the security mode: WPA3-SAE authenticates before association, while an open-system exchange precedes association in WPA2-Personal. The station then sends an association request and receives a response, usually with an association ID. Protected data requires the appropriate key exchange after association. A device stuck before association may be failing discovery, authentication, capability negotiation, or AP policy; a device that associates but cannot use the service may still be failing key exchange, DHCP, or the network path. Reading a failure log against this sequence turns a vague “won’t connect” report into a specific stage to investigate.

14.4.2 Why Roaming Is Not Just An AP Feature

In a multi-AP environment, the network can advertise neighbors and provide infrastructure support, but the client still has behavior of its own. A moving device may stay attached too long, switch at a poor time, or reconnect differently after sleep. Stationary devices may not need roaming evidence, but they do need installed-location coverage and reconnect evidence.

Airtime adds another layer. Two devices can have strong received signal strength and still harm each other if they create retries, bursts, hidden-node contention, or synchronized update traffic. That is why an architecture proof should include representative traffic windows, not only a survey heat map. The review should record which device class owns the airtime risk and which change would trigger a new test.

14.4.3 Advanced Example

A hospital asset tag, a nurse tablet, and a wall-powered gateway can all appear under the same Wi-Fi deployment. The asset tag needs low-power join and report behavior; the tablet needs route evidence through care areas; the gateway needs stable backhaul and monitoring. A single AP dashboard screenshot cannot prove all three. A better record traces device class, BSS or ESS boundary, mobility requirement, airtime risk, credential behavior, and retest trigger.

14.4.4 Failure-Boundary Checks

14.4.9 Try It: Architecture Evidence Sketch

Choose one Wi-Fi IoT device class. Write its station role, expected AP or BSS boundary, SSID or policy boundary, backhaul dependency, mobility or sleep behavior, airtime risk, and retest trigger. If you cannot name one of these fields, the architecture recommendation is not ready.

14.4.10 Under-The-Hood Knowledge Check