Bluetooth Connection Flowcharts#

Introduction#

Bluetooth Low Energy (BLE) defines a framework for a wide variety of communication schemes. It allows devices to discover each other, broadcast data, establish connections, and many other fundamental operations.

These procedures are described comprehensively in a series of sequence diagrams, which focus on the following items:

• BGAPI function calls.

• Messages exchanged over the air.

• Events raised by the BLE stack.

This document does not expose the Bluetooth stack packet management nor it describes the host controller interface (HCI).

The document assumes that the necessary Bluetooth hardware is used, such as an EFR32 SoC or a BGM module.

Generic Access Profile (GAP)#

To establish a BLE connection between the two devices A and B, the following has to happen: one device, say A, has to advertise, and the other one, say B, has to scan for connectable devices. As a result, only the scanning device B can initiate the connection. The scanning device B is then the master and the advertising device A is the slave.

Advertising and Scanning#

BLE implements a time division duplex scheme. This means that on a given frequency channel, duplex communication (i.e., sending and receiving data) is taking place on one physical link. This differs, for example, from a wired serial link, where TX and RX wires would be used respectively for transmission and reception.

As a result, a defined set of tunable timing parameters are available, such as the advertising interval, scanning interval, and scanning window. For more information, see the BLE core specification.

The advertiser periodically sends advertising packets to any listening device. The scanner starts listening and a "scan response" event is raised each time an advertising packets is received. The advertising packets convey some useful information, such as the advertiser Bluetooth address for example. This information can eventually be used to establish a connection.

Passive and active are the two available scanning methods. In passive scanning, the scanner only receives advertising packets. In active scanning, the scanner sends "scan request" messages to the advertiser, containing the scanner Bluetooth address and its address type.

Note: This article does not cover the extended advertising.

Connection Success#

After the scanner has collected all necessary information from an advertiser, it can connect to it. The following sequence diagram illustrates the steps taking place in order to successfully establish a connection:

Note that the scanner is the one that is initiating the connection.

Connection Initiation Failure#

A connection initiation failure can happen either because the connection initiation is canceled or it times out. A device can cancel a pending connection immediately after creation. The slave must respond to the master within a given time interval. The BLE standard defines the fixed number of six connection intervals as the limit within whichever host can remain silent (not sending any packet). If one of the hosts (master or slave) remains silent for longer, the connection is dropped.

In this example, six connection intervals passed without receiving any data channel PDU from the slave. As a result, the connection is dropped. Similarly, If the master had failed to send data channel PDU to the slave for that same time interval, the connection would have dropped.

Note: This is different from the supervision timeout. It applies only for the connection initiation. In other words, there is at least one successful connection event where packets are exchanged between the master and slave.

Updating Connection Parameters#

After a BLE connection has been established, some parameter adjustments might be requested. To do so, the "Connection parameter request" procedure can be triggered by either host, master or slave. The procedure can be triggered at link layer level (i.e., without the application requesting it) during connection initiation. The BGAPI implements the routine gecko_cmd_le_gap_set_conn_parameters() to preset the parameter values. When the connection is initiated, it is still possible at any point in time to update the connection parameters via a call to the routine gecko_cmd_le_connection_set_parameters() in the application layer:

Additionally, the sequence diagram above shows the "GATT MTU exchange" sub procedure.

The ATT protocol defines a Maximum Transmission Unit (MTU) of 23 bytes by default. If the two devices connected can support a bigger ATT_MTU value, the "GATT MTU exchange" procedure is triggered to set the ATT protocol MTU. This procedure is initiated only once during a connection initiation.

Note that the security mode and the data channel PDU payload length may vary during the connection session. For more information on general BLE security features, see Using Bluetooth security features in Silicon Labs Bluetooth SDK.

Note: During the "Connection parameter request" procedure, the master has always the priority over parameter decision. In other words, the master has always the "last word" for parameter negotiation.