How One Wearable Can
Connect with Multiple
Smartphones or Tablets
Simultaneously

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.

Regulatory

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

Countermeasures

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!