隧道里跑 80km/h 的列车，为什么会丢 CBTC 包：一次地铁车地无线改造记录
核心概览
背景： 2025 年 1 月，我们接手一个 8.2 公里地铁区间（含 5.6 公里隧道、2 个车站、一段地面高架）的车地无线改造。原系统是漏缆 + 备用 4G 公网，CBTC 使用独立频段。问题在于：早高峰时 CBTC 往返时延会从正常的 32ms 跳到 140ms 以上，一周内触发了 3 次非计划降速。
结论： 换成轨旁 MESH 架构后，12 次动车测试中 CBTC 往返时延稳定在 21–34ms，列车以 80km/h 通过基站边界时切换时延 24–38ms，全程零丢包。但改造过程中有两件事是原计划里没预料到的：一段弯道里的漏缆残留形成了窄带干扰，以及一个车站的乘客设备量远超预期。
这篇文章写的是这两件事，以及那 12 次动车测试的全部数据。 通用性的 MESH 原理这里不重复，只放现场实测值、测错的地方和对应整改。
故障现象：CBTC 时延为什么会在早高峰跳 4 倍
业主最初给我们的判断是”漏缆老化了，需要换一段”。但我在做故障复现时发现，时延尖峰和老化没有明显关联——它出现的时间点高度集中在两个条件同时成立时：早高峰 + 列车停在 2 号站站台区间。
我拉了连续 14 天的 CBTC 时延日志，按位置和时间做了交叉分析。结论很清楚：不是设备老化，是站台区的射频拥塞。
| 测试条件 | CBTC 往返时延（均值） | CBTC 往返时延（P95） | 触发降速次数 |
|---|---|---|---|
| 非高峰 + 隧道中段 | 31ms | 38ms | 0 |
| 非高峰 + 2 号站站台 | 36ms | 52ms | 0 |
| 早高峰 + 隧道中段 | 34ms | 47ms | 0 |
| 早高峰 + 2 号站站台 | 89ms | 142ms | 3 次/周 |
为什么站台是问题所在？2 号站是换乘站，日均客流 11 万人次。原系统的漏缆在站台区段要同时承载 CBTC 数据和乘客 WiFi 回传——这两类流量共享同一段漏缆的带宽。早高峰时站台上千台乘客设备接入，把漏缆的可用容量吃掉大半，CBTC 的数据包排在队列里等。
这也解释了为什么”换一段漏缆”没用：漏缆本身的射频性能是合格的，问题出在架构——它把所有流量挤在一条共享的物理介质上，没有 QoS 隔离，也没有容量扩展的余地。
隧道逐段勘测数据（含切换时延与 CBTC 往返时延）
下面这张表是现场逐段勘测的原始记录。测点按线路区段编号，里程为线路起点起算的公里标（因涉及运营线路信息，具体坐标以现场图 1 为准）。数据为 2025-02-10 至 2025-02-14 夜间非运营窗口（01:00–04:00）的原系统基线测试实测值，方法为测试列车以 60km/h 匀速通过，用频谱仪（Anritsu MS2720T）+ CBTC 车载日志记录仪同步采集。
「隧道截面」一栏决定了波导效应强弱和基站安装方式——圆形隧道和矩形隧道的信号传播差异可达 8–12dB，这一列也是后来返工一的线索来源。
| 区段 | 里程 | 类型 | 隧道截面 | 原系统 CBTC 时延 | 原系统 RSSI | 切换时延（原） | 建议基站间距 |
|---|---|---|---|---|---|---|---|
| S1 起点 — 1 号站 | 见现场图 1 | 直线隧道 | 圆形 Ø5.4m | 29–34ms | −62 dBm | 240–380ms | 340 m |
| S2 1 号站 — 弯道段 | 见现场图 1 | 曲线隧道（R=350m） | 圆形 Ø5.4m | 33–41ms | −71 dBm | 420–680ms | 180 m |
| S3 弯道段 — 2 号站 | 见现场图 1 | 直线隧道 | 矩形 5.8×5.2m | 31–38ms | −64 dBm | 260–410ms | 320 m |
| S4 2 号站站台区 | 见现场图 1 | 车站（换乘） | 站厅敞开 | 36–142ms | −58 dBm | 280–520ms | 120 m |
| S5 2 号站 — 地面出口 | 见现场图 1 | 斜坡隧道 | 圆形 Ø5.4m | 30–36ms | −66 dBm | 250–390ms | 300 m |
| S6 地面高架段 | 见现场图 1 | 高架（露天） | — | 28–33ms | −68 dBm | 220–340ms | 620 m |
S2 弯道段是最麻烦的区段：切换时延 420–680ms，比直线段高出近一倍。原因是 R=350m 的曲线让漏缆的信号泄漏方向与列车行进方向产生偏角，列车在弯道上实际处于多个泄漏段的交叠区，射频环境比直线段复杂得多。我们把这一段的基站间距从原计划的 340m 压到 180m。
线路区段划分、基站布点与车载 CPE 天线朝向方案见图 1。
返工一：弯道里的漏缆残留形成窄带干扰
第一版方案上线后，S2 弯道段的切换时延虽然从 420–680ms 降到了 46–62ms，但没有达到我们承诺的 35ms 以内。而且数据里有个奇怪现象：同一个弯道，列车往一个方向走是 44ms，反方向走是 58–62ms。
方向相关的性能差异在理论上不该存在——MESH 预连接机制是对称的。所以我把频谱仪架在弯道段中间，做了一次连续 30 分钟的信道扫描，发现了一个不该出现的东西。
在 5.745–5.765GHz 这一段，噪声底比周边信道高出 11–14dB。这个频段上没有任何已知的无线系统在运行。顺着频谱仪的方向找过去，最终定位到的是——原漏缆系统的残余馈线。
原来在改造时，施工队把漏缆更换为 MESH 基站，但有一段约 180 米的旧漏缆馈线没有被拆除（因为它穿在一段不便施工的管线里）。这段悬空的馈线在特定方向上形成了类似天线的结构，把它的谐振频率耦合到了 5.75GHz 附近。列车从一侧经过时，车载 CPE 的天线正好指向这段馈线，受到的影响就更大——这解释了方向相关的性能差异。
整改： 这次的教训是”没拆干净比没装新的更麻烦”。
- 协调运营方在非运营窗口拆除那段 180 米残余馈线（实际花费了两个封锁窗口，因为管线位置确实不便施工）。
- 拆除后把这个频段列入了我们的勘测必查清单——现在做任何改造项目，都会先扫描”原系统残留”的频段特征。
- 在 S2 段把回传信道从受影响的频点移开 2 个信道，即使未来出现类似残余耦合，也有频率余量可用。
整改后 S2 段切换时延降到 24–38ms，双向差异消失。这个问题的处理本身不难，难点是定位花了6天时间。
动车测试：12 次往返，每次切换的原始数据
改造完成后的验收测试做了 12 次动车（6 次往返），全部在非运营窗口进行，测试列车按正常运营速度运行（隧道段 60km/h，高架段 80km/h）。下面是汇总后的原始数据——我保留了每次测试的最大值，因为平均值会掩盖偶发问题。
| 测试项 | 改造前（原系统） | 改造后（MESH） | 12 次测试中的最差值 | 测量方式 |
|---|---|---|---|---|
| 单次切换时延（隧道直线段） | 240–380ms | 24–32ms | 41ms | 车载抓包，切换时间戳差值 |
| 单次切换时延（S2 弯道段） | 420–680ms | 24–38ms | 52ms | 同上 |
| 切换期间丢包 | 1.9%（全程均值） | 0 | 0 | iperf3 持续打流，统计切换窗口 |
| CBTC 往返时延（P95） | 142ms（早高峰站台） | 34ms | 38ms | CBTC 车载日志记录仪 |
| 视频流卡顿帧 | 每次切站出现 2–5 帧 | 0 | 0 | VMS 侧帧时间戳连续性检测 |
| 单列车聚合吞吐 | 未测（原系统已拥塞） | 156–178Mbps | — | 车载交换机端口采样 |
| 非计划降速触发 | 3 次/周 | 0（连续 10 周） | — | 运营方信号系统日志 |
最差单次切换 52ms 出现在 S2 弯道段，属于拆除残余馈线前遗留的一次记录。这里我想说明一点：切换时延的验收标准不该只看均值。我们最初按均值 30ms 验收通过了，但正是那次 52ms 的孤立记录让我们回查频谱数据，才发现了残余馈线的问题。
返工二：车站乘客设备密度被严重低估
第二个问题在 2 号站。我们在方案里给这个站规划了 120 米间距的加密布点，依据是”换乘站、日均 11 万人次”。上线后头两周运营正常，第三周开始出现乘客 WiFi 连接不稳的投诉。
我调了站台区的接入数据，发现问题在并发设备数。我们方案里按早高峰 800 台并发设备估算，实测峰值是 1,640 台——超了一倍。
为什么估错这么多？因为我用的是客流推算（11 万人次 × 高峰系数 × 设备持有率），但没有考虑一件事：换乘站的乘客停留时间比普通站长得多。普通站乘客平均停留 90 秒，换乘站因为要等下一班车，平均停留 4–6 分钟。停留时间长，同一时刻在站台上的设备自然就多。
更麻烦的是 1,640 台设备里有大量是”重连型”设备——乘客的手机在列车进出站时反复断开重连，每次重连都要走一遍认证流程，把基站的关联处理能力占满，反过来影响了 CBTC 和视频流量的队列处理。
整改：
- 在 2 号站站台区增加 2 台 E5000A WiFi 6 模块，专门承载乘客流量。OFDMA 调度让单台设备能高效服务数百个并发客户端，比增加普通 AP 更划算。
- 把乘客流量的容量与 CBTC/视频彻底分离：乘客流量走独立的 VLAN 和独立的射频，物理上就不占用 CBTC 的队列资源。
- 把乘客设备的单客户端限速从 8Mbps 降到 4Mbps。这个决定一开始有争议（运营方担心影响体验），但实测后投诉反而减少了——因为限速释放出的容量让更多设备能稳定接入。
整改后站台区并发设备承载能力达到 2,400 台，CBTC 时延不受影响。这里我学到的教训是：估算乘客设备量不能用”人次”，要用”同时在线设备数”，而且必须考虑换乘站的停留时间差异。
三类流量如何在同一回传上共存
硬件问题解决后，剩下的是流量规划。轨旁 MESH 要同时承载三类要求截然不同的流量，我用的是 VLAN 隔离 + 分级队列。
| 流量类别 | 单列车实测带宽 | 实测时延 | 配置方式 | 实测结果 |
|---|---|---|---|---|
| CBTC 列车控制 | 1.8–3.2Mbps | 21–34ms（往返） | VLAN 10，严格优先队列，保障 5Mbps | 连续 10 周零降速触发 |
| 车载视频监控（12 路） | 62–88Mbps | 后端到端 96–164ms | VLAN 20，承诺信息速率 100Mbps，中优先级 | 零卡顿帧（12 次动车测试） |
| 乘客 WiFi | 可变（共享） | 尽力而为 | VLAN 30，尽力而为，单客户端限速 4Mbps | 站台峰值承载 1,640 台设备 |
CBTC 的保障带宽我们设成了 5Mbps，实测需求只有 1.8–3.2Mbps。这个余量是刻意的——CBTC 流量有突发特性（列车位置更新密集时），而且我宁可浪费一点带宽也不愿让安全关键流量排进队列。
视频流量的承诺信息速率设 100Mbps，实测需求 62–88Mbps。这里有个和仓库 AGV 项目类似的经验：承诺信息速率要按编码器峰值配，不是按平均码率。列车进站时的光照突变会让 H.265 编码器瞬时冲高码率，如果按 88Mbps 的均值配额度，进站瞬间会丢帧。
为什么不沿用漏缆：一笔成本与容量的账
业主内部对这个方案有过争论——漏缆是地铁行业用了几十年的成熟方案，为什么不继续用？我给他们做了一份对比测算，这里的数字是这个项目的实际结算和报价。
| 对比项 | 漏缆方案（原计划扩展） | 轨旁 MESH 方案 |
|---|---|---|
| 施工周期 | 预计 9 个月（需长期封锁窗口） | 4.5 个月（含 12 次动车测试） |
| 封锁窗口需求 | 全程需吊装设备，每个窗口仅能推进 300–400m | 壁挂安装，每个窗口可完成 800–1,200m |
| 站台区容量 | 固定（与列车共享同一段漏缆带宽） | 可扩展（加基站即加容量） |
| 单点故障影响 | 电缆断裂 → 断裂点之后整段失效 | 自愈绕行（相邻基站直连） |
| 未来扩容方式 | 重新敷设全程电缆 | 在瓶颈区段加密基站 |
成本差异主要来自施工方式：漏缆需要沿隧道顶部敷设，依赖专用吊装设备和较长的封锁窗口；MESH 基站是壁挂设备，安装快得多。MESH 方案之所以能用更少的时间完成，也不是因为它”简单”，而是因为它把施工粒度变小了——每台基站相互独立，可以分段推进，不必等整条隧道的连续窗口。
需要说明一点：这个对比结论只适用于改造项目。对于新建线路，如果隧道施工时就已经预留了漏缆敷设条件，漏缆的综合成本未必更高。决策要看项目类型，不能一概而论。
至于为什么最后选了双回传 + 独立覆盖的三频架构——原因和仓库 AGV 项目一样：如果回传和覆盖共用一路射频，12 路车载视频的回传流量会和 CBTC、乘客接入抢同一个空口时间。三频设计把这部分彻底隔开了。
如果再做一次，我会改的 5 件事
- 勘测必查”原系统残留”。 我们扫了现有干扰源、扫了隧道传播特性，唯独没有检查被替换掉的旧系统留下的物理残留。现在我会把”原系统拆除完整性核查”作为勘测的固定步骤。
- 乘客设备量按”同时在线设备数”估，不按客流人次估。 换乘站停留时间 4–6 分钟这个因素，是靠上线后的实测数据才补上的。
- 验收标准要看最差值，不看均值。 那次孤立的 52ms 记录是发现残余馈线的唯一线索，如果只按均值验收就漏了。
- 把”乘客设备重连风暴”纳入容量设计。 列车进出站时大量设备同时断开重连，这个瞬时负载比稳态并发数更考验基站。
- 弯道段的基站间距要在勘测基础上再留 20% 余量。 R=350m 的弯道我们按 180m 布点，事后看应该压到 150m——理由是曲线半径与信号泄漏偏角的关系在勘测阶段很难精确建模，留余量比事后加密省事。
项目最终交付时，8.2 公里线路的 CBTC、12 路车载视频、乘客 WiFi 全部稳定运行，连续 10 周无降速触发，30 天可用率记录 99.96%。业主信号系统负责人后来的一句话我印象比较深：”我们一开始以为这是个换设备的活，后来发现是重新设计架构。”
参考资料
- IEEE 1474.1《Standard for Communications-Based Train Control (CBTC) Performance and Functional Requirements》—— 本文 CBTC 往返时延 50ms 与 90 秒发车间隔指标的参照依据。standards.ieee.org
- IEEE 802.11-2020 —— 无线局域网 MAC 与 PHY 规范，本文 802.11r 快速切换与 VLAN 优先级配置的协议依据。standards.ieee.org
- IEC 62236《Railway applications — Electromagnetic compatibility》—— 本文轨旁设备 EMC 合规与”原系统残留干扰”排查要求的依据。webstore.iec.ch
- ITU-T G.9960 —— 用于 OCC 光纤上联设计的参考建议。itu.int
常见问题
问：这个项目最后用了多少台轨旁基站？
全线共 41 台 MESH 基站。分布是：隧道直线段按 320–340m 间距、S2 弯道段按 180m、2 号站站台区按 120m 并额外加 2 台 WiFi 6 模块、地面高架段按 620m。这个密度是逐段勘测定的，不是统一间距。
问：零丢包是怎么测出来的？真的一次都没丢吗？
测法是 iperf3 持续打流（UDP 模式，10Mbps 恒定码率），在 12 次动车测试全程统计切换窗口内（切换前后各 100ms）的丢包数。结果是 0。需要注意这个结论的边界：它是在整流测试条件下（列车按正常速度、单一方向、无其他列车干扰）得到的。多列车同时运行的场景我们只做了仿真验证，没有实测——这一点我应该坦白说明。
问：拆除那段 180 米残余馈线花了多久？为什么这么难？
用了两个封锁窗口（每个约 3 小时）。难点是那段馈线穿在一条检修不便的管线里，无法直接切割拖出，需要分段拆解。定位花了 6 天，拆除本身只花了 2 个窗口——问题的成本主要在诊断，不在施工。
问：乘客 WiFi 限速到 4Mbps，运营方真的接受吗？
一开始不接受，担心用户投诉。实测后反馈反而变好了：原因是限速之前，少数设备（比如做视频直播的乘客）会占满共享容量，导致大量设备反复掉线。限速后虽然单设备峰值降了，但连接稳定性大幅提升，投诉量下降。这个结论有场景局限性——如果运营方的核心诉求是”保证少数高价值用户的体验”，限速策略就需要重新权衡。
问：这套方案支持多列车同时在隧道里运行吗？
设计上支持。每条 5GHz 回传链路提供 150Mbps 以上双向吞吐，理论上可以承载 2–3 列车（每列约 50–90Mbps 需求）。但如上一个问题所说，多列车场景我们只做了仿真，没有实测。对于发车间隔小于 120 秒、隧道内常驻 3 列以上的线路，我建议在方案阶段就按”每列车独立容量预算”来设计，而不是按共享容量估算。