What are connection parameters?


There are three parameters that define a connection.


Connection Interval: the connection interval is the time between connection events. When in connection a central pings the peripheral as often as is defined by this connection interval. It is the peripheral's duty to respond to this ping in order for the central to consider the connection alive. At these intervals the client can perform it's reads/writes or the peripheral can perform notifications/indications. The interval can be anywhere from 7.5ms to 4s. When the peripheral requests an updated connection interval from the central, the peripheral sends an acceptable range. This increases the likelihood that the allowable window will overlap with what the central is able to provide.


Timeout: connection supervision timeout is the maximum time since the most recent received packet that the connection will be terminated by the central. The valid timeout range is 100ms to 3200ms.


Latency: slave latency is the number of connection events the peripheral is allowed to miss. If set to zero, the peripheral must respond to every connection event. The slave latency must be less than 500 and in the range from 0 to ( supervision_timeout / interval_max ) - 1 ) so that utilizing latency doesn't violate the timeout and cause a terminated connection. If there is no data to be sent, the peripheral will skip as many connection events as is allowed by the connection latency. Once there is data to be sent, every connection event is utilized to send that data until the tx buffer is clear, at which point the peripheral will resume skipping events. This scheme helps to save battery while maintaining throughput in the generally power-constrained peripheral device.




How do we control connection parameters?


Upon initial connection, there is no negotiation of parameters. The peripheral takes whatever the central gives. Upon successful connection, the peripheral may then request different parameters that are more suitable to it's functionality i.e. a higher throughput device will want a lower connection interval, while a power constrained device with low-throughput will want the longest possible connection interval with the most lenient latency.


No matter what, the central device always has final say over the connection parameters. It's important to note that the central can do absolutely nothing if it chooses. If the central has no intention of ever updating the connection parameters, it can simply reject any update requests that are sent its way. It is up to the peripheral to kill a connection if a central won't grant the parameters it needs to maintain its functionality and/or battery life.


There are two standard methods for the peripheral to request updated parameters:



Method 1: L2CAP Connection Parameter Update Request:


Step 1. The peripheral sends an l2cap packet to the central requesting updated parameters:


           void bleprofile_SendConnParamUpdateReq(UINT16 minInterval,

                UINT16 maxInterval, UINT16 slaveLatency, UINT16 timeout);


Example use:


           bleprofile_SendConnParamUpdateReq(32, 64, 0, 10);


These parameters are in special units:


     Min Interval = minInterval* 1.25 ms

     Max Interval = maxInterval* 1.25 ms

     Supervision Timeout = timeout * 10ms


This means that, as the peripheral, I am requesting a new connection interval between 40 and 80ms, a slave latency of 0, and a supervision timeout of 100ms.

Generally, this function is used in the connection up callback and it is recommended by the spec that it be done after GATT discovery and pairing/encryption.


Step 2. The central receives the request at the l2cap level. Different centrals will do different things at this point. By default, our 20736/7 stack will automatically grant whatever the client requested as long as it is feasible for the link layer to carry it out. On the other hand, resource constrained central devices will be far less likely grant the requested parameters. An iPhone, for instance, will not grant any connection interval below 30ms except for special use-cases.


Step 3. After the peripheral sends its request, it may want to hear back from the central once the process is complete. Of course, this is an optional step. But if the peripheral chooses, it can register a callback from the stack to be alerted when a connection parameter update is complete. To do so, declare a callback handler function with no parameters, and pass the function as a parameter to bleprofile_regAppEvtHandler_leConnUpdateComplete.


               Step A.      void paramUpdateHandler( void )


                              ble_trace3("ConnParam in Timeout: %d, %d, %d",





               Step B. bleprofile_regAppEvtHandler_leConnUpdateComplete((BLEPROFILE_NO_PARAM_CB) paramUpdateHandler);




Method 2: Peripheral Preferred Connection Parameters (PPCP):


Step 1. the peripheral, instead of sending an l2cap request, puts the same requested parameters into a GATT characteristic of the mandatory GAP service. This characteristic has a value 8 octets in length. This value is further split into 2 octets per connection parameter. The format can be found below, as implemented in a4wp_power_receiver.c:


             // Handle 0x2e: characteristic preferred connection param, handle 0x2f characteristic value.

             // 0x0050 (100ms preferred min connection interval)

             // 0x00A0 (200ms preferred max connection interval)

             // 0x0000 (0 preferred slave latency)

             // 0x03E8 (10,000ms preferred supervision timeout)



                  0x50, 0x00, 0xA0, 0x00, 0x00, 0x00, 0xE8, 0x03,


Step 2. the central will, in this case, need to first find the requested connection parameters. So, it must perform a GATT discovery on the peripheral and identify and have a special case for the existence of a PPCP characteristic. The exception to this is in Attribute Caching. If two devices are already bonded and the central cached the preferred connection parameters, there is no need to perform a GATT discovery. Once the characteristic is discovered by the client, different stacks will do different things. Our 20736/37 stack does not have built in support for this method of updating parameters. It is up to the app designer to discover the peripheral characteristic, read in the requested values, and handle, at the application level, whether or not to grant the requested parameters.


If, at the application level, it is decided to grant the requested parameters, or to grant new ones at least closer to the requested, the central device can call the following API:



           * \brief Connection update request

           * \ingroup blecm


           * \details This function issues HCI LE Connection Update Command.  This

           * command may be used in the client application if it needs to update

           * connection parameters when connection is already established and

           * required parameters are different than ones requested by the peripheral. 

           * When peripheral device requests some parameters using L2CAP message, stack

           * automatically replies and sets controller appropriately and there is no

           * need to use this function call.


           * \param connHandle HCI handle of established connection

           * \param connMinInterval Minimum value for the connection event interval

           * \param connMaxInterval Maximum value for the connection event interval

           * \param connLatency Slave latency for the connection in number of connection events

           * \param supervisionTimeout Supervision timeout for the LE Link

           * \param connMinEventLen Minimum length of connection needed for this LE connection

           * \param connMaxEventLen Maximum length of connection needed for this LE connection



           void blecm_ConnectionUpdate(INT32 connHandle, INT32 connMinInterval, INT32 connMaxInterval,

                            INT32 connLatency, INT32 supervisionTimeout, INT32 connMinEventLen,

                            INT32 connMaxEventLen);


Step 3. See Method 1 for Step 3 as it will be the same process to register for a parameter update callback to be alerted when the central has updated the parameters.


*some BLE centrals are known to not utilize this method. For instance, Apple devices will not look for a PPCP characteristic in their GATT discovery, they will only respond to l2cap requests.