Media Net Link

High Wire Acts, Without a Wire - A Bluetooth Primer

In one of his routines, comedian George Carlin mimics a reporter interviewing Alexander Graham Bell about his latest invention (I paraphrase):

Reporter: "Where are you going to put all these phones?"
Bell: "I'm going to put them everywhere!"
Reporter: "And how will you connect them all?"
Bell: "With wires! Lots and lots of wires!!"

The telephone wasn't the first electronic appliance to require more wires, and there have been many more since then. Wires are the bane of our electronic existence, one price we pay for the convenience electronic devices provide. There are always too many of them, and they are always too tangled, too messy, too short or too long. Worse yet, they all have plugs at either end that must be connected to the right sockets--and stay connected--to function. Worst of all, though, is that they make it difficult to share peripherals among multiple devices. The bottom line is that wires are the
enemy.
Fortunately for us, we have new battery and radio frequency (RF) technologies that enable wireless devices. Bluetooth is one of the latest such RF-based digital technologies.

What is Bluetooth?
Bluetooth is a short-range RF communications system designed to replace the wires ("cables") between portable or stationary electronic devices and their components, providing about 1Mbps of throughput. Its "short-range" essentially limits usage to devices located within a single room or vehicle. Within that limited scope, Bluetooth provides a robust, flexible, secure, efficient, low power, and low cost network communications medium.

The Bluetooth Core System consists of an RF transceiver (a radio), a 2.4 - 2.483 GHz baseband, and a protocol stack. It provides a development platform that can accommodate virtually any type of point-to-point application. In theory, any application that would otherwise use a wire of up to ten meters in length is suitable for replacement with Bluetooth. This includes all the Internet Protocol (IP)-based applications that can run over wires of any length-and over other wireless networking technologies.

The multi-vendor Bluetooth Special Interest Group (SIG) created and maintains the Bluetooth standards (see bluetooth.org). They defined the Bluetooth Core System of protocols and adopted existing standards from IETF, ETSI, ITU and other protocol standards bodies. They also defined "profiles" that detail Bluetooth service requirements. As we describe shortly, the Bluetooth profiles target common "short-wire" applications.

Who is Bluetooth?
The name has less to do with the technology than you might expect. The name Bluetooth refers to the 10th century Danish King Harald Blatand, a.k.a., Harold Bluetooth. He is credited with having united warring factions in parts of what are now Norway, Sweden and Denmark. Hence, the name is relevant to the technology only insofar as it is a interoperability standard for devices manufactured by competing Bluetooth vendors.

Bluetooth vs. WiFi
(Wireless Fidelity) refers to the IEEE 802.11 standard for RF-based wireless networking, commonly used to support Internet Protocol (IP) applications on laptop and desktop computers, among other things (see wi-fi.org). Anyone familiar with WiFi might consider Bluetooth redundant, but its differences complement rather than compete.


WiFi and Bluetooth both operate in the 2.4 GHz RF range, both utilize Frequency Hopping Spread-Spectrum (FHSS) technologies, both provide "discovery" services to find peers, and both provide authentication and encryption security services. The similarities end there, though.

WiFi is designed as a Local Area Network (LAN) technology, but Bluetooth has a smaller scope. It is intended for use on a LAN portion, a PAN (Personal Area Network), so to speak. A WiFi LAN may provide communications between devices located anywhere throughout an entire building, all the rooms in a house, for instance. Bluetooth, on the other hand, only provides communication between devices in a single room. WiFi is typically limited to distances up to about 100 meters, whereas Bluetooth is typically limited to about 10 meters. The PAN and LAN contrast with the Wide-Area Network (WAN),
which is the Internet itself. These amount to concentric network domains, as illustrated in Figure 1.

Since Bluetooth and WiFi share the same 2.4GHz frequency range, they can potentially interfere with one another. However, Bluetooth has an insignificant affect on WiFi due to its low power and WiFi has no noticeable affect when Bluetooth devices are within two-meters of each other.

Bluetooth Protocol Stack
The Bluetooth Protocol Stack comprises several parallel protocol stacks and a variety of application programming interfaces (APIs). Different applications use different stacks, though all applications use the low-level Bluetooth Core Protocols (pictured in blue in Figure 2): the Logical link Control and Adaptation Protocol (L2CAP), Service Discovery Protocol (SDP), Link Management Protocol (LMP), baseband and Bluetooth radio.

For example, legacy Internet Protocol-based applications-those that use the Sockets API, like WAP (Wireless Application Protocol) and UPnP (Universal Plug'n Play)-run over the TCP/IP stack, as they normally would. Applications using OBEX (Object Exchange) or AT (modem control) commands access the RFCOMM (serial line emulation) layer. Applications using another variation of a UPnP stack and those using TCS (Telephone Control Protocol) Binary operate over the L2CAP layer. LMP and SDP do not have explicit APIs, but are controlled by the Baseband and L2CAP, which provide the Host Control
Interface (HCI).

Knowing how the Bluetooth Core protocols or the stack variations operate is not as important to application developers and end-users as simply knowing they provide a robust and secure network medium that can efficiently handle virtually any application. Much more interesting and relevant are the Bluetooth service profiles that define some of these applications.

Bluetooth Devices and Services
Application potential is the raison d'etre for network technologies like Bluetooth. As mentioned earlier, Bluetooth supports all IP-based applications and also defines a number of Bluetooth service "profiles."

In essence, profiles identify and prescribe discrete functions typically provided by various computer peripherals, audio/video system components, among other things. The great thing about wireless peripherals is they are not "tied" to one device, so may be "mixed and matched" ad hoc, as needed. This helps reduce "function redundancy."

As an example of function redundancy, consider how your computer has a pair of stereo speakers, your television has a pair and your music system has another pair, probably the best pair. You can typically wire the computer, TV and music system together so all three can share the best pair. Aside from the wiring issues, there is the question of whether they may share the speaker pair simultaneously and if not, how the current source is selected.

A better solution is to have a separate "speaker pair" device/service available for use by any or all three devices. Making the speaker pair a wireless device simplifies it even more. As a result any of the three may use the speaker pair.

A Bluetooth device is any implementation of–at the very least–the Bluetooth Core System. As such, it is a service consumer. A Bluetooth device that implements one or more Bluetooth profiles is a service provider.

There are a number of device classes:

The services are also categorized in classes:

There are no restrictions about which devices can host which service types. Most device/service configurations are intuitively obvious, but many non-intuitive combinations are possible and can create unique applications.


Bluetooth Profiles
A Bluetooth Profile defines a service-a Bluetooth application-and specifies its requirements in terms of Bluetooth protocol usage. The Bluetooth SIG has a number of work groups that focus on different application areas such as Audio/Video, Printing, and Still Image. Many profiles have been completed and implementations exist, others are still under development and many more are possible.

As illustrated in Figure 3-which shows many, but not all profiles-the profiles are organized in a hierarchical structure according to dependencies. Notice that all profiles comply with the Generic Access Profile, which defines requirements common to all Bluetooth profiles. It focuses on basic modes and operations like discovery, link establishment and security to ensure connectivity and interoperability between Bluetooth devices.

Notice that there are a number of other "Generic" profiles that define common requirements for subsets of relevant profiles:


Other profiles are generic in a sense too, because they characterize a class of services:

The remaining profiles are much more function-specific, such as:

Bluetooth Security
One good thing you can say about wires is that they are implicitly secure as a communications medium. Your data is safe with them! That is in stark contrast to any RF-based technology. By definition, wireless communications involves broadcasting on the airwaves, where anyone in range can receive. Hence, RF communications is inherently insecure.

The Core Bluetooth specification (currently v1.2) mandates a security implementation. Specifically, it requires explicit authorization from a user for any device pairing or service access, data encryption, and device authentication on-going during communications.

To minimize inconvenience, Bluetooth security imposes on users only during the initial pairing of two Bluetooth devices and in response to service access requests. During a pairing, the user is prompted to set a Personal Identification Number (PIN) of up to 16 bytes in length, which is used to generate the "link key." Paired devices use the resulting 128 bit link key to encrypt communications between them. Longer PIN values provide more secure encryption. The Bluetooth SIG strongly encourages pairing in a private place and the using robust PINs.

There are two types of link keys: unit keys and combination keys. A unit key is created by a Bluetooth device that uses the same PIN for all of its pairings. Combination keys are link keys that are unique to each pairing. Unit keys are less secure than combination keys, so they are only appropriate for devices with limited memory or a limited user interface. Only one device in a pair may use a unit key, to minimize exposure.

Bluetooth security operates only at the low-level data-link layer and does not preclude the use of any higher-level security schemes (e.g., IPSec, SSL, RSH) over Bluetooth.

Bluetooth and UPnP
Universal Plug'n Play (UPnP) is an open protocol standard that is similar to Bluetooth in many ways. Both standards were created by multi-vendor groups with platform independence and interoperability as primary goals. Both define protocols that provide a means for devices to advertise themselves and discover others in limited network domains. And both define a way to programmatically describe services-typically discrete functions-so devices from different vendors can interoperate.

Since the two technologies coincide as much as they do, it is possible to map UPnP to Bluetooth. The Extended Service Discovery Protocol (ESDP) profile describes three approaches to implementing UPnP within a Bluetooth system, as depicted in Figure 3. The first, for use by devices that lack IP support, runs over L2CAP. The other two run in a more traditional UPnP fashion over IP. In this case, the Local Area Network (LAN) Access profile is appropriate when the Point-to-Point Protocol (PPP) is used, otherwise the Personal Area Network (PAN) profile.

Although it is beyond the scope of the ESDP profile, the document also sketches a bridge device that would allow Bluetooth devices to discover and pair with UPnP devices, and vice versa.

Conclusion
It is finally time to say good-bye to wires. They have served their purpose, but Bluetooth can provide a solution that improves on them tremendously in terms of both form and function.

If there is one thing to know, it is that when buying a Bluetooth device, you should find out what profiles it supports. That way you can be sure it is appropriate for the application(s) you have in mind.

Now, if they could only define a profile for delivering power over Bluetooth, we could nix these battery changing and recharging issues…

Bob Quinn