概述

　　在变色龙架构中，不同的协议使、程序用不同的逻辑通道进行通信。每个通道都有自己的一些列协议和包属性。在下图中，应用程序1使用运行在Rime协议栈之上的组网路由协议，应用程序2直接使用Rime协议栈，这两个应用程序各自拥有自己的逻辑通道。

概述

　　关于Rime的缓冲区管理这一块，能在网上搜到很多博客，但是我想说的是，99%+都是过时的，坑爹啊！Contiki的开发非常活跃，所以对代码的改进很多，而Rime的缓冲区管理这也在今年二月份进行了优化，由之前难以理解的、晦涩的“双头栈”改为了现在通俗易懂的结构。双头栈有多晦涩，你将contiki的代码reset到今年二月份之前去看看就知道了。
　　不过不要马虎，虽然现在的缓冲管理变简单了，但是它很重要！很重要！！很重要！！！
　　为啥说它很重要呢？

概述

　　包属性其实属于下一篇博客《Rime 协议栈: 缓冲区管理 packetbuf management》的一部分，但是它比较难以理解，所以单独抽出一篇博客对它做介绍。
　　为了兼容其他协议，Rime不定义任何头部格式，而用包属性代替。一种属性是一种头部字段的抽象。当Rime协议栈中的子协议要发送一个包时，会传递一个属性链表下来。属性链表里包含了若干个属性，这些属性最终会被转换成头部的字段。
　　该部分代码位于:contiki/core/net/packetbuf.[ch]。

概述

　　linkaddr模块是对Rime中地址的抽象表示，用来标识节点在无线传感器网络中的地址。
　　在早期的Contiki代码中，节点地址是以rimeaddr表示的，所以网上很多教程都是rimeaddr的。在2014年1月30日后，adam对Contiki中的所有节点地址相关定义由rimeaddr_xxx修改为linkaddr_xxx。这样做的理由是linkaddr模块不仅仅在Rime协议栈中使用，还被其它很多模块使用。请参考adam的pull request。
　　linkaddr相关源码位于contiki/core/net/linkaddr.[ch]

前言

打算写一个系列的博客来介绍 Rime 协议栈，思来想去，既然是程序员，当然还是用一个程序引入比较好。当然，这个程序必须满足以下几点：

• 足够简单，不会把大家给吓着了
• 能够引入足够多的知识点，可以串起来
• 能够说明包如何在网络中传输

然后我就找啊找，找到了Contiki的一个demo例程：examples/rime/example-abc.c

摘要

　　在早期的传感器网络的研究过程中，人们发现传统的分层通信架构具有太多的局限性，因此提出了跨层优化。不过，在最近的研究工组中，人们又发现跨层优化过于复杂，可能导致系统很脆弱或者难以管理。在此条件下，我们开发了Rime。Rime是用于传感器网络的分层通信协议栈，比传统架构的分层更精细。我们设计Rime的初衷是简化协议的实现过程。经过初步评估证明，只需要增加一点点资源，就能显著地简化传感器网络中协议实现的复杂性。这表明，即使在传感器网络中，使用分层协议栈也是可取的。

介绍

　　在早期的传感器网络的研究过程中，人们发现传统的分层通信架构具有太多的局限性，因此提出了跨层优化。具体来说，在底层实现上层优化。但是最近的研究工作中，人们又发现跨层优化过于复杂，导致系统脆弱、难以管理。相反，一个更加传统的分层架构被提出来了，且其效率也跨层架构相近。这也使得我们再次将精力投入到分层通信抽象中。
　　本论文重点是介绍Rime——一个为传感器网络设计的轻量级分层通信协议栈。Rime不同于传统分层架构，比如因特网架构，Rime的每一层很薄（即Rime是轻量级的）。Rime的代码量小于2kb，内存需求大约为几十个字节。
　　Rime的目的是简化传感器网络协议的实现，以及促进代码的重用。我们已经在Contiki中实现Rime协议[3]，并经过初步评估证明，Rime在只需要增加一点点资源的情况下就能显著地简化协议的实现难度。
　　Rime设计得比已经存在的传感器网络模块化通信抽象协议都更加简单。Rime不是一个完全模块化架构，即不允许所有的模块被替换，而仅仅运行最底层和应用层被替换。

Rime

　　Rime的分层结构如图1所示。就接口和实现而言，Rime的各层都极其简单。发出消息时，每一层都添加本层头部。由于Rime的各层都很简单，因此各层头部也很小，一般都是几个字节。
　　由于Rime各层都很薄，这就使得在堆栈内部重用代码变得可能。例如，可靠可信不是由一层实现的，而是被划分为两次。一层实现消息确认和定序，另一层负不停地重发消息，直到上层告诉它停止。我们将后面那一层叫做“顽固层”（stubborn）。顽固层不仅被用于可靠协议，还用于那些需要发送周期性消息的协议，比如路由协议中的邻居维护、需要反复传输的Rime洪泛路由层。图2展示了如何通过Rime的顽固层广播，sibc，可靠单播，ruc实现的逐跳可靠数据采集协议。
　　Rime的最底层是匿名广播abc（anonymous broadcast）。abc层提供了一个16bit的抽象通道，但是不对节点编址（编址由上层协议完成）。被标识广播ibc（identity broadcast）添加了一个发送标识头字段。单播uc（unicast）添加了一个结束头字段。
　　潜在的MAC或者链路层可以选择在硬件或者固件张实现Rime栈的一部分，比如abc,ibc或者uc。
　　

初步评估

A.内存占用

　　单个Rime模块的代码内存占用是很少的。当前最小的模块是ibc，它只占用100字节。最大的模块时顽固层单播和可靠单播，它们占用266字节。当前Rime所有模块总占用的内存不超过2kb。当然，如果添加更多的特性，占用量肯定会增加。
　　Rime中的每一层的每个连接都需要二到四个字节的内存空间。顽固层由于包含重传定时器，需要额外占用18个字节内存。不过，如果对定时器进行内存占用优化，它所占用的字节数应该更少。

B.逐跳可靠数据采集路由协议

　　为了评估Rime，我们使用Rime重新实现了Contiki的逐跳可靠数据采集路由协议Treeroute。我们对比了两者所占用的代码行数以及内存占用量，发现Rime能够显著简化传感器网络的协议实现。
　　在这个初步评估中，Treeroute的重新实现没有完全遵循已经存在的实现。已存在的实现隐式地使用确认消息，而重新实现时显示地使用确认消息。
　　重新实现的结果如表1所示。统计的代码行数不包括注释。两者都使用编译器GCC 3.2.3编译。重实现的代码占用不包括Rime模块的代码占用，内存占用包括Rime模块的内存占用。从表中可以看出，程序大小明显减小了，头部有一点点增加。
　　尽管重新实现数据采集协议模块的代码和内存占用都显著减小了，但是数据采集协议和Rime的代码总量比已存在的数据采集实现略大。在使用Rime的系统中，Rime模块分摊了各个模块的占用量。因此，从整体上来说，使用Rime的系统减小了整体的代码占用和内存占用。

总结

　　我们的初步评估表明，Rime只需要增加一点点资源代价，就能显著简化传感器网络协议的实现。如果更周密地评估后，依然保持该结果，那么就可以证明，分层协议栈也适用于无线传感器网络。

摘要

　　为了降低系统功耗，低功耗无线设备必须尽可能地将无线电收发器关闭，但是为了接收来自邻居节点的通信消息，它必须被经常唤醒。本论文描述了ContikiMAC RDC(Radio-Duty-Cycling)机制，该机制通过使用一系列时序限制，从而达到既关闭收发器又能高效唤醒的作用。在ContikiMAC机制的作用下，参与网络通信的节点的无线电开关在99%的时间内都是关闭的。本论文描述了ContikiMAC机制，测量了ContikiMAC操作的能耗，评估了快速睡眠和锁相优化的效率。

介绍

　　低功耗无线设备必须具有严格的电源消耗以达到增加设备寿命年限的作用。在低功耗无线设备的左右组件中，无线收发器的功率消耗最大。无线收发器被动接收其它设备消息与主动向其它设备发送消息所消耗的电量是一样的，所以为了达到节能的目的，收发器必须被完全关闭。但又由于收发器在关闭状态时不能接收到任何数据，所以需要一个机制周期性地将打开收发器。在这些年，很多种这样的机制已经被提出来了。在Contiki2.5中，默认的机制是ContikiMAC。

　　ContikiMAC设计的初衷是易于理解和实现。ContikiMAC只使用异步机制，无需发信号消息，也没有附加包头。ContikiMAC包是普通的链路层消息。ContikiMAC具有显著的节能唤醒机制——周期性暂停（duty cycling）机制。该机制的实现依托于精确的时序——一些列严格的时序。除此之外，ContikiMAC使用最优化的快速睡眠和最优化的锁相传输。

　　ContikiMAC中的机制受到已经存在的周期性暂停协议启发。很多协议都使用了周期性唤醒的思想，比如B-MAC，X-MAC，Box-MAC。最优化的锁相技术最先被WiseMAC提出，现在已被也在在其它很多协议中使用。数据包的多拷贝已经被TinyOS Box-MAC协议所使用。

　　本论文的剩下部分以如下形式组织：第二章描述ContikiMAC机制及其基本原则，第三章描述Contiki2.5中ContikiMAC协议的实现过程，第四章在一个数据采集网络中评估ContikiMAC的能量效率，第五章描述相关工作，第六章作总结。

ContikiMAC

　　ContikiMAC是一个RDC（Radio Duty Cycling）协议，使用周期性唤醒机制来侦听来自邻居节点的消息包。对于接收器，如果在被唤醒时检测到了数据包，它将继续保持唤醒状态来接收包。当成功接收到包后，接收器发送一个链路层确认消息。对于发送端，如果想发送一个包，就需要周期性地发送该包，直到收到来自接收器的链路层确认消息。广播包不会引起链路层确认消息。相反，发送端在怎个唤醒间隔内都将周期性发送该包，以确保所有的邻居节点都能收到广播包。图1和图2展示了ContikiMAC的机制。

　　ContikiMAC的时序如图3所示，从图中可以看出其时序要求：

t_i:每个包传输之间的间隔
t_r:RSSI需要的稳定时间，也是CCA需要的稳定时间
t_c:每个CCA之间的间隔
t_a:接收到一个包与发送确认消息之间的间隔
t_d:成功检测到接收端的确认消息所需要的时间。

　　这些时序必须满足很多约束条件。首先，包之间的时间间隔t_i必须必CCA之间的时间间隔t_c小，这能保证第一个CCA或者第二个CCA检测到有包在传输。如果t_i比t_c大，就有可能两个包都不能检测到有包在传输。

　　如图4所示，ContikiMAC所支持的最短包大小也依赖于t_i和 t_c的时序。为了确保两个CCA能够检测到包，传输包不能太短以致于在两个CCA之间就传送完了而无法检测到。明确地，最短包的传输时间必须必大于t_r+ t_c+t_r。

• t_i = 0.4 ms
• t_c = 0.5 ms
• t_s = 0.884 ms

  包检测和快速睡眠

  　　ContikiMAC的CCA包检测是不可靠的：它只检测信号强度是否比一个给定值大。检测到无线信号可能是邻居节点正在向本接收器传输包，也可能是邻居节点正在向其它接收器传输包，甚至是其它设备（不属于该网络，比如一个人带了一个手机进入该范围）发出的无线信号。ContikiMAC必须对此进行辨别，并作出相应的应对措施。
  　　如果一个邻居节点正在向一个接收器传输一个包，那么接收器就应该保持在唤醒装填来接收完整的包，并发送一个链路层确认消息。而其它检测到该包的节点，就该再次快速进入睡眠状态。不过，这些节点并不能快速进入睡眠，因为它们必须接收完整的包。有一个很简单的方法，当CCA检测到无线信号时，在t_l + t_i + t_l时间内一直保持唤醒状态。
  　　其中，t_l是可能的最长传输时间，这确保包能够完整地被接收器接收到（如果在包传输开始时CCA就检测到了信号）。
  　　最优化快速睡眠能够让接收器接收到无线噪声时更早地进入睡眠状态。首先，如果CCA检测到无线信号，且持续时间大于t_l，且CCA检测到噪声，那么节点就回到睡眠。也就是说，信号活跃期后面没有跟随一段信号安静期。第二，如果信号活跃期后跟随着一段信号安静期，但是安静期时间比t_i（两个成功传输的时间间隔）小，那么节点就回到睡眠。第三，如果信号活跃期后跟随一个时间长度正确的安静期，然后再跟着活跃期，但是没有检测到包头，那么节点就回到睡眠状态。该过程如图5所示。
  　　
  　　图5. ContikiMAC最优化快速睡眠：如果在t_l之前一直没检测到安静期，进入睡眠；如果安静期大于t_i，进入睡眠；如果没有接收到包，进入睡眠

  锁相传输

  　　如果我们家是每个接收器都有一个周期的、稳定的唤醒间隔，那么发送器就能利用接收器的唤醒相位来优化它的传输。发送器可以通过接收器发送的链路层确认消息来推断出接收器的唤醒相位。由于接收器必须处于唤醒状态来接收包，如果发送器接收到一个链路层确认消息，就可以假设发送器已经在接收器的唤醒窗口中正确地传输了包，因此就找到了接收器的唤醒相位。发送器在知道接收器的相位后，就可以在接收器下次将要唤醒时开始发送下一个包。整个流程如图6所示。
  　　
  　　锁相传输：成功传输一个包后，发送器获取到接收器的唤醒相位

  实现

  　　在Contiki 2.5的ContikiMAC中，采用实时定时器rtimer来执行周期性唤醒功能，这样就能保证即使很多进程在运行，也能保证ContikiMAC的稳定性。实时定时器能够在精确的时间点上抢占如何Contiki进程。ContikiMAC以一个protothread进程的方式运行唤醒机制，被一个周期的实时定时器调度。这个protothread进程执行周期性的唤醒和最优化快速睡眠。
  　　包的传输是用通用的Contiki进程驱动的。如果一个唤醒进程在无线收发器忙的时候被调度，唤醒定时器将在一个唤醒间隔后调度一个新的唤醒进程。
  　　锁相机制独立于ContikiMAC，以模块的形式实现，便于用在其他的周期性暂停机制中，比如Contiki X-MAC。锁相机制维护了一个邻居链表以及它们的唤醒相位。ContikiMAC传输逻记录了每个包传输时的时间，当它收到一个链路层确认消息后，通知锁相模块更新最后一个包的传输时间。该时间近似于接收器的唤醒锁相。
  　　在开始传输之前，ContikiMAC传输逻辑调用锁相模块，检测其是否记录了接收器的唤醒相位。如果记录了，锁相代码就将包放到传送队列中排队，并在预期的接收器唤醒时间点设置一个回调定时器ctimer。当产生回调时，ContikiMAC就会开始传输。这种情况下的传输将会比普通传输时所消耗的时间短很多，因为传输是在邻居节点将要唤醒时开始的。传输时间少了，进一步也减小了拥塞。
  　　如果一个被记录的邻居节点被重启了，或者它的时钟与记录的唤醒相位产生了大的漂移，那么传输将会失败。为了防止这种情况发生，ContikiMAC为每个几率的邻居节点维护了一个计数器，用于记录失败的次数。当失败次数达到一个固定值的时候（在Contiki 2.5中该值是16），就将该节点从链表中删除。同样地，如果在一个固定的时间内（在Contiki 2.5中时30秒）没接收到链路层确认消息，无论计数器的值是多少，都会从链表中删除该节点。

  评估

  　　本论文对ContikiMAC做了两方面的评估：个体ContikiMAC的能耗和数据采集传感器网络中ContikiMAC的能耗。除了这里所展现的结果，我们还将ContikiMAC运用在许多最近的工作中。更多的关于ContikiMAC的性能结果，读者可参考Dunkels等人的文献[3]，Duquennoy、Osterlind、Dunkels 的文献[7]，Duquennoy等人的文献[8]，Kovatch、Duquennoy、Dunkels的文献 [16]，Lunden、Dunkels的文献[17]和Tsiftes、Dunkels的文献[24]。

  微观基准

  　　我们通过运行ContikiMAC的Tmote Sky mote来测量个体能量消耗。我们将一个100欧姆的电阻与Tmode Sky电源串联，然后使用示波器测量电阻上面的电压。ContikiMAC在Tmote Sky I/O的某个引脚上注册无线信号的状态，其中高电平表示无线信号处于开启，低电平表示无线信号处于关闭，然后用相同的示波器测量这个引脚的状态。测量时的唤醒频率是8Hz，即唤醒间隔为125ms。
  　　图7画出了在没有任何包传输时的ContikiMAC的唤醒情况。在下面那幅图中，我们可以看到，无线信号两次被打开以执行两次CCA。图8显示了当第二个CCA检测到一个假的无线信号活跃期时的ContikiMAC唤醒状态。无线信号继续保持了一会儿开启状态，直到最优化快速睡眠关闭了无线信号。
  　　
  　　图7. 检测不到信号时的ContikiMAC唤醒情况。在下图中可以看到两个CCA
  　　
  　　图8. 检测到虚假无线信号是的ContikiMAC唤醒情况
  　　图9和图10显示了接收广播和组播时各自的情况。在这两种情况下，作为ContikiMAC唤醒机制的一部分，无线信号都被打开，第一个CCA就检测到了活跃的无线信号。我们可以看到，在接收组播的过程中，无线信号开启的时间更长。这是因为接收确认消息也是接收组播包的一部分。
  　　
  　　图9. 接收广播：唤醒、包检测、接收广播包
  　　
  　　图10. 接收组播：唤醒、包检测、接收组播包
  　　图11描述了广播传输情形。广播必须唤醒并传递包到所有的邻居，因此它在整个唤醒间隔期间内都在运行。由于广播不需要接收链路层确认消息，因此发送器可以在两个传输之间关闭无线信号，以达到节能目的。图12描述了向周围邻居发送组播消息的情形。在这种情形下，邻居大约每隔60ms被唤醒一次，因此发送器每隔70ms就重复传输包。传输的开始阶段是信道空闲检测的初始化阶段。经过锁相技术后，随后的传输可以被优化，即在邻居即将唤醒时开始传输。图13描述了经过锁相优化后传输次数减小的情形。
  　　
  　　图11. 广播传输
  　　
  　　图12. 非同步组播传输（随后在110ms时被唤醒）
  　　
  　　图13. 同步组播传输（随后在110ms时被唤醒）
  　　通过计算从图7到图13的面积，我们可以得到每个情形下的能源消耗，其计算结果如图14所示。我们可以看到，广播传输比唤醒所需要的成本大了很多数量级。这是非常好的：唤醒时ContikiMAC中最常见的操作——每秒会执行很多次。
  　　通过图14，我们可以比较ContikiMAC唤醒操作与其他周期性暂停机制中唤醒操作的成本。表1展示了在ContikiMAC，Contiki X-MAC，以及Hui和Culler的周期性暂停机制[14]中唤醒的成本。
  　　
  　　图14. 单一ContikiMAC操作的能源消耗
  　　 Protocol | Energy (uJ) -------- | --- X-MAC [1]| 132 132 | 54 ContikiMAC | 12 　　
  　　表1：唤醒操作的能源消耗比较

  网络功率消耗

  　　为了评估ContikiMAC消耗的网络功耗和优化效率，我们在Contiki仿真环境中运行了一系列的仿真。Contiki仿真环境由Cooja网络仿真器和MSPsim设备仿真器组成。MSPsim提供了精确循环（cycle-accurate）的Tmote Sky仿真和CC2420收发器的精确符号仿真。它使在一个时序精确、受约束的环境中研究ContikiMAC行为成为可能。
  　　我们使用具有20个节点的仿真拓扑运行了一些列仿真。所有的节点都运行Contki和Contiki采集协议。Contiki采集协议是Contiki Rime协议栈的一部分，它使一个地址开发的采集协议。Contiki采集协议建立了一个树根，并向包的路由方向扩展。我们通过对Contiki采集协议做实验[15]，发现该协议与其它数据采集协议相似，比如TinyOS采集树协议[12]。

  还有一点点，看了感觉作用不大，就跳过了

相关工作

　　无线收发器的高功耗是一个知名问题，这使得许多研究都花在RDC上面。RDC机制可以分为两类：同步和异步。同步机制依赖于每个正在被同步的邻居节点，而异步机制不依赖于任何同步。异步机制可以进一步被划分为发送器初始化和接收器初始化。在发送器初始化机制中，由发送器初始化发送器和接收器之间的通信；在接收器初始化机制中，由接收器初始化通信。ContikiMAC是一个发送器初始化异步机制。
　　异步协议的优点是不需要同步，且其研究社区已经扩展了很多不同类的异步协议。早期关于传感器网络架构的工作发现了一个简单异步机制——低功耗侦听，节点被周期性唤醒，以侦听媒介中有无唤醒请求。如果发现了唤醒需求，无线信号就保持唤醒以接收包。当要发送包时，发送器首先发送一个唤醒请求，以唤醒邻居节点。后来，低功耗侦听机制被移植到X-MAC中。在X-MAC中，唤醒请求由一系列的选通（strobe）包组成。当接收器被唤醒后，它发送一个链路层确认消息，以表示它处于唤醒状态且已经做好接收包的准备。ContikiMAC与低功耗唤醒机制及其相似，但是在数据包传输时具有精确的时序，它的唤醒机制更高效。

总结

　　本论文描述了为低功耗无线传感器网络设计的ContikiMAC RDC机制，即Contiki 2.5中默认的RDC机制。ContikiMAC设计的初衷是易于理解和实现，使用异步和隐式同步，不需要附加头部。ContikiMAC使用一个精心设计而又简单的时序策略使唤醒更高效，使用锁相机制使传输更高效，使用快速睡眠机制使接收器收到错误信号时快速进入睡眠。测试证明，唤醒机制比已存在的周期性暂停机制更省电，锁相和快速睡眠也使网络功耗降低10%到80%（依赖于网络中设备的唤醒频率）。

参考文献

[1] M. Buettner, G. V. Yee, E. Anderson, and R. Han.X-MAC: a short preamble MAC protocol for dutycycled wireless sensor networks. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Boulder,Colorado, USA, 2006.
[2] A. Dunkels, J. Eriksson, N. Finne, and N. Tsiftes.Powertrace: Network-level power profiling for low-power wireless networks. Technical Report T2011:05, Swedish Institute of Computer Science,March 2011.
[3] A. Dunkels, L. Mottola, N. Tsiftes, F. Osterlind, ¨J. Eriksson, and N. Finne. The announcement layer:Beacon coordination for the sensornet stack. In Proceedings of the European Conference on Wireless Sensor Networks (EWSN), 2011.
[4] A. Dunkels, F. Osterlind, and Z. He. An adaptive ¨communication architecture for wireless sensor networks. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Sydney, Australia, November 2007.
[5] A. Dunkels, F. Osterlind, N. Tsiftes, and Z. He. ¨Software-based on-line energy estimation for sensor nodes. In Proceedings of the IEEE Workshop on Embedded Networked Sensor Systems (IEEE Emnets), Cork, Ireland, June 2007.
[6] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali. Protothreads: Simplifying event-driven programming of memory-constrained embedded systems. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Boulder, Colorado, USA, November 2006.
[7] S. Duquennoy, F. Osterlind, and A. Dunkels. Lossy ¨Links, Low Power, High Throughput. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Seattle, WA, USA, November 2011.
[8] S. Duquennoy, N. Wirstrom, N. Tsiftes, and ¨A. Dunkels. Leveraging IP for Sensor Network Deployment. In Proceedings of the workshop on Extending the Internet to Low power and Lossy Networks (IP+SN 2011), Chicago, IL, USA, April 2011.
[9] P. Dutta and A. Dunkels. Operating systems and network protocols for wireless sensor networks. Philosophical Transactions of the Royal Society A,370(1958):68–84, January 2012.
[10] Prabal Dutta, Stephen Dawson-Haggerty, Yin Chen,Chieh-Jan Mike Liang, and Andreas Terzis. Design and Evaluation of a Versatile and Efficient Receiver Initiated Link Layer for Low-Power Wireless. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys),Zurich, Switzerland, November 2010.
[11] A. El-Hoiydi, J.-D. Decotignie, C. C. Enz, and E. LeRoux. wiseMAC, an ultra low power MAC protocol for the wiseNET wireless sensor network. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys),2003.
[12] O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis. Collection tree protocol. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Berkeley,CA, USA, 2009.
[13] J. Hill and D. Culler. Mica: A wireless platform fordeeply embedded networks. IEEE Micro, 22(6):12–24, 2002.
[14] J. Hui and D. Culler. IP is Dead, Long Live IP for Wireless Sensor Networks. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Raleigh, North Carolina, USA, November 2008.
[15] J. Ko, J. Eriksson, N. Tsiftes, S. Dawson-Haggerty,M. Durvy, J. Vasseur, A. Terzis, A. Dunkels, and D. Culler. Beyond Interoperability: Pushing the Performance of Sensornet IP Stacks. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Seattle, WA,USA, November 2011.
[16] M. Kovatsch, S. Duquennoy, and A. Dunkels. A Low-Power CoAP for Contiki. In Proceedings of the Workshop on Internet of Things Technology and Architectures (IEEE IoTech 2011), Valencia, Spain,October 2011.
[17] M. Lunden and A. Dunkels. The Politecast ´Communication Primitive for Low-power Wireless.ACM SIGCOMM Computer Communication Review, 41:31–37, April 2011.
[18] D. Moss and P. Levis. BoX-MACs: Exploiting Physical and Link Layer Boundaries in Low-Power Networking. Technical Report SING-08-00, Stanford University, 2008.
[19] R. Musaloiu-E., C-J. M. Liang, and A. Terzis.Koala: Ultra-Low Power Data Retrieval in Wireless Sensor Networks. In Proceedings of the International Conference on Information Processing inSensor Networks (ACM/IEEE IPSN), St. Louis, Missouri, USA, 2008.
[20] K. Pister and L. Doherty. TSMP: Time Synchronized Mesh Protocol. In Proceedings of the IASTED International Symposium on Distributed Sensor Networks (DSN08), Orlando, Florida, USA, November2008.
[21] J. Polastre, J. Hill, and D. Culler. Versatile low power media access for wireless sensor networks. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys),Baltimore, MD, USA, 2004.
[22] J. Polastre, R. Szewczyk, and D. Culler. Telos: Enabling ultra-low power wireless research. In Proceedings of the International Conference on Information Processing in Sensor Networks (ACM/IEEEIPSN), Los Angeles, CA, USA, April 2005.
[23] Y. Sun, O. Gurewitz, and D. Johnson. RI-MAC: A Receiver-Initiated Asynchronous Duty Cycle MAC Protocol for Dynamic Traffic Loads in Wireless Sensor Networks. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Raleigh, NC, USA, 2008.
[24] N. Tsiftes and A. Dunkels. A database in every sensor. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Seattle, WA, USA, November 2011.
[25] T. van Dam and K. Langendoen. An adaptive energy-efficient MAC protocol for wireless sensor networks. In Proceedings of the International Conference on Embedded Networked Sensor Systems (ACM SenSys), Los Angeles, California, USA, November 2003.
[26] W. Ye, J. Heidemann, and D. Estrin. An EnergyEfficient MAC Protocol for Wireless Sensor Networks. In Proceedings of the IEEE Conferenceon Computer Communications (INFOCOM), New York, NY, USA, June 2002.

摘要

　　在微嵌入式系统和传感器网络节点中，事件驱动编程是一个受欢迎的模型。尽管事件驱动编程能降低内存开销，但由于它强制使用状态机编程风格，使许多程序难以编写、维护和调试。我们展示了一个新颖的被叫做protothread的编程抽象，使得在每个protothread只消耗两个字节的前提下，可以用类似线程的风格来编写事件驱动程序。我们检查了很多采用事件驱动状态机制实现的程序，若采用protothread机制改写，将大大减小其复杂性。对于这些被检查的大多数程序，其状态机可以完全被移除。而剩下的那部分程序，其状态机数量也能被彻底地减小。通过protothread机制，代码的行数能减小三分之一。基于protothread的程序，其执行时间与一些处理器的周期相当。

介绍

　　包括传感器网络在内，在内存受限的嵌入式系统中，最常见的编程模型是事件驱动编程。相比较于多线程系统，事件驱动系统不需要为每个线程栈分配内存空间，这更符合低内存需求。基于这个原因，传感器网络中的许多系统个，包括TinyOS、SOS和Contiki都采用事件驱动模型。根据Hill等人所说的：“在TinyOS中，我们采用事件驱动模型，使得高并发性能在非常小的空间中处理。而基于栈的编程方法需要为每个执行内容保留栈空间。”事件驱动编程也常常被用于那些由于内存受限而不能满足通用目的的嵌入式操作系统中。
　　事件驱动模型不支持阻塞等待。因此，这些系统中的程序通常需要使用状态机来实现上层逻辑的控制流。状态机属于系统规范的一部分。与状态机不同，控制流状态机通常没有正式的规范，是由程序员凭空创造的。经验表明，通过确切的状态机来管理控制流将使得事件驱动编程更加复杂。正如Levis等人所说：“这种方法是为响应处理、与硬件通信而设计的，但是由于逻辑阻塞队列必须使用状态机风格实现，使高级操作队列复杂化。”此外，在微嵌入式系统中受欢迎的语言，比如C和nesC，都没有提供任何用于帮助程序员管理状态机的工具。
　　在本论文中，我们将研究protothread是如何减小事件驱动程序中状态机的数量的。
　　本论文的贡献是向大家展示了通过减小状态机需求，实现简化事件驱动编程的原理。在不需要任何机器架构相关代码的前提下，只用C语言就能很简单地实现protothread机制的原型。在之前的论文中，我们已经体现了protothread的思想。在本论文中，我们将通过改善protothread机制、量化和评估protothread工具，来扩展之前的工作。
　　为了评估protothread，我们使用protothread重写、分析了大量的事件驱动程序。我们使用了三个量度来度量protothread的效果：状态机的数量、状态机转换的数量和代码行数。实验证明，我们重写的这些程序，在这三个度量上都有显著效果。对于多数程序，状态机能完全被消除。对于剩下的其它程序，protothread显著地减小了状态的数量。与状态机相比，protothread的内存消耗是单字节的。protothread的内存消耗明显低于传统多线程。protothread的执行时间是几个处理器周期。
　　我们不提倡将protothread作为状态机的通用替代品。状态机是设计、模块化和分析嵌入式系统的强有力的工具。状态机提供了一个有根据的形式体系，允许推断系统状态，且在某些情形下提供系统行为的证据。不过，对于很多情形，protothread在不引进任何可感知到的内存消耗的前提下，能大大简化程序。特别的，我们已经看了很多事件驱动系统的程序，它们的状态机在多数情形下只对程序代码可见，难以从代码中提取出来。
　　我们最初开发protothread的目的是管理uIP的状态机。uIP是嵌入到TCP/IP协议中的协议。本论文中描述的protothread实现原型被用于Contiki操作系统，也被多个第三方嵌入式开发者使用。比如被用于MPEG解码模块，无线传感器、嵌入式设备等。protothread也被其它人移动到C++和Objective C。
　　本论文剩下的部分以如下的形式组织。第2节描述protothread且举一个例子，第3节讨论protothread的内存需求，第4节讲解如何使用protothread替换状态机，第5节描述是如何用C语言实现protothread的，第6节评估protothread，第7节做一个讨论，第8节回顾相关工作，第9节做总结。

protothread

　　protothread是一个新颖的编程抽象。它提供一个条件阻塞等待语句PR_WAIT_UNTIL()，以简化内存受限的嵌入式系统的事件驱动编程。该操作需要一个条件语句，并阻塞protothread，直到该条件语句为真。如果条件语句是真，protothread第一次到达PT_WAIT_UNTIL()时不会中断，会直接执行下去。每次protothread被调用时都会评估PT_WAIT_UNTIL()的条件。PT_WAIT_UNTIL()的条件可以是包括布尔表达式在内的任何复杂语句。
　　protothread是无栈的：它没有函数调用的历史。正相反，系统中的所有protothread都运行在同一个栈之上，当protothread被阻塞时会回到栈顶。
　　protothread被包含在一个函数中。通过重复调用这个函数，就能实现对protothread的驱动。由于protothread是无栈的，它只能在函数顶层阻塞。这意味着，不能通过被protothread调用的常规函数来阻塞被调用函数的内部——只能通过表达式PT_WAIT_UNTIL()来阻塞。这样做的优点是，程序员总是知道哪一条语句可能造成阻塞。虽然如此，也可以使用分层protothread来十年嵌套阻塞（2.5节）。
　　PT_BEGIN和PT_END用来声明protothread的开始和结束。protothread表达式，比如PT_WAIT_UNTIL()，必须放在PT_BEGIN和PT_END之间。表达式PT_EXIT用于提前退出线程。PT_BEGIN和PT_END外面的表达式不属于protothread，其行为是未定义的。
　　protothread可以看做是事件和线程的结合体。从线程角度，protothread继承了阻塞等待语句；从事件角度，protothread继承了无栈特性和低内存消耗特性。阻塞等待机制允许事件驱动程序中的状态进行线性排序。与传统线程相比，protothread的主要优点是轻量级：它不需要栈。所有的protothread运行在同一个栈空间上，通过栈回溯（stack rewinding）实现内容切换。对于内存受限的系统，这是很大的优点，因为线程的栈将会占据相当大一部分有效内存。比如，运行在MS430F149上的线程其栈大小为200字节，几乎占据了整个RAM的10%。于此形成鲜明对比的是，每个protothread的内存消耗只有两个字节，且不需要额外的栈。

调度

　　protothread机制不会指定任何特殊的方法来调用、调度protothread，而是由使用protothread的系统定义的。对于一个运行在事件驱动系统之上的protothread，一旦事件调度器（event scheduler）调用事件处理器（event handler），protothread就会被调度。例如，一个程序运行在uIP TCP/IP栈之上，则在发生TCP/IP事件或者TCP/IP进行周期性轮询时会被调用。
　　在Contiki操作系统中，进程（process）是以运行在事件驱动的Contiki内核之上的protothread实现的。当进程接收到事件后，其protothread会被调用。接收到的事件可能是定时器事件、来自其它进程的消息、传感器输入、或者系统中的其它任何事件。进程可以使用protothread条件阻塞表达式来等待一个事件到来。
　　protothread不指定如何管理保存protothread状态的内存。当有调度时，系统决定如分配内存。如果系统预先知道要运行多少个protothread，则会提前静态分配内存。否则，将动态分配内存。在Contiki中，进程控制块里保存有进程的protothread相关的内存。典型地，Contiki程序为进程控制块静态分配内存。
　　通常，protothread是可重入的。对于多个protothread，只要它们自己有保存状态的内存，就能在相同的代码段上运行。

阻塞事件handler

　　protothread可以看做是阻塞事件的handler，可以在不对事件驱动系统做修改的前提下，在该系统上正常运行。protothread使用表达式PT_WAIT_UNIT()进行条件阻塞。事件调度系统不需要知道这个handler是一个protothread还是一个普通的事件handler。
　　通常，不需要对事件调度系统做任何修改，就能将一个基于状态机实现的程序替换为基于protothread实现的程序。

例子：假想的MAC协议

　　为了描述如何使用protothread替换状态机，我们考虑一个假想的节能传感器网络的MAC协议。该协议的其中一个任务是允许关闭无线radio，以达到减小设备总体能量消耗的目的。因此，许多MAC协议是当无线radio完全关闭后周期地进入睡眠。
　　这里的假想MAC协议与T-MAC协议相似，在调度期间切换无线radio的开关。该机制 如图3所示，且其流程为： 　　

1
2
3
4
5
6

1.打开无线
2.等待，直到 t = t0 + tawake
3.当所有的通信完成后，关闭无线
4.如果通信未完成，等到完成或者直到 t = t0 +tawake +twait_max
5.关闭无线。等待，直到 t = t0 +tawake +tsleep
6.重复步骤1

　　为了在事件驱动模型中实现这个协议，我们首先需要明确一系列的状态，以便设计状态机。对于这个协议，我们可以很快地明确由三个状态：开——无线是打开的，等待——正在等待完成剩下的通信，关——无线是关闭的。图4展示了状态机和状态传输的结果。
　　为了实现这个状态机，我们使用一个变量枚举state（其值为ON，WAITING，OFF）。工具变量state的值，我们使用if语句执行不同的动作。代码放在事件handler函数中，当事件产生时会被调用。在这种情形下，事件可能是定时器到期或者通信完成。为了简化代码，我们用了两个独立的定时器timer、wait_timer去跟踪时间。图1是其对于的伪代码。
　　我们注意到，这样一个简单的机制需要相当多的代码。控制状态机转换的代码超过了总代码的三分之一。当我们使用protothread实现周期睡眠时，我们只需要使用表达式PT_WAIT_UNTIL()来等待定时器到期。图2是对应的伪代码。可以看到，其代码比图1的代码短，且逻辑更清晰。

protothread退出

　　在将状态机重写为protothread的过程中，我们发现了无条件阻塞等待的重要性。表达式PT_YIELF()用于进行无条件阻塞等待，它将阻塞该线程，直到线程下一次被调用。下一次被调用时，protothread将从表达式PT_YIELD()处继续执行。
　　通过添加PT_YIELD()操作，protothread就像一个栈的变形。

protothread分层

　　尽管很多程序可以很容易以单线程实现，但是更多的复杂的程序需要以分层的形式实现。protothread中的表达式PT_SPAWN()支持这种操作。PT_SPAWN()初始化一个子线程，该子线程使用PT_END结束或者使用PT_EXIT退出。子线程被父线程调度。当系统每次调用父线程的时候，都能通过表达式OPT_SPAWN调用子线程。父线程结构体中的一个局部变量保存子线程的状态。
　　为了理解protothread分层工作原理，我们举一个例子，考虑一个假想的数据采集协议。该协议分为两步：第一步，通过网络传送感兴趣的数据；第二步，继续传送数据消息返回到消息传来的地方。消息一一种可靠的方式传播：如果没有收到确认消息，将重传该消息。
　　　
　　图5. 假想数据采集协议的伪代码实现
　　图５用伪代码的形式实现了这假想协议。程序由主线程和线程data_collection_protocal组成。data_collocetion_protocal是一个子线程，采用可靠传输方式试实现数据传输。

本地延续（local continuations）

　　LC（local continuations，其实就我们平时所说的保留现场）是用于支持protothread的底层机制。当protothread发生阻塞时，其线程状态保存在LC中。本地延续LC与平常所说的延续基本相似，有一点不同的是LC不保存程序栈空间，只保存一个函数内部的执行状态。很熟的状态由程序当前正在运行的函数的延续点以及函数局部变量的值共同决定。protothread机制只需要这些实际被用于存储阻塞等待的变量。基于C语言的LC实现原型从这里面抽取了出来，不存储任何局部变量。

摘要

　　随着传感器网络的多样化发展，产生了越来越多的链路层、MAC层协议以及潜在的传输机制。系统开发者必须使他们的应用和系统能够自适应于广泛的、潜在的协议和机制。不过，由于已经存在的传感器通信架构在设计时并没有考虑到这个多样性，所以系统开发者必须为每种潜在的协议和机制重新开发他们的系统。为了补救这种情形，我们提出了一个通信架构。该架构能够在不需要修改任何应用和协议的前提下，适用于广泛存在于从MAC层到传输层的潜在的通信机制。该架构具有足够的表现力以适应典型地传感器网络协议。通过测试证明，相对于非自适应架构，该架构的执行时间只增加了一点点。

介绍

　　随着传感器网络的多样性发展，传感器网络的协议操作受到很大的挑战。比如，如果一个应用程序运行于一个多链路层技术之上，应用程序和协议就不能依赖于已经存在的相关的链路层机制——比如链路层重传。这让我们不得不重新思考传感器网络的通信架构。
　　就互用性和代码重用而言，一个通用的传感器网络架构能带来很多益处。传感器网络社区最近注册了一些不同的传感器网络架构，比如Polastre等人的SP架构，Cheng等人的模块化网络架构。不过，SP和模块化网络架构都不能自适应运行在架构之上的协议。
　　SP没有指定任何协议头，因此能够自适应潜在的协议。但正是由于没有指定协议头，SP也在网络协议自适应的时候存在问题。Cheng等人的模块化架构按照网络层的功能划分成若干模块，在每个模块中定义自己的模块头。如果要添加附加协议，应用程序员必须清楚地定义模块边界并指定包的子头。
　　在本篇论文中，我们展示了一个用于传感器网络的通信架构——变色龙。变色龙架构由两部分组成：Rime通信协议栈和一系列的包传输模块。变色龙架构不仅能够适用于已存在的典型传感器网络协议，还能够自适应大量潜在的协议和机制。
　　设计具有互操作性通信架构的最大问题在于寻找一个通用的头格式。这样的头格式必须同时满足两个条件：对架构支持的通信模式具有足够的表现力，对将来的架构扩展具有足够的灵活性。对于一个传感器网络架构而言，这个问题更具有挑战性，因为必须保证这个头足够小。
　　为了寻找这样一个通用头，变色龙采用了一个彻底的不同的方法：变色龙完全不定义任何头，取而代之使用头属性——一种对包头中的信息的抽象。
　　变色龙中有一个独立的头转换模块，它负责将应用数据和包属性转换为包头，从而可以形成一个具有包头和负载的完整包。通过使用不同的变色龙模块，使创建一个遵从任何给定包头说明的数据包成为可能。
　　

背景

　　一个传感器网络的自适应通信架构必须既支持运行在通信架构之上的典型传感器网络协议，又支持架构所在的ＭＡＣ层和链路层协议。在本节，我们将回顾一下顶层架构下关于通信栈的问题，关于传感器网络协议的需求，关于潜在的MAC层、链路层协议和标准的需求。

狭窄的腰（The Narrow Waist）

ｐｓ：完全搞不懂这一小节说的是啥，将来再补充

　　设计一个网络架构最开始的挑战是在什么地方放架构的狭窄的腰，在什么地方放其它网络架构周围的固定的点。狭窄的腰需要允许不同的协议运行在其之上，允许不同的技术运行在其之下。
　　在以前的传感器网络通信架构中，将传感器网络协议栈的腰放在网络层之下，链路层之上。由于狭窄腰放在这个位置，主要的通信元是单跳广播。这允许在该架构下能有效的实现其它机制，比如拥塞控制。
　　我们的架构已经证实，传感器网络架构的狭窄的腰应该是单跳的最努力的广播（single-hop best-effort broadcast）。

地址自由协议（Address-free Protocols）

　　传感器网络的一个重要的特色是地址自由协议。地址自由协议是一种不使用节点地址的协议。地址自由协议最常见的一个例子是数据散发协议（data dissemination protocal）。在数据散发协议中，数据从一个源节点发送到它所覆盖的网络中的所有节点。源节点或者网络中的其它所有节点都不需要知道接收节点的地址。相反，节点可以利用广播发送数据到它们所有的单跳邻居节点，而邻居节点反过来也可以重新广播数据到它的所有单跳邻居节点。

基于名字的协议

　　尽管地址自由协议在传感器网络中扮演着主要的角色，但总存在基于名字的协议。对于基于名字的协议（name-based protocols），每个节点都被确切地命名（通常使用它们的节点标识地址）。最出名的基于名字的协议是单播多跳路由，这种协议要求网络中的数据包必须由一个指定的节点发送到另一个指定的节点，且发送方知道接收方的地址，发送方和接收方之间的路由中间节点也知道接收方的地址。
　　数据采集协议是地址自由协议和基于名字协议的混合体。在一个数据采集协议中，参与数据采集的节点发送数据到网络中的一个或多个sink节点（不知道该翻译成啥），而数据则被以多跳形式被转发到任何sink节点。参与节点不需要知道最终接受数据的水槽节点的地址，不过一般需要知道单跳邻居的地址。一个节点为了向一个sink节点发送数据，必须发送数据到单跳邻居。因此，数据采集协议在多跳感知时是地址自由协议，在单跳感知时是基于名字的协议。

邻居抽象

　　许多传感器网络算法都是在研究物理或者逻辑上相互靠近的节点，因此也产生了开发这些算法的编程抽象。
　　尽管邻居抽象通常隐藏了抽象层的通信，但是参与邻居抽象的节点通常与其它节点互换消息。一些消息被直接发送到指定邻居，另一些消息被广播到所有邻居。Others need scoped flooding to reach all n-hop neighbors [18]. Similarly, some messages are of higher importance than others and may therefore need to be sent using a reliable communication channel, while others can be sent using best-effort messages. A communication architecture for sensor networks must handle such communication patterns.

MAC协议

　　传感器网络MAC协议的最基本的目标是减小传感器节点的功耗。无线通信通常是能耗最高的模块之一，且其接收消息与发送消息的能耗一样高。因此，MAC协议必须尽可能频繁地关闭无线，但为了与其它节点通信，无线的开启事件又必须足够长。
　　传感器网络存在许多MAC协议，包括时隙TDMA协议和基于竞争的CSMA协议。在基于TDMA的协议中，每个节点都会被分配一个时隙，且只有在这个时隙内才能发送消息。基于CSMA的协议通过对信道进行空闲评估，以确保在任何时刻只有一个发送端占用信道。通过这些机制，包一般不会立即传输，而是在实际传输之前被排队到队列中。
　　传感器网络MAC协议总是区别对待单播和广播传输。单播传输只需要将包送到接收器，因此其它所有节点在这个包传输期间可以关闭无线开关。
　　许多链路层和MAC层协议都支持对单播包进行自动确认。通过对包标记一个特殊的比特位，表示它已经被可到传输。如果发送方没收到确认帧，将会重传该报。
　　不同的链路层和MAC层协议使用不同的编址模式，甚至一个协议支持多个编址模式。以链路层802.15.4为例，它的包既可以使用16位短地址模式，也可以使用64位扩展地址模式。在包头中，甚至有一个选项可以完全关闭地址。
　　自适应传感器网络通信架构必须能够支持上面所有的机制：包排队，广播包、单播包分开处理，单播包自动确认和重传，不同的编址模式。　　

相关标准

　　ZigBee规范是一个短范围、低数据速率控制、感知应用的工业标准。ZigBee协议栈采用分层架构，通过IEEE 802.15.4的网络层和应用支持子层，提供端到端可靠数据传输。ZigBee further specifies how applications can be constructed by requiring a pre-defined application profile along with associated commands, called clusters, for all nodes in the network. ZigBee supports mesh routing protocol based on AODV [28].
　　一般认为，传统的因特网协议族TCP/IP不适用于传感器网络。为了能够让TCP/IP应用于无线传感器网络，我们之前已建议使用简化的TCP/IP协议族，并采用一定的优化技术，比如头部压缩。最近，标准组织6lowpan IETF工作组和工业界已经认同了该想法。例如，为了满足传感器网络的严格能耗限制标准，6lowpan不完全遵循IPv6标准，且在传输之前将IPv6头部进行压缩。
　　理想情况下，自适应传感器网络架构应该让运行在该架构之上的协议兼容这些标准协议。

变色龙架构

　　变色龙架构是传感器网络的自适应架构，该结构的目的主要有三方面。第一，简化传感器网络通信协议栈的实现。这已通过Rime协议栈实现。第二，允许已经实现的运行在架构之上的协议利用潜在的链路层和MAC层协议的特性。这已通过包属性代替包头实现。第三，不用关心运行在架构之上的协议、应用程序，能够独立构成要传输的包头。这已通过独立的包传输模块实现。
　　变色龙架构借鉴了之前关于传感器网络架构、分布式编程和通用网络架构的经验。
　　

3.1 协议逻辑和协议头的分离

　　Rime中的协议逻辑不处理包头的底层细节，这些底层的包头细节交由头部转换模块管理。
　　变色龙架构不使用包头，而使用包属性。在包头中包含的信息，都能在包属性中找到。包属性信息是包头信息的一种抽象。表3.1列举了在变色龙架构中预定义的包属性。应用程序和底层协议都可以自定义额外的包属性。
　　预定义的包属性包括发送方地址、接收方地址、包ID、包类型、已经被转发的次数以及一些从底层来的反馈信息，比如对链路质量、无线信道拥塞信息的预估结果。
　　每个包属性都有一个范围。包属性的范围指定了属性能跟随包多远。如果属性的范围是0，表面属性只能在本节点内跟随包。如果属性的范围是1，表明包头中的属性最多能被转发到一个节点。如果属性的范围是2，属性就能偶跟随包传递到最后的接收者。
　　

头部字段对齐

　　通用的通信协议，比如TCP/IP协议栈，都要求其所有头部字段进行字节对齐处理。这样做的原因是许多微处理器不能访问未对齐的数据。
　　协议的设计者必须确保所有的头部字段被正确对齐，因此有时必须在包头插入填充字节。然而，低功耗无线协议不能负担得起所有头部字段对齐的代价，因为他们必须将保证其头部尺寸尽量小。
　　通过变色龙的包属性，由于头部转换模块中包含了所有底层头部对齐的细节，所以实现协议时不需要对头部字段进行底层对齐处理。

3.1.2 字节序

　　在设计协议头时，通常都要保证具有不同字节序的主机能够相互通信。在通信协议中，最常见的字节序是网络字节序（与大多数微处理器的字节序不同）。因此，在实现协议时，先必须明确地将头部所有的多字节字段转换为网络字节序，然后才写入包头。当接收到包时，进行相反的转换。
　　通过使用包属性，实现协议时不需要考虑被传输的包是什么字节序，能直接以主机字节序访问包属性。变色龙的头部转换模块将负责字节序的转换。

头部字段跨层位组合

　　协议头的很多字段只需要一个或几个比特位，比如flag字段、指定包类型的字段。为了减小包头的总尺寸，通常将许多单字节字段放到一个字节里。在传感器网络中，包的总尺寸很小（例如，Tomte Sky的无线收发器芯片将包的大小限制为128字节），为了在一个包中传输尽量多的数据，减小头部尺寸就成了一项很重要的工作。
　　手工填充单比特的头部字段有很多缺点。第一，实现协议时必须知道单比特字段的确切数量，且这些头部字段必须通过移位操作和布尔表达式访问。第二，实现协议时必须知道单比特字段的内存位置。第三，处于不同层的协议不能将它们的单字节字段合并到一个字节。
　　在传统的分层通信架构中，不可能将处于不同层的不满一个字节的字段打包成到一个字节内。相反，这些字段都需要占用整个字节。图3是一个例子。
　　

3.1.4 头部压缩

　　头部压缩是一个减小传输头的机制。头部压缩不仅能增加网络吞吐量，还能够减小无线网络中的功耗、包丢失率。在无线传感器网络中，头部压缩已被用于减小6lowpan的IPv6头部尺寸。
　　在传统的头部压缩中，头部压缩模块既要解析原始头格式，又要进行位组合。通过包属性，头部压缩被包括到架构之中。

逻辑通道channel

　　在变色龙架构中，使用不同的逻辑通道进行通信。每个通道有自己的协议和包属性。 　　 　　 　　

　　Contiki是由Adam Dunkels及其团队开发的系统，研读其论文是对深入理解Contiki系统的最佳资料。

摘要：

　　无线传感器网络由大量微小的联网可通信设备组成。对于大规模网络而言，动态地下载代码到网络中是极其重要的。在本论文中，我们描述了一个支持动态地加载、替换个人储蓄和服务的轻量级操作系统——Contiki。Contiki基于事件驱动（event-driven）内核，并提供可选的抢占式多线程。在一个资源受限的环境中，Contiki能做到保持基础系统轻量、紧凑的同时，还可以灵活地动态加载和卸载程序和服务。