Thesis
Reference
A real time locating system for Wireless Sensor Networks
CHANTZIS, Konstantinos
Abstract
An RTLS for active RFID tracking, based on WSNs is presented in thesis. It is composed by two communication protocols. The first is a feedback based Topology Control Protocol that uses adaptive transmission power and adaptive throughput control mechanisms to create and maintain an operating WSN, while the second is a presence detection protocol that can track RFID tags by monitoring disseminated detection information via software agents. We apply our protocols in real indoors wireless sensor testbeds with multiple experimental scenarios to showcase scalability and trade-offs between network properties and configurable protocol parameters. By analysis of the real world experimental output, we present results that depict a more realistic view of topology control and presence detection problems in terms of load balancing, connectivity, reliability, fault tolerance and network traffic minimization. Finally, we also conduct some very focused simulations to assess the scalability of our protocols in very large networks.
CHANTZIS, Konstantinos. A real time locating system for Wireless Sensor Networks . Thèse de doctorat : Univ. Genève, 2014, no. Sc. 4652
URN : urn:nbn:ch:unige-356644
DOI : 10.13097/archive-ouverte/unige:35664
Available at:
http://archive-ouverte.unige.ch/unige:35664
Disclaimer: layout of this document may differ from the published version.
1 / 1
D´epartement d’ informatique Professeur Jos´e Rolim
A Real Time Locating System 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
Konstantinos Chantzis
de Peiraias, Gr´ece
Th`ese No 4652
GEN`EVE 2013
d’informatique), K.-M. ANGELOPOULOS (D´epartement d’informatique) et I. CHATZIGIANNAKIS, docteur (Patras University, Computer Engineering and Informatics Department Greece), autorise l’impression de la pr´esente th`ese, sans exprimer d’opinion sur les propositions qui y sont ´enonc´ees.
Gen`eve, le 26 f´evrier 2014
Th`ese No 4652
I, Konstantinos Chantzis, declare that this thesis titled, ‘A Real Time Locating System for Wireless Sensor Networks’ and the work presented in it are my own. I confirm that:
� This work was done while in candidature for a research degree at the University of Geneva.
� Where I have consulted the published work of others, this is always clearly attributed.
� Where I have quoted from the work of others, the source is always given.
� I have acknowledged all main sources of help.
� I certify that the intellectual content of this thesis is the product of my own work and that all the assistance received in preparing this thesis and sources have been acknowledged.
Signed:
Date:
i
R´ esum´ e
Les syst`emes de localisation en temps r´eel (RTLS: Real time locating systems) permettent aux entreprises et aux organisations de localiser et de suivre une vari´et´e de biens mobiles tels que les containers, produits de d´etail, machineries partag´ees, ainsi que le personnel.
Les RTLS actuellement d´eploy´es utilisent les technologies IEEE 802.11 (Wi-Fi) ou Bluetooth en plus de la d´etection radio-fr´equence (RFID). Cependant, ces syst`emes connaissent des probl`emes tels que la d´ependance `a un serveur centralis´e, d´elais de communication, sur-utilisation du canal sans-fil et des informations impr´ecises de position.
Les protocoles RTLS bas´e sur Wireless Sensor Networks (WSN) constituent une meilleure alternative. Les r´eseaux de capteurs sans fil (WSN: Wireless Sensor Networks) sont des r´eseaux qui permettent la communication multi-point. Ils sont constitu´es d’un grand nombre de petits appareils appel´es des noeuds qui communiquent de faon autonome et sans-fil bas´ee sur les sp´ecifications IEE 802.15.4. Ces noeuds ont des ressources limit´ees et des capacit´es de traitement mod´er´ees ; ils peuvent tre organis´es en r´eseaux complexes sans administration centralis´ee et permettent un large ´eventail de m´ethodes de d´etection.
Dans cette th´ese, nous proposons un RTLS distribu´e pour la poursuite de RFID active, bas´e sur les WSNs. Il est compos´e de deux protocoles de communication principaux.
Le premier protocole de contrˆole de topologie utilise la variation de transmission de puissance et adapte le d´ebit de facon r´eactive de mani`ere `a cr´eer et `a maintenir un r´eseau op´erationnel. Le deuxi`eme protocole de d´etection de pr´esence peut suivre les ´etiquettes RFID en traitant les informations brutes d’identification collect´ees `a l’aide d’agents logiciels. On a ajout´e une fonctionnalit´e `a ce protocole qui permet de garantir l’anonymat des biens surveill´es et ainsi garantir la condidentialit´e des information recueillies.
Nous avons mis en oeuvre nos protocols dans le cadre d’exp´erimentations grandeur nature, un utilisant des testbeds de capteurs r´eels en environnement ferm´e suivant diff´erents sc´enarios. Ces exp´eriences nous ont permis de mettre en ´evidence l’´evolutivit´e des protocoles et les compromis n´ecessaires entre les propri´et´es du r´eseau. L’analyse rigoureuses des r´esultats des exp´eriences pr´esentent une vue r´ealiste des probl`emes de d´etection suivant les param`etres topologiques: ´equilibrage de charge, connexit´e, fiabilit´e, tol´erance aux pannes et volume du trafic. Enfin nous avons effectu´e des simulations logicielles tr`es cibl´ees adin d’´evaluer le passage `a l’´echelle de nos protocoles sur des r´eseaux futuristes tr`es denses.
Abstract
Theoretical Computer Science and Sensor Nets Lab Centre Universitaire D’Informatique
Doctor of Philosophy by Konstantinos Chantzis
Real time locating systems (RTLS) allow various businesses and organizations to locate and monitor a variety of mobile assets such as warehouse containers, retail products, shared machinery, as well as working personnel. Existing RTLS deployed in end-user applications utilize IEEE 802.11 (Wi-Fi) or Bluetooth technologies alongside Radio Frequency Identification (RFID) tag detection. These systems suffer from various problems, like dependency on centralized location engines, slow link negotiations, wireless channel over-ocuppancy and inaccurate location information. RTLS protocols based on Wireless Sensor Networks (WSN) constitute a better alternative. Wireless Sensor Networks (WSNs) are ad-hoc networks that support multihop communication. They consist of small sized, low powered devices (nodes) that can communicate wirelessly based on the IEEE 802.15.4 specifications. These nodes are resource constraint with moderate processing capabilities, can be organized into complex networks without centralized administration and usually support a wide range of sensing capabilities.
A distributed RTLS for active RFID tracking, based on WSNs is presented in thesis. It is composed by two main communication protocols. The first is a feedback based Topology Control Protocol that uses adaptive transmission power and adaptive throughput control mechanisms to create and maintain an operating WSN, while the second is a presence detection protocol that can track RFID tags by monitoring disseminated detection information via software agents. It is also further extended by an untraceable tags scheme to offer location privacy for all mobile assets. We apply our protocols in real indoors wireless sensor testbeds with multiple experimental scenarios to showcase scalability and trade-offs between network properties and configurable protocol parameters. By analysis of the real world experimental output, we present results that depict a more realistic view of topology control and presence detection problems in terms of load balancing, connectivity, reliability, fault tolerance and network traffic minimization. Finally, we also conduct some very focused simulations to assess the scalability of our protocols in very large networks.
I would like to express my sincere gratitude to Prof. Jose Rolim for the continuous support of my Ph.D study and research, for his patience and trust. Sincere thanks to Ioannis Chatzigiannakis for his help and advise and also to former colleauges in projects, Dimitrios Amaxilatis and Christos Koninis. Special thanks to Aubin Jarry for his excellent translation skills. Further acknowledgements to all partners who contributed in the design and implementation of the WISEBED experimentation framework and especially Daniel Bimchas.
In then end, I would like to thank my family and close friends for their continuous support during this journey as well as my second family here in Geneva, Jacques and Monica Arpin.
iv
Contents
Declaration of Authorship i
Abstract iii
Acknowledgements iv
List of Figures viii
List of Tables xi
Abbreviations xii
1 Introduction 1
1.1 Motivation . . . 2
1.2 Contributions . . . 4
1.2.1 Topology Control. . . 4
1.2.2 Target Tracking . . . 5
1.3 Summary of Contents . . . 6
2 WSN Protocol Design and Experimental Practices 7 2.1 Wiselib, An Algorithmic Library for Heterogeneous WSN Devices. . . 7
2.1.1 Wiselib and Heterogeneity. . . 8
2.1.2 Architecture . . . 9
2.1.3 Protocol Modeling . . . 10
2.1.4 Cost of Generality and Modularity . . . 15
2.2 Experimental Testbed Framework. . . 16
2.2.1 Hardware Infrastructure . . . 17
2.2.2 Testbed Architecture. . . 18
2.3 Simulation for WSNs. . . 19
2.3.1 Simulation Tools . . . 19
2.3.2 Extending Shawn. . . 22
3 Topology Control with Adaptive Transmission Power 23 3.1 Related Work . . . 25
3.1.1 Degree Based . . . 25
3.1.2 Individual Link Based . . . 26 v
3.2 Motivation . . . 27
3.2.1 Importance of Degree Limitations . . . 27
3.2.2 Link Quality . . . 28
3.2.3 Fault Tolerance . . . 29
3.3 SCLD-ATP Design . . . 30
3.3.1 Link Quantification . . . 30
3.3.2 Online Service . . . 30
3.3.3 Symmetric Coherent Links . . . 31
3.3.4 Spatial Control . . . 33
3.3.5 Unattainable Goals. . . 35
3.3.6 Non Feedback and Monotonous Performance Degradation . . . 35
3.3.7 Feedback Oscillations . . . 35
3.4 Implementation . . . 36
3.4.1 Constrained by Resources . . . 39
3.5 SCLD-ATP Simulations . . . 40
3.5.1 Convergence . . . 40
3.5.2 Load Balancing . . . 43
3.5.3 Stabilization . . . 44
3.5.4 Non Uniform Topology . . . 45
3.6 SCLD-ATP Testbed Experiments . . . 46
3.6.1 Fixed Transmission Power . . . 47
3.6.2 DTPC Performance . . . 47
3.6.3 LINT/LMA/LMN Performance . . . 48
3.6.4 SCLD-ATP Performance. . . 49
3.6.5 Topology Repair and Fault Tolerance . . . 50
3.7 Extending SCLD-ATP . . . 57
3.7.1 Throughput Control . . . 57
3.7.2 Feedback Daemons . . . 57
3.7.3 SCLD Distributed Heuristics . . . 58
3.8 SCLD-A2TP Testbed Experiments . . . 60
3.8.1 Individualistic Behavior for Nodes . . . 61
3.8.2 Altruistic Behavior for Nodes . . . 61
3.8.3 Balanced Behavior for Nodes . . . 62
3.8.4 Hybrid and Hybrid+ approach . . . 62
3.9 Conclusions . . . 63
4 Tracking Mobile Assets with Wireless Sensor Networks 65 4.1 Tracking in WSN Related Work. . . 67
4.2 Location Privacy Related Work . . . 68
4.3 Real Time Locating . . . 70
4.3.1 Initialization Phase Using Topology Control . . . 71
4.3.2 Spreading of Traces . . . 71
4.3.3 Tracking Active Traces. . . 73
4.3.4 Multiple Detection Points . . . 74
4.3.5 Branch Pruning and Reconfiguration . . . 78
4.3.6 LQI-based Heuristic for the Back-off Period . . . 78
4.3.7 Trace Aggregation for Multiple Targets . . . 80
4.4 Implementation . . . 80
4.5 Real experiments . . . 82
4.5.1 Single Target – Single Tracker. . . 83
4.5.2 Multiple Targets – Multiple Trackers . . . 85
4.6 Large-scale simulations. . . 86
4.7 Location Privacy through Ambiguity . . . 89
4.7.1 Untraceable Tags . . . 89
4.7.2 Adapting Untraceable Tags for Location Privacy . . . 91
4.7.3 Implementation. . . 92
4.7.4 Unification of Software Elements . . . 93
4.7.5 Adversarial Cases. . . 94
4.8 Conclusion . . . 96
5 Conclusions 97 5.1 Introduction. . . 97
5.2 Impact of WISEBED Derived Technologies . . . 98
5.3 From Assumption, to Network Abstraction . . . 99
5.4 The Cost of Location Privacy . . . 100
5.5 Future Work . . . 101
5.6 Closing Comments . . . 102
2.1 Wiselib Architecture [1]. . . 9
2.2 University of Geneva and CTI Patras testbed topologies.. . . 17
2.3 An iSense node paired with a gateway module. . . 17
2.4 UDG, Q-UDG and RIM in Shawn simulator. . . 21
2.5 Extended shadow log fade communication model for Shawn. . . 22
3.1 Link PRR versus average LQI and average RSSI. Each point represents a link in a specific transmission power setting. . . 28
3.2 Link PRR, average LQI, average RSSI values versus link length. Each point represents a link in a specific transmission power setting. . . 28
3.3 The online service scheme of SCLD-ATP. . . 30
3.4 Loss of symmetry is detected in both sides. Neighbor B is not considered for Node A due toTB≤TT H and not included in broadcasts. Neighbor A is not considered for Node B due to inv TA ≤ TT H, but included in broadcasts as fit. . . 32
3.5 Decreasing oscillations using a looseSCLDrange at [4, 6]. . . 37
3.6 Stabilization is impossible with a narrowSCLDrange at [2, 3]. . . 37
3.7 Oscillation detection on a single node. From feedback setting as a discrete time series, to normalized correlogram and in the end, peak detection. . . 37
3.8 SCLD-ATP modular and interactive design. High layer protocols can register for callbacks to receive updates and also access link information on demand. . . 38
3.9 Spatial distribution and convergeance of SCLD booting from -24dB. . . . 41
3.10 Spatial distribution and convergeance of SCLD booting from 0dB. . . 41
3.11 Spatial distribution and convergeance of SCLD booting from -30dB. . . . 41
3.12 Spatial distribution and convergence of transmission power locked at -24dB. 42 3.13 Spatial distribution and convergence of adaptive transmission power booting from 0dB. . . 42
3.14 Spatial distribution and convergence of adaptive transmission power booting from -30dB. . . 42
3.15 Resulting SCL graph with constant transmission power at -24dB and adaptive transmission power booting from -30 and 0dB . . . 43
3.16 SCLD local minimums and maximums.. . . 43
3.17 Node density versus SCLD load balancing and speed of stabilization booting from three different transmission power settings. . . 44
3.18 Spatial distribution of transmission power setting, SCLD and SCL graph for constant settings experiment. . . 46
3.19 Spatial distribution of transmission power setting, SCLD and SCL graph for SCLD-ATP. . . 46
viii
3.20 Average SCLD and transmission power for fixed -30dB, -24dB, -18dB
settings. . . 51
3.21 Local SCLD minimums/maximums with SCL graph at 30th monitoring phase, fixed at -30dB. . . 51
3.22 Local SCLD minimums/maximums with SCL graph at 30th monitoring phase fixed, at -24dB. . . 51
3.23 Local SCLD minimums/maximums with SCL graph at 30th monitoring phase fixed, at -18dB. . . 51
3.24 Average Degree for DTPC, average SCLD for DTPC+ and average transmission power for the different RSSI/trust settings. . . 52
3.25 DTPC: Local degree minimums/maximums and link graph at 30th monitoring phase, withRSSI≥20. . . 52
3.26 DTPC: Local degree minimums/maximums and link graph at 30th monitoring phase, withRSSI≥50. . . 52
3.27 DTPC+: Local SCLD minimums/maximums and SCL graph at 30th monitoring phase, withAV G RSSI ≥50 and symmetric trust. . . 52
3.28 Average Degree for LINT, average SCLD for LINT+/LMN+ and average transmission power. . . 53
3.29 LMN+: Local SCLD minimums/maximums and SCL graph at 30th monitoring. . . 53
3.30 LINT: Local degree minimums/maximums and link graph at 30th monitoring phase. . . 53
3.31 LINT+: Local SCLD minimums/maximums and SCL graph at 30th monitoring phase.. . . 53
3.32 SCLD-ATP: Average SCLD and average transmission power for different boot settings. . . 54
3.33 SCLD-ATP: Local SCLD minimums/maximums booting from 0dB.. . . . 54
3.34 SCLD-ATP: Local SCLD minimums/maximums booting from -30dB.. . . 54
3.35 SCLD-ATP: Local SCLD minimums/maximums booting from a random transmission power setting. . . 54
3.36 SCL connectedness on 2, 7, 8, 21, 30 monitoring phases, before enabling middle-node. . . 55
3.37 SCL connectedness on 32, 34, 36, 43, 52 monitoring phases, after enabling middle-node. . . 55
3.38 Average transmission power and local SCLD minimums/maximums booting from 0dB. . . 55
3.39 SCL connectedness on 2, 8, 21, 31 monitoring phases, before disabling middle section. . . 56
3.40 SCL connectedness on 32, 33, 45, 60 monitoring phases, after disabling middle section. . . 56
3.41 Average transmission power and local SCLD minimums/maximums booting from 0dB. . . 56
3.42 Online service of SCLD-A2TP. Second phase of adaptive throughput. Here monitoring broadcast periods are adjusted so as not to “break” degree conformities and link qualities. . . 58
3.43 Average beacon rate of the topology during second phase. . . 59
3.44 Average transmission power of the topology during first phase. . . 59
3.45 Average SCLD of the topology during both phases. . . 60
3.46 Local SCLD mins/maxs and SCL graph. Constant transmission at -18dB
and constant packet rate. . . 62
3.47 SCLD local mins/maxs and SCL graph. Individualistic. . . 63
3.48 SCLD local mins/maxs and SCL graph. Altruistic, no oscillation control. 63 3.49 SCLD local mins/maxs and SCL graph. Altruistic with oscillation control. 63 3.50 SCLD local mins/maxs and SCL graph. Balanced with oscillation control. 63 3.51 SCLD local mins/maxs and SCL graph for Hybrid strategy. . . 63
3.52 SCLD local mins/maxs and SCL graph for Hybrid+ strategy. . . 63
4.1 The life cycle of a single detection trace. Edge thickness represents trace intensity. The target node is located at the upper border of the network. 71 4.2 The 2-step inhibition. The candidate node to propagate a trace has to resolve his decision.. . . 76
4.3 The 1-step inhibition. The candidate node to propagate the trace will inhibit his area aggressively. . . 77
4.4 Taking advantage of the broadcast nature of inhibition messages, to aggressively reconfigure trace branches that lead to stale roots. . . 79
4.5 Integraded WISELIB modules of the RTLS. . . 79
4.6 Path estimation for a single target attached to a person walking a path, while being tracked by a mobile tracker that was moving randomly in the indoors premises. Numbers indicate each detection point. . . 84
4.7 Static Case: Total bytes sent . . . 85
4.8 Partially Mobile Case: Total bytes sent . . . 85
4.9 Fully Mobile Case: Total bytes sent. . . 85
4.10 Multi Case 1: Total bytes sent . . . 85
4.11 Multi Case 2: Total bytes sent . . . 86
4.12 Multi Case 3: Total bytes sent . . . 86
4.13 The effect of the communication range and the intensity properties of a trace on the message load of the passive nodes. . . 87
4.14 The effect of the communication range and the intensity properties of a trace on the hops and success rate of tracking. . . 87
4.15 Target list aggregation optimization impact on the message load of the passive nodes. . . 88
4.16 Concept of Helper nodes providing decrypting functionality to the passive nodes. . . 92
4.17 Concept of a Central Authority encrypting tag IDs of mobile assets. . . . 94
4.18 Privacy Module. . . 94
4.19 Integration of RTLS and Privacy WISELIB modules. . . 94
List of Tables
3.1 Comparison table of the relevant state of the art. . . 26
3.2 The broadcast packet of SCLD-ATP. . . 39
3.3 SCLD-ATP threshold settings for simulations.. . . 40
3.4 SCLD-ATP thresholds for real experiments. . . 47
4.1 Every aspect of the RTLS can be finetuned. . . 82
4.2 Static Case: Query Response & Success Rate . . . 84
4.3 Partially Mobile Case: Query Response & Success Rate . . . 84
4.4 Fully Mobile Case: Query Response & Success Rate . . . 84
4.5 Case 1: Query Response & Success Rate . . . 84
4.6 Case 2: Query Response & Success Rate . . . 86
4.7 Case 3: Query Response & Success Rate . . . 86
xi
WSN Wireless SensorNetwork OS OperatingSystem
API ApplicationProgramming Interface RAM RandomAccessMemory
ROM ReadOnly Memory VT VirtualTable
STL StandardTemplateLibrary pSTL picoStandardTemplateLibrary RTTI RunTimeTypeInformation LQI LinkQuality Indication
RSSI ReceivedSignalStrengthIndication UNIGE University of Geneva
CTI ComputerTechnology Institute UZL Universit¨atZuL¨ubeck
SNAA SensorNetworkAuthenticationAuthorization RS ReservationSystem
NS-2 NetworkSimulator version 2 DES DiscreteEventSimulator
ISO/OSI InternationalStandardsOrganization Open SystemsInterconnection GloMoSim GlobalMobileInformation systems Simulation library
TOSSIM Tiny OS SIMulator
OMNET++ ObjectiveModular NEtworkTestbed in C++
NED NEtworkDescription MAC MediumAccessControl UDG UnitDiskGraph
xii
Q-UDG QuasiUnitDiskGraph RIM RadioIrregularityModel TC Topology Control
SCLD-ATP SymmetricCoherentLinkDegreeAdaptiveTransmissionPower
SCLD-A2TP SymmetricCoherentLinkDegreeAdaptiveThroughputTransmissionPower LINT LocalInformationNoTopology
LMA LocalMeanAlgorithm LMN LocalMeanNeighbors
DTPC Dynamic TransmissionPowerControl TPSO TransmissionPowerSelf Optimization EMI ElectroMagneticInterference
PCBL PowerControl withBlackListing ATPC AdaptiveTtransmissionPowerControl ART Adaptive and RobustTopology Control ODTPC OnDemand TtransmissionPowerControl ULA UnifiedAbstractionLayer
RFID RadioFrequency IDentification WLAN Wireless LocalAreaNetwork Wi-Fi WirelessFidelity
DQT Distributed QuadTree
MDQT MobileDistributedQuadTree DHT Distributed Hash Tree
SSR ScalableSourceRouting RTLS RealTime Locating System
Introduction
Wireless Sensor Networks (WSN) are wireless multihop networks comprised of a large number of low powered tiny devices (also known as nodes) with short range radio capabilities [2]. Their communication is ad-hoc, based on the on the 802.15.4 IEEE standard. They are also embedded with proprietary hardware to support a plethora of sensing attributes but maintan limited computing power and storage capabilities. They can be utilized to provide advanced distributed services that operate locally, that is, they do not require the coordination of the full network to ensure correctness. This emerging and scalable technology has a vast space of different application scenarios that include solutions for battlefield surveillance, industrial processing, home automation, indoors locating services and health monitoring applications.
Real Time Locating Systems (RTLS) are systems that deliver tracking information of assets in real time. Tracking information is usually the trajectory estimation or the geographical location of the asset that is reported in a timely manner. An asset can be anything, from containers in storage repositories, shared equipment that need to be located fast, even people like working personnel or patients in the healthcare domain.
Conventional RTLS in enterprise business environments utilize IEEE 802.11 (Wi-Fi) and Bluetooth based infrastructures. Assets carry small devices (the tags) that actively advertise their identity to the pervasive infrastructure. The advertisements are then routed to a fixed centralized location engine where the tracking information is displayed to the end user.
1
The focus of this thesis is the design, implementation and extensive evaluation of an RTLS that takes advantage of the distributed operation of WSN. The proposed RTLS addresses three main isues. First, the deployment of WSN nodes in an organization has to be adjusted to the corresponding topology of the organization without affecting normal operations. This extends to the necessity, that the participating WSN nodes not only have to organize themselves into a coherent network, but also have to adapt to any environment dynamicity in order to maintain uninterrupted service. Secondly, location information has to be adequately accurate and up-to-date, while the service that tracks and monitors mobile assets has to be available to both static and mobile users without any centralized knowledge or control of the system. Last, the identities of the mobile assets have to be available only to authorized users of the RTLS, while both the identities of the users and mobile assets have to be ambiguated versus malicious adversaries.
1.1 Motivation
RTLS systems based on the IEEE 802.11 standard are usually deployed on top of an existing WLAN infrastruce in order to reduce installation costs, with the detection of mobile assets based on RSSI ranging. Metrics that refer to communication quality like RSSI and LQI cannot be accurately correlated to specific distances due to interference, obstacles, mobility and non continuous fading. Furthermore the sparsity of Wi-Fi access points as well as their usual corridor based deployment, require the RTLS to operatate at relatively high transmission powers, exaggerating the problems of the wireless medium.
Additionally, the Wi-Fi channels are already over-occupied by countless communication
“hungry” devices like smart phones, laptops and tablets that share the same Wi-Fi access points for internet use. These devices will further cause more noise and service disruption.
Ideally, the environment where the Wi-Fi RTLS is deployed has to be sterile from other communication systems. That is unrealistic and impossible in mainstream enterprise environments like hospitals or business offices. Mitigating failures in Wi-Fi RTLS are also problematic. The sparsity of access points make large areas depended on a single access unit. A failure to that unit will render the area depended on it completely out of service, whereas replacement is usually performed after costly and time consuming reconfiguration and calibration of possibly heterogeneous access points.
Bluetooth RTLS available have limited range of applications and performance due to low throughput capabilities, low communication range and slow link negotiations that are depended on two distinct mechanisms. Theinquiry prodedure, where a Bluetooth access point can discover neighboring Bluetooth enabled devices and the paging procedure, where the access point can set up a communication link with a specific Bluetooth device that was previously discovered. Similar to Wi-Fi RTLS, a centralized location engine is needed to gather RSSI readings and compute locations, constituting a less scalable deployement.
As far as tags are concerned, the passive RFID tags are very small in size and simply receive radio signals by static interrogators and reply back with their information. This means that they have to be in the communication range of the interrogators. Since they operate without batteries, passive RFID tags have to beilluminated with sufficient power from the interrogator in order to reply back; this power is aproximately three magnitudes stronger than the power for signal transmission, making it costly in terms of interference and radiation. Thus interrogator and passive RFID tag interaction most of the times has to be deliberate and is only limited to very short distances.
Alternatively, active RFID tags that are powered by batteries are usually larger in size and can be embedded with application specific funcionalities (sensors and microcontrollers).
An active RFID tag (also referred as “chirping” tag) advertises its presence as well as context sensitive information of the asset that carries it, over the wireless medium.
The pervasive RTLS receives these advertisements, localizes the tags and delivers their location alongside with their aforementioned information to the users of the system. The ability of message exchanging and autonomy compared to passive RFID tags broadens the applications scenarios for active RFID. Since communication is initiated from the tag and since the tag can transmit in different transmission powers, there is no need for deliberate action for location detection by the mobile asset and no limitation of service in terms of distances in the area monitored by the RTLS system.
In this direction, RTLS protocols based on IEEE 802.15.4 WSN constitute a good alternative. Multiple WSN devices can be deployed in an environment at a low cost creating dense neighborhoods for increased location accuracy. The decentralized operation of WSNs can easily scale up to support large areas, significantly reducing deployment complexities. With transmission power control techniques, relatively dense or relatively
sparse WSNs can be organized efficiently into sufficient degree and load balanced WSNs.
When signal strength (RSSI) or quality (LQI) ranging techniques are not accurate due to indoor noise or obstacles, nearest neighbor location can be used at a lower cost and higher accuracy than a Wi-Fi based RTLS and at a faster speed than Bluetooth based RTLS, by simply assigning the minimum transmission power required for detection. Maintance and failure costs are also minimum, since local failures can cause only local service disruption.
A non operating WSN node can be simply replaced fast by another from a repository of back-up nodes. The node can be pre-programmed to carry the same functionality and could participate in the tracking process in the next self organizing cycle of the network.
Furthermore, the level of service disruption could be minimal, since a WSN RTLS can employ self-healing techninques when coupled with a topologoy control scheme.
1.2 Contributions
The tools and methodologies employed in this thesis are based on technologies derived from the WISEBED project consortium and constitute a union of multidisciplinary aspects in the experimental driven research field of WSNs. They include a source code library for resource constraint heterogeneous devices, specifications for distributed communication protocol design, a framework for experiments in real WSN testbeds and various simulation tools. The proposed RTLS is an integration of various WSN protocols, algorithms and distributed heuristics that existed mostly as theoretical work and where based on unrealistic assumptions like the celebrated unit disk graph, convenient communication curves, ideal network conditions, centralized knowledge and perfect distance estimations.
Utilizing the aforementioned tools and methodologies and following an experimental driven approach based on real testbed deployments, resulted in new, improved and field tested protocols resilient to environmental dynamics. We here decompose the operation of the RTLS in two main parts.
1.2.1 Topology Control
The first part is a feedback based Topology Control Protocol (TCP) called Symmetric Coherent Link Degree, Adaptive Transmission Power (SCLD-ATP). The purpose of SCLD-ATP is to create the assumption space of communication; that is a working,
adequately connected network. SCLD-ATP is a fully distributed feedback based TCP that employs adaptive transmission power adjustments to WSN nodes. The goal of SCLD-ATP is to discover and regulate the network based on user requirements. The requirements include degrees of connectivity, true link quality and symmetry based on Packet Reception Rate (PRR). Related work in the field of TCPs deals with link quality based on unrealistic assumptions of wireless communications. These include correlation of PRR with metrics provided by radio interfaces, such as LQI/RSSI or idealistic correlation of PRR with Euclidean distances.
We initially provide experimental results in order to show that these assumptions do not hold in indoor spaces and real WSN deployments. Then we provide insights on the principal design aspects of SCLD-ATP. The feedback mechanism is explained and implementation details are provided to showcase easy integration with higher level protocols. We further draw direct comparisons with state of the art implementations in real testbed experiments that show SCLD-ATP superiority in terms of link symmetry, degree conformity, load balancing, low interference, mitigation of node exclusion, multihop traffic and fault tolerance. Large scale simulations show similar performance even on non-uniform distribution of WSN nodes.
Intrinsic problems to feedback based TCPs like non stabilizing conditions, monotonous performance degradation and degree or transmission power oscillations are also presented alongside mitigation techniques. SCLD-ATP is further extended to support throughput rate control (SCLD-A2TP) with six different distributed heuristics and various experiment permutations between them. The motivation was to allow transmission power control to discover the high quality good links, with a specific homogenous degree of connectedness for the topology and then let the throughput control these properties.
1.2.2 Target Tracking
The second part is a distributed tracking scheme for WSNs. The initial point of this work is a lightweight tracking scheme presented in [3]. Here tracking of mobile assets is decomposed into three parts: (a) detection information, (b) dissemination of this information in the form of “traces” across the WSN topology, (c) querying and routing based on the traces to locate the mobile assets. We are inspired by this protocol due to its inherent simplicity, ease of deployment, scalability and distributed operation. In this
work we move beyond this protocol’s abstract design and provide a real deployable system with various optimizations. Managing multiple detections with weighted back-off timers, aggressive trace propagation, trace aggregation to limit excessive message exchanges and trace branch pruning and reconfiguration. Detailed implementation specifications are also provided for all modules that comprise the system. Real experiments performed focus on traffic load and agent performance (success rate and report times) while simulation experiments depict the correlation of topology density, trace properties with the rate of RFID presence advertisement. We further augment the protocol via the adaption and embeddedment of an untraceable passive RFID tag scheme. The resulting protocol offers significant location privacy through ambiguity and still maintains a decentralized operation.
1.3 Summary of Contents
This thesis is organized in five chapters. The first part is the current chapter, the introduction. The second chapter presents the tools and methodologies used for factoring source code for resource constrained devices. It provides further insights on design practices for distributed communication protocols (namely the WISELIB algorithmic library). Next the flexible experimentation framework is discussed with additional information about simulation tools, communication models and extensions to match the capabilities of WSN nodes, like transmission power adjustments and approximate communication range to transmission power correlation. In the third chapter the SCLD-ATP protocol is presented; from design aspects to implementation and extensive evalution supported by a plethora of experimental scenarios and simulations. The fourth chapter follows a similar structure and contains the target tracking protocol specifications.
Here the tracking process is decomposed to: (a) asset detection, (b) detection information creation, (c) dissemination, (d) routing of this information. Additionally the protocol is extended to support location privacy through ambiguity for all mobile assets via an embeddedment of an untraceable passive RFID tag scheme. Last, Chapter 5 provides conclusions and future work. Also, discussion is provided for the various approaches visited in the previous chapters, such as the impact of our methodology for designing and factoring WSN communication protocols as well as the potential costs of location privacy provisions.
WSN Protocol Design and Experimental Practices
In this chapter follows a concise description of the tools and methodologies employed during design, factoring and experimentation for WSN protocols contributed to this thesis.
These include a generic algorithm library for factoring protocols for embedded devices, the testbed experimentation framework used, the local WSN testbed specifications and simulation models utilized for large scale WSN experiments.
2.1 Wiselib, An Algorithmic Library for Heterogeneous WSN Devices
The protocols that are presented in this thesis have been developed with Wiselib [1], [4]:
an open source code library targeted for (but not limited to) factoring protocols for WSN devices. Wiselib allows implementations to be OS independent, platform independent, highly modular and customizable. It is based on C++ with a heavy use of templates, but without virtual inheritance, exceptions and dynamic memory allocation. Algorithmic implementations can be recompiled for several platforms and firmwares, without the need of changing any source code. Wiselib can be interfaced with systems that use C (Contiki), C++ (iSense) and nesC (TinyOS) with growing support. Additionally, Wiselib
also runs on various WSN simulators like Shawn [5] and TOSSIM [6].
7
2.1.1 Wiselib and Heterogeneity
The fragmentation that pervades the plethora of available WSN devices in terms of different programming paradigms, languages, hardware and operating systems constitutes various problems for the young protocol designers and developers.
Memory Requirements and Management. WSN nodes have limited memory and in some cases ROM and RAM (Read Only and Random Access Memories) are shared under the same memory unit. This means that all code generated for a protocol implementation has to fit in the limited memory and has to be written as minimally as possible. Moreover data structures (like routing tables, neighbor lists, vectors filled with sensor data etc.) have to allocate as less space as possible. On the other hand, memory allocation schemes are different accross platforms, with some nodes only supporting physical addresses without dynamic memory management for resizing memory or moving memory blocks (like the celebrated malloc, reallocandfreefunctions).
Limited Processing Capabilities and Data Access. Microcontrollers supported in WSN devices are very constraint and most of the times differ in architecture. For example, Jennic provides the JN5139 / JN5149 32bit microcontrollers clocked at 16mHz while the TelosB nodes contain the 16bit MSP430 microcontroller clocked at 8mHz. Thus, implementations for efficient event management like message receptions, sensor readings, processing of scheduled tasks as well as implementation of data structures for efficient iterative data processing are a necessecity. Constraint processors can serve only a limited number of interrupts and tasks in a short time. Another problem of implementation is the memory addressing differences as well as varying byte order (endianness) between different platforms.
Because of these problems protocol designers are forced to spend a great deal of attention on low-level platform specific complexities, making the process of designing, testing and maintaining source code a painful and time consuming task. Platform specific implementations are not easily ported from one platform to another; this also means that without a unified coding approach useful implementations can become stale or even deprecated in time.
2.1.2 Architecture
Wiselib architecture is based on template Concepts and Models [7]. Concepts are abstractions of class functionalities without formal definitions while Models are full implementations based on Concept specifications. Concepts (Figure2.1) include: OS Facets, Algorithmic modules and Data structures.
Figure 2.1: Wiselib Architecture [1].
OS Facets. With Wiselib all the different platform and OS intricacies supported are fully abstracted and the designer only has to understand the basic principles of operation for WSN devices. These principles are exposed as a generic, unified and simplified Application Programming Interface (API) with the use of OS Facets. These are middleware that connect the Wiselib API with the hardware platform API or operating system API and are factored as template class type definitions. For each hardware platform or OS supported in Wiselib there is a defined collection of OS Facets; an External Interface.
The main OS Facets for an external interface are:
• OS, that provides platform capabilities via type definitions for other Concepts.
• Radio, that provides methods for sending and receiving packets.
• Debug, that provides methods for printing data to a standard output
• Timer, that provides methods that access task scheduling functionalities.
• Clock, that provides time relevant data like elapsed seconds, milliseconds etc.
• Rand, that provides methods for random number generation.
For example, here we see the definition of send( )method for the Radio Facet for iSense OS and how it wraps around the platform specific call:
1 i n t s e n d ( n o d e i d t i d , s i z e t l e n , b l o c k d a t a t ∗d a t a )
2 {
3 o s . r a d i o ( ) . s e n d ( i d , l e n , data , 0 , 0 ) ;
4 return SUCCESS ;
5 }
And here follows the definition for the samesend( )method for the Radio Facet for the Shawn simulator.
1 i n t s e n d ( n o d e i d t i d , s i z e t l e n , b l o c k d a t a t ∗d a t a )
2 {
3 o s ( ) . p r o c−>s e n d w i s e l i b m e s s a g e ( i d , l e n , d a t a ) ;
4 return SUCCESS ;
5 };
Both cases expose the same generic interface for sending messages, while proprietary calls are resolved by the relevant compiler for each platform. Additionally OS Facets define generic data types that map directly to special datatypes per platform. For example, the Radio Facet defines anode id tthat could be specified for 802.15.4 communication or an IPv6 communication.
2.1.3 Protocol Modeling
Aspects of Modularity. Algorithms in Wiselib are also represented with Concepts and Models. Although using Concepts is not a strict nessecity during implementation, algorithmic categories are already provided as abstract template classes for message receptions, callbacks, support of routing maps etc. One simply has to derive a new class, while implementing an algorithm, and inherit the desired functionality without spending a lot of time during the design phase. Furthermore, since the capabilities of WSN nodes are limited in terms of functionality (WSN distributed schemes focus on the use of daemons for scheduling tasks and the radio hardware functionality), new classes with empty stubs can be created and tested very fast with relative ease as follows:
1 template<
2 typename OsModel P ,
3 typename Radio P ,
4 typename Timer P ,
5 typename Rand P ,
6 typename Debug P>
7 c l a s s MyAlgo Type : p u b l i c Routin gBase<OsModel P , Radio P> // c o n c e p t
8 {
9 typedef typename Radio P Radio ;
10 typedef typename Timer P Timer ;
11 typedef typename Rand P Rand ;
12 typedef typename Debug P Debug ;
13 typedef typename Radio : : n o d e i d t n o d e i d t ;
14 typedef typename Radio : : m e s s a g e i d i t m e s s a g e i d t ;
15 typedef typename Timer : m i l l i s t m i l l i s t ;
16 p u b l i c:
17 MyAlgo Type ( ){ };
18 ˜ MyAlgo Type ( ){ };
19 e n a b l e ( )
20 {
21 // R a d i o F a c e t c a l l
22 r a d i o ( ) .template r e g r e c v c a l l b a c k<s e l f t , & s e l f t : : r e c e i v e>( t h i s ) ;
23 }
24 void i n i t ( Radio& r a d i o , Timer& t i m e r , Rand& r a n d , Debug& d e b u g )
25 {
26 r a d i o = & r a d i o ;
27 t i m e r = & t i m e r ;
28 r a n d = & r a n d ;
29 d e b u g = & d e b u g ;
30 }
31 void s e n d ( n o d e i d t d e s t , s i z e t l e n , b l o c k d a t a t∗ d a t a , m e s s a g e i d t m s g i d )
32 {
33 // R a d i o F a c e t c a l l
34 r a d i o −>s e n d ( . . . . ) ;
35 }
36 void r e c e i v e ( n o d e i d t f r o m , s i z e t l e n , b l o c k d a t a t ∗ msg , ExData const & e x )
37 {
38 i f ( m s g i d == MY ALGO ID )
39 {
40 // . . . p a c k e t h a n d l i n g c o d e
41 }
42 }
43 void s i m p l e d a e m o n ( void∗ u d a t a = NULL )
44 {
45 // . . . daemon c o d e
46 m i l l i s t p e r i o d = 1 0 0 0 ;
47 // Timer F a c e t c a l l
48 t i m e r −>template s e t t i m e r<s e l f t y p e , & s e l f t y p e : : s i m p l e d a e m o n>( 1 0 0 0 , t h i s, 0 ) ;
49 }
50 enum m e s s a g e i d s
51 {
52 MY ALGO ID = 01
53 };
54 p r i v a t e:
55 Radio∗ r a d i o ;
56 Timer∗ t i m e r ;
57 Rand∗ r a n d ;
58 Debug∗ d e b u g ;
59 60 }
As seen in the previous example, the OS Facets pass as template parameters to the algorithm structure. This means that:
• Access to OS Facet functionality is completely agnostic to how the OS Facet internally operates.
• Algorithmic schemes interface with an abstract class datatype that provides the expected generic datatypes and methods and nothing else.
Extending this approach, one could simply create higher level Facets that support extended and more complicated functionality but conceal it under the generic API.
Subsequently, an algorithm implemented in Wiselib that accesses Facets does not need to be rewritten in order to take advantage of the extended features.
Let us consider the three different Radio Facets in Wiselib. The firstTxRadio, provides the standard hardware radio functionality of broadcasting data or sending packets to specified recipients with extended metrics support like LQI and RSSI. The second, is a ReliableRadioimplementation that supports retransmissions for reliable packet delivery, while the third is aFragmentingRadio implementation that supports delivery of packets that have a higher byte length than the maximum supported for a platform. Both ReliableRadioandFragmentingRadiowrap around theTxRadiofunctionality and extend it with various buffering schemes for their operations. In the following code portion we see the instantiation of these Facet types:
1 typedef w i s e l i b : : OSMODEL Os ;
2 typedef Os : : TxRadio Radio ;
3 typedef Os : : Debug Debug ;
4 typedef Os : : Rand Rand ;
5 typedef Os : : Timer Timer ;
6 typedef Os : : C l o c k C l o c k ;
7 typedef R e l i a b l e R a d i o T y p e<Os , Radio , Clock , Timer , Rand> R e l i a b l e R a d i o ;
8 typedef FragmentingRad io Typ e<Os , Radio , Clock , Timer , Rand> F r a g m e n t i n g R a d i o ;
9 typedef MyAlgo Type<Os , Radio , Timer>MyAlgo
10 void a p p l i c a t i o n m a i n ( Os : : AppMainParameter& v a l u e )
11 {
12 Radio ∗w i s e l i b r a d i o = &w i s e l i b : : F a c e t P r o v i d e r<Os , Radio>: : g e t f a c e t ( v a l u e ) ;
13 Timer ∗w i s e l i b t i m e r = &w i s e l i b : : F a c e t P r o v i d e r<Os , Timer>: : g e t f a c e t ( v a l u e ) ;
14 Rand ∗w i s e l i b r a n d = &w i s e l i b : : F a c e t P r o v i d e r<Os , Rand>: : g e t f a c e t ( v a l u e ) ;
15 C l o c k ∗w i s e l i b c l o c k = &w i s e l i b : : F a c e t P r o v i d e r<Os , Clock>: : g e t f a c e t ( v a l u e ) ;
16 F r a g m e n t i n g R a d i o ∗f r a g m e n t r a d i o =new FragmeningRadio ( ) ;
17 R e l i a b l e R a d i o ∗f r a g m e n t i n g r a d i o =new R e l i a b l e R a d i o ( ) ;
18 MyAlgo ∗m y a l g o =new MyAlgo ( ) ;
19 r e l i a b l e r a d i o−>i n i t ( ∗w i s e l i b r a d i o , ∗w i s e l i b t i m e r , ∗w i s e l i b c l o c k , ∗w i s e l i b r a n d ) ;
20 f r a g m e n t r a d i o−>i n i t ( ∗r e l i a b l e r a d i o , ∗w i s e l i b t i m e r , ∗w i s e l i b c l o c k , ∗w i s e l i b r a n d ) ;
21 my algo−>i n i t ( ∗f r a g m e n t i n g r a d i o , ∗w i s e l i b t i m e r ) ;
22 my algo−>e n a b l e ( ) ;
23 }
Here, the ReliableRadio accesses the functionality of TxRadio (line 20). Additionally theFragmentingRadiois initialized with the extended functionality of theReliableRadio (line 21). In the end, when themy algoalgorithm is initialized (line 22), it will support long packets that will be fragmented to the maximum allowed byte-size and will be delivered reliably with acknowledgements without any knowledge of the internal complexity of the Radio Facet being used.
This approach of interchangeable and encapsulated Facets inherently offers many choices and can extend to all sorts of flexible schemes. One could simply pass a flooding scheme in the place of a Radio Facet template parameter (provided he/she includes the expected interface) and subsequent radio broadcasts could flood a network with packets instead of reaching only the one-hop-away recipients. Another example could include a routing scheme that is passed as a Debug Facet template parameter and prints data from one node of the network, to the standard output of another node in the network, multiple hops away.
Intermodule Communication. In contrast to the template encapsulation used for implicit interaction between modules (a design aspect) previously discussed, Wiselib offers a more explicit mechanism for generic module communication through callbacks (a runtime aspect). In detail, an arbitrary class A can register itself to another class B and get updated based on specific events triggered, like radio receptions of a specific packet type, scheduled tasks, time critical parts, or any algorithmic event occurence of interest.
Callback mechanisms are most of the times implementated with the use a base class with abstract class members and dynamic memory allocation. Subsequent classes use inheritance and define their members based on the abstract member methods. The drawback of this approach is the utilization of virtual member functions, which in turn let the C++ compiler create a Virtual Table (VT) for the concerned classes. The VT brings certain disadvantages for embedded eystems. First, there is the additional amount of code space that is required for the VT. Second, execution time is slow due to the fact that the VT contains function pointers that have to be looked up on each call of a virtual method.
Wiselib goes around this problem by incorporating a callback mechanism based on delegates [8]. Their implementation is based on a templated class with two members. An object pointer of void type, and a stub pointer, pointing to a static template function:
1 c l a s s d e l e g a t e
2 {
3 typedef void (∗s t u b t y p e ) (void∗ o b j e c t p t r , i n t) ;
4 void∗ o b j e c t p t r ;
5 s t u b t y p e s t u b p t r ;
6 };
The object pointer will be used for storing a pointer to the class which contains the member function to be called. The stub pointer will be assigned to the address of a templated function that calls the chosen member function of the object pointer:
1 template <c l a s s T, void (T : :∗TMethod ) (i n t)>
2 s t a t i c void m e t h o d s t u b (void∗ o b j e c t p t r , i n t a1 )
3 {
4 T∗ p = s t a t i c c a s t<T∗>( o b j e c t p t r ) ;
5 return ( p−>∗TMethod ) ( a1 ) ;
6 }
In the from method( ), a new delegate is created and both its members are assigned.
The object pointer is assigned to the passed parameter that is usually a this-pointer when called from another class. The stub pointer is assigned to the address of the corresponding method to be triggered:
1 template <c l a s s T, void (T : :∗TMethod ) (i n t)>
2 s t a t i c d e l e g a t e from method (T∗ o b j e c t p t r )
3 {
4 d e l e g a t e d ;
5 d . o b j e c t p t r = o b j e c t p t r ;
6 d . s t u b p t r = &m e t h o d s t u b<T, TMethod>;
7 return d ;
8 }
The last part is the invocation of a delegate via the operator( ):
1 void operator( ) (i n t a1 ) const
2 {
3 return (∗s t u b p t r ) ( o b j e c t p t r , a1 ) ;
4 }
In the end, a module that supports registration maintains a Wiselib standard element container (discussed in the next subsection) for delegate members of other modules that need to be informed from triggered events. It exposes methods for callback registration, and can notify the registered modules fast by simply iterating through the container:
1 // d a t a t y p e s
2 typedef d e l e g a t e 4<void, n o d e i d t , s i z e t , u i n t 8 t∗, ExData const&> e v e n t d e l e g a t e t ;
3 typedef v e c t o r s t a t i c<Os , e v e n t d e l e g a t e t , 5> R e g i s t e r e d C a l l b a c k s v e c t o r ;
4 typedef typename R e g i s t e r e d C a l l b a c k s v e c t o r : : i t e r a t o r R e g i s t e r e d C a l l b a c k s v e c t o r i t e r a t o r ;
5 . . .
6 // r e g i s t r a t i o n o f c a l l b a c k s
7 template<c l a s s T, void(T : :∗TMethod ) ( n o d e i d t , s i z e t , b l o c k d a t a t∗, ExData const& ) >
8 u i n t 3 2 t r e g r e c v c a l l b a c k ( T ∗ o b j p n t )
9 {
10 c a l l b a c k s . p u s h b a c k ( e v e n t d e l e g a t e t : :template from method<T, TMethod> ( o b j p n t ) ) ;
11 } 12 . . .
13 // n o t i f i c a t i o n o f r e g i s t e r e d m o d u l e s
14 {
15 f o r ( R e g i s t e r e d C a l l b a c k s v e c t o r i t e r a t o r j = c a l l b a c k s . b e g i n ( ) ; j != c a l l b a c k s . end ( ) ; ++j )
16 {
17 ExData ex ;
18 Message m e s s a g e ;
19 m e s s a g e . s e t m e s s a g e i d ( 0 ) ;
20 m e s s a g e . s e t p a y l o a d ( i−>g e t p a y l o a d s i z e ( ) , i−>g e t p a y l o a d ( ) ) ;
21 (∗j ) ( i−>g e t d e s t i n a t i o n ( ) , m e s s a g e . s e r i a l s i z e ( ) , m e s s a g e . s e r i a l i z e ( ) , ex ) ;
22 i−>i n c c o u n t e r ( ) ;
23 }
24 }
25 . . . .
26 // members
27 R e g i s t e r e d C a l l b a c k s v e c t o r c a l l b a c k s ;
Generic Data Structures and Libraries support. Since different target systems provide different schemes for memory allocation, the C++ STL (Standard Template Library) cannot be supported to preserve Wiselib generality. Instead pSTL (pico STL) is provided as a subset of STL, stripped from dynamic memory support, exceptions and Run-Time Type Information (RTTI). Generic data structures like routing tables, neighborhoods, cluster maps and position maps are provided at a higher level with the use of pSTL as ready-to-be-used implementations. These structures can also be used as general Wiselib Concepts for design and implementation of more complex data structures.
2.1.4 Cost of Generality and Modularity
The advantages of using the above directions come with a few trade-offs. To achieve source code generality in a pool of heterogeneous devices and platforms, development and design has to be limited to a subset of the intersection of capabilities for all these platforms. In order to take advantage of specific device capabilities outside the standard, two directions are available:
The first involves heavy use of preprocessor directives for selective compilation. Each compiler will ignore or take into consideration specific portions of code. With this direction, development strays away from keeping a unified standard library and source code becomes hard to follow.
The second direction focuses on the use of very abstract Types and Concepts that have to be further decomposed to many different sub-types or data structures to support needed platform intricacies. For example Link Quality Indication (LQI) and Received Signal Strength Indication (RSSI) metrics metrics are supported by some hardware radios and not in the same data format. So either different radio impleamentations have to be maintained for each platform or all radio implementations have to support some generic type for general use. A good example regarding this case is seen in the template parameterExDatain all radio implementations previously presented. This “general” type is used as a container for the different data that each platform could support. In this case Wiselib generality is maintained but could also become “bloated“. In the end, the previously discussed external Wiselib interfaces are not enough to cover platform specifics and have to be supported by a plethora of different sub-modules and data structures.
Another problem is the general overhead and code replication involved when implementing generic modules. This is not due to the intrinsic modularity of Wiselib per se, but due to a deliberate support for design flexibility and interchangeability. For instance aDebug interface that could implicitly act as aRadio interface, has to expose types and has to define or wrap methods outside its “normal” concept.
2.2 Experimental Testbed Framework
The protocols and distributed schemes that are presented in later chapters of this thesis have been designed, factored, thoroughly tested and successfully demonstrated in real WSN testbeds of the WISEBED consortium [9]. Specifically, the testbeds in the CUI-TCS department of the University of Geneva (UNIGE), the CTI department of Patras (CTI) and the University of Lubeck (UZL) (Figure2.2). Following in this section, a description of the different aspects of WSN testbeds used are presented.
A
University of Geneva WSN TESTBEDiSense node mini PC 0x15d3
0x1be5 0x1b99
0x9a0d
0x9a0c 0x1725 0x1b95
0x9700 0x96c2
0x9731 0x96eb
0x9708 0x96e0
0x1cb9 0x96fc
0x96f4
0x99bd
0x15e0 0x9710
0x99ad 0x1b7f 0x999d 0x96e5
0x96e5
B
C D E
0x585 0x786a
0x296
0x9979 CTI WSN TESTBED
iSense node
0x295 0x1b77 0xca3 0x1cde
0x153d
0x0180 0x0181
Figure 2.2: University of Geneva and CTI Patras testbed topologies.
Figure 2.3: An iSense node paired with a gateway module.
2.2.1 Hardware Infrastructure
First, the hardware used in all testbeds were the Coalesenses iSense nodes [10]. They are based on the 32bit Jennic JN5139 IEEE 802.15.4 wireless micro-controller [11] that supports six transmission power settings covering a [−30,0]dB space, with a−6dB step interval. The UNIGE testbed is comprised of 25 nodes, while the CTI and UZL testbeds by 11 and 56 respectively. Specifically regarding the UNIGE testbed, where the protocols presented in this thesis have been implemented, tested and evaluated, the WSN nodes are evenly distributed across five different offices, while each office contains a miniPC (basestation) responsible for managing the operations of 4 to 6 sensor nodes. The nodes are stacked to proprietary gateways (Figure 2.3) that are, connected to their basestation PC via USB cables. The basestation PCs are connected via ethernet to a TCP/IP network and mananaged by a central point, the testbed server. This way, WSN nodes can communicate wirelessly with each other while statistics can be collected efficiently
via UART debug messages (out of band) without the need of dedicated wireless message exchanges that could affect experimental results or special “listening” nodes
2.2.2 Testbed Architecture
The testbed architecture is based on WISEBED derived technologies of managing large scale WSN testbeds [12], [13]. The general idea is that a testbed server manages a certain number of WSN nodes and exposes a unified WISEBED API for the management of the said nodes. Further on, testbeds can also be managed by a Federator server that in turn exposes all the testbeds as a single unit with the same WISEBED API for management.
Other extensions include testbed, node and communication link virtualization as well as testbed emulation, simulation and heterogeneous testbed communication.
There are two different ways nodes can interact with the testbed server. (a) Wired, where nodes are connected via gateways and thus always attached to a power source and (b) wireless, where nodes are completely stand-alone. In the second case, the testbed provides limited functionality in terms of node management. It is also much harder to perform OTAP (Over The Air Programming), as reprogramming of nodes has to be done through multiple hops away from special nodes that are responsible for programming the testbed. Aditionally, data logging operations have to be performed over the air.
This means that the process of sniffing packets or broadcasting dedicated messages for statistics, is going to affect and be affected by the common problems of the shared wireless communication medium (collisions, interference etc.). Last, nodes have to include relatively large modules in their memory to support over the air functionalities, thus reducing the available memory that can be used for node programming.
The WISEBED testbed server runs a collection of services, that include but are not limited only to:
• SNAA(Sensor Network Authentication and Authorization). Testbed users can register for accounts with known authentication systems such as Shibboleth and htpasswd. After a user is authenticated, the system returns a authentication key.
• RS(Reservation System). Here users can reserve the testbed resources for a specific duration. Using the authentication key a user can reserve all testbed nodes (to avoid side-effects from other experiments) or a subset to gradually test his/her
