Bluetooth® Low Energy – Deep Dive part 1

Sandra Capri
June 13, 2024

What is Bluetooth®? BLE? Bluetooth® Mesh? Are these all the same thing, or are they different? These are all good questions that will be addressed in this blog entry. We’ll start with an overview, and then link to other blog pages for more information (otherwise this will be a huge blog page!)

Please note that Bluetooth® is a registered trademark of the Bluetooth® SIG (and so we have shown this trademark symbol in references up to this point; but for simplicity, the rest of this blog will reference Bluetooth, BLE, or BT without the trademark symbol).

Bluetooth – Overview

Does it really have anything to do with teeth that are blue? Well, only in the sense that there was a king named Harald who is rumored to have a bad tooth that appeared blue-ish. This king supposedly united tribes, just as in the same way, Bluetooth is to unite devices. The Bluetooth logo is a combination of his initials: ᚼᛒ. [1]

The general idea of Bluetooth is that it is a way for two devices that are fairly close together to wirelessly talk with each other – short range radio communication. By short range, we mean that it is normally around 30 feet, but some applications go up to 300 feet, and long range has the potential of extending the range to 3000 feet or more. [2]

Bluetooth uses the radio frequency in the 2.4GHz band – this is part of the unlicensed ISM (Industrial, Scientific, and Medical) band. It all started out with what we now call Bluetooth Classic.

Bluetooth Classic

Starting in the early 2000s, mobile phones and computers communicated with Bluetooth devices using the Bluetooth Classic protocol. This protocol uses 79 channels, and is very commonly used by the ubiquitous Bluetooth headphones, speakers, and telephone headsets (though this is changing – more on this later).

This protocol has gone through several versions. By the time Bluetooth 4.0 was released, the SIG defined four controller technologies: BR, EDR, AMP, and LE. We will follow the common convention of lumping together BR, EDR, and AMP into the “Bluetooth Classic” category, and LE as the Bluetooth low energy (BLE) category. [3]

A device (like a smartphone) that can communicate with BLE and Bluetooth classic devices is a dual-mode device. Note that Ambient Sensors specializes in BLE, so there is minimal discussion about Bluetooth Classic on our website.

Sidebar: Bluetooth Classic

What do these acroynms mean?

BR – Basic Rate
EDR – Enhanced Data Rate
AMP – Alternate MAC/PHY

The reason for mentioning these acronyms: going through the Bluetooth specification, you may see reference to these. When you see them, you know that they are referring to Classic Bluetooth, and you can ignore them if all you care about is BLE.

BLE (Bluetooth Low Energy)

While BLE uses the same frequency range as Bluetooth Classic (the 2.4GHz band), and is contained in the same Bluetooth specification documents, Bluetooth classic and BLE don’t communicate with each other. As was mentioned earlier, Bluetooth Classic uses 79 channels, but BLE uses 40 channels. One of the reasons for the creation of BLE is the desire for devices to use less power – which enables devices to be battery powered (hence the LE in the acronym). In the following sections, I’ll just be covering some of the basics of BLE, and I’ll describe how that applies to Bluetooth Mesh.

Connections or Broadcast?

Much of the information in this blog entry is contained in the Bluetooth SIG whitepaper “The Bluetooth Low Energy Primer” which I highly recommend as a starting place for those wanting to learn BLE [4].

A BLE device communicates by transmitting and receiving packets of data. In general, these packets of data are interpreted as being communication in a connection or a broadcast/advertisement:

Connection (point-to-point, one-to-one communication) – a device (central) has created a connection to another device (peripheral). They negotiate the best way to communicate at specific times on specific channels. They communicate through this connection through optional encryption.
Broadcast (connectionless, one-to-many communication) – a device (advertiser) sends out BLE advertisements which are heard by another device (scanner). There is no negotiation, but instead the advertiser sends the data out on the three BLE channels that are reserved for advertising. Any scanner that is interested in the data will monitor the advertising channels to receive the broadcast data. Traditionally, the data being advertised is unencrypted, but please note that in version 5.4 of the Bluetooth Core Specification, encrypted advertising data is now part of the spec – this is for the times when security of the advertised data is needed. [5]

Connections – how to communicate

A device that is designed to be a peripheral will advertise for a connection to a central. When a device (like a cellphone) that wants to connect receives the advertising packet, it will send a packet to the advertising device asking to connect. At that point, the advertising device becomes the peripheral, and the device asking to connect becomes the central.

So a smartphone connected to a fitness tracker received an advertising packet from the tracker, initiated a connection, and became the central device in this point-to-point connection. The central generally decides what kind of data it wants from the peripheral device. The fitness tracker is the peripheral, and responds to commands, and sends the requested data (or any asynchronous alerts) to the phone.

The smartphone may also be connected to other peripherals at the same time – a central can have connections to multiple peripheral devices. The number is of connections is resource-limited by the phone (software, memory, etc.). The peripherals are unaware of each other – the central is independently communicating (sending and receiving) with the peripherals.

Note the green lines in these diagrams – they are designating a BLE connection. But of course these are radio broadcasts – so any device listening can “hear” the data. If the data is encrypted, only the central and each of its peripheral devices, respectively, are able to understand the data. This security is the reason that Ambient Sensors strongly recommends using standard BLE encryption (LE Secure connections).

When a smartphone connects to a BLE device, it has set up a point-to-point connection. A connection is one-to-one communication: the peripheral is sending data to the central. No one else will be talking to the peripheral on that connection. Until the central and peripheral break the connection, generally no other device would be able to connect to the peripheral.

The word “generally” is underlined, since, in truth, there are other cases that are a bit more unusual. The normal case is for a peripheral to only support a single connection with a central. It is also normal for a central to connect to one or more peripherals. For more details on the unusual cases, see the sidebar.

Sidebar: a device could be designed to:

have the role of a peripheral for multiple different centrals – the peripheral would then allow different centrals to connect to it, but each connection is independent (i.e., the centrals would not know about each other).
have the role of a peripheral for a central(s), and also take on an independent role as a central to connect to other peripheral(s). But each connection is independent.

How does communication happen between a central and peripheral?

Every BLE peripheral contains a service(s) and characteristic(s). When a central wants to talk to a peripheral, it writes/reads those characteristics.

Most peripherals have multiple services, to allow for different functionality (multiple behaviors). What does that mean from a practical point of view? The peripheral is notified when characteristics are written, and can take action based on the values written. When a characteristic is read, it sends back the appropriate data. Additionally, the peripheral can asynchronously send data to the central with a characteristic notification or indication.

Take the example of a mobile phone (a central) that has connected to an Indoor Positioning Sensor (a peripheral). If the user wants to know the location of the sensor, the phone reads the Latitude and Longitude characteristics (these are just two of the characteristics in the IPS service). The phone app knows the format of the data for the IPS service’s characteristics, and displays the information to the user in the expected format. Similarly, the app could write to various characteristics.

What do these terms mean: service and characteristic?

Service – a service is a “collection of data and associated behaviors to accomplish a particular function or feature”… [6]. You can consider a service to be a collection of characteristics.
Characteristics – You can kind of think of these as locations on the peripheral that allow the central to write values to the peripheral, or to read values back from the peripheral.

The BT SIG has defined some standard services and characteristics that are in common use, and additionally, companies can define custom services and characteristics to pass all kinds of data back and forth between the central and peripheral. It’s a nice, straightforward interface for communication.

How does the central (the phone app, in our case) know what services and characteristics that a BLE device has? When a central connects to a peripheral, the central asks for a list of the available services on the peripheral. If the services are defined by the BT SIG, the writer of the app code on the central will have the BT SIG specifications. This will provide information about the purpose of the service, and how to read/write the characteristics to use the peripheral.

Example:

When a central discovers that a peripheral contains the SIG standard Health Thermometer Service (HTS), the central knows that the values it is receiving are the temperature values defined by the SIG. The central can use the service as defined in the HTS specification.

But if the service(s) are custom, then the app writer of the central central will need to acquire the custom specification to know how to communicate to the peripheral – the characteristics are specific to that service. For example, consider a central that connects to a peripheral and sees two custom services with several characteristics. If the central doesn’t know what the services are, it can try reading and/or writing the various characteristics, and setting up notifications/indications, but the central may not have any clue as to the meaning of these values that it’s sending or receiving.

Broadcast (Advertisements)

If a device is designed to communicate without connections, it will advertise the data it wishes to communicate. These devices are often called beacons. A beacon could advertise the price of a product, the temperature, time of day, or whatever information it was designed to advertise. Any scanner (e.g., mobile phone) could receive that information and utilize it.

If the device is only broadcasting (beaconing), and never turns on the radio for listening, there is no chance for a connection. This means the device is only sending information. In the diagram below, you see 4 scanners – receiving the data from the advertiser (beacon)..

Since it is an advertisement (i.e., one-to-many), there is no connection needed, or available. So even if there are hundreds of scanners listening at the same time, all of them can potentially receive the same data. There are no services or characteristics. This is a great advantage over a connection if the data needs to be made widely available to as many people as possible.

Implementing all of this – the BLE Stack

Whew – that’s a lot of info – how in the world can anyone write all this code in a peripheral to implement all of that? It seems like a lot to implement, and it would be, but the majority of that functionality is contained in the BLE stack (which is normally provided by the BLE chip manufacturer).

As mentioned earlier, BLE communication uses packets – the payload (the information you want to transmit), is formed into PDUs (Protocol Data Units) which are put into BLE packets and sent/received by BLE devices. How does the application know how to put things into packets and send them to the other device? Well fortunately, the BLE stack knows how to do all of that.

diagram of the BLE stack - showing the different layers that BLE uses. — BLE stack

If you are familiar with the OSI networking stack, this is similar. The stack divides the functionality of BLE into layers. The application, at the top, decides what data it wants to send, and sends that to the layer below, which puts things together, and sends to the layer below it, etc, until the packet is completely built up, and ready to be sent out.

Each layer of the stack has specific functionality to perform. For example, GAP is responsible for finding and connecting to devices, or communicating without connections (defining the roles of Broadcaster, Observer, Peripheral and Central). GATT and ATT are responsible for transferring data once the connection has been made (GATT:defining services and characteristics, ATT: defining servers, clients, and attributes). Each layer, properly doing its job, takes data that the application layer wants to send, and ends up creating a packet that the PHY transmits to another BLE device. That BLE device, receives that packet, and sends the data up the stack, until the application layer receives it, and can figure out what to do with it.

Bluetooth Mesh

Well, now that we have discussed how BLE works, now we are going to launch into a discussion of the Bluetooth Mesh (hereafter called “Mesh”). Mesh is a network of devices – and it uses BLE to communicate between the devices.

Bluetooth Mesh networks have the advantage of extending BLE’s communication range – every device that is part of the Mesh can hear and retransmit every message it hears, allowing communication to span the entire length of the mesh.

Consider the example of a building that has implemented Mesh. Every light in the building is a Mesh device (called a node), as is every light switch in the building. A switch at one end of the building can send a message to turn off all lights in the building. The message is received by the lights (nodes) that are closest to the switch, and those lights forward that message to the next set of lights within BLE range, which send the message to the next set of lights, etc., until all of the lights in the Mesh have received the message to power off (and all the lights go out). Excellent – no longer do we have to rewire the building to add a switch, or change how a switch works!

Mesh is an excellent network for lights, but it can do so much more. Imagine ambient light and motion sensors connected to the Mesh – with that kind of information, the lights can turn on or off based on occupancy, or they can dim or brighten based on the amount of ambient light available.

Then we can go even further – let your imagination go wild. What else could we connect to our Mesh? What about fire alarms and burglar alarms? You can have a burglar alarm controller in one area of the building, and it can receive data from all of the motion sensors throughout the building.

And a fire alarm controller can receive data from all of the smoke sensors. Then either the fire alarm controller or the burglar alarm controller can ring alarms on the network (in all areas of the building), or send out a call for help (police, fire department, etc.). The nice thing about having a Mesh network of lights is that it’s a general-purpose Mesh network. Anything you want to add to the network is now interconnected. Even if the burglar alarm controller is a long distance from the motion sensors – it can still communicate through the network because of the lighting nodes.

There’s so much that Mesh can enable. You are only limited by your imagination (and data rates – Mesh’s target is for small amounts of data, not streaming audio or video).

Also, please note that Mesh specification requires security – and multiple layers of it – it is not an optional feature like it is in BLE. So by using this network to control/monitor your home, office building, complex, etc., you are not opening up a big security hole.

Please note that Mesh is different from the previous discussion of BLE connections – since as we saw, those are dependent on point-to-point connections (the central to the peripherals), which are not part of the Mesh. There’s a good reason for that, and I’ll be discussing that in a more in-depth discussion of Mesh: the Mesh deep dive (coming soon).

Bluetooth LE Audio

As was mentioned earlier, Bluetooth Classic is ubiquitous in the world of wireless audio – there are Bluetooth Classic headphones, earbuds, and speakers commonly available around the world. But is that changing?

Bluetooth LE Audio – streaming audio may someday replace Bluetooth Classic’s hold on audio. LE audio has some pretty amazing features:

Support for very low latency audio transmission – enabling hearing aids
Connected secure audio
Broadcast audio for all
Encrypted broadcast audio

The available features of LE audio are actually pretty impressive. For a more in-depth discussion of LE Audio, pleased stay tuned for an LE audio deep dive (coming soon?).

BLE is a big topic, and there is a lot more involved that I haven’t even begun to discuss.

For a more in-depth discussion of BLE, there are many good resources – here’s a few good links:

Excellent article by Kevin Townsend:
https://learn.adafruit.com/introduction-to-bluetooth-low-energy

Video by Mohammed Afaneh:
https://www.youtube.com/watch?v=JSQhRyTKnW4

BLE Primer by the Bluetooth SIG:
https://www.bluetooth.com/bluetooth-resources/the-bluetooth-low-energy-primer

And of course, the core specification [6].

Endnotes

[1] https://www.bluetooth.com/about-us/bluetooth-origin/

[2] https://blog.nordicsemi.com/getconnected/things-you-should-know-about-bluetooth-range

[3] https://blog.nordicsemi.com/getconnected/the-difference-between-classic-bluetooth-and-bluetooth-low-energy

[4] https://www.bluetooth.com/wp-content/uploads/2022/05/the-bluetooth-le-primer-v1.2.0.pdf

[5] https://www.bluetooth.com/wp-content/uploads/2023/02/2301_5.4_Tech_Overview_FINAL.pdf

[6] Bluetooth Core specification v5.4

https://www.bluetooth.com/specifications/specs/core-specification-5-4/