For class C all downlink always happens in Rx1 window

I am using latest prebuilt binaries for all components of LoRa network server(3.0) and a linux based Raspberry Pi gateway with semtech UDP packet forwarder. For class A operation of devices everything works absolutely fine. When I configured a couple of device in class C both in ABP and OTAA mode. I observed that downlink happens at Rx1 and Rx2 frequency and data rate as per ‘rx_window’ param config in “loraserver.toml” file but always happens in Rx1 receive window (default:after 1 second of uplink) . Device repeats the same frame in uplink again and again. Could anyone please help, why this happens ? If it is a known issue ?

But in this case, isn’t the device operating in Class-A when it sends an uplink? So then it is normal that LoRa Server uses RX1 for its response as it is sending a Class-A downlink, not a Class-C downlink.

If a class C device does a confirmed uplink, server sends acknowlegment either in rx1 or rx2 depending on the server’s configuration or may be dynamically decided based on delays. I feel downlinks should happen in proper frequencies in respective rx windows. Be it class C or class A, sending rx2 frequency frames in Rx1 receive window seems not a good idea. Nodes can’t listen to it and incase of confirmed uplink use cases, resends requested data by user’s application, multiple times.