How to respond to writing to Service Change CCC?

[obbe]

We're using the nRF52832 as a peripheral and server. A central and client (tablet) connects to the nRF52832.

Yesterday I noticed that sometimes the tablet will try to perform a write to handle 0x0D, which I figured out was the Client Characteristic Configuration, which lies under Generic Attribute -> Service Changed.

The value it was trying to write was 0x0200, which, if I'm not mistaken, is to enable notifications.

Two questions;

1) I'm guessing that the tablet is trying to make the nRF52832 notify the tablet when the services or characteristics themselves (GATT table?) changes. The services and characteristics themselves will never change. (Characteristics value will, naturally) Is it safe to ignore this request? What is the proper way to abide the request?

2) We're not doing anything actively on the tablet (except connecting), so this is likely at the driver level. Is there anything in particular that would prompt the tablet to occasionally try to write this?

Thanks.

---

Edit: We're not using bonding and the SoftDevice is S132 v3.0.0

Edit2: The full event details:

Handle: 0x000D

OP: 0x00000001

Auth. required: 0x00000000

Offset: 0

Length: 2

Data: 0x0200

[Edvin]

Hello,

1: The value 0x0200 is actually indications, and not notifications. It is similiar to notifications, but with some slightly different properties. Nothing you need to worry about in this characteristic.  The characteristic that the tablet enables indications is the service changed characteristic. This doesn't surprise me, since this service is used to let the connected device know whenever new services or characteristics are added, so that the central can do a new service discovery. You don't need to handle this actively.

2: As I said, I believe this is the OS on the tablet that wants to enable indications on the service changed characteristic so that it knows when it has to do a new service discovery, and when it is unnecessary.

[obbe]

Hello,

Thanks for the reply and confirmation!

I find the nomenclature of indication and notification really backwards and ambigious! (Not your fault, of course)

Still somewhat confusing that it only does this on some occasions, but maybe it assumes that it some circumstances the services are unlikely to change...

Are this request/behaviour processed at the SoftDevice level in some way?

If I receive this request and do want to enable indications for service changes, would that just mean I call sd_ble_gatts_service_changed when my app makes changes to the services?

[Edvin]

Hello

The main difference between notifications and indications is that BLE packets that are sent with notifications are ACKed in the link layer, while the indications has to be ACKed in the application layer. ACKing in the application layer means that you are absolutely 100% sure that the packet is received, and that the application has received and confirmed the packet. Notifications are also ACKed, so that means that no packets are lost. In general, I would recommend to use notifications, as it is secure (regarding packet loss), and the throughput is also very much higher with notifications than when using indications, if that is a concern of yours.

It isn't very easy to say why it only sometimes enabled indications on the service changed characteristic. Where do you see that it does that?

If you are doing development on a DK, tablets and phones tend to store some information regarding devices. So if you flashed another example that didn't have the service changed characteristic, the tablet may think it already know all the services and characteristics, and there is no service changed characteristic to tell it otherwise. Obviously, it is, but the tablet is not aware of it, because it has cached the already known services, and seeing that it is the same device (same address), it will not do a service discovery every time it connects unless it is aware of a service changed characteristic that is telling it that it has some new services.

The service changed characteristic is handled by the softdevice, so it is typically not something you need to take care of, other than including it in your project if you want to use it.

Best regards,

Edvin

[obbe]

Thanks! I was more referring to wording, especially "notification" which is very general and "indication" which I found quite non-descript.

Anyway, it occurred when I was randomly (on purpose) connecting/disconnecting with the same device (no restart, or anything).

We are having some sporadic problems with the tablet app thinking that our device is not connected, while in fact the device says it is connected, as does the OS (Windows). This happened to coincide with the issue manifesting, so I wanted to make sure it wasn't something missing on the firmware side, but we're assuming it something with the BLE library on Windows, or the driver itself. To be clear; the write request happens sometimes without the issue manifesting as well, but it seems to always happen when the issue occurs.