Does Ble Time Service Client Need To Be Bonded?

Chapter four. GATT (Services and Characteristics)

The Generic Attribute Profile (GATT) establishes in detail how to exchange all profile and user data over a BLE connection. In dissimilarity with GAP (Chapter 3), which defines the low-level interactions with devices, GATT deals only with actual data transfer procedures and formats.

GATT also provides the reference framework for all GATT-based profiles (discussed in "SIG-defined GATT-based profiles"), which encompass precise utilise 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 fundamental section of the BLE specification, considering every unmarried item of data relevant to applications and users must be formatted, packed, and sent according to its rules.

GATT uses the Aspect Protocol (detailed in "Aspect Protocol (ATT)") equally its send protocol to exchange data 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

Every bit with any other protocol or profile in the Bluetooth specification, GATT starts by defining the roles that interacting devices can adopt:

Client: The GATT client 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 client does non know anything in advance about the server's attributes, then it must commencement ask nearly the presence and nature of those attributes past performing service discovery. After completing service discovery, it tin can so start reading and writing attributes found in the server, every bit well as receiving server-initiated updates.
Server: The GATT server corresponds to the ATT server discussed in "Attribute Protocol (ATT)". Information technology receives requests from a customer and sends responses dorsum. It also sends server-initiated updates when configured to do so, and it is the role responsible for storing and making the user data available to the client, organized in attributes. Every BLE device sold must include at least a basic GATT server that can respond to client requests, even if only to return an error response.

It is worth mentioning one time more than that GATT roles are both completely independent of GAP roles (run across "Roles") and likewise concurrently uniform with each other. That means that both a GAP cardinal and a GAP peripheral can act as a GATT client or server, or even act equally both at the aforementioned fourth dimension.

UUIDs

A universally unique identifier (UUID) is a 128-bit (16 bytes) number that is guaranteed (or has a high probability) to be 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 16 bytes would take a large chunk of the 27-byte data payload length of the Link Layer, the BLE specification adds two additional UUID formats: sixteen-fleck and 32-fleck UUIDs. These shortened formats can be used only with UUIDs that are divers in the Bluetooth specification (i.e., that are listed past the Bluetooth SIG as standard Bluetooth UUIDs).

To reconstruct the full 128-chip UUID from the shortened version, insert the sixteen- or 32-flake short value (indicated by xxxxxxxx, including leading zeros) into the Bluetooth Base UUID:

xxxxxxxx-0000-chiliad-8000-00805F9B34FB

The SIG provides (shortened) UUIDs for all the types, services, and profiles that it defines and specifies. Only if your application needs its own, either because the ones offered by the SIG practise not embrace your requirements or because yous want to implement a new use case non previously considered in the profile specifications, you can generate them using the ITU'south UUID generation page.

Shortening is not available for UUIDs that are non derived from the Bluetooth Base UUID (commonly chosen vendor-specific UUIDs). In these cases, you lot'll demand to apply the full 128-bit UUID value at all times.

Attributes

Attributes are the smallest data entity defined by GATT (and ATT). They are addressable pieces of information that can contain relevant user data (or metadata) about the structure and grouping of the unlike attributes independent within the server. Both GATT and ATT tin work merely with attributes, so for clients and servers to interact, all information must exist organized in this form.

Conceptually, attributes are e'er located on the server and accessed (and potentially modified) by the client. The specification defines attributes only conceptually, and it does not force the ATT and GATT implementations to use a particular internal storage format or mechanism. Considering attributes contain both static definitions of invariable nature and too actual user (oft sensor) data that is leap to change rapidly with time (equally discussed in "Attribute and Data Hierarchy"), attributes are ordinarily stored in a mixture of nonvolatile memory and RAM.

Each and every attribute contains information about the attribute itself and then the actual information, in the fields described in the following sections.

Handle

The attribute handle is a unique xvi-fleck identifier for each aspect on a particular GATT server. Information technology is the role of each attribute that makes it addressable, and it is guaranteed not to change (with the caveats described in "Attribute Caching") between transactions or, for bonded devices, fifty-fifty beyond connections. Because value 0x0000 denotes an invalid handle, the amount of handles available to every GATT server is 0xFFFF (65535), although in practice, 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 case, handle range 0x0100-0x010A would refer to any attribute with a handle between 0x0100 and 0x010A.

Within a GATT server, the growing values of handles determine the ordered sequence of attributes that a client can admission. But gaps betwixt handles are allowed, so a client cannot rely on a contiguous sequence to guess the location of the adjacent aspect. Instead, the client must apply the discovery feature ("Service and Characteristic Discovery") to obtain the handles of the attributes it is interested in.

Blazon

The attribute type is nada other than a UUID (meet "UUIDs"). This tin can be a 16-, 32-, or 128-flake UUID, taking up 2, 4, or xvi bytes, respectively. The type determines the kind of data present in the value of the attribute, and mechanisms are available to observe attributes based exclusively on their type (see "Service and Feature Discovery").

Although the aspect type is always a UUID, many kinds of UUIDs can be used to fill in the type. They can be standard UUIDs that determine the layout of the GATT server's attribute hierarchy (farther discussed in "Aspect and Information Hierarchy"), such every bit the service or characteristic UUIDs, profile UUIDs that specify the kind of data contained in the aspect, such equally Heart Charge per unit Measurement or Temperature, and even proprietary, vendor-specific UUIDs, the meaning of which is assigned by the vendor and depends on the implementation.

Permissions

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

ATT and GATT define the following permissions:

Access Permissions

Similar to file permissions, admission permissions determine whether the customer can read or write (or both) an attribute value (introduced in "Value"). Each attribute can have ane of the following access permissions:

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

Encryption

Determines whether a sure level of encryption is required for this aspect to be accessed past the client. (See "Authentication", "Security Modes and Procedures", and "Security Modes" for more information on hallmark and encryption.) These are the allowed encryption permissions, as defined by GATT:

No encryption required (Security Mode i, Level 1): The attribute is accessible on a plain-text, non-encrypted connection.
Unauthenticated encryption required (Security Mode 1, Level 2): The connection must be encrypted to access this attribute, but the encryption keys do not need to be authenticated (although they can be).
Authenticated encryption required (Security Mode 1, Level 3): The connection must be encrypted with an authenticated central to access this attribute.

Dominance

Determines whether user permission (also known every bit authorization, as discussed in "Security Modes and Procedures") is required to access this attribute. An attribute can choose merely between requiring or not requiring dominance:

No authorization required: Access to this attribute does not require authority.
Authorization required: Access to this attribute requires authorization.

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

Value

The attribute value holds the actual information content of the attribute. There are no restrictions on the blazon of data it can comprise (you can imagine it as a non-typed buffer that can be cast to whatever the bodily type is, based on the attribute blazon), although its maximum length is limited to 512 bytes by the specification.

As discussed in "Attribute and Data Hierarchy", depending on the attribute type, the value can hold additional information most attributes themselves or actual, useful, user-defined application data. This is the function of an aspect that a client can freely admission (with the proper permissions permitting) to both read and write. All other entities make upward the structure of the aspect and cannot exist modified or accessed straight by the client (although the client uses the handle and UUID indirectly in about of the exchanges with the server).

You tin can think of the whole ready of attributes contained in a GATT server as a tabular array (such as Table 4-1), with each row representing a unmarried aspect and each column representing the different parts that actually constitute an attribute.

Tabular array 4-1. Attributes represented as a table
Handle	Type	Permissions	Value	Value length
0x0201	UUID₁ (16-fleck)	Read just, no security	`0x180A`	2
0x0202	UUID_two (xvi-bit)	Read only, no security	`0x2A29`	2
0x0215	UUID₃ (xvi-bit)	Read/write, dominance required	"a readable UTF-8 cord"	23
0x030C	UUID₄ (128-bit)	Write but, no security	`{0xFF, 0xFF, 0x00, 0x00}`	four
0x030D	UUID₅ (128-bit)	Read/write, authenticated encryption required	`36.43`	8
0x031A	UUID₁ (16-bit)	Read only, no security	`0x1801`	ii

In this fictitious GATT server, the attributes it contains are represented as rows of a uncomplicated table. This particular GATT server happens to host merely 6 attributes (a rather low number when compared to existent-world devices). Note that, every bit mentioned earlier in this section, the handles of the different attributes do not need to be immediately consecutive, only the ordinal sequence must progress increasingly, as in this instance.

The Value column of the tabular array is intended to mirror the high diversity of formats that attribute values can contain in the different GATT-based profiles. The attributes with handles 0x0201, 0x0202, and 0x031A contain 16-scrap integers in their corresponding value fields. The attribute with handle 0x0215 contains a UTF-8 string, 0x030C contains a 4-byte buffer, and 0x030D holds an IEEE-754 64-fleck floating point number in its value field.

Attribute and Information Hierarchy

Athough the Bluetooth specification defines attributes in the ATT section, that is every bit 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 information 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 applied manner, allowing the access and retrieval of information between client and server to follow a curtailed set up of rules that together consitute the framework used past all GATT-based profiles.

Figure 4-1 illustrates the data bureaucracy introduced by GATT.

The attributes in a GATT server are grouped into services, each of which can contain zero or more characteristics. These characteristics, in turn, can include zero or more descriptors. This hierarchy is strictly enforced for any device challenge GATT compatibility (essentially, all BLE devices sold), which means that all attributes in a GATT server are included in one of these three categories, with no exceptions. No dangling attributes can alive outside of this bureaucracy, as exchanging information between BLE devices depends on information technology.

For most types of data in the GATT hierarchy, information technology is important to differentiate between their definition (the whole grouping of attributes that brand it up) and the declaration. The annunciation is a unmarried attribute that is always placed start (in increasing handle club) within the definition and that introduces most of the metadata near the data that follows. All declarations have read-only permissions with no security required, because they cannot contain sensitive information. They are only structural attributes that allow the client to notice out and discover the layout and nature of the attributes on the server.

Services

GATT services group conceptually related attributes in one mutual section of the attribute information set in the GATT server. The specification refers to all the attributes inside a single service every bit the service definition. Therefore, a GATT server'due south attributes are in fact a succession of service definitions, each one starting with a unmarried attribute that marks the beginning of a service (aptly named a service declaration.) This attribute'due south type and value format is strictly specified in GATT, as shown in Tabular array four-2.

Table 4-2. Service Declaration aspect
Handle	Blazon	Permissions	Value	Value length
`0xNNNN`	UUID_{primary service} or UUID_{secondary service}	Read Only	Service UUID	two, 4, or 16 bytes

In the announcement shown in Table 4-two, UUID_{primary service} (0x2800) and UUID_{secondary service} (0x2801) refer to standard, SIG-assigned UUIDs that are used every bit the exclusive type to introduce a service. They are naturally 16-chip UUIDs (because they are central ones defined by the specfication).

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

The value of the service declaration attribute itself contains a UUID (as mentioned in "Value", the value of an attribute tin be any data blazon), this time respective to the UUID of the actual service that this proclamation introduces.

Although the service announcement must always be the first attribute of the service, many others tin can follow information technology before the side by side service annunciation, usually in the form of characteristics and descriptors.

Conceptually, you lot could remember of a GATT service every bit a form in any modern object-oriented linguistic communication, complete with instantiation, considering a service can be instantiated multiple times within a single GATT server (withal, this is not a common occurrence and most services would therefore be alike to singletons).

Inside a service definition (that is to say, within a service), yous can add one or more than references to another services, using include definitions. Include definitions consist of a unmarried aspect (the include declaration) that contains all the details required for the client to reference the included service.

Included services tin can aid avert duplicating information in a GATT server. If a service will be referenced by other services, you lot can apply this mechanism to save retentiveness and simplify the layout of the GATT server. In the previous analogy with classes and objects, you could see include definitions as pointers or references to an existing object instance.

Table four-3 shows the include declaration attribute with all its fields.

Tabular array 4-3. Include Proclamation aspect
Handle	Type	Permissions	Value	Value length
`0xNNNN`	UUID_include	Read only	Included service handle, end grouping handle, Included Service UUID	half dozen, 8, or twenty bytes

Once more, 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 every bit its UUID.

Characteristics

Yous can empathize characteristics every bit containers for user data. They always include at least two attributes: the characteristic annunciation (which provides metadata almost the bodily user data) and the feature value (which is a full attribute that contains the user information in its value field).

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

Table iv-4 shows the construction of the showtime ii attributes of every unmarried characteristic.

Table 4-4. Characteristic proclamation and characteristic value attributes
Handle	Type	Permissions	Value	Value length
`0xNNNN`	UUID_{characteristic}	Read but	Backdrop, value handle (`0xMMMM`), feature UUID	5, 7, or 19 bytes
`0xMMMM`	Characteristic UUID	Any	Bodily value	Variable

All GATT characteristics are always office of a service, and can therefore always be found enclosed in ane.

Characteristic announcement attribute

Once again, the characteristic annunciation aspect'southward type UUID (0x2803) is a standardized, unique UUID used exclusively to denote the beginning of characteristics. Every bit with all other declarations (such as service and include), this aspect has read-simply permissions, considering clients are allowed only to think its value but in no instance change it.

Table 4-5 lists the different items concatenated within the feature declaration's attribute value.

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

These 3 fields are contained in a characteristic declaration aspect value:

Characteristic Properties: This 8-bit bitfield, along with the additional two $.25 in the extended properties descriptor (discussed in "Extended Properties Descriptor"), contains the operations and procedures that can exist used with this characteristic. Each of those nine properties is encoded as a unmarried bit on the bitfield shown in Table 4-6.

Tabular array 4-half dozen. Characteristic backdrop
Property	Location	Description
Broadcast	Backdrop	If fix, allows this feature value to be placed in ad packets, using the Service Information Advertizing Type (run across "GATT Attribute Information in Advertising Packets")
Read	Properties	If set, allows clients to read this characteristic using any of the ATT read operations listed in "ATT operations"
Write without response	Properties	If set, allows clients to use the Write Control ATT performance on this feature (run across "ATT operations")
Write	Properties	If ready, allows clients to apply the Write Asking/Response ATT operation on this characteristic (see "ATT operations")
Notify	Properties	If set, allows the server to utilise the Handle Value Notification ATT operation on this characteristic (run into "ATT operations")
Betoken	Properties	If fix, allows the server to utilize the Handle Value Indication/Confirmation ATT operation on this characteristic (see "ATT operations")
Signed Write Control	Properties	If prepare, allows clients to utilize the Signed Write Command ATT operation on this characteristic (see "ATT operations")
Queued Write	Extended Backdrop	If set, allows clients to use the Queued Writes ATT operations on this characteristic (see "ATT operations")
Writable Auxiliaries	Extended Properties	If gear up, a client tin can write to the descriptor described in "Feature User Description Descriptor"

The client can read those properties to find out which operations information technology is immune to perform on the characteristic. This is especially important for the Notify and Signal properties, because these operations are initiated past the server (farther detailed in "Server-Initiated Updates") but require the customer to enable them beginning by using the descriptor described in "Client Feature Configuration Descriptor".

Characteristic Value Handle: These ii bytes contain the attribute handle of the attribute that contains the actual value of the feature. Although it'south often the case, you should never assume that this handle will exist contiguous (i.e., 0xNNNN+i) to the one containing the declaration.
Characteristic UUID: The UUID of the particular characteristic, this tin can exist either a SIG-approved UUID (when making employ of the dozens of feature types included in the standard profiles) or a 128-chip vendor specific UUID otherwise.

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

Feature value attribute

Finally, the feature value attribute contains the bodily user data that the client tin read from and write to for practical data exchanges. The type for this attribute is e'er the same UUID institute in the characteristic's declaration value field (as shown in "Feature declaration attribute"). So, characteristic value attributes no longer have types of services or characteristics, simply rather physical, specific UUIDs that can refer to a sensor's reading or a keypress on a keyboard.

The value of a characteristic value attribute can contain whatsoever type of data imaginable, from temperatures in celsius to key scan codes to display strings to speeds in miles per hour—annihilation that can exist usefully transmitted over ii BLE devices can make full in the contents of that value.

Characteristic Descriptors

GATT feature descriptors (commonly called only descriptors) are mostly used to provide the customer with metadata (additional information about the characteristic and its value). They are always placed inside the characteristic definition and after the characteristic value attribute. Descriptors are e'er made of a single attribute, the characteristic descriptor declaration, whose UUID is always the descriptor type and whose value contains whatsoever is defined by that item descriptor blazon.

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

GATT-defined descriptors: These are the fundamental, widely used descriptor types that simply add together meta information about the feature. The following sections draw the most mutual ones.
Profile or vendor-divers descriptors: Regardless of whether a profile is specified and published by the SIG or by a particular vendor, these descriptors tin can comprise all types of data, including additional information regarding the characteristic value, such equally the encoding used to acquire the value from a sensor or any other particulars that complement the reading itself.

The following sections depict some of the nigh commonly used descriptors defined by GATT.

Extended Backdrop Descriptor

This descriptor, when present, simply contains the ii additional property bits, covered in "Characteristic declaration aspect" and listed in Table 4-vi.

Characteristic User Description Descriptor

As the name implies, this descriptor contains a user-readable description for the feature within which it is placed. This is a UTF-8 cord that could read, for case, "Temperature in the living room."

Customer Characteristic Configuration Descriptor

This descriptor type (often abbreviated CCCD) is without a doubt the most important and ordinarily used, and information technology is essential for the performance of well-nigh of the profiles and use cases. Its function is simple: it acts equally a switch, enabling or disabling server-initiated updates (covered in more particular in "Server-Initiated Updates"), but but for the characteristic in which it finds itself enclosed.

A CCCD's value is nothing more than than a ii-chip bitfield, with one chip corresponding to notifications and the other to indications. A client can set up and clear those $.25 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 particular characteristic that supports them, it merely uses a Write Asking ATT packet to ready the corresponding fleck to 1. The server will then reply with a Write Response and get-go sending the advisable packets whenever it wants to alert the client of a alter in value.

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

Their values are unique per connection: In multi-connectedness scenarios, in which a central is continued to multiple peripherals and too acting every bit a GATT server, each peripheral will receive its own copy of the CCCD'southward value when reading it with ATT.
Their values are preserved across connections with bonded devices: "Aspect Caching" discusses attribute caching in more than detail, only that concerns only attribute handles. Values are typically not stored per-device and the GATT server can reset them between connections. This is non the example with CCCDs among bonded devices: the last value written by a client to a CCCD on the server is guaranteed to be restored upon reconnection, regardless of the time elapsed between connections.

Many protocol stacks have special mechanisms to deal with CCCDs, both from a client'south and a server'due south perspective, considering they are so critical to correct operation and to guarantee timely information updates between peers.

Characteristic presentation format descriptor

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

Instance Service

This department presents an example of a particular service found in many commercial products today. The Middle Rate Service (HRS) exposes the user'southward center rate to a monitoring device.

Figure 4-two illustrates an instance of the HRS on a fictitious server. This would not exist the only service contained in the server, and then you can see this as a fractional piece of the complete set of attributes that a client could access.

Hither is a handle-by-handle description of the HRS service illustrated in Figure four-2:

Handle 0x0021

This aspect contains the service declaration (see "Services") for the Center Rate Service. These are the service declaration attribute'southward fields:

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

Handle 0x0024

This aspect contains the characteristic declaration (run across "Characteristic declaration attribute") for the Heart Rate Measurement characteristic. These are the characteristic announcement attribute'due south fields:

UUID: The UUID is the standard 16-bit UUID for a characteristic declaration, UUID_{characteristic} (0x2803).
Value: The characteristic backdrop for this characteristic are notify only, the characteristic value handle is 0x0027, and the characteristic value UUID is the UUID for Middle Charge per unit Measurement (0x2A37).

Handle 0x0027

This attribute contains the characteristic value (see "Feature value aspect"), in this case the heart charge per unit measurement itself. These are the feature value attribute'due south fields:

UUID: The aforementioned UUID present in the terminal two bytes of the feature declaration's attribute value.
Permissions: This aspect's value is neither readable nor writable: a client can obtain its value only through notifications sent by the server.
Value: The actual eye rate measurement (fictitiously represented in beats per minute for clarity).

Handle 0x0028

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

UUID: The UUID for any CCCD is always the standard sixteen-fleck UUID_CCCD (0x2902).
Permissions: A CCCD must always be readable and writable. The security level required to execute these operations is defined past the profile or application.
Value: As already established, the CCCD's value is a bitfield, in this case 0x0001, cogent that notifications are enabled for this detail HRM characteristic.

Handle 0x002A

This attribute contains another characteristic declaration (see "Characteristic declaration attribute"), this fourth dimension for Body Sensor Location feature. These are the characteristic annunciation attribute's fields:

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

Handle 0x002C

This attribute contains the feature value (run across "Feature value attribute"), in this case the torso sensor location. These are the characteristic value attribute'south fields:

UUID: The same UUID present in the terminal two bytes of the characteristics definition's aspect value.
Permissions: This aspect's value is read merely: a client tin simply bank check where the sensor is located, simply not modify its location (that is up to the server).
Value: The actual trunk sensor location (fictitiously represented as "finger" for clarity).

Several tools exist to discover and brandish the unlike services on a server in a format similar to Figure iv-2, which can be useful during application development. Affiliate 6 has more than information on these tools.

Avant-garde Aspect Concepts

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

Aspect Caching

"Attributes" discusses how aspect handles allow a client to individually address all available attributes on a server. Discovering the list of available handles and the contents of their respective attributes can be a time-consuming (and ability-consuming) process detailed further in "Service and Characteristic Discovery". Just for now, this section describes what a client can do to avoid performing the discovery process every time it reconnects to a server, and under what circumstances information technology tin can do then.

Servers typically tend to maintain a stable set of attributes, and their basic construction does not, in almost cases, change 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 fifty-fifty replace them with a radically new fix at any time (through a firmware update or perhaps with the installation of applications on the server device, for example). Certain rules and constraints are therefore required, so that a customer can rely on the validity of previously discovered handles without run a risk of them having changed on the server and thus no longer beingness 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. Attribute values, specially in the cases where they correspond to actual user information, are highly volatile, so it ordinarily makes trivial sense to shop them locally in the client for hereafter utilise.

The specification provides the Service Inverse characteristic (discussed in more particular in "GATT Service") for servers to communicate to the client any potential changes in the contents of its attribute data. This is an optional feature, so its mere presence on the server already acts as an warning regarding the actual possibility of structural attribute changes.

Clients tin define if the consequence of discovery can be cached for future utilise by observing the following conditions:

No Service Inverse feature present on the server: Clients tin can freely and permamently cache all handles found with no restrictions. The server guarantees they will not change during the lifetime of the device.
Service Changed characteristic nowadays on the server: In this case, a client needs to subscribe to the server-initiated updates past writing into the corresponding CCCD enclosed within the Service Inverse characteristic (see "Characteristic Descriptors"). This will permit the server to warning the client of any structural changes. If the customer and the server are bonded as described in "Security Modes and Procedures", the client can cache attribute handles across connections and look them to remain identical. If the devices are not bonded, the customer will demand to perform discovery every time it reconnects to the server.

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

GATT Attribute Data in Advertizing 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 attribute information hosted by the server within advertising packets, rendering one or more server attributes available to whatever observer or central while scanning.

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

As shown in Table 4-vii, to be able to circulate service data, a GATT server must include 2 different fields in the advertisement packet's Service Data section.

Table 4-7. Service Data Advertisement Type
Field	Length in bytes	Description
UUID	2, 4, or 16	The actual UUID identifying the information
Service Information	Variable	The information associated with the service identified by the UUID

The contents of the Service Information field can correspond to the complete or fractional value of a item characteristic or descriptor within the corresponding service. It is up to each contour specification to ascertain which, considering only the profile has sufficient knowledge nearly the data to determine which pieces of information are the most relevant to be broadcasted.

Features

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

To a certain extent, most of the features listed in this chapter are exposed in ane way or some other in most GATT APIs. GATT server APIs add the ability to populate the actual server with attributes, simply that is heavily implementation dependant and beyond the scope of this chapter.

Exchange MTU

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

This procedure is used only whenever either the client 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 cease that it can send packets longer than the default values that the specification requires. L2CAP volition then fragment these bigger packets into small Link Layers packets and recombine them from small Link Layers packets.

Service and Feature Discovery

As mentioned elsewhere in this chapter, the client has no knowledge nearly the attributes that might exist present in a GATT server when it offset connects to information technology. Information technology is therefore essential for the client to brainstorm by performing a series of package exchanges to determine the amount, location, and nature of all the attributes that might exist of interest. Equally discussed in "Attribute Caching", procedures in this category can, in some cases, subsequently be skipped.

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

Discover all primary services: Using this feature, clients can retrieve a full list of all primary services (regardless of service UUIDs) from the remote server. This is unremarkably used when the client supports more than than one service and therefore wants to discover out nigh the full service support on the server side. Because the client can specify a handle range when issuing the required request, it must set 0x0001-0xFFFF as the handle range to implement this characteristic, covering the total attribute range of the server.
Discover principal service by service UUID: Whenever the customer knows which service it is looking for (usually considering it supports but that single service itself), it tin simply look for all instances of a particular service using this characteristic, likewise 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 detect all primary services characteristic besides obtains the individual service UUIDs.

When the client has already constitute services on the server, information technology can proceed to perform relationship discovery (the discovery of any included services) with the post-obit feature:

Find included services: This allows a client to query the server near any 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 post-obit options:

Discover all characteristics of a service: In one case a client has obtained the handle range for a service information technology might be interested in, it tin then go along to retrieve a full list of its characteristics. The only input is the handle range, and in commutation, the server returns both the handle and the value of all characteristic declaration attributes enclosed within that service (run across "Characteristic declaration attribute").
Discover characteristics by UUID: This procedure is identical to the previous one, except the client discards all responses that practise not match the particular characteristic UUID it targets.

Once the boundaries (in terms of handles) of a target characteristic accept been established, the client tin can continue to characteristic descriptor discovery:

Discover all characteristic descriptors: Now in possession of a ready of handle ranges and UUIDs for some or all of the characteristics in a service, the client tin can use this feature to recall all the descriptors within a particular characteristic. The server replies with a listing of UUID and handle pairs for the different descriptor declarations (see "Characteristic Descriptors").

All the features in this section can be performed over open up, unsecured connections, because discovery is allowed for all clients without any restrictions.

Reading Characteristics and Descriptors

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

Read characteristic value or descriptor: This feature tin can be used to only read the contents of a characteristic value or a descriptor by using its handle. Simply the first ATT_MTU-1 bytes of the contents can exist read, because that is the maximum number of bytes that can fit in the response packet (i byte is reserved for the ATT operation lawmaking).
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, so that the characteristic value or the descriptor contents tin can be read in successive chunks. Multiple request/response pairs might exist required, depending on the length of the attribute value being read.

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

Read characteristic value using characteristic UUID: Whenever a client does not know the specific handles for the characteristics information technology might be interested in, it can read the values of all the characteristics of a specific type. The client only 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 it wants to obtain the value from, it can and so send a request with this set of handles and subsequently receive the values for all corresponding characteristics.

Reading characteristics and descriptors is subject to the security permissions and the server tin deny permission if the connection's security level does not lucifer the established requirements (see "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 feature 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 functioning code are included in the packet with the information) and the server volition acknowledge 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 past queueing several gear up write operations, each of which includes an offset and the data itself, and then finally writing them all atomically with an execute write performance.

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

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 whatsoever amount without any catamenia command mechanism kicking in (except of course for the native Link Layer flow control, since all traffic is subject to information technology). The server is free to silently discard them if information technology cannot process them or if the attribute permissions foreclose it from accepting it. The client will never know, but that is past common agreement. The only way for the customer to find out whether the value was written is to read information technology afterward the fact.
Reliable writes: Similar to the read multiple characteristic values characteristic, when a customer wants to queue write operations to multiple characteristic values, it issues a final package to commit the pending write operations and execute them.

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

Server-Initiated Updates

Server-initiated updates are the merely asynchronous (i.east., not as a response to a client'southward request) packets that tin 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 ability and bandwidth.

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

Feature Value Notification: Notifications are packets that include the handle of a feature value aspect forth with its electric current value. The client receives them and can cull to act upon them, but it sends no acknowledgement back to the server to confirm reception. Along with write without response, this is the only other packet that does not comply with the standard request/response catamenia control mechanism in ATT, as the server tin send any number of these notifications at any time. This feature uses the handle value notification (HVN) ATT parcel.
Characteristic Value Indication: Indications, on the other hand, follow the same handle/value format but require an explicit acknowledgment from the customer in the course of a confirmation. Note that although the server cannot send further indications (even for different characteristics) until it receives confirmation from the client (because this flows in the opposite direction than the usual request/response pairs), an outstanding confirmation does not impact potential requests that the client might transport in the concurrently. 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 respective CCCD before the server tin start sending them. "Client Characteristic Configuration Descriptor" describes this process extensively.

Security

"Security Modes and Procedures" discusses how the GAP hallmark procedure can exist used to transition from i security mode to a higher, more secure ane by using the different means available within the Security Manager and GAP. GATT transactions tin can act as triggers of such an hallmark procedure. As discussed in "Permissions", each aspect 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 crave no special security to exist accessed. This is true for both service and characteristic declarations, just not for descriptor declarations, which contain the relevant data directly in them, rather than in a split attribute. This is done so that clients that take not even so paired or bonded with a server tin at least perform basic service and characteristic discovery, without having to resort to performing security procedures. The attribute layout and data hierarchy of a server is non considered to be sensitive information and is therefore freely available to all clients.

When accessing a characteristic value or a descriptor declaration (also called service request), notwithstanding, a client can receive an fault response ATT bundle (see "ATT operations"), indicating that the connexion's current security level is not loftier plenty for the asking to be executed. The following ii fault codes are unremarkably used for this purpose and placed in the mistake response packet:

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

GAP and GATT roles are not linked in any way and can be mixed and matched freely, simply security procedures are always initiated by the GAP key (see "Security Managing director (SM)"). Therefore, depending on which peer is acting as a central and which as a peripheral, information technology tin be up to either the GATT customer or the GATT server to initiate the pairing, bonding, or encryption procedure in order to raise the security level of the connectedness. In one case the security level matches the 1 required by the attribute's permissions, the client can ship the asking again to be executed on the server.

GATT Service

Merely as GAP has its ain SIG-specified service that is mandatory for all devices (described extensively in "GAP Service"), GATT also has its own service (containing up to one characteristic) that must be included in all GATT servers. The optional service changed characteristic (introduced briefly in "Attribute Caching"), cannot be read or written, and its value is communicated to the client just through characteristic value indications.

As shown in Tabular array 4-viii, the value consists but of a handle range, which delimits a particular area of attributes in the server. This is the area that has been affected by structural changes and needs to be rediscovered by the client. The client will have to perform service and characteristic discovery in that area, because the attributes information technology can have buried might no longer be valid.

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

A client must enable indications on the respective CCCD for this characteristic before doing anything else, and then that it tin can become enlightened of any changes on the server's aspect structure.

If the server suffers a structural change in attribute layout, it will then immediately send a handle value indication to the customer and wait for the respective confirmation. In this manner, it tin can be certain that the client understands that cached attribute handles in that range might no longer be valid. If the attributes modify exterior the lifetime of a connection with a bonded device, the server will send the indication right afterward the connection is prepare, so that the client has a hazard to rediscover the afflicted area.

Source: https://www.oreilly.com/library/view/getting-started-with/9781491900550/ch04.html

Posted by: taylorshum1960.blogspot.com