What is an Organizationally Unique Identifier?
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 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.
Based on 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.
The OUI is purchased with Data Credits (DC). Costs are subject to change, but currently the OUI itself costs US$100 worth of DC 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.
Please send an email to email@example.com to purchase an OUI.
Submit a "create OUI" transaction:
./helium-wallet oui create --subnet-size 8
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!
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
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:
- number of devices
- location / concentration of devices
To better figure out the right number for you, you will need to understand how
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
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.
Offers only contain:
- the routing information for a packet (
DeviceAddrfor uplinks or
- a hash of the packet, to not reveal its content but still be uniquely trackable by the LNS
- the Hotspot it came from
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.
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
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.
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
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
You have 2 devices
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
Device1 -> DevAddr1, Device2 -> DevAddr2, ..., Device8 -> DevAddr8, Device9 -> DevAddr1.
Device1is sending an uplink.
At this point 2 things can happen:
- The Router identified the offer from the hotspot to be from
Device1. The Router can then process the offer accordingly.
- The Router misidentify the offer thinking that it is from
Device9(as they both share
- If Router deems offers associated with
Device9worthy 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.
- If Router does not deem offers associated with
Device9worthy of purchasing (e.g. maybe
Device9was de-activated by a 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.
- If Router deems offers associated with
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.
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.
curl http://localhost:3000/DevAddr/jsonget all DevAddr assignment in json format
- Input them in https://kepler.gl/demo
router info device <device_id>find every conflicts for a device
router info hotspot <hotspot_b58>find every conflicts for a hotspot