设计用于无缝CoAP和MQTT互操作性的代理扩展

论文标题：Designing a broker extension for seamless CoAP and MQTT interoperability（设计用于无缝CoAP和MQTT互操作性的代理扩展）

作者信息：

• Corrado Innamorati，DEIB Politecnico di Milano，Milan, Italy，corrado.innamorati@polimi.it
• Alessandro Enrico Cesare Redondi，DEIB Politecnico di Milano，Milan, Italy，alessandroenrico.redondi@polimi.it
• Matteo Cesana，DEIB Politecnico di Milano，Milan, Italy，matteo.cesana@polimi.it

论文出处：2024 IEEE 8th Forum on Research and Technologies for Society and Industry Innovation (RTSI)

---

摘要： 本文探讨了物联网（IoT）中设备和日常物品通过互联网连接的变革性范式，这种连接简化了工业流程并提高了生活质量，同时促进了创新应用的发展。然而，创建一个异构“事物”的互联网络在硬件和软件特性上提出了独特的适应挑战，尤其是在通信协议上，导致了重大的互操作性问题。本工作通过提出一种解决方案来解决这些挑战，该方案通过开发互操作性代理扩展，实现了两种广泛采用的协议——MQTT和CoAP的无缝集成。通过有效地映射REST和发布/订阅机制，该代理扩展使得使用单一代理结构的异构客户端之间能够安全、无缝地交互，消除了对额外中间件的需求。全面的测试表明，该系统在延迟和内存资源消耗方面的性能与可比，验证了该系统作为解决IoT互操作性问题的有前景的解决方案。

引言： 物联网（IoT）代表了技术和连接性的革命性范式，允许设备普遍连接。IoT的核心是赋予“事物”互联网连接能力，使它们能够收集、交换和对实时数据采取行动。这些“智能对象”覆盖了从家用电器和车辆到工业机械和医疗传感器的广泛领域，从而将IoT的能力扩展到工业物联网（IIoT）或智能城市等一系列子领域。这种技术的冲击是深远的：华为预测到2025年将有1000亿个设备连接，同年的潜在经济影响范围从3.9到11万亿美元。IoT市场的快速扩张和多样化应用导致了每种设备都需要不同的特性来最好地适应其工作环境的场景。这种多样性导致了设计和通信能力的广泛异构性，创造了一个碎片化的风景，其中IoT范式所承诺的无缝连接常常失去了其效力。这种异构性在应用层得到了反映，众多协议构成了这一画面（例如，HTTP、CoAP、MQTT、AMP）。虽然这些协议旨在导航受限的IoT环境，但它们基于不同且非标准化的原则运行，使得设备之间的通信变得复杂，并加剧了互操作性挑战。因此，互操作性成为了IoT发展中最限制和削弱的方面之一。确保IoT设备之间的顺畅连接不仅对提高其效率至关重要，而且对于在各个领域解锁IoT应用的全部潜力也至关重要。互操作性超越了简单的设备间连接；它涉及赋予它们无缝协作的能力，无论它们固有的协议或通信标准如何。这正是建议的桥接解决方案的中心，集中在MQTT和CoAP协议上，发挥关键作用。提出的解决方案提供了一种实际手段来克服互操作性挑战，并简化两种协议之间的通信，通过MQTT代理实现MQTT和CoAP协议在统一系统中的无缝集成。该架构不依赖于中间件或复杂的中介层，将MQTT代理功能扩展到CoAP环境中，确保两种协议之间的一致功能。

相关工作： 在IoT互操作性解决方案的领域中，已经探索了各种方法来应对不同协议和碎片化通信标准所带来的挑战。文献中的主要工作在[7]中进行了全面的调查，作者报告了2014-2020年间在工业物联网（IIoT）应用层协议互操作性方面进行的工作。具体来说，识别了不同的集成方法，被归类为网关、中间件、代理等。在[8]中，Collina等人介绍了QEST代理，这是一个连接MQTT和REST并提高IoT中的可扩展性和互操作性的解决方案。这项工作涉及构建一个具有MQTT和REST服务器组件的专用代理，使用Redis数据库进行数据存储。该项目后来发展成为Eclipse Ponte项目[10]，该项目通过引入发布/订阅逻辑和增强对多个数据存储单元的支持，进一步完善了代理能力，引入了对CoAP协议的支持。然而，该项目目前被归档，并且没有收到最近的更新。在[9]中，Dave等人提出了一个中间件MQTT-CoAP互连接器（MCI），它在CoAP服务器和MQTT代理之间积极操作，提供数据解析和快速翻译操作。Palavras等人介绍了用于IoT的安全多协议集成桥（SeMIBIoT）[12]，这是一个网关，允许异构客户端之间进行安全通信，支持实时翻译不同协议（包括HTTP、XMPP、MQTT和CoAP）的消息，尽管仅限于特定动作或请求。在[13]中，IOTM2B引入了一种多协议策略，其中MQTT、CoAP和HTTP等协议通过REST消息与外部目标系统（例如，云）通信，由系统的多协议功能促进。虽然现有的工作在解决互操作性问题方面取得了显著进展，但每个解决方案可能有自己的局限性或权衡，范围从系统的适应性到实施的便利性或额外的基础设施要求。

技术背景： A. MQTT MQTT是一种为受限环境设计的轻量级通信协议。最初由IBM开发，现在已成为开源OASIS标准协议。MQTT在基于代理的架构上运行，采用发布/订阅逻辑。客户端连接到中心MQTT代理以发布新消息到主题或订阅它们以获取实时更新。这种解耦的架构使得设备之间的可扩展和异步通信成为可能。MQTT代理在管理、存储和路由消息中发挥着基础作用，减轻了设备的计算和能源使用负担。通过使用保留标志在主题上存储消息：设置了保留标志的发布消息将被保留在代理的内存中，并可能传输给在发布后订阅的客户端。MQTT通常在TCP/IP上运行，支持其安全机制，并引入服务质量（QoS）级别，允许客户端指定消息的可靠性。MQTT的广泛使用得到了Java、Python和C等多种编程语言的支持。在这项工作中，选择了HiveMQ CE代理[15]作为基础，提供了一个基于Java的开源MQTT代理，具有实现自定义扩展的灵活性。

B. CoAP CoAP，或称为受限应用协议，是专为物联网（IoT）生态系统设计的标准化通信协议。由互联网工程任务组（IETF）开发，CoAP遵循RESTful架构，反映了HTTP原则。CoAP在请求-响应模型上运行，CoAP消息通常通过UDP传输以提高效率。它区分可确认和不可确认请求以确保可靠性。CoAP消息支持各种操作，包括GET、POST、PUT和DELETE，允许对IoT资源进行CRUD（创建、读取、更新、删除）操作。CoAP通过观察机制引入了对异步通信的支持，允许设备订阅资源更改并接收修改通知，而无需持续轮询。在这项工作中，CoAP实现基于Eclipse Californiun框架[17]，这是一个轻量级的Java实现CoAP协议。利用这个框架可以简单高效地使用CoAP的基本功能。此外，还纳入了Scandium等补充子模块，以增强CoAP实现的功能和能力。

MQTT-CoAP代理扩展： 本文讨论的解决方案扩展了HiveMQ MQTT代理的功能，桥接了MQTT和CoAP采用的不同通信模型：发布/订阅和请求/响应。在所提出的架构中，总结了图1，保持了MQTT的本地发布/订阅逻辑，同时设计了一个特定的CoAP-MQTT互操作性扩展来集成CoAP请求到系统中，促进CoAP和MQTT客户端之间的双向无缝连接。

A. 映射到主题 为了保持MQTT代理的基本逻辑，主题被用作通信的主要机制。相比之下，CoAP依赖于资源和URI进行寻址。为了弥合这一差距，CoAP资源被转换为MQTT主题，通过将URI路径方案映射到主题名称。一个称为“mqtt”的单一CoAP资源作为CoAP请求的入口点，有效地充当MQTT代理的网关。CoAP客户端通过在URI中指定“mqtt”资源以及代理的IP地址来访问代理。随后的URI路径级别被视为MQTT主题层次结构的一部分。为了遵循CoAP逻辑，代理使CoAP端口5683/5684可用于通信。例如，如图2所示，CoAP客户端可以向“mqtt/room/temp”资源路径发送POST请求，从而创建一个“room/temp”主题，MQTT客户端也可以访问。相反，如果MQTT客户端在“room/light”主题上发布，CoAP客户端可以访问“mqtt/room/light”URI路径来检索内容。

B. 资源发现 与MQTT不同，CoAP支持通过GET请求到“/.well-known/core”URI路径的资源发现机制。任何对此类URI的客户端请求都会触发服务器回复一个活动资源

列表，随后可以查询这些资源。为了桥接CoAP和MQTT，有必要创建一个机制来通知客户端当前活动的MQTT主题。因此，所提出的扩展维护了一个主题映射，其中包含被视为活动资源的MQTT主题，可以直接使用COAP方法访问。这些主题是（i）有关联保留消息的主题，或（ii）在特定时间阈值T内观察到更新事件（无论是MQTT PUB还是COAP POST/PUT）的主题。因此，超过T秒未观察到消息的主题被视为不活动，并从主题映射中移除。对这些不活动主题的PUT/GET/DELETE请求将触发4.04 NOT FOUND错误。当CoAP客户端对代理地址和众所周知的URI执行GET请求时，主题映射被返回，其中始终包括“mqtt”网关资源，强调与MQTT主题交互的选项。

C. CoAP请求方法映射 虽然MQTT客户端可以发布或订阅主题，但CoAP提供了四种类型的请求，GET、POST、PUT和DELETE。这些CoAP请求被适应到MQTT逻辑如下：

1. POST请求：用于用新数据创建新资源。在接收到POST请求时，扩展提取主题名称和负载，然后在识别的主题上创建发布消息。响应代码基于主题的存在是CREATED或CHANGED。发布消息的保留标志通常设置为true，以保存消息供将来的客户端使用。
2. PUT请求：与POST请求类似，它更新资源的内容，但不能创建新资源。在接收到PUT请求时，扩展提取URI和负载字段，并检查主题的存在。如果主题不存在，它以METHOD NOT ALLOWED代码响应。否则：
   • 它发送一个带有CHANGED代码的CoAP响应。
   • 在主题映射中更新时间戳。
   • 像POST案例一样发布MQTT消息。
3. DELETE请求：用于删除资源。在接收到DELETE请求时，扩展检查请求的主题是否存在，如果是肯定的：
   • 从主题映射中取消主题。
   • 发布一个带有空负载和保留标志的MQTT消息，有效地从MQTT的角度清除主题。
   • 发送一个带有DELETED代码的CoAP响应。
4. GET请求：用于检索资源的状态。扩展从URI中提取主题名称，并从主题中检索最后的保留消息。响应可以是负面的（NOT FOUND），如果请求的主题不存在或主题存在但没有保存的消息，或者是积极的（CONTENT），如果主题和保存的消息都找到了。关于服务质量级别，所有作为NONconfirmable请求发送的CoAP请求都设置为QoS=0，而可确认请求通常设置为QoS=1，确保确认机制。

D. GET观察 GET观察方法在RFC 7641[19]中引入，将CoAP架构扩展到同步结构。它允许CoAP客户端模拟SUBSCRIBE行为，接收实时通知而无需持续轮询。为了实现这种方法，我们的扩展引入了观察映射，它存储所有参与观察会话的客户端的引用数据。这个映射使用URI/主题作为键，并为每个客户端会话存储三个元素：

• 用于请求/响应的CoAP交换的引用
• 随着每次通知发送而更新的序列号
• 标记会话为活动或不活动的timestamp当客户端通过发送观察标志设置为0的GET请求发起观察会话时，系统在观察映射中创建一个新的条目，并提供信息。MQTT发布拦截器跟踪通知更新，寻找发布主题和存储在观察映射中的匹配项。如果找到匹配项，通过CoAP交换引用立即向所有观察客户端发送GET响应。相同的机制适用于来自CoAP客户端的传入POST和PUT请求，确保观察映射一致更新。如果对观察主题执行DELETE请求，观察者将收到关于主题删除的关闭通知。客户端可以对主题映射中存储的所有现有主题执行GET观察。如果请求时主题存储了保留消息，它将作为初始响应（CONTENT）发送。否则，如果主题已活动但缺少保留消息，CoAP客户端将收到一个“VALID”响应代码，表示主题处于活动状态并等待通知。为了终止关系，CoAP客户端有几种选择：
• 发送GET观察取消消息，观察标志设置为1，从观察映射中移除其信息，关闭关系，并接收最后观察到的消息作为最终响应。
• 发送带有关联令牌的RST消息，删除所有相关信息。
• 不采取行动，允许代理如果关联的时间戳超过某个阈值，则删除关系。

E. 安全实现 系统还支持安全和认证机制。由于修改后的代理作为统一系统运行，因此在代理内的MQTT和CoAP消息之间的安全性和加密是不必要的。相反，每个协议的安全是独立管理的。在MQTT方面，启用了TLS加密，并在代理的安全端口8883上实现了基于证书的认证。类似地，通过DTLS（数据报TLS）实现CoAP加密，使用PSK（预共享密钥）方法进行认证。选择PSK是因为其轻量级实现，尽管可以在我们的代理中集成替代方法。安全实现是由Californium框架的Scandium子模块促进的。

实验结果： 设计了一个测试场景，以评估代理系统在不同条件下的性能。使用基于容器的网络与Docker，多个CoAP和MQTT客户端通过扩展代理在模拟期间的一小时通信。设计了四种类型的客户端如下：

• MQTT订阅器：向多个主题发送订阅请求，并每5分钟切换订阅。
• MQTT发布器：以不同频率发送发布消息，连续消息之间的最大等待时间为5秒。
• CoAP观察者：建立对不同主题的观察关系，每5分钟切换订阅。
• CoAP发布器：以类似MQTT发布客户端的速率发送POST、PUT、GET或DELETE请求。CoAP客户端是使用Eclipse Californium框架（Java）构建的，而MQTT客户端是使用Eclipse Paho库（Python）开发的。我们为每种类型部署了五个客户端，总共有20个活跃客户端。测试阶段考虑的额外特征包括：
• 消息有效载荷有短（时间戳）或更长（超过1024字节）的大小。
• 使用安全（MQTT的TLS和CoAP的DTLS）。
• 数据包丢失条件，以增加的百分比[5%，10%，20%]对于统一分析，服务质量（QoS）级别设置为1，而在CoAP中，使用了可确认（CON）请求。为了在Docker容器内模拟数据包丢失并评估其对我们扩展的影响，使用了Pumba，这是一个用于在不利网络条件下测试Docker应用程序的开源工具[18]。总共考虑了四种模拟场景，每种场景的数据包丢失都在增加，每个场景收集数据一小时。这些总结在表1中。为了评估我们扩展的性能，延迟被选为主要指标。延迟指的是从数据包创建到接收客户端处理所需的时间。延迟基于请求类型保存，以比较不同协议之间以及同一协议内的交互性能。此外，还监控了模拟期间运行MQTT代理的Docker容器的CPU和内存性能。这些值是从运行MQTT代理的容器中每秒采样几次，以获得时间趋势。图3显示了在理想网络条件下没有数据包丢失时的平均延迟测量值。每个条形图显示了端到端延迟（从消息传输到最终接收者到达）的平均值和标准差，计算了大约20,000条发送的消息。此外，它还包括了在标准HiveMQ代理上进行的MQTT通信的基准往返时间（RTT）测量值，仅供参考。尽管延迟测量反映了扩展代理处理的影响，但值得注意的是，性能仍与基准水平相当。这一观察表明，尽管增加了额外的处理开销，扩展代理的性能被认为是满意的。这一评估特别重要，因为考虑到扩展代理在实现CoAP-MQTT交互中发挥的关键作用，否则这些交互是不可能实现的。更详细的检查揭示了几个具体观察结果：
• 除了基准MQTT场景（蓝色）之外，表现第二好的是MQTT到COAP（观察）路径（红色）。这是因为我们的实现如果发布主题与观察映射中的任何主题匹配，直接将MQTT消息转发到Californium模块。
• 当发送更长的有效载荷时，延迟增加是显而易见的，特别是在涉及CoAP的场景中。这种延迟激增主要是由于碎片问题，导致在CoAP框架内传输的数据包数量更多。
• 尽管实施了安全机制，如加密和认证，但延迟仍然在可接受的范围内。因此，安全措施并没有显著恶化延迟。当数据包丢失增加时，正如预期的那样，延迟性能趋于恶化，与我们之前的预期一致。然而，之前观察到的总体行为仍然得到确认。图4显示了在没有安全措施的情况下报告的延迟，显著地表明MQTT和CoAP之间的通信流程受到严重干扰，特别是随着有效载荷的增加和数据包丢失的增加，强调了碎片化的影响。由于它们没有表现出显著变化，因此没有报告具有安全措施的结果。通过监控整个模拟期间运行MQTT代理的Docker容器的内存和CPU使用数据，进行了资源消耗评估。图5显示了在理想网络条件下获得的平均结果。初步观察发现内存消耗保持有限，介于总专用内存（15.61 GB）的2-2.6%之间。由于流量增加和信息

  处理需求增加，这个值随着时间的推移略有增加。平均CPU使用率保持在20%以下，尽管偶尔观察到更高的消耗峰值。这些峰值通常与代理执行的密集操作同时发生，例如自动查找主题映射或观察映射，或者大多数订阅（SUB）客户端在预定义间隔后同时进行的订阅/观察切换。

  结论和未来工作： 在物联网（IoT）协议的广阔领域中，互操作性是一个关键组成部分，促进了设备的无缝连接和有效管理。我们对两种广泛使用、标准化的IoT协议MQTT和CoAP的关注揭示了双向通信缺乏标准化和高效解决方案的问题。本研究中提出的CoAP-MQTT扩展代理通过增强互操作性，提供了实时相互通信和无缝连接。此外，它集成了两种协议的安全机制和基本功能。我们的实验表明，系统的性能与基准MQTT解决方案相当，仍然提供创新的互操作性特性和易于部署的架构，对最终用户保持透明。就未来发展而言，我们的工作旨在进一步增强系统的能力，例如使MQTT客户端能够通过代理访问外部CoAP资源，扩大互操作性的可能性。此外，我们计划优化架构，探索多代理场景中的负载均衡，并研究边缘/云交互。进行压力测试将提供对我们代理性能与其他现有解决方案的更全面分析，促进IoT互操作性的持续进步