MAC protocols in ContikiOS

From Contiki
Revision as of 14:11, 4 November 2014 by Pedro (Talk | contribs) (References)

Jump to: navigation, search

Back to Contiki Tutorials


This tutorial covers the main features of Medium Access Control (MAC) protocols available on ContikiOS 2.7. Medium Access Control protocols take care of the organization of medium access in wireless networks. They can be interpreted as rules that coordinate when each node is going to transmit/receive packets.

There are a large number of protocols available in the literature, they can usually be classified as contention-based or reservation-based protocols. The first group is based on Carrier Sensing for detecting medium activity and are prone to collisions and lower efficiency; however, they are of easy implementation. The second group is more efficient in terms of throughput and energy, but require precise synchronization and is less adaptable to dynamic traffic. ContikiOS only presents MAC protocols of the first category.

There are about 5 types of MAC layers that can be used in ContikiOS. They are usually implementation of well-known MAC protocols for Wireless Sensor Networks; a few of them are implementations of protocols developed exclusively for ContikiOS, but that were based on previous work present in the literature.

You will learn

Here you are going to be to be more familiar with all MAC protocols implemented on ContikiOS. You are going to understand the organization of MAC protocols, where all files are located and where you should start when you want to modify a protocol. You will also learn the steps you need to take in order to implement your own MAC protocol. And finally, we evaluate two famous MAC protocols: ContikiMAC and X-MAC, showing a few statistics regarding their performance.

MAC, RDC and Framer drivers

The network stack implemented in ContikiOS is a little bit different than the usual 5-layers model typically adopted in TCP/IP. In-between the Physical and the Network layers, where usually is located the MAC, we have 3 different layers: Framer, Radio Duty-Cycle (RDC) and Medium Access Control (MAC). The figure below shows the organization of layers in ContikiOS.


The network layers can be accessed through the global variables NETSTACK_FRAMER, NETSTACK_RDC and NETSTACK_MAC, which are defined in compilation time. All network layers variables can be found in core/net/netstack.h. Every network layer is defined by the pragmas #define in the beginning of this file.

Framer layer is not a common layer implementation; it is actually a collection of auxiliary functions that are called for framezation of transmitting data and parsing of data being received. Examples of Framer types can be found in core/net/mac; there are two types of Framer layers: framer-802154.c and framer-nullmac.c.

Radio Duty-Cycle (RDC) layer takes care of the sleep period of nodes. This is the most important layer because it is the one responsible for deciding exactly when the packets will be transmitted and it is responsible for makeing sure that the node is awake when packets are to be received. RDC protocols' source codes are also located in core/net/mac. Examples of RDC layers that are implemented: contikimac.c, xmac.c, lpp.c, nullrdc-noframer.c, nullrdc.c and sicslowmac.c.

Finally, the MAC layer takes care of addressing and retransmission of lost packets. The source files can be located in core/net/mac; we have only two types of MAC layers available: csma.c and nullmac.c.


A Framer consists of a collection of auxiliary functions that are called before transmitting a packet and after their reception. The Framer struct, called struct framer can be found in file core/net/mac/framer.h. It is shown below.

struct framer {

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


Function create should create a new frame to be transmitted. While function parse will be called for parsing a received frame.

The Framer type framer-nullmac is defined by files core/net/mac/framer-nullmac.c and core/net/mac/framer-nullmac.h. It should be used together with nullmac (MAC layer). The auxiliary function simply populate the 2 fields of nullmac_hdr, which are: receiver address and sender address. This is the very basic type of Framer that can be used on ContikiOS.

The Framer type framer-802154 is defined by core/net/mac/framer-802154.c and core/net/mac/framer-802154.h. It creates and parses frames compatible with standard IEEE 802.15.4 (2003). The create and parse function manipulate all header information abstractedly through the packetbuf structure. The real work is done by functions located in the file core/net/mac/frame802154.c, which are responsible for extracting all information from receive/transmit buffer and inserting/extracting them appropriately into packetbuf structure.

RDC protocols

The RDC struct, called struct rdc_driver can be found in file core/net/mac/rdc.h. It is shown below.

 * The structure of a RDC (radio duty cycling) driver in Contiki.
struct rdc_driver {
  char *name;

  /** Initialize the RDC driver */
  void (* init)(void);

  /** Send a packet from the Rime buffer  */
  void (* send)(mac_callback_t sent_callback, void *ptr);

  /** Send a packet list */
  void (* send_list)(mac_callback_t sent_callback, void *ptr, struct rdc_buf_list *list);

  /** Callback for getting notified of incoming packet. */
  void (* input)(void);

  /** Turn the MAC layer on. */
  int (* on)(void);

  /** Turn the MAC layer off. */
  int (* off)(int keep_radio_on);

  /** Returns the channel check interval, expressed in clock_time_t ticks. */
  unsigned short (* channel_check_interval)(void);

Function input is called when a new packet has arrived and need to be processed by RDC layer. And functions send and send_list are called for transmiting out-going packets.

There are 2 very basic types of RDC layers implemented in ContikiOS: nullrdc-noframer (core/net/mac/nullrdc-noframer.c) and nullrdc (core/net/mac/nullrdc.c). The first one does not use Framer functions, and transmits/receives data directly to Radio layer (Physical). The developer can take total control over the format of the packets being transmitted.

The second RDC layer (nullrdc) uses the Framer functions for header creation/parsing. It does not save energy and works as a pass-through layer that only transmits a packet and returns the results of such transmission (success or collision).

A third simple RDC layer is sicslowmac.c (core/net/mac/sicslowmac.c). This is a RDC layer with no energy savings and that uses IEEE 8021.5.4 frames.

The three last protocols available in ContikiOS are implementations of popular asynchronous MAC protocols that aim at energy saving; namely X-MAC, ContikiMac and LPP. X-MAC is a short-preambule protocol from 2006 that was ported to ContikiOS [1]. X-MAC has two different implementation in ContikiOS, which can be found in files core/net/mac/cxmac.c and core/net/mac/xmac.c. ContikiMac [2] is a protocol that proposes enhancement over X-MAC. The implementation can be found in file core/net/mac/contikimac.c. Finally, LPP (Low Power Probing) is a low power protocol from 2008 that was also ported to ContikiOS [3]; the code can be found in core/net/mac/lpp.c.

Each of the last three RDC protocols can be used for energy saving. The details of each of these protocols is outside the scope of this tutorial and can be found in the references.

MAC protocols

How to choose and change your protocols

How to code your own protocol

Evaluating ContikiMAC and XMAC protocols


1- Buettner, Michael, Gary V. Yee, Eric Anderson, and Richard Han. "X-MAC: a short preamble MAC protocol for duty-cycled wireless sensor networks." In Proceedings of the 4th international conference on Embedded networked sensor systems, pp. 307-320. ACM, 2006.

2 - Dunkels, Adam. "The contikimac radio duty cycling protocol." (2011).

3 - Liang, Chieh-Jan Mike, and Andreas Terzis. "Koala: Ultra-low power data retrieval in wireless sensor networks." In Proceedings of the 7th international conference on Information processing in sensor networks, pp. 421-432. IEEE Computer Society, 2008.

Back to Contiki Tutorials

Edited by: Pedro