• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 51 subscribers
  • Views 4422 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Using BLE 4.1 "Connection Param Request Procedure" to reject LL_CONNECTION_PARAM_REQ

Jack Profit
Prodigy 70 points

I'm using theTI BLE stack (version 2_01_01_44627) as a BLE peripheral connected to an Android Marshmallow phone. I've observed that Marshmallow attempts to decrease the service discovery time by requesting to reduce the connection interval to 7.5ms once the initial connection is made (with 50ms connect interval). The 7.5ms rate is not supported by our BLE peripheral.

I expected to be able to use the BLE 4.1 "Connection Param Request Procedure" to reject the phones LL_CONNECTION_PARAM_REQ. However, it appears that the TI stack accepts the request with a positive LL_CONNECTION_PARAM_RSP regardless of the stack settings I have programmed. Perhaps I am confused about how to tell the TI stack what the limits are. I assumed that the following lines would instruct the stack to reject a 7.5ms connect interval. Am I wrong? Is there another way?

GAP_SetParamValue(TGAP_CONN_EST_INT_MIN, 20);

GAP_SetParamValue(TGAP_CONN_EST_INT_MAX, 1600);

Jack

  • 0
    TI__Guru** 105180 points
    Hello Jack,

    The LL_CONNECTION_PARAM_REQ procedure is for the Controller whilst the GAP settings are for the Host. See "5.1.1 Connection Update Procedure" in the BT4.1 core specification Vol 6, part B.

    Note that the Master may still use the LL_CONNECTION_UPDATE_REQ (which can't be rejected by the Slave) to change the connection parameters if the slave rejects the LL_CONNECTION_PARAM_REQ:
    "If the slave rejects the Connection Parameters Link Layer Specification Request Procedure, then the master may update the connection parameters using the Connection Update Procedure."

    As a test, you could disable the V4.1 controller in buildConfig.opt and test. You'll see the slave will reject the LL_CONNECTION_PARAM_REQ as an unknown opcode.

    Best wishes
  • 0 in reply to JXS
    Prodigy 70 points

    I'm a bit confused by parts of your response. Here is an excerpt from core specification Vol 6 Part B Section 5.1.7.2:

    --- QUOTE ON ---
    5.1.7.2 Responding to LL_CONNECTION_PARAM_REQ and LL_CONNECTION_PARAM_RSP PDUs

    Upon receiving an LL_CONNECTION_PARAM_REQ PDU:
    • The slave shall respond with either an LL_CONNECTION_PARAM_RSP PDU or an LL_REJECT_IND_EXT PDU.
    • The master shall respond with either an LL_CONNECTION_UPDATE_REQ PDU or an LL_REJECT_IND_EXT PDU.
    ...
    If the received LL_CONNECTION_PARAM_REQ PDU contains parameters that are not acceptable to the Link Layer, then the Link Layer of the device shall respond to the LL_CONNECTION_PARAM_REQ PDU with one of the following:

    • An LL_CONNECTION_PARAM_RSP PDU (if the Link Layer is the slave of the connection) or an LL_CONNECTION_UPDATE_REQ PDU (if the Link Layer is the master of the connection) containing alternative parameters.
    • An LL_REJECT_IND_EXT PDU with Error Code 0x20 (Unsupported LL Parameter Value).

    If the received LL_CONNECTION_PARAM_REQ PDU contains any fields that are out of valid range, then the Link Layer shall reject the LL_CONNECTION_PARAM_REQ PDU by issuing an LL_REJECT_IND_EXT PDU with Error Code 0x1E (Invalid LL Parameters).

    --- QUOTE OFF ---

    From this section, it seems clear that the slave (i.e. peripheral) is expected to respond with LL_CONNECTION_PARAM_RSP with alternative parameters or LL_REJECT_IND_EXT if parameters in the LL_CONNECTION_PARAM_REQ are unsupported. This is the behavior that I am trying to get. Are you saying that I cannot get the TI stack to follow this procedure?

    Also, in regard to your last comment, when I disable 4.1 support in the TI stack, the Android phone detects that the peripheral does not support version 4.1 (via the FEATURE_REQ / FEATURE_RSP messages). Once it knows the peripheral does not support 4.1, the phone does not send a LL_CONNECTION_PARAM_REQ at all. It just sends an LL_CONNECTION_UPDATE_REQ (which definitely cannot be rejected). Therefore, I cannot do what you suggest. Without 4.1 support, the phone will never issue the LL_CONNECTION_PARAM_REQ message at all.

    Finally, the conclusion you draw from your spec quote is misleading. From the spec: "If the slave rejects the Connection Parameters Link Layer Specification Request Procedure, then the master may update the connection parameters using the Connection Update Procedure." This means that if the slave rejects the newer Connection Parameter Request _PROCEDURE_ itself (by responding to LL_CONNECTION_PARAM_REQ with UNSUPPORTED or INVALID) then the controller is free to revert to the older (pre 4.1) "Connection Update Procedure". It does not imply that the controller will definitely ignore the slave's proper LL_CONNNECTION_PARAM_RSP / LL_REJECT_IND_EXT and go ahead and send the LL_CONNECITON_UPDATE_REQ anyway.

    Jack

  • 0 in reply to Jack Profit
    TI__Guru** 105180 points
    Hello Jack,

    Thank you for the reply. I will check on the behavior on the controller and update the post.

    In the meantime, can you post/share a sniffer trace showing the master sending the LL_CONNECTION_PARAM_REQ to the slave? This will be helpful.

    Best wishes
  • 0 in reply to JXS
    Prodigy 70 points

    Here is the wireshark trace showing the Android phone's attempt to negotiate connection parameters and TI's response of accepting anything suggested by master.

    I can't seem to figure out how to attach it directly to this site so here is dropbox link:

    www.dropbox.com/.../TI_CONN_PARAM_RSP.pcapng

    Jack

  • 0 in reply to Jack Profit
    TI__Guru** 105180 points
    Hello Jack,

    Thank you for the sniffer trace. For future reference, you can attach files directly via the "Use rich formatting" option.

    Regarding the behavior of the LL_CONNECTION_PARAM_REQ, I did confirm that the slave host will respond with the "LE Remote Connection Parameter Request Reply Command" (generates a LL_CONNECTION_PARAM_RSP back to the master) using the same parameters that the master supplied in the LL_CONNECTION_PARAM_REQ. Although this implementation is compliant to the specification (the TI Host/Controller is designed to support all valid connection parameters), it may not be optimal for the slave's application if there are system constraints outside of the Host/Controller. Therefore, we will make a change in a future SDK to allow the slave application to specify the conn parameters in which the host will respond. I don't have an ETA for this change at this time.

    Finally, in reference to the "misleading" comment, I do agree that the spec is not clear as to what the master must or should do when the slave indicates that the conn params sent in the LL_CONNECTION_PARAM_REQ are not agreeable to the slave - I apologize for not making this more clear. It is implementation specific as to how this is handled; one master may ignore and send the connection update anyway using params in the REQ, or another master may elect to do nothing (keep existing conn params) or use the params supplied by the slave in the RSP. Perhaps a future update to the core spec can make this more clear.

    Best wishes
  • 0 in reply to JXS
    Prodigy 70 points
    I appreciate your help looking into this issue.

    One final observation: I was able to hack together an LL_CONNECTION_PARAM_RSP on the slave side to prove to myself that Android would indeed honor the connection param negotiation process (and not just send a LL_CONNECITON_UPDATE_REQ anyway). The LL_CONNECTION_PARAM_RSP I created suggested 40ms connect interval (min) in response to Android's request for 7.5ms. Android properly reacted to this response and did NOT force a change. Instead it rejected my 40ms suggestion and left the connection parameters the way they were originally.

    Jack
  • 0 in reply to Jack Profit
    TI__Guru** 105180 points
    Jack,

    Thanks for sharing your observations on Android. That is certainly good to know that they honor the LL_CONNECTION_PARAM_RSP. Hopefully this is the case for all Android phones!

    Best wishes