Commercial- and Industrial-Class Wireless Sensor Networks

Home | News & Events | Company Info | Contact Us | Login     
INDUSTRY SOLUTIONS PRODUCTS & SERVICES TECHNOLOGY PARTNERSHIPS & ALLIANCES RESOURCE LIBRARY
Network Protocol
Topologies
Data Models
APIs

White Papers
Learn about the MeshScape technology

MeshScape Technical Overview

Maximizing Data Reliability in Wireless Sensor Networks


Brochures and Data Sheets

MeshScape Brochure

MeshScape 4.0 Data Sheet

MeshScape 5.0 Data Sheet


Data Models

The data model describes the way in which the data flows through the network.

The data model differs from topology. Topology refers to the configuration of the hardware components and how the data is transmitted through that configuration. The data model, on the other hand, is a function of the application and describes the flow of the data in terms of how that data is used. There are two broad categories of data models: data collection models and bi-directional dialogue models. The MeshScape system provides built-in support for data movement profiles to speed development. These data models optimize the network for an application’s specific data requirements and support a variety of classes for collection and bi-directional dialogue data models.

Data models describe monitoring applications where the data flows primarily from the sensor node to the gateway. There are three common data collection models: periodic sampling, event driven, and store and forward. Bi-directional dialogue application classes are characterized by a need for two-way communication between the sensor/actuator nodes and the gateway/application. There are two common data collection models: polling and on-demand.

Periodic Sampling

For applications where certain conditions or processes need to be monitored constantly, such as the temperature in a conditioned space or pressure in a process pipeline, sensor data is acquired from a number of remote sensor nodes and forwarded to the gateway or data collection center on a periodic basis. The sampling period mainly depends 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 to be 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, over-sampling 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 sensor nodes operate with identical or similar sampling rates, collisions between packets from the two nodes is likely to happen repeatedly. It is essential that sensor nodes can detect this repeated collision and introduce a phase shift between the two transmission sequences in order to avoid further collisions

Event Driven

There are many cases that require monitoring one or more crucial variables immediately following a specific event or condition. Common examples include fire alarms, door and window sensors, or instruments that are user activated. To support event-driven operations with adequate power efficiency and speed of response, the sensor node must be designed such that its power consumption is minimal in the absence of any triggering event, and the wake-up time is relatively short when the specific event or condition occurs. Many applications require a combination of event driven data collection and periodic sampling.

Store and Forward

In many applications, data can be captured and stored or even processed by a sensor node before it is transmitted to the gateway or base station. Instead of immediately transmitting every data unit as it is acquired, aggregating and processing data by remote sensor nodes can potentially improve overall network performance in both power consumption and bandwidth efficiency. One example of a store-and-forward application is cold-chain management where the temperature in a freight container is captured and stored; when the shipment is received, the temperature readings from the trip are downloaded and viewed to ensure that the temperature and humidity stayed within the desired range.

Polling

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 polls each device on the network successively, typically by sending a serial query message and waiting for a response to that message. For example, an energy management application would use a polling data model to enable the application controllers to poll thermostats, variable air volume (VAV) sensors, and other devices for temperature and other readings.

On-Demand

The on-demand data model supports highly mobile nodes in the network where a gateway device enters the network, automatically binds to that network and gathers data, 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. An example of an application using the on-demand data model is a medical monitoring application where patients in a hospital wear sensors to monitor vital signs and doctors access that data via a PDA that is a mobile gateway. A doctor enters a room and the mobile PDA automatically binds with the network associated with that patient and downloads vital sensor data. When the doctor enters a second patient’s room, the PDA automatically binds with that network and downloads the second patient’s data.


  MeshScape
The MeshScape wireless sensor networking system delivers the highest performance in scalability, reliability, responsiveness, and power efficiency..
MeshScape

 

Reference Kits
Wireless Sensor Networking Reference Kits for Fast Prototyping
Reference Kits

 

 




© 2005 Millennial Net     All rights reserved.    Site Map