Dr. Dobb's Journal April 2000
Bluetooth technology is an open specification for wireless communication and networking between PCs, mobile phones, and other devices. In the first part of this two-part article, we explored the Bluetooth specification, and discussed the basics of frequency-hopping technology, which acts as the basis for Bluetooth's utilization of the 2.4-GHz ISM band. This month, we'll build on that foundation and examine how Bluetooth network packets are used both to establish a connection and to query for available devices. To this end, we will begin with a whirlwind tour of certain aspects of the Bluetooth packet structure, then just when you are feeling overwhelmed by an assortment of new acronyms, we'll bring these packets to life and demonstrate their usefulness in Bluetooth link establishment.
The Bluetooth Baseband specification (along with all other specifications, available at http://www.bluetooth.com/) is the ultimate authority on such matters and we would encourage you to refer to it for more details.
Figure 1 illustrates the canonical structure of the Bluetooth packet. The row appearing at the top contains the names of the three major sections of all Bluetooth packets. The three rows below this provide a more detailed view of each block in the first row with matching colors. The packet presented is structured as a single slot packet (a concept explored in Part I of this article) with a type of address called an "Active Mode Address."
The Access Code is the first part of most Bluetooth packets (the exception being the FHS packet used in connection setup and when two radios switch master slave roles), and is encoded so that it can simultaneously serve different functions. The preamble of the Access Code consists of a series of alternating 1 and 0 bits, either 1010 or 0101 (depending on the value of the least significant bit in the Synch Word, which follows) and is used for DC compensation. The trailer, like the preamble, also contains a series of alternating 1 and 0 bits depending instead on the value of the most significant bit in the Synch Word that precedes it.
The Synch Word contains a value derived from a 24-bit address, often referred to in the Baseband Specification as the Lower Address Part (LAP). This 24-bit address is actually the first field, hence the term Lower Address Part, of the 48-bit address assigned to each Bluetooth radio. There are also reserved LAPs, however, which are used only for certain types of Access Codes. The derivation of the Synch Word requires that additional values be XORed with the LAP, improving the autocorrelation properties of this value. Considering the focus of this article on the Baseband protocol, autocorrelation is not discussed further. Suffice it to say, it is important to the signaling characteristics of the radio.
There are three basic types of Access Codes: the Device Access Codes (DAC), Channel Access Codes (CAC), and Inquiry Access Codes (IAC). Each type of Access Code is used for different operational states and procedures in the Bluetooth radio. The CAC, as the name implies, characterizes the channel used by the master/slave radios communicating in an established piconet. The DAC is used in the Access Procedures that allow the radios to form a connection, while IAC is used in the Inquiry Procedures to find radios in RF proximity.
Whereas the Access Code of a Bluetooth packet is dedicated to the support of signaling between radios, the Header provides support for the control of Bluetooth physical links (synchronous connection-oriented (SCO) links and asynchronous connectionless links (ACL)). The header consists of six distinct fields, each of which are represented in Figure 1. We will limit our discussion to the two fields most important to link control -- the AM_ADDR field and Type field. (Refer to the Bluetooth Baseband specification at http:// www.bluetooth.com/ for information on the other fields.)
A Bluetooth piconet represents a group of at most seven active slave radios, synchronized to a single master radio. AM_ADDR is a 3-bit field that contains the "active mode" address of each slave radio in the piconet. The 0 value for this field is reserved for sending the same packet to all active slaves in a kind of broadcast (the exception being the FHS packet). The device functioning as the master in the piconet sets the value of this field to the address of the destination slave radio. This same address, however, is also used in any response packets sent from the slave radio back to the master.
The TYPE field of the packet header is a 4-bit field and contains one of 16 different codes defining the type of the packet. The first four TYPE codes (0000b-0011b) are reserved for control packets, and are common to both the ACO and SCO physical links. The remaining 12 TYPE codes are uniquely defined for each type of physical link. There is another type of packet common to both physical links that consists only of the Access Code, and is a fixed length of 68 bits (the width of the Access Code itself). It is called the "ID packet," and it is used in the Inquiry and Access Procedures.
The payload section of the packet differs depending on whether it is a packet from an SCO or ACL physical link (see Table 1). The SCO link packets require only a single voice field and do not contain a payload header as in Figure 1. The ACL link packets, however, contain both a payload header and a payload body along with a CRC field (with the exception of the ACL link AUX packet, which does not require a CRC field). The DV packet is a hybrid of both the ACL link and the SCO link packet, which contains a payload header, a payload body, and separate fields for both voice and data.
Now that we have covered the Bluetooth packet it is time to consider how a Bluetooth radio uses these packets to establish ACL and SCO links. A Bluetooth radio can be understood in terms of the states it operates during link establishment and maintenance. Once the state transition is complete, the radio will then use certain procedures to establish a connection or alter the parameters of an existing connection.
The initial (or default) state of a Bluetooth radio on power-up is STANDBY. This state operates the radio in low-power mode, with only the native clock running. In the CONNECTION state, a connection has been established and packets may be exchanged between the master and the slave radios. The Channel Access Code (CAC) appears at the beginning of each packet and is used synchronize to the channel-hopping frequency maintained by the master radio. To transition to a CONNECTED state from a STANDBY state, the radio must follow certain procedures as defined in the Substates PAGE, PAGE SCAN, INQUIRY, and INQUIRY SCAN.
Figure 2 illustrates the packet exchange between a master and a slave radio. The objective of the master radio is to determine if any devices are in RF Proximity, and to determine the value of the device address (BD_ADDR) that will be used later to establish a connection with the responding slave. The master radio transitions from the STANDBY state to the INQUIRY Substate and sends an ID packet consisting only of the General Inquiry Access Code (GIAC) with the GIAC's reserved Synch Word. Periodically, the slave radio enters the INQUIRY SCAN Substate to check for GIAC ID packets using the inquiry-hopping sequence defined by the reserved value for the GIAC. In this case, the slave has detected the master's GIAC ID packet, and has decided to respond, causing it to enter the INQUIRY RESPONSE Substate.
In the INQUIRY RESPONSE Substate the slave sends an FHS packet to respond to the GIAC ID packet sent by the master. The FHS packet contains the slave radio's device address and timing information required by the master to initiate a connection. The master need not respond to the FHS packet, and may in fact remain in the INQUIRY Substate until it is satisfied that all radios in the INQUIRY SCAN Substate have been found. In the sequence in Figure 2, the slave radio returns to the STANDBY state to await the next interval for entering the INQUIRY SCAN Substate. Before doing so, however, it looks for a connection request from a master radio by entering the PAGE SCAN Substate to look for a DAC ID packet (a packet containing only a Device Access Code).
Figure 3 illustrates the packet exchange for a master radio attempting to connect to a particular slave radio. The master radio has retained the slave's device address that was previously provided in the FHS packet sent by the slave in the INQUIRY RESPONSE Substate. The device address is used to set the initial frequency-hopping sequence from which to attempt contact with the slave radio in the PAGE SCAN Substate. The master transmits the DAC ID packet and the slave radio transitions from the PAGE SCAN Substate to the PAGE RESPONSE Substate. In this state, the slave radio responds by returning the same DAC ID packet to the master in the same hopping sequence (known as the page mode hopping sequence) that was used by the master. The master radio will then respond in the next master-to-slave slot with its own FHS packet, containing its 48-bit device address (BD_ADDR) and real-time Bluetooth clock. Once again the slave sends a response DAC ID packet to the master to confirm the reception of the master's FHS packet. Both the slave and master radios then change to the frequency hopping sequence and clock as defined in the FHS packet. The slave radio then transitions to the CONNECTION state and begins to use the CAC of the master along with the AM_ADDR provided in the master's FHS packet. The master then sends a POLL packet using the newly established hopping sequence (known as the channel hopping sequence) and CAC, and the slave responds with a DAC ID packet (the specification allows a response at this point to contain any type of packet).
Once the slave radio transitions to the CONNECTED state, various operational modes are defined to support reduced power consumption for inactive slave radios or to provide the slave radio with increased capacity to function in other operational states. The modes are Active, Sniff, Hold, and Park.
In Active Mode, the Bluetooth radio actively participates in the piconet. Active master radios periodically transmit to the slaves to maintain synchronization to the channel. Active slaves periodically listen in the master-to-slave slots for packet headers containing their AM_ADDR (assigned by the master radio during the PAGE Substate message exchange). If the Active slave did not receive a packet, it may optionally sleep until the time for the next master-to-slave transmission.
In Sniff Mode, a slave radio may save power by reducing its duty cycle. The duty cycle of a slave radio in this context is defined as the listening activity required to participate in the piconet. If, for example, a slave radio were participating in an ACL Link with a master, it would be required to listen to the traffic from the master in every ACL slot, checking the AM_ADDR in the packet header, processing those packets that matched its assigned AM_ADDR, while ignoring those that did not. All this activity consumes precious power reserves, most likely supplied by a battery-operated mobile device. This is where Sniff Mode comes in.
The master radio may designate a reduced number of time slots for transmission of packets to a specific slave radio. The slave radio may then enter a reduced power state for those slots where it is not expected to receive a packet. Likewise, the master may only use these designated time slots for the transmission of packets to this particular slave radio.
Hold Mode lets the slave radio enter reduced power modes for extended periods of time, while retaining its assigned AM_ADDR (a valuable resource limited to seven slave radios in the piconet). When the time period agreed to by both the slave and master has expired the slave radio must resynchronize with the master and await additional transmissions. It is also possible for the slave radio to use this free time to participate in other piconets, periodically scan for a requested connection from the master of an adjacent piconet (scatternet), or even function as the master of its own piconet.
The down side of Hold Mode is that it requires the slave radio to resynchronize with the master when returning to Active Mode. In Park Mode, it is possible for a slave radio to operate in a low-power state without requiring repeated resynchronization, while periodically waking up to receive packets from the master radio and to maintain synchronization in the piconet. The slave radio must, however, surrender its AM_ADDR in exchange for two new addresses, the Parked Member Address (PM_ADDR) and the Access Request Address (AR_ADDR). The PM_ADDR is used by the master radio to differentiate parked slaves, while the AR_ADDR is used by the parked slave to initiate its own unparking.
The real advantage of this mode comes in when you need more than seven slaves synchronized to a master. The slave radio in Park Mode remains synchronized to the piconet and therefore retains membership in the piconet, but without using one of the seven available AM_ADDRs. Considering that PM_ADDR is 8 bits long, it is therefore possible for a master radio to support a piconet with as many as 232 slave radios. It is also possible for the master to communicate with the parked slave using its BD_ADDR. Using this method, it would be possible to sustain a piconet consisting of a virtually unlimited number of slaves.
As you can see the Bluetooth Baseband protocol is poised to provide highly flexible ad hoc networking between a variety of device types. By carefully selecting the right operational state with an operational mode consuming a minimum of power, it is possible for a Bluetooth radio to exist in a large variety of mobile devices, where wireless technology would never before have been considered.
DDJ