Feedback

Services and characteristics

As discussed in previous topics, the ATT layer defines attributes and how data is exposed between a client and a server. As such, one of the main functions of GATT is the hierarchal structuring of attributes stored in a GATT server into standardized entities (services and characteristics) providing seamless interoperability between different Bluetooth LE devices.

Attributes

The ATT layer defines how data is stored and accessed in a server’s database. The data is stored in the form of data structures called Attributes. Attributes are the core data units that both the ATT and GATT layers are based on. Attributes hold user data as well as metadata describing the attribute itself, its type, security permissions, etc. Data exchange occurring between ATT servers and clients, or, GATT servers and clients, is in the form of attributes. When discussing only attributes, they are said to be stored in an ATT server. Whereas, as we will see further in this lesson, when we start classifying attributes into services and characteristics, we refer to that data structure as a GATT server.

An attribute consists of 4 blocks of data:

Data stored in an ATT server as attributes

Handle: A 16-bit unique index to a specific attribute in the attribute table, assigned by the stack. An attribute is addressed via its handle. You can think of it as the row number in the attribute table, although handles are not necessarily sequential.
Type (UUID): Universally unique ID (UUID), which tells us the attribute type. For example, if this attribute declares a characteristic, this will be reflected in its Type field as it will hold a UUID used specifically to indicate declaring a characteristic.
Permissions: The security level required (encryption and/or authorization) to handle that attribute, in addition to indicating whether it’s a readable and/or writeable attribute.
Value:
- The actual user data (ex: sensor reading) that is stored in the attribute. This field accepts any data type. It can hold a heart rate monitor value (beats per minute), a temperature reading, or even a string.
- It can also hold information (metadata) about another attribute, as we will see later in this lesson.

Universally unique ID (UUID)

A UUID is an abbreviation you will see a lot in the Bluetooth LE world. It is a unique number used to identify attributes and tells us about their significance. UUIDs have two types.

The first type is the SIG-defined 16-bit UUID. For example, the SIG-defined Heart rate service has the UUID 0x180D and one of its enclosed characteristics, the Heart Rate Measurement characteristic, has the UUID 0x2A37. The 16-bit UUID is energy and memory efficient, but since it only provides a relatively limited number of unique IDs, there is a need for more UUID to cover all vendors, users, and use cases.

The second type is a 128-bit UUID, sometimes referred to as a vendor-specific UUID. This is the type of UUID you need to use when you are making your own custom services and characteristics. It looks something like this: 4A98-xxxx-1CC4-E7C1-C757-F1267DD021E8 and is called the “base UUID”. The four x’s represent a field where you will insert your own 16-bit IDs for your custom services and characteristics and use them just like a predefined UUID. This way you can store the base UUID once in memory, forget about it, and work with 16-bit IDs as normal.

Services

Let’s start by examining what constitutes a service and how attributes are hierarchically structured in a given service. As shown in the below figure, attributes are the main building blocks for services. A service definition (commonly referred to as a service) is comprised of multiple attributes arranged in a GATT-specified format which facilitates standardized data exchange between Bluetooth LE devices.

Attributes forming a service with two characteristics

Service declaration attribute

Service definitions always start with a service declaration attribute. This attribute holds metadata about the service, it also indicates the beginning of a service in the sequence of services stored on a GATT server.

The Handle is similar to a row number by which the attribute is addressed. The service declaration attribute’s Type field holds the UUID (0x2800) which is a unique SIG-defined UUID used only to indicate the beginning of a service.

The Permissions field here indicates “read only” and no authentication needed. This is expected in a service declaration attribute as there is no reason to have a write-permission for it, it only declares the beginning of a service.

Lastly, the Value field holds the UUID of the service being declared. For example, the Heart Rate Service is a SIG-defined service and is referred to by the UUID 0x180D which is stored in the Value field of the Heart Rate Service-Service declaration attribute.

Characteristics

Subsequently, a service can have zero or more characteristic definitions (commonly referred to as characteristics). A characteristic is comprised of at least two attributes and optionally more.

Similar to a service definition, a characteristic definition starts with a declaration attribute, to indicate the beginning of a characteristic in the sequence of characteristics in a service definition. This is followed by the characteristic value attribute which holds the actual user data. Optionally, a characteristic can also have one or more characteristic descriptor attributes.

Characteristic declaration attribute: Holds metadata about the Characteristic Value Attribute.
Characteristic value attribute: Holds the actual user data.
Characteristic descriptor attribute (optional): Holds more metadata about the characteristic.

Characteristic declaration attribute

A characteristic definition starts with a characteristic declaration attribute, to indicate the beginning of a characteristic in the sequence of characteristics in a service definition. The characteristic declaration attribute’s Type field holds the UUID (0x2803) used only to declare a characteristic. The declaration attribute has read-only Permissions, ensuring that clients can read the value but not write to it.

The Value field holds important information about the characteristic being declared, specifically three separate fields:

Characteristic properties: What kind of GATT operations are permitted on this characteristic.
Characteristic value handle: The handle (address) of the attribute that contains the user data (value), i.e the characteristic value attribute.
Characteristic UUID: The UUID of the characteristic being declared.

Characteristic value attribute

After the attribute declaring the characteristic comes the characteristic value attribute. This is where the actual user data is stored. Its Handle and Type are the ones referred to in the Characteristic Declaration Attribute Value field. Naturally, its Value field is where the actual user data is stored. The Permissions field indicates whether the client can read and/or write to this attribute.

Characteristic descriptors

The characteristic descriptor attributes are optional. They hold additional metadata about the characteristic, giving the client more information about the nature of the characteristic. There are several kinds of descriptors, but they are generally divided into two categories, GATT-defined and custom.

Descriptors also allow the client to set permissions for certain server-initiated GATT operations. In this course, we will focus on the the GATT-defined Client Characteristic Configuration Descriptor (CCCD) as it is the most commonly used.

Client characteristic configuration descriptor (CCCD)

The Client characteristic configuration descriptor (CCCD) is a specific type of characteristic descriptor that is necessary when the characteristic supports server-initiated operations (i.e Notify and Indicate). This is a writable descriptor that allows the GATT client to enable and disable notifications or indications for that characteristic. The GATT client can subscribe to the characteristic that it wishes to receive updates about, by enabling either Indications or Notifications in the CCCD of that specific characteristic.

For example, in the Heart Rate Service, there is a characteristic called the Heart Rate Measurement. The GATT client (your mobile phone for instance) can use the CCCD of this characteristic to receive updates about this characteristic. So it subscribes to the Heart Rate Measurement characteristic by enabling either Indications or Notifications in the CCCD of said characteristic. This means the GATT server (most likely a heart rate sensor device) will push these measurements to your phone, without your phone having to poll for these measurements.

The CCCD attribute’s format is as pictured below. The UUID for CCCDs is 0x2902. A CCCD must always be readable and writable. Descriptors with the Type CCCD only have 2 bits in their Value field. The first bit signals whether Notifications are enabled, and the second bit is for Indications.

Client characteristic configuration descriptor

We will take a closer look at how to do this in exercise 2 of this lesson.

Nordic Developer Academy Terms of Service

1. Introduction

‍These terms and conditions (“Terms of Use”) apply to the use of the Nordic Developer Academy, provided by Nordic Semiconductor ASA, org. nr. 966 011 726, a public limited liability company registered in Norway (“Nordic Semiconductor”). ‍

Nordic Developer Academy allows the user to take technical courses related to Nordic Semiconductor products, software and services, and obtain a certificate certifying completion of these courses. By completing the registration process for the Nordic Developer Academy, you are agreeing to be bound by these Terms of Use.

These Terms of Use are applicable as long as you have a user account giving you access to Nordic Developer Academy.‍

‍2. Access to and use of Nordic Developer Academy

‍‍Upon acceptance of these Terms of Use you are granted a non-exclusive right of access to, and use of Nordic Developer Academy, as it is provided to you at any time. Nordic Semiconductor provides Nordic Developer Academy to you free of charge, subject to the provisions of these Terms of Use and the Nordic Developer Academy Privacy Policy.

To access select features of Nordic Developer Academy, you need to create a user account. You are solely responsible for the security associated with your user account, including always keeping your login details safe.

You will able to receive an electronic certificate from Nordic Developer Academy upon completion of courses. By issuing you such a certificate, Nordic Semiconductor certifies that you have completed the applicable course, but does not provide any further warrants or endorsements for any particular skills or professional qualifications.

Nordic Semiconductor will continuously develop Nordic Developer Academy with new features and functionality, but reserves the right to remove or alter any existing functions without notice.

‍3. Acceptable use

You undertake that you will use Nordic Developer Academy in accordance with applicable law and regulations, and in accordance with these Terms of Use.‍ You must not modify, adapt, or hack Nordic Developer Academy or modify another website so as to falsely imply that it is associated with Nordic Developer Academy, Nordic Semiconductor, or any other Nordic Semiconductor product, software or service.

You agree not to reproduce, duplicate, copy, sell, resell or in any other way exploit any portion of Nordic Developer Academy, use of Nordic Developer Academy, or access to Nordic Developer Academy without the express written permission by Nordic Semiconductor. You must not upload, post, host, or transmit unsolicited email, SMS, or \”spam\” messages.

You are responsible for ensuring that the information you post and the content you share does not;

contain false, misleading or otherwise erroneous information
infringe someone else’s copyrights or other intellectual property rights
contain sensitive personal data or
contain information that might be received as offensive or insulting.
Such information may be removed without prior notice.

‍Nordic Semiconductor reserves the right to at any time determine whether a use of Nordic Developer Academy is in violation of its requirements for acceptable use.

Violation of the at any time applicable requirements for acceptable use may result in termination of your account. We will take reasonable steps to notify you and state the reason for termination in such cases.

‍4. Routines for planned maintenance

‍Certain types of maintenance may imply a stop or reduction in availability of Nordic Developer Academy. Nordic Semiconductor does not warrant any level of service availability but will provide its best effort to limit the impact of any planned maintenance on the availability of Nordic Developer Academy.

5. Intellectual property rights

‍Nordic Semiconductor retains all rights to all elements of Nordic Developer Academy. This includes, but is not limited to, the concept, design, trademarks, know-how, trade secrets, copyrights and all other intellectual property rights.

Nordic Semiconductor receives all rights to all content uploaded or created in Nordic Developer Academy. You do not receive any license or usage rights to Nordic Developer Academy beyond what is explicitly stated in this Agreement.

‍6. Liability and damages

‍Nothing within these Terms of Use is intended to limit your statutory data privacy rights as a data subject, as described in the Nordic Developer Academy Privacy Policy. ‍You acknowledge that errors might occur from time to time and waive any right to claim for compensation as a result of errors in Nordic Developer Academy. When an error occurs, you shall notify Nordic Semiconductor of the error and provide a description of the error situation.

You agree to indemnify Nordic Semiconductor for any loss, including indirect loss, arising out of or in connection with your use of Nordic Developer Academy or violations of these Terms of Use. ‍Nordic Semiconductor shall not be held liable for, and does not warrant that (i) Nordic Developer Academy will meet your specific requirements, (ii) Nordic Developer Academy will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of Nordic Developer Academy will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through Nordic Developer Academy will meet your expectations, or that (v) any errors in Nordic Developer Academy will be corrected.

You accept that this is a service provided to you without any payment and hence you accept that Nordic Semiconductor will not be held responsible, or liable, for any breaches of these Terms of Use or any loss connected to your use of Nordic Developer Academy. Unless otherwise follows from mandatory law, Nordic Semiconductor will not accept any such responsibility or liability.

‍7. Change of terms

‍Nordic Semiconductor may update and change the Terms of Use from time to time. Nordic Semiconductor will seek to notify you about significant changes before such changes come into force and give you a possibility to evaluate the effects of proposed changes. Continued use of Nordic Developer Academy after any such changes shall constitute your acceptance of such changes. You can review the current version of the Terms of Use at any time at https://academy.nordicsemi.com/terms-of-service/

‍8. Transfer of rights

‍Nordic Semiconductor is entitled to transfer its rights and obligation pursuant to these Terms of Use to a third party as part of a merger or acquisition process, or as a result of other organizational changes.

‍9. Third Party Services

‍‍To the extent Nordic Developer Academy facilitates access to services provided by a third party, you agree to comply with the terms governing such third party services. Nordic Semiconductor shall not be held liable for any errors, omissions, inaccuracies, etc. related to such third party services.

‍10. Dispute resolution

‍‍The Terms of Use and any other legally binding agreement between yourself and Nordic Semiconductor shall be subject to Norwegian law and Norwegian courts’ exclusive jurisdiction.