一种应用于物联网传输的拥塞控制方法与流程

文档序号:11254576阅读:974来源:国知局
一种应用于物联网传输的拥塞控制方法与流程

本发明涉及网络通信技术领域,具体的说,是涉及一种基于messageid的应用于物联网传输的拥塞控制方法。



背景技术:

iot(internetofthing,物联网)在现有通信网络的基础上,进一步将网络延伸至除传统设备以外的物理实体。它把日常生活中的各种物品(例如:电灯、空调、家具等)连接在一起,让它们收集环境信息、相互之间直接“交谈”、改变环境状态,最终营造一个更加智能的的环境,从而极大地提高人们的生活质量。作为新一代的信息技术,iot受到了来自学术界和工业界越来越多的关注。

现有的通信技术无法直接应用于资源受限的iot设备,因此业界各大标准组织正在制定适用于iot场景中资源受限设备的各种通信协议。其中,由ietf于2014年完成标准化工作的coap(constrainedapplicationprotocol,受限应用层协议)是一个备受瞩目的应用层协议。

coap是通过对http协议进行裁剪并添加iot场景所需要的特性而得到,它与http协议的区别主要体现在两个方面:(1)coap仅实现了http协议的一个子集;(2)coap额外提供了资源发现、组播和异步消息等功能。

值得注意的是,http协议建立在tcp协议之上,它把拥塞控制交由tcp协议处理。tcp协议的拥塞控制通过在发送端维持一个拥塞窗口来实现。窗口的大小根据aimd规则动态调整,发送速率则等于拥塞窗口大小除以rtt。rtt的获取方案由rfc6298提供。但是,coap协议基于不可靠传输的udp协议,因此它必须自己解决拥塞控制问题。在iot场景中运行coap协议的资源受限设备通常无法直接采用上述专为资源丰富设备设计的拥塞控制方法,其原因主要体现在如下两个方面:

(1)iot设备通常工作在丢包率和误码率严重的无线网络中,因而其重传的发生概率远高于现有的通信网络。如果直接使用tcp中只运行一个strongrtoestimator的方式获取rtt,那么rtt值的获取概率将会非常低,从而降低拥塞控制的性能;

(2)拥塞窗口不适合iot设备,而stop-and-waitarq的方式才是这类设备的最优选择。一方面,拥塞窗口增大了控制的复杂度,对于资源受限的iot设备是一个不小的负担;另一方面,大多数无线链路的带宽延迟乘积很小,小窗口(stop-and-waitarq相当于一个窗口大小为1的小窗口)的性能往往优于大的窗口。

coap本身所提供的拥塞控制协议是一种基于stop-and-waitarq原理的拥塞控制方法。但是,其rto(重传超时时间)的计算不考虑rtt(往返时间):初始值在默认情况下随机地从2~3s内选取,此后每经过一次重传就用beb算法对当前rto进行更新。显然,这种拥塞控制方法无法适应iot中差异显著的各种网络环境。为此,一个正在ietf中被讨论的rfc草案——cocoa(coapsimplecongestioncontrol/advanced)提供了针对coap拥塞控制机制的扩展方案。cocoa引入adaptivertocalculation、variablebackofffactor(vbf)、rtoaging等3个机制,为coap的拥塞控制机制添加了网络自适应特性,使coap能够获取表征网络环境状况的rtt并据此更新rto。

然而,上述cocoa草案在获取rtt时,存在weakestimators模糊性的问题。具体而言,当发送端收到ack消息时,无法准确判断该ack消息是由此前的哪个con消息所触发的。而cocoa所采取的应对策略为:总认为该ack消息是由第一个con消息所触发并据此测量rtt值。虽然采用这种算法的tcp协议实现也可能出现类似的问题,但是这在现有的通信网络(丢包率相对较低)中并不会成为影响tcp协议拥塞控制性能的重要因素。而在一些lln网络环境(尤其是丢包率严重的网络)中,这会导致rtt估计过大的问题,进而使发送端出现空闲等待,降低了带宽利用率。

上述缺陷,值得解决。



技术实现要素:

为了克服现有的技术的不足,本发明针对物联网应用协议coap本身的以及其扩展草案cocoa所提供的拥塞控制机制的不足,提供一种在几乎不增加额外开销的前提下,可以大概率且准确地测量通信双方的rtt、进而得到最优rto来进行拥塞控制的方法。

本发明技术方案如下所述:

一种应用于物联网传输的拥塞控制方法,其特征在于,在cocoa草案的基础上,发送端每当要重传con消息时,重新封装业务数据并分配新messageid而得到用于重传的消息;发送端收到来自接收端的ack消息,能唯一确定触发该ack消息的con消息;发送端收到ack消息,能测量出此次通信所能得到的rtt,并用该rtt更新rto,从而增强coap协议的拥塞控制能力。

根据上述方案的本发明,其特征在于,进行拥塞控制的具体步骤为:

步骤1、将业务数据封装到coapcon消息中,并分配全局唯一的messageid;

步骤2、将封装好的coapcon消息发往接收端,等待来自接收端的响应;

步骤3、如果发送端在rto时间内收到了来自接收端的ack消息,说明请求成功,结束此次请求的通信过程;否则,说明该请求可能已经失败了,就跳转至步骤4;

步骤4、如果该con消息的传输次数已经超过最大重传次数,表明此次请求已经失败,就返回错误标志并结束此次请求的通信过程;否则,跳转至步骤5进行重传操作;

步骤5、重新将业务数据封装到一个新的coapcon消息中,并分配一个新的全局唯一的messageid;

步骤6、更新rto、使重传计数器加1,然后将封装好的coapcon消息发往接收端,等待来自接收端的响应,并跳转至步骤3。

进一步的,所述步骤2中,在封装好的coapcon消息中,重传次数retransmit初始化为0,rto初始化为ack_timeout~1.5*ac_timeout范围内的某个随机值。

进一步的,所述步骤3中,请求发送成功后,发送端从这次成功的请求中获取网络的rtt值,并根据该rtt值更新rto。

所述步骤5中,在取得用于重传的coapcon消息的方式上,有别于原来的直接从缓存中获取,采用重新封装业务数据的策略来得到coapcon消息。

所述步骤5中,重新封装业务对象时,分配一个新的messageid。

进一步的,所述步骤6中,通过beb算法更新rto。

根据上述方案的本发明,其特征在于,所述con消息中包括固定部分和可变部分。

进一步的,在固定部分中,第一、二位为版本标识位,第三、四位为消息类型标识位,第五到第八位为令牌长度标示位,第九到第十六位为报文代号,第十七到第三十二位为报文id。

进一步的,在可变部分中,包括令牌位、选项位以及负载内容。

根据上述方案的本发明,其有益效果在于,本发明重新封装业务数据并分配新messageid的方式在提高rtt测量准确度的同时,也增大了获取rtt测量值的概率和准确度,能够有效地增强coap协议的拥塞控制能力。本发明不会增加额外的通信开销、内存开销。

附图说明

图1为本发明的工作流程图。

图2为本发明的消息格式。

图3为本发明信令流程图。

具体实施方式

下面结合附图以及实施方式对本发明进行进一步的描述。

如图1所示,本发明提供一种应用于物联网传输的拥塞控制方法,进行拥塞控制的具体步骤如下:

步骤1、将业务数据封装到coapcon消息中,并分配全局唯一的messageid。跳转至步骤2。

步骤2、将重传次数retransmit初始化为0、rto初始化为ack_timeout~1.5*ac_timeout范围内的某个随机值,把封装好的coapcon消息发往接收端,启动重传计时器,等待来自接收端的响应。跳转至步骤3。

步骤3、如果发送端在rto时间内收到了来自接收端的ack消息,说明请求成功。发送端从这次成功的请求中获取网络的rtt值,并根据该rtt值更新rto,最终结束此次请求的通信过程;否则,说明该请求可能已经失败了,就跳转至步骤4。

步骤4、如果该con消息的传输次数retransmit已经超过最大重传次数max_retransmit,表明此次请求已经失败,就返回错误标志并结束此次请求的通信过程;否则,跳转至步骤5进行重传操作。

步骤5、重新将业务数据封装到一个新的coapcon消息中,并分配一个新的全局唯一的messageid。跳转至步骤6。

步骤6、使重传次数retransmit加1、用beb算法更新rto,然后将封装好的coapcon消息发往接收端,重新启动重传计时器,等待来自接收端的响应。跳转至步骤3。

其中,上述步骤1或步骤5中所得到的coapcon消息的报文格式如图2所示,该报文格式具有如下特征:

(1)不增加额外的令牌(token)或者选项(options)等辅助字段,因此不会给传输带来额外的带宽消耗;

(2)报文id(messageid)是全局唯一的,这意味着客户端和服务器通信过程中的其它报文不可能采用与当前报文相同的报文id。

上述步骤的信令流程如图3所示。本实施例中,coap客户端在第3次尝试时成功实现请求。其具体过程如下:

(1)客户端将报文id为147的coapcon消息发往服务器并启动重传计时器。但是由于网络传输错误,该coapcon消息丢失;

(2)客户端在rto时间内没有收到ack消息,断定coapcon消息已经丢失。于是将相同的业务数据封装到报文id为148的coapcon消息中,并用beb算法更新rto,然后将该消息发往服务器、启动重传计时器。但是由于网络传输错误,该coapcon消息再次丢失;

(3)客户端在rto时间内没有收到ack消息,于是再次重复(2)中的操作,将报文id为149的coapcon消息发往服务器。这次,该coapcon消息顺利抵达服务器;

(4)客户端在rto时间内收到了来自服务器的报文id为149的ack消息,请求成功。客户端从这次成功的请求(报文id为149)中获取网络的rtt值,并根据该rtt值更新rto。

在本发明中,beb算法等均是本领域所公知的算法,本发明并未对算法本身做出改进,因此不再对算法内容进行详细描述。

本发明在cocoa草案所提供的拥塞控制机制的基础上,增大了rtt测量值的获取概率,同时也提高了rtt测量值的准确度,能够有效地增强coap协议的拥塞控制能力。这种基于重新分配messageid的拥塞控制方法具有如下优势:

(1)不增加额外的通信开销:如图1所示消息格式,本发明所提方案不需要在消息中添加任何额外的令牌(token)或者选项(options)等字段,因此不会带来额外的通信开销;

(2)不增加额外的内存开销:测量rtt需要用到的两项参数——con消息的messageid和对应发送时间这两项参数本身已经包含于cocoa草案,因而这里并没有增加额外的内存开销;

(3)只需少量额外的cup开销:与cocoa草案中每次重传都直接从缓冲器中取旧消息不同,本发明要求重新封装业务数据,因而需要一定的cpu资源。但是,这些有限的cpu开销是可以接受的。因为研究表明,无线通信所带来的能量消耗大约是节点内计算所带来的能量消耗的10倍。可见,这些cpu开销相对而言是可以忽略的。

coap核心文档指出:messageid的其中一个作用在于帮助接收端检测消息是否重复,从而避免多次处理内容相同的请求。但是,接收端对于幂等的请求类型(get,put和delete)可以放松这个限制;而对于非幂等的请求类型(post),在特定的应用语义下经过权衡后也可以放松该限制。这种措施所带来的额外好处在于,接收端由于无需追踪是否已经处理过相同的请求而节省了开销。

相比于cocoa草案而言,本发明对于messageid的更新更加频繁。对于可能出现的messageid溢出(即messageid过早用完)问题,说明如下:

(1)对于大部分iot应用而言,节点与同一个endpoint的通信次数往往不会非常大。因此,16bits的messageid通常是足够的;

(2)对于可能出现的极度频繁的通信场合,可以通过如下可选的方式来解决:在发送端为当前的业务数据维护一张包括2列的表,这两列分别代表重传次序和对应的messageid,每一行则表示一次con消息传输,并且该表最多为5行。这样,只需保证当前业务数据对应的多个con消息具有互异的messageid,以便完成所收到的ack消息与con消息的匹配即可。之后发送其它业务数据时,这些messageid仍然可以重复使用。

cocoa草案指出,基于rtt的拥塞控制机制是不适合诸如coap协议定义的class1等资源极度受限的设备。换而言之,这种拥塞控制机制要求设备的资源富足程度至少应在coap协议定义的class2设备以上。因此,对于上述(2)所提的表的存储,设备的资源足以提供支持。

应当理解的是,对本领域普通技术人员来说,可以根据上述说明加以改进或变换,而所有这些改进和变换都应属于本发明所附权利要求的保护范围。

上面结合附图对本发明专利进行了示例性的描述,显然本发明专利的实现并不受上述方式的限制,只要采用了本发明专利的方法构思和技术方案进行的各种改进,或未经改进将本发明专利的构思和技术方案直接应用于其它场合的,均在本发明的保护范围内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1