FUOTA server fragments scheduling issue

[akshayredekar]

Hi All,

Not able to receive fragments from lora server after sendMcClassCSessionReq from loraserver.js at end node.

Using mbed-os-example-lorawan-fuota example (https://github.com/ARMmbed/mbed-os-example-lorawan-fuota.git) ported with end node having SX1262 radio library.

On network server side using following - Multitech Gateway with packet forwarder and gateway bridge. lora-app-server version - 2.6.1 loraserver version - 3.2.1

Currently I am Testing using LoRaServer.io with running loraserver.js from application side. Connected end device in OTAA mode first. Clock synchronisation done at port 202 successfully. Received handleMulticastSetupReq at port 200 successfully. Received handleFragmentationSetup at port 201 with FragmentationSession starting successfully. Received handleMulticastClassCSessionReq at port 200 successfully. device is Switched to Class C. But it not receiving fragements from lora server.

Additionally I have setup following as per FUOTA Server guideline - Add a single extra device (this will be used as multicast group), with parameters: LoRaWAN 1.0.2 ABP activation Class C DevAddr: 0x01FFFFFF NwkSKey: BB75C362588F5D65FCC61C080B76DBA3 AppSKey: C3F6C39B6B6496C29629F7E7E9B0CD29

I have send at least one message from the Class C end device. Created multicast group at lora app server with two end devices.

From FUOTA server logs I see data fragments are scheduled to my devEUI but I won't get message at packet forwarder logs. Also subsequently they are not received at end node after switching to Class C.

Logs are attached here for end node console Node_log.txt and FUOTA server side loraserver.js execution.

FUOTA_SERVER_Log.txt

Please anyone let me know what may be the issue or May be I am missing something in configuration/setup.

[janjongboom]

If you send a Class C message from the loraserver console to the device, is it received?

Typically the behavior that you see, where messages are queued but not delivered, is caused by loraserver not knowing how to route the messages. So are you sure the Class C end device both properly sent a message and it was received by loraserver? It also needed to be routed by the exact gateway that you use for the firmware update.

[akshayredekar]

Thanks janjongboom for quick response.

Yes I am able to receive Class C message to device from the loraserver after setting LORA_DR to 8 in running loraserver.js script. Also on loraserver I am getting messages from 008000000000fe85 ABP device connected in CLASS C. But do I need to send at least one message in CLASS C from node 008000000000fe69 ? As it only switches to CLASS C when fragement session request received. Before that all the communication is done in CLASS A only for node 008000000000fe69.

Following are the setup configurations -

In loraserver.js parameter values - devices array with devEUI - 008000000000fe69 mcDetails array with devEUI - 008000000000fe85

devEUI with 008000000000fe85 is my node connected with following - ABP activation Class C DevAddr: 0x01FFFFFF NwkSKey: BB75C362588F5D65FCC61C080B76DBA3 AppSKey: C3F6C39B6B6496C29629F7E7E9B0CD29

I am updating firmware of devEUI mentioned in devices array.

1. I have updated LORA_DR to 8 in following command and it worked with downlink packets scheduled correctly to end node. $ LORA_HOST=127.0.0.1 LORA_DR=5 node fuota-server/loraserver.js Desktop/packets.txt Any particular reason to get this kind behaviour ? Also my PHY region is EU868.

2. Previously getting fragment packets to node connected with ABP only. But when I commented "in_class_c_mode = true;" in switch_to_class_c() function in main.cpp, I am then able to receive same fragment packets in OTAA connected (008000000000fe69) device. Any particular reason to get this kind behaviour ?

3. In FUOTA_SERVER_Log getting following message - "Delta is too big for 008000000000fe69 38" Eventhough my clock sync is done in the start of the script this behaviour is contrasting ?

4. In FUOTA_SERVER_Log before startSendingClassCPackets started I am receiving 1 fragment packet at end node and not getting further fragment packets. Eventhough in FUOTA_SERVER_Log I see further fragment packets getting scheduled. devEUI with 008000000000fe85 connected in ABP mode is receiving the packets continuously. I just don't know what may be the issue in this ?

Please let me know if I am missing anything in the setup/configuration still ?

[finrut]

Hi all,

similar problem also in my case, I've already asked to the (former) loraserver forum :

https://forum.chirpstack.io/t/multicast-group-deletion-during-fuota/6332

but nobody answered nor said what is the status of FUOTA implementation and under which limits it can work at the moment, e.g.:

• LoRa params as timeout for C class and multicast;
• maximum delta binary size (linked to max number of fragments and to LoRa DR );
• why the multicast group is deleted before the FUOTA ending.

If you can say something about the above question it would be of great worth to all of us evaluating the robustness of LoRaWAN protocol and its firmware updates capabilities.