요청한 페이지는 현재 사용 중인 언어로 제공되지 않습니다. 페이지 하단에서 다른 언어를 선택하거나 Chrome에서 기본 제공되는 번역 기능을 사용해 웹페이지를 원하는 언어로 바로 번역할 수 있습니다.

Fitbit & Pixel Watch Heart Rate Sharing Compatibility Guidelines

1. Introduction

Compatible Fitbit fitness trackers and Pixel Watch devices implement the Heart Rate Sharing feature using the standard Bluetooth LE Heart Rate Service (UUID 0x180D). In this document, these devices are collectively referred to as "the Peripheral."

1.1. Purpose & Audience

The primary goal of this document is to define the requirements for seamless interoperability with the Peripheral, ensuring the best possible user experience.

This document serves as a technical resource for equipment manufacturers and application developers building GAP Central devices (e.g., treadmills, fitness apps, rowing machines, bike computers), hereinafter referred to as “the Central.”

1.2. Security Architecture Overview

The Peripheral implements a security policy that prioritizes encrypted and bonded connections for user privacy and seamless reconnection, but supports graceful degradation to unencrypted transport for broad compatibility.

Crucial: To prevent connection stalls and SMP timeouts, the Central, regardless of their security capabilities, must adhere to the Pairing and Security Procedure mandates defined in section 4. Mandatory Behavior: Pairing & Security Procedures.

2. Summary of Requirements

To ensure a reliable connection and a positive user experience, the Central must fulfill the following core requirements:

  1. Provide Device Name: The Central SHALL implement the Device Name Characteristic (UUID 0x2A00) within the Generic Access Service (part of the Generic Access Profile) as Readable. This allows the user to see the equipment name on their watch/tracker. (See Section 6).
  2. Handle Security Requests: The Central SHALL NOT ignore the SMP Security Request (0x0B) sent by the Peripheral, except in the specific case where the Central has already sent an SMP Pairing Request (0x01) (see Section 4.1). In all other scenarios, ignoring this request causes a 30-second timeout and a poor user experience.
  3. Implement Correct Security Logic: The Central must classify itself into one of three security categories (Bonding with Encryption, Encryption-Only, or No Encryption) and implement the corresponding pairing behaviors defined in Section 4.

3. General Security Architecture

The Peripheral operates in LE Security Mode 1 as defined in the Bluetooth Core Specification (Vol 3, Part C, Section 10.2.1).

The specific pairing method (e.g., Just Works, Passkey Entry, or Numeric Comparison) is negotiated dynamically based on the Input/Output (IO) Capabilities and Authentication Requirements of both devices, as defined in the Bluetooth Core Specification (Vol 3, Part H, Section 2.3.5.1).

3.1. Security Negotiation & Fallback

The Central and Peripheral SHOULD negotiate the highest security level supported by the Input/Output (IO) capabilities of both devices, as defined in the Bluetooth Core Specification (Vol 3, Part H, Section 2.3.5.1).

  • Recommendation: To ensure user data privacy, it is HIGHLY RECOMMENDED that the Central accept the negotiated pairing method (e.g., Just Works) if the Peripheral is unable to support higher authentication levels.
  • Fallback Requirement: If the Central's security policy strictly forbids the negotiated pairing method (e.g., it requires MITM but the negotiation results in “Just Works”), the Central SHALL gracefully fall back to No Security (Level 1).
    • The Central SHALL NOT disconnect solely because encryption could not be established. (Note: The Bluetooth Core Specification defines that an SMP failure terminates the pairing procedure but leaves the ACL link active).
    • In this scenario, the Central must terminate the pairing attempt (e.g., send SMP Pairing Failed (0x05) with reason 0x03 (Authentication Requirements)) and proceed with unencrypted data transfer. (Note: The Peripheral will enable data transmission for the existing subscription upon receiving the failure; re-subscription is not required).

3.2. Supported Security Levels

The Peripheral utilizes the highest security level supported by its hardware capabilities and the negotiation results:

  1. Unauthenticated Pairing (Level 2): Supported via Just Works.
  2. Authenticated Pairing (Level 3 or 4): Supported if the device processes the necessary capabilities to perform Passkey Entry or Numeric Comparison.
  3. No Security (Level 1): Unencrypted fallback.

The Peripheral enforces security upon characteristic access. It will issue an SMP Security Request (0x0B) when the Central subscribes to the Heart Rate Measurement characteristic, unless the connection is already encrypted (due to bonding) or pairing is already in progress (e.g., if the Central proactively initiated pairing immediately upon connection).

4. Mandatory Behavior: Pairing & Security Procedures

To ensure a responsive user experience and immediate data availability, the Central MUST establish the security state promptly. This can be achieved through one of the following mechanisms.

4.1. Initiation Scenarios

  1. Central-Initiated: The Central proactively initiates pairing by sending an SMP Pairing Request (0x01) immediately after connection establishment.
  2. Peripheral-Initiated: The Peripheral sends an SMP Security Request (0x0B). The Central SHALL NOT ignore this request and MUST respond with an SMP Pairing Request (0x01) or an SMP Pairing Failed (0x05).
  3. Simultaneous Initiation (Race Condition): If the Peripheral sends a SMP Security Request (0x0B) and the Central sends a SMP Pairing Request (0x01) simultaneously (messages cross in transit):
    • The Central's SMP Pairing Request (0x01) takes precedence.
    • The Central SHALL ignore the incoming SMP Security Request (0x0B) and proceed with the pairing feature exchange initiated by its own request.
    • The Central SHALL NOT send a second Pairing Request (0x01) in response to the crossed SMP Security Request (0x0B).

4.2. Central Categories & Required Responses

In all scenarios, the Central must classify itself into one of three categories and configure the SMP Pairing Request (0x01) or SMP Pairing Failed (0x05) response accordingly:

Category 1: Central Supports Bonding & Encryption (Preferred)

  • Definition: The Central can encrypt the link and store keys (Bonding) for future reconnections.
  • Required Action: Send SMP Pairing Request (0x01) with Bit 0 of the Bonding_Flags field set to 1 (Bonding).
  • Security Policy Exception: If the Central strictly requires MITM protection and rejects the negotiated pairing method (e.g., "Just Works") (see Section 3.1), it SHALL send SMP Pairing Failed (0x05) with reason 0x03 (Authentication Requirements).
  • Important: Please refer to Section 5 (Bonding Persistence & Privacy Addresses). Centrals that bond must persist keys; otherwise, they must downgrade to Category 2.

Category 2: Central Supports Encryption / Pairing Only (No Bonding)

  • Definition: The Central can encrypt the link but does not support bonding.
  • Required Action: Send SMP Pairing Request (0x01) with bit 0 of the Bonding_Flags field set to 0 (No Bonding).
  • Bonding Negotiation: The Peripheral requests Bonding in its SMP Security Request. If the Central does not support bonding but can satisfy the encryption/authentication requirements (e.g., SC/MITM), it SHALL NOT reject the request. It SHALL proceed with the pairing procedure by setting the Bonding bit to 0 in the SMP Pairing Request (0x01).
  • Security Policy Exception: If the Central cannot fulfill the authentication requirements of the Peripheral’s security request (e.g. due to strict security policy requiring MITM protection that the Peripheral’s IO capabilities cannot support) (see Section 3.1), it SHALL send SMP Pairing Failed (0x05) with reason 0x03 (Authentication Requirements).
  • UI Constraint: Because bonding is not performed, the Central will not receive an Identity Resolving Key (IRK). Therefore, the Central SHALL NOT save the Peripheral to a "My Devices" list. The Peripheral uses a Resolvable Private Address (RPA) which changes periodically; saving the current temporary MAC address will result in connection failures later.

Category 3: Central Does NOT Support Encryption

  • Definition: The Central requires an unencrypted connection (Level 1).
  • Required Action: Explicitly reject the request by sending SMP Pairing Failed (0x05) with reason code 0x05 (Pairing Not Supported).

4.3. Outcome

Upon successfully completing the procedure defined in any of the three categories above (either via establishing encryption or explicitly rejecting it), the Peripheral will authorize access and start sharing data per the standard Heart Rate Profile.

5. Bonding Persistence & Privacy Addresses (RPA)

This section applies specifically to Category 1 Centrals.

The Peripheral utilizes a Resolvable Private Address (RPA) to protect user privacy. This means the Peripheral's Bluetooth MAC address changes periodically (e.g., every 15 minutes).

5.1. Requirement for Key Storage

If a Central sets Bit 0 of the Bonding_Flags field to 1 (Bonding), it SHALL persistently store the keys distributed during the pairing process, specifically:

  1. Long Term Key (LTK): Required for encryption.
  2. Identity Resolving Key (IRK): Required to resolve the Peripheral's changing MAC address.

5.2. Prohibition of "False Bonding"

If the Central cannot guarantee non-volatile storage of the LTK and IRK (e.g., due to memory constraints or implementation bugs), it SHALL NOT request Bonding.

  • Consequence: If a Central bonds but deletes the keys, it will be unable to reconnect to the Peripheral once the Peripheral's address rotates. The Central will see the device as "Disconnected," but will lack the IRK necessary to identify the device's new address.
  • Remediation: Centrals with volatile key storage MUST downgrade to Category 2 (Bonding_Flags bit 0 set to 0 (No Bonding)). Consequently, they SHALL NOT treat the device as a "saved" or "known" device in their UI (see Category 2 UI Constraint).

6. Device Name Requirement

To enhance the user experience, the Fitbit/Pixel Watch displays the name of the connected Central device to the user.

  • Requirement: As mandated by the Bluetooth Core Specification (Vol 3, Part C), the Central SHALL implement the Device Name Characteristic (UUID 0x2A00) within the Generic Access Service (UUID 0x1800).
  • Properties: The characteristic SHALL be Readable.
  • Content: The value SHALL be a non-empty UTF-8 encoded string representing the user-friendly name of the Central (e.g., "Treadmill 500", "Rowing Machine").

7. Connectivity Flows

7.1. Encrypted Flow (Categories 1 & 2)

  1. Peripheral sends SMP Security Request (0x0B).
  2. Central sends SMP Pairing Request (0x01) (Bonding_Flags bit 0 set to 0 (No Bonding) or 1 (Bonding)).
  3. Pairing Method Selection: Devices negotiate the method (Just Works, Passkey, etc.) based on IO Capabilities.
  4. Link is Encrypted.
  5. Data transfer (Heart Rate values) proceeds.

7.2. Unencrypted Flow (Category 3 or Failed Negotiation)

This flow applies to Centrals that do not support encryption OR refuse the negotiated pairing method (e.g., refuse Just Works).

  1. Peripheral sends SMP Security Request (0x0B).
  2. Central immediately sends SMP Pairing Failed (0x05) with reason: 0x05 (Pairing Not Supported) or 0x03 (Authentication Requirements).
  3. Peripheral processes failure and disables security enforcement for the current link.
  4. Data transfer (Heart Rate values) proceeds immediately (Unencrypted).

8. References

true
Search
Clear search
Close search
Google apps
Main menu
9409502110805430480
true
도움말 센터 검색
false
true
true
true
false
false
false
false