KB: Connection Parameter Establishment


[RSL10 - Knowledge Base]


Question

While developing with the RSL10 platform, it was found that certain 3rd party client devices (ie. Smart Phones) would immediately drop the Bluetooth Low Energy connection after the RSL10 peripheral device sent a request to update the Connection Parameters.

The specific use-case called for a small Connection Interval (25ms) to be set/verified following a successful connection, which was communicated by the RSL10 peripheral to the client using a “GAPC_PARAM_UPDATE_CMD”. Why is this Disconnect happening?


Description

This Connection Parameter Update can be performed by either the peripheral or client device, but the parameters applied during the initial connection are always established by the client device. The client device can also make use of the peripheral’s Preferred Connection Parameters, if they are available through the Advertising Packet or Scan Response, but this is up to the 3rd party client implementation.

Once connected initially, the Connection Parameter Update can be used by either device to negotiate new parameters. This negotiation requires a specific set of events and handlers to be implemented within each device, ensuring that both successful and rejected updates are communicated to all in the proper way.

This process is implemented within the RSL10 using the following stack messages:

  • GAPC_PARAM_UPDATE_CMD (sent by initiator)
  • GAPC_PARAM_UPDATE_REQ_IND (received by reactor)
  • GAPC_PARMA_UPDATE_REQ_CFM (sent by reactor [accepted/refused])
  • GAPC_CMP_EVT (received by initiator [accepted/refused])
  • GAPC_PARAM_UPDATE_IND (received by both devices once parameters are accepted and applied)

Recommendation

After investigation, it was found that the client devices were not always capable of achieving this 25ms Connection Interval, and that of these, some were not communicating the appropriate rejection via a “GAPC_PARMA_UPDATE_REQ_CFM”. This resulted in the RSL10 applying its newly accepted parameters, while the client device would continue to run on the initially applied value.

The recommended fix is to ensure that the 3rd party client device (ie. Smart Phone) used is capable of achieving the requested Connection Parameters, and if not, will communicate this rejection properly to the RSL10, preventing this disconnect. If the RSL10 is required to work with a client device that cannot achieve these intervals (but rejects requests properly), a larger Connection Interval can be used.