底层拆解：时频资源里的“针线活”
说实话，这几年物联网技术我没少折腾。LoRa、Sigfox、NB-IoT……都被吹得天花乱坠。但真正让我拍大腿说“这到底是给机器设计的玩意儿”的，还是NB-IoT。别的技术都在跟Wi-Fi抢频段，它倒好，直接缩在授权频谱里慢慢啃。所以今天我打算把NB-IoT的物理层算法拆开揉碎了讲，顺带聊聊我们当年踩过的那些坑。
先来看一个事，NB-IoT凭什么能在信号差到离谱的地方工作？因为它在物理层做了一件很“笨”的事——重复。把同样一个数据块，用相同的子载波反复传几十次。这听起来像小学生答题不会就多写几遍，但工程上这叫“分集合并”。基站端硬是把这些噪声里的碎片拼起来，解调门限往下拉了一大截。
举个例子，一场演唱会，舞台离你两百米，你听不清楚歌手唱什么。但如果你拿录音笔录了十分钟，回去反复放，是不是能听个大概？NB-IoT就是这么干的。它把单次传输的可靠性，换成了时间上的冗余。你别嫌它慢，它在乎的是能到不能到。
它下行用OFDMA，子载波15kHz，跟LTE一样。上行就野了，单音和双音两种模式，子载波间隔可以是15kHz，也可以是3.75kHz。尤其是3.75kHz那个，符号拉长到四倍，抗衰落能力直接靠时域拉伸换回来了。
在标准模型里，NB-IoT的最大耦合损耗（MCL）能做到164dB，比GPRS的144dB高出整整20dB。20dB是什么概念？信号功率差了100倍。也就是说，GPRS在墙根底下就没辙了，NB-IoT还能钻地下室。
还有它的随机接入过程，NPRACH那边可不是闹着玩的。小区里成千上万个智能水表同时上报，怎么避免挤成一锅粥？它用了一种带频率跳变的单音前导，每个设备在发起接入时都随机挑一个起始子载波，然后按固定的伪随机序列跳频。这种设计让碰撞概率压到极低，同一个小区挂上去5万个终端也不至于瘫痪。
[IMG_NB-IoT覆盖增强重复传输时隙示意图]
数据说话：压测案例里的真实差距
光讲理论没意思，说个我们去年做的压测。地点是南方某个老小区，表井都在地下三米，井盖还是铸铁的。我们分了两组，300个水表用NB-IoT，200个用GPRS。跑了一个月，GPRS那组，每天凌晨上报高峰时期，成功率掉到67.8%，经常出现“信息已发送”但服务器没收到的情况。NB-IoT那组，成功率稳在99.4%。
你可能觉得是基站密度问题。不对。我们当时就在同一个基站下测试，GPRS那边信号显示两格，但就是传不上去。原因在于GPRS的上行功率是固定上限的，而且没有重传机制？其实GPRS也有重传，但只是链路层的，物理层没有反复增强。NB-IoT这里，基站会指示终端把同一个传输块重复传32次，在时域上做硬合并。数据到了基站后，信噪比被拉高了6dB。这6dB，就是99.4%和67.8%的差距。
再说功耗。我们实测NB-IoT模组在PSM状态下，静态电流是3.2微安，而GPRS即使待机也要2毫安。差了三个数量级。换句话说，同样的一块3.6Ah电池，GPRS水表撑不过一年，NB-IoT水表能跑六年以上。这还没算上每天上报的数据量。
[IMG_NB-IoT水表抄表数据对比曲线图]
安装调试中的三个暗坑，以及治它们的药
第一个坑：重复次数不是越大越好。
我们当时一上来就把每次上报的重复次数设成了256次，想着信号再差也能传出去。结果呢？平均时延飙到20多秒，一块电池几个月就没电了。后来才明白，重复次数是给物理层做合并增益的，但每重复一次，时频资源占用就多一次。正确做法是先用终端上报的RSRP自动映射覆盖等级，再按等级设定重复次数。测试下来，CE0用1次就够，CE1用8次，CE2最高也就128次。我们后来优化成动态调整，功耗直接降了40%。
第二个坑，很多人为了省电，把eDRX调到最大，然后设备就“失踪”了。服务器推送个开关阀指令，等了十分钟才送达，气死人。我们后来改成，上行主动上报时用PSM，下行即时控制时用eDRX，周期设成10秒，发现既省电又不耽误事。关键是别一刀切。
第三个坑，是设备被核心网反复“踢下线”。一开始我们以为是工地信号问题，后来用抓包工具一看，是T3324定时器。有些运营商的核心网默认值特别短，终端刚进PSM就被释放了，过一会又要重新附着。那电量全耗在信令上了。解决方案也很土，在模组出厂前，写一套AT指令把eDRX参数固定死，再让运营商对应用户的APN启用扩展寻呼周期。这几行代码，看起来不起眼，一个月能省下30%的功耗。
说回NB-IoT本身，它不是什么神丹妙药。它速率低、时延大，但它在固定、低功耗、海量连接这些细分场景里，确实有着不可替代的位置。如果你要做一个地下管网的监测系统，或者漫山遍野的牛马定位，NB-IoT大概率是你最省心的选择。前提是，你得懂它的脾气。
