LoRaWAN: Class B or C?

[MaffooClock]

I understand that LoRaWAN is currently a beta feature. So far, I've been able to use this library with a Heltec LoRa 32 v3 to send data to The Things Stack through my MikroTik R11e-LR9 gateway, as well as receive.

One thing I was hoping to achieve is for my node to be a Class C (or at least Class B) device, but nothing I try has allowed the device to receive a downlink without first transmitting an uplink, so pretty much all that I can get my device to do is behave only like a Class A node (which works, by the way!).

Yes, I've configured the node on The Things Stack to have the "Supports Class B" and "Supports Class C" options enabled.

Essentially, what I've tried is adding radio.startReceive() in my setup() and using my loop() to repeatedly call node.downlink() without any delays, then I use my MQTT client to send a message to The Things Stack, expecting it to appear on my device within a second or two. But nothing ever comes in; the message stays queued and is never actually sent to my gateway (there is an MQTT topic that also shows that it is queued and not yet sent).

As a test, in my loop() I added in a 60-second timer that, when it expires, will call node.uplink() to send a message, and when loop() goes back to only calling node.downlink(), the queued message quickly appears in my gateway log, and then on my device.

Since the message stays queued and is never sent to my gateway (without an uplink), that tells me The Things Stack somehow "knows" my device is in Class A mode, which leads me to believe that my strategy of continually checking for a downlink might be correct, but there must be some other step that should have taken place so that The Things Stack knows that it's okay to send a downlink without an uplink (even if this library doesn't currently have that step built in).

I've poured through the numerous issues relating to the development of the beta feature, and I've learned a lot, but I'm not quite sure what's missing from the implementation to make this work. I feel like RadioLib is so close, though!

Any LoRaWAN exports have any tips?

[MaffooClock]

I think I just learned something (naturally, right after starting this conversation):

The message I was sending in my MQTT client was something like this:

{
    "downlinks": [
        {
            "frm_payload": "eyJzb21lS2V5Ijoic29tZVZhbHVlIn0=",
            "f_port": 1,
            "priority": "NORMAL",
            "confirmed": false
        }
    ]
}

...but I just learned that a message for a Class B/C device is different, and so should look like this (notice the new class_b_c key containing the gateway ID and time):

{
    "downlinks": [
        {
            "frm_payload": "eyJzb21lS2V5Ijoic29tZVZhbHVlIn0=",
            "f_port": 1,
            "class_b_c": {
                "gateways": [
                    {
                        "gateway_ids": {
                            "gateway_id": "eui-3235313227005500"
                        }
                    }
                ],
                "absolute_time": "2023-12-18T22:29:00Z"
            },
            "priority": "NORMAL",
            "confirmed": false
        }
    ]
}

So, obviously, my troubles have nothing to do with this library. I'll tinker with this some more to see if I can make some progress...

[StevenCellist]

While this is absolute abuse of the LoRaWAN implementation here, I am also curious to hear if you will actually get anything out of this. I hope to slowly keep working on this in the future, with extending the MAC commands support for end-users in the near future. But if there's actual progress on your side and it appears to be somewhat 'easy', I might take a look at B and C.
However, it's more likely that I will implement the LoRaWAN test suite first to verify that class A is actually working according to spec before looking at B and C.

BTW, you will have to dig deeper than just calling downlink() over and over again, since whatever you do, it only actually listens the 5th and 6th second after an uplink(). So instead of calling dowlink(), you will have to call radio.receive() or something along those lines, with, IIRC, a value of 0 for 'infinite' receive mode on the SX1262. And then every so often check if anything has been received.

[MaffooClock]

this is absolute abuse of the LoRaWAN implementation

Is my use case not a textbook definition of a Class C node? My usage is most certainly within the regulatory limits as well as the FUP. Not sure what I shared that indicates abuse... would you clarify?

instead of calling dowlink(), you will have to call radio.receive() or something along those lines...

My thought behind calling .downlink() was that the protocol layer was basically doing this for me, but in a more appropriate manner (see .downlinkCommon()).

Currently, sending the correct MQTT message to The Things Stack (the one that includes the class_b_c and absolute_time keys) seems to have me on the right track, but those messages stay queued forever (they're never sent to my gateway), so there's something else I'm missing. I need to figure this out before I go back to troubleshooting my end node...

[StevenCellist]

You are completely right that it is the textbook definition of Class C, but it is an "abuse" of the downlink function in RadioLib's LoRaWAN stack - where I didn't mean to offend you. The abuse that I mean is that the downlink function is inherently tied to the last uplink and cannot be called at your own free will at any moment, and only opens very very tiny receive windows instead of a continuous receive window. I expect you understand how the Rx1 and Rx2 windows of Class A work, which is the only thing that is supported by the downlink function. Otherwise, please read up on Class A first before hacking on LW in any way, beit gateway side or node side.

[MaffooClock]

it is an "abuse" of the downlink function in RadioLib's LoRaWAN stack

Ah, gotcha. Yes, I agree that I'm misusing the library in a feeble attempt to make it behave in a way that it wasn't intended. I haven't been able to find any library (specific to Arduino-type devices, anyway) that supports Class C. But I think I now understand why that is, too.

And yes, I'm plenty familiar with Class A -- thanks to RadioLib, I got that working almost immediately without any trouble. I've used other Arduino libraries in that past, and this one is miles ahead, even if LoRaWAN is only a beta feature at the moment. Great job!

For my purpose, it's probably better that I abandon LoRaWAN and just roll my own private MQTT+LoRa solution. But through this experience thus far, I've learned a lot more about LoRaWAN than I thought I knew, so I'd like to keep learning.

[StevenCellist]

Thanks for the compliments :)
I definitely suggest taking another route for now - maybe it some point in the future there will be B/C support in RadioLib, but actually proving it can adhere to A in the field and in the lab is the current priority for me personally. Working in the field appears to be very well, working in the lab is the next milestone.

[jgromes]

The current LoRaWAN support is for class A only. I'm not the LoRaWAN export here (that would be @StevenCellist), so I don't know how much stuff would need to be changed in order to support Class B and C operation.

[ChangYanChu]

@MaffooClock Hi MaffooClock, Have you found a better way to support class B class C so far?