原英文文章：https://github.com/contiki-os/contiki/wiki/Change-mac-or-radio-duty-cycling-protocols


在Contiki中，MAC层源码位于core\net\mac目录下。
       在低功耗网络中，无线收发设备必须时常休眠以节省电量。在Contiki中，负责这个工作的是RDC（Radio Duty Cycling）层，也即信道接入技术。Contiki提供了一系列RDC机制。默认的就是ContikiMAC。
       有人将rdc层归类到mac层，但在contiki中，倾向于将rdc层作为mac之下的独立一层。
       1、关于MAC驱动
MAC（Medium Access Control）层处于RDC的上层。MAC层负责避免数据在传输过程中的冲突以及重传数据包。Contiki提供了两种MAC层，一种是CSMA（Carrier Sense Multiple Access 载波侦听多路访问）机制以及NullMAC机制（只负责对数据的转接而不对数据进行任何的操作）。默认为CSMA。MAC层接收来自RDC层的数据并通过RDC层来转发数据包。假如RDC层或者是radio层检测到数据碰撞，MAC层就要重发这个数据包。如有数据碰撞只有CSMA支持重发。
       2、关于RDC驱动
       Contiki有多种RDC驱动。默认提供ContikiMAC，Contiki X-MAC，Contiki LPP以及NullRDC。默认的是ContikiMAC，它具有很好的功率效率，但有些更偏向于802.15.4无线设备以及CC2420无线收发设备。X-MAC是一个较旧的机制，采用strobe机制和确认机制，当发送方收到接收方对strobe的ack后，开始发送数据包，它不像ContikiMAC那样有高功率效率，但是有较严格的时序要求。Contiki的X-MAC基于原始的X-MAC协议，但前者降低了功耗，有更宽松的时序要求，因此能在更多的无线设备上工作。Contiki的LPP基于LPP（Low-Power Probing）协议，在功耗方面有所改善，同时提供发送广播数据的机制，是一个随接收器启动的RDC协议。NullRDC是一个空的RDC层，它从来不会关闭无线设备，因此可以用来测试或者与其它的RDC驱动比较使用。


       RDC驱动尽量保持无线设备休眠并且定期检查无线传输介质。当进行检测时，无线设备接收数据包。信道检查频率以HZ为单位，指定每秒信道检查的次数，默认为8HZ。典型的信道检查频率为2、4、8、16HZ。在仿真实验时，可以在配置文件中设置。（以sky平台为例，在该平台下的contiki-conf.h文件中通过#define NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE 8宏进行定义，默认果然是8Hz，0.125秒一次）
       通常传输的数据包必须重复发送直到接收器打开检测。这就增加了耗电量以及无线通信流量（traffic）进而影响与其它节点的通信。一些RDC驱动允许锁相优化（phase optimization）以此来推迟选通（strobe）发送的数据包直到接收器将要唤醒。这需要两个节点之间良好的时间同步，如果以1%的时钟差那么唤醒时间将贯穿整个发送阶段窗口每100个周期，比如在信道检查频率为8HZ的时候是12秒。当传送包的时间间隔为几秒的时候这将让阶段优化失去作用，因为发送者必须在接收器唤醒之前提前准备好发送的数据。时钟漂移校正（clock drift correction）可能解决这个问题。
       这些Contiki RDC驱动被称作：
       contikimac_driver
       xmac_driver
       cxmac_driver
       lpp_driver
       nullrdc_driver
另：SICSLoWMAC专门作为6LowPAN的mac层而设计的。有关SICSLowMAC层参见：http://www.sics.se/~adam/contiki/docs-uipv6/a01103.html


关于如何更改contki的mac层和rdc层协议，参见英文原文：https://github.com/contiki-os/contiki/wiki/Change-mac-or-radio-duty-cycling-protocols


配置文件contiki_conf.h中：
#define NETSTACK_CONF_MAC                       csma_driver
#define NETSTACK_CONF_RDC                       contikimac_driver
#define NETSTACK_CONF_FRAMER                    framer_802154
#define NETSTACK_CONF_RADIO                     stm32w_radio_drive
……
#if WITH_UIP6
#define NETSTACK_CONF_NETWORK             sicslowpan_driver
#else
#define NETSTACK_CONF_NETWORK             rime_driver
#endif


大概如下：
radio：即是STM32W支持的射频部分的驱动，在cpu/stm32w108/dev/stm32w_radio.c,相应的平台有相应的radio驱动


Framer:帧结构采用802.15.4协议


RDC:Radio的管理机制在core/net/mac下contikiMAC.c中


MAC：MAC层的管理机制，同样通过配置获得，有csma_driver 可知这里选择的是csma机制。core/net/mac。


适配层：6LowPAN适配层，对mac层的数据进行压缩报头等数据分析与重组。core/net/sicslowpan.c,由input函数进入此函数


network:对数据进行处理，由core/net/tcpip.c下的tcpip_input()，packet_input()，uip_input()函数完成最后将数据交给uIP协议栈，最后由UIP_APPCALL()将数据包分发给不同的应用程序。


rime协议：对于带宽有限或者不能运行完整IPv6网络栈的环境，Contiki定制了名为Rime的无线网络栈。Rime栈既支持简单操作，例如向所有邻居或指定邻居节点发送消息，也支持一些复杂机制，例如网络洪泛、多跳数据采集等。Rime可以运行在休眠路由上以降低功耗。


App：应用程序


从这个过程看，第一个radio中的驱动是紧密与硬件平台有关系的，只能对于相应的硬件平台选择适当的driver，而其他各层却不是与硬件层紧密相连的。但是一些实现需要硬件的支持，所以有些虽然不与硬件直接相关，但是由于硬件本身不支持，所以无法实现一些可用的算法。尤其是在RDC层，因为这个设计可以降低无线射频的功耗，也是Contiki之所以作为网络系统优秀的原因。


从RDC和MAC的文件在同一个文件夹下可知，他们之间应该是有紧密的联系。适配层和Network在同一个文件夹下可知，他们应该是有紧密的联系。


#define NETSTACK_CONF_MAC                       csma_driver
#define NETSTACK_CONF_RDC                       contikimac_driver
#define NETSTACK_CONF_FRAMER                    framer_802154
#define NETSTACK_CONF_RADIO                     stm32w_radio_drive
#if WITH_UIP6
#define NETSTACK_CONF_NETWORK         sicslowpan_driver
#else
#define NETSTACK_CONF_NETWORK          rime_driver
#endif
这里使用这样的宏定义，其实是已经在各个模块中都初始化好的一组函数指针的集合的结构体的全局变量，这种方式相当于用C语言实现了类的功能，只是结构体中只包含了操作，没有包含数据。这样的方法很是巧妙，在linux内核中经常被使用。有效地隐藏了信息，很好地做到了信息隐藏。