Jim is an independent software consultant in Atlanta, Georgia, specializing in the development of embedded and application software for mobile computing devices. He can be contacted at jywilson@ ieee.org. Jason is an independent software and hardware consultant, also in Atlanta. He specializes in the design and development of embedded communication software and hardware. He may be contacted at [email protected].
Bluetooth technology is an open specification for wireless communication and networking between PCs, mobile phones, and other devices. The Bluetooth SIG, a computer/telecommunications consortium originally consisting of Ericsson, IBM, Intel, Nokia, and Toshiba (but now joined by nearly 1200 other companies, including Microsoft, Lucent, Motorola, 3Com, and others), is responsible for defining and promoting the specification. At this writing, the most recent version of the spec, Bluetooth Specification Version 1.0 B, is available at http://www .bluetooth.com/.
In the first part of this two-part article, we will explore the basic nature of the Bluetooth specifications, with particular focus on how best to approach the daunting task of absorbing its many pages. We will discuss Bluetooth frequency-hopping technology, which acts as the basis for its utilization of the 2.4-GHz ISM band. We will also present the overall organization of Bluetooth as an impromptu or ad-hoc network, as we explore the operation of the Bluetooth link layer. In Part II, we will build on this foundation and probe the inner workings of the network from the perspective of the Baseband protocol.
As an aside, Ericsson, the principal innovator of Bluetooth technology, borrowed the name "Bluetooth" from King Harald Bluetooth of Denmark, who lived from 910ad to 940ad. Unlike his Viking counterparts, King Harald had dark hair (thus the name Bluetooth meaning a dark complexion) and is credited with bringing Christianity to Scandinavia along with uniting Denmark and Norway. Perhaps the name Bluetooth will bode well for a technology that promises to unite many dissimilar devices with low-cost wireless communications.
Bluetooth Standards Documents
The Bluetooth standards documents are divided into two distinct groups -- Core and Profile. The Core Bluetooth documents describe the implementation of the various aspects of Bluetooth technology, beginning with the radio transceiver and gradually building to a specification of the various layers of the protocol. Other topics are also covered, such as interoperability requirements with related technologies, testing requirements, and a definition of various Bluetooth timers and their associated values. At over 1000 pages of documentation, the Core Specification pretty much contains the sum of Bluetooth knowledge developed by numerous contributing companies and their hardworking engineers.
Once armed with the information contained in the Core Specification (a process we will discuss later in this article), you might be asking yourself "what would I do if" questions, where your primary concern is how to use the technology for your particular application. The Profile Specifications address these questions by taking what has been thoroughly specified in the Core Documents and defining various usage models. Each Profile Specification illustrates how specific Bluetooth technology defined in the Core Specification would be applied to the implementation of the usage model. This often includes a description of which aspects of the Core Specification are mandatory, optional, or simply not applicable. In many cases, it is necessary to define a profile in the context of another profile. In such cases, the mandatory, optional, and not applicable elements of other Profile Specifications would also be defined.
The primary objective of a Profile Specification is to establish a standard for interoperability between devices claiming compliance with the same Profile Specification. This way, when consumers purchase a Bluetooth-enabled device, they will know which Profile Specifications it is in compliance with (perhaps appearing as a logo printed on the product packaging), allowing them to verify that their existing Bluetooth devices provide an implementation of the same Profile Specification and are therefore, interoperable. This assures potential buyers of a particular Bluetooth-enabled device of successful communication between devices from different manufacturers. Considering that the rate of adoption of any interconnect technology is directly proportional to its degree of interoperability, this is a laudable goal. You need only try to transfer a contact from a Windows CE device to a PalmOS device using their mutually IrDA-compliant ports to discover why this is so.
As you build your understanding of the Profile Specifications, you may notice that each profile falls into one of two camps -- either the "cable replacement" camp or the "wireless audio" camp. The cable replacement profiles focus on providing a convenient, if not totally unconscious, way to transfer data between devices in proximity. When a device wanders into the range of another device, they would transparently query each other for a common profile. This might then cause the end users of each device to be alerted, or simply initiate a silent transfer of data as might occur in the synchronization of PIM data.
The wireless audio profiles provide a means for establishing a short range exchange of digital voice data between two parties. You might, for example, want to originate a call using the land lines available in your home or office when your Bluetooth-enabled cell phone is in proximity to a gateway compliant with the Cordless Telephony Profile. Or you might want to use a Bluetooth-enabled headset for wireless, hands-free conversations using your Bluetooth-enabled cellular phone, both of which comply with the Headset Profile.
In our first few readings of the Profile Specifications, we struggled with the interdependencies between the Profile and Core Specifications. It is difficult to gain a deep understanding of a Profile Specification if you have not already examined the many other documents it references. If you read more than is required, however, you might find that your degree of retention is not as high.
How to Use the Specifications
To address this dilemma, we have included a Bluetooth "Reading List" in Figure 1. It begins with the reading of the same Core and Profile Specifications. Certain profiles exist as a foundation for the creation of other profiles and do not specify independently usable functionality. The General Access Profile, for example, provides a specification of how the Bluetooth baseband architecture, defined in the Core Specifications, should be used between devices that implement one or multiple profiles and is required for the implementation of all Profiles.
As you progress to the reading of the Profile Specifications, you will limit your reading to those that directly apply to your targeted Profile. This is depicted in Figure 1 as a diamond with a separation of the profiles into two groups: cable replacement and wireless audio. Shapes filled in red indicate those documents that should be read carefully, and if necessary, reread many times for a more complete understanding. Shapes filled in yellow need only be read once and are less likely to have a direct impact on your understanding of a particular Bluetooth profile. Shapes filled in green should be skimmed, just to be certain that you are aware of the topics that a particular document addresses. This is not to say that, at some point in your growing understanding of Bluetooth technology, you will not read all of the specifications. This will just help you get started as you scope the overall software effort for your Bluetooth device.
Frequency Hopping
A Bluetooth radio operates in the unlicensed ISM band at 2.4 GHz and uses a frequency-hop transceiver to combat interference and fading. This band is then divided into separate RF channels, each with a 1-MHz spacing. The number of RF channels you can fit into the U.S. ISM band, which is 83-MHz wide, is 78; while the band available in most other countries is smaller and is therefore limited to 22 channels. Frequency hopping occurs by jumping from one RF channel to another in a pseudorandom sequence. This hopping sequence is collectively referred to in the Bluetooth Core Specifications as a "channel," not to be confused with the RF channels that comprise the Bluetooth Channel and its associated hopping sequence.
Slots
A Bluetooth Channel is comprised of a defined hopping sequence where, for a period of time, the Bluetooth radio operates at a particular radio frequency in the 2.4-GHz ISM band. A radio operating in a particular hopping sequence will transmit or receive on a particular frequency at a particular moment in time. Bluetooth requires the radio to remain on each frequency in its hopping sequence for a period of 625 microseconds. Each 625-microsecond time period is assigned a number ranging from 0 to 227-1 and is considered a "slot" in Bluetooth parlance.
Bluetooth radios communicate with each other using a Time Division Duplex (TDD) scheme, whereby one radio transmits on even slots and the other on odd slots. Transmission of a data packet is guaranteed to start at the beginning of a slot, with different types of packets extending over one or more slots. If a particular type of packet is a multislot packet, the radio remains at the same frequency until the entire packet has been transmitted. In the next slot, after the transmission of a complete multislot packet, the radio returns to the frequency required for its particular hopping sequence. This process is shown in Figure 2, where k designates the slot number over each 625-microsecond time period.
Network Topology
In an Ethernet network, packets may be transmitted from any node in the network to any other node in the network. There are no defined master-slave roles in the Ethernet link layer, except those enforced by the application layer software. In this regard, Bluetooth is quite different.
As a short range wireless technology, the invisible wires of a Bluetooth network must effectively be constructed from its channels. This requires the determination of the channel (hopping sequence) and phase (timing offset) that shall be used by all radios that need to communicate. The radio designated as the master makes this determination using its own device address, while all other radios that wish to communicate with the master radio must be configured to the same channel and phase, and are designated slaves. There may be at most seven active slaves, and they may only communicate when granted permission from the master, thus creating a kind of tightly controlled meeting where only those recognized may speak. This meeting, in Bluetooth parlance, is called a "piconet."
A slave radio participating in a Bluetooth piconet is also unable to communicate directly with other slaves in the piconet. It is, however, able to participate in other piconets in proximity. It may do so functioning as a slave or as a master of its own piconet. This form of overlapping piconets is called a "scatternet;" see Figure 3. The radio functioning as a slave in one piconet and as the master of its own piconet appears as a circle with the symbol "M/S."
During asynchronous communications with the master, the slave may only send a packet to the master when it has received a packet (one exception exists that will be discussed in Part II of this article). This process is shown in Figure 4, where the packets appear as boxes between the dotted lines marking the boundaries of each slot. When the master sends a packet to a particular slave, as denoted by the arrows, using an even-numbered (master-to-slave) slot, the slave may respond in the next odd-numbered (slave-to-master) slot. When a slave receives a packet addressed to another slave in the piconet, it simply ignores it. In synchronous communications, the slave is allowed to communicate with the master without permission, using its reserved slave-to-master slot.
Baseband Protocol
Figure 5 illustrates a complete Bluetooth protocol stack. The Baseband Protocol is the lowest layer and is responsible for establishing the physical link between the master and slave radios. The Baseband Specification (one of the Core Specifications) defines two link types -- Synchronous Connection-Oriented (SCO) links and Asynchronous Connection-Less (ACL) links. SCO links are used primarily to exchange time-bounded data requiring guaranteed bandwidth, but without guaranteed delivery. One example of data requiring an SCO link, used in many Bluetooth profiles, is digitally encoded audio data with built-in tolerance to lost data. The guaranteed bandwidth of an SCO link is achieved through a reservation of a particular number of slots in the Bluetooth Channel, and is analogous to a circuit switched connection in the POTS network. The SCO link is established point-to-point, between a master and slave radio, with a maximum of three links maintained by the master to the same or different slaves. The slave may maintain a maximum of two SCO links if connected to different masters, or three links if connected to the same master.
ACL links provide a packet-switched, point-to-multipoint connection between the master and all of its slaves. Unlike an SCO link, no bandwidth reservation is possible and delivery is guaranteed through error detection and retransmission. Only one ACL link at a time may exist between a master and slave, though the master may broadcast a packet to all of its slaves using an address of 0. All active slaves in the piconet receive the packets transmitted by the master, but are able to respond in the subsequent slot only when the packet is specifically addressed to them (refer to the previous discussion of Network Topology for more information).
The ACL and SCO links are, of course, the result of an underlying packet infrastructure, which is the subject of the Baseband specification. The packet structure and type, transmit timing, and channel control states are all covered in the Baseband specification, making it the most daunting of all the Core Specifications to absorb. An understanding of this specification is essential, however, to a complete understanding of all other Core and Profile Specifications, so this will be our primary focus in Part II.
Link Manager Protocol
The Link Manager Protocol (LMP), the next level up from the Baseband Protocol, interacts directly with the Link Controller (LC), which is the device implementing the Baseband Protocol. The messages defined in the LMP are exchanged between a master and slave and are not passed up to higher software layers. LMP messages are always sent as single slot packets with a 1-byte header, and they receive a higher priority than pending application data sent by higher layer software. It is the responsibility of the LMP software to differentiate packets containing application data from those containing LMP messages, and prioritize accordingly. How this differentiation is accomplished in terms of the structure of a Bluetooth packet will be discussed in Part II.
LMP messages provide an opportunity for further negotiation of the characteristics of a master-slave connection, previously established when the slave radio synchronized to its master's Bluetooth Channel (hopping sequence and its associated phase) using the Baseband Protocol. An LMP message exchange can also result in the termination of a connection if the negotiation fails or if either radio is unauthorized for participation in the piconet. If, for example, the master requested the formation of a synchronous connection (a type of connection that provides guaranteed bandwidth) for the exchange of voice data, the LMP messages in Figure 6 would be exchanged.
The first LMP message specifies timing, packet type, and the coding of the packet data payload. The next message contains the reply from the slave indicating acceptance (or refusal) of the requested synchronous connection. LMP messages are always sent as single slot packets.
Logical Link Control and Adaptation
The packet-switched network defined in the Baseband specification provides no mechanism for packets that exceed the maximum length of the data payload of the largest multislot packet (341 bytes). Enter the Logical Link Control and Adaptation (L2CAP) layer. It is responsible for the segmentation and reassembly of higher level packets originating in OSI layer 3 and above protocols, such as TCP/IP or RFCOMM (a Bluetooth Core Specification providing serial port emulation). It also provides protocol multiplexing, enabling simultaneous access by higher layer protocols that share the single master-slave connection provided by the Baseband Protocol.
Various types of communication with remote devices occur through the use of logical channels. (Try not to confuse this reference to the term "channel" with the Bluetooth Channel or the RF Channel used in the Baseband specification.) Bidirectional, connection-oriented communication is provided, along with unidirectional, connectionless communication used to associate a single channel ID with a group of remote devices. Support for Quality of Service (QoS) is optionally included through the use of a flow specification (similar to that specified in RFC 1363) that is exchanged with the remote device during channel configuration.
Just the Beginning
We have really only just scratched the surface in our exploration of the Bluetooth technology described in the Core and Profile Specifications. Most notably, the Core Specification also includes the definition of a standard interface for the lower layers of the Bluetooth protocol stack, called the "Host Controller Interface." This interface is defined for RS-232, USB, and PC Card transports, and provides a command-oriented mechanism for communicating with Bluetooth hardware implementing the Baseband and Link Manager Protocols. Other protocols are defined in the Core Specification for serial port emulation (RFCOMM), service discovery (Service Discovery Protocol), and call control signaling (TCS Bin). As if that were not enough, the Bluetooth consortium also included documents defining interoperability with existing communications technologies, such as IrDA and WAP. Test modes are also defined for Bluetooth hardware in an attempt to standardize the testing functionality offered by various vendors of Bluetooth chipsets. Of course, the definitive references for all this information are the specifications themselves, which may be freely downloaded from the Bluetooth web site at http://www.bluetooth .com/.
Overall, the Bluetooth specifications are impressive. It is rare to find such an exhaustive, all-encompassing set of documents developed in the first version of a communications protocol. In Part I, it was our mission to chart a course through this voluminous document. In Part II, however, we will focus more closely on the features of the Baseband specification.
DDJ
