LoRaWAN Technology
LoRaWAN. Not to be confused with LoRa. This one’s the brain on top – the protocol layer that tries to make LoRa useful. Still LPWAN. Still low power, low bandwidth. But adds things like addressing, security, and network logic. Kinda messy, but it brings structure to chaos. It’s not perfect. Nothing is. But hey – cows and parking sensors love it.
Vendor and URL
This lovely protocol soup is pushed by:
Main vendor: LoRa Alliance (yeah, it’s a whole cartel)
Official docs: https://www.lora-alliance.org
If the link’s dead, congrats – you’ve entered vendor purgatory. Not my fault.
Technical Public Documentation
They’ve got docs. So many docs. Versions galore. Updates that change how stuff works mid-flight. You want the good stuff? Look here:
Full spec: LoRaWAN Specifications
GitHub repo: https://github.com/Lora-net
Warning: some repos are abandoned wastelands. Dig wisely.
Overview
LoRaWAN is the protocol stack that sits on top of LoRa. Think of it like TCP/IP for a lazy, half-deaf, ultra-low-power radio. Devices send tiny packets to gateways, which forward them to network servers. Useful when you care more about battery life than latency or speed.
Architecture
Three core parts: end devices (the sensors), gateways (the dumb pipe), and the network server (the traffic cop). Gateways don’t care what they forward. They just vomit RF into the internet. Then there's an application server somewhere, trying to make sense of it all. Star topology. No mesh. Mesh is for hipsters and Zigbee fans.
Device Roles
No routers. No coordinators. Just nodes (end devices), gateways (packet forwarders), and servers (the brains). End devices come in three flavors: Class A (asleep most of the time), Class B (scheduled check-ins), and Class C (wide awake and battery-hungry). Choose your own death.
Channelization
LoRaWAN works over ISM bands – unlicensed, noisy, chaotic. Channels vary by region. EU has 868 MHz, US gets 915 MHz. Devices pick channels based on regional rules, and servers can force changes if they’re feeling bossy. Also: duty cycles. Meaning you can only talk a few seconds per hour. Enjoy the silence.
Frames
LoRaWAN frames are tight. Like a budget airline seat. You've got MAC headers, frame control, frame counter, optional MAC commands, payload, and a MIC for security. You get about 51 bytes payload if the stars align. Bigger packets? Forget it. Fragmenting is for optimists.
Networking
It’s not peer-to-peer. It’s all star topology. Devices send uplinks. Downlinks happen only when the stars, servers, and duty cycles agree. Devices join via OTAA (Over-the-Air Activation) or ABP (Activation by Personal Pain). IPv6? Nope. It’s all proprietary addressing with DevEUIs, AppEUIs, and NetIDs.
Security
AES-128 is baked in. One set of keys for network stuff, another for app payloads. OTAA is safer – generates fresh session keys every time. ABP is for the lazy and the brave. MIC checks help reject garbage. But if you store your keys in plain text – you deserve what’s coming.
Networking Process
Device wakes up. Tries to join. If OTAA, it sends a join request and waits. If the network likes it, it gets keys and a join accept. Then it sends data. Downlinks? Rare. Expensive. Only happen in the device's receive windows. Otherwise, it’s sleep mode and prayers.
Use Cases
Used in smart cities (whatever that means), agriculture (soil sensors, cow trackers), smart meters (gas, water, electricity), asset tracking (sometimes works), and anything that doesn’t mind delays or lost packets. Not great for critical stuff. But fine if your packet arrives eventually... maybe.