LoRaWAN - moduł ATSAMR34-XPro

Internet Rzeczy jest zbiorem połączonych czujników, sterowników i innych urządzeń. Daje to możliwość wymiany informacji, korzystania z zasobów dostępnych w sieci lub mocy obliczeniowej potężnych serwerów czy algorytmów AI. Najczęściej te zasoby są umieszczane w chmurze, po to by użytkownicy mieli do nich nie skrępowany dostęp z dowolnej lokalizacji. Przy olbrzymiej ilości urządzeń IoT (szacuje się w najbliższej przyszłości będzie to ponad 45 miliardów) i ciągłej tendencji wzrostowej, połączenie ich bezpośrednio do Internetu za pomocą protokołów z rodziny IP wydaje się niemożliwe do zrealizowania. W rzeczywistości wiele tych urządzeń nie ma takiego połączenia z siecią z różnych powodów. Są takie zastosowania, w których połączenia z Internetem nie są konieczne lub wymagane. Jeżeli jednak połączenie jest wymagane, to w wypadku małych czujników zasilanych bateryjnie barierą może być koszt obsługi połączenia opartego na protokole IP. W takim przypadku potrzeba sporych zasobów sprzętowych i programowych. Potrzeba stosowania wydajnych mikrokontrolerów kłóci się z ideą tanich prostych czujników z małym poborem mocy. Sporym problemem może być brak bezpośredniego połączenia internetowego w słabo zaludnionym miejscu instalowania urządzeń IoT. Można próbować temu zaradzić na różne sposoby. Jednym z nich jest rozwiązanie nazwane LoRaWAN.

LoRaWAN

LoRaWAN jest radiowym protokółem komunikacyjnym, który pozwala łączyć się z Internetem urządzeniom IoT wyposażonym w łącze radiowe. Połączenie nie jest realizowane wprost, ale za pomocą specjalnych stacji bazowych nazywanych koncentratorami.  Bardzo ważną cechą standardu jest możliwość uzyskania relatywnie dużego zasięgu liczonego w kilometrach przy bardzo ograniczonej mocy nadawania (20 dBm) i co za tym idzie - przy małym poborze prądu.  LoRaWan bazuje na otwartym standardzie i wykorzystuje pasmo ISM - w Europie jest to 868 MHz. To ma daleko idące konsekwencje, bo umożliwia tworzenie tanich sieci bez konieczności uzyskiwania administracyjnych zgód i ponoszenia opłat za wykorzystanie pasma. Tą technologią interesują się również operatorzy telekomunikacyjni, na przykład Orange, SK Telecom. Niestety w naszym kraju jak na razie pokrycie sieciami LoRaWAN jest bardzo małe.

Standardem LoRaWAN zarządza grupa LoRaAlliance skupiająca ok. 500 członków. Uczestnicy skupieni w LoRaAlliance wspierają rozwój protokołu i tworzą zgodne z nim komponenty, gotowe produkty i usługi. Ze znanych firm wspierających LoRAWAN można wymienić Microchip, ST, CISCO, czy ARM.

Do transmisji w kanale radiowym wykorzystywany jest system  komunikacji nazwana LoRa. W odróżnieniu od innych znanych technologii typu Bluetooth, Wi-Fi, ZigBee - LoRa umożliwia przesyłanie danych na relatywnie duże odległości wykorzystując modulację CSS Chirp Spread Spectrum. Co ciekawe, jest to technika opracowana w latach 30-tych XX wieku na potrzeby konstruowanych w tym czasie radarów. Stosowana też była do łączności w astronautyce. CSS jest odporna na zakłócenia wynikające z interferencji sygnałów oraz na zjawisko Dopplera. Nie wymaga synchronizacji odbiornika i nadajnika oraz, co ważne, amplituda sygnału praktycznie nie ma wpływu na stopę błędów podczas transmisji (amplituda ma wpływ tylko na zasięg sygnału). Za to modulacja CSS ze względu na swoje właściwości nie pozwala na przesyłanie danych z dużą prędkością.

LoRaWAN jest protokółem dostępu do łącza MAC (Medium Access Protocol). Jak wiemy przy jego opracowywaniu położono nacisk na pracę z łączami dalekiego zasięgu, ale o małej przepływności i jest z zasady przeznaczony dla urządzeń IoT pracujących przy małym poborze energii. Dwukierunkowość transmisji danych pozwala na realizację niezawodnego przesyłania informacji przez możliwość zaimplementowania mechanizmu potwierdzeń oraz przesyłanie komend sterowania. Bezpieczeństwo transmisji zapewnia silne szyfrowanie. Ważną cechą użytkową jest możliwość bezprzewodowej rejestracji nowych urządzeń w sieci oraz przesyłanie  danych w trybie multicast (jeden do wielu).

Rysunek 1. Struktura sieci LoRaWAN

Rysunek 2. Wymiana informacji z urządzeniem klasy A

Rysunek 3. Wymiana informacji z urządzeniem klasy B

Rysunek 4. Wymiana informacji z urządzeniem klasy C

Fotografia 5. Moduł ATSAMR34 XPRO Demo Board

Na rysunku 1 pokazano strukturę sieci LoRaWAN. Węzły (urządzenia końcowe - czujniki) łączą się z koncentratorami za pomocą protokołu LoRaWAN RF. Koncentratory przesyłają dane do serwerów sieciowych standardowym połączeniem wykorzystującym protokoły LoRaWAN TCP/IP SSL (Wi-Fi, Ethernet) lub za pomocą usługi dostępowej w sieciach GSM (3G/LTE).

Sieć jest zbudowana z czterech głównych komponentów:

1. Urządzeń końcowych (węzłów).
2. Koncentratorów (stacji bazowych, routerów, bramek).
3. Serwera sieciowego.
4. Serwerów aplikacji.

Urządzenia końcowe to sprzęt, który zawiera czujniki, układy sterowania, mikrokontroler i moduł transmisji radiowej. Obsługują transmisje dwukierunkową z koncentratorami - mogą same wysyłać dane oraz otrzymywać dane z koncentratorów. W założeniu urządzenia IoT, które są czujnikami i pracują jako węzły sieci LoRaWAN powinny nieć możliwość długotrwałej przy zasilaniu bateryjnym. Ze względu na rodzaj transmisji i zużycie energii wprowadzono podział urządzeń na trzy klasy:

1. Klasa A - pobiera najmniej energii. Urządzenia tej klasy wysyłają krótkie informacje tylko wtedy, gdy wystąpi zdarzenie typu przekroczona wartość mierzonego parametru. Mogą też wysyłać dane z określonym interwałem, na przykład, raz na dobę. Odbieranie informacji jest możliwe tylko po wcześniejszym wysłaniu własnych danych. Każda wymiana danych rozpoczyna się od wysłania przez urządzenie końcowe danych (uplink). Po ich wysłaniu węzeł odczekuje przez zdefiniowane dwa określone czasy (okna czasowe) na dane z serwera (wiadomość downlink). Po odebraniu wiadomości z serwera urządzenie końcowe (węzeł) przechodzi do stanu głębokiego uśpienia, aby ograniczyć pobór energii przy pracy z zasilaniem bateryjnym. Zaletą klasy A jest bardzo mały pobór energii, a wadą spore opóźnienia łącza, bo serwer sieciowy nie "wie", kiedy zostanie zainicjowana transmisja (rysunek 2).
2. Urządzenia klasy B mogą przesyłać i odbierać dłuższe informacje z mniejszym opóźnieniem reakcji serwera spowodowanej losowym wysyłaniem danych uplink przez urządzenie klasy A. W klasie B urządzenie okresowo otwiera okno czasowe do odbierania informacji z serwera dowlink. Czas otwarcia łącza (Beacon Period) pomiędzy urządzeniem i serwerem jest ustalany przez zsynchronizowane zegary. Synchronizacja jest realizowana przez sekwencyjne wysyłanie przez serwer komendy synchronizującej odbieranej przez urządzenie. Sama transmisja odbywa się tak jak w klasie A (rysunek 3). Zaletą klasy B jest szybszy dostęp do połączenia, bo serwer sieciowy "wie", w jakim czasie może spodziewać się transmisji z urządzenia.
3. Urządzenie klasy C może ciągle odbierać dane, jeśli samo ich nie wysyła (rysunek 4). Klasa ta nie jest przewidziana do zasilania bateryjnego i wymaga stałego zasilania z sieci energetycznej. W trakcie pracy jest ciągle otwierane okno czasowe. Zmniejsza to opóźnienia łącza umożliwiając przesłanie relatywnie dużej ilości danych, ale znacznie podwyższa pobór energii.

Koncentratory nazywane inaczej bramkami, modemami lub punktami dostępu odbierają dane z węzłów końcowych. Przesyłane dane są dzielona na pakiety i transmitowane protokołami IP do serwera sieciowego Bramki są z zasady przeźroczyste (nie modyfikują zawartości przesyłanych danych). Koncentrator musi był połączony z Internetem.

Serwer sieciowy realizuje dość skomplikowany proces przetwarzania danych przesłanych z węzłów:

• Określa, która z bramek jest najlepsza do komunikacji z węzłem. Do tego celu są wykorzystane parametry łącza radiowego: RRSI (wskaźnik siły odbieranego sygnału) i SNR (współczynnik sygnał/szum) z poprzednio otrzymanych pakietów.
• Przekierowuje dane do odpowiednich aplikacji.
• Usuwa zwielokrotnione (zduplikowane) wiadomości przekazane do węzła przez więcej niż jedną bramkę.
• Deszyfruje wiadomości przesyłane przez węzeł i szyfruje wiadomości przesyłane do węzłów.
• Zapewnia nadzór i diagnostykę szyfrowanego połączenia IP serwer/bramki.

Serwer aplikacji realizuje właściwą usługę związaną z aplikacją IoT zbierająca dane z węzłów. Takie serwery wykorzystują chmury, które łączą się z serwerami sieciowymi.

Węzły (urządzenia końcowe) sieci LoRaWAN jak wiemy muszą się charakteryzować bardzo małym poborem energii. W urządzeniach klasy A i B stosuje się głębokie uśpienie w czasie braku aktywności pozwalające na mocne obniżenie poboru prądu. Ale niezbędny jest też pewien stopień wydajności zabudowanego mikrokontrolera pozwalający na obsługę stosu, kodowanie transmisji danych i oczywiście obsługę czujnika pomiarowego. Dlatego wielu producentów stosuje 32-bitowe mikrokontrolery mające zaawansowane tryby obniżonego poboru energii.

ATSAMR34 XPRO Demo Board

Jednym z gotowych modułów przeznaczonych do pracy jako węzeł sieci LoRaWAN jest ATSAMR34 XPRO Demo Board produkowany i oferowany przez firmę Microchip, jednego z członków grupy LoRaAlliance (fotografia 5). Moduł jest oparty o specjalizowany mikrokontroler ATSAMR34J18B z wbudowanym trasceiverem LoRa i 32-bitowym rdzeniem Cortex-M0+. Jego podstawowe parametry są następujące:

• Wsparcie dla transmisji w pasmach 868 MHz i 915 MHz.
• Maksymalna moc wyjściowa +20 dBm.
• Wbudowany oscylator TCXO.
• Gniazdo antenowe SMA RF z dołączoną w zestawie anteną (Whip Antenna).
• Układy do pomiaru poboru prądu współpracujący z XPRO Current Measurement System Data Visualizer.
• Wbudowany system zarządzenia energią z monitorowaniem poboru prądu.
• Wbudowany EDBG Debugger współpracujący ze środowiskiem Atmel Studio 7 ICE.
• Dwa złącza rozszerzeń .
• 10-pinowe złącze dla programatora Cortex Programmer.
• Przyciski Reset i GPIO.
• Diody LED: sygnalizująca status oraz włączone zasilanie.
• Gniazdo na baterię podtrzymującą CR1220.

Najważniejszym elementem modułu jest mikrokontroler. Seria SAMR34 ma 32-bitowy rdzeń ARM Cortex-M0+ połączony z wbudowanym transceiverem UHF wspierającym standard LoRa z modulacją FSK. Rdzeń może być taktowany maksymalną częstotliwością 48 MHz. Na rysunku 6 pokazano schemat blokowy mikrokontrolera z zaznaczonym modułem transceivera.

Mikrokontroler ATSAMR34J18B jest wyposażony w wiele układów peryferyjnych. Oprócz transceivera UHF najważniejsze z nich to:

• Układ AES ze sprzętowym generatorem liczb losowych.
• 12-bitowy przetwornik A/C z układem nadpróbkowania i programowanym układem wzmacniacza wejściowego.
• Interfejs USB 2.0
• 2 komparatory analogowe.
• 5 interfejsów szeregowych SERCOM mogących pracować jako USART, I²C, SPI lub LIN.
• 12-kanałowy kontroler DMA i 12-kanałowy Event System.
• 3×16-bitowy licznik TC i 3×16-bitowy licznik TCC.
• Moduł zegara czasu rzeczywistego RTC.

Rysunek 6. Schemat blokowy mikrokontrolera ATSAM34/35

Rysunek 7. Układ dystrybucji zasilania modułu ATSAMR34 XPRO Demo Board

Rysunek 8. Schemat modułu XAM

Rysunek 9. Model warstwowy LoRaWAN dla urządzenia końcowego (węzła)

Rysunek 10. Architektura stosu MLS

Aby 32-bitowa jednostka mogła pracować przy bardzo małym poborze mocy, trzeba ją wprowadzać w stan uśpienia w tym czasie, gdy nie ma niczego do zrobienia. W mikrokontrolerze ATSAM34 trybami oszczędzania poborem energii zarządza moduł Power Manager. Ma on do dyspozycji 4 tryby oszczędzania energii: Idle, Standby, Backup i Off. Po wejściu w tryb uśpienia jest zatrzymywane wykonywanie kodu, część modułów mikrokontrolera i ich taktowanie zostają wyłączone. Od trybu uśpienia zależy, które moduły są wyłączane. Wyjście ze stanu obniżonego poboru energii następuje po zgłoszeniu przerwania od aktywnego układu peryferyjnego - na przykład od licznika.

Moduł ATSAMR34 XPRO Demo Board może być zasilany z trzech źródeł: z debuggera EDBG USB, z portu USB (target USB) lub z zewnętrznego źródła zasilania +5 V. Na płytce zamontowano dwa stabilizatory LDO +3,3 V. Jeden z nich zasila debugger EDBG i moduł XAM (Xplained Pro Analog Module), a drugi mikrokontroler ATSAM34 (rysunek 7).

Układ XAM jest funkcjonalnym rozszerzeniem EDBG i umożliwia pomiar prądu przez układy modułu. Schemat blokowy XAM pokazano na rysunku 8. Układ pomiarowy składa się z:

• Układu kalibracji pomiaru.
• Układu napięcia referencyjnego +2,7 V.
• Właściwego układu pomiarowego zbudowanego z szeregowego rezystora pomiarowego, przedwzmacniacza i dwóch aktywnych filtrów z funkcją wzmacniacza sygnału.
• Mikroprocesorowego sterownika z przetwornikiem A/C i procesorem przetwarzania sygnału.
• Interfejsu komunikacyjnego z debuggerem EDBG.

Do dokładnego pomiaru prądu są wykorzystywane 4 zakresy pomiarowe:

1. Zakres z dużą rezystancją rezystora pomiarowego i dużym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru wynosi około 20 nA. Użyteczny zakres pomiaru to 1 µA. Poniżej tej wartości spada dokładność pomiaru.
2. Zakres z dużą rezystancją rezystora pomiarowego i małym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru wynosi 150 nA.
3. Zakres z małą rezystancją rezystora pomiarowego i dużym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru 10 µA.
4. Zakres z małą rezystancją rezystora pomiarowego i małym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru 100 µA.

Zakres pomiarowy jest automatycznie przełączany przez XAM w zależności od mierzonych wartości. Zmierzone wartości mogą być wyświetlane za pomocą aplikacji DataVisualizer.

Oprogramowanie stosu LoRaWAN

Oprogramowanie stosu LoRaWAN oparto o model warstwowy składający się z warstw: aplikacji, MAC i PHY (rysunek 9). Warstwa aplikacji zawiera funkcje i procedury użytkownika, które wykorzystują możliwości warstwy MAC do realizowania przesyłania danych (nadawania i odbierania) przez łącze radiowe LoRa. Warstwa MAC jest pomostem pomiędzy warstwą aplikacji wykonującą funkcje związane z pracą czujnika i warstwą fizyczną PHY. W niej jest organizowana transmisja danych właściwa dla danej klasy urządzeń (A, B, lub C). Warstwa fizyczna PHY to układ transceivera wysyłający i odbierający dane radiowe w kanale radiowym. Zawiera modulator, demodulator CSS, oraz tory nadajnika i odbiornika wraz z układami konfiguracyjnymi i układami sterowania .

Microchip dostarcza stos LoRaWAN MLS (Microchip LoRaWAN Stack) przeznaczony dla mikrokontrolerów ATSAM R34/R35, funkcjonalnie podzielony na kilka modułów z funkcjami interfejsu API:

• LoRaWAN MAC Layer (MAC) - warstwa MAC.
• LoRaWAN Radio Layer (TAL) - warstwa do obsługi sprzętu - wbudowanego Transceivera.
• Persisent Data Server (PDS).
• Power Manager Module (PMM) - funkcje zarządzania poborem mocy.
• Hardware Abstraction Layer (HAL) - warstwa abstrakcji sprzętu oddzielająca funkcje API od zastosowanych rozwiązań sprzętowych w warstwie PHY.

Rysunek 11. Struktura katalogów projektu stosy LoRaWAN Microchipa

Rysunek 12. Wykrycie modułu SAM R32 Xplained Pro

Na rysunku 10 pokazano architekturę stosu MLS. Warstwa MAC dostarcza niezbędnych usług zdefiniowanych w specyfikacji LoRAWAN. Warstwa TAL używa drivera modułu radiowego w celu dostępu do transceivera. Driver radia komunikuje się z modułem radiowym przez interfejs SPI, wspomagany przez dodatkowe linie GPIO i wejście przerwania IRQ. Stos MLS może konfigurować urządzenie końcowe, a w zasadzie jego tor radiowy do pracy w wielu pasmach radiowych, dostępnych w różnych lokalizacjach (Eyropa, Azja, USA itp.). Parametry konfiguracji toru radiowego są pobierane spoza MLS. PDS zawiera parametry konfiguracyjne LoRaWAN zapisane w pamięci Flash. Są one pobierane i odtwarzane  w czasie każdego cyklu wybudzenia z uśpienia. Moduł PMM zarządza układami ograniczania poboru energii przez usypianie mikrokontrolera, kiedy stos wchodzi w tryb IdleMode. ASFv3 jest zbiorem driverów i usług dla interfejsów szeregowych I²C, SPI i UART, a także dla GPIO.

Stos działa w systemie wielozadaniowym bez wywłaszczania (non-preemptive priority) zarządzającym pracą MAC, TAL, PMM, PDC.

Naturalną konsekwencją takiego podziału jest struktura katalogów firmowego przykładu dostępnego na stronach Microchipa i przeznaczonego dla modułu ATSAMR34 XPRO Demo Board (rysunek 11). Dokładny opis wszystkich funkcji API można znaleźć w dokumencie SAM R34/R35 Microchip LoRaWAN Stack Software API Reference Manual DS70005382A.

Obsługa modułu

Moduł ATSAMR34 XPRO Demo Board trzeba połączyć z portem USB komputera kablem dołączonym do złącza EBDG USB (wtyczka USB Micro). Jeżeli jest uruchomiony IDE Atmel Studio 7 to moduł zostanie przez niego wykryty i zidentyfikowany (rysunek 12). Microchip udostępnia na stronie projekt z plikami źródłowymi APPS_ENDDEVICE_DEMO przeznaczony dla środowiska Atmel Studio 7. Po pobraniu projekt trzeba rozpakować i uruchomić z menu File -> Open -> Project/Solution. Przed użyciem w sieci LoRaWAN jest niezbędna konfiguracja wykonywana przez wpisanie odpowiednich ustawień w pliku conf_app.h w kilku krokach:

1. Metoda aktywowania urządzenia końcowego: ręcznie lub przez serwer (Over The Air)

#define DEMO_APPLICATION_SESSION_KEY {0x41, 0x63, 0x74, 0x69, 0x6C, 0x69, 0x74, 0x79, 0x00, 0x04, 0xA3, 0x0B, 0x00, 0x04, 0xA3, 0x0B}

#define DEMO_NETWORK_SESSION_KEY {0x61, 0x63, 0x74, 0x69, 0x6C, 0x69, 0x74, 0x79, 0x00, 0x04, 0xA3, 0x0B, 0x00, 0x04, 0xA3, 0x0B}

Dokładniejszy opis sposobu konfiguracji można znaleźć w dokumencie SAM-R34_MLS-Getting Started User Guide DS50002812A.

Rysunek 13. Uruchomienie Data Visualizer

Rysunek 14. Wybór pomiaru prądu przez Data Visializer

Rysunek 15. Łączenie z wykrytym EDBG i rozpoczęcie pomiarów

Rysunek 16. Pomiar prądu przez moduł

Jak już wspomniałem, zasięg sieci LoRaWAN w naszym kraju jest bardzo ograniczony. W trakcie pisania tego tekstu nie byłem w stanie przetestować transmisji pomiędzy modułem a serwerem. Jednak po doświadczeniach z produktami Microchipa należy się spodziewać, że po prawidłowym skonfigurowaniu modułu wszystko powinno działać.

Ponieważ moduł jest wyposażony w układ pomiaru prądu, a dla urządzeń końcowych pobór energii ma bardzo ważne znaczenie, postanowiłem sprawdzić, czy ta funkcjonalność działa. Wykonane pomiary nie będą miarodajne, bo nie można nawiązać połączenia z serwerem, ale dadzą pojęcie o skali zużycia energii. Poza tym, mając do dyspozycji możliwość szybkiego pomiaru prądu i łatwej wizualizacji jego zmian można szybko oszacować, jaki wpływ na pobór mocy będą miały zmiany w programie czy zmiany w konfiguracji stosu.

W środowisku  Atmel Studio 7 można uruchomić z menu Tools program Data Visualizer (rysunek 13). Jest to aplikacja współpracująca między innymi z debuggerem EDBG połączonym z układem XAM. Pozwala w sposób graficzny przedstawić bieżące zużycie prądu przez moduł. W menu interfejsów obsługiwanych przez EDBG i Data Visualizer zaznaczamy okienko Power (rysunek 14). Przed wykonaniem pomiarów trzeba się połączyć z wykrytym EDBG z modułu SAM32Xplained Pro klikając na przycisk Connect i uruchomić rejestrację pomiarów klikając na przycisk Start (rysunek 15). Na rysunku 16 pokazano fragment okna z graficznym przedstawieniem poboru prądu testowanego modułu w trakcie pracy.

Podsumowanie

Skonstruowanie mikrokontrolera ATSAM34/35 z rdzeniem Cortex M0+ zintegrowanego z modułem radiowego transceivera LoRa wyraźnie pokazuje, że Microchip poważnie podchodzi do technologii LoRaWAN. Moduł z tym mikrokontrolerem i dołączone kompletne oprogramowanie stosu jest na pewno silnym wsparciem konstruktorów urządzeń IoT. Nie bez znaczenia są też dodatkowe funkcje pozwalające szybko zmierzyć, lub przynajmniej oszacować bardzo istotną dla urządzeń zasilanych bateryjnie wartość poboru prądu.  Sama technologia radiowa LoRa jest również atrakcyjna z powodu możliwości przesyłania danych na relatywnie duże odległości przy bardzo energooszczędnych transceiverach.

Ale według mnie jest jeden podstawowy problem z LoRaWAN - brak infrastruktury koncentratorów. Żeby cokolwiek przesyłać trzeba być w zasięgu koncentratora podłączonego Internetem do serwera. A z tym jak na razie u nas i nie tylko u nas jest niezbyty dobrze. Jeżeli ktoś jest zdeterminowany to może "postawić" sobie swój własny koncentrator. Nie jest to bardzo drogie ani mocno skomplikowane pod warunkiem, że mamy do dyspozycji miejsce do zainstalowania anteny i w pobliżu łącze do Internetu. A to w wielu przypadkach może być wielkim problemem, lub może nie być w ogóle możliwe. Jak na razie tylko sieci telefonii komórkowej dysponują infrastrukturą zapewniającą bardzo duże pokrycie zasięgiem: maszty, anteny i  łącza informatyczne o odpowiedniej przepustowości. Wydaje się, że największe prawdopodobieństwo powodzenia będą miały oparte o tani abonament komercyjne systemy wykorzystujące tą infrastrukturę. LoRaWAN może być bardzo dobrym uzupełnieniem tam, gdzie nie ma zasięgu, lub nie będzie usługi przeznaczonej dla IoT, na przykład w terenach mało zaludnionych. Być może będą powstawać sieci koncentratorów montowane przez entuzjastów.

Tomasz Jabłoński, EP