LoRaWan Binding

[egekorkan]

@barnstee has submitted the binding via email. In the first commit, I have copied it over without changing anything to reflect his contributions. Any further changes will be from my side or others.

Email submission: https://lists.w3.org/Archives/Public/public-wot-wg/2026Mar/0002.html

Rendered version: https://deploy-preview-458--wot-binding-templates.netlify.app/bindings/protocols/lorawan

[netlify]

✅ Deploy Preview for wot-binding-templates ready!

Name	Link
🔨 Latest commit	aa50732
🔍 Latest deploy log	https://app.netlify.com/projects/wot-binding-templates/deploys/6a2f1d0da020d10008b6c370
😎 Deploy Preview	https://deploy-preview-458--wot-binding-templates.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[danielpeintner]

I don't have any real experience with LoRaWan. However, a few things caught my eye...

• inconsistencies in terms of capitalization
  e.g., lowerCamelCase like "appKey" vs. lowercase for "routerconfig" vs. lowerCamelCase
  other places like "msgtype", "NetID", "JoinEui", ...

• like @egekorkan mentioned prefix vs. non-prefix terms

[egekorkan]

TD Call:

• co-authorship does not show in GitHub: to be understood if this is a GitHub issue (so other keywords) or this is fine
• There is provisional uri scheme registration https://www.iana.org/assignments/uri-schemes/prov/lorawan but it is not precise at all
• {appKey} is kind of a security key but without it you cannot onboard device. Probably that should not be mentioned in the TM but in TD but only in runtime. It is more like a public key. It is a privacy
• Having two uri schemes means registering two schemes (e.g., lorawan-router, lorawan-device)
• Introduction needs the explanation provided by @barnstee in the call today about the how the different entities interact with each other and their names.
• lorav: prefix should be added to all terms
• Form terms should be split to two tables. First 3 are for devices, next ones are for router
• copy paste remnants of Modbus should be fixed
• Some aspect of bit handling should be generalized later on. byte changes
• router config sent is part of the Lorawan binding that is seen in implementations. Should be asked to lorawan experts

[barnstee]

Here is the official network diagram: https://www.thethingsnetwork.org/docs/lorawan/architecture/

[corroleaus]

TD Call:

• co-authorship does not show in GitHub: to be understood if this is a GitHub issue (so other keywords) or this is fine
• There is provisional uri scheme registration https://www.iana.org/assignments/uri-schemes/prov/lorawan but it is not precise at all
• {appKey} is kind of a security key but without it you cannot onboard device. Probably that should not be mentioned in the TM but in TD but only in runtime. It is more like a public key. It is a privacy
• Having two uri schemes means registering two schemes (e.g., lorawan-router, lorawan-device)
• Introduction needs the explanation provided by @barnstee in the call today about the how the different entities interact with each other and their names.
• lorav: prefix should be added to all terms
• Form terms should be split to two tables. First 3 are for devices, next ones are for router
• copy paste remnants of Modbus should be fixed
• Some aspect of bit handling should be generalized later on. byte changes
• router config sent is part of the Lorawan binding that is seen in implementations. Should be asked to lorawan experts

The appkey is essentially the root provisioning key for the session established during join so while needed for provisioning, having the actual key in a TD sounds problematic. Could reference a key store or security definition rather
than embedding the value directly.

[egekorkan]

@corroleaus thank you! Indeed that was probably the longest point of discussion yesterday. We can also envision the put it like this example a bit https://w3c.github.io/wot-thing-description/#example-22

[relu91]

More info here. If you ask me, it seems like we need a Security scheme. Probably we can re-use https://w3c.github.io/wot-thing-description/#apikeysecurityscheme. What is not clear (at least to me), is how the application will obtain the AppKey. Probably, it is something you provision at a intial configuration phase.

[barnstee]

More info here. If you ask me, it seems like we need a Security scheme. Probably we can re-use https://w3c.github.io/wot-thing-description/#apikeysecurityscheme. What is not clear (at least to me), is how the application will obtain the AppKey. Probably, it is something you provision at a intial configuration phase.

Correct, the app key must be generated offline and provisioned into the device before commissioning. It is never sent across the air but both the network server and the device need it before a connection attempt is made.

[mjkoster]

More info here. If you ask me, it seems like we need a Security scheme. Probably we can re-use https://w3c.github.io/wot-thing-description/#apikeysecurityscheme. What is not clear (at least to me), is how the application will obtain the AppKey. Probably, it is something you provision at a intial configuration phase.

Correct, the app key must be generated offline and provisioned into the device before commissioning. It is never sent across the air but both the network server and the device need it before a connection attempt is made.

More info here. If you ask me, it seems like we need a Security scheme. Probably we can re-use https://w3c.github.io/wot-thing-description/#apikeysecurityscheme. What is not clear (at least to me), is how the application will obtain the AppKey. Probably, it is something you provision at a intial configuration phase.

Correct, the app key must be generated offline and provisioned into the device before commissioning. It is never sent across the air but both the network server and the device need it before a connection attempt is made.

• We agree that we can't store the AppKEy in the TM/TD as plaintext
• V1.1 has a resolution but is not adopted in industry yet (since 2017)
• LoRaWAN version 1.04 is 3 years ahead of V1.1 and 1.04 seems to be the industry adopted version. 1.04 is claimed to resolve the security issues with 1.0
• There is an additional network key in 1.1 that is needed to read the payload

Proposal is to remove the AppKey from the form and use the coded security scheme to inform the consumer to obtain and store the key out of band.

[egekorkan]

@barnstee I have managed to add you as a co-authored now as that is technically your contribution. For others, I thought github username was enough but it must specifically be Co-authored-by: Erich Barnstedt <erichb@microsoft.com>

[egekorkan]

TD Call today:

• ABNF is not working. The following scheme = "lorawan://" "lorav:deviceEui" "/" ("{lorav:appKey}/device") / ( "lorav:gatewayModel" "/routerconfig" ) is working but we need to express that some terms are variables. https://dontcallmedom.github.io/rfcref/abnf/web/ or https://www.icosaedro.it/bnf_chk/bnf_chk_standalone.htm can be used.
• The capitalization is not consistent for the terms. To be checked. Also some terms use _. @barnstee any preference here from lorawan point of view?
• Introduction needs more work. The diagram given by @barnstee is not in public domain so we cannot just copy paste it here. We should make a new one ourselves.

Otherwise, we are leaving it for more reviews. @corroleaus @relu91 @barnstee have another look please.

[barnstee]

TD Call today:

• ABNF is not working. The following scheme = "lorawan://" "lorav:deviceEui" "/" ("{lorav:appKey}/device") / ( "lorav:gatewayModel" "/routerconfig" ) is working but we need to express that some terms are variables. https://dontcallmedom.github.io/rfcref/abnf/web/ or https://www.icosaedro.it/bnf_chk/bnf_chk_standalone.htm can be used.
• The capitalization is not consistent for the terms. To be checked. Also some terms use _. @barnstee any preference here from lorawan point of view?
• Introduction needs more work. The diagram given by @barnstee is not in public domain so we cannot just copy paste it here. We should make a new one ourselves.

Otherwise, we are leaving it for more reviews. @corroleaus @relu91 @barnstee have another look please.

Not yet, but we should ask the LoRa folks once we kick off the joint working group.

[egekorkan]

I had a chat with a colleague and learned the following:

• All interactions are async. So we cannot do a real readproperty unless we are describing an application server (like a gateway) that caches data. Should we only have observeproperty or turn everything to events?
• Wilder payload formats: Apparently, manufacturers do sometimes wild stuff and we will need more vocabulary approaches. Also, sometimes some codecs are configurable by the user of the device, making the manufacturer-provided TM invalid. A very popular lorawan stack lets users write scripts (https://www.chirpstack.io/docs/chirpstack/use/device-profiles.html#codec). Maybe we can cover all the wild variations but for now probably not. In any case, more testing with a variation of devices is needed.

[barnstee]

I had a chat with a colleague and learned the following:

• All interactions are async. So we cannot do a real readproperty unless we are describing an application server (like a gateway) that caches data. Should we only have observeproperty or turn everything to events?
• Wilder payload formats: Apparently, manufacturers do sometimes wild stuff and we will need more vocabulary approaches. Also, sometimes some codecs are configurable by the user of the device, making the manufacturer-provided TM invalid. A very popular lorawan stack lets users write scripts (https://www.chirpstack.io/docs/chirpstack/use/device-profiles.html#codec). Maybe we can cover all the wild variations but for now probably not. In any case, more testing with a variation of devices is needed.

Yes, we are describing a network server/gateway which caches the data. And yes, we require a lot more testing, this is something we can discuss today in the LoRaWAN joint working group.