Gateway Server computes incorrect concentrator_timestamp for Class C downlink, causing TOO_EARLY TxAck

[zyuupup0907-bot]

Summary

When scheduling a Class C downlink via UDP Packet Forwarder, the Gateway Server occasionally computes a concentrator_timestamp that jumps far into the future, resulting in a TOO_EARLY TxAcknowledgment from the gateway.

Environment

• Version: ttn-lw-gateway-server 3.35.2-SNAPSHOT-58357ea7da
• Protocol: UDP (Semtech UDP Packet Forwarder)
• Frequency Plan: EU_863_870_TTN
• Device Class: Class C

What happened

While sending multicast downlinks to a Class C device, the concentrator_timestamp in the scheduled downlink message suddenly jumped from a normal value to an abnormally large one, and the gateway responded with TOO_EARLY.

Normal downlink (immediately before the problematic one)

"scheduled": {
  "frequency": "869525000",
  "timestamp": 2358424571,
  "concentrator_timestamp": "2358424571544"
}

TxAck result: success

Problematic downlink (next one, ~3 seconds later)

"scheduled": {
  "frequency": "869525000",
  "timestamp": 1297309563,
  "concentrator_timestamp": "5592276859385"
}

TxAck result: TOO_EARLY

Observed pattern

All previous downlinks had concentrator_timestamp values incrementing by ~3 seconds (consistent with the downlink interval):

2289389020638
2292412083309
2295423923511
2298431708900
2301387336930
2304395826750
2307411974818
2310416532287
2313438416167
2316424247158
2319463594163
2322476410236
2325503037508
2328417827289
2331408244003
2334461982748
2337467716776
2343072132934
2344621501038
2346401874715
2349443675934
2352470826616
2355487505503
2358424571544  ← last normal
5592276859385  ← sudden jump (~54 minutes into the future)

The jump from 2358424571544 to 5592276859385 is a delta of ~3233 seconds (~54 minutes), completely inconsistent with the expected ~3 second interval.

Analysis

The 32-bit timestamp field dropped from 2358424571 to 1297309563. The Gateway Server computed a future send time that crossed the 32-bit microsecond counter boundary (2^32 = 4294967296), and when converting to the 64-bit concentrator_timestamp, it accounted for a rollover:

1297309563 + 4294967296 ≈ 5592276859 → matches the concentrator_timestamp prefix of 5592276859385

The schedule attempt shows this was a Class C downlink:

"request": {
  "class": "CLASS_C",
  "rx2_data_rate": { "lora": { "bandwidth": 125000, "spreading_factor": 12, "coding_rate": "4/5" } },
  "rx2_frequency": "869525000",
  "priority": "NORMAL",
  "frequency_plan_id": "EU_863_870_TTN"
}

For Class C downlinks, the Gateway Server computes the send timestamp itself (unlike Class A where it's derived from the uplink RX window). It appears the GS used a stale or incorrect concentrator clock reference when calculating the 32-bit timestamp for this downlink, producing a value (1297309563) far in the past relative to the current concentrator counter (~2.36 billion). The rollover detection then interpreted this as a future time, resulting in the abnormally large concentrator_timestamp.

Expected behavior

The concentrator_timestamp should have been approximately 2361424571544 (previous value + ~3 seconds), and the downlink should have been transmitted successfully.

Steps to reproduce

1. Set up a gateway connected via UDP Packet Forwarder
2. Schedule Class C downlinks at a regular interval (~3 seconds)
3. Continue for an extended period (the gateway had been connected for ~20 minutes before the issue occurred)
4. Observe that eventually a downlink gets an incorrect concentrator_timestamp and fails with TOO_EARLY

Additional context

• The gateway had been connected since 2026-04-09T11:25:09Z, and the issue occurred at 2026-04-09T11:45:20Z (~20 minutes after connection).
• The gateway's uplink timestamp values at the time were in the ~2.3-2.4 billion range, which is past the halfway point of the 32-bit counter.
• Round trip times were stable (median ~132ms), so network instability is unlikely to be the cause.

[KrishnaIyer]

@zyuupup0907-bot Thanks for filing the issue.

@halimi: Can this be reproduced?

[halimi]

@zyuupup0907-bot Thanks for reporting the issue.

I have some questions, because this kind of jump (~1 hour) can happen when the duty cycle limit has reached.

Could you please check that the "Enforce duty cycle" is enabled in the gateway settings? And when you scheduling the downlinks do you hit the duty cycle limit?

If that is the case and you don't want to this downlink with the future timestamp be sent out then please make sure that the "Schedule downlink late" is enabled in the gateway settings.

[zyuupup0907-bot]

@zyuupup0907-bot Thanks for reporting the issue.

I have some questions, because this kind of jump (~1 hour) can happen when the duty cycle limit has reached.

Could you please check that the "Enforce duty cycle" is enabled in the gateway settings? And when you scheduling the downlinks do you hit the duty cycle limit?

If that is the case and you don't want to this downlink with the future timestamp be sent out then please make sure that the "Schedule downlink late" is enabled in the gateway settings.

Thank you for your reply. The issue is indeed caused by the downlink transmission reaching the duty cycle limit, and it has been resolved by adjusting the transmission frequency.