How are CTS (0x1805) services discovered when acting as a GATT Server with an ESP32 GATT Client

[an-erd]

Hi, 

I'm using a nrf52832 based beacon with some sensors attached. To retrive the current time I use the CTS client. Actually, I'm following the ble_app_cts_c example to advertise, then perform a db_discovery and, if available e.g. from an iPhone, update the time.

Now i'm trying to understand the way the esp32 (ISP-IDF v4.2) acting as a GATT client is asked for the time. There is no current time server, so char 0x1805 is not found at all. But, I don't see any request in the gattc callback function. 

How is the process flow? Is the nrf52 (as soon as connected with all the security handled) asking the GATT client for the time?

On an iPhone everything is fine, NRF Connect app is obviously serving the time and nrf52 can retrieve this.

Regards

Andreas

[Kenneth]

The GATT client should do a database discovery of the GATT server, after the database discovery the GATT client can write and read the characteristic values it may want to. Typically if any of the characteristics in the GATT server require security to read and write, then this will also trigger a bonding procedure in parallel.

Best regards,
Kenneth

[an-erd]

Let me give some more information on my question:

Peripheral: sensor beacon based on nrf52832, collecting sensor data, advertising, connectable

Central: esp32 based, reading the advertisements of the peripheral, connects to the sensor to get long-term data as a bulk download

Only the esp32 connects to the beacon but not vice versa. In this case, the esp32 is the client, and the beacon the server

As soon as the esp is connected to the beacon, the beacon uses CTS (current time service), now acting as a client, to ask the counterpart, which is the esp, which is now acting as a server (*)

I'd now figure out how this is achieved. As soon as the central is connected to the peripheral with all security done, what happens next:

Question1) is the existing connection used for the vice verse communication as stated in (*), or will there be another connection?

Question 2) on the esp32 side, there are now a GATT Client (getting sensor data from beacon) and a GATT Server (serving the time the CTS (current time service client) asks for?

Regards

Andreas

[Kenneth]

Hi,

Just to make sure the naming is consistent:

The esp32 operate in the GAP central role, while the nRF52 here is the GAP peripheral role. It is the central that can scan and initiate a connection with a peripheral. The GAP role does not change, and the GAP role is independent of GATT. GATT is the layer where data are actually transferred.

In your case the nRF52 at least is a GATT client for the CTS (though it may also have a GATT server), the esp32 is GATT server for the CTS (though it may also be GATT client for services and characteristics on the peer for other BLE profiles).

If you want to understand how the CTS works, you would need to check the BT SIG profile for the CTS. You can find a description in our nRF5 SDK how our examples works (though you can change and modify this as you best see fit):
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/ble_sdk_app_cts_c.html

Best regards,
Kenneth

[an-erd]

Ok, understood so far.

So for question 1) the existing communication will be used.

and for question 2) there will be both, a GATT server and a GATT client on the GAP central role.

Although on the GAP central role the GATT server is connected (Evt 14), I don't see any requests for the CTS service (so a 0x1805)? 

What should I see on the GAP central GATT server?

Regards

Andreas

[Kenneth]

Looking at the \ble_app_cts_c example I can find that the application is calling db_discovery_init() during initialization.

This means that on connection event with a peer the nRF52 will do a full database discovery of the peer.

In the project I can find that the ble_cts_c will register a callback if the current time service is found on the peer. This is done by calling ble_db_discovery_evt_register() in ble_cts_c_init(). This will ensure calling on_cts_c_evt() in main.c if found CTS is found on the peer.

What happens on the GAP central is unknown (not nordic implementation).