NB-IoT从原理到实践：覆盖、功耗、选型与调试指南

第一次在项目会上听到 NB-IoT 这组词时，我脑子里闪过的是“NB”两个字，以为这是一项出门就能用、信号永远满格的黑科技。真正开始调模组、抓空口日志、跑弱覆盖场景之后，才意识到 NB-IoT 之所以叫窄带物联网，恰恰是因为它“窄”。正是这种窄，换来了广覆盖、低成本、低功耗三项核心特性。这篇文章不是从 3GPP 协议里抄定义，而是把我这些年做 NB-IoT 产品时用到的知识框架和踩过的坑整理成一条线，适合正在做模组选型、方案设计，或者已经在写 AT 指令调试的朋友。下面这些内容会直接关系到你怎么看资料、怎么调参数，以及怎么向老板解释“为什么设备在车库上报不了数据”。

1. 先弄清楚 NB-IoT 是被谁“逼”出来的

1.1 传统蜂窝网做物联网，差在哪

十几年前物联网设备要联网，能选的蜂窝方案基本就是 GSM 模块，比如很多老式电表、车载定位器用的都是 2G 模组。GSM 的好处是网络覆盖好、模块便宜，但缺点同样明显：工业级模块价格虽然被压下来了，可是它承载的数据能力非常弱，传输速率低，功耗也压不下去。更难处理的是，2G 频段在不少地方已经进入清频退网流程，继续基于 2G 做“长寿命”终端，本身就是一件很冒险的事。把目光转向 3G/4G 模组，速率倒是够了，代价是模块成本、资费成本和功耗同时上去。对一个一年只上报几百 KB 数据的水表或烟感来说，用 4G Cat.4 模组就是在用大炮打蚊子，没几个人算得过这笔账。

物联网设备的需求和手机完全不一样。手机要的是大带宽、低时延、频繁交互，物联网终端多数时候只要很小的报文，却能容忍几秒甚至十几秒的延迟。它们还经常埋在电井里、楼道配电箱里、停在户外的地磁下面，这些位置对普通 4G 信号来说就是“盲区中的盲区”。所以真正被需要的，是一种新网络：覆盖能力远超传统蜂窝，终端模组便宜，功耗低到用两节电池撑五六年，同时又能利用已经建好的蜂窝基站，而不是让客户自己去重新铺一套网络。这个诉求，技术圈叫 LPWAN。NB-IoT 就是 3GPP 在 Release 13 里为这种诉求给出的蜂窝方案之一。

1.2 NB-IoT 定义的典型业务模型

NB-IoT 从标准立项第一天起，瞄准的就不是“什么都能干”，而是“专门干好一类事”。这类事的特点是：小数据包、低频次、海量连接、对时延不敏感。拿智能水表举例，一个表每天或者每周上报一次累计用量，一次数据量可能就是一百字节左右。拿市政路灯来说，控制指令偶尔下发一次，几十字节已经足够。拿消防烟感来说，平时可能几个月都不发一次数据，只有火警发生时才需要立刻上报。

这些场景合在一起，形成了 NB-IoT 设计时的三个硬指标。第一是广深覆盖，要求能穿一层甚至两层楼板，能覆盖到地下车库和管道井；第二是海量连接，一个小区要能容纳数万个终端而不是过载；第三是低功耗，大多数终端要用电池供电运行五年到十年。这些指标直接决定了它在物理层上如何工作，也决定了我们后续调参时遇到的各种约束。搞清楚这个业务模型，再回头看“NB-IoT 为什么速率这么低”“为什么不能打电话”“为什么不支持小区切换”，答案就非常自然了：标准在写第一行时就已经做了取舍。

2. 180kHz 窄带和 164dB 覆盖：物理层的那本账

2.1 为什么削窄带宽能换覆盖

NB-IoT 用的是 180kHz 系统带宽，这个数字不是随便定的，它对应 LTE 系统里的一个资源块（Physical Resource Block）宽度。这样设计有一个好处：在 LTE 同频部署时，NB-IoT 可以直接借用 LTE 的某个资源块，底层的频谱管理和射频硬件事务处理可以复用成熟方案。

窄带宽带来的直接收益是接收灵敏度提升。从噪声角度看，信道带宽越窄，带内噪声总量越小，基带接收机在一定编码增益下能解调的信号门限就越低。日常工程里，我们看到 NB-IoT 模组的接收灵敏度普遍能做到 -125dBm 到 -135dBm，同步增强模式下甚至更低。这个数字和 Wi-Fi 那种 -90dBm 左右的灵敏度相比，不是一个量级。从发射角度看，NB-IoT 终端把有限的功率集中在很小的带宽上发射，功率谱密度明显高于宽带系统。就好比同一束水，用一个粗水管和一根细水管去冲目标，细水管的水流更有穿透力。蜂窝行业把这套账量化成一个指标：最大耦合损耗（MCL，Maximum Coupling Loss），NB-IoT 的设计目标做到了 164dB。作为对比，传统 LTE 的覆盖能力一般在 142.7dB 左右，AMR 语音和 GPRS 数据也就 144dB 上下。也就是说 NB-IoT 比 LTE 多赢得了 20dB 左右的覆盖余量，这 20dB 在无线传播里意味着能多穿透一两堵混凝土墙，或者从地面基站打到地下十几米的空间。

2.2 覆盖增强不是白来的：重传与低阶调制

多出来的这 20dB 覆盖增益，不可能靠物理层奇迹白拿。NB-IoT 用了一个看起来很“笨”但实际上很有效的策略：重复传输。终端在差信号条件下反复把同一个数据包发很多遍，接收端把多次接收到的信号在时间上做累积合并，等效信噪比就抬上来了。上行数据可以重复发送 1 次到 128 次，下行寻呼和系统消息的重复次数则更多，极端情况下可以重复几百上千次。

这里必须泼一盆冷水：重复传输是拿时间换覆盖，代价是峰值速率和频谱效率急剧下降。调制方式也能说明问题。NB-IoT 上行支持单音（single-tone）和多音（multi-tone）两种发射方式。单音模式下子载波间隔可以是 15kHz 或 3.75kHz，调制阶数最高到 QPSK，一次能传的比特数非常有限。所以 NB-IoT 的理论峰值下行速率大约在 250kbps 左右，上行单音模式下通常只有 20kbps 上下，多音模式能高一些，但实际项目里跑几十 kbps 已经算不错了。看到这个速率，就不要再拿它跟 4G 比网速了，它本来就不是干这个用的。理解重传机制之后，很多现场问题就能解释得通：在弱覆盖区域，一个几百字节的上行报文，可能需要好几秒才能发完，因为大量时间都花在重传和系统消息读取上了。

2.3 PSM 与 eDRX 到底是怎样省电的

低功耗是 NB-IoT 的另一张王牌，而这张王牌主要由两个状态机机制支撑：PSM（Power Saving Mode）和 eDRX（Extended Discontinuous Reception）。

PSM 的省电思路很直接：终端完成注册和数据上报后，可以主动向网络申请进入深睡状态。深睡状态下，终端的接收机基本关闭，不再监听任何寻呼消息，核心网也知道这个终端暂时“叫不醒”，有下行数据就先缓存住，等终端下次主动醒来再补发。这个状态下的待机电流可以压到微安级，很多模组的 PSM 静态电流能做到 3μA 左右。代价是下行数据时延会很大，网络侧无法随时主动联系终端，你给设备发一条控制指令，可能要等它自己按照 TAU 周期醒来才能收到。

eDRX 是另一种折中方案。它不像 PSM 那样完全关闭接收机，而是让终端每隔一个较长的周期醒来一小段窗口监听寻呼。可以理解成一个人睡觉时每隔几个小时定个闹钟醒来扫一眼门口有没有人找，然后继续睡。eDRX 的周期比传统 LTE DRX 长得多，NB-IoT 场景下可以配置到分钟级甚至小时级量级，上行功耗比 PSM 高，但下行可达性和实时性比 PSM 好一些。

实际项目中，这两个机制的参数：激活定时器 T3324、TAU 周期 T3412、eDRX 周期值，都需要和运营商核心网配置配合。有些终端侧配置了 PSM，核心网没开启对应能力，终端会发现自己永远进不了深睡，功耗直接翻几倍。这是我最常建议团队在实验室就先验证的项目之一，不要等装到现场再掐着电流表崩溃。

3. 部署方式：三种频段选择决定了什么

3.1 In-band、Guard-band、Standalone 怎么选

NB-IoT 的部署方式有三种，和很多人理解的“随便找个空闲频率放上去”完全不一样。第一是 Standalone（独立部署），通常是运营商把已有的 GSM 频段重耕出来，独占一段频谱来部署 NB-IoT。这种方式不受 LTE 资源块结构限制，干扰可控，性能也最容易预测。国内不少省市的 NB-IoT 网络就是通过这种方式在 900MHz 附近低频段上铺开的，低频传播损耗小，绕射能力强，非常适合广覆盖。

第二是 In-band（带内部署），NB-IoT 直接占用 LTE 系统内的一个资源块。这种方案的好处是不用额外找频段，坏处是 NB-IoT 必须避开 LTE 的同步信号和控制信道区域，而且 PDSCH/PDCCH 的调度要反复让路，吞吐率还有邻频干扰都会打折扣。第三是 Guard-band（保护带部署），部署在 LTE 频带边缘的保护间隔里。保护带本来就是为了防止不同系统之间干扰而预留的，空间比较干净，但可用带宽不多，网络扩容能力受限。

三者对比，Standalone 覆盖性能最优，In-band 部署最灵活，Guard-band 处于中间位置。但作为终端设备开发方，我们对部署方式能做的选择其实很少，网络是运营商已经建好的。我们真正要关注的，是你所购买的模组固件和射频前端是否支持对应频段和部署模式，以及在不同部署模式下，服务小区的频点、测量量和小区重选行为是否有差异。经常有朋友拿了海外版模组回国测试，发现收不到信号，就是因为频段支持不对。

3.2 频段与天线设计的影响

NB-IoT 目前主要工作在低频段和中频段，常见的如 800MHz、900MHz 和 1800MHz 附近。低频波长的物理特性决定了它在城市环境里穿墙效果更好，所以大多数运营商做主城区覆盖时会优先考虑低频重耕。这也反过来要求终端的天线设计尽量做在对应频段上，而不是随便拿一根 2.4GHz 天线替代。

终端天线的调试有一个容易被低估的点：NB-IoT 设备常常装在金属外壳或者狭小空间里，比如水表井中的金属表箱、电动车里的控制盒。金属环境会严重降低天线辐射效率，驻波比看着还行，实际辐射出去的能量却少得可怜。我遇到过一块 NB-IoT 地磁检测器，放在测试台上信号满格，装进路边车位铁壳里之后附着都困难。后来把天线移出来贴着非金属面，并且调整了匹配电路，才恢复正常。这个经验是：做 NB-IoT 产品时，天线测试不能只在阳光明媚的办公桌上做，一定要放进最终外壳、最终安装位置、最终安装姿态下测，否则老实用 -10dB 的驻波比也是白搭。

4. 选型不能只看 NB-IoT：和 LoRa、LTE-M 放在一起比

4.1 NB-IoT 对比 LoRa：授权频谱与非授权频谱之争

做物联网方案选型时，最经常被拿出来和 NB-IoT 对比的就是 LoRa。两者都是低功耗广域网技术，但底层哲学完全不同。LoRa 工作在免授权频段，任何组织都可以自己搭建基站和网络，组网灵活、数据私有性强、没有蜂窝资费，特别适合厂区、园区、农场、仓库这些边界清晰的封闭场景。NB-IoT 工作在运营商授权蜂窝频段，网络侧不需要用户操心，但数据会经过运营商核心网，方案天然带有“租用网络”的属性。

从覆盖指标看，NB-IoT 设计的 164dB 最大耦合损耗和 LoRa 在低速扩频因子下的链路预算相差不多，但蜂窝网络有成熟的基站回传、干扰管理、安全鉴权体系，这些是自建 LoRa 网络很难复制的。反过来，LoRa 的部署成本模型极其简单，尤其适合在偏远地区或者用户不想依赖运营商网络覆盖的现场。所以两者不是谁取代谁的关系。我看到很多企业内部定了一个“伪规则”，说凡是低功耗物联网一律用 LoRa，凡是蜂窝网络一律用 NB-IoT，这种一刀切做法会在项目里栽跟头。正确姿势是先看项目边界：网络归谁建？数据出不出园区？资费谁承担？运维和覆盖责任在谁？答案不一样，选型就完全不一样。

4.2 NB-IoT 对比 LTE-M/Cat.1：什么时候不该硬选 NB-IoT

蜂窝低功耗方案里，还有两个和 NB-IoT 经常分不清的兄弟：LTE-M 和 Cat.1。LTE-M 也是 3GPP R13 推出的物联网标准，带宽 1.4MHz，在覆盖增强、低功耗方面做得也不错，而且因为带宽更大，速率更高，还支持基站间移动切换和 VoLTE 语音能力。NB-IoT 在 R13 里基本不考虑移动性，设计上更多是针对“固定或低速移动”的终端。如果你的产品是共享单车、便携式穿戴设备、老人定位器这种会频繁跨小区移动，甚至需要实时语音通话的设备，硬选 NB-IoT 会非常痛苦。

Cat.1 则是另外一条路线，本质上是 LTE 的低速率子集，不用支持高阶 MIMO 和载波聚合，芯片和模组成本低于 Cat.4，但速率和功耗又远高于 NB-IoT。这几年在共享单车、云打印机、视频监控等领域，Cat.1 模块的使用量增长很快，一个重要原因是它无缝复用了现有 4G 网络，不需要运营商专门为物联网部署，也比 NB-IoT 更容易支撑固件远程升级包。做产品选型时，要先把“是一天一报的数据”还是“随时可能在线的视频流”分清楚，再决定拉 NB-IoT 出来还是拉 Cat.1 出来。

4.3 一张选型决策表

这张表不是让你记住了直接抄，而是可以在写方案时当 check list 用。每个格子背后都对应一种产品体验和成本结构，换一个场景可能结论就反转。

5. 真正上手做项目后才会遇到的事

5.1 模组选型与入网认证

NB-IoT 模组本身看着很小，但选型要考虑的点并不少。第一是芯片平台和固件成熟度，有些模块厂商的 AT 指令集不是完全标准的，换了平台之后，原来那套指令要重新适配。第二是固件对 R14/R15 新特性的支持情况，比如更高的下行速率、增强的定位能力、更细的省电参数，这些特性必须在规格书里逐条核对，不能只看“支持 NB-IoT”五个字。第三是运营商的型号入库和认证清单。一个没有在运营商现网库存档的型号，就算硬件支持，也可能在附着阶段被网络拒绝。做项目之前，先让模组厂商把对应网络侧的兼容性测试报告发来，能省一大轮踩坑时间。

还有认证这关。在不少行业里，NB-IoT 终端需要做无线电型号核准、入网许可，行业客户还可能要求从生产一致性、电磁兼容到高低温、防水防尘整套测试。这些测试周期长，费用也不低，但绝不能压缩。我见过一个项目为了赶工期，把高低温测试砍了，结果冬天北方批量安装以后，每天凌晨设备批量掉线，最后查下来就是因为部分器件低温性能不达标。省了测试费，赔了售后费，这笔账非常不划算。

5.2 功耗估算：理论值到实测数据

NB-IoT 终端的功耗需要按状态逐段计算。一次完整的数据上报过程通常包括：模组开机搜索网络、附着网络、建立数据连接、发送数据、接收响应、进入 PSM 深睡。每个阶段的电流和时间不同，要分开测量。典型的数据点大概是：发射峰值电流可以到 200mA 以上，接收和系统运行电流几十毫安，PSM 待机电流则能降到 3μA 左右。我们做一个很粗略的算术：假设设备每天上报一次，每次秒级连接，平均电流 50mA，持续时间 3 秒，那单次上报消耗约 0.04mAh；PSM 待机 24 小时按 3μA 算，消耗约 0.072mAh。一年下来约 40mAh。这个量级下，一个几千毫安时的锂电池确实可以用很多年。

但这里有个大陷阱：计算前提是网络环境足够好，终端能用最少的重传把数据发出去。一旦设备处于网络边缘或者干扰严重的位置，重传次数从 2 次变成 32 次，单次上报时间从 3 秒变成 60 秒，功耗立刻放大几十倍。更隐蔽的是，有些模组在弱覆盖下会反复做小区重选、系统消息读取，这些不适合计入规格书“典型待机电流”的功号。所以功耗验证一定要在真实网络覆盖的最差位置做，而不是在实验室里关在屏蔽箱外测一遍就签收。我个人习惯是同一个设备准备三台，分别在强覆盖点、中等覆盖点和弱覆盖点跑一周，抓每台每天的等效平均电流，拿这组数据去倒推电池容量，而不是直接买最贵的电池赌它不出问题。

5.3 现场调试常用的“土办法”

NB-IoT 现场调试没有太多绣花功夫，最常用的是三类手段。第一类是模组自带的 AT 指令，比如用 AT+CSQ 看信号强度，用 AT+CEREG? 看网络注册状态，用 AT+CESQ 看 RSRP 和信噪比。这里必须提醒一点：CSQ 返回的是 RSSI，不是完整覆盖质量的唯一标准。实际项目中 RSRP 很好但 SINR 很差的情况非常多，尤其是旁边的 LTE 网络干扰较大时。只看 CSQ 数值，会导致你以为信号“满格”，实际业务却一直失败。第二类是运营商网优工具或频谱分析仪。如果设备装完之后经常掉线，现场拿频谱仪扫一下信道占用，看一下底噪和邻区干扰，比盲目换模组更有效。第三类是抓空口日志。用模组厂商提供的日志工具抓一下 RRC 层和 NAS 层消息，能直接看到附着被拒绝的协议原因值，很多问题到这一步就真相大白了。

5.4 APN、核心网优化和数据协议选择

NB-IoT 的通信不仅是终端和基站之间的事。终端要完成附着，必须在 SIM 卡里配置正确的 APN 和鉴权参数。APN 配错，终端可能能搜到小区，但永远附着不上。不少 NB-IoT 平台还支持 PSM 和 eDRX 的签约配置，这些参数既可能写在 SIM 卡里，也可能在核心网侧配置，终端侧的 AT 指令配置只是请求，最终是否生效要看网络侧应答。

数据面可以简单分两条路。一条是传统的用户面优化，数据通过模组建立 PDN 连接、走 IP 通道发到业务平台；另一条是控制面优化，也就是把用户数据封装在 NAS 信令里直接通过核心网控制面传到平台，这对小报文场景特别有效，省去了建立 DRB 数据无线承载的时间，终端可以更快回到休眠状态，进一步省电。还有 NIDD 非 IP 数据传递，终端不发 IP 包，而是直接和平台交换数据，省掉 IP 栈的开销。这些优化好不好用，取决于运营商核心网和终端固件是否都支持，选模组时记得和厂商确认 R14 以后的控制面优化支持情况。

6. 踩坑记录：掉线、假死和收不到下行

6.1 附着失败的整套排查链路

有一次我在现场调一批 NB-IoT 设备，现象是 30% 的终端一直附着不上，另外 70% 完全正常。刚开始我怀疑是设备硬件差异，后来逐台排查发现，失败设备的 IMEI 不在运营商的白名单库里。这批设备是另一条产品线的库存，模组型号相同，但整机 IMEI 没有被录入当前运营商的物联网管理平台，网络侧直接回绝了附着请求。这类问题在网络侧是查不到终端日志的，只能在平台侧按 IMEI 检索才能发现，非常隐蔽。

遇到附着失败，我通常按这个顺序排查，也可以分享给各位当模板：

1. 用 AT+CIMI 确认 SIM 卡能被模组读取，排除卡座接触问题。
2. 用 AT+CSQ 确认终端能看到小区信号，排除天线和频段问题。
3. 用 AT+COPS? 或 AT+COPS=0 触发网络搜索，确认是否能注册到 NB-IoT 网络。
4. 用 AT+CEREG? 查询注册状态和拒绝原因值，比如 cause 7 表示 EPS 服务不允许。
5. 把模组日志导出来，看 NAS 层的 Attach Reject 原因，再到运营商平台核对 IMEI 白名单、APN 签约、套餐状态。

这套链路走完，九成附着问题都能定位到。再剩下的那种，基本就要怀疑核心网配置或现场干扰了。

6.2 长时间待机后模组“假死”

NB-IoT 模组进入 PSM 深睡后，有些场景下会出现“叫不醒”的情况。表现形式是终端外接主控通过串口发 AT 指令，模组毫无反应，跟死机了一样。更麻烦的是，这种状态不是每次都复现，可能运行半个月才出现一次，定位难度很大。我的处理经验是先从硬件找原因。因为 PSM 下模组主电源还在，如果电源设计纹波偏大，深睡低负载和醒来高负载切换瞬间产生压降，会把模组内部电压拉低到复位门限附近，导致模组进入一种“半复位、半运行”的异常态。解决方式是给模组电源加稳压和足够的去耦电容，必要时用独立的 LDO 给模组供电，避免和电机、蜂鸣器这些负载抢电流。

软件层面也要做兜底。模组厂商的 AT 指令集里通常有查询模块工作状态或者软复位的手段，但终端主控不能完全依赖它。更稳妥的做法是在外部主控上加看门狗，规定一个最长响应时间，比如模组在 30 秒内不响应 AT 指令，主控就执行一次完整的电源断电重启。这项功能在我的项目里是必做的，因为蜂窝模组再成熟，长时间处于网络极端环境下谁也没法保证协议栈永远干净。

6.3 下行数据延迟与边坪效应：eDRX 的意外放大

下行延迟是 NB-IoT 项目里最容易引发客户投诉的点。很多业务平台默认要求“下发指令后 10 秒内设备有响应”，但终端如果配置了较长的 eDRX 周期或者 PSM，它可能处于“网络知道它在哪里但暂时叫不醒”的状态。下行指令到了核心网，网络侧只能先把数据缓存，等终端按 eDRX 周期醒来再寻呼，或者等 PSM 醒来做 TAU 更新时再补发。于是你看到的现象就是指令发出去了，设备过了几分钟甚至几十分钟才有反应。这不一定意味着终端故障，要看你当初给终端配置的是 PSM 还是 eDRX，以及参数为什么设置成那个值。

所以做业务需求的时候，必须先把“允许的最大下行时延”这条需求界定清楚。对路灯控制、阀门开关这类实时性要求高的场景，宁可牺牲一点功耗，也要把 eDRX 周期配短，或者干脆用 PSM 之外的空闲态监听。对水表、电表这种只做周期上报的设备，下行本来就很少，配置成 PSM 反而更合适。不要把 PS 平台性能问题甩锅给 NB-IoT 网络，很可能是你一开始就选了不适合业务的省电模式。

7. NB-IoT 在向后演进：从 R14 到 5G 时代

7.1 R14/R15 带来了什么

NB-IoT 不是停留在 2016 年的静态技术。R14 引入了一些很实际的能力，比较受关注的是上行多频传输，让终端可以同时占用多个资源块上传数据，把峰值速率明显拉高；还加入了 OTDOA 和 E-CID 定位方案，让 NB-IoT 在物流追踪和资产管理场景里多了一些可行性；对移动性的支持也有改善，虽然还不能跟 LTE-M 完全看齐，但已经能支撑低速移动的终端做跨小区重选。

到了 R15，NB-IoT 进一步做了功耗和时延的优化，比如 RRC 连接暂停/恢复机制，终端在已经没有数据要传时不是完全释放连接，而是保留上下文进入类似“挂起”的状态，下次恢复时能更快回到在线状态。这种机制对小报文频繁交互的场景帮助明显，同时还引入了更灵活的系统消息调度，提升频谱利用效率。做产品规划时，可以关注模块固件是否支持这些新特性，一个支持 R15 的模组和一个只支持 R13 初始版本的模组，在同样网络环境下跑出来的功耗和时延表现差别可能很大。

7.2 5G 时代 NB-IoT 的定位与 Cat.1bis 的承接

很多人问 NB-IoT 是不是快过时了，这个问题我一般反过来答：NB-IoT 已经被 5G 标准明确列为 mMTC 场景的组成部分，它在未来的蜂窝物联网体系里会继续存在，而不是被 5G 智能手机网络消灭。物联网里海量低速小包的需求没有消失，NB-IoT 就是当前解决这类需求最成熟的大规模网络方案之一。5G 新空口虽然能力更强，但对电池供电的海量终端来说，摩尔定律还没法把成本和功耗压到 NB-IoT 这个水平。

同时也要留意 Cat.1bis 这类“平替”方案。Cat.1bis 用单天线替代传统 Cat.1 的双天线，把成本和体积降下来，又能复用完整 4G 网络，速率和实时性都比 NB-IoT 好。未来一段时间会出现的格局是：NB-IoT 负责千万级超低功耗小数据连接，LTE-M/Cat.1bis 负责需要一定速率和移动性的连接，高速大流量继续由 Cat.4/Cat.6 和 5G eMBB 承担。选型时不要把一种技术当成万能答案，把业务需求拆开，按功耗、时延、移动性、成本四象限去匹配，才是长期有效的思路。

最后说一点个人感触。做 NB-IoT 相关项目这几年，我最大的体会是，这行没有玄学，所有的“不稳定”背后都有一个具体的技术原因，要么是网络参数没对齐，要么是功耗模型建错了，要么是天线在真实安装环境里被外壳坑了。把物理层机制弄明白，把现场测试做扎实，很多看起来莫名其妙的问题都能提前死在实验室里。如果你刚开始接触 NB-IoT，建议拿一块支持的模组，配一个带实时电流采集的开发板，在实验室里先把 PSM 和 eDRX 的完整状态切换跑一遍。这一步做完，你对 NB-IoT 的理解会超过一半只会看规格书的同行。