Bluetooth Low Energy Basics – ‘The Story of King Harald in a Nutshell’

King Harald Bluetooth had one idea – to unify Denmark and Norway’s lands in the 10^th Century. The Bluetooth wireless short-distance technology has a similar idea – unifying different technologies such as computers, mobile telecommunication, printers, and digital cameras. Here also begins our story, Bluetooth Low Energy Basics.

Introduce to BLE

The Bluetooth Low Energy (BLE) standard was started by the Bluetooth Special Interest Group (Bluetooth SIG) in 2010 as BLE4.0. It mostly responded to the Bluetooth Classic standard disadvantages (increasing cost and power consumption, lack of customization, only point-to-point direct communication). The BLE4.0 was introduced to face battery-powered, low-power, wearable devices, sensors, and customized devices. Up to 2014, there were several upgrades to the BLE4.0 standard, such as the size of the packets and better security or privacy features (BLE4.1-4.2).

The Bluetooth LE standard revolution started in 2016 when BLE5.0 was introduced. Compared to the previous revisions, BLE5.0 had two times faster speed (2 Mbps), four times wider range (1 km), and eight times more data size of the advertising packets (254 bytes). In 2017, BLE5.0 introduced mesh topology capabilities that allow every device to talk to each other directly (over the same network) or indirectly (over proxy or friendly nodes).

The BLE5.0 standard surprises its users almost every year with new features such: a direction-finding Angle of Arrival (AoA), Angle of Departure (AoD) (BLE5.1 – 2019); Audio LE streaming using isochronous channels (BLE5.2 – 2020), Enhancement Periodic Advertisement (EPA) (BLE5.3 – 2021) or Periodic Advertisement with Responses (PAwR) (BLE5.4 – 2023) [1].

How it really works

This part is mostly dedicated to low-level engineers (both hardware and embedded software) and can be omitted by high-level software engineers, such as back-end or front-end mobile and desktop application developers (but I promise to also give them a junction of knowledge in a pill).

The Physical Layer (PHY) of the BLE stack protocol configures the physical parameters of the radio transmission and reception. It determines how a bit (and its value) is represented over the air. The BLE PHY operates the radio in a 2.4 GHz Industry-Medical-Scientific (ISM) Radio Frequency (RF) range. The radio uses 40 RF channels separated by 2 MHz, which means the usable bandwidth is 1 MHz on each side of each RF channel.

There are three primary channels (37-39) assigned for advertisement only and 37 secondary channels (0-36) foreseen for general purpose data (also enhanced advertisement), as seen in Fig. 1.

The BLE PHY can dynamically switch between RF channels, starting from 2.402 GHz and finishing at 2.480 GHz. Adaptive channel switching is possible thanks to the Frequency Hopping Spread Spectrum (FHSS) algorithm. The signal transmitted by the radio can vary from 100 mW (+20 dBm) down to 0.01 mW (-20 dBm). On the other way, the minimum receiver sensitivity should not be lower than -70 dBm. The maximum theoretical data throughput for 1 M PHY (BLE < 5.0) is 1 Mbps (practical data throughput is ca. 700 Kbps). The data throughput increases up to 2 Mbps theoretically (1.4 Mbps practically) for 2M PHYs (BLE ≥ 5.0).

The BLE 5.0 standard also introduces Coded PHYs that can make long-range communication but with much lower speeds (up to 500 Kbps theoretically and 400 kbps practically for Coding scheme S=2, which means two symbols are coded per single bit). This limitation comes mainly from the usage of Forward Error Correction (FEC) algorithms that allow sending data over long distances of more than 1 km line-of-sight!

The BLE radio modulates data using a 2.4 GHz frequency carrier. The Gaussian Filter Frequency Keying (GFSK) modulation is commonly applied for all Bluetooth devices. From the RF basics, we know that in the modulation process, we have two components: In-phase (I) and Quadrature (Q). The IQ data represent our signal in Cartesian coordinates. In order to send IQ data over the demanding medium, i.e., air, we have to modulate them into the higher frequency carrier.

This process is commonly done by multiplying the IQ envelope by the local oscillators shifted in phase by 90 degrees. In the typical FSK modulation scheme, a carrier’s frequency change by a small frequency deviation (F_d) means a change in a bit from 0 to 1 and vice versa. For the GFSK, the special Gaussian filter is activated before the modulation stage in order to debounce any spikes when switching from 0 to 1 and 1 to 0 logical states.

For the BLE LE devices, a 2x GFSK modulation is mostly implemented. It is accomplished with differential encoding of F_d. When F_d is smaller than a carrier, it means a logical bit 0. When F_d is higher, it means logical bit 1. The RF techniques used are explicitly explained in Fig. 2.

The received signal demodulation is done by applying a bandpass filter that cuts out the carrier frequency and leaves it for fast digitizer (ADC) as a baseband signal (IQ envelope). In most cases, the typical RF front-end supporting radio and application processors is a hard-coded part of the Integrated Circuit (IC).

The typical RF front-end is composed of a BLE controller (it can also have controller of other standards such WiFi, ZigBee, Thread), BLE modulator and demodulator, analog-to-digital (ADC) converters and Band-Pass (BP) filters, phased-locked local (PLL) oscillators, Power Amplifiers (PAs) for transmitter and Low Noise Amplifiers (LNAs) for receiver sections as shown in Fig. 3.

We know how BLE hardware is working now, how the physical bits are encoded and decoded into the RF signals that are next transmitted and received over the air. But how is BLE working in general? In order to answer this question, we have to look more deeply into the BLE core specification [5]. In principle, the BLE devices advertise their attributes (as peripheral devices), scan, discover, and finally connect to the advertising devices (as central devices).

This is the most basic point-to-point direct connection, and it is also supported by Bluetooth Classic [5]. Besides this fact, the BLE also supports one-to-more (broadcasting) as well as more-to-more (mesh) communication schemes.

The typical topologies BLE devices support are listed below:

1. The Ad Hoc network allows only point-to-point communication; a single-point failure means the whole network failure.
2. The Star topology network is created when a single central device, such as a router, communicates with several peripherals by sending requests and receiving responses. A central device allows communication with each other. The communication can be done only over the router. If the peripheral fails, the whole network can still communicate, only losing the failing node functionality. When the central fails, the whole network will fail.
3. The Mesh topology network means that all devices communicate with each other. It can be full mesh (every node is linked to every node) or partial, where only some nodes are connected. The single node failure is self-healed because other nodes can still communicate, losing only one path of possible connection. The network is the most advanced one, but it has the longest delay; it is hard to set up and difficult to control.

How can all this communication and topologies happen? The answer is simple: over the protocol stack divided into abstraction layers.

The Bluetooth LE Stack

This section will be interesting not only for the hardware level but also for the high-level application developers. The typical peer-to-peer (n-th layer can only exchange data units with its peer entity at the same level) protocol stack is composed of layers. The idea behind the layers and abstraction they create is to treat them as black boxes for others.

The layer we want to communicate with only has to provide us with a so-called application programming interface (API). We do not really need to have a big knowledge of this layer functionality and its implementation. We only have to know what the layer should basically do with our data and how to provide the correct data in a format recognized by this layer. The corresponding layers communicate using physical and virtual channels.

The physical channel is commonly used by the lowest level layer of the stack (in most cases, it is hardware-dependent). The channels of the higher layers are always virtual. It means they create an abstraction (can be operated by any medium and knows its protocol), isolation (they are hermetic and closed to the users), as well as separation of concerns (that makes an application simpler by breaking it down into smaller, more manageable parts). The virtual messages are often called Protocol Data Units (PDUs).

The BLE protocol is also stacked and equipped with several different abstraction layers. The abstraction layers are further grouped into the functional components. In fact, it is composed of two main components: host and controller, as shown in Fig. 4.

In the Controller component, starting from the lowest component and its bottom layer, we have the Physical Layer, Link Layer (LL), and/or Isochronous Adaptation Layer (ISOAL).

The Host Controller Interface (HCI) is a medium that communicates between a Controller and a Host. HCI can be hard coded element inside the radio MCU or it can be i.e. an external device such an USB-to-Serial converter.

The Physical Layer controls the BLE radio in a way that we described in the previous section.

The Link Layer provides an abstraction between the Physical Layer and higher-level layers. It is implemented as a finite state machine (FSM) that defines the states in which the BLE device can be operated. The supporting states are STANDBY, SCANNING, SYNCHRONIZATION, INITIATING, CONNECTION, ADVERTISING, and ISOCHRONOUS BROADCASTING, as shown in Fig. 5.

The advantage of the FSM implementation is that every FSM state can go back to the standby mode, which allows energy saving. We can say that the BLE device is mostly radio-off and only for a short time (interval) radio-on (i.e., during data advertising, data writing, reading, notifying, or indicating). In STANDBY mode, the MCU can be forced to go into deep sleep mode. It is waked up only by the RF front-end interrupt, serving the incoming packet by jumping to the demanded state of the LL FSM and then coming back to lower power mode (LPM).

The SCANING, SYNCHRONIZATION, INITIATING, and CONNECTION states are mostly assigned to the Central device. ADVERTISING and ISOCHRONOUS BROADCASTING are foreseen for the Peripheral devices. The SYNCHRONIZATION state is a new feature of the BLE device and allows the scanner to initiate contact with an advertiser using the agreed RF channel.

The ISOAL is a dedicated layer applied only to the new feature called LE Audio stream. It allows the upper layers to send and receive isochronous data to or from the LL in a flexible way (i.e., translate different packet sizes into the LL size).

The host component consists of the Logical Link Control and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Security Manager Protocol (SMP), Generic Attribute Profile (GATT), and Generic Access Profile (GAP).

The L2CAP layer is a kind of multiplexer and demultiplexer that takes larger packets from the higher layers and translates them into the BLE standard packets when concerning the transmitter side. The receiver side takes multiple BLE packets and combines them into larger packets that the upper layers can handle.

Nowadays, cybersecurity is a hot topic for almost all electronic devices in the market, so I will explain in detail how it is processed at BLE. The SMP defines a simple protocol for device pairing and key distribution [7]. Two devices are pairing in order to exchange secret keys so they can encrypt their conversations. By typically authenticating the other device, pairing means the attempt to establish trust with this device.

On the other hand, key distribution is the process of getting the key from one device to the other, so-called bonding. SMP also defines itself as a mechanism for authentication and authorization. Authentication by SMP is verifying that a device is who it claims to be, and authorization is verifying that a device is allowed to access specific resources.

We can have several security attacks on BLE devices. The most popular are:

1. Passive Eavesdropping – malicious device listens to communication between two BLE devices,
2. Active Eavesdropping – malicious device impersonates both devices, so call Main in the Middle,
3. Privacy and Identity Tracking – BLE devices are tracked by attackers using BLE addresses.

The SMP prevents those attacks and gives users certain security. The secured BLE device should fulfill:

1. Confidentiality (we ensure data is not readable): via encryption,
2. Authentication (we ensure the sender knows the receiver): via pairing and bonding,
3. Privacy (we give the device a unique address that can dynamically change) via Random Private Address (RPA),
4. Integrity (data not corrupted): via digital signatures.

The pairing stage means the generation of the secret keys. The bonding process means the exchange of generated keys. The secret keys that are exchanged by connecting devices are used mostly for data encryption, decryption, signing, and resolving RPA. We have the following keys:

1. Temporary keys (TKs) – generated each pairing process occurred,
2. Short Term keys (STKs) – generated from TKs also each pairing process occurred,
3. Long Term keys (LTKs) – generated in the last phase of pairing processes and used for distribution during the bonding stage, created by Encrypted Diversifier (DIV) and Random Number (Rand),
4. Connection Signature Resolving Keys (CSRK) – used to sign data and verify the signature attached to the data, store both sides of the connection,
5. Identity Resolving keys (IRKs) – used for resolving  RPA, which means the Central IRK will be stored at the Peripheral and vice versa the Peripheral IRK will be stored at the Central.

The SMP provides several security modes as well as certain levels for each of the modes that can vary from mode to mode and from level to level. This can be:

Mode 1:

1. Level 1 – no security (no authentication and no encryption),
2. Level 2 – unauthenticated pairing with encryption,
3. Level 3 – Authenticated pairing with encryption,
4. Level 4 – Authenticated LE secure connections pairing with encryption.

Mode 2:

1. Level 1 – Unauthenticated pairing with data signing,
2. Level 2 – Authenticated pairing with data signing.

Mode 3:

1. Level 1 – no security (no authentication and no encryption),
2. Level 2 – use of unauthenticated Broadcast_Code,
3. Level 3 – use of authenticated Broadcast_Code.

The secure modes and levels can variate from one attribute to another as well over a single BLE role assigned to the device by user.

The ATT is the layer neighboring the SMP. It defines how a server exposes its data to a client and how it is structured. We can have two main roles with the ATT:

1. Server that exposes the data it contains, in principle it accepts incoming commands from a client device and sends responses, notifications as well as indications i.e. BLE thermometer reads and record temperature and next notify the client when a temperature reading has changed.
2. Client that reads server’s exposed data and controls server’s behavior. It is a device that sends commands and requests and accepts incoming notifications and indications from the server.

The data that the server exposed is structured as attributes, also called characteristics. We have six different operations that can be done over a single attribute:

1. Commands – sends from client to server and do not require responses, can be written or signed write.
2. Requests – sends from client to server and require response, can be write or read or find information of attributes and their types on a server.
3. Responses – sends from server to a client as a response to a request, can be response to write, read or information requests.
4. Notifications – sends from server to a client to let the client know that a specific attribute changed. Do not require a response.
5. Indications – the same as notifications but require acknowledgment. In order to enable indications or notifications, a client has to write a correct value to the so-called Client Characteristic Configuration Descriptor (CCCD).
6. Confirmation – sends from the client to the server to let him know that the client successfully received an indication.

The Generic Attribute Profile (GATT) defines the hierarchy in the structuring of the data exposed by the server, as shown in Fig. 6.

The characteristics are the lowest level of attributes that serve a specific purpose. Characteristics can be grouped into services. The services can be grouped into Profiles. The single device can have a single role Profile but several services over a profile as well as several characteristics over a single service. The service should always collect a single functionality. The characteristics of different functionality should never be mixed. The services should be kept as simple as possible.

Let’s assume we have in mind a Heart Rate Sensor. One could define two services here: the readouts of the heart rate sensor and the battery level of the system. So we have two services, doing completely different measurements and creating a single profile role. GATT takes the same role as the ATT. The roles are not set per device; they are determined per transaction.

For example, in a request and response transaction, the client is the one sending the request, and the server is the one responding. This also allows a device to act as a server serving up data for clients and, at the same time, act as a client reading data served by other servers. We can say GATT defines the format of services, their characteristics, and the procedures that are used to interface with these attributes, such as service discovery, characteristics reads, writes, notifications, and/or indications.

Going into detail, the service is a collection of one or more attributes, some of which are characteristics. It groups together related attributes that satisfy a specific functionality on the server. The service is made up of the following:

1. One or more include services,
2. One or more characteristics having properties, values, and descriptors.

We have two main types of services:

1. Primary Service – represents a primary functionality of the device
2. Secondary Service – provides auxiliary functionality of the device

A characteristic is always a part of a service, and its value represents a piece of information that the server wants to expose to a client. A characteristic also contains properties, values, and descriptors.

Profiles are much broader in definition than services. They are concerned with defining the behavior of both the client and server when it comes to services, characteristics, connections, and security requirements.

The General Access Profile (GAP) defines the roles, modes, and procedures. We can have several roles such as broadcaster (transmitter only), observer (receiver only), peripheral (single connections oriented, simple), central (multiply connections, initiate connections with peripherals, more complex).

The GAP also defines modes and procedures for the roles. We can have:

1. Broadcast mode and observation procedure,
2. Discovery modes and procedures,
3. Connection modes and procedures,
4. Bonding modes and procedures,
5. Periodic advertising modes and procedures, and finally,
6. Isochronous broadcast and procedures.

To summarize this section. We have to remember that the GAP gives the device a role. Based on the GAP role (modes and procedures), the link layer uses an FSM to map up the expected behavior of the radio. GATT defines the way that BLE devices transfer data back and forth using services and characteristics. Simply put, GAP configures radio to a specific role, and GATT defines how two connected devices present data to each other using ATT protocol and hierarchically structured data.

At the end of this section, I would like to pay attention to the address of the BLE device. In any kind of communication network, it is very important that any message sent from a source device (SD) reaches the proper destination device (DD) to which it was supposed to be sent.

A Bluetooth address, also referred to as a MAC address, is a 48-bit (6-byte) value that is unique and identifies a BLE device. In BLE specification, it is referred to as BD_ADDR [1]. BLE devices can have either a Public Address (PA), a Random Address (RA), or both of them. The specification says that only one of them is required for the device to be identified [5]. The RA is further subdivided into a static and private address type. The private address is once again divided into resolvable and non-resolvable private address types.

The PA is a global fixed address that must be registered with the IEEE. It is composed of:

1. 24 bits of Company ID, which is the publicly assigned portion of the address by the IEEE (MSB), and,
2. 24 bits of Company Assigned, which means the internally assigned ID as a part of the allocated block (LSB).

The PA transmitter and receiver address bit is always set to 0.

The RA is more popular than PA since it does not have to be registered by IEEE. The RA is an identifier that’s either programmed into the device or generated at runtime (depending on the subtype), and it includes:

1. 46 bits of Random Static Address (RSA) plus 1 and 1 MSB bits which are fixed, or
2. 46 bits of Random Private Address (RPA) that has
   • plus 1 and 0 MSB bits which are fixed for Resolvable Device Address (RDA), or
   • plus 0 and 0 MSB bits are fixed for None-Resolvable Device Address (NRDA).

RA and its derivatives, RSA or RPA, have a transmitter and receiver address bit that is always set to 1. The RSA can be programmed for the whole lifecycle of the device once, or every new boot can vary. However, the address cannot change during a single runtime. The RPA is commonly used to protect against cyber security attacks. The protection addresses for RPA are:

1. RRPA, which is resolvable with the trusted device using an Identify Resolving Key (IRK), and it is recommended to be changeable every 15 minutes and
2. NRRPA which is kind of variation of RRPA with a difference that the transmission is not resolvable the any other device.

The BLE device address formats are summarized in Fig. 7.

It is also worth adding that there is another kind of addressing applied for BLE attribute types, and it is called Universally Unique Identifier (UUID). This can be 16-bit in the case of Bluetooth SIG-Adopted or 128-bit in the case of Custom, which is defined by the developer. The example UUIDs for SIG-Adopted and Custom attribute types of different characteristics are summarized in Fig. 8.

When we now how BLE works both hardware and software lets take a look now for some of the BLE features. In the following chapters, I will focus on LE Audio, Mesh, and Beacons.

The Bluetooth LE Audio

The main foundation for LE Audio is the Isochronous channels (ISOC) feature. The channels are defined in a way that allows a device to send multiple streams of time-bounded data to one or more devices. The time-bound data means data that must be received within a specific time period. Otherwise, it is considered as expired. The isochronous channels mean data arrives at different devices and at different times; that is why it must be processed by those devices simultaneously. The processing is so-called time-synchronized at multiple receivers.

The user must enable the isochronous channels feature at the LL state machine level, allowing an Isochronous broadcasting state as listed in Fig. 5.

LE isochronous channels are classified into two main types:

1. Connected Isochronous Streams (CIS), and
2. Broadcast Isochronous Streams (BIS).

CIS devices, like any other type of LE connection-oriented communication, need:

1. Device advertising and other device scanning and
2. if interested, the scanning device sends a connection request to the advertiser,
3. The device requesting the connection moves into a “connected” state and assumes the GAP role as central and
4. Advertising device also moves into the state of “connected” and assume the role of peripheral,
5. Sending by central device a LL_CIS_REQ PDU, and finally
6. Responding by peripheral device LL_CIS_RSP.

The CIS is a reliable, bi-directional transmission where connected devices can transfer their data using an acknowledgment scheme to control flow. CIS transmission uses FHSS over 40 RF channels and can be paired during the connection establishment phase. CIS data are always encrypted to pair types of connections. CIS is commonly used for Unicast topologies, which means the data stream is sent from one device to another in a point-to-point style.

The CIS transmissions occur through time slots called CIG (Connected Isochronous Group) events. The beginning of the CIG event is called the Anchor point, while the end is called the Synchronization point. The CIG events have constant intervals between them called ISO_Interval. The ISO_interval can take from 5 ms to 4 seconds in multiplies of 1.25 ms.

What is more, the time slot for each CIG event is divided into smaller time slots for the transmission of a single or multiple CISes, which are called subevents. The number of subevents used is indicated by the NSE parameter (Number of Subevent). Subevents of a single CIS allow handling or accommodating packet retransmission. Every CIS event begins with the source device (SD) sending isochronous data and listening for an acknowledgment from the receiving device (RD).

BIS devices, instead of being point-to-point, broadcast – much like radio stations. Any device that is within the range of a BIS broadcast transmitter can pick up and render the broadcast audio streams without the connection overhead. The advantages of BIS are listed below:

1. With BIS, there are no acknowledgments being exchanged between devices, which means we are building a broadcaster source with only one transmitter and no receiver,
2. The BIS is called one-to-many, which means broadcasts can be received by any and every broadcast sink that is within range,
3. BIS can cover far more than can be achieved with a CIS.

The main disadvantage one has to keep in mind is that the broadcaster source requires large batteries or a constant power source. BIS, like CIS transmissions, are grouped into time slots called BIGs (Broadcast Isochronous Group), BIS events, and subevents for retransmission purposes. The only difference is that during a subevent, the broadcaster transmits a single packet without the need to include a time slot for receiving packets. We can conclude that CIS is bi-directional while BIS is a uni-directional kind of IOS without acknowledgments.

The LE Audio standard, besides Bluetooth Core Specification, has over 20 more specifications, including:

1. LC3, which stands for the high-quality, low-power audio codec,
2. Generic Audio Framework, which we can further divide into:
   • Stream management,
   • Media control,
   • Call control,
   • Common audio,
   • Coordinated devices,
   • Microphone control,
   • Volume control.
3. Use Case Profiles that can be:
   • Hearing Access Profile and Service (HAP & HAS)
   • Telephony and Media Audio Profile (TMAP), or
   • Public Broadcast Profile (PBP).

For more details about each of the specifications, refer to [5].

One of the examples of combined BIS/CIS ISO communication is a new Auracast standard shown in Fig. 10.

The Bluetooth LE Mesh

We know now that BLE can support one-to-one communication such as standard BLE or CIS LE Audio or one-to-more in the case of BIS LE Audio communications. But what about many-to-many communication? The BLE standard has an answer, which is the BLE LE Mesh standard. The BLE Mesh aims to increase the range and scalability of BLE LE networks and add support for more industrial applications that utilize BLE LE technology. The mesh network gives us the following benefits:

1. Extended range – due to the fact nodes can relay messages to far away nodes via the nodes in between them,
2. Self-healing capabilities, that means there is no single point of failure, if a node drops from mesh network, the other nodes can still participate and send message to one another.
3. BLE LE Mesh is backward compatible the all previous versions of the standard back to original version 4.0.

The Bluetooth Mesh adds additional abstraction layers above the standard BLE stack, as shown in Fig. 10.

Let’s start from the bottom layer named Network. It is composed of a Bearer Layer that defines how the different mesh packets are handled, and it can be, i.e., Advertising Bearer or GATT Bearer. The Transport layer is mainly divided into lower and upper layers. The lower is responsible for packet segmentation from the layer above and reassembly from the layer below.

The upper ones deal with encryption, decryption, authentication, and/or transport control messages (heartbeat, friendship). The access layer defines the application data format, encryption, decryption, and data verification. The models are connected to foundation models, and the model layers are connected to network configuration and management. The models mainly describe the implementation, behavior, messages, states, and state bindings.

The provisioning layer has access to all the abovementioned layers due to the fact the device should be able to connect or disconnect from the mesh network. Let’s see what are the main concepts and terminologies of BLE LE Mesh:

1. Nodes – devices that are a part of the mesh network,
2. Un-provisioned devices – devices that are outside the mesh network,
3. Elements – different parts of a single node responsible for different functions, i.e., lightbulbs that can be on/off,
4. States – the states of elements, which can be on or off, bounded states to other states, which means one state can trigger another,
5. Properties – can add some context to the state, i.e., indoor or outdoor,
6. Messages – all communications are message-oriented, which means nodes send messages to control or relay information to each other; it means messages are the mechanisms by which operations on nodes are invoked. We can have GET (request a state from one or more nodes), SET (change the value of a given state), and STATUS (response to GET, response to SET, report of element status) messages.

One of the key elements of BLE LE Mesha is addressed. We have three groups of addresses:

1. Unicast address – an address that unequally identifies a single node,
2. Group address – an address used to identify a group of nodes, i.e., all nodes within a specific room
3. Virtual address – an address that can be assigned to one or more elements over one or more nodes. It is commonly organized as 128-bit UUID,

The way messages are exchanged in a Bluetooth mesh network is via a publish-subscribe form. Publishing is the act of sending a message. Subscribing is a configuration used to allow select messages to be sent to specific addresses for processing. Typically, messages are addressed to group or virtual addresses.

The main routing mechanism used by BLE LE Mesh is managed flooding. It consists of:

1. Messages that have a Time-To-Live (TTL) assigned – means the number of hops a message can take across multiple nodes with the mesh network is limited, or
2. Messages that are cashed – means all nodes cash received messages, and the ones that already exist in the cache get immediately discarded or
3. Heartbeat messages that indicate to other nodes that the receiving node is alive, and finally
4. Friendship that defines the relationship between two nodes:
   • Low-power node (LPN) that cannot receive mesh messages,
   • Friend node that works as a proxy between mesh and LPN.

Here, a part for high-level application developers starts, called BLE LE Mesh models. Models have three categories:

1. Server model – a collection of states, state transitions, state bindings, and messages that the model can send or receive,
2. Client model – which does not define ant state; it defines only messages such as GET, SET, STATUS, and finally
3. Control model – that combines both server and client models, allowing communication with other server and client models.

One of the final concept of the BLE LE Mesh are scenes. A scene is a stored collection of states and is identified by a 16-bit number, which is unique to the mesh network. Scenes allow triggering one action to set multiple states of different nodes.

The nodes are the main components of each network. The same is true with BLE LE Mesh. This kind of network consists of:

1. Relay nodes – can retransmit messages that are broadcast by other nodes,
2. Proxy nodes – allows nodes outside the network to interface with nodes within the network,
3. Friend nodes – a proxy node to LPN,
4. LPN – a node cannot by itself receive network messages,

In order to add a new node to the network, the node has to process provisioning. The device that is added to the network is called a node, and the device that is supposed to add a device to a network is called a provisioner. The provisioning is performed over the following steps:

1. Beaconing – the un-provisioned device is sending mesh beacon advertisements PDUs to annoy the network its availability,
2. Invitation – provisioner is sending provisioning invite PDU to the un-provisioned device, the un-provisioned device that responds with its capabilities,
3. The combination of symmetric and asymmetric keys are exchanged between the provisioner and the device to be provisioned,
4. Needs action from the user to interact with provisioner and un-provisioned device, i.e., blinking LED or sending a generated number of digits,
5. After authentication is complete, each device derives a session key using its private key, and the public key is sent to it from the other device. The session key is then used to secure the connection for the exchange of additional provisioning data (including network key, device key, and IV index or unicast address), which is assigned to the provisioned device by the provisioner. After this step, the un-provisioned device becomes a node.

The BLE LE Mesh network is secured from attacks like standard techniques already described in the BLUETOOTH LE STACK section and will not be repeated here. The new feature called node removal is designed to avoid so-called trash can attacks. The node that wants to be excluded from the network is added to the blacklist, and their keys are refreshed, which means new network, application, and other relevant data are redistributed to all nodes. The data packet flow between the source, relay, and destination nodes is shown in Fig. 11.

The Bluetooth LE Beacon

The BLE LE Mesh has already used beacons to announce their desire to join the network. Let’s take a closer look at beacons. These are devices that usually only transmit BLE advertising packets. These devices are mainly battery-powered, they operate in an advertising state only, they can transport a small amount of data, and they are used mainly in location-based services. We have two main beacon standards:

1. Apple iBeacon, which can advertise flags and manufacture specific data,
2. Google Eddystone, which can advertise flags, a complete list of Service UUIDs, and Service Data.

The main variables left for the Apple iBeacons developer are:

1. UUID (16-byte value) – specific to the application and deployment use case,
2. Major (2-byte value) – can define sub-region within the larger region defined by UUID,
3. Minor (2 byte value) – can give additional subdivision of the region or use case specified by application and
4. Tx Power Level (1 byte signed value) – commonly used for region monitoring and ranging.

The main variables left for the Google Eddystone are:

1. Eddystone-UID – similar to iBeacon, 10-byte namespace, and 6-byte instance,
2. Eddystone-EID – allows transmitting an ID that an authorized scanner can resolve,
3. Eddystone-URL – allows the transmit a shortened URL to allow the scanner to navigate or retrieve context data from a server,
4. Eddystone-TLM (un-encrypted) – allows transmitting temperature data, battery level readings, timestamps, and a counter of transmitting packets in an un-encrypted way,
5. Eddystone-TLM (encrypted) – allows transmitting temperature data, battery level readings, timestamps and a counter of transmitting packets in an encrypted way.

The Radius Network company a couple of years ago launched a new standard called AltBeacon. The standard gives full freedom to the developers. The summary of all described standards is shown in Fig. 12.

Summary and future activities

I hope I can briefly describe Bluetooth Low Energy (BLE LE) to you and give you a quick overview of its main standards and completely new features. I also hope Bluetooth low energy will not be a black box for You anymore.

Nevertheless, this is not the end of the journey, and within the next articles, I will uncover for You practical aspects of BLE, which are:

1. PCB design guides using simple BLE radio processor from STM (example gerberas will be included for ready-production solution; you have to only get the IC and manufacture the PCB, i.e., at JLCPCB)
2. WEB BLE Api – I will show You how fast You can build Your BLE Scanner Api using the Firefox BLE plugin,
3. BLE BEACON – We will do a simple multichannel monitoring scope,
4. BLE PERIPHERAL AND CENTRAL – I will demonstrate how to control a bulb using Your mobile phone,
5. BLE MESH – We will do a part of the smart home project,
6. BLE AUDIO – We will try to get ISO audio streams from multiple sources.

Enjoy the reading, and see you soon 😊

References

[1] M. Afaneh, “Intro to Bluetooth Low Energy, 2^nd Edition, Learn Bluetooth Low Energy in a Single Weekend“, ISBN: 979-8-9891226-1-5,

[2] internet source: https://www.argenox.com/library/bluetooth-low-energy/introduction-to-bluetooth-low-energy-v4-0/

[3] internet source: https://www.everythingrf.com/community/what-is-gfsk-modulation

[4] internet source: https://www.st.com/en/microcontrollers-microprocessors/stm32wb55rg.html#documentation

[5] internet source: https://www.bluetooth.com/specifications/specs/core-specification-5-3/

[6] internet source: https://www.bluetooth.com/blog/introducing-the-bluetooth-low-energy-primer/

[7] internet source: https://www.bluetooth.com/blog/bluetooth-pairing-part-1-pairing-feature-exchange/

[8] internet source: https://pypi.org/project/blepy/

[9] internet source: https://www.bluetooth.com/auracast/

[10] internet source: https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/mesh/

[11] internet source: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/bt/bt_mesh/architecture.html

[12] internet source: https://www.researchgate.net/figure/Structure-of-iBeacon-AltBeacon-and-Eddystone-beacon-protocols_fig2_322092785