<ph type="x-smartling-placeholder"></ph>
Consulter le code source sur GitHub
Certaines fonctionnalités avancées sont facultatives, pris en charge sur la plate-forme matérielle cible.
Cadrage automatique en attente
La norme IEEE 802.15.4 définit deux types de méthodes de transmission de données entre le parent et enfant: transmission directe et transmission indirecte. Ce dernier est conçu principalement pour les appareils qui ont l’habitude de dormir la plupart du temps, se lever régulièrement pour interroger le parent afin d'obtenir des données en file d'attente.
Transmission directe : le parent envoie une trame de données directement à l'appareil final.
Transmission indirecte : le parent conserve les données jusqu'à ce qu'il en soit demandé à l'appareil final désigné
Dans le cas indirect, l'appareil côté enfant doit d'abord interroger le parent pour déterminer ou si des données sont disponibles. Pour ce faire, l'éditeur enfant envoie un ensemble de données , que le parent reconnaît. Le parent détermine ensuite s'il contient des données pour l'appareil de l'enfant ; le cas échéant, un paquet de données est envoyé appareil, qui accuse réception des données.
Si la case d'option prend en charge la définition dynamique du bit de frame en attente dans les appels sortants des accusés de réception aux SED, les pilotes doivent mettre en œuvre correspondance de l'adresse source pour activer cette fonctionnalité. OpenThread utilise cette API pour indiquer à la radio laquelle SED pour lesquels définir le bit de frame en attente.
Si la case d'option ne prend pas en charge la définition dynamique du bit de frame en attente, le
radio peut bouchonner l'API de correspondance d'adresse source pour renvoyer
OT_ERROR_NOT_IMPLEMENTED
Analyse/Détection d'énergie avec radio
La fonctionnalité de détection/recherche d'énergie nécessite la puce radio pour échantillonner l'énergie présenter sur les canaux sélectionnés et renvoyer la valeur énergétique détectée au couche supérieure.
Si cette fonctionnalité n'est pas implémentée, la couche MAC IEEE 802.15.4 envoie/reçoit un paquet de requête/réponse de balise pour évaluer l'état actuel de la valeur énergétique sur le canal.
Si la puce radio est compatible avec la détection et la recherche d'énergie, veillez à désactiver le logiciel.
de consommation d'énergie en définissant la macro
OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0
Accélération matérielle pour mbedTLS
mbedTLS définit plusieurs macros dans
le fichier d'en-tête de configuration principal,
mbedtls-config.h,
pour permettre aux utilisateurs d'activer d'autres implémentations d'AES, SHA1, SHA2 et
les autres modules, ainsi que les fonctions individuelles de la courbe elliptique.
la cryptographie (ECC) sur le module GF(p). Voir
accélération matérielle mbedTLS
pour en savoir plus.
OpenThread n'active pas ces macros, par conséquent la cryptographie symétrique les algorithmes, les algorithmes de hachage et les fonctions ECC utilisent tous un logiciel par défaut. Ces implémentations nécessitent une mémoire importante et des ressources de calcul. Pour des performances optimales et une meilleure expérience utilisateur nous vous recommandons d'activer l'accélération matérielle plutôt que logicielle mettre en œuvre les opérations ci-dessus.
Pour activer l'accélération matérielle dans OpenThread, le mbedTLS suivant
les fichiers d'en-tête de configuration doivent être ajoutés à la compilation ot-config
dans les fichiers CMake de la plate-forme:
- Configuration principale, qui définit toutes les macros nécessaires utilisées dans OpenThread:
/openthread/third-party/mbedtls/mbedtls-config.h - La configuration spécifique à l'utilisateur, qui définit d'autres implémentations
modules et fonctions:
src/platform-name-mbedtls-config.h
Exemple de nrf52811.cmake:
target_compile_definitions(ot-config INTERFACE
"MBEDTLS_USER_CONFIG_FILE=\"nrf52811-mbedtls-config.h\""
)
Les macros commentées dans mbedtls-config.h ne sont pas obligatoires et peuvent être activées dans
le fichier d'en-tête de configuration spécifique à l'utilisateur pour l'accélération matérielle.
Pour obtenir un exemple complet de configuration spécifique à l'utilisateur, consultez la
mbedtls_config_autogen.h
dans ot-efr32.
Module AES
OpenThread Security applique le cryptogramme AES CCM (Counter with CBC-MAC) aux chiffrer/déchiffrer les messages IEEE 802.15.4 ou MLE et les valider code d'intégration. L'accélération matérielle doit au moins être compatible avec l'ECB AES de base (Electronic Codebook Book) pour l'appel fonctionnel de base AES CCM.
Pour utiliser une autre implémentation de module AES:
- Définir la macro
MBEDTLS_AES_ALTdans le protocole mbedTLS spécifique à l'utilisateur fichier d'en-tête de configuration - Indiquez le chemin d'accès au fichier
aes_alt.hà l'aide deMBEDTLS_CPPFLAGS. variable
Module SHA256
OpenThread Security applique des algorithmes de hachage HMAC et SHA256 pour calculer le valeur de hachage pour la gestion des clés réseau et la génération de clés PSKc conformément au thread Spécification.
Pour utiliser une autre implémentation de base du module SHA256:
- Définir la macro
MBEDTLS_SHA256_ALTdans le protocole mbedTLS spécifique à l'utilisateur fichier d'en-tête de configuration - Indiquez le chemin d'accès au fichier
sha256_alt.hà l'aide deMBEDTLS_CPPFLAGS. variable
Fonctions ECC
Étant donné que mbedTLS n'est actuellement compatible qu'avec l'accélération matérielle pour certaines parties d'ECC
plutôt que l'intégralité du module, vous pouvez choisir d'implémenter
définies dans
path-to-mbedtls/library/ecp.c pour accélérer l'ECC
la multiplication de points.
La courbe secp256r1 est utilisée dans l'algorithme d'échange de clés du Brouillon ECJPAKE. Par conséquent, l'accélération matérielle doit au moins prendre en charge le secp256r1 court Weierstrass opération de courbe. Reportez-vous à la page Accélération matérielle SiLabs CRYPTO pour mbedTLS à titre d'exemple.