Orchestra:通过自主调控的TSCH使网状网络更具有健壮性

TSCH:Time Slotted Channel Hopping MAC(时隙信道跳频)

概要：

时隙调控和信道跳频操作是一个经过广泛验证的以实现高度可靠的低功耗网络的方法。但是很难把时隙应用到物联网的动态网络设想中。通常来讲，这些应用并不具有预定义好的周期传输模式和可动态添加或删除的节点。

这篇论文的挑战就是将tsch引入到这样的动态网络中。我们将关注于低功耗的ipv6和RPL网络，还会介绍orchestra。在orchestra里，节点会自动计算各自的本地时间表。他们维护着多个时间表，每个都被分配一个traffic plane（流量平面？传输平面？）（包括应用程序，路由和mac），并且随着拓扑结构的发展而自动更新。orchestra计算或者重新计算本地时间表不需要信号开销，而且不需要任何中央或者分布式调度程序。相反，它依赖于已经存在的网络堆栈信息来维护这个时间表。这个方案允许orchestra利用TSCH的鲁棒性来建立非确定性网络。我们通过在两个硬件测试平台上做广泛的评估来展示orchestra的实用性并量化收益。orchestra可以减少甚至消除网络竞争（网络争用），在长达72小时的试验运行里我们证明了orchestra可以取得超过99.99%的端到端传输率，相比于RPL在异步低功耗监听网络所起的作用，orchestra提高了两个数量级别的可靠性，但可以达到与RPL类似的延迟能量平衡。

类别和主题描述：

网络结构和设计：无线通信

关键词：TSCH，RPL，调度安排，无线传感网络

1.介绍：

背景：随着物联网的新兴发展，对灵活且健壮的低功耗通讯方法的需求日益增长（灵活是指易于使用，能够满足动态应用的各种要求，健壮性是指工作可靠性）。例如出现在智能家居和智能城市中的应用，包括可穿戴电子消费设备。在这些情况下，短距离低功耗的网状网络被视为实现能源的高效利用和可靠的大范围操作的候选技术。

挑战：灵活性和可靠性是两个矛盾的目标。异步低功耗网状网络（包括低功耗ipv6）是灵活的并且支持非确定性应用，但却是best-effort。最先进的解决方法有着百分之1的丢包率。在不考虑端到端的可靠性的情况下，例如传输层的重传，这样的丢失率对于大多数应用来说都太高了，如果考虑端到端的重传，这些丢包将会导致昂贵开销的重传而且表现的不好，另一方面，使用TDMA的确定性网络和调度后的traffic可以实现降低两到三个数量级的丢失率。例如发送一万个包最多丢失一个包，我们研究的是如何在不确定性网络中达到这样高水平的可靠性。

方法和区别：在这片论文里，我们为非确定性低功耗RPL和IPV6网络里做了一个自动的TSCH调度。我们发现尽管它要求全局同步，但是TSCH方法在稀疏网络里是可行的，而且可以帮助那些使用分布式路由协议（例如RPL：routing protocol for LLN）的网络取得较高的可靠性。我们强调的关键挑战是如何在不妨碍RPL网络灵活性的前提下构建TSCH调度并且满足非确定性应用的各种要求。orchestra通过本地自动调度实现了这些挑战，并且不需要集中式或者分布式调度器。

这与传统的依赖集中式调度器的TSCH调度方法（例如WirelessHART和ISA100.11a）完全不同。也与IETF 6TiSCH 工作小组提出的利用邻居节点之间的调度协商方法是不同的。

在orchestra里，节点采用简单的周期性的时间表，并自动更新的时间表，并立即作为路由拓扑结构的演变。orchestra里的一个TSCH调度由通信时隙的集合组成，这些时隙致力于一个特定的通信平面：MAC,routing and application（就像图一所示），于是，当orchestra受益于TSCH的健壮性，可以使用RPL建立一个通用的灵活的低功耗路由骨干。我们的调度可以减少激烈的网络争用，甚至在一些特定情况下彻底消除争用。

 

图1：在乐团中，几个时间表在不同的时间段（这里为2,3和5）重复，其中时隙分配给特定业务平面（相应的应用，RPL，TSCH）。 时隙在被较高优先级调度中的时隙重叠时被跳过（优先级从图中的顶部向底部增加）。

 

结果：我们在contiki上部署orchestra和TSCH并且使用用了98和25个节点的平台做实验，每个都用的是不同的硬件平台。最终，我们的评价基于219个独立的实验，时间长达72小时并且从源路由到目的的UDP数据包达到1178601个，我们展示了orchestra可以在RPL网络里自动的进行TSCH调度，并且端到端收包率达到了99.99%，比目前最先进的方法提高了一到两个数量级。并且我们还能使达到这么高的端到端可靠性的同时，使我们方案的能量和延迟与目前最好的方法很接近。

贡献：本文的主要贡献是提出了orchestra，一个由路由状态驱动协议驱动，允许TSCH节点自主维护自己调度表的系统，orchestra工作时，不需要集中式的调度器，也不需要节点间的调度协商和路径的预定。我们在实验上证明了orchestra是实用的，可扩展的，并且比低功耗监听在端到端的损失率上降低了两个数量级。

概述：文章是这么展开的，第二部分是在介绍orchestra的一些必要概念之前介绍TSCH和RPL的必要背景，第三部分介绍TSCH作为异步物理层的选择的潜在好处，第四部分讨论orchestra的设计 第五部分详细展示了使如何实施的。第六部分讨论了我们在两个不同的测试平台和控制仿真上进行的实验结果，我们在第七部分讨论了一些相关的工作，并在第八部分进行了总结。

2.概述

这部分介绍一些必要的背景并且为我们的系统orchestra做了大致简单地介绍。

2.1  TSCH

IEEE802.15.4e-2012标准为IEEE802.15.4定义了一些MAC协议，在本文中，我们聚焦于TSCH（时隙信道跳频），它继承于WirelessHART 和ISA100.11a。

一些TSCH节点组建成全局同步的低功耗网状网络。一个节点可以在听到另一个节点发出的增强信标后加入这个网络。时间同步流沿着一个有向无环图从PAN调制解调器到叶子节点，时间被切分成一个一个的时隙，这些时隙组成一个或多个slot帧（时隙帧），一个时隙，典型的是10毫秒长，已经足够节点发送一个或者接受一个帧。一个TSCH调度指示一个节点在每个时隙里传输，接受或者睡眠。时隙帧里的每个时隙是由下面几个属性确定的：时间偏移（用来表示这一时隙在时隙帧里什么时候发生），信道偏移（表示它在哪个频率上交流），还包括以下 一组属性：是否用来传输，接收和时间同步等等。时隙可以是专用的也可以是共享的，即无争用或基于竞争的CSMA避让策略。

TSCH网络使用信道跳变：调度里相同的时隙在时隙帧的每一次迭代中转换成不同的频段。其结果是，相邻节点之间交换的连续的数据包在不同的频段上交流。万一由于外部的干扰和多路径衰弱导致传输失败，重传就会发生在一个不同的频段上，这样往往比使用和上次相同的频段有一个更好的成功概率。

如何在TSCH网络中建立和维护通信调度已经脱离了现在已经存在的范围和标准。传统的调度方法是使用一个集中式的实体来收集来自于网络里的信息，集中计算好调度之后再传播这些路由和调度至每个节点。自2013年底以来，IETF 6tisch工作组正在确定的机制可以来支持分布式调度。在这种方法中，一个节点通过与它的邻居进行交流来添加/删除一个时隙进入他们的局部调度里。

2.2RPL

RPL是为被IETF ROLL工作组标准化的低功耗ipv6网络制定的路由协议。他是一种面向距离矢量的路由协议，它把节点按照DODAG的结构组织起来。DODAG的根是边界路由器节点（互联网接入点），每个节点都被加入到一个rank榜单，即按照一定的成本函数计算得到的它距离根节点的距离（例如ETX度量）。一个节点想要向根节点发送一个数据包那它就要把这个数据包推到一个具有比它的rank小的邻居节点上。从根到一个节点的路由是通过使用反向链接实现的。本篇论文，我们聚焦于RPL 的存储模式。每个节点针对其路由的子节点（也就是那些比它自己距离根还要远的节点）维护一个路由表。RPL采用单播和广播信号消息，即DIO（传播度量），DIS（请求DODAG信息），DAO（传播路线）。从任何一个节点到另一个节点的路由是通过第一个路由先达到他俩的一个共同的祖先（沿着递减的rank），然后再下降到目的地（遵循路由表）。

2.3一句话介绍orchestra

orchestra是从根本上不同于现有的调度解决方案，它不涉及任何额外的中央实体，也不涉及节点间的信令和协商，以及多跳路径预留。（注意：本文提出的方法是一般足够的适用于其他计划的MAC层和任何路由协议.本文的重点是TSCH与RPL）。相反，节点基于他们的RPL邻居和双亲节点来自动的维护他们自己本地的调度表。于是，orchestra使得TSCH像异步MAC层一样灵活，同时还支持随机访问流量。

一个orchestra调度包括几个不同长度的时隙帧。每个时隙帧是为了一个特殊类型的包而建的，要么是TSCH信标，要么是RPL信令流量，要么是应用数据。节点使用调度规则来选择时隙大大减少了争用时隙甚至在某些情况下会消除竞争（见4.2）。这使得orchestra对低功耗ipv6传感器网络有着很大的吸引力。orchestra的一个具体调度例子包含如下：

——一个从每个节点到其孩子节点的专门为TSCH信标设置的广播时隙，每隔X个时隙就重复。

——一个为网络中所有节点设置的时隙，用来广播和单播RPL信号（DIO，DIS，DAO），每隔Y个时隙重复。

——一个从每个节点到它们各自的RPL最近的父亲节点的专门的单播时隙，每隔Y个时隙重复。

——N个从每个节点到它的每个孩子的专门的单播时隙，每隔Z个时隙重复。

orchestra使用互质的时隙帧长度，确保均匀地相互重叠，不会产生意外的同步效应。我们选择每个时隙的时间和信道偏移来作为发送者和接受者标识符（MAC地址或者是一个唯一的网络节点号）的函数。根据调度规则，orchestra可以达到很低水平的争用或者实现无竞争使用。

3.一个在低功耗网络下的TSCH案例

在介绍orchestra的详细设计之前，我们讨论和描述使用异步解决方案的TSCH的潜在好处。

全局同步的成本：TDMA协议在随机访问或者稀疏流量场景中通常被视为不切实际的，主要是因为全球同步的开销是个大问题。在TSCH里，节点保持同步到一个或者多个时间源，无论什么时候接收到从它获取到的ACK包的数据，都要重新调整他们的时钟。在IEEE802.15.4里，被允许的最大的时钟漂移是40ppm（PPM是指百万分之一），例如两个节点最大允许80ppm，假设guard time为+-1ms（TSCH的默认值），一个节点需要每12.5秒同它的时间源邻居重新同步一次。重新同步涉及到发送一个短的数据包和接受一个ACK包，大约占到无线电广播（radio on-time）的6毫秒。在这个假设下，再同步导致了6 ms/12.5 s = 0.048%的占空比。

在实践中，这种基线成本可以推进得更低。在我们的试验台（见§6.1）中，我们测量出节点之间的平均漂移在10-20ppm范围内，低于上述假定的80ppm。 此外，节点通过评价其在运行时的漂移，并动态调整其时钟，可以进一步降低同步的成本[4]。

上面的数字表明，可以以非常低的成本获得同步， 这种低成本当与网状网络的典型占空比百分之几或百分之几十的数量级相比时，实际上是微不足道的。[15,19,21,11]（例如 Contiki-MAC在默认设置中具有0.6％的基线占空比[9]）。 因此，我们认为TSCH即使在稀疏流量情况下也是实用的。

调度与同步

当使用不同的MAC层时，我们运行一组初始化的实验来表征链路属性。 我们使用Indriya 测试平台[6]，包含98个TelosB节点。 我们为Contiki操作系统部署TSCH，并将TSCH与ContikiMAC和Always-on MAC进行比较，其中Always-on MAC,是指节点一直监听并使用CSMA（具有链路层ACK的Contiki的Nullrdc + Csma）进行发送。 后两者是基于争用的异步MAC层。 ContikiMAC [9]是一个先进的低功耗监听协议，建立在成熟的机制[23,16]上（下面会有所描述）。 在ContikiMAC中，节点在每个一个周期（例如，125ms）重复地发送它们的分组，直到接收器唤醒并确认它。 节点通过锁相机制松散同步，这减少了已知邻居的选通脉冲长度。 虽然Always-on在低功耗情况下通常不切实际，但我们将其作为基线方法 。

在实验中，每个节点在给定周期发送具有附加抖动的广播分组，并且记录所有分组接收。我们使用3个不同的异步MAC层：Always-on，ContikiMAC为8 Hz（默认设置，唤醒周期为125 ms），ContikiMAC为64 Hz（唤醒周期为15.6 ms）。我们使用2种不同的配置TSCH：TSCH-minimal，基于6TiSCH最小配置[35]，其中每个节点具有用于任何traffic的单个共享通信时隙（这里我们使用1时隙的时隙帧，即，所有时隙都是活动的 ）和TSCH-dedicated，其中我们使用节点的唯一节点ID在测试台中为每个节点分配专用传输时隙，排除所有的争用。为了使实验更加公平并且聚焦于调度而不是信道调频，在这个特定实验中我们在单个通道（通道26，Indriya最佳通道中的一个）上运行TSCH。

 

图2：定期广播探测实验。 ContikiMAC具有比TSCH和Always-on高得多的信道利用率，在高流量负载时导致较少的稳定链路。使用专用时隙的TSCH，由于完全无竞争，他的表现和always-on的表现是类似的

 

图二总结了实验的结果，我们看两个指标，首先，信道利用率是节点利用其无线电发射所花费的平均时间部分。其次，稳定链路的数量是指PRR（分组接收率）高于90％的链路的总数。ContikiMAC导致具有分组选通的高信道利用率，即，每个节点高达3％，在98节点测试台中，对应于在任何时间点平均发送3个节点。相比之下，TCSH和Always-on节点的信道利用率低于0.08％，是一个37倍的系数改进。 这导致较低的竞争，进而导致更多数量的稳定链路。

信道跳频

TSCH的一个基本好处是它的信道跳跃性质。已知信道跳频有效地对抗外部干扰和多径衰落[38,37]，从而增加信道容量并减少在包重传中花费的能量，信道跳跃可以在异步MAC中实现类似的好处，但是以额外的同步开销为代价[32,24]

4 orchestra的设计

Orchestra是一个在随机接入TSCH网络中实现路由感知和自主的实习分配的系统。

4.1 big picture（大图片，总的介绍？）

在orchestra中，节点通过利用来自RPL拓扑的信息并遵循一组调度规则来调整它们的调度。 这导致周期性活动模式，其中分配给不同traffic平面的时隙帧和时隙，诸如TSCH信标，RPL信令或应用数据。

网络引导 当接通时，节点通过侦听加入TSCH网络，直到它从PAN协调器或另一个节点接收到加强信标（EB）。与该EB同步后，节点运行orchestra。 一个可行的orchestra设置需要用于向/从任何邻居发送和接收分组的时隙。 这模拟了到所有邻居的always-on的链路，允许RPL节点发现它们的邻居并构建拓扑。

TSCH-RPL拓扑映射 orchestra始终使用节点的RPL首选父节点作为其TCSH时间源邻居。随着RPL拓扑的演变和父交换的发生，节点相应的更新其TSCH时间源。利用RPL的内置环路避免机制，产生了无环路的定时结构（在这种情况下是树）。此外，我们使用RPL秩来作为TSCH的加入优先级，就像在6TiSCH结构中定义的那样，这样做，我们还利用RPL机制的梯度收敛和稳定性。 如果节点失去同步，那么它也就离开了RPL网络，以确保重新加入后有一个干净的slate bootstrap（板岩引导？）。

TCSH时间同步 TCSH时间同步发生在来自时间源邻居的任何分组（或ACK）上。在orchestra中，时间同步主要通过周期性TCSH和RPL信标传输发生，这是有效的，因为单个广播消息允许所有的孩子节点更新他们的时钟。每当节点在给定持续时间内没有与其时间源邻居通信（我们使用12秒）时，它发送单播保活消息。重新发送数据包，直到确认，通过使用嵌入在IEEE802.15.4e增强型ACK中的定时信息来进行再同步。

路由感知调度 在整个网络生命周期中，Orchestra通过使用来自路由层的信息安装和更新TSCH调度。RPL未经修改运行，随着拓扑的发展，时隙会自动设置，以确保网络连接并允许上层透明明亮的运行。一个基本的例子是orchestra维持用于父对子通信的专用时隙，在固定周期（例如1秒），在从父节点的唯一节点ID选择的时间偏移和信道偏移处重复。每当孩子切换父级，它会更新它的时隙以匹配新的父节点ID。

4.2 调度

orchestra运行特定于部署的调度规则，描述如何根据路由拓扑维护TSCH时隙帧和时隙

4.2.1 orchestra 时隙

我们定义了orchestra中的四种主要类型的时隙：普通共享时隙，基于接收机的共享时隙，基于发送机的共享时隙和基于发送机的专用时隙。orchestra在运行时动态映射到0,1或多个TSCH时隙上。在4节点网络（图3a）中，不同类型的orchestra时隙在图3中示出，并且仅示出了用于子到父traffic的时隙。

Common Shared Orchestra Slots (CS 普通共享时隙)：CS由一个共享时隙组成，由网络中的所有节点使用，为Rx（接收）和Tx（传输）工作，如图3b所示。时隙安装在固定的坐标（时间和信道偏移），导致其行为和时隙ALOHA很类似。这是模拟always-on链接，允许RPL来发现邻居并无缝的运行。注意，TSCH在每当单播传输未被确认时触发使用指数退避来解决共享时隙中的竞争。

Receiver-based Shared Orchestra Slots (RBS 基于接收机的共享时隙)：RBS被分配用于在从接收机的属性导出的坐标（时间和信道偏移）处的两个邻居之间的通信。在每个节点，RBS orchestra时隙产生一个Rx时隙（基于节点的坐标），以及每个相邻的一个Tx时隙（基于邻居的坐标）。为了计算时隙坐标，可以使用节点的MAC地址的哈希，对时隙帧长度进行模数，或者在可用时利用唯一的节点标识符计算。

一个典型的例子就是儿子父亲节点之间的通信：节点监听一个时隙中的任何traffic（动作），并且子节点维护一个朝向它们的父节点的发送时隙。所以，当节点切换父节点时，它们自主地更新其发送时隙。因为几个节点可以朝向相同的接收器安装时隙，所以在这样的时隙中可能出现竞争。例如，在图3c中，＃3和＃4打算使用标准TSCH回退发送到它们的父＃2。

 

 

图三就是在4节点网络中显示不同orchestra时隙类型的图示，展示出了子对父时隙。还示出了时隙属性：接收（Rx），转换（Tx），共享（S）。 在公共共享时隙中，所有节点同时唤醒以基于争用的方式接收或发送。 在基于接收器的时隙中，节点具有它们自己的接收时隙（这里基于节点ID），在其子帧向它们发送时产生竞争。在基于发送器的时隙中，节点具有它们自己的发送时隙， 他们的父节点被唤醒以接收数据。

Sender-based Shared Orchestra Slots (SBS 基于发送方的共享orchestra时隙)：SBS类似于RBS，除了时隙坐标是从发送者节点的属性而不是接收者获得的。在每个节点上，SBSorchestra时隙导致每个邻居（基于邻居的坐标）产生单个Tx时隙（基于发送者节点的坐标）一个Rx时隙。这导致比RBS更高的能量消耗（当没有业务时，Tx时隙不花费，而Rx时隙总是需要唤醒），但是也可以通过避免每个接收器的时隙分配来帮助减少争用。

例如，对于子对父通信，节点具有一个固定的Tx时隙，父节点对于其每个孩子都维持一个Rx时隙，无论何时切换父级，子级都不需要更新其发送时隙，但是旧的父级必须删除侦听时隙，新的父级要安装新的侦听时隙。在图3d中，＃2具有两个监听时隙，每个时隙对应一个子节点＃3和＃4。这里同样，利用来自标准TSCH共享时隙的回退来解决争用。

Sender-based Dedicated Orchestra Slots (SBD 基于发送者的专用orchestra时隙)：在足够长以容纳到每个节点的唯一发射时隙的时隙帧中，并且假设唯一的节点标识符可用，则无争用通信是可能的。Orchestra利用SBD实现的无争用通信，与SBS类似，除了它们使用专用TSCH时隙而不是共享时隙。注意，使用TCSH专用时隙，丢失的分组被重新发送而没有退避（使用朝向相同邻居的下一个时隙）。唯一节点ID可以在部署时进行硬编码，或在运行时从网络管理器获取。

4.2.2orchestra时隙帧

orchestra在每个节点处管理几个时隙帧，每个时隙帧被分配给特定traffic平面，例如，TSCH信标，路由业务，应用。时隙帧由一组时隙组成，具有由简单调度规则定义的属性。时隙帧在互斥的周期重复，确保它们独立循环。 在来自不同时隙帧的时隙重叠的情况下，优先级最高的时隙帧中的时隙优先。时隙帧的长度引入了业务容量(traffic capacity)，网络延迟和能量消耗的折衷。

Traffic Capacity：较短的时隙帧使它们的时隙更频繁地重复，导致更高的traffic容量。orchestra的方法是过度供应TSCH以支持非确定性业务，并且时隙帧长度是控制给定traffic平面的过度供应量的主要方式。

Network Latency：给定traffic平面上的每跳延迟时间基本上与该特定业务平面的时隙帧的长度成比例。

Energy Consumption：类似地，时隙帧越短，节点越不得不更加频繁地醒来收听或发送，从而导致更高的能量消耗基线。

4.2.3调度规则

orchestra使用简单的调度规则维护其调度，如本节所述。调度规则是一组增加了许多特定于orchestra的属性的TCSH时隙帧和时隙。这些属性有些是..IEEE802.15.4E里的标准属性（标记为std），一些是相对于标准属性的扩展属性（ext），一些是orchestra提出的新的属性（new）

orchestra时隙帧S的属性是：

Handle (std):用于识别和优先级的唯一正整数。 它越小，优先级越高。

Length (ext):时隙帧中的时隙数。 必须与网络中的所有其他时隙帧长度互斥。

Traffic Filter (new)：过滤分组属性（例如，单播，广播）和协议（例如，TSCH，RPL）。时隙帧由乐团时隙组成，每个时隙帧根据当前TSCH和RPL状态映射到0,1或多个TSCH时隙。例如，可以保留一个orchestra时隙，用于与所有TSCH时间源，RPL子节点或当前RPL首选父节点进行通信。时隙的属性包括：

Neighbors (new)：orchestra的邻居或邻居集合可以被实例化为：RPL优选父母节点或所有RPL子节点。 每当TSCH或RPL状态发生改变时，所得到的TSCH时隙就会自动更新。

Coordinates (ext)：时隙帧中的时间和信道偏移。 可以是固定的，也可以是诸如节点ID之类的变量，邻居MAC地址的散列。

Options (std)：标准TCSH选项。 包括：Rx（接收），Tx（传输），S（共享），定义什么时隙可以使用，是否是共享或专用。

虽然现在的orchestra规则在节点中被静态编程，但是可以设计一个基于CoAP的管理界面来在运行时定义新的规则。一旦安装了时隙帧和时隙，orchestra根据标准IEEE802.15.4e执行TSCH，除了发送时隙。对于发送时隙，除了匹配分组和时隙地址字段，Orchestra根据当前时隙时隙帧的业务过滤器检查分组。

4.3 性能分析

 

图4：对于20个节点的小区，每500ms一个traffic的业务负载，CS时隙与RBS/SBS时隙的分析争用概率如图。 RBS/SBS不消除争用，但大大减少。 SBD不在图中，因为它们是无争用的。

 

本节分析用不同类型的orchestra时隙获得的争用率。 然后对不同时隙帧之间的重叠频率制定保证，并且导出节点的无线电占空比的界限。

4.3.1Contention Rate（竞争率 争用率）

orchestra时隙以恒定的周期重复，以服务于特定的traffic平面。

 在时隙ALOHA中，任何传输面对争用的概率是：

 

 

其中T是时隙上的平均traffic负载，其中traffic遵循泊松分布。 例如，如果每两个时隙平均发送一个分组，则T = 0.5。

让我们考虑一个具有N个节点的网络的简单情况，所有节点都彼此连接（一个团体）。 在具有单个CS时隙的具有长度L的一个时隙帧的设置中，每个时隙的负载是T×L，并且争用概率是：

 

 

在具有RBS或SBS时隙的情况下，业务被散布在时隙帧中的所有时隙上。 如果时隙帧大于或等于网络大小，则流量在所有节点上均匀分布，从而将业务负载减少因子N。 否则，所有时隙在节点之间被均等地共享，从而以仅为L的因子减少业务负载。结果，争用概率为：

 

 

SBD时隙下争用概率为：

 

 

 

图四示出了在每500ms一个分组和10ms一个时隙的总体业务负载下，用于20个节点网络的p（cont CS），p（cont RBS）和p（cont SBS）其中T=1/50。在所有情况下，由于较稀疏的时隙重复，对于较长时隙的帧的，争用是增加的。 在任何时隙帧长度，RBS和SBS按照一个很重要的因素减少争用的水平。因此，在不需要公共交会槽的任何情况下，它们是可取的。4.3.2时隙帧覆盖

每个时隙帧以给定的周期（其在时隙中的长度）重复。令Bslot时隙帧B里时隙的个数，Blen是其长度，令collB表示给定时隙与B中的任何时隙冲突的事件。任何时隙与B冲突的概率为：

 

 

当发生这种时隙冲突时，来自具有较小句柄的时隙帧的时隙优先，所有其他时隙被跳过。我们将SF表示系统中所有时隙帧的集合。 由于与任何其他时隙帧的时隙冲突，A（被表示为Ah的句柄）被跳过的概率是：

 

 

 

 

 

 

 

4.3.3 Duty Cycle Bounds占空比边界

令rxMinDc表示在没有通信发生时Rx时隙的无线电占空比，其=rxGuardTime/slotLength

其中rx GuardTime表示TSCH Rx保护时间，sloLength表示TSCH时隙持续时间。

AdcRxBase是在没有通信时对时隙帧A的监听成本：

 

 

 

 

这里，A rxSlots是在时隙帧A中具有Rx标志的时隙的数量。

在没有要发送的数据的情况下，节点不在发射时隙中打开其无线电。 因此，时隙帧A的下限占空比为A dcLower = A dcRxBase。

由于接收保护时间，导致Rx时隙的最大占空比（表示为rxMaxDc）高于Tx时隙的最大占空比（表示为txMaxDc）。 当在每个Rx时隙（相应地，仅有Tx的时隙）接收到（相应地发送）完整大小的分组时达到上限占空比：

 

其中AtxOnSlot是时隙帧A中具有Tx标志而不是Rx标志的时隙数。

系统范围的下限和上限占空比为分别表示为：

 

4.4 orchestra调度实例

我们介绍了整个论文中用于讨论和评估的许多示例乐团设置。

4.4.1 6TiSCH最小调度

一个简单的例子是由6TiSCH定义的调度最小配置，它由具有单个公共共享（CS）时隙的单个时隙帧组成，此配置是非常实用的，因为它为任何流量类型在每个节点之间建立了基本连接。然而，所有时隙在整个网络中被共享，从而导致一个纯粹基于竞争的情形。我们将这样的设置称为TCSH-min-X，其中X是时隙帧的长度。

4.4.2 使用基于接收器的单播插槽进行设置

我们描述了由三个时隙帧组成的更高级的设置，包括用于单播的一个基于接收机的时隙帧。我们将这样的设置称为TCSH-RB-X-Y-Z，其中X，Y，Z是三个时隙帧S0，S1，S2的长度。

EB Slotframe（S0）：第一个时隙帧（S0）专用于EB（TSCH增强信标）传输，用于TSCH关联和子-父同步。这个时隙帧比网络中的节点数量长，并且包括一个基于发送器的专用（SD）时隙。结果，每个节点具有一个Tx时隙和一个Rx时隙，以从其时间源监听EB。 S0中的所有传输都是无争用的。我们使用X = 397个时隙作为S0的默认长度。

Broadcast Slotframe（S1）：我们添加一个具有一个公共共享（CS）时隙的时隙帧（S1）用于RPL广播消息。如§4.3所述，S1周期性地与S0冲突，因为后者具有更高的优先级。我们使用Y = 31个时隙作为S1的默认长度。该时隙与S0冲突并被跳过的概率是：

 

Receiver-based Unicast Slotframe（S2）：我们最终通过基于接收机的共享（RBS）时隙为具有RPL父和所有子的单播业务添加时隙帧（S2）。在此设置中，每个节点在从其自己的MAC地址导出的时间偏移处唤醒，侦听传入流量。我们为每个节点分配时间偏移hash（MAC）％Z，其中Z是时隙帧长度。由于与先前描述的时隙帧之一的冲突，S2中的任何时隙被跳过的概率是：

 

这意味着到给定邻居的单播传输将以96.3％的概率发生，否则被推迟到下一个时隙。

4.4.3 使用基于发送方的单播时隙设置

我们介绍上述设置的变体，其中单播传输发生在基于发送器的共享（SBS）时隙中。S0和S1与TCSH-RB相同，但S2被修改为使用SBS而不是RBS。我们将该设置称为TSCH-SB-X-Y-Z，其中X，Y，Z是S0，S1和S2的长度。

在这个设置中，每个发送者都有一个在S2中分配的发送时隙，每个节点监听它们的RPL父和子时隙。TSCH-SB的主要益处是与TSCH-RB相比减少了争用，其中到给定节点的所有传输发生在相同时隙中。缺点是更高的能量基线，因为节点需要唤醒并在他们或他们的父母和孩子的时隙中听。在所有节点具有唯一ID并且其中时隙帧长度Z大于网络大小的情况下，可以确保无争用传输，并且用专用的时隙替换共享Tx时隙。

图5示出了在Indriya测试台98个TelosB节点（c.f.，§6.1）上使用此设置并设置一个单播时隙帧具有101个时隙的（TSCH-SB-101）情况下，orchestra运行的情况。在这个特定的运行中，我们使用测试的节点ID来定义时间偏移，导致级联传输。该图显示了EB（橙色，级联）的周期性传输，广播

时隙（绿色，所有节点与基于竞争的通信对齐）和单播（蓝色，级联）。

 

图5：在Indriya（上）运行的60分钟乐团和4秒（底部）的缩放视图.EB和单播时隙帧导致活动的对角线，因为它们每个包含单个Tx时隙，时间偏移等于 到节点ID。 广播时隙帧在时间偏移0处具有单个公共共享时隙，因此导致垂直线，因为所有节点同时收听。 所有时隙帧以不同的周期重复。 占空比为0.47％。

 

5. 系统集成

我们在这里讨论一些我们应用于Contiki RPL的修改以实现高可靠性，而且我们介绍了TSH和Orchestra的实现。

Reliable RPL （可靠的RPL）： 因为我们的目标是高可靠性，并且确保TSCH节点总是具有可到达的时间源相邻者，我们如下调整RPL。

首先，我们注意到ETX指标建立尽力而不是可靠的路由。例如，56％的PRR跳（ETX = 1.8）被认为比两个完全跳更好（ETX = 1 + 1 = 2）。当可靠性重要时，后者应该明显优先。我们使用平方的ETX值作为链路的成本，以便有利于良好的链路，同时保持RPL的梯度性质。

第二，我们必须使RPL在切换父节点方面不那么积极，以避免切换到我们还没有很好统计的邻居。为此，我们实现了一个简单的探测机制：每个节点以给定的间隔（我们在本文的实验中使用4分钟）将单播探测传输到其最佳或第二最佳父节点。这允许节点保持最新的链路估计，确保它总是了解一些具有关于其备份（第二好）父的链路质量。我们还使用来自接收到的DIO的RSSI来计算到该DIO的发送方的ETX的初始估计。

第三，我们注意到，尽管RPL最终设法修复路由环路，但是在该过程中总是丢弃多个分组。 为了避免这种情况，我们添加一种机制，其中，每当检测到路由环路时，接收器节点向发送器传送单播DIO消息，从而迫使两个节点的路由状态的立即更新。

我们发现这些增强大大提高了端到端的传输率，不仅与TSCH和Orchestra，而且与异步MAC层（例如，99.8％的交付与ContikiMAC + RPL数据收集，这是我们在文献中知道的最好的结果）。

Implementation（3）：我们为Contiki操作系统实施TCSH和orchestra。这个实现支持两个平台，在下一节中评估：TelosB（MSP430,10kB RAM，48kB闪存，外部CC2420无线电）和NXP JN5168（SoC与32位RISC CPU，32kB RAM，256kB闪存，802.15.4无线电）。在这两种实现中，所有TSCH操作都由定时器中断（TelosB为32kHz时钟，JN5168为16MHz）控制，并禁止无线电中断。TCSH完全负责管理无线电和在适当时读出数据，以及生成和解析IEEE802.15.4e增强型ACK和信标。运行时调度修改如下：首先等待当前时隙的结束，禁用TSCH，在下一个时隙期间继续，恢复TSCH操作。TSCH（配有Orchestra TSCH-min设置和16个数据包的队列空间），当编译为TelosB时，具有10kB闪存和2kB RAM的内存占用。由于TelosB上可用的内存有限，除了TSCH之外，我们无法运行支持向下路由的RPL，只支持向上流量。JN5168支持所有可用的Contiki RPL功能。

 

6.评价

在本节中，我们首先在两个不同的测试台上展示广泛的实验，表明乐团在减少争用和实现高可靠性方面优于最先进的异步MAC层。 第二，我们运行模拟以与集中式调度器进行比较，其中我们量化自主调度方法的延迟和能量的成本，并且展示Orchestra对变化链路条件的适应性。 表1总结了我们的测试平台评估结果。

6.1 建立

Simulation and Testbeds. 我们使用三种不同的环境。首先，我们在Indriya进行实验，在新加坡的一个三层办公楼中设有98个TelosB节点。我们使用顶层的节点＃2作为网络的根。在Indriya的一个实验持续1h，重复3〜10次。显示的结果是具有标准偏差的平均值。

第二，为了克服TelosB平台的内存限制，我们使用部署在办公楼中的25个JN5168节点的测试台（JN-IoT）。我们使用节点＃1，在角落，作为根。JN-IoT测试台的结果来自每个配置的单个实验，每个实验持续16h和72h之间。 我们报告的结果通过总共219个测试台实验收集，并且我们从源到目的地路由1,178,601个UDP分组。

第三，要比较Orchestra对静态调度与完全控制网络条件，我们使用Cooja，Contiki的网络模拟器。Cooja模拟TelosB节点运行编译的MSP430固件，Cooja允许我们完全控制网络条件，并以可重复的方式模拟变化的连接。

Protocols：我们使用orchestra按照§4.4里的所有三个配置。我们将Orchestra与集中式静态调度器（在第6.6节中描述）和异步MAC层Always-on和ContikiMAC在8Hz和64Hz（c.f.，§3）调度器进行比较，所有协议每跳最多使用8次重传，队列中最多包含16个数据包。对于TSCH时隙定时，在TelosB上，我们使用15ms时隙和±0.6ms的保护时间，在JN5168上，我们使用10 ms时隙和±0.25 ms保护时间。 最后，我们通过最佳通道26运行Always-on和ContikiMAC，通过四个最佳通道运行TSCH：15,20,25,26。

Application Scenarios：我们运行两种不同的应用场景：向上路由和向下路由。在向上路由中，节点以给定的平均间隔向网络根发送分组，其中添加了抖动来模拟非确定性业务。这是通过禁用RPL向下路由实现的。在向下路由节点中，网络根随机选择网络中的节点并向其发送请求。目的节点通过发送响应立即回答。这是物联网场景中的典型流量模式，例如使用CoAP的RESTful体系构。在所有情况下，除了集中式调度，节点运行RPL，6LoWPAN，并且所有应用程序流量是具有16字节有效负载的原始UDP。每次运行的前15分钟总是被排除，以允许网络形成和RPL收敛到稳定的拓扑。

Metrics（指标）：我们关注的三个主要指标是端到端分组传送率（PDR），端到端延迟和无线电占空比。PDR是在应用层发送的使它到达其最终目的地的分组的部分，可能经过多跳。端到端等待时间是在初始应用程序发送分组的意图和其在最终目的地处的接收之间测量的。 占空比是无线电开启（发射，侦听或接收）所花费的时间的部分，并且用作与能量消耗的平台无关的测量。 此外，我们看看链路分组接收速率（PRR），即每跳，每传输尝试成功率。

6.2 与异步MAC的比较

我们在indriya运营orchestra，Always-on和ContikiMAC，每个节点以平均60秒的间隔产生向上的流量。 图6总结了我们的结果。

 

图6：Indriya的向上实验。 orchestra得到最高的交付率，在99.996％和99.997％之间。 这可以由下面得理由来解释：即由于较高的链路PRR，达到高达97％，与ContikiMAC的94％（在后一种情况下的损失的两倍）相比。 然而，ContikiMAC提供最佳的延迟能量平衡。 注意，PDR和PRR曲线的y轴不开始为零。

 

所有orchestra配置实现了高于99.99％的最高PDR，即小于每10k分组一个端到端丢失或10-4丢失率。 最好的异步结果是使用Always-on，达到99.9％的PDR，即，10 -3的丢失率，在orchestra后面差了一个数量级。 ContikiMAC是另一个数量级以下，99％或损失率为10 -2。

图6b示出了MAC成功率，即，由每个协议实现的链路质量。 对于所有协议，链路质量和端到端PDR之间存在明显的相关性，这意味着整体性能主要受到介质访问（而不是路由或队列丢弃）的限制。 orchestra获得了最高的MAC成功率，例如，相比于always-on的93％，TSCH-SB-47达到了97％。 我们认为这主要归功于乐团减少争用的能力。 TSCH-min是完全基于争用的，所以有着最低的成功率。

ContikiMAC获得的损失率比Orchestra高两个数量级，但实现了最佳的延迟能量平衡。例如，ContikiMAC @ 8Hz在0.8％的占空比下产生0.5s的延迟，而TSCH-SB-7对于相同的延迟具有1.4％的占空比。Always-on在100％占空比的设计结果，并且实现最低的延迟结果，因为节点不必等待其邻居在发送之前唤醒。

6.3 竞争控制和可扩展性

orchestra的主要目标之一是通过调度减少争用，以提高链路成功率和整体可靠性。 然而，限制是orchestra通过具有固定大小的时隙帧以及跨时隙帧中的所有时隙扩展节点来实现这一点。这可能会导致网络容量和可伸缩性问题。 我们通过改变TSCH-RB和TSCH-SB中的单播时隙帧长度来研究这一点。 我们认为，对于固定数量的节点（Indriya的98个节点）改变时隙帧产生类似于增加固定时隙帧的业务负载或网络大小的效果; 这使我们能够了解orchestra的网络容量和可扩展性。

图7显示了我们使用TSCH-RB-3到TSCH-RB-47和TSCH-SB-3到TSCH-SB-47（基于接收机和基于发送机的共享时隙）的结果。我们还引入了额外的情况，TSCH-RB-47 + 53和TSCH-SB-47 + 53，其中使用两个单播时隙帧，大小为47和53.这将不同单播时隙的数量增加到100，超过了网络的大小。在这种特殊情况下，我们使用节点的唯一ID为每个节点分配一个唯一的时隙。TSCH-SB-47 + 53因此保证完全无竞争（基于发送器的专用时隙）。

图7a显示，如我们在§4.3.1中的分析模型所预测的，TSCH-RB的争用速率在较大的时隙帧增加。 TSCH-SB显示低得多的争用速率，并且具有相反的趋势：其在更长的时隙帧中执行最佳，在47 + 53情况下最终完全没有争用。对于长度为3到29的时隙帧，争用保持大致恒定，在2-3％的范围内。这种低竞争率导致高链路PRR，在大多数情况下高于95％（图7b）。我们将TSCH-SB在处理争用中的优越性归因于其基于发送方的性质。 基于接收机的时隙更可能引起争用，其中到给定节点的所有传输发生在同一时隙中。这不是我们的§4.3.1的分析模型捕获的，它只考虑集团网络（在一个团体中，来自/到任何节点的传输可能冲突）。

 

图7：使用TSCH-SB，更长的时隙帧转换为更多的可用时隙和更少的竞争。在47 + 53时隙，网络是无争用的。较低的值导致争用速率低于3％.TSCH-RB遭受较长的时隙 ，由于节点的Rx时隙上的压力增加。 注意，PRR图的y轴不开始为零。

 

6.4 能量分布和界限

图8显示了不同的乐团配置如何影响节点之间无线电占空比的分布。对于每个配置，我们选择导致可比的占空比的参数，即所有节点在0.3％和3％之间。第一观察是TSCH-SB导致比TSCH-RB更少的均衡平衡的无线电占空比。这可以归因于在这个向上业务情形中的单播Rx时隙的变化数量。TSCH-SB对于每个孩子需要一个这样的时隙，而在TSCH-RB节点中具有单个单播Rx时隙。

表2显示了在所有实验期间测量的最小和最大每节点无线电占空比与§4.3中定义的理论边界。对于所有配置，包括ContikiMAC，我们发现理论下限是准确的。导出准确的上限证明更困难。对于ContikiMAC，它是异步的，上限是节点连续传输广播的情况，这可能导致占空比高达88％。对于TSCH-SB-29，我们也得到非常高的最大值31％ ，这对应于节点使用其所有的29个单播时隙来监听其子节点的情况。TSCH-min-7和TSCH-RB-29，由于它们更可预测的时间表，允许我们导出更现实和可用的上限，都在1.75×最大测量下。

总而言之，在必须限制能量消耗的情况下，orchestra可以产生保证没有节点将其无线电打开超过例如3％的时间的时间表。

 

图8：与ContikiMAC，TSCH-min或TSCH-RB相比，管弦乐队基于发送者的调度（TSCH-SB）具有在节点之间产生较少的均匀分布的占空比的缺点。

 

表2：测量和理论的最小和最大占空比。 在所有情况下精确预测下限，但ContikiMAC或TCSH-SB的上限非常悲观。

 

6.5物联网场景中的orchestra

我们现在移动到JN-IoT测试台并运行向上和向下流量实验。因为ContikiMAC没有移植到JN5168平台，我们只运行always-on和TSCH。我们使用TSCH-min-5和TSCH-SB-29配置。在后者中，由于我们具有大于网络大小的单播时隙帧，我们使用节点的唯一ID来导出无争用时隙。结果示于表1。

一般来说，JN-IoT中的PDR低于Indriya.这是由于物理拓扑和部署站点的差异。特别是，我们注意到，在工作日，与夜晚相比，链路质量有显着的波动，比在Indriya大得多。

在向上和向下的实验中，TSCH-SB-29实现了最高的PDR：比Always-on MAC少4倍的丢失，比TSCH-min-5少10倍。对于所有三种配置（Always-on，TSCH-min-5，TSCH-SB-29），当涉及向下路由时的结果比在向上情形中更糟。我们将其归因于RPL的固有属性，而不是TSCH或者orchestra。

在RPL中，拓扑针对根进行优化，并且仅通过在相反方向上重用链路来实现向下业务，而不保证链路质量。 图9示出了对于每个节点，当向上（从节点）或向下（向着节点）路由时的平均链路PRR。 虽然链路几乎是对称的，但是存在几个显着的例外，例如节点20的平均PRR增加86％，减少71％。在TSCH-SB-29实验中，在72小时发送的258k个分组中，46个丢失 ，其中35人向下，11人向上。 一半的向下损耗归因于链路损耗（部分由于链路不对称），其他归因于临时RPL不一致（环路或拓扑更新后的过时路由）。

总的来说，JN-IoT测试台的这一系列实验表明，orchestra可以在不同的硬件平台和网络上可靠运行，以及使用更具挑战性的流量模式。

 

图9：IN-IoT测试台中的下行实验：每节点链路PRR。 所有链接都是可用的，虽然不是完全对称。

 

6.6与静态调度的比较

本节的目标是评估与集中式静态调度程序相比，使用Orchestra与RPL的开销，同时显示Orchestra与RPL在对网络动态反应中的灵活性。

作为一个基准，我们实施一个简单的离线调度程序灵感来自Pöttner等人的工作。调度器对每个链路的PRR测量作为输入，计算它们的路由度量 - 它使用平方的ETX，如在乐团中，有利于良好的链路 - 并使用Dijkstra计算从每个节点到接收器的最短路径。路由建立仅支持数据收集流量，在预定义的时间间隔（在我们的实验中为30秒）。对于每个路由，我们计算整个网络中的传输的静态TSCH调度。冗余地计划路由以允许重传。注意，这是一个简单的调度程序，没有运行时重新配置也没有多路径传输。

对于这个特定的评估，我们使用Cooja / MSPSim模拟，以便完全控制实验的条件。我们在模型中配置无线链路以反映我们在JN-IoT测试台中测量的链路质量。然而，应当注意，Cooja中的这种无线链路模型呈现均匀分布的损耗，这在突发低功率网络中是不现实的。不过，我们认为对于该特定实验是足够的。

为了模拟网络动态，我们调整三个随机选择的节点的接收概率为0.1×它们的初始PRR，即受影响的节点仍然可以发送，但是10×更可能丢弃输入数据分组。 我们每15分钟重复一次，选择另外三个节点而不恢复先前衰减的节点。 对于不同的实验设置，这完全按照相同的顺序进行。 我们在Cooja中运行实验75分钟，并且仅在30分钟后开始引入故障以证明稳定条件的基线。

我们将静态调度（表示为静态）与以下三个配置的orchestra：TSCH-min-3，TSCH-RB-7，TSCH-SB-7进行比较。 图10显示了每个设置的结果。 首先，当网络稳定时（直到30分钟），我们注意到Static的成本极低。 与Orchestra相比，Static可以产生4到8倍的低占空比（TSCH-SB-7和TSCH-Min-3）和10倍的低延迟。我们将这些归因于静态中的调度和路由，其中（1）被确定为流量负载（2），其被优化以沿着网络最短路径（3）最小化等待时间并且被构建离线涉及在运行时没有邻居发现和路由协议。在端到端PDR方面，两个解决方案都表现异常出色，除了Orchestra需要一点启动时间（在这个特定的设置中大约5分钟）来找到良好的链路和稳定，而Static预先配置与最好的链接和时间表。

第二，我们检查注入网络接收故障（分钟30及以后）后的结果：静态直接降低性能，因为它不适应拓扑变化。 然而，随着乐团，PDR每15分钟暂时下降，然后RPL快速找到新的路线和恢复。

总的来说，乐团对网络连接的变化快速反应，但与针对特定拓扑和流量模式集中建立的调度相比，它在延迟和能量上具有显着的开销。

 

8 结论

本文介绍了Orchestra，一种用于在RPL网络中自主调度TSCH的解决方案。 orchestra运行没有任何中央调度实体或协商，并支持低功率随机接入业务。 关键思想是为不同的业务平面提供一组时隙，并且以这样的方式定义时隙，使得它们可以随着RPL拓扑的发展而自动安装/移除。

我们在Contiki实施乐团，并在模拟和两个不同的测试台上进行广泛评估。我们展示了乐团的实用性及其持续实现最高交付率的能力，同时发现了一个有趣的延迟-能量平衡。

作为未来工作的一部分，我们计划研究如何优化时间同步，进一步降低能耗，探索6TiSCH的管理解决方案启用乐团的运行时重新配置。