Bluetooth 1.1 addresses earlier flaws

Imagine wireless connectivity that lets you effortlessly exchange business cards, files and other information with a co-worker. Or wireless technology that lets you set up your own personal-area network to link your PC to handheld devices, mobile phones, printers, scanners, fax machines and copiers. The new Bluetooth 1.1 specification promises to make such affordable wireless connections an everyday reality.

Bluetooth Version 1.0b failed to fully deliver on its promise as a result of unexpected interoperability issues. Bluetooth 1.0b defined specific functionality but did not mandate specific implementation criteria, leaving key parts of the specification open to interpretation.

As a result, interoperability problems arose and thwarted widespread implementation. When a Bluetooth cell phone from Vendor A does not work with a Bluetooth PC card from Vendor B, the user is not exactly encouraged to buy a Bluetooth printer from Vendor C. Fortunately, Bluetooth 1.1 addresses these interoperability issues.

---

How it works
Subscribe to the Tech Update newsletter
  Here is a weekly newsletter to help you stay abreast of new networking standards and technologies by providing down-to-earth explanations of how they work.

---

The most significant change to Bluetooth in Version 1.1 involves authentication. Bluetooth communications are encrypted for security. When two Bluetooth devices try to establish a link, one of the first things they do is exchange keys confirming their identities. If the keys don't match, the two devices won't talk to each other.

Under Bluetooth 1.0b, the two devices could get into an irreconcilable race condition during the initial link negotiation. The devices would execute the algorithm to generate the key, but each device would generate a different key. The problem revolves around timing.

Generating the correct key depends on which device initiates the conversation (the master) and how fast the responding device (the slave) replies to the master's communications. If the slave can process information faster than the master, the ensuing race condition can leave each device calculating that it is the master. Based on that error, the devices fail to generate matching keys.

Bluetooth 1.1 rectifies this problem by more thoroughly defining the steps required for device authentication. Specifically, Version 1.1 requires that each device confirm its role in the master/slave relationship by reconciling and/or acknowledging which device initiated interaction.

A more basic interoperability issue concerns the harmonization of frequencies. Bluetooth divides the 2.4-GHz frequency into 79 hops. Using a technique called frequency-hopping spread spectrum to transmit data, the master and slave must synchronize their movements up and down the 2.4-GHz frequency to maintain their connection. If they don't arrive at the same hop at the same time, the devices can't communicate.

Unfortunately, France, Japan, Spain and a few other countries use the 2.4-GHz frequency for noncommercial purposes, such as military communications. To accommodate these countries, Bluetooth 1.0b defined a second hop count that avoided select areas of the 2.4-GHz spectrum and divided the frequency into 23 hops. Devices built to work at 79 hops are incompatible with those built to work at 23 hops.

To address this problem, the Bluetooth Special Interest Group negotiated with the 23-hop countries to allow use of 79-hop equipment, which let Bluetooth 1.1 eliminate the 23-hop option. All Bluetooth 1.1 devices use 79 hops to communicate within the 2.4-GHz frequency.

Incompatible data formatting could also prevent interoperability in Bluetooth 1.0b devices. Bluetooth supports up to five slots per packet to reach its maximum data transfer rate of 720K bit/sec per channel. However, not all Bluetooth devices support five-slot packets. If a master tries to send more slots per packet than the slave can support, communications fail.

Under Bluetooth 1.0b, slave devices couldn't tell master devices how many slots could be used during communications. Bluetooth 1.1 fixes this problem by letting the slave communicate back to the master with information about the packet sizes. In Version 1.1, a slave can tell a master to send fewer (or more) slots per packet when necessary.

The Bluetooth 1.1 specification was finalized earlier this year, and vendors have begun shipping 1.1-compliant products.

---

Holtby is Bluetooth product manager at 3Com. He can be reached at Troy_Holtby@3com.com.

Breaking Bluetooth news