Contiki Network Stack

本文轉載自查看原文 2016-10-23 18:26 2156 Contiki

一、協議棧

主要有兩大網絡協議棧，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.