Multiple GATT Notifications - Any OTA order guarantee?

Hi Greg,

Thank you for the quick response.

I do not believe I am seeing retransmission.

In the case of retransmission, I would possibly observe something like this:

Server Value = 0   SN=0,NESN=1

Client Ack SN=1,NESN=1

Server Value = 1   SN=1, NESN=0

Client Nack   SN=0,NESN=1

Server Value = 1 SN=1,NESN=1

with "duplicate" or nearly duplicate payloads depending on the corruption.  Even in the case of retransmission, I should not see out of order payloads, as the server is essentially only allowed to resend the same LL Data packet until it is Ack'd.

What I think I am observing is OTA packets being transmitted out of the order which they were delivered to the controller through the HCI interface.  Is my understanding flawed?  Is it possible that out of order transmission can occur outside of the case of corruption/retransmission?

Thank you,

-Tyler

I have suffered with this out-of-order delivery that Tyler now independently verifies, but which I had mentioned long ago here:

http://e2e.ti.com/support/low_power_rf/f/538/t/158542.aspx#589503

It was very disappointing to see Nick L. totally disregard my observation and hack some "test" that  did not even check for in-order delivery, and thereby totally dismiss my concern as bogus. Is TI not interested in this issue because the BLE specification does not require packet delivery in the order they are sent from the sample application? If so, it is a heavy burden (I know, because I am correcting for it) for the sample application to have to add a packet identifier and "re-order" the packets on the receiver end.

Mr. Codesmith,

I am sorry if I have disappointed you. What I earlier posted was a quick test I did, where I truly did not care about in-order delivery, which obviously was proven to not be reliable. So we did some more tests posted on the wiki, found at http://processors.wiki.ti.com/index.php/CC2540_Data_Throughput, where we presented the maximum throughput of 5.9KB/s running the BLEv1.2, still not caring about in-order delivery though. What should be added is that with a Network Processor solution running HostTestRelease using HCI Commands via UART will probably not have the same throughput figures, since a HCI Command with 20 Byte notification takes ~3ms to transfer with 115200 Baudrate.

I know I just defended the throughput discussion, I cant answer for the mixed-order delivery you are seeing.

Br

Hi Tyler,

You are correct. I checked on controller behavior, and the same packet gets sent over and over until acked, so the out of order is happening before our controller tries to send it OTA.  This has been reported before, so we know this can happen.  I have not quantified this yet though. How often do you see it.  There must be a race condition in the host sw somewhere if it's not completely repeatable.   Do you see any different behavior depending on connection intervals, slave latency, or other settings?  I'll file a bug report, although for now I would recommend adding a seq number to report. 

BR,

-Greg

Hi Greg,

The only correlation I have found so far is that it often happens whenever I attempt to send a notification, but get the "MSG_BUFFER_NOT_AVAIL" error from the GATT_Notification interface.  Perhaps attempting and failing to allocate an hci buffer causes some issue with the buffer management.  I'll update if I see any other correlation.

Thank you for the response and the further investigation into the issue,

-Tyler

Any update on this issue?

Hi Gregs,

If the same packet gets sent over and over until acked, Thus block will hanppen in the BLE communication.

And if the NACK is continuous, how it can stop the packet sent over and over?

Looking forward to your reply.

Best Regrads!