Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol

Transcription

1 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol Pablo Suárez Hernández Stockholm, February 2008, Master Thesis Saab Communication - Swedish Institute of Computer Science Escuela Superior de Ingenieros - Universidad de Sevilla

2

3

4

5 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol Abstract The ZigBee standard is a common choice for implementing wireless sensor networks. For a mesh network topology the protocol lacks of adequate power-saving mechanisms, which limits the lifetime of a battery-powered ZigBee network to a few days. This short lifetime drastically restricts the possible application scenarios for ZigBee. To expand the usefulness of ZigBee an implementation has been developed to replace the default ZigBee MAC protocol with a power-saving protocol denominated X-MAC. The stack has been implemented in Contiki Operating System, which features a novel power profiling mechanism. This implementation has been used to verify the power consumption reduction achieved by the stack, saving up to a 90% of energy, and leading to a ten-fold increase in network lifetime at the price of a slight increase of network latency. I

6 II

7 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol Acknowledgments I would like to express my gratitude to my advisors, Carl-Gustav Renmarker from Saab Communication and Adam Dunkels and Thiemo Voigt from SICS, for their constant help and support through the work, and for having provided an excellent work environment and all the resources I required. I also want to thank to Nicolas Tsiftes, Zhitao He, Niclas Finne, Joakim Eriksson and Fredrik Österlind, members of the NES group at SICS, for their assistance and for sharing with me their experience and knowledge. Thanks also to my supervisor in the Universidad de Sevilla, David Muñoz de la Peña, for his encouragement and for all these years of advice and friendship. I would like to mention all the wonderful people and friends with whom I shared my Swedish experience and that made it worth to stay so far away from home. Thanks specially to Jesús and Agustí, for the unique group we have formed since our very first day here, and to the rest of the Kista Team that survived our Erasmus year: María Elena, Barbara, Claudia, Dani, Luis, and Pancho, and all those that are back home, for their friendship and for everything we have shared. Now that I am one step away from closing an important age of my life, I can t help looking back to the years I spent studying in Sevilla. This has been a tough road many times, but fortunately I never walked alone. I want to thank to the crew of Minas Friki, my flatmates and associates, for all that I learned from them, for the wonderful years we spent together, and for the proud that I feel of having been part of that adventure. I would also like to thank all my other awesome friends and mates that I made through the years, specially to the Dungeoneros squad, who still form part of my life despite the distance. Perhaps being apart from my loved ones is the biggest sacrifice that I have had to make in my life. This applies to my friends, but specially to my family, my parents and my sister to whom I dedicate this thesis and whatever comes after. Thank you for your love and your support, and for being so close although so far away. III

8 IV

9 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol CONTENTS Contents Abstract I Acknowledgments III Contents V List of Figures IX 1 Introduction 1 2 Wireless Sensor Networks Overview Target scenarios Environmental sensing Security sensing Resource tracking Other scenarios Network performance evaluation: Parameters and metrics Traffic load Lifetime Latency Coverage Cost Security V

10 CONTENTS 3 The ZigBee Stack Overview The Physical Layer (PHY) Overview Frame format The Medium Access Control Layer (MAC) Overview Operating modes The CSMA/CA mechanism PAN start, network association and maintenance Transmission and reception of information The Network Layer (NWK) Overview Neighbor table Network creation Network association Routing The Application Layer (APL) Overview Application objects and profiles Discovery and binding ZDO APS The Contiki OS and the Tmote Sky Platform Overview The Contiki Operating System General description and characteristics System architecture The Contiki kernel Services Protothreads Communication stacks The Tmote Sky Platform VI

11 CONTENTS Microprocessor Radio Power Saving Mechanisms for WSN Overview Energy Waste MAC Protocols Strategies Asynchronous protocols Synchronous protocols Proposed MAC Protocols S-MAC and T-MAC WiseMAC TRAMA B-MAC and Z-MAC X-MAC Other Approaches Implementation Software Architecture Overview ZigBee Stack Implementation Functionalities Implemented Contiki main thread Application layer Network layer (NWK) Medium access control layer (MAC) Physical layer (PHY) The X-MAC Protocol Implementation Evaluation Technical and Practical Aspects Scenario 1: Single-hop Energy Consumption Scenario 2: Single-hop with Contention Scenario 3: Multi-hop Conclusions and Future Work 83 VII

12 CONTENTS A Frame Formats 87 A.1 PHY layer A.1.1 PPDU format A.2 MAC layer A.2.1 General MAC frame format A.2.2 Beacon frame format A.2.3 ACK frame format A.2.4 MAC command frames A.3 NWK layer A.3.1 General NWK frame format A.3.2 NWK command frames A.4 APL layer A.4.1 General APL frame format B Implementation Details 95 B.1 Global Variables B.2 Functions Implemented Bibliography 99 VIII

13 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol LIST OF FIGURES List of Figures 3.1 ZigBee protocol stack Star and peer-to-peer topologies [24] Cluster tree topology [24] PPDU frame format [24] Superframe structure in beacon based mode [24] The CSMA mechanism [24] The Rime stack [17] The Tmote Sky node X-MAC transmission and reception mechanisms [10] Proposed software architecture Data transmission procedure [24] General MAC frame format [24] X-MAC powercycle basic scheme X-MAC read function basic scheme Scenario 1 scheme Receive mode power consumption, sender node Receive mode power consumption, sink node Transmit mode power consumption, send node Round trip time Scenario 2 scheme Receive mode power consumption with contention and contention level detected. Sender nodes Receive mode power consumption with contention. Sink node.. 73 IX

14 LIST OF FIGURES 7.9 Transmit mode power consumption with contention Round trip time with contention Scenario 3 scheme Receive mode power consumption in multihop scenario Receive mode power consumption in multihop scenario. Comparision of X-MAC configurations Round trip time in multi-hop scenario A.1 PPDU frame format A.2 General MAC frame format A.3 Frame control field A.4 Beacon frame format A.5 Format of the GTS information field A.6 Format of pending address field A.7 Format of the beacon specification field A.8 Format of the ACK frame A.9 Mac command frame general format A.10 Network frame general format A.11 Frame control field A.12 NWK command frames general format A.13 General APL frame format A.14 Frame control field of the APS general frame X

15 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol 1. Introduction Chapter 1 Introduction The increasing number of wireless-based applications and technologies is changing the mentality and the rules of most Information Technologies systems. In the recent years, developments in the semiconductor industry have enabled the appearance of small, cheap and simple devices, known as sensor nodes. These nodes are capable to sense a number of physical magnitudes, to transmit and receive information to and from other nodes, and to benefit from the low power consumption of its components, resulting in an extended power autonomy. The introduction of this technology in the industry has allowed the development of a number of new applications, and the improvement of many existing ones. These applications range from domotics and automation products to civil defense systems and military applications. This market has been growing during the recent years. Many companies are starting to show interest in new developments and new products based on wireless sensors are being introduced in the market. Also, research groups around the world are constantly working and improving the existing technology, and the wireless sensor network (WSN) development community grows every year with students that find this area interesting and full of possibilities. The Networked Embedded Systems Group of the Swedish Institute of Computer Science (SICS), located in Stockholm, is an acclaimed and remarkable research group in this field. They have developed their own operating system, Contiki, which is now one of the most popular among users and developers of wireless sensor systems. Contiki was developed for memory-constrained embedded systems, like the wireless sensor nodes. It has a number of advanced features, it is easy to port and has already been implemented in a number of different platforms. One of the main challenges that the development of this kind of network presents is to decrease the power consumption as much as possible, extending the lifetime of the battery powered nodes long enough to be considered a good option for scenarios where battery replacement must be done as seldom as possible. Extending the battery life long enough can greatly improve the possible applications and boost the commercial success. It is therefore one of the main subjects being researched by WSN developers. 1

16 There are several approaches to this goal. Many of them focus in medium access control (MAC) protocols. MAC protocols are used in every shared-medium network. Their main task is to avoid collisions among nodes trying to access the channel at the same time. There exist a number of developed MAC protocols that have been in use for a long time, like time multiplexing based schedules (TDMA) or channel assessments procedures (CSMA), that have been implemented in many different kinds of wireless networks. However, the special requirements of wireless wensor networks have motivated the development of more specific MAC protocols that also deal with energy efficiency as well as other relevant factors like scalability or latency. SAAB Communication delivers solutions based in WSN in a wide range of products, and is interested in further development of this technology, specially in the field of energy efficiency and robustness. Although no standard exists that fully meets SAAB s requirements, the use of existing standards is desirable since valuable work has been put into making the design choices defining them. The ZigBee-IEEE stack is one of the most popular choices for WSN development. The set covers network forming, routing and security protocols. Still, further development is required to obtain improved performance in terms of energy consumption in mesh-based networks. This Master Thesis is the result of a research project carried out for SAAB Communication in collaboration with SICS. Hardware and all the required resources were provided by both organizations. This work also represents the author s final project of its Telecommunication Engineering program at the Universidad de Sevilla. The aim of this work has been to implement a version of the ZigBee stack using the Contiki operating system, and to improve it by developing a MAC protocol in order to save as much energy as possible in different scenarios. Several experiments were realized to determine the performance of the designed implementation, and important conclusions and future work ideas were obtained. The rest of the report is structured as follows: Chapter 2 provides a general introduction and description of the most relevant characteristics and considerations regarding wireless sensor networks. Chapter 3 provides a description of the ZigBee standard, focusing on the different layers of the standard. Chapter 4 provides background information of the Contiki OS and the Tmote Sky platform. Chapter 5 covers different existing alternatives of power saving mechanisms for wireless sensor networks, describing several MAC protocols already developed. Chapter 6 describes the implementation that was developed to achieve the objectives described above. Chapter 7 provides detailed results of several experiments carried out to determine the performance of the designed implementation. Finally, the thesis is concluded in chapter 8 with a summary of the main conclusions and several proposals for possible future work ideas. 2

17 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol 2. Wireless Sensor Networks Chapter 2 Wireless Sensor Networks 2.1 Overview New applications based on embedded systems and mobile technologies have caused a significant growth in wireless communication systems. Those related with Internet, such as web browsing or , require high data throughput and bandwidth. The Institute of Electrical and Electronic Engineers (IEEE) published the standard , defining wireless local area networks. This standard is used in the majority of these services. There are a number of versions of this standard, working in different frequency bands and providing different transmission rates and communication ranges. The version n is currently under development and it will allow data rates of up to 300Mbit/s [2]. Wireless personal area networks (WPANs)[29] are based strictly in ad-hoc communication and do not employ any kind of fixed infrastructure. IEEE standardized the previous development performed by the Bluetooth Special Interest Group (SIG)[1] creating the group[2]. More recently, a special type of WPANs has been defined, with lower throughput requirements and generally involving sensing mechanisms. These are known as low-rate WPANs (LR- WPANs), or more commonly, wireless sensor networks (WSNs) [22]. A very clarifying initial definition of a WSN is proposed by Hill [23]. equation: Sensing + CPU + Radio = Thousands of potential applications defines accurately the wide range of different possibilities that the combination of equipment able to sense different physical magnitudes (temperature, movement or light) with tiny, embedded electronic systems and wireless communication capabilities can provide. A WSN consists of a large number of sensor nodes that employ wireless communication to transmit information between each other. The sensor nodes are tiny embedded devices with low computational and memory capacities that feature a number of sensing devices. Such devices can autonomously form a network The 3

18 2.2. Target scenarios through which the collected sensor data is transported. A WSN is normally considered a wireless ad-hoc network, featuring self-configuration and quick deployment capacities, as well as support for multi-hop routing. Sensor nodes are typically equipped with a radio transceiver, a low-capacity microcontroller, a power source (generally a battery) and sensing equipment for different magnitudes. Their size can vary depending on their complexity and their integration level. Previous work [36] have proposed large scale networks using tiny nodes of microscopic dimensions and very low cost. The present state of technology however require further development to fulfill the ideal requirements of this kind of deployment. There are many potential applications and services employing a wireless sensor network [34]. Each of them have their own requirements and constraints, based on the present-day technological status. Factors like price, size or battery lifetime of the nodes must be taken into account in order to develop successful products and services. Given the special characteristics of WSN, and the lack of infrastructure or nodes with higher capacity, one of the main challenges consists of adequately designing individual nodes according to the expected system requirements. It is therefore important to determine the different target applications, and to identify the special requirements and characteristics in a network level, that determine the design of the individual nodes in both hardware and software levels. Sensor networks have many potential applications and scenarios. They are described in next section. There are also a number of design parameters and performance factor, that depend on the chosen application, and that are described in section Target scenarios Previous work [23, 11] agree in defining the following different types of applications as the most relevant and representative scenarios. Combinations of the characteristics of each basic application result in a vast number of possibilities that prove the versatility of WSNs and justify the efforts made in the development of this kind of systems Environmental sensing The low-cost, long battery lifetime and scalability of a WSN can be applied to those activities based on the measuring of different values in different points in a large area. A scientist can deploy a network of tiny nodes that would provide readings on different physical magnitudes, and transmit the information to a sink node after transmitting it through the network. Given that the system can work for a long time, long-term trends or seasonal changes can be easily logged and studied. Another possible scenario might consist in the real-time monitoring of different magnitudes in the crop fields of a farm, integrating the WSN with other 4

19 2. Wireless Sensor Networks kind of automated devices, developing the concept of Intelligent Agriculture. If the amount of water required in different areas of crop fields can be accurately determined thanks to the monitoring of rainfall in different plots that can be thousands of square kilometers large, money and precious resources can be saved. It is important to keep in mind that the sensor nodes that form a WSN can include a great variety of sensing devices, so a scientist, farmer, or any potential user can obtain information about almost any measurable magnitude, including temperature, sound, vibration, pressure, motion or pollutants. In this specific scenario, the network requires to have a high number of nodes scattered in a large area, meaning that multi-hop capabilities are required. A network coordinator, that may have higher computational capacity, is the final destination of all messages issued by the sensing nodes. Data rates in this kind of scenario are very low, although this may differ depending on the quality and frequency of the measures to be taken, as well as the real-time requirements of the selected application. Given that it is likely that the nodes would be distributed evenly, the most usual network topology is that of a mesh network. It is therefore important to have a good routing strategy to optimize the transmission of the messages through the network and to the final destination node. Another option is to implement a tree-based routing network, if the design parameters determine that it is a better solution to have a number of high capacity nodes that may work as a sink for a number of child nodes. Nodes deployed in the target area send information periodically. Depending on the requirements of the application the frequency of transmissions may vary, but for a typical environment monitoring scenario rates are expected to be between 1 and 15 minutes between messages [23], since generally, the parameters being measured change slowly enough as to be correctly studied with such frequency rate. Battery lifetime is a crucial parameter in this case. Given that most of the energy consumed by a node is caused by the radio operation, either sending or receiving packets or simply waiting in listen mode for an incoming transmission [30], sensing nodes must remain in sleep mode most of the time, in order to save as much energy as possible. Still, most of the nodes are not in range of the final destination, so there must be a synchronization procedure that provides reliable communication in a multi-hop network while allowing the nodes to spend as much time as possible in sleep mode in order to save energy. The most important performance parameters of this kind of applications are: Long lifetime. Low data rates latency is not critical. Topologies allowing to cover a vast area (multi-hop capacity) Security sensing One of the earliest proposed uses of WSNs was related with military defensive systems and surveillance applications [11]. The versatile elements that form 5

20 2.2. Target scenarios a WSN provide a wide range of solutions in both the fields of military and civilian defense and security. A WSN is specially suitable to guard defensive perimeters, alerting when non-authorized access occurs in a secure area, or monitoring critical parameters in certain locations as temperature or radiation in power plants. The capacity to detect movement and anomalies can be specially interesting and valuable in restricted facilities, that require the highest security levels, such as airports, harbors or other military installations. Furthermore, sensor nodes can be used to identify targets or locate friendly troops in a battlefield, or can also be used for tasks as control of civilian activities, tracking different parameters like movement or implementing elements like acoustic microphones. A WSN can be integrated in a high scale, integral security system, operating along with other kind of sensors and surveillance equipment, like radars or smart cameras. This can become a very powerful tool for both police forces and private security companies, improving the efficiency of police forces and private guards and contributing to a safer world. Taking a closer look at the characteristics of this kind of network, a very important feature is that, instead of collecting information, the nodes only transmit data when certain events occur, triggering alarms that should spread through the network so that security operators can take appropriate actions. Reliability is also a key requirement. Every node should send periodically a signal to notify the network that it is working properly. This way, controllers can detect possible security violations in areas where nodes have stopped working, and replace the fallen nodes as soon as possible. Additionally, other robustness requirements should be taken into account. For instance solutions may include implementing a mesh topology network in order to have redundancy in the available routes in an eventual node malfunction or even an electronic attack on the network. Another important feature of this kind of networks is the requirement to have a low latency value for alarm messages. If a security violation occurs, immediate actions may be required to be taken, and therefore alarm situations should be reported generally within a second. In a large-scale network, this can represent a challenge because every hop supposes an additional delay. Additionally, powersaving schemes must be adapted to provide a reasonable battery lifetime while ensuring the required latency value. The most important performance parameters of this kind of applications are: Robustness and reliability. Low latency. Low data rates Resource tracking Assets tracking and supply chain management are interesting fields for the implementation of WSNs. In large-scale industrial activities, real time information 6

21 2. Wireless Sensor Networks on the location of relevant resources or people can improve the performance of many operations. Given that one of the most interesting characteristics of sensor nodes is its mobility, attaching these nodes to moving components within a productive process can result in an improvement of productivity (and profit). Sensor nodes can be tracked while moving through any area within the range of a sensor network. In this case, moving nodes are attached to valuable resources, while static ones can control flows within the process or provide real-time inventory information. Additionally, customers may benefit of the existence of a WSN by tracking products through different stages of a delivery process, if they are allowed to access the tracking information that the network can provide. In this kind of scenario, nodes attached to moving objects can actually be considered passive emitters, since all they have to do is send a tracking signal regularly in intervals that can be considered long enough as to allow a very high power autonomy. On the other hand, static nodes tracking the location and status of the moving ones could be placed in fixed positions and be line-powered. It is also important that the network is ready to modify its routing scheme since a number of the elements conforming it will be constantly moving. In a deployment involving a high number of elements being tracked, having cheap and simple tracking devices to tag the different elements is a requirement. Cost should be low enough as to consider replacing the nodes that stop working for new ones. Unlike in the previous proposed scenarios, mobility in this case is a key factor that must be considered when designing the network. The system needs to be capable of supporting a network topology that changes in time as the tracking nodes change their location. The most important performance parameters of this kind of applications are: Mobility of devices, re-configuration of network topology on the run. Low data rates. Low cost Other scenarios The three scenarios described provide a wide idea of the possibilities that a WSN can achieve. The simplicity of the nodes deployed makes it easy to combine different elements to fulfill other requirements in each specific case. This is why an important phase in the network design is to determine the exact requirements that the system will have, and to express them in the appropriate terms so that they can be considered as design constraints for the elements forming the network. 7

22 2.3. Network performance evaluation: Parameters and metrics 2.3 Network performance evaluation: Parameters and metrics The preliminary study of the different target scenarios and applications allows to extract performance objectives and parameters that determine the suitability of a network for different usages.different networks have different objectives and requirements. Several authors [23, 11] have proposed a number of metrics that must be considered when studying the performance and design of WSN for different target applications: Traffic load. Lifetime. Latency. Coverage. Cost. Security. Hill [23] states that some of these parameters are interrelated. Power-saving mechanisms involving synchronization or long sleep periods can increase the latency. Higher traffic rates will generally involve longer listen periods, decreasing the battery lifetime. This set of parameters must be determined carefully, considering both the network requirements and the sensor nodes characteristics Traffic load Traffic load is determined by the amount of information that the WSN is required to transmit. In data collecting scenarios the accuracy of the obtained information depends on the number of samples considered. In cases where the network tracks for events such as alarm, the traffic load is likely to be very low unless many control messages are included in the network to maintain track of the different nodes and their status. The network dependency on the traffic load is evident. Energy consumption generally depends on the number of packets transmitted, since most transmission schemes vary their parameters to be able to carry the amount of expected traffic while consuming the less possible energy by turning the radio off periodically. An excess of traffic in the network can also have an impact in latency if the network is not capable of handling all the frames, resulting in higher delays. Another aspect that must be considered is that in some cases it is required that the network is designed to handle a sudden change of traffic rate caused by an external event (like an alarm) that require a higher transmission throughput in order to fulfill the application requirements. 8

23 2. Wireless Sensor Networks Lifetime In most scenarios a very interesting option of a WSN consists of being able to place a number of nodes in a vast operational area, whether a field being studied in a environmental monitoring application or a security perimeter or a critical location in security sensing applications. Many times, this involves having unattended nodes for as long time as possible. This is limited by the battery life of the device, so each node should perform its tasks while trying to minimize its power consumption as much as possible. Given that a node performs different operations, it is important to have an accurate knowledge on how the energy is spent in order to address the problem. Raghnathan et al [30] have proved that most of energy consumption in a sensor node is related with the radio operation. Furthermore, for most low-power consumption microcontrollers their consumption compared to the radio device can be neglected. In order to extend the battery lifetime transmissions and receptions must be scheduled so that the radio can be turned off during long periods. This has an impact on other system metrics, mainly latency. This problem is one of the key points of this thesis, and is addressed in further sections Latency Latency is a critical parameter in security and surveillance applications in which intrusions or anomalies must be notified immediately to the authorized personnel. One consequence of the high consumption of the radio devices is that the minimization of the energy spent in listen mode affects the latency. Communication protocols trying to save power by periodically turning the radio off cannot guarantee an immediate reception of incoming packets, resulting in higher delays for the information. The trade-off between power consumption and response time is extensively studied in chapter 5 of this report, and is one of the most relevant results of the experiments performed Coverage Coverage is one of the most important parameters related with the specific scenario that a WSN is designed for. Depending on the requirements, the number and the transmission power of the nodes is affected, resulting in the desired physical range of the network. If multi-hop communications are introduced in order to extend the network coverage, latency is also increased because of the necessity to perform more than one transmission to reach a final destination. Scalability is also related with coverage, since a user might be interested in increasing the network range by adding more nodes to a deployed system. The network must be capable of scaling itself in order to adapt to the requirements of each specific situation. 9

24 2.3. Network performance evaluation: Parameters and metrics Cost Given the logical relation between the overall system capacity and the cost, it is important to properly calibrate the system performance requirements in order to minimize the budget of the product. An extensive knowledge of both the available equipment and the application requirements can provide affordable solutions in each case. Other parameters of the network may have an impact on the economic cost, but it is a fact that most of available equipment in the WSN field is versatile enough as to work in different configurations and with different requirements. Another aspect that must also be considered when determining the cost of a system is the capacity of self reparation and self awareness of the status of the network. Maintenance and reparation of the network also determine the economic expenses for a WSN deployment. Minimizing them is possible if the designed network is capable of auto configuring itself for any topology or application, as well as providing accurate information on failing elements and indicating solutions to the user. A WSN must be considered as a tool that non-technically skilled users can employ. Having a user-friendly interface and the autonomy exposed above increases the final value of the product Security Once again, security requirements and its impact on the other network parameters depend on the application implemented. Obviously, those scenarios related to defensive or security system have higher requirements in this field. The security requirements must be addressed from different points of view. Information encryption and authentication are measures to be considered to protect the data transmitted. The result of using these techniques is a higher amount of traffic in the network, which can affect the system overall performance since more redundancy traffic is inserted in the system. Robust systems must also be designed to face unexpected events or even electronic attacks from hostile parties. Increasing the number of nodes in a meshnetwork topology provides a route redundancy that can be helpful to deal with these situations, with a higher economic cost. Other solutions include using multi-channel devices. Summarizing, a number of different applications have been presented. These applications motivate the development of special protocols and standards capable of meeting the requirements in each case, given a number of parameters that determine the validity and the performance of a wireless sensor network. 10

25 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol 3. The ZigBee Stack Chapter 3 The ZigBee Stack Many wireless monitoring and control applications require low data rates and long battery lifetime. Standards for general-purpose networking like the IEEE do not fulfill these requirements, since they are designed for infrastructure based networks that prioritize higher transmission speeds employing devices that are normally line-powered. To fulfill the WSN general requirements, a number of standards and protocols have been developed in order to obtain a feasible solution that enables the use of tiny sensor nodes for all the possible potential applications described before. For this special kind of wireless systems, the IEEE has developed the specification [24] which is widely used in most WSN-based applications. The IEEE specification describes the physical and the medium access control layers of the protocol stack. Different options have been developed for the network and application layers that can be combined with the standard to provide different functionalities depending on the target applications. One of such options is ZigBee [7], developed by the ZigBee Alliance [3], an association of companies working together to develop and improve this protocol stack. This chapter provides a deep study of the ZigBee stack, covering the main features and providing detailed descriptions of the different layers that define the functionality of the standard. 3.1 Overview To start with, it is important to understand the difference between the IEEE and the ZigBee standards. ZigBee only specifies the NWK and APL layers of the stack, and it is built upon the standard that provide both PHY and MAC services and functionalities. However, the name of ZigBee is usually applied to the whole stack. Figure 3.1 presents the proposed protocol architecture. 11

26 3.1. Overview Figure 3.1: ZigBee protocol stack. The main features obtained from the combination of ZigBee and IEEE include: The IEEE specification allows data rates of 250kb/s, 40kb/s or 20kb/s. The network can be deployed using a star or a mesh topology, and may use an optional beacon based optional transmission scheme that enables the power saving capabilities. In that case, a number of time slots can be allocated to specific nodes in order to guarantee a QoS level. The specification also defines a CSMA-CA scheme for transmission, as well as energy detection capacity and link quality indications. ZigBee supports two different types of devices: 1. Full function device (FFD): Can perform all available operations within the standard, including routing mechanism or coordination tasks. 2. Reduced function device (RFD): Only implements a limited version of the IEEE protocol. Must be associated with a FFD. A RFD does not have routing capacity Every LR-WPAN must include a PAN coordinator. That device must be a FFD and provide global synchronization and managing capabilities for the network. There are two basic topologies supported by the IEEE standard: the star topology and the peer-to-peer or mesh topology. Figure 3.2 represents both options. In the star topology one node operates as PAN coordinator while all other nodes in the network can only communicate with it. Any other device willing to join the network or communicate with other nodes must send its data to the PAN 12

27 3. The ZigBee Stack Figure 3.2: Star and peer-to-peer topologies [24]. coordinator, that will forward it or take the appropriate actions. Because of the topology characteristics, it is recommended that the PAN coordinator is main-powered because of the high consumption it is expected to have given the amount of activity required. A star topology is not an adequate solution for most of the proposed scenarios and applications of a WSN for many reasons. Multi-hop networking is not supported, and generally it is required to have a coordinator node not powered by batteries, reducing the versatility. Still, certain applications like home automation can benefit of this option and the other stack features. The alternative to the star topology is the mesh network. A PAN coordinator is also included in this case, although communication is not required to pass through it. Instead, it is decentralized, and routing mechanisms must enable the end-to-end connectivity between all devices in the network. In this sense, it is important to remark that only FFDs can act as routers. The IEEE standard also indicates the possibility of implementing a third network topology, denominated cluster-tree. It basically consists of a special peer-to-peer network in which a number of FFD may act as local coordinators providing synchronization services to child devices. The cluster-head nodes communicate with each other, acting as gateways for the end nodes of each cluster. The specification does not define the cluster tree topology, but it indicates that it is possible to implement it in the higher layer. ZigBee provides support for this option in the NWK layer. Figure 3.3 represents the proposed topology. 13

28 3.2. The Physical Layer (PHY) Figure 3.3: Cluster tree topology [24]. 3.2 The Physical Layer (PHY) Overview The PHY layer is the closest to the medium and the responsible for the data transmission through a certain radio channel using the specific modulation and spread technique described in the specification. There are three frequency bands available at 2.4 Ghz, 915 Mhz and Mhz; and a total of 27 channels. The modulation scheme in the highest band frequency is O-QPSK, while in the two lower bands is a BPSK scheme. A direct sequence spread spectrum (DSSS) is employed in all of the options. Table 3.1 summarizes the main transmission features of each frequency bands. The main tasks of the PHY layer include: Table 3.1: Frequency bands and data rates. Phy Frequency Spreading parameters Data parameters (MHz) (MHz) Chip rate Modulation Bit rate Symbol rate Symbols (kchip/s) (kb/s) (ksymbol/s) 868/ BPSK Binary BPSK Binary O-QPSK ary Orthogonal 14 Transceiver mode management: The radio transceiver may operate in three different modes: transmit,

29 3. The ZigBee Stack receive (or listen) and sleep. The PHY layer turns the device to the appropriate mode upon request of the MAC sub-layer. Energy detection (ED): The PHY layer can use the transceiver to perform an estimation of the power signal present in a specific channel of the supported band. This data can be used by the system, typically to perform a channel assessment operation. Link quality indication (LQI): A measurement can be performed in incoming packets to determine the strength/quality relation of a radio link. This information is available for the upper layers that can use it with several network maintenance operations. Clear channel assessment (CCA): Using the ED capability previously described the PHY layer can determine if a channel is idle before starting a transmission. Channel frequency selection: The PHY layer is able to tune the transceiver to the appropriate physical channel indicated by the MAC layer. To perform these tasks, the PHY layer features two different services that provide an interface between the MAC layer and the physical radio channel. These are the physical data service (PD-DATA) and the physical layer management entity (PLME). The PD-DATA entity supports the transport of frames between peer MAC layer entities, while the PLME provides a management service interface that allow management functions to be invoked. The PLME also maintains a database of managed parameters belonging to the PHY layer. This is denominated PHY PAN information base (PIB). The PIB contains attributes that define different aspects related with the interaction of the device with the physical medium, such as the output power or the current channel in use. These attributes can be modified using the management entity of the PHY layer Frame format The PHY layer frames receive the denomination of PPDU (physical protocol data unit). Its format is shown in Figure 3.4. A PPDU consists of a synchronization header, which allows receiving devices to synchronize to the bit stream; a PHY header, containing the frame length value; and the MAC layer payload. Outgoing frames are generated in the PHY layer by adding the header fields to the MAC payload provided by the MAC layer. In the case of incoming frames, the PHY layer extracts its header information before notifying the MAC data entity the reception of the frame. 15

30 3.3. The Medium Access Control Layer (MAC) Figure 3.4: PPDU frame format [24]. 3.3 The Medium Access Control Layer (MAC) Overview The MAC layer of the IEEE protocol provides an interface between the PHY layer an the higher layers of the stack. The MAC layer handles access to the physical radio channel and is responsible for the following tasks: Generation of beacon frames, if the device is a coordinator and the network is configured to work in a beacon based mode. Synchronization to network beacons. PAN association and disassociation support. Device security. Management of the CSMA-CA mechanism for channel access. Management of the GTS mechanism for allocated time slots. Provide a reliable link between peer MAC entities. The MAC layer provides an interface between the next higher layer in the stack (in this case the ZigBee NWK layer) and the PHY layer. As in the PHY layer, two services are defined that provide the required functionalities: The MAC data service, denominated Mac Common Part Sublayer (MCPS) and the MAC management service, denominated Mac Layer Management Entity (MLME). These services provide the required interface between the NWK and the PHY layers, using the PD-DATA and PLME entities and the corresponding ones in the NWK layer. There is also an implicit interface that allows the MLME to use the MCPS data service in order to transmit several types of command frames. The MAC layer maintains a database including information of different parameters related with the configuration and the operating modes of the device, denominated MAC PIB. These attributes are required to manage the MAC layer, and are accessed and modified by the MLME entity. One of the most important tasks of the MAC layer is to provide a reliable and collision free access to the channel. The IEEE specification defines two possible options that determine the operating mode of the whole network, depending on the use or not of a beacon enabled mode. 16

31 3. The ZigBee Stack Operating modes Beacon enabled mode When the beacon enabled mode is active, a superframe structure is used to schedule communication between devices. The PAN coordinator defines the format of the superframe and notifies it to the other nodes including the information in periodic beacon frames. The superframe consists of 16 equally sized slots followed by an inactive period previously defined. A frame can be divided in 3 different parts: Contention Access Period (CAP), Contention Free Period (CFP) and an Inactive Period (IP). Figure 3.5 depicts this superframe structure. Figure 3.5: Superframe structure in beacon based mode [24]. During the CAP, any device willing to communicate must compete for the channel using a slotted CSMA/CA mechanism. In this case the backoff time of the contention mechanism is aligned with the superframe slot boundaries, so a node that is unable to transmit during a time slot of the superframe because of channel contention is not allowed to try again until next slot. The CSMA/CA procedure is described in a later subsection. The coordinator can also configure the superframe structure to include a contention free period. This option allows to meet QoS requirements by allocating a number of guaranteed time slots (GTSs) to applications that require specific low latency or throughput values. All contention-based communications must have been completed before the start of the CFP. Such periods can last longer than one superframe slot, and are allocated to devices that are allowed transmit without collision problems during their GTS. GTS management is performed by the PAN coordinator. It maintains information about the number of GTS periods allocated, their length and position within the superframe, as well as information concerning which node can use each slot. A device willing to be assigned a CFP slot must request it to the coordinator using a command frame that shall include the main parameters to reconfigure the superframe. Upon reception of the request message, the PAN coordinator sends an acknowledgment frame and determines if the requested reserved slots can be allocated in the superframe structure. When the allocation is confirmed, devices are notified using information fields included in the beacon frames, with all the required parameters that allow the 17

32 3.3. The Medium Access Control Layer (MAC) non-coordinator devices to know the format of the upcoming superframe period as well as details on their GTS allocation. The coordinator can also decide to define some of the superframe slots as inactive. No transmissions are performed in such periods, and devices may enter in sleep mode until next beacon frame is received. This way power consumption can be decreased in scenarios with low traffic rates, being possible to increase the CAP or the CFP if the coordinator detects higher amounts of packets. The beacon-based operating mode is not compatible with a mesh topology, which clearly reduces the ZigBee capabilities in this kind of systems. Non-beacon enabled mode When the network is configured by the PAN Coordinator to work in a non beacon-enabled mode, the superframe structure and beacon frames are not present in the system. In this case, access to the medium is controlled by the unslotted CSMA/CA mechanism. No power-consumption reduction options are available in this case. The upper layers can arbitrarily order to turn the radio off during some periods, but a MAC protocol is required to achieve an acceptable performance while reducing energy consumption and avoiding collisions in the medium. Given that this is the only available option for mesh-based topologies, the developing of such MAC protocols and introducing them in the stack is an important issue that this thesis focuses on, as will be described in later sections The CSMA/CA mechanism The MAC layer uses the CSMA/CA procedure to determine if the channel is idle for the device to start a transmission. This procedure is based on backoff periods, and must be performed before beginning to transmit. If the channel is detected to be idle, the transmission can be carried out immediately after. Figure 3.6 in next page describes the CSMA/CA mechanism. There are two different versions of this procedure, depending if the network is operating in a beacon-enabled scheme or not. The difference lies in the boundaries of the backoff periods, since in the slotted version they must be aligned with the superframe slot boundaries, while in the unslotted case the backoff periods of each device are independent. Three variables are required to schedule the access to the medium: 18 The number of times that the CSMA/CA algorithm is required to backoff while attempting to access the current channel (NB in Figure 3.6). The contention window length, which defines the number of backoff periods that the channel must be sensed as idle before starting a transmission, and that is only used in the slotted version (CW in figure 3.6). The backoff exponent, defining the number of backoff periods that the device must wait between assessments attempts (BE in Figure 3.6).

33 3. The ZigBee Stack Figure 3.6: The CSMA mechanism [24]. 19

34 3.3. The Medium Access Control Layer (MAC) Additionally, a maximum number of clear channel assessments attempts is defined and stored in an internal variable PAN start, network association and maintenance The MAC layer is also responsible of a number of tasks related with the creation and maintenance of a PAN. A FFD can create a PAN after performing a channel scan to determine a suitable channel to use in the newly created network. After a command from the NWK layer is received, the process begins when the device restarts its parameters to the initial configuration. Afterward, a channel scan is performed, and when a suitable option is found the PHY layer tunes the transceiver to the appropriate frequency and PAN identifier is chosen. The next higher layer is notified of these values, and subsequently starts its operation as coordinator by sending a beacon frame, if this operation mode is selected. This will make neighbor devices aware of the existence of the new network, and they may join it upon request. If a device tries to associate to an existing network a scan provides the joining device information on active networks operating within range. The next higher layer is notified of the network chosen and its parameters, and the MLME issues a command frame requesting the association to the coordinator of the chosen network. When it is received, an acknowledgment frame is automatically generated and transmitted, and the coordinator decides whether the operation can be completed or not. If there are enough resources available, the coordinator indicates the joining device its new network address using an association response command. This special frame is also generated indicating a failure in the process if the PAN coordinator does not have available resources to allow a new device joining the network Transmission and reception of information The transmission of data packets depends of the configuration of the network, specifically if the beacon enabled mode is in use. If the beacon scheme is enabled, a transmitting device must wait for the next slot in the superframe structure and compete for the channel with other surrounding nodes, or use its GTS slot if allocated as described before. If the beacon mode is not enabled, the unslotted CSMA/CA mechanism is performed before transmitting data. Reception of incoming packets can only be accomplished if the transceiver is active and in receive mode when the incoming frame is detected in the channel. A device receives every transmission complying the standard specification that is performed in the tuned channel. There is no way to filter frames that are not destined to the node unless they do not comply the PHY layer conditions to receive a frame (FCS code check) before they are processed in the MAC layer. Therefore, only those frames with the appropriate PAN identifiers and destination address fields are either notified to the next higher layer or considered for managing actions in the MAC layer. All other received frames are discarded. 20

35 3. The ZigBee Stack 3.4 The Network Layer (NWK) Overview The network layer provides functionalities to the MAC layer and an interface to the Application layer. All ZigBee devices must be capable of both joining and leaving a network. Additionally, FFDs must provide the following functionalities implemented in the NWK layer: Start a new network, acting as coordinators and allow new devices join it. Configuration of joining devices, address assignment. Maintain information about neighbor nodes within transmission range. Provide routing capacity enabling multi-hop networks. Route discovery, route maintenance and route repair. Unicast, multicast and broadcast communication. Reliable link between peer NWK entities. The NWK layer provides two services in a similar fashion as the previously described layers. These are the NWK data service, or NLDE, and the NWK management service or NLME. The interface between the application and the MAC layer is performed via the MCPS and the MLME described before. The NLDE and the NLME also include an interface that allow them to interact if the task requires so. The NLME also maintains a database of attributes required to manage the NWK layer of a device denominated Network IB. The attributes are accessed or modified using NLME primitives, and include information about the network parameters and status, as well as specifying some device capacities related with the networking operations Neighbor table The neighbor table of a device contains information of every device within transmission range. It is updated every time a device receives any frame from the corresponding network. An entry exist for each neighboring device, with the following fields: The extended and network addresses of the neighboring device. The device type, and the relationship between the neighbor and the current device.. The link quality indicator. Beacon tracking information. 21

36 3.4. The Network Layer (NWK) Network creation Only a ZigBee FFD with coordinator capabilities can start a new network. This process requires functionalities at different layers, and has partly been described in the MAC layer subsection. Upon request of the next higher layer, the NLME entity commands the start of the procedure by ordering the MAC layer to perform a channel scan. When results of a successful energy scan are received, the NLME determines the ones that are suitable to support the new network, favoring the channels with no networks or the ones with a lower number of detected networks. When a channel has been chosen, a PAN Id value is determined and the MAC layer is notified of the new network configuration. When a confirmation notification is received from the MAC layer, the next higher layer is notified of the status of the network creation process. Subsequently, the coordinator must notify the MAC layer that new devices are allowed to join the network, so that the coordinator accepts incoming frames of devices willing to join Network association This procedure was partly described in the MAC subsection, since part of the functionality is implemented by the lower levels. The procedure for joining a network begins upon request of the next higher layer. The NWK layer requests the MAC layer to perform a channel scan in order to discover operating networks within communication range. Once the MAC layer signals the completion of the scan, the NWK has information on the parameters of the surrounding available networks and the neighboring devices belonging to them. Subsequently, the NWK layer choses one of such networks, and issues a request frame to its coordinator device. The procedure continues as described in the MAC layer description, by issuing association request command frames. If the attempt is successful, the 16-bit logical address assigned to the node in the network is received, and is used in any further transmission. Additionally, parameters in the NIB are updated. If the joining attempt is unsuccessful, the next higher layer is notified and depending on the reasons of the failure different actions are taken. For instance, if there are other possible available parents in the neighbor table the device may attempt to join the network by associating with them. The coordinator device procedure logically represents the other end of the operations described above. When the join requests reach the NWK layer of a potential coordinator, they check if there are enough resources to be allocated for the new child, like available positions in the neighbor table, available network short addresses, etc. If the request is granted, the NLME of the parent device create a new entry for the new child in its neighbor table with the supplied information, and indicate the successful association with the appropriate response frame as described in the MAC subsection. 22

37 3. The ZigBee Stack A shorter procedure is also available for devices willing to re-join the network after having lost connection with it. Furthermore, it is also possible for a parent device to directly associate a device if the 64-bit address of the child is provided Routing ZigBee coordinators and routers must provide the following functionality: Relay data frames on behalf of higher layers or other ZigBee routers to the appropriate destination. Participate in route discovery for subsequent data transmissions, as well as in route repair or maintenance. Maintain routing tables to store information about available routes. The NWK layer maintains a routing table that stores information about different parameters of already discovered routes. This table is used to determine what is the next-hop in the path of a multi-hop communication. This table contains the following fields: Destination address (2 bytes): The 16-bit address of the destination device. Status (3 bits): Indicate if the route is active, being discovered or inactive. Control flags (3 bits): Indicate if the route is many-to-one, if a route record is required or if the address represents a group address. Next hop address: The 16-bit address of the next hop on the way to the destination. Additionally, a route discovery table is maintained, which holds different parameters employed in the route discovery procedure. The route discovery table include the following information: Route Request ID (1 byte): Sequence number for a route request command that identifies a route request. Source Address (2 bytes): The 16-bit address of the route request s initiator. Sender Address (2 bytes): The 16-bit address of the device that sent the most recent route discovery request to the present device corresponding to this entry identifier and Source Address. This field is used as next-hop for subsequent reply command frames. Expiration time (2 bytes): Countdown timer indicating the number of milliseconds until the discovery operation expires. 23

38 3.4. The Network Layer (NWK) Routing mechanism When a data frame is received in the NWK layer, either from the next higher layer or from the MAC layer, a procedure to successfully deliver the frame to its final destination is started. The device shall check its routing table for an entry corresponding to the final destination of the frame. If such entry exists, and if the route is marked as active in the status field, the frame is forwarded using the MAC data entity (MCPS) using the Next-hop field of the corresponding field of the routing table as MAC destination address. If the device has a routing table entry corresponding to the routing destination of the frame, but the status field indicates that the route is being discovered, the data frame can be buffered pending for the completion of the route discovery process. Other options include using tree routing in those topologies and network configurations that allow it, or generating a source-routed frame, which includes the addresses of all the different hops until the end node, determined before the transmission by the original sender device. If a device has no routing capacity, or if no routing table entry corresponds to the routing destination of the frame, it is discarded, and the NLDE issues a error notification to the next higher layer. Route discovery The route discovery process is a key element of any network protocol. In ZigBee, a network discovery can be unicast, multicast or many-to-one, depending on the number of devices discovering and being discovered. Basically, the device or devices try to establish a route until a destination address, that can be either the regular short address of a single node, a broadcast address or a multicast group ID. The route discovery process is initiated by a ZigBee router or coordinator NWK layer by request of the next higher layer by specifically issuing a discovery request command. Alternatively, the process can be also started if a frame is generated in the NWK layer or received by the MAC layer with a field indicating that a route should be discovered if the final destination address of the frame is not among the entries of the routing table. If the device has available space in its routing table, a new entry is created with the address to be discovered as destination address, and the status field indicating that discovery is underway. Additionally, a route discovery table entry is created that maintains temporary information about the procedure. Afterward, a route request command frame is generated indicating the final address of the discovery procedure and dispatched using the previously described MAC mechanism. This frame is broadcasted to all nodes within transmission range. When other devices receive the route request command frame, they check if the address being discovered matches their own. If not, they can check if the address is already in their routing table. If so, the discovery frame is forwarded to the 24

39 3. The ZigBee Stack next hop address, and otherwise, it is broadcasted. The intermediate node may attempt to start its own discovery process using the same forwarded frame. This procedure is performed until either the route is successfully discovered or until the route discovery tables timeouts counters expire, signaling a failure in the discovery attempt in the originator device. If the device address matches the one included in the discovery frame, a response is created and sent back to the previous node in the path. The response frame follows the same route that the discovery frame followed, but in the reverse way. Upon reception to an intermediate device, the next hop in the way back to the originator is available in the route discovery table. Intermediate devices that attempted to discover the same route update their routing tables as well. 3.5 The Application Layer (APL) Overview The layer in the top of the stack described by the ZigBee specification is the Application Layer (APL). It consists of several sublayers: the Application Support (APS) sublayer, the ZigBee Device Object (ZDO) and the manufacturer-defined application objects. The APS is responsible for: Maintaining tables for binding, or matching two devices together based on their services. Forwarding messages between bound devices. Address mapping from 64 bit long address mode to 16 bit NWK short addresses. Fragmentation and reassembly of data transport. The APS performs its tasks using two different entities similarly to the lower layers. The Application Support Sub-Layer Data Entity (ASPDE) provide the data service to the Network layer and both the ZDO and the application objects. The Application Support Sub-Layer Management Entity (ASLME) provide a management interface to allow the application to interact with the stack. The ZDO is responsible for: Defining the role of the device within the network (FFD, RFD or PAN Coordinator). Discovering devices on the network and determining the application services they may provide. Initiating and responding to binding requests. Establishing a secure link between network devices. This thesis does not focus in application development or interaction, so this only a brief introduction to the main concepts of the application layer are described. 25

40 3.5. The Application Layer (APL) Application objects and profiles Application objects are hosted in ZigBee devices. Data between them is transmitted using the APSDE. The application objects have an overall control of the whole ZigBee stack functionalities, issuing commands and receiving information as was described in the different lower layers descriptions. ZigBee supports up to 240 application objects, each interfacing on an indexed endpoint. At this point, it is important to consider a node as a platform with several devices and components, with one radio chip among them. Different elements can define their own application objects, and normally they require their own logical communication channel. Individual parts of the nodes are subunits, containing one device description in each subunit. The new level of sub-addressing allow different components to work individually. Each application object also includes information about data attributes they contain. Application profiles are agreement for messages, message formats and processing actions that allow applications to create a distributed application between local installations in different devices. These profiles are a mean to unify different technical solutions with the ZigBee standard Discovery and binding Following a similar procedure as with the NWK case, ZigBee devices can discover each other by issuing query messages that are broadcasted by the lower layers. The discovery can consist of either finding out the long or short address of a specific device. Furthermore, apart from discovering the surrounding devices, applications must also obtain information on what kind of services these nodes can provide. Service discovery can be accomplished by issuing a query for each endpoint on a previously discovered device. Once a device has been discovered, ZigBee allows to create logical links between complementary application devices and endpoints. This concept is denominated Binding. A binding table is implemented with information about this logical link. Binding is always performed after the establishment of a communication link ZDO According to the specification, ZigBee Device Objects is an application which employs resources belonging to the APS and the lower layers to implement functionalities of ZigBee End Devices, ZigBee Routers or ZigBee Coordinators. The ZigBee Device Objects reside in the APL above the APS sublayer. They are responsible for initializing all the stack components according to the specified node type, as well as assembling configuration information from end applications and to manage the network, security issues, etc. 26

41 3. The ZigBee Stack APS The APS sublayer provides an interface between the NWK and APL layers through a set of services that can be used by the ZDO and the manufacturerdefined application objects. It consists of a data entity (APSDE) and a management entity (APSME), similarly to the other layers previously described. The APSDE provides a data service to the network layer and both the ZDO and application objects, allowing the transport of application data units between two or more devices. The APSME provides a management service that allows an application to interact with the rest of the stack. Among other functions, this entity is in charge of matching devices together based on their services and needs (binding), as well as security tasks. 27

42 The Application Layer (APL)

43 Reducing the Energy Consumption of ZigBee with a Power-saving MAC Protocol 4. The Contiki OS and the Tmote Sky Platform Chapter 4 The Contiki OS and the Tmote Sky Platform 4.1 Overview Sensor nodes are generally constrained in memory and computational capacity. The small physical size and the low cost intended for the devices impose a limit that must be taken into account when designing an application. Typical platforms are equipped with a code memory of around 100 kilobytes and a RAM memory of 20 kilobytes approximately. These limitations motivate the development of specifically oriented operating systems for this kind of hardware. A widespread operating system specially designed for these constrained devices is TinyOS [26]. Other options include SensorWave [9] and Mantis [8]. Contiki [18] is one of such operating systems. It has been developed by Adam Dunkels and the members of Networked Embedded Systems Group at the Swedish Institute of Computer Science. Its characteristics make Contiki an appropriate choice as operating system for a WSN. Contiki was chosen to implement a ZigBee stack version and its modifications to improve the energy consumption of nodes in mesh networks. A number of hardware platforms designed for researchers and developers exist in the market. The Moteiv Tmote Sky [6] provide a versatile solution thanks to its USB port and higher memory capacities compared to other platforms. It uses the CC2420 radio chip, compliant with the IEEE specification. The stack developed was implemented and tested in Tmote Sky nodes. This chapter provides background information about the Contiki OS and its components, as well as a brief general description of the Tmote Sky platform. 29

44 4.2 The Contiki Operating System 4.2. The Contiki Operating System General description and characteristics Contiki is a lightweight operating system designed for memory-constrained devices. It is highly portable and has been successfully implemented in a number of platforms. Contiki main features a multitasking kernel based in events. A pure multithreading system can be implemented using optional libraries. Contiki uses protothreads, a novel programming technique that allows linear coding in event driven systems. The use of a special communication stack called uip allows TCP/IP networking. There are other components included, like a simple web browser, a personal web server and a telnet client. Contiki is implemented in the C language and has been ported to the MSP430 microcontroller and the Tmote Sky platform, among many other systems. The typical Contiki configuration requires 2 kilobytes of RAM and 40 kilobytes of ROM. Contiki also includes two complete communication stacks called Rime and uip. Rime is a light weight stack that provides a wide range of communication options. uip is a RFC compliant TCP/IP stack that enables Internet connectivity in sensor nodes System architecture There are two different parts in any Contiki system: The core and the loaded programs. The core includes the Contiki kernel, the program loader, a selection of common support libraries and a communication stack consisting of drivers and functions that allow to handle the communication hardware. The core is compiled and stored in the nodes, while the application program is loaded in the system using the program loader, part of the Contiki core. This can be achieved using the communication stacks implemented or storing it previously in any available external memory device The Contiki kernel The Contiki kernel is event-driven, allowing different applications to be loaded and unloaded at runtime, and provides multitask functionalities. The event driven solution provides concurrency for systems that do not have enough resources to implement a complete multi-threaded model. In the multi-threaded model, each thread requires a stack with an unknown maximum size, and therefore it is not a suitable option for memory-constrained systems. In an event driven system, different processes are implemented as event handlers. All processes running in the system share the same memory stack, with the 30

45 4. The Contiki OS and the Tmote Sky Platform concurrency problems that this represents. Generally, a complex state-machine model is required that is a source of a number of programming difficulties [35]. Contiki implements a solution that can be considered a hybrid of the two models previously exposed. The kernel is event-driven, but preemtive multi-thread can be implemented as an optional library. The kernel consists of an event scheduler that sends events to processes running in the system and that periodically call processes handlers. Once a process handler has been called, the kernel cannot preempt it so it must either run until completion or release the control to the scheduler. Events in Contiki can be synchronous or asynchronous. The main difference lies in when the event is processed: The asynchronous ones are queued by the kernel, meaning that they are processed some time later, while synchronous ones cause the target process to be immediately scheduled. Once the target process has finished processing, control is returned to the posting process. Another inter-process mechanism is provided by the kernel. A process can be polled, meaning that a high-priority event is scheduled. These are normally used by processes that operate closer to the hardware. The event scheduling is performed at a single level, and given the nature of the processes they cannot preempt each other. Instead, they can only be preempted by interrupts, which can be hardware or software based. Interrupts are never disabled in order to support real-time applications. An event is not allowed to be posted by an interrupt handler to avoid concurrency problems in the event handler. A single memory stack is shared by all processes being executed. This is related with the use of protothreads, described later in this section Services A service is defined in Contiki as a process that provides functionalities to other processes. Services can be dynamically replaced at run-time and therefore are dynamically linked. Components like communication protocols, sensor applications, etc, are typical examples of services. This kind of processes are managed by an special layer right below the kernel. This service layer maintains information of running services that can be used to identify and manage them. Services consist of a process implementing them, and a function table with pointers to functions that are called depending on the situation. An application program calls a service through a interface stub. Such stub is linked with the application, using the service layer to find the service process. Once the appropriate service process has been found, its process ID is stored and used for future requests concerning that service. The application program is not aware that a service is being called. Since services can be replaced at real-time operation, and given that the parameter used as the identifier is the corresponding process ID value, if such service process is replaced the new one must retain the process ID of the previously 31

46 4.2. The Contiki Operating System implemented one. This is accomplished by a special mechanism implemented in the kernel Protothreads Contiki implements its processes using a lightweight stackless thread-like construct called Protothreads [19]. Protothreads have been a major contribution to the embedded systems programming techniques and they are currently in use in other kinds of systems and environment apart from Contiki. The main objective is to implement a simple, sequential flow of control avoiding state machines. In a regular event-driven system, blocking a process in order to release control to other parts of the system is done by manually splitting the running function in two parts; one for the code before the blocking call and one for the code after the blocking call. Programming in such conditions is difficult since the use of most simple programming structures becomes complicated. Additionally, it is normally not trivial to determine at which point should the function call resume the execution, specially for complex applications involving many possible situations. Protothreads provide linear code execution for event-driven systems implemented in C. Threads supported by this construct allow a blocking context in eventdriven systems, without the memory requirements of regular multithread stacks. Protothreads are very lightweight, since all protothreads run on the same stack. Context switching between different protothreads is performed using stack rewind. A protothread runs within a single C function. Despite other functions can be called from within the protothread, no block operations can be done in the called functions. Instead, a separate protothread must be spawned if a function must include a blocking procedure. The fact that protothreads do not require their own memory stack suppose the main advantage of this kind of structure. Depending on the architecture, a protothread only require between two and twelve bytes of state memory. Unfortunately, it is also the main source of problems of protothreads, since local variables do not preserve their value after a protothread is blocked, so working with local variables requires additional attention. Summarizing, protothreads can be considered as a combination of events and threads. Protothread can block and wait like threads, and are stackless like events. Implementation Protothreads are implemented in Contiki with a number of macros and functions that define the basic functionalities of this kind of structure. Specific source code and details can be found in the Contiki reference manual [16]. Here a basic description is given of the most relevant ones. The statement PT INIT initializes the protothread. This initialization must be done before starting to execute the protothread. A protothread must have 32

47 4. The Contiki OS and the Tmote Sky Platform a beginning and an end point, which are declared with the PT BEGIN and PT END statements. These define the protothread environment, and all other related statement must be placed between both points. The possibility of having a mechanism to block the protothreads in a controlled way is implemented by the PT WAIT statements. There are three different options that bring more flexibility to the programming process: PT WAIT UNTIL, PT WAIT WHILE, and PT WAIT THREAD. All these three statements block the protothread, checking if either a while or until condition is true, or waiting for a child protothread to finish its execution. If the condition checked is true the first time the protothread reaches the blocking statement, it continues to execute without interruption. Otherwise it is checked every time that the protothread is invoked. Additionally, it is possible to unconditionally block a protothread using the PT YIELD statement. Using the PT SPAWN statement, a new child protothread is generated. The calling protothread blocks until the child exits. This is specially useful when designing a hierarchical structure of functions calls at different levels with blocking requirements. It is also possible to set a timer that determines when a protothread is called with PT SCHEDULE. Local continuations must be taken into account in order to fully understand the fundaments and behavior of protothreads. These are the low-level mechanism that actually implement the protothread mechanism. They are similar to ordinary continuations [32] but they do not capture the program stack. Instead, only the state of execution inside a function is captured. This include the point in the function where the program is being executed and the values of local variables. A protothread consists of a function and a single local continuation, which is set before a blocking statement. When the protothread is invoked again, the protothread resumes the local continuation, and subsequently, either the blocking condition is checked or the protothread function is resumed normally from that point. Processes and protothreads Processes in Contiki are implemented as protothreads running on top of the OS kernel. The protothread is invoked whenever an event is posted to the process. The event might represent a timer event, an alarm by the sensor unit in the node, the indication of an incoming packet, etc. User designed processes can block and wait for incoming events using the process blocking statements. When using a process, similar statements than the ones defined for protothreads must be used. PROCESS BEGIN, PROCESS END, PROCESS INIT, PRO- CESS WAIT UNTIL, PROCESS WAIT WHILE, PROCESS YIELD and PRO- CESS PT SPAWN perform basically the same operations than the protothread versions. There are also additional functions available to the user to post events of different priorities. Posting an event to a process requires 3 arguments: The target process descriptor, an event identifier and a pointer that can be used to pass additional information such as parameters to the process being called. 33

48 4.2. The Contiki Operating System Communication stacks Contiki includes two communication stacks: uip and Rime. uip is a RFCcompliant TCP/IP stack with reduced functionalities that allow Contiki to communicate over the Internet. Rime is a lightweight stack that allows to define a number of functionalities combining different primitives. A brief summary of both stacks is presented next. Rime Rime [17] is a lightweight layered communication stack specifically designed for sensor networks. The main idea is to include very thin layers to simplify the implementation complexity of communication protocols. Rime is organized in layers as shown in Figure 4.1. In Rime, layers are extremely simple, and each one of them performs actions related to a concrete task. This means that the layers are simple and light, and each one requires very small headers, allowing also the possibility to reuse code in different levels. Figure 4.1: The Rime stack [17]. The lowest level in Rime is called anonymous best-effort broadcast, abc. This provides a 16-bit channel without addressing. Addressing is added by upper layers. The sender identity header field (including the address) is added by the identified sender best-effort broadcast layer, ibc, while the receive header information is added by the unicast abstraction layer, uc, and so on with each desired functionality of the implemented protocol. By combining different elements of the Rime stack, messages with different formats can be formed depending on the functionalities that are going to be implemented. Each layer adds a functionality, and the designer of the application must decide which one to include and the exact format and options that will be used. One achievement of Rime is that if the implemented protocol is adapted to the simple layer structure, and since Rime is part of the Contiki core part, loadable programs are smaller. Rime also reduces the memory consumed by using a single buffer for both outgoing and incoming packets. If data queuing is required, layers requiring so can copy the data to dynamically allocated queue buffers. 34

49 4. The Contiki OS and the Tmote Sky Platform The code size of the layers is very small, and varies from 100 bytes of the ibc layer (identified sender best-effort broadcast) to 226 of the suc and ruc (stubborn and reliable unicast). Dunkels [17] describes some evaluation figures that prove the advantages of using a low weight communication stack included in the operating system core like Rime. uip The uip TCP/IP [15] communication stack was designed to allow small, memoryconstrained 8-bit micro-controller based systems to communicate using the TCP/IP suite. TCP/IP is one of the most used standard for communications, including its usage in the Internet, it is clear the great advance that its implementation means for the WSN field. Enabling connectivity with Internet allows a number of new applications and the improvement of existing ones. The uip stack is designed to comply only the absolute minimal set of features needed for a TCP/IP basic communication. Such a reduced version is compatible with most existing sensor nodes in the market. uip includes reduced versions of IP, ICMP, UDP and TCP protocols. Contiki uses uip as one of the core communication stacks. uip is implemented as a main loop that checks if there are incoming packets or if a periodic timeout has expired. If a packet has arrived, a function that handles it is invoked. The function starts different actions depending on the data carried by the incoming packet. Periodic timeouts are used to launch TCP mechanisms depending on timers. Different timers are set depending on the actions performed by the node and the requirements of the incoming packets. If as a result of the timer expiration data packets are produced, they are sent using the regular uip mechanism. Given that the RAM memory is very reduced in the platforms where uip is intended to be used, some TCP/IP mechanisms are not applied. Only one buffer for both incoming and outgoing packets is implemented. Information stored in such buffer cannot be overwritten by new incoming or outgoing packets, so they must be processed immediately or stored in secondary buffers, depending on the memory capacity of the specific platforms. uip is a reduced version of the TCP/IP suite, and therefore not all the functionalities are included, although it complies the minimum requirements of the standard. Complete information about the functionalities not implemented can be found in the uip reference documents [15]. 4.3 The Tmote Sky Platform The Tmote Sky is an ultra low power wireless module for use in sensor networks, monitoring applications, and rapid application prototyping. By using industry standards, integrating humidity, temperature, and light sensors, and providing flexible interconnection with peripherals, Tmote Sky enables a wide range of mesh network applications. It features the MSP430 microcontroller from Texas 35

50 4.3. The Tmote Sky Platform Instruments and the CC2420 radio chip from Chipcon. Tmote Sky node. Figure 4.2 shows a Figure 4.2: The Tmote Sky node Microprocessor The Tmote Sky features the Texas Instruments MSP430 F1611 microcontroller. The MSP430 is a low-power unit with 10kbyes of RAM, 48kbytes of flash memory and 128 bytes of information storage. The processor consumes very low current for both active and sleep modes, allowing a battery lifetime of years without replacing batteries. The internal digitally controlled oscillator allows frequencies of up to 8Mhz. Additionally, a 32kHz eternal oscillator is available. A number of ports are available for different input and output signals, including monitoring of the battery voltage, UART, timers, etc. Communication with host computer is performed using the USB port included in the board. Tmote Sky nodes appear as COM ports, and if multiple nodes are connected to the same computer, each one receives a different port identifier. The COM port can be read by an application, allowing the host computer to obtain output information generated by the node. More detailed information is available in the MSP430 documentation available in the MSP430 data sheet [4] Radio Tmote Sky nodes use the Chipcon CC2420 radio chip [5]. It is a IEEE compliant radio and provide the PHY layer and some MAC hardware-implemented functionalities. Reliable communication is achieved thanks to a high sensitivity value. The radio also features some low-consumption attributes that make it a very popular choice in many different node models based in the IEEE specification. 36