Wi-Fi networking is becoming more popular for embedded applications for much the same reasons as Ethernet networking became popular. The technology is familiar; the equipment to set up the network is inexpensive; and it enables easy communication with PCs and other devices on existing network infrastructure. However, implementing Wi-Fi networking for embedded systems poses some special challenges for the embedded systems designer. Which features should you look for? Which are most important? What special considerations should you be aware of? This article aims to help you understand the peculiarities of Wi-Fi for embedded systems so that you can choose the best Wi-Fi implementation based on your needs.
To determine if a particular embedded Wi-Fi solution is right for you, a number of questions need to be posed and answered. This article covers these questions:
• Does the solution provide full Wi-Fi access (including access to socket-level programming) or simply serial-to-Wi-Fi?
• Will the Wi-Fi solution be available long-term? What issues can you expect over the long-term?
• Is 802.11g or 802.11n supported, or only 802.11b?
• Which security (encryption and authentication) features are supported?
• Is the solution FCC-certified? Can you integrate the solution into your product without additional certification?
• What about certification with other regional authorities? Is multidomain (802.11d) supported?
• What is the maximum data throughput for the solution? How does Wi-Fi encryption and authentication affect your throughput?
• What is the power usage of your Wi-Fi solution? Are low-power modes supported?
• Does it provide typical Wi-Fi range, or is performance compromised?
• What is the operating temperature specification?
• How is antenna placement handled, and can you use an antenna other than that which is provided?
• Is roaming from one access point to another handled cleanly?
Each of these questions will be explored in turn. By studying these questions and researching the answers based on your requirements and the Wi-Fi solutions you're exploring, you should be much closer to selecting the right solution for your product.
Serial-to-Wi-Fi or full access?
Many Wi-Fi devices for embedded systems provide only serial-to-Wi-Fi functionality. The idea is that the Wi-Fi device has preloaded firmware, and you use a serial port on your embedded device to interface with the Wi-Fi device. This is very similar to serial-to-Ethernet devices. Serial-to-Wi-Fi devices make it easy to add some limited Wi-Fi capability to existing embedded devices (as long as a serial port is available). This option works well for applications that need only one connection (or socket) at a time. It is especially well-suited for allowing a serial port to be accessed over the network. If you need the ability to run multiple servers or clients on your device (such as a web server, FTP server, and email client), serial-to-Wi-Fi devices probably will not provide enough flexibility.
An increasing number of single-board computers and core modules are available that have Wi-Fi integrated as a native network interface . The native network interface typically allows full socket-level access so that you can run concurrent servers and clients–in other words, a full networking system. This can make for an overall cheaper solution since a separate device is not needed. Of course, if you are adding Wi-Fi capabilities to an existing system, the serial-to-Wi-Fi devices will be much easier to implement as long as the limitations are acceptable.
Over the long-term
Until recently, it was difficult for manufacturers of embedded devices to integrate Wi-Fi support. Wi-Fi chipsets were targeted more towards the consumer market, which meant chipsets were frequently introduced and EOL'd (end-of-lifed). Some early solutions used Wi-Fi CompactFlash cards. The problem was these cards were targeted specifically at the consumer market; their main purpose was to provide Wi-Fi interfaces for PDAs (personal data assistants). The chipsets changed frequently–by the time an embedded application was released to market, the supported chipset would be at its end of life. Eventually, as PDAs gained integrated Wi-Fi and the consumer's need for CompactFlash- based Wi-Fi cards disappeared, the format vanished altogether.
This discussion implies that it's important to consider the long-term availability of your Wi-Fi solution. If you're using a serial-to-Wi-Fi-style device, it probably includes “canned” firmware that is installed at the factory. Therefore, if the manufacturer finds that they need to change the Wi-Fi chipset used, they can change the installed firmware at the factory before they even sell you the device. However, if you're using an embedded device with an integrated Wi-Fi chipset, you should more carefully consider what a change to the Wi-Fi chipset means for you.
If the embedded device has a pre-installed Wi-Fi driver (perhaps part of a pre-installed operating system), the manufacturer should be able to change the driver when the chipset changes. The impact on your application should be minimal.
If the Wi-Fi driver is compiled as part of your firmware for the device, changes to the Wi-Fi chipset will be much more disruptive. You would need a new driver and multiple versions of your firmware for different versions of the hardware. You should check with your embedded solution manufacturer to find out their plan for Wi-Fi-chipset changes. Do they have a guaranteed supply of chipsets for the life of the product? How will they manage the changes if their Wi-Fi chipset is EOL'd?
Which flavor of 802.11?
Wi-Fi is divided into a number of types. 802.11b was the first Wi-Fi technology that achieved mass acceptance; it has since been largely supplanted by 802.11g. 802.11a has seen some use, but has not achieved the mass popularity of 802.11g. 802.11n is not yet ratified, but some consumer-level devices are beginning to support preliminary versions of the standard. Table 1 provides some useful information on each of the standards.
Note that the maximum data rate does not mean that you will see that amount of data throughput. Wi-Fi has high overhead, especially in infrastructure mode where most data is first sent to the access point and then resent from the access point to the destination. Typically, your maximum throughput will be significantly less than half of the maximum data rate.
The most popular Wi-Fi devices for embedded systems are based on 802.11b and 802.11g. 802.11b has the lowest data rate available but is widely compatible with existing Wi-Fi networks. 802.11g is compatible with 802.11b devices and provides for a much higher maximum data rate. Both 802.11b and 802.11g use the 2.4 GHz operating frequency; this frequency is crowded with interference from other Wi-Fi devices, microwaves, cordless phones, and so forth. In general, the price delta between 802.11g and 802.11b is dropping. For marketing reasons, you should probably deploy 802.11g simply because 802.11b is perceived as being “old” technology. This is similar to the perception of 100Base-T Ethernet versus 10Base-T Ethernet; even if the slower technology provides the necessary performance, it isn't seen as modern and desirable.
If interference is an issue (for example, you need more predictable performance from your Wi-Fi network), then 802.11a should be considered. Its performance characteristics are very similar to that of 802.11g. However, because it uses the relatively uncrowded 5GHz frequency band, it is far less susceptible to interference. Unfortunately, 802.11a availability is relatively low in the embedded space and has limited deployment in the consumer space. If you are designing an embedded system where you are in control of the makeup of the Wi-Fi network, 802.11a could be a good choice. If you need to integrate into existing Wi-Fi networks, 802.11b or 802.11g would be better.
Although 802.11n has the highest data rate available, it has very little presence in the embedded world. 802.11n is new technology–so new that the standard has not even been ratified by the IEEE. Many networking equipment manufacturers are releasing consumer-level devices based on a preliminary version of the standard. At this point, the technology is not stable enough for widespread embedded systems adoption. What if the ratified standard changes from the current draft standards? How will deployed devices be updated? How interoperable are devices from different manufacturers? Until the 802.11n standard has been ratified and the technology has settled down, 802.11n is inappropriate for the vast majority of embedded applications.
Wi-Fi security features
Because Wi-Fi communications happen through the open air, Wi-Fi security is very important. There are two major components to Wi-Fi security: encryption and authentication. Encryption keeps the communications secret, and authentication ensures that only authorized users are allowed to access the network.
When most people think about Wi-Fi security, they first think about encryption. Because Wi-Fi authentication requires more network infrastructure, the vast majority of home networks only use Wi-Fi encryption. WEP was the first Wi-Fi encryption method and is widely deployed. Unfortunately, it has been thoroughly broken; WEP networks can be compromised in minutes. TKIP (in an unfortunate collision of jargon, this is also known as WPA encryption) was developed to replace WEP. It is considered practically secure and has wide support. CCMP (also known as WPA2 encryption or sometimes AES encryption) is another encryption method that was developed using best security principles. CCMP is widely supported for consumer devices, and its presence is growing in the embedded sector. At this point, any Wi-Fi platform being evaluated for new embedded development should support all three encryption methods. Figure 1 shows the relative security of 802.11 encryption standards
Wi-Fi authentication is more complex. With encryption, there are only three major methods to choose from. With authentication, there are dozens (thus proving the old adage “The great thing about standards is that there are so many to choose from”). Fortunately, usage seems to be converging on just a couple of methods: EAP-TLS and PEAP. These are the only two methods that Microsoft Windows supports out-of-the-box. If your embedded system needs to support Wi-Fi authentication, these methods should be supported. EAP-FAST and LEAP are also sometimes used. In general, the more Wi-Fi authentication methods supported, the better. Note that, when reviewing data sheets, Wi-Fi authentication could be referred to as 802.11i authentication, WPA or WPA2 authentication, or 802.1X authentication. Be sure to ask your Wi-Fi manufacturer which authentication methods they support.
How do you know if your embedded Wi-Fi application needs to support Wi-Fi authentication? If you're in control or can specify the Wi-Fi network that will be used, you might not need authentication support. Encryption support could be enough. However, if your device needs to be incorporated into arbitrary Wi-Fi networks (especially corporate Wi-Fi networks), you'll probably need authentication support.
Note that support for Wi-Fi encryption and authentication with ad-hoc mode networks (that is, networks with direct device-to-device communication without an access point) is generally poor. This is not a condition unique to the embedded world; support is spotty everywhere. For this reason, you should consider only infrastructure mode (with an access point) if you need Wi-Fi security.
Regional certification of your Wi-Fi device is a very important consideration. As intentional radiators, Wi-Fi devices must be qualified by regulatory agencies for specific regions. In the United States, the Federal Communications Commission (FCC) must qualify the device. If the solution you're using is a boxed product (such as a serial-to-Wi-Fi device), it's pretty simple–the device needs to be certified for the regions in which you're interested. If you're integrating a core module or other device into your product, it's a bit more complex. Ideally, you would want the module certified in such a way that you won't need to certify your product. Fortunately, most regulatory agencies have a form of modular certification that allows just this.
In any case, the manufacturer of your embedded Wi-Fi solution should be able to handle the certification issues. Your main concern is that the device is certified in all regions in which you want to sell your product. You want your device's Wi-Fi certification to ride on that of the Wi-Fi device manufacturer. Doing your own Wi-Fi certification testing is complex and expensive, so you want to avoid this if at all possible. Furthermore, the software or firmware for the embedded solution needs to provide ways to set the current regulatory region. This involves changing which Wi-Fi channels are available for use as well as the maximum transmit power; some software allows you to simply set the region which will automatically configure the allowable channels and transmit power.
Another option for configuring a device to conform to regional regulations is to use functionality provided by the IEEE 802.11d specification. This allows access points to broadcast the local regulatory domain so that a Wi-Fi client can automatically detect this and comply. If your devices will be deployed in many different countries, then 802.11d support is desirable although not strictly necessary.
The type of Wi-Fi network (such as 802.11b or 802.11g) can give you a rough indication of the performance of a Wi-Fi device, but just because a device has a theoretical data rate of up to 54Mbps does not mean it will achieve that performance. First of all, typical throughput for any Wi-Fi device is usually less than half that of the maximum data rate. Furthermore, embedded devices tend to have lower performance than, let's say, notebook computers. Therefore, it's important to determine, whether through asking the manufacturer or your own benchmarking, the maximum typical throughput that you can expect. This number will vary widely depending on the embedded solution you choose. Serial-to-Wi-Fi devices would typically have lower throughput just because the data must first be stuffed through a serial connection. But even integrated Wi-Fi solutions could have relatively low performance. Check with your solution provider.
Furthermore, some of the security options you choose can affect your performance. Enabling encryption will usually adversely affect your throughput, sometimes by an order of magnitude or more. In general, operating without encryption is fastest. WEP and TKIP/WPA, which both use the relatively simple RC4 encryption, are next fastest. And CCMP/WPA2, which uses the relatively complex AES encryption engine, is the slowest. This may not always be true–some systems include AES hardware acceleration, which could make CCMP encryption faster than WEP or TKIP encryption. Again, check with your manufacturer for benchmarks or perform your own benchmarks.
Unlike encryption, Wi-Fi authentication does not typically affect your data throughput. It does, however, affect how long it takes your device to join the Wi-Fi network. The amount of time it takes to join the network is largely governed by the CPU performance and the size of the certificates' keys. With large keys (2,048 bits or 4,096 bits), the process of joining a Wi-Fi network could take tens of seconds or even minutes. If your device will spend most of its time off but needs to quickly join a network and begin communicating, you should consider how authentication could affect your startup time.
Wi-Fi was not designed to be especially frugal with its power usage unlike other wireless technologies like Bluetooth or 802.15.4 (used for ZigBee). However, many Wi-Fi applications, especially handheld, require a leaner power profile. Your manufacturer should be able to provide data on power usage. The problem is determining how to interpret it.
You will want to know how much power the Wi-Fi device uses when transmitting, which should give an idea of the upperbound. Some typical values would be around 300 to 500 mA at 3.3V. You will also need to know how much power it uses when the Wi-Fi interface is idle. If the idle number is greater than what you need, you might still have some options. Some embedded Wi-Fi devices allow you to turn off the Wi-Fi subsystem when not in use. For applications that perform some data collection and then periodically upload the data over the Wi-Fi network, this could be an acceptable solution. However, if the device needs to be remotely accessible at all times, this would clearly not work–what if it is off when somebody tries to access it?
To help address this, the 802.11 specification includes support for power-saving features. Devices can notify an access point when they are entering power-down mode. The access point will then buffer any data destined for that device. Once the device powers back up, it notifies the access point and can then receive any buffered data. Typically, a device is only down for about 300 ms before checking back in with the access point. Many Wi-Fi devices that quote lower power-usage figures use this power-saving method. Your device will always be accessible remotely, but when the network is otherwise quiet, it can save some more power. Note that there is no guaranteed level of power saving–if network traffic to the device is heavy, the power saving will be much less. Check with your manufacturer to determine if this feature is supported–be sure to ask specifically if the power saving in the 802.11 specification is supported.
You'll probably want to consider a few more factors. First, is the range provided by the embedded solution similar to that of other Wi-Fi devices? Many Wi-Fi devices are said to provide a range of about 150 meters outdoors, less than 50 meters indoors. However, so many factors determine your range that a simple number is inadequate. Unfortunately, your best bet is probably to perform your own testing. Does the device perform equivalently to a notebook computer? A PDA? A competitor?
Another consideration is the operating temperature of the Wi-Fi device. Some components used in the Wi-Fi design may not be specified to full commercial or industrial temperatures. Just because the Ethernet version of a device meets the temperature specification you're looking for does not mean that the Wi-Fi version will.
Wi-Fi often requires the placement or positioning of some sort of antenna. What options does your solution provide? Is there an internal antenna? If so, does it provide satisfactory performance (particularly with the range)? If the antenna is external, are you allowed to use an antenna of your choice? Wi-Fi devices are generally certified for use with specific antennas; use of other antennas could be a violation of local regulations. If you need to use something other than your manufacturer's standard antenna, check with them about your options. They might have other qualified antennas for use with their products.
Finally, you might need to consider how the Wi-Fi device performs when roaming from one access point to another. For infrastructure mode networks, multiple connected access points are often used to canvass a larger area than a single access point could cover. Some embedded devices might “lock on” to a single access point, even when another access point becomes a better choice. Ideally, a device would be able to switch from one access point to another very quickly with minimal interruption in communication. Although you can ask your manufacturer how they handle roaming, this is another instance in which you should perform your own testing.
Owen Magee is a project manager at Digi International in Davis, California. He has also worked as a software engineer with Rabbit Semiconductor and a network administrator for Auburn University. He has a BS in computer science and mathematics and an MS in computer science from the University of Alabama in Huntsville. He will speak on behalf of Digi at the upcoming Embedded Systems Conference in Silicon Valley on the topic of wireless during the “Security in a Wireless Embedded World” seminar.