bachelor thesis - technische universität darmstadt€¦ · bachelor thesis reconfigurable wireless...

Reconfigurable Wireless Sensor Networks: A Survey and Future Works Minh Duy Nguyen

Dependable, Embedded and Distributed Systems & Software Technical University Darmstadt

Bachelor Thesis

Reconfigurable Wireless Sensor Networks:

A Survey and Future Works

Minh Duy Nguyen [email protected]

Supervisor: Abdelmajid Khelil

21.12.2007

Abstract

Originally, each group of many sensor nodes are deployed for one special application. Nowadays and especially in the future, sensor nodes are used for multi‐purposes. They are set for a certain configuration, but may adapt to the dynamic environment and flexible specification. The user such as e.g. administrator controls the whole network and organizes a reconfiguration if necessary. A reconfiguration could be topology changes, task re‐assignments, software updates, etc. The network receives a new configuration and immediately manages the update process. The sensor nodes perform the adaptation automatically. Therefore, human intervention is not needed at sensor nodes. In this thesis, tools of the trade are classified into reconfiguration objects and goals. A survey on reconfiguration in wireless sensor networks gives an overview about possible approaches from the literature. Thereby, for each class, typical scenarios describe the requirement of reconfiguration of some application and system parts. Various approaches are compared to represent the sub‐classes. The paper summaries point out the differences of the approaches. Furthermore, the thesis contains a discussion about the results of such approaches with regard to defined goals. Finally, own ideas show possibly useful future works on reconfiguration.

1


Content

1. INTRODUCTION ....................................................................................................................................... 5 2. RECONFIGURABLE WSNS..................................................................................................................... 6

2.1 WSN CHARACTERISTICS.......................................................................................................................... 6 2.2 RECONFIGURATION.................................................................................................................................. 6

3. RELATED WORK...................................................................................................................................... 7 4. CLASSIFICATION..................................................................................................................................... 8

4.1 CAPABILITIES .......................................................................................................................................... 8 4.2 OBJECTIVES ............................................................................................................................................. 8 4.3 RECONFIGURATION OPTIONS................................................................................................................... 9

4.3.1 Node Properties .............................................................................................................................. 9 4.3.2 Network......................................................................................................................................... 10 4.3.3 Software ........................................................................................................................................ 10 4.3.4 Middleware ................................................................................................................................... 11 4.3.5 Hardware ...................................................................................................................................... 11

4.4 THE SIMPLE CLASSIFICATION ................................................................................................................ 11 4.5 THE MAIN CLASSIFICATION................................................................................................................... 12

5. SURVEY OF LITERATURE................................................................................................................... 14 5.1 FUNCTIONALITY .................................................................................................................................... 14

5.1.1 Function ........................................................................................................................................ 19 5.1.1.1 Node properties ...................................................................................................................................... 20 5.1.1.2 Network.................................................................................................................................................. 20 5.1.1.3 Software ................................................................................................................................................. 20 5.1.1.4 Middleware ............................................................................................................................................ 20 5.1.1.5 Hardware ................................................................................................................................................ 20

5.1.2 Performance.................................................................................................................................. 21 5.1.2.1 Node Properties ...................................................................................................................................... 21 5.1.2.2 Network.................................................................................................................................................. 23 5.1.2.3 Software ................................................................................................................................................. 23 5.1.3.4 Middleware ............................................................................................................................................ 23 5.1.3.5 Hardware ................................................................................................................................................ 23

5.2 DEPENDABILITY .................................................................................................................................... 24 5.2.1 Node Properties ............................................................................................................................ 26 5.2.2 Network......................................................................................................................................... 27 5.2.3 Software ........................................................................................................................................ 27 5.2.4 Middleware ................................................................................................................................... 27 5.2.5 Hardware ...................................................................................................................................... 28

5.3 SECURITY .............................................................................................................................................. 28 5.3.1 Node Properties ............................................................................................................................ 31 5.3.2 Network......................................................................................................................................... 31 5.3.3 Software ........................................................................................................................................ 31 5.3.4 Middleware ................................................................................................................................... 31 5.3.5 Hardware ...................................................................................................................................... 31

6. PAPER SUMMARIES.............................................................................................................................. 32 6.1 FUNCTIONALITY .................................................................................................................................... 32

6.1.1 Node properties ............................................................................................................................ 32 6.1.1.1 Towards Self-organizing Virtual Macro Sensors [34] ............................................................................ 32 6.1.1.2 Energy-Efficient Clustering System Model and Reconfiguration Schemes for Wireless Sensor Networks [1]....................................................................................................................................................................... 33 6.1.1.3 Scalable Data Aggregation for Dynamic Events in Sensor Networks [10]............................................. 34

6.1.2 Network......................................................................................................................................... 35 6.1.2.1 Toward Automatic Reconfiguration of Robot-Sensor networks for Urban Search and Rescue [13]...... 35 6.1.2.2 Dynamic Localization Control for Mobile Sensor Networks [28].......................................................... 36 6.1.2.3 Self-Organized Routing for Wireless Microsensor Networks [31]......................................................... 37

2


6.2 DEPENDABILITY .................................................................................................................................... 39 6.2.1 Node properties............................................................................................................................. 39

6.2.1.1 LACON: Localized Autonomic Configuration in Pervasive Sensor Networks [21] .............................. 39 6.2.1.2 Algorithms for Generic Role Assignment in Wireless Sensor Networks [51], Generic Role Assignment for Wireless Sensor Networks [52], Solving generic role assignment exactly [53]............................................ 40

6.2.3 Software ........................................................................................................................................ 42 6.2.3.1 The Dynamic Behavior of a Data Dissemination Protocol for Network Programming at Scale [49]..... 42

6.2.4 Middleware ................................................................................................................................... 42 6.2.4.1 Reconfigurable Component-based Middleware for Networked Embedded Systems [5], Dynamic Reconfiguration in the RUNES Middleware [4] ................................................................................................ 42 6.2.4.2 Reconfigurable Middleware for Sensor Based Applications [8] ............................................................ 43

6.3 FUNCTIONALITY&DEPENDABILITY ....................................................................................................... 44 6.3.1 Node properties............................................................................................................................. 44

6.3.1.1 Localized Performance-Guided Reconfiguration for Distributed Sensor Networks [35] ....................... 44 6.3.1.2 ASCENT: Adaptive Self-Configuring sEnsor Networks Topologies [43] ............................................. 45 6.3.1.3 SOTP: A Self-organized TDMA Protocol for Wireless Sensor Networks [33]...................................... 46 6.3.1.4 NeuRFonTM Netform: A Self-Organizing Wireless Sensor Network [22] .............................................. 47 6.3.1.5 Self-organizing and Self-stabilizing Role Assignment in Sensor/Actuator Networks [50] ................... 48

6.3.2 Network......................................................................................................................................... 49 6.3.2.1 Self-Organized Data-Gathering Scheme for Multi-Sink Sensor Networks Inspired by Swarm Intelligence [29] ................................................................................................................................................. 49

6.3.3 Software ........................................................................................................................................ 50 6.3.3.1 Run-Time Dynamic Linking for Reprogramming Wireless Sensor Networks [16]................................ 50 6.3.3.2 Design and Implementation of a Framework for Efficient and Programmable Sensor Networks [15]... 50 6.3.3.3 Management and Configuration Issues for Sensor Networks [45], FlexCUP: a Flexible and Efficient Code Update Mechanism for Sensor Networks [46] .......................................................................................... 52 6.3.3.4 Efficient Code Distribution in Wireless Sensor Networks [47] .............................................................. 54 6.3.3.5 Dynamic Reconfigurable Sensor Network Architecture with OSGi Framework [17]............................ 54

6.3.4 Middleware ................................................................................................................................... 55 6.3.4.1 A Reconfigurable Group Management Middleware Service for Wireless Sensor Networks [6]............ 55

6.4 SECURITY .............................................................................................................................................. 57 6.4.2 Network......................................................................................................................................... 57

6.4.2.1 SIGF: A Family of Configurable, Secure Routing Protocols for Wireless Sensor Networks [12] ......... 57 7. DISCUSSION AND FUTURE WORKS ................................................................................................. 59

7.1 DISCUSSION ........................................................................................................................................... 59 7.1.1 Node properties............................................................................................................................. 59

7.1.1.1 Functionality........................................................................................................................................... 59 7.1.1.2 Dependability ......................................................................................................................................... 60 7.1.1.3 Security .................................................................................................................................................. 60

7.1.2 Network......................................................................................................................................... 60 7.1.2.1 Functionality........................................................................................................................................... 60 7.1.2.2 Dependability ......................................................................................................................................... 60 7.1.2.3 Security .................................................................................................................................................. 61

7.1.3 Software ........................................................................................................................................ 61 7.1.3.1 Functionality........................................................................................................................................... 61 7.1.3.2 Dependability ......................................................................................................................................... 62 7.1.3.3 Security .................................................................................................................................................. 62

7.1.4 Middleware ................................................................................................................................... 63 7.1.4.1 Functionality........................................................................................................................................... 63 7.1.4.2 Dependability ......................................................................................................................................... 63 7.1.4.3 Security .................................................................................................................................................. 63

7.1.5 Hardware ...................................................................................................................................... 63 7.1.5.1 Functionality........................................................................................................................................... 63 7.1.5.2 Dependability ......................................................................................................................................... 63 7.1.5.3 Security .................................................................................................................................................. 63

7.2 FUTURE WORKS .................................................................................................................................... 64 7.2.1 Functionality&Dependability ....................................................................................................... 64

7.2.1.1 Node properties ...................................................................................................................................... 64 7.2.1.2 Network.................................................................................................................................................. 65 7.2.1.3 Software ................................................................................................................................................. 66 7.2.1.4 Middleware ............................................................................................................................................ 66 7.2.1.5 Hardware ................................................................................................................................................ 66

3


7.2.2 Security ......................................................................................................................................... 66 8. SUMMARY................................................................................................................................................ 67 REFERENCES .............................................................................................................................................. 68

Acknowledge

I would like convey my thankfulness to all people who supported me to accomplish this bachelor thesis. I am grateful to my supervisor Abdelmajid Khelil. He helped me planning the work and gave me feedbacks if necessary. Furthermore, I thank my family. Without its daily aid, I would not been able to concentrate on the work. A special thank also goes to my friends, especially Hristo Indzhov and Charlotte Hübner. They have always motivated me to complete this thesis.

4


1. Introduction A reconfigurable wireless sensor network (WSN) consists of many sensor nodes, which are deployed for multiple purposes and dynamic environments. The sensor nodes are installed on tiny and resource‐constraint devices, because more than hundreds of them are used to sense data in one area. Due to resource constraints, the sensor nodes are originally fixed for some certain applications. Nowadays, it is desired to use the same WSN for different applications such as multiple monitoring. Thus avoids activating too much nodes. Another important reason for flexible deployment of the nodes comes from the dynamic environments. The natural environment leads to detection of disasters and protection of moving objects. The number of deployed sensor nodes or involved sensing objects is not fixed. Saving energy, the performance of each WSN is scalable. The more performance is required, the more powerful approaches are used, which often consume more energy. Furthermore, the topology in a WSN is important. It decides about the efficiency of the data gathering and communication. The communication model influences the robustness of such network. Normally, sensor nodes may often fail. Thus needs adapting the participation of those. Secure applications such as sensing sensible data require more protection. Attacks to WSNs are reduced by providing security approaches, but they are selected with regard to their necessity. Consequently, the setting of WSNs in all environments should be easily changeable. Reconfiguring the WSN, the initial setting will be adapted to the desired specification. Hence, new applications or configurations are needed. Clearly, the network administrator can go the nodes and install new software and hardware manually. However, the intervention is too high due to the large amount of nodes or the environment may be dangerous or not possible to enter. Thus leads to reconfigurations over the network. Existing tools for standard computers are not appropriate, because they are not such aware to the constrained resource. In this thesis, a survey on reconfiguration in WSNs gives an overview of existing approaches for such networks. There are surveys, which refer to the same topic. However, each paper explains one reconfiguration. In contrast, this thesis contains all the most important possibilities. Furthermore, it explains why reconfiguration is needed by referring to the scenarios. Finally, own ideas show new possible reconfigurations or proposals for improvements. The structure of this thesis is like followed. In section 2, the term reconfiguration is defined. Section 3 shows related works by comparing this thesis with other papers, especially with different surveys. In section 4, the approaches are classified into some classes to group them according to the goals and issues. The main part of this thesis is the survey in the section 5. Section 6 follows with paper summaries to describe the unique reconfigurations of each approach in detail. Evaluating mentioned approaches, section 7 gives a discussion. Furthermore, future works are shown there. The last section summaries this thesis.

5


2. Reconfigurable WSNs Reconfigurable WSNs means that sensor nodes in such networks receive initial settings and applications. Adapting to the current specification of the user and natural environment, the settings and applications are changeable. In the followed sub‐sections, the characteristics of WSNs are described. They lead to necessity of reconfiguration. Examples show some real cases where WSNs should be reconfigurable. Afterwards, the generic steps describe one reconfiguration procedure in general.

2.1 WSN characteristics The resource in WSNs is very constraint. The hardware installing for sensor nodes is much more limited than standard personal computers. The nodes run on some small batteries. That is why they sometimes deplete energy and fail. Furthermore, they have slow processors and some MB of memory. Their size varies from shoebox to grain of sand. Normally, they cost under $1. Consequently, more than hundreds or even thousand nodes can be deployed for one area. In some networks, they are closely together. With that, each detail of such area will not be left out. However, the performance of such systems is restricted. Processing of sensing data is left out. The nodes should only sense and collect data. Then, they transmit the data toward the target. Thus, nodes near the target consume more energy than the other ones. Furthermore, the target is often a base station, which has no such limitations, and can evaluate the data.

2.2 Reconfiguration Reconfiguration contains topology change, task management, software update and adapting system parameters to the flexible environments. WSNs are aware to different applications and scalable to the necessary level of performance, dependability and security. Some concrete examples show when reconfiguration is required. Initially, sensor nodes monitor one building and collect sensing data of temperature measure. The task for one group of sensor nodes may be changed from time to time. With the same nodes, the user sometimes wants to monitor e.g. the movement in this building and the pressure near the windows. Otherwise, in a huge area like a piece of land, the nodes measure the rainfall, but are able to send warning signals if flooding possibly happens. Becoming active, the nodes may restrict nature disasters by sending warning signals. Especially in military, intrusion should be detected by providing appropriate security mechanisms. However, the memory does not allow so many applications stored on the nodes. Thus, it leads to software update or activating new nodes for certain tasks. The topology is crucial for the efficiency of disseminations. If nodes may fail or move, the topology will be changed. Reconfiguring, the heterogeneity are cared, because all nodes should be compatible to the new settings and applications. Furthermore, human intervention and duration of reconfiguration process are to be minimized.

6


Figure 1 shows the generic reconfiguration steps. Reconfiguration can be initialized either by the user, by the network or by the nodes. Normally, at the beginning the user specifies the reconfiguration. The user differs from case to case. It can be network administrator, software developer, robots or end users. Reconfigurations require human intervention at initialization, because human can set rules for reconfiguration. If some decisions are easy to be made and robots are deployed, robots can take over the control. If applications run, the network will control the data distribution and provides other useful network functions (e.g. communication). Finally, the nodes execute their sensing tasks according to the applications. Especially in self‐organizing networks, they should be able to reconfigure themselves.

Figure 1: The generic Reconfiguration steps

3. Related Work The focus of this thesis is on a survey of reconfiguration technologies in WSNs and future works on this field. The thesis is related to some papers. [62] gives an overview of the current research on the network layers. It describes protocols such as routing protocols, protocols in the MAC layer, etc. It also mentions open researches like new transport and routing protocols. However, its content does not contain any reconfiguration. [48] and [25] also provide surveys but on dependability and security in WSNs. They describe approaches, which may meet those goals. Papers, which survey reconfiguration technologies, are e.g. [60] [61] [44]. The first two surveys concentrate on software update. There are three classes such as size reduction on the host, dissemination protocols on the network and execution environment on sensor nodes. [44] describes node selection schemes and thus refers to coverage, tracking and localization approaches and task management for single an multiple mission. Consequently, there are surveys but their structure, complexity and future works are different. This thesis contains a more extensive survey to describe many reconfiguration technologies. Furthermore, its classification differs from other papers and contains more sub‐classes to substitute the complex possibilities according to the goals and technologies.

User Node Wireless Sensor Network

7


4. Classification Reconfiguration in wireless sensor networks (WSNs) is a wide area, therefore we should subdivide it into various classes. There are two criteria such as reconfiguration objectives and capabilities. Objectives (e.g. functionality) express goals that should be met. Capabilities (e.g. node properties) describe elements of WSN, which can be reconfigured. In this thesis, both criteria are combined to say what and why we reconfigure. As result, we have reconfiguration options from several existing approaches and from my contribution, which show how reconfiguration can work.

4.1 Capabilities Capabilities span node properties, network, software and middleware. These properties are reconfigurable. The most useful and probably most important capability is node properties. Node properties refer to repositioning and include changes of network topology, node location and transmission range and bandwidth. Furthermore, the role –describing the function of one node in a network‐ is also reconfigurable. Second, reorganizing the network, we modify network and communication protocols. Third, software reconfiguration leads to update of system or application programs, whereby we replace old with new code. Fourth, middleware are tools, which ease the communication of application and low level constructs. Therefore, we can determine the abstraction level to hide communication protocols or adapt the support of middleware components. Last, hardware is reconfigured by providing abstraction and platform independence.

4.2 Objectives There are three objectives for reconfiguration in WSNs such as functionality, dependability and security. Functionality consists of the functions, which the system provides, and performance, which describes how efficient it works. First, we need reconfiguration, because the function of the system can be changed. The specification and the environment in which the system is deployed are not fixed. Furthermore, performance is also very important, because the WSN is extreme resource‐constraint. That is why algorithms for an application should always be adapted to consume as least energy and memory as possible. Reconfiguration is also necessary if we want dependability and security, which have equal sub‐goals such as availability and integrity. To avoid conflicts we understand dependability just as protection against environment and system changes and security just as protection against attacks. Second, dependability guaranties reliability, availability, safety and maintainability. Reliability occurs, if the system still works correctly after changes, finishes all processes after certain time, and returns a unique solution. Availability means, that the system should be active, if application or user needs it. Safety refers to a system, which is always robust against failures or damages of sensor nodes. This can happen, because sensor nodes are often deployed in areas without human intervention and equipped with some batteries. Last feature of dependability is maintainability. The system should be able to be

8


reengineered every time to achieve flexible deployment or changes of system components, not application‐dependent. Finally, the more serious WSN applications should be, the more we should reconfigure our system to achieve security. The system is designed to protect against attacks. One sub‐goal of security is privacy that means protection of private (secure) data. Authentication is a control of the login process, with that we only allow authorized access (confidentiality). Hence, undesired users are not able to change our system (integrity). It is conceivable that security also ensures indisputability of system utilization. Thus, sensed data belong to unique nodes and any modification may be logged.

4.3 Reconfiguration Options Depending on above‐mentioned objectives and capabilities, we can now describe reconfiguration options of existing papers and other possible ideas. Reconfiguration options are issues which describe here the mechanisms to reconfigure the WSNs. There are different ways to classify. This thesis presents two classifications. The first simple classification is used to overview existing approaches with respect to their reconfigurations very briefly. The main classification represents in {4.3.2} that supports the survey of literature in {5}. There, objectives are prioritized to emphasize the purpose of reconfiguration and due to the complexity of this thesis. Note, the expression [X]{Y} means that the approach is from the paper with the reference X and is described in section Y”. The following sub‐sections give a short overview of the reconfiguration options, grouped by the capabilities to show how we may reconfigure the particular parts of the WSN.

4.3.1 Node Properties Reconfiguration of node properties is used in applications like data gathering and especially event‐based applications. The reconfiguration options are adapting topology for efficient dissemination, activating only a part of nodes to achieve high coverage and performing role assignment so that all functions are divided. There are several kinds of topology in WSN. Using for small networks, star topology describes that one central node is connected to all other nodes and mesh describes that each node is linked with each other. These topologies differentiate in performance and dependability. The star topology needs less power but has shorter range than the mesh topology. Therefore, the topology should be adapted to the current requirement. A combination of these is possible. However, if we consider large networks, we refer to tree‐based or cluster‐based topology. The root of the tree is almost the base station. All data should be transmitted via parent nodes to the root. Examples for tree‐based topologies are NeuRFron [22]{6.3.1.4} basing on the calculation of tree depth and SOTP [33]{6.3.1.3} representing a TDMA protocol which includes collision‐free time slot allocation, thus builds a tree. As cluster‐based topology, [34]{6.1.1.1} presents a per‐region aggregation by grouping nodes depending on the environmental properties. Furthermore, [1]{6.1.1.2} is a clustering reconfiguration scheme. First, the semi‐structure [10]{6.1.1.3} provides structure‐less aggregation and then Dynamic Forwarding on the structure ToD (multiple shortest path trees).

9


For coverage, LACON [21]{6.2.1.1} builds hexagonal clusters and thus deactivates some nodes. Passive nodes preserve energy and have to check for participation periodically. PGR [35]{6.3.1.1} is based on a cost function to determine the candidate for replacement. Role assignment approaches are used to reconfigure the role of nodes. It supports the topology reconfiguration by determining cluster‐heads and slaves (which just collect data). Furthermore, gateways are defined, which are connected with more than one cluster. Roles can also be ON or OFF for coverage. The Generic Role Assignment [51][52][53]{6.2.1.2} provides a very complex role specification language. Furthermore, it presents several reliable role assignment kinds such as straight forward and probabilistic. In contrast, [50]{6.3.1.5} concentrates on the efficient spanning tree and publish/subscribe model to distribute the roles.

4.3.2 Network Network reconfiguration refers to changing the whole network inclusive its architecture and its protocols. Note that it also contains topology formation, however this is not the focus here. For target tracking applications, [13]{6.1.2.1} configures the robot‐sensor network. It can be used in urban search and rescue. Furthermore, [28]{6.1.2.2} controls the frequency of adaptive and predictive localization. For data dissemination, [31]{6.1.2.3} provides a flexible routing. It even ensures 80% performance of the centralized routing (optimum). In contrast, [29]{6.3.2.1} is a robust and self‐organized multi‐sink routing by using Ant Colony Optimization and ant‐based clustering. SIGF [12]{6.4.2.1} additionally contains a configurable collection of secure routing protocols.

4.3.3 Software Software reconfiguration or update is a process containing three steps. In this thesis, step one and two are called external software update. It means that the main part of the reconfiguration is performed outside the nodes. First, on the not resource‐constraint base station the network administrator or software developer (short: user) decides about and specify an update. The user checks the specification of the current programs of nodes in the network. If the specification is not fulfilled due to different software reconfiguration goals (as mentioned in section 4.2), an update should be performed. Thus, the user downloads or develops a new version which is adapting to the environment or application. The new version can be completely different, but eventually has an influence of older versions. There are three kinds of exchange: 1. the whole software image (i.e. Deluge [49]{6.2.3.1}), 2. modular (i.e. FlexCUP [46]{6.3.3.3}) and 3. incremental (e.g. Reijers [47]{6.3.3.4}). A data compression follows to reduce data size. Then, the user eventually selects nodes basing on the system parameters of the nodes (e.g. provided by role assignment of TinyCubus [45]{6.3.3.3}). In the second step, the user distributes the updating code to the nodes via network. Here, we need reliable dissemination protocols like TinyCubus or Deluge. The protocols start an advertisement of the update. The nodes request for update if they receive this task. Now, the data is to transfer regarding link failures and other dependability features. It may become a compatibility problem if the protocols do not support different data formats.

10


Finally, the protocols should verify the completion of update by any data gathering applications. This step is not a content of this thesis. The third step of the software reconfiguration process is performed on the nodes. The execution environment ensures the installation of code. There is a need of operating system and/or virtual machine/framework support. Fewer nodes have the hardware feature explicit Memory Management (MMU). These ones provide a virtual memory space for programs, therefore the code position is independent and thus no relocation is needed. For example, SensorWare [15]{6.3.3.2} supports these nodes to update software. However, the most nodes do not have MMU. The monolithic operating systems such as TinyOS [39] consists of one image, thus always requires the full image replacement. However, using virtual machines like Maté [38] we have programs part stored in RAM to update and further high level operations through an instruction interpreter. In dynamic operating systems such as Contiki [41] and SOS [42] individual modules can be independently loaded (described in [16]{6.3.3.1}), but they require memory relocation.

4.3.4 Middleware Especially, scenarios where heterogeneity, abstraction and software update act important roles require middleware reconfiguration. In the survey, only some approaches are proposed, because the significance and issues intersect with other capabilities. The main difference to software reconfiguration is that middleware reconfiguration concentrates on reprogramming the application level software instead of system software or updating particular modules (see i.e. the Component‐Based System of Runes [4]{6.2.4.1}). The component‐based system of Runes also allows high heterogeneity level by using a set of interfaces. The Group Management Middleware Service [6]{6.3.4.1} provides an interface to different services. This approach allows a generic configuration of selection scheme, however it also presents an implementation of the object tracking application. Additionally, middleware reconfiguration is used for supporting the coordination and communication of nodes running in different systems, in example for target selection (see i.e. the Publish‐Subscribe model of Runes or the Context Management System [8]{6.2.4.2}). As a result, it can be a higher abstraction of mechanisms and protocols easing applications.

4.3.5 Hardware Hardware reconfiguration is required for node robustness. Furthermore, hardware abstraction and heterogeneity are important to use the nodes for each application and for each system in WSNs. The approaches are proposed in the survey, however this thesis does not focus on them. Therefore, there is no paper summary.

4.4 The Simple Classification The simple classification in this thesis is appropriate for an overview of the tools‐of‐the‐trade. It has following structure. First, the defined objectives build four main classes such as Functionality, Dependability, Functionality&Dependability (as combination) and Security. We consider main applications where we need reconfiguration to achieve this objective. Then, the reconfiguration options are assigned to the capabilities. If we just

11


want to read the specific information about the reconfiguration options of existing approaches, we can directly go to the papers in the paper summaries in {6}. Figure 2 shows the compact classification tree with references to several papers as leaves. These papers represent their sub class, because they focus on reconfiguration of certain capabilities. In contrast, the main classification and the survey in {5} provide complex sub‐trees. Existing approaches that fulfil the whole requirements of all objectives are probably optimal for each scenarios and applications in WSN. Some years before, the most approaches set store by either functionality or dependability. It depended on, for which specific areas sensor nodes were used. Nowadays, many papers provide both, because sensor nodes are deployed in more flexible environment. There are not so many approaches for security. Therefore, only functionality and dependability are appropriate to combine.

[34][10][1] [31][8][13]

[22][33][35][43][50] [29][15] [17][45][46][47] [6]

[21][51][52][53] [16][49] [4][5]

[12]

Figure 2: The Simple Classification tree

4.5 The Main Classification The main classification is based on the simple classification, but is more complex to show the classification steps between the reconfiguration objectives and papers. It consists of three main classes such as Functionality, Dependability, and Security. The main class Functionality is separated in Function and Performance. In Function, we only consider the reconfigurations, which ensure the desired functions, not the efficiency of their algorithms. The sub‐class Performance describes the efficiency of the reconfigurations in Function and furthermore necessary reconfigurations for achieving performance. The main class Dependability verifies the dependability of the reconfigurations in Functionality and additional ones for enhancing dependability. Consequently, objectives

12


also have the first priority to emphasize the goals of reconfiguration. However, they are not combined, because in each main class, all according papers will be described. In contrast, in the paper summaries in {6}, the papers represent one main class, because they just focus on certain objectives. Figure 3 shows the generic steps from scenarios and applications to the reconfiguration of the papers for each main class. Steps between applications and reconfiguration possibilities remain constant, but the rest differentiates from one class to another. Note that applications do not have to represent in any scenarios. The user changes the specification of them without influence of the environment or of the network state. First, considering the scenarios, we know which applications or network functions should be performed and reconfigured. On the other hand, some applications derive directly to reconfiguring network functions. Reconfiguring one network function or one application, we should often reconfigure another one, because they are coherent parts of the network. After one or more steps, they lead to reconfiguration possibilities. These possibilities show how the reconfiguration process works. Finally, reconfiguration options collecting from the literature and from own ideas present particular approaches for reconfiguring one possibility. Clearly, these options may consist of different alternatives depending on grouping the papers. Classifying the reconfiguration options, we can assign them to the defined capabilities. Therefore, in each main class we have five sub classes with respect to the capabilities.

Figure 3: Classification steps from scenarios and applications to the references; the grey areas vary from one main class to another; applications, network functions and reconfiguration possibilities deviate in Security from the other two classes

The survey of literature in {5} will show the complete described classification steps for each main class. Furthermore, the reconfiguration options including algorithms will be presented generally by grouping them. The details of the algorithms are to read in the paper summaries in {6}.

APPLICATIONS RECONFIGURATION

POSSIBILITIES

NETWORK FUNCTIONS

Scenarios for each main class RECONFIGURATION

OPTIONS

Alternatives of the options

Grouped by capabilities

References to the papers

13


5. Survey of Literature Surveying the reconfiguration in each main class such as Functionality (with sub‐classes Function and Performance), Dependability, and Security, this chapter refers to the main classification in chapter {4.5}. Describing certain scenarios and applications can explain why reconfiguration is needed to enhance a certain objective (or combination of objectives). Before considering the objectives, the derived reconfiguring network functions are overviewed. They lead to reconfiguration possibilities and then reconfiguration options. Note that the steps between applications and reconfiguration possibilities (see Figure 6, 7 and 8) are the same for the main classes Functionality and Dependability and partly for Security, because all reconfigurations in Function should ensure adequate performance and dependability. However, they are described in Functionality to keep the better understandable order such as from scenarios to reconfiguration options at the end. The sub class Performance and the main class Dependability have additional reconfigurations. The next steps differentiate from (sub)‐class to the other. Reconfiguration options are grouped according to the capabilities to describe which part of the WSN is reconfiguring. Then, they are separated in some alternatives of the options. At first, the similarities in such options are reported. Then, the comparison differentiates the mechanisms in particular approaches. References to the papers and to the paper summaries are given. The summaries mention the main ideas of these approaches, but especially concentrate on their unique reconfiguration. Furthermore, the survey points gaps in the tools of the trade. If existing approaches should be improved or there is no solution for one sub class, these problems (marked as green) will be mentioned here but discussed later and possibly will be tried to solved by own ideas.

5.1 Functionality The complex class Functionality is divided into sub‐classes such as Function and Performance. The class Function concentrates on achieving high quality of applications. The class Performance should provide efficient computation but with the low cost of energy. Note that there are applications which do not need a scenario to be used. These applications are also named in Figure 5. Figure 4 proposes scenarios thus require specific applications in which we enhance the objective functionality (function and performance) by reconfiguring different capabilities and in different ways (reconfiguration options). At the end, approaches from existing papers, which focus on achieving either function or performance or both, are described. The main scenarios come from the dynamic environment in WSNs, i.e. the search and rescue and leader tracking. Here, applications are initialized and adapted to the environment. If the environment sometimes requires other functions, the WSN should provide them. It is not possible due to the limitation in WSNs, that the nodes supply all the functions at one time. Search and rescue and building protection characterize specific and severe scenarios. At first, an area (i.e. forest) is monitored. In case of danger, it will

14


receive a remote support by warning the users of this system. In certain situations (like danger), particular or all objects (i.e. wild animals or danger spots) should be localized. On one hand, mobile objects (i.e. threatened persons, an endangered species or expensive goods) are followed to be monitored and protected. Mobile objects are also followed to avoid that they are able to threaten other protected objects. For example, objects in a military area are defended against undesired intrusions. On the other side, static objects are localized and only warning signals indicate system or human intention. Examples can be found in protection of buildings or disaster zones. Normally, special buildings are equipped with various sensors such as fire, gas, temperature, motion and light. They can only send warning signals in the case that unexpected chance happens. It is imaginable that if such sensors are integrated into sensor nodes by receiving according technical equipment and thus build a WSN, these nodes can additionally provide different warning signals to different targets. The disaster zones are protected by different functions. They can include multiple detection of fire, flooding, tornado, earthquake, etc. If a disaster happens, they also support the rescue by providing important information about these zones. Another scenario in dynamic environment is leader tracking which is similar to search and rescue. However, its goal is just tracking some objects to receive data and it needs a leader election with respect to quality of the result. For example, robots follow their leader to research an interesting surface of one planet. They reconfigure their behaviour according to the characters of the surface. If the surface allows, they will offer a detailed measure, otherwise they only will take photos. In the software development, the software developer writes the code for some functions, and then he installs and tests it. In case he detects content improvements, he updates this version and tests it again. This process continues until the program contains all needed components. Additionally, in the test phase, he can develop a testbed and thus experiments. A testbed maintains system parameters and functions which are continually changed to simulate the system behaviour until the behaviour demonstrates the desired content. • dynamic environment

• search and rescue • mobile objects

• Protection of endangered objects like persons or goods i.e. intrusion detection • static objects – sensor selection

• Alarms in buildings: different detections and evaluation • Different disasters: forest fire, flooding, tornado

• leader tracking i.e. surface research • software Development

• program • testbed

Figure 4: Scenarios requiring reconfiguration There are applications supporting the multi‐purposing WSN, here called dynamic applications. They do not require any scenarios, thus are not depending on the current

15


environment. The user changes the specification of them to provide flexible functions (see Figure 5). The user may collect data from different areas. Therefore, he chooses sources nodes which collect data of their sensors. After nodes have gathered data from their own sensors, they can disseminate sensing data to the selected sinks. All other dynamic applications, where functions are deployed at the initialization, demand for software update. Thus, parts or the whole functions can be added, exchanged or remove. It depends on the current specification.

• data collection from different areas: source selection, data aggregation • data transport to different targets: target selection, data dissemination • changing other functions by adding, exchanging or removing

Figure 5: Dynamic Applications for multi‐purposing WSN

The reconfiguring applications (BOLD AND CAPITALS) come from above‐mentioned scenarios and from the multi‐purpose. However, these applications can be also performed in other not mentioned scenarios. Note that this thesis cannot include all scenarios or applications, but these are the most using in WSNs. Figure 6 shows how applications lead via some steps to other applications and/or network functions (BOLD, CURSIVE AND CAPITALS) and/or reconfiguration possibilities (SMALL CAPS). Reconfiguration possibilities are particular small functions which may be reconfigurable. Note that it does not represent formal expressions. It only describes particular steps in the applications and thus reconfiguration possibilities in an easy way. Steps in square brackets are optional. Words in round brackets are like parameters of the functions. APPLICATIONS APPLICATIONS and/or NETWORK FUNCTIONS and/or RECONFIGURATION

POSSIBILITIES:

• DATA GATHERING • AGGREGATION (arbitrary data) • DATA TRANSPORT

• DATA TRANSPORT • COVERAGE • [TOPOLOGY FORMATION] • DISTRIBUTION (arbitrary data)

• WARNING • COVERAGE • OBJECT SELECTION • RULE DEFINITION • AGGREGATION (arbitrary data) • DETECTION • DISTRIBUTION (alarm signals)

• LEADER TRACKING • LEADER ELECTION • OBJECT TRACKING

• OBJECT TRACKING • COVERAGE (followers) • COVERAGE (targets) • LOCALIZATION (target) • TRACKING

• TASK MANAGEMENT • RULE DEFINTION • ROLE UPDATE • [SOFTWARE UPDATE (task)]

• SOFTWARE UPDATE • [WRITE THE UPDATED CODE] • COVERAGE • DISTRIBUTION (the updated code) • INSTALL (the updated code)

Figure 6: From Applications to Reconfiguration Possibilities

16


Network functions are deployed to realize certain applications. Some of them are reconfigurable and thus also derive to reconfiguration possibilities (see Figure 7). NETWORK FUNTIONS ‐> NETWORK FUNCTIONS and/or RECONFIGURATION POSSIBILITIES:

• LOCALIZATION • DETECTION (node) • DISTRIBUTION (location)

• DETECTION • COVERAGE • OBJECT SELECTION • RULE DEFINITION • MONITORING (objects which should be detected) • DISTRIBUTION (yes or no answer)

• MONITORING • COVERAGE • AGGREGATION (sensing

data) • DISTRIBUTION (sensing data)

• COVERAGE • NODE SELECTION • LOCALIZATION PROTOCOL • ROLE UPDATE (role on or off)

Figure 7: From Network Functions to Reconfiguration possibilities

Many reconfiguration possibilities depend on other possibilities but at least they all deduce to reconfiguration options. Figure 8 shows the steps from possibilities to options (CAPS AND CURSIVE). RECONFIGURATION POSSIBILITIES RECONFIGURATION POSSIBILITIES and/or RECONFIGURATION OPTIONS:

• RULE DEFINITION • CHANGING BY THE USER

• OBJECT SELECTION • SENSOR SELECTION or PARAMETER

SELECTION • PARAMETER SELECTION

• DISTRIBUTION (parameter) • INSTALL (parameter)

• LEADER ELECTION • MECHANISMS

• WRITE THE UPDATED CODE • UPDATED CODE AMOUNT

• ROLE UPDATE • ROLE ASSIGNMENT • ROLE DISTRIBUTION • INSTALL

• TOPOLOGY FORMATION • FORMAT SELECTION

• CLUSTERING or ROUTING TREE or SEMI‐STRUCTURED FORMAT or OTHER FORMATS

• ROLE UPDATE (one role of {on, off, cluster‐head, gateway, slave})

• NODE SELECTION • NODE SELECTION AMOUNT

• AGGREGATION • SENSING or TRANSFER

• SENSING • ROLE UPDATE (role sensing)

• TRANSFER • ROLE UPDATE (role aggregator)

• DISTRIBUTION • COMMUNICATION • ROUTING PROTOCOL • TRANSMISSION

• [BANDWIDTH SELECTION] • [FREQUENCY SELECTION]

• LOCALIZATION PROTOCOL • LOCALIZATION FREQUENCY

• TRACKING • TRACKING OBJECT

• INSTALL • [OS SUPPORT , VM SUPPORT,

FRAMEWORK SUPPORT] • [MIDDLEWARE SUPPORT]

• MIDDLEWARE SUPPORT • ABSTRACTION or PROTOCOL SUPPORT

Figure 8: From Reconfiguration Possibilities to Reconfiguration Options

17


The following descriptions present applications requiring reconfiguration and the steps until the reconfiguration options. The first important application that may require reconfiguration is data gathering. The nodes in WSNs sense data and send them to the certain destination. Sometimes they should transfer data from other nodes, because the dissemination is multi‐hop (Aggregation). The data transport application will be performed. At the beginning of the data transport, the participants are determined (Coverage). Some or even all nodes are selected, then localized and assigned for a task by role update. Often, it is only decided whether the nodes should be on or off. Optionally, the topology can be formatted. The format is based on clusters, trees, semi‐structures or other forms. Clustering is more appropriate for flexible communication and data transport. The whole network is at every time able to divide faster into clusters than into trees, because there are so many groups of nodes which are reachable from different groups. In trees, the nodes only communicate with their parent nodes directly. The root is either the sink in data transport or the base station in each reconfiguration. Finally, data are distributed via cluster‐heads, parent nodes or other representatives to other nodes. The communication structure and routing protocol can be reconfigured. Additionally, the bandwidth and frequency should be selectable. The application warning leads at first to coverage. Then, warning scenarios are created by selecting objects, i.e. a certain area. Thereby, deployable sensors (sensor selection) and system parameters (parameter selection) according to these objects are determined. Parameter selection leads to reconfiguration of parameter distribution and installation. The specified objects and rules characterize the condition of detection. Rules are predefined but they are changeable every time. Now the aggregation can start. The detection works on fewer nodes. These objects are monitored (monitoring consists of coverage, aggregation and distribution) and if a condition for example rainfall is fulfilled, theses nodes will notify. After detections, the system distributes alarm signals. Leader tracking requires leader election and object tracking. There are different approaches for the election. Each one benefits in different manner, therefore they should be selectable. Object tracking performs coverage for followers and targets. Especially, the location of the targets should be found continually. The localization frequency is designed flexibly. Afterwards, tracking differs from the object which should be followed. Tracking human, robots, animals or vehicles are not the same. Their behaviour such as movement, speed and consistency is different. Especially animals are unpredictable, because they can change their behaviour suddenly. Therefore, tracking algorithms should be adaptable. The application task management is used in each WSN. At the beginning, the nodes are initialized with certain roles. Roles describe their tasks in the network. For example, they should be on to sense data, but later are switched off to reserve energy. Sometimes, they should act as cluster‐heads to manage the routing in their clusters. The decision (Rule definition) arrives from considering their properties such as power, location, available sensors, etc. Then, role update can start to assign and distribute the roles to the nodes. Receiving new roles, the nodes install them. Installation is also reconfigurable, because support of operating system, virtual machine and frameworks can be deployed. Additionally, the support of middleware including the system abstraction and protocol support is often suggestive. The nodes set the system according to the roles. Finally, the

18


nodes may receive new reconfiguration or new functions invoking the software update application. One of the most important applications requiring by any reconfiguration is software update. First, the user downloads a different configuration, a new software version or even the whole program from the Internet. Therefore, the updated code amount may vary In WSNs he should often develop them, because the applications for such a network are not compatible like the ones for standard networks. However, he has the possibilities to store various configurations and programs to reconfigure very fast. Afterwards, coverage starts to select nodes which are desired to update. Normally, all nodes should update. The updated code is distributed to these nodes and they install on their system. One discussion point is that who defines all the rules (i.e. for a role or detection) and selects the objects (i.e. for monitoring or tracking). Furthermore, the decision which topology will be used may arrive from different users.

5.1.1 Function In the sub‐class Function we focus on achieving the desired functions as one goal of the objective functionality. We verify that reconfiguration of applications and network functions (defined in Figure 6 and 7) can resist the scenarios (see Figure 4). Here, we do not care about the performance or dependability of the approaches. Therefore, the options are not divided into many alternatives. They do not require any complex reconfiguration. The capabilities such as node properties, network, software and middleware are described in {4.1}. Grouping the reconfiguration options, we map them to according capabilities (see Figure 9). The mappings depend on which parts of the system will be reconfigured in case these options are performed. RECONFIGURATION OPTIONS [alternatives of the options and] references to the papers:

Node properties: • CLUSTERING

• region formation [34]{6.1.1.1} • ROUTING TREE

• spanning tree [22]{6.3.1.4} • NODE SELECTION AMOUNT

• select all nodes • ROLE ASSIGNMENT

• simple ON/OFF assignment • ROLE DISTRIBUTION

• flooding Middleware: • ABSTRACTION

• lowest Hardware: • SENSOR SELECTION

• OSGi [17]{6.3.3.5}

Network: • ROUTING PROTOCOL

• fixed simple protocol DVR • COMMUNICATION

• base station communicates with all nodes • nodes to nodes

• TRACKING OBJECT • human Tracking • robot Tracking [13]{6.1.2.1} • wild‐life tracking [28]{6.1.2.2} • mobile Object Tracking

• LOCALIZATION FREQUENCY • static localization [28]{6.1.2.2} • predictive Localization [28]{6.1.2.2}

Software: • UPDATED CODE AMOUNT

• new complete version update Deluge [49]{6.2.3.1} • FRAMEWORK SUPPORT

• driver Replacement OSGi [17]{6.3.3.5} Figure 9: From Reconfiguration Options to the Papers in Function

19


5.1.1.1 Node properties

Node properties reconfiguration is mostly used, because coverage, localization, topology formation and role assignment are often performed. For the sub‐class Function, we need a simple topology. All nodes may participate in the network for a certain task. They build clusters and trees without regard to performance. For example [34]{6.1.1.1} provides regions according to the environmental properties (such as temperature) for data gathering within the region. In contrast, a tree but not necessary a minimal spanning tree characterizes a hierarchy of dissemination. At first the nodes send data to their parent node, they send to their parent node and so on until the root (sink). For coverage, the roles ON and OFF are enough to describe the participation of the nodes. The role distribution is a flooding mechanism, whereby the nodes transfer the updated role until the relevant node receives it.

5.1.1.2 Network

The network should be reconfigured for better routing and communication in every application especially data transport and tracking. The routing protocol may be fixed and very simple like distance vector routing. With that, the path for transmission can still be found. The communication takes place between the base station and certain nodes or between the nodes. The communication data are transported like flooding. The objects that are followed could be human, whose intention and behaviour are often explicable. The adaptation frequency can be low for example the static localization with fixed period. [28]{6.1.2.2} provides static localization and predictive localization. The behaviour of objects are proposed and configured, especially in case of robots (see an example [13]{6.1.2.1}), (wild) animals or fast moving known objects, because they are more difficult to track. Normally, the nodes are set for a type of object, but the tracking become improperly in case of unknown objects.

5.1.1.3 Software

Software reconfiguration is normally a general process and not for certain applications. In each application, we need to change the code anytime. The software should always have a correct specification, even after updating some parts of it. Updating the software in any reconfiguration, we can exchange the complete software like in Deluge [49]{6.2.3.1}. The framework OSGi [17]{6.3.3.5} supports special software update. It stores some configurations (here driver) for different applications such as fire detection or temperature monitoring. If an event occurs and the nodes should receive new driver, OSGi provides them.

5.1.1.4 Middleware

Middleware provide utilities such as key establishment, but there is no need of such reconfiguration in Function. Furthermore, the abstraction level can be very low, because we do not consider the dependability here.

5.1.1.5 Hardware

If some nodes are equipped with more than one sensors (normally only one), they can select the appropriate sensor according to the receiving task. The framework OSGi [17]{6.3.3.5} undertakes this procedure.

20


5.1.2 Performance The sub‐class Performance relates to reconfiguration options improving the performance of the following applications. The scenarios (see Figure 10) require reconfiguration options for achieving desired computation complexity and energy consumption. Their algorithms should be energy‐aware but nevertheless return expected functions in a short time.

• real‐time environment • minimized processing and fast computation for all applications

• efficient algorithms, topology and routing protocol • resource‐constrained applications

• low consumption of energy, memory and CPU • aware algorithms, , economical transmission

• redundancy in very large, high density networks • limited node participation

Figure 10: Scenarios for Performance

The scenarios for this sub‐class lead to the same applications which should run in real‐time and resource‐constrained. Furthermore, in case various nodes coexist, the data gathering will be used more intensively and thereby resource can be reserved. Therefore, the same reconfiguration possibilities and thus the same reconfiguration options like from the main class Functionality (see Figure 5, 6, 7 and 8) originate. However, the alternatives of the reconfiguration options are different. For example, an effective format (topology) is very important for efficient routing. Figure 11 presents the alternatives of the reconfiguration options which improve the performance of the applications or reconfiguration algorithms.

5.1.2.1 Node Properties

Node properties reconfiguration is very important for achieving performance. The coverage is the crucial factor, because the occupied area for sensing, routing or communication should be maximal but the number of active nodes is minimal. The selectable topology decides about the efficiency. One topology form is clustering consisting of different approaches. The first approach (i.e. [1]{6.1.1.2}) builds clusters which contain cluster‐heads determining according to the node power. The nodes, which have more energy than their neighbours, are selected as cluster‐heads. Second, the clusters are square fields (i.e. [35]{6.3.1.1}), whereby the edges are set with four active nodes and these active nodes are exchangeable with one redundant (passive) node between them. Clusters can consist of hexagonal orbits (i.e. [21]{6.2.1.1} where one cluster‐head reach six nodes around him and thus manages the communication (or dissemination) with (or to/from) them. Ant‐based clustering (i.e. [29]{6.3.2.1}) results clusters with regard to the energy like the first approach, but the way how the remaining node energy is comparing vary. Here, ants simulate the attempt to find better nodes and in this case leave positive pheromones, therefore other ants can follow. There are other conceivable forms of clusters such as triangles, octagons, etc.

21


The topology can be trees instead of clusters. Achieving efficiency, the trees should be minimal spanning trees such as [33]{6.3.1.3}. Therefore, we always maintain the best route between each node and its parent node. It is suggestive that multiple minimal spanning trees are used to share a data volume into packets and disseminate them in several routes. The semi‐structured topology is a combination of two topologies such as clusters and trees [10]{6.1.1.3}. Even other topologies may be practical. For example, circles can simulate the real range of the wireless nodes. Here we contain many flexible communication possibilities. The amount of nodes in the node selection can be one or more i.e. for roots or a set of i.e. cluster‐heads. Role assignment is used to set a task for the nodes. In addition, here, we can use a spanning tree as structure of the assignment. It is more efficient, because the base station can assign hierarchically and uses publish‐subscribe model to distribute the new roles only to subscribed (assigned) nodes (see e.g. [50]{6.3.1.5}). However, role distributions can success in the way as code distribution. The support of the framework TinyCubus [45]{6.3.3.3} is an example for that. RECONFIGURATION OPTIONS [alternatives of the options and] references to the papers:

Node properties: • CLUSTERING

• cluster‐head determination [1]{6.1.1.2} • square fields [35]{6.3.1.1} • hexagonal orbits [21]{6.2.1.1} • ant‐based clusters [29]{6.3.2.1} • other cluster forms

• ROUTING TREE • minimal spanning tree [33]{6.3.1.3} • multiple trees

• SEMI‐STRUCTURED FORMAT • cluster and tree‐based [10]{6.1.1.3}

• OTHER FORMATS • circles

• NODE SELECTION AMOUNT • select one node (root) • select a set of nodes(cluster‐heads)

• ROLE ASSIGNMENT • spanning tree for role assignment

[50]{6.3.1.5} • ROLE DISTRIBUTION

• framework support TinyCubus [45]{6.3.3.3}

• publish‐subscribe model [50]{6.3.1.5}

Network: • BANDWIDTH SELECTION • FREQUENCY SELECTION • ROUTING PROTOCOL

• collection of protocols SIGF [12]{6.4.2.1} • COMMUNICATION

• framework support [17]{6.3.3.5} • communication protocol [31]{6.1.2.3}

• LOCALIZATION FREQUENCY • adaptive localization [28]{6.1.2.2}

Hardware: • PROCESSOR SELECTION

• heterogeneous processors [27] • MEMORY SELECTION

• additional memory cards

Software: • UPDATED CODE AMOUNT

• module update FlexCUP Basic [45][46]{6.3.3.3}

• incremental update FlexCUP Diff [46]{6.3.3.3}, [47]{6.3.3.4}

• OS SUPPORT • dynamic linking Contiki [16]{6.3.3.1}

Middleware: • ABSTRACTION

• lowest • PROTOCOL SUPPORT

• group management [6]{6.3.4.1}

Figure 11: From Reconfiguration Options to the Papers in Performance

22


5.1.2.2 Network

Network reconfiguration with regard to performance deals with routing and communication models. Tools of the trade provide a complex collection of routing protocols for WSNs. They are based on the standard protocols such as distance vector routing, link state routing or geographical support (see also a survey on routing protocols e.g. [26]). In contrast, flooding is the slowest approach. The performance differs in the deployed topology (see {5.1.2.1}), but is also dependent of the protocol. Distance vector based protocols are easier to implement and more energy‐aware than link state based ones, because not all topology changes have to be notified. However, they are more suitable for small networks. If the localization of nodes can result good values for the distance, geographical protocols may support the basic routing. The localization frequency should be adaptive like in [28]{6.1.2.2}. Consequently, the decision which protocol is deployed arrives from the size, density and node robustness of the network. SIGF [12]{6.4.2.1} presents as example a family of protocols, thus provides an appropriate routing in different cases, but more with regard to security and not performance. The communication basing on publish‐subscribe model (see e.g. [17][6.3.3.5}) is better than the case that all nodes communicate with each other. However, a not resource‐limited central point such as base station is required. All other nodes subscribe for an event (here communication content). If a content changes, the central point have only to communicate with according nodes. The communication protocol is like routing protocol. There are nodes which are located physically suitable between the communication pair and thus transfer the communication data. [31]{6.1.2.3} is an example for finding such forwarders. Bandwidth and frequency selection are also important in the transmission. These two elements can be dynamic adapting to the necessary amount to reserve energy.

5.1.2.3 Software

In Function we need only a software update where the whole program image is exchanged, but here the code amount of an update should be minimized. Programs can be divided into many small modules (e.g. in FlexCUP Basic [45][46]{6.3.3.3}). Normally, if changes happen, only some modules will be substituted. Improving this mechanism (e.g. by FlexCUP Diff or [47]{6.3.3.4}), the incremental update requires exchange of only some parts of the module. Thereby, old modules will be compared with new ones and only the newer parts have to be installed.

5.1.3.4 Middleware

In Performance, the abstraction level can be lowest. As protocol support there is a group management (e.g. in [6]{6.3.4.1}) which gather some nodes and services to use them collectively. For example each group of nodes track one object but changes the target in case an event occurs.

5.1.3.5 Hardware

If more performance is desired and the nodes are equipped with multiple hardware devices, we can change the processor and memory selection. The modules of the applications running on the nodes with modularity support (such as from SOS [42], Contiki [41], etc.) have received certain proportion of the computation possibility.

23


However, the proportions must not be fixed, because the consumption of CPU is different and dynamic. There are some modules such as encryption which need much more than other ones. Sensing modules can vary strongly, because their consumption depends on the data amount. Therefore, the hardware architecture contains heterogeneous. The processors are assigned to the modules according to their need. [27] as example provides a communication bus connecting several modules to share the processors. In the similar way, the allocation is always changed adapting to the memory consumption. This mechanism is supported by the dynamic operating systems, but if memory overhead occurs, additional memory can be used. If the nodes are equipped with a field‐programmable gate array (FPGA [30]), they are easier to be reconfigured. The complex configuration with regard to performance is showed e.g. in [32].

5.2 Dependability This class contains reconfigurations for achieving the objective dependability. Scenarios in Figure 12 show when dependability is needed. • ensure correctness, completeness, consistency of applications and network functions

• remove software bugs • verification

• guarantee dependability • flexible system

• heterogeneity • short reboot

• keeping node availability and network robustness (due to instable wireless transmission, conflicts, latency) • improve the performance of all algorithms (but not relevant for this class) • topological reconfiguration

• node replacement • reconfigure the communication channel

• link replacement • multiple routing • synchronization

• self‐organization • monitoring the system status

• reconfigurable non‐functional parameters for dependability

Figure 12: Scenarios for Dependability

First scenario describes that all applications requiring reconfiguration in WSNs should be considered. The come into being network functions for reconfiguration from class Functionality (see Figure 5 and 6) are expected to run stably. The accurate services should be available and consistent as long and often as needed. If software bugs appear, they should be fixed as fast as possible. The software reconfiguration in {5.2.3} describes algorithms for software update. Furthermore, algorithm termination and deadlock‐free state are to ensure. However, using simulation and testbed, the robustness of the

24


applications can be verified. For that, we can read the evaluation part of each paper. This thesis especially focuses on dependability of the whole system in WSNs. The unique main scenario for Dependability is guarantying dependability. Dependability of the system is very important, because additional to that the system fulfils the specification of the user theoretically, it should run robustly, reliably and flexibly. Flexible systems provide heterogeneity where applications are performed with different operating systems, platforms or in programming languages. Thus, they should still keep the same functions with the same quality. That requires higher abstraction and compatibility (by reconfiguring the Hardware/OS/VM/Framework/Middleware Support). A reboot of the system is necessary after each reconfiguration, but it may be short due to the real‐time condition. Since resource especially energy is very limited, sensor nodes often break down. Thereby, the communication is not always ensured, because data are not transmitted directly to the node, but via the other ones. Thus, the network should be restructured by changing the topology and communication model. Failed nodes can be replaced. That may refer to any topology formation, node selection, role update and localization frequency adaptation. Clearly, the performance is a vital factor for dependability, but it is still considered in the main class Functionality. Furthermore, the transmission in wireless networks is often unreliable due to communication channel error. Especially in high dense networks, there are many conflicts, because contention may happen. In this case, reconfiguration of the channel and routing and finally synchronization among the nodes are needed. Therefore, links can be replaced and routes are set redundantly. Such requirements pertain to reconfiguration in routing protocol and middleware support. An important requirement from keeping dependability is self‐organization. The WSN should act automatically. It can solve problems immediately, because any human intervention takes some time and its complexity increases with the network size. Self‐organization refers to all approaches (and also reconfigurations). The last requirement occurs in case of failures, the system should allow monitoring its status. If the network is not self‐healthy, the user can intervene. Dependability level can be selected and relevant mechanisms are deployed to adapt the system according to the current status. Belonging to the mentioned scenarios and their requirements, we derive reconfiguration options for each application and network functions (see Figures 5‐8). It means that any application can be deployed. If one (part of) scenario for Dependability happens, we can reconfigure the system by considering the same network functions and reconfiguration possibilities and options like in Functionality. However, the approaches are different, because they do not focus on achieving the specification or performance. Figure 13 shows alternatives of the reconfiguration options which improve the dependability of the whole system.

25


RECONFIGURATION OPTIONS [alternatives of the options and] references to the papers:

Node properties: • CLUSTERING or ROUTING TREE or OTHER

FORMATS • Node replacement [21]{6.2.1.1}

[29]{6.3.2.1} • NODE SELECTION AMOUNT

• select a set of nodes • ROLE ASSIGNMENT

• complex role specification and assignment [52][53]{6.2.1.2}

• redundant roles • ROLE DISTRIBUTION

• publish‐subscribe model for saving node deployment [50]{6.3.1.5}

Middleware: • ABSTRACTION

• Component‐based middleware services for heterogeneity [4][5]{6.2.4.1}

• PROTOCOL SUPPORT • Node replacement [8]{6.2.4.2},

[6]{6.3.4.1}

Network: • ROUTING PROTOCOL

• multiple route for link replacement [29]{6.3.2.1}

• COMMUNICATION • publish‐subscribe model

• LOCALIZATION FREQUENCY • predictive and adaptive localization due

to node failures [28]{6.1.2.2} Software: • UPDATED CODE AMOUNT

• like in Performance • OS SUPPORT

• Abstraction MagnetOS [36], Mantis [37] • VM SUPPORT

• Abstraction Mate [38] • FRAMEWORK SUPPORT

• Driver replacement OSGi [17]{6.3.3.5} Hardware: • ABSTRACTION [40]

Figure 13: From Reconfiguration Options to the Papers in Dependability

5.2.1 Node Properties Since nodes in WSNs sometimes fail, they should be replaced to fulfil the desired task. Either in clusters or routing trees, cluster‐heads or parent nodes are very important, because the data aggregation goes via them to other nodes. In the replacement procedure, we consider the failure detection, notification and exchange. There are different variants to detect when a node is off. The first possibility is that after certain timeouts, one node does not send any data to other nodes, these nodes would notify. Second, even after specified times of requests, one node does not respond. Finally, the remaining energy of one node is lower than a certain threshold. If one node is detected as failed, the detector can notify the whole network to re‐elect new cluster‐head or parent nodes. Only in the case that the failed node is not able to influence the topology or is not important for the task, the detection is ignored. However, this is a probabilistic approach. The existing approaches work with a global notification, because the clusters or sub‐trees are not independent. Within a cluster or sub‐tree, the cluster‐head or parent node can take over the exchange. It is the most appropriate node to do that, because it has connectivity to all other nodes in its cluster/sub‐tree. It assigns the same role the failed node has to one passive node. If the cluster‐head/parent node fails, other nodes there receive responsibility for the exchange, but it may cause redundant replacement, because more than one node would start this procedure. For more details see i.e. [21]{6.2.1.1} or [29]{6.3.2.1}.

26


The role assignment algorithms in Dependability are more complex than in Functionality where only roles ON, OFF, CLUSTER‐HEAD/PARENT NODE and SLAVES are specified. Here, we add roles such as GATEWAY for node which connects its cluster with another one. Additionally, redundant roles for example second cluster‐heads/parent nodes are set for one cluster/sub‐tree are suggestive. The role specification refers to more node properties than only energy and sensor. For example, other roles in the neighbourhood decide about the role for one node. Details are in e.g. [51][52][53]{6.2.1.2]. These papers provide different role distribution algorithms. Another distribution is the publish‐subscribe model where the roles are assigned directly to the relevant nodes (e.g. see [50]{6.3.1.5}) to reserve participation of other nodes.

5.2.2 Network Using multiple routes is a good approach to repair the routing in case of link failures. The data will be transmitted to more than one node. The receivers also transfer to more than one node. In e.g. [29]{6.3.2.1}, some ants are flooded and the other ones follow them in case of possible feedback (high pheromone amount). Publish‐subscribe model (e.g. in [17]{6.3.3.5}) is used to ensure reconfiguration start in case an event occurs. This model requires event‐based systems where all changes in the WSNs are notified. Examples are node properties or network status changes. However, the system could self‐organize and self‐repair. It communicates only with relevant nodes or parts of the system and reconfigure automatically. Due to failures in WSNs, the localization frequency should be dynamic. See the approach in Functionality [29]{6.1.2.2}).

5.2.3 Software Software reconfiguration is very important for Dependability. Due software bugs, software update algorithms are required. They are also needed in Function where some functions are added or changed. However, here we only need updating small parts of the program code. Therefore, approaches like Performance are deployed. The unique software reconfiguration is the abstraction and heterogeneity support. Some operating systems in WSNs like MagnetOS [36] or Mantis [37] provide high abstraction level for the modules. Using virtual machines (e.g. Mate [38]) on other operating systems like TinyOS [39], the level can be increased. Furthermore, frameworks offer application abstraction, which is similar to heterogeneity support. In Dependability, we consider several drivers for different systems which are not equal with regard to hardware, programming language, etc. For example, OSGi [17]{6.3.3.5} presents a collection of sensing applications for independent systems.

5.2.4 Middleware With middleware reconfiguration, we can increase the abstraction level after software reconfiguration. The components of one system (such as applications and services and not small modules) are hidden. [4][5]{6.2.4.1} show an example for such middleware service. Node replacement can also realized by middleware services such as in [8]{6.2.4.2} and [6]{6.3.4.1}.

27


5.2.5 Hardware Hardware abstraction is used to protect the implementation and to support hardware portability. [40] is an example for reconfiguring hardware that abstraction is ensured. It divides hardware modules into three layers.

5.3 Security The main class Security investigates on the reconfiguration for protecting the WSN against attacks. Here, we want to ensure authentication, privacy, integrity and indisputability. Availability is also a security goal, but it will be considered in the main class Dependability. After a network is deployed, its nodes and transmitted data should not attain an attacker. Otherwise, he could read the sensitive information or even modify them. Therefore, the nodes are always controlled and data such as sensor and network information are kept secret. The importance of security increases with the severity. Especially in military area for example intrusion detection, the authentication is very important, because the access to the whole or to a part of the network is guarded by it. In civilian areas, it depends on the sensing data. In this case, communication keys are distributed to decide about the admission. Communication channels for the keys and for the transmitting sensor data are designed cautiously. In some case such as monitoring a building, the privacy plays a vital role. All data meant to be encrypted and to become unchangeable by cryptographic algorithms. Due to multi‐hop routing, the freshness and correctness of data should be guaranteed. Therefore, data and time should be synchronized. The following scenarios (see also Figure 14) require reconfiguration for adapting the WSN to the current security risk. First, Secure localizations are also important. Since the nodes are often deployed in not protected area, the adversary must not know their location. Otherwise, he may start a physical attack and hijacks some nodes directly to influence the network. If he has control over enough nodes, especially nodes which play a vital role for routing, he could achieve the conclusive information. In such attack, he listens to the communication between other nodes or even modifies the content. He could paralyse some nodes or functions, so the network works incompletely. The denial of services attack and Black hole attack are similar. One cause comes from overload of functions in the network. The denial of service attack blocks the channel for sending or pretends that the data are sent successfully. In Black hole attack, the attacker would drop all packets. Sybil attack is based on the fake of identity. Data may be sent back to the attacker’s virtual node, because the receiver cannot find out the legal node from multiple nodes. One protection mechanism for all mentioned attacks is that the topology for communication and routing will be reconfigured. Therefore, we maintain different alternatives to disseminate the data or to connect the nodes with each other. Another protection mechanism is to enhance the data transport. The routing protocol should be flexible, for instance the number of forwarder can vary. The last important mechanism is based on the selection of cryptographic algorithms. There are many variants, each one can benefit either in performance or in security. The other main scenario for achieving security points to the system availability, which is taken care in the main class Dependability.

28


• Ensure all security goals for data dissemination by protecting against attacks such as physical attack, denial of services attack, Black hole attack and Sybil attack • Topological reconfiguration: different routing and communication possibilities • Data transport reconfiguration • Changing cryptographic algorithms

• Ensure system availability (see the class Dependability)

Figure 14: Scenarios for Security Performing each application (see Figure 6) in WSNs, we expect a certain security level for each data transmission. The data can the network control information, sensing data and communication content. The required level depends on the range of application. Therefore, the user or the network should have an application (see Figure 15) to change it. Thereby, it leads to consider the main network function where security is needed such as secure data transport. APPLICATIONS APPLICATIONS and/or NETWORK FUNCTIONS AND/OR RECONFIGURATION POSSIBILITIES:

• ALL APPLICATIONS IN WSNS • CHANGING SECURITY LEVELS

• SECURE DATA TRANSPORT

Figure 15: From Applications to Network Functions in Security Figure 16 and 17 show useful network functions by reconfiguring for Security and the reconfiguration possibilities and options from there. The network function secure data transport requires a topology formation. The topology is selected like in main class Functionality and Dependability. Additionally, the forwarding area and sliding window describe how the forwarders are determined and how many are suitable. With that, different routes for communication or data transmission can be produced. This network function demands an appropriate key management which decides about the participants while the transport. A secure localization is needed, otherwise attacker may hijack the nodes. Furthermore, keys are generated for the node authentication before receiving or forwarding data. The authentication objects can be the control (protocol) messages or all data. After successful authentication, the session for transmission will be generated. However, it is changeable how long the session is valid, whether for each packet or for some packets at one time. Next, the key distribution works pair‐wise or group‐wise. Unicast between one node and the base station needs a direct key exchange. In contrast, multicast occurs between one node and a group of nodes. Encryption cannot be left out, if we want security. The encryption algorithms differentiate from each other according to the performance and security level. Hence, it should be selectable by the user and even by the network. There are many routing protocols. The main difference according to Security is the amount of state information. Some only use probabilistic decisions to select the next forwarder during the routing. The performance increases, because no information about the nodes has to be transmitted. However, security is affected. In contrast, forwarders can be determined considering possible attacking nodes.

29


NETWORK FUNCTIONS NETWORK FUNCTIONS and/or RECONFIGURATION POSSIBILITIES:

• SECURE DATA TRANSPORT • TOPOLOGY FORMATION • KEY MANAGEMENT • ENCRYPTION • ROUTING PROTOCOL • DATA DISTRIBUTION

• KEY MANAGEMENT • PARTICIPANT DETERMINATION • AUTHENTICATION OBJECT • SESSION GENERATION • KEY DISTRIBUTION

Figure 16: From Network Functions to Reconfiguration Possibilities in Security RECONFIGURATION POSSIBILITIES RECONFIGURATION POSSIBILITIES and/or RECONFIGURATION OPTIONS:

• TOPOLOGY FORMATION • FORMAT SELECTION LIKE IN OTHER MAIN

CLASSES • FORWARDING AREA • SLIDING WINDOW

• DATA DISTRIBUTION • LIKE IN OTHER MAIN CLASSES • OF STATE INFORMATION

• PARTICIPANT DETERMINATION • SECURE LOCALIZATION • COMMUNICATION PAIR or

COMMUNICATION GROUP

• ROUTING PROTOCOL • PROBABILISTIC DEFENCES or DEPLOYMENT

• AUTHENTICATION OBJECT • MESSAGE AUTHENTICATION or DATA

AUTHENTICATION • SESSION GENERATION

• SESSION LENGTH • KEY DISTRIBUTION

• PAIR‐WISE KEY ESTABLISHMENT • GROUP‐WISE KEY ESTABLISHMENT

• ENCRYPTION • ENCRYPTION ALGORITHM

Figure 17: From Reconfiguration Possibilities to Reconfiguration Options in Security As result of the above deduction from scenarios requiring security aspects to reconfiguration options, we maintain different alternatives and papers (see Figure 18), not like in Functionality and Dependability. RECONFIGURATION OPTIONS alternatives of the options and/or references:

Node Properties: • SECURE LOCALIZATION

• range and distance bound [2] • authentication beacons [3]

• COMMUNICATION PAIR • COMMUNICATION GROUP

• fixed • dynamic

Middleware: • PAIR‐WISE KEY ESTABLISHMENT Deng

[19], LEAP [20] • GROUP‐WISE KEY ESTABLISHMENT

Carman [23], LEAP [20]

Network: • FORWARDING AREA

• whole neighbourhood [12]{6.4.2.1} • one area [12]{6.4.2.1}

• SLIDING WINDOW [12]{6.4.2.1} • PROBABILISTIC DEFENCES [12]{6.4.2.1} • DEPLOYMENT OF STATE INFORMATION [12]{6.4.2.1} • SESSION LENGTH

• session for one time • session for many times

• ENCRYPTION ALGORITHM • asymmetric Encryption Diffie‐Hellman [7] , RSA [9] • symmetric Encryption DES [11], AES [14] • hybrid Encryption [18]

Figure 18: From Reconfiguration Options to the Papers in Security

30


5.3.1 Node Properties Node properties reconfiguration for Security deals with the participation of the nodes in communication and routing. Like in other main classes, the network function coverage is performed. Nodes are selected and localized and finally they are assigned for some tasks. The difference is that the localization should be secure. [2] limits the range and distance, therefore the attacker would detect the nodes in a very small area. [3] provides a range‐independent localization and uses authenticated beacons. Furthermore, the node‐to‐node communication achieves higher security, because the base station as communication partner has more resource for complex encryption. However, the WSN does not always grant this fixed structure. Thus, groups are built to forward communication content, but they should be dynamic. With that, the adversary has to attack many times, even if he has control over one group. Therefore, coverage should be considered but is described in other main classes.

5.3.2 Network Reconfiguring the network properties and network protocols, we consider the adaptation of routing and encryption to the current situation. [12]{6.4.2.1} focuses on such reconfiguration and provides many improvements to enhancing security. It contains three selectable routing protocols. They differentiate from the state information, but the more state information the more attacks would be avoided. Its forwarding area and sliding window are changeable from the whole neighbourhood to one small area and from one to many receivers. Encryption algorithms are normally symmetric or asymmetric or hybrid. Asymmetric algorithms such as Diffie‐Hellman [7] or RSA [9] use one public and one private key. They are known in other application areas as achieving high security. However, they are refined upon for resource‐constraint networks. The computation for one key such as in symmetric algorithms DES [11] and AES [14] are more energy‐aware but not such secure. Combining these features, for instance [18] presents a hybrid encryption, whereby the base station performs asymmetric algorithms and the nodes only have to authenticate with the symmetric key.

5.3.3 Software Software reconfiguration is needed in case the security reconfiguration is applied. After each change, the WSNs should receive new configuration such as other algorithms or system parameters. Software update is then performed, which is described in the other main classes. Note that even the update process should be as secure as possible, otherwise the attacker could modify the network.

5.3.4 Middleware As middleware, the key establishment supports the connection of nodes. Its protocols differ from pair‐wise i.e. [19], [20] and group‐wise i.e. [20], [23]. In contrast to {5.3.1} these protocols concentrate on the generation and distribution but not coverage.

5.3.5 Hardware Achieving security, we also need robust hardware. With that, we can provide system availability. However, the reconfiguration is described in the main class Dependability.

31


6. Paper Summaries In this chapter, the reconfigurations mentioned in the survey {5} are described in detail. The summaries show which objective and which capability the papers belong to. The papers are sorted like the simple classification {4.4} (see also Figure 2).

6.1 Functionality

6.1.1 Node properties

6.1.1.1 Towards Self‐organizing Virtual Macro Sensors [34]

N. Bicocchi et al. present a simple algorithm for self‐organisation of sensor network into spatial regions, so that distributed aggregation of sensorial data can be easily performed. This algorithm consists of two parts such as region formation and per‐region aggregation. At the beginning of the region formation each node waits for a fixed period of time t. t delivers the frequency of such operations. All nodes have the same number of operations. After t, for each selected neighbour (the number of neighbours defines the communication cost) the current node transfers important data for updating the link between these two nodes. The update link function is defined as followed:

if ( D(v(a),v(b)) < T ) l(a,b) = min (l(a,b) + delta , 1) else l(a,b) = max (l(a,b) – delta , 0)

If a value of a certain environmental property v (e.g. temperature) differentiates between two nodes (a and b) less than a given threshold T (between 0 and 1), the link l(a,b) converges to one, whereby delta is a value affecting the reactivity. Otherwise, it converges to zero. T and the number of selected neighbours specify the speed of the convergence. If the link of two nodes becomes greater than T, these nodes will be merged to the same region. Due to the sense and purpose of T, each region gets another T, in example T=5°C to differentiate landscapes and T=40°C to detect forest fire. However it should be T=(globalMax–globalMin)*p, whereby globalMax(globalMin) is the maximum (minimum) value of several T in the whole network and p is be to parameterized as a real number to describe the sensibility of the algorithm. Since a stable mode is reached after a certain time, the global aggregation of control data can begin. At this instant, if two nodes are connected, they can exchange or just forward data. The second step is per‐region aggregation. At this point, we only have to perform local aggregations, because various regions will be merged to larger regions and at some point, we cover all nodes. This paper provides two aggregation functions. The first function describes that nodes at the border of a region (each of these gateways has at least one link less than T) propagate sensorial data. On the other hand, the second function affects an election of region leader by exchanging the unique IDs and thus selecting the node with the minimum ID.

32


6.1.1.2 Energy‐Efficient Clustering System Model and Reconfiguration Schemes for Wireless Sensor Networks [1]

In this paper, H. Su et al. extend their analytical model to maximize the network lifetime. Thereby, several parameters such as the number of clusters are gained by complex simulation. Furthermore, they provide energy‐threshold‐driven based clustering reconfiguration schemes, which outperform existing ones. This model assumes that there is no node localization, all nodes have the same range, communications are contention‐free and nodes work without error. Let Pr (Pt) the consumed energy for transmitting (receiving) a unit of data, β thus is the loss percentage with Pr = β*Pt. For each network type, IEEE 802.x has specified β differently. p* is the probability that a node becomes the cluster‐head. It depends on the nodes density parameter m and β. Simulations show that p* is a monotone increased function. Finally, the number of forced cluster‐heads should be minimized. Since cluster‐heads consume more energy than other nodes, the entire network lifetime is short. Therefore, such schemes attempt to balance the energy consumption. In case of defined conditions are not fulfilled, cluster‐heads should be substituted by one node in the same cluster. As the result, the number of cluster‐heads will not change. This paper presents two types such as T‐Driven and ET‐Driven algorithm. In T‐driven algorithm, cluster‐heads are periodically elected by each node. This algorithm will not occur a clustering if the reconfiguration period is longer than the lifetime. ET‐Driven algorithm includes two criteria for stopping re‐election. In ET‐Driven 1 (criterion 1) the cluster‐head compares its initial energy Einit with its residual energy Eres. Before that, all nodes of the set C within a cluster piggyback its residual energy Ememi. If Eres/Einit < Thcond1 is met, whereby Thcond1 is predetermined as parameter, the node i will replace the cluster‐head. The algorithm is like followed: 1: New Round begin 2: repeat 3: receiving the message including raw data plus energy information from node i 4: until get messages from all member nodes 5: Processing the raw data 6: Transmitting the aggregated data to processing center 7: if Eres/Einit < Thcond1 then 8: Rotating the role with node[arg maxi�C Ememi] 9: end if In ET‐Driven 2 (criterion 2) is based on ET‐Driven 1. Only lines 7‐8 from the algorithm of ET‐Driven 1 are changed. Line 7 is replaced by: 7: Emax = maxi�C Ememi ; if Emax/Eres > Thcond2 then and line 8 by: 8: Rotating the role with node[arg Emax]. Here, energy of the cluster‐head and of the node with maximal residual energy is directly compared. Consequently, reconfiguration does not have to be changed many times. Figure 19 shows a comparison between static BCCA [55], LEACH [56] and algorithms from this paper. LEACH and static BCCA are clustering schemes similar to the algorithms of this paper, but they do not care about the very important parameter β. As an advantage, LEACH works with different transmission power and thus different ranges. For T‐driven algorithm, the reconfiguration period is set as 1 and 10 rounds. As the result, ET‐Driven 2 is the best of algorithm for clustering, because the density of nodes does not

33


really influence the network life. In the ranking ET‐Driven 1 follows and then with T‐Driven together. Clearly, the static BCCA is worst.

Figure 19: Comparison among algorithms with various node densities. (left: network lifetime, right: the average number nodes subjected to change cluster every round. [1 modified]

6.1.1.3 Scalable Data Aggregation for Dynamic Events in Sensor Networks [10]

In this paper, K. W. Fan et al. improve the data aggregation especially for large‐scale networks. They use the structure‐less aggregation, called Data Aware Anycast (DAA) [57]. In the next step, they perform the Dynamic Forwarding on the structure ToD (Tree on Directed acyclic graph). Normally, events define which sensing task nodes receive. A cell includes two nodes which are triggered by the same event. Figure 20 shows the next steps of the formation into ToD. Then, each F‐cluster (First‐level cluster) combines two adjacent cells (one hop). F‐aggregators are cluster‐heads. The first phase of this protocol is DAA. DAA is performed only toward the F‐aggregators. The problem in a structure‐less aggregation is that nodes need explicit messages about the end of aggregation and about the next destination. Only when these messages enter, they could forward. Thus, there are two important conditions for aggregation such as spatial and temporal convergence. Due to spatial convergence, a node, which is able to aggregate (according to its capabilities), is the next destination. Temporal convergence is achieved by using randomized waiting (value between 0 and a reconfigurable maximum delay) for each node, before it could forward. The disadvantage of DAA is that the sink maybe does not receive only one packet including all data. Therefore, DAA can waste much energy. Solving the problem of DAA, the authors continue forwarding after DAA has no more aggregations. In the case that one event spans just one F‐cluster, the aggregation will be forwarded directly to the sink. Otherwise, S‐aggregators (Second‐level aggregators) group two F‐aggregators including adjacent cells in different F‐clusters. The above ToD has one dimension and is now is expanded to two dimensions because all F‐aggregators can be assigned to multiple S‐aggregators. The nearest S‐aggregator will be selected, thus avoids leader election.

34


Figure 20: The construction of F‐Tree, S‐Tree and ToD. (a) Leaf nodes are cells. Pairs of cells build F‐clusters. F‐aggregators F1‐8 form the F‐Tree. (b) S‐clusters from adjacent cells pairs. (c) Each F‐aggregator connects to two S‐aggregators. [10] Concluding, data dissemination with this protocol is better than only with DAA. ToD consists of multiple shortest path trees. Hence, data packets are forwarded via F‐aggregators and eventually also via S‐aggregators to the sink. Nodes just have to (know and) communicate with their F‐aggregators, thus is adaptive to scale networks.

6.1.2 Network

6.1.2.1 Toward Automatic Reconfiguration of Robot‐Sensor networks for Urban Search and Rescue [13]

In this paper, J. Reich et al. introduce several algorithms to achieve an automatic network reconfiguration and thus prepare for urban search and rescue. They use a large of simple sensors to guide fewer robots with more mobility capabilities to their targets. This robot‐sensor network especially requires special communication, routing, localization and target tracking. Monitoring the area, various sensor nodes are usually deployed in front of obstacles, but the targets can be everywhere. Since there is no global control of the position of nodes, robots and obstacles, each node should decide how they want to support the robots. Due to the limited resources in such network, the routing protocol should be set as energy‐aware as possible. Since nodes only know whether they are in the vicinity of one target and how they can reach their neighbours, the simple popular Distributed Vector routing algorithm is applied here due its small exchange of routing table. Consequently, they

35


inform each other if the target is detected. Finally, each node leads the robot to its nearest neighbour, which also has neighbours detecting the target. The network configuration mainly depends on the states of each robot. Each robot is in one of three states such as in Figure 21. At the beginning (state 0), it approximates the way to the target. Detecting a node in its range, it follows this sensor. If it receives a signal that one node finds the target, it searches until it reach the target and consequently broadcasts about ownership. In the case that another robot has been there before or the target signal is lost, the robot restarts the search.

Figure 21: Robot behaviour hierarchy [13]

Improving the performance, this paper provides extensions on information exchange. The communication content between robots and nodes is added by labels, time‐stamp and visit counter of involved nodes in the guide, therewith curious robots do not take the same way. Furthermore, robots are postulated to ensure a way back by leaving traces. Additionally, the robot movement can be also reconfigured. Normally, they move forward and turn randomly to one side. This movement is adapted to the environment. Naturally, the quality of target detection depends on the obstacle density, but experiments in this paper show that we should use three times sensor nodes comparing to the number of robots and 90 % of the targets can be discovered. This robot‐sensor network is better than robot‐only network, except if some targets have much more nodes nearby than other ones, because robots will revisit these nodes too often.

6.1.2.2 Dynamic Localization Control for Mobile Sensor Networks [28]

In this paper S. Tilak et al. concentrate on the protocols for controlling the frequency of localization. Since nodes are mobile, they must continuously determine its location, but this process consumes energy. Thus, this localization has an energy‐accuracy tradeoff and can be used for tracking application. S. Tilak et al. develop two approaches such as adaptive and predictive localization comparing with the static localization (SFR) for more non‐mobile nodes, where the period is fixed. The adaptive tracking is called here Dynamic Velocity Monotonic (DVM). If one node has higher velocity between two localization points, it must increase the localization frequency to maintain the same accuracy, but it causes more energy consumption. Thereby, the node divides the moved distance by the time that the node passes by and thus achieves the frequency for next localizations. Additionally, there are upper and lower thresholds to limit the energy.

36


The authors of this paper investigate the first approach using dead‐reckoning, called Mobility Aware Dead Reckoning Driven (MADRD) tracking. Here, the mobility pattern is regarded to calculate the future localization frequency (see state diagram for MADRD in Figure 22). The frequency converges to zero while the prediction of the pattern becomes better (in case of error level is smaller than threshold then state S1) and does not change (state HC). Otherwise, the pre‐defined rate of divergence will be exceeded (state LC) and the localization must be performed more often.

Figure 22: State Diagram for MADRD [28]

The error analysis of this paper shows results for four cases. In case where there is a simple constant velocity, SFR contains the most error percentage, which is proportional to the velocity. Furthermore, MADRD is better than DVM. In case of some nodes move constantly and then stay on one place for a long period of time, all three approaches reach nearly the same accuracy. If nodes move constantly but change their direction, MADRD cannot predict exactly as the others. As last case, if velocity changes, MADRD will provide the best accuracy. Comparing the energy consumption, if the velocity is over 4 m/s, all these approaches are the same. However, at velocity of 1, MADRD is clearly the best approach and then DVM follows.

6.1.2.3 Self‐Organized Routing for Wireless Microsensor Networks [31]

A. Rogers et al. implement an energy‐aware self‐organized routing algorithm. The performance reaches nearly the optimal solution providing by a centralized optimization and is anyway more flexible among the network structure. This routing algorithm is like other “on‐demand” routing, it means that sensor nodes are requested to forward data. The main difference represents the local and not distributed decisions. Transmitting data from the source to the sink, nodes betwixt should minimize their own energy consumption and maximize their contribution (payment scheme). At first, we consider the radio propagation to understand the energy problem. There are deterministic and probabilistic model. The simple deterministic model says that signals are transmitting over the radius r (radial distance between one node and the sink) with the power p, which is proportional to the square of r (p ~ r²). Furthermore, the lifetime t of one node is defined as followed: t = 1/r². In the nature, transmissions are asymmetric, thus the power is not the same for forward and back direction. Hence, the probabilistic model is used by adding a randomly error percentage e (p ~ (r + e)²). However, this small performance loss underlies the gain in lifetime, which occurs when the communication is extended for long ranges but has less power. As the result of the radio propagation, we should maximize both the lifetime of each node and coverage area of the whole network.

37


The next part of this paper describes the communication protocol. While sensor node S1 tries to connect to the sink node, a suitable node for forwarding is selected. The example in Figure 23 shows that only nodes at point (3) are good candidates for forwarding, because nodes at point (1) are farther then S1 and via nodes at point (2) would be more than r. S1 now sets the best candidate as mediator. Thus, it can reduce its energy consumption to nearly a half, because the way to the mediator is about r/2. In the nature, it cannot be exact r/2, therefore we do not have an optimum. Additionally, due to the complex network topology, the global optimum will also not be achieved, because the current mediator is thereby not available

for other nodes and/or may itself find a mediator.

Figure 23: mediator search area [31]

The simulation of this paper with 100 nodes shows that 80% of the centralized optimization can be reached, but here global control data collection is not needed (see Figure 24). While more and more nodes become inactive, they have larger mean radius or rather they still have better coverage (the shaded area shows the improvement of this algorithm (triangles) comparing with default case (solid line). Only the centralized optimization (circles) is a little bit better.

Figure 24: Comparison for the default case (solid line), this approach (triangles) and the optimal solution (circles) [31]

38


6.2 Dependability


6.2.1.1 LACON: Localized Autonomic Configuration in Pervasive Sensor Networks [21]

M. Mudasser Iqbal et al. show a model for self‐configuring sensor networks, especially which ones using in important areas such as in biological applications. They protect the network against failures but ensure high coverage. Thereby, they optimize some parameters for network formation and particularly control the communication and connectivity. In this paper, the network is formatted into a virtual hexagonal topology based on the location and range of nodes. The average range of one child node (PS) to another or to a parent node (PN has more resources than a PS) is between 2 and M times of its range. M is a reconfigurable variable that is determined by the available power and distance. Furthermore, the average range of a PN is as of the PS but the factor modulo 2 is 1. The federation of single hexagons is calculated basing of the average range of the PN. It derives a Federation Effective Boundary FEB which describes the area in which the PN is available. Routing within FEB goes via this PN (see Figure 25 for the optimal coverage as example). After this formation, PNs are localized so that the maximum of PSs are covered and the Grey Region (outside FEB) is minimized. Additionally, the Confusion Zone where there is more than one PN for a group of PSs is reduced.

Figure 25: Coverage and Federation [21]

The second part of this paper is about the self‐configuration model. This model describes how PSs should connect to the PN. In a session, parent and PSs have to handshake just one time and all data transmissions are reported. Then, a PN receives an Availability Request from all PSs and returns its ID including the coordinate. So, PSs can communicate with the closest PN. Due to PN failure, congestion thus information loss and addition of new PNs the authors develop a Self‐Configuration Protocol (SCP) to monitor and repair the network. A PN failure can be fixed as followed. In variant one, PSs, which are not in coverage anymore, start a search for another PN after each timeout until one PN accepts. The second variant describes the task of other PNs. The first PN, which detects this failure (but also has longer Time to Life (ETL) than the mean ETL of its neighbours), sets the PS being closest to the failure as AssociatedPN (replaces PN). In the third variant, if PNs are mobile, they can close their sessions and build other federations with fewer hexagons. The solution for congestion is that PNs in the vicinity will be requested for sharing tasks (mobile PNs needed). If information loss occurs through exceeded ETL or lower load, the overloaded PN will set the PS that is nearest to the PN with minimum load as APN. The APN transfers one part of the load from the overloaded PN to the PN with minimum

39


load. In last case, new PNs are normally added near the largest Grey Regions. If they are mobile, they can be reconfigured as the third variant of PN failure case but with more hexagons. Simulations of this paper show that more than 80% of PSs work, even if half the PNs fail. Furthermore, an APN is selected by 20% overload. However, double number of PNs does not ensure double availability after re‐formation.

6.2.1.2 Algorithms for Generic Role Assignment in Wireless Sensor Networks [51], Generic Role Assignment for Wireless Sensor Networks [52], Solving generic role assignment exactly [53]

Römer et al. propose very complex algorithms for generic role assignment. The network administrator or the software designer uses the role specification language to easily define tasks by setting roles and rules for their assignment. After that, an algorithm is performed to assign new roles to the nodes. A role specification is installed on nodes or adaptively distributed via network. It contains various roles and according conditions. For that, some parameters are given: props (properties), rel (relation), const (constant), size (number of matching nodes), scope (grade of neighbourhood), etc. Following table shows the syntax and semantic of expression: Atomic predicates

Syntax Examples Semantics

Simple props rel const battery >= threshold

the condition for a role

Count count(scope){pred} rel const

count(2 hop){role == ON} <=2

number of nodes depending on condition of pred, rel and const

Retrieve P == retrieve(scope,size) {pred}

clusterheads == retrieve(1 hop, 2)

list of node’s IDs

Nested predicates

Pred role == CH predicates inside other ones

As example (see Figure 26), the specification for the role GATEWAY in the clustering application is defined as follows: 1 2 3 4 5 6 7

GW :: { clusterheads == retrieve(1 hop, 2){ role == CH } && count(2 hop) { clusterheads == super.clusterheads } == 0} SLAVE :: else

Figure 26: An example for Gateway: A Gateway is directly connected with two cluster‐heads and 2 hops far away with slaves.

Other often deployed applications are coverage and In‐Network Aggregation using such a role specification. Reserving battery power, just some of nodes are selected to be turned on. To manage an efficient data dissemination, roles such as SOURCE (for nodes gathering and processing data), AGGREGATOR (for nodes which just forward) and SINK (for receivers) can be defined. In [53] the authors provide better analysis of the role specification which is mapped to an integer linear program formulation. Thus, the binary variable xik declares that if node i

40


fulfil the predicate ck of a given role k, xik = 1, otherwise xik = 0. In addition, showing the role assignment is feasible, at least one role predicate at each node has to be satisfied: ∑k xik >= 1 ∀k,i , whereby a role ELSE can avoid infeasibility. The objective function as optimization criteria is defined as follow. The administrator wants to minimize the set of roles m ⊂ R and maximize the set of roles M ⊂ R: min ∑i�V ( ∑k�m yik - ∑k�M yik ). [51] presents different variations of algorithms for role assignment. The straight‐forward algorithm is based on a fixpoint iteration and has mechanisms such as timeouts, ABORT and CONFIRM messages, and periodical information exchange. Furthermore, it defines a maximum radius to broadcast. Nevertheless, this algorithm achieves low efficiency because it still indicates too much message overhead. The new basic straight‐forward algorithm mentions possible mechanisms to improve the efficiency. There are three steps in the basic algorithm: first Initialization, second Property propagation and third Locale Rule Evaluation. At initialization time, since each node receives the same rules, the basic algorithm can detect which properties which nodes need for their evaluation. Therefore, it achieves higher efficiency than the straight‐forward one. Thereby, it refers to the local cache tables of each node. Figure 27 shows a typical cache for the coverage application. Beside the SOURCE node which possesses some properties (KEY) with their VALUEs, the table contains a DISTance to the source nodes (starting with 0) which need information from the initiator (A). Furthermore, the MAX value returns the maximum hops to propagate according properties and the sequence number (SEQ.NO) will be increased just by the source node (A) if and only if these properties change. The last column says whether these properties are transferred (DIRTY= false).

Figure 27: Node A after initialization [51]

Each node performs a local rule evaluation after property propagation and a delay teval. Consequently, it does not evaluate roles simultaneously and is not assigned to a role which is unstable. In this process, if a role changes, property propagation will be started immediately. In the example above node B starts the local rule evaluation and set the role to OFF, because it fulfil all conditions but node A still has the role ON. Experiments show that very few role changes lead to a stable assignment. Nevertheless, it is still some kind of flooding. Reducing message overhead, this paper also presents an improvement with two probabilistic initialization ways such as “Drawing Roles” and “One Wave”. The mechanism “Drawing Roles” uses the calculated probabilities {p1,...,pq} that each node speculates to be assigned to one role of {1,...,q} at initialization time. Thereby, probabilities defining by experienced person for the predicates of role specification will be regarded altogether. Thus, the initialization with certain roles is certainly an improvement toward the basic algorithm where each node starts with the role UNDEFINED. The probability calculation for atomic predicates ck follows as example. The

41


probability of the whole condition for one role is the sum of the product of the probability of particular predicates is as followed:

pk = P(ck) = ∑i ∏j P(ckij) with ck = (ck

11 ∧ ... ∧ ck1n1

)∨(ck21 ∧ ... ∧ ck

2n2)∨ ...

Improving the above role propagation especially for transmission of role specification, the mechanism “One Wave” sets the bound properties deterministically. Here, only the sink node is able to start with an update message. Other nodes receive it, take a role and piggyback their changes onto this message. Nodes, which already involve in the propagation wave, are considered for the locale evaluation on the current node and the other ones will be interpreted with probabilities.

6.2.3 Software

6.2.3.1 The Dynamic Behavior of a Data Dissemination Protocol for Network Programming at Scale [49]

J. W. Hui et al. presents the data dissemination protocol Deluge, especially for large objects. Deluge provides a reliable multi‐hop transmission. Furthermore, it supports incremental software updates by comparing version numbers. This protocol contains a deterministic state diagram with three states for each node, decided by some local rules to ensure a consistent complete update. The state MAINTAIN declares that nodes broadcast their advertisements to inform about their software inclusive the version number. However, due to the possible redundant messages, all nodes are able to determine whether they send an advertisement in each given time round or not. If node A receives an older version from B, it answers with its object profile. B then is able to detect changes in the software. The changed objects are here split into fixed‐size pages. Each page is again composed of fix‐size packets. In the state RX, B continuously repeats requesting (after a random time) for some packets of one page from one of its neighbours. One neighbour in the state TX replies with all required packets. Before B requests further pages, it informs that it has new advertisement yet. This mechanism is called spatial multiplexing or pipelining. Therefore, this protocol can improve the overall throughput of the operating system TinyOS [39].

6.2.4 Middleware

6.2.4.1 Reconfigurable Component‐based Middleware for Networked Embedded Systems [5], Dynamic Reconfiguration in the RUNES Middleware [4]

G. Coulson et al. describes the reconfiguration in the RUNES middleware. Adapting to the environment, the modularised and customisable component‐based services in RUNES can be reprogrammed and dynamically deployed. The architecture of RUNES consists of two layers such as Middleware Kernel and Component Frameworks building Middleware Services. The Middleware Kernel contains a component model which defines the performing component at runtime. Therefore, it offers for each service several variants with different functionality or supporting various systems (programming language, operating system, resource level …). It ensures

42


heterogeneity by using interfaces to select the appropriate variant and Bind operation in case of dependence. Components can inherit the functionality of other ones by using Receptacles. Due to the flexibility, RUNES contains many loosely coupled components, therefore particular components are more independent. Consequently, components are easily (re)programmable and can be composed at runtime by openLink operation. The Component Framework (CF) on top of the kernel provides an abstraction of components. A CF consists of other CFs. They all are in fact components. However, the software developer can define Constraints to describe the composition by using specific languages. For example, a CF as network stack has a “MAC” interface and a “routing” interface. Consequently, component development becomes easier and more flexible. Each Middleware Service is built by some CFs. As example, the Interaction Service in RUNES is extended in comparison to other middleware to provide more than one interaction such as RPC, Publish‐Subscribe and Group Communication. The Publish‐Subscribe model is used to effectively broadcast data or to control information. This model also grants the topological reconfiguration, because each node can sign for one topic (interested information, task …) and have not to participate in the network the whole time. If a link fails, the TreeOverlayManager component will be performed to change the tree topology from this model. Otherwise, the PSTransport component manages the distribution of the topic content.

6.2.4.2 Reconfigurable Middleware for Sensor Based Applications [8]

P. Hu et al. present a middleware that supports reconfiguration in context‐aware applications. Due to failures of links in sensor network, the Context Management System in this paper provides discovery and replacement of sensors according to their sensor capabilities. This process is abstract to the sensor nodes. The architecture of context‐aware system is showed in Figure 28. Context specifies the situation of entities in the network, especially these ones influencing the user‐application communication. Once context changes, (e.g. the power level of one node), this system reacts and adapts the sensor choice. It contains three layers. The context‐aware applications are on the top, which use the context information to reconfigure their functionality. In the middleware layer, context information is stored, evaluated and transmitted to the application layer in case context changes. The lowest layer – context sensing layer – contains nodes which produce data to convert to context information. This paper focuses on the middleware layer which is divided into two groups. One group consists of Context Model repository and

Context Facts repository supporting the applications. Other components build a group that is relevant for reconfiguration of the choice of nodes.

Figure 28: Reconfiguration Architecture [8]

43


We concentrate on the Context Sources Manager and Reconfiguration Manager. The Context Sources Manager cooperates with the Sensor Description Repository and controls the communication between nodes and Context Management System. It contains elements such as Sensor Discovery Service, Sensor ML Engine and Common Sensor Knowledge Base (CSKB). The Sensor Discovery service assumes that all nodes have the same communication medium. With that, they can be found and connected. Then, sensing data is converted to digital signals by transducers. TEPS (Transducer Electronic Data sheet) creates a template for each transducer type. Afterwards, these signals are changed to context information stored in SensorML description by using the SensorML Engine. In addition, the Context Sources Manager supports security mechanisms, e.g. authentication. It can check security and privacy rights. Software developers define sensing rules stored in the CSKB. Thus, with CSKB nodes with better capabilities can be selected to replace. The Reconfiguration Manager is responsible for monitoring and adapting the mapping between context fact types and context sources. The first element in this component is the Mappings Monitoring Service. Due to detected context delivery failures, it continuously shows the current mapping. The Context Source Matching Service reacts if a mapping fails. It changes the condition for the matching. The Mapping Reconfiguration Service supports the transfer from context sources to context facts. Finally, it adapts the list of current mappings.

6.3 Functionality&Dependability


6.3.1.1 Localized Performance‐Guided Reconfiguration for Distributed Sensor Networks [35]

P. Joshi and C. Jannett provide a Performance‐Guided Reconfiguration (PGR), which guarantees coverage performance. If a node fails, it will be replaced by redundant node, selected by a cost function for optimizing the network. The first step of this algorithm is target localization. The position of all nodes should be found. The current node as target is estimated by comparing the measured signal strength to a threshold at each node. Then, they transmit binary information to a fusion centre, which combines it with existing information about the position to decide where the target is (details in [54]). This algorithm continues with a formation of the network into clusters with 7x7 active. 6x6 redundant (currently passive) sensors are located between active ones. The PGR takes place in a cluster where a node fails. The following cost function appoints the total cost for a candidate set S for replacement of failed node:

Cost(S) = Nsc + Σγ(ri-r) + ηΣ4j=1 Nj / Rj

Ns amounts the total number of nodes, c is a flat cost per node, ri represents the distance of candidate i, r is the radius of search area, Nj amounts the number of nodes in area j and Rj sums redundant nodes in j. η and γ are changeable constants. The first term shows the absolute sensor cost, the second one determines the distance between failed sensor and the candidate and the last one weighs the cost of utilized redundant resources. With this cost function a ranking of all possible candidates can be established.

44


The simulation in this paper shows experiments with different number of failed sensors and realistic results of PGR. Whether there are some like 34 or many like 257 instants, the percentage of the coverage area still amount 100%. Comparing with other variants of this paper (just as alternatives) no reconfiguration or (as), PGR achieves the highest coverage performance, then the simple nearest‐neighbour reconfiguration follows and worst is if we have no reconfiguration.

6.3.1.2 ASCENT: Adaptive Self‐Configuring sEnsor Networks Topologies [43]

A. Cerpa et al. develop ASCENT in which each sensor node decides itself whether it participates in the network topology for multihop routing. As density increases, the ASCENT algorithm offers a connectivity estimation to sort out some nodes becoming active. Furthermore, an analysis describes the energy saving and the protection against node failures. While the source transmits data to the sink, the formation process starts with only some active nodes and the rest is listening. The remote sink detects a high packet loss (communication hole) and thus sends help messages. While a certain number of active nodes is not reached, a passive node (which is in listening‐mode) in the neighbourhood receives this message and makes a decision. If it wants to be active, it will send a neighbour announcement message to other passive nodes. Now the process has finished or must restart at each node when node failures or environmental changes occur. The state diagram in Figure 29 shows all possible situations for each node. Receiving help messages or at the beginning of transmission just one node is selected by a random timer (no collision). This node comes into the test state and exchanges data and routing control messages. A large timer Tt causes more energy consumption but also better decision quality. Thereby, Tt depends on the reception rate for each link. The node becomes active if Tt is passed. Otherwise, if the neighbour threshold NT (defines the average degree of connectivity) or the previous data loss rate loss T0 is exceeded, the node becomes passive. Tp and Ts are similar to Tt, but they are determined in interdependence.

Furthermore, the network density influences these parameters. In passive state, the loss threshold LT describes how much data should not be lost and thus can require participation. The Boolean value help become true if other nodes explicitly send help messages.

Figure 29: ASCENT state diagram [43]

The very complex analysis and experiment of this paper show the end‐to‐end delivery rate (%) of Active case and ASCENT (see Figure 30). Clearly, ASCENT (flooding only to active nodes) outperforms the Active case (flooding to all nodes), because there is less contention for the channel and less energy consumption by limited number of active nodes.

45


Figure 30: left: the end‐to‐end delivery rate as a function of density, right: the energy savings ratio as a function of density [43]

6.3.1.3 SOTP: A Self‐organized TDMA Protocol for Wireless Sensor Networks [33]

In this paper, Y. Wang et al. develop the self‐organized TDMA protocol (SOTP). SOTP support the MAC layer by providing a collision‐free slot allocation controlled by the base station. As the result, SOTP achieves an adaptive tree‐based topology due to the flexible environment in sensor networks. In TDMA there are frames consisting of more time slots (five types) than the number of nodes, thus allows multiple transmissions per frame. The protocol assumes that the base station has much larger range than other nodes. Each node is in one of the three states: searching (wait for a broadcast), synchronized (select one neighbour as father) or registered. In registered state, it transmits data to its father in transmitting slot (TX) and waits for transmissions of its neighbours in the carrier sensing slot (CS) and receiving slot (RX). It fixes the TX of its children as its RX. Collision is avoided, because for each RX there is only one TX. At the beginning, the base station can periodically broadcast slot allocation packets (SAP) in the broadcasting slot (BR) and runs in registered state. Other nodes are in the searching state. If they receive SAP, they send a register packet (REG) to their father and runs in synchronized state. The father forwards REG to its father and so on. At the end, the base station receives REG and releases one slot for the request. Now the nodes in synchronized state pick up the next SAP including the releasing slot and goes into registered state. The reconfiguration is the flexible selection of father/children, for example depending on the stability of the signal. Furthermore, SOTP is adaptive to node/link failures. The active state indicator packet (ACT) from each node in registered state ensures its activity. The base station periodically receives ACT and adapts the SAP. Thus, all nodes can drop the failed node if the failed node is their child. Otherwise, they wait for some time and repeat the registration. The failed node also tries to register again. The analysis and the simulation of this paper show a comparison to LEACH [56]. Since the transmission in LEACH always goes via cluster‐head to the base station but every node can be cluster‐head, SOTP needs less power. Figure 31 verifies that SOTP has about 30% consumption of LEACH depending on the transmission range (in meter).

46


Figure 31: Power consumption of LEACH [56] and SOTP [33]

6.3.1.4 NeuRFonTM Netform: A Self‐Organizing Wireless Sensor Network [22]

L. Hester et al. provide algorithms for construction of the optimal backbone architecture and for information exchange of sensor nodes. Consequently, the routing follows in this hierarchical way. This NeuRFonTM network consists of a spanning tree, where the root is a node with more resources than other nodes. The root decides about the maximum number of children (Cm) for each node, the maximum depth (Lm) of the tree and the frequencies for communication between nodes. Additionally, one timeout for starting recovery and one for receiving new beacons have to be determined. After configuration, each node continually sends beacons containing Cm and Lm of its parent node. Receiving a beacon each node performs profile update and possibly recovery. As profile update, the current node adds the beacon sender to its neighbour list and compares the minimum depth of it with which one from sender, whereby the minimum depth is the depth of parent plus 1. The root has depth zero. If the calculated depth is greater than the receiving one, this node will request to the sender to become its parent. This algorithm ends if a positive response is transmitted or these two values are equal. Otherwise or if timeout comes, the recovery has to be started. This time, if the calculated depth is still greater and there is a timeout, the node sets its depth to infinity, parent=nil and become disconnected. After the algorithm finishes, the routing starts by the root and goes over the parent to the children nodes. Recovery is invoked if a node or a link fails. The dependability and performance of this approach depend on the configuration of the above‐mentioned factors. Therefore, NeuRFonTM can automatically ensure a better protection against node and link failures by shorter timeouts. Performance and energy saving improve if we take a smaller Lm, but this value is selected in dependence with Cm.

47


6.3.1.5 Self‐organizing and Self‐stabilizing Role Assignment in Sensor/Actuator Networks [50]

Weis et al. developed a new mechanism for role assignment. They provide an integrated stack of algorithms, which consists in an autonomous, lightweight middleware to help the role‐based application development. The stack contains a spanning tree, a publish/subscribe infrastructure and a role assignment algorithm. The lowest layer of the algorithm stack is specified as Spanning Tree to build an efficient topology of the network. With that hierarchy, several messages or data can be disseminated. Thereby, this algorithm only uses a timer and the simple radio interface that provides activities such as periodically broadcasting or receiving messages or timeout. It selects the node with the highest ID as tree’s root, but if one node receives TreeMessage with higher ID and shorter distance to the root, it marks them as parents. In addition, TreeMessage also acts as heartbeats to preserve against failed nodes. The Publish/Subscribe algorithm uses the topology from Spanning Tree to distribute data to all nodes. Before dissemination, nodes which are interested in a role subscribe (subscribe(type)). They send the according message type and their routing table to their parents because they do not know about the others, towards the root. Now, the root node can send these messages (publish(type, message)) to the subscribers on the reverse path of subscription, instead of flooding all messages. Figure 32 shows how simple this algorithm works. For example, node 7 just forwards the subscription of node 3 and 1, and node 4 is interested in C. The root node receives the subscriptions and sends messages A, B and C to the corresponding nodes via its children nodes.

Figure 32: Example for the Publish/Subscribe

Algorithm There is another kind of publishing for the role activation such as the publishSingle() method. Here, the message goes directly to the subscriber. Furthermore, each routing entry has a timestamp for subscription expiration. On the top of the stack the role activation algorithm assigns roles using the routing structure of the publish/subscribe layer. It has following phases. First, it determines the capabilities of several nodes to evaluate the condition for all roles. Then, if one node is able to take a role, it periodically subscribes to the message of type possible. Only, because of consistency after all roles have been already subscribed, the root node can assign the roles individually by publishing the according message. In addition, if one role is assigned to different nodes, this role will be deactivated. Otherwise, the receivers can now activate this role and subscribe to the message of type active. Now the root can start publishing again, but with messages of type active to ensure that each role is assigned to one node.

48


6.3.2 Network

6.3.2.1 Self‐Organized Data‐Gathering Scheme for Multi‐Sink Sensor Networks Inspired by Swarm Intelligence [29]

Gathering data, Y. Kiri et al. deploy a robust and self‐organized multi‐sink routing by using Ant Colony Optimization (ACO) and ant‐based clustering. ACO is based on the pheromone level of the nodes. The sinks are determined depending on cluster pheromones. This paper verifies its dependability through a complex simulation. Finding a route between the sink and sensor nodes, this approach starts with the sinks. Small control packets called “backward ants” are forwarded to the nearest nodes. Thereby, they estimate the quality of the trail depending on e.g. hop count, delay, residual power. After that, they go to the next nearest nodes and so on (flooding). Figure 33 shows for example the pheromone value Pbni(Sa) stored at ni, which is depending on the value of its predecessor (the sink has the maximal value), some reconfigurable parameters and residual power. The pheromone value becomes smaller when the ant removes from the sink away. Each node has its own table to store further information such as the Sink, Next‐hop (one hop farther to the sink than itself) and Expiry time. This table will be updated more

frequently between each pair of nodes.

Figure 33: Updating pheromone table on receiving

backward ants [29] The ant‐based clustering works as followed. Grouping some nodes to assign them to a sink due to the efficiency, the cluster pheromone describes in which cluster one node is. Each node stores the received cluster pheromone in its neighbour table. Then, this node calculates the probability of belonging to this cluster. One parameter of this function defines the probability of changing cluster membership. Its cluster pheromone changes according to this probability. It now decides whether it forwards its cluster pheromone to its neighbour and so on. The procedure is like ants which pick up larvae if they detect similarities (here: the belonging to a cluster instead of similarities). This data gathering scheme has self‐recovery from node failure. If a node fails, the Expiry time in the table of its neighbours will be exceeded. Consequently, these neighbours determine the pheromone value without regard of its value. Therefore, the Expiry time should be updated by each received ant. Even if a sink fails, the nodes near this sink reduce their pheromone, thus is clear for the neighbours. Since a cluster change is complex, the Expiry time for sinks should be larger than for other nodes. However, it is not suitable for dynamic environment.

49


The complex simulation of this paper verifies a loss of just about 10% of the data gathering quality after random node failure. If sink fail, cluster changes will take just some seconds to reach the original quality.

6.3.3 Software

6.3.3.1 Run‐Time Dynamic Linking for Reprogramming Wireless Sensor Networks [16]

A. Dunkels et al. propose the runtime dynamic linking model for reprogramming in an efficient way. The linker and loader in the standard object file format are used to perform code update of modules instead of the whole system. Contiki [41] is one sample dynamic operating systems. In contrast to for instance TinyOS [39], it contains loadable modules. The whole system consists of a smaller system core than monolithic systems and several modules which can be exchanged. Some loadable modules such as system core functions are pre‐linked. They include absolute physical addresses to functions and variables in the system code. At runtime, these addresses can be updated (relocation). The benefit of pre‐linking is that the needed memory and thus energy consumption for communication are small. However, is has a disadvantage that this code is not easy to adapt to other systems because of the fixed addresses. Other programs (applications) in dynamic operating systems are dynamically linked. They are invoked by symbolic names. The system stores modules in Executable and Linkable Format (ELF) which is standard format for different (traditional and resource‐constraint) operating systems. This format supports debugging and other important utilities. Improving the memory overhead in case the updating system has 16 or less bit architecture, Compact ELF (CELF) reduces the code size to half. The conversion is provided by Contiki. After the linking and relocation are finished, the new code takes the memory place of the old one. Now the updated program can be started.

6.3.3.2 Design and Implementation of a Framework for Efficient and Programmable Sensor Networks [15]

This work proposes a framework ‐ called SensorWare ‐ for reprogramming. SensorWare allows transferring mobile control scripts (short: scripts) from one node to others. These scripts contain computation, communication, monitoring capabilities, etc., but also instructions that define the task for nodes through software developers. This active sensor framework deploys a script interpreter at each node. Then, a set of nodes is populated with this platform‐independent script, because the script can duplicate itself or migrate its code and data. In other word, the script represents a query including a state diagram that decides what the node should perform next. Thereby, software developers define scripts in a certain language and SensorWare use the functions of the operating system to create a runtime environment for these scripts. The scripting language specifies script commands that build blocks consisting of different tasks for the node. Sample commands can be that the node should communicate with other certain nodes or they should aggregate sensing data. Furthermore, the language contains constructs for binding these blocks. After scripts are defined, they are controlled

50


by external events. Events can be reception of a network message, buffering sensing data etc. The Figure 34 shows the general programming model which support software development or task assignment. It starts with an initialization. Then, for instance the script waits for event a or b. Each event requires one event handler. After an event handler is performed, the code, which implements this event handler, is invoked. The process continues with waiting for other events or terminates.

Figure 34: The programming model [15] In the runtime environment, there are tasks such as fixed and platform specific tasks, Script Manager and Admission Control & Policing of Resource Usage. Fixed tasks like Radio/Networking (for measuring the radio utilization and excepting all network messages) and Timer service (accepts requests for timers) are always available in the SensorWare implementation. For instance, Sensor 1, Sensor 2 and Paging radio etc. represent platform specific tasks which are not compatible to all components in other platforms. Sensor 1 and 2 are sensor abstractions, which manages sensing devices. The Script Manager can duplicate scripts, but before that, it requests the Admission Control task for permission. Additionally, it keeps the current state until the state is not active anymore. Being available for a repeat, it also stores the script in a cache. The Admission Control & Policing of Resource Usage manages the energy consumption of such scripts. Exceeding a threshold would cause warnings. If nodes have different modules like sensing devices but they should exchange codes, SensorWare will create virtual devices. Due to the problem of HW/SW variability (the same modules but different OS and/or hardware), SensorWare solves the problem at first with a separation of never changed and changed code. Never changed code includes platform independent tasks. Other code is ported by protecting it with abstracted wrapper functions that allow developer easier to change. Figure 35 proposes the according code structure.

Figure 35: SensorWare code structure [15]

The evaluation of SensorWare verifies that this framework can be used efficiently for reprogramming. The total size amounts 179Kbytes. Nearly all commands cause an

51


execution time of 0.3msec (delay is 0.25msec). Finally, it is confirmed that SensorWare has 8% speed loss. These are acceptable values, except if we have computation‐intensive algorithms.

6.3.3.3 Management and Configuration Issues for Sensor Networks [45], FlexCUP: a Flexible and Efficient Code Update Mechanism for Sensor Networks [46]

In [45] the authors present TinyCubus, a project at the University of Stuttgart implemented on top of TinyOS [39]. However, it can be used as a generic reconfigurable framework. TinyCubus consists of three parts (see Figure 36): First, the Tiny Data Management Framework selects the suitable implementation through Optimization Parameters, Application Requirements and System Parameters, representing in a cube. Second, the Tiny Cross Layer Framework offers an interface to component’s data (parameters) from different network layers, storing in the State Repository for all layers. Third, the Tiny Configuration Engine distributes and installs code in the network. In addition, its Topology Manager supplies the assignment of roles.

Figure 36: The architecture of TinyCubus [45] A software update, available in the Tiny Data Management Framework is performed in four steps: first role assignment, second Code Distribution, third Code Update and finally again Code Distribution. Roles are set to find an optimal route and to define nodes which really need a software update. Afterwards, the Code Distribution efficiently disseminates the roles, first via gateways and then via their k‐hop neighbours. Now, the Code Update mechanism (FlexCUP) can start to manage the data dissemination and new code packets will be sent to involved nodes. In FlexCUP [46] – the Code Update mechanism of TinyCubus – the single object consisting from application and system software will be divided into particular packets and after that only changed parts will be exchanged. Afterwards, the (nesC) compiler can compile the files separately. Now, particular packets can be linked on a node or exchanged with other nodes. Thus, the first variant FlexCUP Basic just transmits one object file for each changed packet. Reducing more energy cost, the FlexCUP Diff contains an edit script and therefore only the differences between new and existing packets will be

52


transmitted. Both variants generate at the beginning meta‐data to describe components to compile. This energy‐aware process runs at the less limited base station. Then, the runtime linking follows, whereby among others, the relocation table will be transmitted and the installation can be integrated into the running application. In both variants, an update might cause a change of packet size, thus requiring a new memory address. Furthermore, a transmission of metadata is needed. Metadata are used to link the new code to the correct program location and to bind new addresses to the data object. They are composed of generic program information about offsets, a symbol table (mapping of parts in variable and function declaration) and a relocation table with references from component code to symbols. Consequently, the Generation of Component and Metadata is performed as followed. FlexCUP generates a binary component at the compile time that contains a usual combination of element. An example for that is the functional combination of radio communication, the sensor access and the application elements. Furthermore, FlexCUP generates metadata, especially while code is updating. See also the structure of the external flash in Figure 37. In addition, FlexCUP provides optimizations of the metadata size such as minimizing symbols to a two‐byte id and combining entries with the same id of the relocation table. It therefore can save more than 40% of space. After the updated code inclusive metadata is created, the Runtime Linking Process can start on the node (see Figure 37). There are following steps:

• Storage of Component code and Metadata in flash memory which usually has 512 Kbytes (much more than 4 Kbytes of RAM), whereby FlexCUP Basic delivers all components and metadata but FlexCUP Diff only transmits the differences between them and these ones already stored on the node

• Merge new symbol data into the existing symbol table in RAM • Replace relocation tables to have the appropriate location • Update references by checking whether the destination address of new component

code or symbols has changed • Install the updated program code into program memory and reboot the node using

the bootloader

Figure 37: Runtime linking process [46 (added texts are yellow)]

53


6.3.3.4 Efficient Code Distribution in Wireless Sensor Networks [47]

The approach of Reijers et al. provides a simple code distribution for software update. It assumes that an update consists of small changes and therefore uses an edit script to build new code images. Instead of propagation of the whole changed packets, the string differences will be transmitted. The distribution has four steps: Initialisation with a notification that a software update begins: The available memory is divided into two halves. The top halve with application code should be removed whereby critical code (for example system programs) on the bottom halve still runs.

• Code image building: Now, the bottom halve can be updated. After that the application code will be generated by the new critical one. Thereby, like the UNIX diff function, equal strings are copied into the external EEPROM memory and then not equal ones follow. Furthermore, the address of each function or data has to be shifted.

• Verification: A procedure checks the complete memory on each node whether the software update is performed entirely correct. Failed transmissions can be requested again.

• Loading: All nodes can reboot its application.

6.3.3.5 Dynamic Reconfigurable Sensor Network Architecture with OSGi Framework [17]

Since there are more and more multiple sensor applications, H. Song et al. provide a dynamic reconfigurable architecture especially for smart home environment. Their architecture uses the OSGi framework [58] and thus enables multi‐purpose programming. They extend the framework with two features such as Sensor Network Driver and Rule‐based Sensor Network Programming to support heterogeneous sensor networks. Figure 38 presents the architecture containing three components. Due to the dynamic programming, the component Heterogeneous Sensor Networks allows to add new sensor packets. Then, the OSGi downloads new driver module from the Sensor Vendor Server. As user interface, OSGi can be controlled by the end user via end point devices such as PDA or smart phone. Furthermore, UPnP is utilized to manage the network directly.

Figure 38: OSGi‐based dynamic sensor network architecture [17]

54


Figure 39 shows the structure of Sensor Network Application Rule (SAR). At the beginning, the Sensor Manager sends sensor and actuator lists to the user. According to this information, the user defines SAR via UPnP to specify the next application of the sensor network. Thereby, he sends XML code containing a list of events to the Rule Processor. An event typically consists of ID, sensor type, location, and state. Furthermore, events are matched with several operations defining the desired action of the nodes. Next, the SAR will be stored in the SAR Repository and suitable nodes will be selected depending on the current values from the Sensor Information Repository. Now, the Sensor Network Driver subscribes the event to the selected nodes. Only when changes happen, the Sensor Network returns the result of the event in an event notification message. The SAR Processor evaluates the result and performs according operations.

Figure 39: SAR processing structure [17]

6.3.4 Middleware

6.3.4.1 A Reconfigurable Group Management Middleware Service for Wireless Sensor Networks [6]

In this paper, M. S. Vieira et al. present a reconfigurable group management middleware service which can be dynamically adapted to the environmental changes and according to system conditions. They focus on the design but also show the implementation, especially for object tracking as example. The design of the reconfigurable group management (RGM) is showed in Figure 40. The first element in RGM ‐called Repository ‐ contains components for the reconfiguration process. The other main element is Configurator which performs the reconfiguration process.

Figure 40: Overview of the Group Management Service [6]

55


The UML diagram in Figure 41 explains how group management developers can easily adapt the interfaces. They should implement the operations of the interface IConfigurableGM according to the rules in one Group Management component (here A or B). The operation init (finalize) is responsible for starting (releasing) the component. Other operations in IConfigurableGM are trivial. In GMConfigurator operations such as reconfigure and configure differ in functionality and time. At first, the RGM middleware service performs the GMConfigurator and GMRepository. Now, applications can use them to receive all services including the interface IConfigurableGM. Next phase is reconfiguration. The application selects an appropriate service by releasing the current one and by starting the operations in the IConfigurableGM. Afterwards, the application receives these

configurations from the IConfigurableGM. With that, the application can adapt the behaviour of one Group Management component. It configures a certain option of the options returning from the Group Management component. Finally, the GMConfigurator terminates the GMRepository and the new IConfigurableGM. Note that the application always manages the process via GMConfigurator.

Figure 41: Steps of the configuration [6]

As example for utilizing the RGM middleware service, the authors implement an Object Tracking Application (OTA). Therefore, objects can be detected (using sensors) and followed. Figure 42 points the architecture of an OTA. The node application provides object detection by evaluating sensor measurements. The node sends the object‐detected event including the distance between itself and the object to middleware services. Now, the Object Tracking service is used to provide tracking. It communicates with the Group Management Reconfigurator. Thus, group of nodes for tracking is controlled by a selected Group Management service. The Publish‐Subscribe model has the benefit that the communication to certain nodes, which can determine and offer the location of the detected object, has simplified. In this example, there are different Group Management services. One of these is the role output in a group. Here, the leader should know information about the members in its group. The second service is responsible for partial leader election. The last service is for leader election with minimal cost.

56


Figure 42: Architecture of an OTA [6]

6.4 Security

6.4.2 Network

6.4.2.1 SIGF: A Family of Configurable, Secure Routing Protocols for Wireless Sensor Networks [12]

Especially for severe applications, A. D. Wood et al. provide a configurable collection of secure routing protocols. This paper describes the Secure Implicit Geographic Forwarding (SIGF) containing three protocols that are adapted to the desired security level having different resource consumption, but less than static protocols. In the WSN, the security level is changed frequently in case of detected attacks. Thus, the network does not have to provide protection mechanisms at all time. With that, it limits the number of states (network and node properties) to be stored. SIGF is an improvement of the Implicit Geographic Forwarding (IGF) [59] that works without storing any state. There is no routing table, but the next forwarding node is selected by using RTS/CTS handshake of 802.11 DCF MAC protocols. If the channel is free, the sender sends a Request (RTS). The node which the shortest response time (depending on the range) returns an acknowledge (CTS). The data will be transmitted to this node and the others have to wait. This protocol is better than other ones in performance and dependability. However, it does not protect against some attacks. As example, the attacker also sends CTS and can receive data (black hole). This data is lost, because he will never forward. Other attacks such as Sybil or denial of service are also not defendable. The network administrator has the choice of the variant of SIGF or it is automatically set according to the required security level. SIGF‐0 is used in the secure environment like IGF but offers probabilistic defences. The four following dimensions are configurable. First, the Forwarding Area can be enlarged, not only up to the 60° sextant, but up to the CLOSER area or even the whole neighbourhood. The smaller the area is, the more probable an attacker can be there. Second, the Collection Window defines the number of CTS responders at the same time. It can take one responder, but also multiple. Furthermore, it can dynamically change. The attacker does not care about this response

57


delay and sends CTS first. Third, the Forwarding Candidate Choice has elements as followed. It can be the first like in IGF or it can be fixed by priority reaching the highest performance. The random selection is a tradeoff between performance and protection (here especially against unpredictable attacks). The last choice allows multiple paths causing the highest cost. As the result, SIGF‐0 extends IGF to defend against Black Hole attack. Extending SIGF‐0, SIGF‐1 uses some information about the current node and its neighbours to ensure that Sybil attacks (create new identities and overhear messages) will be made difficult. Following values will be calculated and stored. Forwarding success ratio Nsuccess = Nforward / Nsent whereby Nforward is the number of forwarded messages of the neighbour and Nsent is the number of sent messages to this neighbour. Forwarding fairness ratio Nfairness = (T- Nsent) / T whereby T is the number of messages sent to all neighbours. Nconsistency is the consistency score which decreases in case of location change. Forwarding performance Nperformance = (D – Ndelay) / D whereby D is the maximum delay. Consequently, the Reputaion value is computed as a weighted linear combination of the above calculated values. The network administrator decides for the weights and for a Reputation threshold that influences the ranking of the forwarding candidates defined by each node. However, if Reputation values of all neighbours are lower than the threshold, the node with the highest reputation should be the next forwarder. Protecting against Denial Of Services attack, in SIGF‐2 state information are even shared among neighbours but with encryption. Reconfigurable parameters are Message Authentication, Message Sequencing and Payload Encryption. First, all (control and data) transmissions or only data or nothing will be protected with authentication. This protocol assumes that encryption keys are transmitted in a secure way using other approaches. In case of only data, the attacker can still replay transmitted messages, but he is not able to change the data. Then, a sequence number should be increased to ensure the freshness of the message. However, it requires an authentication. Finally, the administrator can allow Payload Encryption due to the privacy. SIGF‐2 also uses mechanisms of SIGF‐0 and SIGF‐1. The very complex evaluation of this paper shows different packet delivery ratio of these three protocols. Naturally, all protocols reach high ratio (about 90% under light traffic load and otherwise over 70%). In case of black hole attack, SIGF‐0/1 with random candidate selection achieves about 40/75%. SIGF‐0 with priority does not always ensure a protection. Other protocols are perfect. Under Sybil attack, SIGF‐0 and SIGF‐1 with random candidate selection have about 30%. SIGF‐1 attains about 80% and SIGF‐2 even 95%. SIGF‐2 is the only protocol that defends against Denial of Services attack with about 95% ratio.

58


7. Discussion and Future Works In this chapter, existing approaches for reconfiguration in WSNs are evaluated. Then, own ideas to improve them are described more in detail.

7.1 Discussion We can compare approaches for each reconfiguration in all main classes. Thereby, we conclude whether the defined objectives are met. Therefore, we consider the fulfilled functions, performance, dependability and security.

7.1.1 Node properties Reconfiguration options for node properties such as topology, coverage and role are very important in WSN. Their reconfigurations allow adapting the network structure according to the data transport and event‐based applications. With data transport, we can disseminate sensing, communication and network control data from child nodes via parent nodes to the root (equal with the sink). Event‐based applications include all applications where the system is reconfigured if a change at any node happens. The discussion points are tree‐based or cluster‐based topology. Furthermore, which approaches are appropriate for coverage and which for role assignment. We should check whether the topology is stabile if any failures happen. Especially for security, the localization algorithms should evaluate whether they are secure.

7.1.1.1 Functionality

A lot of approaches such as [34]{6.1.1.1}, [22]{6.3.1.4}, etc. focus on the same data transport application. They only differentiate in performance. The approaches [21]{6.2.1.1} and [35]{6.3.1.1} provide high coverage to preserve energy for dissemination. It is not clear, which kind of topology is better than the other, because the parent node acts like the cluster‐head. However, normally the tree‐based topology is only more appropriate in data transport applications where the base station is fixed as the sink. It depends on the selection scheme for the parent nodes or cluster‐heads. If the result tree of [22]{6.3.1.4} is not balanced, the depth does not really determine the efficiency. [33]{6.3.1.3} and [1]{6.1.1.2} achieve nearly the same performance, whereby the first approach is tree‐based and the second is cluster‐based. Combining these two topologies, [10]{6.1.1.3} improves the performance. With the effort of coverage, where only as less nodes as possible are active, the data transport becomes more efficient and thus reserve energy. [43]{6.3.1.2} bases on the number of active nodes and high packet loss at the sink. Especially [35]{6.3.1.1} ensure 100% coverage by using a cost function for candidates for replacement. Supporting the formation, role assignment is used by setting the roles. In comparison between two role assignment approaches, [50]{6.3.1.5} outperforms [51][52][53]{6.2.1.2} by assigning roles only to certain nodes, which are predefined by the publish/subscribe model.

59


7.1.1.2 Dependability

[21]{6.2.1.1} only achieves dependability by self‐configuring the hexagonal clusters. It repairs the topology in case of link/node failure, congestion and removing/adding nodes. Deciding about starting recovery, it and the others such as [22]{6.3.1.4} and [35]{6.3.1.1} use the control of timers for answer by cluster‐heads or by the root. [43]{6.3.1.2} refers to the number of active nodes and high packet loss at the sink to. The approaches [51][52][53]{6.2.1.2} and [50]{6.3.1.5} for role assignment awards changing the role of nodes by considering their properties. With that, each node can be reconfigured for different tasks according to the environment and application. The current limitation of the nodes is regarded.

7.1.1.3 Security

The described approaches for node properties reconfiguration ensure secure localization by limiting the range and distance of the transmission of location information. Communication groups are set dynamically so that a successful attack would have to be restarted.

7.1.2 Network With node properties reconfiguration we maintain a topology for routing. In network reconfiguration, we consider the routing and communication protocols, localization frequency and compare the approaches with regard to functionality and dependability. Achieving security, aspects like forwarding area, sliding window, defence, state information, encryption and session length.


The researched approaches can provide functions supporting data transport and target tracking. [13]{6.1.2.1} bases on the range of each node. If the target is on the range, the robot will follow it. The simulation shows a result that 90% of the targets are found. [28]{6.1.2.2} supports this function by controlling the localization frequency. For data transport, [31]{6.1.2.3} and [12]{6.4.2.1} reconfigure the routing protocols. [17]{6.3.3.5} is used especially for home environment. [29]{6.3.2.1} provides multiple routes, thus ensures more performance. [28]{6.1.2.2} is used for target tracking and focus on an energy‐accuracy tradeoff. Its analysis verifies that it is better than static localization (always the same frequency).


The maintenance can be hold by [17]{6.3.3.5} with respect to its flexible architecture. The adaptive localization of [28]{6.1.2.2} is useful in case nodes fail. [29]{6.3.2.1} is very robust, because it provides multiple routes, but it causes memory and management overhead. Furthermore, it protects the routing against failures by using update‐to‐date expiry time. Publish‐subscribe model is used to build direct communication between the base station and certain nodes.

60


7.1.2.3 Security

The network reconfiguration is very important to meet security. SIGF [12]{6.4.2.1} is the approach of all researched papers, which provides three levels (three routing protocols) according to the current attack situation. In spite, its performance is almost better than flooding. Furthermore, it provides many reconfiguration possibilities. The forwarding area and sliding window can be limited and state information is more used in case of intrusion. Existing approaches present different encryption algorithms. The hybrid encryption is most secure but causes more computation complexity. Asymmetric encryption is improved by e.g. [9] which is a trade‐off between security and performance.

7.1.3 Software In software reconfiguration, the user can be the network administrator but also the software developer. He should have knowledge about the current running software and the resource constraint of the deployed nodes. However, how often he checks for update can be a problem. The researched approaches in this thesis do barely describe about this decision, but the scenarios are given in {4.3}. Achieving the reconfiguration objectives, the software update can influence the importance of WSN very strongly.


All researched approaches achieve a consistent update, so all affected nodes install the new version. Verifying the correctness of the application after an update, the approaches do not perform explicit checking process. However, it may be a further task for the user to use reliable code distribution and data gathering. Protocols for code distribution are very similar to data dissemination, because the update content is regarded as data. Report about the current version as collected data from the nodes may confirm that the applications return correct values. Software reconfiguration problems can really be regarded just in the execution environment. However, the code installation on nodes run correctly, in spite of the memory relocation and changing references (especially in FlexCUP [46]{6.3.3.3}). Supporting these hardware accesses, a virtual machine like Maté [38] is very useful. The vital assumption is that the user should know about the software structure to exchange parts. Since (even very many) nodes are deployed for one area, their structure are the same. At the needed time, they should be changed, but all together. The solution for not unique modularity addresses to Full Image Replacement (e.g. Deluge [49]{6.2.3.1}). It is good the worst case, which cause performance loss. Deluge is deployed in monolithic operating systems with only one software image like TinyOS [39] support the Full Image Replacement. If there are more changes and therefore the particular updates needs more energy for transmission, the user should exchange the whole image. However, the changes (i.e. bugs, new functions, etc.) normally are small, so such update causes the most networks overhead. In modular systems such as Dynamic Linking provided by Contiki [16]{6.3.3.1}, only affected modules are updated. The evaluation in [16]{6.3.3.1} shows the energy consumption of different approaches for software update. Deluge causes 20 times

61


consumption to the Dynamic Linking. The Dynamic Linking provided by Contiki [41] and SOS [42] is better than by MagnetOS if the platforms are extreme resource‐constraint. Virtual machines like Maté [38] enable the creation of scripts loadable at any time, thus has small overhead. The problem is to find the proper level of abstraction for instructions, because too specific means being not adaptive to all hardware and too general increases script size. Comparing Dynamic Linking and virtual machines, we can claim that virtual machine code is more expensive, but the update process is more energy‐aware. It depends on the amount of fixed code and of updating code. Additionally, Dynamic Linking is compatible to a combination of native and virtual machine code. SensorWare [15]{6.3.3.2} is a framework which has nearly the same ideas like Virtual Machines, but it addresses to larger platforms. In contrast to Dynamic Linking and SensorWare, other approaches support monolithic operating systems, because they do not support loadable modules and all virtual machines. However, FlexCUP Basic [46]{6.3.3.3} needs energy‐intensive mechanisms for generating metadata. In the future, it wants to provide more complex algorithm for the management of flash memory and reserved RAM. Diff‐based approaches like FlexCUP Diff [46]{6.3.3.3} and Reijers [47]{6.3.3.4} require diff scripts. Furthermore, diff‐based approaches do not support heterogeneity. It means that the server has to know more about the software configuration of the nodes than all other approaches.


There is a need of a reliable multihop transmission for the new code. TinyCubus [46]{6.3.3.3} and Deluge [49]{6.2.3.1} are appropriate for that. They ensure algorithm termination, correctness and consistency. However, this is not the topic of this thesis. This thesis concentrates on the dependability of the software reconfiguration. The more parts of the (system) software are to be updated, the longer reboot. The monolithic systems cause the longest reboot of the nodes. In this time, the nodes are unavailable. The Dynamic Linking [16]{6.3.3.1} uses a standard object format, thus is more portable than the others. However, it requires memory allocation is resolved at runtime. In contrast, virtual machines provide code safety, because applications do not communicate with the hardware directly. A combination of diff‐based approaches and virtual machine is also useful to solve the compatibility problems. Especially, the support of middleware reconfiguration can ease the heterogeneity and software reconfiguration.

7.1.3.3 Security

The objective security has been not regarded by the researched approaches. It is obviously that code distribution (or data dissemination) could arrive to unauthorized parties. However, the code is not data that we have to protect due to privacy. What we should do is to protect it against integrity. If attackers change the code and continue distributing, no objectives will be achieved. They can change the function, the algorithm effectiveness (Denial of Services) and dependability and security mechanisms to hijack the whole WSN. However, it is regarded as similar to data protection.

62


7.1.4 Middleware There are not so many papers, which investigate on the reconfiguration for middleware as for the other objectives. The abstraction and heterogeneity can be improved by the middleware. Furthermore, group management, node replacement, key establishment are provided.


The researched approaches do not focus on the objective functionality, because they support flexible deployment of components (e.g. by [4][5]{6.2.4.1}. They ensure the right specification for generic applications. Only the Group Management [6]{6.3.4.1} provides an implementation for a specific application (object tracking) and thus enhance performance.


Nowadays, middleware reconfiguration focuses on the dependability. Providing abstraction (by all researched approaches), the components of applications are protected. There is less independence between them, thus can be easily exchanged. Therefore, components are deployable for all systems. Furthermore, the approaches (e.g. [8]{6.2.4.2}) attend possible link or transmission failures.

7.1.4.3 Security

There are some middleware services to achieve security such as key management. Thus allows secure communication between two or more nodes. LEAP [20] is a complex approach for key establishment. However, the security depends more on the encryption.

7.1.5 Hardware Hardware reconfiguration deals with selection of sensor, memory or processor and hardware abstraction. This thesis does not focus on it but gives some references to the approaches.


Hardware reconfiguration are application‐independent, thus supports any application. The most reconfigurations require additional hardware capabilities and thus human intervention. Due to the resource limitation, they are not often used.


In the design the implementation of hardware modules are obviously hidden, thus enables changes. Therefore, the modules can be deployed in each system.

7.1.5.3 Security

The abstraction and heterogeneity of hardware modules are also important for security. However, this goal and solution are described in Dependability.

63


7.2 Future Works After the discussion in {7.1}, we can conclude that existing approaches for reconfiguration in WSNs mostly meet the mentioned goals arriving from the scenarios. However, some parts of reconfiguration can be improved, because multi‐purpose applications become more important. We expect that the nodes are deployed not only to monitor one area or measure different objects at the same time. The reason is that many of them are necessary but their participation (due to their costs) should be reserved. Even in buildings, we cannot have place for so many nodes and furthermore the more nodes are used the more organization we need. Current projects and papers intent to improve their algorithms running in certain reconfigurations. Performance and dependability of WSNs will be thus enhanced. As examples, they try to increase the data compression rate. With that, each transmission will be more energy‐aware. Furthermore, they aim to develop better routing protocols by using probabilistic decisions. Conditions for that are a more precise analysis and a more complex simulation. The first own idea for the future works is that the user which performs a reconfiguration does not need to be humans. In more and more cases, robots or base stations can take over this task. Network administrator and software developer initiate the networks with a pre‐configuration. Furthermore, they define rules for reconfiguration start. Robots or base stations follow these rules and reconfigure the network as the specification stored in their less resource‐constraint systems. Different topologies, routing protocols and other protocols are specified, they only have to select the appropriate one. Clearly, the software update should be invoked by human user. Other own ideas are reported for the class Functionality together with Dependability and Security. Then, they are divided into capabilities.

7.2.1 Functionality&Dependability Functionality and dependability should be now regarded together. Reconfigurations fulfil functional requirements with expected performance. Additionally, they are performed in any case of changes in the network such as failures, topology change, node participation change, etc.

7.2.1.1 Node properties

Existing approaches provide simple clustering and routing trees. More efficient and robust is the use of multiple minimal spanning trees. A sample application is data transport in mixed area where one part is inside a building (more reliable environment) and the other one is the natural environment (less reliable). The improvement factor may be x‐times of simple tree, because each packet of a data volume (for routing, communication, etc.) is copied and transmitted over x nodes. Reconfigurations of node properties are determination of the role AGGREGATOR and REPRESENTATIVE and generation of trees for each packet. The role AGGREGATOR describes the nearest node which receives the original transferred packet. It is normally the parent node of the senders. Nodes with the role REPRESENTATIVE can be switched off until they are demanded for participating. The order from small to large distance between the current

64


node and their neighbours should be kept and enumerated. The current nod stores this list. The nodes with the role REPRESENTATIVE can increase the speed by transferring data via him. Furthermore, the dependability is better achieved, because failed connections or nodes can be replaced by him. Similar to multiple routing trees, we can use octagonal clusters or clusters with more nodes with the role SLAVE. Therefore, one cluster‐head can manage the routing for more nodes (within its cluster) than hexagonal clustering. It depends on the density of the network. In some networks such as for fire detection application where many nodes are deployed in one small are but functionally dependent, much more nodes can be grouped to manage them together. Semi‐structured topology (e.g. cluster and tree‐based) could be a good way to keep the advantages of each format. It is used especially for flexible communication. For example in case that internal communication between the nodes (clustering benefits) does not fulfil the requirements of reconfiguration, the user should have information about the current network state (tree of cluster‐heads benefits) and thus intervene. However, it causes more communication and memory overhead than multiple use of one format. Each node receives more than one role and has to store the code specifying such roles. Other topologies like circles could expand the connectivity of the nodes of different areas. The role GATEWAY is assigned to more than one node. Since in the nature, there are covers of ranges, the nodes in different ranges can communicate with different areas. Using more gateways, the bridges cannot be cut off. The node gateway should be replaced periodically, because it consumes more energy for communication and forward.

7.2.1.2 Network

Using multiple routing trees, network reconfigurations describe the management of the number of copies, redundancy detection and selecting an appropriate routing protocol for one area (sub‐network). Using multiple clustering, the network reconfiguration works analogy. The data transport normally comes from sensing nodes via some other nodes to the sinks as base station. It may also be network control data generating by the base station for the nodes. However, the flexible communication between two arbitrary nodes in the network is supported especially by clustering. After sensing data, they initialize copying and transferring the packet. In their neighbourhood, they send the first packet to the nearest neighbours. A timeout decides whether further nodes should receive a copy. The node with the role AGGREGATOR (the nearest neighbour) performs the same procedure. Then, it should send a possible acknowledgment back to their child node. Otherwise, after another timeout, the next representative node with the role REPRESENTATIVE stored in the list of the child node takes over this task. Consequently, Dijkstra algorithm is performed each time and thus ensures always shortest paths. The routing works as depth‐first search (DFS). The best case for highest performance is that only each the nearest neighbour is participating in the dissemination. The worst case is similar to flooding mechanism. However, the user can select smaller number of copies for robust area. The decision may be probabilistic. The trust values describe how large the average number of copies in the groups of sub‐trees was in the last dissemination. Considering this fact and the current network state (with regard to transmission rate and congestion), the user can decide about the number of copies in the next routing.

65


Depending on the particular environments, the appropriate routing protocol can be selected. For small area, distance vector based routing is better than link state based which benefits in highly dense networks. If one area monitors mobile objects, geographical protocols may support this not reliable localization and hence the determination of distance. Thus, mobile objects can be tracked easily. If the mobile objects have certain pattern, they may be categorized. For example, the behaviour of human or vehicles are sometimes predictable. They do something which we know and especially repeat it after a certain time. However, such visualization for human‐computer‐interaction paradigms requires much more resource. Robots should be deployed to sense and evaluate this data.

7.2.1.3 Software

Existing approaches for software reconfiguration provide suitable software update algorithms for flexible applications. System heterogeneity is supporting by dynamic operating systems, but is enhanced by virtual machines and frameworks. The nodes should not focus on such advantage due to their limitations. Future works can refer to better code size reduction by using more efficient unzip mechanisms or more precise diff‐scripts.

7.2.1.4 Middleware

Middleware reconfiguration ensures high abstraction and protocol support such as group management. Therefore, this thesis does not present any ideas for such reconfiguration. Clearly, all parts in reconfigurations of node properties, network or software can be implemented as middleware services.

7.2.1.5 Hardware

Hardware reconfiguration should result more alternatives of the hardware devices. However, the complex selection depends on the capabilities of the nodes. It will be researched for home applications. Furthermore, the devices become cheaper so that the resource limitation will decrease. The hardware modules should stay abstract, because they will be used in different systems in the future.

7.2.2 Security We cannot avoid physical attack, because the nodes are normally deployed in not secure environment. The adversary can attack some nodes to receive sensing data. There are approaches that hijacked nodes. They can be improved by probabilistic decisions depending on certain behaviours and timeouts. For example, attacked nodes often respond first and they try to transfer the data to nodes outside one area such as cluster or sub‐tree. Otherwise, they will drop receiving data even if they are connected with other nodes. It may conclude that they just want to avoid system and service availability. Since the nodes are deployed in wireless networks, encryption algorithms are very important for security. In the future, more algorithms basing on asymmetric or hybrid encryption will be used, because they are more secure than symmetric ones. However, their performance should be improved. The base station authentication may be extended by certificates to ensure a secure reconfiguration. Otherwise, the attacker would change the whole network.

66


8. Summary This thesis contains a survey and future works on reconfiguration in WSNs. It defines the term reconfiguration as followed. Reconfiguration is to modify the setting of the network and sensor nodes. After an initial configuration, if the environment or specification for the applications changes, the involving sensor nodes should be adapted. They are desired to perform their tasks as before. Due to the complexity of this thesis, there are many sub‐classes. Each sub‐class presents another goal (objectives) and reconfiguring object (capabilities), whereby the classification prefers the objectives. Objectives are functionality, dependability and security. Capabilities are node properties, network, software, middleware and hardware. The appropriate scenarios are described in detail to lead to those reconfiguration possibilities. For each possibility, we have one or more options, how we can reconfigure. These approaches, which refer to according papers, are described in a general way. The similarities are reported and the differences are explained in the paper summaries. Therefore, the reader can have a better overview. For details of one certain reconfiguration, he can read the description in the paper summaries. Evaluating the tools of the trade, the discussion contains opinions to their fulfilment. They are able to provide necessary reconfiguration technologies in efficient and robust manner. However, future works on data compression, routing protocols, frameworks for heterogeneity, etc. are important to enhance the efficient use of less sensor nodes for multiple purposes. Furthermore, some improvements such as by using other reconfiguration options can be taken into account. For example, multiple topology formats such as multiple trees or clusters may reduce the system failure rate due to failed node. Additionally, they may increase the dissemination rate up to nearly flooding. However, the node participation becomes higher. Therefore, hardware capabilities and the current environment should be regarded carefully. Consequently, there are more reconfiguration possibilities for the future works. The most important fact is that WSNs should be designed for re‐configurability, but they are.

67


References [1] Hang Su; Xi Zhang, “Energy‐Efficient Clustering System Model and Reconfiguration Schemes for Wireless Sensor Networks”, Information Sciences and Systems, 2006 40th Annual Conference ‼ Perf Extended analy. Model to derive optimal number of clusters to max. The netw. Lifetime and preserve energy [2] S. Capkun, J.‐P. Hubaux, “Secure positioning in wireless networks”, IEEE Journal on Selected Areas in Communications, 2006 [3] L. Lazos and R. Poovendran, “Serloc: Robust localization for wireless sensor networks”, ACM Trans. Sensor Networks, 2005 [4] ] Geoff Coulson, Richard Gold, Manish Lad, Cecilia Mascolo, Luca Mottola, Gian Pietro Picco and Stefanos Zachariadis, “Dynamic Reconfiguration in the RUNES Middleware”, 2006 [5] Paolo Costa, Geoff Coulson, Cecilia Mascolo, Luca Mottola, Gian Pietro Picco and Stefanos Zachariadis, “Reconfigurable Component‐based Middleware for Networked Embedded Systems”, 2005 [6] M. S. Vieira, N. S. Rosa, “A Reconfigurable Group Management Service for Wireless Sensor Neworks”, MPAC 05, 2005 [7] D. J. Malan, M. Welsh, and M. D. Smith, “A public‐key infrastructure for key distribution in tinyos based on elliptic curve cryptography“, In First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, 2004 [8] P. Hu, J. Indulska, R. Robinson, “Reconfigurable middleware for sensor based applications”, CM International Conference Proceeding Series; Vol. 185, Proceedings of the 3rd international Middleware doctoral symposium Melbourne, Australia, 2006 [9] N. Gura, A. Patel, A. Wander, H. Eberle, and S. Shantz, “Comparing elliptic curve cryptography and rsa on 8‐bit cpus“, In In 2004 workshop on CryptographicHardware and Embedded Systems, 2004 [10] Kai‐Wei Fan, Sha Liu, Prasun Sinha, “Storage and abstractions: Scalable data aggregation for dynamic events in sensor networks“, Proceedings of the 4th international conference on Embedded networked sensor systems SenSys ʹ06, 2006 [11] http://csrc.nist.gov/publications/fips/fips46‐3/fips46‐3.pdf [12] Anthony D. Wood, Lei Fang, John A. Stankovic, Tian He, “Secure routing: SIGF: a family of configurable, secure routing protocols for wireless sensor networks“, Proceedings of the fourth ACM workshop on Security of ad hoc and sensor networks SASN ʹ06, October 2006 [13] J. Reich, E. Skar, “Toward Automatic Reconfiguration of RobotSensor Networks for Urban Search and Rescue“, 2006 [14] http://csrc.nist.gov/publications/fips/fips197/fips‐197.pdf [15] SensorWare: “Design and Implementation of a Framework for Efficient and Programmable Sensor Neworks”, Open Architectures and Network Programming Proceedings, 2002 IEEE, 2002 [16] Adam Dunkels, Niclas Finne, Joakim Eriksson, Thiemo Voigt, “Operating systems: Run‐time dynamic linking for reprogramming wireless sensor networks“, Proceedings of the 4th international conference on Embedded networked sensor systems SenSys ʹ06, October 2006 [17] H. Song, J. Sung, J. Kim, D. Kim, “Dynamic Reconfigurable Sensor Network Architecture with OSGi Framework”, Information and Communications University Korea, 2004 [18] Q. Huang, J. Cukier, H. Kobayashi, B. Liu, and J. Zhang, “Fast authenticated key establishment protocols for self‐organizing sensor networks”, In Proceedingsof the 2nd ACM International conference on Wireless sensor networks and applications, 2003 [19] J. Deng, R. Han and S. Mishra, “Enhancing base station security in wireless sensor networks“, Tech. Rep. CU‐CS‐951‐03, Department of Computer Science, University of Colorado. April 2003 [20] S. Zhu, S. Setia and S. Jajodia, “Leap: Efficient security mechanisms for large‐scale distributed sensor networks“, In 10th ACM Conference on Computer and Communications Security (CCS ’03), 2003 [21] M. M. Iqbal, L. Gondal, L. Dooley, “LACON: localized autonomic configuration in pervasive sensor networks Intelligent Sensors, Sensor Networks and Information Processing Conference. Proceedings of the 2004, 2004 [22] L. Hester, Y. Huang, O. Andric, A. Allen, P. Chen, “NeuRon/spl trade/ netform: a self‐organizing wireless sensor network” Computer Communications and Networks, 2002. Proceedings. Eleventh International Conference

68


[23] D. Carman, B. Matt and G. Cirincione, “Energy‐efficient and low‐latency key management for sensor networks“, In 23rd Army Science Conference, 2002 [24] S. A. Camtepe and B. Yener, “Key Distribution Mechanisms for Wireless Sensor Networks: a Survey“, Technical Report, 2005 [25] J. P. Walters, Z. Liang, W. Shi and V. Chaudhary, “Wireless Sensor Network Security: A Survey“, Auerbach Publications, CRC Press, 2006 [26] K. Akkaya, M. Younis, “A survey on routing protocols for wireless sensor networks“, Ah Hoc Networks 3 (2005), 2003 [27] D. Lymberopoulos, N. B. Prijantha, F. Zhao, “mPlatform: A Reconfigurable Architecture and Efficient Data Sharing Mechanism for Modular Sensor Nodes“, IPSN’07, April 25‐27, 2007, Cambridge, Massachusetts, USA, 2007 [28] T. Sameer, K. Vinay, N.B. Abu‐Ghazaleh, K.‐D. Kang, “Dynamic localization control for mobile sensor networks”, Performance, Computing, and Communications Conference. IPCCC 2005. 24th IEEE International, 2005 [29] S. Kiri, M. Sugano, M. Murata, “Self‐Organized Data‐Gathering Scheme for Multi‐Sink Sensor Networks Inspired by Swarm Intelligence”, Self‐Adaptive and Self‐Organizing Systems, SASO ʹ07. First International Conference, 2007 [30] http://www.xilinx.com/products/silicon_solutions/fpgas/index.htm [31] A. Rogers, E. David, N.R. Jennings, “Self‐organized routing for wireless microsensor networks”, Systems, Man and Cybernetics, Part A, IEEE Transactions, 2005 [32] J. Portilla, T. Riesgo, A. Castro, “A Reconfigurable FPGA‐based Architecture for Modular Nodes in Wireless Sensor Networks”, Proc. IEEE Southern Conf. on Programmable Logic, February 2007 [33] W. Yu, I. Henning, L. Xiaoyun, D. Hunter, “SOTP: A Self‐Organized TDMA Protocol for Wireless Sensor Networks”, Electrical and Computer Engineering, Canadian Conference on, 2006 [34] N. Bicocchi, M. Mamei, F. Zambonelli, “Towards Self‐organizing Virtual Macro Sensors”, Self‐Adaptive and Self‐Organizing Systems, SASO ʹ07. First International Conference, 2007 [35] P. Joshi, T. C. Jannett, “Localized Performance‐Guided Reconfiguration for distributed sensor networks”, IEEE 2007 [36] Hongzhou Liu, Tom Roeder, Kevin Walsh, Rimon Barr, Emin Gun Sirer, “Design and Implementation of a Single System Image Operating System for Ad Hoc Networks. ”, In The International Conference on Mobile Systems, Applications, and Services (Mobisys), Seattle, Washington, June 2005 [37] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Torgerson, R. Han, ʺMANTIS OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms”, ACM/Kluwer Mobile Networks & Applications (MONET), Special Issue on Wireless Sensor Networks, vol. 10, no. 4, August 2005 [38] Levis, P., Culler, D., “Mate: a Virtual Machine for Tiny Networked Sensors”. In: Proc. of the ACM Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), October 2002 [39] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. E. Culler, K. S. J. Pister, “System architecture directions for networked sensors”, in Proc. the 9th International Conference on Architectural Support for Programming Languages and Operating Systems, 2000. [40] V. Handziski, J. Polastrey, J.‐H. Hauer, C. Sharpy, A. Wolisz, D. Cullery, “Flexible Hardware Abstraction for Wireless Sensor Networks“, In Proceedings of the 2nd European Workshop on Wireless Sensor Networks, 2005 [41] A. Dunkels, B. Grönvall, T. Voigt, “Contiki ‐ a Lightweight and Flexible Operating System for Tiny Networked Sensors”, In Proceedings of the First IEEE Workshop on Embedded Networked Sensors 2004 (IEEE EmNetS‐I), Tampa, Florida, USA, November 2004 [42] C.‐C. Han, R. K. Rengaswamy, R. Shea, E. Kohler, M. Srivastava, ”SOS: A dynamic operating system for sensor networks”, Proceedings of the Third International Conference on Mobile Systems, Applications, And Services (Mobisys), 2005. [43] Cerpa, A.; Estrin, D.; “ASCENT: adaptive self‐configuring sensor networks topologies” Mobile Computing, IEEE Transactions 2004 [44] H. Rowaihy, S. Eswaran, M. Johnson, D. Verma, A. Bar‐Noy, T. Brown, “A Survey of Sensor selection schemes in wireless sensor networks”,2006

69


[45] Pedro José Marrón, Andreas Lachenmann, Daniel Minder, Matthias Gauger, Olga Saukh, Kurt Rothermel “Management and configuration issues for sensor networks“, International Journal of Network Management, Volume 15 Issue 4, July 2005 [46] Pedro José Marrón, Matthias Gauger, Andreas Lachenmann, Daniel Minder, Olga Saukh, Kurt Rothermel, “FlexCup: A Flexible and Efficient Code Update Mechanism for Sensor Networks”, Proceedings of the Third European Workshop on Wireless Sensor Networks (EWSN 2006), 2006 [47] Niels Reijers, Koen Langendoen, “Efficient Code Distribution in Wireless Sensor Networks”, WSNA’03, San Diego, California, USA, September 19, 2003 [48] A. Avizienis, J.‐C. Laprie, B. Randell, C. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on Dependable and secure Computing, 2004 [49] J. W. Hui, D. Culler, “The dynamic behaviour of a data dissemination protocol for network programming at scale”, Conference On Embedded Networked Sensor Systems, Proceedings of the 2nd international conference on Embedded networked sensor systems, 2004 [50] Torben Weis, Helge Parzyjegla, Michael A. Jaeger, and Gero Mühl, “Self‐organizing and Self‐stabilizing Role Assignment in Sensor/Actuator Networks”, The 8th International Symposium on Distributed Objects and Applications (DOA 2006), volume 4276 of LNCS, pages 1807‐1824, Montpellier, France, October 2006 [51] Christian Frank, Kay Römer, “Software support: Algorithms for generic role assignment in wireless sensor networks”, Proceedings of the 3rd international conference on Embedded networked sensor systems SenSys ʹ05, November 2005 [52] Kay Römer, Christian Frank, Pedro José Marrón, Christian Becker, “Sensor networks: Generic role assignment for wireless sensor networks“, Proceedings of the 11th workshop on ACM SIGOPS European workshop: beyond the PC EW11, September 2004 [53] Frank, C.; Romer, K., “Solving generic role assignment exactly”, Parallel and Distributed Processing Symposium, 2006. IPDPS 2006. 20th International, 25‐29 April 2006 [54] R. Niu and P. K. Varshney, “Target location estimation in sensor networks with quantized data”, in IEEE Transactions on Signal Processing, vol. 54, December 2006 [55] S. Bandyopahyay and E. J. Coyle, “An Energy Efficient Hierarchical Clustering Algorithm for Wireless Sensor Networks,” Porc. of INFOCOM, March 2003 [56] W. R. Heinzelman, A. Chandrakasan and H. Balakrishman, “Energy‐Efficient Communication Protocol for Wireless Microsensor Networks,” Proc. Of IEEE HICSS, January 2000 [57] K. W. Fan, S. Liu, P. Sinha, “On the potential of Structure‐free Data Aggregation in Sensor Networks”, in To be appear in Proceedings of INFOCOM 2006, April 2006 [58] OSGi Alliance, http://www.osgi.org [59] B. Blum, T. He, S. Son, J. Stankovic, “IGF: A state‐free robust communication protocol for wireless sensor networks”, Technical Report CS‐2003‐11, Univ. of Virginia, Charlottesville, VA, 2003 [60] S. Brown, C.J. Sreenan, “Updating Software in Wireless Sensor Networks: A Survey”, Technical Report UCC‐CS‐2006‐13‐07, Ireland 2006 [61] Chih‐Chieh Han, Ram Kumar, Roy Shea, Mani Srivastava, “Sensor Network Software Update Management: A Survey”, Department of Electrical EngineeringUniversity of California, Los Angeles 2005 [62] P. Pavlos“Literature Survey on Wireless Sensor Networks”, [email protected], 2003

70

bachelor thesis - technische universität darmstadt€¦ · bachelor thesis reconfigurable wireless...

Documents