Page 2:Bluetooth Versions And Profiles
Page 3:Bluetooth Operation
Page 4:Bluetooth Wireless Communication
Page 5:The Stack And Packet Exchange
Page 6:Bluetooth Security
Page 7:Hardware, Manufacturing And Host Integration
Page 8:Major Bluetooth Manufacturers
Page 9:The Future Of Bluetooth
From keyboards to headsets to mobile computing, Bluetooth provides the personal wireless network needed to get around without a bunch of cables entangling our lives. Here's a close look at a key technology that empowers our mobile world.
Bluetooth is everywhere—you'll find it in smartphones, tablets, laptops, TVs, cars, security systems, computer peripherals (mice, keyboads, headphones), smartwatches and more. A great many manufacturers in every sector of the tech industry have adopted Bluetooth for reliable and ubiquitous short-distance communication. But while most of us can decode the intricacies of a Wi-Fi connection by the standard's nomenclature, recognition of Bluetooth capabilities usually ends with the version number.
Bluetooth is fascinating, though—not just for its technical operation, but for the multi-national conglomerate of corporations standing behind it, and the work they do behind the scenes to makes sure Bluetooth is the standard. This article is an in-depth look at everything Bluetooth: the science, the tech, the security and the standard.
What Is Bluetooth?
In a nutshell, Bluetooth is a wireless communication specification operating on the unlicensed 2.4GHz band. It could be considered a short-range sibling of Wi-Fi. Where Wi-Fi enables wireless local area networks (WLANs) and ties together devices around some venue, Bluetooth enables wireless personal area networks (PANs) to enable communication in a 10-meter range (for Class 2 and Class 3 Bluetooth devices) and more than 100-meter range for Class 1 devices, mostly used for industrial applications. Even the low-power Class 2 and Class 3 devices are capable of greater than 10-meter range with the new networking and modulation schemes introduced by the Bluetooth standard in March 2016.
Wi-Fi, microwave ovens, drones and Bluetooth all operate on the 2.4GHz band. This frequency is categorized as "unlicensed" in most areas of the world. Unlicensed, however, does not mean unregulated—there are limits on the amount of power that can be transmitted, modulation schemes and unintentional out-of-band RF interference. Fortunately, operating a transmit/receive system does not require a user license. Otherwise we'd all have to take a radio operator course before enabling the Wi-Fi or Bluetooth functions on our smartphones, or even to turn on our microwave ovens.
Like all wireless communications technologies, Bluetooth requires a transmitter and receiver (with antennas on each), and modem-like control chips to modulate and demodulate the digital signal. These functions are usually integrated into one SoC that includes a transceiver, antenna and control chip. For more complex systems like smartphones, Bluetooth is often integrated into a multi-communication SoC that handles other wireless specifications as well.
Texas Instruments CC2560/64 Bluetooth evaluation module
Current implementations of Bluetooth come in two flavors: Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR) and Bluetooth low energy (LE), also called Bluetooth Smart. The former establishes short-range connections for continuous data transfer (think headsets streaming music from a smartphone). Bluetooth LE is designed for short bursts of small data packets over a longer range in order to conserve battery life. Sensors, "smart" lightbulbs and other "smart home" devices are the ideal use-case for Bluetooth LE. Finally, some laptops and smartphones require both LE modes and BR/EDR modes, and this capability is offered by so-called "dual-mode" Bluetooth solutions.
MORE: Wireless Routers 101
MORE: Router SoC 101
MORE: All Networking Content
MORE: Networking in the Forums
A Short History Of Bluetooth
In the tenth century, the Viking king Harald Blåtand (Harald Bluetooth in English) united large swathes of modern-day Norway and Denmark under his rule. Fast-forward to 1994, when Ericsson's R&D teams started investigating ways to connect computers and the "smartphones" of the day without cables. In 1997, Jim Kardach proposed the name "Bluetooth" for the new technology that would unify communications protocols like King Harald had united Scandinavia.
Monument donated by Ericsson CEO Sven-Christer Nilsson in 1999 at the Ericsson R&D facility in Lund. Photograph "Ericsson Runestone" by Karl Baron (CC BY 2.0)
But Ericsson soon realized that implementing such a far-reaching, near-universal protocol would require cooperation on a vast scale. So, in 1998, along with Nokia, IBM, Intel and Toshiba, Ericsson founded the Bluetooth Special Interest Group (SIG). The first formalized Bluetooth technical specification arrived in 1999. The standard's logo is a ligature of two runes from the Younger Futhark runic alphabet: Hagall (ᚼ) and Bjarkan (ᛒ), Harald Bluetooth’s initials.
Bluetooth Special Interest Group
The Bluetooth specification was conceived as a worldwide communications specification. The founding members of the SIG, apart from being the multi-national companies with the most to gain from Bluetooth's adoption, also represented geographic regions: Ericsson and Nokia were from Europe, Toshiba hailed from Asia, and IBM and Intel represented North and South America.
The SIG's day-to-day tasks involve Bluetooth advocacy to governments, legal issues, managing test processes and compliance, and publishing the Bluetooth specification.
Microsoft, Motorola, Lucent Technologies and 3Com also jointed the SIG, and these nine companies formed the upper-level SIG administrators, the "SIG Promoters." The current list of promoters includes Apple, Ericsson, Intel, Lenovo, Microsoft, Nokia, and Toshiba.
"Associate Members" sign a legal document and pay an annual membership fee that allows them to participate in marketing and technical activities. They're also allowed to see draft documents 0.5 and above. With new Bluetooth specifications surfacing every few years, early drafts of the regulations provide Associate Members and the SIG Promoters an advantage in product design and deployment lead times. A third tier, called "Adopters," join for free, but still sign a legal memorandum of understanding. They have access to draft document versions 0.9 and above.
Bluetooth SIG membership tiers
SIG membership is mandatory if a manufacturer wants to use the Bluetooth specification in products, or use the Bluetooth logo or other intellectual property.
IEEE, FCC, CE And Other Regulatory Acronyms
In the United States, the FCC allocates frequency bands for specific uses, the transmission power of devices in various configurations (narrowband vs. spectrum spread), modulation requirements and product certification for any product that has the potential for RF interference.
Most countries require some sort of licensing or approval of low-power devices operating on the 2.4GHz band, and also set limitations on power levels, modulation and other technical specifics of operation. Industry Canada (IC) handles this in Canada, there's CE for Europe and so on. And there are also country-specific requirements. For example, France sets geographical constraints, and Lithuania requires user licenses. Each regulation may also dictate the minimum and maximum number of channels Bluetooth can operate on.
The IEEE, a governing body that develops worldwide consensus standards on electronics, incorporated Bluetooth as standard 802.15.1. Wi-Fi is 802.11, in comparison.
Bluetooth Versions And Profiles
The SIG is continually modifying and updating the Bluetooth specification to keep up with demand and new technologies. Early access to these updated specifications, extended to the two top tiers of SIG members, can make a large difference in the time-to-market of consumer devices, and therefore long-term profits and market positioning of a company.
For consumers, upgrades to the Bluetooth standard introduce many benefits—greater security, more functionality (as with the enhanced data rate addition, and then the Bluetooth Low Energy specification for wearables), improved power consumption and paring reliability. All versions are backwards compatible, and the flagship features of each version are considered optional.
Bluetooth 1.x was plagued with a number of implementation and security problems, and is now obsolete. Bluetooth 2.x opened the gates to mass adoption of the standard, improved interoperability, and quick-pairing, and it introduced the Enhanced Data Rate capability. Bluetooth 3.x tacked on a High Speed feature by adding support for a lower layer link protocol where all Bluetooth capabilities could be run from an alternate radio in the device, like Wi-Fi. Finally, Bluetooth 4.x introduced Low Energy support for devices like wearables and smart sensors with very low data overhead.
A Bluetooth profile is a set of pre-determined capabilities and a customized stack, determined by the type of operation intended. Profiles make it much easier to design for, implement and manage the very wide variety of Bluetooth operations needed for an application. For example, a car with Bluetooth capability would most commonly only implement the Hands Free Profile, containing a very customized protocol stack, but not implement the Serial Port Profile. Meanwhile, a sensor used for laboratory measurements would only implement the Serial Port Profile for collecting data, but would completely ignore the Audio/Video Remote Control Profile.
As of this writing, there are more than 33 profiles listed in the latest Bluetooth specification, and it allows for the addition of many more—as many as required for each new application class that may emerge in the coming years.
Examples of Bluetooth profile relationships
Certain profiles are usually implemented by all Bluetooth devices. For example, the Generic Access Profile (GAP) forms the basis of all other profiles and determines how two Bluetooth devices establish a connection. Other profiles are more specific, for example the Health Thermometer Profile (HTP) that facilities protocols for medical device data exchange.
Profile and device-specific APIs are a key element of many Bluetooth profiles, and implement the customized methods by which the protocol layers may interact.
Bluetooth is designed for communication over a small network called a piconet. The simplest configuration is a point-to-point piconet, with one device designed as a "master" and the other a "slave." The master initiates the communication link, and in general, has control over the network's timing. Up to seven slaves can be connected to a master in a point-to-multipoint configuration. An example of this kind of operation is a smartphone (master) connecting to multiple Bluetooth slaves—a Bluetooth headset for streaming music, a Bluetooth keyboard as an input and a second smartphone for Bluetooth-based file transfers. This kind of system implies an ad-hoc network with no fixed roles or designations. Also, a Bluetooth master can dissolve its piconet and then go join a different piconet as a slave. Here's an example of Bluetooth network organization; Network 1 is a piconet in standalone mode, Network 2 is a scatternet:
A Bluetooth device can be a slave in more than one network (an example would be a multi-point Bluetooth headset that connects to a smartphone and a laptop simultaneously, and the data input from each source device switches the operation of the headset), or a slave in one network and a master in another. Configurations that go beyond the master-and-seven-slave setup are called scatternets.
Establishing A Bluetooth Piconet
Initiating a piconet is done by a master, and the Bluetooth protocol establishes a universal method for establishing links:
- INQUIRY: the master sends out an inquiry to determine which devices are in range
- INQUIRY RESPONSE: the devices hearing the inquiry respond with specific information (their paging parameters)
- PAGE: the master then pages the specific device it wants to connect to
- PAGE RESPONSE: the paged device acknowledges and responds
- LINK PARAMETER EXCHANGE: now the two devices exchange their link parameters, and bi-directional data transfer can begin.
Each Bluetooth device can be in a number of states, depending on the commands sent to it (either internal, or based upon the type/commands of received data packets over the radio) and the type of operation that is expected of it. The three overall states are "standby," "connection," and "park." Each device maintains its own state, and the master maintains a list of its slaves' states (or expected states). There are also a number of sub-states: page, page scan, inquiry, inquiry scan, master response, slave response and inquiry response.
Bluetooth Wireless Communication
While a detailed presentation of key RF transmission modulation techniques is outside the scope of this article, we present the basic skeleton of pertinent RF information required to gain a good understanding of Bluetooth communications.
If a digital signal composed of ones and zeros must be sent, the easiest way to do it would be to flick a switch "on" and "off"—any voltage-sensitive device connected to the circuit can then receive this data. Called the "baseband signal," this raw data needs to be bundled into a wireless RF carrier wave for it to be transmitted by a radio instead of over wires. There are many ways to handle this: the classic "AM" (Amplitude Modulated) and "FM"(Frequency Modulated) signals of analog radio, and Phase-Shift modulation.
Putting information onto a carrier RF wave is called modulation, and extracting the data (on the receiver’s end) is called demodulation. Incidentally, this is exactly what a modem is: a modulator and demodulator of signals. The act of modulating a signal is called "keying," and the individual schemes go by the acronyms that reflect this: FSK (Frequency-Shift Keying), PSK (Phase-Shift Keying) and so on. Each scheme has its own advantages and disadvantages, namely hardware requirements and the inherent error rate (BER, or Bit Error Rate) at a given power level. Either way, the schemes use a single bit (one or zero) to make a change in the symbol being sent in the carrier wave, so the symbol rate is also the bitrate of the signal.
Decoding the specific modulation requirements of the Bluetooth specification are also beyond the scope of this article, but for completeness, they are:
- GFSK with a Bandwidth-Time product of 0.5
- Symbol rate of 1Ms/s (bitrate of 1 Mb/s)
- Modulation index 0.28 < k < 0.35
- Convention: 1 is positive, 0 is negative in terms of frequency delay
- Symbol timing greater than 20ppm
- A "zero crossing error" (i.e. the error in the times the frequency fluctuates between positive and negative ) no greater than 20 percent of the total time it takes to transmit one symbol.
- A minimum frequency delay of 115kHz
- Frequency delay of a 1010 sequence must be, at minimum, 80% of a delay of a 00001111 sequence.
It is disingenuous to claim that error rates drove the modulation scheme for Bluetooth—any modulation scheme is capable of low error rates and high data density, but the trade-off is a matter of SNR (signal-to-noise ratio). In order to meet the low-cost goals of the project, the Bluetooth specification settled on FSK. Amplitude modulation consumes the same amount of power as frequency modulation, however it must be designed to handle double the peak powers, which means expensive components. And though PSK has a far better SNR, the hardware components required for phase detection rule it out as a Bluetooth-enabling method of modulation. So, the Bluetooth specification takes FSK, adds Gaussian Baseband Filtering (a filter that cuts out certain frequencies in order to smooth out the jagged power transitions in the FM signal) and implements Gaussian Frequency Shift Keying (GFSK) as a modulation technique. But with enhanced data rate operation implemented in later versions of the Bluetooth specifications, two separate modulation schemes are used—GFSK for basic data rate tasks (or the basic data rate portion of the packet) and DPSK (Differential Phase-Shift Keying) for the enhanced data rate additions to the transmission.
RF modulation schemes. Source: National Instruments
The next core RF technique that is integral to Bluetooth operation is Frequency Hopping. While the 2.4GHz band extends from 2.4GHz to 2.483GHz, Bluetooth transmits on a channel with a bandwidth of 1MHz. So Bluetooth can utilize up to 79 channels in the band, starting at 2.402GHz and going up in increments of 1MHz. Frequency Hopping means continually changing channels while transmitting a stream of data. This is one of the techniques (in fact, the core of almost all techniques) used to mitigate interference effects in the crowded 2.4GHz band. It also assists in forming the Bluetooth security strategy. Channel hopping rates, timing synchronization between devices and channel set protocols are all defined in the Bluetooth specification.
The final area pertinent to Bluetooth operations is transmission power. The transmission power of the transmitter, the sensitivity of the receiver, the RF bandwidth available and the actual RF frequency of the transmission determine the data transmission rate and the distance an RF link is operated over. Given that the channel bandwidths and the actual frequency are pre-determined by the Bluetooth specification, this leaves transmission power and receiver sensitivity, as variables that determine the effective range of Bluetooth devices.
The SIG defines three classes of Bluetooth devices based on transmit power. These mirror the classes of radios allowed on the ISM band by the FCC (maximum power limits in Europe are lower than those of North America, and the SIG uses the maximum worldwide allowable power to determine power thresholds). Class 1 devices are usually Bluetooth add-on modules for desktop computers, powered hubs, industrial equipment and other devices that need to maximize range. Capable of reaching up to 100 meters, Class 1 devices are restricted to a maximum power of 100mW (20dBm).
Class 2 devices have a typical range of 10 meters. They're the most common Bluetooth modules in headsets and peripherals. Battery life is important here, and the maximum permitted power for Class 2 devices is 2.5mW. Class 3 devices are designed for very short-range communications (typically within 1m). Wearables are a common application well-suited to Class 3 modules with a maximum permitted power of 1mW.
The range of a Bluetooth device is also determined by receiver sensitivity—Class 1 and Class 2 devices generally share about the same level of sensitivity (-75 to -60 dB), but ranges greater than 100m can be accomplished when two Class 1 devices, or Class 1 and Class 2 devices with very high-sensitivity receivers are linked together.
Even the guideline 10m range is not a constant—physical obstacles, walls and multiple reflections all affect the distance a signal will travel. Sometimes the impact is positive, but it's usually negative.
There are many, many different classes and sources of interference for Bluetooth on the 2.4GHz band. RF signals bounce off walls, internal device components and furniture, creating a "multipath" problem at the receiver. In some cases, the signal strength of a reflected RF wave may be stronger than the direct line-of-sight signal! So, a real-world multipath scenario may be used to enhance the signal strength and range of a Bluetooth transmission (as in the case of a long, narrow corridor). More often than not, though, it'll act as a source of interference and signal loss due to the time delay between the primary and reflected signals, leading to confusion at the receiver. Yes, a Bluetooth device can interfere with itself.
Multipath transmission problem
Then there is Bluetooth interference from other piconets, or even other devices within the same piconet. Since each master-slave connection synchronizes its channel-hops and timings, there is low probability that a packet will be mistakenly accepted from a foreign piconet or device, but it will be received nonetheless.
The final class of interference comes from other protocols on the 2.4GHz band—microwave ovens and, a more likely culprit, Wi-Fi. A number of studies were done to determine the effect of Wi-Fi interference on Bluetooth and vice versa, and most conclude that two meters between a Bluetooth transmitter and Wi-Fi node reduces interference to operable levels. However, a Class 1 Bluetooth transmitter in close proximity to a Wi-Fi receiver can, and does, pose significant problems in maintaining a low BER, choking the data rates for both standards.
The core of most passive interference mitigation strategies is channel hopping. If a Bluetooth device determines that there is narrowband interference on a channel, the next hop will solve the problem. And since the channel hops of Wi-Fi and Bluetooth are not synchronized, the likelihood of a receiver listening at the exact time and frequency channel that a foreign device is sending drops significantly.
2.4 GHz interference from radiative sources.
Active interference mitigation can be handed either collaboratively or non-collaboratively. A non-collaborative approach used in cases where the source of interference is completely unknown is rejecting signals below a certain threshold determined by the very first packet that established the signal and link. Other non-collaborative strategies can be considered filtering-based as well. Forward error-correction is also used to mitigate some of the problems arising out of interference.
Collaborative interference mitigation is used most often in devices like smartphones, where Wi-Fi, cellular and other sources of RF radiation sit on the same chip as the Bluetooth module. This is an intensive and expensive approach, requiring close coordination and high-level control. Essentially, the host device’s controller manages several important parameters in order to make sure each radio operates without interference from another in close proximity. This allows strong Bluetooth transceivers and antennas to coexist within a few square centimeters of powerful Wi-Fi transceivers.
The Stack And Packet Exchange
The Bluetooth Stack
The Bluetooth stack is a set of hierarchical protocols designed to deal with the data required to make a successful Bluetooth session. These protocols can be divided into two areas. First is the lower stack, also called a “controller stack”, which contains the timing and radio control protocol (where the Bluetooth header information is used to determine channel-hopping synchronization, for example, or rejecting a channel for too much interference). Then there's the upper stack, also called the “host stack,” which deals with the higher-level data, for example the “how” of dealing with a two-way VoIP call’s audio requirements over a Bluetooth connection.
The controller stack is most commonly implemented in the hardware of the Bluetooth module/chip itself. The relevant protocols are:
- ACL, or Asynchronous Connection-Less, a protocol for sending error-sensitive data like a document. The connection is asynchronous because the receiver and transmitter take turns sending while the other receives. ACL implements forward error-correction and retransmission of a data packet in the absence of acknowledgement.
- SCO, or Synchronous Connection-Oriented, a link protocol used for voice data, where each transmitter in the link simply sends data during its time slot without waiting for acknowledgement. There is no retransmission of data, but forward error-correction can be implemented.
- LMP, or Link Manager Protocol, used to handle link establishment between radios, queries and power control.
- LE LL, or Low Energy Link Layer, an equivalent of LMP for Bluetooth Low Energy links.
- HCI, or Host Controller Interface, a standardized communication protocol used to bridge the host stack and the control stack. There are multiple standards for HCI, and multiple hardware implementations.
The host stack most commonly sits at the operating system level of a PC, smartphone or other advanced device. In certain cases, like Bluetooth headsets, there may be no host stack at all, or a simplified host stack implemented in the device firmware. Protocols inherent in the host stack are:
- L2CAP, or Logical Link Control and Adaptation Protocol, used to pass packets from the host to the HCI, or, when the HCI is omitted, directly to the LMP. L2CAP multiplexes data between different higher-layer protocols (voice data for a phone call transmitted alongside data input from a Bluetooth keyboard, for example), segments and reassembles Bluetooth data packets.
- BNEP, or Bluetooth Network Encapsulation Protocol, used to deliver network packets above L2CAP.
- RFCOMM, or Radio Frequency Communication, a protocol used to emulate RS-232 serial ports.
- SDP, or Service Discovery Protocol, used to allow devices to discover each others' service parameters and which Bluetooth profiles are supported.
- TCS, or Telephony Control Protocol Specification, used to set up and control calls (voice and data) between devices.
- AVCTP, or Audio/Video Control Transport Protocol, used to transfer Audio Video Control over the L2CAP link.
- AVDTP, or Audio/Video distribution Transport Protocol, designed for audio and video distribution (such as streaming music to stereo headsets).
- OBEX, or Object Exchange, used for simple data exchange between devices, for example a document or image.
- ATT, or low energy ATTribute Protocol, the low-energy equivalent of SDP
- SMP, or Low Energy Security Manager, a protocol used for pairing and specific key distribution.
Apart from the location of implementation, the stack can be divided according to the type of link:
- Physical Links: a baseband connection between two devices, associated with exactly one physical channel. Physical link properties include power control, link supervision and encryption.
- Logical Transports: data transport between master and slaves. These include SCO and ACL.
- Logical Links: “virtual” links that control various transports. These are defined to be Link Control, ACL Control, User Asynchronous/Isochronous (ACL-U), User Synchronous (SCO-S) and User Extended Synchronous (eSCO-S).
Bluetooth Packets And Packet Exchange
With the Enhanced Data Rate implemented as of Bluetooth v3.0, data packets are split into two types: the Basic Rate packet, which consists of the access code, header and payload, and the Enhanced Data Rate Packet, which consists of the access code, header, guard period, synchronization sequence, enhanced data rate payload and trailer. Here is what the basic data rate Bluetooth packet structure looks like:
Packet handling and packet sub-components defined by the Bluetooth specification can become rather involved. For example, the Access Code begins with a preamble, a sync-word and a trailer. The preamble and first bit of the sync word provide bit-synchronization, allowing the receiver to set a "decision threshold" of incoming signal strength for the lowest possible BER. The last portion of the sync word and the trailer provide data for decoding the header, which follows the Access Code. Further, there are multiple types of access codes, depending on the operation to be performed: the Channel Access Code (CAC) is included in all packets and is used by piconet members to determine whether they should accept the rest of the packet, the Device Access Code (DAC) is used by the master to page a specific device, the General Inquiry Access Code (GIAC) is used by the master to inquire which Bluetooth devices are within range and the Dedicated Inquiry Access Code (DIAC) is used by the master to page only a specific type of device (to page only printers in the building, for instance, not headsets or smartphones).
The packet header is a 54-bit, six-field entry providing the real data a piconet needs to function, including the addresses of the active slaves the master is addressing, the type of packet being sent (ACL or SCO, for example), the flow of packets to control buffering, an acknowledgement of successful receipt, a sequential number bit to prevent acceptance of duplicate or retransmitted packets and a unique sequence generated from a given polynomial function in order to protect the device from accepting an incorrect packet.
Packets consisting of only an access code and header are called NULL and POLL. They're used to convey flow, acknowledgement or ping a slave for a response.
The payload itself is the biggest chunk of data transmitted, and its structure varies depending on what kind of data is being transmitted.
Bluetooth security employs three distinct features systematically: authentication between two devices, followed by acquiring permissions (authorization) and lastly, encryption. These three processes are implemented at several different layers in the protocol stack, leading to Bluetooth security being referred to as a “cross-layer function”. Security researchers at Kaspersky labs have referred to the Bluetooth specification as having “more security holes than Swiss cheese”. Based on a number of concerns, the pairing and authentication procedures have been updated with each revision.
Security begins with a potential master defining how it will be discovered, and options for connectivity:
- Silent—this mode makes the device undetectable and the device doesn’t accept any connections, though it is able to detect Bluetooth traffic. The device can’t enter either the PAGE SCAN or INQUIRY SCAN state.
- Private—in this mode, the device is able to enter into the PAGE SCAN state, but not INQUIRY SCAN. This status makes the device undiscoverable.
- Public—in this mode, the device can enter both the PAGE SCAN and INQUIRY SCAN states. It is therefore discoverable to other devices and implicitly open to connections.
The Generic Access Profile (GAP), which forms the basis of all other profiles, defines three different security modes for connections:
- Mode 1 (non-secure) allows Bluetooth communication to take place between devices without authentication or encryption of the data.
- Mode 2 (service-level enforced security) permits an Asynchronous Connection-Less (ACL) link between two devices without authentication or encryption. The connection is non-secure. Once the Logical Link Control and Adaptation Protocol (L2CAP) channel request is made, security procedures are initiated.
- Mode 3 (link-level enforced security) allows security procedures to be initiated while the Asynchronous Connection-Less link is being established.
Vulnerabilities And Mitigation
Like all communication protocols, Bluetooth is inherently vulnerable in certain scenarios. One class of vulnerability is proximal—because of the somewhat restricted range of Bluetooth radios (though, given the right circumstances, this range can be much larger than you might anticipate), the majority of attacks have to come from a source physically close to the piconet. But even with such a constraint, snooping, spoofing, denial of service attacks and drive-by malware downloads all are potentially possible.
In 2001, flaws were discovered by Bell Laboratories in Bluetooth's pairing system protocol and encryption. In 2003, Ben and Adam Laurie of A.L Digital Ltd. determined that that the technology's security could lead to the disclosure of personal info due to poor implementations. In 2004, Kaspersky Lab discovered a virus that could be spread through Bluetooth on the Symbian OS. In 2006, researchers from F-Secure and Secure Network showed how devices left in a visible state could be accessed, and that they were vulnerable to worms spread through Bluetooth.
The National Institute of Standards and Technology (NIST) published a guide in 2008 for Bluetooth security in organizations. The guide outlines the possible attacks: denial-of-service, eavesdropping, man-in-the-middle, message modification and resource misappropriation, and includes a security checklist with guidelines and recommendations. Unfortunately, a number of these strategies address concerns at the manufacturer or firmware implementation level, and may not always be part of SIG’s qualification process (especially when a pre-qualified or pre-certified module is used). Do all manufacturers, especially ones producing end-products with price tags below $20, comply with up-to-date security recommendations?
Siemens M75 (left) Bluejacking a Sony Ericsson K600i (right)
Automatic authentication of Bluetooth doesn’t apply to the user, but rather to the device. If an unauthorized individual gains access to that device, security is compromised. This is mitigated by setting user-authentication requirements at the application level, or the upper layers of the Bluetooth stack, where a password must be supplied before a Bluetooth state can be changed.
The flow of data over a Bluetooth link is bidirectional once a connection is established. An eavesdropper may not have access to the channel-hop or synchronization list, but given enough time to listen, the statistical likelihood of intercepting a packet that contains important data for the LM layer rises. Encryption is the primary mitigation strategy for this sort of attack. Then there are attacks where an eavesdropper may use a high-power transmitter and spoofed packet access codes/headers (extracted from the previously intercepted packet) to fool a receiver into rejecting the correct data packets while believing the attacker (based on higher transmit power) is the genuine source.
All of the above attacks have individual mitigation strategies. But the greatest cause of security nightmares is the scenario where a Bluetooth connection is established to a network like the Internet. Then, all bets are off. Even if the Bluetooth link and stack are secured and encrypted, support for legacy applications may require second- or third-party software to act as a liaison between the application and Bluetooth security manager, in which case the liaison itself might be compromised. When a connection is established to access infrastructure like a LAN or the Internet, and there are several layers required to establish the connection, there will be end-to-end issues that may make it necessary to implement a solution that includes Bluetooth security. Without this option, the user has to insert several passwords at different levels, and that could get frustrating.
To prevent eavesdropping in a point-to-point security setup where a master communicates with a single slave, a number of established steps are required for security to be set successfully. Setting up a Bluetooth passkey or a Personal Identification Number (PIN) enables the building of several 128-bit pass keys. The PIN is then used to create the initialization key, which is used to establish a link key that can either be a unit key or a combination key. A unit key is established in a device with limited resources, while a combination key can be established in majority of the latest devices. In the event that encryption is required, the link key is used to generate the encryption key.
For security measures to be effective (to the extent that they can be), authentication and authorization have to be implemented after establishing the Asynchronous Connection-Less (ACL) link. This is the equivalent of the GAP's Mode 2 security. The PIN, either set by the user or programmed into the Bluetooth unit found in the device, is one of the entities used to maintain high-level security. In most cases where there is no man-machine interface (MMI), the PIN is preprogrammed. A common PIN is one that two devices share. When the PIN is entered on both devices, they create the same link key and the authentication process takes place. To ensure Bluetooth security, users are encouraged not to maintain a single PIN for multiple instances of connection, or multiple devices. Pseudorandom number-generated PINs are used to establish secure links with devices that do not have a PIN. All Bluetooth devices have this feature enabled, allowing them to create 128-bit binary numbers once a request is made.
The authentication key (link key) ensures the legitimacy of other devices in the piconet. Due to its length and random generation, the authentication key makes it difficult for a third party to guess. These keys can either be used once or on a semi-permanent basis. Link keys also generate the encryption key where necessary. A device is considered trusted when it has authorization based on previous authentication to access various services. Devices are defined as untrusted when they require the user to insert a password for authorization to be granted.
On the flip side of the coin are the methods of attacking Bluetooth networks. Even the latest specification, 4.x, is vulnerable to many of these attacks, with new threats surfacing every day. The aptly named “Car Whisperer” accesses the audio stream from Bluetooth-enabled vehicles, and Redfang, the venerable Bluetooth snarfer, is joined by a number of software packages circulating openly on the Internet. There are some very high-end, polished products that were originally used for penetration testing and in-house security qualification that have since leaked to the darker shadows of the Web. Some common attacks enabled by Bluetooth’s vulnerabilities include:
- Bluejacking—when an unauthorized source sends a short data transmission, most often some text or a message, to an unsuspecting receiver.
- Bluesnarfing—unauthorized access to information on a Bluetooth host, allowing access to user files like documents, emails and pictures. Any device in a “discoverable” state is vulnerable to this. Bluesniping, where a directional antenna is used to target Bluetooth devices over 1km away, is a specific form of Bluesnarfing.
- Bluebugging—a short-range attack where a host/master is “tricked” into assuming an unauthorized device (with its ID spoofed to look like a legitimate Bluetooth headset) for redirecting calls and messages intended for the victim.
Hardware, Manufacturing And Host Integration
At the lowest level, a Bluetooth device has two key components: a radio and a baseband controller. Simple enough, right? But the small footprint, interoperability constraints and low-cost objectives of Bluetooth technology make manufacturing modules and devices a difficult engineering task when it comes to RF chip design. The challenge is appreciable enough that companies are fanatic about safeguarding their IP, and will often not provide detailed designs for the base Bluetooth IC/SoC even to the vendor that is manufacturing/integrating the final consumer device.
Texas Instruments Bluetooth evaluation module and pinout diagram, Courtesy of Texas Instruments Incorporated (TI)
At the highest level of engineering design, the first decision to make about Bluetooth is its integration with the host product. There are almost as many ways to implement Bluetooth integration in a consumer end-product as there are classes of products. Broadly, they can be classified as:
- Integrated single-chip, where the baseband circuits and Bluetooth radio are completely integrated into the host SoC module. This type of approach is most commonly used in headsets, and the design complexity of a single chip like this is overshadowed by the lower cost of manufacturing and integration.
- Standalone single-chip, where a single Bluetooth SoC containing the baseband circuitry and radio is integrated into a larger system assembly. This is commonly seen on computer peripherals like Bluetooth keyboards and mice, or certain types of smartphones and tablets. Pre-certified Bluetooth modules can be used to save on costs.
- Dual-chip, where the baseband circuits and radio are housed in two separate IC packages. This approach has lost ground to the single-chip approach, and is most often seen when the radio sticks to analog operation and the baseband IC is digital.
The hardware integration is closely (but not always) tied to the partitioning of the Bluetooth protocol stack. Where the Bluetooth implementation is completely integrated with the host, it is the host’s software/firmware and host’s computing resources that are used to manage the upper and lower stacks and the API. In all other cases, the radio and baseband circuits always handle the lower stack (LM, LC and down), so the difference is in where and how the upper stack is managed. For a standalone single or radio-baseband-dual chip, a microcontroller implements the upper stack and there is often no need for the API. When Bluetooth shows up as a host add-on, for example in a Bluetooth adapter for a PC, the Bluetooth plug-in module handles the lower stack, the module communicates with its host through HCI and the host software/drivers handle the upper stack and API. Finally, in the host ASIC case, everything sits on the single Bluetooth chip, and the API on the host machine/device communicates with the module.
The actual Bluetooth radio and baseband chips (whether single SoC or dual-chip solutions) are manufactured using different technologies based on the application. There are variations on CMOS (complementary metal–oxide–semiconductor) chips, gallium-arsenide (GaAs) chips and the most common—silicon-germanium (SiGe) semiconductors in varying packages turned into modules using LTCC (low-temperature co-fired ceramic) films or PCBs (printed circuit boards).
CMOS variants can include the standard bulk CMOS approach, RF (radio frequency) CMOS and SOI (silicon-on-insulator). Traditional bulk CMOS is used to build the digital-only baseband chip, and then chained to an analog circuit for the Bluetooth radio. RF-CMOS adds the radio directly onto the CMOS chip, and SOI adds an insulator layer between the RF and BB circuits for isolation.
A typical CMOS inverter circuit.
GaAs chips are used in “ruggedized” or military applications, since gallium arsenide devices are more resistant to high levels of electromagnetic pulsed radiation—they can be knocked offline by an EMP, but the component isn't reduced to slag. Since the manufacturing process for GaAs is completely different than CMOS (and far more expensive), most manufactures serving the consumer market no longer develop GaAs chips.
An RF chip made from SiGe has higher efficiency and greater throughput than a pure silicon semiconductor-based radio. The choice of silicon CMOS or SiGe BiCMOS depends on the application—where cost is a factor, a standard CMOS die is used, whereas for applications that require better RX or TX sensitivity/power or low power consumption, BiCMOS is used. The final packaging also depends on manufacturer requirements and final device/application: leaded SOIC (small outline integrated circuit), QFP (quad flat package) or PLCC (plastic leaded chip carrier).
Pictured above are the SOIC package and the BGA package.
Leadless designs (BGA—Ball Grid Array, CSP—Chip Scale Package, WLCSP—Wafer Level Chip Scale Package) are used for devices like smartphones, where small footprints are important and generally present good cost savings over QFP packages.
Qualification, Testing And Certification
Imagine a large room—a conference hall, perhaps—where engineers and representatives from dozens of manufacturers, either collaborators or competitors or sometimes both, bombard each other with Bluetooth signals. This is UnPlugFest, an event organized by the SIG, where manufacturers come to test the interoperability of their devices. Interoperability is a key aspect of the Bluetooth standard, and one of the many tests a device must undergo before it is qualified by the SIG.
Bluetooth Product "to market" process. Courtesy of Texas Instruments.
The SIG imposes qualification requirements in the form of the Bluetooth Qualification Program (BQP), including product performance and compliance with the Bluetooth specifications. Once it passes the BQP, the product must be certified, by the FCC in the USA, CE in the EU, TELEC in Japan, etc. The entire certification cycle can take more than a year, and may cost up to tens of thousands of dollars in testing and administrative fees.
Texas Instruments partitioning qualification and certification tasks for products designed with their pre-certified modules, Courtesy of Texas Instruments Incorporated (TI)
Given the complexity, length and high cost of designing and certifying Bluetooth modules, many manufacturers choose to use a pre-certified module in their final consumer product—laptops are a good example of this. Essentially, if a product uses a pre-certified module, the certificate comes with a very strict set of guidelines as to its maintenance, but otherwise can be used without further testing or qualification.
Major Bluetooth Manufacturers
The first Bluetooth headset designed by Ericsson for Nokia was made by Lucent Technologies in 2002. Lucent merged with Alcatel in 2006, and then Alcatel-Lucent officially joined Nokia in 2016. Since Lucent’s first headset, manufacturers all over the world have incorporated Bluetooth into their designs, or based their businesses entirely around Bluetooth. Sony, Philips, Samsung, Apple—all of these companies are major presences in the Bluetooth landscape. Bluetooth chipsets are generally manufactured by semiconductor companies, and once qualified/certified, incorporated into modules or end-products by the major technology vendors.
That very first Ericsson headset was manufactured by VLSI Technologies, which in turn was bought by Phillips in 1999 and then became a part of the Phillips spinoff, NXP Semiconductors.
Original Nokia HDW1 headset, the first Bluetooth headset on the market.
Other large manufacturers are:
- Texas Instruments
- Cypress Semiconductor
- Cambridge Silicon Radio (CSR)
- Nordic Semiconductor
- Dialog Semiconductor
Broadcom, Mediatek and pretty much every other RF module manufacturer has Bluetooth products to offer. Apart from the nine SIG Promoter companies, the member registry lists thousands of organizations at the Associate or Adopter levels. This is not counting the sub-component manufacturers, multi-million-dollar, publicly traded multinationals like IDT, Xilinx and Microchip Technology, all of whom produce microcontrollers, RF modules, transceivers and other sub-components that are integral to the design of other companies’ solutions.
The Future Of Bluetooth
The phenomenal commercial success of Bluetooth means that neither the standard nor its inherent problems are going anywhere. Vendors will introduce support for a wider range of device classes, especially ones that feature Bluetooth 4.1 Low Energy, designed for the Internet of Things. Bluetooth 4.2 was released in 2014—Apple, Samsung, TI and everyone else is already using this latest iteration that allows for better privacy, speed and IPv6. From the vendor side, expect to see better power management, faster data rates and the possibility of a more advanced modulation schemes in high-end devices.
In terms of the standard itself, there are a number of challenges looming on the horizon for Bluetooth. Congestion in the 2.4GHz band is getting worse. Some of the interference is mitigated by Bluetooth’s adaptive frequency hopping capabilities, and Wi-Fi growth is mostly happening in the 5GHz band. But there should be more emphasis on cooperative interference mitigation strategies in the future. The responsibility (or framework required) to implement such strategies is currently in the vendors’ court, but we hope that eventually the standard will present some recommendations on how to standardize those approaches.
We interviewed Mark Powell, executive director of the SIG, and he believes that Bluetooth is the key to tying together the changes we're going to be seeing in wireless communications. Bluetooth is evolving and building up the strength of its low-energy modes—in February 2016, the SIG announced a new architecture and toolkit to enable “smart” Bluetooth functionality where IoT devices are connected over an Internet gateway. Then, in March 2016, the Bluetooth SIG announced the addition of a Transport Discovery Service (TDS), which provides a common framework for low-energy IoT devices.
Older data exchange applications for Bluetooth are coming under pressure from faster technologies like WiGig. But the SIG envisions Bluetooth as a key enabling technology for such applications. Under a cooperative scenario, Bluetooth could be used to page devices capable of WiGig and other high data-rate technologies, perhaps even controlling the wake/sleep state of those power-hungry radios and establish connections. The low power consumption and ubiquity of Bluetooth makes it ideal for enabling such an adaptive “only when needed” operation scenario for data transfer.
The growth of Bluetooth-enabled devices is accelerating, and 2016 promises another iteration of the specification. By lowering the modulation rate of the Bluetooth signal (and therefore its sensitivity to noise), the standard will improve the data rate and range of Class 2 and Class 3 devices. And, for the first time, we expect to see a large number of new network topologies—for instance, mesh networks and decentralized host-to-host networks directly accessing the WAN. This could lead to a complete shift in the kinds of applications, profiles and capabilities that Bluetooth addresses.
The Internet of Things is at the core of this paradigm shift—Bluetooth-equipped light bulbs, Bluetooth door locks, devices acting as relays without a “master”—devices capable of networked operation will hit the market in droves, and soon. Perhaps foreseeing the problem of Bluetooth devices without any capability for input (how do you enter a PIN into a light bulb?), the SIG’s newly released architecture and Bluetooth gateway services will enable the setup and control of these networks over the internet.
We anticipate smart-bulbs and smart appliances, and perhaps smartphone and Web-based apps for control, similar to the capabilities of smart Wi-Fi router apps. This does mean that, in certain cases, Bluetooth’s greatest security strength, the fact that attacks need to come from a physically proximal source, will be negated by direct access of Bluetooth-enabled devices to the Internet. The specification requires 128-bit AES encryption, but the responsibility for dealing with more involved security scenarios is probably going to remain at the application layer, and firmly on the shoulders of device vendors.
Bluetooth mesh network for low-power devices, courtesy of the Bluetooth Special Interest Group
Still, we believe that the most exciting developments in Bluetooth will come from the new network topologies. Mesh networking...mesh networking for everything! New topologies open up a vast array of possibilities for information sharing, research and data transport protocols. With a 400% increase in the range of Bluetooth Smart, and a 2.5x increase in data transfer speeds, with battery demands met by button cell batteries, 2016 and 2017 hold the possibility for new classes of end-products we have never seen before.
MORE: Wireless Routers 101
MORE: Router SoC 101
MORE: All Networking Content
MORE: Networking in the Forums