Free Print Subscription Printer-friendly version Email to a Friend

Eyes and ears everywhere: networking embedded devices

( 01 Aug 2004 )
by Nicholas Cravotta, Contributing Editor

The range of applications for embedded networks is growing as costs drop, considering that manual device management can be extremely labor-intensive. Industrial sensor networks are the foundation of this technology, as are control applications, such as for lighting control. New applications include supply-chain management, in which a mobile endpoint tracks and monitors a package; remote health monitoring, in which sensors collect signals from the human body to send to a monitoring station; and security applications using sensors to quickly secure a location.

Many companies are looking to wireless technology to connect embedded devices and avoid the high cost of installing cable and power lines. Devices such as temperature sensors may send only a few bytes of data every minute. For these applications, high-profile standards, such as 802.11, Bluetooth, and even Zigbee are often too expensive, offer too complex a protocol, and consume too much power. You can neither reliably monitor a factory on X10 technology, nor cost-effectively outfit a light with TCP/IP stacks. Many embedded networks need a low-cost, low-bandwidth wireless link.

Designing an effective wireless network requires understanding the trade-offs involved with using low-cost connectivity. The primary driving factor is power; you don't save much by not having to run a data cable if you still have to run power for a radio. However, you don't want to trade off the burden of manual data collection for the burden of manual battery replacement. To achieve long battery life-that is, several years of continuous use-you have to balance bandwidth, latency, range, topology complexity, security, and versatility.

Fundamentals
An embedded wireless network has several components. Endpoints are the actual devices you want to connect. APs (access points) or gateways aggregate multiple endpoints and often bridge to a wired network. Repeaters or routers connect distant endpoints with APs that are out of range and can provide routing redundancy for mesh configurations. If the APs themselves are wireless (consider the cost of running data cable to various points on a factory floor), you might employ a second-tier, higher bandwidth network to serve as a backbone (Figure 1). You can also aggregate data on a local basis, either wirelessly or via a bus, before hitting the wireless backbone.



Figure 1: A star network (a) uses Aps (access points) to aggregate multiple endpoints. Each AP also provides a gateway to the wired network. Endpoints within range of two APs must register with only one. In a mesh network (b), each endpoint can act as a repeater for endpoints too far away to reach the gateway themselves. Meshes provide redundancy: Data from endpoint 1 can reach the gateway via endpoint 2 or via endpoints 3 and 4. A two-tiered approach (c) aggregates access points using a higher bandwidth technology, such as 802.11, which serves as a backbone to the gateway.

A variety of radio options is available. You can purchase a transmit-only RF from Atmel for as little as $1 or a transceiver with a range of 130ft at a maximum data rate of 10kbps for $2. WirelessUSB from Cypress offers rates of 62.5 to 235kbps at a maximum range of 50m starting at $2. For less than $10, you can buy a drop-in module from Xemics offering as much as 152kbps with a range reaching several kilometers, or the self-configuring i-Bean module from Millennial Net, which operates at as much as 100m LOS (line of sight) at 115kbps with low power consumption. Higher bandwidth devices are available, such as the WIT2410 from Cirronet, which runs at 460.8kbps with adjustable output power at 10 or 100- mW, for less than $200 a module. APs range in price from much less than $100 to more than $1000, depending upon the robustness of the network and functions you need to deploy.

Links are available as integrated RF chips or complete modules. Modules often offer much beyond an RF radio, such as ADCs, digital I/O, PWM generators, memory, or an additional processor. Initially, you may want to retrofit the module to existing devices. Modules usually cost more than devices you build yourself, because they come with software and associated APs. Consider the difficulty of at some point integrating the module for cost savings: If you can't solder it onto a host board using an automated assembly system, you will be stuck with a labor-intensive retrofit on your assembly line.

Different endpoints have different connectivity needs. Monitoring devices on a periodic basis offers a consistent flow of data. However, 10 devices transmitting at 5kbps require 50kbps, assuming no contention or interference. To prevent contention, an AP could use a TDMA scheme, effectively dedicating bandwidth to each endpoint. This approach is useful for predictable traffic but less useful for bursty transmissions. Although they eliminate the need for traffic back-off and collision mechanisms, unused slots waste bandwidth. TDMA puts a hard limit on the number of endpoints an AP can support; as you add more endpoints, especially if you support mobile endpoints, you reduce the individual bandwidth to each device. You'll want some sort of QOS (quality-of-service) mechanism in place if you plan to approach the limits of your bandwidth. For example, lower priority devices could wait longer than higher priority devices before trying to use a channel, giving higher priority devices an advantage.

Consistent transmission, however, is the fastest way to reduce battery life. To reduce transmissions, you could employ a polling mechanism, in which endpoints transmit only when an AP asks them to. Polling increases bandwidth usage by reducing endpoint contention for the channel but increases the latency between transmissions, limiting response time. Polling also requires a store-and-forward mechanism, whereby an endpoint stores periodic data until it has the chance to transmit.

The store-and-forward mechanism is ideal for mobile endpoints that may temporarily leave the network; you can track a package while it is in the plant, store temperature data during transport, and recover the data when it reaches its destination. Mesh networks often use store and forward where endpoints can relay data from other endpoints or to buffer data when QOS is active (see sidebar "Mesh networks").

An event-driven mechanism enables endpoints to intelligently manage themselves. For example, when its time to water a golf course, you need to know only the moisture and temperature. By transmitting only essential information, this mechanism conserves power and bandwidth. However, it requires a more intelligent endpoint. You also need a "heartbeat" mechanism to make sure that the sensor remains active.

Given that a network may contain several types of endpoints, a protocol that supports a mix of these mechanisms can best use bandwidth and conserve power. For example, you could reserve several TDMA slots for event-driven or bursty transmissions, thus simultaneously supporting periodic and event-driven endpoints with the same AP.

Batteries for life
Battery life depends on length and frequency of transmission and reception. The i-Bean from Millennial Net, for example, can run for eight months on a 220-mAHR battery, if it transmits once per second. Dropping transmission to once every 10 seconds increases battery life to two years. Longer range translates to fewer APs to cover an area, but you need to transmit with more power.

You could determine when a battery fails by waiting until an endpoint stops transmitting. Alternatively, instead of adding a few components to self-monitor battery life, you could employ an RSSI (received-signal-strength indicator), in which an AP monitors endpoint-signal strength and sends an alert requesting a battery change when the signal begins to degrade.
Another way to increase battery life is to design transmit-only nodes, so the device does not burn power having to check for signals on a regular basis. Key to conserving power is not having to listen, so the radio link can drop into a deep sleep. For example, Bluetooth devices need to regularly synchronize to discover new devices. In such cases, servicing the protocol could consume more power than transmitting data.

Key fobs, for example, have no receiver. You need to implement a robust messaging protocol to ensure successful data transmission, because data collision and interference are likely, and message acknowledgment is nonexistent. A home-security system might use transmit-only endpoints to decrease costs. When an endpoint stops transmitting, the system assumes that the endpoint has been compromised; the endpoint signals an event by not signaling.

You can also apply these power-saving principles using a transceiver as a transmit-only device, reserving the receiver for rare instances. The device could either listen on an irregular basis for broadcast messages or transmit a "ready-to-receive" message to let the AP know when it is listening. Adjustable transmit power allows you to tune transmissions so that you use only as much power as necessary to reach the AP.

With low enough power consumption, you may be able to run the link parasitically off the embedded device, an important characteristic if you plan to integrate the link into your next generation of devices. If you need to know only the location of mobile endpoints, consider using much less expensive RFID tag technology.

Registration and intelligence
Registering devices on a network presents serious ease-of-use challenges. Automatic registration of devices by an AP eases the process but in exchange for a loss of control. When security is an issue and you don't want an endpoint to connect to a neighboring AP or if you want an endpoint to register with a particular AP when several are within range, you might use a manual process to link the endpoint to the AP. Even with automatic linking, devices have only ID numbers, which tell nothing about the devices' locations in the network. You need a means of clearly mapping out the topology of the network, as well as intelligently naming devices and fixing physical locations. It does little good to know that sensor 54332 has declared a temperature-threshold event if you don't know the physical location of the sensor. Even boiler_temp_ sensor_57 leaves much to be desired.

To ease the attachment process, especially in networks with thousands of devices, you might consider having a PDA serve as a mobile endpoint. Instead of having a second technician in a control room to record the placement of a sensor, the technician placing the sensor could use the PDA to register, name, and describe the location of a device. It is easier to develop software for PDAs, and they are much less expensive than proprietary handheld instruments to replace if you drop them. Note that PDAs do not necessarily need to connect to the network; they could employ a store-and-forward mechanism for registration.

A question always arises concerning where in a network intelligence should reside. Implementing a Web server in an endpoint to support remote control and management eliminates the need for centralized control but seriously increases the cost of each endpoint. Such intelligence might make sense to implement in an AP, which could query an endpoint and wrap the data itself. This approach increases the cost of the AP but enables myriad new control and monitoring features.

However, the ability of an endpoint to manage its own thresholds and events is a key method of increasing battery life. Consider how much processing overhead a module offers and the development environment for adding intelligence and features to the module.

Given the aggressive innovation in low-cost RF technology, carefully plan how you will migrate devices and how legacy endpoints and APs will support new features (see sidebar "Other considerations"). As volumes increase and prices drop, new capabilities and capacities will emerge. For example, the Z-Wave from Zensys, which integrates RF, a microcontroller unit, flash memory, and a plug-and-play mesh protocol at a 9.6kbps data rate, currently costs $5 in volume. The company plans to release a second-generation part in the second half of 2004, which will reduce the price to $2.50, and a ROM version that will cost $1 by the end of 2005.

Author Information
You can reach Contributing Technical Editor Nicholas Cravotta at editor@nicholascravotta.com

at a glance

  • Low-cost wireless links can reduce installation and maintenance costs and provide mobility.

  • Battery life is everything, and the most effective way to conserve power is to reduce transmission frequency and length.

  • A hybrid transmission mechanism lets you more efficiently support a variety of applications on the same network.

  • Ease of use is essential when you consider managing hundreds of devices that aren't even smart enough to know they're part of a network.


  • Sidebar 1: Mesh networks
    In a mesh network, endpoints can act as repeaters or routers to forward data between endpoints and gateways. Although meshes extend excellent coverage to mobile endpoints, each hop consumes bandwidth and power. Endpoints close to a gateway pass more data for other devices than for themselves. Receiving and retransmitting data consumes power on the endpoint, which must also have enough memory to store and forward data as well as manage a routing table.

    Each hop uses at least twice the bandwidth of the data, and latency also takes a hit. You may need to implement back-pressure mechanisms for cases in which too much data hits an endpoint, but, because this implementation pushes the need for buffers back onto the endpoints, doing so increases overall cost. Additionally, because you don't know where in the mesh a device will be placed, you must allocate buffers and battery life for each device as if the device were highly active, passing other endpoint data. A well-placed gateway can significantly reduce the number of hops, conserving bandwidth and increasing battery life.
    Network diagnostics are important for mesh or self-configuring networks. If you can't gather information on bandwidth capacity or latency, for example, then you have no way of knowing whether you've underallocated or overallocated APs (access points). Tracking latency along hops can identify congested nodes; it might be more efficient to select a route with an extra hop to use less burdened nodes. You can also watch for routes that keep changing and determine whether the fact that the network is continuously reconfiguring itself is a potential problem. Consider enabling forwarding nodes to downgrade themselves to nonforwarding nodes when their battery life is low. Endpoints should also be able to send an alert that battery death is pending.

    Sidebar 2: Other considerations

    When using a store-and-forward mechanism, employing a simple differential compression scheme can go a long way toward conserving bandwidth and battery life. If the data you are storing varies little over time, store the number of consecutive identical samples or store the difference between samples. (In other words, use 6 bits to represent a plus or minus change rather than 16 bits to hold the actual value). Be sure the protocol can support proprietary data compression. You could aggregate more complex compression in an AP (access point) that has more processing and storage resources.

    Consider how complex it is to change a battery. It might be more cost-effective to throw out the sensor, given that you can bring in newer and more power-efficient devices in five to 10 years.

    To futureproof your network consider employing containment strategies, such as isolating proprietary devices behind a bridge. Beyond the bridge, data should take on a fairly open format. You can then co-locate several incompatible technologies, enabling you to take advantage of new wireless technologies as they arise without being tied to legacy deployments.

    If you design a handheld interface to your network, be aware that it presents user-interface issues that differ greatly from those of PCs. Handheld devices compete with the surrounding environment for a user's attention; a PC usually commands all the user's attention. A smaller screen also limits the number of endpoints you can monitor simultaneously. Selecting which endpoints to display should be a straightforward process; scrolling through a list of 1000 sensors is anything but. Consider using signal strength to determine which endpoints a user is standing near to narrow the choices.

    Transceivers in the 900- and 868MHz ranges tend to be low-cost in volume, but, because US and European standards differ, you have to create distinct product lines for each of these markets. The 2.4GHz frequency has universal acceptance, but cordless phones, microwaves, and WiFi (Wireless Fidelity) devices are quickly crowding this segment. A variety of other frequencies are available, depending on your environmental conditions.

    Spread-spectrum technologies allow higher transmitting power, because they spread power across many frequencies, but they require a more complex radio and processing and offer fewer channels, limiting co-locating of networks. Frequency-hopping radios support many channels and offer inherent security and signal-reflection resilience but must listen for hop-synchronization information, limiting how long you can put the radio into deep sleep to conserve power.

    Several good reasons exist to provide extra bandwidth. With potentially several hundred endpoints trying to talk to the same AP, more bandwidth reduces contention and may allow you to use a less robust protocol, reducing endpoint complexity and cost. For one-way links, the faster an endpoint can transmit data, the less the exposure to collision. Alternatively, you can use a robust protocol to improve bandwidth usage, allowing you to handle, for example, 100 devices with only 9.6kbps of bandwidth. A broadcast mechanism can conserve bandwidth and reduce the latency of sending universal commands.

    Be sure to understand in detail vendor protocols. Consider how flexible the protocols are and how easily you can add features to them. Don't underestimate the complexity of creating your own protocol.

    Consider a vendor's tool set, such as the software tools available to add functions to the module. Evaluate the deployment and simulation tools available for testing and designing network configurations, as well as profiling bandwidth usage and latency (but never forget that simulation cannot replace field testing). Solid management tools allow you to monitor and maintain the health of the network; if the vendor doesn't supply these tools, you have to develop them yourself.

    Security is a costly proposition, consuming bandwidth with handshaking and data encapsulation. Consider the risk of intrusion: What's the harm in someone's seeing a temperature? If security is important, add it only where data vulnerability matters.

     
    Free Print Subscription Printer-friendly version Email to a Friend
    Article Rating 
    Average Rate: No rating yet
     
    Poor Quite Good Good Very Good Excellent
     
     
    Related Content 
     
     
    WEBCASTS
     
    KNOWLEDGE CENTER
    Panasonic Key Devices Guide 2008:
     
    Fairchild Semiconductor :
     
     
    Highest Rated  
     
    Feedback Loop  
     
     
     
    ADVERTISEMENT
    Press Release 
     
    TECHNOLOGY NEWS
     
    RESOURCE CENTER


     
     
    PRODUCT NEWS
     
    FEATURED SPONSORS


     
     
     
    DESIGN CENTERS
     
    ADVERTISEMENT
         
    Reference Designs 
       
         
     
     
     

     
     
    RSS
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       

    POLL
    What type of environmental regulation do you think will be most beneficial for the tech industry?
    Proper recycling and disposal
    Push for power efficiency and energy conservation
    Chemical/lead regulation
    View results
     
    Outlook and Trends 2008