Contiki Network Stack

一、协议栈

主要有两大网络协议栈，uIP和Rime这两大协议栈（network stack）：

The uIP TCP/IP stack, which provides us with IPv4 networking。

The uIPv6 stack, which provides IPv6 networking。

The Rime stack, which is a set of custom lightweight networking protocols designed for low-power wireless networks.

uIP和uIPv6可以归并为一类即uIP，看过一些资料，目前很火的是uIPv6，基本都是用这个版本，下边是uIPv6网络协议栈的示意图：

图1 网络协议栈示例（uIPv6）

参考：http://anrg.usc.edu/contiki/index.php/Network_Stack#RDC_Layer

网络协议栈主要分四层（大）：Network Layer，MAC Layer，RDC Layer，Radio Layer。

其中Network Layer可为uIP、uIPv6和Rime，可通过NETSTACK_NETWORK更改

#define NETSTACK_NETWORK rime_driver
/* NETSTACK_CONF_NETWORK specifies the network layer and can be either
   sicslowpan_driver, for IPv6 networking, or rime_driver, for the
   custom Rime network stack. */

设置为rime协议栈。

rime协议栈和uIP协议栈的关系：

图2 Rime和uIP协议栈关系

参考：http://blog.chinaunix.net/attachment/attach/91/12/80/039112803aa3e2106582d32bab61bb8339fdd4950.pdf

Having a functional TCP/IP stack and some applications running on top of it is good, but not enough. The uIP stack requires a lower layer (according to the OSI model) in order to communicate with peers. We'll distinguish two different types of peers:

nodes: communication between nodes is achieved with a wireless link. The uIP stack needs to be able to send and receive packets. Depending on the uIP version, Contiki follows different directions.
When it comes to IPv6, Contiki chose to follow a route-over configuration. Therefore, uIP6 uses a simple MAC layer called sicslowmac. Beside header compression provided by the 6loWPAN module, it just forwards the packet to/from the radio.
However, for IPv4, Contiki chose a mesh-under configuration. This is done with the Rime communication stack. Rime provide mesh routing and route discovery, therefore uIP uses it to forward packets on the network. From the IP point of view, all the nodes of the sensor network form a local subnetwork, even though multiple radio hops may be required.
gateways: to reach a network entity outside the wireless sensor network, a gateway is required. It's a system that will make the link between the wireless sensors network and another network. It will typically be a PC in most experiments, although it could be many embedded system. The connection between a PC and a mote is a serial link. IP packets are sent between these two using SLIP, which stands for Serial Line IP. On the computer side, a program must run to do the interface between the serial line and a network interface. Depending on the uIP stack version, the functionality is not the same.
With uIPv6, a node will be loaded with a very simple program that forwards every packet from the radio to the serial link and vice versa. It doesn't do any address comparison, there is no IP stack on it, besides the header compression/decompression mechanism (6loWPAN). This node will just be seen from the PC point of view as an ethernet network interface, thus that's the PC that does all the work.
With uIPv4 it works differently. The node connected to the PC will act as a gateway, with all the IP stack in it. Every time it has a packet to send, it will check its IP address: if it belongs to the wireless sensor network subnet range, then it will send it using its radio, otherwise it will send it to the PC using the serial link. The PC runs a program that create a IP network interface.

关于uIP的一些论述，不确定是否是对的。

总感觉上边的说法是错的，参考：http://senstools.gforge.inria.fr/doku.php?id=os:contiki#rime_stack

二、 uIP

有两个API：raw uIP和Protosocket。

图3 uIPv6 运行在802.15.4、802.11和Ethernet（以太网）上

参考：http://dunkels.com/adam/durvy08making.pdf

图4 CoAP运行于IPv6

参考：http://dunkels.com/adam/kovatsch11low-power.pdf

从上边两个图可概览uIP的协议栈，其中特有的名词如下：

CoAP: the Constrained Application Protocol（可理解为http）

RPL: IPv6 multi-hop routing protocol.

6LoWPAN: The Adaptation Layer provides IPv6 and UDP header compression and fragmentation to transport IPv6 packets with a maximum transmission (MTU) of 1280 bytes over IEEE 802.15.4 with a MTU of 127 byte.

RDC层：Radio Duty Cycling layer saves energy by allowing a node to keep its radio transceiver off most of the time.

其余的和tcp/ip类似。

uIP除了可以运行在802.15.4之上之外，还可以运行在802.11和以太网（不知具体怎么配置）。

三、MAC

图5 MAC、RDC、Framer层

参考：http://anrg.usc.edu/contiki/index.php/MAC_protocols_in_ContikiOS#MAC.2C_RDC_and_Framer_drivers

1、MAC层

Contiki provides two MAC drivers, CSMA and NullMAC.CSMA is the default mechanism.

The MAC layer receives incoming packets from the RDC layer and uses the RDC layer to transmit packets. If the RDC layer or the radio layer detects a radio collision, the MAC layer may retransmit the packet at a later point in time. The CSMA mechanism is currently the only MAC layer that retransmits packets if a collision is detected.

定义使用哪个MAC driver

#define NETSTACK_CONF_MAC nullmac_driver//定义MAC driver

2、RDC层

Contiki has several RDC drivers.

The most commonly used are ContikiMAC, X-MAC, CX-MAC, LPP, and NullRDC.

ContikiMAC is the default mechanism that provides a very good power efficiency but is somewhat tailored for the 802.15.4 radio and the CC2420 radio transceiver.

X-MAC is an older mechanism that does not provide the same power-efficiency as ContikiMAC but has less stringent timing requirements.

CX-MAC (Compatibility X-MAC) is an implementation of X-MAC that has more relaxed timing than the default X-MAC and therefore works on a broader set of radios. LPP (Low-Power Probing) as a receiver-initiated RDC protocol.

sicslowmac is a RDC layer with no energy savings and that uses IEEE 8021.5.4 frames.

NullRDC is a "null" RDC layer that never switches the radio off and that therefore can be used for testing or for comparison with the other RDC drivers.

RDC drivers keep the radio off as much as possible and periodically check the radio medium for radio activity. When activity is detected, the radio is kept on to receive the packet. The channel check rate is given in Hz, specifying the number of channel checks per second, and the default channel check rate is 8 Hz. Channel check rates are given in powers of two and typical settings are 2, 4, 8, and 16 Hz.

定义RDC driver和检查频率：

#define NETSTACK_CONF_RDC nullrdc_driver//To specify what RDC driver Contiki should use
#define NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE 16//specifies the channel check rate, in Hz

3、Framer层：

Framer layer is not a regular layer implementation; it is actually a collection of auxiliary functions that are called for creating a frame with data to be transmited and parsing of data being received.

结构体如下：

struct framer {

  int (* create)(void);
  int (* parse)(void);

};

定义Framer driver：

#define NETSTACK_CONF_FRAMER  framer_802154

四、Rime

图6 Rime整体结构

参考：http://blog.chinaunix.net/attachment/attach/91/12/80/039112803aa3e2106582d32bab61bb8339fdd4950.pdf

Rime协议栈总体概览如图6所示，应用层的数据，通过Rime和Chameleon之后，进入MAC层，再进入Radio。

图7 Rime和Chameleon的相互作用

参考：http://dunkels.com/adam/dunkels07adaptive.pdf

Chameleon机制是一个头部转换模块，处理Rime进来的数据，转换成不同底层协议支持的格式。

The Chameleon architecture. Applications and network protocols run on top of the Rime stack. The output from Rime is transformed into different underlying

protocols by header transformation modules.

图9 两个节点通过rime通信

参考：http://dunkels.com/adam/dunkels07adaptive.pdf

两个节点通过Rime层通信的示例如图9所示。Channel是逻辑信道。这两个应用，一个应用直接使用Rime协议栈；另一个应用，则使用在Rime之上的Mesh 路由协议。

图10 Rime通信单元分层结构

参考：http://dunkels.com/adam/dunkels07adaptive.pdf

Rime协议栈各通信单元之间的关系，及其分层。

图11 另一个角度的Rime通信单元分层结构

参考：http://blog.chinaunix.net/attachment/attach/91/12/80/03911280327775663be017ce25b311c18d2c0698f.pdf

从另一个角度看，Rime协议栈各通信单元之间的关系，及其分层。

五、参考资料

本文参考的资料的源头网站链接（文中的链接是最终的链接）：

Contiki 官网资源（基本是相关论文）：http://contiki-os.org/support.html

USC 关于Contiki的资料：http://anrg.usc.edu/contiki/index.php/Contiki_tutorials

Contiki 学习笔记：http://blog.chinaunix.net/uid-9112803-id-3263428.html

Contiki Wiki：https://github.com/contiki-os/contiki/wiki

六、问题

1、程序使用哪个协议栈Rime或者uIP（包含uIPv6），这怎么配置？

2、Rime走uIP如何配置？

3、uIP走Rime如何配置？

4、关于NETSTACK_NETWORK的理解是不是对的？

注：后续先看Contiki的building，先理解Contiki源码是怎么编译的。

可能可以解答上述问题。