RFC: LoRaWAN in RIOT

[jia200x]

Hi community.

We just had a meeting with @aabadie, @adjih and @fjmolinas to discuss about the possible next stages for LoRaWAN on RIOT.

@aabadie is proposing to add LMIC as a pkg (the IBM original link seems to be broken). Although it has minimal functionalities,it covers class A and B devices and 868-915 MHz bands.

On the other side, @fjmolinas and me originally tried to port Semtech LoRaMAC-Node as a pkg, but we ended rewriting half of the code due to problems with OTA and code logic, lack of an abstraction layer and redundancy with RIOT components. We already deployed a RIOT + LoRaWAN project with this code in the #6645 PR and did some tests. Worked for a month sending packets every 30 secs! (class A, OTA, unconfirmed messages)

At this point we don't suggest trying to port Semtech LoRaMAC-Node as a pkg, but wanted to know your opinion in continuing the development of gnrc_lorawan to make it a RIOT component rather than an external pkg. (The main drawback is the difficulty of adding new features and mantaining, but a custom code can give more control).

TL;DR Opinions on adding IBM LMIC as a pkg and also continue the development of a RIOT's own LoRaWAN stack in #6645 .

Cheers!

[dylad]

it covers class A and B devices

You probably mean A and C classes. B class will cause us a lot of troubles.

I don't really know GNRC and all this stuff but I think it will be a shame to use LMIC as a package now because we will start from zero (dive into code, full review for compliance, heavy tests...) while we have #6645. Of course, the current PR needs more work and a long & painful review but I think It will be even worse and longer with IBM LMIC.

[aabadie]

it will be a shame to use LMIC as a package now because we will start from zero (dive into code, full review for compliance, heavy tests...)

Some work has already been done so we don't start from zero here. Since it will used as a package, I hope the changes will be minimal.

Implementing from scratch a GNRC version of LoRaMAC-node is also a lot of work and there's still a lot of work in #6645.

[dylad]

Some work has already been done so we don't start from zero here

Good to know So do you think it will be faster to use LMIC as a package to get a working LoRaWAN node in RIOT ? I'm not oppose to it but I have some questions :

• LMIC is still uncompleted so should we wait for next release from IBM ? Will they do it ?
• Are we going to diverge ? fork their work and add our features later.

I don't really know which one will be the best solution but in both case, there are looooooot of work ahead and painful reviews ;)

[aabadie]

So do you think it will be faster to use LMIC as a package to get a working LoRaWAN node in RIOT ?

It depends, but that's my intuition.

LMIC is still uncompleted so should we wait for next release from IBM ? Will they do it ?

The repository (arduino-lmic) has not moved during 11 months but still seem to be active (regarding issues/PR) so maybe.

Are we going to diverge ? fork their work and add our features later.

No, we will just use it as an external package, patched to fit to RIOT netdev hal (where we already have the drivers). Then the user will just have to use the high-level API of LMIC. The good thing with packages is that the workload to maintain them is kept minima since it's only a matter of adapting the port. If we find problems, we then have to contribute fixes in the upstream repository.

[dylad]

workload to maintain them is kept minima since it's only a matter of adapting the port

Sure but with this approach, I'm not even sure RIOT will support class B device one day. If this repo is still alive and maintainers are willing to implement the remaining features then maybe we should choose this option. But we haven't any guarantee... Let's see what RIOT's users think about it.

[aabadie]

With this approach, I'm not even sure RIOT will support class B device one day.

If it provides support for class A and C, it's already better than what we have now (e.g nothing). Let's move in small steps first before thinking of supporting all variants of the protocol.

[dylad]

Agreed, I just want to make sure this (future) package will evolve and don't remain in a vegetative state for the rest of its life.

[jia200x]

You probably mean A and C classes. B class will cause us a lot of troubles.

I meant what is currently implement in LMIC.

AFAIK the original LMIC code was available in the IBM site "as it" and hasn't changed in a year. I'm not sure if there will be further development. The netdev adoption might take some time too, it requires going deep and intercept all LMIC driver calls. Will it take less time than refactoring #6645?

We did some tests with LMIC on RIOT (adopted all hal calls to RIOT's spi calls) and worked with some issues (OTA didn't work, ABP did), But was for quick testing, so I guess it's possible to make it work.

PS: We tried LMIC in Arduino and almost everything worked (we had some problems receiving ACK but think it was a gateway fault). OTA was working.

[jia200x]

@aabadie @dylad do you have more comments? :)

Also, @miri64 may be interested in this discussion.

[dylad]

I don't know LMIC enough to have a strong opinion but I doubt it'll evolve in a near future plus it'll be a shame to throw away #6645 In other hands, I do not know GNRC too... It's up to RIOT's maintainers.

[aabadie]

@jia200x can we close this now that #8264 and #7505 are in ?

[jia200x]

Yes, let's close it.

[nasser832385]

quelqu'un peut me dire le RFC de LoRa ? c'est urgent svp mais pas celui de LoraWan

[miri64]

Using google translate I suspect you were asking for a LoRA RFC? There is none by the IETF that specifies LoRA if you are asking about that. This issue here was a RIOT-internal Request For comments if we want to implement LoRAWAN in RIOT. LoRA itself is specified by the LoRA alliance. There is an lpwan working group within the IETF, that focuses on bringing IETF-specified protocols (such as IPv6) to differen Low-Power WAN technologies (including LoRA). They only have an informational overview RFC published so far.