Först och främst, jag hatar att klä på mig televerksoverallen, men jag gör det av och till och jag gör det nu. En återkommande diskussion är om LoRaWAN kan ha en garanterad upptid. I många fall efterfrågas detta och det kallas då SLA. Jag hävdar att det inte är realistiskt, och det kan kännas hårt om man gillar LoRaWAN. Jag skrev om det i ett blogginlägg om SIGFOX nyligen och har fått reaktioner på det. Låt mig inleda med att säga att LoRaWAN är en intressant teknik, oavsett detta med SLA, men SLA-utfästelser för LoRaWAN-nät förstår jag inte riktigt riktigt hur man kan göra.
Bakgrund
För att sätta det hela i en kontext, jag började i branschen 1994 med att trådlöst koppla upp bland annat pumpstationer i olika VA-system. Då byggde vi privata radionät på 439 MHz-bandet. Dessa behövde inga tillstånd, det var fria frekvenser, så det var bara att tuta och köra. Samtidigt nådde signalen långt och det dröjde inte länge innan Sverige var så bebyggt, för vi sålde bra, att det blev överhörning mellan olika system. Vi hade en grym dragkraft i att det var billigt att installera radio, billigt att drifta och det var hög pålitlighet. Men, PTS tvingades införa restriktioner kring masthöjd för att minska överhörningen, och senare så blev det så att man allt mer flyttade trafiken till licensierat spektrum på 370-380 MHz. Branschen var tvungen att självsanera sig.
Det är en gammal historia, mer än 25 år gammal. Men det jag lärt mig av det, genom praktiska erfarenheter, är att fritt spektrum är fritt spektrum. Det är nästan laglöst RF-land. Det man behöver förhålla sig till är sändningscykler och uteffekter. Vi förhöll oss rätt till alla dessa. Ändå gick det kanske litet över styr.
De nät som sätts upp idag för liknande syfte använder licensierade frekvenser, frekvenser som kräver tillstånd, och som bevakas och åtgärdas av PTS om någon stör på bandet. Detta när det gäller egna radionät, för LoRaWAN är det tvärt om.
Vad har detta med LoRaWAN att göra?
LoRaWAN vinner mark, och det är en spännande teknik, absolut. Men man måste veta vad man köper och varför. Jag förstår dem som vill testa på även om jag ser applikationer som är lämpliga för LoRaWAN och andra som är mindre lämpliga.
Frekvensband och SLA
Jag hävdar att de allra flesta SLA-er för LoRaWAN är skrivna så att man garanterar basstationens tillgänglighet att ta emot meddelanden och skicka dem vidare till en molntjänst. Men det omfattar inte frekvensen.
Ett genomtänkt SLA bör väl omfatta nätverks- och plattformstillgänglighet, täckning på positionsnivå och platsnivå samt prestandakriterier på applikationsnivå åtminstone tänker jag. Det stora problemet jag har med att skriva ett sådant SLA för LoRaWAN är radiofrekvensen.
Vad gäller frekvensen för LoRaWAN finns tre stycken som mest används, dessa ligger inom 868,0–868,6 MHz området. Bandet är avsett för “Radiosändare för ospecificerat tillämpningsområde”. Sändningscykel: < 1 % och 25 mW uteffekt (definitionen av sändningscykel: den genomsnittliga sändningstiden under en viss tidsperiod (maximalt en timme) uttryckt i procent av denna period). Detta innebär att om du rent teoretiskt sätter upp ett nät med 100 sändare som delar tiden sig emellan, på en fri kanal, så har du blockerat bandet. Och det här behöver inte betyda att det är en annan LoRa-sändare man har att göra med. Utan detta kan vara vilken tillämpning som helst som dyker upp på marknaden i morgon som vill använda bandet. Det finns inga garantier, och det finns ingen du kan ringa och klaga till om kanalen är blockerad.
Densitet
Med LoRa har du en lång räckvidd, det är en av poängerna. Nackdelen är att det inte går att förtäta på samma sätt som ett mobilnät, alltså är det svårare att skala. När operatörerna av mobilnäten byggt yttäckning, så behöver man förtäta. Det gör man genom att använda frekvenser som skickar signalen kortare sträckor. Här finns ingen plan B med LoRaWAN. När frekvensen är full, med LoRaWAN eller annat, så är det fullt. Som försvar till LoRaWAN så är sändningstiden kort och inte så frekvent. Men kommer en annan användare in på kanalen, då hjälps det inte, det går inte att flytta till en annan frekvens som plan B.
Enterprise IoT
För att kunna bygga en riktig enterprise IoT-lösning, vilket är en av de grupper som främst efterfrågar SLA tänker jag, behöver LoRaWAN-nätverken nå operatörsklass. Många pratar om en upptid på 99,999%. Det handlar också om en garanterad kvalitet, en övervakning om vad som händer i nätet genom övervakning av kanalen, det handlar om att garantera nätverkstäckning. Kommersiella tillämpningar för kritisk infrastruktur och andra viktiga behov kan inte nås genom en täckningskarta som visar var basstationer finns, utan att faktorisera in att kanalen som används inte har garanterat spektrum. Att massivt skala IoT-tillämpningar kräver att näten är anpassade för det. Ett litet antal LoRaWAN-gateways som installeras på strategiska, höga platser runt om ger inte nätverkservice av operatörsklass för de flesta tillämpningar.
Är han ute och snurrar?
Så, det kan låta som att jag inte är påläst här, jag pratar ju mest om gamla radioerfarenheter och inte om LoRaWAN. Jag är varken en LoRaWAN-operatör eller en mobilnätsoperatör. Men när jag ställer frågorna till som är LoRaWAN-operatörer har jag hittills mötts av ointresse eller avfärdande att svara på frågorna. Mobiloperatörerna har alltid gett mig fakta. Så hur kan du och jag dra våra slutsatser då? En bra startpunkt är att läsa “Investigating the practical performance of the LoRaWAN technology” av Joakim Eriksson och Jonas Skog Andersen. Kapitel 2.5.1 LoRaWAN – Simulations, calculations and general discussion innehåller mycket fakta och rapporten avhandlar både störningar från andra tekniker på samma frekvensband, och kollisioner på banden från andra LoRa-nät.
Flera teser bekräftar mina teorier
Läser ni kapitel 2.5.1 så hittar ni referenser till åtskilliga rapporter, där man pekar på flera rapporter som bekräftar det jag säger. Ni kan ladda ned rapporten själva, men jag pekar framförallt på följande:
1. Frekvensproblematiken
Adelantado med flera skrev en artikel i IEEE Communications Magazine 55.9 (2017) “Understanding the Limits of LoRaWAN”. Författarna har försökt att skapa förståelse för LoRaWAN:s begränsningar. De drar slutsatsen att LoRaWAN står inför flera problem när det gäller den faktiska kapaciteten för storskaliga installationer. Det största problemet som författarna tar upp är just regulationerna om användning av frekvensbanden, vilket författarna menar begränsar nätverkskapaciteten och skalbarheten.
2. Densitet
Varsier och Schwoerer gör en simulation för att förstå hur många Gateways som behövs för att hämnta mätvärden i en smart mätarinsamlingsapplikation i Paris. Ett intressant resultat är att det skulle behövas 19 gateways för att uppnå en kvalitetsnivå på 98% när man försöker täcka ett område på 17 km2. En viktig reservation man gör för dessa simuleringar är att man gjort antagandet att det inte fanns någon annan extern trafik som störde i det simulerade området. Författarna menar att detta kan innebära att kvaliteten kan vara mycket sämre i ett verkligt scenario.
Snälla, fakta på bordet
Jag har haft långa diskussioner med exempelvis operatörer av LoRaWAN och fått besked om att vi har ett SLA på 99,8% exempelvis. Min motfråga då har varit, hur kan ni garantera det, när ni inte äger frekvensen? Jag har bett om papper, intyg, uträkningar på var denna SLA-uträkning kommer från. Jag väntar fortfarande på en vettig förklaring. Så om någon kan ge mig den, är jag mer än glad. Jag kan ha fel i min tes. Jag lovar att skriva en ny bloggpost som uppföljare i så fall. Men tills dess att någon förklarar för mig hur en fri frekvens, fri för alla, kan ha en angiven SLA så står jag fast vid det jag säger. Nu åker televerksoverallen av igen.