Skip to main content

What is an 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:

  • up to five filters, describing the sets (AppEUI, DevEUI) expected by the LNS
  • one or more slabs of DevAddrs, reserving an address space for the OUI's devices on the Helium Network

A device, defined by (AppEui, DevEui), can be allocated 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.

info

Based on 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. Instructions here. Requires basic familiarity with Linux and Bash command-line.

OUI Cost

The OUI is purchased with Data Credits (DC). Costs are subject to change, but currently the OUI itself costs US$100 worth of DCs and each DevAddr cost an additional US$100 in DC.

DevAddr are sold in sequential blocks between 8 and 65,536 and any power of two.

You must purchase a slab when purchasing an OUI, therefore, the total minimum cost is US$900 worth of Data Credits: $100 for the OUI itself and $800 for eight DevAddr's.

The OUI purchase transaction itself incurs a fee based as does any other blockchain transaction; generally this will be $0.35-1.00 worth of DCs based on how the fields get filled and change the transaction size.

Purchase Transaction

You need the Helium wallet to go any further. You'll want to create a wallet and to have at least US$900 in HNT (based on current HNT Oracle pricing).

Purchase the OUI

Submit a "create OUI" transaction:

./helium-wallet oui create --subnet-size 8 --filter wVwCiewtCpEKAAAAAAAAAAAAcCK3fwAAAAAAAAAAAABI7IQOAHAAAAAAAAAAAAAAAQAAADBlAAAAAAAAAAAAADEAAAA2AAAAOgAAAA

The filter is a dummy filter to initialize the OUI. When you get Console running, it will automatically maintain it. You can once again track the transaction with the endpoint above. When it is complete, you should also see your OUI as the most recently purchased and on the list here.

Congratulations! You are the proud owner of a Helium Network OUI. OUIs are numbered sequentially, so the lower you are, the earlier you were on the Network!

DevAddr Explained

Device addresses or DeviceAddr are assigned to a device by the LNS during the join procedure See LoRaWAN Spec here for more info about Joins.

Why & when should I purchase more DeviceAddr?

When starting up your Helium LNS (Router / Console) you will probably be wondering, how many DeviceAddr do you need? This depends on a few factors:

  1. number of devices
  2. location / concentration of devices

To better figure out the right number for you, you will need to understand how DeviceAddr are assigned to Devices by Router.

Couple things to know before

First you will need a basic understanding of the location system used by the Helium Network Full Description. If you are aware of H3 Indexes & Hexagons you can skip this.

Then let's talk about the offer / purchase machanism on the Helium Network.

The Helium Network (HN) is not your "typical" LoraWan Network in which a Hotspot (or Gateway) will send its packets to an LNS directly and for "free". In the HN, a Hotspot will make an offer to the appropriate LNS and if said LNS decided to purchase it, the hotspot will then deliver the "full" packet to the LNS. Note that the LNS can refuse an offer from a Hotspot if it thinks that it is not interested by the data from this device.

info

Offers only contain:

  • the routing information for a packet (DeviceAddr for uplinks or EUIs for join)
  • a hash of the packet, to not reveal its content but still be uniquely trackable by the LNS
  • the Hotspot it came from
info

Note that a Console Organization is only ever charged when a packet is received and properly identified. Only Router's balance is charged during the offer / purchase process.

Assigning a DeviceAddr

When a device joins the Helium Network it is assigned a DeviceAddr based on the location of the hotspot that the device is communicating through. Router will lookup the hotspot's location and find its parent hexagon at resolution 3 (resolution 3 is the default value but it can changed via the env variable ROUTER_DEVADDR_ALLOCATE_RESOLUTION) it will then assign the lowest DeviceAddr in its slab to the device. If another device was to join in the same hexagon it would get the following DeviceAddr in the slab, ex: Device1 -> DevAddr1, Device2 -> DevAddr2.

info

At resolution 3 (Average Hexagon Edge Length: 59.8 km), they are 41,162 unique hexagon in the world, so a slab of 8 DeviceAddr would provide 41,162 * 8 = 329,296 devices, see doc.

The maybe not so obvious problem here is: what if you have more devices than DeviceAddr in one Hexagon? This is when conflicts can happen. A DeviceAddr conflict is when Router receives an offer but cannot be entirely sure if the offer is from for Device1 or Device9:

Example

You have 2 devices Device1 and Device9 both sending through the same hotspot and therefor in the same resolution 3 hexagon. As we have 9 devices that have joined in the Hexagon, the assignment rolled back to the first DeviceAddr and gave Device9 the same DeviceAddr1 as Device1.

  • Assignment Device1 -> DevAddr1, Device2 -> DevAddr2, ..., Device8 -> DevAddr8, Device9 -> DevAddr1.
  • Scenario: Device1 is sending an uplink.

At this point 2 things can happen:

  1. The Router identified the offer from the hotspot to be from Device1. The Router can then process the offer accordingly.
  2. The Router misidentify the offer thinking that it is from Device9 (as they both share DeviceAddr1)
    1. If Router deems offers associated with Device9 worthy of purchasing, the offer will be purchased and then the packet will be properly identified via the MIC (Message Integrity Code, see LoraWan spec for more info ). This is essentially a conflict with happy path.
    2. If Router does not deem offers associated with Device9 worthy of purchasing (e.g. maybe Device9 was de-activated by user in Console, or maybe Device9's Console Organisation ran out of Data Credit) the offer will be rejected and data never delivered. This is a conflict with non-happy path.

The non-happy path is fairly rare as Router will do its best to find out the right device but this is where buying extra DeviceAddr can help prevent bad conflicts.

This should help you figure out the number of DeviceAddr that is right for you.

info

Moving devices can trigger the same effect as well as they can get an assigned DeviceAddr in our Hexagaon and move to another one, potentially causing a conflict as specified above.

Tools

Devaddr

  1. curl http://localhost:3000/devaddr/json get all devaddr assignment in json format
  2. Input them in https://kepler.gl/demo

CLI

  • router info device <device_id> find every conflicts for a device
  • router info hotspot <hotspot_b58> find every conflicts for a hotspot
Edit this page