How does Bluetooth Low Energy work? An in-depth study for Internet of Things Wireless Sensors Networks

15 Oct , 2020 IoT

Among the main Internet of Things Wireless communication protocols discussed in this article, the most used for low power and short range communication is Bluetooth Low Energy (BLE), given its high efficiency and radio equipment low cost. Of course, it has many limitations in terms of data rate and operating range, but it is enough for many Wireless Sensors Networks built inside a small building like a flat or a greenhouse, or in an open field, like a garden.

Today we’re going to see how Bluetooth Low Energy works and how we can use it for Internet of Things applications, analysing two ways to use BLE wireless communication protocol to retrieve data from many IoT sensing nodes.

We will also see the strengths and weaknesses of this protocol, both compared with Bluetooth Classic and even with the powerful and faster Wi-Fi. A shortest description of Wi-Fi and  other Internet of Things wireless communication protocols can be seen HERE.

What is Bluetooth Low Energy and how does it work?

Bluetooth low Energy is a short range communication protocol that can be used to create Wireless Personal Area Networks (WPANs), which typically have a range between few meters up to 20 meters in Line-of-Sight (LoS) applications. So, looking at the following graph, we’re looking at the lower right corner. One of the most common protocol used for this kind of Wireless network is Bluetooth, which can be used in the Classic variant for synchronous data transfer operations, or Bluetooth Low Energy, which is often used for low power multi-nodes wireless sensors networks and indoor localisation through beacons, since it has a good range and a very low power consumption.

 

Bluetooth Classic vs Bluetooth Low Energy: use cases and physical layer differences

As mentioned before, Bluetooth Classic is the original standard version, which has been initially released back in 1999. The latest version of the Bluetooth Classic standard is called 5.2, and, like the previous, operates on 79 channels with a 1 MHz bandwidth and a 1 MHz spacing on the 2.4 GHz ISM band, which are defined as shown below.

Bluetooth Low Energy is available since the version 4.0 of the protocol, and, as name suggests, BLE sacrifices performance and operating range in favour of lower power consumption. Compared to the Classic variant, BLE operates in the same free ISM band of 2.4 GHz and uses the same Gaussian Frequency Shift Keying (GFSK) modulation and Frequency Hopping Spread Spectrum (FHSS) techniques to minimize the destructive effects of fading and channel noise from Wi-Fi networks operating on the same band (below you can see the Wi-Fi 2.4 GHz channels spectrum).

In contrast to Bluetooth Classic, the BLE variant uses only 40 channels in the 2.4 GHz band, with a channel spacing that goes from 1 to 2 MHz. Between the 40 channels provided by the BLE, three of them are reserved exclusively for the Advertising process, namely channels 37, 38 and 39. The remaining 37 channels, instead, are used for data transfer between Master and Slave. These three Advertising channels are located at the endpoints and in the middle of the 2.4 GHz band, in order to limit the interference with Wi-Fi networks, as visible below.

 

Typically, Bluetooth Classic is mainly used for all that types of connections that require continuous synchronisation (Synchronous Connection Oriented Link), such as, for example, a connection between a smartphone and a Bluetooth speaker, a pair of headsets, or during a real data transfer between two neighbour smartphones. BLE, instead, is mostly used for wearables, smart devices and cheap battery powered environmental sensors, since these devices communicate their data periodically to a central master that acts as gateway, so they perform asynchronous data communications (Asynchronous Connection Less Link) to one or more master nodes.

Bluetooth Classic vs Bluetooth Low Energy: data rates, power consumption and operating ranges

Given the two protocols different use cases, they have significantly different power consumption, thus operating ranges. Bluetooth Classic transmission speed (bitrate) depends on the type of Phase Shift Keying modulation adopted but, typically, the theoretical transfer rate goes from 1 Mbps up to 3 Mbps (with EDR). Bluetooth Low Energy instead, can reach a maximum data rate of about 2 Mbps with fifth version of the protocol.

The operating range of Bluetooth Classic technology depends on the power radiated by the antenna. Based on the latter factor, it is possible to identify three main power classes for Bluetooth Classic devices, which are shown in the following table. Generally, devices operating with Bluetooth Classic protocol belongs to Class 2, so they have a typical range up to 20 m in an open field.

Regarding Bluetooth low Energy, as opposed to Bluetooth Classic, there are no power classes, but an operating range between two extremes, i.e. the maximum and minimum power values at the transmitter output. These limits are respectively 10 mW and 0.01 mW, so they are much lower than the Bluetooth Classic devices. Unlike the latter, the operating range also decreases, ranging from a minimum of one meter to a maximum around 10 meters in an open field.

Bluetooth packets structures

BLE works slightly differently at higher protocol levels compared to Bluetooth Classic. In fact, BLE not only has less channels than Bluetooth Classic, but also its packets are smaller. Bluetooth Classic has different types of packets, depending on the type of logic transport used for the transmission. They typically are: Asynchronous Connection Less (ACL), Synchronous Connection Oriented (SCO) and enhanced Synchronous Connection Oriented (eSCO). However, a generic Bluetooth Classic packet has is composed of three fields: access code (68 or 72 bits), header (54 bits) and payload (from 0 to 2745 bits). Its structure is shown below.

The access code identify all packets broadcasted in the same physical channel, which will have the same value. The header instead, is a series of 54 bits that contains all the information about the connection control, to the logical transport address – used to identify the active slave of a piconet -, followed by the type of package used. Finally the payload, which contains the real data transported. In addition, there is also a second type of packet related to EDR (Enhanced Data Rate) variant of Bluetooth, which, unlike the first type, provides some additional control systems to take advantage of two simultaneous different modulations used for the transmission of the same package.

BLE packets are, as told before, smaller (in particular the advertising packets) in order to minimize antenna activation time for transmission and reception and, therefore, the power consumption. The structure of the typical BLE package is visible below and, as you can see, there are four parts: Preamble (8 bits), Access Address (32 bits), Protocol Data Unit (between 2 and 39 bytes) and a final Cyclic Redundancy Check (24 bits).

The Preamble consists of 8 bits and is used by the receiver for synchronisation. It is also useful to identify which packages are broadcasted on Advertising channels and in the Data channels. The Access Address  consists of 32 bits and has different values depending on the channel type: advertising or data channels. For example, the Access Address of any package transmitted on the Advertising channels has a hexadecimal value equal to 8E89BED6. The Protocol Data Unit (PDU) field has a variable length (from 2 to 39 bytes) and has a different structure depending on the type of the target channel (Data or Advertising). For Advertising channels, the PDU is composed by two fields: a 2 bytes Header and a 0 to 37 bytes Payload field. For Data channels instead, PDU structure has three components: a 2 bytes Header and a Payload with a size of up to 255 bytes, which could include a MIC check field.

Address mechanism: something that you must know before developing on BLE

Bluetooth low Energy has many different kinds of addresses. Typically, the broadcasted Bluetooth address of a device corresponds to the MAC Address of the radio equipment. However, many devices, specially smartphones, by default use a random type address, which, of course, is not the real MAC Address of the device. So, looking at the Bluetooth specification, there are many kind of addresses. The two main categories are: Public and Random addresses. Typically, wearables and cheap devices comes with a Public address, which is the bare MAC address of the device radio. Therefore, it will never change. However, as told before, complex devices like smartphones, smartwatches and even computers, typically use a Random address to improve the privacy and security, which can be categorised in two classes: Static and Private. Moreover, Private addresses con be classified into Resolvable and Non-resolvable. You can look at the following scheme to better understand the addresses categorisation.

As anticipated, Android smartphones use Private Resolvable addresses, which exploit a mathematical algorithm for the generation of a resolution key, which is periodically shared whit paired devices. The periodically shared is the reason why, while the address periodically changes, the devices already paired can still resolve it and make the connection without having to repeat the authentication steps.

Any kind of address consists of 48 bits. In Public type addresses, the first 24 bits are assigned by the manufacturer, while the second group of 24 bits is the the ID of the manufacturer itself. Random addresses instead, are randomly generated and, among them, those of Resolvable type are divided into two parts, the hash and the prand, while those of type Non-Resolvable contain 46 totally random bits. The solvability feature
is indicated by the 47 bit, which identifies a Non-Resolvable (value 0) or a Resolvable address (value 1), as visible below.

Some examples of Bluetooth Low Energy Advertising Packet Data Units (PDUs)

Advertising packets can have different types of PDUs, depending on the device interaction needed (broadcasting, advertising, connection, active or passive scan). Bluetooth Low Energy interaction depends on their operating state, but we will discuss about it later, in the following section. back to the PDUs, until Bluetooth 4.2 there were only seven PDUs, while with Bluetooth 5.0 – and above – additional PDUs (Extended PDU) have been added, thanks to the introduction of the concept of Secondary Advertising channels. I’ll discuss only the primary PDUs, since they are the key PDUs for BLE functioning.

PDU ADV_IND

The ADV_IND PDU is used for indirect advertising events that include the possibility of connection and scanning by all other nodes listening. It is composed by the AdvA field, which specify the address of the Advertiser and if it is random or public. Then, there is an AdvData field, which contains the advertised data. Here below you can see the PDU structure.

The Advertising events of this PDU can end in three ways:

1. when a listening device reply with a CONNECT_IND PDU type, in case it is a initialiser node, thus establishing a connection with the Advertiser node;
2. when a listening device reply with a SCAN_REQ PDU type, in the case it is an active scanner. After that, the Advertiser device will send a SCAN_RSP PDU response to the scanner, thus leading to the end of the event.
3. if any device answer to the advertiser, the event ends after the PDU has been broadcasted on all the three Advertising channels.

PDU ADV_DIRECT_IND

The ADV_DIRECT_IND PDU type is used for Advertising events with the purpose to establish a connection to a device whose address is already known in advance. The AdvA field specify address of the Advertiser, while the TargetA contains the address of the target device.

The Advertising events of this PDU end in two ways:

1. when the target device, which is listening, reply with a CONNECT_IND PDU type, passing therefore to the connection state;
2. if the Advertiser does not receive any response from other devices, the node continues sending the PDU on the remaining channels, until the maximum time is reached.

PDU ADV_SCAN_IND

The ADV_SCAN_IND PDU type is used by Advertising events for the all these devices in the scanning state, which don’t allow any connection. The AdvA field specify address of the Advertiser, while the AdvData contains any information or data that the advertiser wants to transmit to the scanners.

The Advertising events of this PDU end in two ways:

1. when the active scanner devices respond with a SCAN_REQ PDU type. Then the Advertiser will reply with a SCAN_RSP PDU type. Subsequently, the ADV_SCAN_IND PDU is also sent the other advertising channels.
2. when nobody replies on all the three primary Advertising channels, the event ends.

ADV_NONCONN_IND PDU

The ADV_NONCONN_IND PDU type is used for Advertising events that do not allow neither the connection nor the active scanning by other nodes, since during the
this type of events the Advertiser does not listen on the channels. The AdvA field specify address of the Advertiser, while the AdvData contains any information or data that the advertiser wants to transmit to the scanners.

It is a type of PDU used to perform non direct broadcasting. The events characterised by this PDU end after sending the package on all three Advertising channels.

Others PDU and Extended PDU

Among the other types of PDUs, it is necessary to mention the SCAN_REQ and SCAN_RSP PDUs used in the scan events. Therefore, there is also a CONNECT_IND PDU, which is used to initialise a data transfer over Data Channels, thus the real connection between two devices. Finally, there is an additional ADV_EXT_IND PDU, which has been introduced with Bluetooth 5.0 and it’s used to switch from the primary Advertising channels (37, 38 and 39) to the secondary ones, i.e. the Data Channel, normally intended only for data exchange in Bluetooth 4.2. On Secondary Advertising channels there are also additional PDUs, all characterised by the prefix AUX_ which, however, will not be explored in this article.

The key of Bluetooth Low Energy efficiency for Internet of Things applications

The key of BLE efficiency is certainly the lower number of channels (40 compared to 79 defined for the Bluetooth Classic), of which only three, those of Advertising, are actually used for advertising, scanning and establishing a connection between two nodes. This, combined with smaller packets size and a fair low transmitting power, makes possible to reduce the time in which the antenna and all the other radio equipment remain active during transmission or reception, allowing more stand-by phases and therefore reduced power consumption. All these stuffs together make Bluetooth low Energy suitable for different Internet of things applications where many IoT battery powered sensing nodes need to communicate their data to a central gateway using a wireless communication protocol. As already said, BLE is the mostly used protocols for wearables, smart devices and cheap battery powered environmental sensors, which communicate their data periodically to a central master that acts as gateway, assuring good battery life in a tiny format. However, there are many other features that makes BLE Internet of Things friendly and efficient. Let’s see them in the following paragraphs.

Generic Attribute Profile (GATT): Services and Characteristics for IoT communications

Another key feature of Bluetooth Low Energy that has been partially taken and improved from the Classic variant in order to reach a more efficient resource utilisation, is the Generic Attribute Profile (GATT), which establishes how to exchange profiles and data over an already established BLE connection between one peripheral (GATT Server) and one central device (GATT Client). GATT uses of a generic data protocol called ATTribute Protocol (ATT), which is used to store Services, Characteristics and related data in a lookup table using 16-bit IDs for each entry. GATT can handle only one connection at time, thus when a peripheral connects to a central device, the last one will immediately stop advertising itself, so that other devices will no longer be able to see it or connect to it until the existing connection is interrupted. A behaviour that must be know when dealing on wireless sensor networks with multiple peripheral devices that must connect and exchange data with one central device, a recurrent scenario in many Internet of Things applications which involve the use of Bluetooth Low Energy. The connection procedure between GATT server and GATT client is shown below and, when there is a very large amount of devices, a smart multiple access system should be implemented, in order to optimize the GATT server access.

Once a client is connected to a server, Profile, Services and Characteristics manage the data exchange process between the two nodes. A Profile is simply a pre-defined collection of Services that has been defined by the Bluetooth SIG. A Profile can combines multiple Services, which depends on the device nature. A Service instead, is used to separate data into one or more Characteristics. Each Service distinguishes itself from other services with a unique numeric ID called a UUID, which can be either 16-bit or 128-bit. As Profiles, also Services UUID are defined by Bluetooth Developer Portal, however, users can easily create custom service for specific purpose. The last elements of GATT are the Characteristics, which encapsulates a single data points that could be an array of data, given its maximum size of 512 bytes. As Services, also Characteristic identifies itself though a 16-bit or 128-bit UUID. The entire GATT structure can be seen in the following picture. So, every time that a GATT Client connects to a GATT Server, it writes or reads data over one or more Characteristics. Therefore, Characteristics are a key point of any BLE connection and one of the possible ways to use BLE for Internet of Things applications where many BLE sensing nodes have to communicate their data to a central gateway.

A well defined and limited number of active status

Bluetooth Low Energy owes its efficiency to well defined status, which defines the behaviour of a BLE device during many operations. In fact, there are five Link Layer states: Advertising, Standby, Initiating, Scanning and Connection. A flow diagram of each status possible transaction can be seen here below.

In the Standby state, which is the state where any BLE device spend most of the time, the Bluetooth radio is practically turned off. When it is in this state, the node does not establish any connection, because does not transmit any packets and does not even listen to them. A device in Standby can switch to one of the three active states as a result of a command received from the Host Controller Interface (HCI). In the Connection status, the Data channels are used for the effective exchange of data packets between the Master and the Slave. This phase is always preceded by an event of Advertising or the state of Initiating, necessary for the establishment of the connection between two devices. Following a command received from the Host Controller Interface (HCI), the Connection status can switch back to the Standby status.

The Advertising status is the fundamental state of Bluetooth Low Energy, since it leads to the establishment of a connection, to the discovery of new nearby devices and other operations. When a node is in the Advertising state, during a certain time interval, defined as an Advertising event, the device transmits Advertising Bluetooth packets on the three dedicated channels. The transmit and listening time for each packet must be less or equal to 10 milliseconds for each Advertising channel. Each Advertising event, therefore, has a variable duration but it must be shorter than 30 milliseconds. The time between two Advertising events can be defined as advEvent, and corresponds to the sum of advInterval and advDelay time intervals. The advInterval identifies a multiple of 0.625 milliseconds and goes from a minimum of 20 milliseconds up to a maximum of 10,485 seconds, while the advDelay identifies a random value between 0 and 10 milliseconds generated for each Advertising event. The advDelay has been introduced to minimize the risk of packets collision of other nearby devices.

The Scanning status is used to detect nearby Advertising devices in order to get more information about them without establishing a real connection. There are two types of scanning: passive scanning and active scanning.

• Passive Scanning: when a Bluetooth Low Energy node is in passive scan, it does not transmit any package on the Advertising channels but it listen for incoming Advertising packets for  a certain time window, called scanWindow. The scan process can be repeated after a certain interval of time, defined by the scanInterval, with a duration equal to or less than the scanWindow.
• Active Scanning: unlike the Passive Scanning, during an Active Scan some packets are sent to the Advertising nodes which broadcast them self with ADV_IND or ADV_SCAN_IND Packet Data Units, in order to request additional information. After the receipt of one of these PDU, the scanner device can transmit SCAN_REQ type PDUs to the advertiser in order to obtain more information. To minimize the
  collision risk, the scanner implements a backoff system, characterised by backoffCount and upperLimit variables, with the aim to reduce the number of SCAN_REQs transmitted in case of no response. After sending the request, the scanner listen on the advertising channels for a SCAN_RSP PDU: if it is not received, the backoff mechanism handles the possible retransmission and the waiting time. An example of active scanning is shown below.

Finally, the is the Initiating state, where the device keeps listening on the Advertising channels for the time interval defined by the scanWindow variable. The listening operation is repeated after a certain interval of time, defined by the scanInterval variable. The initialisation state is therefore very similar to a passive scanning, with the difference that when the device receives a packet with a ADV_IND or ADV_DIRECT_IND type PDU, it can reply – if the advertiser’s address is in whitelist – with a CONNECT_IND type PDU, making the node switch to Connection status and ending the Advertising event, as shown in the following example.

Wireless Mesh Networks to reach an higher operating range

The biggest drawback of BLE technology is its limited operating range, which, in a real environment with walls, obstacles and interfering 2.4 GHz Wi-Fi networks, barely reach a two to five meters operating range. A good range for small wireless sensors networks, like in a small flat or greenhouse, but very limited for IoT applications inside medium sized houses and buildings. Depending on the applications, there are two solutions:

• the simplest one is to place more grid powered devices (aka, BLE servers or namely gateways) inside the building in order to reach a full coverage, like if you are working with Wi-Fi access points and you wanna cover an entire building using many access points placed in the right places. It’s a very simple and effective solution which fits well for some kind of applications, where, for example, you have a good number of battery powered BLE sensing nodes and the possibility (both economically and in terms of space/networking configuration) to place more gateways. The main drawback is an higher deployment cost to reach a perfect coverage, because, whether you like it or not, there will always be one or more sensing nodes placed in a corner or near the boundaries of your network, which imply a meticulous placement of your gateways;
• the complex but cheaper solution is to implement a BLE Wireless Mesh Network, thus allowing to any sensing node to reach your central gateway in a smart and efficient way. Wireless Mesh Network is cooperative network topology consisting of several intelligent nodes that act as receiver, transmitter and packets forwarder towards the recipient node, allowing to connect between them devices that cannot be reached in a direct way but only through multi-hops communications. With Bluetooth 4.1 standard, it has been introduced the possibility to make a device both acts as Master and Slave, thus allowing a possible Bluetooth node to act as an intermediary in a communication between two other devices. This could significantly extend the operational range of BLE networks, allowing to cover an entire building. However, this solution is a bit complex to implement even if Bluetooth 5.0 has introduced some new useful functions dedicated to Wireless Mesh Networks. Also, nodes acting as packets forwarder have an higher energy consumption, since they have to spent more time listening for incoming packets, limiting the battery life of constrained devices.

How can we use it for Internet of Things applications?

Well, now that you learnt how Bluetooth Low Energy, we can see how effectively use it for our wireless sensors networks or, more in general, for different kind of Internet of Things applications. As you should have understood in the previous section, there are two possible ways to use it for data communication between a Master node (e.g., a BLE to Internet gateway) and a Slave device (e.g., a battery powered sensing node):

• Implementation of a GATT server and usage of Services and Characteristics to transfer data in both direction between two devices (client and server);
• Usage of Advertising and Scanning status for mono-directional communication between one or more nodes.

There are many difference between these two possible ways. The first one needs an already established connection between the two devices, so it requires some time, because the GATT server, which has the role of Master and defines one or more Services with one or more Characteristics, has to advertise itself in order to be found by the Slave node, which acts as client. Once the connection is achieved, the real data transfer on the Data channels can happen, allowing the client (the Slave node) to transfer a good amount of data in both directions by simply writing or reading on the desired Characteristic. However, there are two big drawbacks: first, as told before, the advertising, scanning, initiating and connection process takes some time (more than you could think), especially on low power devices which have limited computing capabilities, and, as I explained before, once a device is connected to a GATT server (which, in a IoT application, could be our gateway) other nearby sensing nodes can’t find it (because it stops advertising itself), thus wasting power keeping scanning for it. This leads us to the second drawback: data can be exchanged only with one Slave device at time, which could be a problem for densely populated BLE networks, given the connection and disconnection times.

However, typically, battery powered sensing devices in a Wireless Sensor Network have a smaller amount of data to transmit in mono-directional way toward the BLE network gateway. Here it comes the second communication ways, which fits really well for these kind of applications, since the limited payload of the Advertising packets (27 useful bytes) is enough to transmit an identifier ID (if the BLE address is not enough) and many sensors data (you can play with the right variables to reduce and optimize the payload size). In this case, the gateway acts as Passive Scanner, which listens for incoming Advertising packets from many sensing nodes, retrieving their payload. In this way, it is also possible to collect data almost simultaneously from different slaves, since three advertising channels are available, making this solution suitable for high density BLE networks. Of course, the biggest drawback is the mono-directional communication type and the lower (almost null) security of the communication, since by default any encryption is active on advertising packets’ payload. The latter problem could be partially bypassed applying an encryption to the payload, while the first one requires a role exchange between the Master and Slave to be overcome.

Well, these are the must-know things regarding Bluetooth Low Energy. Of course there are a lot more things left, but I believe that this article is a good starting point for BLE Internet of Things beginners.

 

---