The improvements of power management for clustered type large scope wireless sensor networks2010

WARSAW UNIVERSITY OF TECHNOLOGY Faculty of Electronics and Information Technology The improvements of power management for clustered type large scope wireless sensor networks by Pedro de la Fuente Aragón Supervised by Daniel Paczesny, Ph.D. June 2010 Table of contents 1 Introduction ........................................................................................................................ 1 1.1 Motivation ............................................................................................................................. 1 1.2 Description ............................................................................................................................ 1 1.2.1 What is a Wireless Sensor Network ................................................................................................ 2 1.2.2 Benefits of Wireless Sensor Networks ............................................................................................ 2 1.2.3 Drawbacks of Wireless Sensor Networks........................................................................................ 3 1.3 Objectives .............................................................................................................................. 3 1.3.1 Main objectives ............................................................................................................................... 3 1.3.2 Secondary objectives ....................................................................................................................... 3 1.4 Description of the document ................................................................................................ 3 2 State of the art .................................................................................................................... 5 2.1 Introduction .......................................................................................................................... 5 2.2 The communication architecture ........................................................................................ 5 2.3 Design factors and requirements ........................................................................................ 6 2.4 The architecture of the protocol stack ................................................................................ 7 2.5 Wireless Sensor Network protocols .................................................................................... 8 2.5.1 The importance of the physical layer on Wireless Sensor Network protocols ................................ 8 2.5.2 MAC protocols .............................................................................................................................. 10 2.5.3 Routing protocols .......................................................................................................................... 16 2.6 Conclusions ......................................................................................................................... 22 3 WSN Simulators ............................................................................................................... 23 3.1 Introduction ........................................................................................................................ 23 3.2 Simulator requirements ..................................................................................................... 23 3.3 A model for WSN simulation............................................................................................. 24 3.3.1 Network model .............................................................................................................................. 24 3.3.2 Node model ................................................................................................................................... 24 3.4 Network simulators ............................................................................................................ 25 3.4.1 The Network Simulator – ns-2 ...................................................................................................... 25 3.4.2 OMNeT++ ..................................................................................................................................... 26 3.4.3 TOSSIM ........................................................................................................................................ 26 3.4.4 OPNET .......................................................................................................................................... 26 3.4.5 Ptolemy II ...................................................................................................................................... 27 3.5 Description of the OMNeT++ simulator .......................................................................... 27 3.5.1 Overview ....................................................................................................................................... 27 3.5.2 Advantages .................................................................................................................................... 34 3.5.3 Drawbacks ..................................................................................................................................... 34 3.6 Conclusions ......................................................................................................................... 34 4 Evaluation of routing protocols ....................................................................................... 35 4.1 Introduction ........................................................................................................................ 35 4.2 Direct Transmission ........................................................................................................... 35 4.2.1 Direct Transmission operation description .................................................................................... 35 4.2.2 Direct Transmission protocol implementation .............................................................................. 36 4.3 The LEACH protocol ......................................................................................................... 38 4.3.1 LEACH algorithm’s description .................................................................................................... 38 4.3.2 LEACH algorithm’s implementation ............................................................................................ 40 4.4 Conclusions ......................................................................................................................... 47 5 Simulation scenarios ........................................................................................................ 48 5.1 Introduction ........................................................................................................................ 48 5.2 Description of the simulation scenarios ............................................................................ 48 5.3 Design and Implementation of the simulation scenarios ................................................ 48 5.3.1 Implementation of a network simulation step by step ................................................................... 49 5.3.2 Implementation of the simulation network architecture ................................................................ 50 5.3.3 Initialization of the module network parameters ........................................................................... 52 5.4 Conclusions ......................................................................................................................... 54 6 Evaluation of the simulation scenarios ........................................................................... 55 6.1 Introduction ........................................................................................................................ 55 6.2 Radio model ........................................................................................................................ 55 6.3 Monitoring the network’s behavior .................................................................................. 56 6.4 Expected results .................................................................................................................. 56 6.4.1 General results ............................................................................................................................... 56 6.4.2 Comparison between Direct Transmission and LEACH results.................................................... 58 6.5 Conclusions ......................................................................................................................... 58 7 Simulation results ............................................................................................................ 59 7.1 Introduction ........................................................................................................................ 59 7.2 Parameters of the simulation tests .................................................................................... 59 7.3 Direct Transmission results ............................................................................................... 60 7.4 LEACH results ................................................................................................................... 64 7.5 Conclusions ......................................................................................................................... 66 8 Conclusions ...................................................................................................................... 67 9 Future work ...................................................................................................................... 68 10 References ........................................................................................................................ 69 11 Appendix I. Table of Specifications of the simulation scenarios ................................... 73 Index of Figures Figure 1. Wireless Sensor Network architecture ___________________________________ 5 Figure 2. Comparison between OSI model and WSN’s stack protocol architecture ________ 7 Figure 3. RF front-end and baseband processor ___________________________________ 8 Figure 4. S-MAC Messaging Scenario [5] _______________________________________ 11 Figure 5. Comparison between S-MAC and T-MAC schemes, where the arrows indicate transmitted and received messages _____________________________________________ 11 Figure 6. DSMAC duty cycle doubling [7] _______________________________________ 12 Figure 7. B-MAC concepts ___________________________________________________ 12 Figure 8. WiseMAC operation ________________________________________________ 13 Figure 9. Data gathering tree and implementation over DSMAC [10] _________________ 13 Figure 10. A timeline of four nodes running SIFT protocol, where shaded bars indicate packet transmission times and node’s contention window are shown ________________________ 14 Figure 11: CSMA operation __________________________________________________ 15 Figure 12. Classification of routing protocols in WSNs _____________________________ 16 Figure 13. Wireless sensor network model _______________________________________ 24 Figure 14. Tier-based node model _____________________________________________ 25 Figure 15. Simple and compound modules of an OMNeT++ network _________________ 27 Figure 16. Default layout of the OMNeT++ IDE __________________________________ 29 Figure 17. Graphical NED Editor _____________________________________________ 29 Figure 18. The main window of the Tkenv runtime environment ______________________ 30 Figure 19. Top level network and node component structure ________________________ 31 Figure 20. A histogram and an output vector _____________________________________ 31 Figure 21. A network simulation ______________________________________________ 32 Figure 22. Node structure and NIC structure _____________________________________ 33 Figure 23: Network interconnection in Direct Transmission protocol _________________ 35 Figure 24: LEACH cluster type organization _____________________________________ 38 Figure 25. Time line showing LEACH operation __________________________________ 38 Figure 26. Network simulation structure ________________________________________ 50 Figure 27. Node network structure _____________________________________________ 50 Figure 28. Internal node structure _____________________________________________ 51 Figure 29. Mobility and utility node modules _____________________________________ 52 Figure 30. Schema of the simulation tests _______________________________________ 59 Figure 31. Number of alive nodes with data size of 1024 bits ________________________ 60 Figure 32. Number of alive nodes with node speed of 0 m/s _________________________ 61 Figure 33. Number of alive nodes with node speed of 1 m/s _________________________ 62 Figure 34. Number of transmissions per node with data size of 1024 bits and interval of data generation of 30 s __________________________________________________________ 63 Figure 35. Number of transmissions per node with data size of 1024 bits and interval of data generation of 30 s __________________________________________________________ 63 Index of Tables Table 1. Hierarchical vs. flat topologies routing __________________________________ 18 Table 2. Classification and comparison of routing protocols in WSN [30] ______________ 21 Table 3. Radio characteristics ________________________________________________ 55 Table 4. Relation between results with different simulation scenarios _________________ 57 Table 5. First and last node dies values with data size of 256 bits_____________________ 62 INTRODUCTION 1 1 Introduction 1.1 Motivation Sensors are a high developed technology integrated into very different areas like structures, machinery or the environment. Some of the potential benefits that they provide are: prevent catastrophic failures, enhance the job safety or conservation of natural resources. However, this sensor networks are typically wired networks and present high installation and maintenance costs, making more complicated their introduction and use in the daily life. Wireless Sensor Networks (WSNs) are a new kind of communication network based in the use of new microelectronic devices called motes with sensing and data processing capabilities. This kind of networks can eliminate the installation and maintenance costs of typical sensor monitoring, in addition of its ease of installation and elimination of connectors. However, wireless devices contain battery constraints which limit the network lifetime. Due to the energy constrains, the deployment of large scope WSNs will require advanced techniques to maintain low node depletion and achieve adequate network lifetime and efficient operation. The main goal of the current research is the analysis and the deployment of power management improvements based on the state-of-the-art of Media Access Control (MAC) and network protocols by means of simulation techniques. The implementation of power management improvements over large scope WSN will enhance the network lifetime without reducing the network features and capabilities. During this chapter, a description with the fundamentals of Wireless Sensor Networks has been offered, as well as the benefits that WSN provide and the drawbacks that this kind of networks contains. 1.2 Description The aim of this document is the research about the impact of some parameter modification within the mobility, MAC and network modules into the sensors’ energy consumption. The improvements of the nodes’ power management will be found through the study of the network behavior with different parameter values and how they will affect the energy consumption. Special importance will be present on how much influences the node mobility with particular speed values. The differences in the network behavior will help to search different mechanisms to improve the power management and thus to reduce the energy consumption. For that purpose, this project expects to built a realistic simulation of a WSN with the own constraints and required features of some WSN specific scenarios where energy consumption improvements could be obtained. Initially, it is essential to insist not only on the capabilities of WSNs but also in their wide variety of applications and the benefits that provides their use. The simulated network will have the common features which are present on the majority of the up-to-date WSN implementations. Furthermore, advanced features and INTRODUCTION 2 parameters will be analyzed in order to obtain an energy consumption improvement. Therefore, it is essential to analyze and study the state of the art of the most common WSN architectures and protocols. After the analysis of the architectures and protocols present in the current WSNs, the most used simulation environments will be evaluated and the best simulation environment for the purpose of this project will be chosen and analyzed. The main job will consist on the WSN scenario creation on the chosen simulation environment and the study of the network behavior after the variation of some critical parameters in order to obtain the values which provide the best results in terms of energy efficiency and network’s functions. 1.2.1 What is a Wireless Sensor Network According to the definition given in [1], <<A wireless sensor network (WSN) consists of densely distributed nodes that support sensing, signal processing, embedded computing, and connectivity; sensors are logically linked by self-organizing means. WSN typically transmit information to collecting (monitoring) stations that aggregate some or all of the information. WSN have unique characteristics, such as, but not limited to, power constraints and limited battery life for the WNs, redundant data acquisition, low duty cycle, and, many-to-one flows.>>. Although the development of this kind of networks was motivated by military applications, nowadays they are use in many different industrial and civilian application areas, including industrial process monitoring and control, healthcare applications or traffic control. WSN are composed of a set of sensor nodes, called “motes”, typically equipped with some sensors, a radio transceiver or other wireless communications device, a small microcontroller, and an energy source, usually a battery. Therefore, these devices make up a network with sensing, data processing and routing capabilities. 1.2.2 Benefits of Wireless Sensor Networks To be knowledgeable about the benefits of WSNs, it is enough to be conscious of the wide variety of applications where WSN can be present. Typically, WSN applications involve some kind of monitoring, tracking, or controlling. Although wired sensor networks usually can develop the same function like WSNs, these last networks can be present in some applications where wired connections difficult the machinery function or are impossible to introduce, adding to the elimination of installation and maintenance costs. Some of the numerous applications and the benefits that WSN bring are: • Environmental Monitoring: watershed management, forest fire prediction or irrigation management. It helps to preserve and maintain the natural resources. • Structural Health and Industrial Monitoring: machinery failure detection. It reduces the maintenance costs and prevents from catastrophic failures. • Civil Structure Monitoring: health monitoring of large civil structures, like bridges or skyscrapers. It prevents from human catastrophes. • Medical Health-care: telemedicine, remote health monitoring. Allows doctors in remote and rural areas to consult with specialists in urban areas, remote handling of medical equipment (tele-surgery), etc. INTRODUCTION 3 1.2.3 Drawbacks of Wireless Sensor Networks Besides WSN offer several additionally advantages to wired sensor networks, they impose some important constraints, which will affect directly to the network’s and devices’ design. Into the Section 2.3 - Design factors and requirements, the main constraints and design requirements are described. Some of the most significant constraints are: • Power consumption: this constraint affects directly into the nodes’ lifetime. With energy-aware and transmitting power adjusting capacity protocols, the energy consumption can be highly reduced, and thus increased the network lifetime. • Self-configuration capability and good scalability: this issue can be solved by choosing and implementing the suitable network protocol. • Fault tolerance: if all the devices process the same signal (temperature, humidity, etc.), the network will offer replication in a native manner. If the devices do not develop the same function, the device replication can solve the fault tolerance problem, and this solution shouldn’t affect the scalability due to the nature of the network. 1.3 Objectives 1.3.1 Main objectives The main objective of the current project is the search, the development and the implementation of a power management improvement through the adaptation of existing MAC and routing protocols for specific large scope WSN scenarios by means of simulations of the network behavior. 1.3.2 Secondary objectives Diverse secondary objectives are pursued during the development of the current project: • Objectives into the election of the protocols. The protocols that should implement the network of the current project ought to fulfill specific requirements. The MAC protocol should provide a restrained energy consumption, and the routing protocol should present a cluster-type organization and provide a balanced overall energy consumption, i.e., distribute the energy consumption along the nodes in the network. • Objectives into the simulation implementation. The simulation environment should fulfill some requirements like WSN network architecture and features, portability, open source development and a good and friendly user interface. Furthermore, the network simulation implementation should make use of efficiency, independence between modules and reusability principles. 1.4 Description of the document In this document, ten chapters have been presented which presents the performed work. • In the chapter 2, the communication architecture, the architecture of the protocol stack and the featured design factors and requirement of WSNs are detailed. INTRODUCTION 4 Furthermore, the state of the art of the MAC and network WSN protocols is analyzed. • In the chapter 3, the requirements of a WSN simulation environment is analyzed. Moreover, the most common network simulation environments are analyzed. • In the chapter 4, the evaluation of the chosen WSN routing protocols is introduced through their operation description and their implementation into the simulation environment. • In the chapter 5, the network simulation scenarios are depicted, as well as the implementation of the network architecture, the physical environment and the internal node architecture. • In the chapter 6, the radio model adopted for the simulation tests and the parameters selected are described. Furthermore, a priory analysis of the results is given. • In the chapter 7, the different simulation tests made over the network are detailed, and the results obtained after the simulation execution of the different simulation scenarios are analyzed. • In the chapter 8, the obtained conclusions during the development of the whole project are detailed. • In the chapter 9, the possible improvements that could be implemented in future work are explained. • In the chapter 10, the external references consulted during the project development are listed. STATE OF THE ART 11 The advantages of this protocol consist on its implementation simplicity and its energy consumption decrease through sleep schedules. But the disadvantages are the collision probability with broadcast data packets because of the lack of a RTS/CTS schema, the efficiency loss with its constant and predefined sleep and listen periods, overhearing and idle listening problems. Figure 4. S-MAC Messaging Scenario [5] T-MAC Timeout-MAC [6] protocol is an improvement of S-MAC protocol which tries to provide higher energy saving under variable traffic load through variable listen periods. In T-MAC, listen period finishes when a node doesn’t have messages to send or receive in order to save energy. After the message exchange, the node waits an activation event for a time threshold. Although T-MAC shows better results than S-MAC, it breaks the listen period’s synchronization and, because of this and other reasons, T-MAC protocol suffers the “early sleep” problem, where a node C within the same coverage area than a node B can’t send a message to a node D because the node B is receiving a message from a node A and the node D doesn’t detect any sign of activity and switches to sleep mode. Figure 5. Comparison between S-MAC and T-MAC schemes, where the arrows indicate transmitted and received messages STATE OF THE ART 12 DSMAC Dynamic Sensor-MAC [7], also called DSMAC, is a protocol which adds dynamic duty cycle to S-MAC and attempts to decrease the latency for delay-sensitive applications. In this protocol all nodes start with the same duty cycle, and when a node realizes that average one-hop latency is high, it decides to shorten its sleep time and announces it within SYNC period. As a consequence, after a sender node receives this signal, it checks its queue for packets destined to that receiver node and decides to double its duty cycle when its battery level is above a specified threshold. In this manner, DSMAC improves the latency obtained with S-MAC and shows better average energy consumption. Figure 6. DSMAC duty cycle doubling [7] B-MAC Berkeley MAC [8] protocol comes from the University of California, Berkeley, and it achieves to decrease the idle listening. B-MAC proposes that each node must sleep periodically to check the channel occupation; if a node detects activity it remains in listening mode, otherwise it switches to sleeping mode. B-MAC defines eight different check intervals or time intervals between wake-up periods, and each one corresponds with a different listening mode. In order to assure packet delivery, packets are sent with a preamble whose length transmission is longer than the check interval. The advantages of B-MAC are the simplicity of network configuration, ease of tuning, no necessity of explicit sync packets and don’t use of RTS/CTS/ACK if not necessary. Figure 7. B-MAC concepts WiseMAC The Wireless Sensor MAC [9] protocol introduces a new communication schema with a data channel access by spatial TDMA and gives access to the control channel by CSMA. This protocol is based in a preamble sampling technique, where each data packet is preceded by a preamble in order to alert the receiver node. All network nodes sample with a common media period, but using independent relative schedule offsets. STATE OF THE ART 13 They initialize the preamble with the same sampling period’s length. During the protocol’s use, after waking and sampling the media when a node reaches an it’s occupied, stays hearing until receives a packet or finds free the media. This protocol has overemitting problems when after the preamble, the receiver is not available. Also, with the aim of reducing the energy consumption, WiseMAC offers a dynamic length definition preamble method which requires sleep schedules learning neighbor nodes, achieving to minimize the receiver nodes’ radio working time. On the contrary, the difficult of broadcast communication due to the decentralized duty cycle planning and the hidden terminal problem apparition are the main inconvenients. Figure 8. WiseMAC operation DMAC DMAC’s [10] main objective consists on obtaining a very low latency by means of a energy-efficient operation. This protocol makes use of a convergecast communication pattern, very applied on WSNs, where unidirectional paths from the possible sources to the base station can be represented with data gathering trees. DMAC can be identified as an improvement of slotted Aloha protocol, where slots are assigned to sets of nodes based on a data gathering tree similar as showed on Figure 9. In this manner, during a node reception period, all its son nodes have also the same transmission period and they compete for the media. Thus, this protocol provides low latency by assigning contiguous slots to the consecutive nodes along the transmission path. Figure 9. Data gathering tree and implementation over DSMAC [10] STATE OF THE ART 14 One of the best features of DMAC is very good latency in comparison with other sleep/listen period assignment methods. Hence, this protocol becomes a very important candidate in time-constrained applications. On the contrary, this protocol doesn’t use collision avoidance. For this reason, when a considerable number of nodes on the same level try to send data to the same node, collisions will happen. TRAMA Traffic-Adaptive MAC [11] protocol is similar to Node Activation Multiple Access (NAMA) protocol which is operation is described in [11], but this increases the use of TDMA as an energy-efficient mode. In TRAMA protocol a distributed election algorithm is used in order to select a sender inside a two-hop neighborhood. By means of this mechanism, the hidden terminal problem is eliminated and nodes inside the onehop neighborhood guarantee no collision packets will be received. In this registry, time is divided in two different transmission periods: random-access periods, where two-hop topology information through contention-based channel access, and scheduled-access. In these last ones, slots which will be used by nodes are announced by a schedule packet and the bitmap message scheduled receivers. This protocol achieves important advantages: a sleeping mode time percentage increase and a collision probability decrement in comparison with CSMA based protocols. Even so, TRAMA duty cycle is at least of 12.5%, a considerable high value. SIFT SIFT [12] is a MAC protocol for WSN whose operation differs from the above described protocols. This protocol is used on event-driven sensor network environments. Its main idea consists on the next fact: when an event is sensed, the first R reports of N potential reports composes the most important communication part, and this part must be delivered with the minimum latency. SIFT uses a non-uniform probability distribution function. This function helps to the slot acquisition within the slotted contention window: if nodes don’t transmit on the first window slot, all nodes increment exponentially its transmission probability on the next slot considering limited the number of competitors. Figure 10. A timeline of four nodes running SIFT protocol, where shaded bars indicate packet transmission times and node’s contention window are shown This protocol reaches very low latency through a power consumption increment. This parameter can be set properly to the environment requirements. Thus, it could be possible to obtain a power consumption decrement losing some features as low latency when network life time is the main objective. As disadvantages, time on idle listening is increased due to the nodes must listen all the slots before its sending, as well an overhearing increment. STATE OF THE ART 15 CSMA In Carrier Sense Multiple Access (CSMA) [13], the nodes verify the absence of other traffic before transmitting on a shared transmission medium. Two versions of CSMA exist: non-persistent CSMA and p-persistent CSMA. In non-persistent CSMA, a backoff is performed before attempting to transmit if the sensed channel is busy, and the transmission is carried out immediately if the device senses no activity on the channel. In p-persistent CSMA, a node continues sensing the channel if it detects activity instead of delaying and checking again later. When the device senses no activity on the channel, it transmits a message with probability p and delays the transmission with probability 1−p. Figure 11: CSMA operation The channel access times and backoff delays showed on Figure 11 consist of continuous values for unslotted CSMA or discrete time values for slotted CSMA. These parameters are explained below: • SIFS: the minimum Inter Frame Space. It is used to separate transmissions belonging to a single dialog (e.g. Fragment-ACK). • PIFS: it is used by the Access Point to gain access to the medium before any other station. The value of PIFS is SIFS plus a Slot time. Not important in WSN operation. • DIFS: it is the Inter Frame Space used for a station willing to start a new transmission, which is calculated as PIFS plus one Slot time. • Slot time: it is defined in such a way that a station will always be capable of determining if other station has accessed the medium at the beginning of the previous slot. This reduces the collision probability by half. Backoff is method to resolve contention between different stations willing to access the medium. The method requires each station to choose a Random Number (n) between 0 and a given number (Contention Window value), and wait for this number of Slots before accessing the medium, always checking whether a different station has accessed the medium before. The benefit of CSMA/CA techniques in sensor networks depends on the traffic conditions, wireless channel characteristics, and network topology, so in some cases it may prove beneficial and in others an unnecessary overhead. 2.5.3 Routing protocols This section presents the classification of WSN routing protocols. Routing protocols be divided into three groups depending on the network structure: hierarchical-based routing, and protocols can also be divided into five different groups depending on the protocol operation: multipathbased based routing . In addition, routing protocols can be divided into hybrid protoco ls depending on how the source fi proa ctive protocols, all routes are computed before they are needed. In reactive protocols, on the contrary, routes are computed on demand. Hybrid protocols use a combination of these two techniques. routing protocols. Detailed below are the different routing paradigms. Figure 12. Classification of routing protocols in WSNs 2.5.3.1 Network Structure Based The network structure adopts an important role in the operation of routing protocols in WSN. Next are exposed the different subgroups according to the diverse network structures. Flat routing In multihop flat routing protocols to perform the sensing task. BS sends queries to certain regions and waits for data from selected regions. This schema has been adopte makes impossible to assign a global identifier to each node. requested through queries. Hence, properties of data. In flat routing group, we can find a huge variety of protocols: • Flooding, where data is sent to all neighbors; Flooding, where data is forwarded to one randomly selected neighbor. They are the simp lest protocols, overlapping and resource blindness) and • Sensor Protocols for Information via Negotiation (SPIN) operating efficiently by sending meta view of energy resource changes. This protocol protocols through data negotiation and resource adaptive algorithms. some drawbacks , as scalab Network Structure Flat Networks Routing Hierarchical Networks Routing Location Based Routing STATE OF THE ART This section presents the classification of WSN routing protocols. Routing protocols be divided into three groups depending on the network structure: flat routing, and location-based routing . Furthermore, these same protocols can also be divided into five different groups depending on the protocol based , query-based, negotiation-based, QoSbased . In addition, routing protocols can be divided into proactive ls depending on how the source fi nds a route to the destination. ctive protocols, all routes are computed before they are needed. In reactive protocols, on the contrary, routes are computed on demand. Hybrid protocols use a combination of these two techniques. Figure 12 shows the classification of WSN routing protocols. Detailed below are the different routing paradigms. Classification of routing protocols in WSNs Network Structure Based Protocols The network structure adopts an important role in the operation of routing protocols in WSN. Next are exposed the different subgroups according to the diverse network protocols , all nodes plays th e same role and collaborate together to perform the sensing task. They make use of a data centric routing scheme, BS sends queries to certain regions and waits for data from the sensors located in the This schema has been adopte d due to the large number of nodes, which makes impossible to assign a global identifier to each node. In flat routing, data is requested through queries. Hence, attributebased naming is necessary to specify the In flat routing group, we can find a huge variety of protocols: where data is sent to all neighbors; and Gossiping Flooding, where data is forwarded to one randomly selected neighbor. They are lest protocols, but contain important drawbacks overlapping and resource blindness) and they work in a very inefficient way. Sensor Protocols for Information via Negotiation (SPIN) [15] operating efficiently by sending meta -data and being aware and answering in view of energy resource changes. This protocol solves the problems of above data negotiation and resource adaptive algorithms. , as scalab ility problems, and delivery not guaranteed. Routing protocols in WSNs Location Based Routing Protocol Operation Negotiation Based Routing Multi-Path Based Routing Query Based Routing 16 This section presents the classification of WSN routing protocols. Routing protocols can flat -based routing, . Furthermore, these same protocols can also be divided into five different groups depending on the protocol based , and coherentproactive , reactive and nds a route to the destination. In ctive protocols, all routes are computed before they are needed. In reactive protocols, on the contrary, routes are computed on demand. Hybrid protocols use a shows the classification of WSN Classification of routing protocols in WSNs The network structure adopts an important role in the operation of routing protocols in WSN. Next are exposed the different subgroups according to the diverse network e same role and collaborate together They make use of a data centric routing scheme, where the the sensors located in the d due to the large number of nodes, which In flat routing, data is based naming is necessary to specify the In flat routing group, we can find a huge variety of protocols: Gossiping [14], based on Flooding, where data is forwarded to one randomly selected neighbor. They are (as implosion, work in a very inefficient way. [15] : it is based on being aware and answering in solves the problems of above data negotiation and resource adaptive algorithms. SPIN has ility problems, and delivery not guaranteed. QoS Based Routing Coherent Based Routing STATE OF THE ART 17 • Directed Diffusion [16]: it consists basically of naming, interests and gradients, data propagation along the interest’s gradient path, and paths’ reinforcement. This protocol saves energy by selecting good paths and performing data aggregation and caching. Otherwise, data aggregation requires synchronization techniques and increments and recording information when overhead appears. There are several protocols based on Directed Diffusion:  Rumor routing [17], whose key idea is to route the queries to the nodes that have observed a particular event rather than flooding the entire network, and if flooding is needed, it employs long-lived packets called agents. Rumor routing achieves energy savings but it has scalability problems.  Gradient-Based Routing (GBR) [18], where nodes calculate a parameter called the height of the node memorizing the number of hops when the interest is diffused and forward packets on links with the largest gradient or difference between neighbor nodes’ height.  Information-driven sensor querying (IDSQ) and Constrained anisotropic diffusion routing (CADR [19]), where queries are diffused in an isotropic fashion and reaching nearest neighbors first. They query sensors and route data by maximizing information gain and minimizing latency.  Energy Aware Routing [20], which maintains a set of paths instead of or enforcing one optimal path at higher rates. It employs a kind of probability whose value depends on how low is the energy consumption of each path. It achieves to increment network lifetime. • Minimum Cost Forwarding Algorithm (MCFA) [21]: in this protocol, each node maintains the least cost estimate from itself to the base-station. Thus, nodes only re-broadcast messages to their neighbors when they check that they are in the least cost path between the source and the base-station. • COUGAR [22] and ACQUIRE [23]: these protocols view the network as a huge distributed database system. COUGAR uses declarative queries, whereas ACQUIRE can divide complex queries into several sub queries. They show energy efficiency in situations when the generated data is huge. Hierarchical routing In WSN, the concept of hierarchical or cluster based routing is utilized to perform energy efficient routing. In addition, this mechanism provides good scalability and efficient communication. Applying hierarchical architecture to WSN, higher energy nodes can be used to process and send the information while low energy nodes can be used to perform the sensing in the proximity of the target. Thus, cluster heads can perform data aggregation and fusion in order to decrease the number of transmitted messages to the BS and increment the network lifetime. However, in WSN, routing techniques are not only focused on routing, but also on “who and when to send or process/aggregate” the information, channel allocation, etc. Detailed below are several proposals of hierarchical routing protocols: STATE OF THE ART 18 • Low Energy Adaptive Clustering Hierarchy (LEACH [24]): is a self-organizing protocol that uses randomized rotation of cluster-heads to evenly distribute the energy load among the sensor nodes in the network. Although LEACH provides some added features like localized coordination and control, it can’t be applied to time-constrained applications and also presents the “hot-spot” [25] problem. • Power-Efficient Gathering in Sensor Information Systems (PEGASIS) [26]: based on LEACH, PEGASIS is a power efficient algorithm. In this protocol, each node can take turn of being a leader of the chain, where the chain is constructed using greedy algorithms that are deployed by the sensor nodes. PEGASIS outperforms LEACH in several aspects but it presents the same problems than LEACH and also doesn’t scale. • Threshold-sensitive Energy Efficient Protocols (TEEN [27] and APTEEN [28]): these two protocols, proposed for time-critical applications, are LEACH based with multi-level head clusters. They are based on two values: a hard threshold, with the threshold sense value, and a soft threshold, a small value that triggers nodes to transmit. This method reduces the number of transmissions and these values can be tuned to increment the accuracy. Both two protocols outperform LEACH, but multi-level clusters and threshold-based functions increment their complexity. • Other protocols: Small Minimum Energy Communication Network (MECN) [29], which computes an energy-efficient subnetwork by utilizing low power GPS; Sensor Aggregates Routing, whose objective is to collectively monitor target activity in a certain environment; Self Organizing Protocol (SOP), where heterogeneous sensor architecture with mobile or stationary nodes is supported; Virtual Grid Architecture routing (VGA), which uses a GPS-free approach to build clusters that are fixed, equal, adjacent, and non-overlapping with symmetric shapes; Hierarchical Power-aware Routing (HPAR), which divides the network into groups of sensors where messages are routed along the path which has the maximum over all the minimum of the remaining power (maxmin path); and Two-Tier Data Dissemination (TTDD), which provides data delivery to multiple mobile base-stations. As it is shown, there are many differences between flat and routing protocols. In Table 1 extracted from [30] these two approaches are compared. Table 1. Hierarchical vs. flat topologies routing Hierarchical routing Flat routing Reservation-based scheduling Contention-based scheduling Collisions avoided Collision overhead present Reduced duty cycle due to periodic sleeping Variable duty cycle by controlling sleep time of nodes Data aggregation by cluster head Node on multihop path aggregates incoming data from neighbors Simple but non-optimal routing Routing can be made optimal but with an added complexity Requires global and local synchronization Links formed on the fly without synchronization STATE OF THE ART 19 Hierarchical routing Flat routing Overhead of cluster formation throughout the network Routes formed only in regions that have data for transmission Lower latency as multiple hops network formed by cluster heads always available Latency in waking up intermediate nodes and setting up the multipath Energy dissipation is uniform Energy dissipation depends on traffic patterns Energy dissipation cannot be controlled Energy dissipation adapts to traffic pattern Fair channel allocation Fairness not guaranteed Location based routing Location based routing shows a different schema where nodes are by means of their location. In this kind of routing, the location of nodes can be obtained directly if nodes are equipped with a low power GPS or their relative position can be deduced by means of two facts: the distance between nodes estimated on the basis of incoming signal strengths, and relative coordinates of neighbors obtained by exchanging information between them. Energy savings can be obtained switching nodes to sleep mode when there is no activity or having as many sleeping nodes in the network as possible. Next are reviewed several location-based routing protocols: • Geographic Adaptive Fidelity (GAF) [31]: GAF divides the network area into fixed zones and forms a virtual grid. All nodes in each zone elect one sensor node responsible in its zone for monitoring and reporting data to the BS. This node will stay awake for a certain period of time and the rest of nodes will go to sleep. Thus, GAF conserves energy by turning off unnecessary nodes in the network without affecting the level of routing fidelity. • Geographic and Energy Aware Routing (GEAR) [32]: GEAR is a recursive data dissemination protocol. This protocol disseminates queries to appropriate regions whose data include geographic attributes. It achieves energy saving by sending the interest to certain regions rather than the whole network. On the contrary, GEAR is not scalable and does not support data diffusion. • MFR, DIR, and GEDIR [33]: these three protocols employ different mechanisms but they almost always obtain the same path to the destination. In MFR, the dot product of Euclidean distance between destination and neighbor node and Euclidean distance between destination an source node (i.e.,           ) is minimized. DIR method chooses the neighbor with the minimum angular distance between from the imaginary line joining the current node and the destination. In GEDIR, packets are transmitted to the neighbor of the current vertex whose distance to the destination is minimized. • SPAN [34]: this protocol selects some nodes based on their positions that will act as coordinators and will form a network backbone used to forward messages. A node is designed as coordinator when three hop reachability between nodes is not accomplished, i.e., two nodes cannot reach each other directly or via one or two coordinators. STATE OF THE ART 20 2.5.3.2 Protocol Operation Based Protocols In this subsection, some routing methods with different features and functionalities are described. Some of these methods may refer to some concrete protocol which deploys the main feature in their category. Multipath routing protocols Multipath routing mechanisms uses multiple paths in order to increase the fault tolerance of the network. These maintained alternative paths entail an increment of energy consumption and traffic overhead, but helps to increase the network reliability. Diverse researches have provided different ideas. One proposal advocates to create paths with the largest residual energy, change the path whenever a better path is discovered and switch the primary path to the backup path when the energy of the primary path falls to lower levels than the backup path. Another proposal suggests us to use a set of sub-optimal paths with the less energy consumption. This method aims to increase the network lifetime by choosing the paths by means a certain probability depending on the lower minimum energy consumption of each path. Directed diffusion is also a good protocol for robust multipath routing and delivery. Query based routing In query based routing, base station or destination nodes propagate a query through the network. These queries usually use natural or high-level query languages. All nodes have tables with sensing task queries that they receive and nodes having the data associated to this query sends the data back to the node which made the query. Several protocols use query based routing. For instance, in Directed Diffusion, interest messages are propagated through the network and gradient paths are set up and. When the source has data for the interest, the source sends the data along the interest gradient path. Another example is Rumor routing protocol, which uses a set of long-lived agents to create paths that are directed towards the events they encounter. Negotiation based routing Negotiation based protocols use high level data descriptors in order to eliminate redundant data transmissions through via negotiation. This idea aims to suppress duplicate information and prevent redundant data from being sent to the next sensor or the base-station. This is achieved by exchanging a series of negotiation messages before the real data transmission is carried out. One example of negotiation based routing is the family of SPIN protocols, which uses this mechanism and prevents from implosion and overlapping. QoS-based routing Networks with QoS-based routing protocols have to ensure some QoS factors, as for example, low delay, bandwidth, delivery, etc. when sending data to the base stations. However, this kind of protocols applied to WSN has to balance between energy consumption and data quality. Some routing protocols bring several QoS features to WSN. For instance, in Sequential Assignment Routing (SAR) [35], routing decisions are made depending on three factors: WSN SIMULATORS 27 3.4.5 Ptolemy II Ptolemy II [42] is an open-source software framework supporting experimentation with actor-oriented design, similar to component-based design. It includes Java packages that support different models of simulation paradigms (e.g. continuos time, dataflow, discrete-event). It also addresses the modeling, simulation and design of concurrent, real-time, embedded systems. VisualSense [43] is a modeling and simulation framework for WSN built on Ptolemy II. Models can be developed by subclassing base classes of the framework or by combining existing Ptolemy models. Thus, Ptolemy and its IDE components assure a simple and intuitive graphical composition of models. 3.5 Description of the OMNeT++ simulator 3.5.1 Overview OMNeT++ with MiXiM plugin complies with the specific requirements and provides the required tools for the development of the project. 3.5.1.1 Modeling concepts As we can look up on the OMNeT++ User Manual [44], OMNeT++ models consist of modules which communicate with message passing. The active modules are termed simple modules, and they are written in C++. Compound modules are made up of simple modules or other compound modules. Thus, the number of hierarchy levels is not limited. This architecture allows reusing the well-built modules and, moreover, allows implementing and customizing new modules with additional features. The whole model, called network, is also a compound module. The picture below shows the OMNeT++ network structure with different modules. Arrows connecting small boxes represent connections and gates. Figure 15. Simple and compound modules of an OMNeT++ network Modules communicate with messages, which are typically sent via gates. Gates are the input and output interfaces of modules. An input and an output gate can be linked with a connection. Connections spanning across hierarchy levels are not permitted. Messages typically travel through a chain of connections, to start and arrive in simple modules. Parameters such as propagation delay, data rate and bit error rate, can be assigned to connections. Connection types with specific properties (termed channels) can also be defined and reused them in several places. Modules can have parameters. They can take WSN SIMULATORS 28 different values: string, numeric or boolean, and they are mainly used to pass configuration data to simple modules, and to help define model topology. Thanks to its design and its structure, OMNeT++ provides efficient and useful tools for the user to describe the system. Some features of OMNeT++ are: • hierarchically nested modules • modules communicate with messages through channels • flexible module parameters • topology description language 3.5.1.2 The OMNeT++ simulation IDE The OMNeT++ simulation IDE is an extension of Eclipse development platform with new editors, views and other functionality like tools for creating and configuring models and analyzing the simulation results. For further information, it’s available an OMNeT++ IDE User Guide [45]. The Workbench Eclipse is a very flexible system where you can manage different panels, editors and navigators. The OMNeT++ IDE provides a “Simulation Perspective” to work with simulation related NED, INI and MSG files. Next are explained the meaning of these file extensions. • The NED language topology description(s) (.ned files) describe the module structure with parameters, gates etc. • The Message definitions (.msg files) define different message types and add data fields to them. • The Configuration file (.ini files) contains settings that control how the simulation is executed, values for model parameters, etc. The main window showed above on Figure 16 contains different and useful panels: • The Project Explorer shows the projects and their content in your workspace. • The Properties View contains the information on the object selected in the editor area • The Problems View references the code lines where Eclipse encounters a problem • The Module Hierarchy, NED Parameters and NED Inheritance View are with the network topology and its modules. • The Console View shows the results of the executions. WSN SIMULATORS 29 Figure 16. Default layout of the OMNeT++ IDE The manner of creating models and networks is identical to the way of creating programs under Eclipse platform. The workspace is the directory where all your projects are located and can be linked. Additionally, OMNeT++ provides specific editors for the simulations. The graphical NED editor, showed on Figure 17, helps to improve the visual network structure for a better understanding of the user, and INI file editor helps to edit the file with contains the configuration of simulation runs. Figure 17. Graphical NED Editor WSN SIMULATORS 30 The Graphical Runtime Environment The Tkend runtime environment, built in Tcl/Tk, is a portable graphical windowing user interface which supports interactive execution of the simulation, tracing and debugging. It is recommended in the development stage of a simulation since it allows one to get a detailed picture of the state of simulation at any point of execution and to follow what happens inside the network. Some important features are: • message flow animation • graphical display of statistics and output vectors during simulation execution • event-by-event, normal and fast execution • inspector windows to examine and alter objects and variables in the model • scheduled messages can be watched in a window as simulation progresses Figure 18. The main window of the Tkenv runtime environment The main window of the Tkend environment showed on Figure 18 show different parts: • The toolbar includes the access to the main functions of Tkenv like run, stop and start or finish the simulation and configure the visual appearance. • The status bar contains the information about the current state of the simulation like the current run number and network name and the current event number, information about the number of messages and the events processed. • The timeline displays the content of the FES on a logarithmic time scale. • The object tree displays all inspectable objects currently present in the memory. • The log window contains the output of the simulation. The window content can be filtered to include messages only from specific modules WSN SIMULATORS 31 Figure 19. Top level network and node component structure The top level network window shows the network structure. This window enables to explore the component hierarchy in a graphical mode. Networks and compound modules are represented by graphical inspectors displaying their internal structure. Each component can be inspected as object, as graphic or as module output and these different possibilities shows the component contents, its graphical internal structure and its output messages and events, respectively. The top level network and node component structure are showed above on Figure 19. Figure 20. A histogram and an output vector Furthermore, this environment can show output vectors in real-time as showed above on Figure 20. If any component contains an output vector, Tkenv will show a chart by double clicking on the object. WSN SIMULATORS 32 3.5.1.3 MiXiM MiXiM [46] (mixed simulator) is a simulator for wireless and mobile networks using the OMNeT++ simulation engine. This simulator combines various simulation frameworks developed for wireless and mobile simulations in OMNeT++. MiXiM provides detailed models of the wireless channel (fading, etc.), wireless connectivity, mobility models, models for obstacles and many communication protocols especially at the Medium Access Control (MAC) level. Thus, MiXiM provides detailed models and protocols, as well as a supporting infrastructure which can be divided into five groups: • Environment models: it reflects the relevant parts of the real world, such as obstacles or other elements which hinder wireless communication. • Connectivity and mobility: the simulator tracks the movement of nodes and the variations on the influence between nodes and provides an adequate graphical representation. • Reception and collision: the reception handling is responsible for modeling how a transmitted signal changes on its way to the receivers considering the movement of objects and nodes and transmissions making by other senders. • Experiment support: it helps the researchers to compare the results and supports different evaluation methods. • Protocol library: it enables researchers to compare and to share their ideas. This simulator appears as the fusion of different simulator frameworks into one. These frameworks contribute with different approaches to MiXiM: the Mobility Framework (MF) with its mobility support, connection management, and general structure; the CHannel SIMulator (ChSim) with their radio propagation models; and the protocol library from the MAC simulator and the Positif framework. Through its low memory consumption and its modular structure, MiXiM can support simulations with more than 1000 nodes. The graphical configuration interface helps to manage the model and it allows modifying some parameters, filtering the resulting information and adapting the level of detail and thus the execution time. Figure 21. A network simulation WSN SIMULATORS 33 The general structure of MiXiM shows two different parts [47]: • The simulation modules: a MiXiM network contains a “world” utility model which defines the environment properties like the size of the terrain, the kind of terrain simulation (2D or 3D) and different “objects” to model the environment of a simulation. The “ConnectionManager” module manages dinamically the connections between interfering nodes, where the signal quality is based on the interferences and the mobility. Finally, the “nodes” make up the network. MiXiM supports different kind of nodes (like Access Points and terminals) with different properties. An example of a MiXiM network is showed on Figure 21. • The node structure: the nodes contain the modules according to the ISO/OSI architecture, together with other sensor specific and utile modules like the battery module, the mobility module, the arp module and the utility module, as it is showed on Figure 22. The layers of an IP model can be composed by the application layer (appl), the network layer (netw), the MAC layer (mac) and the physical later (phy). The physical and MAC layer are grouped into a Network Interface Card (NIC) module. The mobility module is responsible for the movements of a node or an object. The battery module is used to simulate the power consumption and properties. The arp module handles the Address Resolution Protocol (ARP), and the utility module provides a general interface for collecting statistical data of a simulation and maintains parameters that need to be accessed by more than one module within a node. Figure 22. Node structure and NIC structure WSN SIMULATORS 34 3.5.2 Advantages The combination of OMNeT++ with MiXiM provides numerous features which allow implementing a very detailed simulation in comparison with other WSN simulators. Some of the best features of OMNeT++ with MiXiM are the differentiation between the network structure (implemented with NED) and the network behavior (implemented in C++). They also provide a set of important models like battery, power and propagation models, providing much more functionality and flexibility than other simulators with the lack of some of these modules like GloMoSim, SENS, ATEMU, Prowler and Shawn. OMNeT++ and MiXiM are Open Source, have a very useful graphical support for debugging, support parallel simulation and show a very good scalability to large networks (more than 100 nodes), overtaking other simulators like NS-2 with worse scalability. Furthermore, OMNeT++ is supported by a community site of software developers with several useful features like a mailing list. 3.5.3 Drawbacks OMNeT++ with MiXiM show several drawbacks in comparison with other WSN simulators. The main drawback consists on the fact that OMNeT++ is a general purpose simulation framework and, for that reason, it only supports a limited emulation or Realtime OS/SW execution time modeling, unlike specific simulation tools like ATEMU, EmStar or TOSSIM. Other minor drawback consists on the lack of MAC protocols and the inexistence of any routing protocol. This drawback can be solved by the developer through the implementation of the required protocols. OMNeT++ also doesn’t provide a huge variety of MAC or routing protocols as other simulators like NS-2 or OPNET do. Because of this, the users need to resort to some extensions or some implementations done by the community. 3.6 Conclusions After this chapter, we can ensure that OMNeT++ with MiXiM appear as a very good solution to implement and test the behavior of large scope wireless sensor networks. This simulation framework meets the majority of the simulator requirements explained above and also provides some important features for this project like very good scalability unlike other simulators do. The simulation structure facilitates the design and the test of large scope wireless sensor networks, its graphical runtime environment helps the user with the debugging and tracing tasks, providing better understanding of the network behavior, and MiXiM extension provides the advanced and specific modules required to simulate our sensor network. EVALUATION OF ROUTING PROTOCOLS 35 4 Evaluation of routing protocols 4.1 Introduction The routing protocol is a fundamental piece for the network operation. It will determine the network behavior. Furthermore, the network layer will add some additional features depending on the protocol implementation and the network requirements During this section, the operation and implementation of two different protocols is offered. This fact will help to understand the diverse features that two different protocol implementations will provide. The first one, the Direct Transmission operation, is the simplest implementation of a routing protocol. The second one, the LEACH protocol has acquired great importance due to the fact that it has been the base for numerous network protocol improvements. In this manner, the protocol’s behavior and its main parameters can be studied in order to obtain any improvement. In this chapter, the two mentioned algorithm are described and analyzed. This analysis will help us with a better understanding of the protocol’s behavior for a further design and implementation into the chosen simulator, and therefore, to obtain a completely coherent protocol implementation from with the given description 4.2 Direct Transmission 4.2.1 Direct Transmission operation description The Direct Transmission protocol is the simplest routing protocol. In the Direct Transmission protocol, the base station serves as the destination node to all the other nodes in the network as showed on Figure 23, where the end user can access the sensed data. The nodes only remain active during the data transmission to the base station. Consequently, won’t spend energy on receiving the messages from the other nodes, but they will only spend the minimum data on listening the channel and, therefore, they will spend their battery capacity on sending messages to the base station. Figure 23: Network interconnection in Direct Transmission protocol On the other hand, when a sensor node transmits data directly to the base station, the energy loss incurred can be quite extensive depending on the location of the sensor nodes relative to the base station. As a result, the Direct Transmission protocol’s complexity can be negligible and its implementation quasi-trivial, but it is also the least energy efficient protocol in most cases. EVALUATION OF ROUTING PROTOCOLS 36 4.2.2 Direct Transmission protocol implementation 4.2.2.1 Direct Transmission NED implementation The Direct Transmission NED description (DirectTransmission.ned) is implemented as a simple module extending the BaseLayer module and implementing the IBaseNetwLayer interface 1 . The first parameter that contains the Direct Transmission description is a direct reference to the Direct Transmission C++ class. The description also contains three parameters required by the IBaseNetwLayer interface and used by some Direct Transmission superclasses (from Direct Transmission C++ implementation). 4.2.2.2 Direct Transmission C++ implementation The Direct Transmission C++ implementation consists of two different files: the DirectTransmission.h file, which contains forward declarations of variables, structures and subroutines, and DirectTransmission.cc, which contains the implementation the Direct Transmission protocol operation. DirectTransmission.h file The Direct Transission class implementation extends from the BaseNetwLayer class. The implementation of this simple protocol only contains one variable declaration: int droppedMsgs; This variable, also declared into the LEACH implementation, is a counter which accumulates the number of dropped messages that comes from the MAC layer. On the next chapter is detailed the whole utility and use of this variable. Next are declared the subroutines required by Direct Transmission. These are divided in two parts: a public subsection and a protected subsection. The public subsection only contains one declaration: virtual void finish(); This function performs value recording in some prefixed output files. Finally, the protected subsection is declared with three subroutine declarations: 1 For further information, visit the MiXiM API reference: http://mixim.sourceforge.net/doc/doxy/main.html simple DirectTransmission extends BaseLayer like IBaseNetwLayer { parameters: @class(DirectTransmission); //Required *IBaseNetwLayer* parameters bool debug; // debug switch bool stats; // stats switch double headerLength @unit(bit); // length of the network // packet header (in bits) } EVALUATION OF ROUTING PROTOCOLS 43 Next are described the declared functions: • handleSelfMsg handles the messages sent to itself. The self message within the LEACH protocols work as timers, e.g., the timer used on launching a new LEACH round, or the timer used when the transmission slot is reached. • handleUpperMsg and handleLowerMsg handle the messages which comes from the upper and the lower layer, i.e., from the application and the MAC layer. • encapsMsg is in charge of encapsulating a higher packet layer into a network packet with the associated header. • handleLowerControl handles the control messages that comes from the lower layer, i.e., the MAC layer. The last subsection is the private subsection. It contains the function declarations associated to the LEACH operation. Below are described the mentioned functions: • calculateThreshold calculates the threshold for a node within the current stage. It is calculated on the beginning of the Advertisement Phase. • advertisementPhase , clusterSetUpPhase , scheduleCreation and dataTransmission contains the protocol operation during the different phases. advertisementPhase and dataTransmission contains functionality for cluster-head and non-cluster-head nodes but clusterSetUpPhase only contains functionality for non-cluster-head nodes, and scheduleCreation functionality for cluster-head nodes. This is due to the fact that, for example, during the luster Set-Up Phase, only the non-cluster-head nodes initiate the phase and prepare a “join” message to send to the best cluster-head. Therefore, cluster-head nodes only must wait for the “join” messages. That’s why their phase functionality is described into the handleLowerMsg function, when the message is received. In the case of the Schedule Creation Phase, the situation is the same but on the other way round with non-cluster-head and cluster-head nodes. • setHighTxPower sets the transmitting power to a high value in order to make a long-distance cluster-head – base station transmission. setLowTxPower gets back the normal transmitting power. ... private: /** @brief Calculates the threshold value to be Cluster Head */ double calculateThreshold(); /** @brief Executes the Advertisement Phase steps */ void advertisementPhase(); ... /** @brief Sets the MAC transmission power to low range*/ void setLowTxPower(); }; EVALUATION OF ROUTING PROTOCOLS 44 LEACH.cc file The LEACH.cc file implements the whole functionality of LEACH protocol. The implementation of LEACH protocol is designed as follows: the LEACH network messages interchange carries out the cluster set-up, whereas the use of timers performs the switching between different phases or LEACH rounds. For a better understanding, the LEACH functionality has been divided into C++ functions with the same LEACH phase name. Therefore, the LEACH functionality is implemented by means of four functions that implement the majority of the protocol behavior, four functions that carry out different message handling tasks, and five functions of small functionality. Before the protocol operation, the LEACH class requires the call of the next function: void LEACH::initialize(int stage); This function is called two times (during two initializing stages). During the first initialization stage, all the parameters from the NED file are got and the addresses, counters and other variables are initialized. During the second initialization stage, the timer for the first LEACH round is activated. Detailed below are the functions which implement the LEACH functionality: • void LEACH::advertisementPhase(): this function implements the LEACH Advertisement Phase. The function starts with a call to the function calculateThreshold . If a random obtained value between 0 and 1 is less than the returned threshold, the node became cluster-head: it will update the lastRoundCH variable and will broadcast a “CH announce” message (with CH_STATUS_BROADCAST message kind, the node source address – myNetwAddr – and L3BROADCAST address as destination address). If the random value is higher, the node will be non-cluster-head: it will wait for “CH announces”. Here a timer is activated ( timerNextStage ). If after a waitingTime the node don’t receive any “CH announce”, it goes to the next phase. • void LEACH::clusterSetUpPhase(): this function implements the LEACH Cluster Set-Up Phase. Within this phase, only the non-cluster-head node’s behavior is implemented. Thanks to the distanceToCHs structure, the node chooses the nearest cluster-head node, sets myCH variable and sends it a “join CH” message (with JOIN_CH message kind, the node source address - myNetwAddr – and myCH address as destination address). After sending the message, non-cluster-head nodes wait to the “TDMA schedule” message. The Cluster Set-Up Phase functionality for cluster-head nodes is implemented into the handleLowerMsg function. • void LEACH::scheduleCreation(): this function implements the LEACH Schedule Creation Phase. Within this phase, only the cluster-head node’s behavior is implemented, and they will create a “TDMA schedule” message (with TDMA_SCHEDULE message kind, the node source address – myNetwAddr – and L3BROADCAST address as destination address). This packet will contain a list with the cluster members’ network addresses, i.e., the transmitting slot position associated to each cluster member. After broadcasting this packet, cluster-head nodes will wait to receive all the data packets from the cluster members to perform data compression and send the data to the BS. The Schedule Creation EVALUATION OF ROUTING PROTOCOLS 45 Phase functionality for non-cluster-head nodes is implemented into the handleLowerMsg function. • void LEACH::dataTransmission(): this function implements the LEACH Data Transmission Phase. For the non-cluster-head nodes, when the transmission slot is reached, the procedure consists on setting the packet addressee and sending the packetToSend stored packet if a new application packet has been received, and waiting for a new LEACH round. When clusterhead nodes start to execute this function, they will have received all the noncluster-head node data packets. Therefore, they get all the data from the stored packets and apply data compression. This process is simulated by creating a data packet whose packet size will be the application of the compression index after the sum of all the cluster member stored data packet sizes. This packet will have the same message kind of any of the data stored packets, the cluster-head node source address – myNetwAddr – and L3BS address as destination address. Before sending the packet, the cluster-head nodes call the setHighTxPower function to be able to reach the BS. After sending the packet, cluster-head nodes switch to normal transmitting power and wait for a new LEACH round. Next are described the message handling functions: • void LEACH::handleUpperMsg(cMessage* msg): this function only calls the encapsMsg function with the received application packet as parameter, and stores the network packet resulting from the call. The message will be sent on the next transmission slot if the application layer doesn’t send another message before. In this case, the last stored message will be overwritten. • void LEACH::handleLowerMsg(cMessage* msg): this function handles the packets that comes from the MAC layer. As it was mentioned above, the functionality of some phases is implemented into this function. Therefore, this function is responsible of the correct communication between cluster-head and non-cluster-head nodes. The function’s behavior depends on the message kind:  CH_STATUS_BROADCAST messages should be managed by non-clusterhead nodes during the Advertisement Phase. They, by means of a “special” class, Distance.h, calculate the distance to the message source, which is a cluster-head node, and stores it into the distanceToCHs structure. After that, they reactivate the timerNextStage with a new waitingTime to receive new “CH announces” or going to the Cluster Set-Up Phase. If a cluster-head node receives this message, it just deletes it.  JOIN_CH messages should be managed by cluster-head nodes during the Cluster Set-Up Phase. They save the message source into the membersCH address if the MAX_CLUSTER_SIZE is not reached, which means that this node will be a cluster member. After that, they reactivate the timerNextStage with a new waitingTime to receive new “Join CH” messages or going to the Schedule Creation Phase. If a non-cluster-head node receives this message, it just deletes it.  TDMA_SCHEDULE messages should be managed by non-cluster-head nodes during the Schedule Creation Phase. If the message source is it clusterhead node, the non-cluster-head node look for its transmission slot. If it EVALUATION OF ROUTING PROTOCOLS 46 doesn’t find the slot, it means that the node doesn’t belong to any cluster and it must wait for the next LEACH round. If the node finds its slot, it should switch its state to SLEEP mode and wait for its transmitting slot (activates the timerNextStage with my_slot*slotTime time). If the node has the first slot, it just calls the dataTransmission function. If a cluster-head node receives this message, it just deletes it.  The rest of the messages are supposed to be DATA_MESSAGE . Therefore, only cluster-head nodes will handle this kind of messages during the Data Transmission Phase, and they will just store the message into the netwQueue structure. If a non-cluster-head node receives this message, it just deletes it. • void LEACH::handleSelfMsg(cMessage* msg): this function is in charge of handling self messages, which are used as timers in the OMNeT++ model. Timers are activated by cluster-head and non-cluster-head nodes depending on the phase at which they are:  When TIMER_NEW_ROUND is received, which is activated by all the nodes, a new LEACH round starts. currentRound counter is increased by 1, host state is switched to ACTIVE , timerNextRound is activated again with roundTime time and the AdvertisementPhase function is called.  When TIMER_JOIN_CH is received, means that non-cluster-head nodes won’t receive any more “CH announce” message. If nodes have received any “CH announce”, they switch to the Cluster Set-Up Phase.  When TIMER_CREATE_TDMA_SCHEDULE is received, it means that noncluster-head nodes won’t receive any more “Join CH” message. Therefore, they switch to the Schedule Creation Phase with a scheduleCreation function call.  When TIMER_SEND_DATA is received, which is activated by both clusterhead and non-cluster head nodes, means that their transmission turn has arrived. Host state is switched to ACTIVE mode, the transmission begins with the dataTransmission function call, and host state is switched again to SLEEP mode until the next round arrives. • void LEACH::handleLowerControl(cMessage* msg): this function handles the MAC control messages. If the handled control message kind is BaseMacLayer::PACKET_DROPPED , droppedMsgs counter value will be increased by 1. For the rest of the functions, the description given into the above section is enough. Finally, when the simulation has finished, a call to the next function is made: void LEACH::finish(): This function only records the droppedMsgs value into an output file. EVALUATION OF ROUTING PROTOCOLS 47 4.4 Conclusions After choosing the protocols that are interesting to research about any improvement, it is important to study how they work and how they behave. The analysis of each protocol phase provides a global idea about how it works but also a near knowledge about the operation step by step. As it has been shown, the design and implementation of a new protocol is not a trivial task. A correct design will provide a good codification architecture, which also will help with a better understanding and ease of debugging. The implementation model should be clear and it should use the minimum required resources in order to obtain efficient results when the protocol operation is moved to a real implementation. The two different protocols presented, Direct Transmission and LEACH, show a completely different behavior. Whereas Direct Transmission offers simplicity, LEACH provides advanced features as scalability, robustness and energy savings in most cases at the expense of a more complex protocol implementation and network organization. These features of each protocol are reflected into the simulation protocol’s implementation: the Direct Transmission protocols requires a simply implementation, whereas LEACH implementation requires a more complex node organization, message handling and data management. SIMULATION SCENARIOS 48 5 Simulation scenarios 5.1 Introduction When a research requires performing any simulation, a description of the simulation scenario and specific requirements is needed. A description of the simulation scenario will help to understand the problem and address the solution in a more efficient way. Furthermore, a detailed description allows reproducing the simulation scenario in different simulation environments for any improvement or comparison study. The implementation of the simulation scenario of this research will be build over the MiXiM framework. This fact will help to reuse the framework modules, will provide a faster and more robust implementation and, extending the framework functionality, the network behavior and simulation results could be adapted to our requirements. 5.2 Description of the simulation scenarios Direct Transmission is a protocol for WSN which offers simplicity and acceptable results in specific circumstances and scenarios, and LEACH protocol is a selforganizing protocol which provides good scalability. For this reason, the aim of the present research consists on the study of the behavior of large scope WSNs with different routing possibilities. The present document will study the behavior of a network where nodes send data to the base station with different network protocols. In general terms, the network will be made up of a hundred nodes scattered randomly in a 1000×1000m area and a fixed base station. The network nodes will contain a battery module with a predetermined battery power and they will also have some constant speed mobility. The node radio transmitting power will be 500mW, but the data transmissions to the base stations will require 10W power. The MAC layer will use CSMA MAC protocol and the application layer will generate data in a regular manner with a predetermined data generation period and a prefixed data size. A further simulation scenario description can be found in Appendix I. Table of Specifications of the simulation scenarios. The simulations will obtain diverse results from two different routing protocols: Direct Transmission and LEACH. Furthermore, the behavior within both two protocols will be studied by means of changing the value of some important parameters like the data size, the time between two sensing acts or the speed of the nodes. 5.3 Design and Implementation of the simulation scenarios The simulation scenarios have been built over the MiXiM framework. In this manner, a typical structure from a MiXiM example simulation has been taken. SIMULATION SCENARIOS 49 5.3.1 Implementation of a network simulation step by step The network simulation implemented in this document follows the implementation architecture of MiXiM framework. Therefore, the general steps for the creation of a MiXiM network are detailed 1 : • For the creation of an OMNeT++ Project, follow the next indications from the menu bar: File    New    OMNeT++ Project… In the new window, select the desired project name and push “Finish” button. • For the use of the MiXiM framework in the implementation, the MiXiM resources should be included following the next indications from the project’s pop-up menu: Properties    Project References  Select “MiXiM” project. • The MiXiM framework contains a basic network implementation. This implementation can serve as base for specific implementations. Therefore, the network files should be copied from the next MiXiM folder 2 : . /MiXiM/examples/baseNetwork • For the creation of specific modules, the following files should be created:  Network Description File (.ned file): this file will contain the specific parameters, submodules, gates, etc. It can extend, and thus, specialize parent modules. For the file creation from the pop-up menu: New    Network Description File (ned)  C++ class: following the programming principles, two files should be created: a header class, with the variables and subroutines declaration, and a source file, with the codification of the behavior. For the file creation of these files from the pop-up menu: New    Class (OMNeT++) • For the integration of the created modules into the network simulation, the network description file (BaseNetwork.ned) or the node description file (BaseNode.ned) must be edited with the specific module inclusion. • The following consists on editing the content of the configuration file (omnetpp.ini) should be edited with the initialization of the network parameters and the declaration of the specific modules created for the network simulation. • The last step consists on running the simulation of the network created. Before launching the execution, the project must be built following the next indications from the menu bar or the pop-up menu: Project    Build Project For the simulation execution, the next steps should be followed from the omnetpp.ini file’s pop-up menu: Run as    OMNeT++ Simulation… The Tkenv runtime environment will appear with the created simulation. 1 For information about the OMNeT++ operation basics and the implementation of simple networks visit: http://www.omnetpp.org/doc/omnetpp41/tictoc-tutorial/ 2 For further information about the base network MiXiM implementation visit: http://sourceforge.net/apps/trac/mixim/wiki/HowToStart 5.3.2 Implementation of the simulation network Our simulation scenario s have The network structure is defined into the Figure All the modules from the above architecture are from MiXiM framework. Next is described their function: • BaseNetwork: is the simulation parent module (the • Extended BaseWorldUtility: like playground size (adds some value recording at the end of the simulation nodes during the network lifetime • ConnectionManager: their connection s accordingly it doesn’t mean that they can understand it. • BatteryNode: defines the • Node: defines the base station’s structure. The node structure is defined into the the NIC definition). The node network Figure The functionality of the node network • DataGenerator: is responsible of “sensing” and data generation. The sensing period (ti me between two sensing samples) must be given as input parameter ExtendedBaseWorldUtility ConnectionManager DataGenerator like IBaseApplLayer SIMULATION SCENARIOS Implementation of the simulation network architecture s have been built from the baseNetwork si mulation example. is defined into the BaseNetwork.ned as showed below: Figure 26. Network simulation structure from the above architecture are from MiXiM framework. Next is is the simulation parent module (the System module). BaseWorldUtility: contains global utility methods and parameters like playground size . Extends from BaseWorldUtility MiXiM’s framework (adds some value recording at the end of the simulation , as the number of alive nodes during the network lifetime ). ConnectionManager: checks if any two hosts can hear each other and updates s accordingly . If two hosts are connected and can hear anything, it doesn’t mean that they can understand it. defines the node’s structure of our simulation. defines the base station’s structure. The node structure is defined into the BaseNode.ned file (and the file BaseNic.ned node network architecture is organized as follows: Figure 27. Node network structure node network modules is detailed below: is responsible of “sensing” and data generation. The sensing me between two sensing samples) and other values like the data size must be given as input parameter s. BaseNetwork ConnectionManager node[numNodes]: BatteryNode BatteryNode <NetwProtocol> like IBaseNetwLayer BatteryNic BatteryCSMAMacLayer 50 mulation example. below: from the above architecture are from MiXiM framework. Next is module). contains global utility methods and parameters MiXiM’s framework , as the number of alive checks if any two hosts can hear each other and updates . If two hosts are connected and can hear anything, BaseNic.ned for is organized as follows: is responsible of “sensing” and data generation. The sensing and other values like the data size baseStation: Node BatteryPhyLayer SIMULATION SCENARIOS 51 • <NetwProtocol>: carries out the networking functions. Into this module will be present two different possibilities in different simulations: DirectTransmission and LEACH. The complete functionality of these two possibilities within this module is detailed in Section 4.2 and 4.3 respectively. • BatteryNic: it simulates the Network Interface Controller (NIC). It is made up of the MAC and the PHY layer:  BatteryCSMAMacLayer: implements the CSMA MAC protocol. Extends from CSMAMacLayer MiXiM’s framework (adds some transmitting power switching capacity required by LEACH to make high power transmission to the base station).  BatteryPhyLayer: implements the physical layer. Extends from PhyLayer MiXiM’s framework (adds some parameters for energy consumption calculation 3 ). The node network modules are interconnected similarly as the OSI network architecture. Therefore, when a message is sent, it will start from the application layer; will go through the network and MAC layer until it reaches the physical layer. When a message is received, the inverse procedure takes place. Figure 28. Internal node structure Internally, the MiXiM framework implements this behavior by means of the handle message functions. For instance, when a layer sends a packet to the lower layer through the sendDown call, the lower layer will handle the message by means of the handleUpperMsg function, and when a layer sends a packet to the upper layer through the sendUp call, the upper layer will handle the message by means of the handleLowerMsg function. For the control message interchange, the operation is the same, but using the sendControlDown , sendControlUp calls and the handleUpperMsg and handleUpperControl functions. 3 A special importance for the evaluation of the simulation scenario has the energy consumption model. For further information, see Section 6.2 Furthermore, the nodes contain some other functionality: Figure Next is detailed the battery, • BaseUtility: t his mandatory module a black board like subscribe and publish feature which is used t information. • BaseArp: used by BaseNetwLayer • ExtendedConstSpeedMobility defines current position and the movement pattern of the node. class extends from linear constant speed • Battery and MyBatteryStats module for collecting battery statistics. must be given as input parameters The base station structur e is architecture is also made up of the application layer, the network layer, the MAC layer and the physical layer. The differences consist on the application and the network layer: the base st ation is only data receiver (data drain). Therefore, its application layer won’t generate any data (this class will be called route any packet: they will only handle class will be called BSNetwLayer constraints. Thus, the base station will use the of CSMAMacLayer which recognizes the BS MAC and network addresses, PhyLayer module. Owing to the base station doesn’t have battery constraints; it doesn’t implement a battery module and battery statistics collector module. Due to the mobility module is mandatory for the node implementation, the base station will use the ExtendedConstSpeed Mobility 5.3.3 Initialization of the module network parameters The initialization of the network parameters is made through the a simulation initialization file required to set the initial simulation values. Next is shown a brief example of the simulation’s BaseUtility BaseArp SIMULATION SCENARIOS the nodes contain some other functionality: Figure 29. Mobility and utility node modules battery, mobility and utility node modules: his mandatory module contains node wide utility methods, mainly a black board like subscribe and publish feature which is used t o publish statistic BaseNetwLayer and BaseMacLayer for address resolut ExtendedConstSpeedMobility : IBaseMobility is a m andatory module which defines current position and the movement pattern of the node. class extends from ConstSpeedMobility MiXiM’s framework, which defines speed mobility (adds some minor required functionality). and MyBatteryStats : implements a simple battery module and a utile module for collecting battery statistics. The battery capacity and other values must be given as input parameters e is quite similar to the node structure. The base station network architecture is also made up of the application layer, the network layer, the MAC layer and the physical layer. The differences consist on the application and the network layer: ation is only data receiver (data drain). Therefore, its application layer won’t (this class will be called BSApplLayer) , and its network layer won’t route any packet: they will only handle messages coming from the lower layer BSNetwLayer ) . Furthermore, the base station doesn’t have battery constraints. Thus, the base station will use the BSCSMAMacLayer , a simple subclass which recognizes the BS MAC and network addresses, Owing to the base station doesn’t have battery constraints; it doesn’t implement a battery module and battery statistics collector module. Due to the mobility module is mandatory for the node implementation, the base station will use the Mobility implementation with a speed value of 0. Initialization of the module network parameters The initialization of the network parameters is made through the omnet.ini file required to set the initial simulation values. Next is shown example of the simulation’s omnet.ini file: BatteryNode BaseArp ExtendedConstSpeedMobility like IBaseMobility Battery 52 contains node wide utility methods, mainly o publish statistic for address resolut ion. andatory module which defines current position and the movement pattern of the node. The selected MiXiM’s framework, which defines a (adds some minor required functionality). a simple battery module and a utile The battery capacity and other values The base station network architecture is also made up of the application layer, the network layer, the MAC layer and the physical layer. The differences consist on the application and the network layer: ation is only data receiver (data drain). Therefore, its application layer won’t , and its network layer won’t messages coming from the lower layer (this . Furthermore, the base station doesn’t have battery , a simple subclass which recognizes the BS MAC and network addresses, and the Owing to the base station doesn’t have battery constraints; it doesn’t implement a battery module and battery statistics collector module. Due to the mobility module is mandatory for the node implementation, the base station will use the implementation with a speed value of 0. omnet.ini file. This is file required to set the initial simulation values. Next is shown MyBatteryStats SIMULATION RESULTS 59 7 Simulation results 7.1 Introduction The simulations results are the objective evidences which demonstrates how is the operation of the implemented network and how the consumption of resources happens. Hence, a correct analysis of the obtained results with graphical representations will allow making some comparisons, extracting adequate conclusions and anticipating a preliminary search of improvements. Even though there hasn’t been possible to show simulation results about the LEACH protocol behavior, the general and specific problems are enumerated, in addition to the following steps into future versions of this project. This description will help to prevent from experiencing the same suffered problems. The Direct Transmission results will show its behavior depending on the data size and the interval of data generation. The mobility conditions will also demonstrate how significant the existence of node mobility into the energy consumption is. 7.2 Parameters of the simulation tests In order to obtain multiples results, a series of test has been prepared for the different routing protocols described above. This series of test will determine how the network behaves with a specific routing protocol and fixed parameters. In consequence, the values which demonstrate the best network behavior for each protocol can be obtained. Furthermore, it can be compare how influence the same values into the different protocols. Next on Figure 30 is showed a schema with the diverse test for different values and the obtained network behavior. Figure 30. Schema of the simulation tests SIMULATION RESULTS 60 The simulation variables and its values are described below: • Node speed: it fixes the speed of the nodes in the simulation field, in meters per second. The nodes will describe a constant and linear movement and, when the area limit is reached, it fixes a new direction. The values for the tests will be: 0 (static nodes), 1, 2 and 4 m/s. • Sensing time: it defines the time between two consecutive sensing acts, in seconds. This value determines when a data packet is generated, but not when it is sent to the base station. For instance, in LEACH protocol, the time between different transmissions is fixed by the round time. The values for the tests will be: 30, 60 and 120 s. • Data size: it determines the size of the data sent to the base station, in bits. The bigger data size, the larger amount of data sent to the base station. It can be result obvious the fact that a bigger data size will offer worse results, but, for example, in several scenarios could be more interesting to increase the data size and also the time between two sensing acts to obtain less energy consumption. The values for the tests will be: 256, 512 and 1024 bits of data size. 7.3 Direct Transmission results The simulation results of Direct Transmission protocol obtained from the execution of the simulation scenarios are shown during this subsection. The first analysis showed on Figure 31 consists on the study of the tendency of the energy consumption by means of the number of alive nodes with a fixed data size of 1024 bits and variability in the interval of data generation and the speed of the nodes. Figure 31. Number of alive nodes with data size of 1024 bits The chart showed above on Figure 31 demonstrates that there is a big difference between the static and the dynamic simulation scenario in terms of node mobility. Into SIMULATION RESULTS 61 the chart can be distinguished very clearly four different tendencies corresponding to the interval of data generation. Within these four tendencies, significant differences cannot be appreciated except when the speed of the nodes is 0. In these cases, the shape of the number of alive nodes curve is decreasing exponential. The meaning of these tendencies consists on the fact that, after the moment of the death of the first node, the rest of the nodes will continue dying in a decreasing exponential manner, i.e., the number of alive nodes will decrease more quickly after the death of the first node, but during the execution time, the number of alive node will decrease in a more and more slowly manner. For the rest of the tendencies with a not null mobility value, the tendency showed is quasi-linear. The meaning of these tendencies consists on the fact that, after the moment of the death of the first node, the nodes from the simulated network continue dying in a quasi-uniform manner. The next analysis consists on how much affects the interval of data generation and the data size for a fixed speed of the nodes. Figure 32. Number of alive nodes with node speed of 0 m/s The chart showed on Figure 32 illustrates the behavior of the network in different scenarios for a node speed of 0 meters per second. Into this chart, the shape of the curve of the energy consumption when the network is static can be distinguished clearly. Furthermore, three zones with overlapped curves can be appreciated. These zones are corresponded with the similar quantities of data generated per minute during the simulation and mentioned in Section 6.4.1. These similar zones demonstrate that the node energy consumption is proportional to the amount of data generated per unit of time. Furthermore, it can be seen that the number of alive nodes during the time is almost duplicated when the amount data generated per unit of time is reduced to the half part, and also the number of alive nodes during the time is almost quadruplicated when the amount data generated per unit of time is reduced a fourth of the reference value. SIMULATION RESULTS 62 Figure 33. Number of alive nodes with node speed of 1 m/s The chart showed on Figure 33 illustrates the behavior of the network in different scenarios for a node speed of 1 meter per second. The shape of the curves within this chart differs notably from the shape of the curves showed on Figure 32. This difference comes directly from the mobility of the network as it was described above. This chart distinguishes once again three zones where the curves are overlapped, and they correspond with the quantity of data generated per minute during the simulation, with similar interpretation. Analyzing the differences between the two last charts, it is easy to recognize that the network lifetime in the static network is much longer than the network lifetime in the dynamic network. The comparison of the values shows that the network lifetime in a static network is around 50 times longer than in a network with node mobility of 1m/s for different data size and interval of data generation values as showed in Table 5. Nevertheless, in the dynamic network can be appreciated that the nodes die in a more uniform manner, whereas in the static network, the nodes die from the further zones to the closer zones to the base station. Furthermore, the moment when the first node dies into the dynamic scenarios is greater than two times than the value in comparison with the static scenarios is showed on Table 5. A similar behavior has been observed with speed values of 2 and 4 meters per second, and the rest of data size and intervals of data generation scenarios. Table 5. First and last node dies values with data size of 256 bits Data size = 256 bits sensing_time = 30 s sensing_time = 60 s sensing_time = 120 s v = 0 m/s v = 1 m/s v = 0 m/s v = 1 m/s v = 0 m/s v = 1 m/s First node dies (in s) 2570.22 5450.31 5135.22 12578.34 10265.22 28146.71 Last node dies (in s) 560088.84 12172.21 1120173.84 20313.88 2240343.84 39902.11 SIMULATION RESULTS 63 Finally, the last two analyses have the purpose of demonstrate the drawbacks of the static scenarios in terms of energy balance in comparison with dynamic scenarios. The chart showed on Figure 34 illustrates the number of transmissions to the base station for each node for a data size of 1024 bits and an interval of data generation of 30 seconds. As it can be appreciated, in the static network scenario, there is a big difference between the number of transmissions of nodes located near to the base station and nodes located far from the base station. Hence, even though the network lifetime is decreased, the node mobility influences positively to the network energy consumption balance. Figure 34. Number of transmissions per node with data size of 1024 bits and interval of data generation of 30 s The last chart showed on Figure 35 illustrates how is distributed the energy consumption along the network. A notably difference between the tendency of the curve in the static scenario and the dynamic scenarios is appreciated. Whereas the dynamic scenarios show a relative small difference between the average energy per transmission of all nodes, the difference within the static scenario between the closest and the furthest node to the base station greater than 20 times. Figure 35. Number of transmissions per node with data size of 1024 bits and interval of data generation of 30 s 0 1000 2000 3000 4000 5000 6000 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 Number of transmissions Nodes ordered by distance to the base station Number of transmissions per node with data size of 1024 bits and sensing 30 s v = 0 m/s v = 1 m/s v = 2 m/s v = 4 m/s v = 0 m/s v = 1 m/s v = 2 m/s v = 4 m/s 0 0,005 0,01 0,015 0,02 0,025 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 Average energy per transmission (in Joules) Nodes ordered by distance to the base station Average energy per transmission with data size of 1024 bits and sensing 30 s v = 0 m/s v = 1 m/s v = 2 m/s v = 4 m/s SIMULATION RESULTS 64 7.4 LEACH results Owing to impossibility of finishing the LEACH protocol implementation, simulation results about the LEACH protocol operation couldn’t be obtained. During this subsection, the general and the specific caused of the impossibility of finishing the LEACH implementation are detailed. In addition, the remaining work to obtain correct LEACH operation results and protocol improvements is described. The general factors which hindered to finish successfully the research are presented below: • Insufficient time: the project’s schedule has been altered several times during the development of the project. The main cause has been the increment of the complexity because of the advent of new difficulties. • Insufficient personnel: the lack of information and resources and the presence of bugs into the simulation environment have been one of the main reasons of the experienced delay. A research group consisting of two or three members would have helped to identify the experienced problems and provide some possible solutions. The specific factors and problems that made the development of the project difficult are detailed below: • Huge protocol variety to research: due to the fact that WSN are a new technology, an absence of protocol standards is present This fact difficult the analysis of the current MAC and network protocols and also complicates the election of the suitable protocols for the present study. Currently there exists numerous MAC protocols for WSN, but the WSN constraints have caused that there is a big quantity of basic routing protocols and innumerable lines of research about specific improvements of any routing protocol. • Diversity of simulation environments: the variety of simulation environments, each one with their own features, but also with their own language syntax, made difficult to carry out a clear comparison between them. The general simulation environments required a specific framework to obtain a WSN simulation because they didn’t support the simulation of WSN in native manner, but these frameworks are relatively new and specific of specific researches. Therefore, outside from the framework scope, a lack of unity between modules and presence of bugs has been found. On the other hand, the specific simulation tools, which in include the simulation of the node operating system, or even emulation of the memory mapping, would have added an unnecessary complexity to the current research. • Instability of the simulation environment: several bugs and stability problems were experienced. A major bug 1 was found and reported to the project’s direction. Furthermore, numerous simulation environment crashes happened during the architecture node construction, code implementation, debugging and 1 Reported bug: imposible to make a 2 nd extend into the OMNeT++ hierarchy. Impossible to extend from BaseNetwLayer class, which extends from BaseLayer class. Solution: Ext2NetwLayer was modified to extend from BaseLayer. Further information can be found in: http://dev.omnetpp.org/bugs/view.php?id=88 SIMULATION RESULTS 65 simulation runs were experienced. These facts hampered the progressive project development and, therefore, retarded and hindered the LEACH results achieving. • Absence of ready-to-use protocol implementations: the lack of ready-to-use protocols has remarkably reduced the flexibility and the possibility of testing different options within the simulation environment. The whole implementation of the network architecture and the used protocols has been needed, and debugging, specific corrections and protocol operation tests have been required. • Complexity of the simulation architecture: the module and class hierarchy is so extensive and interrelated that makes extremely difficult the debugging process. The process of sending an airframe requires the use of numerous and interconnected classes from the nodes, the channel and the simulation environment. This fact, together with the environment instability and the bugs found into the used framework made extremely complex the process of finding the origin of the obtained errors during the execution. • Lack of documentation into the API of the used framework: the procedure of looking up into the used framework’s API showed that there is a lack of description in several classes and subroutines. This fact, together with the complexity of the simulation architecture described above, made difficult to understand the simulation operations and more difficult the search of specific functionality • Bugs found into the used framework: several implementation bugs where found into the framework implementation. The first bug 2 made an error into the network address resolution through the MAC address. The second bug 3 , with mayor severity, blocked the energy draw process and hindered the node energy consumption. The process of finding and solving the errors contributed to the simulation development delay. As it has been expounded in Section 4.3.2, the full LEACH protocol operation has been implemented. Therefore, the remaining steps to finish the whole research are explained below: • Check the LEACH protocol correct behavior: it is necessary to check the correct behavior of the implemented protocol by means of error debugging, modification of operation problems derived from protocol understanding difficulties and protocol operation tests execution. • Results achieving: the next step consists on running the set of tests in order to obtain data results and prepare descriptive graphical representations of the obtained results. 2 Reported bug: wrong information given by the getNetwAddr(const int macAddr) subroutine, line 54, within the BaseArp.cc class: http://mixim.sourceforge.net/doc/doxy/a00005.html 3 Reported bug: implementation error into the DrawAmount constructor class made the value initialization impossible: http://mixim.sourceforge.net/doc/doxy/a00062.html SIMULATION RESULTS 66 • Analysis and comparison of results: the following step consists on making a correct analysis with the obtained simulation results and extracting some conclusions about the protocol operation. • Design ad implementation of power management improvements: after having results about how the LEACH protocol behaves with specific values should happen one important step: to plan the design and the implementation of a LEACH energy consumption improvement from the obtained results. • Comparison and measurement of results: the last step will consist on comparing the results obtained from the implemented protocol improvement with the base protocol and measure with specific values how important has been the power management improvement. 7.5 Conclusions During this chapter has been reflected how the mobility of the network, besides the network lifetime is reduced, delays the moment when the first node dies and also introduces uniformity during the node depletion process with Direct Transmission protocol. This fact represents that the network energy consumption is more balanced than in a static network scenario and, therefore, the nodes will die in a regular manner and not from the further places to the closer zones to the base station. Thus, the simulated network won’t have any place in the simulation field without sensing data while the whole network keeps alive. Although simulation results from the LEACH protocol couldn’t be obtained, the experienced problems suffered during the project development have been reflected in order to avoid these problems during future revisions and the guidelines for further versions have been specified. CONCLUSIONS 67 8 Conclusions In the current document, the implementation of a WSN architecture in a simulation environment has been carried out. This implementation will evaluate different simulation scenarios of large scope clustered-type networks. The purpose of the implementation consists on the research and the obtaining of a power management improvement over LEACH, one of the present WSN network protocols. The search of the power management improvement will be performed through the analysis of the network behavior. This network will be obtained by means of simulation executions after the variation of values of specific parameters characteristic of the WSN operation. As a result of the WSN communication architecture, their design factors and requirements, the state of the art of the network and Medium Access Control WSN protocols, and the properties of the simulation scenarios, the election of the MAC and routing protocols has been carried out according to the features and the constraints of WSNs, as well as the features of the simulation scenarios. The analysis about the WSN protocols carried out showed that CSMA, with its simplicity, its well-know behavior and adequate performance; and LEACH, with its clustered type organization, the balance of the overall energy consumption that carries out and its relevance on the current researches, become suitable protocols suitable for the carried out research. The election of the simulation scenario was carried out in regard to compliance with the necessary requirements for the implementation of a WSN architecture, as well as other features which facilitate the implementation development. The analysis carried out about the most common WSN simulation environments showed that OMNeT++, together with MiXiM development framework, meet the majority of the simulation requirements thanks to the simulation structure, the WSN simulation capabilities and the graphical runtime environment, which facilitates the design, debugging and test of large scope wireless sensor networks. The evaluation of the simulation scenarios has been specified with the highest detail as possible. This fact will help the obtaining of simulation results and the reproduction of the tests in other simulation environments. These simulation tests showed about Direct Transmission protocol how the mobility of the network, besides the network lifetime is reduced, delays the moment when the first node dies and also introduces uniformity in during the node depletion process, providing in that manner a more balanced overall energy consumption. Besides it couldn’t be possible to obtain simulation results about the LEACH protocol operation, the experienced problems during the project development have been reflected and the guidelines for further versions have been specified. Therefore, it can be determined that the WSN architecture implemented perform the obtaining of desired results during the development of this project, and could serve as base implementation for future versions of the developed work. FUTURE WORK 68 9 Future work The guidelines for finishing all the objectives from the current study have been detailed in Section 7.4. After obtaining the results about the LEACH protocol operation, the design and implementation of power management improvements over the LEACH operation can be carried out through different alternatives or possibilities. Multiples lines of research are about energy consumption improvements over LEACH have been made and are also currently open. Some possibilities are introduced in [24]: • Energy-aware threshold: the inclusion of an energy level parameter into the calculation of the threshold during the Advertisement Phase will enable the election of the cluster head nodes in relation to the amount of energy of the nodes scattered in the simulation field. Thus, the overall energy consumption of the network would be more balanced. • Hierarchical clustering: the LEACH version implemented in this project can be extended to form hierarchical clusters. In this manner, a hierarchy could be built where the cluster head nodes would communicate with “super-cluster head” nodes and so until the top layer of the hierarchy, at which point the data would be sent to the base station. This architecture could save tremendous amount of energy in large networks WSN as the network scenario of the current project. Furthermore, there are other multiple different possibilities for the research of energy consumption improvements. Some possibilities are described below: • Better integration between MAC and network protocols: the MAC protocols described in this document provide different features. The correct integration of other MAC protocols with LEACH could provide a notably decrement of the overall energy consumption. Possible examples could be WiseMAC, which reduces the energy consumption, or TRAMA, which increases the sleeping mode time percentage and decrements the collision probability in comparison with CSMA based protocols, • Modification of the LEACH operation: some modifications over the LEACH protocol operation could provide better results in terms of overall energy consumption. One possible modification is described below. <<At the beginning of each LEACH round, the base station broadcasts a “round starts” message to the entire network. The nodes that have been elected themselves cluster head nodes broadcast its “cluster head status” message. Furthermore, in this message, they attach the signal strength of the base station broadcast that they received. At this point, if any other cluster head node listen the “cluster head status” message, it compares its base station received signal strength with the signal strength attached in the cluster head node message. If the value in the “cluster head status” message is smaller, it stores the source of the message as “router node”. When the Data Transmission Phase begins and the cluster head nodes have received all the messages from the cluster members, if the cluster head nodes have stored any “router node”, they will send their data to this node instead of sending the message directly to the base station>>. Although can be thought that this scenario could show the “hot spot” problem, can be considered that the network mobility can solve this problem. Furthermore, this new functionality can be disabled when the node energy level reaches a specific threshold.