企业官网建设流程全解析

无人车（远程驾驶/云代驾）这个赛道最近很热，但有个工程问题很少有人讲透：车和云之间那根"看不见的线"，到底要怎么搭？

单5G够不够？4G+5G混搭行不行？新出的RedCap能不能省钱？这些问题选错一个，轻则项目返工，重则"车在路上跑、网突然断了"。

这篇把无人车通讯的需求拆开算一遍账，五种方案摆在一起对比——你会发现，很多看起来"性价比高"的方案，其实有绕不过去的天然缺陷。

先说结论：

无人车通讯有三条硬指标——“0中断”、上行≥40Mbps、控制时延P99≤50ms。对着这三条过一遍，只有"双5G"和"4G+5G"两个方案及格，而4G+5G要付出2~3倍的工程代价。这不是玄学，是物理层决定的。

1、通讯需求从哪来：把无人车的数据流算一遍账

1.1 三条硬指标

做无人车通讯方案，绕不开这三个数字：

① 通讯"0"中断—— 任何单点失效不得造成业务中断，双链路切换中断必须为 0

② 大带宽—— 弱覆盖场景保底上行 ≥40 Mbps（注意：不是峰值，是保底），稳态需求 40~55 Mbps

③ 低时延—— 下行控制 50ms 周期，P99 ≤50ms，送达率 ≥99.999%

1.2 带宽是怎么算出来的

无人车要往云端传什么？拆开看：

① LiDAR原始点云根本直传不了。一台机械式LiDAR的原始点云流量高达277~307 Mbps——这个数字超过了任何蜂窝网络单链路的实际上行能力。所以LiDAR数据必须先在车端压缩，再以5~15 Mbps回传。这也意味着车端要做预处理算力，这是通讯方案之外的成本。

② 40~55 Mbps是"弱覆盖保底"，不是峰值。很多方案宣传"峰值100Mbps+"，但无人车跑在路上，弱覆盖场景（地下、桥下、偏远路段）才是设计基准。峰值好看不解决问题，保底才是。

③ 下行只有400Kbps，但最难做。控制指令是"高频小包"——数据量小，但要求P99≤50ms、送达率99.999%。丢一个包，可能就是一次碰撞。

1.3 还有三个"折损"要记住

理论带宽到了车上还要打折扣：

• 车体遮挡：车载天线安装位置低于手机，可用带宽比理想环境低20%~40%
• 高速移动：60~80 km/h以上，瞬时可用带宽可能只有稳态的1/3
• 上行共享：上行资源天然稀缺（基站上行容量远小于下行），多链路聚合增益有明确上界

这三条折损解释了一个现象：为什么模组规格书上写"上行100Mbps"，实测只有20~30Mbps。不是模组虚标，是场景折损。

2、五种方案摆上桌：三个有天然缺陷

2.1 对比总览

2.2 三个方案的"天然缺陷"（工程手段救不回来）

1、单5G：输的不是速度，是"断了没人接"

单链路的致命问题在故障恢复机制——系统一旦触发重启，在某些特定工况必须重启才能恢复网络通讯。对无人车来说，这几秒到几十秒的空白就是致命的。这是结构性差距，制式本身的限制，靠工程手段无法补齐。

2、单RedCap：不是"差一点的5G"，是另一个坐标系

RedCap（R17轻量化5G）理论上行120Mbps听着不错，但国内20MHz现网实测上行峰值约15Mbps，弱覆盖仅2~5Mbps——连4G都不如。目前国内RedCap基站206.4万站，占全国5G基站的42.7%——覆盖还不完整，无人车跑长途根本赌不起。

3、双4G：解决了"联得上"，没解决"控得住"

LTE空口单程时延10 ~ 25ms，5G是3 ~ 8ms——差一个量级。更致命的是频谱退网风险：4G频谱持续重耕，中短期存在链路直接消失的风险。花双倍硬件的钱，买了两条"正在过时"的链路。

2.3 4G+5G：能用，但代价以倍数计

4G+5G是唯一"可补救"的次优方案，但代价藏在工程里：

而且聚合增益从同构的1.5 ~ 1.8×打折到1.1 ~ 1.3×——实际用起来，常常退化为"5G主用+4G备用"，4G那条链路的带宽价值大打折扣。

一句话：硬件上省一点，工程上多花很多。4G+5G省的是BOM，赔的是开发周期和长期维护成本。

3、时延这笔账：六个环节，通信只能优化两段

很多人以为"上5G=低时延"，但端到端时延是六段加起来的：

① 采集编码 33~50ms → ② 空口上行 → ③ 承载+核心网 → ④ 云解码渲染 15~40ms → ⑤ 控制下行 → ⑥ 执行+底盘 20~60ms

其中②⑤两段，5G（3_{8ms）确实比LTE（10}25ms）好一个量级。但①④⑥三段（车端编码、云端渲染、底盘执行）通信侧根本动不了——加起来70~150ms的"地板"就在那里。

端到端总账：5G覆盖下80_{160ms，弱覆盖下200}400ms。

一个行业参照：腾讯云+中国联通的远程驾驶方案，把跨省端到端时延压到100ms以内，已经是行业标杆水平。他们的方案同样用了5G双通道来抗弱网抖动。

3.1 为什么看P99而不是均值

均值好看不解决问题，尾部才是安全边界。

如果平均时延80ms、P99是300ms——意味着每100个控制指令里有1个要等300ms。对高速行驶的无人车，这1%就是事故率。所以指标要盯P99（99分位），目标100~150ms；送达率要99.999%（丢弃率1e-5）。

3.2 4G+5G的隐藏时延坑

异构双链路还有个不显眼的问题：上下行时延不对称 + gPTP/PTP时钟同步风险。两条链路的RTT差30~50ms，时钟同步做不好，音视频和控制指令会出现"错位"——远端安全员看到的画面和车的实际位置对不上。这类问题测试时很难复现，量产后才暴露。

4、双TBOX不等于双保险：三种失效模式

既然要双5G，那用两个TBOX是不是就稳了？不一定——硬件翻倍≠可靠性翻倍。

4.1 三种失效模式

① 功能错位：两个盒子各管一摊业务，故障时无法互相接管——一盒宕机=业务真空

② 共因穿透：共享天线/供电/GNSS/时钟——单点故障同时打死两个盒子（比如共用的GNSS天线坏了，两个TBOX都定位失败）

③ 切换空洞：主备倒换期间存在100~500ms业务真空，与"0中断"需求直接冲突

4.2 六种分工方式，只有一种是"满分"

4.3 资源归属矩阵：漏一项就是一个坑

做双TBOX方案，必须逐项明确的资源清单：

SIM / 天线 / 供电 / GNSS / IP / 时钟 / 心跳 / OTA 时序

每一项都要回答"两条链路是否独立"。任何一项共享，都是一个隐藏的共因失效点——评审时拿这个清单逐项过，比事后排障省十倍时间。

5、双5G的代价与价值

说完了别人的缺陷，也要说清楚双5G自己要付什么价。

四个优势：

1. Active-Active双活：两条链路同时承载业务，不存在倒换窗口，切换中断天然为0
2. 带宽聚合不牺牲冗余：同构聚合1.5_{1.8×；故障态A+B→A仍保持50}150Mbps，带宽不腰斩
3. 端到端冗余单点全消除：从SIM、天线、供电到IP、时钟，全路径可独立
4. 5G-A生命周期最长：不与4G频谱退网风险绑定，整车生命周期内无需二次换制式

三个代价：

1. 成本最高：双套5G模组+双套天线，BOM高于其他方案
2. 非全场景必要：只有无人车这种强冗余场景ROI成立，乘用车需另做取舍
3. 运维复杂度上升：双链路策略管理、双份OTA与日志，后台工具需同步升级

我的看法：双5G贵，但贵得明码标价——BOM多花的钱，省下的是4G+5G方案1.6_{2倍的开发工时、2}3倍的测试状态空间，以及未来4G退网时的整链路更换。对无人车这种"通讯中断=安全事故"的场景，全生命周期算下来，双5G反而是最便宜的。

6、总结：一张决策图

把整篇文章收成一张决策路径：

无人车通讯方案怎么选？ ├─ 需求确认：0中断 + 上行≥40Mbps保底 + P99≤50ms │ ├─ 单链路（单5G/单RedCap）→ 直接排除（单点失效=全失联） │ ├─ 双4G → 排除（时延差一个量级 + 频谱退网风险） │ ├─ 4G+5G → 可用，但接受： │ 开发 1.6~2× / 集成 2× / 测试 2~3× │ 聚合增益仅 1.1~1.3×，常退化为"5G主+4G备" │ └─ 双5G（推荐基线）→ 关键在执行： · 双TBOX选"完全镜像双活"（方案A） · 资源归属矩阵逐项独立（SIM/天线/供电/GNSS/IP/时钟/心跳/OTA） · 指标盯P99和送达率，不看均值

最后留一个思考：无人车的通讯方案选型，本质上是在回答一个问题——“通讯中断的代价是什么？”

如果答案是"视频卡一下"（比如车载娱乐），单链路+重连就够了。如果答案是"一辆几吨重的车在公开道路上失控"——那"0中断"就不是可选项，而是入场券。

想清楚这个问题的项目，选型不会做错。

标签：无人车 | 远程驾驶 | 5G通讯 | 双链路冗余 | TBOX | 方案选型

❤️文末福利❤️

1、关注擎天柱工坊领取原理图、PCB、学习视频
2、私信发送消息汽车电子硬件设计或者RK3576硬件设计或者RK3568硬件设计或者RK3588硬件设计