- 1 -
基于受限网络的睡眠节点通信的研究
赵晨，魏更宇**
（北京邮电大学计算机学院，北京 100876）
5 摘要：由于物联网中受限节点及受限网络自身的限制，HTTP已经不适合用作受限网络中获
取资源的协议。所以 IETF CoRE工作组为物联网制定了适合受限网络及受限节点通信的受
限应用协议 CoAP。但物联网中有许多受限节点在大多时候是处于睡眠状态的，而 CoAP协
议只提供了受限节点基本通信模块并不提供对资源的发现和睡眠节点通信的支持。本文在实
现 CoAP协议的基础上，深入分析受限网络中资源发现的过程，然后借助资源目录服务器，10
提出受限网络中睡眠节点无法通信问题的解决方案，改善了客户端无法访问睡眠节点上资源
的问题以及受限网络利用率低下的问题。最后本文对在 NS3 实验结果进行分析，然后针对
分析结果对受限网络中睡眠节点的通信提出了一些优化的建议。
关键词：CoAP；资源目录服务器；受限网络；资源发现；睡眠节点
中图分类号：[] 15
Research on Communication of Sleeping Node in
Constrained Network
ZHAO Chen, WEI Gengyu
(School of Computer,Beijing University of Posts and Communications,Beijing 100876) 20
Abstract: HTTP is not suitable for communication in constrained environment due to the limited
node and the limited network. So the IETF CoRE working group draw up the constrained
application protocol(CoAP) for this solution. But CoAP just implements the basic communication
module but provides no support of the resource discovery and the communication of sleeping node.
Based on the CoAP protocol, this paper deeply discuss the main process of resource discovery in 25
constrained situation, and then come up with a solution of the of sleeping node communication
problem and analysis the result at the same time. Finally, the paper give some personal advice
about the communication of sleeping nodes.
Key words: CoAP; Resource Directory; Limited Network; Resource Discovery; Sleepy Node
30
0 引言
物联网（Internet of Things, IoT）中的节点大多数是由纽扣电池供电，且具有能源受限、
处理能力弱、存储容量小的特点而被称为受限节点；而它们所在的网络也因传输速率较低、
出错率较高而被称为受限网络。由于受限网络传输能力差以及受限节点处理能力较低的特
点，传统互联网中普遍使用的 HTTP[1]协议被普遍认为不适用于资源受限网络中，而暴涨的35
物联网节点也会给当前 DNS 带来灾难性压力。所以 IETF CoRE（Constrained Restful
Environment）工作组提出了适用于受限节点的受限网络通信协议 CoAP[2]（Constrained
Application Protocol）。由于能源的限制，绝大多数受限节点会在大多时候处于睡眠状态，
但 CoAP只提供了受限节点的基本通信模块而并没有提供对睡眠节点访问的支持，而且国内
也极少有人科研或商业机构对此做深入研究，所以受限场景迫切需要一个方案来解决此问40
题。本文在实现 CoAP协议的基础上，研究了资源目录服务器。然后借助资源目录服务器，
本文针对受限网络中睡眠节点通信问题以及因此导致的网络利用率低下的问题提出了可行
- 2 -
的解决方案并对方案进行了实施，对结果进行统计分析。
论文的章节安排为：第 1章介绍及受限网络协议 CoAP并讨论资源发现的详细过程；第
2 章提出受限网络中睡眠节点的问题并结合资源目录服务器实际情况和睡眠节点资源的特45
点给出不同情况下的解决方案并对结果进行分析；第 3章对方案进行模拟测试，并对结果进
行统计并分析。第 4章对论文工作进行总结。
1 CoAP及资源目录服务器
受限网络协议 CoAP
CoAP是一种应用于受限网络和节点的支持 REST架构的资源传输协议。它采用了双层50
的结构：事务层(Transaction layer)处理节点间的信息的交换，同时保证可靠传输；请求/响应
层(Request/Response layer)用以传输对资源进行操作的请求和响应信息，CoAP协议的 REST
构架就是基于该层的通信。CoAP的双层处理方式，使得 CoAP即使没有采用可靠的 TCP协
议作为传输层，也可以提供可靠的传输机制：CoAP利用定时器和指数增长的重传间隔时间
实现了可靠消息的重传，直到接收方发出确认消息。同时 CoAP支持拥塞控制[8]、组通信[10]55
和块传输模式[4]。另外，CoAP 的双层处理方式支持异步通信，这是物联网和 M2M 应用的
关键需求之一。
CoAP协议在很大程度上借鉴了 HTTP协议成功的经验，但 CoAP并不是盲目的压缩了
HTTP协议，考虑到资源受限设备的低处理能力和低功耗限制，CoAP重新设计了 HTTP的
部分功能以适应设备的受限条件。图 1显示了 HTTP和 CoAP的协议栈，可以看出 CoAP和60
HTTP在传输层有明显的区别：HTTP协议的传输层采用了 TCP协议，而 CoAP协议的传输
层选择了非可靠性 UDP协议，这样开销明显降低，并且支持多播。
图 1 HTTP和 CoAP的协议栈
The protocol stack of HTTP and CoAP 65
资源目录服务器工作过程
由于膨胀的物联网节点将会给当前 DNS 带来灾难性后果，所以受限网络中不再使用
DNS来进行资源发现而是使用资源目录服务器来实现此目的，即资源目录服务器（Resource
Directory Server，下文简称 RDS）完成受限网络中域名转换的功能。为了进行资源发现，每
个受限网络域中都需要有一个以上的 RDS，RDS 不是受限节点，我们假定他有足够的资源70
来处理各种请求。RDS工作的过程大致可分为两大步：第一，CoAP Server发现 RDS并向
RDS注册、更改、删除其资源描述；第二，响应其他受限节点或代理的查询。
第一部分可细分为以下几步：
1. 当一个 CoAP Server加入到网络时首先会使用Web Link [7]广播发送服务器发现消息，找
到域内 RDS的注册接口信息。 75
2. 根据 RDS返回的地址和接口信息，使用 POST方法向 RDS发出注册信息，信息主要包
- 3 -
中国科技论文在线
括节点属性（节点的域名，节点 IP地址等）及节点所包含的资源属性（资源类型、资
源描述、资源包路径等）的简单描述。
3. 如果 CoAP Server中资源发生了变化，CoAP Server还要负责使用 PUT方法来更新 RDS
中的注册信息。 80
4. 如果 CoAP Server中的资源信息失效了，CoAP Server还要负责使用 DELETE方法来删
除 RDS中的注册信息。
RDS 主要目的是响应资源的查询。我们假设一个域内的 RDS 维持了域内所有 CoAP
Server的资源描述信息。如果现在一个 HTTP客户端要请求某一个节点上的资源信息，则系
统的工作流程如下： 85
1. 客户端节点向 RDS发送请求。
2. RDS根据请求信息获取被请求节点的各种信息（节点名称、IP地址、URI、资源描述信
息等），并将信息返回给客户端。
3. 客户端根据返回的信息直接与 CoAP Server进行通信。
整体通信见图 2： 90
CoAP Server 1
RDS
CoAP Server n
... Proxy
(Get)
2. Registration (Post)
[Update (Put)]
[Remove (Delete)]
Http Client
CoAP Req
CoAP Rsp(ip+rsc dsp)
Http Req
Http Rsp (ip dsp)
Req Resource Statement
Rsp Resource Statement
图 2 RDS工作流程图
The process of RDS
2 睡眠节点的处理
睡眠节点[5]是受限网络中节点通信必须要解决的问题之一。受限网络中节点通常会受到95
电源的限制，它们需要用一颗纽扣电池持续工作数年，而它们自身大部分时间是不需要进行
通信的。基于以上两点，受限节点会选择在不需要通信的时候进入睡眠状态，只有受到了事
件的驱动它们才会被唤醒。所以受限节点的大多数时候是处于休眠状态的，换句话说，受限
网络中的节点在同一时间，大多数是处于休眠状态的。节点处于休眠状态时，通信接口处于
关闭状态，既不能向别的节点发出消息，也无法收到别的节点发来的消息。但在一个受限网100
络中，节点并不知道彼此的状态，所以会出现一个节点向一个睡眠中的节点请求资源的情况。
鉴于同一时刻网络中大部分的节点是处于休眠状态的，所以这种向休眠节点请求资源的现象
会大量存在，因此必须对此提出一个解决方案。
方案的主要思路是在受限域中使用资源目录服务器做资源代理服务器（下文简称代理服
务器）。本文首先把资源分为可代理资源和不可代理资源两种。可代理资源一般为普通资源，105
如温度传感器，此类资源是可以被放置到代理服务器上，当资源状态发生变化时睡眠节点需
要实时更新代理服务器上的资源的状态信息即可；不可代理资源则是一些安全级别较高的资
源，出于安全问题的考虑，这些资源不能被放在代理上，而只能通过代理来访问节点来获取。
代理服务器对这两种情况的处理是不一样的。在描述解决方案前，本文需要做一些约定：
- 4 -
中国科技论文在线
1. 域中都有一个以上的代理服务器，每个代理服务器都是非受限资源，包括能源充足，内110
存充足、CPU可以处理以下论述的操作。
2. 受限域中的睡眠节点必须在状态发生变化时第一时间向代理服务器上报最新状态。
3. 节点之间通信必须经过代理，不能直接通信。
可代理资源
睡眠节点通过特定接口发现代理服务器，然后向代理服务器注册并初始化自己的资源信115
息。此后，每当节点资源状态发生变化，节点会同步更新代理上对应的资源信息以维持资源
信息的实时性。这样，当节点睡眠的时候，客户端可以通过查询代理服务器上的资源状态来
获取睡眠节点的资源信息。系统整体工作流程如图 3所示。
Sleepy Node Proxy
发现
注册
初始化
更新
删除
Client
响应
请求
图 3 proxy工作流程（可代理资源） 120
The process of Proxy（for resource representable）
睡眠节点向代理服务器注册和维护的过程和资源目录服务器工作过程很相似，唯一的区
别在于前者有一个初始化的过程：资源目录服务器工作过程中注册的是资源的描述信息而并
不是资源的实体，而代理服务器需要代理的是资源的描述信息和资源的实体两部分，所以初125
始化的功能就是初始化资源的实体信息。下面对代理服务器工作流程做简单说明，详细请参
考资源发现相关草案[3].
发现。首先睡眠节点需要发现 proxy，这主要是通过广播向代理的/.well-known/core发送
请求。代理收到请求后会给予响应来报告自己的 IP地址、端口等信息。
注册。根据收到的代理服务器相关信息，睡眠节点使用 POST方法将自己的资源描述信130
息注册到代理服务器上。
初始化。睡眠节点反复使用 PUT方法向代理服务器注册实体资源。
更新。当睡眠节点资源状态发生变化时，需要使用 POST方法来更新资源以保证资源的
实时性。
删除。当一个信息不再有效，睡眠节点负责使用 DELETE方法将其删除。 135
通过这种方法，客户端可以直接通过代理服务器读取资源的信息而不受节点休眠的影
响，睡眠节点实时更新资源信息保证了资源信息的新鲜度，使客户端能读取到最新的信息。
这基本解决了大部分对资源读取的需求。
不可代理资源
睡眠节点中存在一系列不可代理资源信息，这一部分信息一般为节点系统信息或安全级140
别较高的资源信息。出于安全性的考虑，这一部分信息不能放在代理服务器上，如果节点需
- 5 -
中国科技论文在线
要的话，只能通过直接访问睡眠节点这种方式获取资源信息。这种情况又可细分为两种：节
点 a通过代理服务器访问节点 b，而 b正处于休眠状态（第一种情况，被请求者睡眠）；节
点 a通过代理服务器获取到节点 b的资源后发送给 a，但 a此时已经休眠（第二种情况，请
求者睡眠）。 145
第一种情况
当节点 a通过代理访问 b的资源时，节点 a向代理发送资源请求报文。代理收到报文时，
解析出目的节点，然后查看目的节点状态。如果 b节点处于休眠状态，代理会根据自身实际
情况做出响应：
a) 如果代理资源充足（此资源主要指硬件资源），会给节点 a回复“b is sleepy”，并缓存下150
a的请求报文。当 proxy感知到节点 b的状态发生变化时，会将 a的请求信息发送给 b，
并将相应回复给 a。系统工作过程如图 4左半边。
a Proxy b
Request （a->b）
Asleep
b is asleep
Wake up
Request （a->b）
Response
Response
a Proxy b
Request （a->b）
Asleep
Retry after
Wake up
Request （a->b）
Response
Response
…
Request （a->b）
Retry after
Request （a->b）
图 4 proxy工作流程（不可代理资源）
The process of Proxy（for resource un-representable） 155
b) 如果系统代理资源不充足的话，proxy会给 a一个“retry after”的响应，以此告知 a节点：
b正在休眠，且 proxy无法缓存请求，请稍后再试。当 a收到请求后会按特定的算法（在
受限环境中改进过的二进制退避算法，在此不多赘述）进行重试，直到 b节点唤醒。
此时系统流程图如图 4的右半边。
第二种情况 160
第二种情况相对简单，代理服务器只需要缓存下 b的响应。这个响应是有生存时间的（具
体根据系统设定）。
a) 当 a 唤醒时，如果响应没有超过生存时间，代理服务器就会将响应发送给 a。详细见图
5左半部分。
b) 当响应的生存周期已过，proxy会在 a唤醒时给 a发送“retry again”报文，告知 a需要重165
新发送请求。详细见图 5右半部分。
- 6 -
中国科技论文在线
a Proxy b
Request （a->b）
Response
Response
a Proxy b
Request （a->b）
Response
Request （a->b） fall asleep
wake up
Request （a->b）
fall asleep
wake up
删除响应
Retry again
图 5 proxy工作流程（不可代理资源）
The process of Proxy（for resource un-representable） 170
3 测试分析
本文在 NS3 上模拟客户端请求睡眠节点资源的过程。由于受限网络底层使用的
6LoWPAN网络通信距离较短，所以一个受限域中节点并不是太多，本文设定为睡眠节点数
100，其中有 90 为可代理节点，10 个为不可代理节点。由于不同节点的睡眠频率不同，本
文假设 20s为一个睡眠周期，对节点睡眠时间百分比做如下假设，详情见表 1。 175
表 1 受限节点属性说明
The property description of constrained node
节点类型 节点个数 睡眠度 睡眠时间百分比
可代理资源节点 30 重度睡眠 90%（睡眠 18s，唤醒 2s）
30 中度睡眠 70%（睡眠 14s，唤醒 6s）
20 轻度睡眠 50%（睡眠 10s，唤醒 10s）
10 轻微睡眠 20%（睡眠 4s，唤醒 16s）
不可代理节点 10 中度睡眠 70%（睡眠 14s，唤醒 6s）
同时系统模拟 20个 CoAP Client随机向这 100个节点发送固定个数的请求，这里假设
为五千个。系统会针对不使用本方案和使用本方案的两个情况下，分别统计出报文请求总数、180
请求成功总数、第一次请求成功数、第二次请求成功数、第三次请求成功数、失败数，然后
根据统计数据计算出两种情况下的通信成功率和网络利用率并做比较（由于通信过程较复
杂，本文只输出最终统计结果）。
统计分析并对比
首先系统让每个 CoAP Client发送五千次独立的请求，即总共有十万次请求。每个请求185
的 CoAP Server是随机的一个睡眠节点。本文使用改进的二进制退避算法做请求失败后的重
传（是一种适合受限网络场景的请求失败后重传的算法，但由于篇幅问题，本文对此不做论
述）且将报文重传最大次数设置为 3。客户端会对发送的报文总数、成功收到响应的个数进
行统计，图 6是不使用代理的统计数据：
190
图 6 固定报文数不使用代理的统计
The statistic of package without proxy
- 7 -
中国科技论文在线
由于在没有使用代理服务器的情况下，只有当请求到达CoAP Server的时候CoAP Server
处于非睡眠状态且响应到达 CoAP Client的时候 CoAP Client也处于非休眠状态，才能完成
一次完整的通信，所以通信成功的概率非常小。 195
成功率：由统计可以看出，系统总共发出了 294652 个报文。这是因为如果报文得不到
响应的话，CoAP Client都会重传此报文直至次重传数达到 3，可以看出十万个报文中
绝大部分报文都经过了三次重传，但最终成功收到响应的只有 17609 个，说明即使经
过三次重传，通信成功率也只有约 %，绝大部分交互是失败的（可能是 CoAP Server
休眠造成的，也有可能是 CoAP Client休眠造成的）。 200
受限网络利用率：CoAP Client发送了 294952个报文，但最终只成功的只有 17609个，
网络利用率只有 %。这是因为主要是因为系统中存在大量无意义的重传报文。
图 7是使用本解决方案的情况下得到的统计数据：
图 7 固定报文数使用代理的统计 205
The statistic of package with proxy
在使用代理服务器的情况下，资源代理服务器承载着大部分可代理资源，客户端可以直
接从资源代理服务器获取资源信息而不用和睡眠节点通信，这大幅度提高了通信的成功率；
而对于少部分的不可代理资源，代理会缓存下发送给 Server 的请求以及 Server 端给出的响210
应，等到客户端或服务器唤醒后再将请求和响应转发给它们，这延长了请求和响应报文的生
存周期，减少了报文的重传数。
成功率：由统计数据可以看出，在有代理的情况下，十万个报文交互中最终成功了 99354
个，这是因为客户端可以直接和非休眠的资源目录服务器通信，失败概率较低；并且在
代理服务器资源充足的情况下，可以将请求报文缓存相当长的一段时间，所以绝大多数215
报文在第一次请求的时候就能成功（第一次成功率约 92%）。即使资源目录服务器内
存资源并不充足的情况下，它依然会在通信失败时通知客户端再次请求 CoAP Server，
这又保证了通信的最终成功率——由统计数据可以看出，在使用本方案的情况下，通信
成功率达到了 %，较原本的 %有个非常大的提高。
网络利用率：在本方案下，对于可代理资源，CoAP Client可以直接与代理服务器通信，220
这降低了报文重传的概率；另一方面，当 CoAP Server或 CoAP Client处于休眠状，在
资源充足的情况下，代理服务器缓存下了发往它们的请求和响应并等它们唤醒时转发给
他们，这也避免了报文无意义的重传。所以网络的利用率很高，由统计数据可以看出，
再发送的 106801个报文中，有 99354个成功了，网络利用率高达 93%。这对传输能力
有限的受限网络来说非常重要。 225
优化建议
在基于模拟测试的基础上，本文对睡眠节点的未来部署提出以下优化措施：
可代理资源方面：本文建议将尽量将资源放在代理上，客户端能直接通过访问代理来获
取资源，从而减少首先网络中的报文传输。强烈建议观察者模式中多客户端订阅的资
源放在代理上，因为观察者模式中的资源具有资源变化频繁、订阅者较多的特点，将230
此类资源放在资源不受限的代理上，在解决睡眠节点问题的基础上很大程度上减轻了
- 8 -
中国科技论文在线
睡眠节点的性能压力，同时有效减少了受限网络中的报文传输量。
不可代理方面：针对不可代理资源的两种情况，本文建议尽量使用每种情况的第一种解
决方案（图左侧的方案）来降低报文传输量，另一方面可在 CoAP 限制的生存周期范
围内，尽量延长报文来保证在相同时间内减少重传次数。 235
4 结论
本文在实现 CoAP 协议和资源目录服务器的基础上首先对受限网络中大量的节点处于
睡眠状态而导致客户端无法与之通信的问题提出了理论的解决方案，该方案可根据代理服务
器硬件资源情况及受限资源的特定灵活的对节点间的通信流程进行控制。其次，本文对该解
决方案进行了实现、部署和模拟测试，得到的结果基本与理论预期保持一致，方案在保证通240
信成功率的同时也极大的降低了报文的重传个数，提高了受限网络的利用率，最后在基于测
试的基础上，本文对后期的方案优化提供了理论上的建议。
[参考文献] (References)
[1] FIELDING R, GETTYS J, MOGUL J, et al. RFC 2616 - Hypertext Transfer Protocol--HTTP/[S]. 1999 245
[2] , ARM, , et al. RFC 7252－The Constrained Application Protocol (CoAP)[S]. 2015
[3] , , , InterDigital Communications, LLC. draft-zotti-core-sleepy-nodes-04.
[4] , Universitaet Bremen TZI, , Ed. draft-ietf-core-block-14.
[5] , Sensinode, , Ericsson, . CoRE Resource Directory
draft-shelby-core-resource-directory-05. 250
[6] . RFC5988:Web Linking.
[7] RT Fielding. Architectural Styles and the Design of Network-based Software Architectures. 《University of
California Irvine》, 2000, 64(3):303
[8] A Betzler, C Gomez, I Demirkol, J Paradells. Congestion control in reliable CoAP communication. 《Recercat
Principal》, 2013:365-372 255
[9] BC Villaverde, PAR De, AJ Jara, S Fedor, SK Discovery Protocols for Constrained
Machine-to-Machine Communications. 《IEEE Communications Surveys & Tutorials》, 2014, 16(1):41-60
[10] , Ed. InterDigital Communications, LLC. Dijk, Ed. Philips
260
