-
Revision: v1.0
-
Revision Date: 2019-07-02
-
Group Prepared By: PUID Working Group
-
Feedback Email: [email protected]
Revision History
|
Revision Number |
Date |
Comments |
|---|---|---|
|
v1.0 |
2019-07-02 |
Adopted by the Bluetooth SIG Board of Directors. |
Contributors
|
Name |
Company |
|---|---|
|
Hironari Ushikubo |
NTT DOCOMO |
|
Frank Berntsen |
Nordic Semiconductor |
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.
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.
If this specification is a prototyping specification, it is solely for the purpose of developing and using prototypes to verify the prototyping specifications at Bluetooth SIG sponsored IOP events. Prototyping Specifications cannot be used to develop products for sale or distribution and prototypes cannot be qualified for distribution.
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 © 2018–2019. 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.
1. Introduction
The Binary Sensor Profile, in conjunction with the Binary Sensor Service [1], provides two characteristics that are used for a protocol between the client and a server to transfer the status of binary sensors on the server side.
1.1. Profile dependencies
This profile is compatible with any Core Host, as defined in the Bluetooth Core Specification [2], that includes the Generic Attribute Profile (GATT).
1.2. Conformance
If conformance to this specification is claimed, all capabilities indicated as mandatory for this specification shall be supported in the specified manner (process-mandatory). This also applies to all optional and conditional capabilities for which support is indicated.
1.3. Bluetooth specification release compatibility
This specification is compatible with Bluetooth Core Specification 5.0 or later [2].
1.4. Language
1.4.1. Language conventions
The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, is, and note in the development of specifications:
|
shall |
is required to – used to define requirements. |
|
must |
is used to express: a natural consequence of a previously stated mandatory requirement. OR an indisputable statement of fact (one that is always true regardless of the circumstances). |
|
will |
it is true that – only used in statements of fact. |
|
should |
is recommended that – used to indicate that among several possibilities one is recommended as particularly suitable, but not required. |
|
may |
is permitted to – used to allow options. |
|
can |
is able to – used to relate statements in a causal manner. |
|
is |
is defined as – used to further explain elements that are previously required or allowed. |
|
note |
Used to indicate text that is included for informational purposes only and is not required in order to implement the specification. Each note is clearly designated as a “Note” and set off in a separate paragraph. |
For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.
1.4.2. Reserved for Future Use
Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.
Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.
When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.
The acronym RFU is equivalent to Reserved for Future Use.
1.4.3. Prohibited
When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.
Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.
“Prohibited” is never abbreviated.
2. Configuration
2.1. Roles
The profile defines two roles: the Sensor role and the Collector role:
-
The Sensor role applies to the device that reports binary sensor status to a Collector device.
-
The Collector role applies to the device that receives data from a Binary Sensor device.
The device acting in the Sensor role shall be a GATT Server.
The device acting in the Collector roll shall be a GATT Client.
Hereafter, this document will simply refer to these devices that implement such roles as a Sensor and a Collector.
2.2. Role/service relationships
The following diagram shows the relationship between service and profile roles. Profile roles are represented by blue boxes and the services are represented by a gray box.
For a wearable device with limited resources, the implementer can choose to implement the Alert Notification Profile Client role to receive notification via a device implementing the Binary Sensor Profile Collector role. For more information, see Appendix A.
2.3. Concurrency limitations/restrictions
The Binary Sensor profile may run concurrently with other profiles.
2.4. Topology limitations/restrictions
There are no topology limitations or restrictions.
The Sensor shall use the GAP Peripheral role.
The Collector shall use the GAP Central role.
2.5. Transport dependencies
This profile is specified for operation over Bluetooth Low Energy (LE) transport.
3. Sensor role requirements
The following table describes support of the Sensor, which shall instantiate one and only one instance of the Binary Sensor Service as a primary service.
The Sensor role shall have one instance of the Binary Sensor Service.
|
Service |
Server |
|---|---|
|
Binary Sensor Service |
M |
- M:
-
Mandatory
3.1. Incremental Binary Sensor Service requirements
This section describes the incremental Binary Sensor Service requirements.
3.1.1. Additional requirements for Low Energy transport
Section 3.1.1.1 and Section 3.1.1.2 describe the requirements for Bluetooth LE transport.
3.1.1.1. Service UUIDs AD Type
While in a GAP Discoverable Mode for initial connection to a Collector, the Sensor should include the Binary Sensor Service UUID defined in [3] in the Service UUIDs AD type field of the Advertising Data or Scan Response Data to enable the Collector to identify a Binary Sensor before initiating a connection.
3.1.1.2. Local Name AD Type
To enable the Collector to identify a Binary Sensor before initiating a connection, the Sensor should include the Local Name, containing either the complete or shortened value of the Device Name characteristic as defined in [2], either in its Advertising Data or in its Scan Response Data.
4. Collector role requirements
Table 4.1 describes support of the Collector requirements:
|
Profile Requirement |
Section |
Support in <client role> |
|---|---|---|
|
Service Discovery |
M |
|
|
M |
|
|
Characteristic Discovery |
M |
|
|
M |
|
|
Binary Sensor procedures |
M |
|
|
M |
|
|
M |
|
|
M |
- M:
-
Mandatory
4.1. GATT sub-procedure requirements
Table 4.2 describes the GATT sub-procedure requirements for a Collector.
|
GATT Sub-Procedure |
<client role> Requirements |
|---|---|
|
Discover All Primary Services |
C.1 |
|
Discover Primary Services by Service UUID |
C.1 |
|
Discover All Characteristics of a Service |
C.2 |
|
Discover Characteristics by UUID |
C.2 |
|
Write Characteristic Value |
M |
|
Indications |
M |
- C.1:
-
Mandatory to support at least one of these service discovery sub-procedures.
- C.2:
-
Mandatory to support at least one of these characteristic discovery sub-procedures.
- M:
-
Mandatory
4.2. Service discovery
The Collector shall perform primary service discovery using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure.
4.2.1. Binary Sensor Service discovery
The Collector shall discover the Binary Sensor Service (BSS).
4.3. Characteristic discovery
As required by GATT, the Collector shall be tolerant of two additional characteristics in the service records of services used with this profile. These two characteristics are described in Sections Section 4.3.1.1 and Section 4.3.1.2.
4.3.1. Binary Sensor Service characteristic discovery
The Collector shall perform either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure in order to discover the characteristics of the service.
4.3.1.1. BSS Control Point characteristic
The Collector shall discover the BSS Control Point characteristic.
4.3.1.2. BSS Response characteristic
The Collector shall discover the BSS Response characteristic.
The GATT Discover All Characteristic Descriptors sub-procedure shall be used to discover the Client Characteristic Configuration descriptor.
4.4. BSS Control Point and BSS Response procedures
Prior to executing any of the procedures described in Sections Section 4.4.1 through Section 4.4.3, the Collector shall configure the Client Characteristic Configuration descriptor of the BSS Response characteristic to enable indications. The Collector shall execute the GATT Write Characteristic Value sub-procedure when writing the BSS Control Point characteristic. The Collector shall execute the GATT Indications sub-procedure to receive indications on the BSS Response characteristic.
4.4.1. Get Sensor Status Command Procedure
The Collector shall write a Get Sensor Status Command Message to the BSS Control Point characteristic of the Binary Sensor Service.
The Get Sensor Status Command Message shall have exactly 1 parameter.
The Sensor Type Parameter shall be set to the type of sensor the Collector is requesting information for.
The Collector shall wait for a Get Sensor Status Response Message indicated on the BSS Response characteristic of the Binary Sensor Service.
4.4.2. Setting Sensor Command Procedure
The Collector shall write a Setting Sensor Command Message to the BSS Control Point characteristic of the Binary Sensor Service.
The Setting Sensor Command Message shall have at least two parameters as described below:
-
The Sensor Type Parameter shall be set to the type of sensor that the Setting Sensor Command Message shall act on.
-
The Report Status Parameter shall be set to On or Off.
For a Single Sensor, the Setting Sensor Command Message may include one Name parameter.
For a Multiple Sensor, the Setting Sensor Command Message may include a Name parameter for each sensor element.
The Collector shall wait for a Setting Sensor Response Message indicated on the BSS Response characteristic of the Binary Sensor Service.
4.4.3. Sensor Status Event Procedure
The Collector shall accept an unsolicited Sensor Status Event whenever the Collector is not processing a Get Sensor Status Procedure or a Setting Sensor Command Procedure.
5. Protocol requirements
The Collector shall implement the protocol as described in the Binary Sensor Service [1]. The Collector shall support all defined sensor types and the Named Sensors option.
6. Segmentation and reassembly
The Collector shall implement the segmentation and reassembly as described in the Binary Sensor Service [1].
7. Connection establishment procedures
There are no connection establishment requirements beyond those already in the Generic Access Profile (GAP).
8. Security considerations
This section describes the security requirements for both Sensor and Collector.
8.1. Sensor security considerations
This section describes the security requirements for the Sensor.
All supported characteristics specified by the Binary Sensor Service shall be set to LE security mode 1 and security level 2 as defined in [2] Volume 3, Part C.
8.2. Collector security considerations
This section describes the security requirements for the Collector.
The Collector may bond with the Sensor.
The Collector shall accept any request by the Sensor for LE security mode 1 level 2, level 3, or level 4 as defined in [2] Volume 3, Part C.
9. Acronyms and abbreviations
|
Acronym/Abbreviation |
Meaning |
|---|---|
|
BSP |
Binary Sensor Profile |
|
BSS |
Binary Sensor Service |
|
GAP |
Generic Access Profile |
|
GATT profile |
Generic Attributes (GATT) profile |
|
HD |
human detection sensor |
|
O/C |
open/closed sensor |
|
VIB |
vibration sensor |
10. References
Bibliography
[1] Binary Sensor Service Specification
[2] Bluetooth Core Specification, Version 5.0 or later
[3] Service UUIDs, Characteristic, and Descriptor descriptions accessible via the Bluetooth SIG Assigned Numbers
Appendix A. Binary Sensors with wearable devices
This appendix describes an alternate method that an implementer might use for notifications from binary sensors.
For a wearable device with limited resources, the implementer can choose to implement the Alert Notification Profile Client role to receive notification via a device implementing the Binary Sensor Profile Collector role. The wearable device then receives alerts from a smart device running the Binary Sensor Profile as shown in Figure A.1.
