5 x Why LoRaWAN Roaming Is Dead On Arrival
LoRaWAN Roaming is designed to exchange traffic between first generation public networks. However, the next potential of LoRaWAN is in exchanging traffic between private networks and infrastructure owners.
This article describes five reasons why LoRaWAN Roaming is dead on arrival and presents a better way to exchange traffic. As standards advocates, we consider this a superset of LoRaWAN Roaming and are committed to standardize our solution.
LoRaWAN and Shared Spectrum
LoRaWAN™ is an open protocol for secure messaging between devices and networks, typically leveraging LoRa® modulation in unlicensed sub-GHz spectrum for low power wide area networking (LPWAN).
In LoRaWAN networks, the gateways, which provide network coverage, are transparent; they forward packets from the LoRa concentrator over the internet to the network server and back. Gateways do not know devices: they forward everything they receive on the channels they are listening on.
Unlike cellular technology in licensed spectrum, many LoRaWAN networks use overlapping channel plans in the shared spectrum. Since gateways forward all packets, networks receive packets from all devices covered by their gateways, even packets intended for other networks. This gives the LoRaWAN ecosystem the unique opportunity for exchanging traffic between networks: once a packet is received by a gateway, the cost to forward the packet to the device's home network is near zero.
Why Exchange Traffic?
There are good reasons to exchange traffic between networks.
First, moving devices don't follow networks. Many networks only have coverage in a certain area, but devices move to areas where other networks have (better) coverage. Also, most networks are providing either outside coverage with a few outdoor gateways installed on towers, or inside-out coverage with many indoor gateways in buildings, ships and trains. Therefore, today, asset trackers lose connectivity when crossing borders or moving from truck to ship.
Second, receiving the same message from more gateways is always better. More gateways increase the network's resilience to gateway failures and provide more capacity for sending messages to devices. More gateways also provide more metadata, like timestamps and signal qualities, to improve triangulation results for locating devices.
Third, exchange traffic for better battery life and more gateway capacity. Networks optimize data rates and transmission power for stationary devices to transmit as efficient as possible while ensuring that devices stay covered through a mechanism known as adaptive data rate (ADR). Devices that are close to gateways can transmit faster with less power while devices that are further away should transmit slower with more power. When networks exchange traffic, data rate and transmission power can be optimized for any close gateways, even those gateways that are connected to other networks. Increasing data rate reduces time-on-air, resulting in less channel utilization on gateways, and, combined with lower transmission power, longer battery life for devices.
LoRaWAN Roaming Is Not A Solution
So, exchanging traffic between networks is a good idea. Therefore, the LoRa Alliance specified LoRaWAN Roaming in an attempt to enable traffic exchange. However, LoRaWAN Roaming is designed for first generation public networks, while LoRaWAN traffic exchange is most powerful in a mix of private (enterprise) networks, public collaborative and operated networks, and even with gateways that are not managed by a network service provider.
LoRaWAN Roaming is dead on arrival because it has five major drawbacks:
LoRaWAN Roaming requires blind trust in roaming parties or hubs
LoRaWAN Roaming requires many-to-many contracts
LoRaWAN Roaming does not support separating payload from metadata
LoRaWAN Roaming requires each party to operate a LoRaWAN network server
LoRaWAN Roaming hubs centralize authority
LoRaWAN Roaming comes in two flavors: hand-over and passive roaming. Hand-over roaming is what happens when you go abroad: your phone connects to a different network. This is great where there is countrywide (outdoor) coverage from a single operator. Unfortunately, that’s only available in three European countries. Passive roaming is where devices stay connected to their home network and one or more networks forward packets to the home network. With passive roaming, the device may or may not be covered by its home network gateways. There are two modes of passive roaming: stateful and stateless.
In stateful passive roaming, the home network has to enable device roaming on each possible forwarding network (dozens!) and for each device (thousands, millions!). This requires massive device session management and LoRaWAN 1.1. As of June 2019, LoRaWAN 1.1 is broken and there is no certification, let alone a LoRaWAN 1.1 device on the market. Forget this for now.
Stateless passive roaming does work for all existing LoRaWAN devices. However, it's stateless so forwarding networks don't know the devices so they don't know if roaming is enabled for them, they don't know if other forwarding networks also forward the packet, and they don't know if the home network received the packet already on its own gateways. As a result, forwarding networks forward all packets to the home network, even if the home network doesn't need the packets and doesn't want to pay for it.
This requires blind trust in the home network for being honest which packets have been used and should be billed. Worst case, the home network pays for all forwarded packets from all forwarding networks, which leads to uncontrolled costs.
LoRaWAN Roaming is peer to peer. With a few first generation public networks in a roaming region like continental Europe, bilateral contracts are perfectly achievable. However, as the power of LoRaWAN traffic exchange is in mixing (a lot of) private networks and public collaborative and operated networks, there's an exponential amount of bilateral contracts required.
With a 100 networks, there are 4950 contracts needed to exchange traffic. This doesn’t scale.
Payload and Metadata
LoRaWAN Roaming does not support separating payload from metadata while payload and metadata are of distinct use and value. Networks need payload for sending data upstream; sensor data from stationary devices for example. Networks need metadata for more downlink options and more accurate geolocation results.
Since LoRaWAN Roaming does not support forwarding either payload, metadata or both, the home network pays for both. However, the home network may not be interested in payload if it received the payload on its own gateways and only wants more metadata for better geolocation. Likewise, it may not be interested in metadata if downlink or geolocation are not applicable.
Roaming Requires Networks
LoRaWAN Roaming is about exchanging traffic between networks; it requires all parties to operate a LoRaWAN network server. How about exchanging traffic directly with gateway owners?
Since we're in unlicensed spectrum, anyone can install gateways anywhere. Therefore, LoRaWAN is not just for traditional carriers who install gateways on towers and operate a network. On the contrary: gateway owners (layer 1) with access to great locations are not necessarily the best ones to provide network services (layer 2).
Now, in order for gateway owners to exchange traffic with networks using LoRaWAN Roaming, they have to operate a LoRaWAN network server that interacts with the LoRaWAN network server of their roaming partners. This adds a barrier for tower companies, real estate companies and satellite service providers to monetize high value locations as they have to go down the path of LoRaWAN network server vendor selection, licensing, operational and maintenance costs, etc.
Roaming Hub Authority
Roaming hubs enable roaming with multiple networks while dealing with a hub which acts as a single roaming partner. Networks may connect with multiple hubs, much like internet exchanges. This may solve the contracting nightmare as illustrated before.
However, roaming partners need to adhere to the hub's rules for packet routing, connected networks, accounting, billing, tax regime, service levels and trust.
Since the hub simply centralizes LoRaWAN Roaming, most drawbacks as illustrated before still apply — potentially to a larger extent. For instance, networks need to blindly trust the hub itself and implicitly all members of the hub. Also, mechanisms provided by the hub to configure traffic exchange between networks only solve the exponential contracting nightmare if there are enough degrees of freedom to avoid bilateral contracts. For example, some networks want to clear traffic exchange on the number of messages, while others want to clear on service area. Does the hub support those accounting rules? Great! If not, you need trilateral contracts with interdependent service levels.
A Better Approach
In short, exchanging traffic between LoRaWAN networks is a great idea, but LoRaWAN Roaming is not the way to go. What is a better approach?
We present Packet Broker!
Packet Broker is built around the following concepts that address the five drawbacks of LoRaWAN Roaming:
Packet Broker supports individual packet selection; home networks only pay for packets they want. There are clear transactions instead of requiring blind trust between parties
Packet Broker separates packet routing from clearing; packets are routed encrypted and can be decrypted using any commonly trusted key exchange. There can be multiple forms of key exchanges: marketplaces, bilateral balances, out-of-band billing, etc. When joining a marketplace, there is no need for bilateral contracts between parties
Packet Broker separates payload from metadata; home networks can buy payload and metadata separately
Packet Broker brings together gateway owners and network service providers; there is no requirement for all parties to operate a LoRaWAN network server. This allows tower companies, real estate companies and satellite service providers to monetize gateway infrastructure directly. Of course, parties can operate LoRaWAN network servers, but it is not required
Packet Broker provides full freedom in clearing between parties; there is no central authority that imposes rules. For instance, there can be multiple marketplaces, ranging from collaborative marketplaces for certain areas (i.e. Europe, North America, Australia) to specialized marketplaces for specific verticals (i.e. seaports, airports, agricultural areas, cities). Parties can also keep bilateral balances where they simply invoice the offset
Packet Broker is a product and its routing and key exchange APIs will be open. It will be available as a hosted solution, but it can also be installed in private cloud or on-premises to exchange traffic between private network clusters.
How Does It Work?
Forwarding networks encrypt payload and metadata separately. The encrypted payload and metadata are then forwarded to a Packet Broker Router, along with the price, key exchanges used and some public attributes. At the same time, the forwarding network publishes the encryption key to one or more trusted key exchanges.
The Packet Broker Router sends the encrypted payload, encrypted metadata and attributes to the home network. The home network considers buying the payload, metadata or both. If there are multiple forwarding networks that offer the same payload or multiple metadata, the home network can choose from which network it buys the payload and/or metadata. This decision can be fully automated and may be driven by price or other predefined rules.
Once the home network decides to buy payload and/or metadata, it connects to one of the key exchanges that can decrypt the message. The home network provides the encrypted data and the key exchange returns the decrypted result.
Packet Broker uses encryption not for security but for individual packet selection. The mutually trusted key exchange decrypts the packet on the home network's request and records the transaction. If the key exchange is a marketplace, it sends monthly debit and credit invoices. If the key exchange is a bilateral balance, parties may clear offsets out-of-band.
Public attributes for packet selection include DevAddr, FPort, FCnt and the hash of the payload. This allows home networks and their applications to see if the packet has already been received on the home network, and if not, whether the packet is of value. For example, the DevAddr and FPort may indicate data of interest from a specific device. To ensure message integrity (and detect networks forwarding garbage), the home network may optionally provide the FNwkSIntKey (LoRaWAN 1.1) or NwkSKey (LoRaWAN 1.0.x) to the trusted key exchange to validate the LoRaWAN message integrity code (MIC) before processing the transaction.
We are advocates of open standards. LoRaWAN Roaming is standardized, and so should any complementary or alternative specification. Designing a specification, however, should not be a paper exercise in lengthy committee meetings. Instead, it should be driven by early validation, from both a technical and business perspective.
Therefore, we decided to move forward with implementing Packet Broker with open APIs and documentation.
Our aim is to make packet-based traffic exchange a first class citizen in the LoRaWAN ecosystem by contributing to the standardized LoRaWAN Backend Interfaces. For quick adoption by network servers of other vendors, the Packet Broker will expose LoRaWAN Roaming in stateless passive mode, which makes Packet Broker essentially a LoRaWAN Roaming hub on steroids. From there, vendors can gradually adopt Packet Broker specific functionality like individual packet selection.
We will connect the The Things Network clusters for global community network coverage, private commercial The Things Industries networks as opt-in as well as build support in the open source The Things Network V3 Stack. We believe this initial coverage from 10,000 to 15,000 gateways is a great starting point for exchanging traffic on next generation LoRaWAN networks.
[update: Question by TTN Berlin]:
One question.. about monetizing gateways... will private TTN gateways in some way be used in future to work as 'cashcows' when receiving 'foreign LoRaWAN signals' and forwarding those via packetbroker.org into another LoRaWAN network, e. g. into another country.... E. G. international transportation and logistic services? And what will be the probable delay time?
[update: answer by Johan Stockking]:
Good question. The owners of gateways connected to the public community network can choose whether they want their gateways to forward traffic to Packet Broker. They can also limit their gateways to “TTN only”
Otherwise, we will use that capacity to 1) balance traffic exchange with other networks, to expand the overall reach of TTN and vice-versa, and 2) use any revenue generated by selling traffic off TTN to cover the rapidly increasing operational (hosting) costs of The Things Network Foundation and other public cluster operators
Our aim is to grow our coverage even more and make TTN as a whole (financially) sustainable while not charging anyone to use the community network. Until then, TTI and public cluster operators sponsor the public network