IoT: LoRaWAN relay mode – Digital4Pro

IoT: LoRaWAN relay mode

AI: L’impatto sull’organizzazione dell’impresa e sui posti di lavoro
23 Settembre 2025

Introduzione

Le reti LoRaWAN sono tipicamente disposte in una topologia a stella, in cui i dispositivi finali comunicano direttamente con uno o più gateway, ma ci sono molti casi in cui potrebbe essere utile avere un nodo speciale in grado di agire da relay tra i dispositivi finali e il gateway.

In questo articolo viene definita un’estensione del protocollo LoRaWAN che consente ai dispositivi finali di scoprire e di legarsi a qualsiasi nodo idoneo al relay nelle vicinanze.

 

Perché il relay mode

Il protocollo LoRaWAN è stato progettato per essere distribuito in una disposizione a stella, in cui tutti i dispositivi finali necessitano di una sola comunicazione LoRa per raggiungere la rete IP.

Questa architettura, ovviamente, semplifica notevolmente il protocollo, eliminando la necessità di meccanismi di routing, ma, d’altro canto, richiede l’installazione di nuovi gateway per espandere l’area di copertura della rete. I gateway LoRa standard, in generale, richiedono una connessione IP per operare come descritto nelle specifiche, e in alcuni contesti (ad esempio aree rurali senza copertura cellulare) potrebbe essere un requisito impossibile da soddisfare.

Al contrario, la soluzione proposta in questa sede permette di estendere l’area di copertura senza bisogno di gateway e, allo stesso tempo, di aumentare le prestazioni dei dispositivi finali a parità di copertura.

 

Figura 1 – Architettura di riferimento della modalità relay.

 

Panoramica del protocollo

Il principale ostacolo alla progettazione di una soluzione di relay in una rete LoRaWAN è che i dispositivi finali che fungeranno da relay hanno spesso una sola interfaccia LoRa e i ricetrasmettitori installati su questi dispositivi non sono in grado di aprire finestre di ricezione contemporaneamente su tutte le possibili frequenze, velocità di trasmissione dati e velocità di codifica.

Per progettare un protocollo che possa essere implementato su questo tipo di dispositivi finali, si è deciso di aggiungere una tecnica TDMA alle specifiche standard. L’idea chiave è che ogni nodo idoneo al relay Relay Eligible Node deve inviare periodicamente un beacon per annunciarsi ai dispositivi finali vicini. L’intervallo di tempo tra due beacon inviati dallo stesso nodo relay è chiamato Beacon Period. Ogni periodo beacon è suddiviso in due fasi diverse:

  • Bind Phase, in cui i dispositivi finali cercano di legarsi al nodo relay;
  • Transmission Phase, in cui i dispositivi finali inviano dati a monte al relay e ricevono dati a valle.

Figura 2 – Diagramma temporale del protocollo.

 

La fase di trasmissione è ulteriormente suddivisa in diversi slot, numerati a partire da zero, in modo da permettere al nodo relay di svegliarsi solo quando necessario, cioè solo in prossimità degli slot legati ai dispositivi finali. In ogni slot solo un dispositivo finale è autorizzato a scambiare dati e ogni dispositivo finale può trasmettere solo in uno slot per periodo di beacon. Lo slot all’interno del periodo di beacon viene assegnato al dispositivo finale dal server di rete nella fase di bind. Uno slot è riservato alle risposte di bind e non viene mai assegnato ai dispositivi.

I beacon e tutti i messaggi di bind vengono inviati utilizzando parametri ben noti (velocità di trasmissione dati, velocità di codifica, frequenza), definiti in questa specifica. Le altre comunicazioni vengono effettuate utilizzando parametri che devono essere scambiati nella fase di bind.

L’obiettivo di questo protocollo è estendere LoRaWAN senza cambiarne radicalmente la filosofia, per cui ogni decisione viene presa dal server di rete, che configura sia i relè che i dispositivi finali tramite comandi MAC.

 

Requisiti

Sebbene la natura molto centralizzata di LoRaWAN sia mantenuta con la nuova modalità relay, ciò non è trasparente per i dispositivi esistenti, che devono essere adattati per supportare il nuovo protocollo. In particolare:

  • I dispositivi finali devono passare esplicitamente alla modalità relay;
  • Il nodo relay deve passare esplicitamente alla modalità relay, pubblicizzando la sua presenza ai vicini e scambiando tutti i parametri necessari con il server di rete;
  • Il server di rete deve essere aggiornato per supportare la nuova modalità;
  • I dispositivi finali e il relay devono appartenere alla stessa rete, in modo da essere gestiti dallo stesso server di rete;

D’altra parte, i gateway LoRa esistenti supportano già la nuova modalità relay perché non interagiscono con il livello LoRaWAN. Inoltre, i dispositivi finali LoRaWAN standard esistenti non sono interessati dal comportamento dei dispositivi aggiornati.

 

Specifica

Questa specifica include il formato di tutti i nuovi massaggi definiti e la descrizione dei vincoli temporali. Può essere logicamente suddivisa in tre parti:

  • Relay eligible node management: definisce tutti i messaggi scambiati tra il relè e il server di rete;
  • End-device binding: definisce tutti i messaggi scambiati per legare (e slegare) efficacemente i dispositivi finali al relè;
  • Data transmission: definisce il protocollo da adottare quando un dispositivo finale vuole trasmettere dati a monte e ricevere dati a valle, se presenti.

 

Gestione dei nodi ammissibili al relay

 

Impostazione del relay

Prima di iniziare a pubblicizzarsi, ogni nodo idoneo al relay deve inviare al server di rete un comando MAC RelaySetupReq, contenente i requisiti minimi per i parametri della sessione di relay.

 

Size (bytes) 2 1 1
Content MinBeaconPeriod MinTslot MaxSlots

Figura 3 – RelaySetupReq MAC command.

 

In particolare, MinBeaconPeriod contiene la lunghezza minima del Bea- con Period espressa in secondi; MinTslot contiene la lunghezza minima dello slot espressa in secondi; MaxSlots contiene il numero massimo di slot per BeaconPeriod che il dispositivo è in grado di gestire.

Il nodo relay non può pubblicizzarsi finché non riceve i parametri dal server di rete tramite il comando RelaySetupAns MAC.

 

Size (bytes) 1 0/2 0/1 0/1
Content SetupAns BeaconPeriod TSlot MaxSlots

Figura 4 – RelaySetupReq MAC command.

 

In particolare, se SetupAns è uguale a 0x00 il dispositivo viene accettato, e questo campo è seguito dai parametri obbligatori da adottare. Il BeaconPeriod e la lunghezza dello slot TSlot sono espressi in secondi. MaxSlots è il numero di slot disponibili.

Se SetupAns non è uguale a 0x00, il dispositivo non è stato accettato dal server di rete come relè e non è seguito da altri campi.

 

Relay status

Il relè può richiedere al server di rete l’elenco dei dispositivi finali ad esso collegati. In risposta riceverà le modifiche all’elenco dei dispositivi finali serviti rispetto all’ultima richiesta. Il RelayStatusReq non ha alcun payload, il RelayStatusAns ha il formato della Figura 5 e ogni DeviceEntry è codificato come nella Figura 7.

 

Size (bytes) 1 5/14 5/14 5/14
Content DeviceControl Dev entry Dev entry Dev entry

Figura 5 – RelayStatusAns MAC command.

 

Il campo DeviceControl (Figura 6) contiene il flag ClearList e il numero di dispositivi (DeviceNum) contenuti nell’elenco seguente. Quando il flag ClearList è impostato, il dispositivo finale deve svuotare il suo elenco corrente prima di aggiornarlo con le nuove informazioni contenute in questo comando MAC. RelayStatusAns può contenere tante voci di dispositivo quante ne entrano nel pacchetto, con un limite superiore di 63. Ogni voce di dispositivo contiene l’indirizzo (DevAddr) e lo Stato del dispositivo, che ha il formato descritto nella Figura 8.

 

Size (bits) 1 1 6
Content ClearList RFU DeviceNum

Figura 6 – DeviceControl field in the RelayStatusAns MAC command.

 

Size (bytes) 4 1 0/3 0/3 0/3
Content DevAddr Status Freq 1 Freq 2 Freq 3

Figura 7 – Device entry contained in RelayStatusAns MAC command.

 

Size (bits) 1 3 4
Content Add/Remove RFU DataRate

Figura 8 – Status fiend within each device entry.

 

Se il flag Add/Remove è impostato, il relay deve deallocare lo slot per il dispositivo finale. Altrimenti, se il flag Add/Remove non è impostato, il campo DataRate trasporta la velocità dati a cui il dispositivo finale trasmetterà i suoi messaggi e il campo Status è seguito da 9 ottetti che trasportano le tre frequenze su cui il dispositivo finale trasmetterà.

 

Relay stop

Il server di rete può arrestare un nodo relay utilizzando il comando RelayStopReq MAC. Quando il nodo relay riceve il comando RelayStopReq, deve arrestare immediatamente ogni attività relay, quindi il server di rete non si aspetta alcuna risposta. Questo comando non ha alcun payload.

 

End-device binding

Per associarsi a un nodo relay, il dispositivo finale inizia ad ascoltare il canale radio, in attesa di un beacon. Se il dispositivo finale riceve un beacon da un nodo relay, può decidere di associarsi a esso inviando un comando RelayBindReq oppure di scartare il beacon e iniziare ad attenderne uno nuovo.

 

Figura 9 – Sequence diagram of the end-device binding.

 

Parameter Value
Data Rate SF9 BW125
Coding Rate 4/5
Frequency 869.525 MHz
Period BEACON PERIOD

Tabella 1 – Transmission parameters of the beacon.

 

Broadcasting Beacons

Per pubblicizzare la propria presenza ai vicini, il nodo relay invia periodicamente un beacon contenente tutte le informazioni necessarie ai dispositivi finali per impostare una sessione con esso. Il beacon deve essere inviato con i parametri riportati nella Tabella 1.

 

Size (bytes) 4 4 3 2 1
Content Timestamp RelayAddr NetID BindAnsDelay Control

Figura 10 – Beacon format.

 

Relay deve includere nel beacon il suo indirizzo (RelayAddr) e l’ID della rete (NetID) a cui appartiene, per consentire al dispositivo finale di selezionare solo relay appartenenti alla propria rete. Il NetID ha il formato descritto nelle specifiche LoRaWAN. Il campo Timestamp contiene il timestamp interno del nodo relay, utilizzando l’unità di misura dei millisecondi. Il campo Control contiene i flag RFU.

 

RelayBindReq

La richiesta di bind deve essere inviata solo nello slot di bind, e esattamente RX DELAY secondi dopo la fine della trasmissione del beacon. La richiesta di bind deve essere eseguita utilizzando il comando MAC RelayBindReq, che ha il formato mostrato nella Figura 11.

 

Size(bytes) 4 1 3 3 3
Content RelayAddress Data Rate Chan 1 Chan 2 Chan 3

Figura 11 – RelayBindReq MAC command.

 

Questi parametri vengono utilizzati dal relay per aprire la finestra di ricezione all’inizio dello slot di trasmissione. Ogni campo Chan contiene la frequenza centrale del canale, espressa in Hertz e divisa per 100. Ad esempio, se la frequenza centrale del canale è 868300000 Hz, il campo Chan corrispondente in RelayBindReq conterrà il numero 8683000.

Il campo DataRate è codificato come mostrato nella Figura 12.

 

Size(bytes) 4 4
Content RFU Data Rate

Figura 12 – DataRate field into RelayBindReq MAC command.

 

RelayBindAns

Il server di rete deve rispondere a un RelayBindReq con un comando RelayBindAns MAC, che ha il formato mostrato nella Figura 13.

 

Size (bytes) 4 1 2 1 2
Content RelayAddr SlotIndex BeaconPeriod TSlot MaxSlots

Figura 13 – RelayBindAns MAC command.

 

Il destinatario di un comando RelayBindAns MAC è il dispositivo finale che ha inviato RelayBindReq. ​​Il server di rete deve includere nel comando RelayBindAns MAC le seguenti informazioni:

  • RelayAddr l’indirizzo del relay;
  • SlotIndex indice dello slot temporale assegnato al dispositivo;
  • BeaconPeriod intervallo di tempo tra due beacon, espresso in secondi;
  • TSlot lunghezza dello slot temporale, espressa in secondi;
  • MaxSlots numero di slot entro un periodo di beacon.

Il dispositivo finale riceverà il comando RelayBindAns MAC nello slot BindAns, che viene pubblicizzato all’interno del beacon tramite il campo BindAnsDelay. Se il comando RelayBindAns MAC non viene ricevuto nel primo slot BindAns disponibile, il RelayBindReq originale deve essere considerato perso e il dispositivo finale deve eseguire una nuova richiesta di associazione.

 

RelayUnbindReq

Il dispositivo finale può esplicitamente scollegarsi dal suo relay inviando un comando MAC RelayUnbindReq al server di rete, che reagisce de-allocando lo slot di tempo riservato al dispositivo finale a partire dal successivo periodo di beacon. RelayUnbindReq contiene solo l’identificativo del comando senza parametri.

 

Figura 14 – Sequence diagram of the end-device unbinding.

Il server di rete può anche rilevare autonomamente lo scollegamento del dispositivo finale, considerando il dispositivo scollegato dopo MAX EMPTY SLOTS slot senza ricevere dati dal dispositivo finale. Quindi, per mantenere attiva la sessione, il dispositivo finale deve inviare un messaggio upstream almeno ogni MAX EMPTY SLOTS / 2 slot.

 

Figura 15 – Sequence diagram of the data transmission.

 

Il dispositivo finale può utilizzare il comando MAC LinkCheckReq per rilevare lo scollegamento. Se dopo MAX LINK CHECK REQUESTS il dispositivo finale non riceve alcun LinkCheckAns, si considera scollegato.

 

Data transmission

A ciascun client è consentito inviare messaggi upstream solo all’interno del proprio slot, utilizzando i parametri del canale concordati in precedenza.

 

Comunicazione tra end-device e relay

Channel  selection: Durante la fase di associazione, il nodo client deve includere nel comando RelayBindReq tre definizioni di canale da utilizzare nella fase di trasmissione. Sia il client che il relay devono scorrere l’elenco dei canali nell’ordine in cui sono definiti in RelayBindReq, quindi al primo slot disponibile dopo l’associazione entrambi i dispositivi devono utilizzare il primo canale definito, quindi devono scorrere l’elenco dei canali.

Message type: Ogni dispositivo finale che opera in modalità relay deve contrassegnare i propri messaggi per consentire al server di rete di distinguere tra messaggi inviati direttamente e quelli inoltrati. Ciò può essere fatto introducendo un nuovo tipo di messaggio denominato Mesh Unconfirmed Data Up (tipo 110). Tutti i messaggi upstream inviati da un dispositivo finale avranno il tipo Mesh Unconfirmed Data Up e non saranno riconosciuti dal server di rete. Quando un server di rete riceve un messaggio Mesh Unconfirmed Data Up, dovrebbe scartare tutte le statistiche raccolte dal gateway (ad esempio RSSI) perché il dispositivo che ha trasmesso il messaggio al gateway, ovvero il relay, non è il dispositivo indicato nel campo DevAddress, ovvero il dispositivo finale.

 

Comunicazione tra relay e gateway

La comunicazione tra il nodo relay e il gateway segue la specifica LoRaWAN 1.0, fatta eccezione per il fatto che tutti i messaggi upstream hanno il nuovo tipo di messaggio Mesh Unconfirmed Data Up. Dato che il relay inoltra esattamente il messaggio LoRaWAN che ha ricevuto, può ricevere una risposta dal server di rete che avrà ClientAddr come DestAddr. Il nodo relay deve memorizzare il messaggio fino alla successiva trasmissione dal dispositivo finale, quindi deve inoltrarlo.

 

Comandi e parametri MAC

Come già affermato, tutte le informazioni di configurazione tra dispositivi finali, relay e server di rete vengono scambiate tramite comandi MAC. I nuovi comandi MAC definiti in questo protocollo sono riepilogati nella Tabella 18.

 

CID Command Transmitted by Description
ED Relay NS
0x80 RelaySetupReq x Requests parameters to start acting as a relay, attaching the minimum requirements
0x81 RelaySetupAns x Answer to RelaySetupReq, with the requested parameters
0x82 RelayStatusReq x Requests the network server to send changes on bound end-devices
0x83 RelayStatusAns x List of new end-devices or “clear list” command
0x84 RelayStopReq x Requests the relay to stop
0x85 RelayBindReq x Requests to bind to a relay
0x86 RelayBindAns x Answer to RelayBindReq
0x87 RelayUnbindReq x Notifies the network server the unbinding of an end-device

Tabella 18 – MAC commends.

 

Il valore di ogni parametro non è fissato nella specifica, ma può essere determinato durante l’installazione in base al caso d’uso. Nella Tabella 19 ci sono alcuni parametri testati.

 

Constant Value
BEACON PERIOD 300 s
RX DELAY 1 s
MAX LINK CHECK REQUESTS 10
MAX EMPTY SLOTS 20
T BIND 30 s
T SLOT 10 s
MAX SLOTS 28

Tabella 19 – Parameters.

 

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.

Condividi su:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *