A vendor’s proprietary roam-assist feature is enabled on city APs, but BYOD phones that only implement standards-based roaming still roam poorly. What should the technician understand?
Select an answer to reveal the explanation.
Short Explanation
Vendor-only roam magic doesn’t show up on a stock phone that only speaks IEEE assists. Standards-based features are what BYOD actually uses. Don’t expect proprietary checkboxes to fix every client.
Full Explanation
When a vendor’s proprietary roam-assist feature is enabled on city APs but BYOD phones that only implement standards-based roaming still roam poorly, the technician should understand that proprietary roaming assists may not help standards-only clients; those devices need standards-based roaming features. Mixed civic BYOD populations punish vendor-only helpers. Prefer interoperable standards when the audience is heterogeneous.
Proprietary roam assists always overriding and upgrading every BYOD stack to full vendor roaming fails because phones cannot gain proprietary code from AP marketing features alone. Standards-only clients roaming better only when proprietary features are the sole option enabled fails by concept: they need standards-based assists. BYOD phones ignoring RF entirely and roaming solely based on cellular tower IDs inside city hall fails: WLAN roam still depends on Wi-Fi RF and WLAN features.
Exam caveat: proprietary assist ≠ universal BYOD roam fix; standards-based features matter for mixed clients.
Operational check: enable 802.11k/v/r (as designed) for the city SSID; leave proprietary assists off or limited when BYOD dominates; walk-test BYOD phones; document vendor feature scope limits for leadership.