HID Over GATT Profile

This profile requires the Generic Attribute Profile (GATT), the Battery Service, the Device Information Service, and the Scan Parameters Profile.

This section summarizes changes at a moderate level of detail and should not be considered representative of every change made.

Requirements in this specification are defined as "Mandatory" (M), "Optional" (O), "Excluded" (E), “Not Applicable” (N/A), or "Conditional" (C.#). Conditional statements (C.#) are listed directly below the table in which they appear.

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.

This profile defines three roles: HID Device, Boot Host, and Report Host.

The term HID Host refers to both host roles: Boot Host, and Report Host. A Report Host is required to support a HID Parser and be able to handle arbitrary formats for data transfers (known as Reports), whereas a Boot Host is not required to support a HID Parser as all data transfers (Reports) for Boot Protocol Mode are of predefined length and format.

Figure 2.1 shows the relationship between services and the profile roles.

Figure 2.1. Boot Host and HID Device Roles/Service Relationship

Figure 2.2. Report Host and HID Device Roles/Service Relationships

The Report Host supports the Scan Client role of the Scan Parameters Profile.

The Boot Host shall not support the Scan Client role of the Scan Parameters Profile.

The HID Device has one or more instances of the HID Service, one or more instances of the Battery Service, a single instance of the Device Information Service, and optionally one instance of the Scan Parameters Service as part of the Scan Server role of the Scan Parameters Profile. A HID Device that supports the HID ISO feature has a single instance of the HID ISO Service. The HID Device may optionally have single or multiple instances of other services.

A Boot Host shall not concurrently be a Report Host.

A Report Host shall not concurrently be a Boot Host.

There are no concurrency limitations on either HID Host roles from also being a HID Device.

Devices with HID SCI and devices with HID ISO can be connected in various combinations. A HID Host may be connected to multiple HID devices, each device using the Hybrid Operation mode or the Default Operation mode with or without HID SCI.

The HID Device shall use the GAP Peripheral role.

The Boot Host shall use the GAP Central role.

The Report Host shall use the GAP Central role.

Multiple service instances shall not be supported for the following services:

Multiple service instances of the HID Service may be supported to allow implementers to define composite HID Devices whose combined functions require more than 512 octets of data to describe.

This profile shall operate over an LE transport only. Implementations that support report intervals less than 2 ms shall use the LE 2M PHY for report intervals less than 2 ms.

HID Host implementations and HID Device implementations that support the HID SCI feature depend on both Host support and Controller support for SCI. See Volume 6, Part B of [2].

Enabling Bluetooth wireless technology end-to-end in an implementation of this profile requires an implementation of a Core Configuration that supports the LE transport.

This sub-section defines additional HID Device requirements beyond those defined in the HID Service [3].

This sub-section defines additional HID Device requirements beyond those defined in the Battery Service [4].

This sub-section defines additional HID Device requirements beyond those defined in the Device Information Service [5].

This subsection defines additional HID Device requirements beyond those defined in the Scan Parameters Service [6].

Section 5 establishes additional requirements for a HID Device that supports the HID ISO feature.

Section 7 establishes additional requirements for a HID Device that supports the HID SCI feature. HID SCI capability is exposed in the HID Information characteristic.

A HID Device may configure a Flush Timeout on LE ACL for Input Reports. Flushing of data is only allowed in the Attribute Protocol with GATT notifications for Input Reports. Flush operation only applies to HID Input Reports. For further information, see Volume 3, Part G, Section 5.2.2 of [2].

Requirements in this section represent a minimum set of requirements for a client. Other GATT sub-procedures may be used if supported by both the GATT Client and GATT Server.

Table 4.2 summarizes additional GATT sub-procedure requirements beyond those required by all GATT Clients.

Requirements marked with ‘M’ are mandatory, ‘O’ are optional, and ‘E’ are excluded (not permitted).

The Report Host shall support the functionality defined in the Scan Parameters Profile [6].

The Boot Host shall perform primary service discovery using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Service by Service UUID sub-procedure. Fast connection parameters and procedures for connection establishment are recommended to enhance Service Discovery speeds.

The Report Host shall perform primary service discovery using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Service by Service UUID sub-procedure. Fast connection parameters and procedures for connection establishment are recommended to enhance Service Discovery speeds.

If the Report Host supports an ATT_MTU larger than the default ATT_MTU, then the Report Host shall use the GATT Exchange MTU sub-procedure prior to performing service discovery.

As required by GATT, the Report Host must be tolerant of additional optional characteristics of services used with this profile and used outside of this profile.

The Report Map characteristic shall return the HID Report Descriptor when read.

The HID Report Descriptor is defined in the USB HID specification [1].

The Report Host shall read all characteristic descriptors of the Report Map characteristic to allow the Report Host to map information within the Report Map characteristic to external service characteristics used to transfer data described by the information between the Report Host and HID Device.

The Report characteristic is used to transfer HID Service data between the Report Host and the HID Device.

The Report Host shall enable notifications, via the Client Characteristic Configuration descriptor, of the Report characteristic for all instances of the Report characteristic where the Report Type as defined in the Report Reference characteristic descriptor refers to an Input Report.

The Boot Host shall ignore notifications of the Report characteristic.

The HID Control Point characteristic is a control-point characteristic as defined in Volume 3, Part F, Section 3.2.6 of [2]. The HID Control Point characteristic allows the Report Host to signal the HID Device that the Report host is entering or exiting a power saving mode known as Suspend Mode (see [8], §7.4.2).

The HID Information characteristic value contains the bcdHID and bcountryCode fields as defined by the USB HID specification [1].

When a system enters a low-power Suspend Mode, the RemoteWake flag shall be used to determine whether the Report Host includes the HID Device in the set of devices that can wake it up.

If the RemoteWake flag is FALSE, then the HID device does not consider itself remote wakeup-capable, and the Report Host can exclude the HID Device from the set of devices that can wake the Report Host up.

When a Report Host is exiting a low power Suspend Mode, the NormallyConnectable flag shall be used to determine whether the Report Host can connect to the HID Device before any user interaction occurs on the HID device. This may be used to improve the perceived responsiveness of the system.

The Protocol Mode characteristic allows reading and writing of the protocol mode of the HID Service and to set the desired protocol mode.

The Boot Host shall write to the Protocol Mode characteristic for each HID Service on the GATT Server and set the characteristic value to the defined value for Boot Protocol Mode following connection establishment. There are no requirements on a Report Host to use the Protocol Mode characteristic.

The Boot Keyboard Input Report characteristic is used to transfer HID Service data representing keyboard keystrokes between a HID Service corresponding to a HID Device operating in Boot Protocol Mode as a keyboard and a Boot Host.

If the Boot Host supports the Boot Keyboard Input Report characteristic, then it shall enable notifications of the Boot Keyboard Input Report characteristic using the Client Characteristic Configuration descriptor.

The Report Host shall ignore notifications of the Boot Keyboard Input Report characteristic.

The Boot Keyboard Output Report characteristic is used to transfer HID Service data representing the status of LED’s visible to the user between a HID Service corresponding to a HID Device operating in Boot Protocol Mode as a keyboard and a Boot Host.

The Boot Mouse Input Report characteristic is used to transfer HID Service data representing pointer coordinates between a HID Service corresponding to a HID Device operating in Boot Protocol Mode as a mouse and a Boot Host.

If the Boot Host supports the Boot Mouse Input Report characteristic, then it shall enable notifications of the Boot Mouse Input Report characteristic using the Client Characteristic Configuration descriptor.

The Report Host shall ignore notifications of the Boot Mouse Input Report characteristic.

The Battery Level characteristic may either be read by the HID Host or be enabled for notification using the Client Characteristic Configuration Descriptor by the HID Host. The HID Host should minimize the frequency of reads of the Battery Level characteristic value to avoid significant impact on the battery life of the HID Device. The HID Host may use the information returned in a read response or a notification of the Battery Level characteristic value to display the battery level of the HID Device.

The PnP ID characteristic value shall be read by the Report Host upon initial connection establishment and may be cached afterwards. The PnP ID characteristic value may be read by the Boot Host upon initial connection establishment and may be cached afterwards.

The HID Host can use the information returned in the PnP ID characteristic value to find representative icons or load associated support software.

The Boot Host and Report Host shall share bonding information and information regarding «Service changed» indications. If a bond is deleted from a Report Host, then the bonding information shall be removed from the Boot Host. If a bond is deleted from a Boot Host, then the bonding information shall be removed from the Report Host.

If a «Service changed» indication is received by the Report Host when connected to the HID Device, then the Report Host shall make the Boot Host aware of the «Service changed» indication and any information contained therein. If a «Service changed» indication is received by the Boot Host when connected to the HID Device, then the Boot Host shall make the Report Host aware of the «Service changed» indication and any information contained therein.

The LE HID Operation Mode characteristic is used to switch the operation mode between Default Operation mode and Hybrid Operation mode at the application layer. For a Report Host that supports the HID ISO feature, the client requirements in Section 5.2 are mandatory.

Section 5.3, Section 5.4, Section 5.5, and Section 5.6 establish additional requirements for a HID Host that supports the HID ISO feature.

Section 7 establishes additional requirements for a HID Host to be able to support the HID SCI feature.

A HID Host that supports the HID SCI feature shall discover the support for HID SCI in the HID Device by reading the HID Information characteristic.

A HID Host may configure a Flush Timeout on LE ACL for Output Reports. Flush operation only applies to HID Output Reports marked as flushable. For further information, see Volume 3, Part G, Section 5.2.2 of [2].

The term “report interval” refers to the nominal time difference between the opportunities to transmit reports created at either the HID Device (Input report) or HID Host (Output report).

For HID Reports sent over LE Isochronous channels in Hybrid Operation mode, the SDU interval is the same value as the report interval.

End-to-end latency for an input report is the time from when a human action is performed on the HID Device until the action is detected by an application on the HID Host.

End-to-end latency for an output report is the time from when an application on the HID Host sends a message to an actuator in the HID Device until the effect of the message reaches the user.

Both report interval and end-to-end latency can be important for the user experience.

The report interval is set by the HID Host selecting an SDU interval supported by both the HID Device and HID Host. The HID Host should choose the minimum report interval that is supported by both devices.

The selected SDU interval will limit the minimum end-to-end latency.

The end-to-end delay is also influenced by several other factors, such as sample acquisition, sample processing, buffering in the transmitting device, maximum spacing between transmit opportunities, buffering in the receiving device, and signaling between layers.

Link Layer parameters for the CIS will impact the average latency as well as the latency variance.

For optimal latency performance, when the report rate is less than 5 ms, the implementer will need to consider the detailed Link Layer timing for the CIS and ACL PDUs (see Appendix C.2 for an example). Section 5.3 describes the Link Layer behavior for optimal latency performance.

The LE HID Operation Mode characteristic is used to switch the operation mode between Default Operation mode and Hybrid Operation mode at the application layer.

When a connection between a HID Device and a HID Host is established, the initial operation mode shall be Default Operation mode, which uses only GATT for sending and receiving reports. In Hybrid Operation mode, the HID Report(s) identified by a command from the HID Host are sent over LE Isochronous Channels while other reports are sent over GATT. The procedures in Section 5.2.1 and Section 5.2.2 are designed to keep the HID Device and the HID Host in the same operation mode at any given time.

Figure 5.1 shows the simplified state diagram of the HID Device and HID Host operation modes.

Figure 5.1. Simplified operation mode state diagram

Section 5.2.1 and Section 5.2.2 describe how the HID Host can change the operation mode and how the HID Device may request an operation mode change. The sequence for changing the operation mode is explained in Appendix B.

The HID Host shall read the HID ISO Properties characteristic on each connection to discover the properties of the HID Device. The HID Host shall configure either an existing or a new Connected Isochronous Group (CIG). The HID Host shall create and configure a single CIS in the CIG to transfer ISO reports in Hybrid Operation mode. The CISes created for HID Devices that are also implementing the HID ISO feature and the CISes for other profiles can be created in the same CIG or in different CIGs. Note that combining CISes in a CIG constrains the link parameters of each CIS ([2] Volume 6, Part B, Section 4.5.14), and will limit which CISes that can be combined into one CIG.

The CIS for HID ISO data shall be configured with the SDU interval (parameters SDU_Interval_P_to_C and SDU_Interval_C_to_P when using HCI) set equal to one of the report intervals supported by the HID Device, as indicated by the Supported Report Intervals field of the HID ISO Properties characteristic.

The maximum SDU size for the Central to Peripheral direction (parameter Max_SDU_C_to_P when using HCI) shall be set to a value greater than or equal to the length of the longest Output Report enabled over ISO plus the overhead of the HID ISO protocol (3 octets). When the HID Host device is not constrained by other use cases, the maximum SDU size for the Central to Peripheral direction should be set to the value of the Max SDU Size for Output Reports field of the HID ISO Properties characteristic. When the maximum SDU size for the Central to Peripheral direction is set to a value less than the value of the Preferred SDU Size for Output Reports field of the HID ISO Properties characteristic, then the HID Device may have to reduce the robustness or reduce the effective report rate.

The maximum SDU size for the Peripheral to Central direction (parameter Max_SDU_P_to_C when using HCI) shall be set to a value greater than or equal to the length of the longest Input Report enabled over ISO plus the overhead of the HID ISO protocol (3 octets). When the HID Host device is not constrained by other use cases, the maximum SDU size for the Peripheral to Central direction should be set to the value of the Max SDU Size for Input Reports field of the HID ISO Properties characteristic. When the maximum SDU size for the Peripheral to Central direction is set to a value less than the value of the Preferred SDU Size for Input Reports field of the HID ISO Properties characteristic, then the HID Device may have to reduce the robustness or reduce the effective report rate.

To minimize latency contribution from the Link Layer protocols, the Controller in the HID Host should be configured to use an ISO subinterval less than or equal to the SDU interval when the SDU interval is less than the ISO interval and to send unframed SDUs.

Note that the HID Host must select a combination of SDU interval and SDU size that allows the Controller to schedule the Central to Peripheral PDU (MPT_C), the Peripheral to Central PDU (MPT_P), and the frame spacing (T_IFS and T_MSS) within one ISO subinterval. See Appendix C.2 for details on Link Layer timing.

To minimize latency contribution from the Bluetooth implementation, the Controller in both the HID Host and the HID Device should send an SDU received from its Host at the first available transmit opportunity (PDU).

To minimize latency contribution from the Bluetooth implementation, the Controller in both the HID Host and the HID Device should send an SDU received from its peer device to its Host as soon as the PDU carrying the SDU is received.

If the Controllers behave differently from what is described in the above two paragraphs, then the latency contribution from the Link Layer can be determined by the Transport Latency calculated by the Link Layer. The behavior described in the two paragraphs above does not affect the Controller’s calculation of Transport Latency as described in [2] Volume 6, Part G, Section 3.2.2. The Transport Latency calculated by the Controller is not used by the application layer for a CIS that carries HID ISO packets. Figure 5.2 shows an adaptation of Figure 3.2 in [2] Volume 6, Part G, Section 3.2.2 to illustrate the behavior described in the above two paragraphs. Figure 5.2 uses black color for semantics copied from [2] with FT=1. Figure 5.2 uses red color for semantics used to describe SDUs and PDUs with the SDU interval identical to the ISO subinterval. Figure 5.2 uses green color for semantics used to describe the optimal behavior for HID ISO.

Figure 5.2. HID ISO compared to Figure 3.2 in Volume 6, Part G, Section 3.2.2 in the Bluetooth Core Specification [2]

The Controller must follow the Bluetooth Core Specification requirements for ISOAL packet sequence numbers (see [2] Volume 6, Part G, Section 2), but the packet sequence number is not used for a CIS that carries HID ISO packets.

Note that an implementation of the HID ISO feature must synchronize generation of its data to the effective transport timing (i.e., the Host must send exactly one SDU, which can be empty, to the Controller each SDU interval) when using Unframed PDUs, see [2] Volume 6, Part G, Section 2.

Table 5.1 shows the requirements for report intervals.

Appendix C shows recommended ISO parameters for each report interval setting, and the range of Max_Transport_Latency that can be used to constrain a generic Controller to achieve those settings.

Zero or more HID ISO packets may be sent in a single SDU over LE Isochronous Channels. A HID ISO packet can contain either a HID report or a Confirmation. Each HID ISO packet that contains a HID report shall use the format defined in Table 5.2. Each HID ISO packet that contains a Confirmation shall use the format defined in Table 5.3.

If the Length field value is set to a value of 0, as shown in Table 5.3, then the packet is a Confirmation to the receipt of a report. The receiving device can use this Confirmation to stop sending reports with the same Sequence Number as the one contained in the Confirmation to save power.

The HID ISO Protocol is defined for transporting HID Reports over LE Isochronous Channels. This protocol provides the following capabilities:

A HID Host that supports the HID ISO feature shall support all the above capabilities.

The HID Device may support some of the above capabilities, and the HID Device shall indicate the support for Repetition (multiple reports per SDU) and Confirmation by setting the corresponding bits in the Additional Info subfield of the Hybrid Mode ISO Reports field of the HID ISO Properties characteristic.

When the HID Host is instructed to enter hybrid mode by a higher layer, the higher layer can include requirements or recommendations for using Repetition or Confirmation. The HID Host should enable Repetition and Confirmation when supported by the HID Device in accordance with the instructions from the higher layer. If there are no recommendations or requirements from the higher layer, then the HID Host should enable Repetitions and Confirmation if supported by the HID Device.

It is up to the implementer of the device transmitting each report to use these features to provide a level of reliability that is adequate for the type of data contained in the report. The following report types are defined to provide guidance on how these features should be used.

ABSOLUTE: The Absolute report type is intended for reports that are more “absolute” in nature. Such reports contain data that represent the current state of an input mechanism, independent of any previous reports to be interpreted by the receiving side. Such reports often remain the same from one transmission to the next. For example, a report containing the status of a momentary push button or the position of a 2-position switch can be interpreted without knowledge of the values of previous reports.

RELATIVE: The Relative report type is intended for reports that are more “relative” in nature. Such reports contain data that are taken together with the values of previous reports to determine or derive another value. For example, the X and Y delta reports for a mouse or other pointing device are summed with previous values to determine the current X and Y coordinates of an on-screen pointer. For such reports, the loss of any single report can have a negative impact on user experience. Because of the nature of Bluetooth transmissions, any single transmission has some probability of being lost because of interference or multipath effects. The frequency hopping mechanism provides frequency diversity; therefore, if a packet is lost on one frequency, then the next transmission will occur on a different frequency on the same link. The existing retransmission (ARQ) schemes used at the Link Layer of Bluetooth LE would introduce too much latency because the receiver must send a negative acknowledgment and the original transmitter must retransmit the lost transmission, as required by Volume 6, Part B, Section 4.5.9 in [2]. To avoid this latency, a simple report repetition scheme is defined.

Some reports can contain both types of data. For example, a mouse report may contain X and Y delta data, which are considered relative, but also buttons, which are absolute. Such reports should be treated as Relative reports.

Reports carrying mouse X and Y delta data should be treated as Relative reports, and repetition should be used when these are carried over the LE Isochronous Channels transport.

The Sequence Number is maintained independently for each Report ID that is enabled to use the LE Isochronous Channels transport.

Section 5.6.1 and Section 5.6.2 specify how the Sequence Number field should be generated for transmission and interpreted upon receipt.

The HID ISO Service does not depend on any other services.

The HID ISO Service defines the Attribute Protocol Application error codes listed in Table 6.1.

Requirements in this section represent a minimum set of requirements for a Server. Other GATT sub-procedures may be used if supported by both the Client and Server.

Table 6.2 summarizes additional GATT sub-procedure requirements beyond those required by all GATT Servers.

The HID ISO Service shall be instantiated as a «Primary Service».

Only one instance of the HID ISO Service shall be allowed on a Server.

The service UUID shall be set to «HID ISO Service» as defined in [7].

This section defines the characteristic requirements. Where a characteristic can be indicated, a Client Characteristic Configuration descriptor must be included in that characteristic as required by [2].

The characteristics defined in this section are using the conventions described in Section 2 of the GATT Specification Supplement [9].

Within this section, the term Transport parameters refers to all the parameters noted in Table 7.1.

Mode, in the context of HID SCI, refers to the ability of a device to adapt transport parameters to different uses and circumstances. Such could be the need to use lower power, default execution, enhanced robustness of the link, or the need for low latency.

Both Transport Interval and end-to-end latency are important for the user experience. Section 5.1 defines end-to-end latency for Input Report and for Output Report. Such end-to-end latency definitions also apply to HID SCI. The Report Interval and Transport Interval together contribute to the minimum end-to-end latency achievable.

The HID Host must select Transport Interval and other parameters as supported by both HID Host and HID Device through SCI negotiation. The HID Host must choose the most appropriate Transport Interval supported by both HID Host and HID Device, as well as by overall airtime allocation.

LE ACL scheduling can affect the performance of HID SCI.

The following section describes the connection life cycle using the HID SCI feature. The section details how the connection is created as well as reconnection and disconnection after no activity.

7.3.1. Initial connection

Figure 7.1 describes the HID SCI Discovery procedure. After a first-time connection, pair, and bond, the HID Host discovers the HID Service among other services, and continues to discover all the characteristics of the HID service, including those influencing the HID SCI behavior.

The GATT database should be cached for fast reconnection.

Figure 7.1. Example of initial discovery and configuration of SCI conveying information related to SCI (not all messages are shown)

7.3.1.1. Configuring HID SCI and activation

To properly configure and activate HID SCI, the following steps apply:

• The HID Host and the HID Device shall read the Rounded connInterval Values (RCVs) and Extended connInterval Values (ECVs) supported by the local controller (command HCI_LE_Read_Minimum_Supported_Connection_Interval when using HCI).

• The HID Host may read the HID Device HID SCI Information characteristic to determine the connection intervals supported by the HID Device for RCVs and ECVs (see Volume 6, Part B, Section 4.5.1 of [2]).

• The HID Host shall write the default connection parameters to the local controller (command HCI_LE_Set_Default_Rate_Parameters when using HCI).

• The HID Host shall configure the HID Device by writing the desired mode to the HID Control Point characteristic (see Section 7.4.1).

7.3.2. Additional message sequence charts

This section details a few more message sequence charts for multiple devices and rejection of negotiation.Figure 7.2 shows an example of two devices with the HID Control Point characteristic enabling two different HID SCI modes.

Figure 7.3 shows an example of HID Control Point characteristic usage with rejected changes.

Figure 7.2. Example of HID Control Point characteristic usage with multiple devices in different HID SCI modes (not all messages are shown)

Figure 7.3. Example of HID Control Point characteristic usage with rejected changes (not all messages are shown)

A connection between a HID Host and a HID Device using SCI can use any Transport Interval that is supported by the Shorter Connection Intervals of [2]. The Bluetooth Core Specification (Volume 6, Part B, Section 4.5.1 of [2]) defines the intervals as RCV and ECV. Table 7.2 shows the Transport Interval requirements for certain intervals that HID Hosts and HID Devices shall support.

The HID Host must choose a mode that is appropriate for the device.

The HID Host or the HID Device can, at any time, renegotiate or update the transport parameters of HID SCI. Renegotiating or updating HID SCI transport parameters may be needed due to different types of devices connecting and disconnecting.

The HID Device, which must be a Peripheral as per Section 2.4, shall be in the Bondable mode as defined in [2] Volume 3, Part C, Section 9.4.3.

HID Service characteristics shall require an encrypted link for reading, writing, and notification.

The HID Device should use the Peripheral Security Request, as defined in [2] Volume 3, Part H, Section 2.4.6, procedure to inform the HID Host of its security requirements.

All supported characteristics specified by the Device Information Service, Scan Parameters Service, and Battery Service should be set to the same LE Security Mode and the same Security Level as the characteristics in the HID Service.

The HID Host, which must be a Central as per Section 2.4, shall perform the Bonding procedure with the HID Device, as defined in [2] Volume 3, Part C, Section 9.4.4.

The HID Host should encrypt the link as early as possible after reconnection.

The HID Host shall only initiate an encryption key refresh on receipt of a Peripheral Security Request, as defined in [2] Volume 3, Part H, Section 2.4.6, from the HID Device.