Technology Review - Published By MIT
Advertisement

A Network That Builds Itself

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

By Michael Fitzgerald

Wednesday, September 03, 2008

smaller text tool iconmedium text tool iconlarger text tool icon

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.

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.
Credit: NIST

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.

"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.

Story continues below

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.

Comments

  • 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.
    Rate this comment: 12345

    ms
    09/03/2008
    Posts:126
    Avg Rating:
    4/5
    • 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.)
      Rate this comment: 12345

      riparian
      09/04/2008
      Posts:2

Log In

Forgot your password?     Register »
Advertisement

Videos

Laser-Triggered Chemical Reactions
Featured Content
Sponsored by:
White Papers

Twelve ways to reduce costs with SQL Server 2008
Find out how to reduce costs and get more efficient

Download

Total Economic Impact of SQL Server 2008 Upgrade
Forrester reports on increasing productivity and management capabilities

Download 

Achieving Cost and Resource Savings with UC
How Office Communications Server R2 and Exchange Server can make your business smarter and more efficient

Download 

The Compelling Case for Conferencing
Read how you can improve workload support and find IT efficiencies

Download

How Windows Server 2008 R2 Helps Optimize IT and Save you Money
Read how you can improve workload support and find IT efficiencies

Download

Windows Server 2008 R2 Hyper-V Live Migration
See how Windows Server 2008 R2 and Hyper-V enable virtualization and Live Migration

Download
Advertisement
Subscribe to Technology Review's daily e-mail update. Enter your e-mail address

TECHNOLOGY RESOURCES
Advertisement
MIT Massachusetts Institute of Technology © 2009 Technology Review. All Rights Reserved.