Pairing, bonding and connecting

Traditional pairing to the host system

Discoverability

Accessories that are intended to be bonded with a Windows system should support the Limited Discoverable mode. Accessories should limit their use of the General Discoverable mode.

Note

Accessory makers are reminded of the core specification, version 6.0, Volume 3, Part C, section 3.2.2.1.1, that requires that the user-friendly device name must be consistent. A dual mode accessory must not return one name for LE and another name for BR/EDR.

"Add Device" discoverability filtering

The complete Bluetooth device add experience in Windows is the "Add a device" dialog from the Bluetooth & devices page in the settings app. The Add a device dialog may filter the results based on the reported appearance and class of device and the version of Windows.

Device makers should include both appearance and class of device if appropriate.

Windows 10

In Windows 10, all discovered devices are shown in the Add a device dialog in Settings.

Windows 11

Starting in Windows 11, version 24H2, there are two lists of devices that Windows can show.

The first list shown to the user is filtered based on the class of device or the appearance and is restricted to devices commonly paired with Windows. Devices commonly paired with Windows include mice, keyboards, game and HID controllers, and audio devices like speakers, headsets, and earbuds. Filtering is based on the class of device or appearance values provided by the device.

The full list shows all discovered devices, allowing a user to pair a device that isn't commonly paired with Windows. This is available after selecting Show all devices. It can be seen that discovered devices that are not typically paired with a Windows device are now shown.

Note

In Windows 11, version 22H2 and 23H2, the Show all devices functionality is not available. Instead, Windows defaults to filtered mode and a setting available in Settings->Bluetooth & devices->Devices allows the filter mode to be changed to show all devices.

Dual Mode class of device representation in Settings

Dual mode accessories shall provide both the Classic Class of Device field along with the LE appearance field in the respective protocols. Windows will prefer the LE Appearance over BR/EDR CoD for dual mode audio and input accessories.

Support bonding

Accessories that do not support bonding should not support discovery. This prevents a user from attempting to “Add a device” with an accessory that doesn't support bonding.

Audio accessories shall support bonding.

Secure connections and key sizes

Accessories should support Secure Connections as defined in the table below for BR/EDR or LE accessories:

BR/EDR	LE
The accessory shall not negotiate an encryption key below 8 octets. Devices should allow at least 16 octet keys.	The accessory shall use the largest spec- and jurisdiction-allowed encryption key size permitted.

Accessories with companion apps

Some accessories are designed to be used with a companion app, and the companion app may also have a preferred user experience for discovering and bonding with the accessory. Depending on the intended use of these accessories, it may be desirable to not support Discoverable Mode, in order to suppress ability to discover and bond via the Windows Bluetooth UX.

For accessories that work with companion apps:

• Accessories of classes that provide native functionality with Windows (e.g., audio, HID, etc.) shall be discoverable and bondable through the Windows Bluetooth UX, whether or not the companion app also offers a discovery and bonding UX.
• Accessories of classes that do not provide native functionality with Windows (e.g., fitness trackers, health devices, etc.) may be discoverable and bondable via the Windows Bluetooth UX, in addition to the preferred UX in the companion app.
• The companion app shall function even when the user has bonded with the accessory through the regular Windows Bluetooth UX.

Facilitated pairing to the host system

Swift Pair

Swift Pair allows users to pair nearby accessories in 1 tap at the desktop instead of needing to go through the Settings app. Accessories that support bonding for Windows should support Swift Pair if appropriate. Audio accessories that support LE baseband shall support Swift Pair. For more information, see the Swift Pair documentation. Accessories that support Swift Pair and that are dual mode shall follow guidance in Pairing and bonding guidance for dual mode accessories.

This guidance extends the Swift Pair specifications by making the display mandatory:

• Accessories should include a Class of Device (CoD) in the Swift Pair payload.
• Accessories that don't provide a Class of Device in the Swift Pair payload shall include a display name for the accessory through the display name field in the Swift Pair payload.

If neither CoD nor display name are provided, Swift Pair will not trigger.

Accessories that pair over LE only will use the LE appearance value for that pairing session.

Swift Pair UX requirements

Accessories that intend to use the Swift Pair UX in Windows must include a class of device (CoD) or name. Without at least one of these, the Swift Pair UX will not be displayed.

Providing a correct Class of Device (CoD)

Accessory makers should note that the icons used in Windows to represent the accessory can be taken from the Class of Device (CoD) in Swift Pair's payload or the LE appearance section in the same advertisement as Swift Pair.

For Windows to correctly represent the accessory, the accessories shall provide an appropriate Class of Device.

BR/EDR accessories shall provide an appropriate CoD value in the Swift Pair payload. LE accessories shall provide an appropriate LE Appearance value in the Swift Pair advertisement.

For Dual mode accessories that provide both an LE Appearance value and a CoD, Windows will prefer the LE Appearance value. This is particularly useful for when there is an LE Appearance value available that more accurately describes the device than what is available with CoD.

Factory bonding (Factory pre-pairing)

This experience allows Windows to provide an accessory connection experience that “just works” as if it were wired. This is for accessories that are bundled in the same box as a Windows system, such as input accessories for All-In-Ones. The specifications are available at Bluetooth LE pre-pairing.

For an accessory to support Factory bonding, it shall support the Bluetooth LE baseband and shall advertise the payload with the correct manufacturer section data, and device identifiers.

Accessories may support Bluetooth LE Factory bonding.

Pairing and bonding guidance for Dual Mode accessories

Dual mode devices can present confusion to users when a single accessory is presented twice for pairing, once for BR/EDR and once for LE. The following guidelines ensure that the user sees each accessory only once, using the most appropriate pairing mechanism.

Dual mode accessories that require bonding over both basebands should support Secure Connections and Cross-Transport Key Derivation (CTKD). Accessories that require bonding over one baseband but do not require a bond over the other do not need to support CTKD. For example, some Audio accessories will primarily use BR/EDR and must be paired and bonded on BR/EDR but have all their LE features accessible without bonding.

Developers should note that not all PCs are equipped with a Bluetooth radio that is capable of supporting BR/EDR Secure Connections. Similarly, not all PCs that are equipped with a Bluetooth radio are capable of Bluetooth LE.

Accessories that implement CTKD in only one direction should implement it from LE to the BR/EDR. This direction is fully supported by Windows. These accessories must also be discoverable on LE.

BR/EDR audio-only (not LE Audio) dual mode accessories shall only be discoverable on one baseband (transport) at a time. Except when otherwise required (for example, Swift Pair and Factory bonded accessories), accessories that are primarily to be used on one baseband (e.g., an audio accessory that is primarily to be used on BR/EDR) should be discoverable only on that baseband.

Once an accessory is bonded to a Windows system, it will retain the distributed keys for future use. When the bonding is no longer required, the accessory shall delete all associated keys.

Low Energy (LE) connection parameters and Bluetooth bandwidth

Users prefer accessories that make reasonable connection parameter tradeoffs between the competing needs of the limited Bluetooth bandwidth, the desire for low latency, Windows performance, and battery life. Windows may need to specify or adjust connection parameters in some cases.

Accessory makers should pay particular attention to Bluetooth bandwidth. As more Bluetooth accessories are used in an area, the radios will see increased contention and users will see a degraded user experience. See the testing requirements for details on how to test this.

All LE and dual mode accessories should operate at a connection interval that is a multiple of 7.5 ms, preferably using powers of two (e.g., 7.5ms, 15ms, 30ms, 60ms, etc.). This minimizes scheduling conflicts between piconets. Only low latency accessories like high-precision mice may use connection intervals as low as 7.5 ms. Input accessories such as keyboards should use connection intervals of 15 ms or higher. Other accessories should use 30 ms or more.

All LE and dual mode accessories that provide a Min and Max connection interval are reminded that the Min value should be selected, when possible, to allow for easy co-existence with other devices that might much lower connection intervals. For example, consider the case where Windows has a device with a 15 ms connection interval (e.g., a keyboard). A device that has a Min, Max of 20 ms, 25 ms will not be able to use the most convenient connection interval (15 ms). The Min, Max connection interval should always include at least one of 7.5 ms, 15 ms, 30 ms or for larger values, is a multiple of 30 ms.

All LE and dual mode accessories should support LE connection parameter requests over LL or L2CAP. If present, the GAP Peripheral Preferred Connection Parameters characteristic should reflect the steady-state preferences for the accessory. Unless otherwise required by a higher-level profile, LE and dual mode accessories shall send connection parameter requests over LL.

LE and dual mode accessories should be able to handle a variety of connection parameters specified by the Windows system, in addition to their ideal connection parameters.

Accessory initiated connection

Accessories that initiate connection with the host upon power-on should initiate connection of all applicable profiles needed for intended operation of the device.

Audio accessories that support a combination of HFP, A2DP and/or AVRCP shall connect all supported profiles upon accessory initiated connection, as recommended in Section 5.2, “Profile (Dis-)Connection Behavior”, of the Multi-Profile Specification v1.0.

Link loss recovery

Users may accidentally move out of range of their Windows system. When this happens, the best user experience is that accessories recover from short-term unintended disconnections.

When an audio accessory determines the link has disconnected because of a link supervision timeout it shall periodically attempt to reestablish the link for at least two minutes after the link supervision timeout. If a link is re-established, the audio accessory should proceed with other profile initialization procedures normally executed after the accessory initiates link establishment.

Basic Rate (BR) / Enhanced Data Rate (EDR) piconets and scatternets

Users often have multiple Bluetooth accessories which are used simultaneously. An important scenario to consider is a user who is actively using their Bluetooth audio accessory and their Bluetooth keyboard and mouse with a Windows system.

The Windows system will usually be the Central and the accessories will each be a Peripheral in a single piconet. It is permitted for either the Windows system or any accessory to request a role switch.

When the user’s phone also connects to the audio accessory, some audio accessories attempt to switch to the Central role in an attempt to be connected as the Central to both the phone and the Windows system. This can leave the Windows system in a scatternet, leading to possibly severe Bluetooth keyboard and mouse performance issues and severe consumer dissatisfaction.

A common point of confusion is when Windows will or will not permit a role change. Accessories need to robustly handle being either the central or peripheral device. Any Windows behavior for role changes is very likely to change for different releases.

For an accessory implementor, some of these guidelines need to be implemented by the Bluetooth chipset. Implementors will need to verify that the chipsets they choose meet their needs.

BR/EDR accessories should allow Windows to be the Central of any piconet that they are a member of. This optimizes the ability for Windows and the controller on the Windows system to effectively schedule parallel latency-sensitive scenarios (e.g., communications with keyboard and mouse input, alongside Wi-Fi).

An audio accessory should not request to be the central role when it only needs to maintain a single link. It should only request to be central when it needs to maintain links with multiple host devices.

Windows may reject a BR/EDR accessory's request to role switch. In this case, the BR/EDR accessory shall maintain the link and continue normal operation.

A BR/EDR accessory in a scatternet should prioritize links that are actively being used for a scenario (e.g., music streaming, voice call). Examples of prioritization would be to put other links into Sniff Mode, give other links a longer sniff interval, or give the link with the active scenario higher priority when resolving scheduling conflicts.

Sniff mode

Users prefer accessories with good battery life. Sniff mode is an important mechanism for accessories to reduce their power consumption. However, Sniff mode is not always appropriate, and it is important that accessories continue to function properly in other modes.

Requirements for accessories that implement sniff mode are listed in the following list:

• Accessories should support sniff mode in addition to active mode.
• Audio accessories shall support sniff mode and should request it as appropriate.

After the Windows system has rejected a mode change from the accessory, the accessory shall accept the rejection and shall resume working normally. The Accessory shall not re-request a mode change right away.

For audio accessories with a connection to a single peer	For audio accessories with connections to multiple peers
The audio accessory shall honor the Windows system's request to change connection mode and shall use the parameter provided by the Windows system.	The audio accessory should honor the Windows system's request to change connection mode and should use the parameter provided by the Windows system.