ContikiMAC
From ContikiWiki
To achieve a low power consumption, Contiki switches off its radio transceiver as much as possible. To be able to communicate while the radio is mostly off, Contiki has several duty cycling mechanisms: X-MAC, LPP, and ContikiMAC. As of Contiki 2.5, ContikiMAC is the default mechanism.
This page describes the ContikiMAC mechanism. The origin of this text is the ContikiMAC technical report, which contains more background information on ContikiMAC as well as citations to relevant related work. To cite the information in this wiki page, please cite the ContikiMAC tech report:
- Adam Dunkels. The ContikiMAC Radio Duty Cycling Protocol. Technical Report T2011:13, Swedish Institute of Computer Science, December 2011.
[ bib | pdf ]
Contents |
[edit] ContikiMAC
ContikiMAC is the default Contiki radio duty cycling protocol. ContikiMAC is designed to be simple to understand and implement, to use standard 802.15.4 frame formats, to use no signaling messages, and to work without any explicit time synchronization. ContikiMAC has a significantly more power-efficient wake-up mechanism than previous duty cycling mechanisms, achieved by precise timing through a set of timing constraints. In addition, ContikiMAC uses a fast sleep optimization, to allow receivers to quickly detect false-positive wake-ups, and a transmission phase-lock optimization, to allow run-time optimization of the energy-efficiency of transmissions.
ContikiMAC uses periodical wake-ups to listen for packet transmissions from neighbors. If a packet transmission is detected during a wake-up, the receiver is kept on to be able to receive the packet. When the packet is successfully received, the receiver sends a link layer acknowledgment. To transmit a packet, a sender repeatedly sends its packet until it receives a link layer acknowledgment from the receiver. Packets that are sent a broadcasts do not result in link-layer acknowledgments. Instead, the sender repeatedly sends the packet during the full wake-up interval to ensure that all neighbors have received it. The principle of ContikiMAC is shown in the figures below.
[edit] ContikiMAC Timing
ContikiMAC has a power-efficient wake-up mechanism that relies on precise timing between transmissions. ContikiMAC wake-ups use an inexpensive Clear Channel Assessment (CCA) mechanism that uses the Received Signal Strentgh Indicator (RSSI) of the radio transceiver to give an indication of radio activity on the channel. If the RSSI is below a given threshold, the CCA returns positive, indicating that the channel is clear. If the RSSI is above the threshold, the CCA returns negative, indicating that the channel is in use.
The ContikiMAC timing is shown in the figure above. The timing requirements from the figure are:
- ti: the interval between each packet transmission.
- tr: the time required for a stable RSSI, needed for a stable CCA indication.
- tc: the interval between each CCA.
- ta: the time between receiving a packet and sending the acknowledgment packet.
- td: : the time required for successfully detecting an acknowledgment from the receiver.
The timing must satisfy a number of constraints. First, ti, the interval between each packet transmission, must be smaller than tc, the interval between each CCA. This is to ensure that either the first or the second CCA is able to see the packet transmission. If tc would be smaller than ti, two CCAs would not be able to reliably detect a transmission. The 802.15.4 standard allows a minimum interframe spacing of 192 microseconds, which rises to 640 microseconds after a frame greater than 18 bytes.
The requirement on ti and tc also place a requirement on the shortest packet size that ContikiMAC can support, as shown in the figure below. For ContikiMACs two CCAs to be able to detect the packet, a packet transmission cannot be so short that it falls between the CCAs. Specifically, ts, the transmission time of the shortest packet, must be larger than tr + tc + tr.
When a CCA has detected a packet transmission, ContikiMAC keeps the radio on to be able to receive the next full packet [rarely will the timing be such that the current packet can be received]. After the packet has been received, a link-layer acknowledgment is transmitted. The time it takes for an acknowledgment packet to be transmitted, ta, and the time it takes for an acknowledgment packet to be detected, td, establishes the lower bound for the check interval tc.
We can now construct the full ContikiMAC timing constraints as
ta + td < ti < tc < tc + 2tr < ts.
With an IEEE 802.15.4 link layer and a specific radio transceiver, some of the variables in the equation above are given as constants. First, ta, the time between a packet reception and the acknowledgment transmission, is defined by the IEEE 802.15.4 specification as 12 symbols. In 802.15.4, one symbol is 4/250 milliseconds long, giving ta = 48/250 = 0.192 milliseconds. Second, an IEEE 802.15.4 receiver can reliably detect the reception of the acknowledgment after the 4-byte long preamble and the 1-byte start of frame delimiter is transmitted, which takes 40/250 miliseconds. Thus, td = 40/250. Finally, tr is given by the data sheet of the CC2420 radio transceiver as 0.192 milliseconds.
With the constants for substituted, the ContikiMAC equation becomes
0.352 < ti < tc < tc + 0.384 < ts.
The remaining variables, ti, tc, and ts can now be chosen. The equation above gives a lower bound on ts > 0.736 milliseconds, which sets a limit on the smallest packet size we can handle. With a bitrate of 250 kilobits per second, this means that packets must be at least 23 bytes long, including preamble, start of frame delimiter, and length field, which leaves 16 bytes of packet data.
To ensure that all packets are larger than the smallest packet size, packets may be padded with additional framing to ensure a minimum packet size. Alternatively, if the network layer is able to ensure that packets never go below a given size, no framing is needed. For example, in the case of an IPv6 network layer, packets with full IPv6 headers will always be longer than the smallest ContikiMAC packet size on a IEEE 802.15.4 link layer. With 6lowpan IPv6 header compression, packets may become smaller, but ensuring a smallest packet size is simple: do not compress the header of IPv6 packets that are smaller than a given threshold.
The ContikiMAC implementation in Contiki 2.5 uses the following configuration:
- ti = 0.4 milliseconds,
- tc = 0.5 milliseconds, and
- ts = 0.884 milliseconds.
[edit] Packet Detection and Fast Sleep
The ContikiMAC CCAs do not reliably detect packet transmissions: they only detect that the radio signal strength is above a certain threshold. The detection of a radio signal may either mean that a neighbor is transmitting a packet to the receiver, that a neighbor is transmitting to another receiver, or that some other device is radiating radio energy that is being detected by the CCA mechanism. ContikiMAC must be able to discern between these events and react properly.
If a neighbor is transmitting a packet to the receiver, the receiver should stay awake to receive the full packet and transmit a link layer acknowledgment. Other nodes, which detect the packet, could quickly go to sleep again. Potential receivers cannot go to sleep to quickly, however, as they must be able to receive the full packet. The naive way to determine how long to be awake when a CCA has detected radio activity is to stay awake for tl + ti + tl, where tl is the transmission time of the longest possible packet. This ensures, if the CCA woke up during the start of the packet, that the full packet will be received by the receiver.
The fast sleep optimization lets potential receivers go to sleep earlier if the CCA woke up due to spurious radio noise. The fast sleep optimization leverages knowledge of the specific pattern of ContikiMAC transmissions as follows. First, if the CCA detects radio activity, but the radio activity has a duration that is longer than the maximum packet length tl, the CCA has detected noise and can go back to sleep. I.e., if the activity period is not followed by a silence period. Second, if the radio activity is followed by a silence period that is longer than the interval between two successive transmissions, ti, the receiver can go back to sleep. Third, if the activity period is followed by a silence period of the correct length, followed by activity, but no start of packet could be detected, the receiver can go back to sleep. The process is illustrated in the figure below.
[edit] Transmission Phase-Lock
If we assume that each receiver has a periodic and stable wake-up interval, the sender can use knowledge of the wake-up phase of the receiver to optimize its transmission. A sender can learn of a receiver's wake-up phase by making note of the time at which it saw a link layer acknowledgment from the receiver. Since the receiver must have been awake to be able to receive the packet, the sender can assume that the reception of a link layer acknowledgment means that the sender has successfully transmitted a packet within the receiver's wake-up window and thus that the sender has found the receiver's wake-up phase. After a sender has learned the phase of a receiver, the sender can commence its successive transmissions to this receiver just before the receiver is expected to be awake. The process is illustrated in the figures below.
[edit] Implementation
The ContikiMAC implementation in Contiki 2.5 uses the Contiki real-time timers (rtimer) to schedule its periodic wake-ups to ensure a stable behavior even if many underlying processes are running. The real-time timers preempt any Contiki process at the exact time at which they are scheduled. The ContikiMAC wake-up mechanism runs as a protothread that is scheduled by a periodic real-time timer. This protothread performs the periodic wake-ups and implements the fast sleep optimization.
Transmissions are driven by an ordinary Contiki process. If a wake-up is scheduled to occur when the radio is busy during a transmission, the wake-up timer schedules a new wake-up after another wake-up interval without performing the wake-up.
The phase-lock mechanism is implemented as a separate module from ContikiMAC, to allow it to be used by other duty cycle mechanisms, such as the Contiki X-MAC implementation. The phase-lock mechanism maintains a list of neighbors and their wake-up phases. The ContikiMAC transmission logic records the time of each packet transmission. When a link layer acknowledgment is received, it notifies the phase-lock module with the transmission time of the last packet. This time is used as an approximation of the wake-up phase of the receiver.
Before commencing a transmission, the ContikiMAC transmission logic calls the phase-lock module to check if it has a recorded wake-up phase of the intended receiver. If so, the phase-lock code queues the packet to be transmitted and sets a callback timer (ctimer) at the time of the expected wake-up of the receiver. ContikiMAC will then resume the transmission when the callback occurs. The transmission will then be significantly shorter than a normal transmission, because it occurs just before the neighbor is expected to be awake. Reducing the length of the transmission thus reduces radio congestion.
If a neighbor whose phase is known has rebooted, or if its clock has drifted far enough away from its previous wake-up phase, transmissions to the neighbor will fail. To protect from this, ContikiMAC maintains a count of failed transmissions for each known neighbor. After a fixed number of failed transmission (16 in Contiki 2.5), the neighbor is evicted from the list of known neighbors. Likewise, if no link layer acknowledgment is received within a fixed time (30 seconds in Contiki 2.5), regardless of the number of transmissions, the neighbor is evicted.
[edit] Performance
This page presents an overview of the performance of ContikiMAC. More ContikiMAC performance results are presented in a number of Contiki-related research papers. See the Contiki publication list for more information.
[edit] Micro Benchmarks
We measure the energy consumption of the individual ContikiMAC operations by measuring the current draw of a Tmote Sky mote running ContikiMAC. We measure the current draw with an oscilloscope by measuring the voltage over an 100 Ohm resistor connected in series with the Tmote Sky power source. We also instrument ContikiMAC to register the state of the radio on one of the Tmote Sky I/O pins, with a high current indicating that the radio is on and a low current indicating that the radio is off, and measure the state of the pin with the same oscilloscope. All measurements use ContikiMAC with a wake-up frequency of 8 Hz, which results in a wake-up interval of 125 ms.
The two figures above shows the current draw of a ContikiMAC wake-up that did not result in any packet reception. In the lower graph, we see that the radio is turned on twice, to perform the two CCAs of the ContikiMAC wake-up. The figure below shows a ContikiMAC wake-up where the second CCA detected spurious radio activity. The radio is then kept on for a while longer, until the fast sleep optimization turns off the radio.
The figures above show a broadcast reception and a unicast reception, respectively. In both cases, the radio was turned on as part of the ContikiMAC wake-up mechanism and the first CCA detected radio activity. The radio was then kept on until the packet was received. We see that the radio is turned on longer in the unicast reception case. This is because of the acknowledgment transmission that is done as part of the unicast packet reception.
The current draw of transmissions are shown in the three figures above. The first figure shows the current draw of a broadcast transmission. A broadcast transmission must wake up and deliver its packet to all neighbors. It therefore runs for a full wake-up interval. Since a broadcast transmission does not expect any link layer acknowledgment, the transmitter can turn off its radio between each packet transmission to save power, which can be seen in the figure. The second figure show the current draw of a unicast transmission to a previously unknown neighbor. In this case, the neighbor's wake-up occurred after roughly 60 ms, which caused the transmitter to repeatedly send its packet some 70 ms. At the start of the transmission, the initial clear channel assessment can also be seen. Subsequent transmissions to the same receiver can now be optimized to start at the expected wake-up time of the neighbor, as seen in the third figure, which shows how the number of transmissions are reduced because of the phase-lock optimization.
By computing the areas under the graphs in the above figures, we can compute the energy consumption of each operation. The result is shown in the figure below. We see that the cost of a broadcast transmission is many orders of magnitude higher than the cost of the wake-up. This is good: the wake-up is the most common operation in ContikiMAC---executed many times per second---and therefore should be significantly less expensive than the other operations.
Armed with the information the figure above, we can now compare the cost of the ContikiMAC wake-up operation with the wake-up operation of other duty cycling mechanisms. The table below shows the cost of a wake-up in ContikiMAC, in the Contiki X-MAC implementation, and the duty cycling mechanism by Hui and Culler.
| X-MAC | 132 |
| Hui and Culler | 54 |
| ContikiMAC | 12 |
[edit] Network Power Consumption
To evaluate the network power consumption of ContikiMAC and the efficiency of its optimizations, we run a set of simulations in the Contiki simulation environment. The Contiki simulation environment consists of the Cooja network simulator and the MSPsim device emulator. MSPsim provides a cycle-accurate Tmote Sky emulation, with a symbol-accurate emulation of the CC2420 radio transceiver. It enables the study of the behavior of ContikiMAC in a timing-accurate and controlled environment.
We run a set of simulations with a 20-node simulation topology. All nodes run Contiki and the Contiki Collect protocol. The Contiki Collect protocol, which is part of the Contiki Rime stack, is an address-free data collection protocol that builds a tree rooted in one or more sinks, towards which packets are routed. The performance of Contiki Collect has been experimentally shown to be similar to other data collection protocols, such as the TinyOS Collection Tree Protocol. The nodes send a data packet towards the sink once every 120 seconds. Every transmission is sent with 31 hop-by-hop retransmissions. Each node sends 100 packets towards the sink. The simulation is run until all data packets have been received by the sink. In all simulations, Contiki Collect was able to successfully deliver all packets to the sink.
The purpose of the simulations is both to measure the typical radio duty cycle that can be achieved with ContikiMAC and to measure the effect of the fast sleep and phase-lock optimizations. We vary the wake-up frequency and the simulated loss levels. We run one set of simulations with no path loss: packets are not lost due to radio fading, but only due to collisions with other packets. The second set of simulations use a path loss model where the probability of a packet loss is proportional to the square of the distance between the sender and the receiver.
We measure the radio duty cycle with Contiki's Powertrace tool. We use the radio duty cycle as a proxy for the power consumption of the network, as the radio transceiver has a linear power draw that depends on its on-time.
We first compare the performance of ContikiMAC with that of X-MAC in a network with path loss. We expect the power consumption of X-MAC to be significantly higher than that of ContikiMAC due to the more costly wake-up mechanism in X-MAC. The figure below shows the result: the power consumption of ContikiMAC is significantly lower for all wake-up frequencies in the experiment.
Next, we measure the efficiency of the individual ContikiMAC optimizations. We run the simulations with the ContikiMAC optimizations switched on and off. The results are shown in the figure below, which shows the radio duty cycle when there is no path loss. We see that the radio duty cycle increases with the wake-up frequency: with more wake-ups, the total power consumption of the network increases. We also see that the fast sleep and phase-lock optimizations significantly reduce power consumption.
The figure below shows the results in the network with path loss. We see that the phase-lock and fast sleep optimizations are more efficient in the face of loss. This is because of a phase-locked transmission being shorter than non-phase-locked transmissions, leading both to less energy being spent on transmissions and to less radio congestion.
