Improve the Device Troubleshooting guide with no_absolute_gateway_time & scheduling conflict errors.

[ymgupta]

Summary

Add different causes for the failure of downlink scheduling (ns.down.data.schedule.fail) at the Network Server to the Device troubleshooting guide.

Why do we need this?

Adding common downlink scheduling issues to the Devices troubleshooting documentation will be useful for the Users.

What is already there? What do you see now?

Troubleshooting points for downlink issues. https://www.thethingsindustries.com/docs/devices/troubleshooting/#when-i-schedule-a-downlink-i-see-the-ns[…]downlink-message-fails-to-be-transmitted

What is missing? What do you want to see?

Add the below troubleshooting points for the failure of downlink scheduling at NS (ns.down.data.schedule.fail).

Insights:

We have observed that the downlink schedule failure (ns.down.data.schedule.fail) event occurs with the following errors:

1. no_absolute_gateway_time
   This error occurs for the following conditions:

• Scheduling downlink with absolute time
• The gateway did not report absolute time, i.e., there's no GPS time sync
• There are less than 5 downlinks sent in the last 30 minutes

Ref: https://github.com/TheThingsIndustries/lorawan-stack-support/issues/225#issuecomment-763603798

Note: For Class B and C scheduling on an absolute time, the Gateway Server needs to sync the absolute time of the server with that of the gateway. This can be done in two ways:

• When the gateway reports its GPS time (requires the gateway to have GPS)
• Gateway Server observes the round-trip times and infers the gateway's absolute time. It takes five round-trips for this to be a reliable value. Hence the gateway has to transmit five normal downlink frames before GS uses the gateway for absolute time scheduling.

Ref: TheThingsNetwork/lorawan-stack#3487 (comment)

2. scheduling conflict
   This error is observed when there is device synchronization ( more devices sending uplinks or joins at a time)
   To avoid the synchronization of devices,

• Configure the end devices to send uplinks/initiate joins at random times or with random delays.
• Improve the coverage by adding more gateways in the respective location

Refer Best Practices section for more insights on how to avoid device synchronization.

How do you propose to document this?

...

Can you do this yourself and submit a Pull Request?

No.