需求文档

参考：

• OMA-RD-LightweightM2M-V1_0-20170208-A.pdf
• OMA-RD-LightweightM2M-V1_1-20180710-A.pdf

注1：由于具体的需求规范在参考实现（如Leshan）中已经完成，因此本文中不做说明，如需要了解请参考原文档。
注2：由于需求文档存在1.0.2和1.1两个版本，中间有部分不同。本文将着重于两者不同的部分进行说明。

范围（略）

参考（略）

术语和惯例（略）

介绍

1.0.2

此文档定义了运行于LwM2M设备之上的LwM2M客户端与LwM2M服务器之间的应用程序层通信协议。与主要专注于移动设备管理的OMA DM协议相比，OMA LwM2M不仅关注设备管理，还关注LwM2M设备的服务启用。LwM2M协议的目标设备特别针对资源受限设备。因此，该协议提供轻量简洁的协议和简明的数据结构。

1.1

以下是引入的新功能：

1. 提高了将LwM2M用于低功率广域网设备（如3GPP CIoT / LoRA）的设备管理的能力。
2. 使用RFC 7925的建议，以及新的TLS / DTLS扩展来提供更好的性能，从而更好的与当前安全实践保持一致。
3. 引入TCP和TLS，以便使CoAP可以在具有防火墙和其他中间件的环境中更好地提供支持。 TCP的使用还降低了在存在网络地址转换的情况下频繁保持心跳连接的需要。
4. 改进了固件升级，引导和注册过程的维护步骤。

发布说明

LwM2M文档提供了一个底层无关协议，以允许LwM2M服务器和LwM2M客户端之间的M2M服务启用和设备管理。

端到端服务描述

LwM2M协议将为资源受限的LwM2M设备提供一个解决方案，该解决方案将大幅减少部署M2M服务的成本。由此带来的优势将使M2M行业的每个利益相关者受益匪浅。LwM2M协议还最大限度地减少了由于M2M设备数量不断增加而对通信网络造成的流量影响。 除此以外，M2M设备的功耗也将降低。（1.0.2）

为演进到LwM2M 1.1，需要对LwM2M 1.0在几个方向上作出改进。新版本针对以下问题提出了增强的解决方案：

LwM2M 核心功能

传输

• 约束应用程序协议（CoAP）是为物联网部署而设计的，它假定我们可以无阻碍的使用UDP或DTLS over UDP。在IP网络且没有防火墙阻拦UDP流量的场景下，UDP是传输少量数据的理想选择。
• 在一些情况下，LwM2M部署需要与现有的企业基础架构集成；在这些企业基础架构中，基于UDP的协议可能不会被正确接收，甚至可能被防火墙阻止。不了解CoAP使用情况的中间件可能会使UDP变得脆弱，导致数据包丢失或格式错误。

引导和注册（Bootstrap & Registration=BSR）

• [LwM2M-BSR-2] Bootstrap扩展能力（Bootstrap Extended Capability）：在LwM2M 1.0中，在Bootstrap阶段执行增量修改（例如添加新服务器和升级/调整客户端配置）是受限的，因为LwM2M客户端中已保存了访问权限，Bootstrap服务器无法升级客户端的ACL实例。
  在LwM2M 1.1中，为Bootstrap服务器提供了一种方法，用于发现LwM2M客户端中已保存的访问控制权限，这样可以允许客户端进行安全/一致的配置升级（无需解决冲突）。
• [LwM2M-BSR-3] 在LwM2M 1.0中，“服务器启动的引导模式”不再被视为一种可靠的模式。LwM2M 1.1定义了允许Bootstrap服务器在客户端中触发“客户端启动的引导模式”的机制，这是一种简单而可靠的方式，使得服务器同样拥有了启动引导序列的功能，同时也重用了已经得到验证的机制。
• 不管是正常操作还是错误条件下，在引导模式和注册模式转换时，都必须支持引导过程和注册过程的连续执行。
• 在引导期间，LwM2M客户端必须能够使用引导序列转换为与LwM2M服务器通信，该LwM2M服务器由LwM2M服务器对象定义所配置。
• 在注册过程中，如果在使用由LwM2M服务器对象或其他对象定义的配置好的LwM2M服务器时，发生重大错误，LwM2M客户端必须能够返回到引导过程，以便更正LwM2M服务器对象中的任何配置错误。
• LwM2M服务器对象或其他对象中定义的资源必须对正常和错误条件下的LwM2M客户端行为都作出规定。
• LwM2M客户端可能需要使用特定的APN与LwM2M服务器通信。

设备管理和服务启用接口

• [LwM2M-OSR-1] 地址扩展：虽然LwM2M TS 1.0已经支持LwM2M多实例资源，但只能将多势力资源作为整体来处理。在LwM2M 1.1中，通过设备管理和服务启用接口，可以支持对LwM2M多实例资源的某个实例进行单独的读写访问。
• [LwM2M-DSE-001] & [LwM2M-IR-001] 在LwM2M TS 1.0中，读取和写入操作分别绑定到CoAP Get和Put方法，其中操作范围可以是对象的所有实例，单个实例或给定实例中的资源。 如果服务器需要访问实例中的资源子集，或者需要访问相同或不同对象的实例，则必须发出多个请求。 对于资源受限的低功率设备，这增加了不必要的开销，因为这意味着设备必须在多个事务上保持更长时间。
  这应该在LwM2M 1.1中解决；在CoAP涉及的传输层面，RFC 8132中新定义的FETCH和PATCH方法已经满足了这一要求，但LwM2M层目前无法利用这些能力。
• [LwM2M-DSE-003] 在LwM2M TS 1.0中，从LwM2M设备发送的任何数据要么是直接READ操作的结果，要么是OBSERVE操作的结果。然而，某些应用程序可能使用了动态数据模型，这使得服务器无法提前知道它们应该READ或OBSERVE哪些数据。
  当前唯一的临时解决方案是让服务器发送一个足够通用的OBSERVE操作，这样会使客户端OBSERVE大量数据（其中很多数据可能服务器并不需要）并发回服务器。从数据和OBSERVE的角度来看，这样产生了许多无用的数据传输。
• [LwM2M-DSE-004] 允许LwM2M客户端按照[LwM2M-DSE-003]的需求向LwM2M服务器报告未经请求的数据，在某些情况下可能会带来一定的风险，特别是有太多设备向服务器报告过量数据的风险。为了降低这种风险，引入了[LwM2M-DSE-004]。

维护和升级

维护

LwM2M 1.1中的维护和升级场景是必要的，因为从LwM2M 1.0或LwM2M v1.0.x的升级很可能实际发生。这部分需求的目的是提供：

• 设备升级之前、期间和之后，要执行的清除操作指南
• 设备升级之前、期间或之后，能有效设置或请求正确配置和参数的能力
• 升级过程还可以指导设备在重启和其他不良情况下的维护阶段

升级

在升级期间需要解决下面的使用问题以保存配置

• 由于设备受限的现实情况，设备可能连接到非常低带宽的网络环境，这使得我们在升级完成后，必须有效的保留不需要重传的内容
• 物联网领域中设备的本质决定，设备需要区分设备默认配置，而设备默认配置通常不在LwM2M服务器。在下图中，蓝色 / 绿色框可以看作两个配置示例，这两个配置需要在升级后继续存在，并且通常LwM2M服务器在整个设备的生命周期中都不拥有这些配置。一般认为这些配置应通过预先商定的方式加载到设备中。可以在升级期间明确请求保留这些配置。
  

在升级和创建升级回退过程期间，以下使用问题需要得到解决

• 由于错误的环境，可能导致升级过程在网络中寻找错误的升级包
• 升级包错误被延迟发现

客户端延迟定时器（Client Hold off Timer）

客户端延迟定时器确保客户端在一段时间后再注册其LwM2M服务器。这是为了确保后端区域（OSS系统）中的相关系统能准备好，一旦设备注册就与设备协调。 当支持多个LwM2M服务器实例时，有时需要具有这样的可配置定时器（秒级），客户端在引导之后，在向每个服务器实例第一次注册之前，都要按照配置的时间延时。这样为配置系统提供了跨服务器后端了解设备特性的机会，以便在客户端注册之前准备好适当的服务器实例。

下图从整体上描述了该部分的需求

上面给出了一种顺序需求的例子，但可能还有其他使用模式，例如LwM2M服务器1/2一起获得初始注册，LwM2M服务器3/4在LwM2M客户端的特定延迟时间后获得初始注册，等等。

观察（Observation）

上报模式（Reporting Mode）

在报告观察通知时，需要附加信息来控制报告的配置并指出报告的原因。

LwM2M网关功能

LwM2M v1.1的LwM2M传统网关（Legacy Gateway）功能旨在互连不同的IoT孤岛，如图3所示。中心的LwM2M传统网关由几个组件组成，即：

• 一个LwM2M客户端，
• 一个协议转换器（protocol translator），以及
• 一个数据模型转换器（data model translator）

LwM2M客户端使用LwM2M协议与Bootstrap服务器以及一个或多个LwM2M服务器进行交互。它负责将非LwM2M设备（也称为传统设备）的信息展示给LwM2M服务器。

协议转换器负责将网关另一侧的消息根据其协议（例如BLE）转换为LwM2M协议消息。此协议转换的细节超出了LwM2M v1.1规范和实现的范围。 例如，RESTful LwM2M请求必须转换为使用类似RPC的机制的BLE查询，这就要求必须在网关上维护状态。 类似地，来自BLE设备的响应消息也必须被转换为相应的LwM2M响应消息。

数据模型转换器负责将LwM2M数据模型转换为传统协议侧的相应表示。 例如，BLE使用服务和特征，这些服务和特征在概念上映射到LwM2M对象和资源。 当然，如果两个数据模型中都存在相应的抽象，则只能以无损方式映射数据模型。 例如，Bluetooth SIG定义了心率服务，但当前在LwM2M定义中没有对应的对象。 在这种情况下，使用LwM2M BinaryAppDataContainer对象是一个可行的机制，它可以将数据通过隧道直接传输到LwM2M服务器，而不需要在传统网关处执行转换。

有两种设计方法可以提供必要的功能，如下所述。 我们将它们称为单实例与多实例方法。

设计方法 #1：单个LwM2M客户端实例 在这种方法中，LwM2M服务器面对的是在LwM2M传统网关上只运行一个LwM2M Client实例的情况。服务器通过转换过的LwM2M数据模型，从连接到LwM2M传统网关的传统设备检索对象和资源。

设计方法 #2：多个LwM2M客户端实例 在这种方法中，LwM2M服务器面对的是在LwM2M传统网关上针对每个传统设备运行一个独立LwM2M实例的情况。此外，网关上还运行一个单独的LwM2M客户端实例，用来表示网关上本身。如图4所示

哪种模型最适合取决于连接的旧设备的数量和其他编程模型的差异。举例来说，移动电话应用程序通常由不同组织开发，且通常内置lib库而不依赖于操作系统提供的共享库。在这种情况下，单个LwM2M客户端实例更易于部署。而对于连接多个IoT设备的独立家庭网关来说，多个LwM2M客户端实例方法更好。

用例 #1：医疗保健 / 健康
一种连接到智能手机的蓝牙低功耗（BLE）心率传感器。 该BLE心率传感器可以选择由Bluetooth SIG定义的心率配置文件和服务，也可以选择专有的配置文件和服务。另外，BLE设备可能支持其他（可能是专有的）配置文件和服务，例如支持固件更新。因为通过此心率传感器获得的数据将不仅用于智能手机上的应用程序，还被传送到基于云的服务器以进行大数据分析。此外，制造商还提供设备管理功能（如固件更新）。
因此，智能电话包括一个转换组件，用于BLE心率设备和LwM2M服务器基础设施之间的通信。

用例 #2：商业室内照明
在这个用例中，独立的LwM2M传统网关被用于在一侧的BACnet楼宇自动化网络和另一侧的LwM2M环境之间进行转换。 与用例＃1不同的是，此网关可能会连接更多数量的设备，并且设备需要自行管理，因为此网关将类似于一个网络设备，并不与用户直接交互。

组 & 拓扑

在LwM2M v1_0_x中不存在组概念；在网关级别建立设备组是一个有趣的尝试，这样服务器可以一次处理一组设备；典型的例子如对于特定患者的一组连接到网关的BLE设备，或是一个区域或楼层的灯等等；这是一个有用的概念，可以帮助传统网关通过LwM2M服务器发来的单个命令处理一组设备的问题。

LwM2M客户端的位置通常位于传感器中，根据房间功能的区别，传感器将可能位于不同楼层或房间，例如厨房、电梯室等。传统网关可以支持这些拓扑视图是有益的，将有助于进一步理解LwM2M客户端放置的位置造成的影响 。

安全性增强

扩展的PKI支持

LwM2M 1.0版使用证书提供对引导的支持，但是受到一些限制：

• 没有提供证书撤销（certificate revocation）的建议，
• 仅支持固定证书（pinned certificates），并且
• 没有获得安全时间信息的建议。

为了实现基于证书的身份验证基础结构的功能和实际部署，必须提供证书撤销建议，以及安全获取时间信息的方法。 此外，虽然固定证书的使用方便且安全，但由于可扩展性受到影响，因此不是部署公钥基础结构的最常用方法。 这样也引出了新的用例，客户可以使用已部署的CA基础架构与LwM2M一起使用。

TLS / DTLS指南

LwM2M 1.0版提供了有关如何使用DTLS通过各种传输为CoAP提供通信安全性的指导。

安全组件支持

• LwM2M 1.1将利用支持基于安全组件的灵活框架（即Secure Element-SE或Trusted Execution Environment-TEE）来扩展LwM2M安全功能

• 该框架将包括：

  • 一个包含敏感信息（例如密钥存储）以及在其中运行的敏感算法（例如，板载密钥对生成......）的安全组件
  • 一个专用于管理安全组件和可部署的服务（例如eUICC-M2M配置文件功能，设备安全启动，LwM2M 1.0智能卡引导程序）的M2M 1.1核心对象
  • 必须在LwM2M安全组件管理对象和安全组件之间建立的标准化协议族

E2E（端到端）安全

端到端安全性的目的是保护端点之间的通信免受来自路径上攻击者的攻击。 为了定义端到端安全性，需要指定端点。 不同的用例需要考虑不同的端点，端点可以支持不同的协议。

为了制定不那么琐碎的要求，必须考虑使用一些特定的设置，这包括这样一些假设，a）这些端点是什么，以及/或者 b）在两者之间使用什么应用层协议（CoAP，HTTP等）。有关设置的更多信息，请参见每个设置的独立章节。

下面列出了几种方案的端点：

• LwM2M服务器 - LwM2M客户端
• 应用服务器 - LwM2M客户端
• LwM2M服务器 - 非LwM2M IoT设备

LwM2M端到端的一般性安全要求

目前，LwM2M V1.0安全要求基本上是根据DTLS定义的。 对于LwM2M V1.1，要求应明确说明E2E安全性所需的安全属性。

完整性保护
路径上的攻击者可能会改变操作或响应内容，例如， 从Read到Delete，操作适用的对象 / 实例或资源，属性，消息的有效负载，错误状态（从失败到成功），错误代码等。路径上的攻击者也可能删除或注入信息。为了防止信息被操控，LwM2M接口上的操作和响应内容必须受到端到端的完整性保护。

加密
路径上的攻击者可能会窃听通信以了解操作的内容或性质。为了机密性和隐私性，LwM2M接口上的通信需要端到端加密。

回放（replay）保护
路径上的攻击者可能会记录操作并稍后回放操作，例如重置旧密钥或使用旧值重新配置对象实例。对于LwM2M接口上的操作，必须受到端到端的回放保护。

响应与操作绑定
当LwM2M服务器向LwM2M客户端发送操作请求时，路径上的攻击者可能会记录并阻止请求的响应，并且在稍后阻止第二个操作请求并发回对第一个操作的响应，从而向服务器提供操作结果的错误信息。有关示例，请参见图5。 因此，端到端安全解决方案必须支持响应与操作绑定。

新鲜度（Freshness）
路径上的攻击者可能会延迟操作请求并在以后的某个特定场合发送操作请求，从而给LwM2M客户端一种LwM2M服务器最近刚刚发送了该操作请求的错误感觉。因此，LwM2M客户端必须能够验证某些特定操作的端到端新鲜度。有关示例，请参见图3。
一种一般的假设是在端点之间（例如LwM2M客户端和LwM2M服务器之间）的路径上，底层绑定协议可能不同，可能包括可靠的传输（如TCP）和不可靠和无序的传输（如UDP）以及其他协议（如SMS和NB-IoT），见图5。

场景1：LwM2M服务器和LwM2M客户端在LwM2M V1.0中具有中间节点

LwM2M V1.0中，服务器与客户端之间的通信基于应用层协议CoAP。在LwM2M的未来版本中，可能会使用不同的应用层协议，但E2E安全解决方案必须存在，特别是使用CoAP协议作E2E操作时。

在LwM2M v1.0中，DTLS支持仅限于LwM2M服务器和LwM2M客户端之间不存在中间节点的情况。因为这个缺点，由于支持SMS作为LwM2M 1.0的传输绑定，所以存在一些安全隐患。

部署设置可以涉及中间节点（例如，代理，SMS-C，蜂窝网关），这些中间节点不一定被端点信任，并且攻击者可以从这些中间节点发起攻击。如果在LwM2M服务器和LwM2M客户端之间有些操作请求必须通过中间节点，那么必须对这些操作请求进行端到端地保护，以便保留操作和响应，请参见图6。

中间节点可以是LwM2M知道的，也可以是LwM2M不知道的。 无论LwM2M是否知道中间节点的存在，前面描述的e2e安全要求都适用。 在LwM2M知道中间节点（例如LwM2M网关）存在的情况下，可以对中间设备施加附加要求。

注意，在中间节点涉及协议转换（例如一侧是MQTT，另一侧是RESTful协议）时，映射需要忠实于LwM2M操作，并符合前面描述的端到端安全要求。必须探索新的安全解决方案来解决这些问题。

场景2：LwM2M服务器和LwM2M客户端之间的E2E安全

应用程序可能需要LwM2M节点和非LwM2M节点之间的e2e安全性。 此场景描述了这样一个用例，即应用服务器使用LwM2M操作向LwM2M客户端中的应用发起了强制安全操作的请求，但LwM2M服务器不被信任能进行读取或修改操作或响应。举例来说，LwM2M获取LwM2M客户端的位置信息这一行为可能是不可信的 - 只有应用程序应该能够请求和读取位置信息。此用例的一个基本原理是关注点分离，其中LwM2M服务器由合作伙伴托管，该合作伙伴不应有权访问LwM2M客户端上的特定资源。

应用服务器和LwM2M客户端之间的节点可以支持协议的组合，例如， 在通用设置中，应用服务器和LwM2M服务器之间的通信可以是HTTP，请参见图8。

图中？指的是可用于与应用程序服务器通信的，HTTP以外的协议。LwM2M服务器可以使用基于MQTT / AMQP / XMPP等协议的API访问应用程序服务器。

如果需要应用服务器和LwM2M客户端之间通信的端到端安全性（例如，在安全地请求LwM2M服务器不应该访问的应用层数据的情况下），那么之前描述的所有一般E2E安全要求也适用于这个案例。请注意，通信端点通常是在LwM2M客户端中运行的应用程序，该客户端可以访问LwM2M API（用于LwM2M客户端 - 服务器通信）和应用服务器API，以便与应用服务器上的应用交换消息。前面描述的所有一般性E2E安全要求都适用于此场景。

场景3：安全碎片（Secure Fragmentation）

将大量数据下载到LwM2M客户端可以用作拒绝服务（Denial-of-Service，DOS）的攻击媒介。如果客户端在整个传输完成之前无法执行任何验证，则路径上的攻击者可以注入数据，从而阻止 / 减少客户端的功能。为了缓解此威胁，服务器必须能够以安全的方式对消息进行分段，以便客户端可以在接收到时消息片段时验证片段。

此要求特别适用于固件更新。请注意，固件上的签名无法解决此问题，因为在客户端可以验证签名之前需要下载整个固件。此外，为了执行适合于特定网络的分段，进行分段的功能通常与代码库分离。一个示例设置如图5所示。

固件下载也可以在LwM2M外部执行。

场景4：LwM2M服务器和物联网设备之间的端到端安全性

此场景描述了LwM2M节点和非LwM2M节点之间的另一个e2e安全用例（比较场景2）。在这种情况下，IoT设备是强制执行LwM2M服务器请求的安全操作的非LwM2M设备，且用于读取或修改其操作或响应的传统网关不被信任。举例来说， IoT设备的数据应该可以为LwM2M服务器加密而在传统网关中不可见，参见图10.（场景1中已经涵盖了对LwM2M 1.1网关的要求）。

此用例的一个基本原理是，如果传统网关托管在不受保护的环境中，其将成为多个物联网设备的集中器，这会是一个有吸引力的攻击目标。前面描述的所有一般性E2E安全需求都适用于此方案。

图中？指的是CoAP以外的，可用于与IoT设备通信的协议。

针对新LPWAN标准的进化

LwM2M是资源受限的IoT / M2M设备中应用层的管理和数据平面。GSMA移动物联网项目组在蜂窝网络LPWAN部分提出了新的3GPP标准化协议。3GPP的移动物联网标准定义了三条类似的标准化运作的场景：EC-GSM-IoT，LTE-MTC（Cat-M1）和NB-IoT（CatNB1）。

由于其本身特点，NIDD（非IP数据传输，Non-IP Data Delivery）是有延迟的。在设备做的越来越小的情况下，对电池使用和网络使用的效率提出了更高要求。这意味着NIDD方案对于某些设备而言是有需求的。 对于像火警一样的实时关键通信，应选择具有正确的短时间超时重试的IP传递路径。

3GPP CIoT架构是在3GPP TR 23.720（TS 23.628）中描述的，其中非IP和IP路径使用的各种场景在以下附图中示出。 3GPP CIoT提供的控制平面和用户平面包括使用完整IP路径的选项。3GPP CIoT也提供最后一段使用非IP路径的选项，以使设备在传输字节数量和能量消耗（节约电量）方面更有效。

LwM2M v1_0提供最佳模型和协议能力，为IoT / M2M设备中的应用程序提供管理和数据平面需求。在LwM2M v1_0中，通过用户平面传送数据的3GPP-CIoT场景（参见图4）已经可用，并且可以与LwM2M v1_1中的新增加的内容一起使用而无需任何特定修改。作为LwM2M v1_1的一部分，通过控制平面传送数据的3GPP-CIoT场景需要引入特定要求和调整，以便在下面所示的场景中满足3GPP CIoT的新兴需求（参见控制平面传送图）。

需求（略）

Appendix A（修改历史）（略）

Appendix B（用例）（略）

注1：1.0.2文档中提出了数种用例，包括：街灯控制 / 空调控制 以及一些术语说明。
注2：1.1文档中罗列了在各大公司中使用的用例。