2. NB-IoT网络架构：核心网、接入网、终端设备、云平台的关系
好，咱们今天聊聊NB-IoT的骨架——网络架构。
很多初学者一上来就被各种网元名字搞晕了。什么MME、SGW、HSS，听着像天书。其实没那么复杂。我习惯把NB-IoT网络拆成四块来看：终端设备、接入网、核心网、云平台。说白了，就是数据从传感器出发，一路跑到你手机App后台的完整路径。
2.1 四层架构，各司其职
先给个全景图。这四层的关系，我画个简单的比喻：
- 终端设备（UE）：就是那个采集温度、湿度、水表读数的传感器节点。它负责把物理世界的信号变成数字信号。
- 接入网（E-UTRAN）：基站那一套东西。终端把数据发出来，基站负责收。相当于快递员上门取件。
- 核心网（EPC）：处理数据、鉴权、计费、路由。相当于快递中转站和分拣中心。
- 云平台（IoT Platform）：数据最终落地的应用服务器。你写个Web页面，或者手机App，就是从这儿拿数据。
嗯，这里要注意：NB-IoT的接入网和核心网，其实是在4G LTE的基础上做了瘦身。为什么？因为NB-IoT设备数量巨大，但每个设备的数据量极小，而且对时延不敏感。你想想看，一个水表一天上报一次数据，需要那么高的带宽吗？不需要。
2.2 终端设备：那个不起眼的“小东西”
终端设备，就是我们常说的NB-IoT模组。比如移远的BC95、BC26，或者华为的Boudica系列。我最早接触NB-IoT时，用的是BC95-B8，那会儿模组还比较贵，一颗要几十块。现在便宜多了。
终端设备的核心工作就三件事：
- 采集数据：通过ADC、I2C、SPI等接口读取传感器数值。
- 封装数据：按照CoAP或UDP协议，把数据打包成报文。
- 发送数据：通过AT指令控制模组，把报文发出去。
我曾经在一个项目中遇到过终端设备频繁掉线的问题。排查了半天，发现是模组的PSM（省电模式）参数没配好。设备进入深度睡眠后，基站以为它离线了。后来我调整了TAU（跟踪区更新）周期，问题就解决了。避坑指南：PSM和eDRX的配置，一定要和运营商协商好，否则设备会莫名其妙失联。
2.3 接入网：基站与空口
接入网，说白了就是基站。NB-IoT的基站和普通4G基站共用硬件，但软件上做了优化。它支持三种部署方式：
| 部署方式 | 说明 | 我个人的看法 |
|---|---|---|
| 独立部署 | 占用独立频段，不依赖LTE | 适合新建网络，但频谱资源稀缺 |
| 保护带部署 | 利用LTE频段边缘的保护带 | 资源利用率高，但干扰控制要小心 |
| 带内部署 | 在LTE频段内分配一个PRB | 最常见，运营商最喜欢这种方式 |
接入网的关键指标是覆盖等级。NB-IoT设计了三个覆盖等级（CE0、CE1、CE2），分别对应不同的信号强度。我建议你在做产品时，一定要测试CE2下的性能。因为很多NB-IoT设备安装在地下室、水表井里，信号极差。CE2模式下，基站会重复发送数据，最多重复2048次，确保数据能传上来。
重要提示：NB-IoT的MCL（最大耦合损耗）可以达到164dB，比GPRS强了20dB。这意味着什么？意味着一个井盖盖着，数据照样能出来。但代价是速率极低，下行峰值才250kbps，上行峰值才250kbps。别指望用它传图片或视频。
2.4 核心网：数据的中转站
核心网，是NB-IoT网络的大脑。它由几个关键网元组成：
- MME（移动性管理实体）：负责鉴权、位置管理、寻呼。说白了，就是管“你是谁、你在哪”。
- SGW（服务网关）：负责数据包的路由和转发。终端发上来的数据，先到SGW。
- PGW（分组数据网关）：连接外部网络，比如互联网或云平台。数据从SGW到PGW，然后出网。
- HSS（归属签约用户服务器）：存用户信息，比如IMSI、密钥。鉴权时用。
核心网里有个特殊的东西叫SCEF（服务能力开放功能）。这是NB-IoT特有的。为什么需要它？因为NB-IoT设备经常处于休眠状态，云平台想主动下发指令，设备却睡着了。SCEF提供了一种非IP数据通道，可以通过控制面信令来传小数据。我建议你如果做下行控制（比如远程开关阀门），一定要了解SCEF的用法。
我记得有一次调试，云平台下发指令，设备死活收不到。查了三天，发现是核心网的SCEF配置没开。运营商那边默认关闭了这个功能，需要单独申请开通。嗯，这个坑我替你们踩过了。
2.5 云平台：数据最终的家
云平台，就是数据落地的服务器。常见的平台有：
- 华为云IoT
- 阿里云IoT
- 腾讯云IoT
- OneNET（中国移动）
- AWS IoT Core
云平台做的事情很简单：接收设备上报的数据，解析协议，存储到数据库，然后提供API给应用层调用。但这里有个关键点——协议转换。
NB-IoT设备通常使用CoAP协议，而云平台内部通常用MQTT或HTTP。所以云平台需要做一层协议转换。我建议你在选型时，优先选择原生支持CoAP的云平台，否则中间加一层协议转换，会增加延迟和丢包风险。
技巧：如果你自己搭建云平台，可以用Node.js写一个CoAP服务器。libcoap库很好用。设备端用AT+NMGS指令发送数据，服务器端用CoAP的POST方法接收。数据格式建议用JSON或CBOR，CBOR更省流量。
2.6 数据流：从传感器到App
咱们走一遍完整的数据流，你就全明白了：
- 传感器采集：温度传感器读到25.3°C，通过I2C传给MCU。
- MCU封装：MCU把数据打包成CoAP报文，格式为
{“temp”:25.3}。 - 模组发送：MCU通过AT指令
AT+NMGS=5,7B2274656D703A32352E337D，把数据发给模组。 - 空口传输：模组通过NB-IoT空口，把数据发给基站。
- 基站转发：基站把数据通过S1接口，发给核心网的SGW。
- 核心网处理：SGW把数据转发给PGW，PGW根据目标IP，把数据路由到云平台。
- 云平台解析：云平台收到CoAP报文，解析出温度值，存入数据库。
- App展示：你的手机App调用云平台API，拿到温度数据，显示在界面上。
整个过程，从传感器到App，延迟通常在1-3秒。如果设备处于PSM休眠状态，延迟可能达到几分钟，因为要等设备醒来才能下发数据。
警告：千万不要在NB-IoT网络上做实时控制！它的设计初衷就是非实时、小数据量。如果你需要毫秒级响应，请用Wi-Fi或5G。我曾经见过有人用NB-IoT做智能门锁的实时开锁，结果门锁响应延迟了10秒，用户体验极差。
2.7 总结一下
NB-IoT的四层架构，说白了就是一条数据管道。终端负责采集，接入网负责传输，核心网负责路由，云平台负责存储和展示。每一层都有它的设计约束和优化点。
我个人习惯在做项目时，先画一张网络拓扑图，把每一层的网元、接口、协议都标清楚。然后针对每一层做测试：终端测功耗和覆盖，接入网测信号强度和重传次数，核心网测鉴权和数据路由，云平台测协议解析和数据存储。这样分层测试，问题定位会快很多。
好，这一章就到这里。下一章咱们聊聊NB-IoT的AT指令集，手把手教你如何用串口控制模组发数据。到时候我会分享一些我踩过的坑，比如AT指令超时、模组死机怎么处理等等。