Attribute and Data Hierarchy

Generic Attribute Profile (GATT) establishes a hierarchy to organize attributes. They are organized as a GATT Server Profile and are grouped into:



A collection of data and associated behaviors to accomplish a particular function is called the Service Definition (i.e. a collection of characteristic attributes). Primary services are discovered by a GATT Client via a "GATT Primary Service Discovery Procedure".

Services are classified as Public or Private

  • Public
    • Defined by the Bluetooth SIG (16-bit UUID)
  • Private
    • Vendor-defined (128-bit UUID)


As depicted above, characteristics are essentially containers for user data. They contain a minimum of two attributes:

  • Characteristic Declaration Attribute
    • Metadata for the Value Attribute
  • Characteristic Value Attribute
    • Contains the data value itself

Declaration attribute permissions are always set to "Read with No Encryption" so as to be always discoverable by a client.

A Characteristic can optionally contain Descriptor Attributes, described below.

Characteristic Descriptors

These are special attributes used to further expand the metadata contained in the Declaration Attribute. Common Descriptor Attributes defined by GATT include:

  • Extended Properties
    • Contains additional declaration property bits
  • Characteristic User Description
    • Contains a user-readable description for the characteristic in which it is placed
  • Client Characteristic Configuration Descriptor (CCCD)
    • A switch, enabling/disabling server-initiated updates

Client Characteristic Configuration Descriptor (CCCD)

This is a very commonly used descriptor.

The client-server nature of GATT data communications has a drawback, in that the client must typically poll for updates of a characteristic on a server.

The CCCD provides a mechanism to enable server-initiated updates where the server can asynchronously push updated characteristic values to the client without the client having to poll for it.

There are two types of server-initiated updates:

  • Notifications (client doesn't acknowledge receipt of the update)
  • Indications (client does acknowledge receipt of the update; the server cannot send further indications until received)

The Client must enable this server-Initiated update mechanism by writing to the corresponding CCCD before the server can start sending them.


The Declaration, Value, and Descriptor Attribute Types have pre-defined UUIDS provided by the Bluetooth SIG. The following links provide useful resources (see GATT Heart Rate Service below).

GATT Profile Example

The following diagram depicts the GATT Heart Rate Service.



  • Service contains eight attribute data structures.
  • Service contains three characteristics.
  • "Heart Rate Measurement" characteristic contains three attributes, including a Descriptor Attribute (CCCD Type), set for Notifications.
    • This is a server-initiated update characteristic - the value will be sent to the client whenever the value attribute is updated.

GATT Profile Example (BM70)

Server profiles are created and depicted in vendor-specific ways. For example, the following depicts the GATT Heart Rate Service being incorporated into the BM70 radio via the BLEDK3 UI Configuration Utility:


Note that the Attribute Handle values are automatically assigned by this tool (starting at 0x8000).

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.