Thesis
Reference
Visualization techniques for wireless sensor networks
KARAGIANNIS, Marios
Abstract
Les réseaux de capteurs sans fil, comme tous les réseaux sans fil, dépendent de facteurs environnementaux qui affectent leur fonctionnement. A cet effet, les chercheurs ont besoin d'outils qui leur permettent de mesurer ces facteurs, et d'évaluer leur impact sur la performance des algorithmes et des protocoles de communication en phase de recherche et développement. Les réseaux de capteurs sans fil on ceci d'unique que chaque capteur pris individuellement n'a qu'une utilité marginale, alors que le réseau pris dans son ensemble accomplit des tâches complexes. Ces réseaux peuvent être composés d'un très grand nombre de capteurs dans des configurations continuellement changeantes, ce qui peut rendre le suivi des opérations particulièrement difficile. Les outils traditionnels de visualisation de graphes y sont d'une certaine utilité, mais les caractéristiques spécifiques des réseaux de capteurs rendent nécessaire le développement d'outils de visualisation spécialisés. Dans ce mémoire de thèse, nous présenterons notre approche pour la conception des outils de visualisation et pour leur évaluation [...]
KARAGIANNIS, Marios. Visualization techniques for wireless sensor networks. Thèse de doctorat : Univ. Genève, 2012, no. Sc. 4500
URN : urn:nbn:ch:unige-266036
DOI : 10.13097/archive-ouverte/unige:26603
Available at:
http://archive-ouverte.unige.ch/unige:26603
Disclaimer: layout of this document may differ from the published version.
1 / 1
D´epartement d’ informatique Professeur Jos´e Rolim
Visualization Techniques for Wireless Sensor Networks
TH` ESE
pr´esent´ee `a la Facult´e des sciences de l’Universit´e de Gen`eve pour obtenir le grade de Docteur `es sciences, mention informatique
par
Marios KARAGIANNIS
de Ath`enes, Gr`ece
Th`ese No 4500
GEN`EVE
Centre d’impression de l’ Universit´e de Gen`eve 2012
Aristotle
This thesis explores different techniques that can be used to visualize several aspects of Wireless Sensor Networks research. We will present software tools and setups as well as different scenarios which benefit from our approach. The utility of our visualization techniques as well as having real-time and time-delayed visualization systems will be explored in both simulated wireless sensor networks as well as physical real deployed sensors forming wireless sensor networks.
Les r´eseaux de capteurs sans fil, comme tous les r´eseaux sans fil, d´ependent de facteurs environnementaux qui affectent leur fonctionnement. A cet effet, les chercheurs ont be- soin d’outils qui leur permettent de mesurer ces facteurs, et d’´evaluer leur impact sur la performance des algorithmes et des protocoles de communication en phase de recherche et d´eveloppement. Les r´eseaux de capteurs sans fil on ceci d’unique que chaque cap- teur pris individuellement n’a qu’une utilit´e marginale, alors que le r´eseau pris dans son ensemble accomplit des tches complexes. Ces r´eseaux peuvent tre compos´es d’un tr`es grand nombre de capteurs dans des configurations continuellement changeantes, ce qui peut rendre le suivi des op´erations particuli`erement difficile. Les outils tradition- nels de visualisation de graphes y sont d’une certaine utilit´e, mais les caract´eristiques sp´ecifiques des r´eseaux de capteurs rendent n´ecessaire le d´eveloppement d’outils de vi- sualisation sp´ecialis´es.
Dans ce m´emoire de th`ese, nous pr´esenterons notre approche pour la conception des outils de visualisation et pour leur ´evaluation dans des conditions d’utilisation r´ealistes.
Les outils de visualisation pour r´eseau de capteur sans fil peuvent tre passifs (on se contente d’observer l’ex´ecution d’algorithmes), ou actifs (en cas de simulation, on peut modifier les conditions environnementales en temps r´eels, dans un but p´edagogique ou exp´erimental). Nous ´etudierons plusieurs applications qui ont des besoins de visualisa- tion sp´ecifiques et proposons des solutions sur mesure qui offrent une efficacit´e sup´erieure aux outils g´en´eriques de visualisation.
Cette th`ese est organis´ee de la mani`ere suivante :
Le premier chapitre pr´esente les r´eseaux de capteurs sans fils et la fonction des outils de visualisation dans un contexte acad´emique (recherche, enseignement) et industriel (util- isateur final). Nous y approfondissons quelques applications et quelques particlarit´es de ces r´eseaux.
Au deuxi`eme chapitre est d´ecrit le simulateur WSNGE et sa suite logicielle. Il s’agit d’abord d’un ensemble d’outils qui permettent de simuler des r´eseaux de capteurs sous divers scenarios de mani`ere rapide, facile et efficace.
La d´efinition des scenarios peut consister simplement en un d´eploiement al´eatoire de capteurs, mais peut ´egalement tre plus complexe, et notament inclure des aspects g´eographiques tels qu’obstacles de forme sp´ecifique, etc. La suite WSNGE permet
`
a l’utilisateur de concevoir compl`etement ses propres sc´enarios ou d’utiliser une bib- lioth`eque de mod`eles existants. Une fois un sc´enario mis en place, la simulation peut se d´erouler pendant une dur´ee pr´e´etablie ou jusqu’`a remplir les conditions d’arrt. L’utilisateur peut alors exploiter toute les donn´ees statistiques de la simulation. De plus, notre plate- form permet de suivre en temps r´eel l’ex´ecution de la simulation. Cette visualisation
´
etape par ´etape permet de comprendre en d´etails puis de faire la d´emonstration du com- portement des algorithmes exp´erimentaux. Enfin, cette suite a ´et´e conue sp´ecialement pour s’int´egrer ais´ement et efficacement `a d’autres syst`emes de simulation suivant les besoins des utilisateurs. Bien que WSNGE ait d’abord ´et´e conu pour la communaut´e
de capteurs mais aussi pour tout autre type de r´eseau sans fil. Nous argumenterons les avantages, les nouveaut´es et les nouvelles possibilit´es offertes par notre approche, notamment `a la communaut´e scientifique et `a l’´etude r´eseaux de capteurs.
Au cours du troisi`eme chapitre nous pr´esenterons le visualisateur IRIDA et sa suit logi- cielle, ainsi que plusieurs scenarios d’application. La suite IRIDA a ´et´e d´evelopp´ee dans l’optique d’aider l’´evaluation des simulations et des exp´erimentations sur le terrain des algorithmes pour r´eseaux de capteurs sans fil. Elle se d´ecompose en trois parties : - Le firmware IRIDA pour capteur. C’est une impl´ementation portable du protocole IRIDA qui s’ex´ecute en parall`ele des algorithmes test´es et fournit les informations cruciales sur la simulation. - L’unit´e de contrle IRIDA (ICU). Ce module rassemble et organise toutes les informations collect´ees sur le terrain ou par le simulateur, et les transmet au om- dule de visualisation. - L’unit´e de visualisation IRIDA (IVU). Ce module s’enregistre aupr`es d’un module ICU et permet la visualisation en temps r´eel ou en temps diff´er´e d’un r´eseau. Le module IVU peut prendre plusieurs formes qui d´epend du mat´eriel de visualisation (projecteurs, smartphone, ordinateur de bureau, etc.). Plusieurs modules de visualisation peuvent s’enregistrer aupr`es d’un mme module ICU et permettre ainsi la visualisation simultan´ee d’une exp´erience sur diff´erentes plateformes situ´ees localement
`
a travers internet. Dans ce chapitre nous d´ecririons aussi plusieurs extensions d’IRIDA qui s’adressent aux besoins particuliers de plusieurs applications, et notament une ex- tension qui permet la localisation en temps r´eel de capteurs `a l’int´erieur de btiments afin d’appr´ecier la performance de divers algorithmes de localisation.
Le quatri`eme chapitre est consacr´e `a des techniques sp´ecifiques de visualisation qui sont moins compl`etes mais plus l´eg`eres et d´evelopp´ees pour des applications sp´ecifiques. En effet, la visualisation concerne ´egalement les donn´ees ´evolu´ees produites par les r´eseaux de capteurs. Nous d´eveloppons deux scenarios en particulier.
Le premier sc´enario a consist´e `a ´etudier le profil de connectivit´e des antennes radio des capteurs iSense. L’exp´erience a consist´e `a d´eployer des capteurs `a 84 endroits sp´ecifiques situ´es sur une matrice 7*12 et observ´es `a partir de six points de vue fixes. L’exp´erience s’est situ´ee `a 60 cm du sol afin de minimiser l’effet de r´eflexion des ondes radio au niveau du sol. Les points de la matrice de d´eploiement ´etaient quant `a eux espac´es de 50 cm.
Le deuxi`eme sc´enario a consist´e `a pister un ´el´ement mobile ou immobile dans un es- pace clos (ensemble de bureaux) dans lequel un r´eseau de capteurs avait ´et´e d´eploy´e.
L’exp´erience s’est d´eroul´ee au laboratoire TCS (Theoretical Computer Science Sensors) de l’universit´e de Gen`eve en utilisant notament des capteurs commerciaux et des robots mobiles. Un algorithme de pistage existant a ´et´e d´eploy´e eta ainsi pu tre ´evalu´e (per- formance, maniabilit´e) dans des conditions r´eelles d’utilisation.
Enfin, nous concluerons cette th`ese au cinqui`eme chapitre.
This work could not be completed without the valuable help of valuable people.
My parents, Thanasis and Stela, who taught me that everything is achievable, as long as you want it bad enough.
My wife Lia, who took care, and still is, of so many important things in my life.
My supervisor, prof. Jose Rolim, who always understood better than anyone that people need space to achieve their goals.
My friend, Dr. Olivier Powell who helped me when I needed it the most.
Ce travail n’aurait pˆut ˆetre r´ealis´e sans l’aide pr´ecieuse de quelques personnes d’importance:
mes parents, Thanasis et Stela, qui m’ont appris que rien n’est impossible `a celui qui le d´esire suffisamment; ma femme, Lia, qui continue de m’´epauler sur tant d’aspects im- portants de ma vie; mon directeur de th`ese, le Professeur Jos´e Rolim, pour son in´egal´ee compr´ehension de l’importance d’avoir de l’espace pour arriver `a ses fins et mon ami le Docteur Olivier Powell, pour son aide au moment le plus opportun.
vii
Abstract iv
R´esum´e de la th`ese v
Acknowledgements vii
List of Figures xi
List of Tables xiii
1 Introduction 1
1.1 Sensing the environment and networks . . . 1
1.2 The wireless sensor network (WSN) vision and example applications . . . 2
1.3 WSN and the internet - the internet protocol version 6 (IPv6) protocol and the IPv6 low power wireless personal area network (6LoWPAN) concept 3 1.4 Visualization aspects . . . 4
1.5 Research questions . . . 5
1.6 Guide to Reading Thesis . . . 5
2 The WSNGE simulator toolkit 7 2.1 Simulating WSN . . . 7
2.2 Additional tools for simulations . . . 9
2.3 The GUI . . . 10
2.4 Previous work . . . 12
2.4.1 Nam, the VINT Network Animator . . . 12
2.4.2 Shawn . . . 13
2.4.3 OMNeT++ . . . 14
2.4.4 DAP/ADAPT . . . 15
2.5 WSNGE Architecture . . . 16
2.5.1 Internal data abstraction . . . 18
2.5.2 Obstacles and faults . . . 19
2.6 The GUI as a monitor and an online interactor . . . 20
2.7 Scripting . . . 21
2.8 Case Study . . . 22
2.9 Conclusion . . . 29
viii
3 The IRIDA visualization toolkit 30
3.1 Introduction . . . 30
3.2 Related Work . . . 31
3.3 Hardware used . . . 32
3.3.1 Testbed . . . 32
3.4 Implementation details . . . 33
3.4.1 The reporting pipeline . . . 33
3.4.2 The reporting protocol . . . 37
3.4.3 Visualization . . . 39
3.5 Proof of concept algorithm . . . 40
3.6 Extending Irida . . . 41
3.6.1 Localization and previous work . . . 41
3.6.2 Theory . . . 42
3.6.3 Algorithm . . . 43
3.6.4 Experimental setup . . . 44
3.7 Conclusion . . . 45
4 Ad-hoc visualization 48 4.1 Ad-hoc offline data visualization scenario . . . 48
4.1.1 Layout . . . 48
4.1.2 Results . . . 49
4.2 Basic real time ad-hoc visualization scenario . . . 55
4.2.1 Hardware . . . 55
4.2.2 The experimental testbed . . . 58
4.2.3 Topology . . . 59
4.2.4 Mobility . . . 60
4.2.5 Networking . . . 62
4.2.6 The tracking algorithm . . . 63
4.2.6.1 Target detection . . . 63
4.2.6.2 Trace spread . . . 63
4.2.6.3 Spread inhibition mechanism . . . 64
4.2.6.4 Tracking . . . 64
4.2.7 Implementation aspects . . . 65
4.2.7.1 The reporting pipeline . . . 65
4.2.7.2 The visualization algorithm . . . 67
4.2.8 Performance measurements . . . 68
4.2.8.1 Scenario 1 . . . 68
4.2.8.2 Scenario 2 . . . 68
4.2.8.3 Scenario 3 . . . 70
4.2.8.4 Scenario 4 . . . 70
4.2.9 Conclusion . . . 73
4.3 Ad-hoc offline visualization scenario with data processing using visualized elements . . . 73
4.3.1 Our approach . . . 75
4.3.2 Method 1 . . . 79
4.3.3 Method 2 . . . 79
4.3.4 Method 3 . . . 79
4.3.5 Examples of applications . . . 80
4.3.6 Modeling Error in Distance Estimates . . . 80
4.3.7 Application to RSSI based methods . . . 82
4.3.8 Evaluation . . . 85
4.3.8.1 Simulation Environment . . . 85
4.3.8.2 Simulation Results . . . 86
4.4 Conclusion . . . 89
5 Conclusion 91 5.1 Thesis summary . . . 91
5.2 Evaluation of research questions . . . 92
5.2.1 Question 1 . . . 92
5.2.2 Question 2 . . . 92
5.3 Final thoughts . . . 93
A Hardware 95 A.1 The iSense platform . . . 95
A.2 The WaspMote platform . . . 97
B Publications 100 B.1 WSNGE: A Platform for Simulating Complex Wireless Sensor Networks Supporting Rich Network Visualization and Online Interactivity . . . 100
B.2 Multilateration: Methods For Clustering Intersection Points For Wireless Sensor Networks Localization With Distance Estimation Error . . . 101
B.3 LQI values heat-map with iSense hardware technical report . . . 101
B.4 Passive target tracking: Application with mobile devices using an indoors Future Internet testbed . . . 101
B.5 Irida: A real-time Wireless Sensor Network visualization feedback protocol101 B.6 Fine-grained in-door localisation with Wireless Sensor Networks . . . 102
C Irida Protocol 103
Bibliography 107
2.1 WSNGE Simulator Toolkit: The High-level Architecture . . . 17
2.2 WSNGE Simulator Toolkit: Two Interacting Simulated Entities . . . 18
2.3 WSNGE Simulator Toolkit: The Main Simulation Window . . . 23
2.4 WSNGE Simulator Toolkit: Controls of the Simulation . . . 24
2.5 WSNGE Simulator Toolkit: Auxiliary Display showing a stage of local- ization . . . 26
2.6 WSNGE Simulator Toolkit: Gabriel subgraph of a network with obstacles 27 2.7 WSNGE Simulator Toolkit: Executing 8 instances of the routing protocol 28 2.8 WSNGE Simulator Toolkit: Detailed view on a second viewport of an execution of 8 instances of the routing protocol . . . 29
3.1 4x4 grid testbed running Irida . . . 33
3.2 4x4 grid testbed running Irida . . . 34
3.3 7x7 grid testbed running Irida . . . 34
3.4 7x7 grid testbed running Irida . . . 35
3.5 7x7 grid testbed running Irida . . . 35
3.6 7x7 grid testbed running Irida . . . 36
3.7 7x7 grid testbed running Irida . . . 36
3.8 Irida architecture . . . 38
3.9 Fine-grained localization base locations . . . 44
3.10 Fine-grained localization mobile mote locations . . . 45
3.11 Irida extension for fine-grained localization visualization . . . 46
3.12 Irida extension for fine-grained localization visualization . . . 46
4.1 The grid. Dashed squares show the locations of the gathering stations while the black circles show all the possible locations of the sole mobile mote. The hex values are the IDs of the gathering stations at each location 50 4.2 Testbed picture 1 . . . 52
4.3 Testbed picture 2 . . . 52
4.4 Testbed picture 3 . . . 53
4.5 Crane-like construction for mobile node . . . 53
4.6 Close up on the mobile node . . . 54
4.7 Average LQI values for all position as seen from gathering station 1bf0 . . 54
4.8 Average LQI values for all position as seen from gathering station 8a04 . 55 4.9 Average LQI values for all position as seen from gathering station 14d8 . 55 4.10 Average LQI values for all position as seen from gathering station 15de . 56 4.11 Average LQI values for all position as seen from gathering station 15e2 . . 56 4.12 Average LQI values for all position as seen from gathering station 9715 . 57
xi
4.13 The Surveyor SRV-1 robot acting as a mobile actor . . . 59
4.14 The atom based PC . . . 60
4.15 A USB connected iSense module . . . 60
4.16 Another USB connected iSense module . . . 61
4.17 Testbed Topology of testbed deployed in five rooms and a corridor using 30 motes . . . 61
4.18 Reporting pipeline . . . 65
4.19 Visualization software and pipeline software . . . 66
4.20 Scenario 1 - Agents Return Times(ms) . . . 69
4.21 Scenario 2 - Agents Return Times(ms) . . . 69
4.22 Scenario 3 - Agents Return Times(ms) . . . 70
4.23 Scenario 4 - Agents Return Times(ms) . . . 71
4.24 Scenarios 3 and 4 - Target path. S stands for the Starting position and E stands for the End position of the path . . . 72
4.25 Scenario 4 - Tracker Mobility Pattern . . . 72
4.26 The steps we follow to calculate the position . . . 77
4.27 Intersection Points Converging on Real Position . . . 77
4.28 Two Anchors Intersection Points . . . 78
4.29 Example of No Intersection Points . . . 78
4.30 Favour Points example . . . 81
4.31 Method 2 Cluster Example . . . 82
4.32 Distance derived from experimental RSSI values . . . 83
4.33 Distance derived from experimental RSSI values . . . 84
4.34 Distance derived from experimental RSSI values . . . 84
4.35 Distance derived from experimental RSSI values . . . 85
4.36 Network 1 Results . . . 87
4.37 Network 2 Results . . . 87
4.38 Network 3 Results . . . 88
4.39 Network 4 Results . . . 88
A.1 iSense Core Module . . . 96
A.2 iSense Gateway Module . . . 96
A.3 iSense Rechargeable Battery Module . . . 97
A.4 iSense Wall Mount Module . . . 97
A.5 WaspMote . . . 98
2.1 Simulator characteristics . . . 12
2.2 Running times and Memory usage of WSNGE . . . 28
4.1 Average values for base station 0x15e2 . . . 51
4.2 Average values for base station 0x14d8 . . . 51
4.3 Average values for base station 0x1bf0 . . . 51
4.4 Average values for base station 0x8a04 . . . 51
4.5 Average values for base station 0x9715 . . . 57
4.6 Average values for base station 0x15de . . . 58
4.7 Light weight target tracking algorithm scenarios . . . 68
4.8 Multilateration techniques: Networks’ Characteristics used for testing . . 86
xiii
WSN wireless sensor network MAC medium access control IP internet protocol
IPv4 internet protocol version 4 IPv6 internet protocol version 6
6LoWPAN IPv6 low power wireless personal area network IETF internet engineering task force
OSI open systems interconnection
GSM global system for mobile communications, originally groupe sp´ecial mobile IVU irida visualization unit
ICU irida control unit LAN local area network USB universal serial Bus UDP user datagram protocol OTA over the air
Introduction
1.1 Sensing the environment and networks
The main idea of Wireless Sensor Networks (WSN) is simple but its implications and applications can be quite complex and there is a need for considerable research effort in multiple areas Very small devices, called nodes or motes, are designed in order to have simple computing, storage, sensing and communication capabilities. These devices are organized into networks taking advantage of their communication capabilities. The networks formed, called Wireless Sensor Networks, can perform various tasks as a whole, taking advantage of the unique characteristics they have as well as the capabilities of the motes that comprise them. Each of these motes by itself is usually a very weak device and cannot perform computing or storage intensive tasks. The parallel and distributed nature of Wireless Sensor Networks makes them a very promising technology, while the understanding and presentation of them can prove to be a formidable challenge.
Wireless Sensor Networks are also quite challenging for another reason. Normally, de- signing and implementing such a network is a multi-layered and multi-disciplinary task.
While in traditional network an open systems interconnection (OSI) explanation is nor- mally enough, this is not the case for these networks. WSN research ranges from low level MAC protocols to high level message routing algorithms. In each of these layers, no solution is optimal in all situations. WSN are particularly ad-hoc in nature. Depending on specific applications solutions are researched and designed for, an algorithm can be more efficient than another, based on scenario set criteria. One thing that is normally true with WSN is that the resources each mote possesses are scarce. Motes are equipped
1
with low computing power accompanied by low memory and storage capabilities com- pared to even today’s mobile phones, not to mention personal computers.
Of particular interest in WSN research is power consumption since in most cases, motes are battery powered, although even this is not absolute since depending on the scenario, power can be provided by external sources, such as solar panels or the mains. Examples of specific motes hardware that have been used in the context of this thesis, can be seen in detail in Appendix A.
1.2 The WSN vision and example applications
The vision of Wireless Sensor Networks is that of Ambient Intelligence ([1]). In most computing platforms, the system is used to process information provided or generally being useful to one or more users said system. This user-centric approach is not the one found in Wireless Sensor Networks. In these systems, the environment in which the sensor-nodes reside is very important to their operation and functionality. Since one of the main components of WSN are the sensors each node features, and those sensors provide data gathering information from the surroundings of the node, the network it- self can utilize algorithms, depending on the application the network is designed for, to process this environment information and provide the required utility. Other important characteristics of such networks are the relatively autonomous operation, requiring lit- tle or no external interaction. Typically, WSN feature auto-configuration of the nodes, using local information, whether this is information about neighborhood nodes or the local environment as well as fault tolerance in the form of network robustness, since the important factor is for the network functionality to be preserved for as long as possible, while at the same time individual nodes of the network are less important. The impor- tance of the aforementioned characteristics is high, since there are applications of WSN that make user intervention very difficult to impossible.
Examples of WSN application scenarios include, but are not limited to:
• Tracking of individuals or equipment include scenarios where a person or item’s location must be tracked within a predefined space. Wildlife tracking in the wild,
a person in an urban environment or a mobile computer’s location tracking inside a building are all examples of such a tracking scenario.
• Smart buildings include scenarios that go beyond simple automation systems in buildings. Since WSN provide local and global intelligence, in the form of decision making based on environment data, as well as other parameters that are fed to the network, complex scenarios can also be implemented using this technology. Area access control, climate control based on personal preferences of specific user groups as well as building energy consumption optimization, based on climate data are examples of this kind of scenario.
• Disaster control scenarios include wildfire scenarios in forests, where a WSN can help guide firefighters by providing a holistic view of the fire, its direction and speed as well as dangerous situations in buildings, such as fires or gas leaks, where a WSN can guide trapped people to safety by marking dangerous areas and safe exit routes.
The above are just a few examples of current and future application scenarios based on WSN technology. The unification of multiple services these networks can provide also leads to the vision of smart cities, where WSN deployed in most city functions, for example transportation, utilities (such as water supply and electricity grids), road networks (with ”smart” roads that can exchange information with the cars about traffic conditions, speed limits etc) and interconnection between the city’s buildings for infor- mation exchange.
1.3 WSN and the internet - the IPv6 protocol and the 6LoWPAN concept
Traditionally, WSN configurations include a number of nodes that form the network itself, and exchange information with the outside world using a gateway (also known as the sink). Information exchanged inside the network use proprietary protocols and forward information that need to leave the network, for example to feed a visualization
system, is forwarded to the gateway. The gateway receives this information and trans- lates it to the format the end-user needs. Addressing of nodes is also proprietary, since the network is practically isolated and this addressing is being used by the networks’
nodes. Addressing can be as simple as assigning random addresses to each node, basing each node’s address to an underlying address, such as the node’s modem MAC address or use sequential addresses with a flooding mechanism.
With the introduction of IPv6 ([2] and [3]), it was made possible to start consider- ing global addressing for WSN nodes. The IPv6 replaces the internet protocol version 4 (IPv4)([4]) as the primary communication protocol for the internet. It is developed by the IETF because of the shortage of addresses the IPv4 provided. IPv4 uses 32 bit number addresses which in practice means it can address 232 (4 294 967 296) different devices. Some addresses are also reserved for private networks and multicast addresses ([5]) so cannot be used for addressing of public nodes. Taking into account the number of different devices already connected to the internet, it is easily understable that this approach was not applicable to include WSN nodes. IPv6 uses 128-bit addressing which allows up to 4.8 x 1028different addresses. This approach allows WSN, even with a large number of nodes, to define global IPv6 addresses to each of the nodes comprising each network. This in turn allows taking advantage of established protocols in the context of WSN. It also removes the complex need of having to translate traffic at the gateway between the internet and the WSNs.
The special characteristics of WSN, such as lower data rates and limited processing power, led to the development of 6LoWPAN. 6LoWPAN originated from the idea that ”the Internet Protocol could and should be applied to the smallest devices” [6].
6LoWPAN allows functions that are very useful when applied in this class of devices, such as hierarchical address resolution, header compression [7] and more.
1.4 Visualization aspects
WSN networks, like all wireless networks, involve environment factors that affect their operation. While researching and testing different algorithms and protocols, researchers need tools to be able to evaluate them, as well as observe the result of tweaking them.
WSN are unique among wireless networks, because of the fact that individual motes in the network are not important by themselves, instead the network as a whole is carrying
out its intended function. The network can consist of a large number of motes and keeping track of the operation of such large and ever changing network configurations can be tricky. Traditional graph-based visualization tools can prove helpful, but due to the unique characteristics of WSN more specialized visualization tools are needed. In the course of this thesis, we will present our approach to designing such tools as well as evaluating them through real-world scenarios.
Visualization tools for WSN include passive tools, for purposes of monitoring the ex- ecution of network algorithms as well as on-line tools, which provide the capability of tinkering with WSN simulations in real time, for education or experimentation reasons.
We will also explore a few ad-hoc solutions, where applications have specific needs that should be addressed outside full fledged visualization frameworks for efficiency.
1.5 Research questions
Research on WSN applications, algorithms and protocols require visualization tools and methods of visualizing in general more than other forms of networked systems.
This is because of the localized nature of WSN; network nodes are placed within an environment which they sense and the same environment affects communications as well. The operation of a WSN relies heavily on communication between the network elements, namely the WSN nodes. Environmental conditions can not only affect this communication at any given point in time but can also change with time, especially in scenarios where WSN are deployed in remote locations such as other planets or the bottom of the ocean, resulting in a quite unpredictable networking system.
The research questions examined in this thesis are:
• Is there a visualization methodology that can be applied to all WSN systems and can be useful in all scenarios?
• To what extent must we abstract visualization protocols in order to make them useful to as broad cases as possible?
1.6 Guide to Reading Thesis
This thesis is organized in the following chapters:
In chapter 2 we are describing the WSNGE simulator toolkit. WSNGE is a toolkit that provides valuable tools for simulating WSN, presenting and understanding algorithms in an on-line configuration. We discuss the advantages of our approach, novelties and new possibilities for researchers that do research on this field, by using the techniques we introduce. Chapter 2 is based on the work done on B.1 of Appendix B.
In chapter 3 we present the IRIDA visualization toolkit, which includes an open vi- sualization protocol as well as tools to make using it easier. We will also present a few scenarios where we applied the IRIDA visualization protocol and the results. Chapter 3 is based on the work done on B.5 and B.6 of Appendix B.
In chapter 4 we present scenarios where ad-hoc visualization techniques were used, in- stead of a full visualization solution. Normally, these scenarios have very simple visual- ization needs or require very specialized techniques to present the functionality or data in real-time. Chapter 4 is based on the work done on B.2,B.3 and B.4 of Appendix B.
Chapter 5 - Conclusion
The WSNGE simulator toolkit
2.1 Simulating WSN
Mostly due to the costs and setup time associated with deploying a real hardware WSN testbed, much on the research done for new or improved algorithms and protocols is being done using simulated testbeds. From a practical point of view, a joint approach of conducting research that combines both theory and practice must overcome consider- able difficulties. To name a few, wireless sensor network application developers should acquire skills regarding embedded software engineering (manipulate timers and inter- rupts), dealing with low-level hardware devices (cables, hubs, and programming boards) and understanding the peculiarities of the wireless channel (hidden terminal problem, power versus distance model) etc. Still, even if all these skills are acquired, the cost of setting up and maintaining an experimental facility of significant size can be very high.
Deploying the experimental network into a realistic environment requires reprogram- ming dozens of nodes in iteration, positioning them throughout an area large enough to produce an interesting radio topology, and instrumenting them to extract performance data. This may have contributed to the fact that only few of these networks have yet been deployed [8–10].
Simulations can easily handle hundreds or even thousands of virtual motes, while sim- ulating their operation in different levels of detail. While there are a few simulators for WSN around, most notable examples are ns-2 [11], OMNeT++ [12], OPNET Modeler [13], GTNetS [14], YANS [15] and Shawn [16], they were designed and developed in relative isolation. Most specifically, the visualization capabilities of each
7
simulator are normally ad-hoc, as were other specific functionality options.
Even though most simulators provide the basic framework required to simulate a generic wireless network, in the context of wireless sensor networks, more facilities are required to produce realistic simulation scenarios that capture real world uses of these networks.
For example, in real world scenarios it is uncommon for nodes to communicate without restrictions inside the whole network area, but stillobstacle modeling and simulation is absent from most simulators. Even when considering wireless sensor networks, where several models assume nodes are prone to errors and hardware failures, there is usually no clearly defined functionality to model failures. Such aspects (obstacle presence and failures) are especially relevant in networks of high dynamics, which often rise in appli- cation scenarios. We also note that the largest part of the research papers which deal with such networks, and use simulation as an analysis tool, makea lot of simplifying as- sumptions to reduce the overall simulation complexity, be it in the simulation setup, the simulation scenarios, or the simulator used itself. Such oversimplifications are sometimes required in order to conduct experiments with a great number of nodes in reasonable time, but most frequently they are imposed by the lack of functionality in the simulation tools. In this way the credibility of such research works is weakened. An analytic and meaningful discussion of common pitfalls and shortcomings in the simulation of wireless networks in general is included in [17] and [18].
To address some of these shortcomings, we have developed a new simulation platform for complex wireless sensor networks that operate a collection of distributed algorithms and network protocols. Simulating such systems is complicated because of the need to coordinate different network layers and debug protocol stacks, often with very different interfaces, options, and fidelities. Our platform (which we call WSNGE) is a flexible and extensible environment that provides a highly scalable simulator with unique char- acteristics. It focuses on user friendliness, providing every function in both scriptable and visual way, allowing the researcher to define simulations and view results in an easy to use graphical environment. Unlike other solutions, WSNGE does not distinguish be- tween different scenario types, allowing multiple different protocols to run at the same time. It enables rich online interaction with running simulations, allowing parameters, topologies or the whole scenario to be altered at any point in time.
2.2 Additional tools for simulations
WSNGE is primarily a tool kit, that provides a set of tools that try to make simulating WSN scenarios easier, faster and more user friendly.
Scenarios that must be simulated, for algorithm or protocol development, validation or fine-tuning, need to be defined. In some cases, a simple random layout of a network can be used, but in most cases there must be specific conditions present in order to validate certain aspects of the network. For example, in geographic routing algorithms, it is often necessary to introduce obstacles of specific shape inside the network, in order to test the versatility and robustness of such algorithms. WSNGE provides tools that allow a protocol designer to create his own environment (abstracting away irrelevant layers, such as the physical layer) with sufficient flexibility to model diverse situations.
After the scenario has been setup, and the initial conditions have been set, according to the scenario, traditionally the network is left to run until certain conditions are met, either time based or event based. Then, statistical data are provided and from them the designer must extract the characteristics of the execution of their algorithms. Our platform provides means to monitor the execution of the system in real time in addition to traditional statistical data generation.
Another issue that simulators often face is that it is often difficult to use the systems they handle to demonstrate or teach the details of an WSN algorithm in practice. De- pending on the system, they may or may not provide a step by step execution capability accompanied with visual representation of each step in multiple detail levels. WSNGE provides such a feature.
Finally, the system must be easy to integrate in existing simulation engines as well as extend depending on specific needs, not considered at the time of initial design, or not generic enough to be included to the framework. Also, special attention was drawn to easiness of use as well as efficiency, in order to make the researcher’s life easier when it comes to monitoring and manipulating their simulations.
Although WSNGE is targeted primarily on WSN research needs, by providing tools to visualize and manipulate things like communication range and battery life, not appli- cable to most other network systems, it could in theory also be used for other wireless network systems simulations, since many of the tools it provides can be used for these scenarios as well, ignoring the specialized features provided for WSN.
2.3 The GUI
Many systems (e.g., ns, Shawn) provide a detailed animation of the simulated system based on system traces extracted during the simulation. In this sense they are only animated visualizers and do not provide any simulation capabilities. We believe that an important aspect of conducting a simulation is to assess the quality of an algorithm.
For this purpose WSNGE includes a graphical user interface (GUI) that can be used to monitor most aspects of the simulation in real time. This feature is quite important since it allows to pause the simulation, make changes to the environment and continue the simulation in order to measure the effect of certain events on the robustness of the algorithm. Essentially the protocol designer is able to interact with the simulation while the experiment is still ongoing. This includes the ability to inject packets online, alter the topology of the network, introduce obstacles or change the parameters of any simu- lated element. To our knowledge, the existing solutions provide poor or no interaction with running simulations whatsoever.
The GUI includes modules for designing the topology, constructing scenarios, recording the simulation and viewing statistics. It provides a visual representation of the struc- tures and data flows that take place during the simulation of an algorithm in order to give a complete overview of the functionality of the network. A powerful feature of WS- NGE is that it provides multiple view ports of the same simulation with customizable information displayed on each, both to avoid clutter and to focus on certain aspects of the execution, making it an ideal platform for demonstration or educational purposes.
Another limitation of the majority of the available systems is that they offer generic net- work simulation and thus require the developer to code the platform in order to provide custom features for the simulation of realistic scenarios. In this case, the programmer is faced with a steep learning curve and there is a lot of wasted effort until he is able to customize the simulated environment and utilize the full potential of the platform. If, in addition, the language is inefficient (e.g., an interpreted language) the developmen- t/testing cycle becomes too long and the developer cannot assess easily the quality of his algorithm. WSNGE focuses on the simulation of wireless sensor networks and provides a large set of tools that are specific to this particular network technology. These include, but are not limited to obstacles (static or dynamic), battery life, algorithmic controlled range manipulation (for packet injections etc), nodes destruction and failure rates and
many more. Essentially this allows the protocol designer to evaluate and test a par- ticular configuration by minimizing the need to customize the simulation platform and thus dramatically reduce the overall development cycle. We note that there exist very few simulation platforms that are dedicated for wireless sensor networks, most notable examples are AlgoSenSim[19] and TRAILS [20].
Another primary concern is to provide an open system that can be used as a scenario editor, online monitoring and presentation tool for other simulation platforms as well, improving thus code reusability with those platforms. To support these functionalities, WSNGE has a very flexible modular architecture where components have very low cou- pling so that they can be easily removed and replaced by external ones in order to come up with customized simulation platforms.
We envisage cases where specific functionality of WSNGE like the creation of customized environments and complex simulation scenarios involving dynamic events (e.g., node fail- ures, obstruction of node movement, etc.) will be used to enrich the capabilities of other, existing, simulation platforms.
Also, another main goal is to provide a truly open environment that does not have to be confined to specific scenarios. This means that the virtual testbed has to act like a real testbed would when it comes to handling different situations. More specifically, multiple protocols of different nature (localization, routing etc.) can be run without affecting each other which should make tasks like protocol comparison trivial.
It is important to note that our toolkit provides a rich interaction with the running simulations, allowing the researcher both to observe and to fine tune the execution of the algorithms at any point in time using simple to use GUI elements as well as pro- viding scripting capabilities. Apart from the nodes that form the network, and their individual properties that define the general structure, the toolkit also provides tools to define the environment that the network resides in to some extent. This includes direct environment elements, such as customizable obstacles, and indirect elements such as virtual causes of nodes-cluster failures. Including this element, complex environment scenarios can be represented, making the scenarios that are formed more realistic.
The use of WSNGE is rather intuitive and does not distract the developer from his main task, that is, the design, development and testing of the application and the algorithms and protocols it encapsulates.
Simulator Type Size (# Nodes) Visualization
ns-2/NAM Generic 103 Offline
Shawn Generic 106 Offline
OMNeT++ Generic 102 Offline
DAP/ADAPT Generic 103 Online
WSNGE WSN 105 Online
Table 2.1: Simulator characteristics
2.4 Previous work
Network simulation is a field with long history. In the past a broad range of simulation platforms have been developed, each with different application domains, focusing on different aspects of the system. In this section we review four, of what we believe to be important representatives, software solutions that provide visualization for network topologies. Each network visualizer approaches the task with interesting ideas and innovations but at the same time retains its own philosophy. In Table 2.1 we attempt to classify these simulators based on their characteristics and capabilities.
2.4.1 Nam, the VINT Network Animator
NAM’s [21] philosophy is to provide a detailed animation of the execution of the algo- rithm in test. It uses the trace files provided by other simulation environments (such as NS) to render a fully interactive animated representation of data flows, connections and network layout. NAM is only an animated visualizer and does not provide any sim- ulation capabilities. It does however include tools for constructing simulation scenarios and extract them so that external tools can run them.
By using the time-indexed events from the trace files, NAM can provide offline re-runs of simulations. Online visualization is also possible using UNIX pipes as input. By taking advantage of the network properties descriptions, NAM provides its core feature, which is packet animation. Using graph layout drawing algorithms, it represents the physical properties, such as latency and bandwidth of links, and animates packets on the edges. The resulting animated graphs are interactive, providing extra information
and statistics about their elements (packets, edges, nodes etc.).
Nam’s design goal is to provide the user with a way to interpret and understand the way a protocol works by using the packet traces generated from NS to visualize the network during its operation. Because of the static nature of the traces, the protocol behavior is hidden, so Nam provides packet-level animation, protocol graphs, time-event plots of protocol actions and scenario editing. It provides a way to interact with the visualization. Clicking on drawable elements it allows to view more information about them (e.g., clicking on a link, the user can view bandwidth utilization or packet loss rates).
Nam’s scenario creation and editing capabilities consist of the scenario input facility which produces scripts executable by NS and the usage of Nam as a visualizer during NS’s scenario generation. The thing to note here is that Nam’s visualization capabilities are restricted to relatively small scenarios (roughly up to 100 nodes) while support for large network topologies scenarios is future work.
2.4.2 Shawn
Shawn [16, 22] is a discrete event simulator that focuses on large scale network simu- lations. Its philosophy is to use a higher level simulation model, that focuses on the algorithmic part of a simulation, which is the effects of the execution of the algorithm as opposed to simulating all the mechanisms that lead to this effect. Shawn uses abstract and exchangeable models for lower level effects, like communication and transmission models instead of simulating every such effect in the most realistic way. This technique allows Shawn to run large scale experiments in a fraction of the time that would take similar simulators for the same experiments.
The goal of the simulator is to make it easy for a researcher to proceed from the original idea to a prototype centralized algorithm that produces satisfactory results in a rapid way. Experiments can then be run using different abstract models for low level effects, such as latencies, packet losses etc including a large number of nodes and do so in a
reasonable timeframe. The abstract models are plugins that can be altered while new ones can be introduced at any time in order to cover the algorithm’s specific needs.
Shawn’s visualization features are plain. It mainly uses an external tool called Vis [23]
to provide visualizations of discreet time instances of the simulation, including drawing of nodes and edges. Each visualized instance is recorded to PNG or PDF files. It uses the Cairo [24] library for drawing and its main components are nodes, edges, graphics, property sets and the camera.
The nodes are the main component and represent the network processors. They have a customizable appearance in color, size and are generated automatically upon execution.
Edges represent the communication connections between nodes and are not generated automatically. They are also customizable in appearance.
Graphics are drawable PNG files that can, for example, be used as a background image.
The property sets are, as the name implies, set of properties that can be used to hold the configuration of a Vis element. Finally the camera controls the resolution, scaling and position of the resulting image in respect to the network topology.
2.4.3 OMNeT++
OMNeT++ [12, 25] is a discreet event simulator. Because of its open architecture, OMNeT++ has been used not only for network simulations but also for IT systems, queuing networks, hardware architectures and business processes. It provides an exten- sive GUI as well as command line options. OMNeT++’s philosophy is to provide a highly distinctive separation between the components of the simulation environment, so that frameworks for a very broad spectrum of applications can be introduced. Following this, OMNeT++ is being comprised by the simulation kernel, a compiler for its own topology description language (NED) [26], GUI and command line interfaces, vector plotting and scalars visualization tools, model documentation tools and other miscellaneous utilities.
Because of its open architecture and interchangeable roles of the tool, OMNeT++ has a very large and active user community. While OMNeT++ is a powerful tool that can be used in diverse scenarios, it is this same quality that makes its learning curve steeper than more custom-tailored solutions.
NED is OMNeT++’s topology description language which can describe parameterized
regular structures, using for example multiple or conditional connections. In this way, OMNeT++ can provide structures that are not characterized by fixed interconnection or fixed number of elements. Using this property, the system can avoid executing multiple simulation runs for similar model topologies. NED also offers the flexibility to describe the topology using parameters.
NED’s model structure consists of hierarchically organized modules that communicate by exchanging messages. The parameters customize the behavior of the model as well as the modules used. These parameters specify submodule types, gate vectors and connec- tions. Modules can also be created dynamically in OMNeT++ and connect to existing modules. At runtime, the model described in NED is being compiled in C++ in order to maintain efficiency.
The system’s vector plotting and scalars visualization tools consist of Plove[27] and Scalars[28]. Plove is a tool to plot and analyze OMNeT++ output vector files. It provides plotting specific options like drawing style and smoothing and can output in various image format files. Scalars is a tool that also uses OMNeT++ output scalar files to draw bar charts and x-y plots. It also supports output in various image format files.
2.4.4 DAP/ADAPT
DAP/ADAPT [29–31] stands for Advanced Distributed Algorithms Platform and Testbed.
Its main goals are to provide a platform which allows the user to develop algorithms in a common and well known programming language, algorithms which can be used in both simulation and real-world deployment, to support heterogeneous simulation envi- ronments and to be open and extensible for new application domains. In ADAPT every simulated process is actually implemented as a “real”, in the operating system sense, process. Each process communicates through the ADAPT client library to a central core, calledEngine that manages the simulation and provides the relevant functionality.
The Engine performs the simulation processing itself. It follows the discreet event simula- tion model thus its central module is an event queue handler. All actions are transformed to discreet events by the system and then fed to the queue for handling. Actions can originate from the processes or the GUI. The Engine also handles metrics and statistics.
The client library is provided in Java (Standard and Micro editions) and C++ and the
processes that are developed need not all use the same client library making it possible to use the system in heterogeneous environments. An interesting feature of ADAPT is that it includes a modified version of Sun’s SUNSPOTS nodes emulator to allow more complex network topologies. This is achieved by inserting ADAPT between the Sport- World emulator and the SPOT Emulator in the MAC layer acting like the middle-man for forwarding messages. Because of the fact that, in their design, a Squawk VM for each application must be used, the system performs slower and has increased memory consumption, but using this technique, the user is able to design algorithms that will run with little or no change to the real hardware.
The GUI that is provided with the system allows real time monitoring of the simula- tions, and is a completely different executable than the Engine itself, communicating with it using TCP/IP. This allows running the simulations in powerful machines while monitoring from one or more less powerful ones. ADAPT supports the creation of cus- tomized environments and complex simulation scenarios involving dynamic events (e.g., node failures, obstruction of node movement, etc.). Scenario definitions in the mobility, obstacles and failures domain can be defined with time-specific actions that can be re- played at any time in the exact same way. The same protocol is used for scenarios that come from the GUI or from scenario files that can be loaded at any time.
2.5 WSNGE Architecture
Here we describe the architecture of WSNGE in greater detail. Its main functional components are its graphical user interface, the scripting engine and its internal simula- tion engine. Figure 2.1 shows the general architecture design and the interaction of the components. The choice of the optional external simulation engine or the integrated in- ternal simulation engine is up to the researcher, depending if one wants to use WSNGE as merely a scenario editor, online manipulation and monitoring tool for an external simulation framework (such as Shawn) or as a complete simulation package. The way these components are interconnected as well as some more details about the function- ality that they support, that regards obstacles and general failures, is also described in the next paragraphs.
In the integrated internal simulation engine, the communication between nodes takes place using data buffers. The simulation engine uses discreet time units, which we call
Figure 2.1: WSNGE Simulator Toolkit: The High-level Architecture
epochs, to distinguish time slots where actions take place. Epochs are essentially itera- tions (i.e., rounds), which are completed when all active nodes in a network complete their respective actions. These actions can be queue processing for receiving data pack- ets sent in the previous epoch, environment sensing or timed events. Within each epoch, each node processes its own data buffer queue until it is emptied. For each data packet injection, and depending on the algorithm used, none, one or more transmissions may occur from this node. The act of transmitting is equivalent to filling one slot of the destination node’s packets buffer with a data packet. Apart from packet queue process- ing, events like sensing take place within each node’s turn in the epoch. The simulator uses precalculated communication graphs, while applying real-time failure calculations, in order to speed up the simulation process. The communication graph is stored inside each node’s properties structure, so the whole network is stored in a distributed way.
Essentially each node stores its neighbors along with additional information for link sta- tus, quality etc. A part of the statistics is also stored in the same distributed way, so that queries about individual statistics can be answered as well as global statistics. This allows us to improve execution time by increasing concurrency of multiple threads.
Nodes attach themselves to predefined communication models (depending on the phys- ical layer we wish to simulate) during the construction of the communication graph.
Figure 2.2: WSNGE Simulator Toolkit: Two Interacting Simulated Entities
Communication models include the Unit Disc Graph with fixed radiusRor more realis- tic irrational graphs with the radiusRvarying randomly fromR1 toR2 whereR1 < R2. In the same way, each node can attach to a mobility model that enables its location to be altered in each epoch following the model’s behavior. While the default model is a dummy static model, other models can include random walk, circular or spiral walks or predefined paths.
2.5.1 Internal data abstraction
Each node is equipped with a packet buffer which can fill up with data packets that are either received by neighboring nodes or injected by the user. Each data packet is generic and can contain information about different functionality. For example, localiza- tion packets contain information about the anchor’s location and localization algorithm while a geographic routing packet may contain the destination location. Packets can be injected at any time using any of the available methods. Using the GUI it’s also possible to view the buffer of any node at any given moment.
The system does not distinguish between different scenario types while running the sim- ulations. This means that at any time, just like in real testbeds, different kind of packets can be moving through the network, without them having to have any sort of compati- bility between them, assuming that the software on the nodes knows how to handle each of them. In practice, this approach provides the researcher with a valuable tool, namely the ability to run multiple protocols on the same network at the same time, in order to directly compare their performances. For example, a number of different geographic routing protocols which share the same source and destination can be executed on the network and allowed to run step by step, allowing in turn the researcher to examine the difference in their behavior, without having to run the same simulation multiple times for each protocol. This is particularly useful, when used with the multiple views sys- tem (described in more details in the next section), for demonstration and presentation purposes.
2.5.2 Obstacles and faults
We feel that an important part of wireless sensor network simulation is shaping the net- work topology in a more natural way by introducing obstacles. Obstacles are categorized in two main categories. The first category is network areas that contain few or no nodes at all. These areas act like obstacles only when their border nodes have communication ranges that do not allow them to transmit over the gap. The second category is explicit obstacles that can be introduced at any time. These obstacles consist of line segments and can form various shapes like lines, triangles or circles. These types of obstacles do not allow communications to pass through them, so any part of the communication graph that crosses these line segments is discarded. They can also be movable by setting their speed per epoch for axis x and y and can be activated or deactivated on demand or using a timer with varying frequency. Obstacles can also appear or disappear at certain intervals or as a result of certain events. We feel that the above tools provide a platform for the user to create very complicated scenarios and network descriptions.
Another important feature of WSNGE is the ability to fine tune the effect of faults both in communications and in other functions of the nodes, such as sensing capabilities, power leakage or total failure. This is optional, so algorithms can be tested in an ideally functioning environment, or in a more realistic one which includes the possibility of
failures. Failures are normally expressed by a probability [0. . .1] for each action that represents the success rate. The probability can be set in the beginning to a fixed value and can change during the course of the simulation, in order to simulate effects like gradually failing nodes.
2.6 The GUI as a monitor and an online interactor
A central goal of WSNGE is to provide the researcher with a way to interact with the experiment online and directly. All operations are easy to control and are initiated by simple combinations of keyboard keys and/or pointing and clicking with the mouse.
Having this in mind, the system provides easy to use ways to manipulate the simulated environment, both during the setup and while the simulation is evolving. In fact, our system does not even distinguish these phases.
Defining the topology of the network is simple and can be done with many different ways, depending on the situation. Individual nodes can be inserted in specific positions by pointing to these and pressing Ins on the keyboard. If automatic deployment is what the user requires, uniform deployment of a given number of nodes in the whole area or in a specified area (again using intuitive GUI) is as easy as choosing the corresponding action from the menu. Node properties include its position, failure rate, communication radius, moving speed in x and y axis for the next epoch and battery level. Each of these properties can be programmatically changed to fit various algorithms.
The GUI of our system can be used in conjunction with the internal simulation engine or with external simulation solutions. In the later case, the GUI can be used as a powerful topology and scenario editor for simulating experiments in third party frameworks, like Shawn and AlgoSenSim. The interface can be either on-line or off-line (using exported Shawn scripts) and the system can be used either to describe and design or to monitor the simulation progress. The functionality that is available for each external simulation engine depends on the engine itself. Engines that do not support obstacles within their simulation, obviously will not benefit from the obstacles provided by WSNGE. On the other hand, if certain functions are supported but in a completely different way than our platform, compatibility can be achieved by developing function and data structure translators between the two systems. If certain data structures are already in place inside
the engine of the external simulator (for example, the connection graph is calculated in Shawn) these data can be left out of the data feed that the external simulation will get from our platform. On the other hand, these data can be brought back to WSNGE for accurate online visualization, even if they differ to the ones that would be produced within our platform.
The GUI provides a way to open multiple views of the running network. Each view window can provide different kind of information about the current network state, like Gabriel planarized subgraphs[32] or connection subgraphs. Also, each view window can use different display technologies like SDL or OpenGL thus taking advantage of any hardware acceleration present. The user can move and resize these windows to use, for example in secondary displays, like projectors, for demonstration purposes. While the main view is used for interaction, the other views can be used to examine the behavior of protocols or to focus on specific data.
2.7 Scripting
In order to provide as much flexibility as possible, the system provides more than the GUI method to perform actions. Every single action can be performed in two more ways.
The first way is using the GUI command line, which can accept command by command a description of each action. For example, instead of inserting a node using the mouse, the user can insert the commandInsertAt 0.5 0.5 effectively inserting a node at the desired position. The same goes for all functionality of the GUI. Commands can be entered at any time during the simulation lifetime. The second way is using script files.
These are simple text files that consist of commands and comments. The commands are executed sequentially until the end of file. An important functionality option is that a command can execute an external script file, both at the command line and within scripts, providing a way to better organize scripting. In this way, one script file can be about deployment while a second one which effectively can include the first one can be the simulation scenario description and execution. Organization is up to the researcher, so separating obstacles placement and node placement for example in different files, so that each can be reused separately, is perfectly possible.
Because every aspect of the network description and scenario can be defined using script commands, exporting the situation status is being done using the scripting system itself.
The system allows exporting in script files, which consist of commands that when rerun, will restore situation state. This way, the researcher can edit these files to fine tune the scenarios, or create similar scenarios.
2.8 Case Study
To demonstrate the capabilities of the WSNGE, we now show how easy and straight- forward it is to simulate a wireless sensor network comprised of 5000 nodes. We wish to simulate an indoor network where nodes will use a localization algorithm to acquire positioning information and use a data propagation protocol that utilizes the virtual coordinates.
In order to develop a new protocol, the researcher must develop a function that imple- ments the core functionality of the algorithm as well as its supporting data structures (e.g., node data structure) and link it to the GUI. Depending on the nature of the al- gorithm (localization, geographic routing, etc.) the function must return a value, or no value at all if it is not needed, for example in localization algorithms. Within the function, packet transmissions can take place if needed, since the function has access to the global data structures of the network. For our case study, in order to develop a new localization algorithm, the node data structure must be altered to include incom- ing localization packets count, and the function must describe the mechanism according to which localization packets will be generated and sent when each node becomes an anchor, or even before that (depending on the algorithm).
For the setup of the network we will use a simple script file, namelynetwork-simple.txt (see listing 6). It creates a network of 5000 nodes, with size 1 x 1 units, using a specific random seed (making the process repeatable) and creates the communication graph for the network using a communication range of 0.05.
To initiate an algorithm, in essence the researcher must inject the appropriate packets or set up the conditions for the algorithm to begin. Based on the controls of Figure 2.4, in order to initiate a Greedy geographic routing algorithm, the steps that must be followed are: select theGeo tab, selectGreedy algorithm from theGeographic Routing drop down
Figure 2.3: WSNGE Simulator Toolkit: The Main Simulation Window
menu, select the source node (by using the mouse to select the actual node from the network), click source, select the destination (again by selecting the actual node from the network), click destination and clickinit.
s e e d 1 0 2 4 // C h a n g e the r a n d o m s e e d
i n s e r t 5 0 0 0 // P o s i t i o n 5 0 0 0 n o d e s u n i f o r m l y s e l e c t all
r a d i u s 0 ,1 // Set c o m m u n i c a t i o n r a n g e d i s c o v e r // C r e a t e c o m m u n i c a t i o n g r a p h
Listing 2.1: Script for simple network definition
At this moment, a greedy geographic routing packet has been injected to the source node, that contains all the necessary information to run the algorithm as well as some statistics (source node, destination location, hop count). By clicking Next Epoch the
algorithm will forward all relevant packets and increase the epoch. By clicking Run Until Completion, the algorithm will run until all packets have been delivered to the destination or they fail to do so.
To run a localization algorithm, the researcher does not need to inject packets, because a newly localized node will decide, depending on the algorithm, to generate its own localization packets. The steps one must follow are: select Local tab, select Greedy algorithm from the Localization Algorithms drop down menu, select anchor node(s) (by selecting the actual nodes from the network), and finally clickLocalize. At this moment, by pressing Next Epoch or Run Until Completion, the anchor nodes will generate the respective localization packets and broadcast them. Each newly localized anchor node will repeat this procedure until a set number of epochs is reached, all nodes are localized or there are no more localization packets to send.
Figure 2.4: WSNGE Simulator Toolkit: Controls of the Simulation
In order to insert obstacle segments by using the GUI, the researcher must follow the following steps: use the menu system to selectObstacles, clickinsert single (for a single line segment) and drag the mouse to set the position of the obstacle. Alternatively, the researcher can use the console by inputing:
obstacle 0.5 0.5 1 1 to create an obstacle between points (0.5,0.5) and (1,1).
An alternative to setup the scenario using the GUI is to define a more detailed script file. We here use two script files, namely network-detailed.txt (see listing 16) and
obstacles.txt (see listing 4) to describe some elements of the network. These con- figuration files insert 3 nodes at specific locations that are being localized, effectively making them the anchors for our localization algorithm testing. In the second file, 3 obstacles are introduced at specific locations. Finally, the first file resumes and creates the communication graph for the final network. The above procedure results in the network shown in Figure 2.3.
s e e d 1 0 2 4 // C h a n g e the r a n d o m s e e d
i n s e r t 5 0 0 0 // P o s i t i o n 5 0 0 0 n o d e s u n i f o r m l y // P o s i t i o n n o d e s at f i x e d p o i n t s
i n s e r t a t 0.1 0 . 4 5 i n s e r t a t 0 . 0 5 0 . 5 3 i n s e r t a t 0 . 1 5 0 . 5 3 l o c a l i z e 5 0 0 0 l o c a l i z e 5 0 0 1 l o c a l i z e 5 0 0 2 s e l e c t all r a d i u s 0 ,1
// I n s e r t o b s t a c l e s f r o m e x t e r n a l s c r i p t s c r i p t s c r i p t s / o b s t a c l e s . txt
// C r e a t e c o m m u n i c a t i o n g r a p h d i s c o v e r
Listing 2.2: Script for detailed network definition
o b s t a c l e 0 0 . 2 5 0.7 0 . 2 5 o b s t a c l e 1 0.5 0.3 0.5 o b s t a c l e 0 0 . 7 5 0.7 0 . 7 5
Listing 2.3: Script for obstacle definition
The above simulation was run step by step observing at each step the newly localized nodes for the purpose of this example. Alternatively, it could be run for a number of times, while providing little or no feedback. Notice that the same obstacles or network file can be reused separately, providing a tool for testing algorithms in a very controlled configuration. Figure 2.5 and Figure 2.6 show the network after 11 epochs running a simple greedy localization algorithm. In Figure 2.5 the full communication graph is shown while on Figure 2.6 shows a Gabriel Planarized subgraph of exactly the same network at the same time.
For demonstration purposes (e.g., in a classroom) we can have multiple windows showing different information related to the execution of the simulation. For example, Figure 2.4
