class-c downlink queue processing issue. NS sends mac-commands but never reach payload data.
fancar opened this issue · 2 comments
- The issue is present in the latest release.
- I have searched the issues of this repository and believe that this is not a duplicate.
What happened?
ns keep constantly sending downlinks to class-c device, which is offline if a message in the device queue for the device is present. It happens because every iteration ns sends mac-commands in frame payload, not application data. So the task won't be removed from the queue during ACK.
What did you expect?
ns shell not send mac-commands at all.
Steps to reproduce this issue
Steps:
- add a new class-c device.
- Switch it off after it sends the first uplink.
- put a message in a queue.
- in case if ns will decide to send a >15 bunch commands in the frame payload, you will see the loop: ns sends downlinks every 2 seconds (lock time).
Could you share your log output?
Your Environment
| Component | Version |
|---|---|
| Application Server | v3.13 |
| Network Server | |
| Gateway Bridge | |
| Chirpstack API | |
| Geolocation | |
| Concentratord |
The note I've found in TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification
2285
A Class C downlink SHALL NOT transport any MAC command. If an end-device receives a
Class C downlink containing a MAC command, either in the FOpts field (if FPort is either
missing or > 0 ) or in the FRMPayload field (if FPort=0 ), it SHALL silently discard the entire
frame.
If it's still relevant, then the solution is just removing setMACCommandsSet from scheduleNextQueueItemTasks