Wireless Inverted Pendulum using IEEE Protocol

Transcription

1 Wireless Inverted Pendulum using IEEE Protocol AITOR HERNÁNDEZ Master s Degree Project Stockholm, Sweden April 4, 2011 XR-EE-RT 2010:020

2

3 Wireless Inverted Penduluml using IEEE Protocol AITOR HERNÁNDEZ Master s Thesis Supervisors: José Araújo, Pangun Park and Prof. Karl.H. Johansson Examiner: Asst. Prof. Carlo Fischione XR-EE-RT 2010:020

4

5 iii Abstract Considering the potential benefits offered by Wireless Sensor Networks (WSNs), they have been becoming an interesting technology for process, manufacturing, and industrial control and Smart Grid applications. These applications motivate many companies, industrial communities and academy to focus and research in this direction. The IEEE is the standard proposed to be use in low-power communication of which WSN is part. Even though there are many implementations of the standard for the selected operating system, TinyOS, they are not fully validated or fully implemented. Moreover, in spite of the existence of previous studies using the protocol, there is no sufficient analysis of the performance of this standard. In this thesis, a comparison between the two main implementations is done through the experiments to validate the feasibility of the implementations. Because of the fact that the selected implementation does not have the Guaranteed Time Slots (GTSs) mechanism developed, in this thesis are provided all the mechanisms necessary to transmit during the Contention-Free Period (CFP): allocation, expiration, reallocation and deallocation. Hence, a IEEE implementation is provided with a comprehensive evaluation with which the behaviour is proven. The implementation is validated in terms of packet delivery rate and delay for different network configurations and different parameters. Owing to no practical results for the use of this protocol in control applications, a inverted pendulum process is introduced to show the benefits in wireless process control by using the IEEE in a real-time control loop process. The extensive experimental results show that packets losses and delays are the essential factors to guarantee the stability of the system. Furthermore, we also demonstrate and analyse the benefits of using this protocol in a Home Smart Grid setup.

6 iv Acknowledgements First of all, I would like to thank my supervisor José Araújo to give me the possibility to work on this thesis. Mention that without his help, the inverted pendulum would not success as it does. Thanks for the discussions, problems, and solutions provided. Moreover, I thank my supervisor Pangun Park for his support and guidance with the IEEE , without him, the understanding and validation of this protocol it would not be easy. I want to thank my colleague João Faria for the improvements made on the pendulum and Micke for the board that he made for us. Thanks for all the people at Automatic Control and special thanks for the people at the eighth floor. Thanks to Aziz, George, Hans, Håkan and João for the pleasant discussions and moments during the breaks and meals. Thanks to all the friends I met here in Sweden. In special for my corridor mates at DKV with whom I spent my first months in Stockholm. I take advantage of this opportunity to thank my family and friends in Spain for supporting me along these years. Above all, I would like to thank my parents,carlos and Encarna, and sister María for the continuous presence and encourage me to struggle on through the years. They support me to come and make this thesis at KTH. An special thank, for all my friends who gave me greats moments, Alex, Alberto, Dani, Felipe, Ismael, Miguel, Ruben and the rest who give me such a greats moments.

7 Contents Contents v Acronyms 1 1 Wireless sensors networks Introduction Motivating applications Process control Smart Grid technology Challenges of WSN Outline IEEE Protocol General description Components of the IEEE WPAN Architecture Network topologies Functional overview Physical sublayer specification MAC sublayer specification MAC sublayer service specification MAC functional description Platforms and tools Hardware platforms Motes IEEE /Zigbee protocol analyser Operating systems Contiki TinyOS IEEE software implementation OpenZB - IPP Hurray TKN v

8 vi CONTENTS TKN15.4 vs OpenZB GTS implementation Overview Implementation status Interoperability Directory Structure GTS Decomposition Reference model Radio Arbitration Timing issues Components Utilities Discussion Future work Performance evaluation of IEEE System model Network scenarios Beacon-enabled vs non beacon-enabled Beacon-enabled and MAC parameters Beacon-enabled with hybrid MAC Validation with theoretical model Future work Control applications Inverted pendulum control system Platform and hardware Control over WSN Problem formulation Performance evaluation Home smart grid Introduction Performance evaluation Conclusion and future work Conclusion Future work References 115 Appendices 119 A Inverted pendulum 121

9 Acronyms ACK Acknowledge packet. 16, 17, 21, 23 25, 28, 35, 40, 41, 78, 80, 85, 109, 111 ADC Analog-Digital converter. 30, 101 AI Analog input. 100, 101 AO Analog output. 101 BE Backoff Exponent. 22, 23 BI Beacon Interval. 20 BO Beacon Order. 20, 40, 43, 60, 62, 72, 74, 85 CA Collision Avoidance. 111 CAP Contention Access Period. 15, 21, 27, 44, 67, 69, 72, 74, 78, 80, 84 86, 97, 111, 114 CCA Clear Channel Assessment. 17, 23, 45, 80, 81, 107 CFP Contention-Free Period. iii, 15, 21, 50, 51, 62, 63, 66, 67, 69, 71, 72, 74, 78, 80, 84 86, 97, 113, 114 CISTER Research Centre in Real-Time Computing Systems. 38 CRC cyclic redundancy check. 17 CSMA Carrier Sense Multiple Access. 96, , 114 CSMA-CA Carrier Sense Multiple Access with Collision Avoidance , 21 23, 39, 41 44, 78, 80, 81, 84, 96, 97, 105, 111 CW Contention Window (length). 22, 23 DAC Digital-Analog converter. 30, 101 DAQ Data Acquisition. 96, 97, 100, 101, 124 DC Direct current. 99 DMA Direct memory access. 30 DSSS direct-sequence spread spectrum. 17 1

10 2 ACRONYMS ED Energy detection. 17 EOM Equations of Motion. 97, 99 ETSI European Telecommunication Standards Institute. 55 FCS Frame Check Sequence. 124 FFD Full-Function Device. 12, 14, 110 GTS Guaranteed Time Slot. iii, 9, 15, 18, 19, 21, 25 28, 42, 49 53, 55, 56, 59, 62, 63, 65 69, 71 74, 77 80, 84 86, 97, 113, 114 IP Internet Protocol. 34 IPP Polytechnic Institute of Porto. 38, 39, 113 ISEP Research Unit based at the School of Engineering. 38, 39 ISM Industrial Scientific Medical. 18, 86 ISO International Organization for Standardization. 55 ITU-T International Telecommunication Union - Telecommunication Standardization Sector. 17 LED Light-Emitting Diode. 32 LQ linear-quadratic. 104 LQI Link Quality Indication. 17 LQR linear-quadratic regulator. 99, 101, 105, 122, 123 LR-WPAN low rate WPAN. 12, 14, 17 MAC Medium Access Control. 9, 12, 16 19, 21, 23 26, 40, 42, 56, 62, 77, 83 86, 114 MCPS MAC Common Part Sublayer. 19 MCPS-SAP MAC Common Part Sublayer - Service Access Point. 18, 19 MCU microcontroller. 31, 43, 44, 114 MHR MAC Header. 32 MLME MAC Sublayer Management Entity. 19, MLME-SAP MAC Sublayer Management Entity - Service Access Point. 18, 20 NB Number of backoff periods. 22, 23 NI National Instruments. 100, 101

11 ACRONYMS 3 O-QPSK orthogonal - quadrature phase-shift keying. 18 OPAM Operational Amplifier. 123 OS operating system. 9, 29, 32, 35, 36, 39 OSI open systems interconnection. 12 P2P peer-to-peer. 13, 14, 16 PAN Personal Area Network , 17, 18, 21, 25 28, 32, 36, 39, 43, 44, 52, 63, 73, 78, 96, 110 PC personal computer. 13, 97, 100, 110, 122 PD-SAP PHY Data - Service Access Point. 19 PHY Physical Layer. 12, 17 19, 21, 23, 24 PIB PAN Information Database. 64, 68 PLME-SAP PHY Sublayer Management Entity - Service Access Point. 19 QoS Quality of Service. 7 RAM random access memory. 30, 33 RF Radio Frequency. 12 RFD Reduced-Function Device , 19, 110 ROM read-only memory. 33, 43 RSSI Received Signal Strength Indication. 87 SAP Service Access Point. 18 SD Superframe Duration. 21 SICS Swedish Institute of Computer Science. 34, 39 SMA SubMiniature version A. 31 SO Superframe Order. 21, 60, 62, SPI Serial Peripheral Interface. 100 SSCS service-specific convergence sublayer. 19 SSSUP Scuola Superiore Sant Anna di Studi Univertari e di Perfezionamento. 39 TCP Transport Control Protocol. 123 TDMA Time Division Multiple Access. 110, 111 TEP TinyOS Extension Proposal. 33, 37 USB Universal Serial Bus , 122, 123 WLAN Wireless Local Area Network. 6 WPAN Wireless Personal Area Network. 6 WPC wireless process control. iii, 9, 96, 108, 114

12 4 ACRONYMS WSN Wireless Sensor Network. iii, 5 9, 29, 30, 32, 33, 38, 81

13 Chapter 1 Wireless sensors networks 1.1 Introduction In the late 1800 s, the first successful wireless radio transmission was accomplished by the Italian Guglielmo Marconi. It was by September 1895 when Marconi had already built the equipment that transmitted electrical signals through the air. He opened the door towards a world that we are still discovering. For most people the significance of wireless technologies comes from the ability to provide communication services like voice/data without any restriction on movement. The mobility and the no necessity of being wired connected is perceived as the main characteristics of the wireless technologies. However, it gives us the possibility of scaling a network, communicate between two points which could be impossible with wires, and the independence of being always connected. With the success of wireless technologies in consumer electronics, standard wireless technologies are envisioned for the deployment in industrial environments as well. [45, 46] Wireless technologies have also been identified for industrial and factory automation, distributed control systems, automotive systems and other kinds of networked embedded systems with high mobility, reduced cabling and installation cost, reduce danger of breaking cables, and less hassle with connectors. Nevertheless, these applications must often satisfy tight real-time and reliability requirements otherwise non-productivity, loss of time, money or even physical damage can result. In wired environments, timing and reliability are well attended by bus systems and protocols, which are a mature technology. When wireless links are included, reliability and timing requirements are slightly more difficult to achieve, due to the characteristics of the radio channels. WSNs have recently received increased attention in the industrial applications, fact that led many companies, industrial communities and academy to focus and 5

14 6 CHAPTER 1. WIRELESS SENSORS NETWORKS u t τ ca A Process x t S y t Wired network Wireless network τ2 ca τ1 sc τ ca 1 u t Controller y t τ sc τ sc 2 PC Figure 1.1: Inverted pendulum diagram research in this direction. WSNs support much lower data rates and much smaller transmit powers than other kind of Wireless Local Area Network (WLAN). This Wireless Personal Area Network (WPAN), due to a limited energy budget sensors should spend most of their time in a sleep state in which they are not able to transmit or receive data. Even though these properties do not favour the adoption of sensor networks in tight control loops, we apply a protocol for WSN in a control loop where a high sample rate is needed in comparison with monitoring tasks. This implementation will help us understanding the challenges of performing real-time control over wireless which is not well studied. 1.2 Motivating applications WSN can be applied in two realistic scenarios, for Smart Grid technology and process control, like home smart grid to monitor the consumption of different devices, or for controlling the air conditioning system. We could find other applications of WSN in [1, 27, 34] Process control The main purpose of this thesis is to show how wireless technology can become a key in process control using the IEEE In comparison to traditional wired sensors, wireless sensors provide advantages in the manufacturing environment, such as an increased flexibility for locating and reconfiguring sensors, elimination of wires in potentially hazardous locations, and easier maintenance. Figure 1.1 shows the block diagram of our inverted pendulum. Our research

15 1.3. CHALLENGES OF WSN 7 Figure 1.2: Home Smart Grid deployment in a kitchen. Source: [33] presented on this thesis has been based on the demonstration that it was possible to control a tight timing control process using the IEEE The full description about the process is shown in Section Smart Grid technology One interesting application of WSNs is to build a smart-grid infrastructure. WSNs are an integral part of the automated metering infrastructure and smart-grid plans. Smart Grid technology is designed to allow customers and utility companies to collaboratively manage power generation, delivery and storage. One case of study has been the research made in [33]. The research involves the programming and deployment of several motes in a kitchen. It shows an example of how it could work in a home or wherever we want to apply this smart-grid technology. It shows also how it is possible to analyse and detect patterns and user profiles. Figure 1.2 shows an example of a deployment in a kitchen. Mention that huge number of motes placed in a reduced space could be difficult and hard to deploy in case of using wires. This example was tested with the standard protocol IEEE [12]. In Section 6.2, we show the results on the communication analysis for this application. 1.3 Challenges of WSN The protocol design for industrial control applications with WSNs encounters much more challenges than the protocol design for traditional communications networks, where, mainly, considering a good Quality of Service (QoS) with a good throughput

16 8 CHAPTER 1. WIRELESS SENSORS NETWORKS is enough. [27, 44] However, in our case of study appears more challenges to deal with: Reliability: Sensor readings must be sent/received with a high probability of success, because missing sensors readings could be critical. However, despite the possibility of maximizing the reliability it is necessary a trade-off between reliability and the network energy consumption. Delay: Sensor information must reach the sink within some deadline. Time delay is very important since it influences on performance and stability of an industrial control system. Even if an outdated packet is received it will not be generally useful for a control application. This plays an important role in our control applications (see Chapter 6). Energy Efficiency: The lack of battery replacement, which is essential for affordable WSN deployment, requires energy-efficient operations. Scalability The protocol/application should be able to adapt to variation in the network size, for example, size variations caused by the addition of new nodes. This characteristic is one of the biggest advantages of low-power wireless nodes. All of these challenges are based on theoretical aspects to take into account when it is needed to design a protocol or evaluate possible applications. As a consequence, we can see how the design of such networked systems has to take into account a large number of factors that ensure correct behaviour. Starting from these requirements, it is important to design an efficient communication protocol that satisfies the constraints and optimizes the energy consumption. On the other hand, once we have designed a good protocol, then the challenges for the implementation appear. Below we show some of the special requirements to take into account once we want to work with a real deployment with WSN [38, 14]: Limited resources: Motes have very limited physical resources, due to the goals of small size, low cost and a low power consumption. The motes that we use (TelosB/TmoteSky [7, 41]) only have 48k ROM and a microprocessor of 8MHz. Adaptation: The network operation should adapt to application requirement changes, time-varying wireless channels, and variations of the network topology. For instance, the set of application requirements may change dynamically and the communication protocol must adapt its parameters to satisfy the specific requests of the control actions.

17 1.4. OUTLINE Outline This thesis shows the steps and progress to someone who wants to use a device for wireless process control (WPC). From an external observer of a system (who does not know anything about sensors network and process control) it is easy to detect two characteristics that the system has to satisfy: a low number of data losses and a high determinism for the arrival packets. Once the characteristics and limitations of the system are known, it is obvious the research of a platform that offers us durability and the expansion of possibility to wide functionalities. At this point some questions appear: Which platform is the most suitable for our application? Is there any operating system already designed, or it is better to use a dedicated system? Which operating system (OS)? Which dedicated system? First of all, in Chapter 2 we focus on a summary of the protocol that is going to be used and analysed along the thesis, the IEEE [12, 26]. We find a brief description of the standard utilities, primitives and configuration. It does not intend to be a reference and wide explication of the protocol, it is just for a quick review and make this thesis more understandable in some points. In Chapter 3, we get the answer for the previous questions. First we present some devices available to use in WSN, and other hardware necessary to analyse the communication protocol. After that, we show a list of OSs that could run in our sensors and we present our choice. Moreover we discuss which is the best IEEE implementation for the selected OS. The performance evaluation of the IEEE depends on how good is the implementation and how close it is to the standard. Furthermore, we analyse the precision and accuracy of the timers with the different implementations. Chapter 4 intends to be a reference guide for the GTS implementation. As a complement of the TKN15.4 documentation [15], we provide a complete guide with the current state of the implementation. This guide consists, first of all, a brief introduction and overview with the current state of the implementation, then we show a decomposition of the components and comments about the radio arbitration, timing issues, and utilities. At the end of this chapter, we show some discussions fields for future work, in order to give an advice on the next steps towards a full implementation. Chapter 5 shows a performance evaluation of the selected implementation. We analyse reliability and delay for the selected implementation and for our GTS. We shows these characteristics comparing with different configurations. First of all, we compare the two transmission modes that the IEEE has. Moreover, we analyse the influence of the Medium Access Control (MAC) parameters in order to characterize which are the critical parameters that influences in the reliability and delay. Once we have the TKN15.4 validated, we focus on the analysis of transmis-

18 10 CHAPTER 1. WIRELESS SENSORS NETWORKS sions using our GTS implementation. To end up, we show a brief validation where we compare some graphs with theoretical model, and some of the future work that would be made in order to improve and get an extensive performance evaluation. Finally, Chapter 6 shows some applications where this protocol is applied to provide more benefits. An inverted pendulum process where the sensing is done through wireless and [33] a home smart grid. More projects related to this protocol in our lab could be found in [24].

19 Chapter 2 IEEE Protocol In this chapter, we show a brief description of the IEEE to facilitate the understanding of this thesis. The main features of this standard are network flexibility, low cost, very low power consumption and low data rate in a ad-hod self-organizing network among inexpensive fixed, portable and moving devices. It has been developed for applications with relaxed throughput requirements which can not handle the power consumption of heavy wireless protocol stacks. 11

20 12 CHAPTER 2. IEEE PROTOCOL 2.1 General description Components of the IEEE WPAN The most basic component in IEEE is the device. A device can be a Full-Function Device (FFD) or Reduced-Function Device (RFD). A network shall include at least one FFD, operating as a Personal Area Network (PAN) coordinator. The FFD can operate in three modes: PAN coordinator, coordinator or device. An RFD is intended for applications that are extremely simple and do not need to send large amounts of data. An FFD can talk to RFDs or FFDs while RFDs can only talk to an FFDs Architecture The IEEE architecture is defined in terms of a number of blocks in order to simplify the standard. These blocks are called layers. Each layer is responsible for one part of the standard and offer services to the higher layers. The layout of the blocks is based on the open systems interconnection (OSI) seven-layer model. Low rate WPAN (LR-WPAN) device comprises a Physical Layer (PHY), which contains the Radio Frequency (RF) transceiver along with its low-level control mechanism, and a MAC sublayer that provides access to the physical channel for all types of transfer. Figure 2.1 shows a graphical representation of these blocks. Figure 2.1: LR-WPAN device architecture Source: [26]

21 2.1. GENERAL DESCRIPTION Network topologies A combination of different components could generate 3 types of topologies that this standard supports. Figure 2.2 shows these combinations. Star Mesh PAN ID2 PAN coordinator Full Function Device (FFD) Reduced Function Device (RFD) Cluster Tree PAN ID1 PAN ID3 Figure 2.2: Topology models Star topology The communication is established between devices and a single central PAN coordinator. Applications that benefit from this topology include home automation, personal computer (PC) peripherals, toys and games. All the experiments and simulations in this thesis are based on this topology, with one PAN coordinator and several RFD. Mesh topology (peer-to-peer (P2P) topology) There is also one PAN coordinator. In contrast to star topology, any device can communicate with any other device as long as they are in range of one another. Applications such as industrial control and environmental monitoring, asset and inventory tracking would benefit from such a topology.

22 14 CHAPTER 2. IEEE PROTOCOL Cluster-tree topology It is a special case of a P2P network in which most devices are FFDs and RFD may connect to a cluster-tree network as a leave node at the end of a branch. Any of the FFD can act as a coordinator and provide synchronization services to other devices and coordinators. However, only one of these coordinators is the PAN coordinator Functional overview A brief overview of the general functions of a LR-WPAN is given in this section and includes information on the superframe structure, the data transfer model, the frame structure, improving probability of successful delivery and power consumption considerations. We skip the security services because it is out of the scope of this thesis Superframe structure This standard allows the optional use of a superframe structure. The format of the superframe is defined by the coordinator, it is divided into 16 equally sized plots. Optionally, the superframe can have an active and an inactive portion, shown in Figure 2.4. During the inactive portion, the coordinator and all the devices may enter a low-power mode. Beacon frames Active Contention Access Period (CAP) (a) Superframe without Inactive period time Beacon frames Active Inactive (b) Superframe with Inactive period Figure 2.3: Superframe Structure time

23 2.1. GENERAL DESCRIPTION 15 The beacons are used to synchronize the attached devices, to identify the PAN, and to describe the structure of the superframes. Any device wishing to communicate during the Contention Access Period (CAP) competes with other devices using a slotted Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA) mechanism. Moreover, the PAN may dedicate portions of the active superframe for GTSs. The GTSs form the CFP, which always appears at the end of the active superframe starting at a slot boundary immediately following the CAP. Beacon frames Contention Access Period (CAP) Contention Free Period (CFP) Figure 2.4: Superframe Structure with CFP time Data transfer model There are three types of data transfer. The mechanism for each transfer type depend on whether the network supports the transmission of beacons. A beacon-enabled PAN is used in networks that either require synchronization. If the network does not need synchronization can elect not to use the beacon for normal transfers. 1. Data transfer to a coordinator (a) To coordinator in a beaconenabled PAN (b) To coordinator in a non beaconenabled PAN Figure 2.5: Communication to a coordinator

24 16 CHAPTER 2. IEEE PROTOCOL Figure 2.5 shows the communication from a device to a coordinator for slotted and unslotted CSMA-CA. The transmission can be done when the device has a packet ready to send. It does not need to wait any kind of instruction, like in the following case. 2. Data transfer from a coordinator (a) From coordinator in a beaconenabled PAN (b) From coordinator in a non beacon-enabled PAN Figure 2.6: Communication from a coordinator Figure 2.6 shows the sequence for the communication from coordinator to device. As far as the device does not have the radio chip enabled for reception all the time, is needed a special mechanism, that allows the device to know when it has to enable the reception. 3. Peer-to-peer data transfers In a P2P, every device may communicate with every other device in its radio sphere of influence. The device can simply transmit its data using unslotted CSMA-CA Frame structure The frame structure depends on the protocol layer which add to the structure with layer-specific headers and footers. This standard defines four frame structures: Beacon frame Used by a coordinator to transmit beacons and set the network configuration Data frame Used for all the transfers data Acknowledge packet (ACK) frame Used for conforming successful frame reception MAC command frame Used for handling all MAC peer entity control transfers

25 2.2. PHYSICAL SUBLAYER SPECIFICATION Improving probability of successful delivery The IEEE LR-WPAN employs various mechanisms to improve the probability of successful data transmission. These mechanism are: CSMA-CA LR-WPAN uses two types of channel access mechanisms: unslotted CSMA-CA for non beacon-enabled PANs and slotted CSMA-CA for beaconenabled PANs. These mechanisms minimize the probability of packet collisions. A detailed explanation is shown in Section Frame acknowledgement A successful reception and validation of a data or MAC command frame is optionally confirmed with an ACK. If the sender does not receive an ACK after some period, it assumes that the transmission was unsuccessful and retries the frame transmission. Data verification In order to detect bit errors, an FCS mechanism employing a 16-bit International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) cyclic redundancy check (CRC) is used to detect errors in every frame Power consumption considerations The protocol has been developed to favour battery-powered devices. However, in certain applications, some of these devices could potentially be powered. 2.2 Physical sublayer specification The PHY is responsible for the following task: Activation and deactivation of the radio transceiver Energy detection (ED) within the current channel Link Quality Indication (LQI) for received packets Clear Channel Assessment (CCA) for CSMA-CA Channel frequency selection Data transmission and reception The standard defines four PHYs, but in our case, we only use one of those, because our radio chip is limited to this one. A 2450 MHz DSSS PHY employing

26 18 CHAPTER 2. IEEE PROTOCOL Binary data Bit-to-symbol 4bits/symbol Symbol-to-Chip 32 chips PN sequence/symbol O-QPSK modulator Modulated signal Figure 2.7: Modulation and spreading functions O-QPSK modulation. This band is part of the Industrial Scientific Medical (ISM) band, which could be interfered with devices operating in the same frequency. Our PHY operates in 2450 MHz, actually use a range between MHz, providing a bit rate of 250 kb/s with a symbol rate of 62.5 ksymbols/s (4 bits/symbol). Figure 2.7 shows the functional block diagram. 2.3 MAC sublayer specification This clause specifies the MAC sublayer of this standard. The MAC sublayer handles all access to the physical radio channel and is responsible for the following tasks: Generating network beacons if the device is a coordinator Synchronizing to network beacons Supporting PAN association and disassociation Supporting device security Employing the CSMA-CA mechanism for channel access Handling and maintaining the GTS mechanism Providing a reliable link between two peer MAC entities MAC sublayer service specification The MAC sublayer provides two services, accessed through two Service Access Points (SAPs): The MAC data service, accessed through the MAC Common Part Sublayer - Service Access Point (MCPS-SAP) The MAC management service, accessed through the MAC Sublayer Management Entity - Service Access Point (MLME-SAP)

27 2.3. MAC SUBLAYER SPECIFICATION 19 These two services provide the interface between the service-specific convergence sublayer (SSCS) and the PHY, via the PHY Data - Service Access Point (PD- SAP) and PHY Sublayer Management Entity - Service Access Point (PLME-SAP) interfaces. In addition to these external interfaces, an implicit interface also exists between the MAC Sublayer Management Entity (MLME) and the MAC Common Part Sublayer (MCPS) that allows the MLME to use the MAC data service. MCPS-SAP MLME-SAP MAC Common Part Sublayer MLME MAC PIB PD-SAP PLME-SAP Figure 2.8: MAC sublayer reference model Below, the main primitives of MLME and MCPS are shown with a brief description MCPS primitives Table 2.1 lists the primitives supported by the MCPS-SAP. Note that primitives marked with a diamond ( ) are optional for an RFD. MCPS-SAP primitive request confirm indication MCPS-DATA MCPS-PURGE Table 2.1: MCPS-SAP primitives MAC functional description In this subclause, we provide a brief description of the MAC functionality. Section describes the following two mechanism for channel access: contention based and contention free. It describes the superframe structure and the CSMA-CA mechanism. Section shows the transmission scenarios. And Section shows the mechanism for allocating and deallocating a GTS.

28 20 CHAPTER 2. IEEE PROTOCOL MLME-SAP primitive request indication response confirm MLME-ASSOCIATE MLME-DISASSOCIATE MLME-BEACON-NOTIFY MLME-GET MLME-GTS * * MLME-ORPHAN MLME-RESET MLME-RX-ENABLE * * MLME-SCAN MLME-COMM-STATUS MLME-SET MLME-START MLME-SYNC * MLME-SYNC-LOSS MLME-POLL Table 2.2: MLME-SAP primitives MAC channel access This subclause describes the mechanism for accessing the physical radio channel. Superframe structure The structure of the superframe is described by the values of macbeaconorder and macsuperframeorder. macbeaconorder describes the interval at which the coordinator shall transmit its beacon frames. The value macbeaconorder, Beacon Order (BO) and the Beacon Interval (BI), are related as follows, BI = abasesuperframeduration 2 BO = abaseslotduration anumsuperframeslots 2 BO (2.1)

29 2.3. MAC SUBLAYER SPECIFICATION 21 where 0 BO 14. The value macsuperframeorder, Superframe Order (SO) and the Superframe Duration (SD), are related as follows, SD = abasesuperframeduration 2 SO = abaseslotduration anumsuperframeslots 2 SO (2.2) where 0 SO BO 14. The active portion of each superframe shall be divided into anumsuperframeslots equally spaced slots of duration abaseslotduration 2 SO and is composed of three parts: a beacon, a CAP and a CFP. All frames, except ACK and any data frame that quickly follow the ACK of a data request command, transmitted in the CAP shall use a slotted CSMA-CA mechanism to access the channel. Transmission within the CFP shall not use a CSMA-CA mechanism to access the channel. CAP CFP Beacon GTS GTS Inactive SD = abasesuperframeduration 2 SO BI = abasesuperframeduration 2 BO Figure 2.9: An example of the superframe structure An example of a superframe structure is shown in Figure 2.9. In this case the BO > SO, and we have two GTS allocated. CSMA-CA In slotted CSMA-CA, the backoff period boundaries of every device in the PAN shall be aligned with the superframe slot boundaries of the PAN coordinator. The MAC sublayer shall ensure that the PHY starts all of its transmissions on the boundary of a backoff period. On the other hand, in unslotted CSMA-CA, the backoff periods of one device are not related in time to the backoff periods of any other device in the PAN.

30 22 CHAPTER 2. IEEE PROTOCOL Figure 2.10: CSMA-CA algorithm Source: [26] Each device shall maintain three variables for each transmission attempt: NB, CW and BE. NB is the number of times the CSMA-CA algorithm was required to backoff while attempting the current transmission. Contention Window (length) (CW) is the contention window length, defining the number of backoff periods that need to be clear of channel activity before the transmission can commence. Note that the CW variable is only used for slotted CSMA-CA. Backoff Exponent (BE) is

31 2.3. MAC SUBLAYER SPECIFICATION 23 the backoff exponent, which is related to how many backoff periods a device shall wait before attempting to assess a channel. Figure 2.10 illustrates the step of the CSMA-CA algorithm. When using slotted CSMA-CA, the MAC sublayer shall first initialize Number of backoff periods (NB), CW, and BE and then locate the boundary of the next backoff period, step (1). For unslotted CSMA-CA, the MAC sublayer shall initialize NB and BE and the proceed directly to step (2). The MAC sublayer shall delay for a random number of complete backoff period in the range 0 to 2 BE 1, step (2), and then request that the PHY perform a CCA, step (3). In a slotted CSMA-CA system, the CCA shall start on a backoff period boundary. In an unslotted CSMA-CA system, the CCA shall start immediately. If channel is assessed to be busy, step (4), the MAC sublayer shall increment both NB and BE by one, ensuring that BE shall be no more than macmaxbe. The MAC sublayer in a slotted CSMA-CA system shall also reset CW to two. If the value of NB is less than or equal to macmaxcsmabackoffs, the CSMA-CA algorithm shall return to step (2). If the value of NB is greater than macmaxcsmabackoffs, the CSMA-CA algorithm shall terminate with a channel access failure status. If the channel is assessed to be idle, step (5), the MAC sublayer in a slotted CSMA-CA system shall ensure that the CW has expired before commencing transmission. To do this, the MAC sublayer shall first decrement CW by one and then determine whether it is equal to zero. If it is not equal to zero, the CSMA-CA algorithmic shall return to step (3). If it is equal to zero, the MAC sublayer shall begin transmission of the frame on the boundary of the next backoff period. If the channel is assessed to be idle in an unslotted CSMA-CA system, the MAC sublayer shall begin transmission of the frame immediately Transmission scenarios Due to imperfect nature of the radio medium, a transmitted frame does not always reach its intended destination. Successful data transmission (1) The originator MAC sublayer transmits the data frame to the recipient via the PHY data service. In waiting for an ACK, the originator MAC sublayer starts a timer that will expire after macackwaitduration symbols. (2) The recipient MAC sublayer receives the data frame, send an ACK back to the originator, and passes the data frame to the next higher layer. (3) The originator MAC sublayer receives the ACK from the recipient before its timer expires and the disables and reset the timers. The originator MAC sublayer issues a success confirmation to the next higher layer.

32 24 CHAPTER 2. IEEE PROTOCOL Originator next higher layer Originator MLME Recipient MLME Recipient next higher layer (1) MLME-DATA.request Data frame Acknowledgement MLME-DATA.indication (2) (3) MLME-DATA.confirm Figure 2.11: Successful data transmission Lost data frame (1) The originator MAC sublayer transmits the data frame to the recipient via the PHY data service. The reception MAC sublayer does not receive the data frame and so does not respond with an ACK. The timer of the originator expires before an ACK is received; therefore, the data transfer has failed. If the transmission was direct, the originator retransmit the data, and this entire sequence may be repeated up to a maximum of macmaxframeretries times. If the transmission was indirect, the data frame will remain in the transaction queue until either another request for the data is received and correctly ACK or until mac- TransactionPersistenceTime is reached. (2) The MLME_DATA.confirm is signalled if the transmission has failed or success. Originator next higher layer Originator MLME Recipient MLME Recipient next higher layer (1) (2) MLME-DATA.confirm MLME-DATA.request Data Retry Data frame transmission upv to amax- FrameRetries time Figure 2.12: Lost data frame Lost acknowledgement frame (1) The originator MAC sublayer transmits the data frame to the recipient via the PHY data service. (2) The recipient MAC sublayer receives the data frame, sends an ACK back to the originator, and passes the data frame to the next higher layer. (3) The originator MAC does not receive

33 2.3. MAC SUBLAYER SPECIFICATION 25 the ACK frame, and its timer expires. Therefore the data transfer has failed. If the transmission was direct, the originator retransmit the data frame. Originator next higher layer Originator MLME Recipient MLME Recipient next higher layer (1) MLME-DATA.request Data (3) MLME-DATA.confirm Retry Data frame transmission upv to amax- FrameRetries time Acknowledgement MLME-DATA.indication (2) Figure 2.13: Lost acknowledgement frame GTS allocation and management A GTS allows a device to operate on the channel within a portion of the superframe that is dedicated exclusively to that device and it shall be used only for communications between the PAN coordinator and a device associated with the PAN. A single GTS may extend over one or more superframe slots. The PAN coordinator may allocate up to seven GTSs at the same time, if there is sufficient capacity in the superframe. GTS allocation Figure 2.14 show the mechanism to allocate a GTS. (1) A device is instructed to request the allocation of a new GTS through the MLME-GTS.request primitive with the GTS characteristics set according to the requirements of the intended application. (2) On reception of a GTS request command indicating a GTS allocation request, the PAN coordinator shall first check if there is available capacity in the current superframe. (3) On reception of the ACK to the GTS request command, the device shall continue to track beacons and wait for at most agtsdespersistencetime superframes. (4) If the GTS descriptor is received, the MLME shall notify the next layer of the success with MLME-GTS.indication with SUCCESS status, if not, it shall indicates the failure with MLME-GTS.indication, indicating the NO_DATA status. GTS usage When the MAC sublayer of a device that is not the PAN coordinator receives an MCPS-DATA.request primitive with TxOptions parameter indicating a GTS transmission, it shall determine whether it has a valid transmit GTS. If a valid GTS is found, the MAC sublayer shall transmit the data during the GTS.

34 26 CHAPTER 2. IEEE PROTOCOL Device next higher layer Device MLME PAN coordinator MLME PAN coordinator next higher layer (1) MLME-GTS.request GTS request MLME-GTS.confirm Acknowledgement MLME-GTS.indication (2) Wait for at most agtsdescpersistencetime (3) MLME-GTS.indication Beacon with GTS descriptor Figure 2.14: MLME-GTS allocation mechanism It the device has any receive GTSs, the MAC sublayer of the device shall ensure that the receiver is enabled at a time prior to the start of the GTS and for the duration of the GTS. When the MAC sublayer of the PAN coordinator receives an MCPS.DATA.request primitive with TxOptions parameter indicating a GTS transmission, it shall determine whether it has a valid received GTS corresponding to the device with the requested destination address. If a valid GTS is found, the PAN coordinator shall defer the transmission until the start of the receive GTS. For all allocated transmit GTSs (relative to the device), the MAC sublayer of the PAN coordinator shall ensure that its receiver is enabled at a time prior to the start and for the duration of each GTS. GTS deallocation The GTS deallocation could be initiated either by the coordinator or the device. Figure 2.15 show the mechanism to deallocate a GTS initiated by the device. (1) A device is instructed to request the deallocation of an existing GTS through the MLME-GTS.request primitive using the characteristics of the GTS it wishes to deallocate. From this point onward the GTS to be deallocated shall not be used by the device, and its stored characteristics shall be reset. (2) On the reception of a GTS request command with the Characteristics Type subfield of the GTS Characteristics field set to zero (GTS deallocation), the PAN coordinator shall attempt to deallocate the GTS. If the GTS characteristics contained in the GTS request command match the characteristics of a know GTS, the MLME of the PAN coordinator shall deallocate the specified GTS and notify the higher layer. GTS deallocation may be initiated by PAN coordinator due to a deallocation

35 2.3. MAC SUBLAYER SPECIFICATION 27 Device next higher layer Device MLME PAN coordinator MLME PAN coordinator next higher layer (1) MLME-GTS.request GTS request (3) MLME-GTS.confirm Acknowledgement MLME-GTS.indication (2) Figure 2.15: MLME-GTS deallocation mechanism Device next higher layer Device MLME PAN coordinator MLME PAN coordinator next higher layer MLME-GTS.request (1) (3) MLME-GTS.indication Beacon with GTS descriptor set to zero MLME-GTS.indication (2) Figure 2.16: MLME-GTS deallocation mechanism initiated by PAN coordinator request from the next higher layer, the expiration of the GTSs, or maintenance required to maintain the minimum CAP length. Figure 2.16 shows the GTS deallocation mechanism initiated by the next higher layer of the PAN coordinator. (1) The MLME shall receive the MLME-GTS.request primitive with the GTS Characteristics set to zero and the length and direction subfields set according to the characteristics of the GTS to deallocate. (2) The notification is achieved when the MLME issues the MLME-GTS.indication primitive. (3) In case of any deallocation initiated by PAN coordinator, it shall deallocate the GTS and add a GTS descriptor into its beacon frame corresponding to the deallocated GTS, but with its starting slot set to zero. GTS reallocation The deallocation of a GTS may result in the superframe becoming fragmented. For example, Figure 2.17 shows three stages of a superframe with allocated GTSs. In Figure 2.17a, five GTSs are allocated starting at slots, 15, 13, 12, 11 and 9, respectively. If GTS 2 is now deallocated (Figure 2.17b, there will be a gap in the superframe during which nothing can happen. To solve this, GTS 3 to 5 will have to be shifted to fill the gap, thus increasing the size of the CAP,

36 28 CHAPTER 2. IEEE PROTOCOL CAP GTS 5 GTS 4 GTS 3 GTS 2 GTS (a) CAP GTS 5 GTS 4 GTS 3 GTS 2 GTS (b) CAP GTS 5 GTS 4 GTS 3 GTS (c) Figure 2.17: CFP defragmentation on GTS reallocations Figure 2.17c. GTS expiration The MLME of the PAN coordinator shall attempt to detect when a device has stopped using a GTS using the following rules: For a transmit GTS, it shall assume that a device is no longer using its GTS if a data frame is not received from the device in the GTS at least every 2 n superframes, where n is defined below. For receive GTSs, it shall assume that a device is no longer using its GTS if an ACK is not received from the device at least every 2 n superframes, where n is defined below. If the data frames sent in the GTS do not require ACK, the MLME of the PAN coordinator will not able to detect whether a device is using its receive GTS. The value of n is defined as follows: { 2 8 macbeaconorder 0 macbeaconorder 8 n = 1 9 macbeaconorder 14

37 Chapter 3 Platforms and tools In this chapter we show the platforms and tools used along this thesis. It intends to answer the questions someone who wants to start with a real WSN implementation need to know. Which platform is the most suitable for our application? Is there any operating system already designed? Which OS is the most suitable? Which is the best implementation for the IEEE ? After these steps, we focus in the platforms we use. For the hardware we select the motes: (a) Tmote Sky (b) Crossbow Telosb and protocol analyser, IEEE /Zigbee protocol analyser. For the software platform we choose the TinyOS and the TKN15.4 implementation. 29

38 30 CHAPTER 3. PLATFORMS AND TOOLS 3.1 Hardware platforms Motes Tiny, low-cost and low-power nodes, colloquially referred to as motes, are the devices deployed in the environment to communicate wirelessly to gather and report information about physical phenomena. There are different types and platforms for being used in WSN. The most common devices are TmoteSky, TelosB, MicaZ [8], imote2 [6], etc Tmote Sky Figure 3.1: Tmote Sky mote without battery extension. Source: [7] Tmote Sky [7] is an ultra low power wireless module for use in sensor networks, for monitoring applications, and rapid application prototyping. Tmote Sky leverages industry standards like USB and IEEE to interoperate seamlessly with other devices. Features 250kbps 2.4GHz IEEE Chipcon Wireless Transceiver [5] Interoperability with other IEEE devices 8MHz Texas Instruments MSP430 microcontroller (10k RAM, 48k Flash) Integrated ADC, DAC, Supply Voltage Supervisor, and DMA Controller Integrated onboard antenna with 50m range indoors / 125m range outdoors Integrated Humidity, Temperature, and Light sensors Ultra low current consumption Fast wakeup from sleep (<6 µs) Hardware link-layer encryption and authentication

39 3.1. HARDWARE PLATFORMS 31 Programming and data collection via USB 16-pin expansion support and optional SMA antenna connector TinyOS support It is important to remark the interoperability they have with the IEEE devices is coming from the use of the CC2420 radio chip with an external crystal of 16 MHz, which assure that the transmitted frames are standard compliant. But in Section 3.3 we see that it is not true for the MAC implementation sublayer Crossbow Telosb Crossbow s TelosB mote is an open source platform designed to enable cutting-edge experimentation for the research community. The telosb bundles all the essentials for lab studies into a single platform including: USB programming capability, an IEEE radio with integrated antenna, a low-power microcontroller (MCU) with extended memory and an optional sensor suite. The TelosB platform was developed and published to the research community by UC Berkeley. This platform delivers low power consumption allowing for long battery life as well as fast wakeup from sleep state. Though the telosb is an uncertified radio platform, it is fully compatible with the open-source TinyOS distribution. Features The Telosb motes have the same hardware than Tmote Sky. (a) Telosb mote with battery extension (b) Functional block diagram Figure 3.2: Telosb mote and functional block diagram Source: [41]

40 32 CHAPTER 3. PLATFORMS AND TOOLS IEEE /Zigbee protocol analyser To be able to analyse the characteristics of our applications, it is needed to have a device acting in a promiscuous mode and sniffing all the packets which are transmitted through the air. The selected board is the Development Kit which includes the CC2420B Evaluation Board and a CC2420EM Evaluation Modules [18]. The Evaluation Module contains the CC2420 chip and required external components. The Evaluation Board serves as motherboard for the Evaluation Modules. The Evaluation Board provides a USB port, a serial port, buttons, LEDs, voltage regulator, configuration jumpers and connectors to make it easy to interface the CC2420 with the SmartRF Studio software Application tools With the CC2420DK, it is provided a Windows applications in order to see graphically, and in real-time, the packets. The program is called SmartRF Packet Sniffer [18]. The data coming from this program is saved in a file with PSD extension. The file contains all the packet information, but it is a binary file. In order be able to analyse the information with another program, i.e. Matlab, we use a PHP script which converts the binary file in a ASCII file where the columns are the fields of the packet, length, frame control, source address, destination address, etc. Figure 3.3 shows the packet format in the PSD file. Note that in our case, the packet format explained in the manual [18] is not the packet format that we have with our packets. The packet format can vary depending on the addressing mode we use in the packets. For example the TKN15.4 implementation, by default, uses IntraPAN which reduces the MAC Header (MHR) to 11 bytes, by assuming that PAN identification is the same for source and destination. In the openzb Hurray implementation, the IntraPAN is not implemented and they have a MHR of 13 bytes. Figure 3.4 shows a packet sniffer screenshot from the IEEE ZigBee protocol, when we were running a performance test for the GTS implementation. Table 3.1 shows the equivalent parsed PSD file for the packets in the Figure 3.4. Note that all the fields are only valid for data packets. 3.2 Operating systems The purpose of this section is to show different available OS designed for WSN. Table 3.2 summarizes the present OSs available for the selected motes. It also

41 3.2. OPERATING SYSTEMS 33 (a) Packet format in PSD file Source: [18] 128 bytes n 2 s Spare Payload RSSI, LQI, correlation Destination address Source address PAN Sequence number Frame control Length Timestamp (b) Packet format in PSD file in our case Figure 3.3: Packet format in PSD file. User manual vs Received packet shows the last updated date. The two active development projects are TinyOS and Contiki. We select TinyOS due to the difference in the learning curve in both cases. TinyOS provides a huge documentation and has a large active community, ready to solve any problem. It has applications, tutorials, TEP that make it easy to start working with TinyOS even though it uses a not common programming language (nesc). In case of Contiki, it is hard to find tutorials and it lacks documentation and implementation of hardware drivers for the TmoteSky/Telosb Contiki Contiki [11] is an open source, highly portable, multi-tasking operating system for memory-efficient networked embedded systems and WSN. It is designed for microcontrollers with small amounts of memory. A typical Contiki configuration is 2 kb of random access memory (RAM) and 40 kb of read-only memory (ROM). Contiki is developed by a group of developers from industry and academia lead

42 34 CHAPTER 3. PLATFORMS AND TOOLS Figure 3.4: Packet sniffer screenshot from the IEEE ZigBee protocols. by Adam Dunkels from the Swedish Institute of Computer Science (SICS). The Contiki team currently has sixteen members from SICS, SAP AG, Cisco, Atmel, NewAE and TU Münich Features [11] Low-power Radio Communication Contiki provides both full IP networking and low-power radio communication mechanisms. For communication within wireless sensor network, Contiki uses the Rime low-power radio networking stack. Network Interaction Interaction with a network of Contiki sensors can be achieved with a Web browser, a text-based shell interface, or dedicated software that stores and displays collected sensor data. The text-based shell interface is inspired by the Unix command shell but provides special commands for sensor network interaction and sensing. Power-efficiency To provide a long sensor network lifetime, it is crucial to control and reduce the power consumption of each sensor node. Contiki provides

43 3.2. OPERATING SYSTEMS 35 Frame format Packet Timestamps Length FC Seq. PAN Dest. Src RSSI* LQI* type [µs] [bytes] num. ID ID ID Beacon CMD ACK CMD ACK Data ACK Data ACK Data ACK Table 3.1: Value after parse the PSD file.(1) For beacons, the fields Dest.Id correspond to Src.Id and the Src.Id is the Superframe specification. ; (2) For CMD, the field Dest.Id and Src Id. don t correspond to the real values ; (3) For ACK, as far as ACKs packets don t have any addressing mode, the sniffer copy the values from the previous packet. OS By License Updated Language Contiki [11] TinyOS [43] SOS [23] Mantis [4] SICS (Sweden) UCB, Intel (USA) UCLA (USA) CU Boulder (USA) BSD BSD Modified BSD September 2010 September 2010 November 2008 C nesc C Partially TKN15.4, Hurray, OpenWSN No BSD 2008 C No Table 3.2: Main available OS for tmote/telosb a software-based power profiling mechanism that keeps track of the energy expenditure of each sensor node. On-node Storage: the Coffee File System Contiki provides a flash-based file system, Coffee, for storing data inside the sensor network. Simulators To ease software development and debugging, Contiki provides three simulation environments: the MSPsim emulator, the Cooja cross-layer network simulator, and the netsim process-level simulator. The development process for software for Contiki typically goes through all three simulation stages before the software runs on the target hardware.

44 36 CHAPTER 3. PLATFORMS AND TOOLS Programming Model Contiki is written in the C programming language and consists of an event-driven kernel, on top of which application programs can be dynamically loaded and unloaded at run time. Contiki processes use lightweight protothreads that provide a linear, threadlike programming style on top of the event-driven kernel. In addition to protothreads, Contiki also supports perprocess optional multithreading and interprocess communication using message passing. Contiki provides three types of memory management: regular malloc(), memory block allocation, and a managed memory allocator TinyOS TinyOS [43] is an open source, BSD-licensed operating system designed for lowpower wireless devices, such as those used in sensor networks, ubiquitous computing, PAN, smart buildings, and smart meters. A worldwide community from academia and industry use, develop, and support the operating system as well as its associated tools. TinyOS has a programming model tailored for event-driven applications as well as a very small footprint. TinyOS is developed in nesc, a language for programming structured component-based applications Features [14, 21] Component-based architecture Provides a set of reusable system components. A application connects components using a wiring specification, each application customizes the set of components it uses. Decomposing different OS services into separate components allows unused services to be excluded from the application so it reduces the memory requirements. Task and event-based concurrency Task and events are the two sources of concurrency in TinyOS. Tasks are a deferred computation mechanism, they run to completion and do not preempt each other. [42, TEP 106] [21, Sec 4.4] Events also run to completion, but may preempt the execution of a task or another event.. Events signify either completion of a split-phase operation or an event from the environment. Split-phase operations Because tasks execute non-preemtively, TinyOS has no blocking operation. All long-latency operation are split-phase: operation request and completion are separate functions. [21, Sec 4.1] Commands are typically requested to execute an operation. A typical example of a split-phase operation is a packet send: a component may invoke the send command to initiate the transmission of a radio message, and the communication component signals the senddone event when transmission has completed.

45 3.2. OPERATING SYSTEMS Directory structure Table 3.3 shows the default packages in a TinyOS distribution. [42, TEP 3]: Folder apps/ tos/system/ tos/interfaces/ Description Contain applications with some division by purpose. Applications may contain subdirectories. It is not necessary that packages other than the core break up their components and their interfaces. Core TinyOS components. This directory s components are the ones necessary for TinyOS to actually run. Core TinyOS interfaces, including hardware-independent abstractions. Expected to be heavily used not just by tos/system but throughout all other code. tos/interfaces should only contain interfaces named in TEPs. tos/platforms/ Contains code specific to mote platforms, but chipindependent. tos/chips/ tos/libs/ Contains code specific to particular chips and to chips on particular platforms. Contains interfaces and components which extend the usefulness of TinyOS but which are not viewed as essential to its operation. Libraries will likely contain subdirectories. Table 3.3: TinyOS-2 tree nesc Programming language nesc [14] is an extension to C designed to embody the structuring concepts and execution model of TinyOS. Two of the motivations in designing nesc were to support and evolve TinyOS s programming model and to reimplement TinyOS in the new language. TinyOS has several important features that influenced nesc s design: a component-based architecture, a simple event-based concurrency model, and split-phase operations, shown in sec The basics concepts behind nesc are [13]: Construction vs Composition The construction and the composition are separated. Programs are built out of components, which are assembled ( wired ) to form whole programs. Components define two scopes, one for their specification (containing the names of their interface instances) and one for their implementation.

46 38 CHAPTER 3. PLATFORMS AND TOOLS Components specification Interfaces may be provided or used by the component. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job. Interfaces Interfaces are bidirectional, they specify a set of functions to be implemented by the interface s provider (commands) and a set to be implemented by the interface s user (events). This allows a single interface to represent a complex interaction between components. Components linked Components are statically linked to each other via their interfaces. This increases runtime efficiency, encourages robust design, and allows for better static analysis of program s. Compiler nesc is designed under the expectation that code will be generated by whole-program compilers. This allows for better code generation and analysis. An example of this is nesc s compile-time data race detector, which detects when a variable could be read/written from two different instruction at the same time. Concurrency The concurrency model of nesc is based on run-to-completion tasks, and interrupt handlers which may interrupt tasks and each other. The nesc compiler signals the potential data races caused by the interrupt handlers. 3.3 IEEE software implementation This section shows the different IEEE implementations for TelosB/TmoteSky. To select one of the existence we analyse which one accomplish better the standard requirements. Mainly we focused on delay introduced by the code, precision and accuracy. The protocol design process for WSN in industrial application encounters more challenges than the three showed before, like reliability. Hence, in Chapter 5 the performance evaluation of these characteristics is done for the selected implementation, the TKN OpenZB - IPP Hurray This implementation is done and supported by Research Centre in Real-Time Computing Systems (CISTER), a top-ranked Research Unit based at the School of Engineering (ISEP) of the Polytechnic Institute of Porto (IPP), Portugal. Firstly, the openzb implementation was selected as the main candidate to apply to our project. There were reasons to use it. Mainly they had a good documentation,

47 3.3. IEEE SOFTWARE IMPLEMENTATION 39 a continuous update at the web page [19] and the forum and some recent publications like [10] which re-conform the good feelings with this implementation. Moreover the SICS is working in conjunction with ISEP in the migration to the Contiki OS, and the Scuola Superiore Sant Anna di Studi Univertari e di Perfezionamento (SSSUP) in the migration to the Erika real-time OS. In the following section, we can see the missing functionalities of this implementation, because although it was our first selection, it is not completely implemented, and it has some known bugs Missing functionalities The next list is the one we could find in the IPP Hurray technical report [9]. Unslotted version CSMA-CA Implemented but not fully tested; Extended Address Fields of the Frames IntraPAN Address Fields of the Frames Active and Orphan channel Scan Orphan Devices Frame Reception Conditions Verify Conditions Security Known Issues Below, the list shows the found bugs in the openzb implementation of IPP Hurray. This is a summary of the known bugs. It could be the case that more issues are involved, but as soon as we discarded this implementation, we stopped analysing it. Stop working The main bug detected is that the motes after some time stop working. As an example, a coordinator without any traffic load, stops working after 2100 beacons sent (36 min). Obviously, it is completely impermissible that stops working after 30 min or after days, if it is powered by the power line it has to work forever. Beacon interval The time between beacons is shifted. We cannot be sure about the periodicity and the interoperability of that protocol implementation and other devices. As we know the beacon is the signal needed to align all the network, and the devices use this to reduce the collisions which mean that if they are not align, the CSMA-CA will not work as it is designed: no interoperability, high delay and low reliability.

48 40 CHAPTER 3. PLATFORMS AND TOOLS Number of packets expected value theoretical value real values Time [µs] Figure 3.5: Histogram of the beacon time interval for BO=5 Figure 3.5 shows the histogram of time interval between two consecutive beacons for BO=5. The green dashed line on the left represents the expected value taking into account that the T symbol will never be equal to 16 µs because our oscillator runs at khz and the minimum time that we can 1 achieve is T symbol = = µs using a virtualized timer. The red dashed line in the middle represents the theoretical value of the beacon interval. And comparing these values with the histogram, we can see how far we are from the real value (low accuracy). Moreover we can see different bars close, which shows the low precision of the timer. Table 3.4 shows the beacon interval with the hurray implementation. As we can see these times are not close to the values from T symbol = 16µs. Moreover we can see how the error error column, representing the difference between the theoretical BO and the most occurred value. is increasing with the BO, but the relative error keeps approximately constant. The precision (standard deviation) increases with BO. The conclusion looking at those values is that the beacon interval is not standard compliant and moreover it has not a good accuracy or precision. Acknowledge delay A device that sends a data or MAC command frame with its ACK Request subfield set to one shall wait for at most macackwait- Duration symbols for the corresponding ACK to be received. It is dependent on a combination of constants and PHY attributes [26, Sec ] The corresponding time for our configuration is: macackwaitduration = aunitbackoffperiod + aturnaroundtime + physhrduration + 6 * physymbolsperoctet = *2 + 6*2 = 54 symb =

49 3.3. IEEE SOFTWARE IMPLEMENTATION 41 BO BI BI Error Precision T symbol = 16µs openzb impl. e e r Standard deviation [ms] [ms] [ms] [%] [µs] Total 14.4 % µs Table 3.4: Beacon interval on openzb implementation 864 µs. For this implementation we get the acknowledge within approximately 5ms value far away of the timing requirements of macackwaitduration. ACK rejection Some ACK are rejecting because the mote was in the middle of the CSMA-CA algorithm of the next transmitted packet. This issue, with the previous one, causes that the transmitted mote re-transmit the previous packet although the receiver has been received it properly. Thus, it increases unnecessarily the traffic load on the network. It could be reasonable in a network with lot of nodes, where the interferences are higher but it also happens when just one node is transmitting to the coordinator. Although this implementation could be considered complete, involving the main issues of the IEEE parts. We could not consider it as a useful implementation due to these imperfections and bugs found TKN15.4 This implementation is done by the Technical University Berlin - Telecommunication Networks Group, more specifically by Jan-Hinrich Hauer, one of the main

50 42 CHAPTER 3. PLATFORMS AND TOOLS contributor of the TinyOS development. The first release has been done in March 2009 [15]. It is a platform-independent IEEE MAC implementation. The code is under active development and most of the functionality described in the standard is implemented and tested. The MAC itself is platform-independent, but it requires (1) a suitable radio driver, (2) Alarms/Timers with symbol precision and (3) some platform glue code (defining guard times, etc.). Currently the only supported platforms are Tmote/TelosB and micaz. Another point to remark about this implementation is the wide knowledge of the platform, possibilities and limitations of the motes. One important thing is discussed in the technical report are the timing issues: precision/accuracy requirements and the clock drift. Because the fact that our motes do not have a clock that satisfies the precision/accuracy requirements of the IEEE standard khz, +-40 ppm in the 2.4 GHz band, the timing in beacon-enabled mode is not standard compliant. Instead we have a virtualized clock of kHz = kHz that provides a T symbol = µs. Following, we present the missing functionalities and known issues extracted from the technical report [15] or the README in the implementation code Missing functionalities GTS The implementation of the GTS has been done in this thesis. A detailed explanation can be found in Section 4. Security services As far as at the moment the Wireless Process Control applications are in an early development, the security services have not been implemented. The Home Smart Grids application shown in Section 6.2 could be interesting to apply a security mechanism in order to protect the data coming from the sensors. Indirect transmissions frames are not kept in transaction queue in case CSMA-CA algorithm fails Known Issues The list below corresponds to the known issues that it is necessary to check/solve to have a proper IEEE implementation. This list correspond to the README file from the TKN15.4 code. Invalid timestamps If initial beacon transmission timestamps is invalid, the coordinator stops.

51 3.3. IEEE SOFTWARE IMPLEMENTATION 43 Frame pending Frame pending flags are (need to be) always set in the ACK headers Complex networks Using an incoming and outgoing superframe at the same time has not been tested. A simple star topology has been used. CSMA-CA During an ongoing CSMA-CA transmission incoming frames are ignored Transmissions modes On a beacon-enabled PAN: if the device cannot find the beacon the DATA frame is not transmitted (but it should be transmitted using unslotted CSMA-CA [26, Sec ]. At the moment they are different components, so at compiling time we differentiate which mode we want to use. As soon as, the motes would have more memory resources (ROM), it would be possible. The next list corresponds to the results of our test and analysis done to decide if this implementation is good enough to continue the development with it. Missed beacons When we are running a network with one coordinator and one device, both are completely synchronized and working fine. If we add another device to the network, it starts the application scanning, but once it synchronizes with the coordinator and receives the first beacon, it loses the synchronization and after amaxlostbeacons beacons, it signals the MLME_SYNC_LOSS. It means that the packets in the network influences also the reception of the beacon. Beacon interval The implementation is not completely standard compliant due to hardware limitations. The limitation is coming from our oscillator that runs at khz. We are currently analysing the new MSP430 MCU to use a higher crystal oscillator and overcome this issue. Figure 3.6 shows the histogram of time interval between two consecutive beacons for BO=5. The green dashed line on the left represents the expected value taking into account that the T symbol = µs. The red dashed line represents the theoretical value of the beacon interval. We see that the histogram is quite tight and close to the expected value. Table 3.5 shows the influence of this difference. As we can see on the fifth column (Error). The difference between the value that we get from the mote and the theoretical value is increasing with the BO, but the relative error shown in column six remains constant.

52 44 CHAPTER 3. PLATFORMS AND TOOLS Number of packets 400 real values 350 expected value theoretical value Time [µs] Figure 3.6: Histogram of the beacon time interval for BO= TKN15.4 vs OpenZB We show a comparison between TKN15.4 and openzb IEEE implementation. Due to the use of the same hardware, we expect similar results. But they are different because of the different ways to use/implement the timers. For the hurray implementation, a timer based on the khz (30.5 µs) , that provides a T backoff = 335, 5ηs, but to launch the different events they used counters of 32 bits, increasing considerably the computational time. [21, Sec. 4.5]. Writing or reading a 32 bits number takes more than one instruction. Then it is possible that an interrupt executes in between two instructions, influencing in the timing related with the MAC layer, as superframe duration fired, beacon interval and backoff fired. TKN15.4 implements a virtualized timer that runs at 2* khz using the external crystal of khz, being able to have a more precision clock. It is possible thanks to the digital clock that is internally is used by the MSP430 MCU. Clock drift: This limitation exists in both implementations and it is due to a hardware limitation. It is recognized that clock drift can cause contradictions with the timing requirements of the slotted CSMA-CA in beacon-enabled PANs. During the CAP the slotted CSMA-CA algorithm requires frames to be transmitted on backoff slot boundaries. In conjunction with the listenbefore-send mechanism, slotted transmissions theoretically guarantee that the time interval during which the arrival of one packet implies a collision with another packet is limited to one backoff slot (320 µs). In practice, however, clock drift can result in collisions between frames even if they are transmitted

53 3.3. IEEE SOFTWARE IMPLEMENTATION 45 BO BI BI BI Error Precision T symb = 16µs T symb = 15.26µs impl. BI(16µs)-BI(impl.) Standard deviation [ms] [ms] [ms] [ms] [%] [µs] Total 4.6 % 10.8 µs Table 3.5: Beacon interval on TKN154.4 implementation in subsequent backoff slots and thus practical vulnerability period is larger. [15, Sec ] It is important to take clock drift into consideration for theoretical models because it is a common problem in hardware devices. Figure 3.7 shows when we detect the collision using devices synchronized. During the CAP of a beacon-enabled PAN, nodes will only collide if they are transmitted in the same backoff slots, because otherwise the CCA mechanism will detect a busy channel. In Figure 3.7a, Device A would collide with the frame from Device B because they are transmitting in the same slot boundaries. However, in Figure 3.7b they would not collide because Device B would detect a busy channel and wait for a random unit of backoff periods. Figure 3.8 shows the case where the devices are not synchronized due to the clock drift. In Figure 3.8a, where they are in the same slot, we do not detect a collision. Moreover, in Figure 3.8b, when they are in different slots and they should detect the collisions, Device A would collide with the frame from Device B because of the clock drift. Beacon interval As we have shown before, both implementations are far from the expected and theoretical values for the beacon interval. For this reason, we compared both version, to check which one had the best results. Table 3.6 shows the real value on the second column, and the values gotten

54 46 CHAPTER 3. PLATFORMS AND TOOLS Backoff period boundary Tbackoff=320µs Device A CCA CCA Frame Device B CCA CCA Frame time time (a) Not collision detection Backoff period boundary Tbackoff=320µs Device A CCA CCA Frame Device B CCA CCA CCA time time Random (2 BE -1)unitbakcoffperiods+Backoffperiodboundary (b) Collision detection Figure 3.7: Slotted CSMA-CA. Alignment in the slot boundaries with CW=2 Backoff period boundary Tbackoff=320µs Device A CCA CCA Frame Device B CCA CCA Frame time time (a) Not collision detection Backoff period boundary Tbackoff=320µs Device A CCA CCA Frame time Device B CCA CCA Frame (b) Not collision detection time Figure 3.8: CSMA-CA with misalignment the slot boundaries with CW=2 from the openzb and TKN15.4 implementation as the difference between those values and the expected ones. Even though it is easy to detect which has the best results, on the last row we have the average of the difference for each implementation, which clearly transmit the TKN15.4 has the lowest error.

55 3.3. IEEE SOFTWARE IMPLEMENTATION 47 openzb impl. TKN15.4 impl. BO BI BI Difference BI Difference [ms] [ms] [ms] [ms] [ms] Relative error: 14.4 % 4.7 % Table 3.6: Comparison between beacon interval with openzb and TKN15.4 implementation

56

57 Chapter 4 GTS implementation The GTS mechanism provides to the nodes in the network to transmit packets to the coordinator with high reliability and high determinism. The purpose of this chapter is to provide a reference guide to the GTS implementation described in the IEEE protocol specification [26] in nesc/tinyos based on the TKN15.4 implementation [15]. The GTS implementation was developed on and is available for the TelosB [41]/ Tmote Sky [7] platform. This chapter is a complement to [15], providing the overview and the scheme of the actual IEEE implementation in TinyOS. 49

58 50 CHAPTER 4. GTS IMPLEMENTATION 4.1 Overview Before focusing on the more detailed description of the code and the implementation, we present a brief description about the implemented features and their working procedure Implementation status In this section, some screenshots and figures are shown to verify how our implementation is working. It tries to be the equivalence between the theoretical part shown in Section and the practical implementation. Most of the signals and primitives are impossible to show with these screenshots, they only show the packets transmitted and the superframe structure of each case. The current version of the GTS implementation supports the following IEEE functionalities: GTS allocation, GTS deallocation, GTS usage, GTS expiration and GTS reallocation GTS allocation To allocate a slot in the CFP the device shall send a request to its coordinator and wait for the GTS Descriptor in the beacon payload. Figure 4.1: GTS allocation mechanism Figure 4.1 shows the process of GTS allocation and Figure 4.2 shows the state of the superframe. The steps are described here:

59 4.1. OVERVIEW 51 CAP (1) CAP GTS 2 ID 0x002 [Tx] GTS 1 ID 0x002 0x001 [Tx] (4) CAP GTS 4 ID 0x001 [Rx] GTS 3 ID 0x002 [Rx] GTS 2 ID 0x002 [Tx] GTS 1 ID 0x002 0x001 [Tx] (7) Figure 4.2: Beacon during GTS allocation mechanism 1. In the beacon, the GTS is enabled (Permit = 1) but there is no slot allocated (Len=0) 2. The coordinator, with ID = 0x0000, has received a GTS allocation from the device 0x0001. The request has length = 1, and the direction is for transmission (direction=0). The direction is related to the device. 3. The coordinator has received a GTS allocation from the device 0x0002. The request has length = 1, and the direction is for transmission. 4. In this beacon we have two slots allocated (Len=2). The direction vector are all with 0, indicating slots with transmission direction. In the list we have the description of the slots indicating short address, starting slot and length. 5. The coordinator has received a GTS allocation from the device 0x0002. The request has length = 1, and the direction is for reception (Direction=1). 6. The coordinator has received a GTS allocation from the device 0x0001. The request has length = 1, and the direction is for reception. 7. In this beacon we have four slots allocated (Len=4). The directions vector are two with 0 and two with 1, indicating slots with transmission and reception direction GTS usage Figure 4.3 shows a sniffer dump where five motes are running at the same time, and transmitting during the CFP with their own slot. The coordinator is configured to

60 52 CHAPTER 4. GTS IMPLEMENTATION send packets to the device 0x0001 if the reception slot is requested otherwise it will fail. The devices 0x0001, 0x0003, 0x0004, 0x0005, 0x0006 send allocation request for both directions, but if they do not use it, then it will be deallocated by the expiration mechanism. All the devices and the coordinator write the slot number in the packet payload in order to assure that they are sending the packet in the correct slot. Figure 4.3: GTS data transmission GTS deallocation To deallocate a slot, there are two ways. If the device starts the deallocation it shall send a request to the coordinator indicating the deallocation. Otherwise the GTS deallocation may be initiated by the PAN coordinator due to a deallocation request from the next higher layer. Figure 4.4: GTS deallocation mechanism Figure 4.4 shows the process of GTS deallocation and Figure 4.5 shows the state of the superframe after receiving the actual packet. The steps are described:

61 4.1. OVERVIEW 53 CAP GTS 1 ID 0x002 [Tx] (1) CAP (3) Figure 4.5: Beacon during GTS deallocation mechanism 1. In the beacon we have one slot allocated (Len=1) for the device 0x0001. See state in Figure The coordinator has received a GTS deallocation from the device 0x In the beacon, we don t have any slot allocated GTS reallocation When a slot has been deallocated, it could do a gap in the superframe as Figure 4.7. To solve this, the slots will realign to avoid the existence of those gaps. Figure 4.6: GTS reallocation mechanism To illustrate this mechanism we have deleted the data packets from a sniffer dump because we just want to focus on what happens with the slots and how the coordinator re-organize them in the superframe. Figure 4.6 shows the beacons from the sniffer, and Figure 4.7 shows the evolution of the superframe structure. The steps are: 1. All the slots are allocated for transmission or reception. 2. The slot for reception of the device with id=0x0002, slot 13, has been reallocated. Slots 9, 10, 11, 12 have been shifted. 3. The slot for reception of the device with id=0x0003, slot 11,has been reallocated. Slot 10 has been shifted.

62 54 CHAPTER 4. GTS IMPLEMENTATION CAP GTS 7 ID 0x004 [Tx] GTS 6 ID 0x003 [Rx] GTS 5 ID 0x003 [Tx] GTS 4 ID 0x001 [Rx] GTS 3 ID 0x002 [Rx] GTS 2 ID 0x002 [Tx] GTS 1 ID 0x001 [Tx] (1) CAP GTS 7 ID 0x004 [Tx] GTS 6 ID 0x003 [Rx] GTS 5 ID 0x003 [Tx] GTS 4 ID 0x001 [Rx] GTS 3 ID 0x002 [Rx] GTS 2 ID 0x002 [Tx] GTS 1 ID 0x001 [Tx] CAP GTS 6 ID 0x004 [Tx] GTS 5 ID 0x003 [Rx] GTS 4 ID 0x003 [Tx] GTS 3 ID 0x001 [Rx] GTS 2 ID 0x002 [Tx] GTS 1 ID 0x001 [Tx] (2) CAP GTS 6 ID 0x004 [Tx] GTS 5 ID 0x003 [Rx] GTS 4 ID 0x003 [Tx] GTS 3 ID 0x001 [Rx] GTS 2 ID 0x002 [Tx] GTS 1 ID 0x001 [Tx] CAP GTS 5 ID 0x004 [Tx] GTS 4 ID 0x003 [Tx] GTS 3 ID 0x001 [Rx] GTS 2 ID 0x002 [Tx] GTS 1 ID 0x001 [Tx] (3) Figure 4.7: Beacon during GTS reallocation mechanism GTS expiration Figure 4.8 shows a deallocation mechanism due to an expiration. The steps are described: 1. In the beacon, we see that the device 0x0002 has two slots allocated, one for reception and one for transmission. 2. The device 0x0002 is sending packets to the coordinator 0x0000. This pattern has been repeated for n = macbeaconorder = 8 superframes (macbeaconorder = 6). After that, the coordinator detects that the slot allocated for reception has not been used for n = 8 superframes. 3. The reception slot has been deallocated by the coordinator.

63 4.1. OVERVIEW 55 Figure 4.8: GTS expiration mechanism CAP GTS 2 ID 0x002 [Rx] GTS 1 ID 0x002 [Tx] (1) CAP GTS 1 ID 0x002 [Tx] (3) Figure 4.9: Beacon during GTS expiration mechanism Interoperability The interoperability between devices, is one of the most important characteristics that a device needs. It has to be standard compliant to be able to use it with different devices everywhere. Since approximately 1950s, associations, companies and organizations, like IEEE, European Telecommunication Standards Institute (ETSI), International Organization for Standardization (ISO),etc. have worked to achieve that. One of the utilities that we use to analyse and debug our implementation is the IEEE /Zigbee protocol analyser from Texas Instruments as we explained in Section but although this board only sniffs IEEE packets, it does not mean the implementation is fully standard compliant. Another important test is the interoperability between motes with the TKN15.4 implementation and other IEEE standard compliant devices. They shall be able to communicate each other without problems because the previous TKN15.4 and the GTS addition are done with a very strict and careful standard document tracking.

64 56 CHAPTER 4. GTS IMPLEMENTATION Directory Structure Within the TinyOS 2 module the TKN15.4 MAC implementation is located basically in the tinyos-2.x/tos/lib/mac/tkn154 directory. The directory includes additional subdirectories for the interface definitions and the placeholder components. Moreover, the location of platform specific code is in another directory. Table 4.1 shows an overview of all the directories involved. Content Directory in the TinyOS-2 Tree TKN15.4 MAC Implementation components tinyos-2.x/tos/lib/mac/tkn154 interfaces tinyos-2.x/tos/lib/mac/tkn154/interfaces placeholder components tinyos-2.x/tos/lib/mac/tkn154/dummies test applications tinyos-2.x/apps/test/tkn154 Platform specific code for TelosB configuration files tinyos-2.x/tos/platforms/telosb/mac/tkn154 modified timer subsystem tinyos-2.x/tos/platforms/telosb/mac/tkn154 CC2420 radio driver tinyos-2.x/tos/chips/cc2420_tkn154 Table 4.1: TKN15.4 directories in the TinyOS-2 tree [15] As we can see, the directory structure is equal to default TKN15.4. The GTS implementation is placed where the rest of the components, interfaces and dummies are. 4.2 GTS Decomposition In this section the specific components of the GTS implementation are described. First of all an architecture overview of TKN15.4 is shown. After that, a reference model, radio arbitration and timing issues are shown as well. Then, the GTS components are described. Finally the GTS mechanism shown in Section is verified with our implementation Reference model Figure 4.10 shows an architectural overview of TKN15.4, its main components and the interfaces that are used to exchange MAC frames between components. While this figure abstracts from the majority of interfaces and some configuration components, it illustrates one important aspect, namely, how access to the platform specific radio driver (PHY) in the MAC components.

65 4.2. GTS DECOMPOSITION 57 MLME-SAP MCPS-SAP AssociateP DisassociateP DataP IndirectTxP PollP Coord- RealignmentP CfpTransmitP FrameTx FrameRx PibP CoordBroadcastP DispatchQueueP RxEnableP DispatchCfpQueueP Beacon- TransmitP Beacon- SynchronizeP Dispatch[Un]- SlottedCsmaP Promiscuous- ModeP ScanP Coord/Device Cfp Radio[Tx/Rx/Off] [Un]SlottedCsmaCa RadioControlP SimpleTransfer ArbiterP RadioTx [Un]SlottedCsmaCa RadioRx RadioOff EnergyDetection AlarmTimer Radio Driver/ PHY System Clock Figure 4.10: TKN15.4 architecture: components are represented by rounded boxes, interfaces by connection lines. The radio driver and symbol clock components are external to TKN15.4 On the lowest level (dark gray boxes), the RadioControlP component manages the access to the radio: with the help of an extended TinyOS 2.x arbiter component it controls which of the components on the level above is allowed to access the radio at what point in time Radio Arbitration The radio arbitration mechanism is used to coordinate the activities of the components on this level so that they do not overlap in time: typically a component is active only while it has exclusive access to the radio resource. It then performs a certain task and afterwards either releases the resource or passes it on to some other

66 58 CHAPTER 4. GTS IMPLEMENTATION component. Figure 4.11 explain how the radio resource is transferred and which components can manage it. The use of a TinyOS resource arbiter avoids inconsistencies in the radio driver state machine and is in line with the standard TinyOS 2.x resource usage model: before a component may access a resource it must first issue a request; once it is signalled the granted() event by the arbiter the component can use the resource exclusively; and after usage, the resource must be released. TKN15.4 extends this model by allowing a component that owns the radio resource to dynamically transfer the ownership to a specific other component. 5. transferto() 3. transferto() 4. transferto() Beacon- SynchronizeP Dispatch SlottedCsmaP DeviceCfpP 2. request() 2. granted() Radio[Tx/Rx/Off]] SimpleTransfer- ArbiterP RadioControlP (a) Device 6. transferto() 3. transferto() 4. transferto() 5. transferto() Beacon- TransmitP CoordBroadcastP Dispatch SlottedCsmaP CoordCfp 2. request() 2. granted() Radio[Tx/Rx/Off]] SimpleTransfer- ArbiterP RadioControlP (b) Coordinator Figure 4.11: Transferring the radio token between the components responsible for an incoming/outgoing superframe. The commands request(), transferto() and the granted() event are part of the TransferableResource interface.

67 4.2. GTS DECOMPOSITION Timing issues On this section, we analysed some timing issues and problems that the GTS implementation involves. Before focusing on the different issues, we have to keep in mind the environment and timing where we are going to run the GTS. Considering Table 3.5, we know that the TKN15.4 implementation uses T symbol = µs instead of T symbol = 16µs, so the time slot duration varies from the standard. Table 4.2 shows the values. From now on, when we talk about the implementation we refer to T symbol = µs and the conversion between symbol units and time is: Duration[µs] = Duration[symbols] T symbol µs = Duration[symbols] symbols Theoretical Implementation BO BI Time Slot BI Time Slot [symbol] [symbol] [symbol] [ms] [symbol] Table 4.2: Beacon interval and Time slot duration on TKN154.4 implementation Timers and Alarms Figure 4.12 shows the timers and alarm involved in the GTS implementation and needed for the smooth running.

68 60 CHAPTER 4. GTS IMPLEMENTATION CAP GTS 2 ID 0x002 [Rx] GTS 1 ID 0x002 [Tx] Legend BeaconSynchronizeP DispatchSlottedCsmaP CfpTransmitP TrackAlarm CapEndAlarm CfpSlotAlarm CfpSlotAlarm TrackAlarm IsCfpRxSlot IsCfpTxSlot CfpEndAlarm Alarm fired instants Figure 4.12: Timers and alarm involved in the GTS implementation Figure 4.13 shows the instant of alarm expiration. The delay influences in the time slot duration, and moreover this delay could not be negligible when we use low SO and BO. CAP GTS 2 ID 0x002 [Rx] GTS GTS 1 1 ID ID 0x002 0x002 [Tx] [Tx] CfpSlotAlarm.start() CfpSlotAlarm.start() CfpSlotAlarm.fired() CfpSlotAlarm.fired() CfpEndAlarm.fired() time Figure 4.13: Detail of alarms involved in the GTS implementation Time slot duration It is known that is very difficult to check and debug timing issues without a hardware emulation. For this reason we try to evaluate it, with two methods and obtain conclusions from both. The first test has been done analysing the sniffer dump. Once enough data is logged with the sniffer, we proceed to convert it to be able to use the data with Matlab. After that, we apply a script to obtain the desired plots and statistics.

69 4.2. GTS DECOMPOSITION 61 The Matlab script computes the difference between data packets and the beacon, preventing to count two packets with the same source id. Some points to be known are: The periodicity of the packets is equal to the half of the beacon interval, to be sure that we have packets in every superframe, otherwise if the periodicity is greater than the beacon interval, we have some superframes without any data packet. The time between the first packet of each slot is not the same due to the periodicity, so although we obtain some results, we cannot assume that is the time slot duration. Figure 4.14 shows the histogram of the time slot duration with sniffer method. There are two distinct peaks, one is coming from the slot in the middle of the superframe and the small one, is coming from the last slot, because it does not include the guard time. time [ms] Number of packets time [symbols] Figure 4.14: Histogram with sniffer method, BO=SO=6 timeslotduration = abaseslotduration 2 S O = = 3840 On the other hand, the second test is reached with printf functions. To compensate the delay that is introduced by the printf instruction. We calculate the difference between the mean using the sniffer method with and without printf. The conclusion is that the printf introduces a delay around 300 symbols, so, the result should be subtract these number of symbols. Figure 4.15 shows the histogram of that time slot duration with printf method. Here we can see two different peaks, but the difference between them, in that case,

70 62 CHAPTER 4. GTS IMPLEMENTATION is bigger than in the one with the sniffer method. It is due to the printf position in the code. For the slot in the middle the printf is placed when a time slot duration is achieved, and for the last one, the shortest one, the printf is placed when the token is going to be transferred. time [ms] Number of packets time [symbols] Figure 4.15: Histogram with printf method, BO=SO=6 timeslotduration = abaseslotduration 2 S O = = 3840 We see that, for our case of study BO = SO = 6, the time slot duration from both test correspond with the expected value, considering the limitations. But these results can not be extrapolated to all the range of BO, SO available. Comments and possible improvement are shown in Section Components The GTS functionality is implemented trying to follow the same structure and the same organization of the TKN15.4 in the MAC layer. Table 4.3 shows the components that provides the GTS functionality. Component Name CfpTransmitP DeviceCfpP DispatchCfpQueueP CoordCfp Function[Provided IEEE Interface] managing GTS transmission [MLME-GTS] functions specific for a device frame transmission during CFP functions specific for a coordinator Table 4.3: GTS components

71 4.2. GTS DECOMPOSITION 63 In the DeviceCfp and CoordCfp, initially it was supposed to contain every function and variable related to the device or coordinator, in order to have device and coordinator in different files. But as soon as the code was growing, most of the code was placed in the CfpTransmit due to the necessity of sharing some variables and functions which are in the file. In the CfpTransmitP component, we have some pieces of code with conditional inclusions (preprocessor directives) to be able to differentiate device and coordinator without the use of nesc conditional sentences, and reduce the size of the program. The interconnection between components, called wiring in nesc, are very important to know which components are related to each other. In our case, due to the modularity of the TKN15.4 implementation, it is impossible to show the wiring graph generated by nesdoc. For this reason, Figure 4.16 and Figure 4.17 show a graph just with the wiring related to our implementation, even if the components is in the graph it is possible that not all the wiring are shown DeviceCfp Uses interface MLME_SYNC_LOSS; Interface that implements the actions in case the device loses synchronization with the PAN coordinator. When it occurs all its GTS allocations shall be lost [26, Sec p. 192], and if the device wants to transmit/receive during the CFP again, it has to request a new slot. interface GtsUtility; See Section Provides interface Init; The basic synchronous initialization interface. interface Get<ieee154_GTSentry_t*> as GetGtsDeviceDb; Interface that is provided to share the device database, with the data of transmit/receive slot. The pointer is shared and the rest of the components that use the interface will be able to modify that variable. Variables 1 To generate the complete graph: 1. compile an app with GTS enabled, make tmote docs; 2. open se.kth.tinyos2x.mac.tkn154/docs/nesdoc/index.html; 3. navigate to the component TKN154BeaconEnabledP

72 64 CHAPTER 4. GTS IMPLEMENTATION MLME_GTS Alarm8 Alarm9 Alarm10 Alarm11 Alarm12 Timer6 MLME_RX_ENABLE RxEnableP QueueC (DeviceCapQueueC) MLME_GTS Notify<bool> MLME_GTS Alarm<T62500hz,uint32_t> CfpTransmitP Timer<T65200hz> RadioTx RadioRx RadioOff TransferableResource RadioClientC (DeviceCfpRadioClient) Queue<ieee154_txframe_t> DispatchQueueP (DeviceCapQueue) FrameTx DispatchSlottedCsmaP (DeviceCap) FrameTx FrameRx FrameRx FrameTx Notify<ieee154_status_t> GetNow<bool> Get<ieee154_GTSentry_t*> Notify<ieee154_status_t> GetNow<bool> Get<ieee154_GTSentry_t*> BeaconSynchronizeP Purge DataP FrameTx Purge DispatchCfpQueueP (DeviceCfpQueue) Get<ieee154_GTSentry_t*> MLME_SYNC_LOSS Queue<ieee154_txframe_t> MLME_SYNC_LOSS DeviceCfpP MCPS_PURGE QueueC (DeviceCfpQueueC) GtsUtility Init MCPS_DATA MLME_SYNC_LOSS MLME_GET MLME_SET MCPS_DATA MCPS_PURGE MLME_GET PibP GtsUtility GtsUtility Figure 4.16: Wiring of the components related to the GTS implementation compiling for a device ieee154_gtsentry_t GTSentry[2] Variable that stores the database for the device. There is the configuration for the transmission and reception slots (starting slot, length and direction). As most of the functions are placed in the CfpTransmitP components, that variable is shared by the interface Get<ieee154_GTSentry_t*> and available for all the components that uses that interface CoordCfp Uses interface MLME-GET; Interface that is used to get the configuration variables from the PAN Information Database (PIB). Use: call MLME_GET. variablename(). interface MLME-SET; Interface that is used to set the configuration variables to the PIB. Use: call MLME_SET. variablename(). interface IEEE154Frame as Frame; Interface that allows access to the content of a IEEE frame. It is not the same as FrameUtility.

73 4.2. GTS DECOMPOSITION 65 MLME_GTS Alarm8 Alarm9 Alarm10 Alarm11 Alarm12 Timer6 MLME_RX_ENABLE RxEnableP QueueC (DeviceCapQueueC) MLME_GTS Notify<bool> MLME_GTS Alarm<T62500hz,uint32_t> CfpTransmitP Timer<T65200hz> RadioTx RadioRx RadioOff TransferableResource RadioClientC (CoordCfpRadioClient) Queue<ieee154_txframe_t> DispatchQueueP (DeviceCapQueue) FrameTx DispatchSlottedCsmaP (DeviceCap) Purge FrameTx FrameRx FrameRx FrameTx Notify<ieee154_status_t> GetNow<bool> Get<ieee154_GTSentry_t*> Notify<ieee154_status_t> GetNow<bool> Get<ieee154_GTSentry_t*> BeaconTransmitP WriteBeaconField DataP FrameTx Purge DispatchCfpQueueP (CoordCfpQueue) Get<ieee154_GTSentry_t*> MLME_SYNC_LOSS Queue<ieee154_txframe_t> MLME_SYNC_LOSS CoordCfpP MCPS_PURGE QueueC (CoordCfpQueueC) GtsUtility Init MCPS_DATA MLME_SYNC_LOSS MLME_GET MLME_SET MCPS_DATA MCPS_PURGE MLME_GET PibP GtsUtility GtsUtility Figure 4.17: Wiring of the components related to the GTS implementation compiling for a coordinator Interface that allows to ac- interface IEEE154BeaconFrame as BeaconFrame; cess the content of a beacon frame. interface GtsUtility; See Section Provides interface Init; The basic synchronous initialization interface. interface WriteBeaconField as GtsInfoWrite; Interface that is used by the BeaconTransmitP to write the GTS descriptor in the beacon, in case it was needed. In that interface we analyse all the database that the coordinator has looking for a GTS slot. It is done, just once if the GTS slots don t change. interface Get<ieee154_GTSdb_t*> as GetGtsCoordinatorDb; Interface that provides to share the coordinator database, with the data of all the slots. The pointer is shared and the rest of the components that use that interface will be able to modify that variable.

74 66 CHAPTER 4. GTS IMPLEMENTATION Variables ieee154_gtsentry_t db[cfp_number_slots]; This is the vector where all the slots informations are store. The number of maximum slots is set to 7, as the standard says [26, Sec p. 145]. The ieee154_gtsentry_t contains the following information: starting slot, length, direction, associate device address (short address) and a field indicating the expiration. ieee154_gtsdb_t GTSdb; This is the database shared with the GetGtsCoordinatorDb interface. It contains the previous vector of each ieee154_gtsentry_t and the number of actual GTS slots that has been used. ieee154_macgtspermit_t m_gtspermit; Variable that stores the boolean indicating the possibility to use or not use the GTS CfpTransmitP Uses interface Leds; Interface that provides commands for controlling three LEDs. interface TransferableResource as RadioToken; As it has been shown in Section we need to share the radio resource with all the components to use it properly. interface GetNow<token_requested_t> as IsRadioTokenRequested; Interface that checks if any component has request the RadioToken, and immediately it will be released. In a normal operation, the RadioToken is not request/release but in some cases like SCAN or RESET is needed. interface Alarm<TSymbolIEEE802154,uint32_t> as CfpSlotAlarm; This is the alarm that triggers every instant one slot has started. When it fires we check in which slot we are at the moment, and if we have to change the radio state to transmission, reception or inactive. Figure 4.12 and Figure 4.13 interface Alarm<TSymbolIEEE802154,uint32_t> as CfpEndAlarm; This alarm indicates that the CFP has finished and the token has to be transfer to the BeaconTransmitP or BeaconSynchronizeP to continue in the inactive period or transmit, receive the beacon. Figure 4.12 interface Alarm<TSymbolIEEE802154,uint32_t> as IsCfpRxSlot; alarm is running it indicates we are in a reception slot. interface Alarm<TSymbolIEEE802154,uint32_t> as IsCfpTxSlot; alarm is running it indicates we are in a transmission slot. When this When this

75 4.2. GTS DECOMPOSITION 67 interface Alarm<TSymbolIEEE802154,uint32_t> as TrackAlarm; This is the alarm that triggers when the CFP starts. It is needed due to the guardtime used at the end of the CAP. Figure 4.12 interface Timer<TSymbolIEEE802154> as GTSDescPersistenceTimeout; Once it receives the acknowledgement to the GTS request command, the devices shall continue to track beacons and wait for at most agtsdescpersistencetime superframe. If the GTS descriptor is received and the MLME_GTS.confirm() is signalled this timer stops running. If the timer fired the MLME-GTS.confirm primitive is sent with status of NO_DATA.See [26, Sec p. 193]. interface TimeCalc; Interface that provides time utilities. interface GetNow<bool> as IsRxEnableActive; reception is active. Interface that indicates if the interface Notify<bool> as RxEnableStateChange; the state has changed. Interface that notifies when interface Notify<const void*> as PIBUpdateMacRxOnWhenIdle; notifies when the RxOnWhenIdle has changed. Interface that interface SuperframeStructure as SF; Superframe utilities to get parameters and configuration of the beacon. Superframe start time, slot duration, number of CAP and CFP slots, GTS fields are some of the parameters we can get. interface RadioTx; Interface that provides the functions to be able to transmit using the radio. interface RadioRx; Interface that provides the functions to be able to receive using the radio. interface RadioOff; Interface that provides the functions to turn off the radio. interface Notify<ieee154_status_t> as HasRequestedCfpTimeSlot; Interface that notifies when a new beacon is received in case we are waiting for a GTS descriptor. It checks if our requested CFP slot exists on the beacon. interface Notify<ieee154_status_t> as CheckCfpTimeSlot; Interface that notifies when a GTS slot has been deleted from the beacon. interface FrameTx as GtsRequestTx; Interface that contains the function to send packet through the radio. It sends packets in the CAP. interface Pool<ieee154_txframe_t> as TxFramePool; Interface that provides the pool that has the packets in the same queue and control it.

76 68 CHAPTER 4. GTS IMPLEMENTATION Interface that con- interface Pool<ieee154_txcontrol_t> as TxControlPool; trols the previous pool, and prevents it to overflow. interface MLME-GET; Interface that is used to get the configuration variables from the PIB. interface MLME-SET; the PIB. Interface that is used to set the configuration variables to interface FrameUtility; of a frame. Interface that provides utilities to access the content interface GtsUtility; See Section interface IEEE154Frame as Frame; Interface that allows to access the content of a IEEE frame. It is not the same as FrameUtility. Interface that allows to ac- interface IEEE154BeaconFrame as BeaconFrame; cess the content of a beacon frame. #ifndef IEEE154_BEACON_TX_DISABLED interface FrameRx as GtsRequestRx; Interface that is used to transmit the MLME_GTS.request and detect the acknowledge. interface Get<ieee154_GTSdb_t*> as GetGtsCoordinatorDb; Interface that is used just when we compile the program for the coordinator. (see on page 63) #else interface Get<ieee154_GTSentry_t*> as GetGtsDeviceDb; Interface that is used just when we compile the program for the coordinator. (see on page 65) #endif Provides interface Init; interface MLME_GTS; Interface that provides all the primitives necessary to use the GTS. The request(), confirm() and indication() are provided. interface Notify<bool> as GtsSpecUpdated; Interface that notifies to other components that the GTS descriptor in the beacon has to be rewritten. interface GetNow<bool> as IsGtsRequestOngoing; Interface that indicates to other components that there is one MLME_GTS.request on going. While there is one request on going, it is not possible to process another one.

77 4.2. GTS DECOMPOSITION 69 interface GetNow<bool> as IsGtsOngoing; Interface that indicates to other components that the GTS is working and we are receiving/transmitting through the GTS. interface Get<ieee154_GTSentry_t*> as GetGtsRequestedDeviceEntry; Interface that is used to share the information about the requested GTS entry. interface FrameTx as CfpTx; Interface that is used to transmit data in the contention free period instead of contention access period. interface FrameRx as CfpRx; Interface that is used when a packet is received in the contention free period. interface Notify<bool> as WasRxEnabled; was enabled to receive packets. Interface that indicates if the radio Variables /* - Vars to CFP tx - */ norace ieee154_status_t m_txstatus; norace uint32_t m_transactiontime; the packets. Indicates the transmission status. To store the transaction time needed for norace uint16_t m_slotduration; To store the slot duration of the beacon. It is equal to: timeslotduration = abaseslotduration 2 SO norace uint16_t m_guardtime; That guard time, it is the time that the radio needs to change its state to inactive. (See [39]). norace uint32_t m_capduration; It is the CAP duration. When the radio resource is transferred to the CfpTransmitP component, that time is recalculated because it is possible that the CAP has changed. capduration = numcapslots timeslotduration = numcapslots abaseslotduration 2 SO norace uint32_t m_gtsduration; It is the CFP duration. When the radio resource is transfer to the CfpTransmitP component, that time is recalculated because it is possible that the CFP has changed. gtsduration = cf pduration = numcf pslots timeslotduration = numcfpslots abaseslotduration 2 SO norace uint32_t m_cfpinit; It is the time when the contention free period has to start. It is used by the TrackAlarm to align the device and the coordinator. cf pinit = capduration + superf ramestartt ime

78 70 CHAPTER 4. GTS IMPLEMENTATION norace ieee154_macmaxframeretries_t m_macmaxframeretries; Variable that is used to control the number of retransmission that are available. norace ieee154_macmaxframetotalwaittime_t m_macmaxframetotalwaittime; Variable that stores the maximum time that it waits until the acknowledge is received and we have to retransmit the packet, if the m_macmaxframeretries is not achieved. norace ieee154_macrxonwhenidle_t macrxonwhenidle; Variable that indicates in which state of the radio, during the idle state. If it TRUE the radio has to be in reception state, to wait for new packets. norace bool m_lock; To prevent non-atomic access to a variable, instead of using atomic block, because although it will assure that the block is accessed with atomic access, it will take some time.[21, Sec. 4.5] norace uint8_t m_slotnumber; Indicates the slot number, where it is at the moment. Variable that is used to load the entry that belongs to the actual slot number. norace ieee154_txframe_t *m_currentframe; Variable that points to the actual frame, that has been prepared to send. norace ieee154_txframe_t *m_lastframe; that has been sent. Variable that points to the last frame /* - Vars to GTS request - */ uint8_t m_payloadgtsrequest[2]; Variable that contains a vector where the payload of the MLME_GTS.request is stored. The first byte indicates the command type (CMD_FRAME_GTS_REQUEST), and the second byte contains the information of the requested slot: short address, length, direction, and type (allocate or deallocate). norace bool m_gtsongoingrequest = FALSE; See entry interface GetNow<bool> as IsGtsRequestOngoing; on page 68. norace bool m_gtsongoing = FALSE; on the previous page. See interface GetNow<bool> as IsGtsOngoing; bool m_hasrequestedtimeslot = FALSE; See interface Notify<ieee154_status_t> as HasRequestedCfpTimeSlot; on page 67. uint8_t m_gtscharacteristicstype = GTS_DEALLOCATE_REQUEST; indicates the characteristics type of the request. Variable that Variable that contains the informa- ieee154_gtsentry_t GTSentryRequested; tion of the request slot.

79 4.3. DISCUSSION 71 ieee154_gtsentry_t GTSentryRequestedEmpty; Variable that contains the information of the request slot, to be deleted. /* - Vars to expiration GTS - */ ieee154_gtsentry_t* actualentry; Variable that points to the actual slot entry depending on the slot number. norace uint16_t m_expiredtimeout; Variable that stores the number of superframes that the coordinator has to wait if the slot it is not used. Afterwards the coordinator starts the GTS expiration mechanism.[26, Sec ] { 2 8 macbeaconorder 0 macbeaconorder 8 n = macbeaconorder 14 norace uint8_t m_expiredreset[cfp_number_slots]; Variable that is used to count the number of superframes in which a slot is not been used. Once this variable is equal to 0, the coordinator proceed the expiration mechanism. When a new slot is requested or when the slot is being used, that variable is reset to m_expiredtimeout Utilities The utility component provides tools to manage and configure the GTSs GtsUtility The TKN154.4 does not provide any functions to access the GTS variables in the beacons. Note that although they are related to the beacon frame or the data frame, it has been considered as best option to do it in a different interface, not in the FrameUtility or IEEE154BeaconFrame. Table 4.4 explains the functions and commands implemented. The first group is focused on the frame, as a MLME_GTS.request primitive, and the beacon frame group provides the functions to read, parse and get the GTS descriptor. Furthermore it provides utilities to manage the GTS database that needs the coordinator. 4.3 Discussion In spite of having a working GTS implementation, there are few known issues and problems to be discussed:

80 72 CHAPTER 4. GTS IMPLEMENTATION Frame functions Function Name uint8_t getgtscharacteristics(...) Description Get the GTS Characteristics from a frame payload uint8_t setgtscharacteristics(...) Return the GtsCharacteristics to create a frame ieee154_status_t parsegtscharacteristicsfromframe(...) ieee154_status_t parsegtscharacteristicsfrompayload(...) BeaconFrame functions uint8_t getgtsentryindex(...) error_t addgtsentry(...) error_t purgegtsentry(...) error_t getgtsfields(...) error_t getgtslist(...) ieee154_status_t hasrequestedtimeslot(...) ieee154_status_t checktimeslot(...) void setnullgtsentry(...) Table 4.4: GtsUtility functions Parse a frame to get the GtsCharacteristics Parse a payload to get the GtsCharacteristics Get the GTS entry index, in case we have it, otherwise return the new one Add the new entry to the coordinator database Purge the entry in the coordinator database. It reallocates the rest of the slots, to keep it in order Reads the GTS Fields of a beacon frame (except GTS List) Reads the GTS List of a beacon frame Return the requested slot configuration in the ieee154_gtsentry_t* Once we have the resource, we just need to check if our slot is still in the beacon Empty the slot. Set the length and starting slot to zero; direction to two (invalid) 2 and expiration to FALSE Guard time: According to [39] there is a switching time between sleep and active states for the radio chip (CC2420). The time is called guard time guardt ime = 420symbols = 6.720ms. Figure 4.18a shows the guard time in the TKN15.4 when the superframe involves CAP and CFP. In Figure 4.18b with BO SO, we can see that the guard time used in CAP is not needed, and it takes time in the CAP. In Figure 4.18a we do not need any guard time, but the implementation has them because it does not distinguish between BO = SO or BO SO. Therefore, we see the necessity of deleting this time in the cases where we do not need it because it decreases the useful time of the period. Moreover, as far as the guard time is not negligible for small SO, it would not allow the use of the GTS. Hence, it is really important to analyse this problem deeply, in

81 4.3. DISCUSSION 73 CAP CFP guardtime time BI (a) BO = SO guardtime guardtime CAP CFP Inactive SD time BI (b) BO SO Figure 4.18: Influence of guard time order to be able to provide a GTS for low SO using the CC2420. Superframe Order: The guard time showed before and the timing limitation with the khz crystal, are the factors that does not allow the implementation to be standard compliant. At the moment it is possible to use 4 < SO 14. For SO < 4 we have a time slot duration lower than the guard time, timeslot < guardt ime. So the last time slot shall not be possible to use. In Figure 4.18, we can see the influence of the guard time in the last slot on the superframe. We are planning to use our implementation in the new Zolertia Z1 [25] motes with the new MSP430 Series 2 which allows to use crystal faster than khz as the Series 1. Missed beacons: As we have seen in Section , the TKN15.4 implementation has a problem of missing beacons when a network is already running. Given a network with several devices, once the device synchronizes with the PAN Coordinator after the MLME_SCAN, it is possible to lose some beacons. It also happens when we have a big interference or a device transmitting with high sample rate in the same channel. In the standard specifications, it is defined that once a node lose the synchronization it shall stop using the allo-

82 74 CHAPTER 4. GTS IMPLEMENTATION cated slots. So in this case, it will be necessary to start a MLME_GTS.request mechanism again. Memory limitation: There is a limit of 48 Kbytes in the ROM memory. With the GTS implementation, the debug utility provided by TKN15.4, dbg_serial, is not possible to use. In the default TKN15.4 with the coordinator was impossible to use as well. By using the new Zolertia Z1 motes, we shall overcome this problem, because the Z1 has 96 kbytes of ROM, instead of 48kBytes that TmoteSky/Telosb have. 4.4 Future work To achieve the desired target of a complete implementation, there are few issues that are necessary to implement. Time slot duration: In Section , we saw that the time slot duration is correct, but there is one thing that would improve it. To be sure that the initial time of the slot is correct, it is possible to modify the timer. Instead of using call AlarmXXX.start(timeSlotDuration), use call AlarmXXX.startAt (initslottime, timeslotduration). Figure 4.19 shows this improvement. Superframe Order: The IEEE protocol is designed to be able to use BO and SO between 1 to 14 for beacon-enabled mode. Hence, to achieve a full implementation we need to be able to use all the range available, that at the moment is limited, 4 < SO 14. As we have seen, our big challenge is for SO < 4 where the guard time set this limitation. Configure slot length: In the MLME_GTS.request() the device has to send the requested GTS slot length. At the moment this functionality is not implemented, the slot length is set to one. Invalid GTS slot: If there was not sufficient capacity to allocate the requested GTS, the start slot shall be set to zero and the length to the largest GTS length that can be currently be supported. [26, Sec ]. In this case, it is allow to expand the CFP and use part of the CAP. CAP Maintenance: As far as we do not have the configuration of the slot length available yet, we assure that the CAP length is bigger than amin- CAPLength symbols. [26, Sec ] The maximum slot number that the CFP could have is7 slotlength = 7, the the minimum value that we can get

83 4.4. FUTURE WORK 75 CAP GTS 2 ID 0x002 [Rx] GTS GTS 1 1 ID ID 0x002 0x002 [Tx] [Tx] Legend Improvement Implemented CfpSlotAlarm.start() CfpSlotAlarm.start() CfpSlotAlarm.fired() CfpSlotAlarm.fired() CfpEndAlarm.fired() time CfpSlotAlarm.startAt(init, slotduraiton) CfpSlotAlarm.fired() CfpSlotAlarm.startAt(init, slotduraiton) CfpEndAlarm.fired() CfpSlotAlarm.fired() time Figure 4.19: Comparison between the time slot duration with the actual implementation and the improvement for the future work. In the actual implementation, we can see the influence of a small delay in the start timer. In the improvement, the timer computes the difference between the starting time and the final, and then the delay does not influence. is: CAP length abaseslotduration (anumsuperframeslots 7) 2 SO min(so) 1080symbols and the default am incap Length = 440symbols. So in our implementation there is no problem, but as far as the slots length will be optional, it is necessary to implement it.

84

85 Chapter 5 Performance evaluation of IEEE In the previous chapter, the IEEE protocol and the GTS implementation were described. There are a lot of factors that could influence the behaviour of the protocol, namely: noise, interferences from other networks and hardware restrictions (delay, precision, accuracy, clock drift). As a consequence, it is important to consider a strong performance evaluation. In this chapter we analyse the delay and reliability for different traffic load η and MAC parameters. 77

86 78 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE System model For the performance evaluation, the system model defined in [29] is implemented in the motes with some variations. It provides us a good reference of how the performance shall be. We consider a star network with a PAN coordinator and N nodes. All N nodes contend to send data packet to the coordinator, which is the data sink. In this analysis we consider applications where nodes asynchronously generate packets with probability η t when a node sends a packet successfully, discards a packet or the GTS request has failed. And with probability η p when the sampling interval has expired. A node stays for ht b without generating packets with probability 1 η t, where h is an integer and T b is the time unit aunitbackoffperiod, corresponding to 20 symbols (320 µs). In general, we consider two different types of data packets: non-time critical data packets transmitted during CAP and time critical data packets during CFP using GTS allocation mechanism. When a node decides to generate a data packet, it generates a non-time critical data packet with probability η d and time critical data packet with probability 1 η d. A node that uses beacon-enabled slotted CSMA-CA algorithm, for sending a time critical data packet, first sends a GTS request to coordinator during CAP. Once the MLME_GTS.confirm is signalled (due to a GTS descriptor reception or and error), each node may need to send a multiple number of time critical packets τ n during CFP once the slot is allocated. For the non-time critical data packet, the node sends one packet during CAP. Note that the packet transmission is successful if an ACK packet is received. Figure 5.1 illustrates the system model implemented in the motes. The grey circles boxes indicate the states of the system. The light blue boxes indicate command to send or a received event. 5.2 Network scenarios In this chapter we show different modes that IEEE allows. In the beaconenabled, we use the slotted CSMA-CA in CAP and GTS in CFP. The non beaconenabled use the unslotted CSMA-CA. Figure 5.2 shows the topology considered for this performance evaluation. All N=9 motes are placed surrounding the coordinator between (50cm - 1m). They have a low transmission power to avoid possible interferences between motes. Following, reliability and delay are shown for different configurations, and as function of some MAC parameters. It does not intend to be a wide comparative

87 5.2. NETWORK SCENARIOS 79 1 η t η t MCPS- DATA.confirm() 1 η p η d CAP Tx MCPS- DATA.request(ACK) Sampling interval Idle Send packet 1 η p 1 η d CFP Tx MLME-GET.request() N Success? MLME- GTS.confirm() Y Y N τ i > τ MCPS- DATA.request(ACK GTS) MCPS- DATA.confirm() Figure 5.1: System model diagram 1 PAN coordinator 9 Reduced Function Devices (RFD) Figure 5.2: Star network topology between the real implementation and the theoretical model found in [29, 30]. This chapter shows the results from the real implementation using the TKN15.4 and our GTS implementation. The reliability is the packet reception rate of the network. And the delays show in this chapter are defined as the variation of time between the generated and

88 80 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE received packets. So, it give as the idea of the delay introduced by the CSMA-CA mechanism influences the network. Mention that in papers where the performance evaluation is done, the delay is refereed to the time between a generated packet and when its ACK is received. Name Value Description SO 6 Superframe Order. This value set the duration of the superframe BO 6 Beacon Order. This value set the duration of the superframe plus inactive period. As we have the same value BO = SO = 6 the inactive period is 0. T b 20 symbols aunitbackoffperiod h 500 the number of backoff units. Sampling interval N 9 Nodes contend to send data packet to the coordinator n 1 macmaxframeretries m 4 macmaxcsmabackoffs m b 8 macmaxbe m 0 3 macminbe τ n 2 The number of time critical data packets for each GTS request. L p 50 bytes Packet length containing the packet header (11 bytes) and payload (39 bytes). η d Probability of non-time critical packet (CAP) 1 η d Probability of time critical packet (CFP) η p Probability to generate a packet when the sampling interval is expired η t Probability to generate a packet when a node send a packet successfully or discard a packet. η = η p = η t Traffic load Table 5.1: Default parameters for CSMA-CA Table 5.1 shows the involved parameters and their default values for our system model Beacon-enabled vs non beacon-enabled In this section we compare the beacon-enabled and the non beacon-enabled mode to see which mode provides a better performance. In the beacon-enabled mode all the motes have their backoff boundaries aligned which reduces the probability of collisions, however, in the non beacon-enabled mode the motes have their own backoff boundaries with no synchronization between motes. In Section 3.3.3, we have seen influence of the clock drift on the CCA mechanism, because even with

89 5.2. NETWORK SCENARIOS 81 the beacon-enabled mode where the motes shall be aligned, they could have some drift Reliability In slotted CSMA-CA, packets are discarded due to two reasons: (i) CCA failure ; (ii) retransmission limits. CCA failure happens when a packet fails to obtain idle channel in two consecutive CCAs within m + 1 backoffs. Furthermore, a packet is discarded if the transmission fails due to repeated collisions after n + 1 attempts. 1 Slotted version Unslotted version 0.95 reliability traffic load, η Figure 5.3: Reliability as a function of the traffic conditions η = η p = η t = 0.3, 0.5, 0.7, 0.9 for slotted and unslotted CSMA-CA, with a given probability for generating non-time critical packet η d = 1, superframe and beacon order BO = SO = 6 (for slotted version), MAC parameters n = 1, m b = 8, m 0 = 3, N = 9, h = 500 and the packet length L p = 50bytes. Figure 5.3 compares the reliability of the slotted and unslotted CSMA-CA as a function of the traffic load η with a given probability for generating non-time critical packets η d. The slotted version has a better reliability than the unslotted version. Reliability decreases as the traffic load increases, but for the lowest traffic load the reliability should be closer to 1. This difference could come from the imperfection of the implementation or external interferences in our work place (radio communications, WiFi, other WSN ). The difference of both probabilities is set around 0.01 for η 0.7. For η = 0.9 the reliability is similar in both cases. This behaviour is reasonable due to the the big number of collisions present in η = 0.9. All the nodes wants to transmit almost continuously, it does not influence the fact of transmitting in the backoffs boundaries (slotted) or every time after we detect the channel clear (unslotted).

90 82 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE Delay 10 8 delay [ms] Number of packets (a) Slotted CSMA-CA with SO = BO = delay [ms] Number of packets (b) Unslotted CSMA-CA Figure 5.4: Snapshot of delay for η = η p = η t = 0.5, with a given probability for generating a non-time critical packet η d = 1, superframe and beacon order BO = SO = 6 (for slotted version) and MAC parameters n = 1, m b = 8, m 0 = 3, N = 9, h = 500 and the packet length L p = 50bytes. Figure 5.4 shows a snapshot of the delay for 250 packets. The delay for the slotted version is lower than the unslotted, where we see a lot of packets between 4 and 10 ms. Figure 5.5 shows the delay as a function of the traffic load η for the slotted and unslotted version. In case of unslotted the values for η 0.5 should be lower and increasing when η increases. As we were expect, with the slotted version we get better performance in terms of reliability and delay. We conform the importance of the alignment in the motes

91 5.2. NETWORK SCENARIOS Slotted version Unslotted version 6 delay [ms] traffic load, η Figure 5.5: Delay as a function of the traffic conditions η = η p = η t = 0.3, 0.5, 0.7, 0.9 for slotted and unslotted CSMA-CA, with a given probability for generating a non-time critical packet η d = 1, superframe and beacon order BO = SO = 6 (for slotted version) and MAC parameters n = 1, m b = 8, m 0 = 3, m = 4, N = 9, h = 500 and the packet length L p = 50bytes. in order to reduce the collisions. Even though we know that the clock drift of the motes influences the alignment, we see that the influences is not big enough to make the slotted worse than the unslotted. In the delay we see a significant difference for low traffic load between the slotted, unslotted version Beacon-enabled and MAC parameters In this section, we focus in the beacon-enabled mode. We analyse the influence of MAC parameters, macminbe, macmaxframeretries and macmaxcsmabackoffs Reliability Figure 5.6 shows the reliability as a function of the traffic load η with a given number of nodes N=9 and different MAC parameters, m 0, m and n. In Figures 5.6a, 5.6b the reliability increases as MAC parameters m 0, m increase, respectively. However, in Figure 5.6c the reliability does not improve as the retry limits n increases for high traffic conditions η 0.7. Notice that the reliability saturates if n 3. Hence, the retransmissions are necessary but not sufficient for high reliability under high traffic load.

92 84 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE Delay Figure 5.7 shows the average delay as a function of the traffic load η with a given number of nodes N=9 and different MAC parameters, m 0, m and n. Observe that the average delay increases as traffic load increases due to high busy channel probability and collision probability. In Figures 5.7a, 5.7b and 5.7c the delay increases as MAC parameters m 0, m and n increases, respectively. However, Figure 5.7a shows that the average delay increases exponentially as m 0 increases. This behaviour is due to the CSMA-CA algorithm. In each backoff period it has a random period of 2 BE 1 backoffs. Hence, we conclude that m 0 is the key parameter in terms of average delay with respect to m and n. It is important to remark which are the most important parameters that influences in the performance of our network. For the reliability, increasing the number of retransmissions we improve the reliability but moreover more packets are sent to the network, so the reliability saturates. But if we increase the number of retransmissions then the delay will be influenced, so it is important to use the value of retransmissions that gives the highest reliability with a low delay. In our case, n = 3 gives the best performance. Moreover the delay is highly influenced by the MAC parameter macminbe (m0). The CSMA-CA algorithm generates a random delay where m 0 is the minimal value of the exponent. For this reason, if we increase this parameter the delay will increase exponentially Beacon-enabled with hybrid MAC Section 5.1 shows the system model used in this chapter, but until now, we analyse the performance transmitting during the CAP (η d = 1), sending non-critical packets. Now, we analyse the hybrid MAC, where we transmit during the CAP or CFP depending of the probability of critical packets (1 η d ). For sending a time critical data packet, first sends a GTS request to coordinator during CAP and send a multiple number of time critical packets τ n during CFP once the slot is allocated. This section present the performance analysis done for a hybrid MAC in a real implementation. Even though, the system model implemented is not the one introduced in [29], It gives a good approximation about the expected values Transient behaviour In this section, we analyse the transient behaviour of the network, keeping track of the slots allocated, received data packets and received request packets.

93 5.2. NETWORK SCENARIOS 85 Figure 5.8 shows the snapshot of a number of received data packets, received GTSs requests, and allocated GTSs. It shows them as a function of traffic load. The convergence of the values is reached around 30 superframes. The received data packets are the packets sent by the device with its ACK from the coordinator. The received GTSs request are the GTS commands sent by the device with its ACK, they are the number of GTS request that the coordinator processes. The allocated GTSs are the slots allocated by the coordinator. This information is extracted from the GTS descriptor for each beacon. In Figures 5.8a and 5.8b, are shown the received packets, request and data, as a function of traffic load. In case of the allocated GTSs, in Figure 5.8c we can see the saturation for η = 0.7, 0.5 while for η = 0.3, 0.1 it converges around the 6 and 5 slots allocated, respectively. In Figures 5.8a and 5.8b, if we focus in one peak when it converges, for example 60, the number of data packets increases when request packets decreases. It is due to the system model implemented, because to send a data packet during the CFP we need to send a request packet and those are not counted as a received data packets Reliability Figure 5.9 shows the reliability transmitting in the CAP and CFP as a function of the traffic load η with a given number of nodes N=9 and different MAC parameters, m 0, m and n. The reliability decreases as the traffic load increases. Note the evolution and behaviour of the plots for η d = 0.5 and η d = 0.8 do not follow a continuous behaviour. For η d = 0.5 the reliability should be bigger than η d = 0.8. As we saw in Section 4.4, the time slot alarm could be influenced by delays. With a high traffic load, the motes is trying to send packets more often and these interruptions could occur during the CFP. Moreover, this drift influences the ACK reception. Even if the packet has been sent correctly, the sender do not receive the ACK sent by receiver. Hence, we can see how important is the improvement proposed in 4.4 for the time slot duration Throughput Here we analyse the throughput of the hybrid MAC, namely, the average amount of both non-time critical packets and critical packets that are transmitted in the superframe, during a length of beacon interval T BI. To be able to compare with different BO, we use a normalized throughput, Θ = N CAP L CAP + N CF P L CF P T BI (5.1)

94 86 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE where N CAP represents the number of successfully received non-time critical packets, L CAP the length of the packets transmitted during the CAP, and N CF P and L CF P are the equivalent values for the time critical packets transmitted during the CFP. Note that the terms N CAP L CAP, N CF P L CF P and T BI are normalized by the slot unit. Figure 5.10 shows the throughput of hybrid MAC as a function of traffic load η, the probabilities of generating a time critical packet 1 η d and superframe order SO = 6 with a given MAC parameters m b = 8, m 0 = 3, m = 4, N = 9, h = 500, the number of time critical data packets for each GTS request τ n = 2, and the packet length L p = 5. Figure 5.10c presents the hybrid throughput, the sum of throughput of CAP in Figure 5.10a and CFP in Figure 5.10b. Note that it is not a comparison between CAP and CFP, it a a decomposition for the hybrid throughput. We observe that as probability for generating a time critical packets 1 η d increases, the throughput of CFP increases, however the throughput of CAP decreases. CAP throughput has a similar trend as the Hybrid throughput. The throughput of CAP is more dominant factor for the hybrid throughput of the network. This is due to the limited number of GTSs slots in the superframe Validation with theoretical model Figure 5.11 shows the reliability for our experimental results and the theoretical model. Reliability as a function of traffic load η using the slotted scheme with a given probability for generating a non-time critical packet η d = 1. Increasing the traffic load, with the experimental results, we see a decreasing reliability, but in the theoretical model it does not happen until η 0.6. In the maximum η = 0.9 we see that the theoretical model is between the maximum value and the minimum that we get with the real implementation. We can see how close the behaviour of our network is in comparison with the theoretical model. 5.3 Future work Validation with theoretical model: An extensive performance analysis regarding reliability, delay, throughput, energy consumption, collision probability and probability/cumulative distribution function is needed in order to assure that the behaviour and characteristics of this implementation are close to the model. [29, 30] are two references where an extensive performance evaluation is done for the CAP and for the Hybrid MAC, respectively. Interference analysis: As far as this standard uses the ISM radio band, other networks and devices surrounding could influence in the reliability,

95 5.3. FUTURE WORK 87 throughput and delay. [2, 16, 32] give some analysis on the impact of the IEEE g/n in IEEE network, or the influence of Received Signal Strength Indication (RSSI) levels. The theoretical model do not take into account these interferences and it will be important to analyse with the real deployment how much the interferences influences in terms of reliability.

96 88 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE reliability η= η=0.5 η= MAC parameter, m (a) m 0 = 3, 5, 8 reliability η= η=0.5 η= MAC parameter, m (b) m = 2, 3, 4, reliability 0.9 η=0.3 η=0.5 η= MAC parameter, n (c) n = 0, 1, 3, 7 Figure 5.6: Reliability as a function of traffic load η = η p = η t = 0.3, 0.5, 0.7 and MAC parameters m 0 = 3, 5, 8, m = 2, 3, 4, 5, n = 0, 1, 3, 7 given probability for generating a non-time critical packet η d = 1, superframe and beacon order BO = SO = 6. N = 9, h = 500 and the packet length L p = 50bytes.

97 5.3. FUTURE WORK 89 delay [ms] η=0.3 2 η=0.5 η= MAC parameter, m 0 (a) m 0 = 3, 5, delay [ms] η=0.3 1 η=0.5 η= MAC parameter, m (b) m = 2, 3, 4, 5 delay [ms] η=0.3 2 η=0.5 η= MAC parameter, n (c) n = 0, 1, 3, 7 Figure 5.7: Delay as a function of traffic load η = η p = η t = 0.3, 0.5, 0.7 and MAC parameters m 0 = 3, 5, 8, m = 2, 3, 4, 5, n = 0, 1, 3, 7 given probability for generating a non-time critical packet η d = 1, superframe and beacon order BO = SO = 6. N = 9, h = 500 and the packet length L p = 50bytes.

98 90 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE η = 0.1 η = 0.3 η = 0.5 η = packets number of superframes (a) Received data packets 9 8 η = 0.1 η = 0.3 η = 0.5 η = packets number of superframes (b) Received requests 7 6 η = 0.1 η = 0.3 η = 0.5 η = slots allocated number of superframes (c) Allocated GTSs Figure 5.8: Snapshot of number of received data packets, received request, and allocated GTSs as a function of traffic load η = η p = η t = 0.1, 0.3, 0.5, 0.7, with a given probability for generating a non-time critical packet η d = 0.8,superframe and beacon order BO = SO = 6, MAC parameters n = 1, m b = 8, m 0 = 3, N = 9, h = 500, the number of time critical data packets τ n = 2 for each GTS request and the packet length L p = 50bytes.

99 5.3. FUTURE WORK 91 Figure 5.9: Reliability as a function of the traffic load η = η p = η t = 0.1, 0.3, 0.5, 0.7 with a given probability for generating a non-time critical packet η d = 0.5, 0.8, 0.9, superframe and beacon order BO = SO = 6, and MAC parameters m b = 8, m 0 = 3, m = 4, N = 9, h = 500 and the packet length L p = 50bytes.

100 92 CHAPTER 5. PERFORMANCE EVALUATION OF IEEE throughput [bps] traffic load, η (a) CAP throughput η d =0.5 η d =0.8 η d = throughput [bps] η d =0.5 η d =0.8 η d = traffic load, η (b) CFP throughput throughput [bps] traffic load, η (c) Hybrid throughput = CAP + CFP throughput Figure 5.10: Throughput as a function of the traffic load η = η p = η t = 0.1, 0.3, 0.5, 0.7 with a given probability for generating a non-time critical packet η d = 0.5, 0.8, 0.9, superframe and beacon order BO = SO = 6, and MAC parameters m b = 8, m 0 = 3, m = 4, N = 9, h = 500 and the packet length L p = 50bytes. η d =0.5 η d =0.8 η d =0.9

101 5.3. FUTURE WORK 93 reliability Real implementation 0.86 Theoretical model Traffic load, η t Figure 5.11: Reliability as a function of η = η p = η t = 0.1, 0.3, 0.6, 0.9 using slotted with a given probability for generating a non-time critical packet η d = 1, superframe and beacon order BO = SO = 6, and MAC parameters m b = 8, m 0 = 3, m = 4, N = 9, h = 500 and the packet length L p = 50bytes. Figure 5.12: IEEE and spectrum usage in the 2.4 GHz ISM band. Source: [16]

102

103 Chapter 6 Control applications In this chapter, we show two practical experiments where the IEEE applies. First, we introduce the inverted pendulum process, which we choose as our control application example to run over IEEE The inverted pendulum involves the control design and the setup of other tools. Furthermore, we also apply our protocol implementation to improve the reliability of a home smart grid [33]. We show how the use of the IEEE can improve the reliability and gives benefits than a simple radio transmission does not have. 95

104 96 CHAPTER 6. CONTROL APPLICATIONS 6.1 Inverted pendulum control system In this chapter, we show the control of single inverted pendulum as an example of tight real-time process. This application example involves communication, a chip software implementation, hardware modifications and a control study. u t τ ca A Process x t S y t Wired network Wireless network τ2 ca τ1 sc τ ca 1 u t Controller y t τ sc τ sc 2 PC Figure 6.1: Inverted pendulum control system: One computer with NI board, three motes and the inverted pendulum Figure 6.1 shows the whole wireless inverted pendulum control process. For the sensing, we use two motes transmitting sensor data to the coordinator, which is another mote connected to the PC. For the actuation, we use a Data Acquisition (DAQ) board to send the voltage control output to the motor. One question that comes up is why we need to use the IEEE for WPC if it adds more complexity to our motes. We show some important points below: Reliability: The protocol provides a robustness mechanism to increase the reliability comparing to a simple channel access method like Carrier Sense Multiple Access (CSMA). IEEE provides a CSMA-CA channel access method with collision avoidance and the possibility of retransmission. In this tight real-time process, it is really important receive all the packets or the pendulum could fall. Adaptation: With the PAN coordinator role in the network, in case of failure, a device could synchronize again and continue sending packets without any hard-reset. Scalability: The inclusion of new sensors do not influence in the other, even if the sample rate is really high. In this case, we add two sensors one for the θ angle and one for the cart position. In case of using a simple CSMA, the

105 6.1. INVERTED PENDULUM CONTROL SYSTEM 97 use of two sensors affects directly to the reliability, because they would find the channel busy, or would create collisions in the network. For the pendulum we use the IEEE with the beacon-enabled mode. Mention that we transmit during the CAP period using slotted CSMA-CA instead of the CFP. In this case, with only two motes transmitting we reach a high reliability and the interferences between each mote, is almost negligible. So it is not needed the use of the GTS mechanism. In case of increasing the number of processes in the same network, I would be necessary the use of the GTS in order to remove the collisions between packets, and assure a high reliability. To whom is interested in knowing the steps with the problems found in our implementation, Appendix A shows a detailed description. Some videos of the demostration are shows in [24] Platform and hardware In this section, we describe the platforms and hardware involved in the wireless inverted pendulum control system. First of all, we see the single inverted pendulum provided be Quanser. Then, we show the counter board that we build to get an accurate resolution from the encoders. Finally the DAQ board and the software to communicate between the PC and the hardware is described Single Inverted Pendulum Figure 6.2 shows the inverted pendulum with the modifications, two motes with their counter boards attached to the encoder. The inverted pendulum is provided by Quanser. Quanser offers a guide with the system model. Moreover provides Simulink and Matlab files to run the pendulum using a DAQ board to get the values from the encoders. [35, 36, 37] The model of the system with the non-linear Equations of Motion (EOM) is characterized with the two equations below: 2 ( ) 2 t 2 x c = t 2 x c (x c, α, F c ) (6.1) 2 ( ) 2 t 2 α = t 2 α (x c, α, F c ) (6.2) (6.3) Figure 6.3 show the schematic of the inverted pendulum. [36] explains step by step all the equations of the physical model, in order to solve the partial derivation of the non-linear EOM.

106 98 CHAPTER 6. CONTROL APPLICATIONS Figure 6.2: Wireless inverted pendulum with the motes and the controller (PC) 2 ( ) 2 t 2 x c = t 2 x c (x c, α, F c ) [ ( ) ( ) d ) ( ) d = I p + M p lp 2 B eq dt x c(t) (Mp 2 lp 3 + I p M p l p sin(α(t)) dt x c(t) ( ) d ( M p l p cos(α(t))b p dt α(t) + ) ] F c + Mp 2 l p g cos(α(t)) sin(α(t)) I p + M p lp 2 / [ (M c + M p ) I p + M c M p lp 2 + Mp 2 lp 2 sin (α(t)) 2], (6.4) 2 ( ) 2 t 2 α(t) = t 2 α (x c, α, F c ) = [ (M c + M p ) M p gl p sin(α(t)) (M c + M p ) B p ( d dt α(t) ) ( ) d 2 ( ) d Mp 2 lp 2 sin(α(t)) cos(α(t)) dt α(t) M p l p cos(α(t))b eq dt x c(t) + ]/[ + F c M p l p cos(α(t)) (M c + M p ) I p + M c M p lp 2 + Mp 2 lp 2 sin(α(t)) 2] (6.5)

107 6.1. INVERTED PENDULUM CONTROL SYSTEM 99 Figure 6.3: Schematic of the single inverted pendulum In order to design and implement a linear-quadratic regulator (LQR) for our system, a state-space representation of that system needs to be derived. Therefore the EOM should be linearised around a quiescent point of operation. In case of the inverted pendulum, the operating range corresponds to small departure angles, α, from the upright vertical position. According to the system, Ẋ = AX + BU, (6.6) where X is the system s state vector, defined as, X T = [x c (t), α(t), d dt x c(t), d ] dt α(t), (6.7) and U is linear cart driving force, which is converted to the cart s DC motor voltage. When we linearise the equations (6.5) and (6.5), the matrix A and B are: A = gmp 2 lp 2 B eq (M p lp 2 + I p ) M p l p B eq (M c + M p )I p + M c M p lp 2 (M c + M p )I p + M c M p lp 2 (M c + M p )I p + M c M p lp 2 0 M p gl p (M c + M p ) M p l p B eq (M c + M p )B p (M c + M p )I p + M c M p lp 2 (M c + M p )I p + M c M p lp 2 (M c + M p )I p + M c M p lp 2 (6.8)

108 100 CHAPTER 6. CONTROL APPLICATIONS B = 0 0 I p + M p l 2 p (M c + M p )I p + M p l 2 pm c M p l p (M c + M p )I p + M p l 2 pm c (6.9) Counter board LS7366R To be able to use this Serial Peripheral Interface (SPI) external counter and avoid the bias that is present using the mote as a quadrature counter, we needed to implement a complete stack for this chip, as the one existent for CC2420 (radio stack) or STM25P (flash memory). These chips are also using the SPI channel number 0. Hence, it is necessary to build a robust implementation with bus arbitration, otherwise they will try access to the resource at the same time, and the program will crash or act in an unpredictable way. Content Directory in the TinyOS-2 Tree for LS7336R LS7336R chip implementation control components tos/chips/ls7366r/control interfaces tos/chips/ls7366r/interfaces SPI components tos/chips/ls7366r/spi test applications apps/test/ls7336r Platform specific code for TelosB ports configuration files tos/platforms/telosb/chips/ls7336r Table 6.1: TKN15.4 directories in the TinyOS-2 tree for LS7336R chip implementation Table 6.1 shows the directories where the LS7336R implementation has been placed. Some modifications in Makerules and Makefile files are necessary to compile the programs successfully. In the Appendix A, we show the schematics for these boards Data acquisition To communicate between the inverted pendulum and the PC, and send the control voltage back to the pendulum motor we use the DAQ board (NI-6221 PCI) provided by National Instruments (NI). [17] Features 16 Analog input (AI). 8 differential or 16 single ended

109 6.1. INVERTED PENDULUM CONTROL SYSTEM 101 Figure 6.4: NI 6221-PCI board Source: [17] Analog-Digital converter (ADC) resolution of 16 bits AI with a maximum sampling rate of 250 ks/s and 50 ns of time resolution 2 Analog output (AO) Digital-Analog converter (DAC) resolution of 16 bits Maximum AO rate of 833 ks/s AO range ± 10 V 24 digital input/outputs NI LabView NI LabView has been selected as the software to use the DAQ board to send the voltage to the motor. We implement the control loop using MathScript RT module which allows to do the calculations efficiently in LabView. In the Appendix A are screenshots of the VI LabView file Control over WSN Our Networked Control System can be modelled as in Figure 6.5. The received measurements from the process are subjected with delays and losses. The most important issue in our model is the delay from sensor to the controller τ sc. For practical experiments, we assume a delay h > τ cs, where h = 25ms. In order to have a stable controller even with the delay, it is necessary to estimate our state while compensating for the delay τ sc and then we use a LQR. Note that we follow the notation of [3]. The controller is designed following the methodology in [31]. Figure 6.6 shows the block diagram of our controller.

110 102 CHAPTER 6. CONTROL APPLICATIONS u t τ ca A Process S x t y t τ ca 2 Network τ1 sc τ ca 1 u t Controller y t τ sc τ sc 2 Figure 6.5: Model of our networked control system u k Controller y k+τ sc u k LQ ˆx k+τ Kalman Filter y k+τ sc u k 1 Figure 6.6: Block diagram of the controller Problem formulation The process to be controlled is described by the continuous-time model in dx = Axdt + Budt + dv c, (6.10) where A, B may be time-varying matrices. The process v c has mean value of zero and uncorrelated increments. x(t) R 4 is the plant state and u(t) R is the control signal. A time-varying discrete-time sampled system, with sampling time h can be written as x k+1 = Φx k + Γ u k + v k (6.11) y k = Cx k + e k, (6.12) where Φ is the fundamental matrix of (6.10) and v k and e k are discrete-time Gaussian white-noise processes with zero-mean value,

111 6.1. INVERTED PENDULUM CONTROL SYSTEM 103 Φ = e Ah (6.13) Γ = h 0 e As dsb (6.14) R 1 = E[v k v T k ] (6.15) R 12 = E[v k e T k ] (6.16) R 2 = E[e k e T k ] (6.17) Time-varying Kalman Filters With a time-varying Kalman filter we estimate the states by computing a new Kalman gain with the received measurements data. The first step is to predict the next value of the states with the knowledge of the previous state and the system model. Optimal Kalman filter equations are given by the equations (6.18) - (6.25). τ k 1 k k + τ k + 1 Figure 6.7: Prediction and delay compensation The Kalman filter could be separated in two steps, the prediction and the correction. Prediction step In the prediction step, it tries to estimate the next state given the estimation of the present state and the control input sent to the process previously, ˆx k+τ k = Φ τ ˆx k k + Γ τ u k 1 (6.18) ˆx k+1 k = Φ hˆx k k + Γ h u k = Φ h τ ˆx k+τ k + Γ h τ u k (6.19) P k+1 k = Φ h P k k Φ T h + R 1, (6.20)

112 104 CHAPTER 6. CONTROL APPLICATIONS where P k is defined as the variance of the estimation error, [ ] P k = E (ˆx k E(ˆx k )) (ˆx k E(ˆx k )) T (6.21) τ = τ sc h (6.22) In (6.19) we apply a delay compensation because the sample that we get is delayed, and it arrives after the sample time h. Correction step When a measurement is received the predicted state can be corrected by calculating the new Kalman gain, ( ) 1 K k = P k k 1 C T CP k k 1 C T + R 2 (6.23) ( ) ˆx k k = ˆx k k 1 + K k y k C ˆx k k 1 (6.24) P k k = P k k 1 K k CP k k 1 (6.25) Linear Quadratic Regulator The linear-quadratic (LQ)-control is solved for the case of complete state information. We assume the deterministic case, where v k = 0 and e k = 0. The discrete state-feedback law u k = L k ˆx k. (6.26) It minimizes a discrete cost function equivalent to the continuous cost function 1 J = lim T 2T T T We determine the discrete state-space model, (ˆx T t Qˆx t + u T t Ru t )dt. (6.27) ˆx k = A hˆx k + B h u k (6.28) where, ˆx k = ˆx c ˆθ ˆx c ˆθ (6.29) We get control gain by using the dlqr function in Matlab. To summarize, the steps needed in LabView are:

113 6.1. INVERTED PENDULUM CONTROL SYSTEM Correct the state ˆx k k given the measurements of y k. 2. Predict the actual state ˆx k+τ k given the state ˆx k k and the control signal u k. 3. Predict the next state ˆx k+1 k given the state of ˆx k+τ and the control signal u k+τ. 4. Apply the LQR to compute the control signal at k + τ given the estimation of ˆx k+τ k u k+τ = Lˆx k+τ k (6.30) Performance evaluation Along this section, we use the process for 2 minutes, and during this time, we have stable period, without any problems and few packets errors, and two different interferences intervals. To make interference on the network we use a scrambling mote. The scrambling mote consists in a mote sending dummy data to an non-existent mote using the same channel that the sensors and coordinator are using, but transmitting in a unslotted CSMA-CA. This node tries to simulate high traffic in the network and interferences. Note that with the highest sampling rate, the mote influences in the beacon reception of the motes, making them losing beacons, as we have seen in Section Below, we show different figures which make it is possible to detect this behaviour from different data, and/or from different points of view. First we see the exported data from LabView, where we see the sensor data and the control output. Then we show different information from the protocol analyser board, where from the time between packets we can detect when we get retransmissions and packet loss. Moreover, once we analyse the data we show the accumulated errors for each node, and the instant of failure. Between the start time at 18:12:57 and 18:13:49 the inverted pendulum process is stable, with few packets loss and few oscillation in the pendulum angle and cart position. After this time, the scrambling mote starts sending data with a 100 ms period. It makes the mote number 1, cart position, start failing and not sending packets, making some read from the carts position invalid, but the pendulum is still upright. Once we increase the sampling rate with the scrambling mote, at 18:14:25, the mote number 2 starts failing as well, which is a very critical measurement for the control of the pendulum, and the pendulum falls Sensing values Figure 6.8 shows the information read from the coordinator, when Figure 6.8a shows the pendulum angle θ, and Figure 6.8b the cart position. During the stable position,

114 106 CHAPTER 6. CONTROL APPLICATIONS (a) Angle θ of the pendulum (b) Cart position (c) Control output to apply to the cart motor Figure 6.8: Values read from the mote while running the pendulum in a stable position θ varies around ± 0.02 rad (1.146 degrees) and the cart position 80 mm. Note that all the figures related to the inverted pendulum have the same timestamps. Hence they are all related although we get ones from LabView and other from the protocol analyser. Observe that the cart position values fail around 18:14:15 after 24 seconds of low rate scrambling data. In the same instant, Figure 6.8c, the control voltage changes. The new voltage levels made the cart move faster, so the pendulum angle oscillations that we get are different than the stable position. After that, the pendulum comes to the stable position again for 5 seconds, and at this moment, after a lot of packets errors from a mote, the pendulum falls and it does not come back on track again. Here we can measure that packet losses critically affect the pendulum, mainly packet losses in node 2 which transmit critical packets with the pendulum angle.

115 6.1. INVERTED PENDULUM CONTROL SYSTEM 107 (a) Time between packets for mote ID=1 (cart position) (b) Time between packets for mote ID=2 (pendulum angle) Figure 6.9: Time between packets for motes 1 and Time between packets Figure 6.9 shows the time between sent packets for each node. Observe a delay jitter of 3 ms with a mean value of 25 ms. The packets under the mean value and the jitter are due to retransmissions and the packets above are packets loss. Therefore, in Figure 6.9a we observe problems in the transmission from 18:13:50 but in Figure 6.9b the errors start around 18:14:10. The difference between the instant 18:13:49 and 18:14:06 is the position of the scrambling mote. During these times, the scrambling mote is moved from mote ID=1 towards mote ID= Reliability and probability of error In Figure 6.10 we show the probability of error and reliability. Figure 6.10a shows the instants of errors differentiating between the errors coming from a CCA failure and retransmission failure. Mainly we have errors due to a retransmission failure, meaning that the influence of the clock drift, saw in Section , does not influence too much and they are transmitting in different backoff slots. In Figure 6.10b, we see the equivalent plot, providing the reliability with a window of 20 packets. So each point in the plot, represents the reliability for 20 packets Accumulated errors Figure 6.11 shows the evolution and behaviour of the error packets, the number of accumulated packet errors. Until 18:13:50 it is almost constant. Then it increase slowly until 18:14:15 and finally it increases really fast. It is easy to show with that

116 108 CHAPTER 6. CONTROL APPLICATIONS (a) Instant of failure (b) Reliability with sliding window Figure 6.10: Comparative between reliability, or probability of failure and the control output send by the PC figure the influence of the scrambling mote, for both motes. The node 1, in Figure 6.11a has more errors because the scrambling mote is close to him than the node 2. Notice that even with a huge number of error between 18:13:40 and 18:14:24, is not until 18:14:24 that the pendulum does not fail. Again, we can notice the criticality of node 2. To summarize, in this chapter we have seen the indispensable tools and platforms needed for the wireless inverted pendulum. The delay and the tight real-time requirements of the process, have forced to use a robust control design. The Kalman filter with the delay compensator has been the pillar of the control, with this estimator the influence of the delay has been relieved. From now onward, we could see the IEEE as the standard for wireless process control tight real-time process control. 6.2 Home smart grid Another application where the IEEE would give benefits is the Home smart grid. Where a large deployment is needed and the packets losses have to be reduced.

117 6.2. HOME SMART GRID 109 (a) Packets errors accumulation for mote ID=1 (Cart position) (b) Packets errors accumulation for mote ID=2 (Pendulum angle) (c) Total packets errors accumulation Figure 6.11: Packets errors accumulation while running the pendulum in a stable position Introduction In this work, a system to detect water and electricity consumption is introduced to identify resource waste and inform the consumers about it. For this purpose, many sensors are deployed in the kitchen of the department in order to gather data of the consumption. These sensors are an alternative to other ways of getting this information that are usually considered invasive, like a camera. Due to the amount of sensors involved and the large area covered, this application is highly suitable to the use of IEEE to gather data from all the sensors.[33] Our contribution in this project is the adaptation of the communication. By default, the TinyOS uses CSMA as a channel access method, which does not give any collision avoidance or any ACK mechanism. In order to provide more a robustness to the application, we adapt the programs to use the IEEE Figure 6.12 shows the communication diagram in this deployment The topology

118 110 CHAPTER 6. CONTROL APPLICATIONS Figure 6.12: Communication in the wireless sensor network Source: [33] used is a start network where we have some RFD devices, which are the sensors, a FFD who makes the connection between the PC and the PAN coordinator. The coordinator is situated in the middle of the kitchen, some sensors around it, and a base station connected to the PC in order to log the date coming from the base station. The coordinator in case of the IEEE , actuates as the PAN coordinator sending the beacon frame periodically, and as a bridge between the network and the PC, where it retransmits all the packets received from the sensors to the base station Performance evaluation Reliability In this application, a low sample rate is used, so comparing with results showed in Chapter 5, we expect a very high reliability. The analysis done in this section are based on the sniffer data. As far as it is an external device, that does not play any role on the network, the results that are shown in this section are not accurate, because the protocol analyser could not receive all the packets. CSMA shows the reliability using the default channel access method implemented in TinyOS. When the sender is ready to transmit data, it checks if the physical medium is busy. It senses the medium continually until it becomes idle, and the it transmits the frame. The collision are not detected by the sender, so it assumes that the packet has received without problems. TDMA shows the reliability using the default radio communication implemented in TinyOS with a previous scheduled times. It is not a strict Time Division

119 6.2. HOME SMART GRID 111 Multiple Access (TDMA), because we do not have any time slots mechanism, but the sender try to transmit in a different instant of time with this protocol. It provides a synchronization mechanism in order to have this behaviour. IEEE shows the reliability in a beacon-enabled transmitting during the CAP. As we have seen, we transmit using CSMA-CA, a modification of CSMA where Collision Avoidance (CA) is used to improve the performance of CSMA by attempting to keep the less busy the channel. If the channel is sensed busy before transmission then the transmission is deferred for a random interval. Reliability [ % ] Sensor CSMA TDMA CSMA-CA Powerplug Powerplug Vibration fridge Vibration sink Light sensor Light sensor Temperature sensor Temperature sensor IR IR IR Total % % % Table 6.2: Reliability for the different communications algorithms and protocols. Source: [33] Table 6.2 shows the reliability for the different sensors deployed in the kitchen. In the columns we have the different types of communications. The first column (CSMA) has the worst reliability because there are no retransmission and no collision detection, where the motes are not aligned each other. In the second column (TDMA) we have the motes aligned and transmitting in different instants of time, so the are no collision between each other, but as far as it is not a strict TDMA and no ACK mechanism and no retransmission, in case of failure they do not retransmit the packet. Therefore, in the IEEE transmitting using CSMA-CA during the CAP, we have a collision detections with a ACK mechanism and retransmission, which give the highest reliability. Figure 6.13 shows the number of accumulated error that we get during one hour of running the application.

120 112 CHAPTER 6. CONTROL APPLICATIONS Packet errors :57:36 13:04:48 13:12:00 13:19:12 13:26:24 Timestamp Figure 6.13: Accumulated errors in Home Smart Grid application 1 Retransmission failure CCA failure 0 12:57:36 13:04:48 13:12:00 13:19:12 13:26:24 Timestamp Figure 6.14: Instant of packet failure Figure 6.14 shows the instant of time where we get a failure, where it could be due to (1) CCA failure or (2) Retx failure.

121 Chapter 7 Conclusion and future work 7.1 Conclusion In this thesis, we describe the necessary steps to reach the wireless inverted pendulum process. First of all, we have described briefly the IEEE in order to know the benefits and problems that the protocol provides. The first critical point was the selection of a protocol implementation that provides us a protocol as close as possible to the standard defined in [26]. A comparison between the two main implementations is done through the experiments to validate the feasibility of the implementations. The IPP implementation [9], against our thoughts, had critical problems. It is impermissible that the motes stop working after some time and the timing for the beacons were not as good as it was possible given the motes used. The TKN15.4 provides a solid implementation but it was not completely implemented. For this reason we expand the functionalities of the implementation and we provide the necessary mechanisms to transmit during the CFP period. These mechanisms involves: GTS allocation, GTS deallocation, GTS expiration and GTS reallocation. Dealing with a real implementation, we face challenges related to the technological limitations of the platforms under use. All of these present more challenges that had to be mitigated to enable the experimental validation and a released implementation. During this particular implementation and experimental efforts, some of those difficulties were re-encountered, namely in what concerns the behaviour of the Tmote Sky/TelosB motes: (i) Memory constraints (ii) Hardware platforms and debugging (iii) CC2420 transceiver limitations (iv) Timing and synchronization requirements (v) TinyOS task scheduler. On the other hand, with a IEEE implementation we provided a evaluation with which the behaviour is proven. The performance evaluation shows which is 113

122 114 CHAPTER 7. CONCLUSION AND FUTURE WORK the real behaviour of our implementation for different network scenarios, in terms of packet deliver loss and delay. For the slotted version, we analysed the characteristics and performance transmitting during the CAP and CFP. Analysing the reliability and delay as a function of the MAC parameters, we have seen the importance of the macminbe respect to macmaxcsmabackoffs and macmaxframeretries in term of average delay. It is also important to mention that with the number retransmissions n we increase the reliability, but for a given n, it saturates and keep constant. An analysis for the hybrid MAC was also performed. Finally, with the IEEE working and with the performance evaluation done that assures that the protocol implementation gives a proper performance, it was the moment to continue and focus on the main goal of this thesis, prove and show the benefits in wireless process control that the standard would give. We use the process with tight real-time requirements available in our lab, a single inverted. We prove that is possible to use IEEE in a tight real-time control system, opening the possibility to prove different researches in a practical environment. Another application were the IEEE provides large benefits is in Home Smart Grid deployment. Using the protocol in the deployment of [33], the reliability increases around 7 % against a simple CSMA transmission mechanism. 7.2 Future work Along this thesis, we have seen different chapters with its own Future work : GTS implementation in Section 4.4 (1) Performance evaluation in Section 5.3.Moreover we posed some discussion in the GTS implementation in Section 4.3. For the IEEE implementation, we have seen some issues that does not allow to have a standard compliant implementation. Some improvements are related to software and hardware. As soon as the new MSP430 series have been launched and the Zolertia company has the motes with this MCU, the acquisition of those and future modification of the clock will reduce the present hardware limitations. Furthermore, in the software development is needed an extensive debugging in order to conform every part of the standard and improve the performance of the code. Having a full standard compliant implementation, a comprehensive performance evaluation and comparison with the theoretical model would give us more information and the certification that the implementation is correct. In papers [30, 29, 28] exist a complete and extensive description of the theoretical model with its characteristics to compare with. There are some researches where hybrid MAC is applied for control applications. With a IEEE implemented and the possibility to transmit during the CAP and CFP, we have opened the door to apply different control mechanism, eventdriven, hybrid control, etc. [20]. To see projects related to our lab visit [24].

123 References [1] A. Alemdar and M. Ibnkahla. Wireless sensor networks: Applications and challenges. Signal Processing and Its Applications, ISSPA th International Symposium on, pages 1 6, feb [2] L. Angrisani, M. Bertocco, G. Gamba, and A. Sona. Effects of RSSI impairments on IEEE wireless devices performance susceptibility to interference. Electromagnetic Compatibility - EMC Europe, 2008 International Symposium on, pages 1 6, sep [3] Karl J. Åström and Björn Wittenmark. Computer-controlled systems: theory and design (3rd ed.). Prentice-Hall, Inc., Upper Saddle River, NJ, USA, ISBN [4] CU Boulder. MultimodAl NeTworks of In-situ Sensors. Technical report. URL Accessed September [5] Chipcon. CC2420 datashet. Technical report. URL berkeley.edu/~cs150/documents/cc2420.pdf. Accessed September [6] Intel Corporation. Intel mote 2 engineering platform. Technical Report Rev URL imote2-ds-rev2.0.pdf. Accessed September [7] Moteiv Corporation. Tmote sky data sheet. Technical report, San Francisco, June URL tmote-sky-datasheet.pdf. Accessed August [8] Crossbow. MICAz datasheet. Technical report. URL net/uploadsproductos/micaz_datasheet.pdf. Accessed September [9] André Cunha, Mário Alves, and Anis Koubâ. IPP Hurray!: An IEEE protocol implementation (in nesc/tinyos): Reference guide v1.2. Technical Report TR , ISEP-IPP, May [10] Ricardo Augusto Rodrigues da Silva Severino. On the use of IEEE /Zigbee for Time-Sensitive Wireless Sensor Network Applications. Master s 115

124 116 REFERENCES thesis, ISEP, October URL fileadmin/dissemination/2009-thesis-award/severino.pdf. Accessed September [11] Adam Dunkels. Contiki - the operating system for connecting the next billion devices - the internet of things. Technical report, URL sics.se/contiki/. Accessed September [12] Sinem Coleri Ergen. ZigBee/IEEE Summary, September [13] David Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric Brewer, and David Culler. nesc 1.1 language reference manual. Technical report, May [14] David Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric Brewer, and David Culler. The nesc language: A holistic approach to networked embedded systems. volume Proceedings of Programming Language Design and Implementation (PLDI), jun [15] Jan-Hinrich Hauer and Adam Wolisz. TKN15.4: An IEEE MAC Implementation for TinyOS 2. Technical report, Technical University Berlin - Telecommunication Networks Group, March URL tkn.tu-berlin.de/publications/papers/tkn154.pdf. Accessed September [16] Jan-Hinrich Hauer, Adam Wolisz, and Vlado Handziski. Experimental Study of the Impact of WLAN Interference on IEEE Body Area Networks. Proc. of 6th European Conference on Wireless Sensor Networks (EWSN), February [17] National Instruments. Ni pci Technical report, URL ni.com/nips/cds/view/p/lang/en/nid/ Accessed September [18] Texas Instruments. Smartrf packet sniffer - user manual. Technical Report Rev URL smartrftm-studio.html. Accessed September [19] IPP. OpenSource Toolset for IEEE and Zigbee. Technical report, URL Accessed September [20] José Araújo, Yassine Ariba, Pangun Park, and K. H. Johansson. Control Over a Hybrid MAC Wireless Network. Technical report. [21] Philip Levis. Tinyos programming. Technical Report 1.3, October URL pdf. Accessed September [22] MAXIM. MAX232 - Datasheet. Technical report, URL datasheets.maxim-ic.com/en/ds/max220-max249.pdf. Accessed September 2010.

125 REFERENCES 117 [23] UCLA NESL. SOS Embeddeed operating system. Technical report. URL Accessed September [24] KTH NetCon group. URL Accessed September [25] Zolertia Z1. URL Accessed September [26] IEEE Std , September, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), September URL standards.ieee.org/getieee802/download/ pdf. Accessed September [27] Pangun Park. Protocol Design for Control Applications using Wireless Sensor Networks. PhD thesis, KTH, Stockholm, ISBN [28] Pangun Park, C. Fischione, and K.H. Johansson. Performance Analysis of GTS Allocation in Beacon Enabled IEEE Sensor, Mesh and Ad Hoc Communications and Networks, SECON 09. 6th Annual IEEE Communications Society Conference on, pages 1 9, jun [29] Pangun Park, Karl H. Johansson, and Carlo Fischione. Performance analysis of hybrid medium access control in IEEE protocol. Submitted, September [30] Pangun Park, Piergiuseppe Di Marco, Pablo Soldati, Carlo Fischione, and Karl H. Johansson. A generalized markov chain model for effective analysis of slotted IEEE Mobile Adhoc and Sensor Systems, MASS 09. IEEE 6th International Conference on, pages , oct [31] Joonas Pesonen. Stochastic estimation and control over wirelesshart networks: Theory and implementation. Master s thesis, KTH, February [32] M. Petrova, Lili Wu, P. Mahonen, and J. Riihijarvi. Interference Measurements on Performance Degradation between Colocated IEEE g/n and IEEE Networks. Networking, ICN 07. Sixth International Conference on, pages 93 93, apr [33] Oriol Prats. Smart office: Wireless sensor network for energy monitoring and user profiling. Master s thesis, KTH Electrical Engineering, August [34] D. Puccinelli and M. Haenggi. Wireless sensor networks: applications and challenges of ubiquitous sensing. Circuits and Systems Magazine, IEEE, 5(3): 19 31, ISSN X.

126 118 REFERENCES [35] Quanser. Single Inverted Pendulum - Instructor Manual. [36] Quanser. Single Inverted Pendulum - Sudent handout. [37] Quanser. Single Inverted Pendulum - User Manual. [38] B. Rubio, M. Diaz, and J.M. Troya. Programming Approaches and Challenges for Wireless Sensor Networks. Systems and Networks Communications, ICSNC Second International Conference on, pages 36 36, aug [39] P. Suriyachai, U. Roedig, and A. Scott. Implementation of a MAC protocol for QoS support in wireless sensor networks. Pervasive Computing and Communications, PerCom IEEE International Conference on, pages 1 6, mar [40] Systems, LSI Computer. LS7366R - Quadrature counter with serial interface. Technical report. URL LS7366R.pdf. Accessed September [41] Crossbow Technology. Crossbow telosb. Technical report, San Jose, California. URL Accessed August [42] TinyOS. TEPs. Technical report. URL php/teps. Accessed September [43] TinyOS. Tinyos. Technical report, URL Accessed September [44] A. Willig. Wireless sensor networks: concept, challenges and approaches. e & i Elektrotechnik und Informationstechnik, 123: , ISSN X. URL /s [45] A. Willig. Recent and emerging topics in wireless industrial communications: A selection. Industrial Informatics, IEEE Transactions on, 4(2): , May ISSN [46] A. Willig, K. Matheus, and A. Wolisz. Wireless technology in industrial networks. Proceedings of the IEEE, 93(6): , jun ISSN

127 Appendices 119

128

129 Appendix A Inverted pendulum Nomenclature Symbol x c d dt x c α d dt α F c I p M p l p B eq B p M c X A B U Description Cart linear positions Cart linear velocity Pendulum angle from the upright position Cart linear velocity Cart driving force produced by the motor Pendulum moment of inertia Pendulum mass Pendulum length from pivot to the centre of gravity Equivalent viscous damping coefficient for cart Equivalent viscous coefficient for pendulum Lumped mass of the cart system, including the Rotor Inertia State vector State-Space Matrix State-Space Matrix Control signal Table A.1: Model nomenclature 121

130 122 APPENDIX A. INVERTED PENDULUM Steps for our approach We think that it is important to show the evolution and different steps that we made to have the inverted pendulum sensing through wireless and the IEEE It could be a good section to read to whom want to reach such a challenge with its own. 1. Simulink with serial blocks: Quanser provides a large number of files with documentation, maple files with the model, matlab files with the control design and a simulink schema to run the application with its hardware or any DAC board that simulink supports, like ours. To be able to get the sensing data from the BaseStation mote instead of the DAC board, it is needed the communication between mote and PC through serial (Universal Serial Bus (USB)). But due to the use of a Real-time environment in Simulink, it was impossible to apply and use the serial blocks. 2. Simulink with S-functions Our second try was the implementation of functions to read the serial port. We had tried to program functions in C and C++, and include them as S-functions, but Simulink did not allow use the USB in any way. As we can see we tried some options with Matlab, because we think that it was the best option to apply control process, reducing delays, easy way to implement transfer functions, matrix multiplications,... but it was necessary to give it up in order to reach our challenge. 3. LabView: The next option available, once we did not find any options with Simulink, was LabView. LabView is a programs focus in the communication between external hardware and the PC. For our approach, with a high sample rate, we were quite sceptical about its behaviour but it was the unique option in mind. The control toolbox for LabView had some timing problems and it was not an option for our applications. Therefore, we continue with the MathScript toolbox which allows us to implement the control manually. When LabView was running the LQR control and controlling the pendulum in real-time, we realized that there was a huge bias between the real value read from the NI board and the value that we are receiving with the BaseStation. Moreover, there was a delay between the samples. It was around 50 ms, time that would crash the pendulum because it is a tight process. So, in this step we realized that we got a bias. This bias is due to the no task priority in the TinyOS. Although it exists some mechanism of pre-emption like task, asynchronous and synchronous functions, it was not enough to read and listen all the events coming from the DAC. The delay introduced on the samples it could be introduced by the communication between mote and PC, the buffers on the operating system, the

131 123 communication between OS and LabView, or the time to process the serial data in LabView. But we can exclude the time between the mote and PC because we know that the delay introduced by the mote is around 5 ms. 4. Labview and LS7366R to avoid bias As soon as we realized that there were nothing to improve in the mote application, the only way to continue dealing with the pendulum was the introduction of an external counter. It will liberate the mote and we will get the exact value. The counter selected was a quadrature counter with SPI communication, LS7366R [40], which provides us a wide settings and different counter configurations, and an easy communication with the mote. Finally with that external counter, we completely remove the bias but the delay problem was still there. For this, we tried to use the RS232 communication instead of using the USB. 5. LabView and LS7366R and RS232: To test the RS232, we get the data from the input of the FDMI driver, pin 25, in the mote and apply this signal to a MAX232 to converter the signal levels to a RS232 standard ones [22, Applications examples ]. But the delay accomplished with the RS232 was the same as the USB, and the packets loss increased. 6. LabView and LS7366R with Kalman filter: Following with our delay deal, we came up on the idea of estimate the state of the process and compensate the delay. For this we applied a Kalman filter with delay compensation which allowed us to predict the next state of the plant and moreover manage the delay. So, applying the estimated states to the LQR we were able to have the inverted pendulum stable for long time. Counter board Figure A.1 shows the schematic of the circuit needed for the SIP external counter. The components are: (a) 3.3 Voltage regulator, FAN2504 (b) Operational Amplifier (OPAM) LM324 (c) The SPI counter LS7366 (d) Crystal oscillator, CMACKD (e) Capacitors and resistors. The connector at the bottom (U13) is the expansion pack in the mote. LabView Figure A.4 shows the time loop used read the values from the BaseStation. Actually, we read the values from the Transport Control Protocol (TCP) port, where we are

132 124 APPENDIX A. INVERTED PENDULUM Figure A.1: Schematic of the circuit running a Serial Forwarder. Serial Forwarder check the Frame Check Sequence (FCS) and sends to LabView the correct packets. Figure A.5 shows the time loop used for compute the control output. On the left, we see the reads of the motes, as a local variables, in the middle the MathScript node where the control in calculated, and on the right we see the DAQ assistant block used to configure the DAQ board and send the output voltage back to the motor. We also used a Write measurements block in order to be able to save the data and compare them with the sniffer data.

133 125 Figure A.2: General layout with the board and the mote (a) (b) Figure A.3: Detailed layout with the board Figure A.4: Screenshot of the VI file from LabView with the time loop to read the values from the BaseStation

134 126 APPENDIX A. INVERTED PENDULUM Figure A.5: Screenshot of the VI file from LabView with the time loop for control