Downlink is Pending

Hello,
Node Settings:
Class A,
Interval 1 hour
data confirmed

Gateway Profile:
Class B and C disabled, So it is Class A
Join Type Is ABP

What Is Happening
The Communication between the Node and the device happening perfectly for the past few months but In the Last 10 Days, The Node has not been able to get Downlink Confirmation data.
I added a Queue to send from the gateway to Node, but after 2 days Queue is still there, pending status is no.

The confirmed data logs.

The Unconfirmed Data Logs


I compared it with other devices that were installed at the same time but still able to get the downlink data from the gateway.
Here is the logs of a working downlink in another device

I see this difference the class b flag is true and f_pending is true, maybe be downlink is going in pending. and why class b is true? the profile is working on class A.
*** class_b:true**
*** f_pending:true**

The f_pending and class_b flags share the same bit. On uplink class_b means that the device is operating as Class-B (it has a beacon lock).

On downlink f_pending indicates that the LNS has more data to send to the device.

The device is set To class A and working for the last few months, how suddenly has it changed to Class B?

If it is set to class B by any unauthorized activity how can I set it to class A because the message I add to the queue remains in the queue forever.

i am not able to access the device but I configured commands to change parameters in Node from getaway but the gateway is not sending a single command.

Please help me it’s a bit urgent.
see the confirmed data logs the class b is false.

I change the downlink count to higher values, but still the same.
can you tell me how to debug that what is the issue?

It did not. In your screenshots, the class_b=false, where in one of the downlinks, it is set to true. As I already said, the f_pending and class_b share the same bit, meaning they are both true or both false. In short, for uplink look at the class_b field, for downlink f_pending.

You can reproduce this behavior by enqueueing two items, you will see the first downlink has f_pending=true as there is an other item to send, the second f_pending=false as after this downlink the queue is empty.

Other devices are successfully receiving data from the first gateway, but this one device isn’t. When I moved it to the second gateway, the pending message cleared. Since both gateways share ChirpStack, the pending message initially sent by the first gateway was cleared once it connected to the second gateway.