Sensor networks based on wireless mesh networking architectures have evolved into a power- and cost-efficient way to manage sensors remotely. These architectures, which make it possible for devices to self-organize without human intervention, have opened the way to a whole new class of wireless machine-to-machine applications. As interconnected sensors proliferate, they gather ever greater amounts of previously unobtainable information.
Wireless sensor networking is being used today for energy management, submetering, environmental monitoring, medical monitoring, and industrial automation. Bear in mind that the technology is not a one-size-fits-all solution. Networks can be designed in a variety of ways to address different priorities and make the appropriate technology tradeoffs as dictated by the specific application. You will need to determine the data model most appropriate for your application based on power consumption and data collection timing. This article focuses on data flow and presents the basics of five standard models.
The data model describes the way in which information flows through the network. It should not be confused with topology, which refers to the configuration of the hardware components and how the data are transmitted through that configuration. The data model is a function of the application and describes the flow of data in terms of how those data are used. There are two broad categories of data models: data collection and bidirectional dialog.
Types of Data Models
Data collection models describe monitoring applications where the data flow primarily from the sensor node to the gateway. There are three common data collection models: periodic sampling, event driven, and store and forward.
Bidirectional dialog application classes are characterized by a need for two-way communication between the sensor/actuator nodes and the gateway/application. There are two common bidirectional models: polling and on demand.
For applications where certain conditions or processes must be monitored constantly, such as the temperature in a conditioned space or pressure in a process pipeline, sensor data are acquired from various remote sensor nodes and periodically forwarded to the gateway or data collection center. The sampling period depends primarily on how fast the condition or process varies and what intrinsic characteristics need to be captured.
In many cases, the dynamics of the condition or process being monitored can slow down or speed up from time to time. Therefore, if the sensor node can adapt its sampling rates to the changing dynamics of the condition or process, oversampling can be minimized and power efficiency of the overall network system can be further improved.
Another critical design issue associated with periodic sampling applications is the phase relation among multiple sensor nodes. If two nodes operate with identical or similar sampling rates, collisions between packets from the two nodes are likely to happen repeatedly. Sensor nodes must detect collisions and introduce a phase shift between the two transmission sequences that will prevent these conflicts from recurring.
Sometimes one or more crucial variables must be monitored immediately after a specific event takes place or a particular condition is detected. Familiar examples include fire alarms, door and window sensors, and instruments that are user activated. To support event-driven operations with adequate power efficiency and response speed, the sensor node must be designed such that its power consumption is minimal in the absence of a triggering event and the wake-up time relatively short when a response is required. Many applications call for a combination of event-driven data collection and periodic sampling.
Store and Forward
Data can often be captured and stored, or even processed by a sensor node before transmission to the gateway or base station. Rather than immediately transmitting every data unit as it is acquired, aggregating and processing the information collected by remote sensor nodes can improve overall network performance in both power consumption and bandwidth efficiency. One example of a store-and-forward application is cold-chain management. Here, the temperature and humidity readings inside in a freight container are captured and stored during shipment. When the container reaches its destination, the data are downloaded and reviewed to ensure that conditions stayed within range during transport.
Controller-based applications use a polling data model. In this model, there is an initial device discovery process that associates a device ID with each physical device in the network. The controller then successively polls each device on the network, typically by sending a serial query message and waiting for a response. For example, an energy management application would use a polling data model to enable the application controllers to poll thermostats, variable air volume sensors, and other climate control devices.
The on-demand data model supports highly mobile nodes in the network. A gateway device enters the network, automatically binds to that network, gathers data, and then leaves the network. With this model, one mobile gateway can bind to multiple networks and multiple mobile gateways can bind to a given network. One example of an application using the on-demand data model is medical monitoring where hospital patients wear sensors to monitor vital signs and physicians access those data via a PDA that constitutes a mobile gateway. A doctor enters a room and the mobile PDA automatically binds with the network associated with that patient and downloads the sensor data. When the physician enters another patient's room, the PDA automatically binds with that network and downloads the second patient's data.
Wireless sensor networking is a powerful technology that can serve a host of applications and functions. Taking advantage of its capabilities requires a thorough understanding of design considerations and necessary tradeoffs. Selecting the appropriate data model will enable you to successfully deploy a sensor network that is designed and configured to meet the unique data flow characteristics and performance requirements of your application.