Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

RE: Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

Kenneth — Thu, 19 Mar 2026 14:02:40 GMT

Hello,

Please make a new case for this request.

Kenneth

RE: Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

ErMaqsood — Tue, 17 Mar 2026 16:14:52 GMT

Hello,

Greeting for the day.

I appreciate your support.

I currently have a DECT NR+ setup running on the nRF9151, based on the HELLO DECT PHY sample using nRF Connect SDK v3.3.0preview2. I am seeking your guidance on how to route data across a small NR+ cluster, specifically in the following topology:

[cluster1] Leaf (Node1) ⇄ Router (Relay) ⇄ Leaf (Node2) [cluster2]

Could you please advise on the correct approach, configuration, or APIs required to enable multi‑hop data routing between Leaf nodes through the Router?

Thank you.

RE: Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

dejans — Mon, 27 Oct 2025 15:42:31 GMT

Hi,

The issue might not be related to MAC as MAC specification as does not mandate how scheduling should be done. PHY layer does not control this as well. It is up to a custom MAC implementation to figure out what kind of scheduling should be supported. This can depend on network topology, latency and reliability requirements. Proper direction would be to consider the timeline devices can support and build scheduling which can support this.

Best regards,
Dejan

RE: Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

Muhammad Ahsan — Mon, 27 Oct 2025 12:33:07 GMT

Hello,

Please find attached the complete log from the relay node.

Sequence overview:

Assigning role name
Starting beacon (beacon_start)
Scanning for beacons and sending association requests to neighboring nodes (sink and leaf — we are using three boards in total)

The scheduling conflict seems to occur because beaconing is an ongoing task, and at the same time we attempt to perform association operations, which causes overlapping scheduled activities.
However, we can’t stop beaconing, as it is required for the boards to transmit payloads, turning it off would prevent data transmission and break the associations.

I have uploaded the important logs — please have a look at them.

Regards,

Muhammad Ahsan Khalid

RE: Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

dejans — Wed, 22 Oct 2025 15:38:35 GMT

Hi,

Thank you for additional information.

Can you upload your complete log?

Best regards,
Dejan

RE: Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

Muhammad Ahsan — Tue, 21 Oct 2025 13:10:20 GMT

Hi,

Thanks for your reply.

On all our boards, beaconing is running continuously — every node (sink, relay, and leaf) keeps its beacon active at all times. While beaconing is ongoing, we also try to associate each node with its neighboring node to form a chain for bidirectional communication, where the relay node needs to associate with both the upstream and downstream nodes (double association).

The issue is that when we try to perform association while beaconing is still active, we get the ERR_OP_SCHEDULING_CONFLICT error. This seems to happen because both the beacon transmission and the association procedure are scheduled operations that overlap in time.

However, from my understanding, beaconing must stay active because if we stop it after the other boards have scanned and associated, the boards automatically become disassociated. So we can’t simply turn off the beaconing after association. Is this correct? Our goal is to enable bidirectional communication [[which inherently requires
beaconing to remain active for neighboring associations -- is this part redundant?]]

Do you have any suggestions or recommended approaches to support this kind of setup continuous beaconing with concurrent association without triggering
scheduling conflicts?

Best regards,
Ahsan

RE: Subject: Scheduling Conflict During Beacon Scan and Association Between DECT NR+ Nodes (Sink–Relay–Leaf Topology)

dejans — Thu, 16 Oct 2025 11:43:46 GMT

Hi,

ERR_OP_SCHEDULING_CONFLICT error is shown in nrf_modem_dect_phy_error and indicates scheduling error where another operation has been scheduled at the same time. Since the error seems to be related to scheduling, you can look at scheduling documentation - scheduling operations and examples of scheduling.

Is your application based on any of existing samples?

Can you provide additional information about your application and test setup?

Best regards,
Dejan