Hardware Reference
In-Depth Information
Name discovery procedure
Advertising packets can carry many different types of user data, including the
Device
Name
: a UTF-8 string containing a human-readable description of the device (sim‐
ilar to a network hostname). But space in the advertising packet is at a premium,
so sometimes devices might not choose to include the Device Name. For such cases,
the name discovery procedure allows a peripheral or central to retrieve the Device
Name over an established connection by using a GATT transaction.
Connection parameter update procedure
Each connection establishment requires a set of connection parameters that are set
unilaterally by the central. These parameters are the key factors in the balance be‐
tween throughput and power consumption for a connection (as described in
“Con‐
nections” on page 22
) and can be modified later in a connection to adapt to changing
balance requirements. The central is always responsible for physically modifying
the connection parameters and can do so at any time without warning, but the
peripheral also has the ability to
request
the central for a change to a specific desired
set of connection parameters. After doing so, the central can opt to deny the request
or to honor it. However, even if it does decide to change the connection parameters,
they might not be the exact ones requested by the peripheral, but rather whatever
the central considers reasonable and closest to the requested set.
Terminate connection procedure
This procedure is self explanatory and completely symmetrical: both the peripheral
and the central can terminate the connection at any time, while providing a
rea‐
son
code that the peer application will receive along with the disconnection event.
Although this concludes the general GAP modes and procedures portion of this chapter,
“Security”
introduces specific modes and procedures exclusive to the subject of security.
Security
Security is built into the core of the Bluetooth Low Energy wireless technology. Since
the introduction of BLE in the Bluetooth 4.0 core specification, the secure transmission
of user data has been a primary design goal, and version 4.1 builds upon the strong
foundations of its predecessor and tightens those principles even further.
As introduced in
“Security Manager (SM)” on page 28
, the enforcement of security and
privacy in BLE is based on two pillars:
Security Manager (and its protocol)
The Security Manager implements the actual cryptographic algorithms and pro‐
tocol exchanges that allow two devices to securely exchange data and privately
detect each other. This is typically implemented inside the protocol stack and uses
the available hardware acceleration modules to perform the required operations,