Until now, CM was responsible for calculation of the connectivity status bitmask (https://opensync.atlassian.net/wiki/spaces/OCC/pages/40054194179 ) and starting the BLE advertising. It started the BLE advertising by writing to AW_Bluetooth_Config table, which is the same table as used by the cloud also for other BLE advertising related features (https://opensync.atlassian.net/wiki/spaces/OCC/pages/40054194179/Bluetooth+Manager+BLEM#MsgType ).

While the pod was disconnected from the cloud, concurrent writes were not an issue. However, during normal operation, simultaneous updates to the same configuration table by both the Connection Manager (CM) and the cloud could lead to race conditions. Additionally, CM had to handle BLE status bit calculations, which properly belong within the scope of the Bluetooth Manager’s responsibilities.

The Connectivity Status byte is advertised via BLE as a first byte of the 6-byte Message field, when the Message Type is Onboarding (0x00).

The connectivity status bitmask value (conditions in the table above) can change rapidly during link selection, and there is no need to try to advertise every change via BLE. The interval between status changes can sometimes be even shorter than the BLE advertising interval (meaning no BLE packet with specific status is broadcast at all), and sub-second status updates provide little value to the end user, except for possibly even overwhelming the BLE scanner.

New Kconfig option BLEM_CONNECTIVITY_STATUS_DEBOUNCE_TIME specifies the in milliseconds for which the connectivity status must remain unchanged before the new status is advertised via BLE. Setting this to 0 will disable debouncing, and the new status value will be advertised immediately after it changes.

Default value is 2000 ms.

If Kconfig option BLEM_CONFIG_VIA_BLE_ENABLED is enabled (disabled by default), then BLEM will enable BLE connectable mode (https://opensync.atlassian.net/wiki/spaces/OCC/pages/40054194179/Bluetooth+Manager+BLEM#Advertising-as-connectable ) when the internet connection is not available for at least BLEM_CONFIG_VIA_BLE_OFFLINE_TIMEOUT seconds.

The check for internet connection is done by checking the Connected to Internet (5th) bit of the Connectivity Status Byte: while this bit is 0, an internal timer counts down from BLEM_CONFIG_VIA_BLE_OFFLINE_TIMEOUT seconds and when it reaches 0, the connectable mode is enabled. When the Connected to Internet bit is set to 1, this timer is reset (stopped and reloaded with its initial value of BLEM_CONFIG_VIA_BLE_OFFLINE_TIMEOUT seconds) and the BLE connectable mode is disabled, if it has been enabled.

New Kconfig option BLEM_CONFIG_VIA_BLE_OFFLINE_TIMEOUT (depends on BLEM_CONFIG_VIA_BLE_ENABLED) specifies the number of seconds of no internet connection before the BLE connectable mode is enabled.

The default value is 60 seconds.

The schema and usage of the AW_Bluetooth_Config table remains the same as detailed under https://opensync.atlassian.net/wiki/spaces/OCC/pages/40054194179/Bluetooth+Manager+BLEM#AW_Bluetooth_Config .

The cloud is now the only entity writing to this table.

The schema of the AW_Bluetooth_State table remains the same, identical to AW_Bluetooth_Config, representing the current Bluetooth state on the node.

AWLAN_Node table (specifically the led_config column) is not used anymore, the functionality is now implemented using LED_Config table.

When BLEM enables connectable mode internally (sets AW_Bluetooth_State::connectable to true, while AW_Bluetooth_Config::connectable is not present or set to false), it inserts the following to the LED_Config table to signalize a pattern:

The OVSDB transaction is performed using LED OSP API:

There are no modifications to the southbound API.

There are no changes to existing Bluetooth Manager requirements.