基于CoAP协议可靠组通信系统的设计及实现

魏更宇+郭雨萌

摘 要：为了解决资源受限传感器网络中的CoAP协议组通信不可靠性的问题，采用基于代理服务器的方式，给出了CoAP协议可靠组通信系统的设计方案，并通过仿真系统模拟实现了此方案。针对接收端节点数量的不同，分别采用基于代理服务器和单播重传的方式实现了该系统的构建，为CoAP协议可靠组通信方案的构建提供了理论模型和架构基础。

关键词：CoAP;组通信;可靠性;代理;多播

中图分类号：TP316         文献标识码：             文章编号：2095-1302（2014）12-00-04

0  引  言

物联网中包括了传统的互联网和主要由传感器节点组成的资源受限网络，而在互联网络中普遍使用的应用层协议HTTP不能够适用于受限网络环境，因此就需要引入一个新的通信协议针对资源受限网络进行通信。在这一背景下，互联网工程任务组（Internet Engineering Task Force，IETF）成立了CoRE[1]工作组，负责定义受限网络中的应用层通信协议——CoAP协议。

CoAP协议将实现资源受限节点间的有效信息传输作为基本目标，其定义了在两个传感器之间以单播方式传输的通信控制协议，能够实现M2M的可靠消息传递。同时，CoAP协议也定义了针对传感器节点之间的组通信协议。

然而，目前的CoAP组通信是基于IP组播[2]协议，其仅能实现不可靠的组通信。具体而言，比照OMA （OPEN MOBILE ALLIANCE， 开放移动联盟）提出的轻量级M2M应用的需求和架构文档，组通信可靠性没有保障的CoAP协议不能够满足OMA针对应用的需求。在OMA提出的应用场景中，如果使用CoAP协议的不可靠组通信，将会对其定义的应用场景带来极大的隐患。

1  IETF 关于CoAP及其组通信的介绍

1.1  CoAP协议

CoAP协议是一种应用于受限网络和节点的特殊Web传输协议，在应用终端间提供方法/响应的交互模式，支持内置的资源发现，包含关键的网络概念，比如URIs和Content-type。CoAP协议类似于HTTP协议[3]，但不是简单地对HTTP进行压缩，而是重新实现了一个类似HTTP的REST子集[4]，以适应资源受限环境[5]。

CoAP协议在资源受限网络中所起的作用类似于HTTP协议[6]在互联网中所起的作用。其基于UDP传输的方式，可明显降低传输开销，并可满足CoAP请求的组通信传递，而组通信对于M2M应用是最重要的需求之一。

1.2  CoAP组通信

CoAP协议构建在UDP协议之上，用以减少开销且支持组通信[5]。由于UDP协议的特性，即不保证数据传输的可靠性，导致CoAP协议虽然支持组通信，但不保证数据传输的可靠性和有序性。这一特性，在某些特定应用场景中会为用户针对设备的操作带来隐患和非便利因素，若用户想同时针对多个接收端进行可靠的控制，则其必须使用逐一控制的方式实现这一功能，否则将有可能导致部分接收端并未按照用户的意愿执行相应的操作，这在实际应用中是不能被接受的。

基于以上原因，本文提出了几种用于CoAP可靠组通信设计的方案，针对不同规模的数据集使用不同的方法，解决CoAP协议的这一缺陷。

2  OMA的M2M应用需求及分析

2.1  基于传感器网络的路灯管理系统应用场景

某用户是一个街区路灯系统的管理员，负责管理其所在街区的所有路灯状态的变更及维护。为了更好、更快地实现针对路灯的控制，该用户将低成本的M2M传感器嵌入在这些路灯中，并通过一个路灯远程控制器针对这些传感器进行操控。

针对这一场景，需要实现以下几方面的功能：用户具备远程开、关特定路灯的能力，包括一次操控一个路灯和一次操控多个路灯;用户能够实时、准确地知道每个路灯的现有状态;确保这些路灯只接受授权用户的指令，杜绝可能存在的安全隐患。

通过以上描述，可以构建一个基于物联网的路灯控制系统，如图1所示。

图 1  基于传感器网络的路灯管理系统

2.2  针对OMA应用场景的需求分析

通过针对上述应用场景的需求分析，将一次完整的针对M2M传感器的控制操作流程概括如下：

（1）用户通过远程控制器接入互联网，指令通过HTTP协议得以传输。

（2）当该指令到达终端设备组成的传感器网络时，通过HTTP协议和CoAP协议相互转换的功能，实现针对指令的报文封装和转换，将互联网中的HTTP报文[3]封装为CoAP报文。

（3）经过封装转换后的信息通过CoAP协议在传感器网络中进行传输，最终到达各个设备上的M2M传感器，实现用户设计的既定操作。

在这一过程中，欲实现用户提出的几项功能，需具备远程操控特定设备的能力，而CoAP协议目前尚仅能满足针对单播的可靠传输，其针对组通信传输尚不能保证可靠性。这一限制条件就导致了当用户想要同时针对多个设备进行控制时，会面临以下几点问题：

（1）若想实现针对多个设备的可靠控制，则只能采用用户逐一针对设备进行操控的方式，利用CoAP协议针对单播可实现可靠传输这一特性实现该操作。

（2）若想一次性地通过组通信实现针对设备的控制，则CoAP协议目前的传输机制将会为此操作埋下隐患，即部分设备可能会因CoAP协议组通信传输的不可靠性致使其没有按照用户的要求进行相应的操作，这在OMA设定的应用场景中是不能为用户所接受的。

综上所述，针对不同规模的用户数集群数量，需实现的功能中皆包含针对设备的可靠单播通信和可靠组播通信。而作为传感器网络重要传输协议之一的CoAP协议，目前尚还只能实现针对单播的可靠通信，而其针对组通信不可靠传输的这一问题将会在诸如以上场景的实际应用中产生巨大的隐患。

3  CoAP可靠组通信方案设计

3.1  逐一单播方案

为了解决CoAP协议组通信不可靠的问题，根据接收端数量的多少，可以采用不同的传输方式加以解决。当控制的接收端数量小于预设值Vs时（Vs值由用户事先根据实际情况加以设定，用以判断接收端数量的多少，决定采用何种发送方式），考虑到实际的发送效率及运营成本，可以采用多个单播的形式实现组通信的功能，具体实现方式如下：

发送端以CoAP单播的形式向每个接收端发送命令。在接收端接收到信息后，会立即发送一个Request响应信息到发送端。经过一个固定延迟△t1后（△t1值根据接收端反馈信息所需花费的平均时间乘以系数m确定），未发送Request响应的接收端，即被判定为接收失败或是Request响应在传输过程中出现了意外。此时，发送端针对这些被判定为接收失败或是Request响应在传输过程中出现问题的接收节点再次重复发送该信息。重复以上过程，直到最终所有的接收端都成功返回Request信息为止，此次组通信发送即宣告完成。

以上这种基于CoAP逐一单播的形式进行传输的要求是，接收端数量小于预设值Vs，如图2所示。

图2  小规模接收端数量

3.2  基于代理的可靠组通信实现方式

3.2.1  逐一单播方案的局限性

通过逐一单播实现CoAP可靠组通信的方式，其优点是实现简便，成本较低;而其缺点则是操作过程繁琐，且仅适用于接收端数量较小时使用。

当系统中的接收端数量较多时，若继续采用通过多个单播重复发送实现这一功能，则易导致出现以下几个问题：

（1）接收端接收到信息的时间间隔过大。

（2）易产生发送端拥塞[8]问题。

（3）操作过程繁琐。

基于以上三点原因，当接收端数量较大时，需要另一种更为高效可靠的方式解决CoAP组通信不可靠的问题。由此，本文将会介绍一种基于代理（Proxy）[9]的方式实现CoAP可靠组通信的方案，这一方案可以较好地同时解决上述三个问题。

图3  大规模接收端数量

如图3所示，在这种基于代理的CoAP可靠组通信传输系统中，除发送端和接收端以外，还需要引入一个代理服务器针对报文进行中转、判定和重传操作，以减轻发送端的拥塞[8]压力，同时也能更好、更快地实现针对报文的重传操作。

此种基于代理的可靠组通信传输方式[10]，具体而言可以分为以下几个步骤。

3.2.2  发送过程

基于代理的CoAP可靠组通信的发送过程分为以下几步：

（1）由发送端通过CoAP单播的形式，将消息发送给代理服务器。

（2）代理服务器将该消息报文解析后，获取到本次发送的实际接收端的地址。

（3）代理服务器将此报文进行整理封装，通过CoAP组通信的形式发送给上述解析出的接收端地址。

同一时间，代理服务器将这些接收端的地址加以记录，建立一个布尔数组，用以记录后续的接收状态，如图4所示。

图4  代理服务器的布尔数组

3.2.3  接收端匹配及反馈过程

在发送过程结束后，接收端结点接收消息报文的过程可分为以下几步：

接收端接收到由代理服务器发出的消息报文后，根据报文中的目标地址进行匹配，若匹配成功则加以接收;匹配成功的接收端针对报文中的内容进行解析，并根据报文内容完成对应的操作;由完成以上两步操作的部分接收端向代理服务器发送反馈信息，在这一过程中，为保证传输过程的可靠性，这一反馈消息需采用CoAP单播加以实现。

3.2.4  代理服务器处理反馈并重传信息

完成了接收端匹配及反馈过程后，代理服务器需针对反馈信息进行分析处理，并根据需求进行重传操作，这一过程可分为以下几步：

代理服务器针对收到的众多接收端发送来的反馈信息，根据众接收端的地址和编号，针对其在发送步骤时创建的代表接收端状态的布尔数组进行状态变更。

在经过了一个预设好的时间△t3后，代理服务器针对状态布尔数组进行遍历，针对其中尚未变更状态的数组单元即代表该接收端并未成功接收到代理服务器之前所发来的信息或是发送反馈信息失败。此时，由代理服务器将之前的信息报文再次重传给这些被判定为接收失败的接收端。

重传时，需要根据本次重传中接收端的数量进行判断，若接收端数量小于Vs值，则采用逐一单播的形式进行发送;若接收端数量大于等于Vs值，则继续采用组通信的形式进行发送，后续反馈过程同本次反馈过程。

状态变更失败或反馈信息发送失败的接收端，在接收到由代理服务器发送来的重传信息后，按照报文中的内容进行相应的操作，并将成功变更的信息反馈给代理服务器。

重复以上步骤，直到代理服务器中的状态布尔数组全部完成变更，即本次组通信操作成功。

完成以上4步后，代理服务器需通过CoAP单播反馈给发送端一个确认信息，确认本次发送成功。

3.2.5  发送连贯性

在以上步骤进行的过程中，发送端可以继续发送后续命令，由于代理服务器的处理能力相比发送端较为优越，因此处理发送端重传的功能由代理服务器完成，发送端在这一过程中可进行连贯发送。

3.2.6  基于代理的可靠组通信流程图

基于代理的可靠组通信流程图如图5所示。

图5  CoAP协议基于代理的可靠组通信传输流程图

3.3  特殊状况处理

3.3.1  结点睡眠

当接收端结点即将处于睡眠模式时，需要进行以下几个步骤的操作：

接收端向CoAP资源目录服务器发送一个消息，告知其关于自身状态变更的消息;CoAP资源目录服务器收到这一信息后，向代理服务器发送一个消息，告知后者该结点处于睡眠状态;当代理服务器进行消息发送时，若查阅自身数据库得知某结点已处于睡眠状态，则需先发送一个睡眠唤醒消息，将这些结点唤醒，之后再针对该结点进行消息发送。

3.3.2  结点关机或供电不足

当接收端结点即将关机（供电不足或人工关机）时，需要进行以下几个步骤的操作：

接收端向CoAP资源目录服务器发送一个消息，告知其关于自身即将关机的消息;CoAP资源目录服务器收到这一信息后，向代理服务器发送一个消息，告知后者该结点处于关机状态;当代理服务器进行消息发送时，若查阅自身数据库得知某结点已处于关机状态，则暂时保留本要发送的数据。当CoAP资源目录服务器告知代理服务器关于该结点重新开机时，代理服务器再将本要发送消息发送给该结点。

4  仿真实现CoAP可靠组通信

基于上文介绍的CoAP可靠组通信应用方案，利用JAVA仿真构建了一个基于代理的CoAP可靠组通信模拟系统，该系统可实现基于代理的模拟CoAP组通信。

图6  仿真实现CoAP可靠组通信

该通信的规则为：由发送端将报文发送至代理服务器，代理服务器根据其中的接收端数量判定是何种方式进行重传。经大量实验证明，当接收端数量大于Vs时采用CoAP组通信，当接收端数量小于等于Vs时采用CoAP单播通信如某次组通信发送后出现了接受失败的节点，则会针对其进行重传，重传的方式同样由接收端数量来决定。重复以上步骤，直至所有接收端节点都顺利接收到该报文，此次发送结束。

5  结  语

目前互联网工程任务组的Core工作组给出的CoAP协议草案中尚未提出针对CoAP组通信不可靠性的有效解决办法。而在OMA 等提出的应用场景中，CoAP协议由于其不可靠组通信这一特性将不能胜任此类应用场景对传输协议所提出的需求。

基于以上背景，本文利用CoAP协议的基本特性，构建了针对不同规模接收端数量的两类传输方式的可靠组通信理论模型，即基于代理服务器和逐一单播的形式实现CoAP可靠组通信。在构建理论模型的基础上，本文还进一步通过程序搭建了CoAP协议可靠组通信模拟系统，在该系统中真实模拟了CoAP组通信的全过程，清晰而直观地将CoAP可靠组通信的实现方案呈现于该系统中。通过理论模型的构建和模拟系统的架构，为后续研究CoAP协议可靠组通信奠定了良好的理论基础。

参考文献

[1] IETF. Constrained RESTful Environments（coRE） [EB/OL].http：//datatracker.ietf.org/wg/core/charter/，2012.

[2] Deering S.Multicast Routing in Internetworks and extended LANs[J].ACM Transaction on Computer Systems，1990， 8（2）：85-110

[3] FIELDING R，GETTYS J， MOGUL J，et al.RFC 2616 – Hypertext Transfer Protocol--HTTP/1.1[S].1999.

[4]ZTE.深入浅出REST[EB/OL].http：//www.infoq.com/cn/articles /rest-introduction /，2012.

[5]刘紫青，程燕，关联，等.CoAP 协议研究[J].电视技术，2013，37（ 7）：192-196

[6]苏勇.深入理解HTTP协议[EB/OL].http：//www.blogjava.net/zjusuyong/articles/304788.html，2012.

[7] CoRE Working Group. Constrained Application Protocol（CoAP draft-ietf-core-coap-13）[EB/OL].http：//download.csdn.net /detail/luoqiuzeng/5076830，2012.

[8] IETF. Congestion Control for the Constrained Application Protocol（CoAP draft-eggert-core-congestion-control-03）[EB/OL].http：//tools. ietf. org/id/draft-ietf-core-coap-03. html，2012.

[9] Lao L，Cui J H，Gerla M，et al .A Comparative Study of Multicast Protocol：Top，Bottom，or In the Middle[C]. MIEEE INFOCOM.Barcelona，2006

[10] Jannotti J， Gifford D K， Johnson K L， et al.Over cast：Reliable multicast with an overlay network[C] The 4th Usenix Symposium on Operating System Design and Implementation （OSDI）.Denver， 2000

3.2.6  基于代理的可靠组通信流程图

基于代理的可靠组通信流程图如图5所示。

图5  CoAP协议基于代理的可靠组通信传输流程图

3.3  特殊状况处理

3.3.1  结点睡眠

当接收端结点即将处于睡眠模式时，需要进行以下几个步骤的操作：

接收端向CoAP资源目录服务器发送一个消息，告知其关于自身状态变更的消息;CoAP资源目录服务器收到这一信息后，向代理服务器发送一个消息，告知后者该结点处于睡眠状态;当代理服务器进行消息发送时，若查阅自身数据库得知某结点已处于睡眠状态，则需先发送一个睡眠唤醒消息，将这些结点唤醒，之后再针对该结点进行消息发送。

3.3.2  结点关机或供电不足

当接收端结点即将关机（供电不足或人工关机）时，需要进行以下几个步骤的操作：

接收端向CoAP资源目录服务器发送一个消息，告知其关于自身即将关机的消息;CoAP资源目录服务器收到这一信息后，向代理服务器发送一个消息，告知后者该结点处于关机状态;当代理服务器进行消息发送时，若查阅自身数据库得知某结点已处于关机状态，则暂时保留本要发送的数据。当CoAP资源目录服务器告知代理服务器关于该结点重新开机时，代理服务器再将本要发送消息发送给该结点。

4  仿真实现CoAP可靠组通信

基于上文介绍的CoAP可靠组通信应用方案，利用JAVA仿真构建了一个基于代理的CoAP可靠组通信模拟系统，该系统可实现基于代理的模拟CoAP组通信。

图6  仿真实现CoAP可靠组通信

该通信的规则为：由发送端将报文发送至代理服务器，代理服务器根据其中的接收端数量判定是何种方式进行重传。经大量实验证明，当接收端数量大于Vs时采用CoAP组通信，当接收端数量小于等于Vs时采用CoAP单播通信如某次组通信发送后出现了接受失败的节点，则会针对其进行重传，重传的方式同样由接收端数量来决定。重复以上步骤，直至所有接收端节点都顺利接收到该报文，此次发送结束。

5  结  语

目前互联网工程任务组的Core工作组给出的CoAP协议草案中尚未提出针对CoAP组通信不可靠性的有效解决办法。而在OMA 等提出的应用场景中，CoAP协议由于其不可靠组通信这一特性将不能胜任此类应用场景对传输协议所提出的需求。

基于以上背景，本文利用CoAP协议的基本特性，构建了针对不同规模接收端数量的两类传输方式的可靠组通信理论模型，即基于代理服务器和逐一单播的形式实现CoAP可靠组通信。在构建理论模型的基础上，本文还进一步通过程序搭建了CoAP协议可靠组通信模拟系统，在该系统中真实模拟了CoAP组通信的全过程，清晰而直观地将CoAP可靠组通信的实现方案呈现于该系统中。通过理论模型的构建和模拟系统的架构，为后续研究CoAP协议可靠组通信奠定了良好的理论基础。

参考文献

[1] IETF. Constrained RESTful Environments（coRE） [EB/OL].http：//datatracker.ietf.org/wg/core/charter/，2012.

[2] Deering S.Multicast Routing in Internetworks and extended LANs[J].ACM Transaction on Computer Systems，1990， 8（2）：85-110

[3] FIELDING R，GETTYS J， MOGUL J，et al.RFC 2616 – Hypertext Transfer Protocol--HTTP/1.1[S].1999.

[4]ZTE.深入浅出REST[EB/OL].http：//www.infoq.com/cn/articles /rest-introduction /，2012.

[5]刘紫青，程燕，关联，等.CoAP 协议研究[J].电视技术，2013，37（ 7）：192-196

[6]苏勇.深入理解HTTP协议[EB/OL].http：//www.blogjava.net/zjusuyong/articles/304788.html，2012.

[7] CoRE Working Group. Constrained Application Protocol（CoAP draft-ietf-core-coap-13）[EB/OL].http：//download.csdn.net /detail/luoqiuzeng/5076830，2012.

[8] IETF. Congestion Control for the Constrained Application Protocol（CoAP draft-eggert-core-congestion-control-03）[EB/OL].http：//tools. ietf. org/id/draft-ietf-core-coap-03. html，2012.

[9] Lao L，Cui J H，Gerla M，et al .A Comparative Study of Multicast Protocol：Top，Bottom，or In the Middle[C]. MIEEE INFOCOM.Barcelona，2006

[10] Jannotti J， Gifford D K， Johnson K L， et al.Over cast：Reliable multicast with an overlay network[C] The 4th Usenix Symposium on Operating System Design and Implementation （OSDI）.Denver， 2000

3.2.6  基于代理的可靠组通信流程图

基于代理的可靠组通信流程图如图5所示。

图5  CoAP协议基于代理的可靠组通信传输流程图

3.3  特殊状况处理

3.3.1  结点睡眠

当接收端结点即将处于睡眠模式时，需要进行以下几个步骤的操作：

接收端向CoAP资源目录服务器发送一个消息，告知其关于自身状态变更的消息;CoAP资源目录服务器收到这一信息后，向代理服务器发送一个消息，告知后者该结点处于睡眠状态;当代理服务器进行消息发送时，若查阅自身数据库得知某结点已处于睡眠状态，则需先发送一个睡眠唤醒消息，将这些结点唤醒，之后再针对该结点进行消息发送。

3.3.2  结点关机或供电不足

当接收端结点即将关机（供电不足或人工关机）时，需要进行以下几个步骤的操作：

接收端向CoAP资源目录服务器发送一个消息，告知其关于自身即将关机的消息;CoAP资源目录服务器收到这一信息后，向代理服务器发送一个消息，告知后者该结点处于关机状态;当代理服务器进行消息发送时，若查阅自身数据库得知某结点已处于关机状态，则暂时保留本要发送的数据。当CoAP资源目录服务器告知代理服务器关于该结点重新开机时，代理服务器再将本要发送消息发送给该结点。

4  仿真实现CoAP可靠组通信

基于上文介绍的CoAP可靠组通信应用方案，利用JAVA仿真构建了一个基于代理的CoAP可靠组通信模拟系统，该系统可实现基于代理的模拟CoAP组通信。

图6  仿真实现CoAP可靠组通信

该通信的规则为：由发送端将报文发送至代理服务器，代理服务器根据其中的接收端数量判定是何种方式进行重传。经大量实验证明，当接收端数量大于Vs时采用CoAP组通信，当接收端数量小于等于Vs时采用CoAP单播通信如某次组通信发送后出现了接受失败的节点，则会针对其进行重传，重传的方式同样由接收端数量来决定。重复以上步骤，直至所有接收端节点都顺利接收到该报文，此次发送结束。

5  结  语

目前互联网工程任务组的Core工作组给出的CoAP协议草案中尚未提出针对CoAP组通信不可靠性的有效解决办法。而在OMA 等提出的应用场景中，CoAP协议由于其不可靠组通信这一特性将不能胜任此类应用场景对传输协议所提出的需求。

基于以上背景，本文利用CoAP协议的基本特性，构建了针对不同规模接收端数量的两类传输方式的可靠组通信理论模型，即基于代理服务器和逐一单播的形式实现CoAP可靠组通信。在构建理论模型的基础上，本文还进一步通过程序搭建了CoAP协议可靠组通信模拟系统，在该系统中真实模拟了CoAP组通信的全过程，清晰而直观地将CoAP可靠组通信的实现方案呈现于该系统中。通过理论模型的构建和模拟系统的架构，为后续研究CoAP协议可靠组通信奠定了良好的理论基础。

参考文献

[1] IETF. Constrained RESTful Environments（coRE） [EB/OL].http：//datatracker.ietf.org/wg/core/charter/，2012.

[2] Deering S.Multicast Routing in Internetworks and extended LANs[J].ACM Transaction on Computer Systems，1990， 8（2）：85-110

[3] FIELDING R，GETTYS J， MOGUL J，et al.RFC 2616 – Hypertext Transfer Protocol--HTTP/1.1[S].1999.

[4]ZTE.深入浅出REST[EB/OL].http：//www.infoq.com/cn/articles /rest-introduction /，2012.

[5]刘紫青，程燕，关联，等.CoAP 协议研究[J].电视技术，2013，37（ 7）：192-196

[6]苏勇.深入理解HTTP协议[EB/OL].http：//www.blogjava.net/zjusuyong/articles/304788.html，2012.

[7] CoRE Working Group. Constrained Application Protocol（CoAP draft-ietf-core-coap-13）[EB/OL].http：//download.csdn.net /detail/luoqiuzeng/5076830，2012.

[8] IETF. Congestion Control for the Constrained Application Protocol（CoAP draft-eggert-core-congestion-control-03）[EB/OL].http：//tools. ietf. org/id/draft-ietf-core-coap-03. html，2012.

[9] Lao L，Cui J H，Gerla M，et al .A Comparative Study of Multicast Protocol：Top，Bottom，or In the Middle[C]. MIEEE INFOCOM.Barcelona，2006

[10] Jannotti J， Gifford D K， Johnson K L， et al.Over cast：Reliable multicast with an overlay network[C] The 4th Usenix Symposium on Operating System Design and Implementation （OSDI）.Denver， 2000