Mesh together: This prototype relay node, developed by NIST, features an LED that automatically changes from green to red whenever a new node needs to be set down.
NIST

Computing

A Network That Builds Itself

Ad-hoc wireless networks may soon tell emergency workers how to deploy transmitters.

  • Wednesday, September 3, 2008
  • By Michael Fitzgerald

Building an on-the-fly wireless communications networks is a vital part of firefighting, handling hostage situations, and dealing with other emergencies. But it is difficult to build such networks quickly and reliably.

Soon these emergency wireless networks could help build themselves. The National Institute of Standards and Technology (NIST) recently presented details of two experimental networks that tell emergency workers when to set down wireless transmitters to ensure a good signal.

Ad hoc wireless networks relay messages between transmitters, or nodes, without requiring any central control. But as things stand, emergency workers simply follow suggested guidelines for building such a wireless network--placing each node 15 or 30 meters apart and at key points, like the corners of a building. Or they periodically check back with the command center to make sure they're still in touch. Neither method is terribly efficient in an emergency, however. The process can also be costly if a large number of nodes are used.

The NIST prototypes, which have been under development for more than three years, use algorithms to monitor the signal-to-noise ratio of transmissions and automatically warn when a new node should be set down.

Advertisement

"We didn't want to have fixed rules, because there can be a lot of metal in walls or cinder block," meaning signal strength varies building to building, says Nader Moayeri, a senior technical advisor in NIST's Advanced Network Technologies Division. "Plus, you don't want to deploy too many, because of the cost factor as well as potential for communication delays."

Moayeri says that NIST considered having nodes ping each other with short messages to see how many packets of data were lost in transit. The problem with this approach is that the person deploying the network would not detect a weak connection immediately and might have to backtrack. Having an algorithm measure the signal-to-noise ratio instead avoids this problem and provides a clearer picture of connection strength.

NIST built two prototype networks using off-the-shelf hardware. One operates at 900 megahertz and uses Crossbow MICA2 Motes to transmit radio signals. The other, a Wi-Fi network operating at 2.4 gigahertz , uses Linux-based Gumstix transmitters. But Moayeri says that the NIST algorithm should work with any wireless hardware and on any available spectrum.

In the Crossbow system, each node has an LED that automatically changes color, from green to red, when a new node needs to be set down. The Gumstix system issues alerts via a handheld or tablet computer connected to the same wireless network.

Print

Related Articles

A New Language for Phone Networks

Researchers develop a better way to write applications for peer-to peer cellular networks.

A Mobile Mesh Network Goes Nuclear

Backpacks that detect nuclear material form a wireless mesh network.

Meraki Outdoor

A mesh networking repeater for harsh conditions.

Close Comments

To comment, please sign in or register

Forgot my password

ms

190 Comments

  • 1259 Days Ago
  • 09/03/2008

35 kbps is plenty for voice

35 kbps should be quite sufficient for voice communication. The standard rate for landline-quality voice is 64kbps uncompressed, which reduces to around 7kbps when compressed by standard methods.

Reply

riparian

2 Comments

  • 1258 Days Ago
  • 09/04/2008

Re: 35 kbps is plenty for voice

I asked Nader Moayeri to take a look at this and respond.  He sent me a response instead, which I am posting below.  Michael Fitzgerald

Moayeri's comment:

this is a good question.  However, this person is thinking point-to-point communications.  If you have a single transmitter sending information to a single receiver, then a tranmission rate of 35 Kbps would certainly be adequate for sending voice.  In fact, there are voice coders that code voice at 4 Kbps.

However, when you do VOIP (Voice Over IP), which is what's happening in our network, there is a good bit of overhead (packet headers, possibly retransmissions as a result of transmission errors, etc).  Not only we are using VOIP, but this is also an ad hoc network.  There is a lot of overhead associated with establishing multihop routes and maintaining them, because routes do break.  That's why having voice communications over our the mote network we built is not possible even if we had used a 4 Kbps voice coder.  (Right now we are using a 28 Kbps voice coder.)

Reply

Advertisement

MAGAZINE

Can We Build Tomorrow's Breakthroughs?

Manufacturing in the United States is in trouble. That's bad news not just for the country's economy but for the future of innovation.

Sponsored Content

Technologies from National Instruments

Adding Data Logging
Log measured data to a file and open it in Microsoft Excel

> Click here for more National Instruments Videos <
Whitepaper

Temperature Measurements with Thermocouples: How-To Guide

This document is part of the “How-To Guide for Most Common Measurements” centralized resource portal. This tutorial provides a detailed guide for measurement and device considerations to take temperature measurements using thermocouples. Get an introduction to thermocouples, which are inexpensive sensing devices widely used with PC-based data acquisition systems. Also review some specific thermocouple examples and learn how thermocouples work and ways to integrate them into a data acquisition measurement system.

View full PDF > Listen to story >
Find us on Youtube

Videos

A Robot Recruit that Can Do It All

More

Advertisement

Technology Review Lists

TR50

Our list of the 50 most innovative companies, including the following:

Zynga

Facebook

A123 Systems

BIND Biosciences

More

Advertisement

Facebook

Advertisement