Erweiterte Funktionen implementieren

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Quelle auf GitHub ansehen

Einige erweiterte Funktionen sind optional, je nachdem, ob sie auf der Zielhardwareplattform unterstützt werden oder nicht.

Automatischer Frame ausstehend

IEEE 802.15.4 definiert zwei Arten der Datenübertragung zwischen übergeordneter und untergeordneter Methode: direkte und indirekte Übertragung. Letztere ist in erster Linie für schläfrige Endgeräte (SEDs) vorgesehen, die die meiste Zeit schlafen. Außerdem wird in regelmäßigen Abständen der Ruhemodus des übergeordneten Geräts abgefragt, um Daten in der Warteschlange abzurufen.

  • Direkte Übertragung: Ein übergeordneter Datenframe wird direkt an das Endgerät gesendet. Direkte Übertragung

  • Indirekte Übertragung: Der übergeordnete Partner speichert die Daten, bis sie vom gewünschten Endgerät angefordert werden. Direkte Übertragung

Bei indirekten Fällen muss ein untergeordnetes Endgerät zuerst eine Abfrage an das übergeordnete Gerät senden, um festzustellen, ob Daten für dieses verfügbar sind. Dazu sendet das untergeordnete Element eine Datenanfrage, die vom übergeordneten Publisher bestätigt wird. Das übergeordnete Element bestimmt dann, ob es Daten für das untergeordnete Gerät enthält. Wenn dies der Fall ist, sendet es ein Datenpaket an das untergeordnete Gerät, das den Empfang der Daten bestätigt.

Wenn das Radio die Frame-Pending-Bit dynamisch in ausgehenden E-Mails an SEDs einstellen kann, muss der Treiber die Source Address Match-API implementieren, um diese Funktion zu aktivieren. OpenThread verwendet diese API, um dem Funkgerät mitzuteilen, für welche SEDs das Bit „Ausstehend“ für den Frame festgelegt werden soll.

Wenn das Radio die Einstellung „Frame Ausstehend“ nicht dynamisch unterstützt, kann das Radio die Adresse API der Quelladresse abgleichen, um OT_ERROR_NOT_IMPLEMENTED zurückzugeben.

Energiescan/Funkerkennung

Die Funktion „Energy Scan/Detect“ muss den Funkchip abfragen, der auf den ausgewählten Kanälen präsentieren kann, und den erkannten Energiewert an die oberste Ebene zurückgeben.

Falls diese Funktion nicht implementiert ist, sendet die IEEE 802.15.4-MAC-Ebene ein Beacon-Anfrage-/Antwortpaket, um den aktuellen Energiewert des Kanals zu bewerten.

Falls der Radiochip Energy Scan/Detect unterstützt, musst du die Logik für das Scannen von Softwareenergie deaktivieren, indem du das Makro OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0 angibst.

Hardwarebeschleunigung für mbedTLS

mbedTLS definiert mehrere Makros in der Hauptkonfigurationsheader (mbedtls-config.h), damit Nutzer alternative Implementierungen von AES-, SHA1-, SHA2- und anderen Modulen sowie einzelne Funktionen für das Elliptische-Kurven-Kryptografie (ECC) über das GF(p)-Modul aktivieren können. Weitere Informationen finden Sie unter mbedTLS-Hardwarebeschleunigung.

OpenThread aktiviert diese Makros nicht. Daher nutzen alle symmetrischen Kryptografiealgorithmen, Hash-Algorithmen und ECC-Funktionen standardmäßig Softwareimplementierungen. Diese Implementierungen benötigen erheblichen Arbeitsspeicher und Rechenressourcen. Für eine optimale Leistung und eine bessere Nutzererfahrung empfehlen wir, die Hardwarebeschleunigung anstelle der Software zu aktivieren, um die oben beschriebenen Vorgänge zu implementieren.

Um die Hardwarebeschleunigung in OpenThread zu aktivieren, sollten die folgenden mbedTLS-Konfigurationsheader in die ot-config-Compiler-Definitionen in den CMake-Dateien der Plattform aufgenommen werden:

  • Hauptkonfiguration. Darin sind alle erforderlichen Makros für OpenThread definiert: /openthread/third-party/mbedtls/mbedtls-config.h
  • Nutzerspezifische Konfiguration, die alternative Implementierungen von Modulen und Funktionen definiert: src/platform-name-mbedtls-config.h

Beispiel aus nrf52811.cmake:

target_compile_definitions(ot-config INTERFACE
    "MBEDTLS_USER_CONFIG_FILE=\"nrf52811-mbedtls-config.h\""
)

Kommentierte Makros in mbedtls-config.h sind nicht obligatorisch und können in der nutzerspezifischen Konfigurations-Header-Datei für Hardwarebeschleunigung aktiviert werden.

Eine vollständige nutzerspezifische Konfiguration findest du in der Datei mbedtls_config_autogen.h in ot-efr32.

AES-Modul

OpenThread Security wendet AES CCM (Zähler mit CBC-MAC) an, um die IEEE 802.15.4- oder MLE-Nachrichten zu verschlüsseln/entschlüsseln und den Nachrichtenintegrationscode zu validieren. Die Hardwarebeschleunigung sollte mindestens den einfachen AES-ECB-Modus (Electronic Codebook Book) für den einfachen AES-CCM-Aufruf unterstützen.

So verwenden Sie eine alternative AES-Modulimplementierung:

  1. Definieren Sie das MBEDTLS_AES_ALT-Makro in der nutzerspezifischen mbedTLS-Konfigurationsheaderdatei
  2. Pfad der Datei aes_alt.h mit der Variable MBEDTLS_CPPFLAGS angeben

SHA-256-Modul

OpenThread Security wendet HMAC- und SHA256-Hashalgorithmen an, um den Hashwert für die Verwaltung von Netzwerkschlüsseln und die PSKc-Generierung gemäß der Threadspezifikation zu berechnen.

So verwenden Sie eine alternative SHA256-Modulimplementierung:

  1. Definieren Sie das MBEDTLS_SHA256_ALT-Makro in der nutzerspezifischen mbedTLS-Konfigurationsheaderdatei
  2. Pfad der Datei sha256_alt.h mit der Variable MBEDTLS_CPPFLAGS angeben

ECC-Funktionen

Da mbedTLS derzeit nur die Hardwarebeschleunigung für Teile der ECC-Funktionen und nicht das gesamte Modul unterstützt, können Sie einige in path-to-mbedtls/library/ecp.c definierte Funktionen implementieren, um die Multiplikation von ECC-Punkten zu beschleunigen.

Die Kurve secp256r1 wird im Schlüsselaustauschalgorithmus des ECJPAKE-Entwurfs verwendet. Daher sollte die Hardwarebeschleunigung zumindest den kurzen Kurvenvorgang „secp256r1“ unterstützen. Ein Beispiel finden Sie unter SiLabs CRYPTO Hardware Acceleration für mbedTLS.