Understanding the Bluetooth Connection Process#

Introduction#

Bluetooth ensures reliable data transfers for connected devices. 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 sl_bt_advertiser_start, 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 sl_bt_advertiser_stop.

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. iBeacon and Eddystone standard are beacon examples. If a remote device attempts to connect to a non-connectable advertiser, the request will be dropped. 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 sl_bt_evt_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.

When a connection request is received, the Bluetooth stack automatically stops advertising to avoid unintended multiple connections. If multiple connections are required, advertising can be restarted after the sl_bt_evt_connection_opened event was received.

Closing Connections#

If a connection is closed, the event sl_bt_evt_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 Reference Manual.

Secure and Unsecure Connections#

When a connection event is received(sl_bt_evt_connection_opened), the application can determine whether or not a bond was made with the remote device by examining the bond_handle parameter. A value of 0xFF indicates no bond, while 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, at least one connection parameters event (sl_bt_evt_connection_parameters) will occur. 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. These are the types of security modes:

  1. No security

  2. No authentication, but encrypted

  3. Authenticated and encrypted

Either stack of the user application can request secure connection. 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 calling sl_bt_sm_increase_security(). In eithe