The Ultimate Guide to Managing Your BLE Connection

Table of Contents

19 minute read

One of the core aspects of designing a BLE application is determining how connections will be managed. There’s more to it than simply starting a connection whenever the devices should communicate. You must consider the following:

• When to advertise
• When to request connections
• How to make your devices available to connect
• When to disconnect
• How to limit connections

Note that this blogpost covers the most common Bluetooth behaviors. The Bluetooth Specification describes advanced modes that won’t be discussed here. In most cases, those modes are not necessary for an application, introduce additional complexity, or aren’t universally supported by phones or Bluetooth stacks. If you do need to take advantage of those modes, you’ll want to already be well-versed in the contents covered by this post.

To start, let’s cover some basics of BLE. 

Many BLE applications consist of an embedded device (often low-power) interacting with a mobile device. For example, this could be a fitness tracker and a phone. In this case, the low-power device (fitness tracker) usually assumes the “Peripheral” role and the mobile device (phone) assumes the “Central” role within the BLE GAP layer. The BLE specification’s intent is that the low-power device assumes the Peripheral role because the Peripheral requires much less power. 

By the way, we have created a handy glossary at the end of this post in an effort to define critical BLE terms without too much jargon.

Advertising Overview

Advertising: Before any connection can begin, the Central must receive one of the Peripheral’s advertisements while scanning. This means the Peripheral must send periodic transmissions known as advertisements to announce its presence. The advertisement packet consists of self-identifying data, which could consist of a string of the device name, a UUID, or perhaps just an address. 

The advertisement can also contain a few other fields to provide additional information, but this is limited to only tens of bytes. Overall, up to 64 bytes¹ of data, including metadata, can be sent via advertising² in a typical scenario. These fields are known as “Advertising Data (AD)” and they’re defined in the Core Specification Supplement.

After sending each advertisement, the Peripheral listens for a brief duration. During this window, the Central may send a Scan Request or a Connection Request. The Peripheral responds to a Scan Request with a Scan Response. The Scan Response is basically a secondary advertisement that stores additional Advertising Data.

¹ More data may be sent with extended advertisements. This is a more advanced feature that was introduced in BT v5.0. We won’t cover it in this blogpost
² 64 bytes includes both the advertisement and the scan response

Scanning: The Central will scan for advertisements by listening on known frequencies that advertisements are sent. Because the Central can only listen on one frequency at a time, and must share the 2.4GHz band with other applications (e.g. Wi-Fi), the Central is limited to listening periodically for advertisements. This means that in order for the Central to discover the Peripheral, the Peripheral’s advertisement must coincide with the Central’s scanning window and frequency.⁴

⁴ BT v5.0 introduced “Periodic Advertising.” This is an advanced feature that allows the Central to synchronize with a Peripheral’s advertisement transmissions.

When Advertising is enough: If all your application requires is to send a tiny amount of relatively static data at low rates from the low-power device to the mobile device, then your application might not need to ever connect. Simply advertising is sufficient, in which case the low-power device advertises just like a Peripheral. According to GAP role terminology, this advertiser is a Broadcaster instead of a Peripheral because it’s configured to never connect. Likewise, the phone would be an Observer instead of a Central. 

But remember that when broadcasting, the Observer usually won’t see every packet because there’s no guaranteed delivery. As a result, broadcasting dynamic data or segmenting data across multiple packets isn’t a viable option.⁵

⁵ “Periodic Advertising” presents interesting possibilities for dynamic broadcast data. Additionally, configuring devices as both broadcasters and observers presents the opportunity for connectionless data exchange. We’ll let your creativity explore whether these options could be right for your application

Connections Overview

But what if your application requires more than sending a few bytes of static data in one direction? This is where connections come into play. First, it’s important to understand a few mechanics of a connection. 

Establishing a Connection: Connections are initiated by a Central responding to an advertisement with a connection request. This means that in order to connect, a Peripheral first must be advertising. After sending each advertisement, the Peripheral listens for a brief duration. During this window, the Central may request the connection. If the Peripheral isn’t advertising, the devices cannot connect. And once advertising, the Peripheral can’t force the connection. The Central must initiate.

During a Connection: Once connected, advertising is no longer used for communication between connected devices. Instead, devices communicate with each other at a periodic interval known as the connection interval. At each connection interval, a connection event takes place in which the Central sends a packet and the Peripheral responds with a packet. 

If there’s data to be sent by either side, they send it in the packet. If there’s no data, then an “empty packet” is sent. If there’s enough data to be sent by either side, multiple back-to-back packet exchanges may occur during a single connection event. These packet exchanges serve as a handshake to maintain the wireless connection even if no application data needs to be sent for extended durations.

Multiple Connections: Both a Central and a Peripheral can be connected to multiple devices at a time. In order for a Peripheral to accept connections from more than one Central, a Peripheral must continue to advertise even while in a connection. If only one connection is desired, it’s good practice to stop advertising while connected. 

Additionally, a device can operate as both a Central and Peripheral where it serves as one role with one device and a different role with another device. For the purposes of this blog post, we’ll focus on a single connection. Refer to the later section “Multi-Central Connection Management” for additional details.

Terminating a Connection: While connected, either device can terminate a connection through a simple request. Connections are also “lost” after either device doesn’t receive a packet from the other side for a configurable duration known as the Supervision Timeout. The Supervision Timeout can range from 100 milliseconds up to 32 seconds. After a connection ends, the Peripheral may or may not decide to resume advertising. Likewise, the Central can decide whether to keep scanning for advertisements or not.

Summary: The following diagram illustrates the general connection flow between a Peripheral and Central:

When to be connected

There’s no obvious answer to deciding when to be connected. Unlike a wired connection, the low-power wireless-nature of BLE means a connection won’t or shouldn’t necessarily be available on-demand at all times. Some applications will be best suited with staying connected whenever possible, while others may only need to connect for a quick data exchange and then disconnect. There are also plenty of hybrid options.

When designing a system with BLE, you’ll need to decide when the Peripheral will advertise, when the Central will request a connection, and if/how the connection will be expected to terminate.

Here are the major factors to affect your design:

Availability

Availability refers to the Peripheral and Central being in a state of readiness for exchanging data.⁶ When connected, both the Peripheral and the Central are free to asynchronously exchange data with each other. In reality, devices may go in and out of range, meaning it’s not possible to always be connected. So when it comes to the mechanics of always being connected, this means the Peripheral is always advertising while not connected and the Central is always scanning and attempting to connect. Once devices are in-range, they will connect.

While attempting to always be connected is ideal from an availability perspective, there are a few possible drawbacks compared to limiting when connections will occur:

1. Power consumption
2. Persistent notification
3. Availability of a Peripheral to other Centrals

These will be discussed in later sections. In the meantime, the alternative to not always being connected is either limiting advertising or limiting scanning. 

⁶ “Availability” is not an official term. This is our own definition for the sake of this blogpost.

Limiting Advertising: If the Peripheral is solely responsible for knowing if and when data should be sent to the Central, the Peripheral can start advertising only upon these triggers. Then if the Central is always scanning, the Peripheral effectively controls the start of a connection when it starts advertising. 

Example: A button press or accelerometer event could wake the Peripheral from sleep and trigger advertising. The Central’s scanning sees the advertisements and initiates a connection. The Peripheral reports the event, disconnects, and goes back to sleep.

Limiting Scanning: If the Central is solely responsible for knowing if and when data should be exchanged, the Peripheral may need to always be available. With the Peripheral always advertising, the Central can decide when to connect and whether to stay connected or to perform the data exchange and disconnect. On mobile platforms such as Android and iOS, the OS is usually performing some degree of background scanning, but it won’t request a connection unless an app requests it or if the Peripheral implements the HID GATT profile.

Example: Data exchange is only needed while a mobile app is in the foreground. The user opens the app, scanning starts, and a connection is made. Then the app uploads data from the Peripheral and displays this in the app, or the user chooses something in the app that downloads information to the Peripheral. After this activity completes, the app can terminate the connection.

If both the Central and Peripheral need to asynchronously exchange data, always attempting to stay connected (i.e. always advertising and always scanning while not connected) is usually best.

Example: A smartwatch’s mobile app sends mobile notifications to the watch (even while backgrounded) for prompt display on the wrist. From the other end, a user starts an exercise from the watch, triggering GPS tracking on the phone.

Power Consumption

From the Peripheral’s perspective, perhaps the biggest limitation to always being connected is power consumption. If your Peripheral is a low-power battery-operated device and it requires infrequent data exchanges with no latency requirements, there’s no need to waste power by always advertising or being connected constantly. A user action such as a button press or an internal event can wake the device and it can start advertising.

However, if your device needs to always be made available for a connection, then it needs to always advertise or be connected. The power consumption difference between advertising and being connected depends heavily on the parameters defining transmission intervals (the advertising interval and connection parameters), but generally, it’s advantageous to be connected over advertising. With both advertising and being connected, there are parameters for minimizing power consumption, but with an impact on latency of data exchange. Here’s some background:

Advertising for Power Consumption vs Latency

Advertising’s primary parameter is the advertising interval, which can range from 10s of milliseconds to over 1 second. This is the interval at which a set of advertisement packets is transmitted. The advertising interval may be adjusted on the fly based on the GAP Discoverable Mode: either by always advertising at a constant interval (General Discoverable Mode), initially advertising at a rapid interval and then reducing the interval, or advertising for a duration and then stopping (Limited Discoverable Mode).

A fast interval is useful for minimizing connection latency, i.e. the time it takes for a scanning device to detect the advertisement and initiate a connection. A slow interval is better for lower power consumption. Note that the duration it takes to connect is probabilistic, and it may take many seconds if a long advertising interval is used. 

To balance connection latency vs power consumption, it may be ideal to use a fast interval (under a few hundred milliseconds⁷) for a short duration (e.g. 30 seconds) at Peripheral power-up, upon disconnection, or upon a user event like a button push. After 30 or more seconds, either reduce the advertising interval (between 1.0 and 1.2 seconds is recommended by the Bluetooth Spec⁸) or stop advertising. Obviously, if advertising is stopped, you may need a way to restart advertising in the future!

⁷ Most likely, a BT stack’s examples will include default advertising intervals. These are a good starting point. Also, refer to the Bluetooth Core Specification Version 5.3 | Vol 3, Part C, Appendix A for detailed recommendations.
⁸ Bluetooth Core Specification Version 5.3 | Vol 3, Part C, Appendix A, T_GAP(adv_slow_interval)

Connection Parameters and Power Consumption vs Latency

Power consumption during a connection is primarily configured by the connection parameters. These parameters are the connection interval, peripheral latency, and supervision timeout. The combination of the connection interval and peripheral latency parameters define how frequently the Central and Peripheral exchange packets for maintaining a connection.⁹ 

Most stacks use a default connection interval of under 100 milliseconds and a peripheral latency of 0. These parameters can be updated upon request from the Peripheral (Android and iOS don’t provide an interface for this). By reducing the interval at which a Peripheral’s radio is in receive or transmit mode, using a longer connection interval and/or higher peripheral latency can substantially reduce Peripheral power consumption, but at the expense of increase latency and or throughput when data needs to be transmitted.

It’s possible to request unique connection parameters depending on system state, such as requesting fast connection parameters when needing to perform lots of data transfers and requesting slow connection parameters when the system does not.

⁹ Refer to the glossary for a more complete explanation of connection interval and peripheral latency

Transmit Power

It’s worth explicitly mentioning that the previous sections emphasize reducing radio activity because radio transmission and reception (even if no packet is being received) modes are the primary power consumers in the BLE portion of an application. While most radios have limited options for adjusting power consumption while in receive mode, transmit power is generally adjustable. A lower transmit power will reduce overall power consumption with the consequence of reduced wireless range. But if your application doesn’t require a far range, reducing transmit power may be a good knob to adjust. Your BLE stack may provide an option to configure advertising TX power separately from TX power while in a connection.

For optimal power control, Bluetooth Core Specification v5.2 introduced “LE Power Control.” This feature allows the BLE stack to adjust transmit power levels dynamically to avoid wasting energy by transmitting at a higher power than necessary.

Power Consumption Takeaways

Many factors will influence how to choose connection behaviors to optimize for power consumption. But here are a few key takeaways if power consumption is a major constraint:

1. For optimal battery life, advertise and connect only when needed. Sleep at other times.
2. As discussed elsewhere in this post, sleeping may not be viable. In these cases, use longer advertising intervals and/or connection parameters.
3. Advertising with a long advertising interval and maintaining a connection with a long connection interval + peripheral latency combination is approximately the same order of magnitude of power consumption. Therefore, maintaining a connection may be preferable due to avoiding latency of initiating a connection.
4. Adjust transmit power to meet range requirements. Consider enabling the LE Power Control feature if available.
5. Consider the overall power budget on your Peripheral. Maybe BLE only consumes a small fraction of overall device power, meaning optimizing BLE power consumption is not essential.

Latency

While in a connection, either the Peripheral or Central can asynchronously send application data at any time with low latency. If not already connected, starting a connection is not instantaneous. The duration for a Central to respond to an advertisement while scanning is probabilistic and it could take several or even tens of seconds, largely depending on the advertising interval. This means if your system requires low latency between the occurrence of an event and data being received over BLE, it’s best to already be connected.

Latency will be influenced by power constraints: If power consumption is not a concern, the Peripheral can advertise at a faster rate, reducing the latency to connect. Once connected, the Peripheral can maintain a fast connection interval with no peripheral latency. If power consumption is a concern, refer to the Power Consumption section above.

Android’s Persistent Notification

This is a mobile-specific impact of always trying to be connected. If using Android, you may have experienced some apps requiring a “persistent notification” in the notification drawer. This is a side effect of using a Foreground Service, which is required to allow the app to continually scan for and communicate with the Peripheral even when the app is backgrounded. This can be a nuisance you don’t want your mobile app to deal with. 

So, what can you do? 

If you need your mobile device to always be receiving data from the Peripheral even if the user is not in your app (e.g. it needs to send regular data to the cloud or respond to high priority events), not much — you need a Foreground Service. 

But if your system can wait to communicate with the Peripheral until the app is opened, then scan and attempt to connect at some point while the app is active. This means the peripheral will spend a lot of time advertising whenever the app isn’t opened, and the peripheral will want to use a lower advertising interval, so that the Central can connect quickly once the app is opened.

Android’s foreground services have a wide set of use cases beyond BLE. The persistent notification exists as a way to enforce transparency since foreground services can have a significant impact on battery life, or otherwise operate maliciously. From Android 13 onwards, users will also be able to terminate foreground services easily via a Foreground Services Task Manager, so this approach isn’t bulletproof by any means. User education would be important to ensure that they don’t inadvertently terminate the app process and sign up for a user experience downgrade.

iOS approaches the backgrounding issue very differently. iOS apps can take advantage of features within the Core Bluetooth framework that allow the app to spend a short amount of time (~10 seconds) running in the background in response to a BLE event such as connecting, disconnecting, or receiving a notification or write response. iOS will even restore applications that have been removed from RAM in response to a BLE event. Overall, the iOS implementation is much cleaner and has less impact on the user.

Multi-Central Connection Management

If a 1-to-1 relationship between the Central and Peripheral is desired (i.e. the Peripheral doesn’t need to interact with multiple Centrals), always staying connected is more viable. If multiple relationships are desired, always staying connected may limit access to the Peripheral among Centrals.

A Peripheral can support multiple connections at a time, but doing so in a Peripheral can bring additional complexity due to managing connection limits, managing bonds if applicable, and receiving data from multiple sources. If using multiple connections, the Peripheral must continually advertise as long as it’s accepting additional connections. 

If only one connection is allowed, advertising can be stopped while connected. This makes connection management simpler and it conserves power, but it results in a first-come-first-serve scenario for Centrals. If wanting to maintain the simplicity of a single connection at a time, only connecting when needed allows multiple Centrals to interact with the peripheral without much delay.

Reconnection Frequency

When either the Peripheral or Central intentionally terminates a connection, keep in mind that the central is responsible for deciding whether to connect again when it sees an advertisement. Take care to avoid a loop where a Peripheral or Central intentionally terminates a connection, then a Peripheral advertises immediately, the Central  initiates a connection as soon as it sees an advertisement, the devices connect and complete their data exchange, the connection is terminated, and the cycle repeats again. This is power inefficient. After an intentional disconnection, typically either the Peripheral should not restart advertising immediately or the Central should not start scanning immediately.

Privacy

Once you have your plan for when to advertise and connect, it’s important to step back and consider who can see the Peripheral’s advertisements and attempt to connect. Advertisements can be seen by anyone, and they’re always in plaintext. Therefore, do not put any sensitive information in them. This also means the Peripheral can be tracked, such as going to the mall and a store could detect your presence anytime you go. 

To mitigate this, BLE has a feature known as LE Privacy in which the Peripheral’s advertisement address changes at a configurable interval, making it more difficult to track a Peripheral. However, be careful because the privacy effects of rotating the peripheral’s address can be negated by including other static data in the advertisement that uniquely identifies the peripheral.

Limiting Connections

Because the Peripheral’s advertisements announce its presence to the world, any Central can request to connect. If the Peripheral does not need to support multiple connections and therefore stops advertising while connected, this may mean an undesired device nabs the connection. Even if the Peripheral terminates the connection, the same or different Central could reconnect, causing a denial of service.

It’s tempting to think bonding will solve this issue, but bonding occurs at a different level than connections. BLE security occurs after a connection is made. Bonding can prevent a device from unauthorized interactions with your peripheral’s application layer, but it alone won’t stop an unbonded Central from connecting to the Peripheral.

Luckily, there’s a way for the Peripheral to limit connections: using a Filter Accept List. 

If the Peripheral can authenticate a Central one time, then the Peripheral can utilize a Filter Accept List. The Peripheral adds the Central to its Filter Accept List, meaning the Peripheral ignores connection requests from any Central outside the Filter Accept List. This means your system needs a way to allow devices to connect and be added to the Filter Accept List. 

Typically, a special mode could disable using a Filter Accept List for a short duration, allowing any device to connect. There’s also an option to provide the Filter Accept List address out-of-band. Keep in mind that a Filter Accept List is not a replacement for security, as any device could spoof a Filter Accept Listed address.

Summary

When designing a BLE application, there’s plenty to consider with managing connections. Here are a few key points to remember:

• A low-power Peripheral announces its presence by advertising.
• A Central device such as a phone scans for an advertising Peripheral.
• A Peripheral may advertise indefinitely or as little as needed, but a Central cannot request a connection unless a Peripheral is advertising.
• Maintaining a connection promotes responsive, low-latency data exchange between the devices.
• Applications may attempt to maintain a connection indefinitely. Adjust the Connection Parameters to balance power consumption against latency.
• Devices will inevitably disconnect due to going out-of-range, power cycling, interference, etc. Factor these possibilities into your design.
• By default, any Central can connect to your Peripheral, although bonding or application-level authentication can prevent unauthenticated devices from exchanging data with your device. To prevent a connection in the first place, use a Filter Accept List.
• Every application is unique. Some applications are best suited by always attempting to be connected, while others are best suited by minimally advertising/scanning with quick connections. Some applications don’t even require connections.

Glossary

The following glossary attempts to define BLE connection-related terms without too much Bluetooth jargon. Official definitions can be googled elsewhere, but while those definitions can be technically precise, they can still be confusing.

¹⁰ Bluetooth Core Specification Version 5.3, Vol 3, Part C
¹¹ Bluetooth Core Specification Version 5.3 | Vol 6, Part B, Sect 4.5