酒店WiFi认证项目里，"无缝漫游"是甲方提得最多的需求之一。住客从大堂走到电梯，从电梯走到走廊，再进入客房，整个过程中WiFi不断线、认证不重弹，这是理想状态。但真正做过酒店项目的人都知道，要做到真正的无缝漫游认证，涉及的环节远比想象中多，很多项目最后交付的只是"能漫游但偶尔断一下"的半成品。

漫游和认证是两件事

很多人把漫游和认证混在一起谈，实际上这是两个独立的流程。漫游是指终端从一个AP切换到另一个AP的过程，认证是指终端接入网络时的身份验证。漫游本身是无线层面的行为，由终端和AP协商完成；认证是网络层面的行为，由认证服务器判断终端是否允许上网。两者之间的关联在于：如果漫游后终端的认证状态没有同步到新的AP或新的无线控制器，住客就会被重新弹出Portal页面，需要重新认证。

酒店场景的漫游难点在于建筑结构复杂。客房走廊通常很长，一个AP覆盖不了整条走廊，住客从走廊走到客房，可能跨越两三个AP的覆盖范围。如果每个AP切换都触发重认证，住客体验会非常差。尤其是视频通话、在线会议这类对延迟敏感的应用，哪怕断两三秒，用户都能感知到。

快速漫游协议在酒店场景的局限

802.11r是业界常用的快速漫游协议，理论上可以把漫游切换时间从几百毫秒压缩到几十毫秒。但802.11r的生效有前提条件：终端和AP都要支持，且整个漫游域内的AP要由同一个无线控制器管理。酒店场景的实际情况是，住客的终端五花八门，从最新款手机到老旧笔记本都有，不是所有终端都支持802.11r。我们测过一批常见手机，苹果手机支持得比较好，部分安卓手机对802.11r的兼容性存在问题，开启后反而导致漫游失败。

还有一个容易被忽略的问题：酒店里经常有多个楼层，跨楼层漫游比同楼层漫游更复杂。不同楼层可能由不同的无线控制器管理，跨控制器漫游需要控制器之间做认证状态同步。如果控制器之间的同步机制没配好，住客从三楼走到四楼就要重新认证。这种问题在测试阶段不容易发现，因为测试人员通常在同一楼层活动，只有住客实际使用时才会暴露。

认证状态同步的架构设计

要让漫游后不重新认证，核心是认证状态的同步。Portal认证的状态通常保存在无线控制器或认证网关上。如果住客漫游后接入的AP由同一个控制器管理，认证状态天然共享，不需要额外处理。但如果跨控制器，就需要在控制器之间配置认证状态同步。不同厂商的控制器同步机制不同，有的支持RADIUS记账代理，有的用专用的控制器间同步协议，有的干脆不支持跨控制器漫游认证保持。

在一个国际连锁酒店项目中，客房和大堂分别用了两套不同厂商的无线设备，大堂是早期建设的，客房是后期改造的。住客在大堂认证上网后，走到客房就要重新认证。甲方要求解决这个体验问题，但两套设备的认证状态无法直接同步。最后的解决方案是在两套设备前面加了一层认证网关，所有认证请求统一走网关，网关维护全局认证状态。这样虽然增加了架构复杂度，但确实解决了跨设备漫游认证保持的问题。

项目验收时的漫游测试方法

很多酒店WiFi认证项目在验收时只做静态测试：在固定位置测信号强度、测认证成功率。但漫游问题只有在移动中才会暴露。我们建议验收时做动态漫游测试：测试人员拿着手机从大堂走到电梯，坐电梯到目标楼层，沿走廊走到客房，全程视频通话不断。如果通话中断或Portal页面弹出，记录中断位置和时间。用这个方法，我们在多个项目中发现了漫游认证盲区，大部分集中在电梯井附近和楼层交接处。这些问题在静态测试中完全看不到，但对住客的实际体验影响很大。

还有些酒店为了节省成本，在走廊里隔三四个房间才放一个AP，信号覆盖勉强达标，但漫游切换的迟滞区很大。住客从走廊走到房间的几秒钟内，手机在两个AP之间来回切换，每次切换都可能触发认证状态检查。如果认证系统的响应速度跟不上切换频率，就会出现认证掉线。合理规划AP密度，保证每个位置至少有两个AP的信号覆盖重叠，是减少漫游认证问题的基础工作。