LoRaWAN specificationen er vel den som frit kan hentes fra LoRAWAN Alliances hjemmeside <a href="https://lora-alliance.org/resource-hub/lor..">https://lora-alliance.org…;.

Det er kun lag 2 og opefter i OSI modellen - altså de lag, som er nødvendige for at kunne bruge diverse IC'er. Lag 1 - physical layer, som er det specielle i LoRaWAN med den særlige spread-spectrum chirp modulation, omtales ikke, og i application note AN1200.22 LoRa, som kan downloades her: https://semtech.force.com/DP , hvis man opretter eller har en konto, kan man læse følgende:

LoRa is a <strong>proprietary</strong> spread spectrum modulation scheme that is derivative of Chirp Spread Spectrum.

Indtil én eller anden viser mig, hvor man kan downloade eller købe specifikationen til lag 1, vil jeg stadig påstå, at LoRaWAN er en lukket, proprietær standard, som de også selv skriver!

Der er en slåfejl i ovenstående indlæg. Det er ikke 500 men 5000 der er antallet motes i et net, unskyld.

Et af kravene for åbne standarder, hvad enten det er europæiske ( EN xxx), Internationelle ( ISO/IEC xxxx) eller internet (RFC xxxx) er at IP (intellectual Properties) skal være tilgængelig på "fair, reasonable, and non-discriminatory" (FRAND) eller "free" betingelser. Mig bekendt er IP for selve LoRa protokollen dækket af et patent der ejes af Semtech og jeg har ikke set tegn på at disse rettigheder skulle være tilgængelige på FRAND eller "free" betingelser.

LoRaWAN kan dække et stort område med en enkelte central mast. Spørgsmålet er dog om hvor mange enheder (motes) der kan håndteres på en gang. Artiklen "On the limits of LoRaWAN Channgel Access" fra "2016 International Conference on Engineering and Telecommunication" har forsøgt at analysere det. Her er de kommet frem til at et net med 500 motes er begrænset til omkring 2 pakker om dagen. For at undgå "tommelfinger ned" så ja, artiklen ligger bag en paywall. Hvis dette er bare rimligt korrekt så giver det nogle alvorlige begrænsninger i den praktiske størrelse af nettene.

LoRaWAN specificationen er vel den som frit kan hentes fra LoRAWAN Alliances hjemmeside https://lora-alliance.org/resource-hub/lorawanr-specification-v103

Cibicom har satset på den <strong>åbne standard</strong> LoRaWAN, som sender data i det ulicenserede frekvensspektrum.

For ikke så længe siden var protokollen absolut ikke åben, og de teams, der har prøvet at "reverse engineere" LoRaWAN - se bl.a. https://www.tlab.gr/reverse-engineering-lora-phy/ , har opdaget, at den praktiske implementering ikke engang følger de relativt få konkrete data, det er muligt at få fat i.

Mig bekendt er/var det en proprietær standard sat af Semtech, og Microchip kan nu også levere LoRaWAN chips; men er protokollen reelt set blevet åbnet og frigivet? Spørgsmålet har betydning for bl.a. Aarhus kommunes satsning på LoRaWAN - se: https://www.smartaarhus.dk/nyheder/smalbaand-i-aarhus-muliggoer-smart-city-loesninger, da det kan være på kant med EU's konkurrenceregler, hvis en offentlig myndighed satser på en standard, der ikke er åben, så konkurrenterne holdes ude.

Definitionen på en åben standard må være, at alle med de nødvendige tekniske kompetencer kan købe eller downloade en standard og så selv implementere den og være sikker på kompatibilitet, hvis standarden følges 100 %, som det er tilfældet med NB-IoT.

Den franske netværk Sigfox, der er en lukket proprietær protokol

Hele radiospecifikationen kan gratis downloades her: https://build.sigfox.com/sigfox-device-radio-specifications . Jeg har ikke studeret den godt nok til at kunne vurdere, om det er nok til en fuld implementering; men standarden er trods alt nok mere åben end LoRaWAN!

Fordi Sigfox i Europa sender over ISM-båndet på 868-878.6 MHz er det kun tilladt at sende 140 beskeder om dagen, altså lige knap seks gange i timen og hver besked må højest være på 12 bytes.

Ja, på upload; men der er kun 8 bytes på download fra net til enhed, så man kan ikke sende den samme datatype frem og tilbage, hvilket yderligere begrænses af, at der kun må sendes 4 download telegrammer pr. dag, som oven i købet kun har en 8-bit CRC, hvor upload har 16, så Sigfox er reelt set næsten en envejskommunikation. Det kan være OK til f.eks. en skraldespand, der bare skal melde fuld; men det er ubrugeligt til f.eks. procesovervågning, hvor man i tilfælde af en hændelse gerne vil kunne kommunikere yderligere med anlægget. Jeg forstår ikke, hvorfor man har begrænset sig sådan på downloadsiden og dermed afskåret sig fra en hel del anvendelsesmuligheder.