Inside the LoRaWAN Protocol: Classes & Frames

The three-lot parking prototype in part one used the simplest topology that could work: a couple of transmitters talking directly to one receiver. But researching that project meant going deep into the LoRaWAN standard — the protocol that governs how you'd take "three sensors and a receiver" and turn it into a real network serving a whole city. This post is what that research surfaced: the network architecture, the device classes, the frame design, and the battery-life math that makes LoRaWAN worth learning even when your own prototype is simpler than the full spec.

Why star-of-stars beats mesh for battery-powered sensors

Plenty of existing wireless sensor deployments use a mesh topology — every node forwards its neighbours' traffic to extend range. It works, but it taxes exactly the resource battery-powered sensors can least afford: every node now spends energy receiving and relaying data that's often irrelevant to it.

LoRaWAN instead uses a star-of-stars: end nodes talk directly to any gateway in range (never to each other), gateways forward everything to a central network server, and the server does the hard thinking. A node never wakes up to relay a stranger's packet — it wakes up, says what it has to say, and goes back to sleep. That single architectural choice is most of why LoRaWAN nodes are reported to run for years on one battery.

NODE ──radio──▶ GATEWAY ──backhaul──▶ NETWORK SERVER ──▶ APPLICATION SERVER ──▶ your app
 (sensor)        (relay, adds          (dedup, security,      (decrypt payload,
                  SNR/RSSI)             scheduling, ADR)        business logic)

• Node — the sensor itself: battery, radio, and whatever it's measuring.
• Gateway — hears uplinks from every node in range and forwards them upstream, typically tagging each packet with signal quality metadata (SNR, RSSI) but not interpreting the payload.
• Network server — the brain: filters duplicate packets (multiple gateways often hear the same transmission), checks device legality, schedules acknowledgements, and applies adaptive data rate.
• Application server — decrypts and processes the payload, exposing it to whatever dashboard or API consumes it.

A node isn't bound to one gateway — several gateways typically hear the same uplink, and the network server picks the best one to answer through. That also means a moving node needs no handover between gateways, unlike a cellular phone crossing cell towers — genuinely useful for asset-tracking, and a hint at how a parking network could extend to tracking mobile assets, not just fixed lots.

The battery-life trick: don't synchronise, just talk

Cellular and mesh networks generally need nodes to periodically wake up and check in with the network just to stay synchronised — and that synchronisation, not the actual data transmission, is usually the biggest drain on a battery. LoRaWAN nodes instead use an Aloha-style asynchronous protocol: a node transmits only when it actually has something to say, whether that's triggered by an event or a schedule it keeps entirely to itself. No handshake, no check-in, no idle synchronisation tax. Independent industry comparisons of LPWAN technologies have put LoRaWAN's battery-life advantage at 3 to 5 times other options specifically because of this.

For a parking sensor, that maps directly onto the design from part one: a slot doesn't change state very often, so a node that only transmits when the flag actually flips — plus an occasional keep-alive — burns a fraction of the energy a "check in every few seconds" design would.

Not all nodes are created equal: device classes A/B/C

LoRaWAN defines three device classes, and the choice between them is a direct trade-off between downlink latency and battery life:

• Class A — the default, lowest-power option. After every uplink, the node opens two brief downlink receive windows and then goes silent until it next has something to say. If the server wants to talk to the node at any other time, the message waits in a queue until the node's next uplink. Perfect for sensors that mostly report outward.
• Class B — adds scheduled receive windows on top of Class A, synchronised by a time-beacon from the gateway. The server now knows specific times the node is listening, trading some battery life for lower, more predictable downlink latency.
• Class C — the node's receiver is open almost continuously, closing only to transmit. Lowest possible latency, at the cost of being the most power-hungry class — realistically a mains-powered actuator, not a battery sensor.

A vacancy sensor that only needs to report its own state is a textbook Class A device. A barrier gate that needs to react to a remote "open now" command in real time is a Class C candidate. Choosing the class isn't a technicality — it's deciding what your device is actually for.

Frame design: small payloads, dense meaning

LoRaWAN payloads stay deliberately small — every extra byte costs airtime and battery, so the spec favours a bit-packed header over anything resembling a JSON blob. A researched uplink frame header fits this into a single byte:

A second byte carries a sequence number. That's it — one status flag, one battery flag, and a type tag, and the network already knows everything it needs. Uplink frame types typically include a start-up frame (sent once on boot, expecting the server to reply with a synchronised clock), an info frame whenever the tracked state actually changes, a periodic keep-alive proving the node is still alive even when nothing changed, and an RTC update request sent roughly once a day to resync the node's clock against server time. Downlink frames mirror this with a configuration frame (push new parameters to the node) and an RTC sync frame (the mandatory reply to a start-up or clock-update request).

Applied to the part-one design, this reframes the flat "flag + lot name" payload as something that scales: a status bit, a battery bit, and a frame-type tag turn a single sensor reading into a self-describing packet a network server can route, deduplicate, and monitor for free.

Night-mode: adjusting the sleep interval to the world, not the clock

One of the more elegant power-saving patterns in the researched node design is night-mode: a second, independently configurable sleep interval, switched on for a set number of hours per day. A day-mode sleep of one minute becomes a night-mode sleep of ten minutes from, say, 9 PM to 7 AM — because a parking slot changes state far less often overnight, checking it as frequently is wasted battery. The name is a slight misnomer: the mode is really "the interval expected to have less activity," and for some deployments — a slot near an office, say — that quiet window might fall during the day.

The broader lesson generalises well beyond parking: if you know your event rate varies predictably, let your poll rate vary with it. A fixed sensing interval is the easy default; a context-aware one is where the real battery savings live.

Security: two layers, so no single party sees everything

LoRaWAN separates network-layer security from application-layer security, both built on AES with key exchange anchored to an IEEE EUI-64 device identifier. Network-layer security proves a packet genuinely came from a registered device; application-layer security means the payload itself is opaque to everyone except the application server that holds the application key — including, notably, the network operator. That separation matters the moment your network infrastructure and your application aren't run by the same party, which is the normal case for any commercial LoRaWAN deployment.

Common pitfalls

1. Building a Class C battery sensor. If a node needs to sleep for years on a coin cell, Class A is almost always the right default — Class C is for devices that don't mind staying awake.
2. Fat payloads. LoRaWAN rewards small, bit-packed frames; sending verbose text payloads burns airtime, battery, and against real gateways, your fair share of duty-cycle limits.
3. No keep-alive frame. Without one, a network server can't distinguish "nothing changed" from "this node is dead" — both look identical: silence.
4. Ignoring adaptive data rate. A node close to its gateway that always transmits at the lowest data rate holds the channel far longer than it needs to, crowding out other nodes — let the network push it to a faster rate.
5. One security layer instead of two. Relying only on network-layer auth means your network operator can read every payload — fine for a single-party deployment, a liability the moment it isn't.

FAQ

Interested in LoRaWAN, IoT networks, or a full-stack build in Dubai, UAE? Get in touch.