• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 246 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2642R-Q1: Delete bonding data during communication

Yoshiaki Otsu
Prodigy 130 points
Part Number: CC2642R-Q1

hello

We implement BLE Service using SIMPLE LINK-CC13X2-26X2-SDK_6.30.01.03 and CC2642R-Q1.

We would like to implement the BLE device's ability to perform session disconnection after removing bonding data.

If GAPBOND_ERASE_BOND_IN_CONN is set to TRUE and bonding data shared with a communicating Peer is deleted, how does this affect that BLE session?

Immediately after deletion, does the communication behave as if the LTK is lost?(In other words, the session is disconnected.)
Or does the communication remain encrypted until the session is disconnected?

  • +1
    TI__Mastermind 37340 points

    Hi Yoshiaki-san,

    I believe if you delete the keys of the link you have created and already encrypted, then the link will remain encrypted. That said, I would not recommend it. Generally there can also be a risk of loosing connection events when erasing a bond while in a connection as this invokes a flash operation potentially and can be a blocking operation where the BLE stack is not able to service connection events for a period of time until the operation is finished. Our first recommendation is to, if possible, do a bond erase after all connections have been terminated. 

  • 0 in reply to Evan Wakefield
    Prodigy 130 points

    Thanks for the answer.
    Let me ask a few more questions.
    We are using a BLE device as Peripheral.

    I am aware that there will be no tolerance on Connection Interval due to the Blocking API being used, is this correct?

    If the above is correct, then the rewrite performed by the BLE stack is expected to be around 100ms, even with compression, so am I correct in understanding that the worst case is to miss a Connection Event from Central during that blocking process?
    That is, if the Connection Supervision Timeout has not elapsed after the blocking process, the link will be maintained.

  • +1 in reply to Yoshiaki Otsu
    TI__Mastermind 37340 points

    Hi Yoshiaki-san,

    Generally I communicated about 150ms blocking, but it depends on aging and so on. Worst case you will miss connection events, so you should design your system to account for an link supervision timeout that should be large enough to sufficiently tolerate this with some margin add as well. Margin is important anyways as if you have a device on the edge of a connection, it's expected to anyways miss a few connection events. I like to select a supervision timeout of around 1 to 3 seconds with phones, as their connection intervals are anywhere between 30 and 50ms. But in the cases of larger connection intervals, a larger STO should be selected. 

  • 0 in reply to Evan Wakefield
    Prodigy 130 points

    Thank you for your detailed reply.
    I understand the issues.