TTN e la politica di accesso Equo

La politica di accesso equo di TTN limita i dati che ciascun dispositivo può inviare, consentendo:

  • Una media di 30 secondi di messaggi in uplink al giorno, per ciascun dispositivo.
  • Massimo 10 messaggi in downlink al giorno, inclusi gli ACK per i messaggi di uplink con richiesta di conferma.

Un buon obiettivo consiste nel mantenere il payload dell’applicazione sotto i 12 byte e l’intervallo tra i messaggi di almeno alcuni minuti.

 

Sono da applicare anche le seguenti norme:

 

LoRaWAN velocità dati e dimensioni dei pacchetti

La velocità di trasmissione e la dimensione massima del pacchetto dipendono dalla distanza dal gateway più vicino e dal tipo di dati da inviare e sono definiti anche nella specifica di ciascuna regione. Per la fascia europea 863-870MHz, la dimensione del payload dell’applicazione varia tra 51 byte per la velocità di trasmissione più lenta e 222 byte per quella più rapida. Va tenuto in considerazione inoltre che il protocollo LoRaWAN aggiunge almeno altri 13 byte al payload dell’applicazione.

Non è consentito l’accesso alla rete a dispositivi con velocità dati fisse in SF12 o SF11.

 

LoRaWAN i cicli di lavoro e i tempi di attesa

Per evitare la congestione della rete, LoRaWAN definisce i cicli massimi di trasmissione  (duty cycle) e i tempi di trasmissione massimi (tempi di attesa). Questi dipendono da molti fattori, tra cui la regione e il tipo di operazione (come l’invio di dati o la trasmissione di una richiesta di accesso a una rete).

Per la banda europea ISM di 863-870MHz, la specifica limita il ciclo di lavoro all’1% per i dati:

LoRaWAN applica una limitazione del duty-cycle a livello di sottobanda. Ogni volta che un frame viene trasmesso in una data sottobanda, vengono registrati i tempi di emissione e la durata della trasmissione (time on air) per questa sottobanda. La stessa sottobanda non può essere utilizzata nuovamente durante i secondi di Toff successivi dove:

Toff[sottobanda] = (TimeOnAir / DutyCycle[sottobanda]) - TimeOnAir

Durante il tempo non disponibile di una data banda secondaria, il dispositivo potrebbe ancora essere in grado di trasmettere su un'altra sottobanda. Se non ci sono più sottobande disponibili, il dispositivo deve aspettare prima di procedere con una ulteriore trasmissione. Il dispositivo adatta la sequenza di salto del canale in base alla disponibilità della sottobanda.

Esempio: si prenda in considerazione un dispositivo che ha trasmesso solo un frame lungo 0,5 secondi su un canale predefinito. Se questo canale è in una sottobanda che consente un ciclo di lavoro (duty cycle) del 1%, l'intera sottobanda (868 - 868,6) non sarà disponibile al dispositivo per 49,5 secondi.

Nelle altre regioni si applicano limitazioni molto simili.

 

Perché?

In una rete aperta con diversi dispositivi finali (nodi) che non sono connessi tra loro, che iniziano l’invio quando lo necessitano (protocollo ALOHA) , hanno bisogno di dati differenti e differenti qualità di connessione, ci sono molti fattori limitanti da tenere in considerazione affinché tutto funzioni. Quando un dispositivo (nodo) è lontano dai gateway, è necessario utilizzare una velocità di trasmissione bassa per assicurare la ricezione dei dati ad almeno un gateway. Ma una velocità di trasmissione bassa implica un tempo di trasmissione (time on air) più lungo per ogni singolo byte. Ciò limita la dimensione massima del pacchetto, per garantire agli altri dispositivi finali un tempo di utilizzo della rete equo. Se la trasmissione dura più a lungo, il dispositivo dovrà ridurre la frequenza degli invii.

Il limite di uplink nella politica di accesso equo di TTN si basa su quanto segue:

  • 8 frequenze
  • 5% per il ciclo di lavoro in ricezione  sul gateway
  • 86.400 secondi in un giorno
  • 1.000 nodi

Oppure: (8 × 86.400 × 0.05) / 1.000 che equivale a circa 30 secondi per nodo al giorno.

Da The Things Network 2016 Update

Politica di accesso equo: in pratica

- Regola d'oro: 30 secondi di tempo trasmissione per dispositivo al giorno
- Per 10 byte di payload, si traduce in (circa):
* 20 messaggi al giorno a SF12
* 500 messaggi al giorno a SF7
* Di più per SF7BW250 e FSK (area locale)
- Se la tua applicazione richiede maggiore larghezza di banda, pensa ad un'altra soluzione diversa da LoRaWAN
- Questi limiti consentono una capacità di oltre 1000 nodi per singolo gateway
- La larghezza di banda per il downlink è ancora più limitata
* Non puoi inviare tutti i messaggi di uplink con richiesta di conferma
Esempi

Considerando un gateway europeo, un payload di applicazione di 55 byte (al massimo 222 byte) potrebbe richiedere 71,81 millisecondi quando si utilizza la velocità massima di trasmissione dati. Ciò implica che il dispositivo finale (nodo) deve aspettare solo 7,109 millisecondi prima di tentare di utilizzare nuovamente la stessa sottobanda, limitata dalla regola del ciclo di lavoro LoRaWAN all’1% (altre sottobande potrebbero essere disponibili). Tuttavia, data la politica di accesso equo di TTN di 30 secondi, il dispositivo è anche limitato all’invio di soli 417 pacchetti di 71,81 ms al giorno. Quindi, mentre può inviare un altro pacchetto dopo aver aspettato 7,1 secondi, in media può inviare solo una volta ogni 3,5 minuti.

Se si è molto più lontani da un gateway, inviando un payload di applicazione di 55 byte utilizzando la velocità più bassa di trasmissione dati questo può richiedere fino a 36 volte di tempo in più, 2.629,63 millisecondi. Quindi il dispositivo deve attendere 4.4 minuti prima di tentare di inviare un altro pacchetto (nella stessa sottobanda). Ma può anche inviare solo 11 pacchetti al giorno, in media meno di una volta ogni 2 ore.

Limitando il carico utile dell’applicazione a soli 8 byte (che avranno comunque bisogno di almeno ulteriori 13 byte per il protocollo LoRaWAN) riduce i tempi di “time on air” sopra indicati a 30,85 e 1,318,91 millisecondi. Questa riduzione del payload consente una quantità doppia di pacchetti al giorno, rispettando sempre la politica di accesso equo di TTN.

 

Fonti:

arjanvanb, moderatore del forum di The Things Network.

Understanding the Limits of LoRaWAN

Commenti

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. Nome ed email sono obbligatori