La maggior parte dei confronti tra gateway BLE inizia con dati essenziali: portata, larghezza di banda, consumo energetico e costo.

Ma le implementazioni sul campo raramente falliscono perché qualcuno ha frainteso una tabella in una brochure. Falliscono perché il gateway esegue scansioni troppo frequenti. Oppure perché un piccolo payload BLE è diventato 15 record beacon per uplink. Oppure perché il segnale cellulare sembrava buono su un telefono, ma poi è collassato all'interno di un contenitore metallico. Oppure perché il cliente si aspettava allarmi in tempo reale da un profilo di consumo energetico progettato per un consumo ridotto.

Questo è il modo più utile per confrontare il backhaul del gateway BLE. La domanda da porsi, invece di "quale radio è la migliore?", è: Quale percorso di backhaul si guasta meno gravemente quando il sito diventa inutilizzabile?

In Lansitec, questa domanda è importante perché Gateway Bluetooth sedersi all'incrocio disordinato della raccolta BLE locale e della connettività ad ampia area. Un beacon BLE può pubblicizzare UUID, principale, secondario, RSSI, dati dei sensori, eventi di panico, temperatura, movimento e altro ancora. Il gateway deve quindi decidere cosa inoltrare, con quale frequenza inoltrarlo e su quale rete trasmetterlo.

Lansitec supporta questa soluzione attraverso diverse famiglie di servizi di backhaul: LoRaWAN, NB-IoT/LTE-M e Cat-1. La scelta giusta dipende meno dalla teoria radio e più dalla realtà dell'installazione.

Parliamo di cosa si rompe effettivamente.

Innanzitutto, cosa fa esattamente il gateway BLE?

In un'implementazione in stile B-Mobile, fari Bluetooth sono attaccati ai beni o indossati dalle persone. Gateway Bluetooth si trova in una posizione fissa, riceve i messaggi beacon nelle vicinanze, ristruttura i dati e li inoltra attraverso una rete di backhaul al server o all'applicazione. Nel sistema Lansitec LoRaWAN Architettura B-Mobile, ovvero BLE al gateway, gateway al LoRaWAN Il segnale passa attraverso il gateway, quindi prosegue tramite 4G o Ethernet fino al server di rete e all'applicazione.

Nella versione NB-IoT/LTE-M, il gateway salta la parte locale LoRaWAN l'infrastruttura e inoltra i dati BLE ristrutturati direttamente attraverso la rete cellulare dell'operatore a un server MQTT o HTTP.

Il gateway deve bilanciare cinque elementi:

1. Finestra di scansione BLE
2. intervallo del rapporto di backhaul
3. dimensione del carico utile
4. bilancio energetico
5. Ripristino dell'interruzione

Se si commette un errore, il sistema potrebbe comunque funzionare durante la fase dimostrativa. Semplicemente, dopo l'implementazione, diventa costoso, lento, rumoroso o richiede una manutenzione complessa.

Modalità di guasto 1: il budget di potenza è stato calcolato per la radio, non per il lavoro

La potenza di backhaul non dipende solo dal modulo radio.

È il ritmo costante del gateway: si attiva, esegue la scansione BLE, filtra i dati, trasmette, attende la conferma (ove applicabile), riprova se necessario, torna in modalità di sospensione. Un gateway che esegue scansioni continue e invia report frequentemente sta svolgendo due operazioni dispendiose in termini di risorse contemporaneamente.

È proprio lì che molti progetti falliscono.

LoRaWAN: efficace quando i report sono piccoli e disciplinati

LoRaWAN è notoriamente frugale, ma solo se si rispetta il modello di carico utile e di tempo di trasmissione. Funziona bene quando il gateway invia eventi compatti: ID beacon, RSSI, ID del gateway, timestamp e byte del sensore selezionato.

Lansitec LoRaWAN Macro Gateway Bluetooth è un buon esempio della filosofia di progettazione che privilegia la batteria. Utilizza due batterie Li-SoCl2 da 19.000 mAh e elenca 83 mesi di attività con un intervallo di segnalazione di 5 minuti. La stessa famiglia di prodotti supporta il filtraggio configurabile del payload Bluetooth, quindi il gateway non ha bisogno di inoltrare ogni byte che riceve.

Questo è il punto. LoRaWAN Le prestazioni sono ottimali quando il sistema si comporta come un sistema di segnalazione di eventi, non come un sistema di streaming di pacchetti BLE grezzi.

NB-IoT/LTE-M: bassa potenza, ma il comportamento dell'operatore è importante

NB-IoT e LTE-M sono progettati per l'IoT cellulare, ma non si comportano allo stesso modo.

NB-IoT è ideale per dispositivi statici, payload ridotti, finestre di inattività prolungate e copertura indoor capillare. LTE-M è più indicato quando il dispositivo è in movimento, richiede un downlink più reattivo o deve supportare aggiornamenti firmware pratici. Le linee guida GSMA per l'IoT mobile considerano NB-IoT e LTE-M tecnologie LPWA complementari, con LTE-M generalmente più adatto alla mobilità e a casi d'uso più interattivi, mentre NB-IoT è tipicamente utilizzato per messaggi di piccole dimensioni, poco frequenti e con copertura estesa. ⁽¹⁾

Il problema è che la potenza della rete cellulare è fortemente influenzata dalla qualità del segnale. Un gateway in una zona con scarsa copertura potrebbe consumare più energia per connettersi, ritentare la connessione o mantenere attivo il modem. Sulla carta, il modello a batteria sembra perfetto. In pratica, però, non lo è.

Abbiamo visto clienti dare per scontato che la connettività cellulare sia sinonimo di prevedibilità. Non è così. È sinonimo di connettività basata su spettro concesso in licenza e supportata da un operatore, il che è diverso.

Cat-1: non è LPWAN, ma a volte è operativamente più pulito

La categoria 1 non è l'opzione a bassa potenza. Diciamolo chiaramente.

Ma presenta un vantaggio diverso: si comporta in modo più simile al normale LTE. Offre maggiore capacità di carico utile, latenza inferiore, comunicazione IP più semplice e flussi di lavoro di configurazione e firmware più flessibili. Quectel posiziona LTE Cat-1 bis come una via di mezzo tra LPWA e le categorie LTE superiori, con maggiore mobilità, latenza inferiore e larghezza di banda superiore rispetto a NB-IoT/LTE-M, evitando al contempo la complessità dei moduli LTE di categoria superiore. ⁽²⁾

Per BLE portali, il che può essere utile. Non perché Cat-1 sia magicamente efficiente, ma perché una sessione breve e di successo può essere meglio di una lenta e instabile quando l'applicazione è "loquace".

Lansitec Gateway Bluetooth macro Cat-1 mostra come appare in un prodotto gateway: backhaul Cat-1, filtraggio BLE, compressione dati Bluetooth e un elenco Durata della batteria di 5 anni a 5 s Ricezione Bluetooth durata e intervallo di segnalazione di 240 secondi.

Quel numero ha senso solo perché il gateway non tratta la connessione Cat-1 come una connessione continua. Continua a utilizzare le procedure di gestione del ciclo di lavoro, filtraggio e segnalazione.

Regola di campo

• Se il gateway esegue scansioni continue, segnalate gli eventi con parsimonia.
• Se genera report frequentemente, esegui una scansione intelligente.
• Se fa entrambe le cose in modo aggressivo, la batteria diventa il programma di manutenzione.

Modalità di errore 2: la copertura è stata trattata come una mappa, non come un comportamento del sito.

Le mappe di copertura sono rassicuranti. Gli edifici, invece, non lo sono.

Un telefono che mostra le barre del segnale non è un'indagine sulla stazione base cellulare. LoRaWAN l'affermazione sulla portata non è una LoRaWAN Rilievo del sito. BLE "150 m in linea di vista" non significa 150 m attraverso scaffalature, cemento, pareti bagnate, macchinari, persone e camion parcheggiati.

La decisione di effettuare il trasporto di ritorno si concretizza in tre punti: scantinati, banchine di carico e locali tecnici.

La copertura LoRaWAN è controllabile, ma è necessario pianificarla

Il grande vantaggio di LoRaWAN è controllo. Se il cliente possiede il sito, puoi posizionare il LoRaWAN Posiziona il gateway dove deve stare, ottimizza l'implementazione e mantieni bassi i costi di rete ricorrenti.

Funziona splendidamente in fabbriche, magazzini, campus e parcheggi. Un'implementazione Lansitec B-Mobile LoRa può utilizzare Gateway Bluetooth nell'area di lavoro, quindi riportano indietro i loro report BLE attraverso un LoRaWAN gateway connesso tramite 4G o Ethernet.

Le linee guida di implementazione di Lansitec raccomandano di posizionare il LoRaWAN porta d'accesso sulla sommità di un edificio, ove possibile, o in una posizione interna elevata per una singola fabbrica. Si nota inoltre che il LoRaWAN Il gateway stesso richiede una connessione 4G o Ethernet e suggerisce di avviare i progetti 4G con un piano dati da 2 GB, poiché l'utilizzo della SIM varia a seconda del progetto.

Un gateway LoRaWAN BLE implementato presenta comunque due livelli di rete:

Strato	Cosa può fallire?
BLE a Gateway Bluetooth	Muri, stanze, RSSI sanguinamento, tempistica della scansione
Gateway Bluetooth A LoRaWAN porta d'accesso	Copertura LoRa, fattore di diffusione, capacità, posizionamento del gateway
LoRaWAN Porta d'accesso al cloud	Interruzione Ethernet, interruzione 4G, piano SIM, percorso server di rete

La copertura NB-IoT/LTE-M è più semplice da implementare, ma più difficile da controllare.

NB-IoT/LTE-M rimuove il sito di proprietà LoRaWAN Portale. È attraente. No LoRaWAN pianificazione del gateway. Nessun locale LoRaWAN Decisione del server. Nessun cliente chiede dove montare l'antenna.

Il compromesso è la dipendenza.

Se l'operatore offre una copertura NB-IoT o LTE-M forte proprio nel punto in cui si trova il gateway, ottimo. In caso contrario, le opzioni a disposizione sono limitate. È possibile migliorare il posizionamento dell'antenna, selezionare un profilo SIM più adatto, utilizzare strategie eSIM/eUICC o cambiare operatore. Tuttavia, non si ha il controllo della stazione base.

NB-IoT tende inoltre ad essere poco adatto a dispositivi in movimento o interazioni veloci. Lo stesso Lansitec LoRaWAN Il confronto tra NB-IoT e NB-IoT rileva che NB-IoT non è adatto ai dispositivi mobili, mentre LoRaWAN Supporta la mobilità e le velocità di trasmissione dati adattive.

La copertura di categoria 1 è ampia, ma potenza e costi devono essere scelti con cura.

La categoria 1 si basa su un'infrastruttura LTE consolidata. Questo spesso semplifica le implementazioni miste o temporanee, soprattutto laddove la disponibilità di LTE-M o NB-IoT è disomogenea.

È inoltre più tollerante per i flussi di lavoro MQTT, HTTP(S), TCP e UDP. In un edificio in cui il team IT non concede l'accesso Ethernet, o dove il Wi-Fi non è consentito per i dispositivi IoT, il cavo Cat-1 può rappresentare la soluzione più pratica.

La domanda sul campo non è "il cavo Cat-1 si connette?". Di solito sì. La domanda è: Il progetto può permettersi i consumi energetici e i dati richiesti dalla Categoria 1? Se la risposta è sì, è un'opzione valida.

Modalità di errore 3: i vincoli di carico utile sono stati ignorati finché la dashboard non è apparsa vuota

Il BLE può produrre una grande quantità di dati locali.

Un gateway può sentire decine di fari. Ogni beacon può pubblicizzare più identificatori o campi sensore. Il team di sviluppo chiede quindi: "Possiamo semplicemente inoltrare tutto?"“

Di solito no.

O almeno, non se il backhaul è LoRaWAN e il progetto prevede una lunga durata della batteria.

LoRaWAN La dimensione del payload dipende dalla regione e dalla velocità di trasmissione dati. Nella banda EU863-870, la documentazione di The Things Network indica dimensioni massime del payload applicativo di 51 byte per i valori da DR0 a DR2, 115 byte per il valore da DR3 e 222 byte per i valori da DR4 a DR7. Viene inoltre menzionata la raccomandazione del duty cycle 1% nella banda europea. ⁽³⁾

LoRa Alliance mantiene questi vincoli regionali separatamente dal nucleo LoRaWAN specifica, con RP002-1.0.5 pubblicata l'8 ottobre 2025. ⁽⁴⁾

Ecco perché il filtraggio è importante.

Lansitec LoRaWAN Gateway Bluetooth includono ripetutamente il filtraggio dei dati Bluetooth configurabile e la segnalazione del payload. Il gateway può filtrare byte di dati specifici da un payload BLE e inoltrare solo le informazioni utili. LoRaWAN. Il solare e il macro LoRaWAN Gateway Bluetooth le specifiche elencano anche 105 massimo fari supportato E un massimo di 15 messaggi beacon in uno LoRaWAN pacchetto su SF9.

Una strategia di backhaul per gateway BLE dovrebbe definire i livelli di payload:

Livello di carico utile	Esempio di contenuto	Miglior vestibilità per il recupero
presenza minima	ID del beacon, ID del gateway, RSSI	LoRaWAN, NB-IoT
Sensore Event Plus	ID del beacon, RSSI, temperatura, movimento, bit di allarme	LoRaWAN con filtraggio, LTE-M
Rapporto del gateway avanzato	Registrazioni multiple di beacon, diagnostica, batteria, timestamp	LTE-M, Cat-1
Carico utile di manutenzione	Registri, frammenti di firmware, diagnostica estesa	LTE-M, Cat-1

Il progetto peggiore è quello vago: "Invia i dati del beacon".“

Quali dati beacon? Ogni pacchetto? Ogni ID univoco per intervallo? Ogni RSSI campione? Media RSSI? Prima e ultima apparizione? I 3 più forti fariSolo eventi di allarme?

Queste decisioni determinano tutto e dovrebbero essere prese prima dell'installazione.

Modalità di guasto 4: il comportamento di interruzione non è stato progettato, ma solo sperato

Ogni rete può fallire. La parte interessante è come fallisce.

Interruzioni LoRaWAN

In un LoRaWAN architettura gateway BLE, la raccolta BLE locale può ancora avvenire anche se LoRaWAN La connessione internet del gateway presenta dei problemi. Tuttavia, l'applicazione potrebbe non visualizzare dati aggiornati finché il collegamento con il gateway non verrà ripristinato.

Se il problema è LoRa RF, spostando il LoRaWAN Il gateway o il miglioramento del posizionamento dell'antenna potrebbero essere d'aiuto. Se il problema è il LoRaWAN backhaul 4G del gateway, quindi il BLE portali Potrebbe andare bene, e il collo di bottiglia è il collegamento tra il gateway e il cloud.

Questa distinzione è importante. Senza una diagnostica, in entrambi i casi il gateway sembra offline.

Interruzioni NB-IoT/LTE-M

Le interruzioni di NB-IoT e LTE-M sono generalmente dovute a problemi lato segnale, lato operatore, lato SIM o lato profilo di potenza.

NB-IoT può essere molto valido per report tolleranti ai ritardi. È meno adatto quando l'applicazione si aspetta una risposta immediata in downlink. LTE-M è generalmente la scelta LPWA cellulare più sicura per dispositivi mobili, allarmi e aggiornamenti del firmware, poiché supporta una maggiore mobilità e una risposta in downlink più rapida. ⁽¹⁾

Interruzioni di categoria 1

Il protocollo Cat-1 solitamente si ripristina in modo più simile al protocollo LTE/IP. Questo è utile quando il gateway deve caricare batch di dati memorizzati nel buffer, riconnettersi a MQTT o ricevere rapidamente modifiche alla configurazione.

Ma può anche creare un enorme problema di sovraffollamento.

Immagina 300 portali Dopo un'interruzione di corrente nel sito, l'alimentazione viene ripristinata. Ogni gateway si riattiva, si connette, si riconnette, verifica la configurazione, carica un backlog e richiede la sincronizzazione dell'ora. Se il firmware non utilizza un backoff casuale, il ripristino si trasforma in una seconda interruzione.

Regola di campo

Progettare il comportamento in caso di interruzione del servizio prima che si verifichi l'interruzione stessa.

Un gateway BLE utile dovrebbe saper fare quanto segue:

• Buffera gli eventi selezionati localmente
• Riprova con cautela, senza farti prendere dal panico.
• Riportare il motivo per cui ha avuto difficoltà, non solo che ha avuto difficoltà.
• Evita di riattivare tutti i dispositivi contemporaneamente dopo il ripristino dell'alimentazione.

Quale collegamento di backhaul è adatto a quale implementazione?

Ora possiamo fare il confronto senza fingere che ogni progetto sia uguale.

1. Solo batteria per interni

Ideale per: LoRaWAN Macro o Micro Gateway Bluetooth

Possibile adattamento: Gateway macro NB-IoT/LTE-M, se la copertura dell'operatore è comprovata

Utilizzare la categoria 1 quando: I payload sono più ricchi, il downlink è importante o l'intervallo di segnalazione non è ultra-aggressivo

Le installazioni indoor con sole batterie sono complesse perché i tecnici detestano sostituire le batterie del gateway in ambienti chiusi quasi quanto lo detestano all'aperto. Montaggi a soffitto, colonne di magazzini, spazi ristretti e aree di produzione complicano ulteriormente la situazione.

LoRaWAN è la prima scelta naturale se il sito può supportare un privato o gestito LoRaWAN Gateway. Macro di Lansitec Gateway Bluetooth È progettato per l'uso in ambienti interni o semi-esterni dove non è disponibile un'alimentazione esterna, con una batteria da 38.000 mAh, un involucro IP66, intervalli regolabili e filtraggio del payload BLE.

NB-IoT/LTE-M ha senso quando il cliente non vuole LoRaWAN infrastrutture. Ma non sceglietelo da una mappa di copertura. Verificate la posizione effettiva del gateway, soprattutto se il dispositivo si trova vicino ad ascensori, scaffalature in acciaio, muri rinforzati, aree sotterranee o locali elettrici.

Il Cat-1 può funzionare, soprattutto con batterie di grandi dimensioni e un utilizzo moderato per la segnalazione. Tuttavia, se l'unica esigenza è quella di sapere "ultimo avvistamento nella stanza A", il Cat-1 è probabilmente più di quanto necessario.

La nostra opinione: Per la presenza in ambienti interni solo a batteria, iniziare con LoRaWAN a meno che la proprietà del sito o la copertura dell'operatore non ti costringano a cercare altrove.

2. Solare per esterni

Ideale per: LoRaWAN Solare Gateway Bluetooth per siti privati

Possibile adattamento: NB-IoT/LTE-M o Gateway Bluetooth solare Cat-1 dove la copertura cellulare è stabile

Rischio principale: autonomia nei giorni di pioggia più comportamento di riprova

L'energia solare esterna sembra facile da installare, finché il tempo non cambia.

Lansitec LoRaWAN Solare Gateway Bluetooth usa un pannello solare da 3 W e un Batteria ricaricabile da 5300 mAh. Il catalogo dei prodotti elenca un mese di pioggia continua con ricezione continua Bluetooth e 60 secondi LoRaWAN intervallo di segnalazione. Supporta inoltre il filtraggio del payload Bluetooth, TDMA e la compressione dei dati.

Si tratta di un profilo decisamente adatto alle attività all'aperto.

Tuttavia, gli impianti solari falliscono quando i team sovrastimano i tempi di recupero. Un gateway può sopravvivere a diversi giorni nuvolosi, ma se tenta anche di connettersi in modo aggressivo in presenza di scarsa copertura, invia report troppo frequentemente o rimane in ascolto continuamente quando non è necessario, il margine di sicurezza si riduce.

Energia solare cellulare portali sono utili quando LoRaWAN L'infrastruttura non è disponibile. La categoria 1 può essere particolarmente conveniente per lotti remoti, depositi all'aperto, piazzali per attrezzature e siti temporanei in cui un cliente desidera una connettività cloud diretta.

La nostra opinione: L'energia solare esterna non riguarda solo le dimensioni dei pannelli. Riguarda anche la disciplina nella redazione di report dopo eventi meteorologici avversi.

3. Edificio sempre alimentato

Ideale per: LoRaWAN Per interni, SocketSync, NB-IoT/LTE-M per interni o Cat-1 Compact, a seconda dell'accesso IT

Rischio principale: Non il potere, ma la politica di rete.

Gli edifici sempre alimentati cambiano le carte in tavola.

Se l'alimentazione è disponibile, la conversazione sul backhaul si sposta dalla durata della batteria all'attrito di implementazione. Puoi usare Ethernet? Il Wi-Fi è consentito? Il team IT approverà MQTT in uscita? Puoi posizionare un LoRaWAN Gateway sul tetto? Le SIM sono più semplici dei ticket VLAN?

Negli ambienti interni alimentati elettricamente, LoRaWAN rimane attraente quando il sito può supportare un gateway locale. Di Lansitec LoRaWAN Gateway Bluetooth per interni supporta alimentazione 5V/1A e può ricevere 100 messaggi beacon in 1 secondo, con un massimo di 15 messaggi beacon inviati in un singolo pacchetto.

NB-IoT/LTE-M o Cat-1 possono essere soluzioni più pulite quando la rete dell'edificio è protetta. Ospedali, centri commerciali, centri logistici e catene di vendita al dettaglio spesso preferiscono la tecnologia cellulare semplicemente perché evita le approvazioni di rete interne.

La nostra opinione: Negli edifici alimentati elettricamente, scegliete la soluzione di backhaul che il cliente può effettivamente gestire, non quella che sembra più economica in termini di hardware.

4. Eventi temporanei, flotte a noleggio e siti pop-up

Ideale per: Cat-1 Compact o NB-IoT/LTE-M Compact

Possibile adattamento: LoRaWAN Compatta se LoRaWAN la copertura esiste già

Rischio principale: tempo di configurazione e comportamento di ripristino

Le implementazioni temporanee penalizzano le scelte che richiedono un grande investimento in infrastrutture.

Se un cliente necessita di copertura BLE per un evento del fine settimana, un'area di noleggio, un magazzino temporaneo, una fiera o una postazione medica temporanea, la connessione cellulare diretta è spesso la soluzione migliore. La categoria 1 è particolarmente utile quando il gateway deve entrare in funzione rapidamente, inviare dati più complessi e supportare i normali flussi di lavoro IP.

LoRaWAN La soluzione più compatta può comunque essere la migliore se il sito è già LoRaWAN copertura. In caso contrario, implementare un LoRaWAN Un gateway pensato solo per supportare un evento di due giorni potrebbe essere eccessivo.

La nostra opinione: Per i siti temporanei, è fondamentale ottimizzare per garantire la certezza dell'installazione. Un costo leggermente superiore per il traffico dati è spesso più conveniente di una seconda visita in loco.

Una matrice di selezione pratica

Scenario di implementazione	LoRaWAN	NB-IoT/LTE-M	Cat-1
Solo batteria per interni	La vestibilità migliore quando LoRaWAN le infrastrutture sono possibili	Utile se la copertura è testata e i carichi utili sono piccoli	Utilizzare con cautela, meglio con una batteria più grande o con una segnalazione moderata
Solare per esterni	Ideale per siti privati e con bassi costi ricorrenti.	Utile dove la copertura cellulare è affidabile	Ideale per carichi utili più complessi e connettività cloud diretta.
Edificio sempre alimentato	Forte se LoRaWAN È consentito il posizionamento del gateway	Utile se l'accesso alla rete dell'edificio è bloccato	Forte se il comportamento IP, MQTT/HTTP(S) e la reattività sono importanti
Porta mobile	Dipende da LoRaWAN schema di copertura	LTE-M è migliore di NB-IoT	Adattamenti forti
Elevato volume di carico utile	Necessita di filtraggio e compressione	Meglio di LoRaWAN, ancora dipendente dal profilo	Vestibilità migliore
Aggiornamenti del firmware	Funziona per BLE lato gateway FOTA flussi di lavoro, ma la strategia del carico utile è importante	LTE-M è migliore di NB-IoT	Il più facile dei tre
Costo di connettività ricorrente più basso	Spesso il più forte	Costo SIM richiesto	Costo della SIM e piano dati richiesto

Cosa registreremmo prima di dare la colpa alla radio

Ecco una lezione imparata a caro prezzo: essere "offline" non è una diagnosi.

Un gateway può non funzionare a causa di problemi come la scansione BLE, l'impacchettamento del payload, la qualità del segnale, il tempo di connessione al backhaul, il rifiuto da parte del server, i limiti del piano SIM, i cali di tensione o un ciclo di tentativi errato. Senza i log corretti, ognuno di questi problemi si traduce in un problema di connettività.

Per i progetti gateway BLE, registreremmo almeno quanto segue:

Articolo registrato	Perché è importante
durata e intervallo della scansione BLE	Distingue il "segnale di errore" dal "collegamento in uscita mancato".“
Numero di beacon per rapporto	Indica quando l'imballaggio del carico utile diventa un problema
dimensione del carico utile	Svela LoRaWAN pressione del tempo di trasmissione o aumento incontrollato dei dati cellulari
RSSI/SNR/SF per LoRaWAN	Aiuta a diagnosticare la copertura, la capacità e il comportamento del fattore di diffusione
RSRP/RSRQ/SINR per dispositivi cellulari	Indica se il consumo di energia cellulare è causato da un segnale debole.
Tempo di allegato e numero di tentativi	Rivela problemi lato modem e lato operatore
Tensione della batteria prima e dopo il collegamento	Conferma se i guasti sono correlati all'alimentazione.

È qui che i cruscotti noiosi diventano preziosi. LoRaWAN Un gateway bloccato su SF12, un gateway LTE-M con tempi di connessione lunghi e un gateway Cat-1 che ritenta la connessione MQTT dopo un errore TLS possono sembrare tutti simili da lontano.

Strategia di payload: cosa dovrebbe effettivamente inviare un gateway BLE?

Un buon gateway BLE non inoltra tutto. Inoltra solo ciò che l'applicazione può utilizzare. Per la maggior parte delle implementazioni di tracciamento e rilevamento della presenza, si consiglia di iniziare con quattro tipi di messaggio:

1. Aggiornamento sulla presenza
   ID del beacon, ID del gateway, RSSI, data e ora, batteria se disponibile.
2. Aggiornamento dell'evento
   Stato di ingresso, uscita, panico, movimento, manomissione, permanenza oltre il tempo consentito o allarme.
3. Aggiornamento del sensore
   Temperatura, umidità, vibrazioni, stato della porta, numero di passi o altri dati selezionati.
4. Aggiornamento sullo stato di salute
   Batteria del gateway, qualità del segnale, versione del firmware, numero di segnalazioni, numero di tentativi.

La combinazione esatta dipende dalla distanza di backhaul.

LoRaWAN Dovrebbe trasportare dati compatti relativi a eventi e stati. NB-IoT/LTE-M può tollerare un contesto dei sensori più ampio, soprattutto quando i report sono poco frequenti. Cat-1 può trasportare batch e diagnostica più ricchi, ma beneficia comunque di un filtraggio efficace.

Compatibilità dei prodotti Lansitec in base al tipo di installazione

Tipo di installazione	Vestibilità Lansitec	Perché
Solo batteria per interni	LoRaWAN Macro Gateway Bluetooth	Batteria di grande capacità da 38.000 mAh, filtro BLE configurabile, lunghi intervalli di segnalazione
Piccole stanze interne dotate di alimentazione elettrica	LoRaWAN Gateway Bluetooth per interni	Alimentazione 5V/1A, elevata capacità di ricezione BLE, installazione compatta
Sito privato esterno con pannelli solari	LoRaWAN Solare Gateway Bluetooth	Pannello solare da 3W, batteria da 5300 mAh, LoRaWAN backhaul, filtraggio del carico utile
Solare esterno senza LoRaWAN	NB-IoT/LTE-M o Gateway Bluetooth solare Cat-1	Backhaul diretto della rete dell'operatore
Sito o evento temporaneo	Gateway Bluetooth compatto Cat-1	Portatile, cellulare, adatto per un'installazione rapida
Gateway diretto al cloud	Famiglia NB-IoT/LTE-M o Cat-1	Percorso del server MQTT/HTTP senza locale LoRaWAN porta d'accesso

È qui che la gamma di Lansitec si rivela utile. Non dobbiamo per forza imporre un unico backhaul per ogni implementazione. Un parcheggio, un corridoio ospedaliero, un cantiere minerario e un evento improvvisato non meritano la stessa risposta.

Raccomandazione finale: scegliete la modalità di guasto che potete gestire.

LoRaWAN, NB-IoT/LTE-M e Cat-1 possono tutti funzionare per il backhaul del gateway BLE. Semplicemente, presentano malfunzionamenti diversi.

LoRaWAN Il sistema fallisce quando i team ignorano il tempo di trasmissione, la dimensione del carico utile, il fattore di diffusione o il posizionamento del gateway. Tuttavia, se il sito è ben pianificato, offre un'eccellente durata della batteria, un controllo efficace e bassi costi di connettività ricorrenti.

NB-IoT/LTE-M fallisce quando la copertura dell'operatore, il roaming, la latenza e il comportamento del downlink vengono dati per scontati invece di essere testati. Ma è molto utile quando i clienti desiderano un backhaul cellulare diretto senza implementare LoRaWAN infrastrutturale.

Cat-1 fallisce quando i team lo trattano come LPWAN. Ma per payload più ricchi, mobile portali, Grazie alla configurazione rapida, ai flussi di lavoro IP diretti e al ripristino reattivo, può essere la scelta più pulita.

Quindi la regola pratica è semplice: Scegliete la tubazione di ritorno che potete utilizzare anche in condizioni avverse, non quella che sembra migliore in condizioni perfette.

Una buona implementazione di un gateway BLE diventa noiosa dopo l'installazione. Il gateway esegue la scansione quando necessario, filtra i dati ricevuti, segnala le informazioni rilevanti, riprova in modo cortese e fornisce alla piattaforma sufficienti informazioni diagnostiche per risolvere i problemi prima che qualcuno debba intervenire.

Riferimenti e ulteriori letture:

1. GSMA: Guida all'implementazione dell'IoT mobile
2. Quectel: Moduli LTE Cat 1 bis
3. La rete delle cose: banda EU863-870 MHz
4. LoRa Alliance: RP002-1.0.5 Parametri regionali LoRaWAN