Bluetooth Low Energy BLE Connection Event Parameters and Update Methods

Bluetooth States and Basic Connection Process

0.1 Bluetooth States:

Bluetooth has 5 states:

Standby State: No devices are connected, and no data is being transmitted or sent.

Advertising State: Periodic advertising state.

Scanning State: Actively searching for broadcasting devices.

Initiator State: Actively initiating a connection.

Connected State: Already connected.

0.2 Bluetooth Connection Process

Figure 1 BLE Connection Process

1. Connection Events

In a connection, the Master device sends packets to the Slave device during each connection event. A connection event refers to the process of the Master and Slave devices exchanging packets. Connection events occur at a fixed frequency, with each packet waiting 150μs after the previous packet is sent.

The connection interval determines the interaction interval between the Master and Slave devices; it refers to the time distance between the start of two consecutive connection events, which can be any value between 7.5ms to 4s, but must be a multiple of 1.25ms. To determine the actual interaction interval between the Slave and Master devices, the Slave latency parameter is used, which represents how many connection events the Slave can ignore before it must listen.

As shown in the figure below, connection events are separated by connection intervals. Starting from when the Master device sends a packet, each connection event can continue until the Master or Slave device stops responding. No packets are sent between the Master and Slave devices outside of connection events.

Figure 2: Communication Timing Diagram After Successful Connection (One packet sent per connection event)

For example, if the connection interval is 100ms and the Slave latency is 9, then the Slave can ignore 9 connection events but must listen to the 10th connection event. In other words, the Slave must listen once per second, and the minimum monitoring timeout should be 1010ms. Conversely, in another extreme example, if the maximum monitoring timeout is set to 32s, for a link with a 100ms interval, the Slave latency must be less than or equal to 319.

Figure 3: Communication Timing Diagram After Successful Connection (Multiple packets may be sent per connection event)

Figure 4: Details of Connection Events

However, if the Slave latency is set to the feasible maximum, the Slave will only have one opportunity to listen to the Master device before the monitoring timeout occurs, which is not a good idea. Therefore, it is recommended to allow the Slave at least 6 listening opportunities. In the previous example, if the connection interval is 100ms and the Slave latency is 9, then the monitoring timeout should be at least 6s, ensuring that the Slave has at least 6 listening opportunities before the link eventually disconnects.

2. Connection Parameters

2.1 Introduction

After the Master and Slave devices establish a connection, all data communication is conducted during connection events.

Figure 5: Details of Connection Interval

The spikes represent connection events, while the rest is the sleeping time. Most of the time after establishing a connection, the device is in a sleeping state, which results in low power consumption, while during connection events, the power consumption is relatively high, which is one of the reasons why BLE is energy-efficient.

Each connection event requires the Master to initiate a packet, which is then replied to by the Slave.

The Master is the host, abbreviated as M; the Slave is the peripheral, abbreviated as S. The M->S or S->M seen during packet capture indicates communication from the host to the Slave or from the Slave to the host.

2.2 Connection Parameters:

By modifying the following three parameters, the transmission speed and power consumption during the BLE connection process can be set.

1. Connection Interval

Connection Interval (GAPROLE_MIN_CONN_INTERVAL && GAPROLE_MAX_CONN_INTERVAL) is the interval used in the connection between two BLE devices using frequency hopping. The two devices use specific channels to send and receive data, and after a period of time, they switch to new channels (the BLE protocol stack’s link layer handles channel switching). Sending and receiving data after switching channels is referred to as a connection event. Even if no application data is sent and received, the two devices will still exchange link layer data (empty PDU) to maintain the connection.

This connection interval refers to the time interval from the start of one connection event to the start of the next connection event. The connection interval is measured in units of 1.25ms, with a range of 6 to 3200, which corresponds to 7.5ms to 4s.

2. Slave Latency

Slave Latency allows the Slave to skip a certain number of connection events when there is no data to send, without needing to respond to the Master’s packets, thus saving power.

Range: 0 to 499

More detailed usage analysis is as follows:

Figure 6: Details of Slave Latency Parameter

When Slave Latency = OFF, which means Slave Latency is 0, the Master sends a packet, and the Slave must reply. If it does not reply, the Master will assume that the Slave is not receiving properly.

When Slave Latency = ON, meaning Slave Latency is not 0, in the diagram, Slave Latency is 3. The Master sends a packet, and when the Slave has no data to reply, it will ignore 3 connection events. After receiving the Master’s data in the 4th connection event, it will reply to the Master. If the Slave has data to send, it will wake up and reply immediately, meaning that even if Slave Latency is 3, if the Slave has data to respond to when the Master sends the second packet, it will reply to the Master immediately instead of waiting until the 4th connection event after ignoring 3 connection events.

3. Supervision Timeout

This parameter sets a timeout period. If no communication occurs within this time, the connection will automatically disconnect.

The unit is 10ms, and the range of this variable is 10 to 3200, which translates to a time range of 100ms to 32s.

The connection interval, Slave latency, and supervision timeout must satisfy the following formula:

Supervision Timeout > (1 + Slave Latency) * (Connection Interval)

This formula must be satisfied, otherwise the connection will disconnect abnormally.

The impact of these three connection parameters under different conditions on communication speed and power consumption:

Shortening the Connection Interval increases the frequency of communication between Master and Slave, improving data throughput speed and reducing data sending time, but it also increases power consumption.

Increasing the Connection Interval reduces communication frequency, lowers data throughput speed, increases data sending time, and reduces power consumption.

Reducing Slave Latency or setting it to 0 means that the Slave must reply to the Master’s packets in every Connection Event, which increases power consumption but improves data sending speed.

Lengthening Slave Latency reduces power consumption but lowers data sending speed.

3. Connection Parameter Update Procedure

When a connection is established, the Master device sends connection parameters through a link request data packet. After the connection has been active for a while, the connection parameters may no longer be suitable for the services currently in use. For the sake of efficiency, the connection parameters need to be updated. Instead of first disconnecting and then reconnecting with new parameters, there is a simpler way to update parameters in the link, as shown in the figure below:

Figure 7: Connection Parameter Update Procedure

To do this, the Master device sends a connection update request to the Slave device, namely LL_CONNECTION_UPDATE_REQ, which carries the new parameters. These parameters do not need to be negotiated; the Slave can either accept and use them or disconnect the link. The connection update request includes a portion of the parameters used when the connection was first created, along with a new parameter called Instant:

1. Transmission Window Size

2. Transmission Window Offset

3. Connection Interval

4. Slave Latency

5. Supervision Timeout

6. Instant

The Instant parameter determines the start time for the connection update. When sending the message, the Master device selects a future time point for the connection update and includes it in the message. Upon receiving the message, the Slave will remember this future time point and switch to the new connection parameters at that time. This helps address one of the biggest issues in wireless systems — packet retransmission. As long as the number of packet retransmissions is sufficient and ultimately succeeds in transmission before the Instant, the process will execute without issue. However, if the packet fails to complete transmission by that time, the link may be lost.

Since Bluetooth Low Energy does not have a clock, the determination of the instant time relies on counting the number of connection events. Therefore, each connection event will be counted, with the first connection event on the link (the one immediately following the connection request) being noted as 0. Thus, the instant is essentially a counter for connection events, and when the corresponding connection event arrives, the new parameters will be used. To ensure the Slave receives the packet, the Master must provide sufficient opportunities. However, regardless of the Slave latency, it should ensure at least 6 data sending opportunities. This means that if the Slave latency is 500ms, the instant is typically set to some future time point 3s later.

When the instant arrives, the Slave begins listening to the sending window, just as in the connection establishment process. The Master device can adjust the Slave’s timing, overall not exceeding 1.25ms. However, since the Master device may still be a classic Bluetooth device, this adjustment allows it to coordinate with the low-power Bluetooth Slave device for better scheduling. Once this process is complete, the new connection interval, supervision timeout, and Slave latency values will come into effect.

4. Modifying Connection Parameters

The “Connection Parameter Update Request” command allows the Slave device to update the link layer connection parameters, as shown in the figure below. These parameters include the connection interval (the frequency at which the Slave device wishes the Master device to allow it to send packets), Slave latency (the maximum number of connection events the Slave can ignore from the Master), and supervision timeout.

Figure 8: Modifying Connection Parameters

In a connection, if the Slave wishes to modify the current connection parameters, it can use this command. For example, if the connection event interval may be too fast, resulting in excessive power wastage. This is not a problem when the Slave latency is large, but if not, the Slave will frequently listen to the link. This is necessary in some cases, such as during the initial binding between devices, exchanging multiple packets, exploring services, and device characteristics. However, in many other cases, minimizing the number of connection events the Slave must listen to is crucial for improving battery life.

The connection parameter update request command is only used for the Slave to send to the Master, as the Master can initiate link layer connection parameter update control (Connection Parameter Update Control) procedures at any time. If this command is sent by the Master device, the Slave will interpret it as an error and return a “Command Not Understood” reason code in a “Command Reject” command.

The Slave can send this command at any time; if the Master device can modify the connection parameters upon receiving this information, it will return a “Connection Parameter Update Response” with the result code set to “Accepted”. Subsequently, the Master device will initiate the link layer connection parameter update control procedure.

Of course, if the Master device does not agree with the Slave’s requested parameters, it can send a connection parameter update response command with the result code set to “Rejected” to deny the request. At this point, the Slave has two options: either accept the parameters currently being used as desired by the Master or terminate the connection. Terminating the connection may seem drastic, but if the Slave would run out of power in a week using the current parameters, while the requested parameters would last for years, it is clear that the reasonable choice is the latter.

When modifying connection parameters, to reduce the likelihood of the Master rejecting the Slave’s request, a range of acceptable parameters can be set in the request. A well-designed Slave will be willing to accept a wide range of parameters. Since the Master device may be busy with tasks such as real-time audio connections or high-quality voice connections, it can accept connection interval parameters within a certain range. The acceptable interval parameters may vary depending on the current task, potentially differing from the parameters used during the last device connection.

To increase the chances of the Master accepting the connection parameters, another method is for the Slave to provide a reasonable Slave latency. The Master can choose the most suitable connection event interval, while the Slave uses the optimal power consumption Slave latency parameter.

For example, if the Slave wants to synchronize every 600ms, it can request a connection interval parameter range of 100ms to 750ms and include a Slave latency of 5. If the Master chooses 100ms, the Slave synchronizes every 6 connection events; if the Master chooses 200ms, the Slave synchronizes every 3 connection events, achieving its desired 600ms interval; if the Master chooses 300ms, the Slave ignores synchronization every other connection event; if the Master chooses 400ms, the Slave synchronizes every 400ms.

Special Features of This Article

5. Case Program Interpretation

Below, we introduce the method for modifying connection parameters in TI’s CC2540 and CC2541.

(1) Automatically Requesting Modification of Connection Parameters After Successful Connection Establishment.

Taking the “simpleBLEPeripheral” project in TI 1.4.0 protocol stack as an example, the following macro is defined in the application file “Projects\ble\SimpleBLEPeripheral\Source\simpleBLEPeripheral.c”:

// Whether to enable automatic parameter update request when a connection is formed#define DEFAULT_ENABLE_UPDATE_REQUEST         TRUE

From the above comment, we can see that the role of this macro is to determine whether an automatic request for connection parameter updates is needed when a connection is established. When set to “TRUE”, it is needed; when set to “FALSE”, it is not. So how does this macro work? Let’s take a look.

1. In the “SimpleBLEPeripheral_Init” initialization method in the application file “Projects\ble\SimpleBLEPeripheral\Source\simpleBLEPeripheral.c”, the macro is processed as follows:

uint8 enable_update_request = DEFAULT_ENABLE_UPDATE_REQUEST;GAPRole_SetParameter( GAPROLE_PARAM_UPDATE_ENABLE, sizeof( uint8 ), &enable_update_request );

1. We look at the relevant operations inside the “GAPRole_SetParameter” method, which are in the file “Projects\ble\Profiles\Roles\peripheral.c”, as shown in the source code below:

case GAPROLE_PARAM_UPDATE_ENABLE:    if ( (len == sizeof ( uint8 )) && (*((uint8*)pValue) <= TRUE) )    {        gapRole_ParamUpdateEnable = *((uint8*)pValue);    }    else    {        ret = bleInvalidRange;    }    break;

1. From the above code, it is not difficult to see that the macro we set is assigned to the global variable “gapRole_ParamUpdateEnable”. Below, we search for the places where this global variable is used in this file and find it is used in the following source code:

// After the connection is successfully established, the event returned by the lower layercase GAP_LINK_ESTABLISHED_EVENT:{    gapEstLinkReqEvent_t *pPkt = (gapEstLinkReqEvent_t *)pMsg;    if ( pPkt->hdr.status == SUCCESS )    {        VOID osal_memcpy( gapRole_ConnectedDevAddr, pPkt->devAddr, B_ADDR_LEN );        gapRole_ConnectionHandle = pPkt->connectionHandle;        gapRole_state = GAPROLE_CONNECTED;        if ( gapRole_RSSIReadRate )        {            // Start the RSSI Reads            VOID osal_start_timerEx( gapRole_TaskID, RSSI_READ_EVT, gapRole_RSSIReadRate );        }        // Store connection information        // Save the connection parameters just established        gapRole_ConnInterval = pPkt->connInterval;        gapRole_ConnSlaveLatency = pPkt->connLatency;        gapRole_ConnTimeout = pPkt->connTimeout;        // Check whether update parameter request is enabled        // Check if update connection parameter request is enabled        if ( gapRole_ParamUpdateEnable == TRUE )        {            // Get the minimum time upon connection establishment before the             // peripheral can start a connection update procedure.            // Get the set time interval; the peripheral will trigger the connection update event             // at least after this time interval after the connection is established.            uint16 timeout = GAP_GetParamValue( TGAP_CONN_PAUSE_PERIPHERAL );            // Trigger the connection parameter update event after a delay of timeout*1000 ms            osal_start_timerEx( gapRole_TaskID, START_CONN_UPDATE_EVT, timeout*1000 );        }}

2. The above comments are very clear. In the event returned after the connection is successfully established, it checks the macro we set. If set to “TRUE”, it retrieves the time interval we set, and after the specified time interval (mentioned above as a minimum because it uses the system timer, which may be executing other events, so the actual delay time may be longer than what we set, but generally, this slight offset can be ignored), it triggers the connection parameter update event to update the connection parameters. Where are the time intervals and the connection parameters to be updated set? Let’s continue to look at the relevant settings in the application layer file.

3. In the application file “Projects\ble\SimpleBLEPeripheral\Source\simpleBLEPeripheral.c”, the following macros are defined to set the values of the connection parameters used when automatically updating connection parameters:

// Minimum connection interval (units of 1.25ms, 80=100ms) if automatic parameter update request is enabled// If automatic parameter update request is enabled, the minimum connection interval, unit 1.25 ms#define DEFAULT_DESIRED_MIN_CONN_INTERVAL     80// Maximum connection interval (units of 1.25ms, 800=1000ms) if automatic parameter update request is enabled// If automatic parameter update request is enabled, the maximum connection interval, unit 1.25 ms#define DEFAULT_DESIRED_MAX_CONN_INTERVAL     800// Slave latency to use if automatic parameter update request is enabled// If automatic parameter update request is enabled, the Slave latency#define DEFAULT_DESIRED_SLAVE_LATENCY         0// Supervision timeout value (units of 10ms, 1000=10s) if automatic parameter update request is enabled// If automatic parameter update request is enabled, the supervision timeout value, unit 10 ms#define DEFAULT_DESIRED_CONN_TIMEOUT          1000// Connection Pause Peripheral time value (in seconds)// If automatic parameter update request is enabled, the time interval value used, unit s#define DEFAULT_CONN_PAUSE_PERIPHERAL         6

4. The corresponding settings using the above macros are in the “SimpleBLEPeripheral_Init” initialization method in the file “Projects\ble\SimpleBLEPeripheral\Source\simpleBLEPeripheral.c”, as shown in the source code below:

VOID GAP_SetParamValue( TGAP_CONN_PAUSE_PERIPHERAL, DEFAULT_CONN_PAUSE_PERIPHERAL );uint16 desired_min_interval = DEFAULT_DESIRED_MIN_CONN_INTERVAL;uint16 desired_max_interval = DEFAULT_DESIRED_MAX_CONN_INTERVAL;uint16 desired_slave_latency = DEFAULT_DESIRED_SLAVE_LATENCY;uint16 desired_conn_timeout = DEFAULT_DESIRED_CONN_TIMEOUT;GAPRole_SetParameter( GAPROLE_MIN_CONN_INTERVAL, sizeof( uint16 ), &desired_min_interval );GAPRole_SetParameter( GAPROLE_MAX_CONN_INTERVAL, sizeof( uint16 ), &desired_max_interval );GAPRole_SetParameter( GAPROLE_SLAVE_LATENCY, sizeof( uint16 ), &desired_slave_latency );GAPRole_SetParameter( GAPROLE_TIMEOUT_MULTIPLIER, sizeof( uint16 ), &desired_conn_timeout );

We will not go through the specific implementation of the above operations in the file “Projects\ble\Profiles\Roles\peripheral.c” because it is essentially an assignment process, so please check it out yourself.

(2) Modifying a Specific Connection Parameter or All Connection Parameters When Needed After Successful Connection Establishment.

1. Method to Modify a Single Connection Parameter

To modify the minimum connection interval

uint16 desired_min_interval = DEFAULT_DESIRED_MIN_CONN_INTERVAL;GAPRole_SetParameter( GAPROLE_MIN_CONN_INTERVAL, sizeof( uint16 ), &desired_min_interval );

To modify the maximum connection interval

uint16 desired_max_interval = DEFAULT_DESIRED_MAX_CONN_INTERVAL;GAPRole_SetParameter( GAPROLE_MAX_CONN_INTERVAL, sizeof( uint16 ), &desired_max_interval );

To modify Slave latency

uint16 desired_slave_latency = DEFAULT_DESIRED_SLAVE_LATENCY;GAPRole_SetParameter( GAPROLE_SLAVE_LATENCY, sizeof( uint16 ), &desired_slave_latency );

To modify supervision timeout

uint16 desired_conn_timeout = DEFAULT_DESIRED_CONN_TIMEOUT;GAPRole_SetParameter( GAPROLE_TIMEOUT_MULTIPLIER, sizeof( uint16 ), &desired_conn_timeout );

2. Method to Modify All Connection Parameters Together

uint16 minConnInterval;uint16 maxConnInterval;uint16 slaveLatency;uint16 timeout;// Update connection parametersGAPRole_SendUpdateParam( minConnInterval, maxConnInterval, slaveLatency, timeout, GAPROLE_TERMINATE_LINK);

The last parameter passed to GAPRole_SendUpdateParam defines the action to take if the connection parameter update fails, with possible values defined in the peripheral.h file as follows:

/** *  Possible actions the peripheral device may take if an unsuccessful parameter *  update is received. * *  Parameters for GAPRole_SendUpdateParam() only */#define GAPROLE_NO_ACTION                    0 // Take no action upon unsuccessful parameter updates#define GAPROLE_RESEND_PARAM_UPDATE          1 // Continue to resend request until successful update#define GAPROLE_TERMINATE_LINK               2 // Terminate link upon unsuccessful parameter updates

GAPROLE_NO_ACTION: No action

GAPROLE_RESEND_PARAM_UPDATE: Resend parameter update request

GAPROLE_TERMINATE_LINK: Disconnect link

For the two methods introduced above for modifying connection parameters, I personally recommend using the second method, as the first method may cause changes to other parameters when modifying a single parameter. For example, if we only modify the connection interval, the Slave latency may change accordingly, making it impossible to control the connection parameter updates according to our needs.

The second method may encounter a situation where we only want to modify one or two connection parameters while keeping the others unchanged. In this case, we need to read the connection parameters before modifying them and then reset the parameters that need to be modified. The code for reading the connection parameters is as follows:

uint16 interval;uint16 latency;uint16 timeout;GAPRole_GetParameter(GAPROLE_CONN_INTERVAL, &interval); GAPRole_GetParameter(GAPROLE_CONN_LATENCY, &latency); GAPRole_GetParameter(GAPROLE_CONN_TIMEOUT, &timeout);

Below, we will go through an example to understand the method of modifying connection parameters. The requirement is to change the connection interval to 25, the Slave latency to 8, while not modifying the timeout, and to resend the parameter update request upon failure. In this example, the Master device is an Android device, and the Slave device is CC2541. The code implementation is as follows:

uint16 interval;uint16 latency;uint16 timeout;GAPRole_GetParameter(GAPROLE_CONN_INTERVAL, &interval); GAPRole_GetParameter(GAPROLE_CONN_LATENCY, &latency); GAPRole_GetParameter(GAPROLE_CONN_TIMEOUT, &timeout); GAPRole_SendUpdateParam( 25, 25, 8, timeout, GAPROLE_RESEND_PARAM_UPDATE);

The captured process shows the following:

From the captured packets, we can see that first S->M, which means the Slave sends a connection parameter update request with the requested connection parameters, then M->S, which means the Master returns a connection parameter update response, with Result being 0, indicating approval for the modification. Finally, M->S sends a link layer connection parameter update control procedure with the agreed connection parameters, thus putting the new connection parameters into use.

Note that when modifying connection parameters, certain requirements must be met:

1. When the Android device acts as the Master, the requirements for connection parameters are as mentioned in the second section of this article titled “Introduction to Connection Parameters”. Additionally, in actual development, it has been found that when the Android device acts as the Master, some Android devices can only modify the BLE device’s connection parameters once after connecting.

2. When the Apple system device acts as the Master, the requirements for updating connection parameters are quite strict, as follows:

- Interval Max * (Slave Latency + 1) ≤ 2 seconds- Interval Min ≥ 20 ms- Interval Min + 20 ms ≤ Interval Max- Slave Latency ≤ 4- connSupervisionTimeout ≤ 6 seconds- Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout即：    最大连接间隔时间 *（从机延迟 + 1） ≤ 2s    最小连接间隔时间 ≥ 20 ms    最小连接间隔时间 + 20 ms ≤ 最大连接间隔时间    从机延迟 ≤ 4    超时时间 ≤ 6s    最大连接间隔时间 *（从机延迟 + 1）* 3  < 超时时间

Therefore, if your BLE Slave device needs to be connected by an iOS Master device, the default requested connection parameters of your BLE Slave device must meet the above requirements, and the connection parameters must also meet these requirements during the connection process.

References

Robin Heydon, “Bluetooth Low Energy The Developer’s Handbook” (If you want the e-book, you can find me)

Core System Package [Low Energy Controller volume] https://www.bluetooth.com/specifications/bluetooth-core-specification/

cc2400 datasheet (If you want the e-book, you can find me)

The Connection Process of Bluetooth Low Energy

Detailed Analysis of BLE Connection Establishment Process

In-depth Understanding of the Pairing Process of Bluetooth Low Energy – Part 1 Pairing Feature Exchange

Recommended Reading

[1] In-depth Understanding of Bluetooth Low Energy (BLE) Protocol Stack, Using Ubertooth One to Scan and Sniff Low Energy Bluetooth

[2] BLE 5 Protocol Stack – Direct Test Mode

Exciting Recommendations