Scenka z miasta: czujniki wiszą, dane nie dochodzą
Problem: „to miało działać samo”
Na dachu biurowca w centrum miasta wisi kilka świeżo zamontowanych czujników jakości powietrza. Wszystko wygląda profesjonalnie: obudowy IP65, logo firmy, nawet kabelki schowane w peszlach. Po tygodniu od uruchomienia dashboard wciąż świeci pustkami – część czujników wysyła dane raz na kilka godzin, część wcale. Właściciel sieci był przekonany, że „LoRaWAN ma duży zasięg, więc jakoś to będzie”.
Po krótkim dochodzeniu okazuje się, że gateway LoRaWAN stoi… w serwerowni na pierwszym piętrze, za kilkoma żelbetowymi stropami i ścianami z windami po drodze. Antena przykręcona jest bezpośrednio do obudowy, schowana za klimatyzatorem. W szczycie dnia w okolicy pracuje kilka innych instalacji radiowych, do tego gęste otoczenie budynków tworzy klasyczne „kaniony miejskie”. Efekt: ramki radiowe giną w szumie i odbiciach.
Tak wygląda typowy scenariusz, w którym prywatna sieć LoRaWAN w mieście kończy jako pasmo frustracji zamiast niezawodnej warstwy komunikacyjnej. Samo „powieszenie czujników” i „postawienie gatewaya” rzadko wystarcza. Bez planu warstwy radiowej, zrozumienia ograniczeń pasma ISM i sensownie dobranego serwera sieciowego LoRaWAN całość działa jak loteria.
Rozsądne podejście do budowy prywatnej sieci LoRaWAN w środowisku miejskim zaczyna się od fundamentów: regulacji, architektury sieci, realnego planowania pokrycia i dopiero na tym tle wyboru sprzętu, konfiguracji gatewaya oraz integracji danych z aplikacjami IoT. Im lepszy porządek na poziomie koncepcji, tym mniej „magii” i przypadkowych awarii w codziennej eksploatacji.
Czym jest prywatna sieć LoRaWAN i po co ją stawiać w mieście
LoRa vs LoRaWAN – dwa poziomy tej samej układanki
LoRa i LoRaWAN są często wrzucane do jednego worka, choć to dwie warstwy o różnym zakresie odpowiedzialności. LoRa to warstwa fizyczna – modulacja radiowa oparta o rozpraszanie widma (chirp spread spectrum) w nielicencjonowanym paśmie ISM. Dostarcza duży zasięg przy niskim poborze energii, ale nic nie mówi o tym, jak zarządzać siecią, ruchem, bezpieczeństwem czy adresacją urządzeń.
LoRaWAN to protokół warstwy sieciowej i architektura całej sieci. Definiuje:
- jak urządzenia końcowe (node’y) komunikują się z gatewayami,
- jak działa uwierzytelnianie i szyfrowanie,
- jak wyglądają klasy pracy urządzeń (A/B/C),
- jaką rolę pełni network server i application server,
- jak zarządzać parametrami radiowymi (np. ADR).
Można więc zbudować prostą, „gołą” łączność LoRa (np. punkt–punkt), ale prywatna sieć LoRaWAN w mieście opiera się o komplet: modulację LoRa plus pełny stos LoRaWAN z serwerem sieciowym i aplikacyjnym.
Publiczna sieć operatora a prywatna sieć LoRaWAN
W wielu miastach działają publiczne sieci LoRaWAN – operatorzy komercyjni lub społecznościowe projekty typu The Things Network. Dają one wygodę „podpięcia” urządzeń bez inwestowania w infrastrukturę radiową. Jednak dla wielu scenariuszy miejskich to nie wystarcza.
Publiczna sieć LoRaWAN oznacza:
- brak pełnej kontroli nad pokryciem radiowym (operator decyduje, gdzie stoją gatewaye),
- uzależnienie od SLA i polityk operatora,
- koszty zależne od modelu abonamentowego lub liczby wiadomości,
- ograniczone możliwości customizacji (np. specyficzne kanały, parametry ADR).
Prywatna sieć LoRaWAN to:
- pełna kontrola nad infrastrukturą (gatewaye, anteny, network server),
- możliwość dopasowania pokrycia do konkretnych obiektów (osiedle, kampus, centrum handlowe),
- kontrola nad danymi – od warstwy radiowej po integrację z systemami SCADA, BMS czy platformami IoT,
- przewidywalne TCO, często niższe przy dużej skali i długim horyzoncie czasu.
Jeżeli celem jest kilka rozproszonych czujników w mieście, publiczna sieć operatora bywa idealna. Gdy pojawia się własne osiedle, park technologiczny, port, kampus uczelni czy sieć wodomierzy zarządzanych przez miejską spółkę – prywatna sieć LoRaWAN daje znacznie większą kontrolę i elastyczność.
Miejskie scenariusze zastosowań prywatnej sieci LoRaWAN
Środowisko miejskie jest naturalnym poligonem dla LoRaWAN. Typowe projekty, w których prywatna sieć ma duży sens:
- Parking i strefa płatnego parkowania – czujniki zajętości miejsc w garażach podziemnych i na ulicach; wymagana powtarzalność odczytów i brak zależności od operatora zewnętrznego.
- Monitoring pojemników i odpadów – czujniki poziomu napełnienia śmietników, kontenerów, „dzwonów” na szkło; prywatna sieć ułatwia rozciągnięcie zasięgu na obrzeża miasta i bazy przeładunkowe.
- Infrastruktura wod-kan i ciepłownicza – wodomierze, ciepłomierze, studzienki, przepompownie; sieć LoRaWAN pozwala na głęboką penetrację podziemnych instalacji przy niskim zużyciu energii.
- Smart building i kampusy – biurowce, centra logistyczne, lotniska, uczelnie; jedna lub kilka bram pokrywa tysiące sensorów: HVAC, drzwi, wilgotność, zużycie mediów.
- Smart city – oświetlenie uliczne, czujniki jakości powietrza, stacje meteo, monitoring hałasu, ławki „smart”; prywatna sieć gminna pozwala uniknąć vendor lock-in względem jednego integratora.
Elementy składowe prywatnej sieci LoRaWAN
Kompletna, prywatna sieć LoRaWAN, nawet w małej skali, składa się z kilku warstw:
- Urządzenia końcowe (end devices, node’y) – czujniki, liczniki, siłowniki; wyposażone w moduł LoRa i stos LoRaWAN.
- Gatewaye (koncentratory) – odbierają ramki LoRa od urządzeń i przesyłają je dalej po IP (Ethernet, LTE) do serwera sieciowego.
- Network server (NS) – kluczowy element logiki sieci LoRaWAN; odpowiada za routing, deduplikację, bezpieczeństwo, ADR.
- Application server (AS) – dekoduje payload, udostępnia dane aplikacjom zewnętrznym (API, MQTT, webhooki).
- Systemy nadrzędne – dashboardy, systemy SCADA/BMS, platformy IoT, hurtownie danych, aplikacje biznesowe.
Prywatna sieć ma największy sens tam, gdzie kluczowe jest połączenie trzech rzeczy: kontroli nad zasięgiem, bezpieczeństwa i suwerenności danych oraz przewidywalnych kosztów całkowitych (TCO) w perspektywie kilku lat.
Regulacje i podstawy radiowe: pasmo, moc, duty cycle
Pasmo ISM EU868 w Polsce – co jest do dyspozycji
W Polsce i generalnie w Europie LoRaWAN w zastosowaniach miejskich korzysta z nielicencjonowanego pasma ISM w okolicach 868 MHz (EU868). Jest to pasmo współdzielone – działają w nim także inne technologie (np. niektóre alarmy, systemy telemetryczne), więc obowiązują zasady współistnienia i limity użytkowania.
Regulacje wynikają z norm ETSI (głównie EN 300 220) oraz krajowych przepisów dotyczących urządzeń małej mocy w pasmach ISM. W praktyce, projektując prywatną sieć LoRaWAN, trzeba brać pod uwagę:
- dostępne podzakresy częstotliwości w EU868,
- maksymalną moc nadawczą (EIRP),
- obowiązek stosowania duty cycle lub mechanizmów LBT (Listen Before Talk).
Moc nadawcza, kanały i przestrzeganie duty cycle
Dla typowych kanałów LoRaWAN w EU868 maksymalna moc EIRP wynosi 14 dBm. EIRP uwzględnia zysk anteny i straty na kablu, więc przy stosowaniu anten o dużym zysku nie da się „dokładać” mocy w nieskończoność. Gatewayy przemysłowe mają zwykle możliwość ustawienia mocy wyjściowej tak, by z kompensacją strat na kablu nie przekraczać dopuszczalnego EIRP.
Duty cycle to procent czasu, w którym nadajnik może być aktywny na danej częstotliwości. Dla popularnych podzakresów EU868 (np. 868.0–868.6 MHz) wynosi on 1%. Oznacza to, że w ciągu godziny nadajnik może nadawać łącznie 36 sekund na danym kanale. W przypadku LoRaWAN ograniczenie to dotyczy zarówno urządzeń końcowych, jak i gatewaya (dolny i górny tor). Mechanizmy LoRaWAN (ADR, odpowiedni dobór SF i długości ramek) pomagają utrzymać ruch w granicach normy, ale projektant sieci powinien uwzględniać duty cycle na etapie planowania:
- liczby urządzeń w danej komórce sieci (zasięgu gatewaya),
- częstotliwości wysyłania ramek (interwałów raportowania),
- możliwych retransmisji i downlinków (zdalna konfiguracja, potwierdzenia).
Ignorowanie obowiązujących limitów może prowadzić do zatykania pasma (kolizje ramek, utrata danych) oraz do formalnych konsekwencji – urządzenia radiowe muszą spełniać wymagania zgodności (CE, ETSI), a przeciążona prywatna sieć może stać się źródłem zakłóceń dla innych użytkowników ISM.
Propagacja 868 MHz w mieście – co robią budynki i kanaliki
Często powtarzana opinia „LoRaWAN ma zasięg do kilkunastu kilometrów” pochodzi z testów w terenie otwartym. Miasto rządzi się innymi prawami. Częstotliwości ~868 MHz mają lepszą zdolność przenikania przez przeszkody niż Wi‑Fi 2,4 GHz, jednak gęsta zabudowa, szkło, metal i żelbet skracają zasięg w dramatyczny sposób.
Elementy, które najmocniej wpływają na zasięg w mieście:
- Wysokość montażu anteny – im wyżej, tym większa strefa Fresnela i mniejsza liczba przeszkód; gateway na 20–30 m wysokości „widzi” znacznie więcej niż na 5 m.
- Materiały budowlane – żelbet, metalowe konstrukcje, fasady z metalizowanym szkłem potrafią niemal „odciąć” sygnał.
- „Kaniony uliczne” – między wysokimi budynkami fale radiowe odbijają się i tłumią; niektóre miejsca są zaskakująco „głuche”.
- Wnętrza budynków i piwnice – sygnał „wchodzi” przez okna, szyby i otwory; urządzenia w piwnicach albo w metalowych szafkach licznikowych wymagają odpowiedniego planowania SF i mocy.
Znajomość ograniczeń propagacji na 868 MHz, połączona z respektowaniem duty cycle, jest kluczowa dla uniknięcia „dziur zasięgu” i późniejszych prób ratowania sytuacji przez chaotyczne dokładanie kolejnych gatewayów.
Architektura sieci LoRaWAN: jak układają się klocki
Warstwa urządzeń, gateway, network server i application server
LoRaWAN opiera się na architekturze gwiazdy typu star-of-stars. Urządzenia końcowe nie komunikują się między sobą, a jedynie z gatewayami. Gateway może odebrać tę samą ramkę co kilka innych gatewayów jednocześnie – dlatego potrzebny jest centralny komponent, który to ogarnie.
Podstawowe elementy architektury:
- Urządzenia końcowe (node’y) – generują dane (np. pomiary) i okresowo nadają ramki uplink. Nie mają wiedzy o topologii sieci; wysyłają, a kto odbierze – to już sprawa warstwy wyżej.
- Gatewaye – zawierają koncentrator LoRa (np. SX1302/1303) i komputer sterujący (Linux, router). Odbierają i czasem nadają ramki LoRaWAN, ale nie podejmują decyzji typu „do którego serwera to przesłać” na podstawie logiki LoRaWAN – robią prosty forward do network servera (UDP, MQTT, HTTP).
- Network server (NS) – serce sieci; przyjmuje ramki z wielu gatewayów, deduplikuje je, dekapsuluje, sprawdza MIC, obsługuje join’y, zarządza sesjami i kluczami.
- Application server (AS) – po stronie aplikacyjnej dekoduje payload (np. CBOR, JSON w LoRa payload), realizuje logikę biznesową lub forwarduje dalej (MQTT, HTTP, AMQP).
Klasy urządzeń: A, B, C i ich zastosowanie w mieście
LoRaWAN definiuje trzy klasy urządzeń:
- Klasa A – każde urządzenie otwiera dwa krótkie okna downlink po swoim uplinku; najmniejszy pobór energii, idealna do czujników bateryjnych. Domyślna i najbardziej zalecana klasa w większości przypadków.
- Klasa B – dodatkowe zsynchronizowane „beacony” z gatewayów pozwalają na przewidywalne okna downlink; przydatna tam, gdzie trzeba częściej „zawołać” urządzenie, ale nadal chronić baterię.
Strategie bezpieczeństwa i zarządzania kluczami w prywatnej sieci
W pewnej gminie ktoś wgrał na serię czujników ten sam klucz sieciowy „na szybko, bo pilnie trzeba montować”. Po roku nikt nie pamiętał, kto ten klucz zna, a kilku podwykonawców dawno nie pracuje przy projekcie. W teorii sieć była „szyfrowana”, w praktyce pełna niepewnych zaufanych.
LoRaWAN z definicji jest szyfrowany, ale poziom bezpieczeństwa zależy od tego, jak wygląda proces zarządzania kluczami i dostępami. W prywatnej sieci w mieście granica odpowiedzialności nie kończy się na bramce – dochodzi łańcuch integratorów, instalatorów, administratorów systemów nadrzędnych.
- ABP vs OTAA – do nowych wdrożeń miejskich wybiera się OTAA: dynamiczne sesje, możliwość rotacji kluczy i centralne zarządzanie. ABP ma sens tylko w bardzo specyficznych, zamkniętych scenariuszach.
- Przechowywanie root key (AppKey, NwkKey) – klucze nie powinny leżeć w arkuszu Excela ani w kodzie firmware na stałe. Używa się bezpiecznych magazynów (HSM, secure element w urządzeniu, menedżer haseł z kontrolą dostępu).
- Oddzielenie ról – instalator terenowy nie potrzebuje widzieć root key; wystarczy, że ma QR‑kod z identyfikatorem urządzenia i tokenem do systemu provisioningowego.
- Rotacja i odwoływanie urządzeń – sieć miejska żyje: jedne czujniki są zdejmowane, inne giną, część wraca z serwisu. Network server musi mieć procedury: blokada urządzenia, wygaszenie sesji, możliwość „zapomnienia” klucza.
Bez uporządkowanego podejścia do kluczy prywatna sieć bardzo szybko zamienia się w bałagan, w którym każdy „jakoś coś ustawia”, ale nikt nie ma pełnej kontroli nad tym, kto naprawdę ma dostęp do ruchu radiowego i danych.
Monitoring, logowanie i obserwowalność ruchu
W pewnym momencie ktoś dzwoni: „czujniki z dzielnicy X przestały raportować”. Jeśli jedynym narzędziem jest login do panelu integratora, diagnoza trwa wieki. W prywatnej sieci wszystkie warstwy mogą być widoczne – pod warunkiem, że się je monitoruje.
Kluczowe obszary obserwowalności:
- Gatewaye – status połączenia z NS, obciążenie CPU, liczba ramek uplink/downlink, RSSI/SNR z ostatnich raportów; proste metryki publikowane np. do Prometheusa.
- Warstwa LoRaWAN – join success rate, ilość retransmisji, rozkład SF, częstość ADR adjust, liczba kolizji (wnioskowana po błędach CRC).
- Warstwa aplikacyjna – opóźnienie między pojawieniem się ramki na NS a zapisaniem rekordu w systemie nadrzędnym, liczba błędów dekodera payload.
Nawet prosta tablica „heatmapy” zasięgu i jakości sygnału w mieście, aktualizowana na bazie realnych raportów, daje szybką odpowiedź, czy problem leży w radiu, gatewayu, czy na etapie przetwarzania danych.
Projektowanie polityki ADR i profili urządzeń
W wielu wdrożeniach włącza się ADR „z pudełka” i liczy na to, że „jakoś się dopasuje”. W mieście z ruchem z wielu typów czujników takie podejście łatwo prowadzi do przeciążenia niektórych kanałów i SF‑ów.
Dobry punkt wyjścia to podział urządzeń na kilka profili ruchu:
- Profil „miasto statyczne” – wodomierze, liczniki ciepła, sensory w piwnicach; wysoki SF (SF10–12), interwał raportowania rzędu godzin, niewielka liczba downlinków (głównie konfiguracja).
- Profil „miasto dynamiczne” – parkingi, czujniki zajętości, outdoor; średnie SF, raportowanie co kilka minut, okresowe zdalne aktualizacje ustawień.
- Profil „near real-time” – np. krytyczne alarmy, wybrane sterowania; możliwe klasy B/C i ostrożnie planowane okna downlink, ograniczenie liczby urządzeń w tej kategorii.
Dla każdego profilu network server może mieć inne parametry ADR (np. minimalny i maksymalny SF, targetowany poziom SNR). Dla wielu miejskich wdrożeń lepszy efekt daje konserwatywne podbicie SF w trudnych lokalizacjach niż agresywne „ściskanie” do SF7 na siłę.
Planowanie miejskiego zasięgu: lokalizacja gatewaya i anten
Wysokość, prawo budowlane i dostęp serwisowy
W teorii „im wyżej, tym lepiej”, ale na dachu 18‑piętrowca ktoś musi wejść w styczniu o świcie, żeby zrestartować zasilacz albo wymienić PoE. Dla miejskiej sieci dobry kompromis leży zwykle między „maksymalnym możliwym dachem” a budynkiem, do którego jest łatwy dostęp techniczny.
Przy wyborze lokalizacji trzeba pogodzić kilka osi:
- Wysokość – powyżej linii dachów sąsiednich budynków, ale bez skrajności, które komplikują logistykę i formalności (dźwigi, specjalne uprawnienia).
- Dostęp serwisowy – legalne wejście, klucze, rejestr osób, brak konieczności wzywania dwóch ekip za każdym razem, gdy trzeba coś sprawdzić.
- Zasilanie i łączność – sensowny punkt poboru energii (zabezpieczony obwód) i miejsce na router LTE/światłowód; bez przedłużaczy „na krzyż” przez korytarze techniczne.
- Uzgodnienia formalne – zgody zarządcy, ewentualne zgłoszenie w urzędzie, jeśli konstrukcja antenowa przekracza określone w prawie parametry.
Lepiej mieć dobrze obsadzony „średni” dach w centrum, niż idealny zasięg z jednego wieżowca, do którego nikt nie może wejść przez pół roku z powodu remontu elewacji.
Modele pokrycia miasta: jeden wysoki punkt czy kilka niższych
Dwa popularne podejścia do sieci w mieście to „latarnia morska” (jeden lub dwa bardzo wysokie punkty) oraz „tkanka miejska” (kilka lub kilkanaście gatewayów na średnich wysokościach). Wybór zależy od scenariusza.
- Latarnia morska – świetna do zbierania telemetrii z rozproszonych obiektów (wodomierze gminne, stacje meteo, syreny alarmowe). Prosta architektura, mniejszy CAPEX, ale gorsza odporność na awarie pojedynczego punktu.
- Tkanka miejska – większe nakłady, ale lepsze pokrycie „do środka budynku”, łatwiejsze planowanie klas B/C, możliwość stopniowego dogęszczania tam, gdzie ruch jest największy.
W praktyce często wychodzi hybryda: jeden wysoki gateway „międzygminny” plus kilka miejskich punktów dogęszczających zasięg w krytycznych rejonach, np. stara zabudowa z grubymi murami, tunele, okolice dużych węzłów transportowych.
Wybór anten: zysk, charakterystyka i środowisko miejskie
Anteny w LoRaWAN bywają traktowane jak „dodatek do pudełka”. A to one decydują, czy czujnik w piwnicy starej kamienicy „dogada się” z gatewayem na dachu ratusza. W mieście szczególnie ważny jest kompromis między zyskiem anteny, jej charakterystyką i realnym środowiskiem.
- Zysk (dBi) – anteny 2–6 dBi są zwykle wystarczające; bardzo wysokie zyski powodują spłaszczenie charakterystyki w pionie, co w mieście może „przestrzelić” nad pobliskimi budynkami.
- Charakterystyka promieniowania – im wyżej montujemy antenę, tym ważniejsze jest, jak opada główny list w dół. Zbyt wąska wiązka pionowa sprawi, że świetnie „widzimy” przedmieścia, ale nie parterowe lokale w centrum.
- Odporność mechaniczna i IP – miasto to wiatr, smog, ptaki, czasem wandalizm. Antena z IP65 i solidnym mocowaniem przetrwa więcej niż delikatny „patyk” na cienkim uchwycie.
Często więcej daje poprawny montaż i wymiana taniego kabla koncentrycznego na lepszy z mniejszym tłumieniem niż dokładanie kolejnych decybeli zysku anteny.
Kable, złącza i straty na torze antenowym
Scenariusz powtarza się regularnie: świetna antena, dobry gateway, a zasięg marniutki. Po sprawdzeniu instalacji okazuje się, że ktoś połączył wszystko długim odcinkiem cienkiego kabla z dwoma przejściówkami po drodze.
Kilka prostych zasad projektowania toru antenowego:
- Minimalizacja długości kabla – gateway jak najbliżej anteny, nawet jeśli oznacza to montaż w skrzynce na dachu i doprowadzenie tylko Ethernetu/światłowodu.
- Dobór typu kabla – dla dłuższych odcinków używa się kabli o mniejszym tłumieniu (np. LMR‑400 zamiast RG‑58). Tłumienie jest funkcją długości i częstotliwości, nie warto na tym oszczędzać.
- Jakość złączy – szczelne, dobrze zaciśnięte złącza (N, SMA) z dodatkowymi osłonami UV; źle zaciśnięte złącze to nie tylko strata sygnału, ale i źródło odbić.
- Ochrona przeciwprzepięciowa – w rejonach o częstych wyładowaniach stosuje się odgromniki gazowe w torze antenowym oraz dobre uziemienie masztu.
Sumaryczna strata na torze antenowym (kabel + złącza) wchodzi do bilansu mocy EIRP. Zbyt duże straty zmarnują część dopuszczalnej mocy, a zbyt małe, przy bardzo wysokim zysku anteny, mogą przekroczyć limity regulacyjne, jeśli nie skoryguje się mocy nadajnika.
Wybór sprzętu: gateway, koncentrator, komputerek, anteny i akcesoria
Rodzaje gatewayów: indoor, outdoor i „DIY na malinie”
W jednym z projektów pilotaż zaczął się od gatewaya DIY na Raspberry Pi wpiętego w parapet serwerowni. Działało to zaskakująco dobrze… do pierwszej awarii prądu i przegrzania latem. Przejście na sprzęt outdoor z PoE i sensownym chłodzeniem zaoszczędziło wielu nerwów.
W praktyce spotyka się trzy główne kategorie gatewayów:
- Indoor – małe, zintegrowane urządzenia z dołączoną anteną; dobre na start, do testów lub jako bramka pokrywająca jeden budynek/kampus. Ograniczona odporność środowiskowa.
- Outdoor przemysłowe – obudowy IP65/67, szeroki zakres temperatur, zasilanie PoE lub DC, często wbudowany router LTE. To podstawowy wybór dla miejskich dachów i masztów.
- DIY – koncentrator mini‑PCIe + mały komputer (Raspberry Pi, RPi CM, x86), wszystko w własnej obudowie. Elastyczne i tańsze w hardware, ale kosztuje czas: projekt zasilania, osłona przed warunkami, własny serwis.
Do stałej sieci miejskiej stosuje się głównie gatewaye outdoor, zostawiając DIY na laboratorium, prototypy i nietypowe lokalizacje (np. wewnątrz szafy sterowniczej, gdzie gotowy gateway się nie mieści).
Koncentratory LoRa: SX1301 vs SX1302/1303 i ich konsekwencje
Serce gatewaya stanowi koncentrator LoRa – układ zdolny do równoczesnego odbioru wielu ramek w różnych SF na wielu kanałach. W nowszych generacjach poprawiła się nie tylko liczba kanałów, ale też energochłonność i czułość.
- SX1301 – starsza generacja, często spotykana w tańszym sprzęcie lub w DIY; działa, ale ma większy pobór mocy i ograniczenia przy dużych gęstościach ruchu.
- SX1302/1303 – nowsze układy, lepsza czułość, niższe zużycie energii, wsparcie dla nowszych funkcji; preferowane do nowych wdrożeń w mieście.
- Moduły „full size” vs kompakty – duże koncentratory na płybach PCIe/mini‑PCIe ułatwiają serwis (wymiana modułu), ale wymagają lepszego chłodzenia; kompaktowe moduły w pełni zintegrowanych gatewayach są mniej elastyczne, za to proste w użyciu.
Przy większych projektach warto ujednolicić generację koncentratorów, żeby nie mieć potem kilku profili firmware i odmiennych zachowań w jednej sieci.
Komputer sterujący: od routera MIPS po x86 z Linuxem
Koncentrator sam w sobie nie wysyła ramek do network servera – robi to komputer sterujący. Producenci gatewayów integrują go w różny sposób: czasem to prosty router na MIPS, czasem pełnowartościowy mini‑komputer x86 z Linuxem.
Przy doborze platformy zwraca się uwagę na:
- Stabilność i wsparcie systemu – lepiej mieć Debian/Yocto z regularnymi aktualizacjami niż egzotyczny firmware, który „zamarza” po dwóch latach.