The Ultimate Guide to Managing Your BLE Connection

Introduction

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

What This Guide Covers

Note that this article 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. 

---

The Basics of Bluetooth Low Energy

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.

Note: There is a handy glossary at the end of this post in an effort to define critical BLE terms without too much jargon. If you want to dive deeper, check out our BLE Connectivity Architecture: The Ultimate Guide.

---

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.

Related Ultimate Guides

For more expert connectivity development resources, check out our other great guides:

---

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.

Term	Definition
Advertising	The process of the Peripheral announcing its presence to the world by transmitting periodic advertisement packets.
Advertising Data	The contents of the advertisement or scan response packets. The advertising data is primarily used to identify the peripheral. The central scans for advertisements and inspects the advertising data to determine if the peripheral is the device it wants. The type and format of the data is defined in Bluetooth Core Specification Supplement.
Advertising Interval	The interval at which a set of advertisements is transmitted (A set consisting of an advertisement being sent on each of the three advertising channels/frequencies). This is configured in the Peripheral. Acceptable values depend on using limited discoverability vs general discoverability. Apple recommends selecting from a specific set of intervals for iOS compatibility. Faster interval=faster time to connect Slower interval=less radio usage, lower power consumption
Bonding	The process of storing keys in the Central and Peripheral devices for the purpose of privately identifying each other at a later date and securely reestablishing an encrypted channel. Basically, bonding creates a unique relationship between the devices. Bonding also results in a Peripheral showing up in a mobile/computer list of paired Bluetooth devices in the OS system settings.
Broadcaster	One of the two GAP roles that a device assumes when not seeking a connection, the Broadcaster sends regular advertisements without the intention of making a connection. The Broadcaster transmits data to any Observer in range without seeking a response from the Observer.
Central	One of the two GAP roles that a device assumes when seeking a connection, the Central is the device that scans for a Peripheral’s advertisement. This is typically a mobile phone or a computer. The Central role generally consumes more power than the Peripheral. The Central is also the Link Layer role of the device that controls the timing of the connection event by being the first to transmit (this was formerly the Master role in the Link Layer).11
Connection	Connections are initiated by a Central through a connection request sent in response to a Peripheral’s advertisement. While connected, the Central and Peripheral have a dedicated communication schedule, which they use to hop radio frequencies together, perform security if desired, and quickly exchange data. A connection ends when either device requests a connection termination or when either side doesn’t receive a packet from the other for a configurable duration known as the Supervision Timeout.
Connection Event	BLE connections work by having the Central transmit a packet to the Peripheral at a regular interval. The Peripheral responds to this packet. If either device had application data or BLE control data to send, they send the data in these packets. If there’s no data to send, they send an “empty packet” containing no payload. This exchange at each interval is called a Connection Event. The Connection Event is used for exchanging data and also for maintaining the connection, with each Connection Event being a sync point, both for time synchronization and for simply knowing the other device is still present. Multiple back-to-back packet exchanges may occur in a single Connection Event if either side still has data to send. The interval of Connection Events is the Connection Interval.
Connection Interval	The interval at which Connection Events occur. The Connection Interval is one of the Connection Parameters.
Connection Parameters	A set of parameters that define a connection’s Link Layer behavior. These parameters define the frequency of interaction between the Central and Peripheral. The primary parameters consist of the Connection Interval, the Peripheral Latency, and the Supervision Timeout. These parameters are primarily used to balance low power consumption against high data throughput and low latency. A range of preferred Connection Parameters are typically configured by a developer in Peripheral firmware due to mobile OSes hiding access to these parameters despite being the ones who have final say over the Connection Parameter. iOS has narrower restrictions on acceptable connection parameters than the limits set by the Bluetooth specification.
Filter Accept List (formerly White List)	The Peripheral may create a Filter Accept List of devices that it will accept connections from. Without a Filter Accept List, the Peripheral will accept a connection request from any Central. With a Filter Accept List in place, the Peripheral will only accept a connection request from a device in the Filter Accept List.
GAP	Generic Access Profile. This profile defines the generic procedures related to discovery of Bluetooth devices and link management aspects of connecting to Bluetooth devices. In other words, the profile defines high level device modes and procedures that determine how Bluetooth devices10 find each other and communicate.
Latency	Latency is a general term, but in the contents of this blogpost, latency affects two scenarios: 1. While advertising, Latency is the duration from when a connection is desired to actually connecting. This would mean the duration from when the Peripheral is advertising and the Central is scanning until the connection is made. Generally, a larger advertising interval results in increased Latency. This Latency is not deterministic, i.e. it’s based on probabilities with RF characteristics and timings. This latency could range from 10s of milliseconds to 10s of seconds. 2. While connected, Latency can refer to the duration between a device application telling the BLE stack to send data until reception of the data from the receiving device’s application. A longer connection interval and/or higher Peripheral Latency will increase this latency. Wireless characteristics may also increase latency if packet transmissions need to be retried.
LE Privacy	Advertisement packets contain an address that is unique to the Peripheral. This means someone with the know-how could track your advertising Peripheral (and perhaps you!) through your neighborhood or even across the country. To mitigate this, BLE contains a feature called LE Privacy in which this address is updated at a configurable interval (often 15 minutes). Only other devices that have a key (exchanged during bonding) that can resolve the address and know it’s the same device. This feature is generally not enabled by default.
Observer	One of the two GAP roles that a device assumes when not seeking a connection, the Observer listens for a Broadcaster’s advertisements.
Peripheral	One of the two GAP roles that a device assumes when seeking a connection, the Peripheral is the device that advertises and awaits a connection request from a Central. This is typically a small low-power device such as a fitness tracker or sensor. The Peripheral role generally consumes less power than the Central. The Peripheral is also the Link Layer role of the device that responds to the Central (this was formerly the Slave role in the Link Layer). The Peripheral can not initiate its own transmit timing. It’s always subject to responding to a Central.
Peripheral Latency (formerly Slave Latency)	The Peripheral Latency is a Connection Parameter that describes whether a Peripheral will skip/ignore Connection Events. With a Peripheral Latency of 0 (this is usually the default), the Peripheral listens for and responds to every Connection Event (Remember than Connection Events always start with the Central sending the first packet of the Connection Event). If the Peripheral Latency is N, the Peripheral intentionally ignores N consecutive Connection Events. Then it listens for and responds to the next Connection Event. Then it ignores N Connection Events again and the cycle repeats. The purpose of Peripheral Latency is to reduce power consumption of the Peripheral. Using a non-zero Peripheral Latency may be advantageous over a high connection interval because the Peripheral doesn’t need to wait N Connection Events. If data is ready to be transmitted, the Peripheral can forgo skipping Connection Events and send data in the next Connection Event. A short connection interval combined with a high Peripheral Latency has all of the benefits of a high connection interval when there’s not data to exchange, while still allowing for a low latency in Peripheral -> Central communication.
Scan Request & Scan Response	While scanning for a Peripheral, the Central may send a Scan Request in response to an advertisements packet. The Peripheral may respond with a Scan Response. The Scan Response contains additional Advertising Data. Simply put, the Scan Response is another advertising packet, allowing for doubling the amount of Advertising Data.
Scanning	The process of the Central listening for advertising packets from a Peripheral. The Scanning process is how a Central detects a Peripheral and initiates a connection. A scanning Central will not receive every advertisement packet because the Central can only receive on one of three advertising channels/frequencies at a time and the Central may need to perform other activities in the 2.4GHz frequency (other Bluetooth activity with other devices or Wifi).
Supervision Timeout	The Supervision Timeout is a Connection Parameter that defines the duration for determining that a connection is lost. After either side does not receive a packet from the other for the Supervision Timeout, the connection is lost and the devices would need to resume advertising/scanning in order to reconnect.

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