FN_99

MAGGIO 2019 FIELDBUS & NETWORKS 65 I primi modem NB-IoT disponibili, forniti dai principali operatori del mercato LTE, hanno seguito il primo approccio, sfruttando l’e- sperienza già maturata per fornire soluzioni LTE ‘ridimensionate’, per le quali però basso costo e consumo non erano un fattore chiave. Solo più di recente hanno iniziato a emergere soluzioni nativamente orientate a tali requi- siti, fondamentali per tutte le applicazioni tipiche discusse precedentemente. Come già sottolineato, il costo è un fattore chiave di qualunque implementazione NB-IoT. Il costo di un modem è determinato prevalentemente dall’area silicio occupata, con memorie e ac- celeratori hardware che la fanno da padrone nell’accaparrarsi spazio nel die. Di conse- guenza, si possono identificare due strategie principali per l’ottimizzazione del sistema: (1) una riduzione della dimensioni del codice e, di conseguenza, della memoria di sistema; (2) la minimizzazione dell’uso di acceleratori hardware a favore di soluzioni puramente software. Tali acceleratori, infatti, sono giustificati solo se il guadagno in termini di prestazioni giustifica l’aumento di area silicio e, quindi, in funzione per esempio dell’effet- tiva applicazione da realizzare. Per le aree di applicazione tipiche, infatti, non sono solita- mente richiesti trasferimenti di dati continui; generalmente, a una prima fase di raccolta dei dati dai vari sensori, segue una fase di elaborazione (per esempio per ‘data fusion’) e solo successivamente si trasmettono le infor- mazioni ricavate (per esempio verso il cloud). Altri scenari possono sfruttare un accesso a basso consumo al canale di comunicazione in attesa di ricevere un messaggio di downlink per attivare una risposta di qualche tipo. In entrambi i casi, la fase di trasmissione dati (attiva) è soltanto una piccola frazione del tempo complessivo di funzionamento del sistema, il che lascia quindi ampi intervalli di tempo a disposizione di un singolo pro- cessore non solo per l’applicazione utente, ma anche per l’implementazione dell’intero stack protocollare. Infatti, nel caso di NB-IoT, grazie alla modalità di funzionamento half- duplex e a un singolo processo di Hybrid Au- tomatic Repeat reQuest (Harq) per la variante Cat.NB1, la sequenza di azioni che un end device deve eseguire è ridotta e può essere serializzata, il che si traduce, per esempio, nella possibilità di gestire la comunicazione in una singola funzione di interrupt, o con un approccio timer-driven. I tipici passi richiesti possono essere così riassunti: 1) ricerca della rete cellulare; 2) registrazione alla rete cellulare; 3) ricezione dei dati di controllo; 4) ricezione dei dati di downlink; 5) trasmissione dei dati di uplink. Un’alternativa alle reti LPwan Un’ulteriore riduzione della complessità rispetto a LTE tradizionale si ottiene utiliz- zando una codifica di canale più semplice. Infatti, nessun ‘turbo code’ è utilizzato in NB-IoT per il downlink. Inoltre, un modem software defined si adatta più facilmente alle continue evoluzioni di quello che è uno standard in divenire, per esempio attraverso aggiornamenti del firmware via etere. Tutto ciò è oggi reso possibile dalla dispo- nibilità di processori e Instruction Set Archi- tecture (ISA) efficienti e versatili. Un modem NB-IoT si basa generalmente su un singolo processore, efficiente, con funzionalità DSP integrate, affiancato da (pochi) acceleratori hardware ben mirati. La bassa complessità computazionale si traduce in frequenze di clock più basse, il che aiuta a risparmiare energia. Inoltre, una bassa frequenza di clock è compatibile con tensioni di alimentazione più basse (ancora una volta a vantaggio dei consumi). Se l’ISA permette un’elevata densità di codice, le dimensioni della memoria sono ridotte e l’uso di off-chip Dram può quindi essere evitato, mantenendo bassi sia i costi sia i consumi del sistema. Il processore deve essere solamente affiancato da un front-end per l’implementazione del ricetrasmettitore a radio frequenza e di un blocco in grado di processare il segnale in banda base per propagarlo ai livelli superiori dello stack pro- tocollare. In definitiva, quindi, il processore utilizzato per implementare la trasmissione NB-IoT può essere utilizzato anche per eseguire l’appli- cazione utente, ovvero task come la raccolta e l’elaborazione dei dati dai sensori, senza bisogno di un processore host separato. Il processore deve in questo caso supportare meccanismi di accelerazione delle routine DSP, quali la funzione FFT complessa (per esempio, supporto dell’indirizzamento in- vertito richiesto dal computo della butterfly), piuttosto che la decodifica Viterbi, alla base dei meccanismi di ‘forward error correction’. Inoltre, va ricordato che lo standard emanato dal 3GPP definisce il comportamento del si- stema, ma lascia molti aspetti implementativi non specificati. Per esempio, solo il percorso di trasmissione è definito nella norma, men- tre la ricezione è ‘vendor specific’. Per questi motivi, iniziano a comparire diverse soluzioni offerte da costruttori che non si annoverano tra i tipici fornitori di soluzioni mobile, che potrebbero portare NB-IoT a diventare, una volta superate le limitazioni imposte dal modello di business degli operatori di rete, un’alternativa alle già citate LPwan, in attesa che il 5G diventi una realtà. Foto tratta da www.pixabay.com