Alcune funzionalità avanzate sono facoltative, a seconda che siano supportate o meno sulla piattaforma hardware di destinazione.
Frame automatico in attesa
IEEE 802.15.4 definisce due tipi di metodi di trasmissione dei dati tra principale e secondario: trasmissione diretta e trasmissione indiretta. Quest'ultimo è progettato principalmente per i dispositivi finali assonnati (SED) che dormono la maggior parte del tempo, periodicamente si svegliano per raccogliere dati sulla coda dei genitori.
Trasmissione diretta: il genitore invia un frame di dati direttamente al dispositivo finale
Trasmissione indiretta: il genitore detiene i dati finché non sono richiesti dal dispositivo finale previsto
Nel caso indiretto, un dispositivo finale secondario deve prima connettere il genitore per determinare se sono disponibili dati. A tal fine, il publisher secondario invia una richiesta di dati, che il genitore riconosce. Quindi, l'elemento principale determina se sono presenti dati per il dispositivo secondario; in questo caso, invia un pacchetto di dati al dispositivo figlio, che conferma la ricezione dei dati.
Se la radio supporta l'impostazione dinamica del bit Frame Pending nelle conferme in uscita verso SED, i driver devono implementare l'API match address source per abilitare questa funzionalità. OpenThread utilizza questa API per comunicare alla radio per quali SED impostare il bit del frame in attesa.
Se la radio non supporta l'impostazione dinamica del bit in attesa per i frame, la radio potrebbe terminare l'API di corrispondenza degli indirizzi di origine per restituire OT_ERROR_NOT_IMPLEMENTED.
Scansione/rilevamento dei consumi energetici con radio
La funzionalità Scansione/rilevamento energia richiede al chip radio di campionare l'energia presentata sui canali selezionati e di restituire il valore di energia rilevata al livello superiore.
Se questa funzionalità non è implementata, il livello MAC IEEE 802.15.4 invia/riceve un pacchetto di richiesta/risposta Beacon per valutare il valore energetico corrente del canale.
Se il chip radio supporta Energy Scan/Detect, assicurati di disabilitare la logica di scansione energetica del software impostando la macro OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0.
Accelerazione hardware per mbedTLS
mbedTLS definisce diverse macro nel file dell'intestazione di configurazione principale, mbedtls-config.h, per consentire agli utenti di abilitare implementazioni alternative di AES, SHA1, SHA2 e altri moduli, nonché singole funzioni per il modulo Elliptic Encryption (ECC) su GF(p). Per ulteriori informazioni, consulta l'articolo sull'accelerazione hardware mbedTLS.
OpenThread non abilita tali macro, pertanto gli algoritmi di crittografia simmetrici, gli algoritmi hash e le funzioni ECC utilizzano tutte le implementazioni software per impostazione predefinita. Queste implementazioni richiedono una memoria considerevole e risorse di calcolo. Per prestazioni ottimali e una migliore esperienza utente, ti consigliamo di abilitare l'accelerazione hardware anziché il software per implementare le operazioni illustrate sopra.
Per abilitare l'accelerazione hardware all'interno di OpenThread, è necessario aggiungere i seguenti file di intestazione della configurazione mbedTLS alle definizioni di compilazione ot-config nei file CMake della piattaforma:
- Configurazione principale, che definisce tutte le macro necessarie utilizzate in OpenThread:
/openthread/third-party/mbedtls/mbedtls-config.h - Configurazione specifica dell'utente, che definisce implementazioni alternative di
moduli e funzioni:
src/platform-name-mbedtls-config.h
Esempio da nrf52811.cmake:
target_compile_definitions(ot-config INTERFACE
"MBEDTLS_USER_CONFIG_FILE=\"nrf52811-mbedtls-config.h\""
)
Le macro commentate in mbedtls-config.h non sono obbligatorie e possono essere attivate nel file di intestazione della configurazione specifica dell'utente per l'accelerazione hardware.
Per una configurazione di esempio specifica per l'utente, consulta il file mbedtls_config_autogen.h in ot-efr32.
Modulo AES
OpenThread Security applica la crittografia AES CCM (contatore con CBC-MAC) per criptare/decriptare i messaggi IEEE 802.15.4 o MLE e convalida il codice di integrazione dei messaggi. L'accelerazione hardware dovrebbe almeno supportare la modalità AES ECB di base (Electronic Codebook Book) per le chiamate funzionali di base AES CCM.
Per utilizzare un'implementazione alternativa del modulo AES:
- Definisci la macro
MBEDTLS_AES_ALTnel file di intestazione della configurazione mbedTLS specifico dell'utente - Indica il percorso del file
aes_alt.hutilizzando la variabileMBEDTLS_CPPFLAGS
Modulo SHA256
OpenThread Security applica algoritmi hash HMAC e SHA256 per calcolare il valore hash per la gestione delle chiavi di rete e la generazione di PSKc in base alla specifica Thread.
Per utilizzare un'implementazione di base del modulo SHA256 alternativo:
- Definisci la macro
MBEDTLS_SHA256_ALTnel file di intestazione della configurazione mbedTLS specifico dell'utente - Indica il percorso del file
sha256_alt.hutilizzando la variabileMBEDTLS_CPPFLAGS
Funzioni ECC
Al momento, mbedTLS supporta solo l'accelerazione hardware per parti delle funzioni ECC anziché per l'intero modulo, quindi puoi scegliere di implementare alcune funzioni definite in path-to-mbedtls/library/ecp.c per accelerare la moltiplicazione dei punti ECC.
La curva secp256r1 viene utilizzata nell'algoritmo di scambio delle chiavi della bozza ECJPAKE. Pertanto, l'accelerazione hardware dovrebbe supportare almeno l'operazione breve di curva seier256r1. Per un esempio, vedi SiLabs CRYPTO Hardware Acceleration for mbedTLS.