Body Composition Service

Abstract

This service exposes data related to body composition from a body composition analyzer intended for consumer healthcare and sports/fitness applications.

Revision: V1.0.0
Revision Date: 2014-10-21
Group Prepared By: SF WG
Feedback Email: sf-main@bluetooth.org

Revision History

Revision	Date (yyyy-mm-dd)	Comments
V1.0.0	2014-10-21	Adopted by the Bluetooth SIG BoD

Contributors

Name	Company
Robert Hughes	Intel Corporation

DISCLAIMER AND COPYRIGHT NOTICE

This disclaimer applies to all draft specifications and final specifications adopted by the Bluetooth SIG Board of Directors (both of which are hereinafter referred to herein as a Bluetooth “Specification”). Your use of this Specification in any way is subject to your compliance with all conditions of such use, and your acceptance of all disclaimers and limitations as to such use, contained in this Specification. Any user of this Specification is advised to seek appropriate legal, engineering or other professional advice regarding the use, interpretation or effect of this Specification on any matters discussed in this Specification.

Use of Bluetooth Specifications and any related intellectual property 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, including, but not limited to, the Membership Application, the Bluetooth Patent/Copyright License Agreement and the Bluetooth Trademark License Agreement (collectively, 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 use of any portion of a Bluetooth Specification may involve the use of intellectual property rights ("IPR"), including pending or issued patents, or copyrights or other rights. Bluetooth SIG has made no search or investigation for such rights and disclaims any undertaking or duty to do so. The legal rights and obligations of each Member are governed by the applicable Membership Agreements, 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 Agreements, Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in (i) termination of the applicable Membership Agreements or Early Adopters Agreement and (ii) liability claims by Bluetooth SIG or any of its Members for patent, copyright and/or trademark infringement claims permitted by the applicable agreement or by applicable law.

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 wireless technology ("Bluetooth Products") may be subject to various regulatory controls under the laws and regulations applicable to products using wireless non licensed spectrum 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. To the extent not prohibited by law, in no event will Bluetooth SIG or its Members or their affiliates be liable for any damages, including without limitation, lost revenue, profits, data or programs, or business interruption, or for special, indirect, consequential, incidental or punitive damages, however caused and regardless of the theory of liability, arising out of or related to any furnishing, practicing, modifying, use or the performance or implementation of the contents of this Specification, even if Bluetooth SIG or its Members or their affiliates have been advised of the possibility of such damages. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS MEMBERS OR THEIR AFFILATES RELATED TO USE OF THE SPECIFICATION.

If this Specification is an intermediate draft, it is for comment only. No products should be designed based on it except solely to verify the prototyping specification at SIG sponsored IOP events and it does not represent any commitment to release or implement any portion of the intermediate draft, which may be withdrawn, modified, or replaced at any time in the adopted Specification.

Bluetooth SIG reserves the right to adopt any changes or alterations to the Specification it deems necessary or appropriate.

Copyright © 2013 - 2014. The Bluetooth word mark and logos are owned by 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, LLC, Nokia Corporation and Toshiba Corporation. Other third-party brands and names are the property of their respective owners.

Document Terminology

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).

The term Reserved for Future Use (RFU) is used to indicate Bluetooth SIG assigned values that are reserved by the Bluetooth SIG and are not otherwise available for use by implementations.

1. Introduction

The Body Composition Service (BCS) exposes data related to body composition from a body composition analyzer (Server) intended for consumer healthcare as well as sports/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 to 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 Bluetooth Core Specification 4.0 or later version of the Core Specification [1].

1.4. GATT Sub-Procedure Requirements

Requirements in this section represent a minimum set of requirements for a 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
Indications	M
Read Characteristic Descriptors	M
Write Characteristic Descriptors	M

Table 1.1. GATT Sub-procedure Requirements

There are no transport restrictions imposed by this service specification.

Where the term BR/EDR is used throughout this document, this also includes the optional use of AMP.

1.5. Error Codes

This service does not define any Attribute Protocol Application Error codes.

1.6. 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].

2. Service Declaration

In most cases, the Body Composition Service should be instantiated as a «Primary Service»; however this is defined in an higher level specification.

The service UUID shall be set to «Body Composition» defined in [2].

3. Service Characteristics

The following characteristics are exposed in the Body Composition Service. Only one instance of each characteristic is permitted within this service. The characteristic formats and UUIDs are defined in [2].

Where a characteristic can be indicated, a Client Characteristic Configuration descriptor shall be included in that characteristic as required by the Core Specification [1].

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Body Composition Feature	M	Read		None
Body Composition Measurement	M	Indicate		None

Table 3.1. Body Composition Service Characteristics

Notes:

Properties not listed as Mandatory or Optional are excluded for this version of this service
Security Permissions of “None” means that this service does not impose any requirements

3.1. Body Composition Feature

The Body Composition Feature characteristic shall be used to describe the supported features of the Server.

Reserved for Future Use (RFU) bits in the Body Composition Feature characteristic value shall be set to 0.

3.1.1. Characteristic Behavior

When read, the Body Composition Feature characteristic returns a value that is used by a Client to determine the supported features of the Server.

The bits of the Body Composition Feature characteristic may either be static for the lifetime of the device (i.e., static permanently or until Service Changed is indicated) or guaranteed to be static only during a connection. This requirement is defined in the table below on a bit-by-bit basis. Although all defined bits in this version of this specification are required to be static during the lifetime of a device, it is possible that some future bits will be defined as being static only during a connection.

Bit	Body Composition Feature Bit	Static Requirement
0 to 17	Various	Lifetime
18-31	Reserved for Future Use	Not defined.

Table 3.2. Static Requirements for Body Composition Feature Bits

When the Server supports a feature, the associated bit of the Body Composition Feature characteristic shall be set to 1 (Feature supported), otherwise, the associated bit shall be set to 0 (Feature not supported). The feature bits are defined in [2].

If the Height field of the Body Composition Measurement characteristic is not supported, then the corresponding resolution bits shall be set to 0.

3.2. Body Composition Measurement

The Body Composition Measurement characteristic is used to send body composition- related data to the Client. Included in the characteristic value are a Flags field (for showing the presence of optional fields and measurement units), a Body Fat Percentage field, and depending upon the contents of the Flags field, may include one or more optional fields defined in [2].

3.2.1. Characteristic Behavior

When the Body Composition Measurement characteristic is configured for indications via the Client Characteristic Configuration descriptor, the following applies:

	If a connection to a Client is not established and a new value for the Body Composition Measurement characteristic becomes available for this Client, the Server shall become connectable to allow the Client to create a link. Once connected, the Server shall indicate this characteristic and other unsent stored characteristics to the Client.

	If a connection to a Client is established and a new value for the Body Composition Measurement characteristic becomes available for this Client, the Server shall indicate this characteristic to the Client.

For LE, not all the fields of this characteristic can be indicated simultaneously if using a default MTU size. If the required data exceeds the current MTU size, the remaining optional fields shall be sent in the subsequent indication (also known as a ‘continuation packet’) and shall not include the Time Stamp field or the User ID field. Where the measurement is required to be split across two separate packets, the Multiple Packet Measurement bit in the Flags field of both packets shall be set to 1.

For BR/EDR, this restriction does not exist due to a larger MTU size.

Once transfer of a measurement is successful, the measurement shall not be retransmitted. As such, the design of this Service is only suited to sending indications to a single Client for a given user.

The Body Composition Measurement characteristic contains time-sensitive data, thus the requirements for time-sensitive data and data storage defined in Section 3.3 apply.

3.2.1.1. Flags Field

The Flags field shall be included in the Body Composition Measurement characteristic.

Reserved for Future Use (RFU) bits in the Flags fields shall be set to 0.

The bits of the Flags field, their function, and relationship to bits in the Body Composition Feature characteristic are shown in Table 3.3.

Flags Bit Name	When Set to 0	When Set to 1	Corresponding Body Composition Feature Support bit (see Section 3.1)
Measurement Units (bit 0)	SI (Weight and Mass in units of kilogram (kg) and Height in units of meter )	Imperial (Weight and Mass in units of pound (lb) and Height in units of inch (in))	Mass Measurement Resolution bits (11-14) and Height Measurement Resolution bits (15-17)
Time Stamp Present (bit 1), see Section 3.2.1.3	Corresponding field not present	Corresponding field present	Time Stamp Supported (bit 0)
User ID Present (bit 2), see Section 3.2.1.4	Corresponding field not present	Corresponding field present	Multiple Users Supported (bit 1)
Basal Metabolism Present (bit 3), see Section 3.2.1.5	Corresponding field not present	Corresponding field present	Basal Metabolism Supported (bit 2)
Muscle Percentage Present (bit 4), see Section 3.2.1.6	Corresponding field not present	Corresponding field present	Muscle Percentage Supported (bit 3)
Muscle Mass Present (bit 5), see Section 3.2.1.7	Corresponding field not present	Corresponding field present	Muscle Mass Supported (bit 4)
Fat Free Mass Present (bit 6), see Section 3.2.1.8	Corresponding field not present	Corresponding field present	Fat Free Mass Supported (bit 5)
Soft Lean Mass Present (bit 7), see Section 3.2.1.9	Corresponding field not present	Corresponding field present	Soft Lean Mass Supported (bit 6)
Body Water Mass Present (bit 8), see Section 3.2.1.10	Corresponding field not present	Corresponding field present	Body Water Mass Supported (bit 7)
Impedance Present (bit 9), see Section 3.2.1.11	Corresponding field not present	Corresponding field present	Impedance Supported (bit 8)
Weight Present (bit 10), see Section 3.2.1.12	Corresponding field not present	Corresponding field present	Weight Supported (bit 9)
Height Present (bit 11), see Section 3.2.1.13	Corresponding field not present	Corresponding field present	Height Supported (bit 10)
Multiple Packet Measurement (bit 12)	Measurement contained in single packet	Measurement split across two consecutive packets	None

Table 3.3. Bit Definitions for the Body Composition Measurement Characteristic

The term ‘mass’ refers collectively to the following fields: Muscle Mass, Fat Free Mass, Soft Lean Mass, Body Water Mass.

Flags bits in the table above, other than the Time Stamp Present bit and User ID Present bit, may change during a connection if the corresponding support bit in the Body Composition Feature characteristic is set to 1, indicating that the feature is supported. However, if the corresponding Body Composition Feature support bit is set to 0, then the corresponding Flags bit shall also be set to 0 since the feature is not supported.

The Mass Measurement Resolution bits are only for the purpose of allowing the Client to determine the resolution of the Weight and Mass measurements. All supported Weight and Mass fields are assumed to have the same resolution. Similarly, the Height Measurement Resolution bits are only for the purpose of allowing the Client to determine the resolution of the Height measurements. The use of these bits may be required by some Clients that need to know the approximate precision of the data. Note that value of these bits has no impact on the value of 1 bit of the Weight, Mass or Height fields.

3.2.1.2. Body Fat Percentage Field

The Body Fat Percentage field shall be included in the Body Composition Measurement characteristic.

See Table 3.3 for details on the relation between the unit of weight, mass and height, and bit 0 of the Flags field.

The special value of 0xFFFF can be used to indicate ‘Measurement Unsuccessful’ to the Client. If this is used, all optional fields other than the Time Stamp field and the User ID field shall be disabled.

3.2.1.3. Time Stamp Field

The Time Stamp field is optional, but shall be included in the Body Composition Measurement characteristic if the Server supports the Time Stamp feature (see Table 3.3) with the exception that it shall not be included in continuation packets (see Section 3.2.1). The Time Stamp feature shall be supported if the device supports the storing of data.

The Time Stamp field is defined to use the same format as the Date Time characteristic defined in [2]. However, a value of 0 for the year, month or day fields (meaning unknown) shall not be used for this service. It is left to the implementation to ensure the user sets the correct date and time before the Server is used.

The value of the Time Stamp field is derived from a source of date and time within the device at the time of measurement. If the Time Stamp feature is supported, a source of date and time is mandatory. The date and time of the device may be updated by various means such as via a simple user interface on the device, via the Current Time Service [3] or other method. Regardless of the method of updating the date and time, a method should be provided to allow the Client to verify the accuracy of the time base in the Server. This is a requirement for implementations needing to be compliant with guidelines set forth by the Continua Health Alliance (and hence those needing data to be transcoded to a format compliant with IEEE 11073-10420 [4]).

3.2.1.4. User ID Field

The User ID field shall be included in the Body Composition Measurement characteristic if the device supports the Multiple Users feature (see Table 3.3) with the exception that it shall not be included in continuation packets (see Section 3.2.1). This field shall not be included if the Multiple Users feature is not supported.

The values used for User ID shall be unique per Server, but are otherwise left to the implementation. For example, if the Server supports two User IDs to distinguish between two users, the Server may use User ID 1 and 2 or User ID 35 and 97 or other unique combinations.

A special User ID value of 0xFF represents “unknown user”. This can be used for cases where a Body Composition Analyzer can be used for Guests.

3.2.1.5. Basal Metabolism

The Basal Metabolism field may be included in the Body Composition Measurement characteristic if the device supports the Basal Metabolism feature (see Table 3.3).

3.2.1.6. Muscle Percentage

The Muscle Percentage field may be included in the Body Composition Measurement characteristic if the device supports the Muscle Percentage feature (see Table 3.3).

3.2.1.7. Muscle Mass

The Muscle Mass field may be included in the Body Composition Measurement characteristic if the device supports the Muscle Mass feature (see Table 3.3).