Bluetooth: different transaction collision

[cvinayak]

Certain phones violate Bluetooth Procedure Collision rules. There is nothing the Bluetooth controller can do than disconnect with reason, different transaction collision.

As a workaround to IOP with such phones, may be:

• Make the initiation of PHY update procedure (and Connection Parameter Request) on connection establishment optional in host Kconfig.
• Have a Bluetooth API to switch to 2M PHY which the application can do when needed (could be immediately on connection establishment callback)
• On disconnection reason (0x2a) different transaction collision, setup a random back-off timeout (in connection event count resolutions) within a set range that will be used the very next connection establishment to setup a deferred PHY update procedure.
• Remember this value if the connection leads to bonding, and use this for future connections with this phone.
• On consecutive disconnect reason, different transaction collision, use new random back-off delays.

Drawback:

• ugly, best is the phone fix their firmware
• Initial bonding may require multiple connection attempts

[nashif]

@cvinayak moving this to 1.14, is that ok with you? Can you give details on what is planned to be done here.

[cvinayak]

@nashif yes, this issue be moved to 1.14.

Make the initiation of PHY update procedure (and Connection Parameter Request) on connection establishment optional in host Kconfig.

This has been done in #9654 for 1.13. Sufficient for now.

Rest of the points needs discussion (if nothing happens by 1.14, we close it as wont fix).

[cvinayak]

Closing this due to inaction.