- [Greg] Hello, and welcome to Getting Started With AWS:
IoT Core for LoRaWAN, Network Analyzer.
My name is Greg Breen
and I'm an IoT Specialist Solutions Architect with AWS.
This video dives straight into the Network Analyzer feature
of the AWS IoT Core for LoRaWAN service.
To follow along, it's helpful
if you're already somewhat familiar
with LoRaWAN fundamentals
and the AWS IoT Core for LoRaWAN service.
Network Analyzer allows you to monitor
and debug your fleet by tracing network frames
and events in real time.
Activity can be traced for both devices and gateways.
The user select the specific device and gateway resources
that should be traced,
and the user can control the logging level.
We'll now learn about the features
and capabilities of the AWS IoT Core
for LoRaWAN Network Analyzer.
Using a Class A device we will;
add device and gateway resources to the configuration
to select what to trace,
trace a device joining the network,
trace a device sending uplinks,
modify the configuration to control
what frames and events are traced,
trace downlink messages being sent to a device,
and finally, trace a gateway connecting
to AWS IoT Core for LoRaWAN.
We begin by navigating to the Network Analyzer.
Network Analyzer has a default configuration.
This has frame info enabled and log level set to INFO.
These are the most verbose trace settings.
It has no devices or gateways configured,
and hints, it will not yet produce any traces.
At this time, it's not possible
to create your own configuration,
so we select this default.
Drilling down, we can again see the frame info
and the log level settings.
Clicking on the Resources tab,
we confirm the configuration lacks device
or gateway resources, and therefore we need to add some.
For the purposes of this demonstration,
I'll add just a single gateway
and a single Class A device.
Returning to the Resources tab,
we confirm that the gateway
and device have been successfully added.
We can now activate trace messaging for these two resources.
A short time after powering on the device,
we receive three trace messages
about the device joining the network.
There are two broad categories of trace messages
and these can be distinguished by the trace columns.
The first message is a log event.
You can use the configuration's log level
to control logging of these events.
The second and third messages are LoRaWAN frames.
You can use the configuration's frame info setting
to control the logging of these.
All of these messages originate from the same resource ID,
a wireless device ID in this case.
Examining the first trace message,
we see it's an event that records a successful join.
The second trace message is a join request LoRaWAN frame
from the device.
And the third trace message is a join accept frame
sent back to the device.
As you can see, the LoRaWAN frame trace message records
a great deal of information.
It records the gateway that handled the message,
the RSSI, SNR, data rate, frequency,
and fine details of the LoRaWAN MAC.
After a delay, we see the first uplink from the device.
Again, we have both a log event for the uplink
and also a LoRaWAN frame.
We examine the details of the log event
to confirm it's an uplink from the device.
Likewise, the details of the LoRaWAN frame show
that it's an unconfirmed uplink.
As before, many details are recorded.
We now deactivate the trace session,
then modify the default configuration
to disable the logging of events.
Reactivating the trace session
and repowering the device,
we see it join the network again.
However, as expected this time,
we have only LoRaWAN frames and no log events.
Deactivating the trace again,
we'll now look at the converse configuration.
We reenable log events, but disable the frame info.
Restarting both the trace and the device,
we can observe that just the log event
for the join is recorded this time
and no LoRaWAN frames are in the trace.
Now we quickly restore the LoRaWAN frame tracing
before proceeding.
Activating the trace once more,
we repower the device and wait for it to join the network.
Before proceeding to downlinks,
we pause briefly to await the first uplink.
Navigating now to our wireless device in the console,
we place a confirmed downlink message
into its downlink queue.
Returning to the active trace,
we await the next uplink.
Upon the next uplink,
we receive three trace messages,
one uplink log event, and two LoRaWAN frames.
Examining the details, our log event is an uplink.
The first LoRaWAN frame is the same unconfirmed uplink.
But the second LoRaWAN frame is the confirmed downlink
that we queued a short time ago.
Notable for its absence, however,
is a log event for the downlink.
This is because this was a confirmed downlink
and AWS IoT Core for LoRaWAN is yet to receive
an acknowledgement from the device.
Upon the next uplink, we get both a downlink
and uplink log event.
Drilling into the uplink LoRaWAN frame,
we can observe that the acknowledgement was sent,
completing the confirmed downlink.
We conclude the demonstration
by repowering the gateway to force a reconnection.
A short time later,
several wireless gateway events are recorded.
Inspecting the details,
we can see that the reconnection first caused
a disconnection,
followed shortly thereafter by a successful reconnection.
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.