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

[Muhammad Ahsan]

Description:

Hello, We are developing a DECT NR+ communication setup using multiple nRF9161 DK boards arranged in a Sink–Relay–Leaf topology.

Each board operates as a DECT node (sink, relay, or leaf) and participates in a bidirectional communication chain. In this setup:

• Relay nodes must associate both upstream (with the previous node) and downstream (with the next node).
• All boards begin by starting a beacon, scanning for neighboring beacons, and then initiating association with detected neighboring nodes.

Observed Problem:

When the relay nodes start beaconing followed by beacon scanning and then association, the association step fails with scheduling conflict errors.

Specifically:

• After all nodes start their beacons and begin scanning, each node detects the neighboring beacons correctly.
• However, when the association procedure starts between nodes, associations fails with an error related to “scheduling conflict”.
• This happens most often on relay nodes, which attempt to associate with two neighbors (both uplink and downlink).

Codes:

NRF_MODEM_DECT_PHY_ERR_OP_SCHEDULING_CONFLICT = 0x1004

Regards,

[dejans]

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

[Muhammad Ahsan]

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

[dejans]

Hi,

Thank you for additional information.

Can you upload your complete log?

Best regards,
Dejan

[Muhammad Ahsan]

Hello,

Please find attached the complete log from the relay node.

Sequence overview:

1. Assigning role name

2. Starting beacon (beacon_start)

3. 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

[dejans]

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