DECT-NR+ Scheduling Latency issues

RE: DECT-NR+ Scheduling Latency issues

BillyBobJoe — Tue, 01 Sep 2026 15:42:17 GMT

I am part of the Opener initiative and they are hosting a copy of my repo. I suggest you look at the very prominent README.md

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Mon, 31 Aug 2026 12:23:55 GMT

Dont get me wrong @BiilyBobJoe or WilliamGFish, this Question has nothing todo with the github repo Opener Repo ... I used this as a reference here for compare in research topics.
It is related to the Nordic Radio specially for DECT-2020, Nr+ on a 91xx SoC.

There is also a opener initiative ongoing https://github.com/Opener-Initiative but this is open source initiave of many different stakeholders.

The MAC stack I or we are wrote and using is completly different from your code, completly invisible from public and closed source only. That is why I cannot simply use a link to our code pieces, but to those which is public in github as a reference.
Some parts are in discussion to open in public place, since we are on DECT-2020 NR+ Topic since the beginning, and we are in the meetings which are going on.

If you still find something suspicious write me an E-Mail and we could create an appointment with a meeting, mr. BillyBobJoe or WilliamGFish

kind regards.

RE: DECT-NR+ Scheduling Latency issues

BillyBobJoe — Mon, 31 Aug 2026 10:49:41 GMT

I'm the author and am suspicious of people who need to remain anonymous using copyright and licensed code.

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Mon, 31 Aug 2026 08:16:04 GMT

Thanks!

I was in the intern meeting about this topic. :)

Have a great day!

RE: DECT-NR+ Scheduling Latency issues

BillyBobJoe — Mon, 31 Aug 2026 02:07:13 GMT

Do you have permission to use the code in Opener Repo as that is for research purposes only and requires permission for use?

RE: DECT-NR+ Scheduling Latency issues

Amanda Hsieh — Fri, 14 Aug 2026 18:44:59 GMT

This is explained in the documentation DECT NR+ physical layer — nrfxlib 3.3.1 documentation, I hope well enough.

Thus, if you schedule operations the first operation you need to take the t_{standby_to_idle} and t_{idle_to_active} into account depending on radio mode. The second operation needs only t_{min_sched_opr_trans_dly} also noted as t_m in the figures.

The modem packet scheduler handles automatically whether it has time to go to IDLE or STANDBY between consecutively scheduled operations. If you have scheduled multiple operations in advance.

If it goes to IDLE or STANDBY then the next operation always pays the t_{standby_to_idle} and t_{idle_to_active} delays.

So if the modem knows what is going to happen after current radio command it is executing the delay between radio operations is < 1 slot. But if it does not know, or the command comes too late, i.e. modem is already transitioning to IDLE or to STANDBY, then you pay additional latency.

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Fri, 14 Aug 2026 13:04:05 GMT

Thanks a lot for the answer! :)

Most of this is we figured already out.
The we rely currently on the "scheduled_operation_transition"

Is this the correct delay to be used than or

idle_to_active + <operation_startup_time + duration> + active_to_idle ?
It feels like that with low_latency mode we are already scheduling massive staying in ACTIVE somekind of and only the <operation_startup_time + duration> + scheduled_operation_transition + <operation_time> is necessary.

Can you put some light into this darkness for me?

kind regards
Christoph

RE: DECT-NR+ Scheduling Latency issues

Amanda Hsieh — Fri, 14 Aug 2026 12:48:21 GMT

Currently each modem command is atomic thus modem goes after the operation to “idle/stand-by” state and next operation needs to get back “up” from idle state to “active” state. Fast, back-to-back tx-tx, rx-rx, tx-rx or rx-tx operations require some work from our side and new FW release.

The delays in state transitions is inherent to modem RF resources ramping down and ramping up for next transmission/reception. Currently the gap you have to have is approximately single slot. The exact value is reported in API. This value in microseconds you can convert to ticks by multiplying the duration with 69.12MHz clock.

Please also see the FW / NCS compatibility matrix.

RE: DECT-NR+ Scheduling Latency issues

Amanda Hsieh — Wed, 12 Aug 2026 16:24:02 GMT

I have removed the name. Let me know if anything is missing.

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Mon, 10 Aug 2026 12:01:30 GMT

can you remove the name please?
thanks in advance ...

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Thu, 23 Jul 2026 13:56:00 GMT

thanks for quick reply :)

Sure it can wait,

next two weeks I am in vacation.

Hope to hear from you.

RE: DECT-NR+ Scheduling Latency issues

Amanda Hsieh — Thu, 23 Jul 2026 12:37:27 GMT

Our experts are on vacation. I will check with them and update the case when they are back. I am sorry about any inconvenience this might cause.

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Thu, 23 Jul 2026 08:38:05 GMT

Hello again,

to add more insights:
Please see in git post Line the idle_to_active
https://github.com/Opener-Initiative/dect_open_stack_ms/blob/main/lib/dect_nrplus/mac/dect_mac_sm_ft.c#L3105

We achive something similiar but this is somekind of waste of a slot or a blind-slot for each op, right?

I want to stay in Radio ACTIVE for some Slots, is that possible? With different TX Ops ? or RX Ops

Scenario (with sycnd devices)

Assuming I have a stream of data, which should be addressed scheduled to others. One device will schedule different slots pre-allocated / scheduled.
But the delay is important here, it should be keep low as possible.

Radio is in low latency mode and the ops_transsion delay and other I am aware of.
But why that many delay?

Cant I just stay in ACTIVE State wait for new data or new data is arrived (assuming dma + acklowged isr), checking for next timeslot to schedule and use that data for that timeslot.

After the frame is over remove it, or keep in softbuffer if necessary, is that so?

I am basically searching for the lowest latency with high output of data I could achieve.

Just the idea in reducing the idle_to_active, active_to_idle delays just haveing a small operation_transistion delay or wait_for_dma + IPC sth. ?

Thanks in advance
Have a great day :)

bye

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Thu, 23 Jul 2026 07:43:14 GMT

All fine, they do internally somehow.

I am the just the tech guy, not in the management world.

ncs is: v3.2.4

mfw: mfw-nr+-phy_nrf91x1_2.0.0.zip

Regards,
Christoph

RE: DECT-NR+ Scheduling Latency issues

Amanda Hsieh — Wed, 22 Jul 2026 15:02:04 GMT

Hi,

What NCS and MFW versions are you using?

[quote user="schnitzlein"]You can also address this question with from a company you might well know[/quote]

Sorry, I cannot find the information regarding the name you mentioned.

Regards,
Amanda H.

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Wed, 22 Jul 2026 14:21:51 GMT

I am not allowed to mention the name here. We have the same questions related with being in ACTIVE Mode and schedule time in for cast.

RE: DECT-NR+ Scheduling Latency issues

schnitzlein — Wed, 22 Jul 2026 12:36:15 GMT

How far in advance (in ticks if possible) should we schedule new Operations to have TX after TX Operation with 2 Slots usage and directly after this the next TX Operation?
You can put this to private if you want, because it sounds not to be mentioned yet for the public and is mostly related with a scheduled access transmission.