Bluetooth Basics

Rebecca Spaker

Due to its RF nature, Bluetooth is not subject to such limitations. In addition to wireless device connections up to 10m (up to 100m if the transmitter's power is increased), devices need not be within line-of-sight and may even connect through walls or other non-metal objects. This allows for applications such as a cell phone in a pocket or a briefcase acting as a modem for a laptop or a PDA.

Bluetooth could also be used in home networking applications. With increasing numbers of homes having multiple PCs, the need for networks that are simple to install and maintain is growing. Wireless connections circumvent the hassle of adding wiring to existing residences. Competing technologies for this market include HomeRF and IEEE 802.11. The main drawback to these technologies is their cost, which is in both cases greater than $100 per node.

Bluetooth is designed to be low cost-eventually under $10 per unit. On the flip side, however, is the limited connection distance, and even more damaging, the transmission speeds. Bluetooth supports only 780Kbps, which may be used for 721Kbps unidirectional data transfer (57.6Kbps return direction) or for up to 432.6Kbps symmetric data transfer. These rates are comparable to the 1Mbps to 2Mbps supported by HomeRF and, although live digital video is still beyond the capability of any RF technology, are perfectly adequate for file transfer and printing applications.

Finally, Bluetooth's main strength is its ability to simultaneously handle both data and voice transmissions. It's capable of supporting one asynchronous data channel and up to three synchronous voice channels, or one channel supporting both voice and data. This capability combined with ad hoc device connection and automatic service discovery make it a superior solution for mobile devices and Internet applications. This combination allows such innovative solutions as a mobile hands-free headset for voice calls, print to fax capability, and automatically synchronizing PDA, laptop, and cell phone address book applications.

Architecture overview
The Bluetooth Core specification has over 1,000 pages and covers everything from the radio transceiver to various interfaces to third-party protocols. This includes descriptions of technology implemented in silicon, in hardware, and in software. A diagram of the Bluetooth protocol architecture is shown in Figure 1

Link control hardware. Bluetooth link control hardware, either integrated as one chip or as a radio module and a baseband module, implements the RF, Baseband, and Link Manager portions of the Bluetooth specification. This hardware handles radio transmission and reception as well as required digital signal processing for the baseband protocol. Its functions include establishing connections, support for asynchronous (data) and synchronous (voice) links, error correction, and authentication. The link manager firmware provided with the baseband CPU performs low-level device discovery, link setup, authentication, and link configuration. Link managers on separate devices communicate using the Link Management Protocol, which utilizes the services of the underlying link controller (baseband). The link control hardware may also provide a Host Controller Interface (HCI) as a standard interface to the software.

Network topology. Bluetooth devices are generally organized into groups of two to eight devices called piconets, consisting of a single master device and one or more slave devices. A device may additionally belong to more than one piconet, either as a slave in both or as a master of one piconet and a slave in another. These bridge devices effectively connect piconets into a scatternet. A diagram of a Bluetooth scatternet is shown in Figure 2

Bluetooth operates in the unlicensed ISM frequency band that is generally cluttered with signals from other devices-garage door openers, baby monitors, and microwave ovens, to name just a few. To help Bluetooth devices coexist and operate reliably alongside other ISM devices, each Bluetooth piconet is synchronized to a specific frequency hopping pattern. This pattern, moving through 1,600 different frequencies per second, is unique to the particular piconet. Each frequency "hop" is a time slot during which data packets are transferred. A packet may actually span up to five time slots, in which case the frequency remains constant for the duration of that transfer.

Baseband state machine. Piconets may be static or may be formed dynamically as devices move in and out of range of one another. A device leaves standby (the low power, default state) by initiating or receiving an inquiry or a page command. An inquiry may be used if the address of a targeted device is unknown; it must be followed by a page command. A page command containing a specific DeviceAccessCode is used to connect to a remote device. Once the remote device responds, both devices enter the connected state, with the initiating device becoming the master and the responding device acting as a slave.

Once in the connected state, the slave device will synchronize to the master's clock and to the correct frequency hopping pattern. At this point, link managers exchange commands in order to set up the link and acquire device information. The master will then initiate regular transmissions in order to keep the piconet synchronized. Slaves listen on every master-transmit time slot in order to synchronize with the master and to determine if they have been addressed.

Each active slave is assigned an active member address (AM_ADDR) and participates actively on the piconet, listening to all master time slots to determine if it is being addressed by the master. In addition, there are three lower-power slave states: sniff, hold, and park. A master can only transmit to devices in sniff mode during particular sniff-designated time slots. Therefore, these devices listen only during these special time slots and sleep the rest of the time. A slave in hold mode, alternately, does not receive any asynchronous packets and listens only to determine if it should become active again. Finally, a device in park mode not only stops listening, but gives up its active member address. It is only a member of the piconet in that it remains synchronized with the frequency hopping pattern.

Baseband links. The Bluetooth baseband provides transmission channels for both data and voice and is capable of supporting one asynchronous data link and up to three synchronous voice links (or one link supporting both). Synchronous connection-oriented (SCO) links are typically used for voice transmission. These are point-to-point symmetric connections that reserve time slots in order to guarantee timely transmission. The slave device is always allowed to respond during the time-slot immediately following a SCO transmission from the master. A master can support up to three SCO links to a single or multiple slaves, but a single slave can support only two SCO links to different masters. SCO packets are never retransmitted.

Asynchronous connectionless (ACL) links are typically used for data transmission. Transmissions on these links are established on a per-slot basis (in slots not reserved for SCO links). ACL links support point-to-multipoint transfers of either asynchronous or isochronous data. After an ACL transmission from the master, only the addressed slave device may respond during the next time-slot, or if no device is addressed, the packet is considered a broadcast message. Most ACL links include packet retransmission.

Link manager. The baseband state machine is controlled largely by the link manager. This firmware-generally provided with the link control hardware-handles link setup, security, and control. Its capabilities include authentication and security services, quality of service monitoring, and baseband state control. The link manager controls paging, changing slave modes, and handling required changes in master/slave roles. It also supervises the link and controls handling of multi-slot packets.

Link managers communicate with each other using the Link Management Protocol (LMP), which uses the underlying baseband services. LMP packets, which are sent in the ACL payload, are differentiated from logical link control and adaptation protocol (L2CAP) packets by a bit in the ACL header. They are always sent as single-slot packets and are a higher priority than L2CAP packets. This helps ensure the integrity of the link under a high traffic demand.

Host controller interface (HCI). Some link controller hardware may include an HCI layer above the link manager. This firmware layer is used to isolate the Bluetooth baseband and link manager from a transport protocol such as USB or RS-232. This allows a standard host processor interface to Bluetooth hardware. An HCI driver on the host is used to interface a Bluetooth application with the transport protocol. Currently three transport mechanisms are supported: USB, RS-232, and UART. The HCI layer is illustrated in Figure 3 Using HCI, a Bluetooth application can access Bluetooth hardware without knowledge of the transport layer or other hardware implementation details.

Software protocols. The remaining Bluetooth protocols are implemented in software. L2CAP, the lowest layer, provides the interface to the link controller and allows for interoperability between Bluetooth devices. It provides protocol multiplexing, which allows support for many third party upper-level protocols such as TCP/IP and vCard/vCalendar. In addition, L2CAP provides group management-mapping upper protocol groups to Bluetooth piconets, segmentation and re-assembly of packets between layers, and negotiation and monitoring "quality of service" between devices.

Several Bluetooth protocols interface to the L2CAP link layer. SDP provides service discovery specific to the Bluetooth environment without inhibiting the use of other service discovery protocols. RFCOMM is a simple transport protocol providing serial data transfer. A Port Emulation Entity is used to map the communication API to RFCOMM services, effectively allowing legacy software to operate on a Bluetooth device. Telephony Control Protocol Specification (TCS) is provided for voice and data call control, providing group management capabilities and Connectionless TCS, which allows for signaling unrelated to an ongoing call. Both point-to-point and point-to-multipoint signaling are supported using L2CAP channels, although actual voice or data is transferred directly to and from the baseband-bypassing L2CAP-over SCO links.

Bluetooth also supports IrDA Object Exchange Protocol (IrOBEX), a session protocol defined by IrDA. This protocol may run over other transport layers, including RFCOMM and TCP/IP. For Bluetooth devices, only connection-oriented OBEX is supported. Three application profiles have been developed using OBEX. These include synchronization functionality for phone books, calendars, messaging, and so on; File Transfer functionality; and Object Push for business card support.

Finally, Bluetooth may be used as a Wireless Application Protocol (WAP) bearer. The specification outlines the interoperability requirements for implementing this capability.

Logical Link Control and Adaptation Protocol (L2CAP)
The L2CAP link layer operates over an ACL link provided by the baseband. A single ACL link, set up by the Link Manager using LMP, is always available between the master and any active slave. This provides a point-to-multipoint link supporting both asynchronous and isochronous data transfer. L2CAP provides services to upper-level protocols by transmitting data packets over L2CAP channels.

Three types of L2CAP channels exist: bi-directional signaling channels that carry commands; connection-oriented channels for bi-directional, point-to-point connections; and unidirectional connectionless channels that support point-to-multipoint connections, allowing a local L2CAP entity to be connected to a group of remote devices.

Channels. Figure 4 shows L2CAP entities with various types of channels between them. Every L2CAP channel includes two endpoints referred to by a logical channel identifier (CID). Each CID may represent a channel endpoint for a connection-oriented channel, a connectionless channel, or a signaling channel. Since a bi-directional signaling channel is required between any two L2CAP entities before communication can take place, every L2CAP entity will have one signaling channel endpoint with a reserved CID of 0x0001. All signal channels between the local L2CAP entity and any remote entities use this one endpoint.

Each connection-oriented channel in an L2CAP entity will have a local CID that is dynamically allocated. All connection-oriented CIDs must be connected to a single channel, and that channel must be configured before data transfer can take place. Note that the channel will at that point be bound to a specific upper-level protocol. In addition, a quality of service (QoS) agreement for the channel will be established between the two devices. QoS is negotiated for each channel during configuration and includes data flow parameters such as peak bandwidth, as well as the transmission type: best effort, guaranteed, or no traffic.

Connectionless channels are unidirectional and used to form groups. A single outgoing connectionless CID on a local device may be logically connected to multiple remote devices. The devices connected to this outgoing endpoint form a logical group. These outgoing CIDs are dynamically allocated. The incoming connectionless CID, however, is fixed at 0x0002. Although multiple outgoing CIDs may be created to form multiple logical groups, only one incoming connectionless CID is provided on each L2CAP entity. All incoming connectionless data arrives via this endpoint. These channels do not require connection or configuration. Therefore, any required configuration information, such as upper-level protocol, is passed as part of the data packet.

Channel state machine. An L2CAP connection-oriented channel endpoint may be in one of several possible states, with data transfer only possible in the OPEN state. Initially, an endpoint is CLOSED, indicating that no channel is associated with the CID. This is the only state in which a baseband is not required and it is the state an endpoint will default to if the link is disconnected. Figure 5 illustrates the state interactions between two L2CAP entities on either end of a connection-oriented channel.

Connection. In order to open a channel, the channel endpoint must be connected and configured. A connection occurs when either the local L2CAP entity requests connection to a remote device or an indication has been received indicating that a remote L2CAP entity is requesting connection to a local CID. In the first case, the request has originated from the upper-level-protocol, has been passed on to the remote device, and the local entity enters the W4_L2CAP_Connect_RSP state to await a response. In the latter case, the indication is recognized as a connection request, the request has been passed on to the upper layer, and the local entity enters the W4_L2CA_Connect_RSP state to await a response. In either case, when the expected response is received, the local device enters the CONFIG state.

Configuration. A connection-oriented channel must be configured before data can be transmitted. Configuration involves a negotiation between both sides of the connection until all options are agreed upon. This is done using Configuration Request and Configuration Response commands. Supported configuration option types include a maximum transmission unit (MTU), a flush timeout, and a quality of service (QoS) agreement. The MTU option reflects the largest L2CAP packet payload the local device can handle. The flush timeout determines the amount of time the link controller will attempt to transmit a L2CAP segment before flushing the packet. Finally, the QoS is used to negotiate a flow specification for a single transmission direction. L2CAP implementations are only required to support "Best Effort" service but "No traffic" or "Guaranteed" service may also be negotiated. Other parameters in the flow specification include the token rate, token bucket size, peak bandwidth, latency, and delay variation. The requesting device indicates all of the non-default options it will accept, to which the responding device either agrees or provides alternate settings. This process continues until all options are agreed upon. This configuration is for a single transfer direction, however, and the process must then be repeated for the opposite transfer direction. After all configuration parameters have been determined, both L2CAP entities enter the OPEN state, at which point data transfer may begin.

Disconnection. To close a channel, one L2CAP entity must send a disconnection request to the other. If an entity receives a disconnect request from the upper-level protocol, it passes the request onto the remote device and the local entity enters the W4_L2CAP_DISCONNECT_RSP state to await a response. If the local entity receives an indication that the remote device is requesting disconnection, it sends a disconnection request to the upper layer and then enters the W4_L2CA_DISCONNECT_RSP state to await a response. In either case, when the expected response is received, the local device enters the CLOSED state.

Packets. Data is transmitted across channels using packets. A connection-oriented channel uses packets with a 32-bit header followed by a payload of up to 65,535 bytes. The header includes a 16-bit length of payload to use for integrity check and the 16-bit destination CID. The payload contains information received from or being sent to the upper-level protocol. Connectionless channel packets also include a header but always use 0x0002 for the remote CID. In addition, the header is followed by a 16-bit (minimum) protocol/service multiplexer (PSM), which is used to indicate the upper-level protocol the packet originated from. This allows for packet re-assembly on the remote device. The PSM field is not required for connection-oriented channels since they are bound to a specific protocol during connection.

L2CAP supports segmentation and reassembly of packets between upper-level and lower-level protocols. Packets from the upper-level must not exceed a maximum transmission unit (MTU) negotiated during configuration. These upper-level packets are segmented into protocol data units (PDUs) that are small enough for the lower-level protocol. Depending on the protocol stack implemented, PDUs may be baseband packets or blocks of data supported by a host controller interface. In either case, all PDUs for a packet must be sent over the baseband before another packet can be sent to the same remote device. The baseband will send PDUs in order, using retransmit and timeouts as necessary, but notification of packet delivery depends on the implementation. If reliability is required, L2CAP must check the length field of the L2CAP packet header to determine if a packet has been transmitted successfully and then notify the upper level protocol.

Signaling packets are similar to data packets. They include a header with the payload length and the remote CID, which is always 0x0001. The payload contains one or more signaling commands used to establish and remove connections or to initiate activity over a link. Each command includes a command code, an identifier used to match requests with corresponding responses, a data length, and zero or more bytes of data. The commands are either requests or responses with every request requiring a corresponding response with the same identifier. Signaling commands provide connection-oriented service primitives and include requests and responses related to connecting, configuring, and disconnecting channels, as well as echo (ping) and information (MTU) requests and responses. In addition, a Command Reject command is used to respond to an invalid or unrecognized command.

Service discovery protocol (SDP)
SDP provides a means of determining what Bluetooth services are available on a particular device. A Bluetooth device may act as an SDP client querying services, an SDP server providing services, or both. A single Bluetooth device will have no more than one SDP server, but may act as a client to more than one remote device. SDP provides access only to information about services; utilization of those services must be provided via another Bluetooth or third-party protocol. In addition, SDP provides no notification mechanism to indicate that an SDP server, or any specific service, has become available or unavailable as may occur when the services available on a device change, or when a device comes in or out of RF proximity. This would be a common occurrence in a network supporting mobile devices. The client may, of course, poll a server to detect unavailability, but other means are required for detecting a server or service that has recently become available.

Service records. In SDP, a service may provide information, perform an action, or control a resource. SDP servers maintain service records to catalog all available services provided by the device. Each service is represented by a single service record with a dynamically allocated service record handle that is unique within the server. A special service record, with a service record handle of 0x00000000, is provided to describe the SDP server itself and its supported protocols. Service attributes within a service record describe and define the supported service including the service type, a service ID, the protocols supported, the service name, a service description, and so on. These attributes are composed of a 16-bit ID and a variable length value. Attribute values in turn include a header field, with a data type and data size, and a data field. A range of data types are supported: null, unsigned integer, signed twos-complement integer, Universally Unique Identifier (UUID), text string, Boolean, data element sequence (set), data element alternative (select one), and URL. The interpretation of this data is dependent on the attribute ID and the service class to which the service belongs.

Service classes. Each service belongs to a service class which defines all attributes by ID, intended use, and the format of the attribute value. A sub-class of another service class may define more specific attributes, in which case the sub-class inherits the attributes of the super-class. The ServiceClassIDList attribute of a service record lists the class IDs for all classes to which the service belongs. A class ID is a UUID that identifies a specific service class. If a service belongs to more than one class, the ServiceClassIDList will list class IDs starting from the most specific subclass and ending with the most general super-class, effectively defining all service attributes. The relationship between the service record attributes and the service classes is illustrated in Figure 6

Discovering services. The purpose of SDP is to discover, not access, services. Two processes are supported: searching and browsing. Searching is based on UUIDs. A service record is returned by a search only if all of the UUIDs in the service search pattern are found within service record attribute values. It does not matter in which attribute a UUID is found, or whether the UUID is only one element in a list, as long as all the search pattern UUIDs are contained somewhere among the attribute values for the service.

Searching is useful if the client is looking for specific capabilities, but for a client to identify all services offered by a remote device, the SDP "browsing" mechanism must be used. Browsing is accomplished via the search capability by using a special service attribute supported by all service classes: BrowseGroupList. This attribute contains a UUID list of "browse groups." At the top-level of the browse hierarchy, this will be the "PublicBrowseRoot." Searching on the PublicBrowseRoot UUID will return all services that may be browsed at the top-level, as well as BrowseGroupDescriptor service records describing lower-level browse groups. BrowseGroupDescriptor service records include a GroupID attribute with the UUID for the browse group it is describing. To browse the services belonging to this group, the client must read the GroupID attribute of the BrowseGroupDescriptor and then search on this group ID. Services belonging to this group will include the group ID in their BrowseGroupList attribute, and will therefore be returned by the search.

Protocol.SDP is a packet-based protocol utilizing a request-response architecture. The SDP packet is referred to as a protocol data unit (PDU), which includes a header followed by a variable number of parameters. The length of the parameter field is specified in the header, as is the type (PDU ID) which may indicate a request or response for searches or attribute queries. The header also includes a transaction ID that is used to match a request with a corresponding response. Every request must be acknowledged with a response. If for some reason the server cannot handle the request, it may send a response of type ErrorResponse (PDU ID 0x01).

It is possible that the response may be too large to fit into a single PDU. To accommodate this, a continuation state parameter is supported by most PDUs. In a response, this parameter indicates the number of bytes that are outstanding. The client may then re-send the original request-with a new transaction ID-but with the continuation state parameter set. This alerts the server to send the continuation of the response. At what point a response is split is determined by the server.

Three categories of transactions (PDU IDs) are supported: service search transactions, service attribute transactions, and service search attribute transactions. Service search transactions are used to request a list of service record handles for service records which have attributes containing all of the UUIDs in a service search pattern. There is no mechanism to request all the service records, although browsing is supported as already described. Service attribute transactions are used to request specific attribute values from a service record. Service search attribute transactions combine the service search and the service attribute transactions, which allows getting specific attribute values for all service records that match a service search pattern.

Bluetooth today and tomorrow
With the bulk of the work developing the Bluetooth specification complete, the Bluetooth SIG is now working on improvements and analyzing feedback from the industry. In addition to their work investigating improvements in speed, security, noise immunity, and so on, the SIG continues to develop Bluetooth profiles. These are defined in a separate Bluetooth Profiles Specification, also in excess of 1,000 pages.

Bluetooth profiles. The continuing effort to define profiles provides Bluetooth with a significant advantage over competing technologies. Profiles, defined by the Bluetooth SIG, are intended to ensure interoperability between Bluetooth applications and devices from different manufacturers. These profiles define the roles and capabilities for specific types of applications. Different profiles may encompass different layers and protocols and to different degrees. In addition to requirements for interoperability, protocols may define required services to other applications or to end users.

All Bluetooth devices must support the Generic Access Profile at a minimum. This profile defines device discovery, connection procedures, and procedures for various security levels. Some Bluetooth-specific user interface requirements are described as well. Another universal profile, although not required, is the Service Discovery Access Profile which defines how a service discovery application on a device determines the services on other remote devices as well as the protocols and associated parameters required to access them. Quite a number of additional profiles have been defined including TCS-, RFCOMM-, and OBEX-related profiles. Some of these require the implementation of others, and all of them require the implementation of the Generic Access Profile. So much work has been done developing profiles that a separate article would be required to adequately cover them all.

What's next
Along with the continuing development of profiles, the Bluetooth SIG is working on other fronts to improve the specification. This includes addressing other interoperability issues and developing support for faster data rates, a crucial factor in the future success of the technology. Bluetooth security capability is also an area of concern for potential Bluetooth adopters. On the implementation front, work is being done to integrate the silicon for the RF and baseband chips, as well as achieving a small enough implementation to be practical in small portable devices.

At the time of this writing, Bluetooth RF/baseband modules were selling well above the $5 per unit target. After an impressive marketing push that resulted in Bluetooth nearly becoming a household name, designers are beginning to give Bluetooth a more critical look and are voicing their concerns. Although it is well positioned for success in the emerging wireless networking market, the key will be in Bluetooth's evolution.

The Bluetooth SIG must overcome the outstanding barriers to wide-scale implementation and must keep the technology up to date with the ever-increasing consumer demands for price and performance. If they can accomplish that, the Bluetooth wireless world they envision may well come to be.

After earning a BS in electrical engineering from the University of Rochester, Rebecca Spaker has spent the last eight years designing embedded hardware and software, with recent work focused on hardcopy and digital imaging-related applications. For the last four years she has worked for Questra Corp. as a senior consultant. Currently, she works with Questra's eAppliances practice group, providing consulting and development services for internet-enabled devices. Her e-mail address is rspaker@questra.com.

References

• Specification of the Bluetooth System-Core v1.0A. July 26, 1999.
• Specification of the Bluetooth System-Profiles v1.0A. July 26, 1999.
• www.bluetooth.com. The official Bluetooth Web site.
• www.bluetooth.net. Digianswer A/S Bluetooth Web site.
• www.palopt.com.au/bluetooth. Palo Pacific Technology Bluetooth Web site.