Exigences HCI

L'interface du contrôleur hôte (HCI) est utilisée pour interagir avec un contrôleur Bluetooth.

Ce document fournit une liste des exigences HCI Bluetooth (BT) et Bluetooth Low Energy (BLE). L'objectif est que les fournisseurs de piles hôtes BT et les fournisseurs de contrôleurs BT se conforment à ces exigences de plate-forme afin d'utiliser l'ensemble des fonctionnalités décrites ci-dessous.

Ce document fait référence à la spécification Bluetooth Core 5.2 sous le nom de « spécification ». La spécification Bluetooth Core 5.2 est disponible sur le site Web Bluetooth SIG avec d'autres documents adoptés.

Présentation générale de la conception

Capacités et configuration de la puce

En tant que plate-forme ouverte, Android dispose d'une matrice de versions logicielles, d'OEM, de fournisseurs, ainsi que de capacités de plate-forme et de puces.

Pour gérer les différents paysages et gérer les migrations, une philosophie de conception permettant aux contrôleurs BT d'exposer leurs capacités (au-delà de la spécification Bluetooth Core 5.2 standard) est décrite dans ce document. La pile BT hôte peut ensuite utiliser ces capacités pour déterminer les fonctionnalités à activer.

Prise en charge des normes ouvertes

L'un des objectifs d'Android est de prendre en charge les normes ouvertes après ratification d'une spécification Bluetooth. Si une fonctionnalité décrite ci-dessous devient disponible dans les méthodes HCI standard dans une future spécification Bluetooth, nous tendrons à faire de cette approche la valeur par défaut.

Capacités spécifiques au fournisseur

Commande spécifique au fournisseur : LE_Get_Vendor_Capabilities_Command

Champ de commande OpCode (OCF) : 0x153

Un événement Command Complete sera généré pour cette commande.

Regroupement des résultats d'analyse

L'un des objectifs de conception est d'améliorer la façon dont les notifications d'événements Bluetooth LE Scan Response sont transmises à l'hôte, afin d'économiser de l'énergie dans l'hôte.

En réduisant la fréquence à laquelle le contrôleur demande au processeur d'application hôte d'analyser les résultats, le processeur d'application hôte peut rester inactif/veille plus longtemps. Cela réduit la consommation d'énergie de l'hôte. Le paramètre de retour total_scan_results_storage de LE_Get_Vendor_Capabilities_Command indique la capacité de la puce pour le stockage des résultats d'analyse.

Cette fonctionnalité se concentre sur la gestion et la configuration de l'installation de stockage des résultats du scan LE dans le contrôleur Bluetooth. Le stockage est utilisé pour regrouper temporairement les données publicitaires et analyser les données et métadonnées reçues par le contrôleur pour une livraison ultérieure à l'hôte.

Le micrologiciel doit prendre en charge deux types de traitement par lots, qui peuvent être engagés simultanément :

• Tronqué. Contient les éléments d'information suivants : {MAC, TX Power, RSSI, Timestamp}
• Complet. Contient les éléments d'information suivants : {MAC, TX Power, RSSI, Timestamp, Adv Data, Scan Response}

LE_Batch_Scan_Command

OCF : 0x156

Un événement Command Complete sera généré pour cette commande. L'activation de la fonctionnalité spécifique au client ne démarre pas l'analyse.

LE_Batch_Scan_Command : activer la fonctionnalité spécifique au client

Sous-OCF : 0x01

Un événement Command Complete sera généré pour cette commande.

LE_Batch_Scan_Command : sous-commande Définir le paramètre de stockage d'analyse par lots

Sous-OCF : 0x02

Un événement Command Complete sera généré pour cette commande.

LE_Batch_Scan_Command : sous-commande Définir le paramètre d'analyse par lots

Sous-OCF : 0x03

Cette sous-commande lancera l'analyse par lots, si elle est activée. Dans l'analyse tronquée, les résultats sont stockés sous une forme tronquée où la clé unique pour le style tronqué = { BD_ADDR, scan_interval}. Cela signifie qu'un seul BD_ADDR will enregistré pour chaque intervalle d'analyse. L'enregistrement à conserver pour le mode tronqué est le suivant : { BD_ADDR , Tx Power, RSSI, Timestamp}

Lorsque le mode complet est activé, l'analyse active sera utilisée et les réponses à l'analyse seront enregistrées. La clé unique de style complet = {MAC, Ad packet}, quel que soit l'intervalle d'analyse. L'enregistrement à conserver pour le mode complet est { BD_ADDR , Tx Power, RSSI, Timestamp, Ad packet, Scan Response}. Dans le style Full, le même paquet AD, lorsqu'il est vu plusieurs fois sur différents intervalles d'analyse, n'est enregistré qu'une seule fois. Cependant, en mode tronqué, c'est la visibilité de BA_ADDR sur différents intervalles d'analyse qui est intéressante (une fois par intervalle d'analyse). Le RSSI est la valeur moyenne de tous les doublons d'une publicité unique au cours d'un intervalle d'analyse.

Un événement Command Complete sera généré pour cette commande.

LE_Batch_Scan_Command : sous-commande Lire les résultats de l'analyse par lots

Sous-OCF : 0x04

Un événement Command Complete sera généré pour cette commande. Lorsque l'hôte émet cette commande, tous les résultats du contrôleur peuvent ne pas tenir dans un seul événement Command Complete. L'hôte répétera l'émission de cette commande jusqu'à ce que les résultats correspondants dans l'événement Command Complete indiquent 0 dans le nombre d'enregistrements, ce qui indique que le contrôleur n'a plus d'enregistrements à communiquer à l'hôte. Chaque événement Command Complete peut contenir plusieurs enregistrements d’un seul type de données (complètes ou tronquées).

Les références temporelles du contrôleur et de l’hôte ne sont pas synchronisées. L'unité de l'horodatage est de 50 ms. La valeur de l'horodatage est basée sur le moment où Read_Batch_Scan_Results_Sub_cmd est donné par l'hôte. Si l'heure d'arrivée d'une commande est T_c dans le micrologiciel, alors l'heure réelle à laquelle l'horodatage a été pris dans le micrologiciel est T_fw . L'heure du rapport sera : ( T_c - T_fw ). T_c et T_fw sont dans le domaine temporel du micrologiciel. Cela permet à l'hôte de calculer depuis combien de temps l'événement s'est produit.

Filtre de contenu de paquet publicitaire

Utilisez-le pour activer/désactiver/configurer le filtre de contenu de paquets publicitaires (APCF) dans le contrôleur. APCF filtre les rapports publicitaires dans le contrôleur mais ne filtre pas les publicités périodiques.

LE_APCF_Command

OCF : 0x157

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : Enable_sub_cmd

Sous-OCF : 0x00

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : set_filtering_parameters_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer une spécification de filtre ou effacer une liste de filtres pour le filtrage sur puce.

Sous-OCF : 0x01

Les valeurs RSSI doivent utiliser le complément à 2 pour représenter les valeurs négatives.

L'hôte doit pouvoir configurer plusieurs filtres avec APCF_Application_Address_type défini sur 0x02 (pour toutes les adresses de diffuseur) pour gérer diverses combinaisons de filtres.

Le filtrage, le traitement par lots et le reporting sont des concepts interdépendants. Chaque publicité et réponse d’analyse associée devra passer par tous les filtres, l’un après l’autre. Ainsi, les actions résultantes ( delivery_mode ) sont étroitement liées au filtrage. Les modes de livraison sont les suivants : report_immediately , batch et onFound . La valeur OnLost est liée à OnFound dans le sens où elle viendra après OnFound en cas de perte.

Ce flux de traitement décrit le modèle conceptuel :

Lorsqu'une trame de publicité (ou de réponse d'analyse) est reçue, elle est appliquée à tous les filtres dans un ordre sériel. Il est possible qu'une publicité provoque un rapport immédiat basé sur un filtre et un regroupement de ceux-ci en raison d'une action de filtre différente.

Les seuils de niveau RSSI (haut et bas) permettent de contrôler le moment où la trame est visible pour le traitement du filtre, même lorsqu'un paquet valide est reçu par le contrôleur. Dans le cas où le mode de livraison est défini sur immédiat ou par lots, le RSSI d'une trame est pris en compte pour le traitement ultérieur du contrôleur. Différentes applications nécessitent un comportement différent en matière de reporting et de traitement par lots. Cela permet à plusieurs applications d'avoir simultanément des rapports directs et/ou un regroupement des résultats dans le micrologiciel. Un exemple est le cas où une analyse par lots est active à partir d'une application et plus tard, une analyse LE régulière est émise par une autre application. Avant qu'une analyse par lots ne soit émise, le framework/l'application définit les filtres appropriés. Plus tard, lorsque la deuxième application émet une analyse régulière, le traitement par lots précédent continue. Cependant, en raison de l'analyse régulière, cela revient à ajouter conceptuellement un filtre nul (avec tous les filtres existants) avec la commande LE scan. Les paramètres de la commande LE scan sont prioritaires lorsqu’ils sont actifs. Lorsque l'analyse LE régulière est désactivée, le contrôleur revient à une analyse par lots précédente, si elle existait.

Le mode de livraison OnFound est basé sur des filtres configurés. Une combinaison qui déclenche la réussite de l'action d'un filtre est considérée comme l'entité à suivre pour onLost . L'événement correspondant est le sous-événement de suivi LE Advt.

La transition OnFound/OnLost pour un filtre (si activé) ressemblera à ce qui suit :

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : diffusion_adresse_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer une adresse d'annonceur ou pour effacer la liste d'adresses d'annonceur pour le filtrage sur puce.

Sous-OCF : 0x02

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : service_uuid_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer un UUID de service ou pour effacer une liste d'UUID de service pour le filtrage sur puce.

Sous-OCF : 0x03

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : sollicitation_uuid_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer un UUID de sollicitation ou pour effacer une liste d'UUID de sollicitation pour le filtrage sur puce.

Sous-OCF : 0x04

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : nom_local_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer une chaîne de nom local ou pour effacer la liste de chaînes de nom local pour le filtrage sur puce.

Sous-OCF : 0x05

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : manf_data_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer une chaîne de données de fabricant ou pour effacer la liste de chaînes de données de fabricant pour le filtrage sur puce.

Sous-OCF : 0x06

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : service_data_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer une chaîne de données de service ou pour effacer la liste des chaînes de données de service pour le filtrage sur puce.

Sous-OCF : 0x07

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : ad_type_sub_cmd

Cette sous-commande est utilisée pour ajouter ou supprimer un type AD ou pour effacer une liste de types AD pour le filtrage sur puce. Utilisez read_extended_features_sub_cmd pour vérifier si cette commande est prise en charge ou non.

Sous-OCF : 0x09

Un événement Command Complete sera généré pour cette commande.

LE_APCF_Command : read_extended_features_sub_cmd

Cette sous-commande est utilisée pour lire les fonctionnalités APCF étendues.

Sous-OCF : 0xFF

Un événement Command Complete sera généré pour cette commande.

Activité du contrôleur et commande d'informations sur l'énergie

L'objectif de ces informations est que les fonctions supérieures du système hôte analysent les activités totales de tous les composants, y compris le contrôleur BT et son état macro, en conjonction avec ce qui se passe dans les applications et le framework. Pour ce faire, les informations suivantes sont requises de la pile BT et du contrôleur :

• Pile BT : rapporter l'état macro-opérationnel actuel du contrôleur
• Micrologiciel : rapporter des informations globales sur l'activité et l'énergie

États des macros de la pile hôte BT, tels que déterminés au niveau de l'utilisateur :

• Inactif : [analyse de page, annonce LE, analyse de demande]
• Scan : [pagination/demande/tentative de connexion]
• Actif : [Lien ACL activé, lien SCO en cours, mode reniflage]

Les activités que le contrôleur suit tout au long de sa durée de vie sont le temps Tx, le temps Rx, le temps d'inactivité et l'énergie totale consommée. Ils sont effacés lors de la lecture depuis l'hôte.

LE_Get_Controller_Activity_Energy_Info

Il s'agit d'une commande spécifique au fournisseur.

OCF : 0x159

Un événement Command Complete sera généré pour cette commande.

Commande de paramètres d'analyse de définition étendue LE

Cette commande peut être utilisée pour activer une fenêtre et un intervalle d'analyse plus grands dans le contrôleur. Conformément à la spécification BT Core 5.2, une fenêtre et un intervalle d'analyse ont une limite supérieure de 10,24 secondes, ce qui entrave les intervalles d'analyse plus longs des applications au-delà de 10,24 secondes.

Référence de base : Spécification BT Core 5.2, page 2493 (commande LE Set Scan Parameters)

OCF : 0x15A

Un événement Command Complete sera généré pour cette commande.

Obtenir la commande d'informations de débogage du contrôleur

L'objectif de cet élément d'information est d'acquérir des informations de débogage du contrôleur par un hôte, sous forme binaire, pour un post-traitement et une analyse. Cela aide à déboguer les problèmes sur le terrain et fournit aux ingénieurs une boîte à outils pour enregistrer les informations à des fins d'analyse. Un contrôleur peut fournir les informations à la demande d'un hôte via l'événement (sous-événement Controller Debug Info) ou de manière autonome lorsque le contrôleur le souhaite. Des exemples d'utilisation pourraient consister à rapporter des informations sur l'état du micrologiciel, des informations de vidage sur incident, des informations de journalisation, etc.

OCF : 0x15B

Un événement Command Complete sera généré pour cette commande.

Prise en charge du déchargement matériel A2DP

La fonction de déchargement A2DP prend en charge le déchargement du processus de codage audio A2DP vers un processeur audio connecté au contrôleur BT. Le flux de données audio codé passe directement du processeur audio au contrôleur BT sans la participation de l'hôte BT. L'hôte BT est toujours responsable de la configuration et du contrôle de la session A2DP. Deux versions des commandes sont disponibles. Les commandes héritées avec Sub OCF 0x01-0x02 ne prennent en charge que les codecs open source. Les versions avec Sub-OCF 0x02-0x03 sont indépendantes du codec configuré.

OCF : 0x15D

Démarrer le déchargement A2DP (hérité)

Sous-OCF : 0x01

Utilisez cette commande à la fois pour configurer le processus de déchargement A2DP et pour démarrer le flux A2DP.

Un événement Command Complete sera généré pour cette commande.

Démarrer le déchargement A2DP

Sous-OCF : 0x03

Utilisez cette commande à la fois pour configurer le processus de déchargement A2DP et pour démarrer le flux A2DP.

Un événement Command Complete sera généré pour cette commande.

Arrêter le déchargement A2DP (ancien)

Sous-OCF : 0x02

Cette commande est utilisée pour arrêter le flux de déchargement A2DP.

Aucun paramètre n'est défini pour cette commande.

Un événement Command Complete sera généré pour cette commande.

Arrêter le déchargement A2DP

Sous-OCF : 0x04

Cette commande est utilisée pour arrêter le flux de déchargement A2DP.

Un événement Command Complete sera généré pour cette commande.

Commande de rapport de qualité Bluetooth

La fonction de commande BT Quality Report démarre le mécanisme du contrôleur Bluetooth pour signaler les événements de qualité Bluetooth à l'hôte. Vous pouvez activer quatre options:

• Mode de surveillance de la qualité: le contrôleur envoie périodiquement un sous-événement BQR lié à la qualité de la qualité à l'hôte.
• Approchant LSTO: Si aucun paquet n'est reçu du périphérique BT connecté pour plus de la moitié de la valeur de tempsut de supervision de liaison (LSTO), le contrôleur rapporte un événement LSTO approchant à l'hôte.
• Audio A2DP Shoppy: Lorsque le contrôleur détecte les facteurs qui provoquent un son saccadé, le contrôleur rapporte un événement audio A2DP SOSSPY à l'hôte.
• (e) voix SCO saccageuse: lorsque le contrôleur détecte les facteurs qui provoquent une voix agitée, le contrôleur rapporte un événement (e) voix sco de la voix saccade à l'hôte.
• Inflammation racine: Cet événement est envoyé par le contrôleur à la pile lorsque le HAL ou le contrôleur rencontre une erreur fatale et doit redémarrer Bluetooth.
• Trace du message LMP / LL: le contrôleur envoie le message de message LMP / LL avec le périphérique distant à l'hôte.
• Bluetooth Multi-Profile / Coex Planage Trace: Le contrôleur envoie ses informations de planification lors de la gestion de plusieurs profils Bluetooth et de la coexistence sans fil dans la bande 2,4 GHz à l'hôte.
• Mécanisme d'information de débogage du contrôleur: Lorsqu'il est activé, le contrôleur peut signaler de manière autonome les informations de journalisation de débogage via le sous-événement des informations de débogage du contrôleur à l'hôte.

OCF: 0x15E

Un événement complet de commande sera généré pour cette commande.

Commande de tampon audio dynamique

Le tampon audio dynamique réduit le glitch audio en modifiant la taille du tampon audio dans le contrôleur Bluetooth en fonction de divers scénarios.

OCF: 0x15f

Obtenez la capacité de temps du tampon audio

Sub OCF: 0x01

Utilisez cette commande pour obtenir la capacité de temps du tampon audio du contrôleur Bluetooth.

Un événement complet de commande sera généré pour cette commande.

Définir l'heure du tampon audio

Sub OCF: 0x02

Utilisez cette commande pour définir l'heure du tampon audio sur le contrôleur Bluetooth.

Un événement complet de commande sera généré pour cette commande.

Événement HCI (spécifique au fournisseur)

Des événements HCI spécifiques au fournisseur sont nécessaires dans certains cas. Reportez-vous à la figure 5.4 à la page 1897 de la spécification BT Core 5.2. Le paramètre de l'événement 0 contiendra toujours le premier code de sous-événement, sur la base duquel le reste de l'événement HCI est décodé.

Sous-événement du seuil de stockage

Cet événement indique que le seuil de stockage a été violé.

Code de sous-événement = 0x54

Sous-événement de changement d'état multi-advertissant le

Cet événement indique qu'une instance publicitaire a changé son état. À l'heure actuelle, cet événement n'est utilisé que pour indiquer quelle instance publicitaire a été arrêtée à la suite d'une connexion.

Code de sous-événement = 0x55

Sous-événement du suivi de la publicité Le

Cet événement indique quand un annonceur est trouvé ou perdu.

Code de sous-événement = 0x56

Sous-événement de débogage du contrôleur

Cet événement est utilisé par un contrôleur pour fournir des informations de débogage binaire à un hôte.

Code de sous-événement = 0x57

Sous-événement du rapport de qualité Bluetooth

Cet événement indique l'un des éléments suivants: Un événement de qualité Bluetooth s'est produit, le contrôleur a téléchargé la trace de message LMP / LL et la trace de planification multi-link / coex Bluetooth, ou les données d'informations de débogage vidées du contrôleur.

Code de sous-événement = 0x58 [Quality_Report_id = 0x01 ~ 0x04, Event de la qualité liée à la qualité]

Code de sous-événement = 0x58 [Quality_Report_id = 0x05, événement d'inflammation racine]

Cet événement indique que Bluetooth HAL ou le contrôleur a rencontré une erreur fatale et a besoin d'une pile Bluetooth pour enregistrer cette situation et redémarrer. Le contrôleur doit envoyer un root_inflammation_event à la pile Bluetooth avant d'envoyer le premier fragment des événements de débogage d'informations dans tous les cas.

Le paramètre error_code contient un code d'erreur rapporté à partir de HAL / Controller, 0 s'il s'agit d'une erreur spécifique au fournisseur de chipset. Le vendor_specific_error_code contient un code d'erreur spécifique du fournisseur de chipset de HAL / Controller. Il doit définir 0 si le paramètre error_code n'est pas 0. Les paramètres error_code et vendor_specific_error_code ne doivent pas être 0.

Code de sous-événement = 0x58 [Quality_Report_id = 0x11 ~ 0x13, événement lié à un vidage de journal]

Support multi-advertiser

Les objectifs du support multi-advertiser sont les suivants:

• Capacité à prendre en charge plusieurs publicités ( max_advt_instances )
• Différentes pouvoirs de transmission pour permettre une plage variable
• Contenu publicitaire différent
• Une réponse individualisée pour chaque annonceur
• Confidentialité (non tracassable) pour chaque annonceur
• Connecté

Pour garder cette spécification proche des normes existantes, les commandes spécifiques au fournisseur suivantes sont fournies. Ils sont dérivés de la spécification Bluetooth Core 4.1.

Le_multi_advt_command

OCF: 0x154

Un événement complet de commande sera généré pour cette commande.

Le_multi_advt_command: set_advt_param_multi_sub_cmd

Référence de base: Bluetooth Core 4.1 Spécifications, page 964 (Commande de paramètre publicitaire LE SET)

Sub OCF: 0x01

Le paramètre Own_Address pourrait être une adresse configurée par l'hôte au moment de la configuration de cette instance multi-adversation. Cela offre la possibilité d'avoir une adresse privée résolunable au moment de la transmission de la première balise. La publicité sur une instance se poursuivra quelle que soit la connexion. La pile BT hôte peut émettre une commande pour démarrer la publicité sur une instance, publication de connexion.

Un événement complet de commande sera généré pour cette commande comme spécifié dans la spécification Bluetooth Core 4.1, selon la commande ci-dessus. Le contrôleur répondra avec un code non inscriptif (paramètre non valide) si l'instance publicitaire ou les paramètres Tx_Power ne sont pas valides.

Le_multi_advt_command: set_advt_data_multi_sub_cmd

Référence de base: Bluetooth Core 4.1 Spécification, page 969 (Commande de données publicitaires LE SET)

Sub OCF: 0x02

Un événement complet de commande sera généré pour cette commande comme spécifié dans la spécification Bluetooth Core 4.1, selon la commande ci-dessus. Le contrôleur répondra par un code non inscriptif si l'instance publicitaire ou les paramètres Tx_Power ne sont pas valides.

Le_multi_advt_command: set_scan_resp_data_multi_sub_cmd

Référence de base: Bluetooth Core 4.1 Spécification, page 970 (Commande de données de réponse à Set Scan)

Sub OCF: 0x03

Un événement complet de commande sera généré pour cette commande comme spécifié dans la spécification Bluetooth Core 4.1, selon la commande ci-dessus. Le contrôleur répondra avec un code non inscriptif (paramètre non valide) si l'instance publicitaire ou les paramètres Tx_Power ne sont pas valides.

Le_multi_advt_command: set_random_addr_multi_sub_cmd

Référence de base: Bluetooth Core 4.1 Spécification, page 963 (Commande d'adresse aléatoire du set)

Sub OCF: 0x04

Un événement complet de commande sera généré pour cette commande.

Le_multi_advt_command: set_advt_enable_multi_sub_cmd

Référence de base: Bluetooth Core 4.1 Spécification, page 971 (Commande SET ANTERRICY Activer dans cette spécification de base)

OCF: 0x05

Un événement complet de commande sera généré pour cette commande.

Résolution déchargée de l'adresse privée

Cette fonctionnalité résout une adresse privée dans le firmware ou le matériel du contrôleur, qui offre les avantages suivants:

• Latence impliquée avec l'hôte pour résoudre une adresse privée
• Économiser de l'énergie en s'abstenant de réveiller l'hôte

Le_set_rpa_timeout

OCF: 0x15c

Le_rpa_offload_command

OCF: 0x155

Un événement complet de commande sera généré pour cette commande.

Le_rpa_offload: enable_cust_specific_sub_command

Sub OCF: 0x01

Le déchargement RPA doit être activé par l'hôte, en fonction de la capacité de puce. Reportez-vous à LE_Get_Vendor_Capabilities_Command . Chaque puce peut avoir un max_irk_list_sz variable dans le firmware.

Un événement complet de commande sera généré pour cette commande.

Le_rpa_offload: add_irk_to_list_sub_command

Sub OCF: 0x02

Un événement complet de commande sera généré pour cette commande.

Le_RPA_OFFLOAD: REPOUP_IRK_TO_LIST_SUB_COMMAND

Sub OCF: 0x03

Un événement complet de commande sera généré pour cette commande.

Le_rpa_offload: clear_irk_list_sub_command

Sub OCF: 0x04

Un événement complet de commande sera généré pour cette commande.

Le_rpa_offload: read_irk_list_sub_command

Sub OCF: 0x05

Un événement complet de commande sera généré pour cette commande.