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

• 
• 
• 
• 
•