*LL Procedure Collision* unexpectedly reported and hanging stack

First of all I’d like to report in which environment we are working in.

  • Custom firmware implementing a peripheral (slave) developed with
  • SDK 3.3. We have some constraints keeping us working with this.

In certain conditions we see the following behaviour (see trace below for details / overview):

  • The RSL10 answers an LLCP Connection Parameter Request (part of the Bluetooth LE Connection Parameter Update Procedure)
  • sent by the peer, which is the master (a smartphone that initiated the connection),
  • with an LLCP Reject Extended Indication including error code LMP Error Transaction Collision / LL Procedure Collision (0x23).
  • Subsequently an ATT Read By Type Request Packet (initiating a service discovery) sent from the master remains unanswered.

This is not expected, because of several reasons defined in the Bluetooth Core Specification (v5.0, p. 2685 and 2764).

  • This error code is only expected in case of collisions of procedures, i. e. the same procedures triggered simultaneously by the slave and the master. We can not see any procedure triggered by the slave in this case.
  • Even if there would be a procedure collision, the LLCP Reject Extended Indication including error code LMP Error Transaction Collision / LL Procedure Collision should be sent by the master, not the slave.

For us it would be interesting to know if you see when this LLCP Reject Extended Indication including error code LMP Error Transaction Collision / LL Procedure Collision is sent. Under which conditions would you expect this error code to be sent?

@we.f

In our CEVA document “RW-BLE-GAP-IS_2mbps.pdf” 5.3 has reference and MSC information.

  1. “If the LLC Connection Parameter Request feature is supported by both devices, then either Master or Slave can propose new connection parameter to the peer device, which it can accept/reject.”

    so we could say master/slave can reject. Not master only.

  2. For the LLCP Connection Parameter Request, if there is instant LMP collision detected, it will send error code (0x23) for rejection.

That’s right, I can also see that defined in the Bluetooth Core Specification (v5.0). Though, this is valid for error codes other than LMP Error Transaction Collision / LL Procedure Collision only, as defined on page 2685 (and indicated by the direction of the arrow in the message sequence chart above).

The second point you made seems legit.

We double-checked the communication and again could not find any suspicious procedure (neither Connection Update Procedure nor Connection Parameter Update Procedure) triggered by the RSL10 in this case. Can you see other conditions, in which you would expect the error code LMP Error Transaction Collision / LL Procedure Collision to be sent?

@we.f

Is this issue related with specific phone? or specific phone version?
In which “certain condition” you could see this issue? Is it repeatable?
Please let us know.

I guess we are quite at the point here and it would be interesting to know when the stack grabs the error code LMP Error Transaction Collision / LL Procedure Collision (0x23), puts it into a LL_REJECT_EXT_IND and sends it as a response to a LLCP Connection Parameter Request. Can you see that in the code of the stack?

The following is for the sake of context.

We tested this with a Google Pixel 5 and a Google Pixel 6, both running Android 12.

The certain condition in our case is met repeatedly, when

  • after a restart of the RSL10, which is
  • not paired with the smartphone,
  • prior to the connection with the error reported, there have been three connections.
    • #1
      • service discovery
      • read of characteristic, which does not require encryption
    • #2
      • service discovery
      • pairing
      • reads and writes on some characteristics, which require encryption
    • #3
      • service discovery
      • encrypt
      • reads and writes on some characteristics, which require encryption
    • #4 - connection as seen in the trace above

Please elaborate on the question raised in the beginning of this post.

@we.f
Firstly, we would like to fully understand what you are asking.

“ For us it would be interesting to know if you see when this LLCP Reject Extended Indication including error code LMP Error Transaction Collision / LL Procedure Collision is sent. Under which conditions would you expect this error code to be sent?

Our understanding is in which conditions you could generate this error message. Is that right?
If yes, we could see that you posted one reasons in the topic.

This message is generated by ceva stack message, if the stack sends param update during an another active LL procedure and it fails.

  1. You posted two phones and Android version. But you did not confirm if other phones or Android version still see this issue. — we need confirm this.
  2. You have shown 4 cases. All they all have this error message. Is our understanding correct?
  3. If phone received this error message, it keeps send connection param update, it will keep receiving this error message or not?
  4. If phone can receive this error message constantly, that should be some issue on RSL10.
  5. Which sample code, are you using on RSL10?
    For example #1 case.
    a. service discovery
    b. read of characteristic, which does not require encryption
    by using our sample (peripheral_server sample code) to test this, can you still see this message or not?
    If that is true, could you please send full sniffer file to let us debug.

I’m afraid to say that we actually asked for something else. The question raised in the beginning of the last post can be understood as the same question as the one you are referencing, put into other words and trying to get more to the point. Please answer this question.

Let me try to answer your questions one by one.

  1. We have observed the behaviour with the Google Pixel 5 and Google Pixel 6, both running Android 12. We did not test this with other phones, at first. In the meantime we could test it with a Google Pixel 3a, not showing the error behaviour.

  2. The points labeled with #1 to #4 do not show error cases, but connections leading to the error. A revised version of the discussed part of the previous post could state the following.

  3. Yes, the phone retries to open a connection, do the Connection Parameter Update Procedure and discover services, with the same result - LL Procedure Collision unexpectedly reported and hanging stack.

  4. Correct. We can see this behaviour repeatedly.

  5. We do not use a sample code on our RSL10, as stated before.

@we.f

  1. Please use our latest SDK3.5 since we have some update from BLE stack.
  2. It would be better to use our sample project to see if it has similar issue. – We need reproduce this issue. Would it be possible to send us the full sniffer file not just screen copy to let use have a look. Please use our onhelp@onsemi.com if you do not want to share the details in here.

Unfortunately we have some constraints keeping us working with SDK 3.3. The port of the custom application to SDK3.5 is not trivial and thus can only be done upon strong indication that the described issue is solved by it.

I just sent you the requested Bluetooth trace file per mail. Please use it to anticipate the irregularities causing troubles in the stack.

I’m coming back to this after such a long time as we recently ported our project to SDK 3.6. We tried again with the new version and still no luck - the same error is unexpectedly reported.

Do you think not the LLCP Connection Parameter Request could be the issue, but the preceding LLCP Encryption Start? We were bug-hunting another issue and found that LLCP Encryption Start or LLCP Encryption Restart preceded all the error cases of Link Layer Control Procedures under investigation, just like here.

@we.f

To solve this issue, we need reproduce the issue on our side.

  1. First method: please use or modify our project sample code, and check if it will have the same issue using our board RSL10 EVB. If yes, please share the software with us. We will reproduce the issue on our side.

  2. Second method: share you code so we can reproduce the issue on our side.

On-going support for this topic has been transitioned to our direct support team.

Once a solution has been reached, we will be uploading any relevant information to this topic in a reply.

#FollowUp