2. LwM2M协议栈与对象模型精要

LwM2M 终端接入工程里，最容易“看起来懂了、实际接不通”的地方，往往不是服务器配置，而是对协议栈分层和数据模型语义理解不到位。一个终端上报的“温度 23.5℃”，在 LwM2M 里并不是一段裸数据，而是沿着 Object → Object Instance → Resource 的路径被寻址，再经 CoAP 的消息语义封装，最后由 DTLS 提供传输安全。任何一层理解偏差，都会表现为注册失败、读值超时或写命令不生效。

一、协议栈分层：谁负责什么

从下往上看，LwM2M 的承载栈通常为：UDP → DTLS → CoAP → LwM2M。UDP 提供无连接数据报；DTLS 在 UDP 之上补齐握手、加密与完整性校验；CoAP 提供请求/响应与观察语义；LwM2M 则定义对象模型和注册、管理、上报等接口。需要特别注意的是：DTLS 保护的是传输通道，不改变 CoAP 与 LwM2M 的语义。因此抓包时若只看到加密后的 UDP 载荷，必须先在客户端侧解密或使用 PSK 密钥还原，才能看到 CoAP 报文。

CoAP 的关键语义包括：CON/NON 消息类型、GET/POST/PUT/DELETE 方法、Token 匹配、以及 Observe 观察。LwM2M 的“注册更新”“读资源”“写资源”“执行资源”最终都映射为 CoAP 请求。例如读取 /3/0/0（Device 对象的 Manufacturer 资源）就是一次 CoAP GET；写 /1/0/1（Server 对象的 Lifetime）通常是一次 CoAP PUT。理解这层映射，才能在日志里把 CoAP 响应码翻译成 LwM2M 操作结果。

二、对象模型：Object、Instance、Resource 的层级语义

LwM2M 用三层结构描述终端能力。Object（对象）是一类功能的定义，例如 Object 3 是 Device、Object 1 是 Server、Object 3303 是 Temperature。每个对象有唯一的 Object ID，由 OMA 注册或厂商自定义。Object Instance（实例）是对象的具体实体，用 Instance ID 区分。例如一个终端有两个温度传感器，就对应 Object 3303 的 Instance 0 和 Instance 1。Resource（资源）是实例下可读写或可执行的最小数据单元，例如 Sensor Value、Units、Min Measured Value。

寻址采用 URI 形式：/ObjectID/InstanceID/ResourceID。读取 Device 对象的厂商资源写作 /3/0/0；读取第二个温度传感器的当前值写作 /3303/1/5700。这里 5700 是 OMA 定义的 Sensor Value 资源 ID。工程中最常见的错误是把 Resource ID 当成 Instance ID，导致读值返回 4.04 Not Found。排查时先确认对象和实例是否存在，再确认资源 ID 是否在该对象定义中。

资源还有若干关键属性：Operations 决定可执行的操作（R 只读、W 只写、RW 读写、E 执行）；Multiple 表示是否可多值；Mandatory 表示是否必须实现；Type 表示数据类型（Integer、Float、String、Boolean、Time 等）。例如 Battery Level 是 Integer 且只读，Reboot 是 Execute 且无返回值。写资源时若类型不匹配，CoAP 层可能返回 4.00 Bad Request，而不是 LwM2M 层的语义错误。

三、注册与交互语义：从 Register 到 Observe

终端上电后第一件事是向 LwM2M Server 发起 Register。注册请求携带 Endpoint Client Name、Lifetime、LwM2M Version、Binding Mode（UDP 或 UDP with DTLS）以及对象实例列表。服务器返回 2.01 Created 并分配 Location Path，例如 /rd/5a3f。后续所有管理操作都基于这个 Location Path 进行。若 Lifetime 设为 300 秒，终端必须在到期前发送 Update，否则服务器会认为终端离线并释放注册。

注册成功后，服务器可以发起 Read、Write、Execute、Discover 等操作。Read 对应 CoAP GET，返回资源值；Write 对应 PUT 或 POST，修改可写资源；Execute 对应 POST，触发动作。终端主动上报则通过 Notify 实现：服务器先对某资源发起 Observe，终端在值变化或达到 PMin/PMax 条件时发送通知。PMin 是两次通知的最小间隔，PMax 是最大间隔，二者共同控制上报频率，避免网络拥塞。

四、DTLS 与 CoAP 的协作要点

DTLS 握手在 UDP 之上完成，常用 PSK 模式。终端与服务器需预置相同的 Identity 和 Key。握手成功后，CoAP 报文作为 DTLS 应用数据被加密传输。这里有一个容易忽略的点：DTLS 记录层有重传和超时机制，CoAP 自身也有 CON 重传。若两者超时参数不协调，可能出现重复注册或重复执行。建议 CoAP ACK_TIMEOUT 设为 2 秒、MAX_RETRANSMIT 设为 4 次，DTLS 握手超时设为 10 秒以上，给弱网留出余量。

另外，NAT 环境下 UDP 映射会老化。终端应通过注册更新或 CoAP 空报文维持通道。若使用 Queue Mode，终端可在休眠前告知服务器，服务器缓存下行请求，待终端唤醒后一次性下发。这要求注册时正确声明 Binding Mode 和 Queue Mode 参数，否则下行命令会在终端休眠期间丢失。

五、一个可复用的接入检查清单