[Contiki series of papers 4] Contikimac RDC Protocol

Directory

• Directory
• Summary
• Introduced
• Contikimac
  • 1 Contikimac Timing
  • 2 packet detection and fast sleep
  • 3 Phase Lock Transmission
• Realize
• Evaluation
  • 1 Micro Benchmark
  • 2 Network Power consumption
• Related work
• Summarize
• Reference documents

Summary

To reduce system power consumption, a low-power wireless device must shut down the radio as much as possible, but in order to receive communication messages from neighboring nodes, it must be woken up frequently. This paper describes the Contikimac RDC (radio-duty-cycling) mechanism, which uses a series of timing constraints to achieve a function of both shutting down the transceiver and efficiently waking up. Under the action of the CONTIKIMAC mechanism, the radio switches of the nodes participating in the network communication are closed for 99% of the time. This paper describes the CONTIKIMAC mechanism, measures the energy consumption of the CONTIKIMAC operation, and evaluates the efficiency of fast sleep and lock phase optimization.

1 Introduction

Low power wireless devices must have strict power consumption to increase the life of the device. In the left and right components of a low-power wireless device, the wireless transceiver consumes the most power. The wireless transceiver passively receives other device messages and consumes the same amount of power as the active sending of messages to other devices, so the transceiver must be completely shut down for energy saving purposes. However, because the transceiver cannot receive any data when it is turned off, a mechanism is required to periodically turn on the transceiver. Over the years, many such mechanisms have been put forward. In Contiki2.5, the default mechanism is CONTIKIMAC.

Contikimac is designed to be easy to understand and implement. Contikimac uses only asynchronous mechanisms, no signaling messages, and no headers attached. The Contikimac package is an ordinary link-layer message. Contikimac has a significant energy-saving wake-up mechanism-periodic pause (duty cycling) mechanism. The implementation of this mechanism relies on precise timing-some of the strict timing of the columns. In addition, CONTIKIMAC uses optimized fast sleep and optimized lock-in transmission.

The mechanism in Contikimac is inspired by the already existing periodic moratorium protocol. Many protocols use the idea of periodic awakening, such as B-mac,x-mac,box-mac. The most optimized phase-lock technology was first proposed by Wisemac and has now been used in many other protocols. Multiple copies of the packet have been used by the TinyOS Box-mac protocol.

The remainder of this paper is organized in the following form: Chapter Two describes the CONTIKIMAC mechanism and its basic principles, The third chapter describes the implementation process of the CONTIKIMAC protocol in Contiki2.5, the fourth chapter evaluates the energy efficiency of CONTIKIMAC in a data acquisition network, and the fifth chapter describes the related work and summarizes the sixth chapter.

2 Contikimac

Contikimac is an RDC (Radio Duty Cycling) protocol that uses a periodic wake mechanism to listen for message packets from a neighbor node. For a receiver, if a packet is detected when it is awakened, it will continue to wake up to receive the packet. When the package is successfully received, the receiver sends a link-layer acknowledgment message. For the sending side, if you want to send a packet, you need to send the packet periodically until you receive a link-layer acknowledgment message from the receiver. Broadcast packets do not cause link-layer acknowledgment messages. Instead, the sending side periodically sends the packet during the wake-up interval to ensure that all the neighbor nodes receive the broadcast packet. Figure 1 and Figure 2 show the mechanism of the CONTIKIMAC.

Figure 1. Contikimac: The node is asleep most of the time and is periodically woken up to detect the wireless signal. If a transport packet is detected, the receiver remains awake to receive the next packet and send a link-layer acknowledgment message. In order to send a packet, the sending side periodically sends the same packet knowing that the link layer acknowledgment message is received.

Figure 2. Broadcast messages are sent periodically within two wake-up intervals

2.1 Contikimac Timing

Contikimac's energy-saving wake-up mechanism relies on precise timing during transmission. The CONTIKIMAC uses the Idle channel Evaluation (CLEAR Channel Assessment, CCA) mechanism, which uses the received signal strength (reveived Signal strength Indicator,rssi) to determine the status on the channel. If Rssi is below a given threshold, CCA returns a positive value indicating that the channel is idle, and if RSSI is above this threshold, CCA returns a negative value indicating that the channel is being used.

Figure 3. Contikimac Transmission and CCA timing

The timing requirements of the Contikimac are shown in timing 3:

TI: The interval between each package transfer
Tr:rssi required stable time, but also the stable time required for CCA
TC: The interval between each CCA
TA: The interval between receiving a packet and sending a confirmation message
TD: The time required to successfully detect a confirmation message from the receiving end.

These timings must meet a number of constraints. First, the time interval between the packets Ti must be the time interval TC between CCA is small, which ensures that the first CCA or the second CCA detects that there is a packet in the transmission. If TI is larger than TC, it is possible that neither package can detect that there is a packet in the transmission.

As shown in 4, the shortest packet size supported by the CONTIKIMAC also depends on the timing of TI and TC. To ensure that the packet is detected by two CCA, the transmission packet cannot be too short to be detected when the transfer is done between two CCA. Clearly, the shortest packet transmission time must be greater than tr+ tc+tr.

Figure 4. The package must be large enough
When CCA detects a package, Contikimac keeps the wireless transceiver turned on to receive the full package and sends a confirmation message. The delivery confirmation packet takes the time TA and the confirmation packet is detected to the required event TD for the detection interval TC establishes a smaller range.
Now we can establish the complete timing constraints for the CONTIKIMAC:
　　 Ta+td < TI < TC < TC+2TR < TS (1)
Some of the parameters in Equation 1 are set to constants. First, the interval between packet reception and acknowledgement of message transmission is defined as 12 symbols in IEEE 802.15.4. In 802.15.4, a symbol is 4/240ms, so ta=48/250=0.192ms. Second, the IEEE802.15.4 receiver is able to reliably detect a confirmation message (a 4-byte long pilot code and a 1-byte long frame delimiter before the message is confirmed), so td=40/250 is required to spend 40/250ms. Finally, the CC2420 transceiver data sheet is given a tr of 0.192ms.
The constant was replaced, and the equation 1 changed to
　　 0.352 < TI < TC < TC + 0.384 < TS (2)
The remaining variables TI,TC and TS are optional. From Equation 2 we can get a lower bound, i.e. TS > 0.736ms, which is the minimum length of the package we can handle. In the case of a bitstream of 250kbps, this means that the package needs at least 23 bytes long (including the pilot code, frame delimiter and length fields, so there are 16 bytes of data fields left).
　　
To ensure that all packages are longer than the minimum package size, some packages may be populated with additional information. If the internetwork protocol ensures that the packet is always larger than the given minimum packet length, no padding is required. For example, if the protocol for the internetwork layer is Ipv6,ipv6, the length of the header is always larger than the minimum packet size of the IEEE 802.15.4 link layer. If the IPV6 header compression protocol 6LoWPAN is used, the package may be too small, so the measures taken are: if the package size is smaller than the given size threshold, no compression is done.
　　
In Contiki 2.5, the configuration used by Contikimac:

• TI = 0.4 ms
• TC = 0.5 ms
• TS = 0.884 ms

2.2 Packet detection and fast sleep

CONTIKIMAC CCA Packet detection is unreliable: It detects only if the signal strength is greater than a given value. A wireless signal is detected that the neighbor node is transmitting packets to this sink, or that the neighbor node is transmitting packets to other receivers, or even other devices (which are not part of the network, such as a person bringing a cell phone into the range). Contikimac must identify this and make corresponding response measures.
If a neighbor node is transmitting a packet to a receiver, the receiver should remain in the wake-up reload to receive the complete package and send a link-layer acknowledgment message. The other node that detects the package should go to sleep again quickly. However, these nodes do not get into sleep quickly because they must receive the full package. There is a very simple method, when CCA detects the wireless signal, in the TL + TI + TL Time has remained awake state.
Wherein, the TL is the longest possible transmission time, which ensures that the package can be fully received by the receiver (if the signal is detected by CCA at the beginning of the packet transfer).
Optimal fast sleep allows the receiver to get to sleep earlier when it receives wireless noise. First, if CCA detects a wireless signal, and the duration is greater than TL, and CCA detects noise, the node goes back to sleep. In other words, the signal is not followed by a quiet period after the active period. Second, if the signal after the active period followed a period of quiet period of signal, but the quiet period of time than Ti (two successful transfer of time interval) is small, then the node back to sleep. Thirdly, if the signal is active and follows a quiet period with the correct length of time, then the active period is followed, but the header is not detected, then the node goes to sleep state. This procedure is shown in 5.
　　

　　 Figure 5. Contikimac Optimal fast sleep: If the quiet period is not detected before the TL, go to sleep, if the quiet period is greater than TI, go to sleep; If you do not receive the packet, go to sleep

2.3 Phase Lock Transmission

If our home is each receiver has a periodic, stable wake-up interval, then the transmitter can use the wake-up phase of the receiver to optimize its transmission. The transmitter can infer the wake-up phase of the receiver through the link layer acknowledgment message sent by the receiver. Since the receiver must be in a wake state to receive the packet, if the sender receives a link-layer acknowledgment message, it can assume that the sender has correctly transmitted the packet in the receiver's wake-up window, and therefore finds the wake-up phase of the receiver. After the transmitter knows the phase of the receiver, it can start sending the next packet the next time the receiver wakes up. The entire process is shown in 6.
　　

　　 Lock-in transmission: After successfully transmitting a packet, the transmitter acquires the wake-up phase of the receiver

3. Implement

In the Contiki 2.5 Contikimac, a real-time timer Rtimer is used to perform periodic wake-up functions, ensuring contikimac stability even when many processes are running. Real-time timers can preempt how to Contiki processes at precise points in time. Contikimac runs the wake-up mechanism in a protothread process and is dispatched by a periodic real-time timer. This protothread process performs periodic wake-up and optimal fast sleep.
The transport of the package is driven by a generic Contiki process. If a wake-up process is dispatched when the wireless transceiver is busy, the wake-up timer dispatches a new wake-up process after a wake-up interval.
The phase-locked mechanism is independent of the CONTIKIMAC and is implemented in the form of modules, and is easily used in other periodic suspension mechanisms, such as Contiki X-mac. The phase locking mechanism maintains a list of neighbors and their wake-up phase. The Contikimac transport logic records the time each packet was transmitted, and when it receives a link-layer acknowledgment message, notifies the lock-in module to update the transmission time of the last packet. The time is approximately the wake-up lock phase of the receiver.
Before the transfer begins, the CONTIKIMAC transport logic calls the phase-locked module to detect if it records the wake-up phase of the receiver. If it is logged, the lock code puts the packet in the delivery queue and sets a callback timer Ctimer at the expected wake-up time of the receiver. When a callback is generated, the CONTIKIMAC begins to transmit. In this case, the transfer will take much less time than the normal transmission, because the transmission begins when the neighbor node is about to wake up. The transmission time is low and the congestion is further reduced.
If a logged neighbor node is restarted, or if its clock and the wake-up phase of the record have a large drift, the transmission will fail. To prevent this from happening, Contikimac maintains a counter for each chance of a neighbor node to record the number of failures. When the number of failures reaches a fixed value (the value is 16 in Contiki 2.5), the node is removed from the linked list. Similarly, if a link-layer acknowledgment message is not received at a fixed time (30 seconds in Contiki 2.5), the node will be removed from the linked list regardless of the value of the counter.

4. Assessment

In this paper, two aspects of CONTIKIMAC are evaluated: the energy consumption of individual contikimac and the energy consumption of CONTIKIMAC in the Data Acquisition sensor network. In addition to the results shown here, we also apply CONTIKIMAC to many recent work. More about the performance of Contikimac, readers can refer to dunkels and other people's literature [3],duquennoy, Osterlind, dunkels literature [7],duquennoy and other people's literature [8],kovatch, Literature of Duquennoy, Dunkels [16],lunden, Dunkels [17] and Tsiftes, Dunkels [24].

4.1 Micro Benchmark

We measure individual energy consumption by running Contikimac's Tmote Sky mote. We used a 100 ohm resistor in series with the Tmode Sky power supply and then measured the voltage above the resistor using an oscilloscope. The CONTIKIMAC registers the status of the wireless signal on one of the pins of the tmote Sky I/O, where the high level indicates that the wireless signal is on, the low level means that the wireless signal is off, and then the state of the pin is measured with the same oscilloscope. The wake-up frequency at the time of measurement is 8Hz, i.e. the wake-up interval is 125ms.
Figure 7 shows the wake-up condition of the CONTIKIMAC without any packet transmission. In the image below, we can see that the wireless signal was opened two times to perform two CCA. Figure 8 shows the Contikimac wake-up state when the second CCA detects a false wireless signal active period. The wireless signal continues to remain open for a while, and the wireless signal is switched off until the optimal fast sleep.
　　

　　 Figure 7. Contikimac wake-up condition when signal is not detected. You can see a total of two CCA
　　
　　 Figure 8. False wireless signal detected Yes Contikimac wake-up condition
Figure 9 and Figure 10 show the respective situations when receiving broadcasts and multicast. In both cases, as part of the Contikimac wake-up mechanism, the wireless signal is turned on, and the first CCA detects the active wireless signal. We can see that in the process of receiving multicast, the wireless signal is turned on for a longer time. This is because receiving a confirmation message is also part of receiving the multicast package.
　　
　　 Figure 9. Receive broadcast: Wake up, packet detection, receive broadcast packet
　　
　　 Figure 10. Receive multicast: Wake up, packet detection, receive multicast packets
Figure 11 depicts the broadcast transmission scenario. The broadcast must wake up and pass the package to all neighbors, so it runs during the entire wake-up interval. Because the broadcast does not need to receive a link-layer acknowledgment message, the transmitter can turn off the wireless signal between two transmissions for energy saving purposes. Figure 12 depicts the scenario of sending a multicast message to a neighboring neighbor. In this case, the neighbor is woken up approximately every 60ms, so the transmitter repeats the packet every 70ms. The start phase of the transfer is the initialization phase of the channel idle detection. After the phase-locked technology, subsequent transmissions can be optimized to begin transmission when the neighbor is about to wake up. Figure 13 depicts the reduction in the number of transmissions after a lock-phase optimization.
　　
　　 Figure 11. Broadcast transmission
　　
　　 Figure 12. Non-synchronous multicast transmission (then awakened at 110ms)
　　
　　 Figure 13. Synchronous multicast transmission (then awakened at 110ms)
By calculating the area from Figure 7 to Figure 13, we can get the energy consumption in each case, as shown in the calculation result 14. As we can see, the cost of broadcast transmission is much higher than the amount of order needed to wake up. This is very good: the most common operation in Contikimac when awakened--executes many times per second.
With Figure 14, we can compare the cost of wake-up operations in the Contikimac wake-up operation with other periodic pause mechanisms. Table 1 shows the cost of waking up in the Contikimac,contiki X-mac, as well as the periodic pause mechanism for Hui and culler [14].
　　
　　 Figure 14. Energy consumption for single CONTIKIMAC operation
　　

Energy

Protocol	(UJ)
X-mac [1]	132
132	54
Contikimac	12

　　
　　

Table 1: Energy consumption comparisons for wake-up operations

4.2 Network Power consumption

To assess the network power consumption and optimization efficiency consumed by CONTIKIMAC, we ran a series of simulations in the Contiki simulation environment. The Contiki simulation environment consists of the Cooja network emulator and the MSPSIM Device Emulator. The Mspsim provides precise cycle (cycle-accurate) Tmote sky simulations and accurate symbolic simulations of CC2420 transceivers. It makes it possible to study contikimac behavior in a time-accurate, constrained environment.
We ran some column simulations using a simulation topology with 20 nodes. All nodes run the Contki and Contiki acquisition protocols. The Contiki acquisition protocol is part of the Contiki rime protocol stack, which enables the acquisition of an address development protocol. The Contiki acquisition protocol establishes a root and expands the routing direction of the packet. We experimented with the Contiki acquisition Protocol [15] and found that the protocol was similar to other data acquisition protocols, such as the TinyOS Acquisition Tree Protocol [12].

And a little bit, see the feeling of little effect, jumped over the

5 Related work

The high power consumption of the wireless transceiver is a well-known problem, which allows many studies to be spent on RDC. The RDC mechanism can be divided into two categories: synchronous and asynchronous. The synchronization mechanism relies on each neighbor node that is being synchronized, and the asynchronous mechanism does not depend on any synchronization. Asynchronous mechanisms can be further divided into sender initialization and sink initialization. In the sender initialization mechanism, the communication between the sender and the receiver is initialized by the sender, and in the receiver initialization mechanism, the communication is initialized by the receiver. Contikimac is a transmitter that initializes the asynchronous mechanism.
The advantage of asynchronous protocols is that they do not require synchronization, and that their research community has expanded many different classes of asynchronous protocols. Earlier work on the Sensor network architecture found a simple asynchronous mechanism-low power interception, where nodes are periodically woken up to listen for any wake-up requests in the media. If wake-up requirements are found, the wireless signal stays awake to receive the packet. When a package is being sent, the sender first sends a wake-up request to wake the neighbor node. Later, the low-power interception mechanism was ported to the X-mac. In X-mac, a wake-up request consists of a series of pass-through (strobe) packets. When the receiver is awakened, it sends a link-layer acknowledgment message to indicate that it is awake and ready to receive the packet. The CONTIKIMAC is similar to the low-power wake-up mechanism, but has a precise timing when the packet is transmitted, and its wake-up mechanism is more efficient.

6 Summary

This paper describes the CONTIKIMAC RDC mechanism designed for low-power wireless sensor networks, which is the default RDC mechanism in Contiki 2.5. The Contikimac design was designed to be easy to understand and implement, using asynchronous and implicit synchronization without the need for additional headers. Contikimac uses a well-designed and simple timing strategy to make wake more efficient, uses a lock-in mechanism to make transmissions more efficient, and uses a fast sleep mechanism to quickly get to sleep when the receiver receives an error signal. Tests have shown that the wake-up mechanism is more energy-efficient than the existing periodic pause mechanism, and that lock-in and fast sleep also reduce network power consumption by 10% to 80% (depending on the wake-up frequency of the devices in the network).

7 References

[1] M. Buettner, G. Yee, E. Anderson, and R. han.x-mac:a Short preamble MAC protocol for dutycycled Wireless sensor NE Tworks. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Boulder,colorado, USA, 2 006.
[2] A. Dunkels, J. Eriksson, N. Finne, and N. tsiftes.powertrace:network-level power profiling for Low-power Wireless net Works. Technical report t2011:05, Swedish Institute of Computer Science,march 2011.
[3] A. Dunkels, L. mottola, N. tsiftes, F. osterlind,¨j. Eriksson, and N. finne. The announcement Layer:beacon coordination for the Sensornet stack. In Proceedings of the European Conference on Wireless Sensor Networks (EWSN), 2011.
[4] A. dunkels, F. Osterlind, and Z. He. An adaptive¨communication architecture for wireless sensor networks. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Sydney, Australia, Novem BER 2007.
[5] A. dunkels, F. osterlind, N. tsiftes, and Z. He. ¨software-based on-line energy estimation for sensor nodes. In Proceedings of the IEEE Workshop on Embedded networked Sensor Systems (IEEE emnets), Cork, Ireland, June 2007.
[6] A. dunkels, O. Schmidt, T. Voigt, and M. Ali. Protothreads:simplifying Event-driven programming of memory-constrained embedded systems. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Boulder, Colorado, USA, November 2006.
[7] S. Duquennoy, F. Osterlind, and A. Dunkels. Lossy¨links, low Power, high throughput. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Seattle, WA, USA, Novemb ER 2011.
[8] S. Duquennoy, N. wirstrom, N. tsiftes, And¨a. Dunkels. Leveraging IP for Sensor Network Deployment. In Proceedings of the workshop on extending the Internet to low power and Lossy Networks (IP+SN), Chicago, IL, USA, A Pril 2011.
[9] P. Dutta and A. Dunkels. Operating Systems and network protocols for wireless sensor networks. Philosophical Transactions of the Royal Society a,370 (1958): 68–84, January 2012.
[Ten] Prabal Dutta, Stephen dawson-haggerty, Yin Chen,chieh-jan Mike Liang, and Andreas Terzis. Design and Evaluation of a versatile and efficient Receiver initiated Link Layer for Low-power Wireless. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Zurich, Switzerland, Nove Mber 2010.
[One] A. El-hoiydi, j.-d. Decotignie, C. Enz, and E. Leroux. Wisemac, an ultra low power MAC protocol for the Wisenet Wireless sensor network. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), 2003.
O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis. Collection Tree Protocol. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Berkeley,ca, USA, 2009.
J. Hill and D. Culler. MICA:A Wireless platform fordeeply embedded networks. IEEE Micro, 22 (6): 12–24, 2002.
J. Hui and D. Culler. IP is Dead, a Long Live IP for Wireless Sensor Networks. In Proceedings of the international Conference to Embedded networked Sensor Systems (ACM SenSys), Raleigh, North Carolina, USA, November 2008.
J. Ko, J. Eriksson, N. Tsiftes, S. dawson-haggerty,m. Durvy, J. Vasseur, A. Terzis, A. Dunkels, and D. Culler. Beyond interoperability:pushing The performance of Sensornet IP Stacks. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Seattle, Wa,usa, Novembe R 2011.
M. Kovatsch, S. Duquennoy, and A. Dunkels. A low-power CoAP for Contiki. In Proceedings of the Workshop Internet of Things Technology and architectures (IEEE Iotech), Valencia, Spain,octo BER 2011.
M. Lunden and A. Dunkels. The politecast′communication Primitive for Low-power wireless.acm sigcomm computer communication Review, 41:31–37, April 2011.
D. Moss and P. Levis. Box-macs:exploiting physical and Link Layer boundaries in Low-power Networking. Technical report sing-08-00, Stanford University, 2008.
R. musaloiu-e., C-j. M. Liang, and A. Terzis.koala:ultra-low Power Data retrieval in Wireless Sensor Networks. In Proceedings of the international Conference on Information Processing insensor Networks (acm/ieee ipsn), St. Louis, Mis Souri, USA, 2008.
K. Pister and L. Doherty. Tsmp:time Synchronized Mesh Protocol. In Proceedings of the Iasted International Symposium on Distributed Sensor Networks (DSN08), Orlando, Florida, USA, Novemb er2008.
J. Polastre, J. Hill, and D. Culler. Versatile low power media access for wireless sensor networks. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Baltimore, MD, USA, 2004.
J. Polastre, R. Szewczyk, and D. Culler. Telos:enabling Ultra-low power Wireless. In Proceedings of the international Conference on Information Processing in Sensor Networks (ACM/IEEEIPSN), Los Angeles, C A, USA, April 2005.
[All] Y. Sun, O. Gurewitz, and D. Johnson. Ri-mac:a receiver-initiated Asynchronous Duty Cycle MAC Protocol for Dynamic traffic Loads in Wireless Sensor Networks. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Raleigh, NC, USA, 2008.
N. Tsiftes and A. Dunkels. A database in every sensor. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Seattle, WA, USA, Novemb ER 2011.
T. van Dam and K. Langendoen. An adaptive energy-efficient MAC protocol for wireless sensor networks. In Proceedings of the international Conference on Embedded networked Sensor Systems (ACM SenSys), Los Angeles, California, USA, November 2003.
[+] W. Ye, J. Heidemann, and D. Estrin. A energyefficient MAC Protocol for Wireless Sensor Networks. In Proceedings of the IEEE Conferenceon computer Communications (Infocom), New York, NY, USA, June 2002.
　　
1
　　
　　

[Contiki series of papers 4] Contikimac RDC Protocol