Understanding the Bluetooth Connection Process#
Introduction#
Bluetooth ensures reliable data transfer when devices are connected. A connection is required for secure data transfer. This document describes the various states that a Bluetooth device can be in and how to move between these states.
Bluetooth States#
After starting the Bluetooth stack, the device will be in an idle state. In other words, it will be non-discoverable and non-connectable. Through a call to the API function le_gap_start_advertising, the device can be made discoverable and non-connectable or discoverable and connectable. It is also possible to return the device to the idle, non-discoverable and non-connectable state by le_gap_stop_advertising.
Non-connectable Beacons#
A device which is discoverable, but non-connectable is known as a beacon. The advertising data can be seen by any device within range but it is not possible to establish a connection. This means that the advertising device’s data cannot be written. Examples of beacons are the iBeacon and Eddystone standards. If a remote master attempts to connect to a non-connectable slave, the slave’s stack responds to the master with a connection refused error. No interaction is required by the user application.
Connectable Advertisers#
A device which is discoverable and connectable advertises and accepts connections from any device within range. When a connection has been established, the stack sends the event le_connection_opened to the application. This event contains the address of the remote device, the type of address, a connection handle, the role of the device in the connection, and a bond handle to indicate whether the device is bonded or not. The event also includes a handle to indicate which advertising set the connection is associated with. If multiple connections are required, advertising can be restarted from this event.
Closing Connections#
If a connection is closed, the event le_connection_closed will be sent to the application. This event includes the connection handle and the reason for disconnection. The reasons for disconnections are documented in the Bluetooth errors section of the API guide.
Connections – Secure and Unsecure#
When a connection event is received(le_connection_opened), the application can determine whether or not there is a bond with the remote device by examining the bond_handle parameter. A value of 0xFF indicates no bond, any other value indicates a valid bond. If the local and remote devices are not bonded, the communication between them will be unencrypted and visible to any Bluetooth device within range. It is strongly recommended to secure any sensitive data.
After the connection event, there will be at least one connection parameters event (gecko_evt_le_connection_parameters_id). This event is sent when a connection is opened and any time the connection parameters are updated. The connection parameters event includes information about the connection parameters (connection interval, latency, timeout) as well as the security mode and maximum PDU size. The security mode is one of the following:
No security
No authentication, but encrypted
Authenticated and encrypted
A secure connection can be requested either by the stack or the user application. The stack will request a secure connection if the remote device attempts to access a protected characteristic. The user application can request a secure connection by making a call to cmd_sm_increase_security(). In either case, an event will be sent by the stack to the user application to indicate whether the bonding/pairing was successful (evt_sm_bonded) or unsuccessful (evt_bonding_failed).
Bonding vs Pairing#
The security manager contains events and commands for controlling the security features included in the Bluetooth stack. One of these features is the ability to form new bonds (bondable mode). As shown in the diagram below, when a connection is secured it will either be bonded and assigned a long term key (LTK), which can be used in subsequent connections or paired and assigned a short term key (STK) which will be discarded when the connection is terminated. Upon successful bonding/pairing the stack sends the event evt_sm_bonded to the application with a bond_handle as a parameter. As with the bond_handle passed to the evt_le_connection_opened any value other than 0xFF indicates that the devices are bonded while a value 0xFF in this case means that the devices are paired for the current connection.
Maximum Transmission Unit (MTU)#
In addition to the connection opened event and the connection parameters event, there will always be a GATT MTU exchanged event for each connection. This event tells you the size of the maximum transmission unit (MTU). This is the maximum size of any packet that can be sent between the client and server. The only special handling that may be required for this event is to use the MTU to determine whether an entire characteristic can be sent in a single read/write or if multiple writes are required. A single read/write can be MTU – 3 bytes in length.
Bluetooth 5 Connections#
Whether a connection is secured or not, Bluetooth 5 allows the choice of 1 Mbps or 2 Mbps PHY on a per connection basis. The PHY can be selected with a call to le_connection_set_preferred_phy(). A call to this API results in the stack sending the event evt_le_connection_phy_status to indicate which PHY is actually in use for the connection. The diagram below shows that the flow of the connected state is similar to that of Bluetooth 4.x with the addition of the possibility of selecting the 2M PHY.
Multiple Connections and Dual Mode Topology#
It is possible to allow up to 8 simultaneous connections. The max_connections parameter in the Bluetooth configuration structure can be used to limit the number of connections to less than 8 if desired. To allow multiple connections, restart advertising after a connection is made. This can be done from the connection_opened event.
One of the additions made in Bluetooth 4.2 is the so-called dual mode topology, which allows a device to be a master and a slave simultaneously. Previously it was necessary to disconnect to switch roles between master and client.
Conclusion#
Connections are Bluetooth’s way of ensuring reliable and, optionally, secure data transfer. Connections also make it possible for devices to negotiate the PHY that they use to communicate.