📚 课程目录第3章 LwM2M接口与操作流程

3. LwM2M接口与操作流程

LwM2M 的四大接口并不是四个并列的功能菜单，而是围绕“设备如何被接入、如何被管理、如何上报数据”形成的一条完整交互链。理解它们的关键，是看清每个接口在 CoAP 消息层上交换了什么、由谁发起、成功后设备端和服务器端各自进入什么状态。本节按真实交互顺序展开，并给出可直接对照的消息示例。

一、四大接口的职责边界

Bootstrap 接口解决“设备第一次连谁、用什么服务器地址”的问题，由 Bootstrap Server 向客户端下发配置。Registration 接口解决“设备上线后向 Management Server 声明自己存在”的问题，由客户端主动发起。Device Management & Service Enablement 接口解决“服务器如何读写设备对象、执行资源”的问题，是管理面最常用的接口。Information Reporting 接口解决“设备如何按条件把资源变化推给服务器”的问题，包括 Observe、Notify 和 Cancel Observation。

四者的关系可以用一条主线概括：Bootstrap 提供服务器信息 → Registration 建立会话 → Device Management 执行读写与执行 → Information Reporting 持续上报变化。下面这张图把四个接口的发起方、CoAP 方法、关键路径和状态结果放在同一张交互链上，便于对照记忆。

二、Bootstrap：设备第一次连谁

设备出厂时通常只预置一个 Bootstrap Server 地址。上电后，客户端向 Bootstrap Server 发起请求，服务器通过 POST /bs?ep={Endpoint Client Name} 下发配置。配置内容主要是 Security Object（/0）和 Server Object（/1），前者告诉设备 Management Server 的 URI 和安全模式，后者告诉设备短服务器 ID、生命周期和绑定方式。

一个典型的 Bootstrap 请求与响应如下：

// Client → Bootstrap Server
POST coap://bs.example.com:5683/bs?ep=dev001
Content-Format: application/vnd.oma.lwm2m+tlv

// Bootstrap Server → Client（下发 Security 与 Server 实例）
2.04 Changed
Payload(TLV):
  /0/0: LWM2M Server URI = coap://lwm2m.example.com:5683
  /0/0: Security Mode = 3 (NoSec)
  /1/0: Short Server ID = 101
  /1/0: Lifetime = 300
  /1/0: Binding = "U"

客户端收到后返回 2.04 Changed，并关闭 Bootstrap 会话。此时设备已经知道“该向哪个 Management Server 注册”。如果 Bootstrap 失败，设备通常按退避策略重试，而不是直接进入注册流程。

三、Registration：建立在线会话

注册由客户端主动发起，目标是 Management Server 的 /rd 资源。请求中必须携带 Endpoint Client Name，可选携带 Lifetime、Binding 和 Object 列表。服务器成功创建注册后返回 2.01 Created，并在 Location-Path 中给出注册资源路径，后续更新和注销都基于该路径。

// Client → Management Server
POST coap://lwm2m.example.com:5683/rd?ep=dev001&lt=300&b=U
Content-Format: application/link-format
Payload: </1/0>,</3/0>,</3303/0>,</3347/0>

// Management Server → Client
2.01 Created
Location-Path: /rd/5a3f

注册成功后，设备进入在线态。若 Lifetime 为 300 秒，客户端需要在到期前发送 POST /rd/5a3f 更新注册；若设备主动下线，则发送 DELETE /rd/5a3f。服务器在 Lifetime 超时未收到更新时，会将该注册标记为过期。

四、Device Management & Service Enablement：读写与执行

这是管理面最常用的接口，服务器通过它对设备对象执行读、写、执行、创建、删除等操作。路径遵循 /{Object ID}/{Instance ID}/{Resource ID} 结构。例如读取温度对象 3303 的当前值：

// Server → Client
GET coap://[dev001]/3303/0/5700
Accept: text/plain

// Client → Server
2.05 Content
Content-Format: text/plain
Payload: 23.5

写操作使用 PUT，例如把温度单位从摄氏度改为华氏度：PUT /3303/0/5701，Payload 为 1，客户端返回 2.04 Changed。执行操作使用 POST，例如重启设备：POST /3/0/4，客户端执行后返回 2.04 Changed。如果资源不存在，返回 4.04 Not Found；如果方法不允许，返回 4.05 Method Not Allowed。这些响应码是判断操作是否真正生效的直接依据。

五、Information Reporting：Observe 与 Notify

Information Reporting 的核心是 Observe 机制。服务器在 GET 请求中附加 ?obs 参数，表示订阅该资源。客户端返回 2.05 Content 并携带 Observe: 0，之后每次资源变化都会主动发送 Notify，Observe 序号递增，服务器据此判断消息的新旧顺序。

// Server → Client（订阅）
GET coap://[dev001]/3303/0/5700?obs

// Client → Server（首次响应）
2.05 Content
Observe: 0
Payload: 23.5

// 资源变化后（Notify）
2.05 Content
Observe: 1
Payload: 24.1

取消订阅有两种方式：服务器发送 GET ...?obs 且不带 Observe 选项，或客户端在 Notify 中返回 4.04 Not Found。实际开发中，还要注意 Notify 的触发条件——可以是数值变化、也可以是周期上报，具体由服务器在订阅时通过 pmin、pmax 等参数约定。

四个接口的先后关系不是绝对的：设备可能跳过 Bootstrap 直接注册（预置服务器信息），也可能在注册后立即发起 Observe。但无论顺序如何，Registration 都是管理面和上报面的前提——没有成功注册，服务器无法定位设备，也就无法执行读写或订阅。

六、消息示例对照表

接口	发起方	CoAP 方法与路径	成功响应
Bootstrap	Bootstrap Server	POST /bs?ep=dev001	2.04 Changed
Registration	Client	POST /rd?ep=dev001&lt=300&b=U	2.01 Created + Location-Path
Device Management	Server	GET /3303/0/5700	2.05 Content
Device Management	Server	PUT /3303/0/5701	2.04 Changed
Device Management	Server	POST /3/0/4	2.04 Changed
Information Reporting	Server	GET /3303/0/5700?obs	2.05 Content + Observe:0
Information Reporting	Client	Notify（无请求路径）	2.05 Content + Observe:n

把这张表与前面的交互链图对照，可以快速定位每个接口的发起方、路径和响应码。实际开发中，建议在设备端日志中同时记录 CoAP Message ID、Token 和 Observe 序号，这样在排查注册失败、Notify 丢失或读写超时时，能直接判断问题出在哪个接口、哪条消息上。