|
|
The Human Interface Device Profile Specification
defines the protocols, procedures, and features that shall be used by
Bluetooth Human Interface Devices, such as keyboards, pointing devices,
gaming devices, and remote monitoring devices. This specification uses the
USB (Universal Serial Bus)
definition of Human Interface Device (HID) in order to leverage the
existing class drivers for USB HID devices.
This document describes how to use the USB Human
Interface Device (HID) class devices over a Bluetooth wireless link. The
HID class consists primarily of devices that are used by humans to control
the operation of computer systems. Typical examples of HID class devices
include:
-
Keyboards and pointing devices; for example, standard mouse
devices, trackballs, and joysticks
-
Front-panel controls; for example, knobs, switches, buttons, and
sliders
-
Controls that might be found on devices such as telephones, VCR
remote controls, games or simulation devices; for example, data
gloves, throttles, steering wheels, and rudder pedals
-
Devices that may not require human interaction but provide data in
a similar format to HID class devices; for example, bar-code readers,
thermometers, or voltmeters
For more details : Download the HID Profile from the Bluetooth.org
website.
1.1 Overview
Here we will examine a single USB device class, HID
(Human Interface Device), a powerful and extensible data reporting system
that was designed specifically for the needs of Human Interface Devices. HID
is not specific to USB or any other type of physical data transport.
It is the intention of this profile to describe how to use the HID protocol
over the Bluetooth wireless communications system, allowing manufacturers
of input devices to produce high performance, interoperable, and secure
wireless input devices.
Information about a HID device is stored in segments
of its ROM (read-only memory). These segments are called descriptors. An
interface descriptor can identify a device as belonging to one of a finite
number of classes. The HID class is the primary focus of this
document. Other types of device classes described by USB specifications
include display, audio, communication, and data storage. A HID class
device uses a corresponding HID class driver to retrieve and route
all data. The routing and retrieval of data is accomplished by examining
the descriptors of the device and the data it provides.
Image reprinted from Bluetooth HID Profile, Page 19
The HID class device descriptor identifies which
other HID class descriptors are present and indicates their sizes;
for example, Report and Physical Descriptors. A Report descriptor
describes each piece of data that the device generates and what the data
is actually measuring. For example, a Report descriptor defines
items that describe a position or button state.Physical descriptor sets
are optional descriptors that provide information about the part or parts
of the human body used to activate the controls on a device.
Image reprinted from Bluetooth HID Profile, Figure 2
Above is an illustration of the software layers that
reside in both the host and the human interface device for an example
implementation. In this example, the host is a personal computer and has
the upper layers of the Bluetooth software running on its native processor
and is connected to a Bluetooth radio module via a transport bus such as
USB. The HID in this example has its firmware embedded with the radio
firmware, running on the same CPU, for the lowest possible cost
implementation. Other implementations on the HID side are possible and
equally valid.
The following roles are defined for devices that
comply with this profile:
-
The HID (Human Interface Device) is the device providing the
service of human data input and output to and from the host. Because
the USB definition of HID includes all devices that report data in a
similar fashion to HIDs, other devices such as remote sensors are
included which may not interface directly with a human. Examples of
HIDs are mice, joysticks, gamepads, keyboards, and also voltmeters and
temperature sensors. The HID is normally the slave in the Bluetooth
piconet structure.
-
The host is the device using or requesting the services of a
Human Interface Device. Examples would be a personal computer,
handheld computer, gaming console, industrial machine, or data
-recording device. The host is normally the master in the Bluetooth
piconet structure.
Following are some brief descriptions of how people
might use Bluetooth Human Interface Devices.
There are 4 scenarios that are covered in this
profile:
-
Desktop Computing Scenario: In the traditional desktop
computer scenario, use of Bluetooth wireless computer peripherals
will free the desktop from multiple cables and allow input devices
to be operated further from the desktop and in positions that are
more comfortable. Users will be able to switch between multiple
input devices without plugging and unplugging cables. Users will
also be able to control different computers or host devices with at
different times with a single Bluetooth HID device without concern
for connecting cables.
-
Living Room Scenario: HID devices with Bluetooth wireless
technology will enable the ease of multiplayer gaming. The users are
no longer tethered to the gaming machine and can be seated casually
within a standard sized living room. Bluetooth devices will not
require line of sight alignment with the receiver and the two-way
capability allows remote displays and user feedback devices.
-
Conference Room Scenario: A pointing device enabled with
Bluetooth wireless technology will allow the presenter in a
conference room to control the presentation on a video screen from
up to 10 meters away, without the need to be near the host or the
projection device. The device need not be designed for operation on
a flat surface.
-
Remote Monitoring Scenario: Battery powered monitoring
devices with Bluetooth wireless technology will provide many
benefits to the end user. Some examples of these devices include
temperature sensors, remote thermostats, security devices, pressure
sensors, voltmeters, etc. By using Bluetooth wireless technology and
the HID standard, monitoring systems can be installed quickly
without running new wires to each of the installed sensors. The low
power modes provided by Bluetooth wireless technology will provide
long battery life for the remote transmitters.
Potential HID devices enabled with Bluetooth
wireless technology include:
-
Computer keyboards and keypads
-
Trackballs, mice, and other pointing devices
-
Game controllers (gamepads, joysticks, steering wheels, etc.)
-
Battery operated sensors (temperature, pressure, security, etc.)
-
Simple alphanumeric remote displays
-
Universal remote controls
-
Bar code scanners
This is a brief outline of Bluetooth requirements
detailed by this specification:
-
Master/Slave roles. Although there are no mandated
master/slave roles, it is recommended that Bluetooth Human Interface
Devices normally be a slave device, in order to avoid having the host
radio multiplex between piconets.
-
Discoverability. It is recommended that all Human Interface
Devices use limited discoverable mode only, since devices are normally
used in a 1:1 relationship with a host. Once the device address is
known by the main host, there is no need to allow further discovery of
its address unless the user specifically allows it for a brief period.
-
Authentication/bonding/encryption. This profile requires
support for authentication and encryption for keyboards, keypads, and
other HIDs that transmit sensitive information. This is due to the
extraordinary sensitivity of the information that commonly travels
from these devices (usernames, passwords, emails, passkeys). It is
optional for other types of HIDs.
-
Configuration. Bluetooth HIDs should be easy for consumers
to configure out of the box. This profile will give examples of
systematic configuration of Bluetooth peripherals.
-
Performance. Bluetooth HIDs should have responsiveness
(latency) similar to wired USB input devices, and provide superior
performance to most other types of proprietary wireless input devices.
-
Battery life. Bluetooth HIDs should fully utilize the power
saving mechanisms provided by the Bluetooth Specification, such as
Park, Hold, and Sniff modes, to achieve battery life comparable with
existing wireless human input devices.
-
Host software. The host will typically implement the HID
profile by writing an interface driver (sometimes called a miniport
driver on a PC host) between a standard HID class driver and the
Bluetooth L2CAP and Link Manager layers.
If conformance to this profile is claimed, all
capabilities indicated mandatory for this profile shall be supported in
the specified manner (process-mandatory). This also applies to all
optional and conditional capabilities for which support is indicated.
A dedicated configuration pushbutton or other simple
user action should be used to initiate configuration of the human input
device, placing it in limited discoverable mode for 30-180 seconds. The
host should prompt the user to press the configuration button, and then
discover the device’s address automatically. No more actions by the user
should be required, unless the device implements security procedures and
requires a manual passkey entry from the host or device.
Once the Bluetooth connection is established and the
HID descriptors have been passed to the HID class driver on the host, the
device will function like a wired USB HID device.
The essential performance requirement is that
Bluetooth Human Interface Devices provide responsiveness to changes in
input that are equivalent to wired devices. High performance applications,
such as gaming, require application response time from a user button press
or joystick movement on the order of a single video frame (16.7 ms at 60
Hz refresh). The implementation of the Bluetooth link should add no more
than 5 ms additional latency between the user input and the application
response over a wired implementation when the Bluetooth HID is in the
active state.
The goal for common HID devices (mice, keyboards,
gamepads) is to achieve at least three months of operation with three
standard AAA or two AA alkaline batteries. The host shall not be required
to actively power manage the HID device, with the possible exception of
notifying the HID devices when its power state changes. The HID is
responsible for its power management.
Bluetooth HIDs shall set no limitation on the number
of devices per host (up to the seven simultaneous active devices allowed
per piconet). All trusted devices (devices that have either been
authenticated or have no security procedures required) shall be allowed to
have simultaneous connections to the host, if the host so desires. For
example, multiple Bluetooth mice and keyboards are allowed. The behaviour
in this case shall be the same as for the USB case; i.e., input from all
devices is allowed and the data streams are logically OR’ed together.
Similarly, a single Bluetooth HID may have
established a bond or have its address known by multiple hosts. However,
if it has declared itself virtually cabled, it is mandatory that the
device only support a single host connection, and only one control and one
interrupt L2CAP channel to that host, at one time. If the device has not
declared itself virtually cabled, it is still recommended that the device
only support a single host connection at one time, i.e. no more than one
SDP, control, and interrupt channel may be open at a time. A Bluetooth HID
that implements the Virtual Cable feature shall have sufficient resources
to remember a minimum of two hosts, and four hosts is recommended, to make
later reconnection easier without passkey entry.
Bluetooth security measures, such as authentication,
bonding, and encryption, are optional in all Bluetooth HIDs except
keyboards and keypads. . Similarly, hosts or host applications that can
potentially receive sensitive information from a Bluetooth keyboard or
keypad should request a secure connection. This is to ensure that users
are not confused by the availability of both secure and non-secure
Bluetooth keyboards, and provides a clear value-added security benefit to
Bluetooth keyboards over existing wireless keyboards on the market. It is
normally the responsibility of the host to initiate security procedures.
Both the host and the HID shall provide a means of
unbonding if they provide a means of bonding. It shall also be possible to
unbond a device with or without the presence of the other party, in order
to resolve an erroneous bonding situation.
-
Link Loss : When a "virtually cabled" Bluetooth HID
goes out of range and back in range, up to a maximum timeout period,
the link shall be automatically re-established by the host if SDP
attribute HIDReconnectInitiate is false and by the HID if
HIDReconnectInitiate is true.
-
Pairing or Bonding Refused by HID : If a HID refuses
pairing, the host shall display a comprehensible error message to the
user.
-
Connection Refused by HID : If a HID refuses a connection
with a host, when possible the host shall display a comprehensible
error message to the user, preferably with a list of possible causes
(such as a connection with another host is already active).
The interoperability requirements for an entity that
is compatible with the AVRCP are completely contained in this chapter. The
requirements directly relate to the application layer features.
- Generic HID Compilance :PC host applications should be
developed to work with a HID device independently of the
communications bus that connects them. PC HID applications should
adhere to the standard HID client rules for the particular platform
and operating system in question.
-
Fixed Format Reporting : Other resource-limited host
applications which implement HID may choose to implement only the Boot
Protocol, which is the minimum required level of host functionality.
-
Rules for Minimum Level of Host Compatibility : To ensure a
base level of interoperability between Bluetooth HID hosts and
devices, Bluetooth HID hosts that support any type of keyboard
functionality shall support the keyboard boot protocol. Hosts that
support any type of pointing device functionality shall support the
pointing device boot protocol.
-
HID Class Driver Interface to Bluetooth Stack : Hosts with
existing support for the HID protocol running over USB shall supply an
adapter driver, which generates and decodes the necessary packet
header and L2CAP requests for running the HID protocol over a
Bluetooth data channel. The host adapter driver shall provide the
means for applications to establish and terminate HID protocol
connections to a Bluetooth Human Interface Device.
-
L2CAP HID Protocol Support : The implementation of L2CAP on
the host should meet the default minimum MTU (maximum transmission
unit) of 48 bytes , although the default value of 672 is recommended.
The host BT-HID adapter driver should implement packet segmentation
and reassembly up to the largest practical size (64k bytes maximum) in
order to maintain compatibility with all possible Bluetooth HIDs, but
this is not required for hosts which support only Boot Protocol mode.
-
SDP Support in Host : The host is required to implement an
SDP client.
-
QoS (Quality of Service) Requirements : The HID protocol was
first implemented on the Universal Serial Bus. USB provides hardware
that can guarantee maximum data latency to and from HIDs by means of
the interrupt pipes. Although Bluetooth 1.1 contains support for
synchronous channels (SCO links) with guaranteed latency, these are
intended for voice, and all other traffic is placed on the ACL
channel. The ACL channel and its higher-level abstractions do not
contain hardware mechanisms for prioritizing one L2CAP data channel
over another, so any Quality of Service requests at the L2CAP
connection layer must be handled by L2CAP or lower layer software. Due
to implementation reasons L2CAP QoS may not be implemented in
many versions of the software stack. However, it is required for HID
hosts to implement the L2CAP QoS interface and be able to perform QoS
negotiation with devices. Supporting the interface will eventually
allow improved performance for first generation Human Interface
Devices when the underlying QoS system is put into place in future
radios.
-
Use of L2CAP Channel Identifiers (CIDs) : In the case of
multifunction Human Interface Devices (such as keyboard with
integrated pointing device), the HID protocol itself allows
distinguishing the origin or destination of the data by means of
Report IDs. Thus, different CIDs are not needed for each function in a
multifunction device.
-
Authentication, Pairing, Bonding : Support for
authentication, pairing, and bonding routines in hosts and
applications of Bluetooth Human Interface Devices is optional,
although authentication is strongly encouraged and encryption is
recommended for host application programs requiring users to enter
sensitive information on a Bluetooth keyboard or keypad. It is
normally the responsibility of the host to initiate security
procedures, however HIDs are optionally allowed to initiate
authentication (after initial pairing, initiated by the host, has been
completed) to prevent host spoofing. Hosts shall by default try the
zero PIN code first (0x00, one byte) when requesting authentication to
a HID. If the device has not been preprogrammed to a zero PIN, the
authentication will fail, at which time the host can prompt the user
for the non-zero device PIN code.
-
Special Considerations for Keyboards and Keypads : Pairing
with Bluetooth keyboards and keypads requires passkey entry on a host
that may not have a wired keyboard or other alternate method of entry
for the passkey. In this case, it is recommended that the host
generate a random passkey code that can be displayed to the user for
entry into the Bluetooth keyboard or keypad. A keyboard may be
identified without performing Service Discovery by using the specific
Class of Device bits that are returned in the FHS packet when the
keyboard responds to an Inquiry command. The host may sort device
responses based on this field.
-
Hosts with Limited Input Capability : In the case where
pairing with a new Bluetooth keyboard is required and there are no
other means of responding to prompts for proceeding with the pairing
procedure, a non-secure connection may be established for purposes of
prompting the host to begin the pairing process. In this case, the
host or host application shall ensure that keyboard operation cannot
continue without performing the pairing process.
-
Use of Encryption : Encryption is strongly recommended for
host applications that allow entry of sensitive information such as
user names and passwords through a Bluetooth keyboard or keypad. All
Bluetooth keyboards and keypads shall support any encryption key size,
8 to 128 bits, requested by an application. It is always the
responsibility of the host to initiate the encryption procedure.
-
Connection Handling Rules : See Section 5.4.5 of the HID
Profile, to see the connection handling rules covering the following
areas:
-
HID Protocol Connection Establishment
-
Reconnection After Host Reset
-
Page Mode Support
-
Page Scan Mode Support
-
Termination and Re-Establishment of Connection
-
Failed Reconnection
-
Packet Types
-
Support of Low Power Link Modes
-
Inquiry Scan
-
BIOS Requirements for Boot Device Support : In order to
provide complete Bluetooth keyboard and pointing device functionality
in a PC-based host, keyboard or mouse control is often needed before
the operating system is loaded, for low -level system configuration.
In order for Bluetooth keyboards and mice to function like wired
keyboards, the PC BIOS must contain firmware that understands how to
communicate to keyboards and pointing devices over a Bluetooth radio.
If security is an issue, pairing and authentication procedures must
also be performed by the BIOS, and the resultant key shared with the
operating system. Bluetooth HID pointing devices and keyboards are
required to support boot protocol mode.
-
Keyboard Auto-Repeat Functionality : When in the boot
protocol mode (entered with the SET_PROTOCOL command), Bluetooth HID
keyboards and keypads provide auto key repeat functionality
internally, like USB HID keyboards. When in full HID protocol mode,
auto-repeat functionality is provided in the host. However, it should
be noted that link loss after a key down event might generate
unintended keystrokes until the link timeout occurs.
Bluetooth Human Interface Devices shall meet the
following requirements of the Bluetooth Specification. In addition to the
requirements listed below, all devices claiming conformance to this
profile shall meet the requirements of the Generic Access Profile
specification.
Bluetooth Interface Devices are providers of a
service to a host, that service being to provide input from a human to an
application program running on the host. Multiple HIDs are typically
connected to a single host; for example, a mouse, a keyboard, and a
joystick. For this reason, Bluetooth HIDs should normally be implemented
as slaves in the Bluetooth link protocol. If HIDs were masters, each
additional HID master using the host radio as its slave would create an
additional piconet (by definition), with corresponding reductions in
bandwidth efficiency due to inter-piconet packet collisions and timing
uncertainties at the host radio.
Human interface devices shall be implemented as limited
discoverable devices. HIDs are normally associated with a single host or a
fixed number of hosts that are used with and bonded with a particular HID.
For reasons of security, a Bluetooth HID device should not allow its
address to be discovered at all times by any unknown or unauthorized (and
possibly untrustworthy) Bluetooth device. Once a HID has established a
bond with the main host that primarily uses its services, it shall not by
default allow other hosts to discover its address and attempt to make a
connection with it.
Bluetooth Human interface devices that are
implemented as slaves indicate their connectibility (whether they are in
page scan mode or not) by the state of the SDP attribute
HIDNormallyConnectable. If this attribute is True, the device shall stay
in Page Scan mode when no active connection is present. If this attribute
is false, they may shut down completely when no active connection is
present. If the host cannot contact the HID during the initialization
sequence, and if the SDP attribute HIDReconnectInitiate is set to TRUE,
HIDs are permitted to page the host and perform a master/slave switch to
restore the connection. This will help avoid creating the situation where
the host is constantly paging devices that have gone out of range
(possibly forever) and using up bandwidth in the piconet. However,
designers must be aware that it may take several seconds to re -establish
the connection, depending on the page and page scan modes used, and the
presence of any audio (SCO) connections. The resultant latency may be
annoying to the user.
The term virtual cable is used to indicate
that the HID has a 1:1 association with a particular host. It is useful to
use this term as an adjunct to the Bluetooth terms pairing and bonding.
Pairing is the process of creating a trusted relationship between two
devices, which can be either a transient or semi-permanent relationship.
If the resultant authentication keys generated from the pairing process
are stored for later re-use, a semi-permanent relationship is established,
and the devices are then bonded. However, this says nothing in particular
about when devices should try to establish a connection with each other,
and what should happen when an established connection is lost for an
unknown reason (interference, out of range, dead batteries, etc).
Typically a human interface device is a personal
device that is used with one host at a time. When a cabled HID is
plugged into a host by a user, the user creates both a "bond"
between the devices and a 1:1 relationship. To use the device with another
host, the cable must be manually unplugged and plugged into another host.
User intervention is required for this.
-
Adding Virtually-Cabled Devices : Section 6.4.1 of the HID
Profile gives an example of the sequence of events that a host and
device will execute to initiate a "plug" operation with a
virtual connection. These examples assume a Connect button
exists on the HID that can be used to manage plugging and unplugging.
-
Removing Virtually-Cabled Devices : Section 6.4.2 of the HID
Profile gives an example of the sequence of events that a host and
device will execute to initiate an "unplug" operation with a
virtual connection. Other implementations are possible.
Since in the great majority of cases the Bluetooth
HID devices will be battery powered, the goal is to implement Bluetooth
HIDs with battery life comparable to competing input devices with
proprietary wireless technologies. Although Bluetooth is at a distinct
disadvantage in terms of power due to its relative complexity and twoway
design, there are features available for power savings that can
substantially reduce the power used by the receiver.
-
Bluetooth HID Power Management Philosophy : In general,
Bluetooth HID devices shall be responsible for their own power
management. The host shall not be required to manage the various power
states of the device. This would require knowledge of the features and
usage model of every specific HID which is connected, which is
contrary to the idea of HID; that is, to use a one class driver for a
wide variety of Human Interface Devices. However, the host may notify
the HID of power state changes in the system (e.g., standby, suspend)
which the HID may choose to respond to. See section 6.5.1 of the HID
Profile for more information regarding the following power
optimisation cases:
-
Use of Bluetooth Low Power Modes
-
Use of HOLD Mode
- Use of PARK Mode
- Use of SNIFF Mode
- UNSNIFF and UNPARK Response Issues
- Host Changing of SNIFF and PARK Parameters
- Example Power State Diagram for Bluetooth HID
-
Minimum Duty Cycle in Suspend Mode
-
Behaviour when Host Connection Lost
The general requirement for Bluetooth HIDs is that
they have actual and user-perceived performance that is equal to wired
devices. By performance, we mean response time (latency) and throughput
(bandwidth). Because of the relatively high bandwidth of the radio and
most possible host radio connections (with the exception of RS-232), equal
or higher performance than low-speed USB devices should be achievable.
- Requirements for Gaming and Pointing Devices: See section
6.6.2 of the HID Profile for details regarding the following
requirements for Gaming/Pointing devices.
- Input Latency
- Output Latency
- Report Rate
- Requirements for Other HIDs : See section 6.6.3 of the HID
Profile for latency/report rate requirements for the following
devices:
- Remote Monitoring Devices
- Remote Control
- Other HIDs
Table 2 in the HID Profile gives a Latency table to
assist designers in accounting for all the latencies through a system with
a Bluetooth Human Interface Device.
- Pairing, Bonding, and Authentication for HIDs : The use of
Bluetooth pairing, bonding, and authentication procedures in all HIDs
except keyboards and keypads is optional and is up to the device
manufacturer to determine. The lowest cost devices may wish to not
support these procedures to reduce the cost associated with
non-volatile storage for link keys. It is normally the responsibility
of the host to initiate security procedures , however all HIDs may
optionally authenticate the host, after the host-initiated pairing
procedures are completed. See section 6.7.1 for the following security
requirements:
-
Mandatory Requirements for HIDs
- Recommended Requirements for HIDs
- Recommended Link Key Types
- Recommended Non-Volatile Storage for Host Keys
- Behavior when Key Storage Capacity Exceeded
- Behavior when Key Storage is Lost on a Device
- Special Keyboard and Keypad Considerations
-
Mandatory Requirements for Keyboard and Keypads
-
Import/Export Restrictions for Encryption Products
-
Optional Requirements for Other HIDs
-
Multiple Host Connections : Virtually-cabled Bluetooth HIDs
are only allowed to support a single ACL connection with a single host
at any given time. This is desirable from both the HID’s limited
resource perspective, for reasons of security, and for consistency
with the virtual cable concept.
-
Remote as Slave with System Controller : In a system of
devices with one master controller that is not the remote control, the
remote should operate as a slave. One such example would be a PC as
piconet master controlling several devices and a remote control
operating as one of the slaves, or an A/V home theater receiver as the
master controller in a system with the Bluetooth remote as a slave
device.
-
Remote as Piconet Master :For a universal remote control
device that is implemented with the HID protocol, it is advantageous
from a battery life standpoint to only request a connection when there
is button activity, transfer the data, and dissolve the connection. In
this case, the remote control must be the master of the piconet in
order to initiate the connection. This method of operation is
desirable because of the very small amount of information and the very
small duty cycle of operation relative to other types of HIDs makes it
very inefficient to operate as a slave (and be constantly polled). The
slave devices shall be in a page scan mode that is consistent with the
response times desired.
Image reprinted from Bluetooth HID Profile, Figure 5
The Bluetooth HID (BT-HID) Profile defines the
over-the-air interface for HID devices, which use the Bluetooth RF
interface standard to communicate with a host system. In this document
there are several assumptions about the layout of the system software
stacks on both the device and the host; however, actual implementations
may vary as long as they fully support the over-the-air interface defined
in this profile.
The Bluetooth HID protocol defines a set of services
that can be used between a host capable of supporting HID devices and a
BT-HID device. This profile mandates the need for one or more L2CAP
channels for conducting transmission of both control and data packets. The
BT-HID Header differentiates packet types in a channel.
The communication flow requirements of BT-HID devices
depend on the target application. An L2CAP channel represents each
communication flow. A local endpoint on the BT-HID device and a buffer on
the host terminate L2CAP channels. Information associated with the L2CAP
channel is used to identify the respective BTHID channel. Channel IDs
(CIDs) identify the BT-HID channels.
A BT-HID host shall open two channels: Control and
Interrupt. Separate PSMs are used to distinguish the two channels. The
Control channel is always set to th e Best Effort service
type. Low latency data is carried on the Interrupt channel, so the service
type will normally be set to Guaranteed to ensure Quality of
Service. However, if a device does not declare any Input or Output
reports, then the Interrupt channel may be set to the No Traffic Service
type in the respective direction.
-
Feature Reports : Feature reports assume a Best Effort
latency requirement. They can carry application-specific data and
initialization information that is not time-critical. For instance, a
device may use Feature reports to adjust coordinate scaling
parameters, enable device options, or determine current device state.
Feature reports must be carried on the Control channel. BT-HID devices
shall support one Control channel and that channel is always tied to
the HID Control PSM.
-
Input Reports : Input reports provide low latency delivery
of asynchronous information from the device to the host. For in
stance, a mouse would use Input reports to send changes in position to
the host. All traffic from the device to the host on an Interrupt
channel consists of Input reports.
-
Output Reports : Output reports provide low latency delivery
of information from the host to the device. For instance, a force
feedback gamepad would use Output reports to trigger force feedback
effects in the device. All traffic from the host to the device on an
Interrupt channel consists of Output reports. shows how the Input and
Output reports are routed over the low latency L2CAP Interrupt channel
and the bi-directional Feature reports are carried on the best effort
L2CAP Control channel. L2CAP route all reports of a single
baseband ACL channel. Note that the Interrupt channel carries Input
reports from the device to the Host, and Output reports from the Host
to the Device.
Image reprinted from Bluetooth HID Profile, Figure 7
The figure above shows how the Input and Output
reports are routed over the low latency L2CAP Interrupt channel and
the bi-directional Feature reports are carried on the best effort L2CAP Control
channel. L2CAP route all reports of a single baseband ACL channel. Note
that the Interrupt channel carries Input reports from the device to the
Host, and Output reports from the Host to the Device.
Below is a simplified version of the BT stack as it
relates to a HID device.
Image reprinted from Bluetooth HID Profile,
page 54
The host side provides a mini-driver to translate
between the HID and Bluetooth stacks. On the Device side, a generic HID
Services module provides the services required by any BT-HID
implementation. The HID Services module communicates over the L2CAP
interfaces and provides the Bluetooth functionality such as
authentication, flow control, packetization of the HID commands.
-
Boot Mode Operation : Boot mode was originally defined by
USB HID to simplify the design of PC BIOSs; however, it has proved
useful for a variety of products with small, embedded operating
systems. When a HID device is in Boot mode, a HID parser and SDP
client is not required in the host system. HID devices can support two
protocols: Report and Boot. Report protocol is the default mode for
all HID devices. The Report protocol requires that a host support a
HID parser to interpret the Report Descriptor stored in the SDP
information. Boot Protocol is currently only defined for keyboards and
mice. When in Boot Protocol, a HID parser is not required because
fixed Report Descriptors defined in the HID Specification identify the
reports generated by the respective devices. Boot Protocol simplifies
a BIOS (or embedded application) design by eliminating the need for a
HID parser, but it limits the functionality of a keyboard to a basic
103-key PCAT layout and a mouse to a simple 3 button, 2-axis design.
-
Channel Initialization : A host or device shall always open
both the control and interrupt channels. The Interrupt channel may be
open but idle if there are no Input or Output reports declared in the
Report Descriptor. A host or device shall establish the control
channel first, then the interrupt channel. Note that
"establish" means that an L2CA_ConnectCfm response has been
received for the channels L2CAP_ConnectReq. Channel configuration may
overlap, however the configuration of both channels shall be complete
before sending any data. A host or device shall always complete the
disconnection of the interrupt channel before disconnecting the
control channel. L2CAP configuration stage should be short because
BT-HID is designed with small CPUs in mind, i.e. keyboards, mice, and
joysticks. Most BT-HID devices will only try a couple configuration
settings before going to a "no-QoS" setting.
All messages between a HID device and a host are
preceded by a BT-HID Transaction Header (THdr). The Transaction Header is
divided into two fields: the Transaction Type and a Parameter. The
Transaction Parameter is Transaction Type dependent.
The Transaction Header (THdr) Types are described
below. Transactions consist of a request payload to the device followed by
data or a handshake payload from the device. Requests can get report data
(GET_REPORT), set report data (SET_REPORT), identify the current protocol
(GET_PROTOCOL), change the current protocol (SET_PROTOCOL), identify the
current Idle rate (GET_IDLE), or change the current Idle rate
(SET_IDLE).See section 7.4 of the HID Profile for details on the following
codes/transaction types:
- HANDSHAKE
- HID_CONTROL
- GET_REPORT
- SET_REPORT
- GET_PROTOCOL
- SET_PROTOCOL
- GET_IDLE
- SET_IDLE
- DATA
- DATC
- Payload : The figure below illustrates how payloads are
translated between the data defined by the HID Specification
(top layer) and the baseband Bluetooth packets (bottom layer). A
BT-HID device adds a header (also called the BT-HID Header, Hdr) to
the HID payload. Hdr is always 1 byte long; however, one or more bytes
of non-data items may immediately follow it. L2CAP adds another layer
of encapsulation, defined by the Bluetooth Specification. If the
resulting payload is too large to fit in a single baseband packet, the
L2CAP layer will segment the payload into smaller blocks before
transmission or assemble segmented received packets into an L2CAP
packet.
Image reprinted from Bluetooth HID Profile,
Figure 10
-
MTU : HID devices and Hosts shall support a Maximum
Transmission Unit (MTU) equal or greater than the minimum value of 48
bytes 1, although it is recommended that HID hosts provide support for
the default MTU of 672 bytes.
-
Report Data : It is recommended that data reports be
designed to fit within the negotiated L2CAP negotiated MTU size.
If a report defined by a device is larger than the
negotiated MTU, then the HID device shall implement segmentation and
reassembly (SAR) of up to MTU-sized data payloads. HID hosts are required
to support SAR for payloads greater than the negotiated MTU in size. The
HID drivers need to implement SAR on top of L2CAP since HID packet report
sizes can be as large as 64K bytes, and a small memory constrained host
may need to handle HID packets larger than the L2CAP MTU. The key
difference is that the HID segmentation and reassembly does not have the
concept of an MTU and therefore does not require the host or device to
have an amount of RAM equal to the largest possible packet size. The large
packets must be assembled or decoded on the fly in this case.
For segmentation the HID SAR module shall divide
data into segments less than or equal to the L2CAP layer’s negotiated
MTU limit, before sending them to the L2CAP layer.For reassembly if the
L2CAP payload received by the HID SAR module equals the channel’s MTU
for that direction, for a SET_ request or DATA packet, it will append all
subsequent DATC packet payloads. . When all segments are assembled, the
payload will be passed to the upper software levels as a single large data
object.
Flow control is not supported by the BT-HID profile. Most
HID devices do not require explicit flow control support. If flow control
is required, a vendor should use the L2CAP flow control mechanism when it
is standardized.
Section 8.3 of the HID profile defines the L2CAP Configure
Request parameter values that are recommended for a BT-HID device. For the
Control channel, the default Bluetooth "Best Effort" QoS is
assumed. If an Interrupt channel is opened, then the device can define its
QoS requirements with the InFlow parameter of the L2CA_ConfigReq
primitive. see Table 17 for a list of the QoS Parameters.
-
Control Channel : Most control channel transfers have two
phases: a request by the host and a response by the device. Only one
host control channel request shall be outstanding at a time. The
exception to this rule is that a device may spontaneously send a
HID_CONTROL packet that specifies VIRTUAL_CABLE_UNPLUG event. See
section 7.9.1 for more information on Control Channel transfers,
including Timeout, Control Channel GET_ , Control Channel SET_ &
Virtual Cable Unplug.
-
Interrupt Channel : The Interrupt Channel carries
asynchronous, low-latency data. DATA and DATC packets are the only
packet types transmitted or received on the Interrupt channel.See
section 7.9.2 for more information on Interrupt Channel transfers,
including Timeout, Interrupt IN , Interrupt OUT.
A HID device returns the following list of
attributes in an SDP_ServiceAttributeResponse:
-
HIDProfileVersion
-
HIDDeviceReleaseNumber
-
HIDParserVersion
-
HIDDeviceSubclass
-
HIDCountryCode
-
HIDVirtualCable
-
HIDReconnectInitiate
-
HIDSDPDisable
-
HIDBatteryPower
-
HIDRemoteWake
-
HIDSupervisionTimeout
-
HIDNormallyConnectable
-
HIDBootDevice
To retrieve the service records in support of this
profile, the SDP client entity in the host device connects and interacts
with the SDP server entity in the HID via the SDP and L2CAP procedures
presented in Sections 5 and 6 of the SDAP
Profile. In accordance with SDAP (Service Discovery Application Profile),
DevA plays the role of the host, while DevB plays the role of the Human
Interface Device.
Bluetooth Human Interface Devices shall implement a
minimal Bluetooth SDP server, with one exception. Declaration of the
LanguageBaseAttributeIDList attribute is required in all HID
implementations.
This is an example for a mouse with the following
database description. The mouse has the following features:
-
Provides strings for only one language, English
-
Provides Service Name, Service Description, and Provider Name
Strings
-
Supports the Boot mode protocol
-
Reports mouse coordinates every 10 ms.
-
Supports Virtual Connections
-
Will initiate a reconnection if a connection is lost
-
Supports 3 buttons and 2 axes
-
Battery powered
-
Considers itself a "Remote Wakeup" device
-
Generates a single 3 -byte Input report
See section 7.14 of the HID Profile more details of
the following SDP transaction:
-
Example 1: ServiceSearchRequest
- Example 2: Service Attribute Transaction
- Example 3: ServiceSearchAttributeTransaction
Assume for this example that the device is an ATM
with a HID interface that defines 5 strings in 3 languages: English,
German, and Italian. The first two strings are the Service Name and the
Provider Name. The next 3 strings are "HID strings", referenced
in the HID Report Descriptor. Each HID string uses a string index defined
in the Report Descriptor as the offset from the language attribute ID
"base" in the LanguageBaseAttributeIDList. This example device
has 3 strings associated with dedicated buttons: "Cancel
Transaction", "Another Transaction", and "Accept
Transaction".
See section 7.15 of the HID Profile for an excerpt of the Service
Record for the device.
Section 7.16 of the HID Profile gives examples of
the L2CAP Configuration Request parameters that would be specified for a
-
Mouse
-
Keyboard
-
Force-Feedback Joystick
Since a connectionless channel type is not used with
this profile, broadcast packets are disallowed.
The HID’s L2CAP implementation shall support a
minimum MTU (Maximum Transmission Unit) of 48 bytes, as required by the
Bluetooth Specification. Bluetooth has specified the "default"
MTU size as 672 bytes; however, due to the extreme memory resource
constraints faced by Human Interface Devices it is expected that most HIDs
will not support an MTU size this large. Hosts, however, are recommended
to support an MTU of at least 672 bytes.
It is recommended that the L2CAP Flush timeout
parameter be set to 0xFFFF (infinite) until problems with this function in
the L2CAP protocol are addressed in a future revision of the Bluetooth
core specification.
For high performance gaming and pointing devices
intended for use in a multiple slave piconet, it is recommended to
negotiate guaranteed service using the L2CA_ConfigReq command, with
parameters as recommended in Section 7.16 of the HID Profile to ensure the
connection latency standards are met.
In order for hosts to be compatible with all
Bluetooth HIDs, they shall implement the mandatory link manager commands
specified in the Table 31 of the HID Profile. Likewise, in order to
support any potential host, all Bluetooth HIDs shall implement the
mandatory commands specified in the table.
Table 32 of the HID Profile provides a list of the
Link Control layer procedures that are required for host and device. This
includes support for various packet types, inquiry modes, and paging
modes.
Bluetooth Human Interface Devices shall implement a
minimal Bluetooth SDP server, with one exception. Declaration of the
LanguageBaseAttributeIDList attribute is required in all HID
implementations. Note that this must match the HIDLANGIDBaseList described
in Section 7.11.8 of the HID Profile
For SDP Service Record Requirements, see Section
7.10 of the HID Profile
Image reprinted from Bluetooth HID Profile,
Table 33
Note, the above text contains excerpts from the Bluetooth SIG's
Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth
Specification.
|
