For Bluetooth® Low Energy (LE) connection-oriented applications, it’s common that one central device initiates and maintains connections with multiple peripherals. As shown in Figure 1, you can see that one central, such as a smartphone, can connect with multiple peripherals, such as a lock, light, thermal device, switch, and so on. The number of connections one central can provide depends on that central’s offering.

Figure 1 – The central initiates and maintains multiple peripheral connections

Recently, I was asked if it’s possible for one peripheral like a smartwatch to maintain connections with multiple centrals, such as smartphones and laptops, and if it’s allowed in the Bluetooth specification.

Figure 2 shows the scenario with one smartwatch working as a peripheral. It maintains multiple connections with three smartphones and three laptops, even if all those connections are initiated by these centrals.

Figure 2 – The peripheral maintains connections with multiple centrals.


Yes, it’s allowed. The screenshot below (Figure 3) is from the Bluetooth Core Specification v5.1, Vol 6, Part B, Section 1.1.1, “Permitted state and role combinations” on page 2684.

Figure 3 – Screenshot from Bluetooth Core Specification v5.1

You can see from the red box in Figure 3, that a peripheral:

  • Keeping a connection can also be in an advertising state
  • Can have more than one connection with multiple centrals

Timing Overlapped      

Figure 4, below, shows there are two centrals: Central 1 and Central 2. Both of them connect with a single peripheral and are in the same time axis.

  • Blue means that Central 1 establishes a connection with the peripheral, the connection interval is assigned from Central 1 to Peripheral
    • M1->S means Central 1 sends packet to Peripheral and
    • S->M1 means Peripheral responds to Central  1
  • Green means that Central 2 establishes a connection with the peripheral, the connection interval is assigned from Central 2 to Peripheral
    • M2->S means Central 2 sends packet to
    • Peripheral and
    • S->M2 means Peripheral sends packet to Central 2

The peripheral just has one transceiver, and this transceiver works as a half duplex. So, at the same time, only certain centrals can communicate with the peripheral. In Figure 4, you can see that Central 1 and Central 2 alternatively communicate with the peripheral.

Figure 4 – Alternating communication between two centrals and one peripheral

Figure 5 is different. In this instance, Central 2 adjusts the connection interval with the peripheral so there are two overlapped slots (red parts).

  • Overlap 1: The peripheral is sending a packet to Central 1 while Central 2 is sending a packet to the peripheral
  • Overlap 2: Central 1 and Central 2 are both sending packets to the peripheral

Figure 5 – Timing overlapped


While timing overlap is possible, there are three countermeasures to handle it. The countermeasures below are not defined in the Bluetooth Core Specification, but they may be useful for you.  

Prioritize Connections: When a developer designs firmware for the peripheral, they should define a connection priority table on it to list the highest to lowest. Some Bluetooth LE SDKs (software development kits) also provide the priority table inline. Developers should check and see if the application requires a single peripheral to connect with multiple centrals simultaneously.

Update Connection Parameters: If connections are prioritized, when there is an overlap, a peripheral can update connection parameters like Connection Interval, Peripheral Latency, and Supervision Timeout. Based on connection priority, the peripheral can adjust these parameters to avoid overlap conflict. For more detail on Connection Parameters Request, refer to Bluetooth® Core Specification v5.1, Vol 6, Part D, Section 6.12, “Connection Parameters Request”.

Drop Connection: The updated connection parameter initiated by the peripheral may not be accepted by the central because the central has the authority to accept or reject. If the central rejects the updated connection parameter, the only thing the peripheral can do is drop the connection. The connection that is dropped depends on the connections’ priority. Lower priority connections can be dropped first, and higher priority connections can be kept.

Whichever you choose, it’s not about correct or incorrect, just whether it’s suitable or not for your application or system design. I hope it’s useful for all of you!


Enhancing Bluetooth Location Services with Direction Finding

A new Bluetooth direction finding feature allows devices to determine the direction of a Bluetooth signal, thereby enabling the development of Bluetooth proximity solutions that can understand device direction as well as Bluetooth positioning systems that can achieve down to centimeter-level location accuracy.


Bluetooth® Mesh Feature Enhancements Summary

This paper summarizes the recent Bluetooth® Mesh feature enhancements and provides references to other…

Bluetooth® Mesh Subnet Bridging - Technical Overview

This paper examines subnet bridging, a new feature introduced in the Bluetooth® Mesh protocol…

Bluetooth® Mesh Remote Provisioning - Technical Overview

This paper provides an overview of remote provisioning, a new Bluetooth® Mesh feature that…

Bluetooth® Mesh Private Beacons - Technical Overview

This paper examines private beacons, a type of beacon that can be used to…

Bluetooth® Mesh Directed Forwarding - Technical Overview

This paper provides an overview of directed forwarding, a new Bluetooth® Mesh feature that…

Bluetooth® Mesh Device Firmware Update - Technical Overview

This paper examines the new device firmware update (DFU) feature of Bluetooth® Mesh that…

Bluetooth® Mesh Certificate-Based Provisioning - Technical Overview

This paper provides an overview of the certificate-based provisioning feature that allows digital certificates…

The Latest in HADM with Bluetooth LE

HADM, or high accuracy distance measurement using Bluetooth does exactly what it says –…

Bluetooth® Certificate-based Provisioning - A Technical Overview

This paper details the capabilities and benefits of certificate-based provisioning. Provisioning is the procedure…

Silicon Labs Bluetooth Low Energy Devices Now Support Bluetooth Core Specification 5.4

The release of Bluetooth® Core Specification Version 5.4 earlier this year was met with…

Mr. Beacon Podcast: Snapdragon Sound with Mike Canevaro

This episode of the Mr. Beacon Podcast explores the revolutionary world of Bluetooth audio.…

The Importance of Commissioning in NLC

With constant technology advancements and growing market awareness, we are all getting more and…

Large Scale Bluetooth Mesh Testing

Reliability and latency are the key parameters to be optimized to achieve a seamless…

Top 10 Auracast™ Resources

It’s been almost a year since the Bluetooth Special Interest Group (SIG) released Auracast™…

Features and Benefits of Bluetooth Mesh 1.1 for Wireless Mesh Networking

Commercial and industrial applications like lighting require large-scale, low-power device networks where thousands of…

Bluetooth ESL – The Global Standard for the Electronic Shelf Label MarketBluetooth ESL – 電子棚札市場のためのグローバル規格

Electronic shelf label (ESL) systems have historically relied on proprietary protocols for wireless communication,…

The Bluetooth® Low Energy Primer

Are you new to Bluetooth Low Energy? Learn about its constituent parts, features, and how it works.

Bluetooth® Technology for Linux Developers

Learn how to use the interprocess communication system D-Bus and the BlueZ APIs to create Bluetooth applications for Linux computers.

Designing and Developing Bluetooth® Internet Gateways

Learn about Bluetooth internet gateways, how to make them secure and scalable, and design and implement your own working prototype gateway and web application for use with either Bluetooth LE Peripherals or with Bluetooth mesh networks.

 Get Help