BLE(Bluetooth Low Energy)

Bluetooth Low Energy is abbreviated as BLE (Bluetooth Low Energy, and is also marketed as Bluetooth Smart). Bluetooth Low Energy (BLE), sometimes known as Bluetooth Smart, maybe a lightweight subset of original Bluetooth that debuted with the Bluetooth 4.0 core specification. 

What Is Bluetooth?

Before diving into the small print of Bluetooth Low Energy, it is essential for us to understand the meaning and dealing of Bluetooth. The Bluetooth specifications specify the technical components developers utilize to build the interoperable devices that structure the thriving Bluetooth ecosystem.

The Bluetooth Special Interest Group (SIG) oversees Bluetooth specifications, which are updated and improved daily by Bluetooth SIG Working Groups to satisfy changing technology and market needs.

Most people associate Bluetooth with a wireless headset or another gadget that connects you to the information you are transmitting. Bluetooth is a wireless connection between your phone and the device to which you are linked. This mechanism allows data to be sent over small distances without using cables.

What Is Bluetooth Low Energy?

Bluetooth Low Energy, also called BLE, was introduced in 2010 and ushred in a new age of connectivity, especially between smart devices and smartphones. BLE is a new wireless protocol that shares some features with Bluetooth Classic. It takes some of the same concepts pionered by Bluetooth like simple connections and fast data transfers, but is simplified for low power, reliable and quick data transfer between devices.

This guide is intended to cover many of the basics of BLE that you need to know when developing or designing a product. In addition to this guide, there are several other ones discussing advertising and other design aspects.

Before we talk about BLE, it’s important to note the naming: Bluetooth Smart was the original marketing name for Bluetooth Low Energy. The Bluetooth Smart name and mark didn’t catch on – most people including us refer to it as Bluetooth Low Energy or BLE. From a marketing perspective this was also confusing – is there any Bluetooth that’s not smart?. To add to the confusion, there also existed “Smart Ready” devices thatare commonly referred to as “Dual Mode”, meaning they support both Bluetooth Low Energy and Bluetooth Classic (used for making calls with your phone, for example). We won’t be referring to Bluetooth as smart, but you should understand why the old Logos refer too.

While commonly referred to as BLE, the Bluetooth SIG discourages this name because BLE isn’t a trademark they own. So officially, Bluetooth LE is the proper way to refer to it.

Bluetooth is one of the most popular wireless protocols, and it has been available in smartphones, computers, and other devices for over a decade. Most of us are familiar with Bluetooth and how Bluetooth can allow us to connect a headset and make calls using our cellphones. The explosive growth in Bluetooth devices and new use cases led the Bluetooth SIG and other companies to the realization that Bluetooth consumed too much power and took too long to connect in some applications. For example, a key chain finder using Bluetooth would not run very long and that it could take significant time for it to connect, frustrating users.

Apple’s support for BLE in their devices, starting with iPhone 4s, opened the way to a massive number of small, battery operated devices.
Before BLE, using Classic Bluetooth could be a pain for users and developers. Bluetooth Classic is complex, has significant battery drain and on iPhones required an authentication chip which was costly and made these products too expensive. For trnasferring data, BLE is supported without this requirement in Apple devices, so it is lower cost.

One of the most powerful aspects of BLE is how extensible it is and how it allows any developer with an idea and a need to exchange information to do so, as opposed to the rigid structure of Classic Bluetooth.

Bluetooth Low Energy vs. Bluetooth Classic

• Both are accustomed Connect the devices and Transferring the info for private and commercial use.
• The main difference is how they’re distributing data for low-energy power.
• Bluetooth classic is employed to transfer many data continuously but contains high power and more cost.
• BLE transfers smaller packets of information over short periods of your time using low battery power.

Bluetooth LE Power Saving Features

1.BLE Radio Isn’t Chatty 

The radio of Bluetooth LE-enabled devices only awakes when necessary to conserve power. When a device wants to send or listen for data, the LE radio is turned on to quickly perform the necessary tasks and then disconnects. This operation of an LE radio differs from a Bluetooth Classic radio, where the radio is on most of the time, and the connections are maintained for many hours or days. 

Since the LE radio is not chatty, it is suitable for applications where a device sends a small packet of data every now and then, ranging from once per second to once every few days. For example, a heart rate monitor in a fitness tracker can collect all the heart rate data and send it to your smartphone once every hour. Or a temperature sensor that’s triggered only to send the temperature reading if the temperature is very high or low.

2. The BLE Radio Has Shorter Connection Times

Bluetooth LE consumes less energy due to the reduced number of RF channels available for the connection, which results in faster connections and less time spent scanning. Bluetooth Classic has 32 RF channels that can be used to establish a connection between devices, whereas Bluetooth LE only has three.

Additionally, a BLE device that wants to be discovered sends signals on the RF37, RF38, and RF39 channels, known as the primary advertising channels.

When a device wants to find other devices, it listens for advertisement packets on the primary advertising channels. Since there are only three primary advertisement channels, the LE radio doesn’t have to scan as many channels and can spend less time awake, thus using less energy.

3. The BLE Radio Uses Smaller Packets 

Bluetooth LE data packets are much smaller than Bluetooth Classic data packets. Smaller packet sizes require less computation overhead when encoding and decoding. This reduces power consumption.

4. The Battery Discharge is Pulsed

One of the properties of a battery is how it is discharged affects its capacity. Battery capacity is the amount of energy that can be extracted from a battery under certain conditions. A constant current discharge of a battery reduces its life. On the other hand, a pulsed discharge, in which there is idle time between discharging, helps get a battery as close to its nominal capacity as possible. This is referred to as the battery recovery effect.

Bluetooth LE takes advantage of this recovery effect. Data transmissions with BLE are done in periodic short bursts that are followed by idle periods. During these idle periods, the battery can recover, which helps the battery last longer.

5. The Bluetooth LE Protocol is an Asymmetric Design

The LE protocol uses an asymmetric design to issue tasks to devices that want to connect. The device that is the most resource-constrained does the least work. For devices to be connected, one has to take the role of a central and the other of a peripheral. The central device usually has more processing capability and battery power, like a smartphone. On the other hand, the peripheral is usually a device with less processing power and limited energy resources like fitness trackers, heart-rate monitors, etc. 

Architecture of BLE

 The following figure shows the different layers within the architecture of BLE. The three main blocks in the architecture of a BLE device are: the application, the host, and the controller.

1.The application

The application layer is use-case dependent and refers to the implementation on top of the Generic Access Profile and Generic Attribute Profile — itʼs how your application handles data received from and sent to other devices and the logic behind it. This portion is the code that you would write for your specific BLE application and is generally not part of the BLE stack for the platform which you develop. This part will not be covered in the book, since it depends on the specifics of your application and use case.

2.Host

The host contains the following layers:

• Generic Access Profile (GAP)
• Generic Attribute Profile (GATT)
• Attribute Protocol (ATT)
• Security Manager (SM)
• Logical Link Control and Adaptation Protocol (L2CAP)
• Host Controller Interface (HCI) — Host side 

 

The main functions of each layer of the BLE protocol stack are summarized in Table 1.

Table 1. Main functions of each LE protocol stack layer.

Protocol Layer	Main Function
Physical Layer (PHY)	Defines the specifications for the hardware (LE radio) used for sending and receiving data over the air. The specifications include frequency bands, modulation characteristics, output power, and radio range.
Link Layer	Responsible for configuring the LE radio to form communication links per the type of communication. Other functions include defining states of the LE radio, packet format, channel map, and device address, as well as encryption and control procedures.
Host Controller Interface (HCI) Layer	It is an interface between low-level protocols in the controller and upper-level protocols in the host. The HCI can be implemented using UART, USB, or ignored if all the protocol layers are on a single chip.
Logical Link Control & Adaptation Protocol Layer (L2CAP)	It serves as a liaison between the upper and lower layers of the Bluetooth LE stack. Tasks include: segmenting data from upper layers into smaller sizes suitable for lower layers and packet reassembly from lower layers to upper layers.
Security Manager (SM)	It defines the pairing, authentication, and encryption procedures between LE devices. It protects against passive eavesdropping, Man-in-the-Middle, and tracking. Tasks include key generation, key distribution(pairing), and random address generation and resolution.
Attribute Protocol (ATT)	LE devices store data using a data type called an attribute. The ATT defines the structure of an attribute and its access permissions (read, write, read-only, etc.)
Generic Attribute Profile (GATT)	It provides a hierarchical data structure to arrange data in a file-folder way. Hierarchically organizing data makes it easy for LE devices to access and store data when interacting. The hierarchical structure consists of profiles, services, and characteristics.Related characteristics are organized into a service. Services that are related are grouped into a profile.
Generic Access Profile (GAP)	It defines procedures for how a BLE device can communicate with others through broadcasting or connecting. Tasks include: defining BLE device roles, as well as how each role controls the link layer.

3.Controller

·         The controller contains the following layers:

·         Physical Layer (PHY)

·         Link Layer

·         Direct Test Mode

·         Host Controller Interface (HCI) — Controller side

Layers of the BLE Architecture

Physical Layer (PHY)

Bluetooth LE introduced a completely new radio which a similar but different modulation to Bluetooth Classic’s 1Mbps. Let’s dive deeper into the BLE Physical layer. The Physical layer refers to the radio itself:

BLE uses the same 2.4GHz ISM band used by Bluetooth Classic and Wi-Fi since it is “unlicensed” and available without an FCC license, and is also available worldwide. This band starts at 2400MHz and continues until 2483.5MHz. The Bluetooth LE specification divides the band into 40 channels of 1MHz spaced 2MHz apart. This is half the channels of Bluetooth Classic, but it helps simplify some of the radio design. 3 Of these channels are called “advertising” and are used by devices exclusively to send beaconing packets called advertising packets. These packets contain information that allow other devices to connect, but can also provide information about a device.

The advertising channels have been placed specifically in the lower, upper, and middle of the band to avoid interference from Wi-Fi and other sources. For example, Wi-Fi can take 20MHz to 40MHz of bandwidth. By spreading the advertising channels it makes a Wi-Fi station much less likely to interfere with all the channels. For example, if Channel 38 and its surrounding channels are getting interference, then there are still 2 other advertising channels, 37 and 39, that will not be affected.

BLE Radios transmit using a modulation scheme that is either 1Mbps or 2Mbps for Bluetooth 5.0 capable radios. MOst if not all radios made available are 5.0 compatible, but some older devices are not. 2Mbps PHY (as physical layer is referred to) allow for faster data transfer, but usually at the cost of range. Bluetooth 5.0 also introduced the CODED phys. Transmissions using coded PHY use the 1Mbps modulation, but they use bits for redundancy (called Coding in wireless terms). This allows for error correction which effectively improves the noise signal.

One thing that is not typically explained are some of the tradeoffs. 1Mbps is the standard modulation used for most advertising. Using 2Mbps requires the radios to negotiation. for it to work, both sides of the connection need to support Bluetooth 5.0. The 2Mbps PHY is mandatory for Bluetooth 5.0 to support, but Bluetooth Long Range support is optional. Smartphones support the 2Mbps PHY but we have yet to see one support LE Long Range. Part of the reason is that Long Range is typically an industrial requirements.

Bluetooth 5.0 also enabled output powers up to +20dBm, the maximum limit you can achieve. Previously, +10dBm was the limit, but most BLE radios supported up to 4dBm or so, with a few exceptions. Such high output power enables BLE to cover very long ranges.

The flexibility of BLE in terms of speed and output power allows optimizing the design for the application and gives BLE a lot of power to fit into many use cases.

To build a BLE product it’s not necessary to understand more about the physical layer, but a few words about the RF are in order. Like all wireless transmitters, BLE devices transmit and receive Radio Frequency signals which require an Antenna and careful design RF design. Antenna design is a complicated topic, but practically any 2.4GHz antenna can be used. PCB and Chip Antennas are among the most common ones, but there are many options. We’ll discuss some of this later.

Link Layer

Now that we understand the BLE PHY, it’s important to cover the BLE Link Layer, which is the protocol in charge of exchanging packets and uses the BLE PHY to do so. This is where the majority of the BLE operations happen and what designers deal with most commonly.

Bluetooth LE specification defines two roles: Peripheral and Central. The real difference between the two is who initiates a connection. Central devices are the ones that initiate, while peripherals accept. In this sense Central acts as a master, with many peripheral slaves attached.

The design of the BLE protocol intentionally shifts the power requirements to the Central device. Perihperals are expected to act to conserve energy, while the Central is more burdened.

The three main states in which a BLE device operates in are:

• Advertising state
• Scanning state
• Connected state

 When a device advertises, it allows other devices that are scanning to find the device and possibly connect to it. If the advertising device allows connections and a scanning device finds it and decides to connect to it, they each enter into the connected state.

Each device in the BLE can be in any of the following state

• Standby – The device isn’t transmitting or receiving. Usually associated with the system being asleep to conserve power
• Advertising – A device with a Peripheral Role will enter the Advertising state where it will send packets on the advertising channels. In this state it will also listen to any responses from a Central device.
• Scanning – Scanning refers to listening to advertising packets that are sent over those channels. This mode is used to scan for devices
• Initiating – This state is the state a Central device usually enters before a connection is established. The Central device will listen for advertisements on peripherals, but once the advertisement from the desired peripheral
  device is received, the Central may connect by sending the right data

For the Peripheral device, the Advertising state is also the initial state before the Connection state. The connection state is the final state in which the Slave (Peripheral) and Master (Central) can exchange data.

Exchanging Data

Since the BLE Link layer exchanges packets, it’s important to understand the two main mechanisms for exchanging data in BLE:

• Advertising – Advertising allows sending unidirectional but broadcast data. The perihperal sends data using Advertismenets and Scan Response packets. Because it’s broadcast in nature, multiple devices can listen to the advertising data. Each advertising packet is configurable by the product developer and can contain a wealth of information. It’s not necessary to connect to a device to get these packets, but the Central cannot send any data back
• Connections – Connections allow the Central and Peripheral to exchange data bidirectionally, controlling the device and sending it information, as opposed to the unidirectional nature of advertising.

So advertising packets serve dual roles – they enable Central devices to find devices and connect, and also able to convey any information the designer want. For example, sensor data.

 In essence, the Central sends a connection request, coordinating the timing of the Connection interval. The perihperal then waits for data from the central device at the right moment, and they begin exchanging data. If data doesn’t arrive, the connection is ultimately disconnected on both sides.

Establishing Connections

Most of what you think about exchanging data in BLE is done using connections. For example, when you buy a new iPhone accessory with Bluetooth support, you open the App which uses iOS or Android to scan for the advertising packets. It then finds the device and connects to it.

Data is transmitted on 37 data channels which are not used for advertising. When devices are in a connection, the periodically exchange packets periodically during Connection Events. The rate of these events is defined by parameters such as Connection Interval, which as you will learn are critical because they determine how quickly data is exchanged, but they also control the amount of power the BLE radio will end up using. Faster connection events mean quicker data transfer, but will consume much more power.

We touhed on the connection interval and said that at every such interval, the devices exchange either empty packets (if they don’t have any data to send) or send whatever data they have available. So if the connection interval is every 30ms, the devices will exchange packets every 30ms. As you can imagine, there are many times where the either Central or peripheral won’t have any actual data to send. The BLE specification allows the peripheral device to skip connection events. This is called “Slave Latency”. By skipping connection events and not listening to the Central’s packet, the Slave (peripheral) can save on power.

the slave latency parameter, like the Connection Interval Min and Max parameters, are configurable and need to be agreed upon by both sides of the connection. The Central is forced to send data on each interval . Remember when we mentioned that the Central ends up consuming more power? This is why.

A typical BLE application involves a BLE chip connected to various sensors. A user walks into the BLE range. For the User’s smartphone to connect and read the sensor data, the BLE device needs to be advertising. Once the Smartphone receives the advertisement packet, it will begin the process to connect and obtain the sensor data. If the advertising interval is set too high, the devices will take time connecting and the user will experience this delay. If the advertising delay is too short, the frequent TX and RX will drain the battery more quickly.

L2CAP

The Logical Link Control and Adaptation Protocol (L2CAP) layer acts as a protocolmultiplexing layer. It is borrowed from the Bluetooth Classic standard, and performs the following tasks in the case of BLE:

• Takes multiple protocols from the upper layers and places them in standard BLE packets that are passed down to the lower layers beneath it.
• Handles fragmentation and recombination. It takes the larger packets from the upper layers and splits them into chunks that fit into the maximum BLE payload size supported for transmission. On the receiver side, it takes multiple packets and combines them into one packet that can be handled by the upper layers.

The L2CAP layer fragments and re-assembles packets from other layers, but it also acts as a sort of router – it takes packets received by the BLE link layer and forwards them to the right destination. In BLE, those destinations are commonly the GATT and the Security Manager

Recent additions to the BLE specification also allow for L2CAP Oriented Channels. As you’ll soon see, the GATT protocol for sending data adds quite a bit of overhead. For many applications, it’s overkill. L2CAP Oriented Channels allows establishing direct data channels between two devices that send data directly to their respective L2CAP layers without GATT. The overhead is reduced and the data rate effectively increased. It also can allow reducing the memory/flash footprint.

• Users want responsive products, and the advertising interval is critical in quick connections.
• Advertisements are the core of iBeacon, EddyStone and other beacons, so they’re used all the time

Advertising is by design unidirectional. A Central device can’t send any data to the Peripheral device without a connection. But a single peripheral can advertise to multiple masters in the area.

Advertising and Scanning

Generic Access Profile (GAP) The Generic Access Profile (GAP) provides the framework that defines how BLE devices interact with each other. This includes the following aspects:

• Modes & Roles of BLE devices.
• Advertisements (advertising, scanning, advertising parameters, advertising data, scanning parameters).
• Connection establishment (initiating, accepting, connection parameters) Security.

The implementation of this framework is mandatory per the official specification, and it is what allows two or more BLE devices to interoperate, communicate, and be able to exchange data with each other. We talked briefly about the advertising and scanning states of a BLE device, and we mentioned that a BLE device always starts in the advertising state. This is the case even when it wants to operate in the connected state most of the time. In order for two BLE devices to discover each other, one of them has to advertise while the other scans the three Primary Advertising channels (RF channels 37, 38, and 39) looking for advertisement packets sent by the advertising device. If the advertising device supports a connection and a central device discovers it, it may choose to establish a connection. In this chapter, we will focus on these initial states: advertising and scanning.

BLE Advertisement Interval

When a BLE peripheral device is in advertising mode, advertising packets are sent periodically on each advertising channel. The time interval between packet set has both a fixed interval and a random delay. The interval is specified between the set of 3 packets (and 3 channels are almost always used).

You can set the fixed interval from 20ms to 10.24 seconds, in steps of 0.625ms. The random delay is a pseudo-random value from 0ms to 10ms that is automatically added. This randomness helps reduce the possibility of collisions between advertisements of different devices (if they fell in the same rate, they could interfere more easily). We mentioned that finding advertisements is critical, so avoiding collisions at all costs is extremely important. This is just another way BLE uses to improve robustness.

You may be thinking that you would want to advertise on just one or two channels, not all three to save power, because each packet transmitted has a specific cost that may significantly increase the average current. Most companies frown on this approach because of the effect from interference. If the channels you selected are blocked, you device won’t work. Apple, for example, recommends advertising on all 3 channels, as do other manufacturers.

Another thing to remember is that the advertising interval we’re talking about is separate from the connection interval. So, just because your device is slower to form a connection doesn’t prevent you from sending data quickly once the connection is established.

Despite the wide range of advertising interval, most products use the following as a guideline:

• Less than 100ms – for very aggressive connections and usually for short periods of time
• 100ms to 500ms – normal fast advertising for most devices
• 1000ms to 2000ms for devices that connect to gateways and where latency is not critical

The ranges above are general guidelines you should consider, taking additional account of Apple and Android’s recommendations. For example, we’ve had customers use 20ms to 50ms to establish a very fast connection because the central device had less than a second to connect. Remember that it will take a few advertisements to be able to connect, especially since a scan response may be further needed. SOme packets can be lost. So in these cases, you may err on the side of caution, especially since the time to connect is limited.

In the case of sensors that connect to a gateway to provide data but need very low power, a 1s advertising rate or even up to 2 seconds may be useful to ensure the sensor doesn’t waste a lot of time. Also, if the advertising packet provides data which doesn’t change much, then there’s no need to transmit frequently.

Make sure to realize that a connection may take a multiple of the advertising interval.

Most devices actually create a more complex system for advertising, using a Fast and Slow advertising regimes. The device boots up or is told to start advertising at a fast rate because the user has interacted with it. This is done for a limited amount of time to provide fast response when the user is expecting a quick connection.

After some pre-determined time, when no connection has occurred, the device then switches to a slow advertising rate which allows an app to connect, but limits the power consumption since the user may take some time to connect.

Advertising rates when a user has already connected depend on whether you want to use directed advertising and user requirements. But since the device may remain unconnected for significant amount of time, it’s important to limit it to conserve power.

BLE Advertising Packets

The Bluetooth Specification defines the top level packet in Bluetooth LE with two data units. The packet itself has several parts including a preamble and access address, as well as a CRC.

The Packet data unit for the advertising channel (called the Advertising Channel PDU) includes a 2-byte header and a variable payload from 6 to 37 bytes. The actual length of the payload is defined by the 6-bit Length field in the header of the Advertising Channel PDU.

It’s important to note that there are several PDU types for the advertisements, but here we will focus primarily on ADV_IND and ADV_NONCONN_IND.

ADV_IND is a generic advertisement and usually the most common. It’s generic in that it is not directed and it is connectable, meaning that a central device can connect to the peripheral that is advertising, and it is not directed towards a particular Central device.

When a peripheral device sends an ADV_IND advertisements, it is helping Central devices such as Smartphones find it. Once found, a Central device can begin the connection process.

ADV_NONCONN_IND is the advertisement type used when the peripheral does not want to accept connections, which is typical in Beacons.

The right Advertisement flavor to use depends on your application, whether you want to form a quick connection or avoid a connection completely.

Advertising Channel PDU

The Advertisement Channel PDU itself has payload that depends on the Advertising PDU type. The figure above shows the ADV_IND payload. This payload has an Advertisement Address of 6 bytes and a variable number of advertisement data structures.

After the advertisement address is taken into account (this is typically referred to as the Bluetooth MAC Address although it may change at will), we are left with 37 – 6 = 31 bytes for actual advertisement data structures. This has to fit a length, type and data itself.

We went through a few of the layers, and you can see that BLE encapsulates a lot of data the deeper you go. This gives you a lot of flexibility in supporting different behaviors that best suit your product.

At the lowest level, the advertisement has 31 bytes that can advertise any number of different things. You can see the full list of the Advertisement Data types on the Bluetooth Sig Website , each data type specifies a different standard of data in the payload.

Some of the most commonly used Advertising Data Types are:

• 0x06 Incomplete List of 128-bit Services: UUIDs of the services provided by the peripheral can be advertised in 128-bit format.
• 0x02 Incomplete List of 16-bit Service Class UUID
• 0x08 Shortened Local Name and 0x09 Complete Local Name

Since the number of advertising data structures is variable, you can combine them as needed.

The most important part of building the advertisement is getting the right information to the Central device (Smartphone or standalone Central device), and this usually depends on what’s important for your product. If your product provides unique services, you can advertise those services so that a Smartphone can distinguish your product from others nearby. For example, Beacons have custom data like unique UUIDs, power levels and other characteristics that are important for finding and using beacons.

The Bluetooth SIG also has the 0xFF data type which is manufacturer specific, so you have the flexibility of defining your own custom payload.  Apple did this for the iBeacons which combine a standard Advertising data type with a manufacturer specific one.

The defining your own advertisements gives you a lot of power, but it’s up to you to find the best way to get to where you want.

Bluetooth 5.0 – Advertising Extensions

Although Bluetooth 5.0 claim to fame is the longer range and higher data throughput features, one feature that will provide to help provide a better experience are the Bluetooth 5 advertising extensions. Instead of just sending advertising data on the 3 advertising channels, BLE advertising allow you to chain together advertising packets and use the other 37 channels that didn’t carry advertising data before. This is helpful for getting advertising data even in cases where there is a lot of interference.

Bluetooth 5 also enables an advertising packet to hold up to 255 bytes of data, which is a lot larger than the 37 packets that was possible in Bluetooth 4.0 up to Bluetooth 4.2. This makes it possible to get data without connections, which saves on power consumption and allows many devices to obtain the data.

These features require both devices to be Bluetooth 5 compatible, which isn’t currently very common as most smartphones are still support v4.2 or older. But over time this feature will begin getting traction and getting used in a number of applications.

Advertising Bluetooth Services

Although every application is different, advertising the most important or unique services provided by the peripheral is the easiest way to connect to it, and it makes sense in a lot of products. When an iPhone or Android is looking for devices, it can use the custom service UUID to find the exact devices it wants to talk to and filter out other devices. Searching for a specific address can be impossible, but finding devices that have unique IDs is easier.

For example, let’s say your product is a small light sensor. You can create a custom service with a unique 128-bit UUID. Then by including the UUID in the advertisement packet, an iPhone can ignore all other devices in the vicinity except your product. This makes finding devices faster since you don’t have to connect to each device to discover its capabilities.

This is also good when it comes to power savings. New generations of Smartphones are making more and more of the decisions and filtering on the low level. They do this because it’s more energy efficient to discard an advertisement packet early on if it’s not used than it is to inform the OS and the user of it and discarding it later. But the phone needs to have information about what to filter which the application has to provide, and it depends on unique UUIDs for services or device addresses.

A Quick Look into UUIDs

Once you start working with BLE devices, you’ll quickly realize that UUIDs are critical. Services,Characteristics and other items use UUID to uniquely identify them.

UUIDs are nothing more than unique 128-bit (16 byte) numbers:

75BEB663-74FC-4871-9737-AD184157450E

It’s typical to arrange the UUID in the format above  4-2-2-2-6. Each pair of characters actually indicate a hexadecimal number. So 75 above is actually 0x75.

To avoid constantly transmitting 16 bytes which can be wasteful (Bluetooth is very limited in the amount of data and 16 bytes are significant), the Bluetooth SIG has adopted a standard UUID base. This base forms the first 96 bits (12 bytes)  of the 128-bit UUID. The rest of the bits are defined by the Bluetooth SIG:

XXXXXXXX-0000-1000-8000-00805F9B34FB

The top 32-bits are up to you. For 16-bit UUIDs, the bottom 16-bits remain 0. For example the short form 16-bit UUID for the Heart Rate Service is:

0x180D

In reality this represents a 128-bit UUID:

0000180D-0000-1000-8000-00805F9B34FB

If you’re using existing services or profiles that were specified by the Bluetooth SIG, you can avoid using the full 128-bit UUID. But, custom services need a fully defined 128-bit UUID.

Creating UUIDs

The most important thing about UUIDs is that they’d be unique.

You can randomly generate them in various ways. One website that can generate them is Online UUID Generator. In Mac OS X you can use the uuidgen utility from the command line for the same thing.

Because of the number of bits, it’s unlikely that you’ll ever generate a similar UUID as anyone else. It’s most important that you avoid the Bluetooth SIG base in custom UUIDs.

Optimizing BLE Advertisements for Power and Latency

One of the most critical things to realize is the big tradeoff between power consumption and latency. Every advertisement consumes power. The BLE radio has to power up and transmit.  The less advertisements, the longer the system runs from a set of batteries. So is setting the advertisement interval to 10 seconds a good idea?

Well, let’s assume that a user wants to connect to the peripheral. Can you wait 10 seconds? A long interval can be very frustrating to a user, especially if the environment has interference and packets get lost. So, making the interval too large is bad for user experience. Somewhere in the middle, around 500ms to 1 second is a sweet spot for most products. In some of the Applications we’ve developed, we’ve increased it, but only after careful consideration. Some systems that don’t have users in the loop, so it’s easier to do.

When you’re building your advertisement packets, you also need to consider that more bytes mean higher power consumption. Each byte in the advertisement packet forces the radio to stay on longer to transmit, which uses more energy. In some cases, reducing the number of bytes in the advertisement to the bare minimum can help squeeze everything from the Coin Cell battery.

BLE Advertisements and the Smartphone

Bluetooth LE was designed to allow peripherals to be extremely low power. It does this partially by placing much of the burden on the smartphone, with the assumption that a smartphone has a larger battery and is frequently recharged. In real products, you want to avoid causing significant battery drain on the smartphone. Enabling Bluetooth drains the battery faster, and some users will end up disabling Bluetooth or your app in frustration. This is a problem for most products that want to provide the user with a fast experience.

Much of the power used by smartphones comes from scanning for advertisements.  Because of this, Android and iOS limit significantly the scanning, especially background scanning.

While your App is in the foreground, you basically have complete control of the BLE and you have a high priority. It makes sense because Apple and Google know you want to show data quickly to the user, so there’s no point in delaying it.

Once your application is in the background, looking for nearby devices (if your application supports it), the OS usually downgrades the priority. This is done in a few ways:

• The scanning interval increases, so it takes longer to discover a peripheral device that is advertising. This is especially true if, for example, there is no BLE app in the foreground scanning.
• The OS will generate less advertisement discovery events, such as multiple discoveries of the same device.

Android and iOS each handle this separately, so it’s important to understand what effect running in the background has on your device and connection.

Scan Response

We already mentioned that the advertisement packet has 31 data bytes available for you to use. This isn’t much, especially when you consider that a 128-bit UUID takes 16-bytes. If you want to include more information, your only choice is to respond to scan responses.

When a a smartphone scans for advertisements, it can also request more information from the advertising device without forming a connection. This is done through a Scan Request which is a special packet that is sent to the peripheral. The BLE peripheral receives the Scan Request and responds with a Scan response.

Both iOS, Android and other systems issue Scan Requests automatically without user intervention when scanning. Your device will therefore receive these requests if it has it enabled.

The Scan Response packet has the same packet format as the advertisement, with the exception of the type on the higher layer indicating it’s a scan response instead of an advertisement. So your scan response can provide the device name or other services you didn’t mention in the advertising packet.

BLE Beacons and iBeacons

No discussion of BLE Advertisement would be complete without discussing Beacons and in particular Apple’s iBeacon standard.

Beacons are BLE peripherals that use advertisements exclusively, without allowing connections. The reason connections are not allowed is that if the Beacons were to establish a connection, advertisements would have to stop, so no other device could find the beacon. The packet format sent varies. and Apple’s iBeacon uses a very specific format for the payload.

You can see the format for the iBeacon packets. These packets use the basic BLE format, with some specific fields. Let’s go through them one by one.

The advertisement packet contains the Bluetooth MAC address and the payload. The payload is composed of two AD Structures, the first one gives generic information using the Flags Data Type, and the second is the Apple specific iBeacon information.

Flags Advertising Data Type

This packet has data type 0x01 indicating various flags. The length is 2 because there are two bytes, the data type and the actual flag value. The flag value has several bits indicating the capabilities of the iBeacon:

• Bit 0 – Indicates LE Limited Discoverable Mode
• Bit 1 – Indicates LE General Discoverable Mode
• Bit 2 – Indicates whether BR/EDR is supported. This is used if your iBeacon is Dual Mode device
• Bit 3 – Indicates whether LE and BR/EDR Controller operates simultaneously
• Bit 4 – Indicates whether LE and BR/EDR Host operates simultaneously

Most iBeacons are single mode devices BR/EDR is not used. For iBeacons, General discoverability mode is used.

iBeacon Data Type

The most important advertisement data type is the second one. The first byte indicates the number of bytes, 0x1A for a total of 26 bytes, 25 for payload and one for the type. The AD type is the Manufacturer Specific 0xFF, so Apple has defined their own Advertisement Data.

The first two bytes indicate the company identifier 0x4C00. You can see identifiers for other companies as well.

The second two bytes are beacon advertisement indicators. These are always 0x02 and 0x15.

The critical fields are the iBeacon proximity UUID which uniquely identifies the iBeacon followed by a major and minor fields.

Each iBeacon has to have a unique UUID so that an iPhone app can know exactly where it is located relative to one or more iBeacons.

Finally, there is also a 2’s complement of the calibrated TX power that can be used to improve location accuracy knowing the power level of the beacon.

There’s nothing stopping you from creating your own beacons with a different manufacturer format. The problem is that Apple specifically detects iBeacons with the particular format, so there won’t be any interoperability.

Key Terms And Concepts

1. Generic Attribute Profile (GATT) :
   The GATT profile could be a general specification for sending and receiving short pieces of information called “attributes” over a BLE link. GATT supports all current BLE app profiles.
2. Generic Access Profile (GAP) :
   GAP is mandatory for BLE devices as it defines a framework for enabling device discovery, security, connectivity, and related network technologies. This defines the role that the Connection can implement.
3. Profiles :
   Profiles can be specifications that show how the tool works in a particular application. Note that a tool can implement quite one profile. For example, a tool could contain a vital sign monitor and a battery level detector.
4. Attribute Protocol (ATT) :
   GATT is made on top of the Attribute Protocol (ATT). ATT is optimized to run on BLE devices. Up to this point, use as few bytes as possible. Each attribute is uniquely identified by a Universally Unique Identifier (UUID). This can be in the standardized 128-bit format of the string identifier used to identify the information uniquely. The attributes transported by ATT are formatted as characteristics and services.
5. Characteristic :
   The lowest level concept in GATT transactions is the Characteristic, which encapsulates one datum. Similar to Services, each Characteristic distinguishes itself via a pre-defined 16-bit or 128-bit UUID. Characteristics are the most point that you will interact with along with your BLE peripheral, so it is vital to grasp the concept. They also want to send data back to the BLE peripheral since you’re also ready to write to characteristics.
6. Descriptor :
   Descriptors are defined attributes that describe a characteristic value.
   For example, a descriptor might specify a human-readable description, an appropriate range for a characteristic’s value, or a unit of measure specific to a characteristic’s value.
7. Service :
   Services are accustomed to breaking data into logical entities and containing specific chunks of information called characteristics. A service can have one or more characteristics. Every service distinguishes itself from others using a singular numeric ID called a UUID, which may be either 16-bit or 128-bit.

BLE Operations

You must communicate with the BLE device to perform any action or operation. Therefore, BLE communication can be combined into three operations.

1. Read:
   When this property is enabled, the app will read the value of the property or descriptor of the BLE device and interpret it based on the previously created protocol.
2. Write :
   We can write data 2 ways:-
   Write With The Response: If you enable this property, you can write characteristic values ​​and get confirmation from the BLE device after completing the process.
   Write Without Response: If you enable this property, you can write characteristic values, but you will not receive confirmation from the BLE device after the operation is complete.
3. Notify / Indicate:
   Both are a way for the peripheral to notify the medium when the feature value changes. The only difference between notifications and indications is that notifications need to be accepted by the client when receiving a package, while indicators require this type of acceptance. So it moves slowly.

GAP Roles

GAP is a topology for maintaining connectivity between BLE devices and the devices that control BLE devices. GAP roles can be defined in two ways.

The first one is Broadcasting or connectionless.
The second one is Connecting or connection-oriented.

Broadcasting OR ConnectionLess

1. Broadcaster :
   Devices with the sender role only send data to this environment. This is done through continuous advertising and usually contains useful data in your ad package, that is, data that is visible to everyone. Such devices do not require a receiver and do not accept connections, as their sole job is to send them to others.
2. Observer :
   Observers are the opposite of broadcasters. Observers passively listen to nearby BLE devices and process the data in their ad packets. No transmitter is needed as it does not broadcast anything and does not connect.

Connecting OR Connection-Oriented

1. Peripheral Devices :
   BLE peripherals are generally low-power devices. Peripherals can be scanned with a Bluetooth central device. When Connection is established, the peripheral act as an enslaved person. Smartwatches, bracelets, sensors, fitness bands and smart light bulbs are examples of peripherals.
2. Central Devices :
   The central device is usually a high-power energy device. A hub is a device that searches for Bluetooth devices and connects to and uses the information they contain. Central devices are typically richer in resources, such as computing power, than peripheral devices. Pre-attached: The device is designated as the central device at boot time and as the master after it is connected. Laptop, mobile, and tablet devices are examples of core devices.

How Does Bluetooth Low Energy Work?

GATT is an acronym for Generic Attribute Profile, which uses services and characteristics to define how two Bluetooth Low Energy devices exchange data. GATT works when a dedicated connection is established between the two devices. This means that you have already completed the GAP-regulated advertising process.

The most important thing to note about GATT and connections is that the connections are exclusive. BLE peripherals can only connect to one central device (such as a mobile phone). When a peripheral connects to a central device, it stops advertising itself, and other devices cannot recognize or connect to it until the existing connection is broken.

Establishing a connection is also the only way to enable two-way communication. In this case, the central device can send meaningful data to peripheral devices and vice versa. The operation of BLE can be divided into three sections described below and will help you understand how Bluetooth low energy works.

Attribute And Data Hierarchy

Attributes are the smallest data entity defined by GATT (and ATT). These are addressable information that may contain relevant user data (or metadata) about the structure and grouping of the various attributes contained in the server. GATT and ATT work only on attributes, so all information must be organized in this format for the client and server to interact.

The attributes of the GATT server are grouped into services, and each service may contain zero or more characteristics. These features can contain zero or more descriptors. The “Important Terms” section above discusses the relationship between services and features.

Most data types in the GATT hierarchy must distinguish between their definitions (the entire set of attributes that make them up) and their declarations. Declarations are the single attribute that always comes first (in ascending order of handles) in the definition and introduces most of the metadata for subsequent data.

All declarations have read-only permissions that do not require security because they cannot contain sensitive data. These are just structural attributes that allow the client to understand and discover the server’s layout and type of attributes.

Central And Peripheral Communication

A central device and peripheral devices are required to perform BLE operations. Peripherals advertise themselves and contain information. The central device scans for ad packages. Once connected, you can perform BLE operations. The central device can perform read and write operations if peripheral functions give this permission.

BLE technology acts as an intermediary between both types of devices. When operating with BLE peripherals, notification/display operations can be performed on the central device. This type of surgery is useful for all kinds of emergencies.

Example Service

This section provides examples of specific services found in many commercial products today. Heart rate service (HRS) relays your heart rate to a monitoring device.

This heart service has several features, each with a descriptor. The structure of the attributes is as follows:

Attribute Handle

The attribute handle is a 16-bit unique identifier:

• Makes the attribute “addressable.”
• Does not change.

Handle values ​​grow in an ordered order on the server (gap allowed) and during the discovery process Detected by the client.

Attribute Type (Universally Unique Identifier (UUID))

The attribute type determines the data type present in the attribute’s value and uses a 2-byte or 16-byte UUID. Here is an example:

• Service UUID
• Characteristic UUID
• Profile UUID
• Vendor-Specific UUID

Attribute Value

The attribute value contains the actual data content that the client can access. You can also include metadata about the attribute (depending on the type).

Attribute Permissions

Attribute permissions are attribute metadata that specifies:

• ATT access operations are allowed on attribute values. The allowed operations are read and write, no operations.
• Security requirements. In this case, encryption is required. Cryptography has different types of layers that are also needed for security. Authentication is also required for security, such as biometrics and password authentication..

Network Topology

Bluetooth Low Energy devices can communicate with different devices by using two different network topologies: Broadcasting and Connections.

• Broadcasting 

Using connectionless broadcasting, you can send data to any scanning device or receiver within listening range. This technology essentially allows you to send data to anyone or anyone who can pick up the communicated data.

Broadcasting is crucial to comprehend since it is the only means for a device to simultaneously send data to several peers. You can broadcast data by using BLE’s advertising features. Broadcasting is quick and simple to use, and it is an excellent option if you simply need to send a small quantity of data to several devices regularly.

When opposed to a conventional connection, one of the key disadvantages of broadcasting is that there are no security or privacy safeguards; that is, any spectator device can receive the data being broadcasted; hence the broadcasting topology may not be suitable for sensitive data.

• Connections 

Connections are one of the most widely used network topologies, which is convenient and better and establishes a secure bidirectional one-to-one (1:1) data transfer link. A peripheral/ central GAP roles pair is required to make a BLE connection.

The peripheral GAP function uses as little computing power and memory as possible. Most of the time, this is the job chosen for the device under development. A central device receives connectable advertising packets from a peripheral and makes a request to the peripheral to establish an exclusive connection between the two devices to commence a connection.

The peripheral stops advertising once the connection is established, and the two devices can begin exchanging data in both directions. A connection is thus nothing more than the periodic data exchange between the two peers involved in it at certain times (connection events).

It is worth noting that, while the center is the device that handles connection setup, data can be transmitted independently by either device during each connection event. The roles have no bearing on data throughput or priority. 

Applications of BLE

Based on the limitations and benefits we mentioned earlier, there are a number of use cases where BLE makes the most sense. Therefore, BLE can be used in different personal and professional applications.

• Wireless charging
• Medical service
• Smart Kitchen
• Smart Tags
• Mobile payments concept
• Track a pet’s behavior
• Automotive industry
• Home automation systems.
• Personal and wearable devices
• Broadcast only devices

What Makes Bluetooth Low Energy (BLE) Different?

Bluetooth Low Energy is a separate Bluetooth standard incompatible with conventional Bluetooth. The latter was originally commercially released almost 20 years ago, and the Bluetooth Special Interests Group (SIG) is no longer actively developing it.

Not being developed certainly does not imply not being used. It is commonly found in devices that demand a constant connection, mostly audio devices such as wireless speakers and headphones. 

The main distinction between Bluetooth Low Energy and Bluetooth is Bluetooth Low Energy’s ability to consume less energy. Compared to traditional Bluetooth, BLE is designed to use significantly less power and cost while retaining a similar communication range.

Applications with minimal energy consumption can run on a small battery for longer periods. Although this is inconvenient when talking on the phone, it is critical for applications that regularly transmit small amounts of data.

Bluetooth Classic is meant for continuous two-way communication, but Bluetooth Low Energy (BLE) sends smaller data packets over shorter durations. Just as the name implies, Bluetooth Low Energy consumes far less energy, up to 100 times less than Bluetooth Classic.

Bluetooth Classic, on the other hand, provides a bigger range and higher data throughput because it is not as constrained. Bluetooth Low Energy is natively supported by mobile operating systems such as iOS, Android, Windows Phone, and BlackBerry, as well as macOS, Linux, Windows 8, and Windows 10.

Limitations of BLE

Data Throughput

The data throughput of BLE is limited by the physical radio data rate, which is the rate at which the radio transmits data. This rate depends on the Bluetooth version used. For Bluetooth 4.2 and earlier, the rate is fixed at 1 Mbps. For Bluetooth 5 and later, however, the rate varies depending on the mode and PHY (discussed later in the Physical Layer section) being used. The rate can be at 1 Mbps like earlier versions, or 2 Mbps when utilizing the high-speed feature. When utilizing the long-range feature, the rate drops to either 500 or 125 Kbps. Weʼll discuss each of these in more detail in the section on Bluetooth 5.

At the application layer and for the end-user, the data rate is much lower than the radio data rate due to the following factors:

Gaps in between packets: The Bluetooth specification defines a gap of 150 microseconds between packets being transmitted as a requirement for adhering to the specification. This gap is time lost with no data being exchanged between two devices.

 Packet overhead: All packets include header information and data handled at levels lower than the application level, which count towards the data being transmitted but are not part of the data utilized by your application.

 Slave data packets requirement: The requirement to send back data packets from the slave, even when no data needs to be sent back and empty packets are sent.

Retransmission of data packets: In the case of packet loss or interference from devices in the surrounding environment, the lost or corrupted data packets get resent by the sender.

Range

BLE was designed for short range applications and hence its range of operation is limited. There are a few factors that limit the range of BLE including:

• It operates in the 2.4 GHz ISM spectrum which is greatly affected by obstacles that exist all around us such as metal objects, walls, and water (especially human bodies).
• Performance and design of the antenna of the BLE device.
• Physical enclosure of the device which affects the antenna performance, especially if itʼs an internal antenna.
• Device orientation, which effectively relates to the positioning of the antenna (e.g. in smartphones).

Advantages of BLE

Even with the previously mentioned limitations of BLE, it has presented some significant advantages and benefits over other similar technologies in the IoT space. Some of these advantages include:

• Lower power consumption Even when compared to other low-power technologies, BLE achieves a lower power consumption than its competitors. It’s optimized, and less power consumed, by turning the radio off as much as possible, in addition to sending small amounts of data at low transfer speeds.
• No cost to access the official specification documents With most other wireless protocols and technologies, you would have to become a member of the official group or consortium for that standard in order to access the specification. Becoming a member of those groups can cost a significant amount (up to thousands of dollars per year). With BLE, the major version (4.0, 4.1, 4.2, 5) specification documents are available to download from the Bluetooth website for free.
• Lower cost of modules and chipsets when compared to other similar technologies.

Last but not least, its existence in most smartphones in the market. This is probably the biggest advantage BLE has over its competitors such as ZigBee, Z-Wave, and Thread