A volunteer Wi-Fi team proposes an ad hoc IBSS for a city festival. What should an assessor flag about that choice versus AP-based service?
Select an answer to reveal the explanation.
Short Explanation
IBSS is DIY picnic blankets—no pavilion AP running the show. Fine for a tiny peer demo; shaky if you expected roaming, centralized policy, or AP-style guest controls.
Full Explanation
An Independent Basic Service Set (IBSS), often called ad hoc mode, lets stations communicate peer-to-peer without a traditional access point anchoring the BSS. For a city festival, that choice changes coverage planning, roaming expectations, power/responsibility boundaries, and typical security tooling assumptions compared with an infrastructure BSS or multi-AP ESS. Assessors should flag that festival operations relying on IBSS will not inherit controller features, seamless ESS roaming, or the same enterprise authentication patterns by default. Claiming an IBSS automatically provides enterprise RADIUS and multi-AP ESS roaming overstates what peer mode delivers. Calling IBSS another name for a controller-managed campus ESS collapses opposite architectures. Asserting festival IBSS setups encrypt all neighbor traffic by default with WPA3-Enterprise invents a security baseline IBSS deployments do not magically guarantee. Exam caveat: Know IBSS versus infrastructure BSS as a mode distinction even if most OSWP lab targets are infrastructure APs. Operational check: If volunteers propose IBSS for a civic event, document whether RoE and support staff can accept peer-mode failure modes; prefer a managed infrastructure SSID unless the engagement explicitly validates ad hoc behavior.