-
Revision: v1.0.1
-
Revision Date: 2024-10-01
-
Group Prepared By: SF WG
Revision History
|
Revision |
Date |
Comments |
|---|---|---|
|
V1.0.0 |
2014-10-21 |
Adopted by the Bluetooth SIG BoD |
|
v1.0.1 |
2024-10-01 |
Adopted by the Bluetooth SIG Board of Directors. |
Version History
|
Versions |
Changes |
|---|---|
|
v1.0.0 to v1.0.1 |
Incorporated errata 16254, 16255, 18760, 22602, 19079, 23321. |
Acknowledgments
|
Name |
Company |
|---|---|
|
Robert Hughes |
Intel Corporation |
|
Jerry Wang |
A&D Medical |
|
Yoshiteru Nozoe |
A&D Medical |
|
Tetsu Nishimura |
Murata Manufacturing |
|
Leif-Alexandre Aschehoug |
Nordic Semiconductor |
|
Elvis Pfutzenreuter |
Signove |
Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.
Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”
Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING 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, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.
Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.
Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.
Copyright © 2013–2024. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. 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 Weight Scale (WS) Service exposes weight and related data from a weight scale (Server) intended for consumer healthcare as well as sports/fitness applications.
1.1. Conformance
Each capability of this specification shall be supported in the specified manner. This specification may provide options for design flexibility, because, for example, some products do not implement every portion of the specification. For each implementation option that is supported, it shall be supported as specified.
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.2 or later [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 |
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 [1].
2. Service Declaration
In most cases, the Weight Scale Service should be instantiated as a «Primary Service»; however this is defined in a higher-level specification.
The service UUID shall be set to «Weight Scale Service» defined in [3].
3. Service Characteristics
The following characteristics are exposed in the Weight Scale Service. Only one instance of each characteristic is permitted within this service. The characteristic formats and UUIDs are defined in [3].
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 |
|---|---|---|---|---|
|
Weight Scale Feature |
M |
Read |
Indicate C.1 |
None |
|
Weight Measurement |
M |
Indicate |
None |
- C.1:
-
The Indicate property shall be supported for the Weight Scale Feature characteristic if the device supports bonding and the value of the Weight Scale Feature characteristic can change over the lifetime of the device, otherwise excluded for this service.
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. Weight Scale Feature
The Weight Scale Feature characteristic shall be used to describe the supported features of the Server.
Reserved for Future Use (RFU) bits in the Weight Scale Feature characteristic value shall be set to 0.
3.1.1. Characteristic Behavior
When read or indicated, the Weight Scale Feature characteristic returns a value that is used by a Client to determine the supported features of the Server.
The bits of the Weight Scale Feature characteristic may either be static for the lifetime of the device 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 |
Weight Scale Feature Bit |
Static Requirement |
|---|---|---|
|
0 to 9 |
Various |
Lifetime |
|
10-31 |
Reserved for Future Use |
Not defined. |
When the Client Characteristic Configuration descriptor is configured for indications and the supported features of the Server have changed, the Weight Scale Feature characteristic shall be indicated to any bonded Collectors after reconnection.
When the Server supports a feature, the associated bit of the Weight Scale 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 [3].
If the Height field of the Weight Measurement characteristic is not supported, then the corresponding resolution bits shall be set to 0.
3.2. Weight Measurement
The Weight Measurement characteristic is used to send weight-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 Weight field, and depending upon the contents of the Flags field, may include one or more optional fields defined in [3].
3.2.1. Characteristic Behavior
When the Weight 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 Weight 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 characteristic values to the Client. |
|
|
If a connection to a Client is established and a new value for the Weight Measurement characteristic becomes available for this Client, the Server shall indicate this characteristic to the Client. |
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 Weight 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 Weight 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 Weight Scale Feature characteristic are shown in Table 3.3.
|
Flags Bit Name |
When Set to 0 |
When Set to 1 |
Corresponding Weight Scale Feature Support bit (see Section 3.1) |
|---|---|---|---|
|
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)) |
Weight Measurement Resolution bits (bits 3-6) and Height Measurement Resolution bits (bits 7-9) |
|
|
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) |
|
BMI and Height Present (bit 3), see Section 3.2.1.5 |
Corresponding field pair not present |
Corresponding field pair present |
BMI Supported (bit 2) |
The BMI and Height Present bit in the table above may change during a connection if the corresponding support bit in the Weight Scale Feature characteristic is set to 1, indicating that the feature is supported. However, if the corresponding Weight Scale 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 Weight Measurement Resolution bits and Height Measurement Resolution bits are only for the purpose of allowing the Client to determine the resolution of the Weight and Height measurements respectively. The use of these bits may be required by some Clients that need to know the approximate precision of the data. Note that the value of these bits has no impact on the value of 1 bit of the Weight and Height fields.
3.2.1.2. Weight Field
The Weight field shall be included in the Weight Measurement characteristic.
See Table 3.3 for details on the relation between the unit of weight, 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 Weight Measurement characteristic if the Server supports the Time Stamp feature (see Table 3.3). 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 [3]. 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-10415 [4]).
3.2.1.4. User ID Field
The User ID field shall be included in the Weight Measurement characteristic if the device supports the Multiple Users feature (see Table 3.3). 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 Weight Scale can be used for Guests.
3.2.1.5. BMI and Height Field Pair
The BMI and Height field pair may be included in the Weight Measurement characteristic if the device supports the BMI feature (see Table 3.3). When present, these fields shall always be present as a pair.
See Table 3.3 for details on the relation between the units of weight and height, and bit 0 of the Flags field.
BMI or Body Mass Index is calculated as Weight in kilograms divided by the square of Height in meters. When only imperial values of weight and height are available, BMI can be calculated by dividing the Weight in pounds by the square of the Height in inches and multiplying this by a factor of approximately 703.07. For Servers that support BMI, this calculation requires the Server to know the height of the user. This information may be entered locally at the Server user interface or by other means and is beyond the scope of this service.
3.3. Requirements for Time-Sensitive Data
The Weight Measurement characteristic contains time-sensitive data (i.e., the Weight value) and is considered a time-sensitive characteristic, thus the following requirements apply:
If the Time Stamp feature is not supported:
-
The value of a time-sensitive characteristic shall be discarded either if the connection does not get established or if the indication is not successfully acknowledged by the Client in a timely manner as decided by the implementation (e.g., if the Server cannot send the data within 5 minutes of taking the measurement).
If the Time Stamp feature is supported:
-
It is recommended that the value of a time-sensitive characteristic be stored if either the connection does not get established or if the indication is not successfully acknowledged by the Client during the connection.
-
For basic scenarios, the Server should be able to store at least 25 data measurements (i.e., Weight values). Multi-user devices should be able to store that number of measurements per supported user.
-
If the maximum storage capacity in the Server is reached, the Server should overwrite the oldest measurement data first when acquiring new measurement data and should inform the user (e.g., via the UI of the device). For multi-user devices, the Server should purge the oldest data for a given user to make room for the most recent data for that user.
-
When transmitting stored data, the oldest data shall be sent first followed by the next oldest data (in FIFO order) until all stored data (as controlled by the Client) has been transferred.
4. SDP Interoperability
If this service is exposed over BR/EDR then it shall have the following SDP record.
|
Item |
Definition |
Type |
Value |
Status |
|---|---|---|---|---|
|
Service Class ID List |
M |
|||
|
Service Class #0 |
UUID |
«Weight Scale» |
M |
|
|
Protocol Descriptor List |
M |
|||
|
Protocol #0 |
UUID |
L2CAP |
M |
|
|
Parameter #0 for Protocol #0 |
PSM |
Uint16 |
PSM = ATT |
M |
|
Protocol #1 |
UUID |
ATT |
M |
|
|
BrowseGroupList |
PublicBrowseRoot* |
M |
- *
-
PublicBrowseRoot shall be present; however, other browse UUIDs may also be included in the list.
5. Acronyms and Abbreviations
|
Acronyms and Abbreviations |
Meaning |
|---|---|
|
AMP |
Alternate MAC/PHY |
|
BR/EDR |
Basic Rate / Enhanced Data Rate |
|
GAP |
Generic Access Profile |
|
GATT |
Generic Attribute Profile |
|
LE |
Low Energy |
|
RFU |
Reserved for Future Use |
|
SDP |
Service Discovery Protocol |
|
WS |
Weight Scale |
|
UUID |
Universally Unique Identifier |
6. References
[1] Bluetooth Core Specification v4.2 or later
[2] Bluetooth Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers/
[3] Current Time Service Specification v1.1 or later
[4] IEEE 11073-10415 - 2008 (Health informatics—Personal health device communication - Part 10415: Device specialization— Weighing Scale)