BLE_p2pServer Example: Why adding 2 to aPeerToPeerContext.P2PNotifyServerToClientCharHdle

[BGeor.1]

I would like to know why 2 is added to the P2PNotifyServerToClientCharHdle while checking for an attribute handle match in p2p_stm.c file. Later in the same function, 1 is added to P2PWriteClientToServerCharHdle. Is there an implicit assumption made here to add 2 to a notify handle and 1 to a write characteristic handle. 

P2PNotifyServerToClientCharHdle is declared as uint16_t. Why add 2 to an integer for matching to Attr_Handle.

static SVCCTL_EvtAckStatus_t PeerToPeer_Event_Handler(void *Event)

{

SVCCTL_EvtAckStatus_t return_value;

hci_event_pckt *event_pckt;

evt_blecore_aci *blecore_evt;

aci_gatt_attribute_modified_event_rp0 * attribute_modified;

P2PS_STM_App_Notification_evt_t Notification;



return_value = SVCCTL_EvtNotAck;

event_pckt = (hci_event_pckt *)(((hci_uart_pckt*)Event)->data);



switch(event_pckt->evt)

{

case HCI_VENDOR_SPECIFIC_DEBUG_EVT_CODE:

{

blecore_evt = (evt_blecore_aci*)event_pckt->data;

switch(blecore_evt->ecode)

{

case ACI_GATT_ATTRIBUTE_MODIFIED_VSEVT_CODE:

{

attribute_modified = (aci_gatt_attribute_modified_event_rp0*)blecore_evt->data;

if(attribute_modified->Attr_Handle == (aPeerToPeerContext.P2PNotifyServerToClientCharHdle + 2))

{

/**

* Descriptor handle

*/

return_value = SVCCTL_EvtAckFlowEnable;

/**

[STTwo-32]

Hello @BGeor.1 

The characteristics is made by 2 or 3 handles

• First handle is the Characteristic itself
• Second handle is the value of the characteristic
• If properties is Indicate or notify, a third value is added to manage the descriptor (Write enable or Disable ).

So, that's why the P2P notification needs to add 2.

Best Regards.

STTwo-32

[BGeor.1]

Hello STTwo-32,

Thank you for the quick reply. Interesting details. I want to understand how handles are managed little bit further. I would assume GATT server stores these handles in an attribute table when we call the following code.

COPY_P2P_NOTIFY_UUID(uuid16.Char_UUID_128);

aci_gatt_add_char(aPeerToPeerContext.PeerToPeerSvcHdle,

UUID_TYPE_128, &uuid16,

2,

CHAR_PROP_NOTIFY,

ATTR_PERMISSION_NONE,

GATT_NOTIFY_ATTRIBUTE_WRITE, /* gattEvtMask */

10, /* encryKeySize */

1, /* isVariable: 1 */

&(aPeerToPeerContext.P2PNotifyServerToClientCharHdle));

Above function returns one handle, aPeerToPeerContext.P2PNotifyServerToClientCharHdle. But it

looks like since it is a notify characteristic, there are two more consecutive handles(First

handle +1, First Handle + 2) stored in the attribute table automatically. Is that how it works?

Is there a documentation on this behavior. I don't see any description for this behavior

in AN5289. It doesn't look like core 6.0 spec is very clear about the implementation

details of how attribute handles are stored in the table.

[STTwo-32 · Accepted solution]

Hello @BGeor.1 

I think you should have a look at the description of the ACI_GATT_ADD_CHAR on the part 2.6.4 of the AN5270. On the BLE Core 6.0 spec, we have:

Characteristic descriptors are used to contain related information about the
Characteristic Value. The GATT profile defines a standard set of characteristic
descriptors that can be used by higher layer profiles. Higher layer profiles may
define additional characteristic descriptors that are profile specific. Each characteristic
descriptor is identified by the characteristic descriptor UUID. A client shall support the
use of both 16-bit and 128-bit characteristic descriptor UUIDs. A client may ignore any
characteristic descriptor declaration with an unknown characteristic descriptor UUID. An
unknown characteristic descriptor UUID is a UUID for an unsupported characteristic
descriptor.

Characteristic descriptors if present within a characteristic definition shall follow the
Characteristic Value declaration. The characteristic descriptor declaration may appear
in any order within the characteristic definition. The client shall not assume the order
in which a characteristic descriptor declaration appears in a characteristic definition
following the Characteristic Value declaration. 

Characteristic descriptor declaration permissions are defined by a higher layer profile or are implementation specific. A client shall not assume all characteristic descriptor
declarations are readable.

Best Regards.

STTwo-32

[BGeor.1]

Thank you STTwo-32 for pointing me to the right document. Looks like I was looking at the wrong document. Thanks again!