6.4 物联网与车联网通信

6.4 物联网与车联网通信

本节摘要：当账本从"人的上网"铺到"万事万物"，链接预算的口径就开始变了。物联网弹的是"海量终端 + 单点低能耗 + 长待机"；车联网弹的是"高速移动 + 极低时延 + 高可靠"。本节把这两类"不同物种"的账分别摊平，再看技术与协议的取舍。

承接 6.1 的 mMTC 与前面的物理层、能效账，本节把"海量又省电"和"快又稳"这两类极致需求，从 5G 一般化到整个物联网与车联网生态的实账。

从"人上网"到"万物记账"，口径先得换

前面几章那套"高吞吐、低时延、强覆盖"的账本，默认服务的是"人上网"这个物种。可一旦接入的东西从手机变成万千的水表、门锁、温湿度计、车载单元，链路预算的口径就得整个重写——你不再追求"一个人快不快"，而要打量"这一片到底有多少台设备、每台怎么熬过一整年、别让它们互相吵起来"。

这种口径的转变，源于服务对象变了。物联网（IoT）端的是三类新的平衡：连接密度（一个小区要同时容纳动辄几十万终端，接入和信令是沉重的盘子）、单点能耗（很多终端用一枚钮扣电池点着，要待机数月到数年，能源预算抠到发指）、单点速率几乎不在乎（一条水表一天报几字节就够了，绝不跟人抢那点宽带）。于是物联网的设计目标，从"哪根比特流更快"彻底转向"哪套方案能养活得下一大片低功耗的设备"。

读懂"口径随物种而换"，是你理解整节的钥匙。它不止提醒你别拿蜂窝的老尺去量物联网，更提醒你：物联网与车联网这两类"不同物种"之间，账目也几乎背道而驰——一个拿着"慢与省"当宝，一个把"快与稳"奉为命根。先弄清你伺候的是哪种物种，再谈该记哪种账，规划才不会满盘皆输。

学习目标

• 说清物联网在连接密度、能耗、时延上的三本特殊账。
• 举出窄带物联等低功耗广域的典型场景与取舍。
• 讲清车联网为何对时延与可靠近乎苛刻，常见协同手段是什么。

物联网：账本从人铺到万事

物联网最大的变化是"接入的东西从手机变成了万千传感器、水表、门锁、监测仪"。由此链路上挂上三本新账：

• 连接密度：一个小区动辄几十万终端要同时登记，接入和信令都是重负。
• 单点能耗：很多终端用钮扣电池点着，要一口气待机数月到数年，能源预算极抠。
• 单点速率不在乎：一条水表上报每天发一次几字节就够，永远不必跟人抢带宽。

这三本账决定了物联网要的不是"峰值速率"，而是"海量、省电、抗命令冲突"。于是有了低功耗广域与窄带物联网这一类专门设计：窄带宽、慢速率、重信令优化，把对单点速率的不讲究，换成对连接密度与待机时长的讲究。

车联网：账本要快又稳到冒汗

车联网（V2X）又是另一种物种：车与车、车与路、车与云端彼此实时交互，要让车能把"前面急刹"这类消息送进"正在行驶的车控决策"里。它的账没什么商量的余地：时延要毫秒级、可靠要近乎百分之百——半秒的延迟或一次丢包，可能就是一次事故。

这么苛刻的账，单条链路预算扛不住，需要多种通信拼盘：车车直连走短距广播（低时延、不依赖基站），车路协同靠路侧设备做"中继和调度"，车云远程走蜂窝再兜底。协同的本质，是让"紧急的近的消息走最近的路、非紧急的云上算"。

把两种账摊成两张对照

物联网与车联网的账差到几乎背道而驰，画在一块对比最清楚。

这张表一句话点破：物联网个别比特丢了可以"明天再报"，车联网一次消息错失可能就是事故。所以两者落在协议与规划上的选择，南辕北辙毫不奇怪。

一次"上报间隔与能耗"的取舍

用一段脚本体会物联网"拉长上报间隔省电"的边际账：

def battery_life(report_sec, battery_j, energy_per_report):
    per_day = 86400 / report_sec
    use_per_day = per_day * energy_per_report
    return battery_j / use_per_day / 365  # 年

for sec in [60, 3600, 6*3600, 86400]:
    years = battery_life(sec, 100, 1)
    print(f"每 {sec:>6} 秒报一次 -> 可选待机约 {years:.1f} 年")
​

输出随间隔拉长明显变好：一小时报一次比一分钟报一次能在同样电池下多撑几十倍。这正是物联网用"慢一点"换"久一点"的账——也解释了低功耗广域为何舍得把速率和时延都放得很宽。

把这两类"不同物种"的账放回全书的主账，你会发现它们其实就是把前面几章学过的那条链路预算，按服务对象重新定义了优先级的两个极端样板：物联网把能耗与连接密度顶到最高优先级，于是要牺牲速率、简化信令、宽容时延；车联网把时延与可靠性顶到最高优先级，于是要动用短距广播、路侧调度与蜂窝兜底的多套手段拼盘。两者并非谁更高级，而是再次印证了第 2.2 章那句"立场决定目标"——不同的物种握着不同的命门，自然会开出性质完全相反的两张账。你在规划、协议选型时，只要先分清"我伺候的是海量省电的万物，还是高速求稳的车辆"，再去翻对应的那本账，就不会再把蜂窝的老尺或物联网的低功耗逻辑用错地方。

最后落一个实操提醒：给物联网选型，别只盯速率，还要盯"接入容量、待机时长、覆盖深度"这几本只有它才重的账；给车联网选型，则别只盯时延，还要把"高可靠与低时延如何兼得"作为一个整体来设计。很多项目之所以翻车，不是技术不够强，而是从一开始就把"服务的对象"认错了——用手机上网那套去衡量一盏智能路灯，或用工业网那套去要求一个停车场的车况传感器。先问清物种，再翻对应的账，往往比堆花哨技术更决定成败。

易踩的坑

常见坑：拿"全覆盖、大带宽"的蜂窝逻辑去套物联网，或拿"低功耗"的物联网逻辑去套车联网。一个苛求密度与续航，一个苛求时延与可靠，套错物种会让规划满盘皆输。

本节要点回顾

• 物联网三账：高密度接入、单点低能耗、速率不在乎。
• 低功耗广域：以宽时延与低速率为代价，换续航与密度。
• 车联网两账：毫秒时延 + 近乎全可靠，靠车车/车路/车云拼盘协同。
• 物种有别：两套账南辕北辙，规划要先分清对象再记账。