There’s a lot more to Bluetooth than being able to have a wireless earpiece for your mobile phone. For instance, Toshiba now markets a Bluetooth-enabled washer/dryer, microwave oven and refrigerator. The controlling Bluetooth ‘Home Terminal’ allows the devices to be controlled, new programmes downloaded and problems reported back centrally. The products are only available in Asia, unfortunately, under the bizarre brand of Femininity.

On a more mainstream level, there are a plethora of PC and PDA accessories, games devices and audio-visual equipment. All are designed to be easy to use and interoperable.

Interoperability is one of the major selling points for Bluetooth. It has to be possible to mix and match devices from different vendors and get them to talk to each other easily. But if a manufacturer has to carry out interoperability tests with every other Bluetooth device from every other manufacturer, and provide software that will support them all, it would all get far too cumbersome, slow to market and expensive for anyone to want it.

If you want to know more about the basic protocols of Bluetooth, read our guide to the Nuts and Bolts. If Bluetooth works, but your devices don't, read on here.

Profile architecture
Hence Bluetooth profiles - a set of specifications that define how the wireless transmission should work between devices for different user tasks. There are multiple profiles already defined, with more under way. Although there are some interdependencies between profiles, they are separate enough, that manufacturers can implement only the pieces relevant to each specific product. This keeps the development costs down, and - since each is a self-contained entity - makes testing for compliance a lot quicker.

Think of it a bit like the OSI 7-layer model (actually Bluetooth does follow this model, with its own set of protocols—we’ll cover that at a later date). If you’re writing a TCP stack or application (at layer 4), you know that it’ll run over the network, data link and physical layers, but as long as you write the part that interacts with layers three and five correctly, you don’t need to be too concerned about what goes on in the other layers - you rely on the underlying layers (or, in Bluetooth’s case, the underlying profiles) to fill in the rest, while anything that works at the higher layers doesn’t need explicit information about how your part works, just as long as the hooks that join it together match up.

Profile types
The foundation of all profiles, and one that must be supported by all Bluetooth devices, is the Generic Access Profile (GAP). This profile defines the generic procedures related to discovery of Bluetooth devices (idle mode procedures) and link management aspects of connecting to Bluetooth devices (connecting mode procedures). It also defines procedures related to the use of different security levels. It covers naming and addressing, and general discovery procedures. In theory, any two Bluetooth devices should be able to connect at a basic level, since they all support this profile, even if it’s just in order to determine that they don’t share any common services or applications.

All the other profiles ride on top of the Generic Access Profile and depend on it. Some of these profiles themselves have other profiles residing above them.

For example, above the GAP are the Intercom Profile, Generic Object Exchange Profile and Serial Port Profile. There’s nothing dependent on the Intercom Profile, but both of the other two have in turn other profiles that rely on them — the File Transfer and Synchronisation profiles for instance, won’t work without the Generic Object Exchange Profile. And the Serial Port Profile underpins several of the most common profiles, such as the Headset Profile, the Hands-Free Profile and the LAN Profile.

So, if you want to use your Bluetooth device to connect to the network, it will have to support the Generic Access Profile, the Serial Port Profile and the LAN Profile. But there’s no need for it to have any of the others (unless of course you want it to do other functions). Similarly, for a Bluetooth-capable phone and earpiece to work together, they both must support the GAP, SPP and Headset Profile. If that’s the case, then it shouldn’t matter which manufacturer they come from, just like it’s perfectly possible to get a 3Com NIC to talk to an Extreme switch port.

Other profiles currently standardised or underway include the ISDN Access Profile, Basic Imaging and Printing Profiles, Dial-up Networking and Fax Profiles and a Service Discovery Application Profile (service discovery is automatically carried out by many of the other profiles, but you can also manually force a discovery—a browse of the Bluetooth environment to see what’s out there from one of the Bluetooth analysers and test tools available that support this profile).

If they don’t have the correct profile support, it won’t work. Since they will probably have GAP support, they may well be able to discover each other, but they won’t be able to communicate at the proper level.

Most of the Bluetooth profiles appeared with the Bluetooth Core Specification version 1.1 (1.2 appeared at the end of last year). Since more profiles are constantly being added, the format of the spec has been changed so that the whole thing doesn’t have to be rewritten as profiles are added but can be updated just as required. You can get a copy of the spec from the Bluetooth SIG.

Bluetooth itself may be designed around ease of use, but the specification isn’t - you’ll get easier profile definitions at Palo Wireless's Bluetooth Resource centre.