Date / Year-Month-Day Approved Revision Document No

BLUETOOTH® DOC
2011-07-12 Adopted V10r00 HRS_SPEC
Prepared By E-mail Address N.B.

MED WG med-feedback@bluetooth.org

HEART RATE SERVICE

Abstract:

This service exposes heart rate and other data from a Heart Rate
Sensor intended for fitness applications.
BLUETOOTH SERVICE SPECIFICATION Page 2 of 15
Heart Rate Service

Revision History
Revision Date Comments
(yyyy-mm-dd)
D09r00 2011-02-04 Initial Draft from Health Thermometer Service.
D09r01 2011-02-06 Incorporated feedback from Wicentric. Version used at IOP
D09r02 2011-02-13 Incorporated feedback from IOP. Accepted all changes.
D09r03 2011-03-14 Updated to align with latest Thermometer Service changes.
D09r04 2011-03-23 Incorporated feedback from MED WG reviews.
D09r05 2011-04-01 Incorporated feedback from BARB and MED WG reviews.
Incorporated feedback from Bob, Guillaume and Vishwanath.
D09r06 2011-04-08 Accepted all changes. Prepared for BARB review. Incorporated
feedback from BARB review. Prepared for IOP.
D09r07 2011-05-11 Accepted all changes. Prepared for resubmission to BARB. Minor
editorial updates to align with recent changes to HTS.
D09r08 2011-05-11 Accepted all changes. Submitted to BARB for review.
D09r09 2011-05-18 Incorporated feedback from BARB. Version approved by BARB
and Board.
D10r00 2011-06-22 Updated to draft 1.0. Changed names of Control Point and Sensor
Location characteristics to be more specific to Heart Rate. Minor
changes to align with adopted version of HTS. Applied changes
recommended by tech pubs.
D10r01 2011-06-28 Version submitted to BARB for approval. Incorporated feedback
from GPA WG.
D10r02 2011-06-28 Accepted all changes.
V10r00 2011-07-12 Adopted by the Bluetooth SIG Board of Directors

Contributors
Name Company
Amit Gupta CSR
Robert Hughes Intel Corporation
Krishna Shingala MindTree
Leif-Alexandre Aschehoug Nordic Semiconductor
Guillaume Schatz Polar
Jason Hillyard Wicentric
Niclas Granqvist Polar
Jari Miettinen Polar
Marko Tilvis Polar
Matti Sipola Polar
BLUETOOTH SERVICE SPECIFICATION Page 3 of 15
Heart Rate Service

Disclaimer and Copyright Notice

The copyright in this specification is owned by the Promoter Members of Bluetooth® Special Interest Group
(SIG), Inc. (“Bluetooth SIG”). Use of these specifications and any related intellectual property (collectively, the
“Specification”), is governed by the Promoters Membership Agreement among the Promoter Members and
Bluetooth SIG (the “Promoters Agreement”), certain membership agreements between Bluetooth SIG and its
Adopter and Associate Members (the “Membership Agreements”) and the Bluetooth Specification Early
Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated
Bluetooth SIG and the Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of
the Promoter Members under the Early Adopters Agreements have been assigned to Bluetooth SIG by the
Promoter Members.
Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters
Agreement (each such person or party, a “Member”) is prohibited. The legal rights and obligations of each
Member are governed by their applicable Membership Agreement, Early Adopters Agreement or Promoters
Agreement. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are
granted herein.
Any use of the Specification not in compliance with the terms of the applicable Membership Agreement, Early
Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in
termination of the applicable Membership Agreement or Early Adopters Agreement and other liability permitted
by the applicable agreement or by applicable law to Bluetooth SIG or any of its members for patent, copyright
and/or trademark infringement.
THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY
WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR
PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY
ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL,
SPECIFICATION OR SAMPLE.
Each Member hereby acknowledges that products equipped with the Bluetooth technology ("Bluetooth
products") may be subject to various regulatory controls under the laws and regulations of various governments
worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation,
use, implementation and distribution of Bluetooth products. Examples of such laws and regulatory controls
include, but are not limited to, airline regulatory controls, telecommunications regulations, technology transfer
controls and health and safety regulations. Each Member is solely responsible for the compliance by their
Bluetooth Products with any such laws and regulations and for obtaining any and all required authorizations,
permits, or licenses for their Bluetooth products related to such regulations within the applicable jurisdictions.
Each Member acknowledges that nothing in the Specification provides any information or assistance in
connection with securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION
CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR
REGULATIONS.
ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY
RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS
EXPRESSLY DISCLAIMED. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES
ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER MEMBERS RELATED TO USE OF THE
SPECIFICATION.
Bluetooth SIG reserve the right to adopt any changes or alterations to the Specification as it deems necessary
or appropriate.
Copyright © 2011. Bluetooth® SIG, Inc. All copyrights in the Bluetooth Specifications themselves are
owned by Ericsson AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft Corporation,
Motorola Mobility, Inc., Nokia Corporation and Toshiba Corporation.
*Other third-party brands and names are the property of their respective owners.
BLUETOOTH SERVICE SPECIFICATION Page 4 of 15
Heart Rate Service

Document Terminology
The Bluetooth SIG has adopted Section 13.1 of the IEEE Standards Style Manual, which
dictates use of the words ``shall’’, ``should’’, ``may’’, and ``can’’ in the development of
documentation, as follows:
The word shall is used to indicate mandatory requirements strictly to be followed in order to
conform to the standard and from which no deviation is permitted (shall equals is required to).
The use of the word must is deprecated and shall not be used when stating mandatory
requirements; must is used only to describe unavoidable situations.
The use of the word will is deprecated and shall not be used when stating mandatory
requirements; will is only used in statements of fact.
The word should is used to indicate that among several possibilities one is recommended as
particularly suitable, without mentioning or excluding others; or that a certain course of action is
preferred but not necessarily required; or that (in the negative form) a certain course of action is
deprecated but not prohibited (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard
(may equals is permitted).
The word can is used for statements of possibility and capability, whether material, physical, or
causal (can equals is able to).
BLUETOOTH SERVICE SPECIFICATION Page 5 of 15
Heart Rate Service

Table of Contents
1 Introduction .................................................................................................................................... 6
1.1 Conformance ............................................................................................................................. 6
1.2 Service Dependency ................................................................................................................. 6
1.3 Bluetooth Specification Release Compatibility .......................................................................... 6
1.4 GATT Sub-Procedure Requirements ........................................................................................ 6
1.5 Transport Dependencies ........................................................................................................... 6
1.6 Error Codes ............................................................................................................................... 7
1.7 Byte Transmission Order ........................................................................................................... 7
2 Service Declaration ........................................................................................................................ 8
3 Service Characteristics ................................................................................................................. 9
3.1 Heart Rate Measurement .......................................................................................................... 9
3.1.1 Characteristic Behavior ..................................................................................................... 10
3.1.1.1 Flags Field .................................................................................................................. 10
3.1.1.2 Heart Rate Measurement Value Field ........................................................................ 11
3.1.1.3 Energy Expended Field .............................................................................................. 11
3.1.1.4 RR-Interval Field ......................................................................................................... 11
3.1.1.5 Transmission Interval ................................................................................................. 12
3.1.2 Characteristic Descriptors ................................................................................................. 12
3.1.2.1 Client Characteristic Configuration Descriptor ........................................................... 12
3.2 Body Sensor Location ............................................................................................................. 12
3.2.1 Characteristic Behavior ..................................................................................................... 12
3.3 Heart Rate Control Point ......................................................................................................... 12
3.3.1 Characteristic Behavior ..................................................................................................... 12
3.4 Requirements for Time-Sensitive Data ................................................................................... 13
4 Acronyms and Abbreviations ..................................................................................................... 14
5 References .................................................................................................................................... 15
BLUETOOTH SERVICE SPECIFICATION Page 6 of 15
Heart Rate Service

1 Introduction
The Heart Rate Service exposes heart rate and other data related to a heart rate sensor
intended for fitness applications.

1.1 Conformance
If a device claims conformance to this service, all capabilities indicated as mandatory for
this service shall be supported in the specified manner (process-mandatory). This also
applies for all optional and conditional capabilities for which support is indicated. All
mandatory capabilities, and optional and conditional capabilities for which support is
indicated, are subject to verification as part of the Bluetooth qualification program.

1.2 Service Dependency

This service is not dependent upon any other services.

1.3 Bluetooth Specification Release Compatibility

This specification is compatible with any Bluetooth core specification [1] that includes
the Generic Attribute Profile (GATT) specification and the Bluetooth Low Energy
Controller specification.

1.4 GATT Sub-Procedure Requirements

Requirements in this section represent a minimum set of requirements for a Heart Rate
Sensor (Server). Other GATT sub-procedures may be used if supported by both Client
and Server.
Table 1.1 summarizes additional GATT sub-procedure requirements beyond those
required by all GATT Servers.
GATT Sub-Procedure Requirements
Write Characteristic Value C.1
Notifications M
Read Characteristic Descriptors M
Write Characteristic Descriptors M
Table 1.1: GATT Sub-procedure Requirements
C.1: Mandatory if the Heart Rate Control Point characteristic is supported, otherwise excluded for this
service.

1.5 Transport Dependencies

This service shall operate over an LE transport.
BLUETOOTH SERVICE SPECIFICATION Page 7 of 15
Heart Rate Service

1.6 Error Codes

This service defines the following Attribute Protocol Application error codes:
Name Error Code Description
Control Point Not
0x80 Control Point value not supported.
Supported

1.7 Byte Transmission Order

All characteristics used with this service shall be transmitted with the least significant
octet first (i.e., little endian). The least significant octet is identified in the characteristic
definitions in [2].
BLUETOOTH SERVICE SPECIFICATION Page 8 of 15
Heart Rate Service

2 Service Declaration
The Heart Rate Service shall be instantiated as a «Primary Service».
The service UUID shall be set to «Heart Rate Service». The UUID value assigned to
«Heart Rate Service» is defined in [2].
BLUETOOTH SERVICE SPECIFICATION Page 9 of 15
Heart Rate Service

3 Service Characteristics
The following characteristics are exposed in the Heart Rate Service. Unless otherwise
specified, only one instance of each characteristic is permitted within this service.
Characteristic Requirement Mandatory Optional Security
Name Properties Properties Permissions
Heart Rate M Notify None.
Measurement
Heart Rate M Read, Write None.
Measurement Client
Characteristic
Configuration descriptor
Body Sensor Location O Read None.
Heart Rate Control C.1 Write None.
Point
Table 3.1: Heart Rate Service characteristics
C.1: Mandatory if the Energy Expended feature is supported, otherwise excluded.
Notes:
 Security Permissions of “None” means that this service does not impose any requirements.
 Properties not listed as Mandatory or Optional are Excluded.

3.1 Heart Rate Measurement

The Heart Rate Measurement characteristic is used to send a heart rate measurement.
Included in the characteristic are a Flags field (for showing the presence of optional
fields and features supported), a heart rate measurement value field and, depending
upon the contents of the Flags field, an Energy Expended field and an RR-Interval field.
The RR-Interval represents the time between two consecutive R waves in an
Electrocardiogram (ECG) waveform (see Figure 3.1).

Figure 3.1: ECG Waveform and RR-Interval

The RR-Interval field is variable length and, for a 23-octet ATT_MTU, may contain 0 or
up to 8 or 9 RR-Interval sub-fields depending upon the Heart Rate Measurement Value
format and if the Energy Expended field is present or not.
BLUETOOTH SERVICE SPECIFICATION Page 10 of 15
Heart Rate Service

3.1.1 Characteristic Behavior

When the Client Characteristic Configuration descriptor is configured for notification and
a heart rate measurement is available, this characteristic shall be notified while in a
connection.
The Heart Rate Measurement characteristic contains time-sensitive data, thus the
requirements for time-sensitive data and data storage defined in Section 3.4 apply.
3.1.1.1 Flags Field
The Flags field shall be included in the Heart Rate Measurement characteristic.
Reserved for Future Use (RFU) bits in the Flags fields shall be set to 0.
The bits of the Flags field are defined in the following subsections.
3.1.1.1.1 Heart Rate Value Format bit
The Heart Rate Value Format bit (bit 0 of the Flags field) indicates if the data format of
the Heart Rate Measurement Value field is in a format of UINT8 or UINT16.
When the Heart Rate Value format is sent in a UINT8 format, the Heart Rate Value
Format bit shall be set to 0. When the Heart Rate Value format is sent in a UINT16
format, the Heart Rate Value Format bit shall be set to 1.
The value of the Heart Rate Value Format bit may change during a connection.
3.1.1.1.2 Sensor Contact Status bits
The Sensor Contact Status bits (bits 1 and 2 of the Flags field) indicate whether or not,
the Sensor Contact feature is supported and if supported whether or not skin contact is
detected.
If the Sensor Contact feature is supported by the Server, the Sensor Contact Support bit
(bit 2 of the Flags field) shall be set to 1. If the Sensor Contact feature is not supported
by the Server, the Sensor Contact Support bit shall be set to 0.
The value of the Sensor Contact Support bit is static while in a connection.
The value of the Sensor Contact Status bit may change while in a connection.
If the Sensor Contact feature is supported and if the device detects no or poor contact
with the skin, the Sensor Contact Status bit (bit 1 of the Flags field) shall be set to 0.
Otherwise it shall be set to 1.
3.1.1.1.3 Energy Expended Status bit
The Energy Expended Status bit (bit 3 of the Flags field) indicates whether or not, the
Energy Expended field is present in the Heart Rate Measurement characteristic.
If the Energy Expended field is not present, the Energy Expended Status bit shall be set
to 0. If the Energy Expended field is present, the Energy Expended Status bit shall be
set to 1.
The value of the Energy Expended Status bit may change while in a connection.
BLUETOOTH SERVICE SPECIFICATION Page 11 of 15
Heart Rate Service

3.1.1.1.4 RR-Interval bit

The RR-Interval bit indicates whether or not RR-Interval values are present in the Heart
Rate Measurement characteristic.
If RR-Interval values are not present, the RR-Interval bit shall be set to 0. If one or more
RR-Interval values are present, the RR-Interval bit shall be set to 1.
The value of the RR-Interval bit may change while in a connection.
3.1.1.2 Heart Rate Measurement Value Field
The Heart Rate Measurement Value field shall be included in the Heart Rate
Measurement characteristic.
While most human applications require support for only 255 bpm or less, special
applications (e.g. animals) may require support for higher bpm values.
If the Heart Rate Measurement Value is less than or equal to 255 bpm a UINT8 format
should be used for power savings.
If the Heart Rate Measurement Value exceeds 255 bpm a UINT16 format shall be used.
See 3.1.1.1.1 for additional requirements on the Heart Rate Value format change.
3.1.1.3 Energy Expended Field
The Energy Expended field represents the accumulated energy expended in kilo Joules
since the last time it was reset.
If the Server supports energy expended calculations, the Energy Expended field may be
included in the Heart Rate Measurement characteristic.
If energy expended is used, it is typically only included in the eart Rate Measurement
characteristic once every 10 measurements at a regular interval.
See 3.1.1.1.3 for information regarding the Energy Expended Status bit.
Since Energy Expended is a UINT16, the highest value that can be represented is
65535 kilo Joules. If the maximum value of 65535 kilo Joules is attained (0xFFFF), the
field value should remain at 0xFFFF so that the client can be made aware that a reset of
the Energy Expended Field is required. See Section 3.3.1 for requirements related to
resetting the value of this field.
3.1.1.4 RR-Interval Field
The RR-Interval field may be included in the Heart Rate Measurement characteristic if
the device supports RR-Interval measurements.
If RR-Interval values are present in the Heart Rate Measurement characteristic, the
Server shall set bit 4 of the Flags field (RR-Interval bit) to 1 and shall include one or
more RR-Interval values in the Heart Rate Measurement characteristic. Otherwise RR-
Interval values shall not be included and bit 4 of the Flags field shall be set to 0.
For a 23-octet ATT_MTU and the Heart Rate Measurement Value format set to UINT8,
the maximum number of RR-Interval Values that can be notified if Energy Expended is
BLUETOOTH SERVICE SPECIFICATION Page 12 of 15
Heart Rate Service

present is 8 and the maximum number of RR-Interval Values that can be notified if
Energy Expended is not present is 9.
For a 23-octet ATT_MTU and the Heart Rate Measurement Value format set to UINT16,
when notifying the Heart Rate Measurement characteristic, the maximum number of
RR-Interval values that can be contained within a single Heart Rate Measurement
characteristic with Energy Expended is 7 and the maximum number of RR-Interval
values that can be notified if Energy Expended is not present is 8.
If more RR-Interval values are measured since the last notification than fit into one
Heart Rate Measurement characteristic, then the remaining RR-Interval values should
be included in the next available Heart Rate Measurement characteristic.
If there is no available space in the internal buffer of the Heart Rate Sensor, it may
discard the oldest RR-Interval values.
3.1.1.5 Transmission Interval
In typical applications, the Heart Rate Measurement characteristic is notified
approximately 1 time per second and includes the Heart Rate Measurement Value field
and, if supported, the RR-Interval field. The Energy Expended field, if supported, is
typically included in the Heart Rate Measurement characteristic for transmission
approximately 1 time per every 10 seconds. These intervals may vary and are
determined by the Server and are not configurable by the Client.

3.1.2 Characteristic Descriptors

3.1.2.1 Client Characteristic Configuration Descriptor
The Client Characteristic Configuration descriptor shall be included in the Heart Rate
Measurement characteristic.

3.2 Body Sensor Location

The Body Sensor Location characteristic of the device is used to describe the intended
location of the heart rate measurement for the device.
The value of the Body Sensor Location characteristic is static while in a connection.

3.2.1 Characteristic Behavior

The Body Sensor Location characteristic returns the sensor location value when read.

3.3 Heart Rate Control Point

The Heart Rate Control Point characteristic is used to enable a Client to write control
points to a Server to control behavior.
Support for this characteristic is mandatory if the Server supports the Energy Expended
feature.

3.3.1 Characteristic Behavior

The Heart Rate Control Point characteristic sets a control point value when written.
BLUETOOTH SERVICE SPECIFICATION Page 13 of 15
Heart Rate Service

If the Client attempts to write a value to the Heart Rate Control Point characteristic that
is not supported by the Server, the Server shall send an error response with the error
code set to Control Point Not Supported.
If supported by the Server, when a value of 0x01 is written to the Heart Rate Control
Point characteristic (Reset Energy Expended), the Server shall restart the accumulation
of energy expended from zero.

3.4 Requirements for Time-Sensitive Data

The Heart Rate Measurement characteristic contains time sensitive data and is
considered a time-sensitive characteristic, thus the following requirements apply:
Since this service does not provide for a time stamp to identify the measurement time
(and age) of the data, the value of the Heart Rate Measurement characteristic shall be
discarded if either the connection does not get established or if the notification is not
successfully sent to the Client (e.g., link loss).
BLUETOOTH SERVICE SPECIFICATION Page 14 of 15
Heart Rate Service

4 Acronyms and Abbreviations

Acronyms and Abbreviations Meaning
BR/EDR Basic Rate / Enhanced Data Rate
ECG Electrocardiogram
GAP Generic Access Profile
GATT Generic Attribute Profile
LE Low Energy
RFU Reserved for Future Use
UUID Universally Unique Identifier
Table 4.1: Acronyms and Abbreviations
BLUETOOTH SERVICE SPECIFICATION Page 15 of 15
Heart Rate Service

5 References
[1] Bluetooth Core Specification v4.0
[2] Characteristic and Descriptor descriptions are accessible via the Bluetooth SIG Assigned Numbers.