Indication and Notification

Document created by Iliana Berenice Tejeda Hernandez Employee on Oct 16, 2015Last modified by josem.reyes.chaidez on Apr 26, 2016
Version 3Show Document
  • View in full screen mode

I want to share with you the information that I found about Indication and notification. I hope this information help you to understand more about these topics.

 

Indication and notifications are commands that could be send through the attribute(ATT) protocol. So, there are two roles defined at the ATT layer:

  • Client devices access remote resources over a BLE link using the GATT protocol. Usually, the master is also the client but this is not required or mandatory.
  • Server devices have the GATT database, access control methods, and provide resources to the remote client. Usually, the slave is also the server.

BLE standard define two ways to transfer data for the server to the client: notification and indication. Maximum data payload size defined by the specification in each message is 20 bytes. Notifications and indications are initiated by the Server but enabled by the Client.

  • Notification don't need acknowledged, so they are faster. Hence, server does not know if the message reach to the client.
  • Indication need acknowledged to communicated. The client sent a confirmation message back to the server, this way server knows that message reached the client. One interesting thing defined by the ATT protocol is that a Server can't send two consecutive indications if the confirmation was not received. In other words, you have to wait for the confirmation of each indication in order to send the next indication.

Figure 1. Indication/Notification

 

Nevertheless, server are not able to send indications or notifications at the beginning of the communication. First, client must enable notifications and indications permissions on the server side, so, the server is allowed to send indications or notifications. This procedure involves the client to write the Client Characteristic Configuration Descriptor (CCCD) of the characteristic that will be notified/indicated.

 

In other words, the client may request a notification for a particular characteristic from the server. Once the client enabled the notifications for such characteristic in the server, server can send the value to the client whenever it becomes available. For example, thinking in a heart rate sensor application connecting to Heart Rate smartphone application. Heart Rate Service can notify its Heart Rate Measurement Characteristic.  In this case, the sensor is the server while the smartphone is the client. Once devices are connected, smartphone application must set the notifications permissions of the Heart Rate Measurement Characteristic through its CCCD. Then, when smartphone application(client) set the CCCD withe notifications enabled, Heart Rate Sensor (server) is able to send notifications whenever a heart rate measurement is available. This same procedure is needed if the characteristic has indication properties.  At the end, the client is the one that allow the server to indicate or notify a characteristic.

Finally, it is worth to comment that unlike notification, the indication is more reliable, but slower, because the server sends the data but the client must to confirm 
when data is received.


1 person found this helpful

Attachments

    Outcomes