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. More about Lorawan roaming find out below.

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 you leaving your home network.

LoRaWAN: Multicasting to the Cloud

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.

The Benefits of Passive Roaming in LoRaWAN

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 setup, 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.

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

LoRaWAN Geolocation: From Distance to Direction

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.

LoRaWAN Class B: A Power-Saving Option for IoT Devices

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. The key determiner of the most appropriate service for a given application is power – in particular, the RF receives 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. (Source)