As we previously stated, the layered protocol stack description of the system architecture for a sensing node cannot cover all the aspects involved (such as cross-layer communication, dynamic update, etc.). The crossing planes though the protocol stack seems good as a solution, but in reality is almost difficult to implement. Establishing communication between the blocks in the protocol stack on a dynamic basis, being flexible with respect to the types of data being available at a certain moment inside the node and tolerating misbehaving blocks (correctly designed but producing unusable data due to effects of dynamics of the environment, mobility, out-of-date software, etc.) are some of the constraints affecting the design of a software architecture.
In this section we propose a new flexible architecture design. The architecture was designed having environmental dynamics in mind and is aimed at offering maximum flexibility while still adhering to the basic design concept of sensor networks: the devices should adapt at run time with the main goal of keeping the network alive, under a variety of conditions (the designer being probably unaware of most of them at design time).
4.3.1 Motivation
The sensor networks are dynamic from many points of view. Continuously changing behaviors can be noticed in several aspects of sensor networks, some of them being:
• Sensing process: The natural environment is dynamic by all means (the basic purpose of sensor networks is to detect, measure, and alert the user of the changing of its parameters).
Thesensor modules themselves can become less accurate, need calibration, or even break down.
• Network topology: One of the features of the sensor networks is their continuously chang-ing topology. There are a lot of factors contributchang-ing to this, such as failures of nodes or the unreliable communication channel, mobility of the nodes, variations of the transmission ranges, clusters reconfiguration, addition/removal of sensor nodes, etc. Related to this aspect, the algorithms designed for sensor networks need to have two main characteris-tics: they need to be independent on the network topology and need to scale well with the network size.
• Available services: Mobility of nodes, failures, or availability of certain kinds of nodes might trigger reconfigurations inside the sensor network. The functionality of nodes may
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
4-12 Networked Embedded Systems
depend on existing services at certain moments and when they are no longer available, the nodes either reconfigure or try to provide them themselves.
• Network structure: New kinds of nodes may be added to the network. Their different and increased capabilities will bring changes to the regular way in which the network func-tions. Software modules might be improved or completely new software functionality might be implemented and deployed in the sensor nodes.
Most WSN architectures currently use a fixed layered structure for the protocol stack in each node.
Thisapproach has certain disadvantages for WSNs. Some of them are:
• Dynamic environment: Sensor nodes address a dynamic environment where nodes have to reconfigure themselves to adapt to the changes. Since resources are very limited, reconfiguration is also needed in order to establish an efficient system (a totally new func-tionality might have to be used if energy levels drop under certain values). The network can adapt its functionality to a new situation, in order to lower the use of the scarce energy and memory resources, while maintaining the integrity of its operation.
• Error control: It normally resides in all protocol layers so that for all layers the worst case scenario is covered. For a WSN this redundancy might be too expensive. Adopting a cen-tral view on how error control is performed and cross-layer design reduces the resources spent for error control (and actually makes it feasible).
• Power control: It is traditionally done only at the physical layer, but since energy con-sumption in sensor nodes is a major design constraint, it is found in all layers (physical, data-link, network, transport, and application layer).
• Protocol place in the sensor node architecture: An issue arises when trying to place certain layers in the protocol stack. Examples may include: timing and synchronization, local-ization, and calibration. These protocols might shift their place in the protocol stack as soon as their transient phase is over. The data produced by some of these algorithms might make a different protocol stack more suited for the sensor node (e.g., a localization algorithm for static sensor networks might enable a better routing algorithm that uses information about the location of the routed data destination).
• Protocol availability: New protocols might become available after the network deploy-ment or at certain modeploy-ments, in specific conditions, some of the sensor nodes might use a different protocol stack that better suits their goal and the environment. The means of changing or updating at run time parts of the software on the nodes is an important needed feature.
4.3.2 Architecture Description
Thesystem we are trying to model is an event-driven system, meaning that it reacts and processes the incoming events and afterward, in the absence of these stimuli, it spends its time in the power-down state (the software components running inside the sensor node are not allowed to perform blocking waiting).
We introduce a higher level of abstraction for the event class as data. Data may encapsulate the information provided by one or more events, have a unique name and contain additional infor-mation such as time inforinfor-mation, identity of producer, etc. Data is the means used by the internal mechanisms of the architecture to exchange information components.
In the following we address any protocol or algorithm that can run inside a sensor node with the term entity (see Figure .. An entity is a software component that will be triggered by the availability of one or more data types. While running, each entity is allowed to read available data types (but not wait for additional data types becoming available). As a result of the processing, each
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
Architectures for Wireless Sensor Networks 4-13
Module manager Publish/subscribe server
Data Data Data
Data Data Data Data Data
Data Data
Data Input Input
Data DataOutputFunctionality Capabilities {...}
Data
DataData Data
Data Data
Input Capabilities {...} Capabilities {...}
Functionality Functionality Capabilities {...}
Functionality
Input Input
Output Data Input Input
Output OutputInput FIGURE.Entitydescription.
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
4-14 Networked Embedded Systems
software component can produce one or more types of data (usually upon the completion of their execution).
An entity is also characterized by some functionality, meaning the sort of operation it can produce on the input data. Based on their functionality, the entities can be classified as being part of a certain protocol layer as in the previous description. For one given functionality, several entities might exist inside a sensor node; to discern among them, one should take into consideration their capabilities. By capability we understand high-level description containing the cost for a specific entity to perform its functionality (as energy, resources, time, etc.) and some characteristics indicating the estimated performance and quality of the algorithm.
In order for a set of components to work together, the way in which they have to be interconnected should be specified. Most of the architectures existent up to this moment in the WSN field, assume a fixed way in which these components can be connected, which is defined at compile time (except for the architectures that, for example, allow execution of agents). To change the protocol stack in such an architecture, the user should download the whole compiled code into the sensor node (via the wireless interface) and then make use of some boot loader code to replace the old running code in it.
In the proposed architecture we are allowing this interconnection to be changed at run time, thus making on line update of the code possible, the selection of a more suited entity to perform some functionality based on the changes in the environment, etc. (in one word allowing the architecture to become dynamically reconfigurable).
To make this mechanism work, a new entity needs to be implemented—we call this the data man-ager. The data manager monitors the different kinds of data being available and coordinates the data flow inside the sensor node. At the same time it selects the most fitted entities to perform the work and it is even allowed to change the whole functionality of the sensor node based on the available entities and external environment (for a conceptual schematic see Figure ..
The implementation of these concepts cannot make abstraction of the small amount of resources each sensor node has (as energy, memory, computation power, etc.). Going down from the abstrac-tion level to the point where the device is actually working, a compulsory step is implementing the envisioned architecture in a particular operating system (in this case, due to the size and func-tionality provided, maybe a better term is system software). A large range of operating systems exist for embedded systems in general ([,] being two of the several tens of names). Scaled down versions with simple schedulers and limited functionality have been developed especially for WSN [].
Usually, the issues of system architecture and operating system are treated separately, both of them trying to be as general as possible and to cover all the possible application cases. A simplistic view of a running operating system is a scheduler that manages the available resources and coordinates the execution of a set of tasks. This operation is centralized from the point of view of the scheduler that is allowed to take all the decisions. Our architecture can also be regarded as a centralized sys-tem, with the data manager coordinating the data flow of the other entities. To obtain the smallest overhead possible there should be a correlation between the function of the central nucleus from our architecture and the function of the scheduler from the operating system. This is why we propose a close relationship between the two concepts by extending the functionality of the scheduler with the functionality of the data manager. The main challenges that arise are keeping the size of the code low and the context-switching time.
4.3.3 Additional Features
As we mentioned earlier, the general concept of data is used rather than the event one. For the decision based on data to work, there are some additional requirements to be met.
First of all, all the modules need to declare the name of the data that triggers their action, the name of the data they need to read during their action (this can generically incorporate all the
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
Architectures for Wireless Sensor Networks 4-15
Data
Data Input Functionality Capabilities {...}
InputOutputData
Data Data Data
Data Input Functionality Capabilities {...}
InputOutputData
Data Data Data
Data Input Functionality Capabilities {...}
InputOutputData
Data Data Data
Data Input Functionality Capabilities {...}
InputOutputData Data Data
Data
Data Input Functionality Capabilities {...}
InputOutputData Data Data
Data
Data Input Functionality Capabilities {...}
InputOutputData Data Data
Data
Data Input Functionality Capabilities {...}
InputOutputData Data Data
Data
Data Input Functionality Capabilities {...}
InputOutputData
Data Data Data
Data Input Functionality Capabilities {...}
InputOutputData Data Data
Data
Data Input Functionality Capabilities {...}
InputOutputData
Data Data Data
Data Input Functionality Capabilities {...}
InputOutputData Data DataData
Data Input Functionality Capabilities {...}
InputOutputData Data Data FIGURE.Architecturetransitions.
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
4-16 Networked Embedded Systems
shared resources in the system) and the name of the data they produce. The scheduler needs all this information to take the decisions.
From the point of view of the operating system, a new component that takes care of all the data exchange needs to be implemented. This would in fact be an extended message-passing mechanism, with the added feature of notifying the scheduler when new data types become available. The mapping of this module in the architecture is the constraint imposed to the protocols to send/receive data via, for example, a publish/subscribe mechanism to the central scheduler.
An efficient naming system for the entities and the data is needed. Downloading new entities to a sensor node involves issues similar to services discovery. Several entities with the same functionality but with different requirements and capabilities might coexist. The data-centric scheduler has to make the decision which one is the best.
Thearchitecture presented earlier might be extended to groups of sensor nodes. Several data-centric schedulers together with a small, fixed number of protocols can communicate with each other and form a virtual backbone of the network [].
Entities running inside sensor nodes can be activated using data types that become available at other sensor nodes (for example, imagine one node using his neighbor routing entity because it needs the memory to process some other data).
Of course, this approach raises new challenges. A naming system for the functionality and data types, reliability issues of the system (for factors such as mobility, communication failures, node fail-ures, and security attacks), etc. are just a few examples. Related work on these topics already exist (e.g., [,]). In the case of the data-centric architecture we propose, this aspect is a research topic addressed by the Featherlight research project [].
4.3.4 Generalized Component Interfaces
Sensor networks are a relatively new field of science. A large number of prototypes have been already built and some commercial application already exist. One of the main problems a system integrator faces at this moment is the lack of standards and basically the lack of a standardized interface to the data available via the sensor networks.
Thelack of standardized interfaces manifests itself at various levels: the interface between appli-cation and the architecture, interface between appliappli-cation and networking protocols, interface between the gateway and an external computer, and the interface between the computer and existing infrastructure. The end result of this lack of standardization reflects itself in the usability of sensor networks and their adoption by the general public. Applications are written now mainly for specific platforms and specific networking protocol stacks and sharing of data between various applications needs to be implemented almost from scratch every time.
In this section we will explore one alternative for such an interface. The motivation for this effort is quite straight forward—we can only bring into discussion the fact that interfacing the various building blocks of a sensor network takes more development time then implementing the spe-cificapplication. The existence of a generally accepted interface will allow various protocols to be actually stacked on top of each other; it will also allow quantification of the behavior of various algo-rithms/protocols in a given setup. Other benefits of having such an interface would be reducing the number of interfaces needed to access all the data provided by the sensors in the network, reducing the number of packet formats to be transmitted by the MAC and routing protocols, etc.
The starting point for the generalized component interface is the concept of entity itself. As mentioned previously, by entity we understand a basic software component having a dedicated func-tionality. The entity provides already a number of parameters as the details needed for the real time scheduler, the details about the data it produces and it consumes, etc. We extend this information with a description on the way the actual entities provide functionality to the exterior.
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
Architectures for Wireless Sensor Networks 4-17
Thegeneralized component interface consists of the following basic concepts:
• Identification means: The entity needs to be uniquely identifiable from the user perspec-tive. A tuple of parameters containing the node identifier, the entity identifier, and the sensor instance identifier is proposed as a solution.
• Functionality access: The user will interact with the entity by calling a function (even-tually receiving the result returned by the function). The entity will provide two sets of functions: a fixed set (generic functions available in every entity as configuration func-tions, service description, standard access funcfunc-tions, etc.) and a user-specific set (with no restrictions applied to it).
• Standardized parameters: The functions provided by the entity need to accept parameters of various types and sizes. We propose to use one standard data structure containing two fields: the size of the user data and the actual payload of the user data for that function.
Because the user calls a specific function, it knows what parameters it needs to send and can transform them in a byte array (a “void *” pointer in the C language) of a known length. The function in the entity will cast this array of bytes to the structure it expects as input as the first operation and then perform as any regular function. The return parame-ters are passed based on the same philosophy. Because both the user and the function have a clear understanding of the data structure for a given function, no additional description needs to be sent in clear.
When building the generalized interface as an application block we can built it out of three small layers:
• Physical layer: Any physical interface existing in the node. Examples include the radio interface, the serial port, the digital I/O lines, etc. No specific software needs to be devel-oped here except the hardware abstraction layer (hardware driver) usually provided by the system software.
• Data-link layer: This layer is a small extension of the data-link layer existent already on top of the chosen physical layer. The addition consists in specifying the payload to be sent/received by this layer in the form of two fields: the size of the byte array and the byte array itself. This is a straight forward extension on most data-link layers.
• Standard interface layer: This layer needs to be developed once for every entity. As we already mentioned, this layer needs to provide a unique mean of identification, a set of predefined functions, and a set of user defined functions. Additional mechanisms (as reporting an error when an nonexistent function was called or when the data struc-ture sent to a function cannot be cast to the needed data strucstruc-ture) need to be set in place.
Themain advantage of this approach is the large flexibility offered. At the physical level, it does not really matter though which interface the data arrived to the entity (via the serial port, via the radio, etc.). The data-link layer stays basically unchanged. The standard interface layer allows users/applications to call any function as long as they supply the correct input parameters.
4.3.5 Concluding Remarks
In this chapter we introduced the concept of a flexible data-centric architecture that gathers its strength from combining the concepts of architecture and operating system in one single notion.
Additional strength is gained by offering a unified approach in calling functionality across all the
Additional strength is gained by offering a unified approach in calling functionality across all the