次级STA漫游行为------保持应用连接不间断
在移动场景中，漫游是不可避免的。当主STA端口检测到当前AP信号衰弱，并决定漫游至新的AP时（可能跨越不同频段，例如从5GHz漫游至2.4GHz），驱动程序必须精心处理辅助STA的状态，以避免双端口同时处于漫游过渡期而导致所有连接中断。推荐的行为模式如下：
首先，主STA开始漫游流程（扫描候选、认证、重关联）时，辅助STA保持其当前连接不变，正常收发数据（若应用绑定在辅助链路上）。主STA的漫游过程中，驱动程序应确保辅助STA的数据路径不受影响，即使主STA需要临时切换射频前端到新信道，也尽量利用辅助STA的硬件链保持服务。其次，主STA完成漫游并成功与新AP建立安全连接（即密钥已安装、加密已激活）后，驱动程序才启动辅助STA的漫游评估。此时，驱动程序会基于新的主STA频段和当前环境，为辅助STA选择合适的漫游候选------候选可能位于相同频段或不同频段，但需避免两者最终工作于同一拥挤信道造成自干扰。
关键在于同步漫游的时序：驱动程序应确保主STA和辅助STA不会同时执行重关联握手，因为这会增加CPU和固件负担，且可能导致信标丢失。因此，通常采用串行化方式：先完成主漫游，再触发辅助漫游。在辅助STA漫游过程中，主STA已稳定工作，可承载关键流量。通过这种方式，绑定到任一STA端口的上层应用（例如视频会议软件绑定到主端口，文件下载绑定到辅助端口）都不会经历完全断开，仅可能在辅助端口切换瞬间出现微小的丢包（小于50ms），这对于具有缓冲和重传机制的应用而言是可接受的。
此外，如果主STA漫游失败而断开连接，驱动程序应决定是否让辅助STA也立即断开（以保持一致性）还是让辅助STA单独存在（允许用户继续使用辅助网络）。WiFiCx推荐后一种策略，因为辅助网络可能是为了特定应急通信而建立的，不应受主故障影响。但具体选择可由IHV通过私有配置调整。
功耗与性能权衡
双STA模式不可避免地增加射频活动，从而提升功耗。因此，驱动程序应实现智能电源管理：当辅助STA无活跃流量且主STA负载较轻时，可允许辅助STA进入省电模式（PS-Poll或U-APSD），仅在信标监听时唤醒。同时，操作系统可动态启用或禁用辅助STA功能（通过设置标志位），例如在电池模式下优先关闭辅助STA以延长续航。这些优化须在驱动能力声明中体现，并与WiFiCx电源策略协同。
未来扩展与兼容性考虑
尽管当前仅支持两个STA，但设计上已预留扩展空间。后续版本可能支持三个或更多辅助STA，届时频段组合数组将随之增长，漫游和扫描逻辑需更为复杂。同时，双STA功能应与前述ECSA（扩展信道切换）机制兼容------当GO角色启用ECSA时，辅助STA连接不应被中断，驱动程序需确保信道切换通知能同步传达给所有活跃端口。
总之，双STA连接为WiFiCx生态提供了强大的多网络融合能力，但实现质量完全取决于驱动/固件对扫描抑制、同步连接、串行漫游和电源管理的精细控制。建议IHV开发人员严格遵循上述TLV规范和时序要求，并通过全面的漫游和断线恢复测试验证可靠性。后续，微软将提供参考实现示例和性能基准工具，以协助各厂商快速集成。