Summary
This article summarizes the procedure required to configure both Central and Peripheral devices, operating on individual STM32WB platforms for Whitelisting operation. A description of the Whitelisting operation within the context of Bluetooth LE standards is provided, along with the procedure required to implement this operation on either the Central or Peripheral device. The implementation is based upon the implementation and use of standard P2PServer and Client application examples, as can be found in the STM32WB Firmware Repository.
Whitelisting in Bluetooth LE, works in a similar way. When a central and peripheral are functioning within a crowded area with many BLE devices, Whitelisting allows the connection between the desired parties to be set up. In this way, the peripheral, only advertises to the desired central and would not have to respond to and address scan or connection requests from other centrals it had no interest to connect with. The reverse is also valid. A central could send a connection request to a specific BLE peripheral. The necessary condition for the above to occur is that both central and peripheral, must be in each other’s whitelist directory.
The pre-requisite with this approach is that both the central (client) and peripheral (server) must have previously connected and are within each other’s bonded and Whitelist. A description of how Whitelisting is set up on both the client and server is provided. The necessary procedural steps and some key definitions associated with the process is presented.
The following procedures or steps, must occur between a client and server in order to establish a Whitelist entry.
The initial connection process associated with the first time set up of the Whitelisting is described, followed by the procedure that is established on subsequent connection requests. It is assumed during the example that the peripheral or server is trying to establish the Whitelist however it will also be shown how the central or client can initiate a scan.
The initial connection process will be described as specified within the BLE standard. The implementation is reflected in the example presented for both the client and server application as described within this document. The example will be implemented on two Nucleo boards in order that the process may be repeated. It has been experienced that different smart phones do not respond or react in identical ways, thus, the implementation is based upon the Nucleo boards.
Figure 1 summarizes pass one of the process and also the structure of the project to be presented. The server begins in advertising mode, the client is scanning. The IO capability is established. In this case a yes/no numeric comparison is used as the input mechanism. The bonding configuration is set and scanning and advertising events are enabled. The connection process begins and ends with an event blue gap pairing complete on both the central and peripheral. The two devices are now connected, bonded and whitelist established. The whitelist process allow for session encryption and session address information to be stored and retrieved quickly for a directed re-connection when requested.
Figure 1: Connection Process
Once connection is established, the client initiates a disconnect command using aci_gap_terminate(). Figure 2 summarizes the process after disconnection. The server sends a aci_gap_configure_whitelist() command to store and associate the whitelist entry with the bonding information. It then begins a new advertising procedure. However, this time, the advertising is with aci_gap_set_undirected_connectable(), with filter policy 3. This represents the whitelist advertising and with this setting, the advertising AD flag not set. This ensures that the advertising server will not be visible or connectable to non whitelist clients.
In parallel, the client begins a general scan with its scanning filter policy enabled to connect to only whitelist entries. Once a connection event is detected, it will check that the event handler for a SCAN_RSP. Within the scan response data, the server’s public address must be present to qualify whitelist device. The process of qualifying the server’s correct public address is important to prevent connection with another device. At this time, it can connect to the intended server or peripheral.
Figure 2: Whitelist Reconnection Process
Article Part 2
Article Part 3
Article Part 4
1.Overview
The first step is to define Whitelisting and how it can be used. Assume that two people are in a crowded area and trying to locate and make contact with one another. They could try to yell or scream to find each other, but most likely, the background noise and not knowing which direction to face, would drown out their calls. They could use a smart phone device to call, text, email, or use any other social app to contact each other. This would work as the contact details contains exactly the information to set up this communication link. The connection is only between the two desired parties only, unless they provide similar contact details for others to join.Whitelisting in Bluetooth LE, works in a similar way. When a central and peripheral are functioning within a crowded area with many BLE devices, Whitelisting allows the connection between the desired parties to be set up. In this way, the peripheral, only advertises to the desired central and would not have to respond to and address scan or connection requests from other centrals it had no interest to connect with. The reverse is also valid. A central could send a connection request to a specific BLE peripheral. The necessary condition for the above to occur is that both central and peripheral, must be in each other’s whitelist directory.
The pre-requisite with this approach is that both the central (client) and peripheral (server) must have previously connected and are within each other’s bonded and Whitelist. A description of how Whitelisting is set up on both the client and server is provided. The necessary procedural steps and some key definitions associated with the process is presented.
2. Whitelist Procedure
The following procedures or steps, must occur between a client and server in order to establish a Whitelist entry.
| Connection | A GAP central and GAP peripheral connection established between the two devices |
| Pairing | The connected devices exchanges security encryption keys to manage the link (Controlled by the Security Manager Protocol) |
| Bonding | Both of devices enable their bonding settings prior to the paring process. This step ensures the encryption keys and BD addresses are stored for the next connection between the two devices |
| Whitelist Entry | The client will add the server information (bonding) to its whitelist. The server will add the client information (bonding) to its whitelist. Note: That this is typically completed when the disconnect state is achieved. |
The initial connection process associated with the first time set up of the Whitelisting is described, followed by the procedure that is established on subsequent connection requests. It is assumed during the example that the peripheral or server is trying to establish the Whitelist however it will also be shown how the central or client can initiate a scan.
2.1 Connection and Re-Connection Process
The initial connection process will be described as specified within the BLE standard. The implementation is reflected in the example presented for both the client and server application as described within this document. The example will be implemented on two Nucleo boards in order that the process may be repeated. It has been experienced that different smart phones do not respond or react in identical ways, thus, the implementation is based upon the Nucleo boards.
Figure 1 summarizes pass one of the process and also the structure of the project to be presented. The server begins in advertising mode, the client is scanning. The IO capability is established. In this case a yes/no numeric comparison is used as the input mechanism. The bonding configuration is set and scanning and advertising events are enabled. The connection process begins and ends with an event blue gap pairing complete on both the central and peripheral. The two devices are now connected, bonded and whitelist established. The whitelist process allow for session encryption and session address information to be stored and retrieved quickly for a directed re-connection when requested.
Figure 1: Connection Process
Once connection is established, the client initiates a disconnect command using aci_gap_terminate(). Figure 2 summarizes the process after disconnection. The server sends a aci_gap_configure_whitelist() command to store and associate the whitelist entry with the bonding information. It then begins a new advertising procedure. However, this time, the advertising is with aci_gap_set_undirected_connectable(), with filter policy 3. This represents the whitelist advertising and with this setting, the advertising AD flag not set. This ensures that the advertising server will not be visible or connectable to non whitelist clients.
In parallel, the client begins a general scan with its scanning filter policy enabled to connect to only whitelist entries. Once a connection event is detected, it will check that the event handler for a SCAN_RSP. Within the scan response data, the server’s public address must be present to qualify whitelist device. The process of qualifying the server’s correct public address is important to prevent connection with another device. At this time, it can connect to the intended server or peripheral.
Figure 2: Whitelist Reconnection Process
Article Part 2
Article Part 3
Article Part 4