Can A Ble Peripheral Be A Current Time Service Client>

Chapter four. GATT (Services and Characteristics)

The Generic Aspect Profile (GATT) establishes in detail how to commutation all profile and user data over a BLE connection. In dissimilarity with GAP (Affiliate three), which defines the depression-level interactions with devices, GATT deals only with actual data transfer procedures and formats.

GATT as well provides the reference framework for all GATT-based profiles (discussed in "SIG-defined GATT-based profiles"), which comprehend precise use cases and ensure interoperability between devices from different vendors. All standard BLE profiles are therefore based on GATT and must comply with it to operate correctly. This makes GATT a central section of the BLE specification, considering every unmarried detail of data relevant to applications and users must be formatted, packed, and sent co-ordinate to its rules.

GATT uses the Aspect Protocol (detailed in "Attribute Protocol (ATT)") equally its send protocol to substitution information between devices. This data is organized hierarchically in sections called services, which group conceptually related pieces of user data called characteristics. This determines many fundamental aspects of GATT discussed in this chapter.

Roles

Equally with whatever other protocol or profile in the Bluetooth specification, GATT starts past defining the roles that interacting devices tin can adopt:

Client: The GATT customer corresponds to the ATT client discussed in "Attribute Protocol (ATT)". It sends requests to a server and receives responses (and server-initiated updates) from it. The GATT customer does not know anything in advance about the server'southward attributes, so it must offset enquire nearly the presence and nature of those attributes by performing service discovery. After completing service discovery, information technology can then starting time reading and writing attributes found in the server, as well equally receiving server-initiated updates.
Server: The GATT server corresponds to the ATT server discussed in "Attribute Protocol (ATT)". It receives requests from a customer and sends responses back. Information technology also sends server-initiated updates when configured to do so, and it is the office responsible for storing and making the user data bachelor to the client, organized in attributes. Every BLE device sold must include at least a basic GATT server that tin can answer to client requests, even if only to render an error response.

It is worth mentioning again that GATT roles are both completely contained of GAP roles (see "Roles") and also concurrently uniform with each other. That ways that both a GAP primal and a GAP peripheral can human action as a GATT client or server, or even act equally both at the same fourth dimension.

UUIDs

A universally unique identifier (UUID) is a 128-scrap (16 bytes) number that is guaranteed (or has a high probability) to exist globally unique. UUIDs are used in many protocols and applications other than Bluetooth, and their format, usage, and generation is specified in ITU-T Rec. X.667, alternatively known as ISO/IEC 9834-8:2005.

For efficiency, and because xvi bytes would take a large clamper of the 27-byte data payload length of the Link Layer, the BLE specification adds two additional UUID formats: 16-chip and 32-scrap UUIDs. These shortened formats can be used only with UUIDs that are defined in the Bluetooth specification (i.e., that are listed by the Bluetooth SIG as standard Bluetooth UUIDs).

To reconstruct the full 128-bit UUID from the shortened version, insert the xvi- or 32-bit curt value (indicated by xxxxxxxx, including leading zeros) into the Bluetooth Base of operations UUID:

xxxxxxxx-0000-1000-8000-00805F9B34FB

The SIG provides (shortened) UUIDs for all the types, services, and profiles that it defines and specifies. Just if your application needs its ain, either because the ones offered past the SIG do not cover your requirements or because you want to implement a new employ case not previously considered in the contour specifications, you can generate them using the ITU's UUID generation page.

Shortening is not available for UUIDs that are non derived from the Bluetooth Base of operations UUID (ordinarily called vendor-specific UUIDs). In these cases, you lot'll demand to employ the full 128-fleck UUID value at all times.

Attributes

Attributes are the smallest data entity divers by GATT (and ATT). They are addressable pieces of data that can contain relevant user data (or metadata) nigh the structure and grouping of the different attributes contained inside the server. Both GATT and ATT can work only with attributes, so for clients and servers to collaborate, all information must exist organized in this class.

Conceptually, attributes are always located on the server and accessed (and potentially modified) by the client. The specification defines attributes only conceptually, and information technology does not forcefulness the ATT and GATT implementations to use a particular internal storage format or mechanism. Considering attributes incorporate both static definitions of invariable nature and also bodily user (frequently sensor) data that is bound to change chop-chop with time (equally discussed in "Attribute and Information Hierarchy"), attributes are usually stored in a mixture of nonvolatile memory and RAM.

Each and every attribute contains data near the attribute itself and then the bodily information, in the fields described in the post-obit sections.

Handle

The attribute handle is a unique 16-bit identifier for each attribute on a item GATT server. It is the part of each attribute that makes information technology addressable, and it is guaranteed not to change (with the caveats described in "Attribute Caching") between transactions or, for bonded devices, even across connections. Because value 0x0000 denotes an invalid handle, the corporeality of handles bachelor to every GATT server is 0xFFFF (65535), although in do, the number of attributes in a server is typically closer to a few dozen.

Note

Whenever used in the context of attribute handles, the term handle range refers to all attributes with handles contained between two given boundaries. For example, handle range 0x0100-0x010A would refer to whatever aspect with a handle between 0x0100 and 0x010A.

Within a GATT server, the growing values of handles determine the ordered sequence of attributes that a customer can access. Only gaps between handles are allowed, so a customer cannot rely on a contiguous sequence to judge the location of the side by side attribute. Instead, the customer must use the discovery feature ("Service and Characteristic Discovery") to obtain the handles of the attributes it is interested in.

Type

The attribute blazon is nothing other than a UUID (run across "UUIDs"). This can be a xvi-, 32-, or 128-bit UUID, taking up two, 4, or sixteen bytes, respectively. The blazon determines the kind of data nowadays in the value of the attribute, and mechanisms are available to discover attributes based exclusively on their type (see "Service and Characteristic Discovery").

Although the attribute type is ever a UUID, many kinds of UUIDs can be used to fill in the blazon. They can be standard UUIDs that determine the layout of the GATT server's aspect hierarchy (further discussed in "Attribute and Data Hierarchy"), such every bit the service or characteristic UUIDs, profile UUIDs that specify the kind of information independent in the aspect, such as Heart Rate Measurement or Temperature, and even proprietary, vendor-specific UUIDs, the meaning of which is assigned past the vendor and depends on the implementation.

Permissions

Permissions are metadata that specify which ATT operations (run into "ATT operations") tin can be executed on each particular attribute and with which specific security requirements.

ATT and GATT define the following permissions:

Access Permissions

Similar to file permissions, access permissions make up one's mind whether the client can read or write (or both) an aspect value (introduced in "Value"). Each attribute tin can have ane of the following access permissions:

None: The attribute can neither be read nor written by a client.
Readable: The aspect can be read by a client.
Writable: The aspect tin can be written by a client.
Readable and writable: The attribute can be both read and written by the customer.

Encryption

Determines whether a sure level of encryption is required for this aspect to exist accessed by the customer. (See "Authentication", "Security Modes and Procedures", and "Security Modes" for more than information on authentication and encryption.) These are the allowed encryption permissions, every bit defined by GATT:

No encryption required (Security Style 1, Level 1): The attribute is accessible on a plain-text, non-encrypted connection.
Unauthenticated encryption required (Security Mode 1, Level ii): The connectedness must be encrypted to access this attribute, but the encryption keys practise not need to be authenticated (although they can be).
Authenticated encryption required (Security Mode one, Level three): The connectedness must exist encrypted with an authenticated primal to access this attribute.

Authorization

Determines whether user permission (as well known as potency, equally discussed in "Security Modes and Procedures") is required to access this aspect. An attribute can cull only between requiring or not requiring authorization:

No authority required: Admission to this attribute does non require authorization.
Authorization required: Admission to this attribute requires authority.

All permissions are independent from each other and tin can be freely combined past the server, which stores them in a per-attribute basis.

Value

The aspect value holds the bodily data content of the attribute. There are no restrictions on the type of data it tin can contain (yous can imagine information technology as a non-typed buffer that can be bandage to any the bodily type is, based on the attribute type), although its maximum length is limited to 512 bytes by the specification.

As discussed in "Aspect and Data Bureaucracy", depending on the attribute type, the value tin hold additional data most attributes themselves or bodily, useful, user-defined awarding data. This is the part of an attribute that a customer can freely access (with the proper permissions permitting) to both read and write. All other entities make upwards the construction of the attribute and cannot be modified or accessed directly by the client (although the customer uses the handle and UUID indirectly in most of the exchanges with the server).

You can call up of the whole set of attributes contained in a GATT server as a table (such as Table 4-one), with each row representing a unmarried attribute and each column representing the different parts that actually constitute an attribute.

Table four-1. Attributes represented as a table
Handle	Blazon	Permissions	Value	Value length
0x0201	UUID₁ (16-flake)	Read only, no security	`0x180A`	2
0x0202	UUID₂ (sixteen-chip)	Read only, no security	`0x2A29`	two
0x0215	UUID_three (16-bit)	Read/write, say-so required	"a readable UTF-viii string"	23
0x030C	UUID₄ (128-fleck)	Write only, no security	`{0xFF, 0xFF, 0x00, 0x00}`	4
0x030D	UUID_v (128-fleck)	Read/write, authenticated encryption required	`36.43`	8
0x031A	UUID_ane (16-bit)	Read only, no security	`0x1801`	ii

In this fictitious GATT server, the attributes information technology contains are represented as rows of a uncomplicated table. This particular GATT server happens to host only vi attributes (a rather low number when compared to real-earth devices). Annotation that, as mentioned earlier in this section, the handles of the different attributes practise non demand to be immediately consecutive, but the ordinal sequence must progress increasingly, every bit in this example.

The Value column of the table is intended to mirror the high variety of formats that aspect values tin can incorporate in the dissimilar GATT-based profiles. The attributes with handles 0x0201, 0x0202, and 0x031A contain 16-flake integers in their respective value fields. The attribute with handle 0x0215 contains a UTF-8 string, 0x030C contains a four-byte buffer, and 0x030D holds an IEEE-754 64-bit floating point number in its value field.

Aspect and Data Hierarchy

Athough the Bluetooth specification defines attributes in the ATT section, that is equally far as ATT goes when it comes to them. ATT operates in attribute terms and relies on all the concepts exposed in "Attributes" to provide a series of precise protocol data units (PDUs, commonly known as packets) that permit a customer to access the attributes on a server.

GATT goes further to establish a strict hierarchy to organize attributes in a reusable and practical fashion, allowing the access and retrieval of information between customer and server to follow a concise set of rules that together consitute the framework used past all GATT-based profiles.

Figure 4-ane illustrates the information hierarchy introduced by GATT.

The attributes in a GATT server are grouped into services, each of which can contain nix or more than characteristics. These characteristics, in turn, can include nada or more descriptors. This hierarchy is strictly enforced for any device challenge GATT compatibility (substantially, all BLE devices sold), which means that all attributes in a GATT server are included in one of these iii categories, with no exceptions. No dangling attributes tin can live outside of this hierarchy, every bit exchanging data between BLE devices depends on information technology.

For most types of data in the GATT bureaucracy, it is important to differentiate between their definition (the whole grouping of attributes that go far up) and the declaration. The declaration is a single attribute that is always placed first (in increasing handle order) inside the definition and that introduces almost of the metadata near the data that follows. All declarations accept read-only permissions with no security required, because they cannot contain sensitive data. They are only structural attributes that allow the client to find out and discover the layout and nature of the attributes on the server.

Services

GATT services group conceptually related attributes in ane common section of the aspect information fix in the GATT server. The specification refers to all the attributes within a single service as the service definition. Therefore, a GATT server'southward attributes are in fact a succession of service definitions, each 1 starting with a single aspect that marks the first of a service (aptly named a service declaration.) This aspect's type and value format is strictly specified in GATT, as shown in Table 4-2.

Table 4-2. Service Declaration attribute
Handle	Type	Permissions	Value	Value length
`0xNNNN`	UUID_{chief service} or UUID_{secondary service}	Read Only	Service UUID	2, four, or 16 bytes

In the declaration shown in Table iv-2, UUID_{primary service} (0x2800) and UUID_{secondary service} (0x2801) refer to standard, SIG-assigned UUIDs that are used every bit the exclusive type to innovate a service. They are naturally 16-flake UUIDs (because they are fundamental ones defined by the specfication).

The deviation between primary and secondary services is important to note. A main service is the standard blazon of GATT service that includes relevant, standard functionality exposed past the GATT server. A secondary service, on the other hand, is intended to be included but in other chief services and makes sense only as its modifier, having no real pregnant on its own. In exercise, secondary services are rarely used.

The value of the service announcement aspect itself contains a UUID (as mentioned in "Value", the value of an attribute can be any data type), this time corresponding to the UUID of the bodily service that this declaration introduces.

Although the service declaration must always be the first attribute of the service, many others tin follow it before the next service annunciation, unremarkably in the form of characteristics and descriptors.

Conceptually, you could think of a GATT service every bit a class in any mod object-oriented language, consummate with instantiation, because a service can be instantiated multiple times within a unmarried GATT server (however, this is not a mutual occurrence and almost services would therefore exist akin to singletons).

Inside a service definition (that is to say, inside a service), you lot tin add one or more references to another services, using include definitions. Include definitions consist of a single attribute (the include annunciation) that contains all the details required for the client to reference the included service.

Included services can assistance avert duplicating data in a GATT server. If a service will be referenced by other services, you can apply this machinery to save retention and simplify the layout of the GATT server. In the previous illustration with classes and objects, you could encounter include definitions as pointers or references to an existing object instance.

Tabular array 4-iii shows the include declaration attribute with all its fields.

Tabular array four-3. Include Declaration attribute
Handle	Type	Permissions	Value	Value length
`0xNNNN`	UUID_include	Read only	Included service handle, finish group handle, Included Service UUID	half dozen, eight, or xx bytes

Over again, the UUID_include (0x2802) is a special SIG-assigned UUID used exclusively in include declarations, and the value field in this instance contains both the start and cease handles of the include service, as well as its UUID.

Characteristics

Y'all tin can empathise characteristics as containers for user data. They always include at least two attributes: the characteristic declaration (which provides metadata about the actual user information) and the characteristic value (which is a total attribute that contains the user data in its value field).

Additionally, the characteristic value can be followed by descriptors, which farther expand on the metadata contained in the characteristic proclamation. The declaration, value, and any descriptors together grade the characteristic definition, which is the bundle of attributes that make upwardly a single characteristic.

Table 4-4 shows the structure of the first two attributes of every unmarried feature.

Table four-4. Feature announcement and characteristic value attributes
Handle	Blazon	Permissions	Value	Value length
`0xNNNN`	UUID_feature	Read only	Backdrop, value handle (`0xMMMM`), feature UUID	5, 7, or 19 bytes
`0xMMMM`	Feature UUID	Whatsoever	Actual value	Variable

All GATT characteristics are always function of a service, and tin can therefore always exist found enclosed in ane.

Feature annunciation aspect

In one case once more, the characteristic declaration attribute's type UUID (0x2803) is a standardized, unique UUID used exclusively to denote the beginning of characteristics. Equally with all other declarations (such as service and include), this aspect has read-merely permissions, because clients are allowed only to retrieve its value just in no example modify it.

Table 4-five lists the unlike items concatenated within the characteristic announcement's attribute value.

Table iv-5. Characteristic declaration attribute value
Name	Length in bytes	Description
Feature Backdrop	i	A bitfield list the permitted operations on this characteristic
Characteristic Value Handle	2	The handle of the attribute containing the characteristic value
Characteristic UUID	two, 4, or 16	The UUID for this particular characteristic

These three fields are contained in a characteristic declaration attribute value:

Feature Properties: This 8-bit bitfield, along with the additional 2 bits in the extended properties descriptor (discussed in "Extended Properties Descriptor"), contains the operations and procedures that tin can exist used with this feature. Each of those 9 properties is encoded as a single scrap on the bitfield shown in Tabular array iv-6.

Tabular array 4-vi. Characteristic properties
Property	Location	Description
Broadcast	Properties	If set, allows this characteristic value to exist placed in advertising packets, using the Service Data AD Type (see "GATT Attribute Information in Ad Packets")
Read	Properties	If fix, allows clients to read this characteristic using whatever of the ATT read operations listed in "ATT operations"
Write without response	Backdrop	If set, allows clients to use the Write Command ATT operation on this characteristic (see "ATT operations")
Write	Properties	If set up, allows clients to use the Write Request/Response ATT operation on this characteristic (see "ATT operations")
Notify	Properties	If set up, allows the server to utilise the Handle Value Notification ATT functioning on this feature (see "ATT operations")
Indicate	Properties	If set, allows the server to utilize the Handle Value Indication/Confirmation ATT operation on this feature (see "ATT operations")
Signed Write Command	Properties	If fix, allows clients to use the Signed Write Command ATT operation on this characteristic (meet "ATT operations")
Queued Write	Extended Properties	If ready, allows clients to utilize the Queued Writes ATT operations on this feature (see "ATT operations")
Writable Auxiliaries	Extended Backdrop	If set, a client can write to the descriptor described in "Characteristic User Description Descriptor"

The client can read those properties to observe out which operations it is allowed to perform on the characteristic. This is particularly of import for the Notify and Betoken properties, because these operations are initiated by the server (further detailed in "Server-Initiated Updates") but require the customer to enable them first by using the descriptor described in "Client Characteristic Configuration Descriptor".

Characteristic Value Handle: These two bytes comprise the attribute handle of the attribute that contains the bodily value of the characteristic. Although it's frequently the example, you lot should never assume that this handle volition exist face-to-face (i.east., 0xNNNN+1) to the one containing the declaration.
Characteristic UUID: The UUID of the item characteristic, this can be either a SIG-canonical UUID (when making use of the dozens of characteristic types included in the standard profiles) or a 128-bit vendor specific UUID otherwise.

Continuing with the class and object-orientation analogy, characteristics are like individual fields or properties in that course, and a profile is like an application that makes use of one or more classes for a specific demand or purpose.

Characteristic value attribute

Finally, the feature value aspect contains the actual user data that the customer tin can read from and write to for practical information exchanges. The blazon for this attribute is ever the same UUID establish in the characteristic's proclamation value field (every bit shown in "Characteristic declaration attribute"). So, characteristic value attributes no longer take types of services or characteristics, but rather concrete, specific UUIDs that tin refer to a sensor's reading or a keypress on a keyboard.

The value of a characteristic value attribute tin can contain any blazon of information imaginable, from temperatures in celsius to key scan codes to brandish strings to speeds in miles per hour—annihilation that can be usefully transmitted over two BLE devices can make full in the contents of that value.

Characteristic Descriptors

GATT characteristic descriptors (commonly chosen just descriptors) are mostly used to provide the customer with metadata (additional data about the feature and its value). They are always placed within the characteristic definition and afterward the characteristic value attribute. Descriptors are always made of a single attribute, the characteristic descriptor declaration, whose UUID is always the descriptor blazon and whose value contains any is defined by that particular descriptor type.

You can find two types of descriptors in the different GATT characteristics:

GATT-defined descriptors: These are the fundamental, widely used descriptor types that only add together meta data about the characteristic. The following sections describe the most common ones.
Profile or vendor-defined descriptors: Regardless of whether a profile is specified and published by the SIG or past a detail vendor, these descriptors tin contain all types of information, 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 virtually commonly used descriptors divers past GATT.

Extended Properties Descriptor

This descriptor, when present, simply contains the two boosted property bits, covered in "Characteristic declaration attribute" and listed in Tabular array 4-half dozen.

Feature User Description Descriptor

Equally the proper name implies, this descriptor contains a user-readable clarification for the characteristic within which information technology is placed. This is a UTF-eight string that could read, for example, "Temperature in the living room."

Client Characteristic Configuration Descriptor

This descriptor type (oftentimes abbreviated CCCD) is without a doubt the most important and ordinarily used, and it is essential for the operation of most of the profiles and use cases. Its function is uncomplicated: it acts as a switch, enabling or disabling server-initiated updates (covered in more than item in "Server-Initiated Updates"), just only for the characteristic in which it finds itself enclosed.

A CCCD's value is nothing more a ii-chip bitfield, with ane chip corresponding to notifications and the other to indications. A client can ready and clear those bits at any time, and the server will check them every time the characteristic that encloses them has changed value and might be susceptible to an update over the air.

Every time a client wants to enable notifications or indications for a detail characteristic that supports them, it simply uses a Write Request ATT packet to set the respective bit to 1. The server will and so respond with a Write Response and outset sending the appropriate packets whenever information technology wants to alert the client of a alter in value.

Additionally, CCCDs have ii special backdrop that separate them from other attributes:

Their values are unique per connexion: In multi-connexion scenarios, in which a central is connected to multiple peripherals and likewise acting equally a GATT server, each peripheral volition receive its own copy of the CCCD's value when reading it with ATT.
Their values are preserved across connections with bonded devices: "Attribute Caching" discusses attribute caching in more item, only that concerns just attribute handles. Values are typically not stored per-device and the GATT server can reset them between connections. This is not the case with CCCDs amongst bonded devices: the terminal value written past a client to a CCCD on the server is guaranteed to be restored upon reconnection, regardless of the fourth dimension elapsed between connections.

Many protocol stacks have special mechanisms to bargain with CCCDs, both from a customer's and a server's perspective, because they are and then critical to correct operation and to guarantee timely information updates between peers.

Feature presentation format descriptor

When present, this descriptor blazon contains the actual format of the enclosing characteristic value in its seven-byte aspect value. The list of formats available include Booleans, strings, integers, floating-signal, and even generic untyped buffers.

Case Service

This section presents an example of a particular service constitute in many commercial products today. The Eye Rate Service (HRS) exposes the user's heart charge per unit to a monitoring device.

Figure 4-2 illustrates an example of the HRS on a fictitious server. This would not be the simply service independent in the server, and then yous tin can meet this equally a partial slice of the complete gear up of attributes that a client could access.

Hither is a handle-by-handle clarification of the HRS service illustrated in Figure 4-2:

Handle 0x0021

This attribute contains the service declaration (meet "Services") for the Heart Charge per unit Service. These are the service declaration aspect's fields:

UUID: The UUID is the standard 16-scrap UUID for a primary service declaration, UUID_{main service} (0x2800).
Value: The value is the sixteen-chip UUID for the Heart Rate Service, assigned by the SIG (0x180D).

Handle 0x0024

This attribute contains the feature declaration (run into "Characteristic declaration aspect") for the Centre Rate Measurement characteristic. These are the characteristic annunciation aspect'southward fields:

UUID: The UUID is the standard xvi-bit UUID for a feature annunciation, UUID_feature (0x2803).
Value: The characteristic backdrop for this feature are notify only, the characteristic value handle is 0x0027, and the characteristic value UUID is the UUID for Heart Rate Measurement (0x2A37).

Handle 0x0027

This attribute contains the characteristic value (see "Characteristic value attribute"), in this case the heart rate measurement itself. These are the feature value attribute'due south fields:

UUID: The same UUID nowadays in the last 2 bytes of the characteristic declaration'southward attribute value.
Permissions: This attribute'due south value is neither readable nor writable: a customer tin can obtain its value merely through notifications sent past the server.
Value: The bodily centre rate measurement (fictitiously represented in beats per infinitesimal for clarity).

Handle 0x0028

This aspect contains a CCCD (a key descriptor described in "Client Characteristic Configuration Descriptor"). These are the CCCD attribute'southward fields:

UUID: The UUID for any CCCD is always the standard 16-bit UUID_CCCD (0x2902).
Permissions: A CCCD must e'er be readable and writable. The security level required to execute these operations is defined by the contour or application.
Value: As already established, the CCCD's value is a bitfield, in this example 0x0001, denoting that notifications are enabled for this particular HRM feature.

Handle 0x002A

This attribute contains another characteristic proclamation (run across "Feature declaration aspect"), this fourth dimension for Body Sensor Location characteristic. These are the characteristic declaration attribute's fields:

UUID: The UUID is the standard xvi-fleck UUID for a characteristic announcement, UUID_{characteristic} (0x2803).
Value: The characteristic properties for this characteristic are read merely, the characteristic value handle is 0x002C, and the feature value UUID is the UUID for the Body Sensor Location (0x2A38).

Handle 0x002C

This attribute contains the characteristic value (see "Characteristic value attribute"), in this case the torso sensor location. These are the characteristic value attribute'southward fields:

UUID: The aforementioned UUID present in the concluding two bytes of the characteristics definition'south attribute value.
Permissions: This attribute's value is read only: a client tin only check where the sensor is located, merely not modify its location (that is up to the server).
Value: The actual torso sensor location (fictitiously represented as "finger" for clarity).

Several tools exist to discover and brandish the different services on a server in a format similar to Figure four-2, which can be useful during awarding evolution. Chapter 6 has more information on these tools.

Avant-garde Attribute Concepts

This section introduces boosted concepts related to working with attributes that are besides worth mentioning considering their understanding is frequently required for many types of BLE applications.

Attribute Caching

"Attributes" discusses how attribute handles allow a customer to individually address all available attributes on a server. Discovering the list of available handles and the contents of their respective attributes can exist a time-consuming (and power-consuming) process detailed further in "Service and Characteristic Discovery". Just for now, this section describes what a client can do to avert performing the discovery procedure every time information technology reconnects to a server, and nether what circumstances information technology tin do so.

Servers typically tend to maintain a stable ready of attributes, and their bones structure does not, in near cases, alter over the lifetime of a server device. But the implementation imposes no rigid restrictions in this regard, and a server is indeed free to completely overhaul its attributes and even replace them with a radically new set at any time (through a firmware update or perhaps with the installation of applications on the server device, for case). Sure rules and constraints are therefore required, so that a client tin can rely on the validity of previously discovered handles without take a chance of them having changed on the server and thus no longer being valid.

As a general dominion, the specification recommends that clients cache (i.e., store for subsequent transactions and even connections) the handles of the attributes they are interested in. Aspect values, especially in the cases where they correspond to actual user data, are highly volatile, so it usually makes little sense to store them locally in the client for futurity use.

The specification provides the Service Changed characteristic (discussed in more detail in "GATT Service") for servers to communicate to the client whatsoever potential changes in the contents of its attribute information. This is an optional characteristic, so its mere presence on the server already acts as an alert regarding the actual possibility of structural attribute changes.

Clients can define if the upshot of discovery tin exist cached for future utilize past observing the post-obit atmospheric condition:

No Service Changed characteristic present on the server: Clients tin can freely and permamently cache all handles plant with no restrictions. The server guarantees they volition non modify during the lifetime of the device.
Service Changed characteristic present on the server: In this case, a client needs to subscribe to the server-initiated updates by writing into the respective CCCD enclosed within the Service Changed characteristic (encounter "Characteristic Descriptors"). This will allow the server to alert the client of any structural changes. If the customer and the server are bonded as described in "Security Modes and Procedures", the client tin enshroud aspect handles across connections and look them to remain identical. If the devices are not bonded, the client will demand to perform discovery every fourth dimension it reconnects to the server.

"GATT Service" provides more details virtually using the Service Changed feature.

GATT Attribute Information in Advertisement Packets

Although GATT primarily relies on established connections between a central and a peripheral (as described in "Roles"), it is also possible to include portions of the aspect data hosted by the server inside advertising packets, rendering ane or more server attributes bachelor to whatsoever observer or central while scanning.

Table iii-3 discusses the Service Data AD Blazon, but that section does not describe the format it uses to enclose server attributes within an advertising packet. The Core Specification Supplement in the Specification Adopted Documents page specifies the fields that the GATT server must insert in the payload of an advert package to make a particular service's data available to scanners.

As shown in Tabular array 4-7, to be able to circulate service data, a GATT server must include two different fields in the advertising parcel's Service Data department.

Table 4-7. Service Data AD Type
Field	Length in bytes	Clarification
UUID	two, iv, or 16	The actual UUID identifying the data
Service Data	Variable	The data associated with the service identified by the UUID

The contents of the Service Information field can stand for to the complete or fractional value of a particular characteristic or descriptor inside the corresponding service. Information technology is up to each profile specification to ascertain which, because but the profile has sufficient knowledge nearly the data to determine which pieces of data are the most relevant to exist broadcasted.

Features

GATT features are strictly divers procedures that permit GATT-based data exchanges to take place. They are all based on the unlike operations that ATT provides (introduced in "ATT operations").

To a sure extent, almost of the features listed in this chapter are exposed in one fashion or another in most GATT APIs. GATT server APIs add together the ability to populate the bodily server with attributes, but that is heavily implementation dependant and across the scope of this affiliate.

Commutation MTU

This succinct ii-packet procedure allows each ATT peer to let the other cease know nigh the maximum transmission unit (MTU, or effectively maximum package length) it can agree in its buffers and tin can therefore accept.

This procedure is used only whenever either the customer or the server (or both) can handle MTUs longer than the default ATT_MTU of 23 bytes (see "Logical Link Control and Adaptation Protocol (L2CAP)") and wants to inform the other end that it can transport packets longer than the default values that the specification requires. L2CAP will then fragment these bigger packets into modest Link Layers packets and recombine them from pocket-size Link Layers packets.

Service and Characteristic Discovery

As mentioned elsewhere in this chapter, the client has no knowledge about the attributes that might be present in a GATT server when information technology start connects to it. It is therefore essential for the client to brainstorm by performing a series of packet exchanges to determine the corporeality, location, and nature of all the attributes that might be of involvement. Every bit discussed in "Attribute Caching", procedures in this category tin, in some cases, subsequently be skipped.

For primary service discovery, GATT offers the two following options:

Observe all primary services: Using this characteristic, clients tin remember a total list of all master services (regardless of service UUIDs) from the remote server. This is commonly used when the client supports more than one service and therefore wants to find out about the full service support on the server side. Considering the customer can specify a handle range when issuing the required asking, it must set 0x0001-0xFFFF as the handle range to implement this feature, covering the full attribute range of the server.
Discover chief service by service UUID: Whenever the client knows which service information technology is looking for (usually because it supports only that single service itself), it can only look for all instances of a particular service using this feature, besides with the requirement of setting the handle range to 0x0001-0xFFFF.

Each of these procedures yield handle ranges that refer to the attributes that belong to a single service. The discover all principal services feature besides obtains the individual service UUIDs.

When the client has already establish services on the server, it can go along to perform relationship discovery (the discovery of any included services) with the post-obit characteristic:

Find included services: This allows a client to query the server virtually whatever included services within a service. The handle range provided in such a query refers to the boundaries of an existing service, previously obtained using service discovery. As with service discovery, the customer also receives a prepare of handle ranges, along with UUIDs when applicable.

In terms of characteristic discovery, GATT offers the following options:

Discover all characteristics of a service: Once a customer has obtained the handle range for a service it might be interested in, information technology can then proceed to retrieve a full list of its characteristics. The only input is the handle range, and in exchange, the server returns both the handle and the value of all characteristic declaration attributes enclosed within that service (see "Characteristic declaration attribute").
Observe characteristics by UUID: This process is identical to the previous one, except the client discards all responses that do not match the particular feature UUID it targets.

Once the boundaries (in terms of handles) of a target characteristic have been established, the customer tin go along to characteristic descriptor discovery:

Discover all feature descriptors: Now in possession of a set of handle ranges and UUIDs for some or all of the characteristics in a service, the client can use this characteristic to think all the descriptors inside a item feature. The server replies with a list of UUID and handle pairs for the different descriptor declarations (encounter "Feature Descriptors").

All the features in this department can be performed over open, unsecured connections, considering discovery is immune for all clients without any restrictions.

Reading Characteristics and Descriptors

To obtain the current value of a characteristic value or a descriptor, the client has the following choices:

Read characteristic value or descriptor: This feature can be used to simply read the contents of a characteristic value or a descriptor by using its handle. Merely the first ATT_MTU-1 bytes of the contents can be read, because that is the maximum number of bytes that can fit in the response packet (1 byte is reserved for the ATT operation code).
Read long characteristic value or descriptor: If the value is as well long to be read with the previous feature, this feature includes an kickoff along with the handle in the asking, then that the characteristic value or the descriptor contents can exist read in successive chunks. Multiple request/response pairs might be required, depending on the length of the attribute value being read.

Additionally, and only applicable for characteristic values, these features are available:

Read characteristic value using characteristic UUID: Whenever a client does non know the specific handles for the characteristics it might be interested in, information technology can read the values of all the characteristics of a specific type. The client simply provides a handle range and a UUID and receives an array of values of characteristics enclosed in that range.
Read mutiple characteristic values: Conversely, if a client already has the handles for a set of characteristics information technology wants to obtain the value from, information technology can then send a asking with this ready of handles and afterward receive the values for all respective characteristics.

Reading characteristics and descriptors is field of study to the security permissions and the server can deny permission if the connection's security level does not lucifer the established requirements (run across "Security").

Writing Characteristics and Descriptors

To write to the value of a characteristic value or a descriptor, the customer has the following choices:

Write characteristic value or descriptor: This feature is used to write to a characteristic value or descriptor. The client provides a handle and the contents of the value (up to ATT_MTU-3 bytes, because the handle and the ATT operation code are included in the packet with the information) and the server will admit the write operation with a response.
Write long characteristic value or descriptor: Similar to the read long characteristic value or descriptor feature, this permits a client to write more than ATT_MTU-3 bytes of data into a server's feature value or descriptor. It works by queueing several set up write operations, each of which includes an offset and the data itself, so finally writing them all atomically with an execute write operation.

Additionally, and only applicable for feature values, these features are available:

Write without response: This feature is the converse equivalent of notifications (detailed in "Server-Initiated Updates") and uses Write Command packets. Write Commands are unacknowledged packets that include a handle and a value, and they can exist sent at any time and in any amount without any flow command mechanism boot in (except of course for the native Link Layer flow command, since all traffic is field of study to information technology). The server is gratuitous to silently discard them if information technology cannot process them or if the aspect permissions prevent it from accepting it. The client will never know, but that is by mutual agreement. The but fashion for the client to find out whether the value was written is to read it after the fact.
Reliable writes: Similar to the read multiple feature values feature, when a client wants to queue write operations to multiple characteristic values, it issues a terminal parcel to commit the pending write operations and execute them.

Writing characteristics and descriptors is discipline to the security permissions, and the server can deny permission if the connexion's security level does not match the established requirements (see "Security").

Server-Initiated Updates

Server-initiated updates are the only asynchronous (i.east., not as a response to a client's request) packets that can flow from the server to the client. These updates send timely alerts of changes in a characteristic value without the client having to regularly poll for them, saving both power and bandwidth.

At that place are ii types of server-initiated updates:

Characteristic Value Notification: Notifications are packets that include the handle of a characteristic value attribute along with its current value. The client receives them and can choose to act upon them, but information technology sends no acknowledgement back to the server to confirm reception. Along with write without response, this is the only other package that does not comply with the standard request/response menses control mechanism in ATT, as the server tin transport any number of these notifications at any time. This characteristic uses the handle value notification (HVN) ATT packet.
Feature Value Indication: Indications, on the other hand, follow the same handle/value format merely require an explicit acknowledgment from the client in the form of a confirmation. Annotation that although the server cannot transport further indications (even for different characteristics) until information technology receives confirmation from the client (because this flows in the opposite direction than the usual request/response pairs), an outstanding confirmation does non affect potential requests that the customer might send in the meantime. This feature uses the handle value indication (HVI) and handle value confirmation (HVC) ATT packets.

The client must enable both types of server-initiated updates past writing to the corresponding CCCD before the server tin can showtime sending them. "Customer Feature Configuration Descriptor" describes this procedure extensively.

Security

"Security Modes and Procedures" discusses how the GAP authentication procedure can be used to transition from one security style to a higher, more secure one past using the different means bachelor within the Security Manager and GAP. GATT transactions can act equally triggers of such an authentication procedure. As discussed in "Permissions", each attribute inside a GATT server has fine-grained, independent permissions for both reading and writing, and these permissions are enforced at the ATT level.

Generally speaking, attributes that are declarations require no special security to be accessed. This is true for both service and feature declarations, merely not for descriptor declarations, which incorporate the relevant information directly in them, rather than in a separate attribute. This is washed and then that clients that have not yet paired or bonded with a server can at least perform bones service and characteristic discovery, without having to resort to performing security procedures. The attribute layout and information bureaucracy of a server is not considered to be sensitive information and is therefore freely available to all clients.

When accessing a characteristic value or a descriptor announcement (also called service request), however, a client can receive an error response ATT packet (see "ATT operations"), indicating that the connection's current security level is not high plenty for the request to be executed. The following two error codes are unremarkably used for this purpose and placed in the error response packet:

Insufficient Hallmark: Denotes that the link is not encrypted and that the server does not have a long-term key (LTK, beginning introduced in "Security Keys") available to encrypt the link, or that the link is indeed encrypted, just the LTK used to perform the encryption process is not authenticated (generated with human-in-the-middle protection; see "Hallmark") while the permissions required authenticated encryption.
Insufficient Encryption: Denotes that the link is not encrypted but a suitable LTK is available.

GAP and GATT roles are not linked in any manner and tin be mixed and matched freely, simply security procedures are ever initiated by the GAP fundamental (see "Security Manager (SM)"). Therefore, depending on which peer is acting as a central and which as a peripheral, it tin can exist upwardly to either the GATT client or the GATT server to initiate the pairing, bonding, or encryption procedure in lodge to heighten the security level of the connectedness. Once the security level matches the one required past the aspect's permissions, the customer can send the request once again to be executed on the server.

GATT Service

Merely every bit GAP has its own SIG-specified service that is mandatory for all devices (described extensively in "GAP Service"), GATT besides has its own service (containing up to one characteristic) that must exist included in all GATT servers. The optional service inverse characteristic (introduced briefly in "Aspect Caching"), cannot be read or written, and its value is communicated to the client only through characteristic value indications.

Every bit shown in Table four-viii, the value consists only of a handle range, which delimits a particular area of attributes in the server. This is the area that has been affected past structural changes and needs to exist rediscovered by the client. The customer will have to perform service and feature discovery in that surface area, because the attributes information technology can accept cached might no longer be valid.

Table 4-8. Service changed characteristic value
Handle	Type	Permissions	Value	Value length
`0xNNNN`	UUID_{service changed}	None	Affected handle range	4

A customer must enable indications on the corresponding CCCD for this characteristic before doing anything else, so that it can become aware of any changes on the server's attribute structure.

If the server suffers a structural alter in attribute layout, information technology will so immediately send a handle value indication to the client and wait for the respective confirmation. In this way, it tin be certain that the client understands that cached attribute handles in that range might no longer be valid. If the attributes change exterior the lifetime of a connection with a bonded device, the server will ship the indication right after the connection is fix, so that the client has a take a chance to rediscover the affected expanse.