Class C downlinks from TTS not being rescheduled, and being classified as Class A

[conanomori]

I am unsure if this is an issue on the Basics Station side or TTS side. My issue is that if I try to schedule multiple simultaneous downlinks from TTS to Class C devices, and I get the following errors

[S2E:INFO] ::1 diid=26714 [ant#0] - displaces ::1 diid=26715 [ant#0] due to -20ms283us overlap [S2E:VERB] ::1 diid=26715 [ant#0] - class A has no more alternate TX time [S2E:WARN] ::1 diid=26715 [ant#0] - unable to place frame

However, the expected behavior for Class C downlinks that have scheduling conflicts is for them to be reattempted as per the altTxTime function from s2e.c. I believe these downlinks are being classified as Class A, and so after looking for the alternate Tx time, gets rejected.

When I send a downlink from TTS to a Class C device, this is the log output, where "dC: 0", I assume means "Class A"

[AIO:XDEB] [5|WS] < {"msgtype":"dnmsg","DevEui":"00-00-00-00-00-00-00-01","dC":0,"diid":61948,"pdu":"60c8d4fe27800800044b278f0458dc285ba90125a9f068","priority":25,"rctx":0,"MuxTime":1722645127.194299,"RxDelay":1,"RX1DR":13,"RX1Freq":923300000,"xtime":4222125188644978}

I believe either the Basics Station is interpreting the downlink messages from TTS incorrectly, or TTS is sending the wrong downlink. The function handle_dnmsg seems straightforward enough for the J_dC case, that I suspect it is the latter. However, wanted to get a better set of eye on the issue.

[conanomori]

Update: I had opened issue #7227 for the TTS codebase. They seem to suggest that TTS intentionally does not send downlinks as Class C (i.e., dC = 2) as the expectation is that TTS performs all the necessary scheduling, and so there is not a need for the basics station to be aware that its intended for a Class C device.

[beitler]

Hi @conanomori

thanks for checking with TTS. It looks like the behavior you are observing is actually intended by this LNS provider. Nevertheless, there is probably still a problem with the LNS's downlink scheduler as it is scheduling overlapping downlinks. This should not happen in any case.

[conanomori]

Hi @beitler, thanks for the response. I'm a bit out of my depth when it comes to all this, but at first I was under the impression that the basics station does the scheduling, but a maintainer for TTS said that TTS actually does the scheduling. I'm a bit confused as to which one is responsible for this?

This problem is a bit of a roadblock for us, and are trying to come up with some workarounds. Would playing with the TX_AIM_GAP and TX_MIN_GAP parameters potentially resolve this issue? This is partly where my confusion lies because if TTS is the one doing the scheduling, then what do these parameters achieve on the BS side?

[beitler]

I see that this can be confusing as there is actually multiple levels of 'scheduling' goin on. The LoRaWAN Network Server (TTS in your case) has to make a decision at what time over which gateway to transmit a packet. This is the LNS's scheduling decision. What is special about the TTS scheduling is that it wants to have tight control and low-level knowledge of the gateway's transmissions in order to make optimal scheduling decisions. As such, TTS does not want the gateway to make autonomous re-scheduling decisions (e.g. transmitting downlinks at a different time than the originally intended one). This, I suppose, is the reason why TTS disguises the Class C downlink as a Class A downlink towards Basics Station, as Class A downlinks have fewer re-scheduling options than Class C due to the fixed reception windows in Class A.

The problem I was alluding to, is the fact, that the TTS downlink scheduler apparently attempts to transmit two downlinks with overlapping times on air over the same gateway. Presumably, this happens because you are attempting to send Class C downlinks and Class C downlinks actually skip any consistency checks the TTS downlink scheduler would normally do? Could it be that for subsequent calls to the Class C downlink API in TTS you are specifying the absolute transmission times with too little time gaps?

[conanomori]

Ok thank you for the explanation! This is starting to sound like more of a bug than a feature on TTS side.

Presumably, this happens because you are attempting to send Class C downlinks and Class C downlinks actually skip any consistency checks the TTS downlink scheduler would normally do?

I will bring this question up my TTS issue that I opened

Could it be that for subsequent calls to the Class C downlink API in TTS you are specifying the absolute transmission times with too little time gaps?

We don't specify transmission times when sending downlinks through TTS, just that there is a downlink.

And back to my point about TX_MIN_GAP, upon further investigation that wouldn't help anyway. I am consistently getting around 20-25ms overlap between frames, so even if I removed my current TX_MIN_GAP from 10ms to 0ms, that would not make up the required difference.

[beitler]

We don't specify transmission times when sending downlinks through TTS, just that there is a downlink.

Omitting an explicit transmission time likely results in a 'send as soon as possible' semantic. So, the downlink scheduling time likely just reflects more or less the TTS Class downlink API invocation time. Can you try introducing a delay of a few seconds between subsequent calls to the TTS Class C downlink API (at least when choosing the same gateway for subsequent transmissions)?

[conanomori]

Was able to fix this issue by implementing a 50ms delay between calls to TTS to send the downlinks. Considering that Class C downlinks being classified as Class A is intended by TTS, and that manually fudging the scheduling by adding a 50ms delay fixed the problem, I think this is clearly a TTS issue, so I'll close the issue. Thanks for the help!