Bluetooth ensures reliable data transfer when devices are connected. A connection is required for secure data transfer. This article describes the various states that a Bluetooth device can be in and how to move between these states.
Upon starting the Bluetooth stack, the device will be in an idle state, that is to say it will be non-discoverable and non-connectable. Through a call to either of the API functions le_gap_set_mode() or le_gap_bt5_set_mode(), 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.
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.
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 or le_connection_bt5_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. In the case of a Bluetooth 5 connection, 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.
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.
When a connection event is received(evt_le_connection_opened or evt_le_connection_bt5_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
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).
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 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.
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.
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_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.
It is possible to allow up to 8 simultaneous connections. The max_connections parameter in the Bluetooth configuration struct can be used to limit the number of connections to less than 8 if desired. In order to allow multiple connections it is necessary to restart advertising once 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 in order to switch roles between master and client.
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.
Re the statement made above, ".... The user application can request a secure connection by making a call to cmd_sm_increase_security()".
It is not clear to me where this API is to be called. Have read somewhere that it should be called in the Connection Opened event but I don't see any bonding take place in my BGScript client.
Elsewhere I have read that all that the client has to do is to access a protected characteristic (nothing said about cmd_sm_increase_security).
What technique should the BLE client use?
@gerlad0 have a look at this thread that was created recently:
I'm working on EFR32BG1B232F256GM48. I'm using thermometer example. But my device gets detected and cant see any change in data.
I used one more app "bleterm". With that I was able to see all services and send and receive data. But this app works in few mobile and not in others. It says connections issue. unable to connect:null
Can you let me know what this issue is. I'm new to EFR32BG1B232F256GM48.