Bluetooth HID has its roots in another protocol altogether: USB. Before we all had Bluetooth keyboards and mice, engineers were trying to get a hold of the very messy reality that we were facing with no standardization amongst computer peripheral devices. From all the chaos came the human interface device protocol that provided a common language for all USB communication.
In this article, we will look at how this original HID spec has been extended for use with Bluetooth Low Energy (BLE). Let’s dive in!
A brief history of HID device communication
For many decades, humans have been working with electronic calculators to tackle complex tasks. One of the first riddles engineers had to solve was developing a means of communication to instruct the machines about the jobs requested and then receive feedback about the results from their metallic “friends.”
The first step in this process was the invention of input devices, the predecessors of what we now call keyboards, mice, joysticks, and pointing devices.
While the first solutions used a mixture of hardcoded (i.e., not customizable) and proprietary protocols in conjunction with dedicated ports (does PS/2 remind you of something? 😬), it soon became clear that there was a need for standardizing the way peripheral devices communicate with the central processing unit (the PC) operating systems. The list of devices that the average person was using every day was growing, and it simply wasn’t practical anymore to have proprietary protocols for each type of device on the market. Furthermore, there was a growing need for interoperability between devices from different manufacturers. Something had to change.
In the mid-90s, USB protocols and cables started to appear as they were set to become a universal bus able to connect any peripheral to a personal computer.
Within this environment, the USB SIG developed the revolutionary specification of HID (Human Interface Device) class USB devices, which is a generic framework that could allow input device manufacturers to develop their products ensuring interoperability within different hosts and, most of all, a plug-and-play user experience.
This was achieved thanks to the assumption that mainstream OSes already included support for HID and could recognize USB HID devices from the get-go without the need to install specialized device drivers. That has been a fundamental turning point for these types of consumer devices!
More recently, a wireless protocol (hint: it has some blue in its logo and name 😉) took hold thanks to the promise of delivering satisfactory performances while removing the hassle of physically connecting cables.
Bluetooth has been initially developed to stream audio to headsets and transfer files wirelessly with a PC. However, it became very soon clear that it could also help in getting rid of cables needed for input devices that had to be always connected to desktop computers in offices and at home, often resulting in an unaesthetic messy jungle of wires (say hello to the Bluetooth keyboard!).
With the advent of Bluetooth Low Energy around 12 years ago, it was necessary to implement the same protocol using the newer and more power-efficient standard; so here we are, describing the HID Profile for BLE, also called HID-over-GATT or the BLE HID profile!
💡Insider Tip: If you’re a professional Bluetooth developer, check out the Bluetooth Developer Academy, where you can unlock access to in-depth BLE development video courses + more!
Bluetooth Profiles
A Bluetooth Profile is a specification describing a particular use case of Bluetooth-based wireless communication between devices.
In order to use Bluetooth (Classic and Low Energy), a device must be compatible with the subset of device Profiles that implement its capabilities.
It is worth noting that BLE profiles don’t map to any part of a BLE stack implementation, in contrast to Services, Characteristics, Descriptors, GAP functionalities, etc.
They are instead just behavioral specifications covering common scenarios and including capabilities requirements/recommendations for the peer devices involved and security restrictions, if any.
For instance: the Heart Rate Profile includes the Heart Rate Service and Device Information Service. This means that a device streaming Heart Rate values will also need to expose information about the Manufacturer, its Serial Number, and more to be qualified as a Bluetooth Heart Rate sensor device.
HID-class devices compliant with the official BLE Profile make no exception: for instance, its Bluetooth HID Service requirements are listed in Table 3.1 of the specification:
The Importance of the Bluetooth HID Specification
HID has been developed to standardize communication: a Bluetooth HID Device and an HID Host device exchange data within a well-defined framework.
The specification is also extensible and versatile, covering a wide range of products.
This means that manufacturers can develop different kinds of devices, making sure that:
- Interoperability with any legit HID Host is preserved
- The performance of competitors’ HID Devices can be easily compared using generic Host drivers
- Any proprietary/device-specific information can still be transmitted using dedicated vendor-specific “pipes” (more on that later…)
- No matter the physical link used (USB, Bluetooth Classic, Bluetooth LE,…), the plug-and-play experience for the user is always preserved
BLE HID Profile components
The official Profile specification is downloadable here.
The document outlines the supported roles when establishing HID bi-directional communication over BLE:
- Bluetooth HID Device (pointing device, Bluetooth keyboard, game controller, …)
- Boot Host
- Report Host
The two kinds of Hosts differ in the way they’ll need to interpret the data received from the connected Devices: in Boot mode, no HID parser is needed, and a fixed data format is used, supporting keyboards and mice exclusively; if Report mode is instead enabled, the Host is required to decode payloads to interpret them correctly.
NOTE: Boot mode represents some sort of retro-compatibility feature with respect to the old-fashioned PS/2-based protocol, which supported only fixed data format from the Devices; it is also very useful if a Device needs to connect with a Host when no OS has booted, such as if only the BIOS is running.
As we already know, the mandatory Services to be implemented for Bluetooth HID Devices are HID, Battery, and Device Information (note: for DI, only a single instance is allowed!).
The Host shall instead support the Scan Client role of the Scan Parameters Profile, but given that Scan Parameters Service is optional for the Device, we’ll ignore this detail.
On the Device side, a set of recommendations on the configuration of each of the Services is described; for instance, the payload sent with Advertising packets should contain some specific information in order to enhance the user experience and ensure a prompt discovery by scanning Hosts in range.
The specification document also describes the GATT procedures that the Host will need to support to interact with the Device: for instance, the requirements for the Discovery of Services and Characteristics slightly differ between Boot and Report mode.
Some suggestions (aka the “should” terminology in the spec) or hard requirements (aka “shall” terminology) are also listed regarding the specific Device-Host interaction on the Characteristics themselves (e.g., the expected behavior of Battery Level) and on connection establishment procedures, being started by the Device or the Host.
This is where suggestions about Advertising and Scanning parameters are described.
If we reflect on this for a second, this is exactly what we expect from this specification: punctual and precise guidelines that help standardize the behavior of similar devices produced by different manufacturers but competing in the same market!
Last but not least, a few words on security: to be compliant, a Bluetooth LE HID Device shall protect all supported Characteristics with LE Security Mode 1, Level 2, or 3. This means encryption is mandatory for any kind of Characteristics interaction between peers.
Insights into the Bluetooth HID GATT Service
It should be clear by now that the Bluetooth HID GATT Service represents the backbone of the communication between compliant Hosts and Devices. If a device utilizes the HID GATT service, it can be referred to as a Bluetooth Low Energy-GATT-compliant HID device.
The specification has been modeled after the original USB HID approach but adapted to a different underlying protocol. Let’s start by listing out the main characteristics involved, as they are described in the official spec:
The first thing that catches the eye is that many of the characteristics within this Service are optional or at least configurable, which is exactly what makes it so flexible!
Now, before getting into the juicy details of the main characteristics, let’s spend a few words about the least important:
- The HID Information characteristic simply reports some static HID Device attributes related to the behavior of the Devices in some conditions (e.g., advertising if already bonded but not connected, …).
- The HID Control Point characteristic can be used by the Host device to flag that it is entering a particular state. At the time being, only Suspend and Exit Suspend are supported.
Protocol Mode: A Safety Switch
This characteristic is used to read or set the current mode of operation of HID Service.
Only two values are currently supported, as stated in the spec:
In practice, this means that:
- If the value is 0, Boot Procol Mode is active, and the Device will send and receive data through the Boot Input/Output characteristics (available for keyboards and mice only).
- If the value is 1, Report Protocol mode is active, and the Device will send and receive data via standard Input/Output reports characteristics.
- Upon each connection establishment, Protocol Mode is reset to the default (Report).
It is now evident why more than one operation mode exists: a less capable Host device can always force a basic level of communication to work using a fixed format, regardless of the complexity of the peer Device.
💡Insider Tip: Get exclusive access to step-by-step Bluetooth development courses as a Bluetooth Developer Academy member!
Reports: Input, Output, and Feature
Three different kinds of reports characteristics can be implemented:
- An Input Report is used to transmit data from the Device → Host direction.
- An Output Report is used to transmit data from the Host → Device direction.
- A Feature Report is used to set/get properties (configurations, states …) in both directions.
In a single Service implementation, multiple reports characteristics of each kind can be implemented. The number of reports present and their data format is regulated by the Report Map.
Report Map: the encoding/decoding trace
The Report Map characteristic plays a major role in the success of the Bluetooth HID protocol.
Its value is constant, and a single instance is allowed for a given Service implementation on the Device.
The Map is nothing but a single descriptor defining how the data prepared by the Device is packed into the Input Reports and how the data received from the Host, if any, is expected to be formatted into the Output Reports.
The format of the characteristic value is fully inherited by the USB HID Class specification, tracing the HID Descriptor.
As an example, have a look at a Report Map for a basic mouse:
static const uint8_t report_map[] = { 0x05, 0x01, /* Usage Page (Generic Desktop Ctrls) */ 0x09, 0x02, /* Usage (Mouse) */ 0xA1, 0x01, /* Collection (Application) */ 0x09, 0x01, /* Usage (Pointer) */ 0xA1, 0x00, /* Collection (Physical) */ // Define 3 buttons data format (1 bit for each button) 0x05, 0x09, /* Usage Page (Button) */ 0x19, 0x01, /* Usage Minimum (0x01) */ 0x29, 0x03, /* Usage Maximum (0x03) */ 0x15, 0x00, /* Logical Minimum (0) */ 0x25, 0x01, /* Logical Maximum (1) */ 0x95, 0x03, /* Report Count (3) */ 0x75, 0x01, /* Report Size (1) */ 0x81, 0x02, /* Input (Data,Var,Abs,No Wrap,Linear,...) */ // 5 bits padding needed after the 3 bits for buttons 0x95, 0x01, /* Report Count (1) */ 0x75, 0x05, /* Report Size (5) */ 0x81, 0x03, /* Input (Const,Var,Abs,No Wrap,Linear,...) */ // Define the motion sensor data format (8 bits for each axis) 0x05, 0x01, /* Usage Page (Generic Desktop Ctrls) */ 0x09, 0x30, /* Usage (X) */ 0x09, 0x31, /* Usage (Y) */ 0x15, 0x81, /* Logical Minimum (129) */ 0x25, 0x7F, /* Logical Maximum (127) */ 0x75, 0x08, /* Report Size (8) */ 0x95, 0x02, /* Report Count (2) */ 0x81, 0x06, /* Input (Data,Var,Rel,No Wrap,Linear,...) */ 0xC0, /* End Collection */ 0xC0, /* End Collection */ }; // With the above Report Map, the mouse input report sent over-the-air will // look like: struct mouse_report_t { uint8_t buttons; // Use only 3LSBits int8_t x; int8_t y; }
Snippet from hog.c (Zephyr RTOS source code – https://github.com/zephyrproject-rtos)
Useful tools
As we’ve seen, a significant portion of the HID Service specification is inherited from the USB HID Class, especially when it comes to en/decoding the Report Map characteristic.
Don’t worry if you are not familiar with that terminology!
Luckily, tools can automate generating or decoding a valid Map without you knowing all the quirks of the USB spec.
Usually, it’s a good idea to start with the working example of a descriptor and then gradually modify it according to your product needs.
Check out the tools below; all freely available online, that may come in handy along the way:
- HID Descriptor Tool
The official (and a bit dated…) USB HID tool that lets you edit, create and validate HID Report Descriptors. - USB Descriptor and Request Parser
An online tool that’s able to parse HID Descriptors, providing some insights about their structure. - Waratah
It is the newest of the tools I’ve found, directly maintained by Microsoft. It offers the use of a meta-language to easily design descriptors and generate the right blob in code – quite remarkable! 💡
Conclusion – Working with Bluetooth HID
While the roots of HID are in USB, today developers are making use of it to implement BLE device connections. And that’s exactly what we looked at in today’s article. If you’re ready to tackle a more hands-on Bluetooth HID project, head over to Bluetooth HID Device Design: Step-by-Step Example Project.
As you expand your knowledge of BLE HID, I recommend you bookmark this article along with these other helpful resources:
- Comprehensive Resources – The Bluetooth Developer Academy
- Blog Article – Bluetooth HID Device Design: Step-by-Step Example Project
- Official Spec – USB HID official specs
- Official Spec – BLE HID-over-GATT Profile spec
- Official Spec – BLE HID Service spec
💡 Want to get your Bluetooth-connected devices to market faster? Enroll in the Bluetooth Developer Academy today and get exclusive access to in-depth courses built for developers.
About the Author: Davide Pollarolo is an Embedded Software Engineer with extensive experience in designing & developing smart devices using Bluetooth Low Energy. He has an MSc in Computer Engineering and has worked in various domains, including robotics, sport & medical wearables, and computer peripherals. Davide is fascinated by Human-Computer Interaction and loves spending his free time snorkeling in the Mediterranean 🌊 or hiking in the Alps 🏔