Class B Remote multicast setup

[oedze]

For our project we need to use the Class B remote multicast setup to implement FUOTA on class B (batterij powered) devices.
The current code does not seem to support it because there is still a TODO item in the code -> src/app/LoraMac-Node/common/LmHandler/packages/LmHpRemoteMcastSetup.c Line 406.

Are there plans to add this functionality or what stepps should be taken/considered to add this functionality?

[mluis1]

Yes, there are plans to add this. However it will not happen in the near future.

The current priorities on this project are (from highest to lowest):

• We are currently focusing in defining and implementing the Class B LoRa-Alliance certification process.
• We are also working on updating the radio drivers to the new ones provided by Semtech. (LR1110, SX126x)
• Update FUOTA packages to version 2 of the specifications (not yet published by the LoRa-Alliance)

As the Class B multicast handling should be similar to the one for Class C I will try to provide here as soon as possible the required changes. However I cannot guaranty that it will work out of the box.

[mluis1]

Please find attached a patch proposition to add Class B remote multicast support.

I had to make small modifications to the MAC layer in order to support the creation of both multicast channel types.
I did not test the proposed changes. Please give it a try and let us know your feedback.

Once we have time to validate this proposition we will include it to the repository.

add_class_b_rmcast_support.patch.txt

[oedze]

I can verify that the remote multicast setup part works with the proposed changes. We are now attempting to make the whole fuota update process work, if that works i will verify that as well.

[mluis1]

@oedze Had you time to check that the proposed patch is working properly?

[oedze]

@oedze Had you time to check that the proposed patch is working properly?

I did have time to check it. We continued the development with it.
I can confirm that the RemoteMulticastSetupClasssB command is received, stored and answerered correctly, so the fix works.
There is a part of the code that when changing to multicast, it would choose class C, because there is no check for which class.
We decided to continue on Class C for now. We do plan to continue to work on Class B FUOTA later this year.

[mluis1]

Thanks for the feedback.

I will then mark the topic as answered.

We will integrate the patch as soon as possible.

[praneet-kaur]

Hi @oedze,

I am trying to use FUOTA on my STM32 Nucleo L476RG reference hardware with SX1261MB2BAS shield. I am using OTAA instead of ABP for joining process.
I tried taking the logs provided as a reference but I see a lot of differences. My program seems to be stuck at clock sync. I am unable to pinpoint exactly what is going wrong. I have attached the logs. Please have a look.
putty_fuota.log

Also, if you could share how you verified the remote multicast setup process, that would be great.

[mluis1]

From your log the end-device never receives an answer to the uplinks on FPort 202.
The uplinks are asking the ClockSync application server to answer the AppTimeReq command.
Please refer to the following specification:
https://lora-alliance.org/wp-content/uploads/2020/11/application_layer_clock_synchronization_v1.0.0.pdf

A downlink following the AppTimeReq uplink is never received by the end-device.
You can observe this by looking at Rx 2 timeout lines each time an uplink on FPort 202 is sent by the end-device.

Please check the following:

1. Does your LoRaWAN Network Server implement the FUOTA specifications?
2. Can you check the Network Server logs in order to see if downlinks are being sent to the end-device and that they are well formatted (FPort 202 and frst byte of the payload is 0x01)

You may refer to the following comment #827 (comment) for a description of the full process using ChirpStack network server.

Please note that ChirpStack does not work anymore in the same way. Nowadays, the FUOTA server is an additional server to the default ChirpStack delivrables. chirpstack-fuota-server

[praneet-kaur]

Hi @mluis1,

Thanks for the clarification. You are right on the NS not supporting FUOTA. I will test with different instance of NS.
I will also check logs at network server to get the complete understanding.