CC2541: Will there be any Physical level ACK packet even for Notification (But not ATT level Confirmation which is required for Indication)

Vishnu Beema

Part Number: CC2541

Hello Eirik,

I am not sure how to change the settings so that I can keep the ticket under open. Since the ticket is under resolved I am added my query separately.

https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/787376#pi320995filter=answers&pi320995scroll=false

As per above link, my query is

Need more clarity on your statement "Any packet transmitted must be acknowledged before the next packet is transmitted". Is this statement even valid for "Notify" packets.

I was going through BLE Core4.2 Vol3 Part F (ATT) Section 3.3.2 (Page 2171) and co-relating with IEEE 802.15.4 Retry, Error indication to application etc.

Since Notification packets are to a specific Client, whether there will be any Physical level ACK from client ?. Whereas for Broadcast packets from Server or Client, there wont be Physical layer Ack. If this is true (Physical Ack from Client), then what layer of Client will be sending "Confirmation" packet for "Indication" packet from Server. Is this from "ATT" layer of stack ?

Even in TI SmartRF BLE sniffer I am seeing "ACK Status" as "OK" for Notification packets. What does it mean. To my understanding, in Connection interval, at Anchor point Master will send a packet and slave will send a empty PDU packet in response, these are for Synchronization. For both M->S and S->M there wont be any separate "Ack" packets. But for "Notify" will there be any separate Physical layer Ack packets.

Thanks & Regards

Vishnu Beema

over 6 years ago

0 J Lindh over 6 years ago

TI__Guru 57865 points

Hi Vishnu,
Both notification and indication packets will be acknowledged by the Link Layer per the BT core spec. In fact, all packets will, so no packet drops in Bluetooth low energy at all. So re-transmit will occur if the packets don't come through. In addition, Indication requires App level acknowledgement. Does this help your understanding?

0 Vishnu Beema over 6 years ago in reply to J Lindh

Expert 1450 points

Hello Lindh,

Interesting to know about this point where even Notification will have Link Layer Ack. For better understanding on your comments, please find my below queries.

1) Ack to my understanding is the Ack over the air from Link Layer of remote device, but not from low level layer to upper level layer within same device.

2) "Indication required App level acknowledgement". So for Indication will there be two Acks. One is at ATT level Confirmation and the other is Link Layer Ack.

3) "no packet drops in Bluetooth low energy at all", In this case what is the advantage of using Indication, even if there wont be packet drops with Notification itself.

4) With respect to Notification, I did few experiments. I kept Connection interval min/max as 10ms and 250ms. In each packet I am sending 20 bytes. I see few packet misses. As show in below snapshot,

0x24 + 20 = 0x38

0x38 + 20 = 0x4C

0x4C + 20 = 0x60

After 0x60 I am seeing only 0x9C. Here two packets are missed. Is this something not able to buffer at stack level. If yes, how to detect the error conditions. As part of GATTServApp_ProcessCharCfg() under SimpleProfile_SetParameter() do I need to pass "taskID" as simpleBLEPeripheral_TaskID rather than INVALID_TASK_ID.

Thanks & Regards

Vishnu Beema

0 J Lindh over 6 years ago in reply to Vishnu Beema

TI__Guru 57865 points

Hi,
1. Correct.
2. Correct, and you will need to implement the application level acknowledgement for indications.
3. The benefit with indications comes when you need to pend on processing, i.e. Over the Air download (OAD). For most use cases, notifications are good enough.
4. In your screenshot, I see that packet 1038/1039 show Unexpected NESN, which means that the sniffer actually missed the packets. Are you able to populate an array or such on the receiving side to verify?

0 Vishnu Beema over 6 years ago in reply to J Lindh

Expert 1450 points

Hello,

Thanks a lot. I got what you meant. TI sniffer may miss few packets receiving. This does not mean App did not receive. I saw the log file and all packets are received.

I am new to BLE and trying to get as depth as possible. I have gone through Core_4.2 specification and other online information. Sorry some of my queries may be silly, but I am trying to get confirmation from knowledgeable persons like you and other TI support team, rather than assumptions. My further queries are

1) "you will need to implement the application level acknowledgement for indications". To my understanding, Master ATT layer will generate Confirmation packet automatically. What do you mean by application need to be implemented.

a) Whether Master application can send any data as part of ATT layer Confirmation. I don't think so as "3.4.7.2 Handle Value Confirmation" (Page 2200) of Core_v4.2 does not have any payload filed.

2) In gatt.h for GATT_Notification() I am seeing below statement.

“A notification may be sent at any time and does not invoke a confirmation”

a) Without Anchor point from Master as reference, how can slave send Notification at any time.

b) At starting of Connection interval, M-> S and S-> M as exchanged in Connection event. To my understanding Master will go to sleep for remaining Connection interval or service/schedule Connection interval for other device connected.

c) In Sniffer log after Notification (S -> M) I am seeing Empty PDU from M -> S. Even LLID is 0x02 which indicates complete packet without fragmentation. In this case how come Master enables its receiver and received next Notification within same Connection Interval. I thought after receiving first Notification, Master will send Link Layer level Ack and then go to sleep for remaining Connection interval. How-come back to back Notification packets are possible within same Connection Interval.

Thanks & Regards

Vishnu Beema

0 J Lindh over 6 years ago in reply to Vishnu Beema

TI__Guru 57865 points

Hey,

1. You can look at the Glucose Collector sample application so see how it's implemented. I.e. you will need to addGATT_RegisterForInd (uint8 taskId) during initiation and then issue the following upon processing the indication;

// Send confirm for indication
if ( pMsg->method == ATT_HANDLE_VALUE_IND )
{
ATT_HandleValueCfm( pMsg->connHandle );
}

You are correct that there is no payload attached to it. It's just a confirmation.

2. It can't send at "any time". The device will have to wait for a connection event, defined by the Master device by using connection intervals.Small connection event is less latency although higher power consumption over time. You should read the software developers guide in addition to the core spec. Note that empty connection events is what is keeping devices in synch, they will always occur regardless if you send data or not. It's how a BLE communication is fundamentally defined.

0 Vishnu Beema over 6 years ago in reply to J Lindh

Expert 1450 points

Hi Lindh,

Thank you for confirmation.
Yes, even I have gone through SWRU271 BLE Software developers guide. I got clarification for point 'a'. Even SWRU271 do not mention about back-to-back Notifications.

But still I have confusion on point 'b' & 'c'. How come there can be back-to-back notifications in same Connection interval.

b) At starting of Connection interval, M-> S and S-> M as exchanged in Connection event. To my understanding Master will go to sleep for remaining Connection interval or service/schedule Connection interval for other device connected.

c) In Sniffer log after Notification (S -> M) I am seeing Empty PDU from M -> S. Even LLID is 0x02 which indicates complete packet without fragmentation. In this case how come Master enables its receiver and received next Notification within same Connection Interval. I thought after receiving first Notification, Master will send Link Layer level Ack and then go to sleep for remaining Connection interval. How-come back to back Notification packets are possible within same Connection Interval.

Thanks & Regards
Vishnu Beema

0 J Lindh over 6 years ago in reply to Vishnu Beema

TI__Guru 57865 points

Vishnu Beema said:
b) At starting of Connection interval, M-> S and S-> M as exchanged in Connection event. To my understanding Master will go to sleep for remaining Connection interval or service/schedule Connection interval for other device connected.

Correct, although as long as Master or Slave has "More Data" (MD) bit set, the will continue the communication in the existing connection event.

Vishnu Beema said:
c) In Sniffer log after Notification (S -> M) I am seeing Empty PDU from M -> S. Even LLID is 0x02 which indicates complete packet without fragmentation. In this case how come Master enables its receiver and received next Notification within same Connection Interval. I thought after receiving first Notification, Master will send Link Layer level Ack and then go to sleep for remaining Connection interval. How-come back to back Notification packets are possible within same Connection Interval.

Same here, the MD bit indicates that there are more data to be sent.

0 Vishnu Beema over 6 years ago in reply to J Lindh

Expert 1450 points

Thanks a lot for your inputs. I overlooked MD bit.

Thanks & Regards

Vishnu Beema

Bluetooth®︎

Bluetooth forum

CC2541: Will there be any Physical level ACK packet even for Notification (But not ATT level Confirmation which is required for Indication)