The IEEE 802.11 Wireless LAN, or Wi-Fi as it has been branded, has evolved over the years, and continues to evolve. One of the early milestones in its path was the addition of operation in the 5 GHz segment of the license-free ISM bands. The move was based on planning for the ability to increase network capacity, reducing interference, and providing better quality of service, with the anticipation of the 2.4 GHz band becoming crowded. However, the 2.4 GHz band continues to be preferred, given its advantages, real or perceived, of lower cost, better coverage, and widespread interoperability. In this article, we look at how operation in the 5 GHz band would stimulate the rapid adoption of Wi-Fi based RTLS and M2M systems.

The Wi-Fi market has grown as fast as or faster than projections the past several years. Almost a billion devices were shipped in 2011; and in 2020, the estimate is for 50 billion devices. In addition to the traditional applications – laptops, mobile phones, and the variety of handheld computing devices popular today – a new wave of Wi-Fi adoption in M2M (machine-to-machine) communications, RTLS, and for cable replacement are expected to fuel this growth. It is interesting to note that it is the proliferation of Wi-Fi for basic data connectivity that has enabled this. Today, Wi-Fi networks are deployed in a variety of areas – homes, offices, hospitals, public places, factories, warehouses, with increasing demands on coverage and capacity.

Some common characteristics of M2M communications are the transfer of relatively smaller amounts of data over infrequent intervals, automated connection establishment, data security and the ability to integrate into the enterprise network with no additional load than their own communication needs. Wi-Fi provides for these; and Wi-Fi is a key technology in RTLS systems, enabling the locating and tracking of assets as well as providing for communication with the deployed devices or ‘tags.’ Tags are usually battery operated and therefore battery life is an important consideration. The IEEE 802.11 standard provides for ways to conserve energy – tags use these to the hilt and then their own methods based on their design and application.

A crowded spectrum influences deployment and operation in many ways:

• Accommodating larger numbers of devices in a wireless network often requires the network coverage area to be shrunk. This is so that nodes may use higher data rates, occupying less time on air individually.
  The network would be preferred to be all 802.11n rather than a mix of legacy 802.11a/b/g and 802.11n capable. An otherwise all 802.11n network would suffer a significant drop in network capacity even with the addition of a single legacy 802.11b/g node joining it.
• Quality of service in data transfers is often not met, reducing the overall user experience, and limiting the applications that can run over the network.
• Most significantly, the expected battery life of devices reduces drastically in a crowded environment.

RTLS systems use one or more of several techniques to determine the location of a tag. Well-known methods are ranging through measurement of RSSI (received signal strength indication) at either the tag or at a reader or access point; and measurement of transmission delay and ranging through the TDOA (time difference of arrival) method. In either case, a Wi-Fi based tag carries out at least one of these two functions:

1. The periodic transmission of valid WLAN frame for access points or other units in the vicinity to receive and measure for RSSI or time of arrival
2. The periodic scanning of the frequency band to gather beacons from access points in the vicinity and to measure their RSSI, and to make this information available to a location measurement system.

Because these measurements take place periodically, with separations of several seconds to several minutes, the Wi-Fi tags use a power-save scheme to conserve battery life taking advantage of the available power profiles in their hardware.

The typical operational profile of a WLAN device is shown in the figure below. Since the 802.11 standard provides for a station to go to a sleep state and wake up periodically to listen to beacon information from the access point or to transmit data after announcing the exit from its sleep state, most station devices are implemented with a standby mode where no active transmission or reception can take place, but the connection state is preserved and a timer or other mechanisms available to wake up the device at the required time. Wi-Fi RTLS tags utilize this feature and also other profiles where the device can be put into an even lower power ‘off’ state only to be woken up periodically and go through the process of acquiring the required operational state. This transition may involve loading in of firmware, initializing internal blocks or external devices, and if necessary scanning the channel prior to establishing a connection.

The figure below depicts a typical operational profile of a Wi-Fi based RTLS tag. In this example, the tag is set to send out beacons every 10 seconds. During the quiet interval, it is configured to be in a very low power sleep state. Upon wake-up, the tag sends out beacons in the programmed channels and with the programmed repetition. A tag sends out multiple beacons in order to minimize the chances of the beacons being missed by the APs in the vicinity. A typical Wi-Fi tag in this scenario powered by a 1200 mAh battery would be able to remain operational for more than three years.

This estimated battery life is based on an assumption that the tag is able to beacon out at the programmed intervals. Between two beacons, the tag is in a receive or listen state, monitoring the channel and looking for an opportunity to transmit. When there is little or no other traffic on air, the tag would be able to adhere to a predetermined timing of transmission. Battery life computation is usually based on this ideal scenario.

When the channel is occupied with other WLAN activity, the tag is forced to wait longer intervals for an opportunity to transmit. The figure below depicts such a scenario.

The designed battery life of a tag is computed from the configured operational scenario, which would vary according to tag type and application. Default computation of tag life assumes a fairly clear channel. For comparison, and for comparison we take a busy channel where average wait time (due to packet activity on air) is about 2 ms and where on average 40% of attempts to transmit result in back-off due to on-air activity.