-
Version: v1.2
-
Version Date: 2023-06-21
-
Prepared By: Human Interface Device Working Group
Version History
|
Version Number |
Date |
Comments |
|---|---|---|
|
V10r00 |
2011-05-24 |
Adopted by the Bluetooth SIG Board of Directors |
|
V11r00 |
2011-11-29 |
Adopted by the Bluetooth SIG Board of Directors |
|
v1.2 |
2023-06-21 |
Adopted by the Bluetooth SIG Board of Directors. For the change history between this version and the previous version, see Section 1.7. |
Acknowledgments
|
Name |
Company |
|---|---|
|
Robin Heydon |
CSR |
|
Robert Hughes |
Intel |
|
Krishna Shingala |
MindTree |
|
Mateus Lima |
Signove |
|
Jason Hillyard |
Wicentric |
|
Len Ott |
Socket Mobile |
|
Erik Moll |
Koninklijke Philips N.V. |
|
Jordan Hartmann |
Nonin Medical, Inc. |
|
Frank Berntsen |
Nordic Semiconductor ASA |
|
Victor Zhodzishsky |
Infineon Technologies AG |
|
Niclas Granqvist |
Logitech International SA |
|
Xavier Boniface |
Logitech International SA |
|
Robert Hulvey |
Meta Platforms, Inc |
|
Christopher Church |
Qualcomm Technologies International, Ltd |
|
Alicia Courtney |
Broadcom Corp. |
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 © 2011–2023. 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 Device Information Service exposes manufacturer and/or vendor information about a device.
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 service is compatible with any Bluetooth Core Specification host [1] that includes the Generic Attribute Profile (GATT).
1.4. GATT sub-procedure requirements
This service does not require any additional GATT sub-procedures beyond those required by all GATT Servers.
1.5. Transport dependencies
This service uses GATT and therefore has no additional transport dependencies.
1.6. Error codes
This service does not define any application error codes.
1.7. Change History
This section summarizes changes at a moderate level of detail and should not be considered representative of every change made.
1.7.1. New and updated features
|
Feature Name |
Description |
Location |
|---|---|---|
|
Unique Device Identifier for Medical Devices |
Addition of the UDI for Medical Devices and related metadata as a new characteristic. |
|
|
Multiple Instances |
Changes so that a GATT Server can support multiple instances of the DIS Service. |
1.7.2. Removed features
No features were removed in this version.
1.7.3. Errata incorporated in v1.2
|
Section |
Errata |
|---|---|
|
Front Matter |
E18793, E22608 |
|
Disclaimer |
E18774 |
|
Global |
E22608 |
|
Section 1.1 |
E18795 |
|
Section 1.4 |
E19230 |
|
Section 1.5 |
E19229 |
|
Section 2 |
E23096 |
|
Section 3.10 |
E6237, E6238 |
|
Section 4 |
E16573 |
|
Section 5 |
E23029, E23103 |
1.8. Language
1.8.1. Language conventions
In the development of a specification, the Bluetooth SIG has established the following conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”, and “can”. In this Bluetooth specification, the terms in Table 1.3 have the specific meanings given in that table, irrespective of other meanings that exist.
|
Term |
Definition |
|---|---|
|
shall |
—used to express what is required by the specification and is to be implemented exactly as written without deviation |
|
shall not |
—used to express what is forbidden by the specification |
|
should |
—used to express what is recommended by the specification without forbidding anything |
|
should not |
—used to indicate that something is discouraged but not forbidden by the specification |
|
may |
—used to indicate something that is permissible within the limits of the specification |
|
must |
—used to indicate either:
|
|
can |
—used to express a statement of possibility or capability |
1.8.1.1. Implementation alternatives
When specification content indicates that there are multiple alternatives to satisfy specification requirements, if one alternative is explained or illustrated in an example it is not intended to limit other alternatives that the specification requirements permit.
1.8.1.2. Discrepancies
It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not contain discrepancies. However, members can report any perceived discrepancy by filing an erratum and can request a test case waiver as appropriate.
1.8.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.8.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. Service declaration
No more than one instance of the Device Information Service may be exposed as a «Primary Service» on a device. One or more instances of the Device Information Service may be exposed as a «Secondary Service» on the same device.
A Device Information Service instance that is exposed as a «Primary Service» shall represent the information that corresponds to the device itself. A Device Information Service instance that is exposed as a «Secondary Service» must be included in another service (see [Vol 3] Part G, Section 2.6.3 in [1]). The specification of the including service defines the device that the characteristics of the included Device Information Service represent.
The service UUID shall be set to «Device Information». The UUID value assigned to «Device Information» is defined in [2].
3. Service characteristics
The Device Information Service may expose one or more of the characteristics shown in Table 3.1. It is possible that none of the characteristics below are included. Unless otherwise specified, only one instance of each characteristic shall be present.
|
Characteristic Name |
Characteristic Qualifier |
Mandatory Properties |
Optional Properties |
Security Permissions |
|---|---|---|---|---|
|
Manufacturer Name String |
O |
Read |
None |
|
|
Model Number String |
O |
Read |
None |
|
|
Serial Number String |
O |
Read |
None |
|
|
Hardware Revision String |
O |
Read |
None |
|
|
Firmware Revision String |
O |
Read |
None |
|
|
Software Revision String |
O |
Read |
None |
|
|
System ID |
O |
Read |
None |
|
|
IEEE 11073-20601 Regulatory Certification Data List |
O |
Read |
None |
|
|
PnP ID |
O |
Read |
None |
|
|
UDI for Medical Devices |
O |
Read |
None |
Notes:
-
Security Permissions of “None” means that this service does not impose any requirements.
-
Properties not listed as Mandatory or Optional are Excluded.
-
The structure of these characteristics is defined in the GATT Specification Supplement [4].
-
The connection should be authenticated if Serial Number String, System ID, or UDI for Medical Devices is present because any fixed and unique number can be considered Personally Identifiable Information (PII).
3.1. Manufacturer Name String
The Manufacturer Name String characteristic shall represent the name of the manufacturer of the device.
3.1.1. Characteristic behavior
The Manufacturer Name String characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.2. Model Number String
The Model Number String characteristic shall represent the model number that is assigned by the device vendor.
3.2.1. Characteristic behavior
The Model Number String characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.3. Serial Number String
The Serial Number String characteristic shall represent the serial number for a particular instance of the device.
3.3.1. Characteristic behavior
The Serial Number String characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.4. Hardware Revision String
The Hardware Revision String characteristic shall represent the hardware revision for the hardware within the device.
3.4.1. Characteristic behavior
The Hardware Revision String characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.5. Firmware Revision String
The Firmware Revision String characteristic shall represent the firmware revision for the firmware within the device.
3.5.1. Characteristic behavior
The Firmware Revision String characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.6. Software Revision String
The Software Revision String characteristic shall represent the software revision for the software within the device.
3.6.1. Characteristic behavior
The Software Revision String characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.7. System ID
The System ID characteristic shall represent a structure containing an Organizationally Unique Identifier (OUI) followed by a manufacturer-defined identifier and is unique for each individual instance of the product.
3.7.1. Characteristic behavior
The System ID characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.8. IEEE 11073-20601 Regulatory Certification Data List
The IEEE 11073-20601 Regulatory Certification Data List characteristic shall represent regulatory and certification information for the product in a list defined in IEEE 11073-20601 [3].
3.8.1. Characteristic behavior
The IEEE 11073-20601 Regulatory Certification Data List characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.9. PnP ID
The PnP_ID characteristic is a set of values that is used to identify all devices of a given type/model/version. Included in the characteristic are a Vendor ID source field, a Vendor ID field, a Product ID field, and a Product Version field.
The fields in this characteristic shall be packed into the characteristic in the following order:
-
Vendor ID source
-
Vendor ID
-
Product ID
-
Product Version
The Vendor ID, Product ID, and Product Version fields shall be packed into the characteristic in little‑endian format. The Vendor ID source field shall start at the Least Significant Octet of the characteristic and the Product Version field shall end at the Most Significant Octet.
3.9.1. Characteristic behavior
The PnP_ID characteristic returns its value when read using the GATT Characteristic Value Read procedure.
3.9.1.1. Vendor ID Source field
The Vendor ID Source field designates which organization assigned the value used in the Vendor ID field value.
The possible values are defined in Table 3.2.
|
Value |
Description |
|---|---|
|
0x01 |
Bluetooth SIG-assigned Device ID Vendor ID value from the Assigned Numbers document [2] |
|
0x02 |
USB Implementer’s Forum assigned Vendor ID value |
|
0x00, 0x03 to 0xFF |
Reserved for future use |
3.9.1.2. Vendor ID field
The Vendor ID field is intended to uniquely identify the vendor of the device. This field is used in conjunction with Vendor ID Source field, which determines which organization assigned the Vendor ID field value.
Note: The Bluetooth Special Interest Group assigns Device ID Vendor ID, and the USB Implementer’s Forum assigns Vendor IDs, either of which can be used for the Vendor ID field value. Device providers should procure the Vendor ID from the USB Implementer’s Forum or the Company Identifier from the Bluetooth SIG.
3.9.1.3. Product ID field
The Product ID field is intended to distinguish between different products made by the vendor identified with the Vendor ID field.
The vendors themselves manage Product ID field values.
3.9.1.4. Product Version field
The Product Version field is a numeric expression identifying the device release number in Binary-Coded Decimal. This is a vendor-assigned value that defines the version of the product identified by the Vendor ID and Product ID fields. This field is intended to differentiate between versions of products with identical Vendor IDs and Product IDs. The value of the field value is 0xJJMN for version JJ.M.N (JJ – major version number, M – minor version number, N – sub-minor version number); e.g., version 2.1.3 is represented with a value of 0x0213 and version 2.0.0 is represented with a value of 0x0200. When upward-compatible changes are made to the device, it is recommended that the minor version number be incremented. If incompatible changes are made to the device, it is recommended that the major version number be incremented. The sub-minor version is incremented for bug fixes.
The vendors themselves manage Product Version field values.
3.10. UDI for Medical Devices
The UDI for Medical Devices characteristic is a structure that contains the Unique Device Identifier (UDI) as assigned to the medical device. When the device has a label representing the UDI, the UDI for Medical Devices characteristic shall represent the same value.
The UDI of a personal medical device is seen as Protected Health Information.
3.10.1. Characteristic behavior
The UDI for Medical Devices characteristic returns its value when read using the GATT Characteristic Value Read procedure.
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 |
«Device Information» |
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 |
|---|---|
|
ATT |
Attribute Protocol |
|
BR/EDR |
Basic Rate / Enhanced Data Rate |
|
GATT |
Generic Attribute Profile |
|
LE |
Low Energy |
|
OUI |
Organizationally Unique Identifier |
|
PnP |
Plug and Play |
|
UDI |
Unique Device Identifier |
|
UUID |
Universally Unique Identifier |
6. References
Bibliography
[1] Bluetooth Core Specification, Version 4.2 or later
[2] Bluetooth Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers/
[3] IEEE Std 11073-20601™- 2008 Health Informatics - Personal Health Device Communication - Application Profile - Optimized Exchange Protocol - version 1.0 or later
[4] GATT Specification Supplement, v8 or later