Hardware Reference
In-Depth Information
Profile or vendor-defined descriptors
Regardless of whether a profile is specified and published by the SIG or by a par‐
ticular vendor, these descriptors can contain all types of data, including additional
information regarding the characteristic value, such as the encoding used to acquire
the value from a sensor or any other particulars that complement the reading itself.
The following sections describe some of the most commonly used descriptors defined
by GATT.
Extended Properties Descriptor
This descriptor, when present, simply contains the two additional property bits, covered
in
“Characteristic declaration attribute” on page 59
and listed in
Table 4-6
.
Characteristic User Description Descriptor
As the name implies, this descriptor contains a user-readable description for the char‐
acteristic within which it is placed. This is a UTF-8 string that could read, for example,
“Temperature in the living room.”
Client Characteristic Configuration Descriptor
This descriptor type (often abbreviated CCCD) is without a doubt the most important
and commonly used, and it is essential for the operation of most of the profiles and use
cases. Its function is simple: it acts as a switch, enabling or disabling server-initiated
updates (covered in more detail in
“Server-Initiated Updates” on page 72
), but only for
the characteristic in which it finds itself enclosed.
Why Provide a Notification Switch?
As discussed earlier, a client knows nothing in advance about a server's attributes, so it
will need to perform discovery to find out which services, characteristics, and descrip‐
tors are present on the server. The server sends server-initiated updates (handle value
notifications and handle value indications, introduced in
“ATT operations” on page
26
) asynchronously whenever a characteristic's value changes, formatted in a packet that
only contains an attribute handle and an array of bytes with the value.
If the client has not yet discovered all characteristic and descriptor handles on the server,
it might not yet be able to associate the data received in those notifications and indica‐
tions with a particular type, rendering those over-the-air transactions useless. Further‐
more, even when a client can identify all handles with their corresponding services and
characteristics, there might be times (perhaps because the application is not visible,
perhaps because the client uses only one of many services and characteristics in the
server) when the client simply does not wish to receive updates. That is where CCCDs
