- [Greg] Hello.
And welcome to getting started
with AWS IoT Core for LoRaWAN,
Firmware Update Over The Air.
Or more concisely, FUOTA.
My name is Greg Breen,
and I'm an IoT Specialist Solutions Architect with AWS.
This video dives straight into the FUOTA feature
of the AWS IoT Core for LoRaWAN service.
To follow along, it's helpful if you're already
somewhat familiar with LoRaWAN,
LoRaWAN classes, multicast, unicast,
and the AWS IoT Core for LoRaWAN service.
To use the FUOTA feature,
you must have a LoRaWAN device
that supports the LoRa Alliance FUOTA process.
Specifically, the Application Layer Clock
Synchronization Specification,
the Fragmented Data Block Transportation Specification,
and the Remote Multicast Setup Specification.
You can find links to these specifications
in the video description.
Most LoRaWAN devices do not support FUOTA at this time,
so please check your device documentation.
Additionally, you need source code and build tools
for your device firmware
so you can generate an appropriate binary file
to use with FUOTA.
In this video, I'll demonstrate FUOTA
using an ST Nucleo-WL55JC evaluation board.
The STMCubeWL firmware
includes the LoRaMAC-node reference stack.
This stack includes implementations of the specifications
mentioned on the previous slide.
FUOTA can be unicast to a single device
or multicast to a group of devices.
Due to the low throughput of LoRaWAN,
multicast is more common.
Additionally, FUOTA can be either Class B or Class C.
AWS IoT Core for LoRaWAN supports
all of these combinations,
with multicast Class C being the most common type.
I'll now demonstrate FUOTA.
Specifically, multicast FUOTA
to a group of Class A devices
that temporarily switch to Class C.
The steps we'll follow are,
create a wireless device that has FUOTA enabled;
create a multicast group to synchronize the device time
and set up the multicast keys;
create a FUOTA task,
selecting the new firmware binary;
add devices to the FUOTA task
by assigning the multicast group to it;
schedule the FUOTA task to assign the multicast
start time, duration, frequency and data rate;
perform the fragmentation session
to transport the firmware fragments;
and finally, reboot the device to authenticate
and run the new firmware,
thereby completing the FUOTA task.
We begin by creating a new wireless device
because it's not possible at this time
to add FUOTA to an existing device.
We configure the EUIs and the keys in the normal way.
We then enable FUOTA.
For LoRaWAN 1.0.x devices,
we need to supply the GenAppKey.
This is the root key for deriving multicast session keys.
Please check your device documentation for your key value.
For this ST Nucleo device,
it's just the AppKey again.
We also need to assign the FPorts
for the multicast FUOTA and clock sync packages.
The default values are usually correct
as they are for this ST Nucleo device.
But please consult your device documentation.
Select your profiles
and your destination
as you normally would,
and then create the device.
Now we create a multicast group that FUOTA will target.
We select the RF region the device is in,
and select Class C as the type of multicast.
Normally a multicast group would include multiple devices.
For this demonstration, however,
just a single device is in the group.
At this point, we introduce
the ST Nucleo device's serial terminal.
Here we can see that the firmware app version is 1.2.0.
The device has joined the network
and is sending uplinks once per minute.
We create the multicast group
and drill into the group's details.
The group status is pending
because no session start time has yet been scheduled.
The individual device status is Package Attempting
because the multicast group
has not been initialized on the device.
Upon the next uplink,
AWS IoT Core for LoRaWAN issues commands
from the Application Clock Layer
Synchronization Specification
to synchronize the time
and commands from the Remote Multicast Setup Specification
to create the multicast group.
With the multicast group created on the device,
we can observe that the status of that individual device
has changed to Multicast Setup Ready.
Note that the multicast group session is not yet scheduled
and therefore no start time, session duration,
RX frequency nor RX data rate has yet been assigned.
We can now proceed to creating a FUOTA task.
We name the task
and select the RF region.
We select the firmware binary file to upload.
Recall that the running firmware app version was 1.2.0,
and this new version is 1.2.1.
The binary can be uploaded to an existing S3 bucket
or a new bucket can be created.
And finally, the FUOTA task requires a role
granting it permission to get the firmware binary
from the S3 bucket.
The task can now be created.
Drilling into the task details,
we can see that the status is Pending
and that the task still lacks target devices
and a session start time.
We then add devices to the task by selecting
the multicast group that we created earlier.
We can now schedule the FUOTA task.
The session start time has to be
at least 30 minutes into the future
because AWS IoT Core for LoRaWAN needs to send
setup messages to every device in the task.
The task now has a session start time,
and the state has changed from Pending,
to Session Waiting.
Upon the next uplink,
AWS IoT Core for LoRaWAN issues a command
from the Remote Multicast Setup Specification
to schedule the multicast Class C session.
The device is now furnished with the session start time,
session duration, RX frequency, and RX data rate.
At some point before the start of the session,
AWS IoT Core for LoRaWAN issues commands
from the Fragmented Data Block Transportation Specification
to set up the fragmentation session.
All is now in readiness.
At the scheduled time,
the device switches to Class C in preparation
for receiving the firmware binary file fragments.
A short time later, fragment transmission begins
on the scheduled frequency and data rate.
The time taken to transfer the entire firmware image
depends on the size of the image,
78 kilobytes in this example;
the fragment size negotiated
between AWS IoT Core for LoRaWAN and the device,
48 bytes in this example;
the RX data rate used for the session;
and the number of fragments lost during the transfer.
Just under an hour later,
the fragmentation reaches its conclusion.
In this case, only two fragments were lost.
The device has to continue past 1,638 fragments
to recover the two lost fragments.
With all fragments received,
the device reboots,
authenticates the new firmware,
and starts if authentication succeeds.
As we can see, the new firmware version 1.2.1
is successfully started
and the device rejoins the network.
Returning to the FUOTA task,
the device status is now Successful,
and the task status is Done.
Thank you for watching this video.
If you have any questions,
please ask them at repost.AWS
where you can leverage the entire AWS community.
I may see you there!
Goodbye for now.