GATT (Services and Characteristics) - Getting Started with Bluetooth Low Energy - page 72

Server-Initiated Updates
Server-initiated updates are the only asynchronous (i.e., 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.
There are two 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 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 flow control mechanism in ATT, as the server
can send any number of these notifications at any time. This feature uses the handle
value notification (HVN) ATT packet.
Characteristic Value Indication
Indications , on the other hand, follow the same handle/value format but require an
explicit acknowledgment from the client in the form of a confirmation . Note that
although the server cannot send further indications (even for different character‐
istics) until it receives confirmation from the client (because this flows in the op‐
posite direction than the usual request/response pairs), an outstanding confirma‐
tion does not affect potential requests that the client might send in the meantime.
This feature uses the handle value indication (HVI) and handle value confirma‐
tion (HVC) ATT packets.
The client must enable both types of server-initiated updates by writing to the corre‐
sponding CCCD before the server can start sending them. “Client Characteristic Con‐
figuration Descriptor” on page 62 describes this process extensively.
Security
“Security Modes and Procedures” on page 46 discusses how the GAP authentication
procedure can be used to transition from one security mode to a higher, more secure
one by using the different means available within the Security Manager and GAP. GATT
transactions can act as triggers of such an authentication procedure. As discussed in
“Permissions” on page 54 , each attribute within a GATT server has fine-grained, inde‐
pendent 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 characteristic declarations, but not for de‐
scriptor declarations, which contain the relevant data directly in them, rather than in a