Radio duty cycling
Contiki has three duty cycling mechanisms: ContikiMAC, X-MAC and LPP. ContikiMAC is a protocol based on the principles behind low-power listening but with better power efficiency. Contiki's X-MAC is based on the original X-MAC protocol, but has been enhanced to reduce power consumption and maintain good network conditions. Contiki's LPP is based on the Low-Power Probing (LPP) protocol but with enhancements that improve power consumption as well as provide mechanisms for sending broadcast data.
Power consumption is important for wireless sensor nodes to achieve a long network lifetime. To achieve this, low-power radio hardware is not enough. Existing low-power radio transceivers use too much power to provide long node lifetimes on batteries. For example, the CC2420 radio transceiver, used in the Tmote Sky boards, draws approximately 60 milliwatt of power when it is listening for radio traffic. Its power consumption when transmitting radio data is slightly higher. With a power draw of 60 milliwatt, a sensor node depletes its batteries in a matter of days.
To achieve a long lifetime, the radio transceiver must be switched off as much as possible. But when the radio is switched off, the node is not able to send or receive any messages. Thus the radio must managed in a way that allows nodes to receive messages but keep the radio turned off in between the reception and transmission of messages.
The purpose of a power-saving duty cycling protocol is to keep the radio turned off while providing enough rendezvous points for two nodes to be able to communicate with each other. There are multiple ways of providing rendezvous points in a duty cycling protocol. If the nodes are time-synchronized, the duty cycling protocol can set up and maintain a schedule of when nodes can communicate. The protocol would turn the radio on at a known time, and neighboring nodes could then transmit packets at this know time. Without scheduled time synchronization, nodes must use other means to provide rendezvous points.
In the sensor network research community, radio duty cycling protocols are often called MAC protocols because radio duty cycling was often implemented at the MAC layer. This is the reason for ContikiMAC's name. In Contiki, we have decided to factor out duty cycling from the MAC layer and moved it into its own layer, called the RDC layer.
Low-power listening is a duty cycling technique where the receivers periodically turn on their radios to poll the radio medium for activity. If there is activity, the radio is kept on for a longer time in case a packet would be sent to the node.
Before sending a packet, the sender sends a number of strobe packets with the intent to let the receiver know that a neighbor wants to send a packet. Because all neighbors are periodically sampling the radio medium, they will see the strobe packets and keep their radios on in anticipation of the data packet. The strobe period is defined to be as long as the sleep period of the neighbors so that the neighbors will be woken up by the strobe packets.
There are several variants of low-power listening. Some do not send strobe packets to wake up their neighbors, but send a long wake-up tone instead. This tone serves the same purpose as the strobe packets but cannot contain any information.
By placing the receiver address in the strobe packets, the neighbors can quickly decide if they should be awake for the data packet. Only if the receiver address matches the address of the node will the node keep its radio on.
B-MAC is an early example of a low-power listening protocol. B-MAC, which was initially developed for radio transceivers that did not automatically packetize the bytes it sent, did not use strobe packets but a tone to wake up every neighbor.
WiseMAC is similar to B-MAC, but further optimizes transmission by allowing all nodes to record their neighbors' radio sample phase. When sending a packet to a given neighbor, the sender waits until the neighbor is known to sample the radio medium before it sends its wake-up tone. Thus the wake-up tone will be sent just before the receiver wakes up, further saving energy.
X-MAC was the first low-power listening protocol that was developed for a packetizing radio, and the first protocol to use strobes instead of a wake-up tone. In X-MAC, strobes contain the address of the receiver and other neighbors can refrain from keeping their radios on when hearing a strobe for another node. Additionally, X-MAC optimizes the mechanism further by adding a strobe acknowledgment packet. This packet is sent by a receiver in response to a strobe that contains its address. The sender will, upon hearing the strobe acknowledgment packet, immediately sent its data packet.
Low-power probing is a rendezvous method that reverses the roles from low-power listening. Instead of having the receivers periodically sample the radio medium, the receivers periodically transmit a probe into the radio medium. To send a packet, the sender turns on its radio and listens for a probe packet from the neighbor that should receive the data packet. When the probe packet arrives, the sender immediately sends its data packet. The receiver, which keeps its radio on for a short while after sending its probe, will thus receive the data packet.
Two low-power probing protocols have been published. The first, simply called Low-Power Probing (LPP), used the mechanism to wake up a section of the network. The RI-MAC protocol developed a fully functional MAC protocol based on the same idea. Although the two protocols were published one after the other, they were developed independently of each other.
By default, Contiki provides three duty cycling MAC protocols: the ContikiMAC protocol, Contiki X-MAC and Contiki LPP. ContikiMAC is a low-power listening-based protocol with a very high power efficiency. The Contiki X-MAC is based on the original X-MAC protocol but with a significant set of improvements and extensions. The Contiki LPP is based on the same ideas as the original LPP and RI-MAC but with a number of changes.
In both the X-MAC and LPP protocols, nodes periodically wake up in anticipation of a potential incoming packet. The wake-up period is fixed, but the nodes are not synchronized. Therefore, there is a phase shift between all neighboring nodes. By utilizing information about a neighbor's phase, it is possible to save power when sending packets. Both the Contiki X-MAC and the Contiki LPP make use of this phase awareness.
Both the Contiki X-MAC and the Contiki LPP provides a streaming functionality where packets can be tagged with a stream flag. Packets tagged with the stream flag are part of a higher layer stream of packets, and the MAC layer treats them differently than others. For example, in a stream, it is likely that more packets arrive quickly. Thus the MAC protocol can keep its radio on for a while longer, knowing that more packets are about to arrive.
The ContikiMAC radio duty cycling mechanism is illustrated in the figure above. The figure illustrates the timing constraints under which ContikiMAC operates.
For ContikiMAC to work, the timing must satisfy the following constraints. First, ti, the interval between each packet transmission, must be smaller than <math>t_c</math>, the channel check interval. This is to ensure that either the first or the second channel check is able to see the packet transmission. If <math>t_c</math> would be smaller than <math>t_i</math>, two channel checks would not be able to reliably detect a packet train. Conversely, <math>t_r + t_c + t_r</math> must be smaller than the transmission time of the shortest packet, <math>t_s</math>.
When a packet transmission has been detected, ContikiMAC keeps the radio on to be able to receive the full packet. When a full packet has been received, a link-layer acknowledgment is transmitted. ContikiMAC requires that the underlying link layer is able to transmit acknowledgment packets in response to received packets. If the link layer does not provide this by itself, it is possible to implement this as a layer between the link layer and ContikiMAC.
The time it takes for an acknowledgment packet to be transmitted, <math>t_a</math>, and the time it takes for an acknowledgment packet to be detected, <math>t_d</math>, establishes the lower bound for the check interval <math>t_c</math>.
We now have all the timing constraints for ContikiMAC. They can be summarized as
<math> t_a + t_d < t_i < t_c < t_c + 2 t_r < t_s. </math>
For an IEEE 802.15.4 link layer, we can substitute some of the variables in the equiation above with constants. First, <math>t_a</math> is defined by the IEEE 802.15.4 specification to be 12 symbols long. In 802.15.4, one symbol is 4/250 milliseconds long, meaning that <math>t_a</math> is <math>48/250 = 0.192</math> milliseconds. Second, we 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. Finally, <math>t_r</math> is given by the CC2420 data sheet and is 0.192 milliseconds.
In conclusion, with the constants for IEEE 802.15.4 substituted, the equation above becomes
<math> 0.352 < t_i < t_c < t_c + 0.384 < t_s. </math>
The remaining variables, <math>t_i</math>, <math>t_c</math>, and <math>t_s</math> can now be chosen. Equation~\ref{eqn:part3:contikimac-802} gives a lower bound on <math>t_s > 0.736</math> 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. If ContikiMAC is asked to transmit a longer packet, the packet can be padded with null bytes to ensure this requirement.
The current ContikiMAC implementation uses the following configuration:
- <math>t_i = 0.4</math> milliseconds,
- <math>t_c = 0.5</math> milliseconds, and
- <math>t_s = 0.884</math> milliseconds (28 - 6 data bytes).
| Variable | Meaning | Value |
|---|---|---|
| <math>t_i</math> | the interval between each packet transmission | 0.4 ms (Implementation dependant) |
| <math>t_r</math> | the time required for a stable Received Signal Strength Indication (RSSI) | 0.192 ms (CC2420 dependant) |
| <math>t_c</math> | the interval between each channel check | 0.5 ms (Implementation dependant) |
| <math>t_a</math> | the time between receiving a packet and sending the acknowledgment packet | 0.192 ms |
| <math>t_d</math> | the time required for successfully detecting that an acknowledgment is being transmitted | 0.16 ms |
| <math>t_s</math> | the time for transmitting the shortest data packet | 0.884 ms (Implementation dependant) |
The Contiki X-MAC is based on the original X-MAC design but adds support for broadcast traffic, phase awareness, stream transport, and optional MAC layer retransmissions.
The basic mechanism in the Contiki X-MAC is shown in the figure to the right. Nodes maintain a strict schedule during which they first switch their radio on, listens for incoming strobes from neighbors, switch off their radio if no strobes were received, and keep the radio off during the rest of the duty cycle period. If a strobe was received, the node transmits a strobe acknowledgment packet to the sender. When the sender receives a strobe acknowledgment packet from the node to which it is sending strobe packets, the sender immediately sends it data packet.
To implement broadcast in an X-MAC-like protocol, there are at least two alternatives. The first implementation is to let the sender send strobe packets in which the address of the receiver is set to the broadcast address. When a node hears a strobe packet with the broadcast address, it does not transmit a strobe acknowledgment packet, but instead switches its radio on. The sender sends a full period of strobe packets, followed by the data packet. This mechanism ensures that all nodes are awake by the time the broadcast packet arrives, but it wastes energy because all nodes have to be awake until the data packet arrives.
The second way to implement broadcast in X-MAC is simpler. When sending a broadcast packet, instead of sending strobes, the sender simply sends the broadcast packet itself. This has the advantage that the neighbors do not need to keep their radio on for a longer time than a check interval. The problem with this is that it slightly changes the semantics of the broadcast: since nodes receive their broadcast packet at different times, the broadcast reception is not atomic and cannot be used for implicit synchronization.
Broadcast in the Contiki X-MAC.
Broadcast in the Contiki X-MAC is done with repeated transmissions of the data packet, as shown in the figure.
Phase awareness in the Contiki X-MAC is simple. Every time a node sends a packet to its neighbor, the sender records the time at which the receiver was awake. The sender knows the time at which the neighbor was awake, because the receiver sent a strobe acknowledgment packet then. When the sender is aware of the time at which the neighbor was awake, the sender then knows the phase of the neighbor.
When a sender is about to send a packet to a neighbor for which the sender is aware of its phase, the sender does not start to send its strobes until the neighbor is awake. If the sender misses the awake period of the neighbor, the sender will simply continue to send strobes for an entire period. Thus the mechanism is correct regardless if the phase is correctly recorded or not. With correct phase information, the mechanism is more efficient, however.
If perfectly tuned, the sender will only need to send a single strobe packet when it knows the phase of the neighbor. The Contiki X-MAC does allow for an amount of desynchronization between the nodes, and senders start to send their strobes one awake time earlier than its phase information tells it. On average, the sender will then send two strobe packets for every transmission. We have not yet measured the effectiveness of this mechanism.
The Contiki X-MAC allows the higher layers to set a flag that tells the MAC layer that a packet is expected to be acknowledged. For such packets, the Contiki X-MAC does not switch off its radio after sending the packet. Instead, it explicitly keeps the radio on in anticipation for an incoming acknowledgment packet. The acknowledgment packet can then be sent without any strobes, since the neighbor knows that the sender's radio is turned on after sending such a packet. This improves the performance of packets with transport layer or application layer acknowledgments.
The Contiki X-MAC provides compatibility with the 802.15.4 link layer standard by forming its messages according to the 802.15.4 specification. All messages, both strobes and data messages, use the 802.15.4 frame and addressing format. This makes it possible to interoperate between an always-on 802.15.4 network and a Contiki X-MAC network. Although the logic is different, and the nodes cannot directly communicate with each other, other mechanisms of the 802.15.4 standard work, such as the ability to discard incoming packets that have a destination address that does not match the node's address.
The two Contiki MAC protocols have different requirements in terms of periodicity and exactness and we have therefore used two different techniques when implementing them. In Contiki, MAC layers are a special module that is called by the radio driver when incoming packets, and by the network layer for outgoing packets. Both MAC protocols use timers to implement their behavior.
The Contiki X-MAC implementation uses the Contiki real-time timer module, rtimer, in order to provide an exact timing behavior. At the heart of the Contiki X-MAC implementation is a function called powercycle().
The powercycle() function switches the radio on and off as part of the X-MAC idle listening. Because the periods have to be short, and because the timing has to be exact, this function is scheduled by an rtimer to be called at the exact moment at which is it scheduled. Internally, the powercycle() function is implemented as a protothread.
When sending or receiving packets, the idle listening is temporarily disabled by a flag being set. The powercycle() function is still called, but it does not switch the radio on and off when the flag is set. This ensures that the phase of the duty cycle is stable after sending or receiving packets.
The LPP implementation has lower requirements on exactness of timing. Therefore, the LPP implementation uses the less exact ctimer module for its timing. The ctimer does not provide any guarantees for when a function will be called, but it is significantly simpler to use than the rtimer module because ctimers will never preempt other code.
The LPP function uses a central duty cycling protothread called dutycycle() to send probes and to turn the radio on and off. This function is periodically scheduled with a ctimer.