feature article
Subscribe Now

LoRaWAN Gets an Upgrade

A Look at Three New Features

Has it really been two and a half years? That’s how long it’s been since we did a round-up of the many contenders for low-power, wide-area wireless service. While I haven’t gone back to do a, “where are they now?” review, my suspicion is that winners are shaking out.

Of course, in this early stage of roll-out, a “winner” is, more or less, someone who’s still in the trenches fighting the good fight with the resources to be serious about that fight. One such protocol, LoRaWAN, recently issued an update to their protocol, and some of what they added makes for interesting discussion.

Before we take that on, however, we should pause, since you may think of this protocol as LoRa (or is it just me?). Well, it bears noting that the LoRa Alliance makes a big distinction between LoRa and LoRaWAN. LoRa refers only to the physical layer; the full protocol stack, layered above LoRa, is LoRaWAN. Which is why I’ve made sure to convert every subsequent “LoRa” reference in this piece to “LoRaWAN.”

Roaming Roaming Roaming

They’ve upgraded the roaming capability from passive to “hand-over.” In my original briefing with the LoRaWAN folks, the term “active” roaming was used, but I’ve since received clarification that the term “active” doesn’t apply (despite the obvious contrast with the prior “passive” roaming); it’s simply “hand-over roaming.“

Now… “roaming” may conjure up different things for different people – especially those who have been burned by excessive roaming charges on their cell phone bill. Likewise, the notion of hand-over may not be what you expect. So let’s pull this all apart, at the risk of describing some familiar things.

LoRaWAN is intended for internet-of-things (IoT) traffic, but it bears some resemblance to our ubiquitous cell phones. Any such wireless system can be assembled into a network by combining a series of antenna towers, along with backhaul capabilities and servers that keep track of the connections that are active. I know, that’s probably got to be the most over-simplified description of a wireless network ever, but let’s roll with it.

The idea of roaming originates out of the notion that you have your own “home” network that coexists with other networks. Of course, some of those other networks may be in the same place as the home network – just as there are with cell phones. But the home network might also have a physical limit. Cell phone coverage has gotten pretty complete (until you get rural), but coverage with IoT networks is much more limited. So you may run into the far reaches of your home network.

Roaming refers to the ability to establish or maintain a connection via a network that’s not your home network (I’ll refer to it as a “foreign” network). It’s essentially a long-distance call. And it may get billed as such: the cost of roaming seems to be set more by deals negotiated between network operators than by technical or equipment costs.

But the “hand-over” thing is confusing. With normal cell phones, your phone establishes a connection through a specific tower; as you move out of range of that tower and into range of another, your connection gets handed off, allowing you to remain mobile without killing the connection. This happens without your leaving your home network.

But LoRaWAN doesn’t work this way. You don’t get assigned to a specific tower; when your equipment transmits data (so-called up-link, since you’re sending up away from the equipment), you multi-cast to any towers in range. The server at the top of this arrangement receives all the signals from all the towers that saw the data and then de-duplicates to isolate the single packet. Simply put, the server is handling the MAC functions for the connection.

This way of doing things has a couple of benefits. For one, the multiple towers effectively act as diversity antennas, improving signal clarity overall. Second, it makes for tighter security, since taking one tower down doesn’t necessarily kill the connections going through that tower; the other towers effectively allow the network to be repaired.

Note that, for downlink, they look at the uplink metadata to decide which tower has the strongest signal for the end equipment, and then they downlink from that tower only (so no de-duplication is needed in the end equipment).

So, concisely put, there is no tower-to-tower hand-off with LoRaWAN. Things get more complicated, however, when you move beyond the range of your own network and into the range of a neighboring foreign network.

There is a certain amount of overhead in establishing a connection within a network. One item is security: encrypting the messages. That means setting up keys – and those keys are available only to the equipment and the network server for the duration of the connection. So the first clue that you’ve moved away from your current network – assuming another one is nearby and you haven’t gone totally out of range – is that you’re going to get a server error. That’s because the new network server can’t decrypt the data being transferred.

When this happens, data transmission pauses while a new connection is established with the new tower. Including new encryption keys. Once that’s all set up, then data transmission can resume. But with passive roaming, your packets still have to get to your home server – that server still owns the MAC functions. I’m probably fudging a bit on the details here, since this “new connection” thing sure feels like it would involve MAC stuff. So… don’t take me too literally here (or don’t take too many punches at me). (If it’s absolutely correct, on the other hand, then feel free to consider me brilliant. I’ll roll with it until proven otherwise… which might not take long…)


With hand-over roaming, the MAC handling can be handed to the foreign network directly. This simplifies the packet path, removing some significant hops.

I Know Where You Are

The next capability that’s been added is geolocation. It leverages the fact that LoRaWAN assigns no MAC address; it does the multi-cast thing we just discussed, and any tower within range can receive a message.

What’s changed is that a timestamp has been added to the packet, and that timestamp can be read by any tower in range. You can now, in theory, geolocate in three ways with varying specificity.

It’s possible to measure the distance only using just one tower; that tells you how far away a piece of equipment is, but not in which direction. You end up with the locus of points at the given distance from the tower – a sphere, interrupted by the earth.

Two towers give the locus of points both at one distance from one tower and the other distance from the other tower. You lose a degree of freedom, and the sphere collapses to a vertical circle – also interrupted by the earth.

Three towers give full triangulation, eliminating yet one more degree of freedom and nailing a point in space in three dimensions. In practical fact, it’s likely that many towers will get the signal, making the one- and two-tower scenarios mostly academic exercises.

A Class Act

Finally (at least in terms of the new features I’m focusing on), LoRaWAN now supports Class B radio service. Let’s unpack that.

Broadly speaking, there are three classes of service. And the key determiner of the most appropriate service for a given application is power – in particular, the RF receive power in an IoT device with a LoRaWAN connection.

The type of service we’re most used to is Class C: always on. It’s been available with LoRaWAN prior to the 1.1 version. Think of it as being like our cell phones, which are always on, whether or not we’re on a call or actively transferring data. This is needed for applications where data may need to be received by the end equipment at any time. The cost: the radio receiver must always be on so that it doesn’t miss anything while sleeping. And that chews up energy.

On the opposite end of the scale is Class A. You might think of this as the Queen’s class: speak only when spoken to. You could be forgiven for thinking that the server end of the connection would be in control of this, since, well, servers rule the world. But no, that actually wouldn’t make sense. With Class A, the end node – a sensor, for example – has some way of knowing when it’s time to send up data. When it transmits, it opens up a window for the server (or something beyond the server) to send data back.

The benefit here is that the receiver is almost always off, saving energy. There’s a known window where the receiver has to turn on, and when that window closes, the equipment can’t receive anything until the next transmit cycle. This class has also been available prior to the 1.1 edition.

With 1.1, we now get Class B service as well. This is a middle ground, opening up additional windows for the end node to listen for data. Now… you might think that this is simply a matter of scheduling. “Window for downlink every 10 minutes… starting… now!” Having synchronized watches, the server and end node trundle merrily along until the server is ready to send a really important message and… the end node isn’t listening.

Of course, that’s because clocks drift. And the longer they run their merry way, the farther apart they get. So what LoRaWAN adds in version 1.1 is a synchronizing beacon, which is sent by the gateway. That way, the server will have a better sense of when the end node is listening. Yes, clocks can also drift between beacon pings; that’s a margin/frequency thing that presumably gets baked into the protocol so that the clocks don’t drift so much that you miss.

The other good thing is that each ping is a resynchronization, so you don’t go for long times without zeroing out any accumulated clock drift. You start fresh with each ping.

So those are the big additions to LoRaWAN 1.1. You can get more detail at the link below.

More info:
LoRa Alliance

One thought on “LoRaWAN Gets an Upgrade”

Leave a Reply

featured blogs
Oct 20, 2020
In 2020, mobile traffic has skyrocketed everywhere as our planet battles a pandemic. Samtec.com saw nearly double the mobile traffic in the first two quarters than it normally sees. While these levels have dropped off from their peaks in the spring, they have not returned to ...
Oct 20, 2020
Voltus TM IC Power Integrity Solution is a power integrity and analysis signoff solution that is integrated with the full suite of design implementation and signoff tools of Cadence to deliver the... [[ Click on the title to access the full blog on the Cadence Community site...
Oct 19, 2020
Have you ever wondered if there may another world hidden behind the facade of the one we know and love? If so, would you like to go there for a visit?...
Oct 16, 2020
[From the last episode: We put together many of the ideas we'€™ve been describing to show the basics of how in-memory compute works.] I'€™m going to take a sec for some commentary before we continue with the last few steps of in-memory compute. The whole point of this web...

featured video

Demo: Inuitive NU4000 SoC with ARC EV Processor Running SLAM and CNN

Sponsored by Synopsys

See Inuitive’s NU4000 3D imaging and vision processor in action. The SoC supports high-quality 3D depth processor engine, SLAM accelerators, computer vision, and deep learning by integrating Synopsys ARC EV processor. In this demo, the NU4000 demonstrates simultaneous 3D sensing, SLAM and CNN functionality by mapping out its environment and localizing the sensor while identifying the objects within it. For more information, visit inuitive-tech.com.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured Paper

New package technology improves EMI and thermal performance with smaller solution size

Sponsored by Texas Instruments

Power supply designers have a new tool in their effort to achieve balance between efficiency, size, and thermal performance with DC/DC power modules. The Enhanced HotRod™ QFN package technology from Texas Instruments enables engineers to address design challenges with an easy-to-use footprint that resembles a standard QFN. This new package type combines the advantages of flip-chip-on-lead with the improved thermal performance presented by a large thermal die attach pad (DAP).

Click here to download the whitepaper

Featured Chalk Talk

Keeping Your Linux Device Secure

Sponsored by Mentor

Embedded security is an ongoing process, not a one-time effort. Even after your design is shipped, security vulnerabilities are certain to be discovered - even in things like the operating system. In this episode of Chalk Talk, Amelia Dalton chats with Kathy Tufto from Mentor - a Siemens business, about how to make a plan to keep your Linux-based embedded design secure, and how to respond quickly when new vulnerabilities are discovered.

More information about Mentor Embedded Linux®