Designed behaviour of S110 when notifications(CCCD) are disabled with packets queued?

[Peter Myerscough-Jackopson]

What is the designed (/actual/required due to the specification) behaviour of the Bluetooth stack S110 when notification packets are queued and the CCCD controlling the attribute has its notifications disabled before they are sent?

e.g.

1. I queue up six notification packets.
2. In the next transmission interval three are sent, and the CCCD is written to, disabling the attribute.

What happens to the other three packets? and is this designed/stable behaviour I can rely on between S110 releases, or do you intend on changing it?

I'm trying to ensure minimal data loss and confirm reception of data from my internal buffer before deleting it.

Thanks

Peter

[Hung Bui]

@Peter: As far as I know, the stack will continue to send these 3 packets that already queued in the buffer. We don't have a mechanism to stop and trash them.