IoT: LoRa e LoRaWAN

Introduzione

LoRa è una delle tecnologie più interessanti che maggiormente contribuir`a nei  prossimi  anni  allo  sviluppo  delle LPWAN.  Il  termine  LoRa è  l’acronimo di Long Range e si colloca nell’ambito di applicazioni WAN a bassa potenza. LoRa è una  tecnologia  wireless  proprietaria  operante  nella  banda  ISM (Industrial, Scientific and Medical) sviluppata dall’azienda francese Semtech Corporation. LoRa è un  marchio  sottoposto  a  brevetto,  pertanto  ogni  altro produttore di componenti elettronici che volesse integrarla nei propri dispositivi dovrà corrispondere delle royalties alla casa francese.

Spesso si sente parlare di LoRa e LoRaWAN indistintamente, ma `e necessario fare distinzione tra i due termini. Il primo è il livello fisico (o modulazione wireless) utilizzato per creare un link di comunicazione a lungo raggio attraverso questa tecnologia. Adotta una tecnica di modulazione chiamata CSS  (Chirp Spread Spectrum)  utilizzata  gia` da  decenni  in  ambito  militare e  nelle  comunicazioni  aerospaziali,  ma  che è stata  impiegata  per  la  prima volta in ambito commerciale grazie a Semtech.  LoRaWAN `e il protocollo di comunicazione superiore a quello fisico con il quale vengono definite tutta una serie di regole e l’architettura della rete. I requisiti di progettazione di questo protocollo sono in linea con le caratteristiche definite per le LPWAN, ovvero  il  risparmio  energetico  dei  dispositivi,  la  capacit`a della  rete,  la  qua- lit`a  del  servizio,  la  sicurezza  e  la  gestione  di  applicazioni  vaste  e  variegate.

La  LoRa  Alliance  (https://www.lora-alliance.org/)  è  un’organizzazione  non profit nata con lo scopo di standardizzare ilprotocollo e veicolare il successo a livello globale, i cui membri sono i maggiori leader del mercato, tra cui IBM, GoogleCloud, Cisco, Orange, ST Microelectronics, Bouygues telecom e, ovviamente, Semtech.

La caratteristica di LoRa, in linea con le linee guida delle reti LPWAN, `e quella di permettere la comunicazione tradispositivi su lungo raggio e con bassa potenza.  Inoltre, `e in grado di colmare quel gap che sia le reti cellulari che le tecnologie come WiFi, BLE (bluetooth low energy) non sono in grado di  soddisfare,  in  quanto  le  prime  richiedono  una elevata  capacit`a  di  banda e potenza trasmissiva mentre le seconde sono state pensate principalmente per ambienti indoor e per applicazioni a corto raggio. Le tecnologie basate su standard IEEE 802.15.4 come Zigbee, soddisfano il requisito di risparmio energetico ma non sono state progettate per trasmissioni a lungo raggio. Lo standard IEEE 802.15.4 adotta come soluzione al problema di copertura di una vasta aria, l’implentazione di una topologia di rete amesh, che però ha come svantaggio l’utilizzo di nodi che svolgono il compito di routing quindi devono essere sempreaccesi.

Figura 1 – Confronto tra LoRA e altre tecnologie wireless.

Panoramica tecnologia LoRa

LoRa opera all’interno della banda ISM ovvero la porzione di spettro elet- tromagnetico riservato dall’ITU (International Telecommunication Union) alle applicazioni di radiocomunicazioni non commerciali, ma per uso industriale, scientifico e medico. I requisiti normativi sono differenti in base ai vari continenti. Le due frequenze più  diffuse sono 868 MHz inEuropa e 915 MHz in Nord America. Altre regioni, in particolare l’Asia, hanno esigenze diverse. Queste frequenze, denominate Sub GigaHertz, hanno un’ottima ca- pacit`a di propagazione nello spazio e sono abbastanza resistenti agliostacoli, pertanto si prestano bene agli ambiti in cui sono necessarie le trasmissioni a lungo raggio. Di contro, utilizzando una limitata ampiezza di banda, non consentono il trasporto di dati ad elevato bit rate. Una trasmissione LoRa pu`o estendersi in campo aperto fino a 15 chilometri di distanza ed in ambito metropolitano fino ad un paio di chilometri. [20] A livello fisico la tecnologia LoRa impiega, in Europa, 10 canali di trasmissione nella banda degli 867-869Mhz. I canali hanno un’ampiezza di banda leggermente differente in base a che si tratti di canali in uplink (trasmissione disegnale) o downlink (ricezione di  segnale). Nel primo caso l’ampiezza di banda è di 125/250 KHz, mentre nel secondo caso è di 125 KHz (in Europa) [2].

LoRa PHY

LoRa è una tecnologia di trasmissione wireless proprietaria di Semtech. Essa utilizza la tecnica CSS, “Chirp SpreadSpectrum”, per ottenere una buona resilienza al rumore e raggiungere coperture di diversi chilometri sia in aree rurali che in zona urbane. Si presentano brevemente gli aspetti principali inerenti alla trasmissione LoRa che sono risultati utili al prosieguo del lavoro.

Come già accennato il segnale wireless trasmesso si basa sulla tecnica CSS. Esso è composto da simboli, contenenti leinformazioni da trasportare, ciascuno ha le seguenti caratteristiche:

• Le frequenze che lo compongono sono tutte comprese tra una f_min ed una f_max che ne delimitano la banda, BW;
• Esso inizia all’istante t=t₀ con una frequenza f=f₀ appartenente all’intervallo [f_min; f_max];
• Nel caso si tratti di un “upchirp”/“downchirp”, la frequenza f del segnale cresce/diminuisce linearmente nel tempo sinoa quando non raggiunge f_max/f_min. A questo punto essa riparte dall’estremo opposto della banda, ovvero f_min/f_max, fino al raggiungimento della frequenza f0.

All’interno della banda del segnale esistono 2^SF livelli di frequenza dai quali ciascun simbolo può originarsi (SF è lo “Spreading Factor”). Pertanto per ciascun SF è possibile ottenere 2^SF simboli diversi e ogni simbolo codifica un numero di bit pari a SF.

Figura 2 – Rappresentazione di un “upchirp”.

Si riporta (1):

𝑅𝑐ℎ𝑖𝑝 = 𝐵𝑊

e (2):

𝑇𝑐ℎ𝑖𝑝 = 𝑅𝑐ℎ𝑖𝑝−1

Con 𝑅𝑐ℎ𝑖𝑝 frequenza di un singolo “chip” e 𝑇𝑐ℎ𝑖𝑝 durata di un singolo “chip”. A partire dall’equazione (2) definiamo la durata di un simbolo (3):

e (4):

Infatti ciascun simbolo è ottenuto moltiplicando i dati da trasmettere per uno “spreading code” composto da 2^SF “chips”.

Infine calcoliamo la rapidità di variazione delle frequenze di un simbolo come (5):

Come si può notare dall’equazione (6) è possibile modificare la “pendenza” di un simbolo agendo sulla BW e sullo SF. Unaproprietà interessante che si ottiene da questo fenomeno è l’ortogonalità dei simboli. Due simboli si definiscono ortogonali quando configurati con opportune valori di BW e SF non interferiscono l’uno con l’altro pur sovrapponendosi temporalmente. Grazie a tale proprietà è possibile avere contemporaneamente trasmissioni multiple sullo stesso canale. In Figura 3 si possono osservare simboli non ortogonali tutti dotati della stessa rapidità di variazione di frequenza nel tempo.

Figura 3 – Spettrogramma di simboli non ortogonali.

Invece in Figura 4 i simboli rappresentati sono ortogonali tra di loro.

Figura 4 – Spettrogramma di simboli ortogonali.

Figura 5 – Configurazioni di Spreding Factor (SF) e Bandwidth [kHz] (BW) non ortogonali. Evidenziate in rosso le configurazioni disponibili per le reti LoRaWAN.

Un altro aspetto della modulazione LoRa è lo schema di correzione degli errori utilizzato per migliorare la robustezza dei segnali trasmessi. Esso garantisce prestazioni di decodifica migliori a spese di una certa ridondanza introdotta nei datitrasmessi.

Partendo da un bit rate di modulazione Rb pari a (6):

dove SF indica il numero di bit presenti in ogni simbolo, possiamo definire un bit rate nominale 𝑅𝑏𝐼 che tiene conto anche della ridondanza introdotta dalla tecnica di correzione (7):

Nell’equazione (7) il 𝑅𝑎𝑡𝑒 𝐶𝑜𝑑𝑒, sempre minore di uno, quantifica l’overhead in trasmissione dovuto allo schema dicorrezione e dipende dal parametro detto “code rate”, abbreviato con CR [14].

Prima di proseguire mostrando le prestazioni dichiarate da Semtech sulla “sensitivity” offerta da LoRa nella decodifica dei messaggi, ovvero la minima intensità di un segnale correttamente rilevabile da un ricevitore, introduciamo il concetto di “link budget”. Esso rappresenta la quantità di energia che una trasmissione radio può spendere per propagarsi nelmezzo di comunicazione e raggiungere un ricevitore con una potenza sufficiente alla decodifica delle informazionitrasportate.

La potenza di una trasmissione radio varia durante il tragitto tra il trasmettitore e il ricevitore. Si hanno solitamente perdite dovute alle connessioni tra i vari componenti dei dispositivi, guadagni di potenza forniti dalle antenne ma soprattutto siha un grandissimo degrado delle prestazioni durante la propagazione del segnale in aria. In Figura 8 si propone una rappresentazione grafica della variazione di potenza di un segnale durante la sua propagazione.

Figura 6 – Potenza di un segnale nel tragitto dal trasmettitore al ricevitore.

Utilizzare modulazioni wireless  che offrono  una “sensitivity” molto bassa è vantaggioso perché permettono dicoprire lunghe distanze in trasmissione.

Per quantificare le prestazioni dichiarate da Semtech [14] si sono calcolate le distanze teoriche massime di alcune trasmissioni LoRa supponendo l’utilizzo della massima potenza permessa ai dispositivi, ovvero 14dB [12], e il modello dipropagazione denominato “Okumura-Hata”, appositamente realizzato per lo studio di comunicazioni radio in scenari urbani [15]. In particolare la formula considerata per il calcolo del “path loss”, ovvero la perdita di potenza del segnale durante la fase di propagazione in aria, è stata (8):

𝐿𝑢 = 69.55 + 26.16 ∗ 𝑙𝑜𝑔10 𝑓 − 13.82 ∗ 𝑙𝑜𝑔10 ℎ𝐵 − 𝐶𝐻 + (44.9 − 6.55 ∗ 𝑙𝑜𝑔10 ℎ𝐵) ∗ 𝑙𝑜𝑔10 𝑑

Dove per città grandi si ha (9):

Con:

• Lu = “path loss” nelle aree [dB]
• hB = altezza dell’antenna del gateway. [m]
• hM = altezza dell’antenna del end-device. [m]
• f = frequenza della [MHz]
• CH = fattore di correzione dell’altezza dell’antenna. [dB]
• d = distanza tra il gateway e il [km]

I valori ottenuti nei calcoli al variare delle configurazioni di rete considerate sono riassunti in Tabella 1.

Tabella 1 – Bit rate e sensitivity di diverse configurazioni di trasmissioni LoRa e relative distanze di copertura derivate con l’utilizzo dell’equazione.

LoRa PHY (livello fisico) utilizza CSS (Chirp Spread Spectrum) come tecnica  di  dispersione  dello  spettro.  Questa modulazione `e  stata  sviluppata originariamente per applicazioni radar fin dagli anni ’40 per poi essere adot- tata indiverse applicazioni di comunicazione di ambito militare. I punti di forza di questo tipo di modulazione sono la potenza relativamente bassa e l’elevata robustezza intrinseca a meccanismi di degrado del canale di comuni- cazione da interferenze come il multipath fading, l’effetto Doppler e l’in-band jamming.

Tabella 2 – Riepilogo caratteristiche spettro LoRA.

Essendo  resistente  all’effetto  Doppler  pu`o  essere  anche  impiegata per oggetti in movimento. CSS codifica i dati conun “chirp”, essenzialmente un segnale sinusoidale modulato in frequenza a banda larga che varia linearmente con il tempo, crescendo (up-chirp) o decrescendo (down-chirp) [23].

CSS, a differenza di FHSS e DSSS, non aggiunge alcun elemento pseudo- casuale al segnale per aiutare a distinguerlo dal rumore sul canale, affidandosi invece alla natura lineare dell’impulso del chirp. La modulazione LoRa ado- pera pertanto una variazione di frequenza, concettualmente simile ad FSK (Frequency Shift Key) ma con uno schema un p`opiu` complesso che rende la trasmissione  piu`  resiliente  alle  interferenze. L’intera banda di canale viene impiegata per la  trasmissione. La bandwidth (BW) è la porzione di spettro occupata da un chirp,  che  nel  caso  di  LoRa, è scalabile  ed è stata  stabilita essere, in base agli accordi internazionali, di 125 Khz,  250 Khz e 500 Khz.

Figura 7 – Rappresentazione di un chirp.

In Europa sono ammesse solo le prime due. Un incremento della banda permette di usare un data rate effettivo piu` alto,ma esistono dei vincoli nor- mativi da rispettare in merito all’occupazione di banda.  Sebbene CSS `e una tecnica  di dispersione  dello  spettro  e  quindi  garantisce  una  migliore  qualit`a di trasmissione, per poter garantire un buoncompromesso tra performance ed impiego minimo di risorse i canali LoRa dispongono di una bandwidth ristretta [21].La modulazione spread spectrum LoRa viene eseguita attra- verso la rappresentazione di ciascun bit dell’informazionedel payload in piu` chirps di informazione. Il rate con il quale l’informazione viene diffusa ed inviata `e relativa al symbolrate.  Il rapporto tra il symbol rate nominale ed il  chip  rate  `e  chiamato  spreading  factor  e  rappresenta  il  numero  di simboli inviati per bit di informazione.  Spreading Factor (SF) è ottenuto calcolando il logaritmo del numero di chirps per simbolo, in quanto 1 simbolo equivale a 2^SF [21].

LoRa offre sei diversi fattori di dispersione che vanno da SF-7 a SF-12. Quanto piu` il fattore di dispersione `e alto, tanto piu` il segnale `e robusto e sopravvive alle lunghe distanze. Nella Tabella 3 vengono riportati i valori di spreading factor ed il relativo numero di chips per simbolo.

Tabella 3 – Lora Spreading Factor, Chirps Symbol, Demodulator SNR.

Nella Figura 8 `e possibile apprezzare la differenza della durata di un chip in  relazione  ai  valori  di  SF.  Ad  un  valore  piu` elevato  di  SF  corrisponde  una durata maggiore del segnale.

Figura 8 – Spettrogramma dei diversi valori di Spreading Factor.

Il Chirp Rate rappresenta il numero il numero di chirp per secondo ed `e equivalente alla BW [21]. Il Coding Rate(CR) viene usato per migliorare la robustezza di un link LoRa ed indica il quantitativo di ridondanza applicata ai dati.Maggiore  ridondanza  equivale a fornire maggiore affidabilit`a al trasporto dei dati a discapito del quantitativo di datiutili del payload.

Esiste una relazione inversamente proporzionale tra ridondanza e bit rate. Il coding  rate  pu`o  assumere  valori  da  1  a 4.   Il  modem  LoRa  impiega  il  con- trollo a ridondanza ciclica (CRC) per effettuare la correzione degli errori. Tuttavia la correzione degli errori introduce un overhead di dati relativo alla trasmissione.  Il  data  overhead  per  trasmissione `e riepilogato  nella  seguente tabella:

Tabella 4.3: Lora Coding Rate, Cycle Coding Rate,Overhead Radio.

Un simbolo nella modulazione CSS ha quattro importanti parametri: Spreading Factor, frequenza minima f_min, frequenza massima f_max, input bits.   Per  generare  un  simbolo  CSS,  `e  necessaria  una  frequenza  di  parten- za  f0. La frequenza di partenza `e compresa tra f_min e f_max e rappresenta l’informazione in input ottenuta con log₂(SF ) [23]. Per SF ¹, log₂(SF ) bits definisco f₀.

La lunghezza di un simbolo T_s  pu`o essere cos`ı calcolata [23]:

Una  volta  che  la  lunghezza  di  un  simbolo  T_s  `e  stata  definita,  possiamo definire un chirp come un tono che oscilla tra f<sub>0</sub> e f<sub>max</sub>.  La modulazione LoRa `e definita attraverso tre parametri:  Spreading Factor (SF), bandwidth (BW)  e frequenza  del  canale.   Il  compito  svolto  dal  modulatore  `e  quello  di tradurre i simboli costituiti da SF bits in chirps che corrispondono a 2<sup>SF</sup> samples ad un specifico chirp rate (BW). Pertanto i bits di SF del simbolo in ingresso si traduconoin 2<sup>SF</sup> spostamenti unici dell’onda base che rappresenta il  chirp.  Un  aspetto  importante  della  modulazione  CSS `e che  per  ogni  sim- bolo  `e  necessario  raddoppiare  il  numero  di  samples  in  output  necessari  per modulare ilsimbolo. Questo rende la modulazione LoRa CSS molto lenta ma estremamente robusta alle interferenze ed alrumore.

Il fattore di dispersione SF, la bandwidth BW ed il coding rate determi- nano Il bit rate della trasmissione dati LoRa :

Dove:

• SF = Spreading Factor (6,7,8,9,10,11,12)
• CR = Coding Rate (1,2,3,4)
• BW = Bandwidth in KHz (10.4, 6, 20.8, 31.25, 41.7, 62.5, 125, 250, 2500)
• R_b= Data rate or Bit Rate in bps

Il bit rate in LoRa dipende dalla combinazione dei possibili valori di SF, CR e BW,  pertanto  si pu`o  calcolare quali sono  i  data  rate  possibili.  Il rapporto che esiste tra spreading factor e bit rate `e inversamente proporzionale.  Se si vogliono raggiungere distanze maggiori bisogna aumentare spreading factor a discapito del bit rate, viceversa se si vuole incrementare data rate bisogna ridurre spreading factor. Nella Tabella 4 riporto un esempio del data rate ottenibileper le tre differenti bande a parit`a di spreading factor e coding rate [21].

In base ai requisiti dell’applicazione, ma soprattutto in base allo scenario in cui vengono collocati due stazioni chetrasmettono attraverso un link Lora `e possibile configurare i parametri di spreading factor, coding rate e bandwidth per ottenere  le  migliori  condizioni  per  la  qualit`a  di  servizio.  Tra  le  features piu`  interessanti di LoRa c’`e anche l’elevatasensitivit`a, in quanto la stazione radio `e in grado di decifrare il segnale fino alla soglia di -137 dBm.

Tabella 4 – Lora Bandwidth (KHz), Spreading  Factor,   Coding  Rate, Nominal Rb.

Grazie a questa caratteristica, LoRa `e in grado di ricevere e trasmettere dati anche su distanze dell’ordine dei chilometri. Esiste un rapporto diretto tra spreading factor, bandwidth e la soglia di sensitivit`a possibile in relazione aquesti due fattori. Spreading Factor rappresenta il rapporto tra chip rate e symbol rate, pertanto per un valore alto di SFcorrisponde un incremento del Signal Noise Ratio (SNR), della sensitivita, della distanza ma anche tempo necessario allatrasmissione  del  dato  (airtime).  SNR  `e  il  rapporto  minimo  tra  potenza  del segnale desiderata e rumore che pu`oessere demodulato e viene espressa in db [29].  Per  il  calcolo  della  sensibilit`a  del  ricevitore, `e  necessario  il  valore SNR minimo in modo che l’informazione possa essere decodificata correttamente. Ad ogni valore di spreading factorcorrisponde una soglia minima di SNR. Ad  esempio  per  un  valore  di  SF  pari  a  7  `e  necessario  un  valore  minimo  di-7.5 db di SNR per decifrare l’informazione. Questi valori possono cambiare anche in base alla BW. La tabella 4.6 riepiloga la corrispondenza che esiste tra SF, SNR e time on air sulla banda dei 125 KHz. Bisogna precisare che il time on air dipende anche dalla dimensione in byte del pacchetto inviato [21].

La soglia di sensitivit`a di un ricevitore radio indica il valore espresso in db al di sotto del quale non `e possibiledecodificare i dati trasmessi.

Tabella 5 – Lora Spreading Factor,SNR Limit (db),Time on air.

La formula per calcolare la sensitivit`a S, di un ricevitore radio `e la seguente:

S = −174 + 10log₁₀(BW ) + NF + SNR

Dove:

• S = sensitivit`a in dBm
• BW = Bandwidth in KHz
• NF = Noise Figure (quantifica la rumorosit`a di un sistema)
• SNR = Signal Noise Ratio

L’equazione  della  soglia  di  sensitivit`a  prende  in  considerazione  il  valore  di SNR, pertanto essendo quest’ultimo,nel caso di LoRa in riferimento a SF, ne consegue che esiste un valore di sensitivit`a diverso per ogni valore di SF.

Anche  in  questo  caso  per  un  piu`  alto  valore  di  SF  corrisponde  un  piu`  alto valore di SNR e quindi `e necessaria unasensitivit`a maggiore.  La Tabella 6 mostra  quali  sono  i  valori  di  sensitivit`a  in  relazione  ai  valori  di  SF  per  ogni bandadi frequenza [21].

La modulazione LoRa implementata dal livello PHY fornisce un impor- tante miglioramento di link budget rispetto alle tradizionali modulazioni narrowband.

Tabella 6 – Rapporto tra Spreading Factor e Bandwidth.

Il link budget massimo `e di 157 dB e viene calcolato in questo modo [22]:

LB = +20 − (−137) = +157dB

Dove:

• P_rx = +20 dBm a 100 mW costanti in output all’antenna
• RS = fino a -137 dBm

Il livello fisico LoRa (PHY Layer) oltre a definire tutte le caratteristiche per la modulazione del segnale, definisce anche la struttura del pacchetto. BW e SF sono i principali parametri della modulazione LoRa. Un simbolo LoRa  `e composto  da  2<sup>SF</sup>  chirps,  che  coprono  l’intera  banda  a  disposizione. Un chirps a livello fisico, inizia con una serie di upward chirps (variazione crescente della frequenza). La variazione di frequenza nel tempo viene ef- fettuata quando viene raggiunta la frequenza massima della banda per poi ripartire dalla frequenza minima, come `e possibile vedere in Figura 9.

Figura 9 – Variazione di frequenza nel tempo di un segnale emesso.  fc `e la frequenza centrale del canale.

Sebbene la modulazione LoRa potrebbe trasmettere un qualsiasi frame, Semtech definisce uno specifico formato del frame per la trasmissioni di un pacchetto tra due stazioni LoRa. Un frame LoRa inizia con un preambolo. Il preamboloinizia con una sequenza costante di otto up-chirps che coprono l’intera banda di frequenza. Gli ultimi due up-chirps dell’ottetto, decodi- ficano  la  sync  word.   La  sync  word  `e  un  valore  di  un  byte  che  `e  usato  da differenti LoRa network che usando la stessa banda. Un dispositivo configu- rato con una specifica sync word potr`a fermare l’ascoltodelle trasmissioni se si accorge che la sync word non corrisponde alla sua configurazione. Dopo gli  otto  up-chirps seguono  due  down-chirps  piu`  1/4  di  down-chirp,  per  una durata di 2.25 simboli chiamati simboli di sincronizzazioneche vengono usati per la sincronizzare la trasmissione nel tempo. La durata totale del pream- bolo  pu`o  essere configurata  tra  10.25  e  65539.25  simboli.   A  seguire  c’`e  la trasmissione dei simboli che identificano il payload. L’immagine 4.5 mostra la modulazione del segnale di un frame LoRa.

Dopo  il  preambolo  c’`e  un  header  opzionale.   Quando  `e  presente,  questo header `e trasmesso con un code rate di4/8.  Questo indica la dimensione del payload (in byte), il code rate usato per la fine della trasmissione e se il CRC a 16-bit  `e  abilitato  o  meno,  quindi  se  presente  dopo  il  payload.   L’header, inoltre, include un CRC che permette al receiver di scartare i pacchetti con un  header  non  corretto.   Il  payload  pu`o  avere  dimensioni  da  1  a  255  byte. L’header pu`o essere disabilitato se ritenuto non opportuno usarlo per lasciare un maggiore spazio per il payload.  Ilpayload `e sempre inviato dopo l’header e alla fine del frame pu`o esserci opzionalmente il CRC del payload.  La Figura 11 mostra lo schema che riassume il formato del frame.

Figura 10 – Spettrogramma LoRa.

Per  trasmettere  il  payload  n_s  `e  possibile  calcolare  quanti  simboli  sono necessari attraverso un’equazione che prende in considerazione tutti questi parametri. Per calcolare quanti sono i simboli necessari per la dimensio- ne totale del pacchetto bisogna aggiungere anche i simboli per codificare il preambolo.  L’equazione `e la seguente :

Dove:

• PL = dimensione payload in byte
• CRC = 16 se il CRC `e abilitato, zero altrimenti
• H = 20 quando l’header `e abilitato, zero altrimenti
• DE = 2 quando low data rate optimization `e abilitato, zero altrimenti

Figura 11 – Struttura di un frame LoRa.

LoRaWAN

LoRaWAN `e il protocollo di livello MAC creato per usare lo strato fisico LoRa.  Esso `e  stato  progettato  principalmente per  le  reti  di  sensori,  in  cui  i dispositivi scambiano pacchetti con un server con un basso data rate e con un lungointervallo di tempo.  Lo stack LoRaWAN `e composto da quattro livelli. Al livello piu` basso c’`e la specifica inerentel’accesso fisico alle frequenza della banda ISM e le relative regolamentazioni che dipendono dall’area geografica in  cui  si opera.   Il  secondo  livello  c’`e  la  specifica  sulla  modulazione  LoRa  e rappresenta lo strato proprietario di Semtech, in quanto la tecnica di CSS utilizzata da LoRa `e stata brevettata.  Il livello Mac `e open source e definisce le classi degliend device.  Il livello piu` alto `e l’applicazione in cui il dispositivo viene impiegato.

LoRAWAN definisce l’organizzazione della rete e quali sono i ruoli dei dispositivi  in  questo  contesto.   La  topologia  `e a  stella,  in  cui  vi  `e  un  no- do centrale con la funzione di gateway in grado di instradare verso la rete Internet tutti i pacchetti provenienti dai vari dispositivi con cui interagisce attraverso un link LoRa entro il raggio di copertura della trasmissione. In questo  design  non  `e  previsto  che  i  dispositivi  possano  comunicare  diretta- mente tra loro e tantomeno possano instradare i pacchetti verso altri nodi.

Figura 12 – Stack LoRaWAN.

Questa scelta progettuale fa in modo che, sebbene l’architettura di rete sia abbastanza semplice ed il nodo gatewayrappresenta un single point of failure, permette di mantenere i costi di deploy bassi, in quanto i dispositivi hanno solo compito di trasmettere e ricevere dati verso il gateway e vengono assolti dalle funzioni di routing tipico delle reti mesh.

Componenti di una rete LoRaWAN

Nelle specifiche del protocollo LoRaWAN vengono definiti i ruoli dei com- ponenti all’interno della rete: end device, gateway e network server. Gli end device sono sensori a basso consumo energetico in grado di comunicare con ilgateway attraverso un link LoRa. All’interno di una rete LoRa possono esse- re presenti anche migliaia di questi nodi in quanto questi dispositivi possono trasmettere anche allo stesso tempo sul mezzo trasmissivo usando differentifrequenze o spreading factor [21].

Il gateway `e dispositivo intermedio in grado di instradare i pacchetti pro- venienti dagli end device verso il networkserver attraverso un collegamento IP che possa permettere un elevato throughput come ad esempio un link 3g/4g oppure  Ethernet. In un deploy LoRaWAN possono esistere piu` gateways e lo stesso pacchetto  pu`o  essere  ricevuto  ed instradato  da  uno  o  piu` di essi. Per poter supportare una rete a stella di ampie dimensioni, il gateway deve  disporre  di buone  capacit`a  di  ricezione,  ed  essere  capace  di  gestire  un alto numero di messaggi provenienti da svariati enddevice (anche sull’ordine delle migliaia).  Il gateway `e in grado di ascoltare le trasmissioni anche su piu` canali e di decodificare pacchetti inviati con un differente spreading factor contemporaneamente.

Il  network  server  `e  una  componente  di  back-end  che  svolge  processi  piu` complessi in relazione al management delnetwork.  Esso `e responsabile della ricezione  dei  dati  provenienti  dai  vari  gateway  e  svolge  diverse  funzionalit`a tracui il filtraggio ed eliminazione di eventuali pacchetti duplicati. Il network server implementa la funzionalit`a di adaptivedata rate (ADR) allo scopo di massimizzare la vita delle batterie che alimentano i dispositivi e la capacit`a totale della rete. Il network server assegna a ogni end node che si vuole connettere alla rete, un data rate e una potenza di uscitada utilizzare per la trasmissione RF, diversa per ogni esigenza.   L’algoritmo ADR assegna un  data  rate  maggiore  ai  nodi  terminali  piu`  vicini  al  gateway  in  quanto meno suscettibili alle interferenze, e una potenza di uscita minoreper la trasmissione RF. Minor tempo di trasmissione e minor potenza di uscita si traducono in un ovvio risparmioenergetico.   Solo ai nodi che si trovano a  distanze  notevoli  dal  gateway,  il  server  assegner`a  un  data  rate  piu` basso (minore  suscettibilit`a  ai  rumori)  e  una  maggiore  potenza  di  uscita.   Il  data rate previsto non `e quindicostante.  Le specifiche LoRaWAN indicano valori che vanno da 300bps fino a 50kbps [22].

I dati ricevuti possono essere inviati agli application server per le elabora- zioni successive oppure `e possibile inviareeventuali notifiche agli end device per far attuare un’azione. Non ci sono interfacce standard di trasmissione dei dati tranetwork server ed application server.

Figura 13 – Architettura LoRaWAN.

A differenza di una tradizionale rete cellulare o una rete Wi-Fi, gli end device non sono associati ad uno specifico gateway per poter accedere alla re- te. Il gateway ha semplicemente il ruolo di stabilire un link di comunicazione LoRa edi instradare i pacchetti ricevuti dagli end device verso il network server e viceversa, al piu` aggiungendo informazionisulla qualit`a di ricezione dei dati.  In questo modo, un end device `e associato ad un network server il quale rappresentauna sorta di coordinatore della rete ed `e in grado di comunicare con un altro end device attraverso il gateway opportuno. A livello logico il gateway `e trasparente in quanto ha solo il ruolo di instradamento senza fare alcuna elaborazione. Le trasmissioni tra end device e gateway possono essere di due tipi:

• Uplink : trasmissione dati da end device verso il gateway
• Downlink : trasmissione dati da gateway verso end device

Figura 14 – Struttura dei diversi componenti di una rete LoRaWAN e connessioni presenti tra di esse [Fonte:  https://www.lora-alliance.org/technology].

Le classi LoRaWAN

LoRaWAN definisce tre classi di funzionamento, di cui solo la classe A deve essere obbligatoriamente implementata su tutti i dispositivi compatibili con LoRaWAN. Grazie a questa politica, abbiamo un insieme di caratteristiche di base che sono presenti su tutti i dispositivi finali LoRaWAN, mantenendo sia la complessità architettonica che il costo di produzione il più basso possibile.

LoRaWAN ha tre differenti classi di end device che si differenziano tra loro sulla  modalit`a  di  ricezione  dei  pacchetti  in downlink  (da  gateway  verso  end device), il che permette di soddisfare i requisiti di scenari applicativi differen- ti in relazione al consumo energetico.

Oltre alla classe di base, sono state definite due modalità di funzionamento più complesse con l’obiettivo di disaccoppiare le trasmissioni a valle da quelle a monte. Dato che queste due modalità avanzate possono essere più costose da progettare, produrre e mantenere, solo i dispositivi finali che richiedono fortemente queste caratteristiche sono tenuti a implementarle.

Di default i dispositivi LoRa operano in modalit`a classe A con le propriet`a di risparmio energetico, mentre devono essere esplicitamente configurati per operare in classe B o C. Inoltre i dispositivi di classe B e C devono comunque soddisfare anche i requisiti di classe A [22]. Le tre classi dei dispositivi sono:

• Classe A, bidirezionali: I dispositivi di classe A possono schedulare l’invio di una trasmissione in uplink in base alle specifiche dell’applica- zione ad intervalli di tempo regolari con un piccolo jitter che consiste in una variazione random prima della trasmissione. Questi tipi di device permettono comunicazioni bidirezionali attraverso un meccanismo per ilquale restano in ascolto per un certo intervallo di tempo di eventuali trasmissioni in downlink solo dopo aver effettuato una trasmissione in Il  tempo  in  cui  restano  in  ascolto `e  determinato  da  due  brevi finestre in ricezione dopo aver trasmesso un pacchetto. Una volta ter- minato il tempo di ricezione il dispositivo di classe A torna in modalit`a dormiente per conservare energia delle batterie.
• Classe B, bidirezionali con slot in ricezione schedulato: Questi tipi di dispositivi si mettono in ascolto di comunicazioni in downlink aprendo una finestra in ricezione ad intervalli di tempo schedulati. Per questo tipo di  comunicazione `e necessario un  meccanismo  di  sincronizzazione con  il  gateway  che  avviene mediante  b Il network server dovr`a conoscere quando l’end device sar`a in ascolto.
• Classe C, bidirezionali con slot di ricezione: A questa categoria af- feriscono tutti quei dispositivi che sono costantemente in ascolto. Il ri- cevitore LoRA resta attivo permettendo una ricezione immediata senza che il dispositivoapra una finesta in

La scelta della classe dell’end device deve essere ponderata in base ai re- quisiti dell’applicazione ed al contesto in cui si opera. Le classi A e B garantiscono una migliore efficienza energetica e sono stati pensati per i dispositivi alimentati a batteria, mentre gli end device di classe C sono alimentati at- traverso  rete  elettrica. Questo tipo di comunicazione  non `e  pensato  per  il risparmio energetico ma garantisce che il dispositivo possa ricevere direttive in un qualsiasi  momento.La  banda  ISM  utilizzata  dalle  reti  LoRaWAN  `e soggetta a limitazioni d’uso sulla base delle normative vigenti. Esistono delle regolamentazioni in merito alla potenza massima trasmissiva e sul duty cycle (ciclo di lavoro utile).

Figura 15 – Classe A.

Figura 16 – Classe B.

Le limitazioni sul duty cycle si traducono in un ritardo sul frame che deve essere successivamente inviato. In Europa sulla banda di frequenza  degli  868  MHz  il  duty  cycle  `e  pari  a  1%  per  gli  end  device  [27]. Questo implica che unend device su 100 slot di tempo (suddivisione logica del  tempo)  ne  pu`o  impiegare  al  piu`  uno  per  la  trasmissione.   Inoltre  dovr`a effettuare un salto di canale pseudo-random per ogni trasmissione.   Infine, nelle public community network, esiste un regolamento per una equa politica di accesso al canale che limita la trasmissione in uplink a 30 secondi al giorno per end device ed i messaggi in down-link a 10 messaggi al giorno per end device. Tuttavia se si unarete LoRaWAN privata non sono previste que- ste limitazioni ma bisogna rispettare i limiti imposti dalle leggigovernative.

Figura 17 – Classe C.

Per quanto riguarda la politica di accesso al canale condiviso da parte di piu` stazioni trasmittenti, LoRa nonimplementa nessun meccanismo di chan- nel feedback ovvero di ascoltare il canale prima di trasmettere perverificare se  `e  occupato  da  un’altra  trasmissione  come  avviene  invece  per  il  protocol- lo CSMA. I dispositivi di classe A implementano una politica di accesso al mezzo simile ad ALOHA, in cui il tempo `e suddiviso in intervalli logici (slot) di lunghezza prefissata. La trasmissione del dato sul canale avviene quando il trasmettitore radio `e pronto dopo averaspettato per un numero casuale di slot. Viene inviato sempre il primo pacchetto in testa alla coda del buffer. Nel caso di messaggi che richiedono conferma (ack) il trasmettitore effettua una ritrasmissione in caso di mancata ricezione diack.

Finestre di ricezione di classe A

Dopo ogni trasmissione in uplink, il dispositivo finale apre due brevi finestre di ricezione. La finestra di ricezione inizia esattamente dopo un intervallo di tempo predefinito dalla trasmissione dell’ultimo bit di uplink.

La prima finestra di ricezione (RX1) viene aperta dopo RECEIVE DELAY1 milli-secondi, che per impostazione predefinita è impostato su 1 secondo. Utilizza la stessa frequenza della trasmissione uplink precedente e, in generale, anche la stessa velocità di trasmissione (in alcune regioni può essere funzione della velocità di trasmissione uplink).

La seconda finestra di ricezione (RX2) viene aperta dopo RECEIVE DELAY2 millisecondi, definito come RECEIVE DELAY1 + 1 secondo. La fre- quenza e la velocità di trasmissione sono fisse per tutte le trasmissioni, quindi non dipendono dalla comunicazione uplink precedente, e sono configurabili tramite un comando MAC come rappresentato in Figura 18.

Figura 18 – Finestre di ricezione LoRaWAN.

Ciascuna finestra di ricezione viene mantenuta aperta almeno per il tempo necessario a de- ttrare il preambolo di una trasmissione downlink LoRa, che è dell’ordine dei microsecondi. Se un frame viene ricevuto correttamente durante la prima finestra di ricezione, il dispositivo finale non apre la seconda. Un dispositivo finale non deve trasmettere un altro messaggio uplink prima che sia stato ricevuto un messaggio downlink o che sia scaduta la finestra RX2.

Formato del messaggio

LoRaWAN fornisce un protocollo di rete full stack, con caratteristiche di livello data- link, rete e trasporto, e supporta nativamente la crittografia, l’autenticazione e la comunicazione affidabile attraverso la ritrasmissione dei pacchetti.

Radio physical layer

Ogni pacchetto LoRa trasporta un carico utile fisico (PHYPayload) che contiene messaggi LoRaWAN. Quando un pacchetto LoRa contiene un messaggio LoRaWAN, il campo CRC, calcolato sul PHYPayload, è presente solo nelle trasmissioni up-link, poiché è disabilitato per le trasmissioni down-link.

Figura 19 – Livello fisico della radio LoRa (messaggi CRC solo in uplink).

Physical payload

Il payload fisico contiene tre campi principali:

– MAC Header: specifica il tipo di messaggio e la versione di LoRaWAN;

– MAC Payload: contiene il frame LoRaWAN;

– MIC: il Message Integrity Code, è calcolato come specificato nella RFC 4493 e autentica ogni messaggio al LoRa Network Server.

Figura 20 – Carico utile fisico LoRa strutturato come messaggio LoRaWAN.

MAC Header

L’intestazione MAC specifica il tipo di messaggio e la versione di LoRaWAN. Nella tabella 3.1 sono riportati tutti i possibili tipi di messaggio LoRaWAN.

Figura 21 – LoRaWAN MAC header.

Tabella 7 – LoRaWAN message types.

MAC Payload

Il payload MAC contiene i campi obbligatori Frame Header e, facoltativamente, Frame Port e Frame Payload.

Figura 22 – LoRaWAN MAC payload.

Frame Header

Il Frame Header contienes il 32 bit Device Address, il campo Frame Control, il Frame Counter e il campo Frame Options, che viene utilizzato per aggiungere comandi MAC al traffico dati dell’utente.

Figura 23 – LoRaWAN frame header.

Nel Frame Control sono presenti diversi flag importanti: il flag ADR segnala che la velocità dei dati è controllata dalla rete; il flag ADRACKReq è impostato dal dispositivo per verificare se il gateway è ancora in grado di ricevere il suo traffico; il flag ACK è impostato per confermare il precedente pacchetto ricevuto.

Figura 24 – LoRaWAN frame control.

Frame Port and Frame Payload

Per impostazione predefinita, LoRaWAN cripta ogni Frame Payload mediante l’Application Session Key. Se il Frame Payload contiene un comando MAC, la Frame Port viene impostata a 0 e viene crittografata con la Network Session Key. Se la crittografia viene eseguita al di sopra del livello LoRaWAN, è possibile disabilitare questa funzione tramite un comando MAC, ma ciò è consentito solo se il frame payload non contiene un comando MAC.

Comandi MAC

I comandi MAC sono un insieme di messaggi scambiati esclusivamente tra il livello MAC dei dispositivi finali e il server di rete. Questi messaggi possono contenere informazioni utili per l’amministrazione della rete, come la verifica dello stato di un dispositivo o la modifica di alcuni parametri di comunicazione, e non sono mai visibili al server applicativo in esecuzione nel cloud o all’applicazione in esecuzione sul dispositivo finale.

I comandi MAC possono essere inviati come Frame Payload, impostando Frame Port a 0 ed eseguendo la crittografia tramite NetworkSessionKey. I comandi MAC possono anche essere inseriti nel campo FOpts, in questo caso non devono superare i 15 ottetti e vengono inviati sempre in chiaro.

Un comando MAC consiste in un identificatore di comando (CID) di 1 ottetto seguito da una sequenza di ottetti eventualmente vuota specifica del comando. I CID nell’intervallo tra 0x00 e 0x7F sono riservati, mentre i CID da 0x80 a 0xFF sono disponibili per le estensioni di rete proprietarie.

Tabella 8 – Comandi MAC da 0x02 a 0x05.

La Tabella 8 e la Tabella 9 contengono l’elenco dei comandi MAC definiti nella specifica LoRaWAN 1.0.

Attivazione del dispositivo finale

Per partecipare a una rete LoRa, un dispositivo finale deve ottenere tre informazioni:

• DevAddress Indirizzo LoRa a 32 bit;
• NetSessionKey Chiave AES a 128 bit, utilizzata per l’autenticazione;
• AppSessionKey Chiave AES a 128 bit, utilizzata per la crittografia.

Tabella 9 – Comandi MAC da 0x06 a 0xFF.

A questo scopo esistono due possibili procedure di adesione: l’Attivazione via etere Over-The-Air Activation (OTA), in cui ogni dispositivo finale deve eseguire una procedura di adesione che prevede lo scambio di alcuni messaggi con l’infrastruttura del server, e l’Attivazione tramite personalizzazione Activation by Personalization, in cui i dispositivi finali conoscono già l’indirizzo e le chiavi, quindi possono bypassare la procedura di adesione.

Mentre l’attivazione tramite personalizzazione può essere banalmente implementata caricando su tutti i dispositivi finali l’indirizzo e le chiavi di sessione, l’adesione OTA richiede sia un protocollo per ottenere le informazioni dal server, sia un algoritmo per generare le chiavi di sessione.

La procedura di join consiste in due messaggi:

• Join Request, inviato dal dispositivo finale al server e contenente AppEUI, DevEUI e DevNonce;
• Join Accept, inviato dal server al dispositivo finale e contenente DevAddress, NetID e AppNonce, tutti criptati con una AppKey condivisa a lungo termine.

Se questa procedura si conclude con successo, sia il dispositivo finale che il server possono eseguire l’algoritmo di generazione della chiave per calcolare la chiave di sessione.

Caratteristiche di Classe B e Classe C

I dispositivi finali di Classe B aprono finestre di ricezione, chiamate ping slots, a intervalli di tempo prevedibili, consentendo l’invio di messaggi down-link avviati dal server, chiamati ping. Per implementare questa funzione, tutti i gateway devono trasmettere in modo sincrono un beacon. Se un dispositivo finale si sposta e rileva un beacon diverso, deve inviare un messaggio up-link per aggiornare il percorso di routing.

Tutti i dispositivi finali entrano nella rete come classe A e la decisione di passare alla classe B deve provenire dal livello applicativo del dispositivo finale. In questo caso, il livello Lo- RaWAN cerca un beacon e, se lo trova, seleziona la velocità dei dati e la periodicità dello slot di ping.

Il dispositivo finale deve trasmettere periodicamente un messaggio di uplink per aggiornare il percorso di routing nel server di rete. Se non riceve alcun beacon per un certo periodo di tempo, passa nuovamente alla classe A.

La classe C è implementata aprendo RX2 il più spesso possibile, in modo da essere continuamente in ascolto del canale. Questo porta a un protocollo inefficiente, con un consumo energetico molto elevato, non adatto a dispositivi finali alimentati a batteria. I dispositivi finali di classe C non possono implementare l’opzione di classe B.

Multicast

In modalità Classe B e Classe C i dispositivi possono ricevere anche frame multicast in downlink. L’indirizzo multicast multicast address, la NetSessionKey e la AppSessionKey devono provenire dal livello applicativo e i frame multicast non possono trasportare comandi MAC. Poiché gli ACK non sono ammessi quando si opera in modalità multicast, il tipo di messaggio LoRaWAN deve essere “Unconfirmed Data Down”.

GWMP: Gateway Message Protocol

Come già detto, ogni gateway comunica con il server di rete tramite una connessione IP standard. A seconda del server di rete e del packet forwarder installato sul gateway, possono essere utilizzati diversi protocolli applicativi.

Le specifiche LoRaWAN non richiedono uno specifico protocollo gateway-server, poiché il server deve ricevere il carico fisico completo LoRa, incapsulato nel protocollo più adatto, a seconda del caso d’uso specifico.

Tuttavia Semtech, l’azienda che ha sviluppato inizialmente la modulazione LoRa e il protocollo LoRaWAN, ha rilasciato anche un proprio protocollo gateway-server, chiamato Gateway Message Protocol (GWMP).

GWMP si basa su UDP, che lo rende un protocollo senza connessione, e utilizza il formato JSON per trasportare il frame ricevuto con le statistiche associate.

Formato del messaggio

Ogni messaggio GWMP, come mostrato nella figura 3.11, comprende tre campi obbligatori e due opzionali:

• Protocol Version: la versione del Gateway Message Protocol utilizzata;
• Token: numero scelto casualmente dal mittente per identificare univocamente il messaggio;
• Type: specifica lo scopo del messaggio. Fino alla versione 2 sono stati definiti sei tipi diversi;
• Gateway EUI: contiene l’identificatore del gateway, basato sulla specifica EUI-64. Non è presente nei messaggi con tipo di messaggio. Non è presente nei messaggi di tipo PUSH ACK o TX ACK;
• Payload: contiene una stringa formattata in JSON;

Figura 25 – GWMP packet format.

Tipi di GWMP

• PUSH DATA: utilizzato dal gateway per trasmettere al server di rete sia i frame LoRaWAN ricevuti che altre statistiche periodiche. La sua dimensione totale non deve superare i 2408 ottetti;
• PUSH ACK: viene trasmesso immediatamente dal server di rete alla ricezione di un messaggio PUSH DATA per confermarlo. Non contiene l’EUI del gateway e il payload e il token è lo stesso del PUSH DATA;
• PULL DATA: inviato periodicamente dal gateway, funge da messaggio “keep alive” che informa il server di rete dell’indirizzo e della porta UDP a cui inviare eventuali PULL RESP;
• PULL ACK: viene trasmesso immediatamente dal server di rete alla ricezione di un messaggio PULL DATA per confermarlo. Non contiene alcun payload e il token è lo stesso del PULL DATA;
• PULL RESP: contiene nell’oggetto JSON il frame LoRaWAN da trasmettere ai dispositivi finali e la sua dimensione non deve superare i 1000 ottetti;
• TX ACK: presente solo nella versione 2 del GWMP, è utilizzato dal gateway per confermare un messaggio PULL RESP.

Protocollo GWMP Json

L’oggetto Json è utilizzato per trasportare i messaggi LoRaWAN e altre informazioni. Per migliorare la compatibilità sono ammessi solo caratteri ASCII e non devono esserci spazi bianchi al di fuori del testo quotato. Inoltre, l’oggetto JSON di primo livello può contenere altri oggetti, purché rispettino la restrizione sopra descritta.

Tabella 10 – GWMP types.

Upstream transmissions

Nelle trasmissioni upstream l’oggetto Json può contenere un array di oggetti RXPK, uno per ogni messaggio LoRa trasportato, e un oggetto STAT, che riporta alcune statistiche sul gateway.

Come già detto, ogni oggetto RXPK contiene un frame LoRa catturato, codificato nel formato Base64, insieme all’ora di ricezione e alle informazioni sul canale LoRa su cui è stato rilevato (data rate, coding rate, frequenza, ecc.). In Figura 28è mostrato un esempio di un possibile oggetto RXPK.

Figura 26 – Esempio di oggetto RXPK.

L’oggetto STAT è utilizzato per informare il server di rete sullo stato del gateway. In particolare, contiene le coordinate geografiche del gateway e le statistiche sui messaggi ricevuti e inoltrati. Un esempio di oggetto STAT è riportato in Figura 29.

Figura 27 – Esempio di un oggetto STAT.

Downstream transmissions

L’oggetto TXPK è incluso nei messaggi downstream per trasportare il messaggio LoRa downlink insieme alle informazioni necessarie sui parametri, quali velocità di trasmissione dati, velocità di codifica e frequenza, da utilizzare per la trasmissione. È importante notare che i gateway, in generale, non hanno alcuna nozione del livello LoRaWAN e delle sue finestre di ricezione, quindi si affidano al timestamp incluso nell’oggetto TXPK per sincronizzarsi correttamente con le finestre di ricezione dei dispositivi finali. La Figura 30 riporta una possibile istanza di un oggetto TXPK.

Figura 28 – Esempio di oggetto TXPK.

Bibliografia

• Phui San Cheong, Johan Bergs, Chris Hawinkel, Jeroen Famaey. Com- parison of LoRaWAN Classes and their Power Consumption. DOI: 10.1109/SCVT.2017.8240313, 2017
• Usman Raza, Parag Kulkarni, and  Mahesh    Low Power Wide Area Networks: An Overview. DOI: 10.1109/COM-ST.2017.2652320, 2017
• Nb-iot: enabling new business opportunities. Hawei Technologies Co., Tech. Rep., 2015. [Online]. Available: http://www.huawei.com/minisite/4-5g/img/NB-IOT.pdf
• Sigfox’s ecosystem delivers the worlds first ultra-low cost modules to fuel the internet of things mass market deployment. [Online]. Available: https://www.sigfox.com/en/press/ sigfox-s-ecosystem-delivers-world-s- first-ultra-low-cost-modules-to-fuel-internet-of-things
• Andrey Dvornikov, Pavel Abramov, Sergey Efremov, Leonid Vo- skovQoS Metrics Measurement in Long Range IoT Networks. DOI: 10.1109/CBI.2017.2 , 2017
• Ingenu : https://www.leverege.com/blogpost/rpma-technical-drill-down-ingenus-lpwan-technology
• Berhane G. Gebremedhin, Jussi Haapola and Jari Iinatti Center for Wireless Communications. Performance Evaluation of IEEE 802.15.4k Priority Channel Access with DSSS PHY. ISBN: 978-3-8007-3976-9, 2015
• KAN ZHENG, (Senior Member, IEEE), SHAOHANG ZHAO , ZHE YANG, XIONG XIONG, AND WEI XIANG , (Senior Member, IEEE). Design and Implementation of LPWA-Based Air Quality Monitoring System. DOI: 10.1109/ACCESS.2016.2582153, 2016
• Berhane G. Gebremedhin, Jussi Haapola and Jari Iinatti Center for Wireless Communications. Feasibility Study of IEEE 802.11ah Ra- dio Technology for loT and M2M use Cases. DOI: 10.1109/GLO-COMW.2012.6477839, 2013
• [Online]. Available: http://www.weightless.org/
• Martin C. Bor, Utz Roedig, Thiemo Voigt, Juan M. Alonso. Do lora low-power wide-area networks scale? . DOI:10.1145/2988287.2989163, 2016
• Georgiou and U. Raza. Low power wide area network analysis: Can lora scale? DOI: 10.1109/LWC.2016.2647247 , 2017
• ANDRES LAYA, CHARALAMPOS KALALAS, FRANCISCO VAZQUEZ-GALLEGO, LUIS ALONSO AND JESUS ALONSO- ZARATE. Goodbye, aloha. DOI: 10.1109/ACCESS.2016.2557758 , 2016
• “Software defined Radio” . https://patents.google.com/patent/US20040242261A1/en
• Mads Lauridsen, Benny Vejlgaar, Istvan Z. Kovacs, Huan Nguyen, Preben Mogensen, Dept. of Electronic Systems, Aalborg University, Denmark Nokia Bell Labs, Aalborg. Interference measurements in the european 868 mhz ism band with focus on lora and sigfox. DOI: 10.1109/WCNC.2017.7925650, 2017
• Bandyopadhyay, Soma and Sengupta, Munmun and Maiti, Souvik and Dutta, Subhajit. Role Of Middleware For Internet Of Things. DOI: 10.5121/ijcses.2011.2307, 2011
• J. Krizman, T. E. Biedka, and S. Rappaport. Wireless Position Loca- tion: Fundamentals, Implementation Strategies, and Sources of Error. DOI: 10.1109/VETEC.1997.600463 , 2002
• Kartakis, B. D. Choudhary, A. D. Gluhak, L. Lambrinos, and J. A. McCann. Demystifying low-power wide-area communications for city iot applications. DOI: 10.1145/2980159.2980162 , 2016
• Xin Ma, Wei Luo. The analysis of 6LowPAN technology. DOI: 10.1109/PACIIA.2008.72 , 2009
• Lingling Li,  Jiuchun  Ren,  Qian      On   the   Application   of LoRa LPWAN Technology in Sailing Monitoring System. DOI: 10.1109/WONS.2017.7888762 , 2017
• Semtech’s datasheets : https://www.semtech.com/uploads/documents/sx1272.pdf
• Phui San Cheong, Johan Bergs, Chris Hawinkel, Jeroen  Famaey  ID- Lab, University of Antwerp imec, Antwerp, Belgium Nokia Bell Labs, Antwerp, Belgium. Comparison of LoRaWAN Classes and their Power Consumption. DOI: 10.1109/SCVT.2017.8240313 , 2017
• Ferran Adelantado, Xavier Vilajosana, Pere Tuset-Peiro, Borja Marti- nez, Joan  Meli`a-SeguA˜,  Thomas    Understanding  the  Limits of LoRaWAN . DOI: 10.1109/MCOM.2017.1600613 , 2017
• Emekcan Aras, Gowri Sankar Ramachandran, Piers Lawrence and Danny Hughes. Exploring the Security Vulnerabilities of LoRa. DOI: 10.1109/CYBConf.2017.7985777 , 2017
• https://www.researchgate.net/publication/322505680 What Drives the Implementation of
• Yongxin Liao, Fernando Deschamps,  Eduardo de Freitas Rocha Lou- res, Luiz Felipe Pierin Ramos. Past, present and future of Industry 4.0 – a systematic literature review and research agenda proposal. DOI: 10.1080/00207543.2017.1308576 , 2017
• Fabrizio Mazzetto, Michael Riedel, Pasqualina Sacco – Sistemi informativi aziendali e agricoltura di precisione – Edagricole 2017
• Lingling Li,  Jiuchun  Ren,  Qian      On   the   Application   of LoRa LPWAN Technology in Sailing Monitoring System. DOI: 10.1109/WONS.2017.7888762 , 2017
• William Stallings. Comunicazioni e reti wireless. Editore McGraw-Hill, ISBN 8838634327
• LPWAN White Paper: https://www.leverege.com/research- papers/lpwan-white-paper
• Chonggang Wang, Tao Jiang, Qian Zhang – Zigbee network protocol and applications. Editore CRC Press, ISBN 1439816026
• Vermesan e P. Friess, Internet of Things – From Research and Innovation to Market Deployment, River Publishers, 2014.
• Mattern e C. Floerkemeier, «From the Internet of Computers to the Internet of Things» 2010.
• The Hammersith Group, «The Internet of things: Network objects and smart devices» 2010.
• Evans, «The Internet of Things – How the Next Evolution of the Internet Is Changing Everything» Cisco, 2011.
• Nordrum, «The Internet of Fewer Things» 2016.
• 3GPP, «release 13» 2016.
• GSMA, «3GPP Low Power Wide Area Technologies» 2016.
• Nokia, «LTE Evolution for IoT connectivity» 2017.
• Technical Marketing Workgroup 1.0, «LoRaWAN What is it?» LoRa Alliance, 2015.
• Brown, «A Detailed Breakdown of LPWAN Technologies and Providers» 2016.
• Leverege, «LPWAN White Paper» 2016.
• ETSI, «Final Draft ETSI EN 300 220-1 v.2.4.1» 2012.
• Sornin, M. Luis, T. Eirich, T. Kramp e O. Hersent, «LoRaWAN Specification v.1.0.2» LoRa Alliance, 2016.
• Semtech, «AN1200.22 LoRa Modulation Basics, revisione 2» 2015.
• Wikipedia, «Hata model» Wikipedia, vol. https://en.wikipedia.org/wiki/Hata_model.
• Semtech, «SX1272/3/6/8: LoRa Modem – Designer’s Guide – AN1200.3» Semtech, 2013.
• IEEE, «IEEE Std 802.15.4™» IEEE, 2006.
• LoRa Alliance, «LoRaWAN™ 1.0.2 Regional Parameters» 2017.
• C. Bor e U. Roedig, «Do LoRa Low-Power Wide-Area Networks Scale?» Conference Paper, 2016.
• Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melià-Seguf e T. Watteyne, «Understanding the Limits of LoRaWAN» IEEE Communications Magazine, Gennaio 2017.
• Haxhibeqiri, F. Van den Abeele, I. Moerman e J. Hoebeke, «LoRa Scalability: A Simulation Model Based on Interference Measurements» Sensors – MDPI, 2017.
• Vejlgaard, M. Lauridsen e H. Nguyen, «Interference Impact on Coverage and Capacity for Low Power Wide Area IoT Networks» IEEE, 2017.
• Semtech, «SX1301 Datasheet» 2017.
• Mikhaylov, J. Petäjäjärvi e T. Hänninen, «Analysis of the Capacity and Scalability of the LoRa Wide Area Network Technology» European Wireless (EW) conference paper, 2016.
• S. Tanenbaum, Computer Networks, New Jersey: Person Education International, 2003.
• Huang, H. Li, B. Hamzeh, Y.-S. Choi, S. Mohanty e C.-Y. Hsu, «Proposal for Evaluation Methodology for 802.16p» IEEE 802.16 Broadband Wireless Access Working Group, 2011.
• IBM, «LoRaWAN in C (LMiC) Technical Specification» 2015.
• Wu, X., Xiong, Y., Li, M., Huang, W., Distributed spatial-temporal compressive data gathering for large-scale WSNs, Computing, Communications and IT Applications Conference (ComComAp), pp. 105-110, 2013.
• INFSO D.4 Networked Enterprise RFID INFSO G.2 Micro Nanosystems in Co-operation with the Working Group RFID of the ETP EPOSS, 2008.
• Semtech, AN1200.22 LoRa™ Modulation Basics, Application Note, http://www.semtech.com/images/datasheet/an1200.22.pdf
• LoRa Technology, https://www.lora-alliance.org/What-IsLoRa/Technology
• ABI Research, “Best Fit Use Cases for LPWANs,” pp. 1–16, August 2016.
• The Evolution of the Internet of Things, On-line http://www.ti.com/lit/ml/swrb028/swrb028.pdf.
• The Things Network Documentation, https://www.thethingsnetwork.org/docs/
• Bankov, E. Khorov, and A. Lyakhov, “On the Limits of LoRaWAN Channel Access,” in 2016 International Conference on Engineering and Telecommunication, Moscow, Russia, November 2016, pp. 10–14.
• LoRa Alliance Technical Marketing Workgroup , “A technical overview of LoRa and LoRaWAN,” November, 2015.
• Wixted, P. Kinnaird, A. Tait, A. Ahmadinia, and N. Strachan, “Evaluation of LoRa and LoRaWAN for Wireless Sensor Networks,” in 2016 IEEE SENSORS, October 2016, pp. 1–3.
• Bor, J. Vidler, and U. Roedig, “LoRa for the Internet of Things,” in Proceedings of the 2016 International Conference on Embedded Wireless Systems and Networks, Graz, Austria, February 2016, pp. 361– 366.
• Reynders and S. Pollin, “Chirp Spread Spectrum as a Modulation Technique for Long Range Communication,” in 2016 Symposium on Communications and Vehicular Technologies (SCVT), Mons, Belgium, November 2016, pp. 1–5.
• Semtech, “LoRa Modulation Basics,” pp. 1–26, May 2015.
• C. Bor, U. Roedig, T. Voigt, and J. M. Alonso, “Do LoRa LowPower Wide-Area Networks Scale?” in Proceedings of the 19th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems, Malta, Malta, November 2016, pp. 59–67.
• Mikhaylov, J. Petaj¨ aj¨ arvi, and T. H ¨ anninen, “Analysis of Capacity and ¨ Scalability of the LoRa Low Power Wide Area Network Technology,” European Wireless 2016, pp. 119–124, 2016.
• Semtech, “SX1272/3/6/7/8: LoRa Modem Designer’s Guide,” pp. 1–9, July 2013, AN1200.13.
• Neumann, J. Montavont, and T. Noel, “Indoor Deployment of Low- ¨ Power Wide Area Networks (LPWAN): a LoRaWAN case study,” in 2016 IEEE 12th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), New York, NY, USA, October 2016, pp. 1–8.
• Sornin, M. Luis, T. Eirich, T. Kramp, and O. Hersent, “LoRaWAN TM Specification,” pp. 1–70, July 2016, V1.0.2.
• Aref and A. Sikora, “Free space range measurements with Semtech LoRaTM technology,” in 2014 2nd International Symposium on Wireless Systems within the Conferences on Intelligent Data Acquisition and Advanced Computing Systems, IDAACS- SWS 2014, Offenburg, Germany, September 2014, pp. 19–23.
• Augustin, J. Yi, T. Clausen, and W. Townsley, “A Study of LoRa: Long Range & Low Power Networks for the Internet of Things,” Sensors, vol. 16, no. 9, 2016.
• LoRa Alliance Technical comittee, “LoRaWAN Regional Parameters,” July 2016, V1.0.
• https://www.lairdconnect.com/documentation/quick-start-guide-sentrius-rg1xx-v30
• https://www.st.com/resource/en/application_note/dm00658170-stevalstrkt01-power- management-architecture-description-and-configuration-for-optimized-battery-life- stmicroelectronics.pdf
• https://www.st.com/resource/en/user_manual/dm00595064-getting-started-with-the- stevalstrkt01-lora-iot-tracker-stmicroelectronics.pdf
• https://www.thethingsnetwork.org/article/the-things-network-architecture-1
• https://www.thethingsnetwork.org/docs/network/architecture.html
• Semtech Corporation. LoRa Modulation Basics. Accessed: Nov. 3, 2018. [Online]. Available: https://www.semtech.com/uploads/ documents/an1200.22.pdf
• Short Range Devices (SRD) Operating in the Frequency Range 25 MHz to 1000 MHz | Part 1: Technical Characteristics and Methods of Measurement. 75p. Accessed: Aug. 31, 2018. Available: https://www.etsi. org/deliver/etsi_en/300200_300299/30022001/03.01.01_30/en_ 30022001v030101v.pdf
• Augustin, J. Yi, T. Clausen, and W. M. Townsley, “A study of LoRa: Long range & low power networks for the Internet of Things,” Sensors, vol. 16, no. 9, p. 1466, 2016.
• https://ieeexplore.ieee.org/document/8648485
• https://ieeexplore.ieee.org/document/8515030
• https://www.research- collection.ethz.ch/bitstream/handle/20.500.11850/348400/3/08703036.pdf
• https://ieeexplore.ieee.org/document/8034915
• https://ieeexplore.ieee.org/document/8095703
• https://tutcris.tut.fi/portal/files/15822869/cts_05_4807.pdf
• https://ieeexplore.ieee.org/document/8553767
• Estimation in the bernoulli model. http://www.math.uah.edu/stat/ interval/Bernoulli.html.
• Ferran Adelantado, Xavier Vilajosana, Pere Tuset-Peir´o, Borja Mart´ınez, and Joan   Meli`a.       Understanding   the   limits   of          CoRR, abs/1607.08011, 2016.
• Aref and A. Sikora. Free space range measurements with semtech lora technology. In Wireless Systems within the Conferences on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Ap- plications (IDAACS-SWS), 2014 2nd International Symposium on, pages 19–23, Sept 2014.
• Marco Centenaro, Lorenzo Vangelista, Andrea Zanella, and Michele Zorzi. Long-range communications in unlicensed bands: the rising stars in the iot and smart city scenarios. Oct 2015.
• Petajajarvi, K. Mikhaylov, A. Roivainen, T. Hanninen, and M. Pet- tissalo. On the coverage of lpwans: range evaluation and channel atten- uation model for lora technology. In ITS Telecommunications (ITST), 2015 14th International Conference on, pages 55–59, Dec 2015.
• Pham. Deploying a pool of long-range wireless image sensor with shared activity time. In Wireless and Mobile Computing, Networking and Communications (WiMob), 2015 IEEE 11th International Conference on, pages 667–674, Oct 2015.
• Libelium Comunicaciones Distribuidas S.L. Waspmote lorawan network- ing guide. http://www.libelium.com/downloads/documentation/ waspmote-lorawan-networking-guide.pdf, May 2016.
• Sornin, M. Luis, T. Eirich, T. Kramp, and O. Hersent. Lorawan specification. Technical report, LoRa Alliance, 2015.
• Wendt, F. Volk, and E. Mackensen. A benchmark survey of long range (loratm) spread-spectrum-communication at 2.45 ghz for safety applica- tions. In Wireless and Microwave Technology Conference (WAMICON), 2015 IEEE 16th Annual, pages 1–4, April 2015.