Skip to main content

LoRaWAN On Helium

In typical LoRaWAN Networks, a central or regional LNS is managed by a single entity. Helium's design for a decentralized Network, however, means not only do we want gateways (referred to as Hotspots) to be independently owned and operated, but we want to enable the independent operation of the LNS.

Without this, access to the Network would require permission from a single central entity, the LNS operator of the Network.

Therefore, we want to enable the multi-tenancy of LNSs on the same public LoRaWAN Network. Achieving this distinguishes Helium's LoRaWAN Network from all other LoRaWAN networks: public wireless infrastructure is now compatible with privately-run Network Servers.

The rest of this article will discuss the networking primitives. If you want to go ahead and run a Network Server, please check out our article about running a network server.

The OUI​

Each LoRaWAN Network Server (LNS) on the Helium Network acquires an Organizationally Unique Identifier (OUI). This registers the LNS with the blockchain and allocates two very important routing objects owned and maintained by the OUI Operator:

  • one or more slabs of DevAddrs, reserving NwkAddr space for the OUI's devices on the Helium Network

A device defined by (AppEUI, DevEUI) can be allocated to any of the DevAddrs owned by the OUI. It is even possible to multiplex many devices on the same DevAddr at the same time, using the Message Integrity Check (MIC) to disambiguate.

Starting in 2023, Helium will be utilizing an OpenLNS Initiative to allow more choice and increase usability. You can read more about the OpenLNS Initiative at the Helium Foundation Blog or read more in the Use Helium LoraWAN section.

Organizationally Unique Identifier​

Organizationally Unique Identifiers (OUIs) are registered identities on the Helium Blockchain. To send and receive packets to an end-device, a network user needs to be serviced an OUI. This can be their own OUI or one operated by a third party, such as Helium Console operated by the Helium Foundation.

An OUI has some specificities related to LoRaWAN and packet routing, as documented above, but with respect to the blockchain, what's important is that only libp2p addresses registered as endpoints for the OUI may open and close state channels on behalf of an OUI.

For example, the account 13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc purchased the first OUI on the Helium Blockchain. The address 112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE operates the OUI on behalf of the owner.

OUIs are purchased (see current Transaction Fee Schedule) and numbered in incrementing order.

info

Based on the latest benchmarking tests the upper limit for a Devaddr 1024 slab is approximately 5800 devices, but results still need to be replicated and bracketed. Community members are encouraged to run their own benchmarking tests. Requires basic familiarity with Linux and Bash command line.

Join Request Frames and Filters​

A Join Request frame has the following unencrypted header:

+---------------------------------------------------------+
|   Size (octets)  |      8     |      8     |      8     |
+------------------+------------+------------+------------+
|   Join Request   |   AppEUI   |   DevEUI   |  DevNonce  |
+---------------------------------------------------------+

From the gateway's perspective, the (AppEUI, DevEUI) may be used to figure out if one or more OUI's are interested in the Join Request.

This is done by querying every filter maintained and written to the blockchain by every OUI. The filters themselves are xorhash tables, thus the AppEui and DevEui cannot be extracted. Only with the AppEui and DevEui in hand can the gateway run it through the table to see if it's there.

In response to the Join Request, a Join Accept is sent down, assigning the NwkAddr. Due to the multi-tenancy on the Helium Network, the LNS may only assign NwkAddrs within its DevAddr slab(s).

Data Frames and DevAddr Slabs​

Data packets have the following unencrypted header (FHDR):

+----------------------------------------------------------------------+
|   Size (octets)  |     4      |      1     |      2     |    0..15   |
+------------------+------------+------------+------------+------------+
|   FHDR           |  DevAddr   |    FCtrl   |     FCnt   |    FOpts   |
+----------------------------------------------------------------------+

Within DevAddr, there is the NwkAddr of a device:

+------------------------------------------------+
|                     DevAddr                    |
+------------------------+-----------------------+
|   NwkID (bits 31–25)   |  NwkAddr (bits 24–0)  |
+-----------+--------------------+---------------+
|     Helium Network     |   allocated by slab   |
|(‘H’ / 0b1001000 / 0x48)|      to OUIs          |
+-----------+--------------------+---------------+

From the gateway's perspective, it can use DevAddr to determine the OUI of Data frames. A quick query can say which OUI owns this DevAddr slab. This look-up and routing by DevAddr instead of by (AppEUI, DevEUI) via xorhash filters is generally much quicker.