无线漫游是校园WiFi用户体验的分水岭。你问一个普通学生"学校网络好不好"，他不会跟你讨论出口带宽或者认证协议，他只会告诉你"走到教学楼B区的时候网断了"，或者"从图书馆走到食堂要重新登录"。这些问题的根都在漫游上。但对信息中心来说，漫游不只是无线侧的事，它跟计费系统的衔接如果没处理好，会直接导致计费数据错乱、重复扣费、甚至用户莫名其妙被踢下线。

漫游触发的计费事件链，比想象中复杂

一个学生在校园里走动，手机从AP1的信号范围走到AP2的范围，底层发生的事比用户看到的多得多。首先是无线侧的802.11r或者11k/v快速漫游协议完成AP切换，然后是网络接入层的认证状态迁移，最后才是计费系统层面的会话更新。在计费系统看来，一次漫游至少触发三个事件：旧的计费会话要结算，新的计费会话要建立，中间不能有空窗期导致计费数据断裂。

如果这三个事件的处理时序不对，就会出现各种诡异的问题。最常见的一种：漫游之后新AP发了一个Accounting-Start包给RADIUS，老AP也发了一个Accounting-Stop包，但两个包到达RADIUS服务器的顺序反了——Stop包先到，Start包后到。如果计费系统不做时序校验，就会把这个Stop当成会话正常结束，把Start当成一次全新上线，中间产生了计费空窗。用户实际上一直在上网，但计费记录上有一段空白，这段空白的流量去哪了？答案是：走了，但没算钱。

RADIUS无状态协议的计费连续性保障

RADIUS协议是UDP承载的无状态协议，设计的时候就没考虑过会话状态的跨AP传递。标准RADIUS里有Acct-Session-Id这个属性，理论上同一个用户的同一个上网会话应该用一个Session-Id贯穿始终，漫游不改Session-Id。但现实是很多厂商的AP在漫游后会重新生成一个新的Session-Id，导致计费系统以为这是两个独立会话。

解决这个问题的关键是计费系统自己在应用层做会话关联，不能只依赖RADIUS的Session-Id。具体做法是：计费系统在收到Accounting-Stop的时候，不要立刻关闭账户的计费会话，而是先等一个非常短的间隔（比如五秒），看看同一个用户的同一个MAC地址在另一个AP上有没有新的Accounting-Start到达。如果有，说明这是一次漫游而非真正的下线，计费上下文应该继承而不是重置。这个等待窗口的时间要把握好，太长了用户体验差（用户漫游后迟迟看不到自己的实时流量统计），太短了容易误判（万一用户真的断网了再重连，两个操作之间也是一小段间隔）。

还有一类更复杂的情况：三层漫游。学生在不同子网之间漫游，IP地址变了，但MAC地址没变。对计费系统来说，同一个MAC出现了两个IP，到底是一个用户在漫游还是两个不同的设备？这种情况单靠MAC地址就不能判断了，需要在计费系统里把用户账号、MAC地址、VLAN、AP位置做一个联合指纹，漫游的时候通过指纹匹配来判断是同一用户的跨子网移动。

漫游计费里最容易踩的坑：时长和流量的重复计算

如果说计费空窗是少收了钱，那重复计费就是多收了钱，后者引发的投诉比前者严重得多。漫游导致重复计费的情况通常是这样的：漫游前老AP发了一个Accounting-Stop，里面带了从上线到漫游这段时间的累计流量统计；漫游后新AP发了一个Accounting-Start，开始从零计数。但如果新AP在发送第一个Accounting-Interim-Update的时候，把上线以来的所有流量都报上去了，而计费系统在漫游前已经结算过一次，那就重复扣了。

这个问题的根在AP和计费系统的计费语义不一致。有的AP在每次Accounting-Interim-Update里报的是增量流量（从上一个Interim到现在的差值），有的AP报的是累计流量（从上线到现在的总量）。如果计费系统不做识别，把累计流量当成增量流量来加，就会重复累加。所以计费系统必须具备识别Acct-Input-Octets是累计值还是增量值的能力，通常的识别方式是：如果这次的Acct-Input-Octets比上一次小，那说明AP重启了或者这是一个新会话，应该按增量处理而不是累计。

高密度场景下的漫游风暴

在学校体育馆、报告厅、食堂这类高密度场景，几十上百个设备同时在密集的AP之间来回漫游，会产生一场"漫游风暴"。这个风暴对计费系统的压力不是带宽，而是每秒的RADIUS事务量。一台普通的RADIUS服务器，单核处理能力大概在每秒几千个认证包。但在漫游风暴里，每台设备一次漫游触发两到四个RADIUS包（Stop、Start、可能还有Interim），乘以同时漫游的设备数，峰值可以轻松突破每秒几万个包。

应对漫游风暴需要计费系统在架构层面做好两件事。第一是RADIUS接收端的UDP缓冲区要足够大，不能因为瞬时包量太大导致丢包——UDP丢包在RADIUS场景里等于直接丢失计费数据。第二是计费引擎的后端处理要做异步化，前端RADIUS组件只负责快速接收、打时间戳、写入消息队列，后端的计费计算模块从队列里异步消费，不阻塞前端接收。

还有一个从网络侧配合的手段：在AC或者无线控制器上配置"漫游粘滞"，也就是让设备在短时间内（比如一到两分钟）尽量不离开当前AP，减少不必要的漫游。这个设置跟计费系统看起来没关系，但实际上是降低计费系统无效事务量的有效手段。但粘滞时间不能设太长，否则用户走到新AP的信号核心区还粘在旧AP上，反而导致体验下降。一般建议是一到两分钟的粘滞时间配合信号阈值触发漫游的双重策略。