Wi-Fi & 802.11 · Study deck
Wi-Fi Network Topologies
Imagine a stock-room scanner that shows full signal bars but cannot update an order.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: A client may see one SSID, but it is still attached to one AP radio at a time, using one channel, one BSSID, one authentication state, and one path toward the service.
- Explain: When a troubleshooting record only says "the Wi-Fi was connected," it hides whether the failure sat at association, key exchange, DHCP, DNS, firewall policy, broker reachability, roaming timing, or application recovery.
- Explain: 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.
Major section
Start With the Wireless Story
The radio link may be fine while a later cable, address check, or service is broken.
- A single green symbol does not prove the whole path.
- The network planner should trace one real job.
- This simple path leaves out the radio rules that let many devices share the air.
Major section
Wi-Fi Architecture Is A Set Of Boundaries
Wi-Fi architecture describes how stations, access points, SSIDs, BSSs, ESSs, backhaul paths, and management systems fit together.
- The main design move is to separate boundaries.
- An ESS can connect multiple BSSs behind one network name.
- Backhaul carries traffic away from the AP.
- Roaming, reconnect, segmentation, and support ownership are separate evidence questions.
Major section
Wi-Fi Architecture Is A Set Of Boundaries (continued)
Each boundary has different evidence, connecting architecture to a diagnostic sequence that stops a successful join from masking a later failure.
- A useful review therefore follows the traffic and the support responsibility, not just the SSID name.
- This separation prevents two common mistakes.
- Backhaul carries traffic from APs toward services.
Major section
Wi-Fi Architecture Is A Set Of Boundaries (continued)
For IoT, the architecture question is not only "can the device connect?" It is whether the chosen arrangement can support coverage, traffic, power behavior, security, operations, and recovery for the devices that will actually be deployed.
- The second is treating one shared network name as proof that cameras, scanners, sleepy sensors, robots, and maintenance tablets have the same risk.
- They do not: each class needs a matching record for access, traffic, mobility or reconnect, security, and operations.
- The AP radio accepts client associations; its BSS is the local radio cell that clients actually join.
Major section
Wi-Fi Architecture Is A Set Of Boundaries (continued)
Multiple BSSs can present one network name, but a shared SSID does not prove roaming, coverage, or policy behavior.
- 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.
Major section
Wi-Fi Architecture Is A Set Of Boundaries (continued)
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.
- A warehouse scanner, fixed freezer sensor, ceiling camera, and maintenance tablet may all use Wi-Fi, but they do not prove the same architecture.
Major section
Under The Hood: Roaming, Airtime, And Operations Make The Architecture Real
Protected data requires the appropriate key exchange after association.
- Wi-Fi architecture becomes real when devices move, sleep, reconnect, compete for airtime, and depend on operators to maintain credentials and AP behavior.
- The BSS/ESS boundary is where many hidden failures start.
- Airtime adds another layer.
Major section
Under The Hood: Roaming, Airtime, And Operations Make The Architecture Real (continued)
The review should record which device class owns the airtime risk and which change would trigger a new test.
- The architecture diagram may show one clean network, but the runtime system contains AP radios, client decisions, authentication state, retries, uplinks, monitoring gaps, and support handoffs.
- The station then sends an association request and receives a response, usually with an association ID.
- A single AP dashboard screenshot cannot prove all three.
Major section
Under The Hood: Roaming, Airtime, And Operations Make The Architecture Real (continued)
A moving device may stay attached too long, switch at a poor time, or reconnect differently after sleep.
- A client may see one SSID, but it is still attached to one AP radio at a time, using one channel, one BSSID, one authentication state, and one path toward the service.
- When a troubleshooting record only says "the Wi-Fi was connected," it hides whether the failure sat at association, key exchange, DHCP, DNS, firewall policy, broker reachability, roaming timing, or application recovery.
- If you cannot name one of these fields, the architecture recommendation is not ready.
Major section
Under The Hood: Roaming, Airtime, And Operations Make The Architecture Real (continued)
In a multi-AP environment, the network can advertise neighbors and provide infrastructure support, but the client still has behavior of its own.
- 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.
- 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.
- Stationary devices may not need roaming evidence, but they do need installed-location coverage and reconnect evidence.
Major section
Summary
Wi-Fi architecture for IoT is a boundary-and-evidence problem.
- The safest recommendations are bounded.
- They state which device classes are covered, which evidence was observed, what remains out of scope, and what change should trigger retest.
- That makes Wi-Fi architecture a reviewable engineering decision rather than a generic technology label.
Deck summary
Key takeaways
The radio link may be fine while a later cable, address check, or service is broken.
- Wi-Fi architecture describes how stations, access points, SSIDs, BSSs, ESSs, backhaul paths, and management systems fit together.
- Each boundary has different evidence, connecting architecture to a diagnostic sequence that stops a successful join from masking a later failure.
- For IoT, the architecture question is not only "can the device connect?" It is whether the chosen arrangement can support coverage, traffic, power behavior, security, operations, and recovery for the devices that will actually be deployed.
- Protected data requires the appropriate key exchange after association.
Retrieval practice
Recall check 1 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q1A scanner joins the access point but an order update never reaches the service. Who should investigate?
Show answer
Answer: A The first failed handoff identifies the responsible part.
Retrieval practice
Recall check 2 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q2Why is a successful Wi-Fi association not enough evidence to approve an IoT Wi-Fi architecture?
Show answer
Answer: C A join event is useful evidence, but it is not the whole architecture review.
Retrieval practice
Recall check 3 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q3A station joins an access point but cannot reach the local service. Which map helps locate the break?
Show answer
Answer: A Those boundaries can fail independently.
Retrieval practice
Recall check 4 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q4A team proposes one shared SSID for staff laptops, cameras, scanners, and battery sensors. How should the network plan address these different device classes?
Show answer
Answer: D A shared SSID may work, but only if each device class has evidence for its behavior and support needs.
Retrieval practice
Recall check 5 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q5Why should Wi-Fi architecture reviews separate stationary-device reconnect evidence from mobile-device roaming evidence?
Show answer
Answer: A Different movement patterns create different architecture evidence requirements.
Print reference
Answers
Answer key.
- A · The first failed handoff identifies the responsible part.
- C · A join event is useful evidence, but it is not the whole architecture review.
- A · Those boundaries can fail independently.
- D · A shared SSID may work, but only if each device class has evidence for its behavior and support needs.
- A · Different movement patterns create different architecture evidence requirements.