数据通信中的自适应等待的制作方法

本发明涉及网络化的设备中的等待持续时间的控制。

背景技术：

由于因特网的出现，在能够存储、处理和传送数据的设备的互联性方面已经存在快速增长。现在，随着被称为物联网(iot)的发展，传统上并不被装配用于存储、处理和传送数据的设备正变得被如此装配。一个示例是家用冰箱的示例，所述家用冰箱设置有识别与易变质食物相关联的编码数据、将所述数据存储在设备存储装置中、并随后在由监视所述数据的程序触发时通过到智能电话的网络警告用户临近针对该食物的“有效”日期的能力。

用于设备的这种经扩展的能力带来了优点，但是同时所述设备可能遭受诸多缺点。首先，所述设备所使用的网络可能是间歇性的，例如ad-hoc网络，并且可能遭受带宽限制。第二，所述设备自身可能具有有限的电力，并在一些情况下可能具有有限的电池寿命。第三，在设备的大型网络中，可能存在能力大不相同的设备，诸如不同的通信和处理数据速率之类。第四，这种网络非常大且复杂，并且因此不可能被管理人员完全理解并由此设置操作参数以争取最优性能。

在图9至12中示出了具有不同的处理延迟的设备的示例。在这些图中的每个图中，示出了网络中连接的各种处理设备的示例性布置，所述设备具有变化的处理器和通信部件(在所述示例中是射频部件rf)，使得所述设备的处理和数据通信速度变化，从而影响数据分组的传送和接收以及确认分组的传送和接收发生时的速度。所述图中的示例性设备和网络分别是iot设备和因特网协议第六版低功耗无线个人区域网(6lowpan)，但是在其它的设备和网络布置中也存在问题，并且在许多网络布置中需要被缓解。所述示例中的变化的处理器和通信部件的细节不是重要的，所述图被给出以示例说明对具有广泛变化的性能特性的网络化的设备中的确认等待持续时间进行控制所涉及的复杂性。

在图9中，示出了在处理能力方面具有快速平台(短的处理延迟)的典型的网络。在图10中，示出了在处理能力方面具有慢速平台(长的处理延迟)的典型的网络。在这两种平台中，使用相同的数据速率(250kbit/s)，并且因此如图11中那样，这些设备能够相互通信，其中取决于接收器处理延迟，确认等待持续时间为短或长。在图12中，示出了与图10中相同的平台，但这次数据速率降低到50kbit/s，这使得确认等待持续时间甚至更长。

在这种传统的布置中，系统管理员将需要设置：

--用于图9中的设备的短的固定ack等待时间，因为仅存在快速设备。

--用于图10中的设备的长的固定ack等待时间，因为存在慢速设备。

--用于图11中的设备的长的固定ack等待时间，因为存在慢速设备(msp430+cc1101)。

--用于图12中的设备的非常长的固定确认等待时间，因为存在具有低数据速率的慢速设备。

因此，在网络中可能出现的具体问题是当在网络上发送单播分组时要设置的确认等待持续时间的问题。传统地，当发送分组时，发送方等待来自接收方的确认。如果在确认等待持续时间到期之前未收到确认，则基于分组在传输中已丢失的假设而重传所述分组。

典型地由发送方将确认等待持续时间设置为固定的设置，所述固定的设置通常是使用根据通信协议标准的公式并通过输入基于系统管理员对系统特性的知识的参数来计算的。所述知识可能是不完整的并且倾向于简单粗糙但可用的经验法则，特别是当网络中存在非常多的设备和通信路径时——管理员可能不具有设置有效的持续时间所要具备的足够的精确知识，并且可能被削弱成设置将容纳最慢的设备和通信路径的用于所有传送的持续时间。对于本领域技术人员而言将清楚的是，这种方式在最差的情况下导致了以下极端情况中的任一种：不必要的频繁重传或不必要的长等待持续时间。

技术实现要素：

在本公开的技术的第一方面中，提供了一种机器实现的方法，用于控制从传送器节点到接收器节点的单播数据分组传送的重试，所述方法包括以下步骤：从具有不同的处理延迟的一组接收器节点中选择所述接收器节点；向所述接收器节点传送第一单播数据分组；在所述传送器节点处建立用于期望的确认等待持续时间的延迟；在所述传送器节点处接收来自所述接收器节点的确认分组；响应于实际的确认等待持续时间小于所述期望的确认等待持续时间，将所述期望的确认等待持续时间设置为新的期望的确认等待持续时间，所述新的期望的确认等待持续时间至少包括所述实际的确认等待持续时间；向所述接收器节点传送第二单播数据分组；在所述传送器节点处建立用于所述新的期望的确认等待持续时间的延迟；以及响应于在未接收到来自所述接收器节点的确认分组的情况下所述新的期望的确认等待持续时间到期，重试传送第二单播数据分组的步骤。。

在本公开的技术的第二方面中，提供了一种具有适于执行上述方法的步骤的部件的设备。

在本公开的技术的第三方面中，提供了一种计算机程序产品，包括有形地存储在计算机可读介质上的计算机程序代码，所述计算机程序代码能够被计算机系统执行以用于执行根据第一方面的方法的步骤。

附图说明

参照附图，读者将更好地认识本公开的技术的示例性实施例，在附图中：

图1示出了根据所述等待持续时间设置技术的方法；

图2示出了根据所述等待持续时间设置技术的设备；

图3至8示出了根据现有的技术和本公开的技术的时序图；以及

图9至12示出了具有不同的通信和处理数据速率的设备的示例。

具体实施方式

现在转到图3，示出了描述单播数据分组的传送的时间图。传送节点(a)传送由接收节点(b)接收的分组。传送节点(a)启动超时(ack等待持续时间)，并且在该时间之内接收节点(b)应当发送确认帧以验证接收节点(b)已接收了数据。

如图4中所示，如果节点(a)未接收到确认，则节点(a)在ack等待持续时间之后将开始重传。这里称为“ack等待持续时间”的时间在mac规范例如ieee802.15.4-2006中通常根据以下公式来定义：

macackwaitduration＝aunitbackoffperiod+aturnaroundtime+physhrduration+[6*physymbolsperoctet]

这意味着ack等待持续时间的时间取决于处理器平台和通信部件配置。一个硬编码的静态超时时段将仅对全部的平台和配置起作用，并且如果该硬编码的静态超时时段非常长，那么这将导致显著的重传时延(latency)。

本公开的技术确定了用于每个接收器的独有的ack等待持续时间，以在相同的网络中在处理功率方面支持慢速平台和快速平台这二者，并且本公开的技术起作用以通过使用所确定的ack等待持续时间来减少重传的时延。

图5介绍了传送节点(a)正向接收节点(b)发送第一单播分组的情况。由于(a)尚未向(b)发送任何分组，因此(a)正在使用根据所述公式设置的非常长的ack等待持续时间。在传送之后，(a)启动定时器以测量接收来自(b)的确认需要多长时间。当接收到ack时，(a)将所测量的值添加到用于存储关于已知邻居节点的信息的“邻居表”中。

当节点(a)向节点(b)传送第二分组时，节点(a)从所述“邻居表”读取所测量的ack等待持续时间、添加一些安全余量、并使用该值作为接收器(b)专用的ack等待持续时间，如图6中那样。

以这种方式，节点(a)可以及时地确定用于节点(a)正与之通信的全部设备的ack等待持续时间。该机制的优点是，当节点(a)知道接收节点应当多快作出对传送的分组的确认时，节点(a)可以使用非常积极的重传定时。在图7中，传送节点(a)测量用于节点(b)的针对第一个单播分组的非常短的ack等待持续时间。

如图8所示，当本公开的技术的系统具有用于ack等待持续时间的精确数据时，所述系统可以利用非常短的重传定时。

在实施例中，可以定期地重复所描述的测量，以便能够响应于诸如温度改变之类的变化的环境。以这种方式，“邻居表”更可能包含用于所有邻居节点的多个有效ack等待持续时间。

现在转到图1，示出了根据本公开的技术的机器实现的方法100。所述方法在开始步骤102开始，并且在选择接收器步骤104，从典型地由于其变化的处理器和通信部件性能特性而具有不同的处理延迟的一组接收器节点中选择接收器。在测试步骤106，进行测试以确定单播传送实际上对于所选的接收器而言是否是第一次，也就是说，系统是否已经存储了所述接收器的个体等待数据。如果测试步骤106的结果是否定的，则系统未获知所述接收器的等待数据，并且在步骤108，系统使用典型地根据至少与已知系统和网络特性有关的公式而导出的预定的等待持续时间，并进行到发送和设置时钟的步骤112。如果测试步骤106的结果是肯定的，则所述系统存储有所述接收器的等待数据，例如存储在上述的“邻居表”中，在步骤110使用所述已知的等待数据来确定用于向所述接收器进行传送的ack等待持续时间。在步骤112，发送单播数据分组，并将所述ack等待持续时间时钟设置为期望的等待时间。如果在测试步骤114，期望的等待时间到期而未接收到确认分组，则时钟在步骤116停止，并在步骤118重试发送。如果在步骤114期望的等待时间尚未到期并且在步骤120接收到确认分组，则时钟在步骤122停止，并且在步骤124用于所述接收器的期望的等待被设置为新的期望的等待。所述系统可以将用于接收器的新的期望的等待持续时间存储在如上文所述的“邻居表”中。

所述机器实现的方法还可以包括设置重试计数阈值，并响应于对所述重试计数阈值的超过，将新的期望的确认等待持续时间重设为先前的期望的确认等待持续时间(典型地根据所述公式导出的持续时间)。在一个可能的变型中，可以设置用于新的期望的确认等待持续时间的有效期，并且响应于所述有效期的到期，可以将所述新的期望的确认等待持续时间重设为先前的期望的确认等待持续时间。在任一变型中，将期望的确认等待持续时间设置为新的期望的确认等待持续时间的步骤可以包括向实际的确认等待持续时间添加安全因素持续时间的步骤。典型地，通过协议标准来确定期望的确认等待持续时间，并且在一个示例中，所述协议标准为mac通信标准。

在图2中示出了适于执行上述的控制等待持续时间的方法的步骤的设备200。设备200包括适于从由于其变化的处理器和通信部件性能特性而典型地具有不同的处理延迟的一组接收器节点中选择接收器的接收器选择器部件202。接收器选择器部件202使用节点集合列表204来选择接收器，并与确认等待控制器206进行通信。

确认等待控制器206使用接收器等待数据列表208来确定实际上是否已经存储了所述接收器的个体等待数据。如果没有，则确认等待控制器206未获知所述接收器的等待数据，并且因此被配置为使用典型地根据至少与已知的系统和网络特性有关的公式而导出的预定的等待持续时间。如果确认等待控制器206已经存储有所述接收器的等待数据，则所述等待控制器206使用所述已知的等待数据来确定用于向所述接收器进行传送的ack等待持续时间，并将其传送给等待时钟210。传送器/接收器212被配置为通过网络214发送单播数据分组，以接收确认并响应于等待时钟210而重试发送。在通过网络214接收到确认时，传送器/接收器214能够操作以将期望的等待持续时间和实际的等待持续时间传送给计算器216，计算器216使用实际的等待持续时间来计算新的期望的等待持续时间，并将所述新的期望的等待持续时间提供给确认等待控制器206，确认等待控制器206转而能够操作以将所述新的期望的等待持续时间存储在接收器等待数据列表208中。

本领域的技术人员将认识到，本技术的各方面可以被实现为系统、方法或计算机程序产品。相应地，本技术的各方面可以采取整体硬件的实施例、及整体软件的实施例、或组合软件方面和硬件方面的实施例的形式。

此外，本技术的各方面可以采取在其上实施有具有计算机可读程序代码的计算机可读介质中实施的计算机程序产品的形式。所述计算机可读介质可以是计算机可读信号介质或计算机可读存储介质。计算机可读存储介质可以是例如但不限于电子、磁、光、电磁、红外或半导体系统、装置或设备，或上述的任何适当的组合。

用于执行本技术的各方面的操作的计算机程序代码可以按一种或多种编程语言的任意组合来编写，包括面向对象的编程语言和传统的过程编程语言。所述程序代码可以全部在用户的计算机上执行、部分地在用户的计算机上执行且部分地在远程计算机上执行、或者全部在远程计算机或服务器上执行。在后者的场景中，远程计算机可以经由任何类型的网络连接到用户的计算机。代码组件可以被实现为过程、方法等，并且可以包括子部件，所述子部件可以采取任意抽象级别(从原生指令集的直接机器指令到高级别经编译或解释的语言结构)的指令或指令序列的形式。

本领域的技术人员也应当清楚，根据本技术的优选实施例的逻辑方法的全部或部分可以适当地在包括执行所述方法的步骤的逻辑元件的逻辑装置中实施，并且这种逻辑元件可以包括例如可编程逻辑阵列或应用特定的集成电路中的诸如逻辑门之类的部件。这种逻辑布置还可以使用例如虚拟硬件描述符语言在用于暂时地或永久地在这种阵列或电路中建立逻辑结构的使能元件中实施，所述虚拟硬件描述符语言可以使用固定的或可传送的载体介质来存储和传送。

在一个替代中，可以按部署服务的计算机实现的方法的形式来实现本技术的实施例，所述计算机实现的方法包括部署计算机程序代码的步骤，所述计算机程序代码当被部署到计算机基础设施或网络中并在其上执行时能够使得所述计算机系统或网络执行所述方法的全部步骤。

在又一替代中，本技术的优选实施例可以按其上具有功能数据的数据载体的形式实现，所述功能数据包括当被加载到计算机系统或网络中并在其上运行时使得所述计算机系统能够执行所述方法等全部步骤的功能计算机数据结构。本领域的技术人员将清楚，在不背离本发明的范围的情况下，可以对上述的示例性实施例进行诸多改进和修改。