Questions regarding FOTA End Time Determination?

[Ajay K]

I was wondering if the Multitech team can provide some kind of overview over the calculation related to the FOTA End time, based on the FOTA file size to be transferred and I am guessing the data rate plays in determining each fragment size and the time to end the FOTA transfer.

Below is a log entry I see when enabling logging in the mdot api. I am assuming the time to end value of 4131 is in seconds? Which is about almost 1 hr and 8 minutes. So would that mean based on the file size and other considerations, the FOTA transfer could take upto that time?

4/5/2021 3:20:40 PM: [INFO] Multicast class C session; time to start 30, time to end 4131, dr 12, freq 923300000
4/5/2021 3:20:40 PM: [INFO] Multicast session 0 starting in 30 seconds

Thanks,
Ajay.

[Jason Reiss]

Page 11 shows the timeout field available for a multicast session is 4-bits. This setting has a maximum of 9 hours.

LoRaWAN® Remote Multicast Setup Specification v1.0.0

The FOTA service in mPower will set a timeout at 9, 4, 2 or 1 hours depending on the datarate and Rx2 Duty-Cycle for the selected region. Each datarate step takes half the time on air to send the same number of bytes.

$ lora-query -x config plan rx2
{
   "datarate" : 2,
   "duration" : 698,
   "duty_cycle" : 0.10000000000000001,
   "frequency" : 869525000,
   "max_payload" : 51
}

The timeout is not currently reduced according to file size. In the future it may.

[Ajay K]

Thanks Jason for the explanation and I will review the document you have provided via the link. However I am just curious regarding the log entry which calls out the end time as 4131 (which I am assuming is in seconds). So what does that time represent? Is that when the mdot eventually switches back to a non FOTA mode, once the FOTA process has started?

Thanks,
Ajay.

[Jason Reiss]

To perform FOTA there is a multicast session and a fragmentation session. The multicast session has a timeout in seconds sent in the multicast session setup command as 4 bits. So the maximum is 2 to the power of 15 or ~32K seconds or ~9 hours. When the multicast session expires a device that is normally class A will close the class C window.

[Ajay K]

Thanks Jason for the explanation. Is there a way to get access to this end time via any of the API calls either using the FOTA api or the mDot API? we currently use the timeToStart() method on the Fota Class to determine if FOTA is about to begin or is in progress. However I was wondering if there is a way to look at when the estimated end time would be, basically get access to the value being logged in this case 4131 seconds?

Thanks,
Ajay.

[Ajay K]

I did find a way to determine the end time that is received based on the packet type described below received on Port 200. However I was wondering is the mDot just going to sit there in class C mode for let’s say best case 1 hr when the FOTA transfer fails? Which is what is happening in our case and since we can not enter sleep during class C, it will burn thru’ a lot of power. Any suggestions as to figure out when we can definitely say that there is no more FOTA Packets arriving after all the parity frames have been received and we can go to sleep even though we are in Class C Mode?

MC Class C Session Req
MC Index Start Time Timeout Freq DR
04 00 11a2a84c 0f 68e28c 0a

Thanks,
Ajay

[Author]

Posts