In Contiki, duty cycle is performed by the Radio Duty Cycling (RDC) layer. In Contiki, the radio duty cycle is expressed as a function of the wake up frequency called channel check rate (a channel check rate of 8 will result in 8 wake-ups a second for each node). Contiki provides a set of RDC mechanisms, with vari- ous properties such as: X-MAC, LPP, and ContikiMAC. All three duty cycle protocols in Contiki are asynchronous. The default mechanism in Contiki is Con-
tikiMAC [117, 118].
Figure 3.14: The network radio duty cycle with ContikiMAC, averaged for all
nodes ta the network without path loss [4]
ContikiMAC [4] uses periodical wake-ups in order to listen for packet transmis-
sions from neighbour nodes. If a packet transmission is detected during a wake-up, the receiver keeps the radio on to receive the packet. When a packet is received, the receiver sends a radio acknowledgment. In each packet transmission, sender is repeatedly sending the packet until an acknowledgment is received. Broadcast packets doe not wait for link layer acknowledgments. Instead the transmitter node will continuously send the packet for the whole wake-up interval. Additionally, ContikiMAC uses a fast sleep optimisation, to allow receivers to quickly detect false-positive wake-ups, and a transmission phase-lock optimisation, to allow run- time optimisation of the energy-efficiency of transmissions. Furthermore, a power- efficient wake-up mechanism that relies on precise timing between transmissions is implemented in ContikiMAC. 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 is used for Con- tikiMAC’s wake-up. If the RSSI is below a given threshold, the CCA returns positive, indicating that the channel is clear and thus node returns to sleep mode. If CCA returns negative, indicates that the channel is in use. Therefore the radio
remains on for the reception of the transmitted frame.Figure 3.13shows the energy
Figure 3.15: The network radio duty cycle with ContikiMAC, averaged for all
nodes in a network with path loss [4]
has the lowest energy cost. This can explain why ContikiMAC is designed to oper-
ate with frequent (many times per second) wake-ups and CCA checks.Figure 3.14
and Figure 3.15 demonstrate the radio duty cycle in ContikiMAC, averaged for all nodes in the network for no-loss and with loss paths accordingly.
In X-MAC [8], before each packet transmission, nodes transmit short preambles
that contain the destination address. Periodically, a node will switch its radio on and scan for incoming preambles. When a node is not included in a communication (no preamble received or preamble is not destined for that node), it will immedi- ately go back to sleep mode. When a node successfully receives a preamble, it will reply with an early acknowledgment (ACK) and keep the radio listening in order to receive the incoming packet. X-MAC assume that nodes will wake-up simul-
taneously after a fixed interval. Figure 3.16, demonstrates the radio duty cycle in
a data collection network with path loss for X-MAC and ContikiMAC.
R. Musaloiu-E et al. propose Koala: an Ultra-Low Power Data Retrieval in
Wireless Sensor Networks [9]. In this work a low power probing (LPP) tech-
nique has been proposed for duty cycling. Nodes will periodically broadcast short packets (probes) requesting acknowledgments. When a node receives an acknow- ledgment, it remains active and starts waking up other nodes by acknowledging their probes. If a node does not receive an acknowledgment after transmitting the
Figure 3.16: The radio duty cycle in a data collection network with path loss, with X-MAC and ContikiMAC, as a function of the wake up frequency called channel
check rate [4]
Application Programme
UDP
TCP
IPv6
IEEE 802.15.4 MAC
IEEE 802.14.5 PHY
6LoWPANadaptation layer
Transport
Network
Data Link
Physical
Application
Figure 3.17: 6LoWPAN adaptation layer
3.7
6LoWPAN
Insubsection 2.2.1we discussed what are the advantages of integrating IP in sensor nodes. However, to integrate IP in WSNs, several significant attributes must be combined. WSNs are data centric while IP networks are address centric. The main objective of 6lowPAN, proposed by IETF, is to integrate IPv6 in LoWPANs
supported by IEEE 802.15.4 [119, 120,121,122,123].
IPv6’s MTU is 1280 bytes. IEEE 802.15.4 standard defines a packet size of 127 bytes. Out of the 127 bytes of 802.15.4, 25 are used by the MAC layer headers and optionally 21 bytes are consumed for security by AES-CCM-128. In the worst case this leaves 81 bytes for the IPv6 payload. After removing the size of an IPv6
01
0000010
HC1
11
000
Datagram size
Datagram tag
11
100
Datagram size
Datagram tag
Datagram Ofset
10
O
F
Hop limit
Source
address
Dest.
address
01
000001
Uncompressed IPv6 address
01
0000100
HC1g
Header compression
First fragmentation header
Subsequent fragmentation header
Mesh Header
header (40 bytes) only 41 bytes are left. Additionally, the transport layer header must be deducted from the remaining 41 bytes (8byte UDP header and 20 bytes the TCP header). This would lead to a very short payload (33 bytes if UDP is used and 21 bytes if TCP is used).
Based on the above, an adaptation layer is needed to comply with the IPv6 requirement to support a minimum MTU size of 1280 bytes as well as compression
techniques to reduce protocol overhead. RFCs 4919 [22] and 4944 [23], define the
functions included in 6LoWPAN. The 6LoWPAN adaptation layer provides three main services:
• Packet size adaptation, fragmentation and reassembly in order to fragment IPv6’s packets into 127 byte packets.
• Header compression. This feature allows the protocol to compress the 40 bytes of standard IPV6 to just 2 bytes.
• Link layer (layer 2) forwarding when multi-hop is used by the link layer. In most cases, the use of efficient compression allows most applications to send
their data within a single IPv6 packet. Figure 3.17 demonstrates an IPv6 with
6LoWPAN protocol stack.
Similar to IPv6, the 6LoWPAN adaptation layer makes use of header stack- ing (headers are added only when needed). Currently three type of headers are supported by 6LoWPAN:
• A mesh addressing header. • A fragment header.
• An IPv6 compression header.
These headers will appear in the above order when present. Figure 3.18shows the
layout of 6LoWPAN headers.