2、车地通信基础：无线通信原理、WLAN与LTE-M技术对比、通信时延与可靠性指标

各位好，我是老张。在信号系统里摸爬滚打了十几年，今天咱们聊聊车地通信。说白了，列车和地面控制中心怎么「说话」，是自动驾驶能不能跑起来的关键。你想想看，车跑得再快，指令传不过去，那不就是睁眼瞎吗？

2.1 无线通信原理：信号是怎么「飞」起来的

先讲点基础。无线通信，本质上就是电磁波在空间里传播。我习惯把电磁波想象成水波——你往池塘里扔块石头，波纹一圈圈往外扩散。无线信号也一样，从天线发射出去，碰到障碍物就反射、绕射、散射。

这里有个关键概念：多径效应。信号从发射端到接收端，走的不是一条直线。它会撞到楼、撞到车、撞到隧道壁，然后从不同路径到达。结果呢？接收端收到的是多个「迟到」的信号叠加在一起。我在北京某条地铁线调试时，就遇到过这种情况——列车在隧道里跑着跑着，通信突然断了。查了半天，原来是多径干扰导致信号相位抵消。

接收功率 = 发射功率 + 天线增益 - 路径损耗 - 阴影衰落 - 多径衰落

还有一个概念叫多普勒频移。列车高速移动时，接收到的信号频率会发生变化。往基站方向跑，频率变高；远离基站，频率变低。我建议做系统设计时，一定要预留频率偏移的余量。尤其是时速160公里以上的线路，这个偏移量能到几百赫兹，处理不好就会丢包。

2.2 WLAN与LTE-M技术对比：老将和新秀

现在主流的车地通信方案就两种：WLAN（无线局域网）和LTE-M（轨道交通专用LTE）。我两个都用过，各有各的脾气。

2.2.1 WLAN：成熟但有点「娇气」

WLAN就是咱们家里用的Wi-Fi的工业版。优点是便宜、成熟、生态好。我在早期项目里，轨旁装的全是802.11n的AP，一个站台装4-6个，覆盖整条线路。

但WLAN有个硬伤：切换时延。列车从一个AP覆盖区跑到另一个，需要断开旧连接、建立新连接。这个过程叫「漫游」。我记得在深圳某条线路上，列车以80公里时速跑，漫游时延能到150-200毫秒。对于自动驾驶来说，这个时延太大了——车都跑出去好几米了，指令还没到。

2.2.2 LTE-M：专为轨道而生

LTE-M是4G LTE的定制版。它解决了WLAN的几个痛点：

• 无缝切换：核心网统一管理，切换时延控制在50毫秒以内。我做过实测，30毫秒左右就能完成切换。
• 覆盖范围大：一个基站覆盖1-3公里，比WLAN的200米强太多。
• 抗干扰能力强：采用OFDM（正交频分复用）技术，对多径效应有天然免疫力。

但LTE-M也有缺点：贵。一套基站设备几十万，核心网还要单独建。小线路用不起。

我个人习惯这样选型：线路长度小于20公里、速度低于80km/h，用WLAN性价比高；线路长、速度快、对可靠性要求高，直接上LTE-M。

2.3 通信时延与可靠性指标：数字背后的门道

做信号系统，最怕的就是「差不多」。时延和可靠性，必须用数字说话。

2.3.1 时延指标

车地通信的时延，我一般分三段看：

1. 空口时延：信号从车上天线到轨旁设备的时间。WLAN大概5-10ms，LTE-M大概10-20ms。
2. 网络传输时延：从轨旁设备到控制中心的时间。光纤传输，1公里大概5微秒，基本可以忽略。
3. 处理时延：设备处理数据的时间。这个取决于硬件性能，一般10-30ms。

总时延 = 空口时延 + 网络时延 + 处理时延。对于GoA4级（全自动运行）系统，端到端时延要求不超过500毫秒。我建议留出20%的余量，按400毫秒设计。

2.3.2 可靠性指标

可靠性，说白了就是通信不能断。行业里常用两个指标：

• 丢包率：丢失的数据包占总发送量的比例。CBTC（基于通信的列车控制）系统要求丢包率小于1%。我建议按0.1%设计。
• 可用性：系统正常运行时间占总时间的比例。一般要求99.99%，也就是一年停机不超过52分钟。

为什么会丢包？原因很多：信号遮挡、干扰、设备故障。我记得在成都某条线上，一到早晚高峰就丢包。查了三个月，发现是乘客手机Wi-Fi热点干扰了轨旁AP。后来我们加了5GHz频段，问题才解决。

系统可用性 = 设备可靠性 × 链路冗余度 × 抗干扰能力

嗯，最后说一句。车地通信是信号系统的「血管」。血管堵了，大脑再聪明也没用。所以，做设计时多花点心思在通信上，绝对值得。