Contiki Network Stack

標籤：more   問題   mtu   miss   格式   技術   res   header   分層   

一、協議棧

主要有兩大網路通訊協定棧，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

設定為rime協議棧。

 

rime協議棧和uIP協議棧的關係：

 

圖2 Rime和uIP協議棧關係

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

二、 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源碼是怎麼編譯的。 可能可以解答上述問題。

 

Contiki Network Stack