9.3 CoAP与LwM2M协议
9.3.1 CoAP协议基础与RESTful映射
在物联网项目中，工程师们经常会反复面对一个成本问题：一个只上报温度的设备，每隔几分钟发几字节数据，为此维持一条TCP长连接并按时发送心跳包，是不是太奢侈了？对于那些部署在偏远位置、靠电池供电、大部分时间只做单向上报的传感器，MQTT的TCP保活和连接建立开销确实有其工程代价。CoAP（Constrained Application Protocol，受限应用协议）的出现，正是为了解决这一矛盾——它把HTTP的请求/响应模型压缩到UDP之上的极紧凑消息内，让资源受限的设备也能以标准的IP协议方式进行通信。
CoAP可被视作HTTP在受限网络上的映射版本。它遵循C/S（客户端/服务器）模式，设备既可以作为客户端发起请求，也可以作为服务器暴露资源。这种模式与MQTT的发布/订阅架构形成了根本性差异：CoAP设备与通信对象之间是直接通信的，不需要Broker作为中间代理。这决定了CoAP更适用于设备与平台之间的一对一数据交互场景。
消息模型：CON与NON
CoAP的传输层基于UDP，但这并不意味着它是一个“发完就不管”的不可靠协议。IETF在RFC 7252中定义了四种消息类型，用于覆盖不同场景下的可靠性需求。在工程中应用最广泛的两种，是CON（Confirmable，需要确认）和NON（Non-confirmable，不需要确认）。
- CON消息：发送方发出一个CON请求后，接收方必须用ACK（Acknowledgment，确认应答）回应。如果发送方在超时后仍未收到ACK，会执行指数退避的重传策略，直到收到应答或超过最大重传次数后放弃。这种机制的确认逻辑与TCP类似，但开销要小得多——确认包本身只是一条最短的CoAP空消息。
- NON消息：发送即可遗忘，接收方不回复ACK，CoAP协议层也不为此提供重传。周期性上报的传感器数据是典型的NON场景：丢掉一个采样值并不会造成严重后果，因为下一轮数据会在几秒或几分钟后自动补上。
- RST消息：当接收方无法处理某个请求，例如无法识别报文中某个选项时，会发送RST（Reset，复位）消息，通知对方终止本次通信。
这一设计让CoAP在同一个端口上实现了“有确认”和“无确认”两种级别的可靠传输。在工程实践中，开发者需要根据数据的关键程度做出选择：告警类消息应使用CON确保到达，而周期性采样使用NON则可大幅降低功耗和网络开销。
RESTful映射
CoAP直接继承了HTTP的REST（Representational State Transfer，表征状态转移）设计理念，支持GET、PUT、POST、DELETE四种请求方法，其语义与HTTP完全一一对应。一个CoAP客户端请求服务器上/temperature资源的当前值时，发出去的报文由 4 字节固定头打头——其中包含一个字节的 Code（GET 请求即 Code 0.01）和两字节的 Message ID——固定头之后是长度为 0–8 字节的 Token（具体长度由固定头中的 TKL 字段指定，典型实现取 4 字节），再往后是携带 URL Path 的选项。整个请求通常几十字节内就能完成。
然而，CoAP的请求/响应模型与HTTP存在一个本质区别：它是异步的。HTTP要求客户端在同一个TCP连接上阻塞等待响应，而CoAP的CON消息携带一个Message ID（消息ID），响应可以通过该ID与请求进行匹配。这意味着客户端不需要在发送请求后阻塞等待，它可以同时发出多个请求，并在收到响应时通过Token区分不同的请求。在UDP的无连接环境下，这种设计是自然的，也使得CoAP能够支持真正意义上的异步通信。
这种映射关系为开发者带来的直接好处是：他们可以用熟悉的REST模式来设计物联网接口，而底层通信的负载却大幅降低。
资源发现
在HTTP生态中，用户通过浏览器“看到”页面内容。在CoAP生态中，客户端需要知道设备提供了哪些资源，才能进一步发起请求。CoAP规范定义了一个核心链接格式（Core Link Format），客户端可以通过GET请求/.well-known/core来获取设备上的资源列表。响应体是一个紧凑的链接描述：
</temp>;if="sensor";rt="temperature-celsius",
</light>;if="actuator";rt="light-control"这种自描述能力在规模化部署中具有显著的工程价值：平台在接入新设备时不必依赖外部配置，设备可以在连接后“介绍自己”。资源属性和内容协商机制还可以帮助客户端理解数据格式。与MQTT需要额外定义主题命名规范和物模型映射的工程流程相比，CoAP的资源发现机制提供了一种更独立的标准接口。
以下是用libcoap库实现的CoAP客户端示例程序，它发送一个CON GET请求，获取服务器上的温度资源。libcoap是C语言环境中使用最广泛的CoAP实现，适用于嵌入式Linux和RTOS环境。
// CoAP客户端：请求资源（使用libcoap库，示意代码）
#include <coap3/coap.h>
int main(void) {
coap_context_t *ctx = NULL;
coap_session_t *session = NULL;
coap_address_t dst;
coap_uri_t uri;
unsigned char got_data = 0;
// 初始化libcoap上下文
coap_startup();
ctx = coap_new_context(NULL);
if (!ctx) return 1;
// 解析URI
coap_split_uri((const uint8_t *)"coap://<device-ip>/temperature",
strlen("coap://<device-ip>/temperature"), &uri);
coap_address_init(&dst);
// ... 省略地址解析与session创建细节 ...
// 发送CON GET请求，注册响应回调
coap_pdu_t *pdu = coap_new_pdu(session, COAP_MESSAGE_CON,
COAP_REQUEST_CODE_GET,
coap_opt_new(session, &uri));
coap_send(session, pdu);
// 进入事件循环，等待响应
while (!got_data) {
coap_io_process(ctx, COAP_IO_WAIT);
}
coap_free_context(ctx);
return 0;
}在实际工程项目中，CoAP还支持块传输（Blockwise Transfer）用于拆分超过UDP MTU的负载（报文尺寸受 IPv6 最小 MTU——1280 字节，RFC 8200——约束），以及DTLS（Datagram Transport Layer Security，数据报传输层安全）/CoAPS（端口5684）用于加密传输。不过，对于一个只需上报几个整数的温度传感器，最简的NON请求已经足够——这也是CoAP在典型应用场景下功耗经常低于MQTT的根本原因。
9.3.2 LwM2M协议：设备管理与遥测
CoAP 解决了受限设备“怎么发请求、怎么拿数据”的问题，但它只管消息的收发与可靠投递，不管设备本身——设备是什么型号、固件版本多少、需要远程改一个配置参数怎么办？这些“设备管理”层面的需求，CoAP 既没定义结构化的扩展点，也没规定业务语义。
LwM2M（Lightweight Machine-To-Machine，轻量级 M2M）就是来补这块的。它由 Open Mobile Alliance（OMA）制定，不是另造一套传输协议，而是直接架在 CoAP 之上。CoAP 管信号层面的请求/响应和观察机制，LwM2M 管设备能力的抽象、注册、配置和维护。二者跑在 UDP 上，默认端口 5683，加密时使用 DTLS/CoAPS 走 5684。在电信级、需要远程运维的终端（NB-IoT 模组、智能表计、路灯控制）里，LwM2M 是常见的设备管理协议选择。
对象树：把设备能力变成可寻址的路径
LwM2M 的核心设计是把设备的能力抽象成一棵对象树（Object Tree）。这个模型只有三个层级：
- Object（对象）：代表一类能力。例如 OMA 规范中，
3代表“设备”，3303代表“温度传感器”，6代表“位置”。不同厂商的设备实现相同的对象 ID，意味着平台端的读写接口可以直接复用。 - Object Instance（对象实例）：同一类能力的多个副本。一台设备上装了三个温度传感器，就有三个
/3303/的实例，编号从0开始。 - Resource（资源）：实例里的一个具体可读/可写项。例如
/5700代表传感器当前读数，/5601代表最小测量值。资源还定义了操作权限，如只读（R）、可写（W）、可执行（E）。
访问一个具体的值，路径就是 /<objectId>/<objectInstanceId>/<resourceId>，例如读第一个温度传感器的当前值，路径为 /3303/0/5700。这套路径语义和 CoAP 的 URI 格式天然对齐，不需要额外路由映射，设备端的 LwM2M Client 固件只需要按路径查表找到对应的处理器函数即可。
这套模型的关键在于标准化：不同厂商生产的温度传感器，只要遵循 OMA 定义的 LwM2M 对象 3303，无论其硬件内部实现差异多大，平台端的读写接口就完全通用，不需要针对每家厂商单独适配。OMA 维护了一个公开的对象注册表，覆盖设备管理（对象 3）、位置（对象 6）、传感器（温度 3303、气压 3323、湿度 3304）、执行器、软件升级等数百种预定义对象。这种统一表达能力是 LwM2M 区别于 MQTT（需要应用层自行定义 payload 格式）的重要特征：设备的能力在协议层就被描述清楚，而不是依赖文档约定。
表9-3 LwM2M 常用对象与资源示例（基于 OMA LwM2M 规范）
| 对象名称 | 对象 ID | 资源名称 | 资源 ID | 操作权限 | 说明 |
|---|---|---|---|---|---|
| 设备 | 3 | 制造商 | 0 | 只读 | 设备厂商名称 |
| 设备 | 3 | 固件版本 | 3 | 只读 | 当前固件版本号 |
| 设备 | 3 | 重启 | 4 | 执行 | 触发设备软重启 |
| 温度 | 3303 | 传感器值 | 5700 | 只读 | 浮点型温度读数 |
| 温度 | 3303 | 最小测量值 | 5601 | 读/写 | 可配置的量程下限 |
| 温度 | 3303 | 最大测量值 | 5602 | 读/写 | 可配置的量程上限 |
| 气压 | 3323 | 传感器值 | 5700 | 只读 | 浮点型压力值 |
| 位置 | 6 | 纬度 | 0 | 只读 | 十进制格式 |
| 位置 | 6 | 经度 | 1 | 只读 | 十进制格式 |
| 固件更新 | 5 | 固件包 | 0 | 写 | OTA 镜像文件 |
| 固件更新 | 5 | 固件包 URI | 1 | 写 | 设备从该 URI 下载固件镜像 |
| 固件更新 | 5 | 执行固件更新 | 2 | 执行 | 触发升级流程 |
| 固件更新 | 5 | 固件状态 | 3 | 只读 | 升级进度/状态码 |
引导与注册：设备上平台的标准三步
设备首次接入网络时，并不知道应该连哪个 LwM2M 服务器，也不知道用什么安全凭证。LwM2M 通过引导服务器（Bootstrap Server）来解决这个“初生设备”的问题。引导与注册流程大致分三步：
- 引导：设备启动后，用出厂预置的引导信息（可能是一个域名或固定 IP）联系引导服务器。引导服务器返回 LwM2M 主服务器的地址、端口、安全凭证（例如 PSK 预共享密钥或证书的公钥部分）以及设备相关的初始配置参数（如心跳间隔）。这个步骤只在新设备首次上电或恢复出厂设置时发生，正常运行时设备已缓存这些信息。
- 注册：设备拿到服务器信息后，向 LwM2M Server 发送 CoAP POST 请求，请求的 Payload 中携带设备支持的所有对象 ID 列表和端点名。服务器端收到后，建立一个设备实例并返回一个 CoAP
2.01 Created响应。 - 更新注册：在存活时间（Lifetime）到期之前，设备必须周期性地发送 CoAP POST 到注册路径来续约。如果服务器在超时后仍未收到更新，就判定设备离线，释放该设备的注册资源。
这个流程在电池供电的 NB-IoT 模组中很常见：水表在出厂时内置了运营商的引导地址，通电后自动完成引导和注册，平台端就能直接读水表读数或执行抄表指令。注册报文本身极为轻量，对每天只上报几次数值的 NB-IoT 场景来说，网络和功耗开销都相当低。
观察/通知：从轮询到推送
传统 CoAP 里，客户端要拿数据就得反复发 GET 请求。对于温度、气压这类周期性变化的数据，轮询既浪费带宽又费电。LwM2M 利用 CoAP 的 Observe（观察） 机制实现了推送式的数据上报。
流程很简洁：平台端先向设备发送一条带 Observe: 0 选项的 CoAP GET 请求（例如 GET /3303/0/5700 Observe: 0）。设备收到后，把它加入观察者列表，并立即将当前传感器值作为第一次通知返回。此后每当传感器数据发生变化（或者达到预设的最小上报周期），设备就主动向平台发送一条 CoAP 响应，内容就是最新的资源值。平台端在不需要时可发送 RST 消息取消观察。
实际工程中，LwM2M 的 Client 端通常配合两个参数来决策何时上报：一是变化阈值，例如仅当温度变化超过 0.5℃ 时才上报；二是最小通知周期，例如两小时内最多上报一次。这就把通信主动权交给了设备侧：设备自行判断数据变化是否值得唤醒并上报，平台只收不催。对于深度休眠的传感器，设备采集完数据后瞬间唤醒、发出通知，然后继续休眠，耗电量远低于维持一个 TCP 长连接。
固件升级与远程配置的协议映射
固件升级（Firmware Update）是 LwM2M 提供的标准化设备管理能力之一。它在协议层面体现为一组预定义的资源。以固件更新对象（对象 ID 5）为例，升级流程在协议层面拆解如下：
- 固件包写入：平台通过 CoAP PUT 请求，将整个固件镜像分块写入固件包资源。OMA LwM2M 规范支持利用 CoAP 的块传输（Block Transfer）机制自动完成分片与重组，设备端每收到一个块回复 ACK 并等待下一个块，无需应用层关心拆包逻辑。
- 升级触发：写入完成后，平台向执行固件更新资源发送 CoAP POST 请求（本质上是“执行”指令），触发设备验证镜像的完整性并将新固件刷入存储区。
- 状态反馈：设备在升级过程中将状态码写回固件状态资源。平台通过 Observe 机制订阅该资源的变化，就能实时获得例如“升级中 20%”、“校验失败”、“成功”等进度反馈。
远程配置的实现方式更直接。平台端对着对象树中对应的资源发一条 CoAP PUT 请求，设备端的 LwM2M Client 解析并应用新值。例如要修改雨量计的采集间隔，平台直接 PUT 新值到对象 3303 实例 0 之下代表“测量周期”的资源。
这种“操作 = 写资源”的模型，让固件升级（写固件数据→执行升级→读状态）和远程配置（写配置值→设备立即生效）的实现逻辑高度统一：都是 CoAP 请求，区别只在于操作的对象路径和数据类型。设备端的 LwM2M Client 只需要识别对象树的结构，按资源 ID 查表找到处理器函数，而不需要为每类操作单独写一套状态机。这种设计大幅降低了设备端固件的复杂度，也是 LwM2M 能够在资源受限的 MCU（内存通常只有几十到几百 KB）上跑起来的原因之一。
工程检查表：LwM2M 部署要点
- 对象树版本对齐：设备端和平台端使用的 OMA 对象注册表版本必须一致，否则平台可能无法解析设备上报的资源 ID。在项目初期就应确定所使用的 OMA LwM2M 规范版本，并锁定目标设备固件的实现。
- 引导场景区分：仅在新设备首次上电、恢复出厂设置或证书过期时才需要引导服务器。生产环境中不应让设备每次重启都请求引导，否则会引入不必要的对外部引导服务器的依赖，增加故障点。
- 生存时间与心跳间隔：Lifetime 的设定应结合设备的功耗预算和网络可靠性，在 NB-IoT 场景下通常为数十分钟到数小时。过短会增加上行流量和耗电，过长则会导致平台端延迟发现设备离线，影响业务连续性判断。
- 观察/通知的阈值配置：变化阈值和最小通知周期需在设备端和平台端达成一致。阈值过小导致频繁上报（增加功耗和网络流量），阈值过大则数据变化可能被错过，无法触发业务决策。建议在生产部署前，用真实的设备样本运行一个实验性周期，校准阈值。
- 固件升级的失败回滚：升级过程中需设计回退机制。设备应保留上次可用的固件版本，在升级失败或校验错误后能自动回滚，避免设备变砖。LwM2M 规范中的固件状态资源（如对象 5 的固件状态资源）就是为此提供标准化接口，平台端必须订阅该资源的变化以感知升级结果。
9.3.3 CoAP/LwM2M在NB-IoT中的应用案例
要理解CoAP和LwM2M在NB-IoT（Narrowband IoT，窄带物联网）中的协同价值，一个城市路侧停车位的场景比任何抽象描述更直观。先交代本节与第 4 章的分工：4.5 节以智能路灯为例，讲的是 NB-IoT 空口特性与统一接入层的配置落地；本节则下探到终端内部的协议栈——CoAP 报文交换与 LwM2M 对象模型如何在同一颗 NB-IoT 模组上配合。场景是某城市部署了上千个地磁传感器节点，每个节点通过NB-IoT模组接入，定期上报“空闲/占用”状态，支持远程调整计费策略参数（如免费时长、高峰费率阈值）以及固件升级。这套系统中，NB-IoT提供了广覆盖、低功耗的物理通道，CoAP负责轻量消息交换，LwM2M承担设备管理与对象标准化——三者配合是实现低功耗运维的关键。
CoAP的NON消息与NB-IoT节电机制的适配
NB-IoT的PSM（Power Saving Mode，省电模式）与eDRX（Extended Discontinuous Reception，扩展非连续接收）两种节电机制，已在第 4 章 4.1.1 节结合空口特性介绍过——设备大部分时间深度休眠，仅在配置的寻呼窗口或主动上报时唤醒。这与CoAP无连接、无状态的模型天然适配。
在停车位管理场景中，地磁传感器是典型的单向大幅上行设备，每天以周期性状态上报为主。如果强行使用MQTT，即使采用QoS 0且拉长PINGREQ间隔，也需要设备在报文间隙维持与Broker的会话状态和周期性心跳任务。对于休眠电流极低、发射瞬间电流大幅攀升的NB-IoT模组，这种维持带来的额外能耗不可忽略。
更合理的做法是：传感器检测到磁场变化后，构造一条CoAP NON（Non-confirmable）消息发往平台，随即立即进入PSM模式深度休眠。NON消息不要求ACK，没有重传开销，也不维持任何会话上下文。设备的状态机简化为“采集-组包-发送-休眠”的无状态循环，无需处理连接断开重连、心跳超时等逻辑。若场景要求对计费扣款等关键事件提供可靠性保障，则切换为CON（Confirmable）消息——CoAP内置的指数退避重传机制能保证在中等丢包率下可靠送达。从能耗角度来看，CoAP+NON+PSM的组合能充分释放NB-IoT的低功耗潜力，而非像TCP协议那样需要用周期心跳来对抗连接维护的开销。
LwM2M对象标准化与设备管理
CoAP解决了“如何发消息”的问题，但停车计费运营方还需要知道：传感器是哪个供应商的、当前检测灵敏度是多少、如何远程修改“免费时长”。这些管理需求落在LwM2M的职责内。LwM2M通过对象树将设备能力抽象为标准化路径。对于停车传感器，典型的对象实例包括：
- Object 3（设备）：提供制造商、型号、固件版本等基本信息。
- 自定义的“地磁检测”对象：描述传感器类型和量程。
- Object 5（固件升级）：实现固件包下载、校验和状态回传。
管理人员通过LwM2M Server发送Write指令，CoAP层将其转换为CON消息确保可靠交付，传感器更新配置后响应。固件升级是LwM2M设备管理中最具代表性的操作——运营方需要批量升级固件以修复地磁检测算法时，客户端通过CoAP块传输分片下载固件二进制，支持断点续传。
以下代码展示LwM2M客户端使用Anjay库实现固件升级的关键回调逻辑，仅用于说明流程，并非生产级代码：
// 示意代码：LwM2M客户端固件安装回调（Anjay库）
#include <anjay/anjay.h>
#include <anjay/fw_update.h>
static int fw_install(anjay_t *anjay, const anjay_fw_update_handle_t *handle) {
const uint8_t *data;
size_t size;
anjay_fw_update_get_package(anjay, handle, &data, &size);
if (!verify_checksum(data, size)) {
anjay_fw_update_set_update_result(anjay, handle, 1); // 1=校验失败
return -1;
}
write_firmware_to_flash(data, size);
return 0;
}
int main(void) {
anjay_config_t config = {
.endpoint_name = "parking-sensor-001",
.in_buffer_size = 1024,
.out_buffer_size = 1024
};
anjay_t *anjay = anjay_new(&config);
anjay_fw_update_config_t fw_cfg = {
.install_callback = fw_install,
.download_mode = ANJAY_FW_UPDATE_DOWNLOAD_MODE_COAP_BLOCKING,
.supported_protocols = ANJAY_FW_UPDATE_PROTOCOL_COAP | ANJAY_FW_UPDATE_PROTOCOL_HTTP
};
anjay_fw_update_install(anjay, &fw_cfg);
while (1) { anjay_sched_run(anjay); sleep(1); }
anjay_delete(anjay);
}服务器端只需通过CoAP向Object 5的对应资源写入固件镜像，客户端回调启动下载与安装，升级状态通过资源回传。这使得远程固件运维不再是“保持设备在线”的难题，而变成可监控的异步任务。
工程权衡：NON vs CON与块传输的可靠性
地磁传感器上报使用NON消息是典型的功耗与可靠性权衡。连续两次丢包，平台可能在该周期内显示“离开”状态，导致计费中断。后端系统通常允许一定的丢包率，通过状态推测算法（如最近一次状态+超时推断）补偿。对于计费、开闸等关键指令，必须用CON消息保证送达，但每次需等待RTT级别的ACK，设备唤醒窗口被拖长。工程检查点在于区分状态的冗余度和指令的实时性。
固件升级块传输的可靠性更复杂：设备可能在下载过程中断电。LwM2M Object 5支持断点续传，但需要客户端将已接收块信息持久化（如写入Flash），否则断电后服务器从零重传，浪费大量空口流量。部署时须确认固件状态持久化逻辑是否已实现。
实践检查清单：适用性评估
在评估项目是否适合该组合时，可对照以下项进行逐项检查：
- 确认模组能力：设备NB-IoT模组需支持eDRX/PSM，并配置合理的睡眠-唤醒周期。若不支持PSM，电池寿命会大幅缩短。
- 消息可靠性分级：状态上报使用NON；计费、配置、固件操作使用CON，并设置合理重传超时。
- LwM2M对象标准化：优先采用OMA IPSO（Internet Protocol Smart Objects）定义的标准对象ID和资源ID，减少供应商自定义扩展，否则平台侧需要针对每个型号加适配层。
- 固件升级持久化：启用断点续传，配合固件状态持久化至NV存储，升级失败时保留回滚机制。
- 网络覆盖裕量：地磁传感器常安装在地下或金属井盖下，NB-IoT覆盖增强带来的功耗增加应在早期测试中评估，避免在弱覆盖区盲目采用NON消息。
- 引导服务器预置：所有设备出厂前配置Bootstrap Server信息，避免现场逐台手动写入服务器地址和密钥。
以上内容基于例子和公开标准推导。具体性能数字（如单次上报能耗、电池寿命年数）应参考实际芯片手册和运营商网络配置进行测试。CoAP/LwM2M与NB-IoT的组合，是低功耗广域网应用层的一个工程标杆——但其价值在于让运维人员理解从无线空口到设备管理语义的全链路约束，才能在设计阶段做出清醒的取舍。它不适用于需要高实时性双向交互或大数据量的场景，那些场景更适合MQTT或HTTP。