Extensions HCI Bluetooth définies par Microsoft
L’interface Hôte-Contrôleur Bluetooth (HCI) spécifie toutes les interactions entre un hôte et un contrôleur radio Bluetooth. Les spécifications Bluetooth permettent des commandes et des événements HCI définis par les fournisseurs pour permettre une interaction non standardisée entre les hôtes et les contrôleurs. Microsoft définit des commandes et événements HCI spécifiques au fournisseur qui sont consommés par Windows. Les implémenteurs de contrôleurs Bluetooth peuvent utiliser ces extensions pour implémenter des fonctionnalités spéciales.
Spécifications
Les commandes HCI Bluetooth sont identifiées par un code de commande 16 bits. L’organisation Bluetooth définit des valeurs dans la plage 0x0000 à 0xFBFF. Les fournisseurs définissent des valeurs dans la plage 0xFC00 à 0xFFFF, permettant 1024 codes de commande différents attribués par les fournisseurs.
Le fournisseur doit choisir la valeur du code de commande défini par Microsoft. Microsoft ne peut pas choisir un code de commande et supposer qu’aucun autre fournisseur n’utilise ce code à des fins conflictuelles. Il est dangereux d’émettre une commande spécifique au fournisseur et de dépendre du contrôleur pour rejeter la commande s’il ne la comprend pas. Le contrôleur pourrait interpréter la commande comme une opération destructive, telle que la mise à jour du firmware du contrôleur.
Le fournisseur doit communiquer la valeur choisie par une méthode autre que le contrôleur. Microsoft ne spécifie pas comment obtenir le code choisi.
Notification de la pile Bluetooth Windows du code de commande spécifique au fournisseur
La pile Bluetooth Windows lit le code de commande spécifique au fournisseur à partir d’une clé de registre, VsMsftOpCode.
La clé de registre VsMsftOpCode a un type de REG_DWORD et les données de la clé sont l’opcode spécifique au fournisseur.
Pour spécifier l’opcode spécifique au fournisseur, utilisez la directive AddReg sous la section DDInstall.HW dans le INF du pilote. La section de l’ajout du registre devrait contenir :
HKR,,"VsMsftOpCode",0x00010001,<Vendor Specific Opcode>
Exemple :
[radio.NTamd64.HW]
AddReg=radio.NTamd64.HW.AddReg
[radio.NTamd64.HW.AddReg]
HKR,,"VsMsftOpCode",0x00010001,<Vendor Specific Opcode>
Commandes HCI définies par Microsoft
| Commandes HCI | Description |
|---|---|
| HCI_VS_MSFT_Read_Supported_Features | Fournit un bitmap qui décrit quelles fonctionnalités définies par Microsoft le contrôleur supporte, et spécifie le préfixe pour les événements définis par Microsoft renvoyés par le contrôleur. |
| HCI_VS_MSFT_Monitor_Rssi | Demande au contrôleur de commencer à surveiller le RSSI du lien mesuré pour une connexion spécifiée, et génère un événement lorsque le RSSI du lien mesuré de la connexion sort des limites spécifiées. |
| HCI_VS_MSFT_Cancel_Monitor_Rssi | Annule une commande HCI_VS_MSFT_Monitor_Rssi précédemment émise. |
| HCI_VS_MSFT_LE_Monitor_Advertisement | Demande au contrôleur de commencer à surveiller les annonces qui se situent dans la plage RSSI spécifiée et répondent également à d’autres exigences. |
| HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement | Annule une commande HCI_VS_MSFT_LE_Monitor_Advertisement précédemment émise. |
| HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable | Définit l’état des filtres d’annonces. |
| HCI_VS_MSFT_Read_Absolute_RSSI | Lit la valeur absolue de l’indication de la force du signal reçu (RSSI) pour une connexion BR/EDR à partir du contrôleur. |
Commande et sous-commandes HCI définies par Microsoft
Le contrôleur comprend qu’il n’y a qu’une seule commande HCI spécifique à Microsoft. L’ensemble de commandes spécifiques à Microsoft est étendu en utilisant un opcode. Le premier paramètre de commande pour la commande HCI définie par Microsoft est un opcode qui spécifie la sous-commande.
Les contrôleurs doivent supporter HCI_VS_MSFT_Read_Supported_Features pour supporter toute autre sous-commande HCI Microsoft. Le support d’autres commandes est optionnel et dépend des valeurs renvoyées par HCI_VS_MSFT_Read_Supported_Features. Windows n’envoie aucune sous-commande définie par Microsoft à moins que le contrôleur indique le support de la sous-commande par une réponse à HCI_VS_MSFT_Read_Supported_Features.
HCI_VS_MSFT_Read_Supported_Features
HCI_VS_MSFT_Read_Supported_Features fournit un bitmap qui décrit quelles fonctionnalités définies par Microsoft le contrôleur supporte, et spécifie le préfixe pour les événements définis par Microsoft renvoyés par le contrôleur.
Le contrôleur doit toujours terminer cette commande rapidement avec un événement Command Completed.
| Commande | Code | Paramètres de commande | Paramètres de retour |
|---|---|---|---|
| HCI_VS_MSFT_Read_Supported_Features | Code de base choisi | Subcommand_opcode | Statut, Subcommand_opcode, Supported_features, Microsoft_event_prefix_length, Microsoft_event_prefix |
Command_parameters
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x00 | L’opcode de la sous-commande pour HCI_VS_MSFT_Read_Supported_Features. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01 to 0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x00 | L’opcode de la sous-commande pour HCI_VS_MSFT_Read_Supported_Features. |
Supported_features (8 octets):
| Valeur | Description des paramètres |
|---|---|
| 0x00000000 00000001 | Le contrôleur prend en charge la fonctionnalité de surveillance RSSI pour les connexions BR/EDR. De plus, le contrôleur supporte HCI_VS_MSFT_Read_Absolute_RSSI pour lire la mesure RSSI absolue d’une connexion BR/EDR. |
| 0x00000000 00000002 | Le contrôleur supporte la fonctionnalité de surveillance RSSI pour les connexions LE. |
| 0x00000000 00000004 | Le contrôleur supporte la surveillance RSSI des annonces LE héritées. |
| 0x00000000 00000008 | Le contrôleur supporte la surveillance des annonces des annonces LE héritées. |
| 0x00000000 00000010 | Le contrôleur supporte la vérification de la validité des coordonnées publiques X et Y sur la courbe lors du processus de couplage simple sécurisé pour P-192 et P-256. Pour plus d’informations, consultez Bluetooth Core Specification Erratum 10734. |
| 0x00000000 00000020 | Le contrôleur supporte la surveillance continue des annonces LE réalisée simultanément avec d’autres activités radio, en utilisant HCI_VS_MSFT_LE_Monitor_Advertisement [v1]. |
| 0x00000000 00000040 | Réservé. |
| 0x00000000 00000080 | Le contrôleur supporte l’offload AVDTP et les commandes HCI_VS_MSFT_Avdtp_* décrites dans ce document. |
| 0x00000000 00000100 | Réservé. |
| 0x00000000 00000200 | Réservé. |
| 0x00000000 00000400 | Le contrôleur prend en charge HCI_VS_MSFT_LE_Monitor_Advertisement [v2]. De plus, le contrôleur supporte la surveillance continue des annonces LE réalisée simultanément avec d’autres activités radio, en utilisant HCI_VS_MSFT_LE_Monitor_Advertisement [v2]. |
| 0xFFFFFFFF FFFFFF00 | Bits réservés pour définition future. Doit être zéro. |
Microsoft_event_prefix_length (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x00 to 0x20 | Nombre d’octets dans le champ de préfixe de l’événement Microsoft tel que spécifié dans le Microsoft_event_prefix renvoyé. C’est le nombre d’octets d’informations constantes au début de chaque événement HCI spécifié par Microsoft. |
Microsoft_event_prefix (longueur variable) :
| Valeur | Description des paramètres |
|---|---|
| Valeur du préfixe de l’événement | Les informations constantes à attendre au début de chaque événement défini par Microsoft. Ces informations sont utilisées pour distinguer les événements définis par Microsoft des autres événements personnalisés. |
HCI_VS_MSFT_Monitor_Rssi
HCI_VS_MSFT_Monitor_Rssi demande au contrôleur de commencer à surveiller le RSSI du lien mesuré pour une connexion spécifiée, et génère un événement lorsque le RSSI du lien mesuré de la connexion sort des limites spécifiées.
| Commande | Code | Paramètres de commande | Paramètres de retour |
|---|---|---|---|
| HCI_VS_MSFT_Monitor_Rssi | Code de base choisi | Subcommand_opcode, Handle de connexion, RSSI_threshold_high, RSSI_threshold_low, RSSI_threshold_low_time_interval, RSSI_sampling_period |
Statut, Subcommand_opcode |
Le contrôleur doit notifier l’hôte de la valeur RSSI avec un événement généré périodiquement (basé sur le RSSI_sampling_period). Le RSSI du lien mesuré doit être la valeur absolue de la force du signal du récepteur en dBm pour la connexion BR/EDR.
En réponse à une commande HCI_VS_MSFT_Monitor_Rssi, le contrôleur doit générer un événement Command Complete avec un statut égal à zéro si le contrôleur peut commencer à surveiller, ou un statut non nul sinon. Si la valeur du statut est non nulle, le contrôleur ne doit pas générer un HCI_VS_MSFT_Rssi_Event en réponse à cette commande.
Le contrôleur doit refuser la commande si une autre commande HCI_VS_MSFT_Monitor_Rssi avec le même Connection_Handle est en cours, ou si le handle de connexion spécifié est invalide. Le contrôleur peut également refuser la commande pour d’autres raisons, telles que l’épuisement des ressources.
Ce diagramme d’état montre les états de transition sur le contrôleur lors de la surveillance du RSSI pour une connexion.
Le contrôleur doit générer un HCI_VS_MSFT_Rssi_Event lorsque le RSSI reçu est supérieur ou égal à la RSSI_threshold_high spécifiée. Après que cet événement a été généré, le contrôleur ne doit pas générer un nouveau HCI_VS_MSFT_Rssi_Event pour spécifier que la RSSI_threshold_high a été dépassée jusqu’à ce qu’il génère un HCI_VS_MSFT_Rssi_Event spécifiant que le RSSI est tombé en dessous de RSSI_threshold_low.
Le contrôleur doit générer un HCI_VS_MSFT_Rssi_Event lorsque le RSSI reçu est égal ou inférieur à la RSSI_threshold_low spécifiée pendant le RSSI_threshold_low_time_interval spécifié. Après que cet événement a été généré, le contrôleur ne doit pas générer un nouveau HCI_VS_MSFT_Rssi_Event pour spécifier que le RSSI est tombé en dessous de la RSSI_threshold_low jusqu’à ce qu’un événement HCI_VS_MSFT_Rssi_Event soit généré pour spécifier que RSSI_threshold_high a été atteint ou dépassé.
Si le RSSI_sampling_period est compris entre 0x01 et 0xFE, le contrôleur doit générer un HCI_VS_MSFT_Rssi_Event périodiquement tous les RSSI_sampling_period. Cet événement doit contenir la moyenne du RSSI calculée sur la RSSI_sampling_period. Si le RSSI_sampling_period est 0x00 ou 0xFF, le contrôleur ne doit pas notifier l’hôte périodiquement avec HCI_VS_MSFT_Rssi_Event.
Command_parameters
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x01 | L’opcode de la sous-commande pour HCI_VS_MSFT_Monitor_Rssi. |
Connection_Handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Le handle pour la connexion dont le RSSI doit être surveillé. |
RSSI_threshold_high (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0xXX | La valeur RSSI maximale attendue. Le contrôleur génère un événement si le RSSI observé devient supérieur ou égal à cette valeur. Unité : dBm Plage BR/EDR : -128 à 127 (entier signé) Plage LE : -127 à 20 (entier signé) |
RSSI_threshold_low (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0xXX | La valeur RSSI minimale attendue. Le contrôleur génère un événement si le RSSI observé devient inférieur ou égal à cette valeur. Unité : dBm Plage obligatoire BR/EDR : -128 à 127 (entier signé) Plage obligatoire LE : -127 à 20 (entier signé) |
RSSI_threshold_low_time_interval (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Valeur réservée. |
| N = 0xXX | Le temps en secondes pendant lequel la valeur RSSI doit être inférieure à RSSI_threshold_low avant qu’un HCI_VS_MSFT_Rssi_Event soit généré. Période = N * 1 seconde Plage obligatoire : 0x01 à 0x3C |
RSSI_sampling_period (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Valeur réservée. |
| N = 0xXX | L’intervalle d’échantillonnage en millisecondes. Période = N * 100 millisecondes Plage obligatoire : 0x01 à 0xFE |
| 0xFF | Valeur réservée. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01 to 0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
| 0x07 | Le contrôleur doit renvoyer Memory Capacity Exceeded s’il n’a pas assez de mémoire pour traiter la commande. |
| Code de l’erreur | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x01 | L’opcode de la sous-commande pour HCI_VS_MSFT_Monitor_Rssi. |
Événements générés sauf si masqués
Le contrôleur doit générer rapidement un événement Command Complete lorsque la commande HCI_VS_MSFT_Monitor_Rssi est reçue. Si l’événement Command Complete renvoie un statut de 0, le contrôleur doit générer un HCI_VS_MSFT_Rssi_Event lorsque l’une des conditions suivantes se produit.
- Le RSSI observé pour l’appareil au cours de RSSI_threshold_low_time_interval devient égal ou inférieur à la valeur spécifiée RSSI_threshold_low.
- Le RSSI observé pour l’appareil devient supérieur ou égal à la valeur spécifiée RSSI_threshold_high.
- Le RSSI_sampling_period est valide et la période d’échantillonnage expire.
Le contrôleur doit effectuer tous les nettoyages nécessaires si la connectivité avec l’appareil spécifié est perdue. Dans ce cas, une commande HCI_VS_MSFT_Cancel_Monitor_Rssi n’est pas envoyée au contrôleur.
HCI_VS_MSFT_Cancel_Monitor_Rssi
HCI_VS_MSFT_Cancel_Monitor_Rssi annule une commande HCI_VS_MSFT_Monitor_Rssi précédemment émise. Le contrôleur doit générer rapidement un événement Command Completed en réponse à cette commande.
| Commande | Code | Paramètres de commande | Paramètres de retour |
|---|---|---|---|
| HCI_VS_MSFT_Cancel_Monitor_Rssi | Code de base choisi | Subcommand_opcode, Handle de connexion |
Statut, Subcommand_opcode |
Command_parameters
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x02 | L’opcode de la sous-commande pour HCI_VS_MSFT_Cancel_Monitor_Rssi. |
Connection_Handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Le handle pour la connexion dont le RSSI doit être annulé. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01 to 0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x02 | L’opcode de la sous-commande pour HCI_VS_MSFT_Cancel_Monitor_Rssi. |
Événements générés sauf si masqués
Le contrôleur doit générer un événement Command Complete lorsque la commande HCI_VS_MSFT_Cancel_Monitor_RSSI est reçue.
HCI_VS_MSFT_LE_Monitor_Advertisement
HCI_VS_MSFT_LE_Monitor_Advertisement demande au contrôleur de commencer à surveiller les annonces qui se situent dans la plage RSSI spécifiée et répondent également à l’une des conditions suivantes :
- Un modèle spécifié peut être apparié au paquet d’annonce reçu.
- Un UUID spécifié peut être apparié au paquet d’annonce reçu.
- Une clé de résolution d’identité (IRK) spécifiée peut être utilisée pour résoudre l’adresse privée de l’appareil d’où provient le paquet d’annonce.
- Une adresse Bluetooth spécifiée peut être appariée au paquet d’annonce reçu.
La commande v2 permet à l’hôte de combiner certaines des conditions ci-dessus avec des options régissant la source de l’annonce et la cible d’une annonce dirigée, pour affiner davantage les annonces surveillées. La commande v2 permet également à l’hôte de filtrer quelles annonces surveillées amènent le contrôleur à générer des rapports d’annonces.
| Commande | Code | Paramètres de commande | Paramètres de retour |
|---|---|---|---|
| HCI_VS_MSFT_LE_Monitor_Advertisement [v2] | Code de base choisi | Subcommand_opcode_v2, RSSI_threshold_high, RSSI_threshold_low, RSSI_threshold_low_time_interval, RSSI_sampling_period, Monitor_options, Advertisement_report_filtering_options, Peer_device_address, Peer_device_address_type, Peer_device_IRK, Condition_type, <Paramètres de condition> |
Statut, Subcommand_opcode, Monitor_Handle |
| HCI_VS_MSFT_LE_Monitor_Advertisement [v1] | Code de base choisi | Subcommand_opcode_v1, RSSI_threshold_high, RSSI_threshold_low, RSSI_threshold_low_time_interval, RSSI_sampling_period, Condition_type, <Paramètres de condition> |
Statut, Subcommand_opcode, Monitor_Handle |
Le contrôleur doit générer un événement Command Complete en réponse à cette commande. La valeur du statut doit être fixée à zéro si le contrôleur peut commencer à surveiller, ou à une valeur non nulle sinon. Si le contrôleur ne supporte pas la surveillance RSSI pour les annonces LE, il doit ignorer les valeurs des paramètres RSSI_threshold_high, RSSI_threshold_low, RSSI_threshold_low_time_interval, et RSSI_sampling_period parameter values.
Ce diagramme d’état montre les états de transition sur le contrôleur lors de la surveillance du RSSI pour une annonce.
Le contrôleur doit commencer à surveiller une annonce uniquement lorsque le RSSI reçu est supérieur ou égal à RSSI_threshold_high pour un appareil particulier et que les Monitor_options correspondent (voir ci-dessous). Le contrôleur doit générer un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state défini à 1 et Monitor_handle défini sur le handle pour cette Condition, pour notifier l’hôte que le contrôleur surveille cet appareil particulier pour Condition. De plus, le contrôleur doit propager le premier rapport d’annonce d’une annonce surveillée à l’hôte uniquement lorsque les Advertisement_report_filter_options correspondent (voir ci-dessous).
Les Monitor_options pour un filtre sont considérés comme correspondant sur la base de la logique suivante (en pseudocode) :
MatchesCondition = (PDU Matches Condition Parameters)
IsAdvAMatch = ((Monitor_options bit 0 is set) && ((AdvA == Peer_device_address) && (TxAdd == Peer_device_address_type))) ||
((Monitor_options bit 1 is set) && (AdvA resolvable with Peer_device_IRK))
IsDirectedAdvAMatch = (TargetA is permitted based on the Scanning Filter Policy) &&
(((Monitor_options bit 2 is set) && ((AdvA == Peer_device_address) && (TxAdd == Peer_device_address_type))) ||
((Monitor_options bit 3 is set) && (AdvA resolvable with Peer_device_IRK)))
IsDirectedTargetAMatch = (Monitor_options bit 4 is set) &&
(TargetA is permitted based on the Scanning Filter Policy)
MonitorOptionsMatch = (MatchesCondition && IsAdvAMatch) ||
IsDirectedAdvAMatch ||
IsDirectedTargetAMatch ||
((Monitor_options bit 5 is set) && MatchesCondition)
Et pour une annonce surveillée, les Advertisement_report_filter_options sont considérés comme correspondant sur la base de la logique suivante (en pseudocode) :
IsDuplicateFilterSatisfied = (Advertisement_report_filter_options bit 0 is NOT set || PDU is not a duplicate)
ShouldGenerateLegacyReport = (Advertisement_report_filter_options bit 1 is set) &&
(PDU is Legacy) &&
MonitorOptionsMatch
ShouldGenerateExtendedReport = (Advertisement_report_filter_options bit 2 is set) &&
(PDU is Extended) &&
MonitorOptionsMatch
ShouldGenerateDirectedReport = (Advertisement_report_filter_options bit 3 is set) &&
(PDU is Directed) &&
MonitorOptionsMatch
AdvertisementReportFilterOptionsMatch = IsDuplicateFilterSatisfied &&
(ShouldGenerateLegacyReport || ShouldGenerateExtendedReport || ShouldGenerateDirectedReport)
Le contrôleur doit cesser de surveiller pour Condition si le RSSI des annonces reçues est égal ou inférieur à RSSI_threshold_low pendant RSSI_threshold_low_interval pour l’appareil particulier. Le contrôleur doit générer un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state défini à 0 pour notifier l’hôte que le contrôleur a cessé de surveiller l’appareil particulier pour la Condition. Après que le contrôleur a spécifié l’événement HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state défini à 0, le contrôleur ne doit pas permettre que d’autres paquets d’annonce soient envoyés à l’hôte pour l’appareil jusqu’à ce que le contrôleur ait notifié l’hôte que le RSSI pour l’appareil particulier a atteint ou dépassé RSSI_threshold_high pour l’appareil particulier pour la Condition.
De plus, le contrôleur doit générer un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state défini à 0 pour notifier l’hôte que le contrôleur a cessé de surveiller l’appareil pour la Condition si le RSSI_threshold_low_time_interval spécifié expire sans recevoir de paquets d’annonce de l’appareil. Si le contrôleur surveille un appareil pour une condition particulière, les déclarations suivantes sont vraies.
Si le contrôleur supporte la surveillance RSSI des annonces LE étendues sans échantillonnage, le contrôleur doit propager les paquets d’annonce anonymes à l’hôte si la valeur RSSI du paquet est supérieure ou égale à RSSI_threshold_high. Les annonces anonymes ne doivent pas être suivies et l’événement HCI_VS_MSFT_LE_Monitor_Device_Event ne doit pas être généré.
Si le contrôleur supporte la surveillance RSSI des annonces LE sans échantillonnage, le contrôleur doit générer un rapport d’annonce tronqué dans le cas où le ou les fragments reçus de l’annonce sont concordants, mais où l’annonce entière n’a pas été reçue avec succès.
Le contrôleur doit supporter un minimum de 30 Monitor_handles simultanés, un minimum de 30 appareils suivis simultanés et un minimum de 20 annonces dupliquées suivies simultanées. Le contrôleur doit également être capable d’effectuer une analyse LE continue avec un cycle d’utilisation de 10 %.
Si la résolution d’adresse est activée dans le contrôleur et que l’hôte a l’intention de surveiller un appareil distant avec son IRK stocké avec succès dans la liste de résolution du contrôleur, alors l’hôte doit fournir les paramètres Peer_Identity_Address et Peer_Identity_Address_Type de l’entrée de la liste de résolution de l’appareil distant en tant que Peer_device_address et Peer_device_address_type, respectivement.
| RSSI_sampling_period | Annonces héritées | Annonces étendues (non anonymes) | Annonces étendues (anonymes) |
|---|---|---|---|
| 0x00 | Le contrôleur doit propager tous les paquets d’annonce reçus à l’hôte pour l’appareil pour cette Condition à moins que le contrôleur n’ait précédemment reçu une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable défini à 0x00. Le contrôleur doit propager un paquet d’annonce à l’hôte même si le RSSI reçu est inférieur ou égal à RSSI_threshold_low tant que RSSI_threshold_low_time_interval n’a pas expiré pour l’appareil particulier pour cette Condition. La valeur RSSI de ce paquet d’annonce doit être la valeur RSSI de l’annonce reçue. | Si le contrôleur supporte la surveillance RSSI des annonces LE étendues sans échantillonnage, le même comportement que la colonne Legacy Advertisements sauf qu’un paquet d’annonce est défini comme tous les PDU dans la chaîne d’annonce. | Si le contrôleur supporte la surveillance RSSI des annonces LE étendues sans échantillonnage, le contrôleur doit propager tous les paquets d’annonce reçus à l’hôte pour l’appareil pour cette Condition à moins que le contrôleur n’ait précédemment reçu une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable défini à 0x00. |
| 0x01 to 0xFE | Le contrôleur doit propager les paquets d’annonce hérités à l’hôte tous les RSSI_sampling_period spécifiés à moins que le contrôleur n’ait précédemment reçu une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable défini à 0x00. La valeur RSSI spécifiée pour l’annonce doit être la moyenne de la valeur RSSI reçue pendant cet intervalle d’échantillonnage. Si le contrôleur ne reçoit pas de paquet d’annonce pendant la période d’échantillonnage, il ne doit pas propager une annonce à l’hôte. Il est possible que le RSSI_sampling_period soit inférieur à RSSI_threshold_low_time_interval et que toutes les annonces reçues pendant le RSSI_sampling_period aient un RSSI inférieur à RSSI_threshold_low. Le contrôleur doit toujours propager l’annonce avec la moyenne de la valeur RSSI reçue pendant cet intervalle d’échantillonnage. | Si le contrôleur supporte la surveillance RSSI des annonces LE étendues sans échantillonnage, le contrôleur doit se comporter comme si le RSSI_sampling_period était 0x00. | Si le contrôleur supporte la surveillance RSSI des annonces LE étendues sans échantillonnage, le contrôleur doit se comporter comme si le RSSI_sampling_period était 0x00. |
| 0xFF | Le contrôleur ne doit pas permettre que d’autres paquets d’annonce soient envoyés à l’hôte pour l’appareil pour la Condition jusqu’à ce que le contrôleur ait notifié l’hôte que le RSSI de l’appareil particulier est tombé en dessous de RSSI_threshold_low pendant RSSI_threshold_low_time_interval pour l’appareil particulier pour cette Condition. Cette notification est effectuée en générant un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state défini à 0. | Si le contrôleur supporte la surveillance RSSI des annonces LE étendues sans échantillonnage, même comportement que la colonne Legacy Advertisements. | Si le contrôleur supporte la surveillance RSSI des annonces LE étendues sans échantillonnage, le contrôleur doit se comporter comme si le RSSI_sampling_period était 0x00. |
Si le contrôleur a précédemment reçu une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable défini à 0x00, le temporisateur de période d’échantillonnage ne doit pas être arrêté. Voir l’exemple : HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable sur les filtres avec période d’échantillonnage pour plus d’informations. Si le contrôleur reçoit des paquets d’annonce non dupliqués du même appareil, il doit apparier chaque paquet d’annonce aux Conditions stockées sur le contrôleur.
Si le contrôleur reçoit un paquet d’annonce d’un appareil qui correspond à plusieurs Conditions, alors le contrôleur doit générer un HCI_VS_MSFT_LE_Monitor_Device_Event pour chaque Condition qui a correspondu, avec Monitor_handle défini sur la Condition qui a correspondu.
Si le contrôleur n’est pas capable de surveiller les valeurs RSSI pour tous les appareils à portée qui correspondent à la Condition, il continue de surveiller autant d’appareils qu’il le peut. La décision concernant les appareils à surveiller dépendra des valeurs RSSI des publicités reçues. Le contrôleur doit surveiller les appareils avec la plus grande puissance de signal reçue.
Si le contrôleur a notifié l’hôte concernant un appareil particulier (A) et qu’il surveille les appareils à la capacité maximale du matériel, et si un autre appareil (B) entre en portée avec une valeur RSSI plus élevée, alors le contrôleur doit notifier l’hôte qu’il a cessé de surveiller l’appareil (A) en générant un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state réglé à 0. Le contrôleur doit également générer un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state réglé à 1 pour notifier l’hôte que l’appareil (B) est maintenant surveillé.
Type de condition et paramètres de condition
Le paramètre Condition_type spécifie si le paramètre Condition spécifie un modèle, UUID, IRK ou BD_ADDR.
Si le paramètre Condition_type spécifie un modèle, le Condition contient deux sections qui contiennent le nombre de modèles présents dans la Condition, et les données du modèle.
Nombre de modèles spécifie le nombre de modèles à faire correspondre.
Données du modèle ont le format suivant.
- Longueur spécifie la longueur de ce modèle incluant le type de données et l’octet de départ du modèle.
- Type AD spécifie le champ Type AD.
- Début du modèle spécifie la position de l’octet de départ du modèle immédiatement après le Type AD.
- Le Modèle a une taille de (Longueur - 0x2) et est le modèle à faire correspondre pour le type AD spécifié dans le paquet de publicité à partir de l’octet de départ spécifié.
S’il y a plusieurs modèles spécifiés, le contrôleur doit s’assurer qu’au moins un modèle correspond à la publicité reçue.
Si le contrôleur prend en charge la surveillance RSSI des publicités étendues LE sans échantillonnage :
Le contrôleur doit rechercher le modèle dans les 251 premiers octets des Données de Publicité de l’Hôte et peut rechercher dans tous les octets restants des Données de Publicité de l’Hôte. Si la section AD dépasse les 251 premiers octets des Données de Publicité de l’Hôte, le contrôleur doit rechercher le modèle dans la partie de la section AD qui se trouve dans les 251 premiers octets des Données de Publicité de l’Hôte et peut rechercher dans tous les octets restants des Données de Publicité de l’Hôte. Remarque : en fonction de la fragmentation par l’annonceur, les 251 premiers octets des Données de Publicité de l’Hôte peuvent s’étendre sur les AdvData de plusieurs PDU de publicité. Les scanners doivent veiller à limiter le nombre d’AuxPtrs qu’ils suivent, pour éviter de suivre des chaînes de PDU trop longues.
Le contrôleur doit suivre sur la base de chaque adresse d’appareil par ensemble de publicité. Le contrôleur doit propager un HCI_VS_MSFT_LE_Monitor_Device_Event pour chaque ensemble de publicité qui correspond au modèle, même si la publicité provient de la même adresse d’appareil.
Si le paramètre Condition_type spécifie un UUID, le paramètre Condition contient un Type de UUID et un UUID. Le Type de UUID spécifie si l’UUID est de 16 bits, 32 bits ou 128 bits. Le contrôleur doit analyser l’UUID de Service du paquet de publicité pour vérifier l’UUID spécifié. Si le Type de UUID est défini comme 0x01, le contrôleur doit analyser la Liste Incomplète des UUIDs de service de 16 bits et la liste complète des UUIDs de service de 16 bits spécifiés dans le Type de AD de Service. Si le Type de UUID est défini comme 0x02, le contrôleur doit analyser la Liste Incomplète des UUIDs de service de 32 bits et la liste complète des UUIDs de 32 bits spécifiés dans le Type de AD de Service. Si le Type de UUID spécifié est 0x03, le contrôleur doit analyser la Liste Incomplète des UUIDs de Service de 128 bits et la liste complète des UUIDs de Service de 128 bits spécifiés dans le Type de AD de Service.
Si le contrôleur prend en charge la surveillance RSSI des publicités étendues LE sans échantillonnage :
Le contrôleur doit rechercher l’UUID de Service dans les 251 premiers octets des Données de Publicité de l’Hôte et peut rechercher dans tous les octets restants des Données de Publicité de l’Hôte. Si la section AD dépasse les 251 premiers octets des Données de Publicité de l’Hôte, le contrôleur doit rechercher l’UUID de Service dans la partie de la section AD qui se trouve dans les 251 premiers octets des Données de Publicité de l’Hôte et peut rechercher dans tous les octets restants des Données de Publicité de l’Hôte. Remarque : en fonction de la fragmentation par l’annonceur, les 251 premiers octets des Données de Publicité de l’Hôte peuvent s’étendre sur les AdvData de plusieurs PDU de publicité. Les scanners doivent veiller à limiter le nombre d’AuxPtrs qu’ils suivent, pour éviter de suivre des chaînes de PDU trop longues.
Le contrôleur doit suivre sur la base de chaque adresse d’appareil par ensemble de publicité. Le contrôleur doit propager un HCI_VS_MSFT_LE_Monitor_Device_Event pour chaque ensemble de publicité qui correspond à l’UUID de Service, même si la publicité provient du même appareil.
Si le paramètre Condition_type spécifie un IRK, le paramètre Condition contient l’IRK.
Si le paramètre Condition_type spécifie une adresse Bluetooth, le paramètre Condition contient le type d’adresse et BD_ADDR.
Le contrôleur doit continuer à surveiller en fonction des conditions, même lorsque la numérisation (Active ou Passive) est activée. Lorsque la numérisation active est activée, la réponse de numérisation pour une publicité correspondant à un filtre doit être propagée à l’hôte.
Si le contrôleur reçoit une commande HCI_VS_MSFT_LE_Monitor_Advertisement lorsque les filtres sont désactivés (en raison d’une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable précédemment reçue avec Enable réglé à 0x00), le contrôleur doit accepter la commande si possible, mais la mettre à l’état désactivé. Le contrôleur peut également refuser la commande pour d’autres raisons telles que l’épuisement des ressources.
Si tous les bits de Monitor_options sont effacés, le contrôleur doit renvoyer le code d’erreur Paramètres de commande HCI invalides (0x12).
Si le bit 1 ou le bit 3 de Monitor_options est réglé et que Peer_device_IRK est réglé sur un IRK invalide, ou si aucun des bits de Monitor_options n’est réglé, le contrôleur doit renvoyer le code d’erreur Paramètres de commande HCI invalides (0x12).
Si le bit 0 ou le bit 1 ou le bit 2 ou le bit 3 de Monitor_options est réglé et que Condition_type est réglé sur 0x03 ou 0x04, alors le contrôleur doit renvoyer le code d’erreur Paramètres de commande HCI invalides (0x12).
Si le bit 0 de Advertisement_report_filter_options est réglé et que RSSI_sampling_period est une valeur autre que 0x00, le contrôleur doit renvoyer le code d’erreur Paramètres de commande HCI invalides (0x12).
Paramètres manquants
Lorsqu’une version de cette commande est émise qui n’inclut pas tous les paramètres, les éléments suivants doivent être utilisés :
| Paramètre | Valeur |
|---|---|
| Monitor_options | Bit 5 réglé ; tous les autres bits effacés |
| Advertisement_report_filter_options | Bits 1 et 2 réglés ; tous les autres bits effacés |
| Peer_device_IRK | 0x0000000000000000 0000000000000000 |
| Peer_device_address | 0x000000000000 |
| Peer_device_address_type | 0x00 |
Command_parameters
Subcommand_opcode_v1 (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x03 | L’opcode de sous-commande pour HCI_VS_MSFT_LE_Monitor_Advertisement [v1]. |
Subcommand_opcode_v2 (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x0F | L’opcode de sous-commande pour HCI_VS_MSFT_LE_Monitor_Advertisement [v2]. |
RSSI_threshold_high (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0xXX | La valeur RSSI maximale attendue. Le contrôleur génère un événement si le RSSI observé devient supérieur ou égal à cette valeur. Unité : dBm Plage obligatoire : -127 à 20 (entier signé) |
RSSI_threshold_low (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0xXX | La valeur RSSI minimale attendue. Le contrôleur génère un événement si le RSSI observé devient inférieur ou égal à cette valeur. Unité : dBm Plage obligatoire : -127 à 20 (entier signé) |
RSSI_threshold_low_time_interval (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Valeur réservée. |
| N = 0xXX | Le temps en secondes pendant lequel la valeur RSSI doit être inférieure à RSSI_threshold_low avant qu’un HCI_VS_MSFT_Rssi_Event ne soit généré Période = N * 1 seconde Plage obligatoire : 0x01 à 0x3C. |
RSSI_sampling_period (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Le contrôleur doit propager toutes les publicités reçues à l’hôte. |
| N = 0xXX | L’intervalle d’échantillonnage en millisecondes. Période = N * 100 millisecondes. Plage obligatoire : 0x01 à 0xFE |
| 0xFF | Le contrôleur ne doit pas propager les publicités reçues à l’hôte. |
Monitor_options (1 octet) :
| Nombre de bits | Description des paramètres |
|---|---|
| 0 | Le contrôleur doit surveiller les PDU de publicité où AdvA ou son adresse d’identité résolue correspond à Peer_device_address et Peer_device_address_type et où TargetA n’est pas présent ou, s’il est présent, le TargetA est autorisé en fonction de la politique de filtre de numérisation, si ces PDU correspondent à la condition spécifiée dans Condition_Type. |
| 1 | Le contrôleur doit surveiller les PDU de publicité où AdvA est résolvable avec Peer_device_IRK et où TargetA n’est pas présent ou, s’il est présent, le TargetA est autorisé en fonction de la politique de filtre de numérisation, si ces PDU correspondent à la condition spécifiée dans Condition_Type. Ce bit ne doit pas être réglé si la confidentialité de la couche de liaison est utilisée dans le contrôleur. |
| 2 | Le contrôleur doit surveiller les PDU de publicité dirigés où le TargetA est autorisé en fonction de la politique de filtre de numérisation et où AdvA ou son adresse d’identité résolue correspond à Peer_device_address et Peer_device_address_type. Ceci indépendamment du fait que le PDU corresponde à la condition spécifiée dans Condition_Type. |
| 3 | Le contrôleur doit surveiller les PDU de publicité dirigés où le TargetA est autorisé en fonction de la politique de filtre de numérisation et où AdvA est résolvable avec Peer_device_IRK. Ceci indépendamment du fait que le PDU corresponde à la condition spécifiée dans Condition_Type. Ce bit ne doit pas être réglé si la confidentialité de la couche de liaison est utilisée dans le contrôleur. |
| 4 | Le contrôleur doit surveiller les PDU de publicité dirigés où le TargetA est autorisé en fonction de la politique de filtre de numérisation, indépendamment de la valeur de Peer_device_address et Peer_device_address_type ou Peer_device_IRK et indépendamment du fait que le PDU corresponde à la condition spécifiée dans Condition_Type. |
| 5 | Le contrôleur doit surveiller les PDU de publicité de tout AdvA où TargetA n’est pas présent ou, s’il est présent, le TargetA est autorisé en fonction de la politique de filtre de numérisation, si ces PDU correspondent à la condition spécifiée dans Condition_Type. |
| Tous les autres bits | Paramètres réservés pour un usage ultérieur |
Advertisement_report_filtering_options (1 octet) :
| Nombre de bits | Description des paramètres |
|---|---|
| 0 | Filtrer les PDU de publicité en double. Ce bit ne doit être réglé que si RSSI_sampling_period est 0x00. |
| 1 | Le contrôleur doit générer des événements HCI_LE_Advertising_Report ou HCI_LE_Directed_Advertising_Report ou HCI_LE_Extended_Advertising_Report pour les PDU de publicité hérités, si ces PDU correspondent aux Monitor_options spécifiées. |
| 2 | Le contrôleur doit générer des événements HCI_LE_Extended_Advertising_Report pour les PDU de publicité étendue, si ces PDU correspondent aux Monitor_options spécifiées. |
| 3 | Le contrôleur doit générer des événements HCI_LE_Advertising_Report ou HCI_LE_Directed_Advertising_Report ou HCI_LE_Extended_Advertising_Report pour les PDU de publicité dirigée, si ces PDU correspondent aux Monitor_options spécifiées. |
| Tous les autres bits | Paramètres réservés pour un usage ultérieur |
Peer_device_address (6 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXXXXXXXXXX | Adresse d’appareil publique ou adresse d’appareil aléatoire à faire correspondre. |
Peer_device_address_type (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Adresse d’appareil publique |
| 0x01 | Adresse d’appareil aléatoire |
| Toutes les autres erreurs | Paramètres réservés pour un usage ultérieur |
Peer_device_IRK (16 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0x0000000000000000 0000000000000000 | IRK invalide. Ne doit pas être la valeur lorsque le bit 1 de Monitor_options est réglé ou lorsque le bit 3 de Monitor_options est réglé. |
| 0xXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX | IRK de l’appareil à faire correspondre. Peer_device_address et Peer_device_address_type doivent être renseignés. |
Condition_type (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x01 | La condition est un modèle qui doit être fait correspondre sur la publicité. |
| 0x02 | La condition est un Type de UUID et un UUID. |
| 0x03 | La condition est la résolution d’un IRK. Exclu si l’un des bits 0, 1, 2 ou 3 de Monitor_options est réglé. |
| 0x04 | La condition est un type d’adresse Bluetooth et une adresse Bluetooth. Exclu si l’un des bits 0, 1, 2 ou 3 de Monitor_options est réglé. |
Condition : Les champs applicables pour Condition dépendent de la valeur de Condition_type. Voir la section Condition_type et paramètres de condition pour plus d’informations.
Number_of_patterns (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0xXX | Le nombre de modèles spécifiés dans le paramètre Pattern_data. |
Pattern_data (>3 octets) :
| Valeur | Description des paramètres |
|---|---|
| Longueur | Longueur de ce modèle. |
| Type de données | Type de données de la section de publicité. Les valeurs sont listées dans le document Bluetooth Assigned Numbers. |
| Octet de départ | Position de départ du modèle à faire correspondre pour le type de données spécifié. |
| Modèle | Modèle à faire correspondre (taille de Length – 0x2 octets). |
UUID_type (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x01 | Le UUID est un service de 16 bits. |
| 0x02 | Le UUID est un service de 32 bits. |
| 0x03 | Le UUID est un service de 128 bits. |
UUID (2, 4 ou 16 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | 2 octets si UUID_type est 0x01. 4 octets si UUID_type est 0x02. 16 octets si UUID_type est 0x03. |
IRK (16 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX | IRK à utiliser pour résoudre l’adresse privée. |
Address_type (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Adresse d’appareil publique. |
| 0x01 | Adresse d’appareil aléatoire. |
| 0x02 to 0xFF | Valeurs réservées pour un usage futur. |
BD_ADDR (6 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXXXXXXXXXX | L’adresse Bluetooth de l’appareil à surveiller. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x07 | Le contrôleur doit renvoyer la Capacité Mémoire Dépassée s’il n’a pas assez de mémoire pour traiter la commande. |
| Code d’erreur | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x03 or 0x0F | L’opcode de sous-commande pour HCI_VS_MSFT_LE_Monitor_Advertisement [v1] ou HCI_VS_MSFT_LE_Monitor_Advertisement [v2], selon la commande soumise. |
Monitor_handle (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 to 0xFF | Le handle de cette règle. Ce handle est utilisé comme paramètre pour HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement pour annuler la surveillance de la publicité. Ce paramètre n’est valide que si Status est 0x00. |
Événements générés sauf si masqués
Lorsque la commande HCI_VS_MSFT_LE_Monitor_Advertisement est reçue, le contrôleur doit générer un événement Command Complete.
HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement
HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement annule une commande HCI_VS_MSFT_LE_Monitor_Advertisement précédemment émise.
| Commande | Code | Paramètres de commande | Paramètres de retour |
|---|---|---|---|
| HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement | Code de base choisi | Subcommand_opcode, Monitor_handle |
Statut, Subcommand_opcode |
Le contrôleur doit générer rapidement un événement Command Completed en réponse à cette commande.
Command_parameters
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x04 | L’opcode de sous-commande pour HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement. |
Connection_Handle (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0xXX | Le handle du filtre à annuler. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x07 | Le contrôleur doit renvoyer la Capacité Mémoire Dépassée s’il n’a pas assez de mémoire pour traiter la commande. |
| Code d’erreur | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x04 | L’opcode de sous-commande pour HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement. |
Événements générés sauf si masqués
Le contrôleur doit générer un événement Command Complete lorsque la commande HCI_VS_MSFT_LE_Cancel_Monitor_Advertisement est reçue.
HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable
HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable définit l’état des filtres de publicité.
| Commande | Code | Paramètres de commande | Paramètres de retour |
|---|---|---|---|
| HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable | Code de base choisi | Subcommand_opcode, Enable |
Statut, Subcommand_opcode |
Si Enable est réglé à 0x00, le contrôleur doit propager les publicités reçues à l’hôte en fonction des paramètres de la liste d’acceptation de filtres existante. Le contrôleur doit continuer à surveiller les appareils qui sont actuellement surveillés et générer un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state réglé à 0 si l’appareil n’est plus surveillé. Le contrôleur doit générer un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state réglé à 1 si un nouvel appareil est surveillé. L’hôte peut émettre HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable réglé à 0x01 pour réactiver toutes les conditions de filtre.
Si Enable est réglé à 0x01, cette commande active tous les filtres qui ont été définis avec une commande HCI_VS_MSFT_LE_Monitor_Advertisement précédemment émise. Le contrôleur doit rejeter une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable si elle ne modifie pas l’état du filtre :
- Le contrôleur doit rejeter une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable réglé à 0x01 si elle a précédemment reçu une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable réglé à 0x01.
- Le contrôleur doit rejeter la commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable réglé à 0x00 si elle a précédemment reçu une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable réglé à 0x00.
L’état par défaut du filtre de publicité doit être désactivé. Cet état est équivalent à la réception précédente par le contrôleur d’une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable réglé à 0x00. Le contrôleur doit générer rapidement un événement Command Completed en réponse à cette commande.
Command_parameters
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x05 | L’opcode de sous-commande pour HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable. |
Enable (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Revenir au comportement actuel de la liste d’acceptation des filtres, mais continuer à surveiller les appareils en fonction de la Condition des commandes HCI_VS_MSFT_LE_Monitor_Advertisement. |
| 0x01 | Activer toutes les commandes HCI_VS_MSFT_LE_Monitor_Advertisement émises sur le contrôleur. |
Return_parameter
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x0C | Le contrôleur doit renvoyer Commande Interdite si le contrôleur a rejeté la commande parce qu’il avait précédemment vu une commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable avec Enable réglé à la même valeur que cette commande. |
| Code d’erreur | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x05 | L’opcode de sous-commande pour HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable. |
Événements générés sauf si masqués
Le contrôleur doit générer un événement Command Complete lorsque la commande HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable est reçue.
HCI_VS_MSFT_Read_Absolute_RSSI
HCI_VS_MSFT_Read_Absolute_RSSI lit la valeur absolue de l’Indication de Puissance du Signal Reçu (RSSI) pour une connexion BR/EDR à partir du contrôleur.
| Commande | Code | Paramètres de commande | Paramètres de retour |
|---|---|---|---|
| HCI_VS_MSFT_Read_Absolute_RSSI | Code de base choisi | Subcommand_opcode, Handle de connexion |
Statut, Subcommand_opcode, Handle de connexion, RSSI |
Un handle de connexion est fourni à la fois comme commande et paramètre de retour pour identifier la connexion ACL dont le RSSI est en cours de lecture. La métrique RSSI est la puissance absolue du signal du récepteur en dBm avec une précision de ± 6 dB. Si le RSSI ne peut pas être lu, la métrique RSSI doit être réglée à 127. Le contrôleur doit toujours terminer cette commande rapidement avec un événement Command Completed.
Command_parameters
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x06 | L’opcode de sous-commande pour HCI_VS_MSFT_Read_Absolute_RSSI. |
Connection_Handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Le handle de la connexion BR/EDR dont le RSSI doit être lu. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01 to 0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x06 | L’opcode de sous-commande pour HCI_VS_MSFT_Read_Absolute_RSSI. |
Connection_Handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Le handle de la connexion BR/EDR dont le RSSI a été lu. |
RSSI (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| N = 0xXX | La valeur RSSI pour la connexion BR/EDR. Unité : dBm Plage obligatoire : -128 à 127 (entier signé) |
Événements générés sauf si masqués
Le contrôleur doit générer un événement Command Complete lorsque la commande HCI_VS_MSFT_Read_Absolute_RSSI est terminée.
Événements HCI Bluetooth définis par Microsoft
Tous les événements HCI Bluetooth définis par Microsoft sont des événements définis par le fournisseur et utilisent le code d’événement 0xFF. Les données d’événement pour les événements Microsoft commencent toujours par une chaîne de bytes constante pour distinguer les événements définis par Microsoft des autres événements définis par le fournisseur. La longueur et la valeur de la chaîne constante sont définies par le fabricant du contrôleur et renvoyées en réponse à HCI_VS_MSFT_Read_Supported_Features.
| Événement HCI | Description |
|---|---|
| HCI_VS_MSFT_Rssi_Event | HCI_VS_MSFT_RSSI_Event indique qu’une commande HCI_VS_MSFT_Monitor_Rssi est terminée. |
| HCI_VS_MSFT_LE_Monitor_Device_Event | HCI_VS_MSFT_LE_Monitor_Device_Event indique que le contrôleur a commencé ou cessé de surveiller un appareil Bluetooth LE. |
HCI_VS_MSFT_RSSI_Event
HCI_VS_MSFT_RSSI_Event indique qu’une commande HCI_VS_MSFT_Monitor_Rssi est terminée. Si le paramètre Status est à zéro, la commande est terminée car la valeur RSSI pour l’appareil distant a changé pour une valeur en dehors de la plage spécifiée. Si le paramètre Status est non nul, la commande s’est terminée parce que la valeur RSSI de la connexion ne peut plus être surveillée.
| Événement | Code de l’événement | Code d’événement Microsoft | Paramètres de l’événement |
|---|---|---|---|
| HCI_VS_MSFT_RSSI_Event | 0xFF | 0x01 | Event_prefix, Microsoft_event_code, Statut, Handle de connexion, RSSI |
Event_parameters
Event_prefix (taille variable) :
| Valeur | Description des paramètres |
|---|---|
| Préfixe de l’événement | Le préfixe de l’événement qui indique que cet événement est défini par Microsoft. La taille et la valeur sont telles que retournées par la commande HCI_VS_MSFT_Read_Supported_Features. |
Microsoft_event_code (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x01 | Le code de l’événement pour HCI_VS_MSFT_RSSI_Event. |
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Opération réussie. La valeur RSSI de la connexion a rempli l’une des conditions suivantes. Le RSSI a atteint ou dépassé RSSI_threshold_high. Le RSSI a atteint ou est tombé en dessous de RSSI_threshold_low pendant RSSI_threshold_low_time_interval secondes. La période d’échantillonnage RSSI (RSSI_sampling_period) a expiré et cet événement a été généré pour notifier l’hôte de la valeur RSSI. |
| 0x01 to 0xFF | Échec. La valeur RSSI de la connexion ne peut plus être surveillée. Le code d’erreur est généralement l’un des codes décrivant pourquoi la connexion ACL sous-jacente a été perdue. |
Connection_Handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Le handle pour la connexion dont le RSSI doit être surveillé. |
RSSI (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0xXX | La valeur RSSI mesurée du lien pour la connexion. Unité : dBm Plage BR/EDR : -128 à 127 (entier signé) Plage LE : -127 à 20 (entier signé) |
HCI_VS_MSFT_LE_Monitor_Device_Event
HCI_VS_MSFT_LE_Monitor_Device_Event indique que le contrôleur a commencé ou cessé de surveiller un appareil Bluetooth LE.
Si la valeur du paramètre Monitor_state est 1, le contrôleur a commencé à surveiller le périphérique Bluetooth avec l’adresse BD spécifiée. Si la valeur du paramètre Monitor_state est 0, le contrôleur a cessé de surveiller le périphérique Bluetooth avec l’adresse BD spécifiée.
| Événement | Code de l’événement | Code d’événement Microsoft | Paramètres de l’événement |
|---|---|---|---|
| HCI_VS_MSFT_LE_Monitor_Device_Event | 0xFF | 0x02 | Event_prefix, Microsoft_event_code, Address_type, BD_ADDR, Monitor_handle, Monitor_state |
Le contrôleur ne doit pas générer un HCI_VS_MSFT_LE_Monitor_Device_Event avec le paramètre Monitor_state défini à 0 s’il n’a pas déjà généré un HCI_VS_MSFT_LE_Monitor_Device_Event avec Monitor_state défini à 1.
Event_parameters
Event_prefix (taille variable) :
| Valeur | Description des paramètres |
|---|---|
| Préfixe de l’événement | Le préfixe de l’événement qui indique que cet événement est défini par Microsoft. La taille et la valeur sont telles que retournées par la commande HCI_VS_MSFT_Read_Supported_Features. |
Microsoft_event_code (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x02 | e code de l’événement pour HCI_VS_MSFT_LE_Monitor_Device_Event. |
Address_type (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Adresse d’appareil publique. |
| 0x01 | Adresse d’appareil aléatoire. |
| 0x02 to 0xFF | Valeurs réservées pour un usage futur. |
BD_ADDR (6 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXXXXXXXXXX | L’adresse Bluetooth du périphérique. |
Monitor_handle (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0xXX | Le handle du filtre spécifié pour la commande HCI_VS_MSFT_LE_Monitor_Advertisement. |
Monitor_state (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | Le contrôleur a cessé de surveiller le périphérique spécifié par BD_ADDR et Monitor_handle. |
| 0x01 | Le contrôleur a commencé à surveiller le périphérique spécifié par BD_ADDR et Monitor_handle. |
Commandes AVDTP HCI définies par Microsoft
Les commandes AVDTP HCI suivantes fournissent un support pour le déchargement de la bande latérale audio A2DP. Pour plus d’informations, veuillez consulter la section Audio Sideband A2DP Offload.
| Commandes HCI AVDTP | Description |
|---|---|
| HCI_VS_MSFT_Avdtp_Capabilities_Configuration | Configure l’interface de transport audio et renvoie les capacités des codecs du contrôleur Bluetooth, qui est une liste de blocs d’informations sur les codecs. |
| HCI_VS_MSFT_Avdtp_Open | Alloue et configure les ressources d’AVDTP offload dans le contrôleur. |
| HCI_VS_MSFT_Avdtp_Start | Commence la diffusion audio du transport audio aux paquets média AVDTP transmis. |
| HCI_VS_MSFT_Avdtp_Suspend | Arrête l’activité de streaming initiée par HCI_VS_MSFT_Avdtp_Start. |
| HCI_VS_MSFT_Avdtp_Close | Libère les ressources d’AVDTP offload allouées par HCI_VS_MSFT_Avdtp_Open. |
HCI_VS_MSFT_Avdtp_Capabilities_Configuration
HCI_VS_MSFT_Avdtp_Capabilities_Configuration configure l’interface de transport audio et retourne les capacités du codec du contrôleur Bluetooth, qui est une liste de blocs d’informations sur le codec. Chaque bloc d’informations sur les codecs décrit un codec pris en charge.
Certains paramètres ci-dessous sont des tableaux de structures de longueur variable, il est donc supposé que tous ces paramètres tiendront toujours dans une seule commande HCI et dans un seul événement HCI correspondant.
Command_parameters
External_codec_count (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00-0xFF | Le nombre de blocs de capacités de codec qui suivent. |
External_codec_capability (longueur variable) :
| Valeur | Description des paramètres |
|---|---|
| Bloc de capacités du codec | Un bloc d’informations sur les capacités du codec comme décrit dans les informations sur les capacités du codec. Cela décrit un seul codec pris en charge par le périphérique connecté à l’interface audio. |
Cette structure de données se répète External_codec_count fois.
Audio_interface_parameter_count (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00-0xFF | Le nombre de paramètres d’interface audio qui suivent. |
Audio_interface_parameter (longueur variable)
| Valeur | Description des paramètres |
|---|---|
| Paramètre d’interface audio | Un paramètre d’interface audio comme décrit ci-dessus, défini par le périphérique connecté à l’interface audio. |
Cette structure de données se répète Audio_interface_parameter_count fois.
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01-0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x07 | L’opcode de sous-commande pour HCI_VS_MSFT_Avdtp_Capabilities_Configuration. |
Internal_codec_count (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00-0xFF | Le nombre de blocs de capacités de codec internes qui suivent. |
Internal_codec_capability (longueur variable) :
| Valeur | Description des paramètres |
|---|---|
| Bloc de capacités du codec | Un bloc d’informations sur les capacités du codec comme décrit dans Audio Sideband A2DP Offload. Cela décrit un seul codec pris en charge par le contrôleur Bluetooth. |
Cette structure de données se répète Internal_codec_count fois.
Audio_interface_parameter_count (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00-0xFF | Le nombre de paramètres d’interface audio qui suivent. |
Audio_interface_parameter (longueur variable)
| Valeur | Description des paramètres |
|---|---|
| Paramètre d’interface audio | Un paramètre d’interface audio comme décrit ci-dessus. Le logiciel hôte passe ce paramètre au périphérique connecté à l’interface audio. |
Cette structure de données se répète Audio_interface_parameter_count fois.
HCI_VS_MSFT_Avdtp_Open
Alloue et configure les ressources d’AVDTP offload dans le contrôleur.
Certains paramètres ci-dessous sont des tableaux de structures de longueur variable, il est donc supposé que tous ces paramètres tiendront toujours dans une seule commande HCI et dans un seul événement HCI correspondant.
Command_parameters
Connection_handle (2 octets)
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Identifie le canal média AVDTP L2CAP connecté au périphérique distant. |
L2cap_destination_cid (2 octets)
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | CID de destination L2CAP du canal média AVDTP |
L2cap_mtu (2 octets)
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | MTU du canal média AVDTP L2CAP |
Configured_codec_capability (longueur variable) :
| Valeur | Description des paramètres |
|---|---|
| Bloc de capacités du codec | Un bloc d’informations sur les capacités du codec comme décrit dans Audio Sideband A2DP Offload. Cela décrit le codec configuré pour le média AVDTP. |
Audio_interface_parameter_count (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00-0xFF | Le nombre de paramètres d’interface audio qui suivent. |
Audio_interface_parameter (longueur variable)
| Valeur | Description des paramètres |
|---|---|
| Paramètre d’interface audio | Un paramètre d’interface audio comme décrit ci-dessus. Le périphérique connecté à l’interface audio spécifie ces paramètres pour une instance de flux particulière. |
Cette structure de données se répète Audio_interface_parameter_count fois.
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01-0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x08 | L’opcode de sous-commande pour HCI_VS_MSFT_Avdtp_Open. |
Avdtp_offload_handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Identifie la ressource allouée pour le flux déchargé. |
Audio_interface_parameter_count (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00-0xFF | Le nombre de paramètres d’interface audio qui suivent. |
Audio_interface_parameter (longueur variable)
| Valeur | Description des paramètres |
|---|---|
| Paramètre d’interface audio | Un paramètre d’interface audio comme décrit ci-dessus. Le logiciel hôte passe ce paramètre au périphérique connecté à l’interface audio pour l’instance de flux. |
Cette structure de données se répète Audio_interface_parameter_count fois.
HCI_VS_MSFT_Avdtp_Start
Cette commande commence la diffusion audio depuis le transport audio vers les paquets médias AVDTP transmis. Lors de l’exécution de cette commande, le contrôleur Bluetooth commence l’activité suivante.
- Reçoit les données audio du transport audio
- Si l’encodeur est dans le contrôleur Bluetooth, encode les données reçues du transport audio pour produire des trames encodées
- Si l’encodeur est dans le DSP audio, extrait les trames encodées du transport audio
- Assemble les trames encodées en charges utiles média AVDTP
- Construit et transmet des paquets média AVDTP contenant les charges utiles média
Command_parameters
Avdtp_offload_handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Identifie la ressource allouée pour le flux déchargé. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01-0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x09 | L’opcode de sous-commande pour HCI_VS_MSFT_Avdtp_Start. |
HCI_VS_MSFT_Avdtp_Suspend
Arrête l’activité de streaming initiée par HCI_VS_MSFT_Avdtp_Start.
Command_parameters
Avdtp_offload_handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Identifie la ressource allouée pour le flux déchargé |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01-0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x0A | L’opcode de sous-commande pour HCI_VS_MSFT_Avdtp_Suspend. |
HCI_VS_MSFT_Avdtp_Close
Libère les ressources d’AVDTP offload allouées par HCI_VS_MSFT_Avdtp_Open.
Command_parameters
Avdtp_offload_handle (2 octets) :
| Valeur | Description des paramètres |
|---|---|
| 0xXXXX | Remarque : Cette valeur n’est plus valide après la fin de cette commande. |
Paramètres de retour
État (1 octet) :
| Valeur | Description des paramètres |
|---|---|
| 0x00 | La commande a réussi. |
| 0x01-0xFF | La commande a échoué. Veuillez consulter la section Codes d’erreur dans la spécification Bluetooth Core pour plus de détails. |
Subcommand_opcode (1 octet):
| Valeur | Description des paramètres |
|---|---|
| 0x0B | L’opcode de sous-commande pour HCI_VS_MSFT_Avdtp_Close. |
| Valeur | Description des paramètres |
|---|---|
| 0x00 | |
| 0x01 | Le contrôleur a commencé à surveiller le périphérique spécifié par BD_ADDR et Monitor_handle. |
Annexe
Cette section contient des exemples et des diagrammes d’extensions HCI Bluetooth définies par Microsoft.
Exemple : Correspondance de modèles pour HCI_VS_MSFT_LE_Monitor_Advertisement
Cet exemple montre une commande HCI_VS_MSFT_LE_Monitor_Advertisement reçue et les évaluations de trois paquets publicitaires différents par rapport aux paramètres de la commande.
Commande HCI_VS_MSFT_LE_Monitor_Advertisement reçue. Une commande HCI_VS_MSFT_LE_Monitor_Advertisement est reçue par le contrôleur et contient les paramètres suivants.
| Paramètre | Valeur | Notes |
|---|---|---|
| Subcommand_opcode | 0x03 | Opcode de sous-commande pour HCI_VS_MSFT_LE_Monitor_Advertisement |
| RSSI_threshold_high | 0x01 | 1dB |
| RSSI_threshold_low | 0xCE | -50dB |
| RSSI_threshold_low_time_interval | 0x05 | 5 secondes |
| RSSI_sampling_period | 0xFF | Aucun échantillonnage |
| Condition_type | 0x01 | Condition |
| Condition | 0x02 | Deux modèles doivent être mis en correspondance |
| 0x03 | Longueur du premier modèle, y compris le type AD et la position de départ | |
| 0x01 | Type AD | |
| 0x00 | Position de départ suivant le type AD | |
| 0x01 | Premier modèle à faire correspondre | |
| 0x06 | Longueur du deuxième modèle, y compris le type AD et la position de départ | |
| 0xFF | Type AD (données spécifiques au fabricant) | |
| 0x00 | Position de départ suivant le type AD | |
| 0x00 | Deuxième modèle à faire correspondre | |
| 0x06 | ||
| 0xFF | ||
| 0xFF |
Le contrôleur reçoit ensuite les paquets publicitaires suivants.
Paquet publicitaire [A]
0x02 0x01 0x01 0x07 0x09 0x54 0x61 0x62 0x6C 0x65 0x74 0x05 0xFF 0x00 0x06 0xFF 0xFFPaquet publicitaire [B]
0x02 0x01 0x01 0x07 0x09 0x54 0x61 0x62 0x6C 0x65 0x74 0x04 0xFF 0x00 0x06 0xFFPaquet publicitaire [C]
0x07 0x09 0x54 0x61 0x62 0x6C 0x65 0x74 0x05 0xFF 0x00 0x06 0xFF 0xFFPaquet publicitaire [D]
0x02 0x01 0x02 0x05 0xFF 0x00 0x06 0xFF 0x01
Évaluation de la correspondance pour le paquet publicitaire [A]
| Description | active |
|---|---|
| Type AD du premier modèle à faire correspondre | 0x01 |
| Longueur du premier modèle à faire correspondre | 0x03 - 0x02 = 0x01 octet |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0x01 | 0x01 |
| Octets à la position 0x00 pour le type AD 0x01 | 0x01 (MATCH!) |
| Type AD du deuxième modèle à correspondre | 0xFF (données spécifiques au fabricant) |
| Longueur du deuxième modèle à faire correspondre | 0x06 - 0x02 = 0x04 octets |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF 0xFF |
| Octets à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF 0xFF (MATCH!) |
Verdict : PASS (les deux modèles correspondent)
Évaluation de la correspondance pour le paquet publicitaire [B]
| Description | active |
|---|---|
| Type AD du premier modèle à faire correspondre | 0x01 |
| Longueur du premier modèle à faire correspondre | 0x03 - 0x02 = 0x01 octet |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0x01 | 0x01 |
| Octets à la position 0x00 pour le type AD 0x01 | 0x01 (MATCH!) |
| Type AD du deuxième modèle à correspondre | 0xFF (données spécifiques au fabricant) |
| Longueur du deuxième modèle à faire correspondre | 0x06 - 0x02 = 0x04 octets |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF 0xFF |
| Octets à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF (aucune correspondance) |
Verdict : PASS (uniquement les premières correspondances de modèle)
Évaluation de la correspondance pour le paquet publicitaire [C]
| Description | active |
|---|---|
| Type AD du premier modèle à faire correspondre | 0x01 |
| Longueur du premier modèle à faire correspondre | 0x03 - 0x02 = 0x01 octet |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0x01 | 0x01 |
| Octets à la position 0x00 pour le type AD 0x01 | Undefined. La publicité ne contient pas de données avec le type AD 0x01. |
| Type AD du deuxième modèle à correspondre | 0xFF (données spécifiques au fabricant) |
| Longueur du deuxième modèle à faire correspondre | 0x06 - 0x02 = 0x04 octets |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF 0xFF |
| Octets à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF 0xFF (MATCH!) |
Verdict : PASS (seulement la deuxième correspondance de modèle)
Évaluation de la correspondance pour le paquet publicitaire [D]
| Description | active |
|---|---|
| Type AD du premier modèle à faire correspondre | 0x01 |
| Longueur du premier modèle à faire correspondre | 0x03 - 0x02 = 0x01 octet |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0x01 | 0x01 |
| Octets à la position 0x00 pour le type AD 0x01 | 0x02 (pas de correspondance) |
| Type AD du deuxième modèle à correspondre | 0xFF (données spécifiques au fabricant) |
| Longueur du deuxième modèle à faire correspondre | 0x06 - 0x02 = 0x04 octets |
| Modèle à faire correspondre à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF 0xFF |
| Octets à la position 0x00 pour le type AD 0xFF | 0x00 0x06 0xFF 0x01 (aucune correspondance) |
Verdict : FAIL (aucun modèle de correspond)
Exemple : Surveillance des annonces publicitaires
Cet exemple illustre la surveillance des publicités RSSI. Les valeurs RSSI pour les publicités reçues qui ont satisfait une condition spécifiée sont montrées ci-dessous.
| Durée (s) | RSSI (dB) |
|---|---|
| 1 | -100 |
| 2 | – 90 |
| 3 | -5 |
| 4 | 15- |
| 5 | -30 |
| 6 | 15- |
| 7 | -45 |
| 8 | -20 |
| 9 | -35 |
| 10 | -45 |
| 11 | -70 |
| 12 | -85 |
| 13 | -85 |
| 14 | -85 |
| 15 | – 90 |
| 16 | – 90 |
| 17 | -70 |
| Paramètre | Valeur |
|---|---|
| RSSI_threshold_high | -10dB |
| RSSI_threshold_low | -80dB |
| RSSI_threshold_low_time_interval | 3 secondes |
| RSSI_sampling_period | 2 secondes |
Le RSSI de la publicité est supérieur RSSI_threshold_high au temps 3. Le minuteur périodique pour l’échantillonnage commence au temps 3. Toutes les 2 secondes, le minuteur périodique expire et la valeur moyenne du RSSI de la publicité reçue est propagée à la pile.
Lorsque le minuteur périodique expire au temps 5, la moyenne des RSSI des publicités reçues pendant ce temps (-23dB) est propagée à la pile.
Lorsque le minuteur périodique expire au temps 13, la moyenne des RSSI des publicités reçues pendant ce laps de temps est inférieure à RSSI_threshold_low (-80dB). La moyenne du RSSI des publicités (-85 dB) doit être propagée à l’hôte.
Lorsque RSSI_threshold_low_time_interval expire à l’instant 15, une publicité est propagée à l’hôte avec un RSSI de -85dB. Aucune publicité supplémentaire n’est envoyée à l’hôte dans cet exemple.
Exemple : Surveillance des annonces BAP d’un appareil
Tout en étant lié à un Accepteur CAP, mais non connecté, un hôte pourrait surveiller les annonces BAP de cet appareil.
| Paramètre | Valeur |
|---|---|
| Subcommand_opcode_v2 | 0x0F |
| RSSI_threshold_high | -127 |
| RSSI_threshold_low | -127 |
| RSSI_threshold_low_time_interval | 0x05 |
| RSSI_sampling_period | 0x00 |
| Monitor_options | Bit 0 défini ; Bit 1 défini si l’appareil a distribué un IRK |
| Advertisement_report_filtering_options | Bit 0, 1 et 2 définis |
| Peer_device_address | <address> |
| Peer_device_address_type | <type d’adresse> |
| Peer_device_IRK | <IRK, si le bit 1 est défini> |
| Condition_type | 0x01 |
| Number_of_patterns | 0x01 |
| Pattern_data | 0x04 (longueur) 0x16 (données de service - UUID 16 bits) 0x00 (octet de départ) 0x4E (octet bas de l’UUID ASCS) 0x18 (octet haut de l’UUID ASCS) |
Exemple : Surveillance des annonces CAP d’un appareil
Tout en étant lié à un Commandant CAP, mais non connecté, un hôte pourrait surveiller les annonces CAP de cet appareil.
| Paramètre | Valeur |
|---|---|
| Subcommand_opcode_v2 | 0x0F |
| RSSI_threshold_high | -127 |
| RSSI_threshold_low | -127 |
| RSSI_threshold_low_time_interval | 0x05 |
| RSSI_sampling_period | 0x00 |
| Monitor_options | Bit 0 défini ; Bit 1 défini si l’appareil a distribué un IRK |
| Advertisement_report_filtering_options | Bit 0, 1 et 2 définis |
| Peer_device_address | <address> |
| Peer_device_address_type | <type d’adresse> |
| Peer_device_IRK | <IRK, si le bit 1 est défini> |
| Condition_type | 0x01 |
| Number_of_patterns | 0x01 |
| Pattern_data | 0x04 (longueur) 0x16 (données de service - UUID 16 bits) 0x00 (octet de départ) 0x53 (octet bas de l’UUID CAS) 0x18 (octet haut de l’UUID CAS) |
Organigramme : Filtrage des publicités et de la liste d’acceptation des filtres
Cet organigramme fournit un exemple de mise en œuvre du filtrage des publicités et de la liste d’acceptation des filtres lorsqu’une publicité est reçue.
Un contrôleur peut implémenter cette logique différemment, tant que l’hôte est informé de la publicité ou de HCI_VS_MSFT_LE_Monitor_Device_Event comme spécifié par l’organigramme.
Diagramme de séquence : Propager la réponse de balayage associée à la publicité
Diagramme de séquence : Propager la réponse de balayage associée à la publicité
Ce diagramme de séquence montre une réponse de balayage propagée associée à une publicité qui satisfait un filtre publicitaire lorsque le balayage actif est activé. Ce diagramme ne montre que la séquence d’événements attendue entre le contrôleur et l’hôte, et ne montre pas les événements entre le contrôleur et un appareil particulier. Supposons qu’il y ait une publicité A qui satisfait un filtre publicitaire, et une publicité B qui ne satisfait pas le filtre publicitaire.
