EO_491

31 - ELETTRONICA OGGI 491 - GENNAIO/FEBBRAIO 2021 TECH INSIGHT IOT GEOLOCATION WiFi una correzione precisa della posizione, l’host dovrà acquisire gli indirizzi MAC di diversi punti di accesso nelle vicinanze. Pertanto, il controller host può attivare la modalità di scansione passiva un cer- to numero di volte in successione finché non sia suf- ficiente. Per evitare sprechi di energia in aree con accesso WiFi scadente, il motore RF può implementare una modalità di timeout, disabilitando automaticamente il ricevitore se non è stato trasmesso alcun pacchetto valido fino a quando il controller host non decide di riprovare. L’host potrebbe decidere di attendere, oppure di pas- sare alla modalità GNSS, questo nel caso in cui si trovi a grande distanza da qualsiasi router WiFi oltre che in una posizione esterna. Una volta che avrà ottenuto un elenco di indirizzi MAC e indicazioni sulla potenza del segnale, l’host può, come con i dati GNSS, passare i dati al Cloud per la conversione in una geolocaliz- zazione. L’utilizzo del Cloud per alleggerire il lavoro di ottenimento della geolocalizzazione porta a ulte- riori risparmi energetici superiori alle ottimizzazioni utilizzate per estrarre solo la quantità di informazioni necessarie dai segnali RF ricevuti. Il risultato finale è un tag geolocalizzabile che con- suma un ordine di grandezza in meno rispetto ai mo- delli convenzionali, spingendo la durata della batteria che passerà da una questione di pochi mesi ad oltre due o tre anni. Ciò a sua volta riduce notevolmente il sovraccarico operativo di un fornitore di servizi in quanto vi è una necessità molto inferiore di sostituire le batterie in tag che possono essere disseminati in molteplici località sul campo. Ottimizzare i costi La natura del motore RF, definita da software, consen- te ulteriori ottimizzazioni dei costi. L’accesso al servi- zio Cloud per trasmettere le richieste di posizione e altri dati IoT non richiede l’utilizzo di un altro dispo- sitivo RF. Quando il ricevitore ha terminato l’acquisi- zione dei dati GNSS, il controller host può commuta- re il motore RF in modalità radio per accedere alle funzionalità di accesso LoRaWAN che fornisce. Una volta che i dati pacchettizzati siano stati inviati, il mo- tore RF può essere commutato in modalità di ricezio- ne, pronto per la risposta o passare ad una modalità standby a basso consumo per attendere fino all’ora programmata, per ricevere altre istruzioni o una ri- sposta da un server remoto. Il modo in cui è configurato LoRa Edge significa che le scelte su dove vengono inviati i pacchetti di dati sono interamente quelle dell’integratore o dell’opera- tore del servizio. LoRa Edge sfrutta appieno le funzio- nalità di sicurezza del protocollo LoRaWAN, e la sicu- rezza integrata è un componente chiave di LoRaWAN. A differenza della maggior parte degli altri protocolli mirati all’IoT, LoRaWAN implementa la crittografia end-to-end per i dati delle applicazioni. Questo è più efficace di una crittografia a livello di rete che viene utilizzato per impedire ai nodi non autorizzati di otte- nere l’accesso. Il processo di commissioning prevede una richiesta ad un Join Server che esegue le routine di autentica- zione e controlla le credenziali del dispositivo utiliz- zando protocolli basati su AES standard. In seguito a tale processo di autenticazione, il Join Server e il dispositivo cooperano per creare chiavi di sessione che possono essere utilizzate per proteggere i mes- saggi di rete. I dispositivi possono quindi utilizzare procedure simili per autenticarsi sui server delle ap- plicazioni dell’utente. In questo modo, non è necessa- rio che le applicazioni e l’operatore di rete condivida- no le chiavi. Servizi di rete e applicativi La distinzione tra servizi di rete e applicativi è im- portante per i servizi di geolocalizzazione del Cloud quanto lo è per altri casi d’uso delle applicazioni. Lo schema di progettazione di LoRa Cloud e LoRa Edge lo consente, garantendo che ad effettuare tutte le richieste di correzioni della posizione sia il server delle applicazioni del cliente invece che il dispositi- vo stesso ad effettuare la richiesta a livello di rete. In questo modo, gli integratori possono determinare au- tonomamente la migliore architettura dell’applicazio- ne. Se una geolocalizzazione deve essere riportata ad un tag, ciò può essere gestito a livello di applicazione dal sistema dell’utente. Tuttavia, in molti casi, i dati non devono essere archi- viati nel dispositivo stesso: possono essere conser- vati nel cloud e distribuiti solo quando necessario. Allo stesso tempo, il design di LoRa Edge fornisce agli utenti un comodo meccanismo per memorizzare le chiavi di crittografia necessarie per l’accesso alla rete e alle applicazioni. Un’area di memoria sicura è programmata con i dati chiave utilizzati per unirsi a una rete LoRaWAN all’av- vio e supporta la capacità di memorizzare chiavi per- sonalizzate per l’utilizzo da parte delle applicazioni utente. Come memoria sicura, le chiavi non possono essere lette dal dispositivo. La logica on-chip esegue tutte le operazioni sicure e crittografiche necessarie per accedere alle funzionalità LoRaWAN. In conclusione, grazie a un’attenta scelta dell’archi- tettura e dell’implementazione che si estende dall’in- terfaccia RF fino al Cloud, LoRa Edge dimostra come sia possibile utilizzare un approccio a livello di siste- ma per mantenere la promessa efficienza energetica dei dispositivi IoT e supportare un facile design-in.