Characteristics are the lowest and the most important echelon of the Bluetooth Low Energy technology. Encapsulated by a related service, these are the actual state variables, each of which stores a single piece of relevant measurement and information data:

Just like services, these have a UUID, which can be 16-bit or 128-bit based, depending on whether a characteristic has a standard or custom definition. For example, the blood glucose measurement characteristic has a UUID of 0x2A35. Also, just like services, a manufacturer is free to define custom characteristics of only his/her software, but to facilitate maximum interoperability between Bluetooth Low Energy devices, it is always better to follow the definition of standard characteristics. Bluetooth SIG defines a list of standard Bluetooth Low Energy characteristics here.

It is worthwhile taking a look at the collection of characteristics exposed by the Blood Pressure Service.

Remember how we previously discussed that we can abstract Bluetooth Low Energy as an intelligent database. To build all that intelligence, characteristics bundle much more than a single value. Although the value is of prime importance, it is important to understand what makes this intelligent database magical.

Each characteristic as a whole comprises the following:

• Characteristic declaration: The characteristic declaration is an important part of a characteristic as it contains the UUID and properties of a characteristic. The properties of a characteristic are 8-bits lined together, which determine how the value of the characteristic can be used and how the descriptors can be accessed. You should already have seen the properties associated with each characteristic of the Blood Pressure Profile service by visiting the preceding link. We discuss the relevance of each of these properties as follows:
  • Read: If this bit is set, then it means that clients are allowed to read this characteristic's value.
  • Write: If this bit is set, then it means that clients are allowed to write (and receive a response) to this characteristic's value.
  • Write without response: If this bit is set, then it means that clients are allowed to write (without response) to this characteristic's value.
  • Signed Write: If this bit is set, then it means that clients are allowed to do a signed write to this characteristic's value.
  • Notify: One of the important ones. If set then the server will asynchronously notify the client whenever the value of the characteristic gets updated on the server. We will discuss this more in the next section. Also, if set, then the client configuration descriptor will exist. We shall discuss descriptors in detail shortly.
  • Indicate: Similar to notify, the only difference is that an indication requires an acknowledgement from the client. We will discuss this more in the next section. Also, if set, then the client configuration descriptor will exist. We shall discuss descriptors in detail shortly.
  • Write auxiliaries: If set, then the client can write to the characteristic user description descriptor.
  • Broadcast: If this bit is set, then it means that the value of this characteristic will be broadcasted, that is, placed in advertising packets.
  • Extended properties: Is set, then additional properties are defined in the characteristic extended properties descriptor, which also means that the characteristic extended properties descriptor shall exist. We shall discuss descriptors in detail shortly.

These properties are essentially the guidelines for how clients can interact with this characteristic and also, how they can subscribe (listen) to indications and/or notifications of this characteristic. We will see how the indications and notifications can be enabled in the next section.

• Characteristic Value: This is self-explanatory. You can already see how the measurement data is packaged for a blood pressure measurement characteristic at the link provided in the upcoming information box.

• Characteristic Descriptor: Each characteristic can be followed by one or more descriptors. Descriptors contain more information regarding a characteristic and its value. Just like services and characteristics (and you might have already guessed it here), these can either have a standard definition or a custom definition. To help clarify, we shall discuss some standard descriptors defined by GATT.

• Client Characteristic Configuration Descriptor (CCCD): This is one of the most important and most commonly used descriptors. This descriptor is used when you need to configure (enable/disable) indications or notifications for the characteristic. It is this descriptor that makes our so-called database so intelligent. By correctly configuring it for a characteristic, a client (possibly your app J) can expect to be dynamically notified whenever the characteristic updates its value on the GATT Server (a Bluetooth Low Energy sensor such as a blood pressure or a blood glucose meter). The blood pressure measurement characteristic includes a client characteristic configuration descriptor.

• Characteristic User Description Descriptor: As the name already suggests, this descriptor contains a human-readable string that describes the characteristic's value, which also can be directly presented to the user.

• Extended Properties Descriptor: If this is present, it contains information about extended properties.

Starting with Profiles, we finally covered the lowermost echelon of the Bluetooth Low Energy communication, the characteristic. We saw that it is not just as simple as reading and writing to/from a characteristic. We also touched upon the magic of indications and notifications upon which the whole Bluetooth Low Energy communication relies heavily and, hence, they deserve a topic of their own.