做轨道交通无线项目这些年我经常被问到一个问题列车上的无线不就是每节车厢装个AP吗每次听到这个我都得从头解释一遍。列车是一个高速移动的金属封闭体车厢里几十上百个终端要同时上网车底和轨旁还有数据链路要时刻保持这种场景下如果没有一套集中的控制器来统一调度地面的网络经验放到车上基本会翻车。Controller Provides Wireless Solution for Trains这个方向说白了就是给一列火车配一个无线大脑把车厢内部的覆盖、车地之间的回传、整列车的策略管理全串起来。这篇文章我把这类方案的架构逻辑、关键功能、落地调试和排障经验整理出来给轨道交通行业的集成商、运维和研发朋友做个参考。1. 整个方案的设计思路为什么列车需要一台总控1.1 列车上的无线需求不是装几个AP那么简单先梳理一下列车无线网络到底要承载哪些业务。我自己做过的项目里常见需求通常分四类第一类是乘客Wi-Fi这是最占流量的整车几十到上百个用户同时刷视频第二类是车载视频监控回传一节车厢至少两三个摄像头数据要实时或准实时地到地面第三类是PIS信息、广告屏内容更新这类虽然不大但要求稳定推送第四类是车辆状态、能耗等运行数据的采集上报。这些业务混在同一个无线网络里如果只是简单地把每节车厢的AP独立配置各管各的乘客流量一冲就把监控和状态数据挤掉了调度侧根本没有办法做整体控制。我举个实际例子。之前某条线用的就是独立AP方案每节车厢一台AP自主运行开通乘客Wi-Fi那阵子还算平稳后来监控要上线、要求视频回传问题马上暴露了没有统一调度监控流量经常跟乘客流量抢带宽出了故障要一节车厢一节车厢登设备去看运维的人叫苦不迭。后来改造引入控制器方案把九节车厢的AP全部纳入一个管理域再配合QoS和下行限速策略监控回传的稳定性才算真正解决。这个例子在行业里特别典型也是很多项目从散装无线走向整列协同的直接原因。所以控制器在这个方案里的角色不只是一个管理门户更是一个集中的策略执行点把所有车厢的接入、承载、优先级都收到一个统一的框架下来处理。1.2 列车环境给无线带来的四个麻烦列车环境远比办公室复杂我做第一次车载项目时就吃过亏。第一个麻烦是高速移动带来的信道变化。车速到了每小时两三百公里无线信号会产生明显的多普勒频移频率偏移量跟车速成正比接收端如果用的是普通室温设备的默认设置很容易出现信号强度看起来不错、实际吞吐掉得厉害的情况。这个现象在越区切换的瞬间尤其明显信号一旦处理不及时整条链路的质量就会肉眼可见地变差。第二个麻烦是金属车厢的封闭结构。车厢内部相当于一个法拉第笼信号在车厢里反复反射多径非常严重。而且车厢与车厢之间、车厢与地面之间的穿透损耗很大靠车厢里的普通天线很难兼顾内部覆盖和车地链路。你在办公室常见的一台AP带半个楼层的经验在车厢里完全不适用因为车厢的金属边界决定了覆盖范围极其有限同时又要通过车窗和车底向外部建立链路这两个方向对天线需求是矛盾的。第三个麻烦是电磁兼容。列车上有很多牵引变流器、空调压缩机、制动系统这类大功率设备它们工作起来产生的电磁干扰是持续性的尤其牵引变流器在加速和制动阶段干扰会突然增强。无线设备如果没有合理的频段选择和抗干扰策略现场测试经常会出现进库正常、上线拉胯的情况一上正线跑起来某个频段的底噪比车库高出一大截。第四个麻烦是供电和物理环境的不稳定。车载直流母线电压会波动PoE供电距离又受线缆限制加上列车持续振动连接器、天线馈线这些地方是最容易出隐性故障的。这些麻烦单独拿一个出来都能对付但它们同时叠加在同一个系统上就非常考验方案的整体设计。1.3 控制器方案的定位把散装无线变成整列协同针对前面这些麻烦控制器方案的核心思路就是统一、协同、冗余。无线控制器AC部署在列车通信机柜里每节车厢的AP通过车载以太网接到控制器上控制器统一管理射频参数、SSID、认证方式和QoS策略。这样一来列车内部就组成了一个逻辑上一体的无线网络而不是九节车厢九个孤立的小网络。控制器同时还要负责管理车地之间的回传链路不管是走轨旁无线AP还是走LTE专网都要在控制器上做链路选路和切换决策。为什么要集中到控制器而不是在每个AP上做本地决策原因很简单列车在运行过程中是一个整体车厢里的终端会移动业务会有高峰低谷轨旁链路会有切换。如果所有决策都在本地做每台AP只能看到自己眼前的一小块状态很难保证整列车策略一致。集中式控制器天然适合这种一个移动的小型园区网络的角色。而且从运维角度看列车入库检修的时间窗口很短分散式方案根本没有时间让人逐台设备去查配置、看日志。集中管理之后检修人员上车接一台笔记本几分钟就能把全车无线设备的状态拉出来问题定位速度完全不一样。2. 控制器核心能力拆解它到底管了什么2.1 统一接入管理和策略下发控制器的第一项核心能力是把所有车厢AP拉进一个管理域。实际部署中每台AP上电后会通过IP网络去找到控制器完成隧道建立和状态注册然后所有配置都由控制器统一下发包括SSID、加密方式、频段参数、功率等。AP只在本地做最基础的转发和射频处理复杂的策略决策全部回到控制器。这件事在办公室网络里很普通到列车上却有它的特殊性。首先车上AP数量不多十节车厢也就几十台但安装位置分散、环境恶劣。如果每台都要单独登录去调参数维护成本实在太高。我见过不止一个项目因为没上控制器改一个SSID要逐台登AP去改改完还容易漏最后乘客连不上某个车厢的Wi-Fi查了半天才发现是那节车厢的AP没改到。有了集中控制器配置变更、固件升级、射频调优都是全场下发效率完全不是一个量级。其次控制器的管理通道要能容忍断网。列车进隧道或者车地链路切换时车厢内部的管理通信不能中断所以车载控制器和车载AP之间必须走车内有线网络不能依赖任何外部链路。这个原则看似简单但如果方案设计时把控制器放在地面、让车载AP通过回传链路去注册那一旦车地链路不稳定整列车管理就会瘫痪是非常危险的架构建议选型时一定要避开。2.2 快速漫游让终端在车厢间走动不掉线列车乘客从一节车厢走到另一节车厢终端会从一个AP漫游到另一个AP。这个场景跟办公室漫游差别很大第一乘客可能正在视频通话或直播对中断非常敏感第二车厢连接处的信号跳变往往在几秒内完成没有太多时间协商第三车上有各种移动终端和IoT设备它们的漫游能力参差不齐。控制器在这里要承担三个任务。一是支持快速漫游协议包括802.11k、802.11v、802.11r分别解决邻居测量、网络辅助引导和快速密钥握手的问题。简单说802.11k让终端知道附近有哪些AP、哪个更合适802.11v让网络可以主动建议终端切换802.11r则把切换时的安全认证过程缩短让终端在很短的时间里完成迁移。这三个机制叠加漫游中断时间可以从几百毫秒降低到几十毫秒。二是统一维护整列车的邻居关系表让每个AP知道相邻车厢和本车厢的AP信息这样漫游引导时不至于把终端引导到信号很差的远端AP。这个表在列车上比较好维护因为车厢布局固定AP的相对位置不会变但绝对不能省略。三是漫游阈值和切换参数的管理。漫游阈值如果设得太激进终端会在两个AP之间来回震荡设得太保守终端已经走到信号死角还不切换视频自然卡顿。我在项目中常用的思路是根据车厢长度、AP间距和现场实测数据做分段配置而不是全列车用一套固定参数。这些都是控制器可以在统一界面上做精细调节的点。2.3 QoS精细化调度不能让乘客流量把关键业务挤掉列车上的业务优先级差异很大QoS是无线方案里最容易被低估的模块。摄像头视频流和状态数据需要低时延、低丢包乘客网页浏览和视频缓冲相对可以容忍延迟。没有QoS的网络在流量一大时会出现大家互踩的情况最终结果就是关键业务没有任何保障乘客体验也一起变差两头不讨好。控制器的做法是按SSID和用户组设定优先级用WMM/802.11e机制在空口做队列调度同时按用户做上行和下行带宽限制。我在实际项目里通常会把监控流量放到高优先级队列PIS和状态数据放到中高优先级乘客流量统一限速并放到普通队列。这里有个很实在的经验QoS策略一定要在控制器上做而且要在车载核心交换机上配合做报文优先级标记因为空口只是其中一个瓶颈车厢之间的有线链路如果被突发流量占满一样会出问题。整体要做的是端到端优先级的映射不是只在无线侧设几个参数就完事。另一方面给乘客做带宽限制要讲究颗粒度。限制太狠乘客看个网页都转圈限制太松一两个用户就能把链路占满。我一般是按单用户下行2到4Mbps、上行1到2Mbps来做起步值再根据实际车地链路带宽和用户数动态调整。这个值没有标准答案要根据线路带宽、并发用户数、业务占比综合推算项目现场调优时通常要多试几轮才能找到一个平衡点。2.4 冗余容灾与链路备份列车无线系统最忌讳单点故障冗余设计要从系统层面贯穿。控制器本身建议做双机热备两台控制器之间同步配置和会话状态一台故障时另一台秒级接管。这个在列车上实现起来要考虑机柜空间和供电能力但必须做因为控制器是整个无线网络的中枢它一旦宕机整列车无线可能回到散装状态。AP侧的冗余一般体现在每节车厢的AP需要考虑覆盖重叠和故障替代至少要做到相邻车厢的AP覆盖能互相兜底。这个配合射频调优一起看不能单纯把功率开满而是要让覆盖重叠区恰好覆盖到车厢连接