Beware of Wireless Impairments!

By Jim Geier

When creating mobile wireless applications, many software developers don't spend enough time thinking about the pesky impairments that wireless networks offer. The prevailing thought is that the Linux or Windows operating system will take care of any issues with the network. Wrong! Limited throughput, spotty coverage, and radio interference are a few of the problems that will wreak havoc unless you include special countermeasures in your design.

Wireless LAN protocols, for example, induce much more overhead into the transfer of packets than wired networks. In contrast to Ethernet, an IEEE 802.11 ("Wi-Fi") wireless LAN client device or access point receiving a packet must always send an acknowledgment to the sending party if no errors are found in the frame. This is necessary because the sender has no way of discerning if the packet made it through the channel without errors.

In addition, hidden nodes can cause substantial collisions in wireless networks. This occurs when Station A and Station B are sending data to a common destination, and neither Station A nor Station B can hear each other to facilitate taking turns using the air medium. The resulting collisions require both stations to retransmit their data. This problem feeds upon itself with a greater number of active stations. The additional retransmissions that result from the increasing numbers of collisions cause more retransmissions, and so on.

This additional overhead of acknowledgments and retransmissions significantly reduces the available throughput, which is the transfer rate that you can count on when moving real information. An IEEE 802.11b wireless LAN, for example, may deliver 11Mbps connections, but this is the rate that a station will transmit an individual frame of data. After factoring in the overhead, the resulting total throughput is at best 5MBps. In fact, the total throughput decreases even more as the number of active stations increases. So, don't count on having applications send data at 11Mbps continuously through the network!

As a developer, you should conserve bandwidth when sending data over a wireless network. Start by streamlining the transfer of information. For example, combine smaller data packets into a single larger packet to avoid the extra overhead that each packet requires. This could backfire on you, though, if significant radio interference is present. Larger packets take longer to transmit, which makes them vulnerable to errors that may result from interference. It is possible, however, to utilize mechanisms that adapt to the presence of interference.

Take advantage of compression algorithms at the transport layer to help minimize the number of bits sent over the wireless link. Some implementations of wireless middleware use header compression, where mechanisms replace traditional packet headers with a much shorter bit sequence before transmission. This is suitable for most scenarios. However, it often reduces interoperability because of fewer adherences to standards.

Another big issue with wireless networks is that you can't see where radio waves go. 

Some companies do a great job of identifying the optimum location of access points through effective site surveys. The goal is to provide complete coverage in all areas where users may roam. Other companies don't do very well at this. In numerous situations, coverage of wireless LANs and WANs is not continuous. Transmission may be unexpectedly cut at midstream at any time a user moves to an area where a coverage hole exists.

This always reminds me of one of my first consulting gigs. A company in sunny Florida was having strange errors occurring in a database that was part of an application hosted on an IBM AS/400. Warehouse clerks were using hand-held data collectors equipped with a bar code scanner, 5250 terminal emulation, and a wireless LAN interface to perform inventory management functions in a warehouse. The database errors were intermittent (the type of problem that's not fun to solve), but the troubles were obviously stemming from the inventory application.

After spending several hours troubleshooting the problem, I found that users would sporadically lose wireless connectivity. In some cases (specifically when the errors were occurring), the connection would go down when the user was in the middle of an inventory function having multiple transactions with the database. When a connection was lost, the user would reposition the data collector to gain adequate signal strength again. The user would also have to log back into the system, resulting in a partial completion of a particular function with records undone in the database.

Your mobile software must incorporate an intelligent restart as a recovery mechanism that detects the premature end of a series of transactions. After re-establishing the connection, the application must resume from the break point. Also, avoid posting a transaction to the database unless the entire series is complete.

Radio devices (such as cordless phones, microwave ovens, and other nearby wireless networks) cause interference that can also negatively impact mobile wireless applications. The interfering signal will either cause wireless clients to hold off from transmitting data or induce errors in data frames that prompt retransmissions. In either case, indefinite data transfer delays will persist. As with spotty coverage, ensure that your application software can drop connectivity from time-to-time and restart where it left off when the connection is back.