A large public civic venue will use temporary IoT ticket scanners for a three-day festival. What WLAN/IoT design approach is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Festival scanners are weekend guests—give them their own SSID, size the air for the rush, then pack them up. Dumping them on staff Wi-Fi forever or onto the payment VLAN is asking for pain. Ad-hoc with no backhaul is not a box office.
Full Explanation
Temporary IoT ticket scanners for a three-day civic festival belong on an isolated temporary SSID with a capacity and RF plan sized for peak ingress, then decommissioned after the event. Joining scanners to the permanent staff SSID with no capacity model and leaving them afterward pollutes the production WLAN. Bridging scanners into the payment card VLAN without segmentation creates compliance risk. Relying solely on open ad-hoc IBSS between scanners with no backhaul plan fails when cloud validation is required. Exam caveat: event IoT needs time-bounded SSID, RF, and security design. Operational check: build and load-test the temp SSID before gates open, monitor airtime at ingress, and tear down credentials and SSIDs when the festival ends. In municipal WLAN and IoT operations, record the chosen control and the rejected alternatives in the change ticket so on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same control still holds under the current platform code, device mix, and civic event calendar used by the wireless team. Keep RF, capacity, security, and QoS evidence attached to the municipal runbook entry for auditors and future CWNE-level reviews.