Reti e architetture per lo smart parking

I principali protocolli di comunicazione utilizzati dai nostri sensori e le applicazioni possibili in ambiente smart parking

LoRa

NB-IoT

Conclusioni

Il protocollo LoRa (Long Range) è una tecnica di modulazione “a spettro espanso” di cui Semtech (USA) è proprietaria dal 2012.



Caratteristiche

Il protocollo LoRa si avvale di frequenze a libero utilizzo denominate ISM (Industrial, Scientifical, Medical) e riservate principalmente per utilizzo industriale, scientifico e medico, ma che sono impiegate anche da tutti i dispositivi radio acquistabili in commercio e utilizzabili liberamente, come telecomandi per cancelli, dispositivi Wi-Fi, allarmi funzionanti via radio, ecc.

Gli operatori che utilizzano questi dispositivi non sono soggetti ad autorizzazioni o al versamento di canoni. In ogni Paese è possibile trovare qualche operatore pubblico e decine o centinaia di aziende private che “vendono” la connessione.



Velocità

La velocità di trasmissione dei dati è detta Spreading Factor (SF). Il range di SF utilizzati va da SF12, il più lento, che consente una comunicazione a circa 250 bps (bit per secondo), fino al SF7, il più veloce, con circa 11.000 bps.

Quindi se un sensore smart parking deve inviare il suo pacchetto dati relativo allo stato di libero/occupato di un posto auto e questo è composto ad esempio da 60 byte (1 byte = 8 bit), significa che la lunghezza totale del pacchetto da inviare (detta Payload) è di 480 bit. Con SF12 sono necessari almeno 1,92 s (480 bit/250 bps = 1,92 s) mentre con SF7 sono sufficienti circa 44 ms (480 bit/11.000 bps = 0,044 s circa).



Batteria

Con SF7 il consumo di batteria è notevolmente inferiore rispetto a SF12 ma uno SF lento riesce a penetrare maggiormente gli ostacoli e a comunicare a lunga distanza. Immaginiamo di essere in una piazza affollata, alla distanza di 20 metri da una persona che per scambiare con noi 100 parole può impiegare 20 secondi o 200 secondi. Se la persona vuole comunicare chiaramente e a maggiore distanza può impiegare più tempo ed è necessario che parli a voce molto alta, stancandosi prima (l’equivalente della batteria che si consuma più velocemente), oppure può avvicinarsi e quindi parlare più velocemente e ad un volume più basso (è l’equivalente dell’utilizzo di un maggior numero di gateway).

È per questo motivo infatti che Intercomp cerca di utilizzare sempre lo SF7 nelle proprie installazioni: meglio utilizzare qualche gateway in più che dover sostituire le batterie dei sensori ogni 2 anni invece che ogni 8/10 anni.

Il sensore Intercomp è compatibile e certificato dalla LoRa Alliance™ con il piano canali EU863-870 e frequenza base di trasmissione e ricezione a 868 MHz. È utilizzabile in tutta l’Europa, il Medio Oriente e in alcuni paesi africani.



Configurazione

Per i nostri dispositivi sono disponibili tre differenti configurazioni.

LoRaWAN®

È realizzata secondo le specifiche della LoRa Alliance™, che prevede dispositivi, gateway, network server e piattaforma di gestione (ad esempio il nostro POLIS). Gateway e network server devono essere messi a disposizione dall’operatore LoRaWAN®, pubblico o privato. Il problema della saturazione si pone per numeri molto elevati di sensori ma in genere i produttori di gateway e network server dichiarano la possibilità di connettere diverse migliaia di dispositivi (anche fino a 20 mila), anche se molto dipende dal traffico generato.

LoRaWAN® SPN (Small Private Network)

LoRaWAN® SPN è una variante di LoRaWAN® che utilizza gateway con un network server integrato che presenta caratteristiche ridotte rispetto a un vero network server. Ogni gateway SPN consente di gestire qualche centinaio di dispositivi. È utile per realizzare reti LoRaWAN® private in tempi molto rapidi, risparmiando il costo di un network server (qualche decina di migliaia di euro).

LoRa Intercomp

Si tratta di un protocollo proprietario LoRa sviluppato da Intercomp che sfrutta le potenzialità di penetrazione e di distanza tipiche del protocollo LoRa, ma utilizza un solo canale per la comunicazione e il data rate (la velocità di comunicazione) è fisso normalmente su SF7.

I componenti di questa architettura sono i sensori LoRa Intercomp, i gateway R3000 Intercomp alimentabili in alta o bassa tensione e la piattaforma di gestione POLIS.

Ogni gateway è in grado di gestire fino a 150/200 sensori. Oltre questo numero il gateway può ancora funzionare, ma possono subentrare due fattori che devono essere tenuti in considerazione:

tipo di dispositivi connessi, che non sono tutti sono uguali. Ad esempio sensore smart parking può trasmettere anche oltre 50 messaggi al giorno, quindi il traffico radio generato sugli eventi libero e occupato, può risultare molto elevato;
Duty Cycle, vale a dire il tempo di trasmissione che, per rispettare la normativa di legge non deve superare l’1% calcolato su base oraria (non oltre 36 secondi in un’ora). Per un sensore non è un problema ma per un gateway può diventarlo se è configurato per rispondere ai dispositivi connessi e se questi sono in numero elevato. Il Confirmed Packet per le reti LoRaWAN® o l’Acknowledge (ACK) per la rete LoRa Intercomp (cioè la conferma che il pacchetto del sensore è stato consegnato) è un’opzione configurabile sui gateway LoRaWAN® e impostata di serie sulla rete LoRa Intercomp. Quindi se un gateway deve confermare la ricezione ad un numero elevato di sensori, è possibile che il limite del Duty Cycle venga raggiunto e da quel momento il gateway non potrà più rispondere ai dispositivi, a meno di non infrangere la normativa. In un sistema smart parking, soprattutto se vengono gestiti anche i pagamenti (come avviene nel sistema di Intercomp), la conferma di ricezione dei pacchetti è un dato molto importante. Ma essendo altrettanto importante la durata della batteria, nel protocollo LoRa Intercomp i sensori possono essere configurati in modo da stoppare i tentativi di comunicazione dopo 6 tentativi, nel caso non venga ricevuto l’ACK dal gateway.

La tecnologia NB-IoT (Narrow Band – Internet of Things) impiega frequenze e apparati delle bande LTE (Long Term Evolution).



Caratteristiche

Le frequenze dedicate a NB-IoT (il cosiddetto 4G impiegato dagli operatori telefonici) non sono ad uso pubblico, ma un operatore deve acquistare le licenze per poter utilizzare quelle frequenze nei vari Stati in cui vuole operare, arrivando a spendere fino a parecchi milioni di euro o dollari (ad esempio in Italia le aste per l’impiego delle frequenze riservate al 5G sono state assegnate per 6,55 miliardi di euro). In ogni Paese sono presenti generalmente dai 2 a 4 operatori in grado di offrire il servizio di connessione.

NB-IoT opera secondo le stesse modalità delle comunicazioni dati telefoniche, ma a differenza dei telefoni (ai quali occorre ricaricare la batteria praticamente ogni giorno) per i dispositivi come il nostro sensore gli operatori devono applicare una configurazione particolare che garantisca molta autonomia in merito a quando chiudere la comunicazione e quando rimanere in stand-by.

Con NB-IoT infatti la rete, a differenza del LoRa, è in grado di comandare i dispositivi connessi, risvegliandoli e facendoli rimanere on-line per il tempo desiderato. Gli operatori in ogni caso possono adottare una specifica configurazione per consentire ai dispositivi NB-IoT una certa libertà nella chiusura delle connessioni una volta trasmesso il pacchetto dati.



Efficienza

La velocità di comunicazione non è significativa per i consumi, mentre lo sono la configurazione della rete e la potenza di trasmissione.

Con NB-IoT non ci sono limiti di occupazione della banda e quindi si può disporre di una trasmissione per un periodo illimitato. Ovviamente se il dispositivo è alimentato a batteria e si sceglie un’installazione sotterranea (come per i sensori Intercomp), minori sono il tempo e la potenza impiegati per comunicare, maggiore è la durata della batteria.

Le frequenze utilizzate dalle reti NB-IoT sono chiamate bande e sono più ampie rispetto a LoRa. La B20 (800 MHz) e la B8 (900 MHz) sono presenti nel 67,8% del mercato mondiale. Infatti a parità di potenza garantiscono una buona penetrazione e distanza di comunicazione (più la frequenza è alta e più viene filtrata da muri, pareti e altri ostacoli).



Configurazione

Per quanto riguarda la configurazione delle reti non esistono molte variabili di architettura: l’unica possibile è rappresentata dall’operatore (e quindi dalla SIM) da utilizzare. Nel caso di un sensore la comunicazione con la cella telefonica è diretta previa configurazione dei parametri di rete.

La configurazione del dispositivo è stabilita dai settaggi dei parametri dell’operatore telefonico utilizzato (PLMN e APN). Nel firmware del dispositivo sono invece inseriti i parametri standard di configurazione comunicati dai produttori dei moduli radio NB-IoT.

Per quanto riguarda il problema della saturazione gli operatori garantiscono la connessione di decine di migliaia di dispositivi sulla stessa cella.

Conclusioni

Nei progetti di smart parking tutte le architetture possono essere utilizzate, valutando attentamente pregi e difetti di ognuna. Riguardo al LoRaWAN®, anche se i produttori sostengono la possibilità di gestire migliaia di dispositivi, dipende sempre dalla quantità di pacchetti inviata dai dispositivi stessi. Nel caso di sensori smart parking è preferibile non oltrepassare il numero di qualche centinaio per gateway, per non caricare troppo la rete e per poter utilizzare il Confirmed Packet.

I calcoli esatti di dimensionamento di una rete LoRaWAN® possono essere eseguiti mediante software specifici in grado di calcolare, in base all’area da coprire, al numero di dispositivi, alla quantità giornaliera o oraria dei pacchetti da ricevere e alla qualità del segnale desiderato, posizione e numero di gateway necessari.

Di seguito un confronto tra reti e architetture per lo smart parking.