Hello Bt-Maintainers,
Bluetooth Advertisement Monitor API was introduced to support background
scanning and proximity detection based on the application specified RSSI
thresholds and content filters on LE advertisement packets.
To optimize the power consumption, the API offloads the content
filtering and RSSI tracking to the controller if the controller
offloading support is available. However, this monitoring is not
completely offloaded as the bluetoothd also handles RSSI thresholds and
timeouts in order to fulfill high/low thresholds/timeouts filtering with
D-bus clients.
There is further room to achieve better power optimization by supporting
the controller event HCI_VS_MSFT_LE_Monitor_Device_Event to fulfill true
monitor offloading. This is currently not supported as it was originally
desired to minimize the changes to the MGMT interface and reuse the
existing MGMT event - MGMT_EV_DEVICE_FOUND to pass advertisements to
bluetoothd and let bluetoothd handle the RSSI thresholds and timeouts in
order to fulfill the D-bus API requirements for the client.
This patch series introduces a new MGMT interface -
MGMT_EV_ADV_MONITOR_TRACKING to deliver the Monitor Device event
received from the controller to the bluetoothd.
Please let me know what you think about this or if you have any further
questions.
Thanks,
Manish.
Manish Mandlik (3):
doc: Add Advertisement Monitor Device Tracking event
lib: Add definition of AdvMonitor Tracking event
adv_monitor: Receive Device Tracking event
doc/mgmt-api.txt | 27 ++++++++++++++++++++++++++-
lib/mgmt.h | 8 ++++++++
src/adv_monitor.c | 25 +++++++++++++++++++++++++
3 files changed, 59 insertions(+), 1 deletion(-)
--
2.33.0.685.g46640cef36-goog
This patch adds the Advertisement Monitor Device Traching event. This
event indicates that the controller has stated/stopped tracking a
particular device matching one of the already added Advertisement
Monitor.
Reviewed-by: Miao-chen Chou <[email protected]>
Reviewed-by: Yun-Hao Chung <[email protected]>
---
doc/mgmt-api.txt | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 5355fedb0..06df3e914 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -107,7 +107,8 @@ Configuration command, Default Runtime Configuration Changed event, Get
Device Flags command, Set Device Flags command, Device Flags Changed event,
Read Advertisement Monitor Features command, Add Advertisement Patterns
Monitor command, Remove Advertisement Monitor command, Advertisement Monitor
-Added event and Advertisement Monitor Removed event.
+Added event, Advertisement Monitor Removed event and Advertisement Monitor
+Device Tracking event.
Example
@@ -4910,3 +4911,27 @@ Controller Resume Event
Address_Type. Otherwise, Address and Address_Type will both be zero.
This event will be sent to all management sockets.
+
+
+Advertisement Monitor Device Tracking Event
+===========================================
+
+ Event code: 0x002f
+ Controller Index: <controller_id>
+ Event Parameters: Monitor_Handle (2 octets)
+ Monitor_State (1 octet)
+ Address (6 octets)
+ Address_Type (1 octet)
+
+ This event indicates that the controller has started/stopped tracking
+ a particular device matching the Advertisement Monitor with handle
+ Monitor_Handle.
+
+ Possible values for the Monitor_State parameter:
+ 0 The controller has stopped tracking a device
+ 1 The controller has started tracking a device
+
+ The address of the device being tracked will be shared in Address and
+ Address_Type.
+
+ This event will be sent to all management sockets.
--
2.33.0.685.g46640cef36-goog
This patch adds a definition of the Advertisement Monitor Device
Tracking event.
---
lib/mgmt.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/lib/mgmt.h b/lib/mgmt.h
index 0a6349321..f23041f96 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -1014,6 +1014,13 @@ struct mgmt_ev_controller_resume {
uint8_t wake_reason;
} __packed;
+#define MGMT_EV_ADV_MONITOR_TRACKING 0x002f
+struct mgmt_ev_adv_monitor_tracking {
+ uint16_t monitor_handle;
+ uint8_t monitor_state;
+ struct mgmt_addr_info addr;
+} __packed;
+
static const char *mgmt_op[] = {
"<0x0000>",
"Read Version",
@@ -1152,6 +1159,7 @@ static const char *mgmt_ev[] = {
"Advertisement Monitor Removed",
"Controller Suspend",
"Controller Resume",
+ "Advertisement Monitor Device Tracking", /* 0x002f */
};
static const char *mgmt_status[] = {
--
2.33.0.685.g46640cef36-goog
This patch registers a callback function to receive Advertisement
Monitor Device Tracking event.
Test performed:
- verified by logs that Monitor Device is received from the controller
and sent to the bluetoothd when the controller starts/stops monitoring
a bluetooth device.
---
src/adv_monitor.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/src/adv_monitor.c b/src/adv_monitor.c
index 715ac5904..05bd49134 100644
--- a/src/adv_monitor.c
+++ b/src/adv_monitor.c
@@ -1531,6 +1531,27 @@ static void adv_monitor_removed_callback(uint16_t index, uint16_t length,
ev->monitor_handle);
}
+/* Processes Adv Monitor tracking event from kernel */
+static void adv_monitor_tracking_callback(uint16_t index, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adv_monitor_manager *manager = user_data;
+ const struct mgmt_ev_adv_monitor_tracking *ev = param;
+ uint16_t handle = le16_to_cpu(ev->monitor_handle);
+ const uint16_t adapter_id = manager->adapter_id;
+ char addr[18];
+
+ if (length < sizeof(*ev)) {
+ btd_error(adapter_id,
+ "Wrong size of Adv Monitor Tracking event");
+ return;
+ }
+
+ ba2str(&ev->addr.bdaddr, addr);
+ DBG("Adv monitor with handle 0x%04x %s tracking device %s", handle,
+ ev->monitor_state ? "started" : "stopped", addr);
+}
+
/* Allocates a manager object */
static struct btd_adv_monitor_manager *manager_new(
struct btd_adapter *adapter,
@@ -1555,6 +1576,10 @@ static struct btd_adv_monitor_manager *manager_new(
manager->adapter_id, adv_monitor_removed_callback,
manager, NULL);
+ mgmt_register(manager->mgmt, MGMT_EV_ADV_MONITOR_TRACKING,
+ manager->adapter_id, adv_monitor_tracking_callback,
+ manager, NULL);
+
return manager;
}
--
2.33.0.685.g46640cef36-goog
Hi Manish,
On Mon, Sep 27, 2021 at 1:17 PM Manish Mandlik <[email protected]> wrote:
>
> This patch adds the Advertisement Monitor Device Traching event. This
> event indicates that the controller has stated/stopped tracking a
> particular device matching one of the already added Advertisement
> Monitor.
>
> Reviewed-by: Miao-chen Chou <[email protected]>
> Reviewed-by: Yun-Hao Chung <[email protected]>
> ---
>
> doc/mgmt-api.txt | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 5355fedb0..06df3e914 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -107,7 +107,8 @@ Configuration command, Default Runtime Configuration Changed event, Get
> Device Flags command, Set Device Flags command, Device Flags Changed event,
> Read Advertisement Monitor Features command, Add Advertisement Patterns
> Monitor command, Remove Advertisement Monitor command, Advertisement Monitor
> -Added event and Advertisement Monitor Removed event.
> +Added event, Advertisement Monitor Removed event and Advertisement Monitor
> +Device Tracking event.
>
>
> Example
> @@ -4910,3 +4911,27 @@ Controller Resume Event
> Address_Type. Otherwise, Address and Address_Type will both be zero.
>
> This event will be sent to all management sockets.
> +
> +
> +Advertisement Monitor Device Tracking Event
> +===========================================
> +
> + Event code: 0x002f
> + Controller Index: <controller_id>
> + Event Parameters: Monitor_Handle (2 octets)
> + Monitor_State (1 octet)
> + Address (6 octets)
> + Address_Type (1 octet)
> +
> + This event indicates that the controller has started/stopped tracking
> + a particular device matching the Advertisement Monitor with handle
> + Monitor_Handle.
> +
> + Possible values for the Monitor_State parameter:
> + 0 The controller has stopped tracking a device
> + 1 The controller has started tracking a device
> +
> + The address of the device being tracked will be shared in Address and
> + Address_Type.
> +
> + This event will be sent to all management sockets.
I wonder if wouldn't it be better to indicate this over Device Found?
Or the controller will indicate the advertising report in addition to
this event? Btw, I think it is about time we introduce these commands
to the emulator in order to have proper CI tests, without it cannot
become a stable API.
> --
> 2.33.0.685.g46640cef36-goog
>
--
Luiz Augusto von Dentz
Hi Manish,
> This patch adds the Advertisement Monitor Device Traching event. This
> event indicates that the controller has stated/stopped tracking a
> particular device matching one of the already added Advertisement
> Monitor.
>
> Reviewed-by: Miao-chen Chou <[email protected]>
> Reviewed-by: Yun-Hao Chung <[email protected]>
> ---
>
> doc/mgmt-api.txt | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 5355fedb0..06df3e914 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -107,7 +107,8 @@ Configuration command, Default Runtime Configuration Changed event, Get
> Device Flags command, Set Device Flags command, Device Flags Changed event,
> Read Advertisement Monitor Features command, Add Advertisement Patterns
> Monitor command, Remove Advertisement Monitor command, Advertisement Monitor
> -Added event and Advertisement Monitor Removed event.
> +Added event, Advertisement Monitor Removed event and Advertisement Monitor
> +Device Tracking event.
>
>
> Example
> @@ -4910,3 +4911,27 @@ Controller Resume Event
> Address_Type. Otherwise, Address and Address_Type will both be zero.
>
> This event will be sent to all management sockets.
> +
> +
> +Advertisement Monitor Device Tracking Event
> +===========================================
> +
> + Event code: 0x002f
> + Controller Index: <controller_id>
> + Event Parameters: Monitor_Handle (2 octets)
> + Monitor_State (1 octet)
> + Address (6 octets)
> + Address_Type (1 octet)
> +
> + This event indicates that the controller has started/stopped tracking
> + a particular device matching the Advertisement Monitor with handle
> + Monitor_Handle.
> +
> + Possible values for the Monitor_State parameter:
> + 0 The controller has stopped tracking a device
> + 1 The controller has started tracking a device
> +
> + The address of the device being tracked will be shared in Address and
> + Address_Type.
> +
> + This event will be sent to all management sockets.
I have to echo Luiz's comment here. How is this suppose to work. We now get a Device Found and Device Tracked event?
Wouldn’t it be really better to have a “I am tracked” flag in the Device Found event?
Regards
Marcel
Hi Manish,
can we please stop top-posting and follow the general rules of this mailing list.
> The controller sends advertising reports in addition to this event. This event is reported only when there are active and matched advertisement monitors.
>
> Whenever an advertisement matches a Monitor, the controller sends this event with Monitor_state set to 1, indicating that it has started monitoring that particular device. After that it may send one or more advertising reports based on the configured Sampling_period for that Monitor. Once the controller stops monitoring that device, it sends the same event again with Monitor_state set to 0 to notify the host that it has stopped monitoring that particular device.
>
> Since this event is sent only twice (at start and end of monitoring) per monitoring period [1], combining this with the Sampling_period - 0xFF (send only one advertisement report per monitoring period) [2], we can drastically reduce the number of events generated by the controller during background scanning but still have the DeviceFound/DeviceLost functionality in bluetoothd.
>
> So, it will be better to keep this event separate than the Device Found event as it is triggered only during monitoring. Please let me know what you think about this.
> [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_device_event
> [2]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_advertisement
This is what I was thinking:
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 97d33e30a15d..fa9121c3bc87 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -4263,6 +4263,7 @@ Device Found Event
1 Legacy Pairing
2 Not Connectable
3 Reserved (not in use)
+ 4 Device Tracked
For the RSSI field a value of 127 indicates that the RSSI is
not available. That can happen with Bluetooth 1.1 and earlier
@@ -4910,3 +4911,19 @@ Controller Resume Event
Address_Type. Otherwise, Address and Address_Type will both be zero.
This event will be sent to all management sockets.
+
+Device Lost Event
+=================
+
+ Event Code: 0x002f
+ Controller Index: <controller id>
+ Event Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+
+ This event indicates that a tracked device was no longer found
+ during monitoring.
+
+ Possible values for the Address_Type parameter:
+ 0 BR/EDR
+ 1 LE Public
+ 2 LE Random
I really don’t get why we would make it more complicated for mgmt-api and thus bluetoothd.
Regards
Marcel