Bluetooth Classic is the wireless protocol that's been ubiquitous for almost 15 years. Bluetooth Headsets, Speakers, Smartphones, Smart watches and many devices use a Bluetooth radio to communicate. While in 2010 the standard was updated with Bluetooth Low Energy, we're going to talk about Bluetooth Classic, the original radio protocol that is still widely used for streaming audio and voice.
The Bluetooth standard was born out of necessity of creating a wireless connection between computers and devices. In the late 90's it was clear that computers would require wireless connectivity for a host of devices.
The basis for Bluetooth (now usually referred to as Bluetooth classic to distinguish it from Bluetooth Low Energy) was developed in the late 90's. In 1998, the Bluetooth Special Interest Group (Bluetooth SIG) was formed among a consortium of companies to push the standard. It took several years for the companies to come together and settle on a specification.
The first official Bluetooth specification adopted was Bluetooth v1.0, but it wasn't really until Bluetooth 2.0 that it began solidifying. The 1.0, 1.0b 1.1 and 1.2 Bluetooth specifications contained various bugs, limitations, or lacked features that were needed for users.
Bluetooth 2.0 resolved significant issues and introduced the Enhanced Data Rate mode which had faster modulation and allowed up to 3Mbps throughput. This enabled higher quality audio. The Bluetooth 2.1 + EDR specification is the spec that forms the basis for Bluetooth Classic, and the technology has stayed mostly the same since. Bluetooth 2.0 didn't have any real security and 2.1 brought Secure Simple Pairing. You're probably familiar with it by the pairing pin you need to type when pairing a Bluetooth device to another.
Despite all the changes in the Bluetooth specification - the latest is Bluetooth 5.2 - the Bluetooth Classic has remained the same since Bluetooth 2.1 + EDR was released in 2007. Bluetooth 3.0 introduced the High Speed (HS) mode, which allows a Bluetooth paired device to use Wi-Fi or another medium (PHY) to transfer the data.
In Bluetooth 3.0, Bluetooth creates the connection and then the data transfer uses a different protocol like Wi-Fi. But this never really got deployed widely and Bluetooth 3.0 specification is not common. We sometimes see manufacturers claim compliance with the Bluetooth 3.0 specification, but in effect this is a v2.1 device.
The Bluetooth protocol assured backwards compatibility, so users typically don't have to worry about having the exact version of Bluetooth. The downside is that features are limited by the device with the oldest specification. Overall it works extremely well and users rarely have compatibility issues.
Since the introduction of Bluetooth Low Energy in the Bluetooth 4.0 specification, there are basically two different radios in Bluetooth. Because of this, it's important to understand what the radio supports. A Bluetooth 5.0 or 4.0 device could support Bluetooth Classic, Bluetooth Low Energy, or both (called Dual mode devices).
Here we will discuss Bluetooth Classic. You will also see Bluetooth Classic called BR/EDR since that is the modulation schemes it supports. If you read about BR/EDR, you will know this is a Bluetooth Classic capable device.
It's important to know that all specifications before Bluetooth 4.0 are now withdrawn. Meaning, qualifying a product (getting it certified with the Bluetooth SIG) costs more or may not be possible. If you're looking to develop a product with Bluetooth Classic, it would be best to use a recent radio that has Bluetooth 5.0 support.
Now that we understand more about where Bluetooth Classic stands, let's start diving into the actual radio.
Bluetooth Classic uses two general modes to transmit data:
The transmit power of Bluetooth devices is defined into multiple classes:
While we've seen a lot of claims about Bluetooth range, the range of Bluetooth devices depends on many factors and the output power is only one piece of the equation. So while we've seen claims that Bluetooth can reach 100m, Bluetooth Classic is typically shorter range, especially for high end audio streaming. The actual range of Bluetooth depends on the design, the modulation used, and the environment.
Basic Rate is the standard BR radio modulation with 1Mb/s air data throughput. This is the maximum over the air throughput and doesn't account for protocol overhead. Because the rates needed to transmit voice and sometimes video are high, Enhanced Data Rate (EDR) was introduced to provide 2Mb/s and 3Mb/s rates that would allow high end CODECs to operate.
Even though BR uses 1Mb/s GFSK, just like Bluetooth LE, they are not compatible. There are modulation and RF channel differences and the radios can't communicate with each other. When enabled, Enhanced Data rate works hand in hand with Basic Rate. When using EDR, parts of the packet are sent using BR 1Mb/s, while the rest of the packet including the payload, are sent using EDR data rates.
The higher data rates of Bluetooth BR/EDR help it carry audio, video and high data rate transmissions. High quality audio requires high data rates, which BLE can't generally provide. This has changed somewhat with Bluetooth 5.2 that introduces LE Audio, but we expect Bluetooth Classic will be popular in the long term.
Bluetooth Classic uses the 2.4GHz ISM band. This band is available worldwide, which means that users can use Bluetooth anywhere in the world. The 2.4GHz ISM band extends from 2400MHz to 2483.5Mhz, but Bluetooth and many other systems only use 80MHz of the bandwidth.
This bandwidth is divided by Bluetooth into 79 channels, each spaced 1MHz apart, starting from 2402MHz up to 2480MHz. The channels are numbered 0 to 78.
One of the goals of Bluetooth is to avoid interference. The number of channels and the adaptive frequency hopping algorithm help prevent interference from many sources. Since the 2.4GHz band is unlicensed, there are many transmitters nearby like baby monitors, Wi-Fi, and Microwave ovens
Bluetooth creates point-to-point or point-to multipoint connections. In practice though, the Single Slave or Multi-slave approaches dominate. For example, an iPhone connected to a Bluetooth Headset. Bluetooth can form complex networks where a slave may be connected to two different masters.
The main form of the topology in Bluetooth is called a piconet. A piconet has a single master that has a master clock and can have up to seven slaves. When piconets share slaves (or masters that act as a slave in another piconet), they form what is called a scatternet. Piconets are not synchronized and each has its own hopping sequence.
The diagram above shows the packet format for both Basic Rate and Enhanced Data Rate. As we mentioned before, the EDR packet sends the Access Code and Header using the basic rate, then the guard time gives it time to change modulation. The Sync, payload and Trailer are sent using the modulation format.
One of the most critical aspects of Bluetooth is the Clock. The master device in a Bluetooth connection has a clock that is used to split the time on each physical channel. All slaves in a connection have clocks that are synchronized to the Master clock.
Synchronizing the clocks on Bluetooth is critical because the radios need to sync up on when they transmitt. Because Bluetooth uses precise timeslots for transmissions with the devices alternating, if the clocks are not synchronized there could be issues with devices transmitting at the wrong time.
As we mentioned, there are 79 RF channels. Bluetooth radios use these channels to transmit using a pseudo random frequency hopping algorithm. In addition, this algorithm is adaptive and the channels to be used are dynamically updated at run time depending on interference. Because of this, Bluetooth is said to use Adaptive Frequency Hopping, commonly called AFH. This technique allows it to avoid significant interference in the 2.4GHz band. It also enables multiple Bluetooth systems to coexist in the same space. Bluetooth hops up to 1600 hops per second.
In order to transmit, Bluetooth devices use at the start of a packet the Access Address. The Access Address is 48-bit and is based on an OUI and address space allocated by the IEEE.
While Bluetooth jumps through multiple channels, each channel is divided into 625 μs timeslots. The Master and slave alternate sending data. The master sends data in the even timeslots, while the slave sends data in the odd timeslots. Because 625 μs is relatively short, specific packet types can agregate multiple time slots. The largest packets can transmit in 5 timeslots.
Sending data in larger packets is more efficient, because there's less overhead, so that helps with higher quality audio applications.
The diagram above shows the states of a Bluetooth Classic Link Controller
When in a connection, some of the states are:
Every Bluetooth device starts at Standby. If a Bluetooth device wants to connect to another device, the only thing it needs to know is the Bluetooth address. If it has the Bluetooth device address, it can start the Page procedure and "Page" the device so both can connect. This process can take some time, but can be sped up if there is information about the clock or page mode of the device we want to connect to. While the Master initiates the Page, the Slave needs to be in the Page Scan mode waiting for paging events. The device that starts the connection using the Page procedure is automatically the Master of that connection.
In the Page procedure, the master sends a paging message with the slave's Device Access Code (DAC) in different channels it is hopping across, listening in between the transmissions for a response from the slave. The issue, and one of the reasons Bluetooth connection establishment takes time is that the clocks of both devices are not synchronized. The slave wakes up to receive packets at different periods, so this can take time.
Paging can be done from Standby, meaning there aren't any active connections, or from the connection state. Paging is a pretty demanding process, and because of that, it can have an impact on the performance of the active connection. Bluetooth controllers may put the active connection on hold, reduce retransmissions or other things. Because of this, connecting to other devices must be done carefully.
In the discussion above we assumed that we already had the Bluetooth address of the device. Obviously, when connecting to a completely new device, that won't be the case. So how do we find devices? Bluetooth uses the Inquiry procedure and Inquiry Scan. One device enters the Inquiry state and begins sending inquiries. The device we want to connect to needs to be discoverable, which means it enters the Inquiry Scan.
Since power consumption is a critical aspect in most Bluetooth devices, it's important to reduce this. Listening and communicating on every time slot will use a lot of power. So a specific mode called Sniff allows a slave in the piconet to reduce its activity and avoid listening at every time slot. Sniff Subrating is an additional mode that is interleaved with Sniff mode and reduces even further the sniff anchor points.
The Bluetooth Hold state is a temporary mode that allows a slave to save on power. When a Bluetooth device is placed in Hold mode, the Master and Slave agree on a wakeup time. The slave will then wake up after the specified amount of time.
You may have seen reference to the Bluetooth Park state. This state allowed a slave to reduce its activity if it didn't need to participate in the piconet channel but still wanted to remain synchronized. Aside from very low power consumption, Park was one way to technically have more than 7 slaves. The 7 slave limitation is for active devices in the connection state, but switching devices to parked allowed new devices.
In the parked state, the slave that's parked wakes up periodically to check for broadcast messages to synchronize with the master. The master uses a beacon train to do the synchronization.
The parked state is now a deprecated feature as of Bluetooth 5.0.
When the discovering Bluetooth device enters the inquiry mode, it attempts to discover all devices nearby that are discoverable by collecting the inquiry responses. Devices are not forced to answer the inquiry. The Inquiring device gets the Bluetooth addresses and clocks of all the devices that respond, but the device can also get the Extended Inquiry Response (EIR) that contains local name and services if the discoverable device provides it.
If you've ever opened the Bluetooth Settings screen in an iOS device or Android and find some devices, they're showing up because when entering that screen the phone starts the inquiry process and is collecting data.
Like the Paging State, the Inquiry state can be entered from the Standby mode (no current connections) or from the Connection state. As with paging, performing an inquiry during a connection puts certain demands on the timing and radios.
One of the downsides of the Inquiry procedure is that it may take up to 10.24s to fully complete (unless terminated earlier). This is assuming no interference. The inquiry can require longer time to find the actual device. This is one of the reasons Bluetooth Classic takes time to form a connection.
Bluetooth has to support multiple types of data to be sent between Master and Slave. Each type of data has different requirements. For example, Audio has to be sent at a consistent rate and with little latency and packet losses. But there is also data where some delays are not a problem. To deal with all these, Bluetooth defines five logical transports, of which the mains are:
SCO transport is point to point between the slave and master and is used to transport voice or audio data that requires a time bound, limited latency. SCO uses a set of reserved slots and never re-transmits its data.
eSCO is like SCO except that it supports retransmitting the data after the reserved slots.
ACL transport is point to multipoint between a Master and all Slaves in a piconet. Because of this, ACL packets are not addressed to a specific slave. It allows for packet retransmission. ACL doesn't need to transmit every time if there is no data to send.
The transports like SCO, eSCO and ACL use specific types of packets to send their data:
The packets are further broken down into even more specific types. The following are the packets for SCO which don't include any Message integrity (MIC) or CRC and are not retransmitted. You will notice that SCO doesn't have any packets starting with 2 or 3 in their name. That's because SCO is only supported in Basic Rate (BR)
eSCO uses the EV packet types and has different types depending on whether one uses Basic Rate or Enhanced Data Rate:
ACL also defines several packets it can use. The following packets are defined for Basic Rate transmissions
For Enhanced Data Rate, the following packets are used
The first number for the Enhanced Data Rate packet formats indicates the EDR modulation used (2Mb/s or 3Mb/s). The second number indicates the number of timeslots that the packet uses, such as 1 (for 2-DH1), 3 (2-DH3) or 5 (3-DH5).
Why do the packets matter? Because the larger packets that take more timeslots allow for much higher packet efficiency. Higher quality audio requires higher datarates, and packing as many bytes on every packet helps. On the flip side, the higher data rates require modulation like EDR 2Mb/s or 3Mb/s which are more sensitive to interference and low signal. This is one of the reasons why Bluetooth can be challenging and why understanding what's actually happening in a connection is critical.
The LMP porotcol is the protocol that manages and negotiates the Bluetooth connections between a Master and Slave, including all the logical transports and logical links. Each device contains a Link Manager (LM) that sends and receives LMP messages. LMP messages are exchanged over the ACL-C logical link that is carried by the ACL logical transport. These messages also have higher priority than other traffic on this channel.
The LMP protocol controls everything and is the main control mechanism for everything including pairing, clock adjustment, security, AFH control, etc.
Now that we understand a little more about LMP, we can discussion pairing and bonding, which most will be familar with. Pairing is simply exchanging data to create a security key for encryption. Bonding means storing that information.
For example, let's say that you have an iPhone and you've paired and bonded it to your Bluetooth radio in your car. The bonding part is done automatically on both sides. So, when you walk into your car, the connection is automatically restored and is secured.
Before the pairing process is complete, there is an authentication process. Technically there isn't a way for a device to know if the other side it's talking to is the one you're holding. The car can't know your iPhone is actually your iPhone. To address this, an authentication procedure is done that depends on the IO capabilities of devices. For example, your iPhone and your car can display the same number, which can allow you to confirm both devices are talking to each other. There are a few options
On top of all the Bluetooth layers sit the profiles. These profiles are
While there are many other Bluetooth profiles, most devices use the profiles above. Note that A2DP builds upon the Generic A/V Distribution Profile (GAVDP).
The profile to choose will depend on the product use case. Multiple profiles can be used, although there are limitations on how they operate due to bandwidth and other constraints.
If you look, you will find that the number of companies that provide Bluetooth Classic capable devices is not very large. One of the main reasons is that Bluetooth is a relatively complex solution that requires significant investments. Today's biggest Bluetooth players also have a long history in the area, and given how Bluetooth has evolved, most new entrants have gone to develop Bluetooth LE (Single Mode) devices only.
One of the largest chipset providers is Qualcomm which acquired CSR plc a few years ago. CSR chipsets were used in volume in headsets and a multitude of applications. Qualcomm and Realtek tend to dominate audio related applications, which are the highest volumes one.
TI has been offering the CC256x chipset, such as CC2564C for a long time. This is a Bluetooth Controller device that requires a microcontroller to run the host stack. An advantage of this device is that it's publicly available and well known. It also still has good RF performance, even compared to some newer device. It's a great device for many application, especially industrial devices.
Some of the best devices that are not Audio centric are made by Cypress Semiconductor. Cypress bought the IoT connectivity business of Broadcom, and the chipsets are extremely good.
For some applications, Bluetooth Classic is the clear choice. Audio streaming to speaker, headsets and other devices. The latest LE Audio features of Bluetoot 5.2 may meet what you need, but this will take time. Bluetooth Classic will continue to grow and improve.
Picking the right Bluetooth Classic chipset can be difficult because there are many options and it's application dependent, but after the chipset is selected, building a product comes down to properly designing the system, especially the RF.
As with any design, it's critical to test the Bluetooth design and ensure the RF and antenna works well.