[mle] Should partition priority be considered for FEDs during parent selection?

[EwoutBergsma]

Dear community,

I searched the existing issues and discussions but could not find this particular case addressed. While comparing OpenThread’s parent-selection implementation with the Thread 1.4.0 specification, I noticed a detail I’d like to clarify.

Thread 1.4.0 Section 4.5.2.1.1 lists the Mesh Impacting Criteria for Parent Selection. The first criterion is qualified as “For REED Devices only” and selects the highest-priority Thread Network Partition.

The specification distinguishes between the roles an FTD may operate in. In particular, an FTD may operate as a REED or as an FED, where an FED remains an End Device and does not become a Router.

In OpenThread, the parent-response handling appears to compare partitions whenever the attaching device is an FTD:

#if OPENTHREAD_FTD
  if (Get<Mle>().IsFullThreadDevice())
  {
      compare = ComparePartitions(connectivity.IsSingleton(), leaderData, mParentCandidate.mConnectivity.IsSingleton(), mParentCandidate.mLeaderData);
  }
  
  VerifyOrExit(compare >= 0);
#endif

Since a FED is also an FTD, my understanding is that partition priority can affect parent selection for FEDs as well, not just REEDs.

My reading of Section 4.5.2.1.1 is that partition priority is specifically a criterion for REEDs, whereas for an FED the first applicable Mesh Impacting criterion would be the calculated two-way link quality. Is this interpretation correct, or is there a reason OpenThread intentionally applies the partition comparison to FEDs as well?

Thanks for any clarification,
Ewout

[jwhui]

Your reading of the Thread specification (Section 4.5.2.1.1, Mesh Impacting Criteria) is correct. The specification explicitly qualifies the partition priority criterion with "For REED Devices only". Strictly speaking, for non-REED devices (FEDs, MEDs, and SEDs), parent selection would begin evaluation with the calculated two-way link quality.

In OpenThread, applying partition comparison across all FTDs (including FEDs) is an intentional design choice for network stability and consistency:

1. Partition Convergence and Stability: In a multi-partition scenario within radio range, lower-priority partitions are expected to eventually merge into the highest-priority partition. If an FED attached to a lower-priority partition simply because of a slightly better link margin at attach time, it would likely experience network churn when that partition is merged or dismantled. Attaching to the highest-priority partition connects the FED directly to the primary, dominant network.
2. Dynamic Router Eligibility: An FTD's router eligibility can change dynamically at runtime (for example, via API configuration or security policy changes). If an FED were attached to a lower-priority partition and later had router eligibility enabled, it would immediately need to migrate or trigger a merge. Keeping all FTDs on the highest-priority partition avoids this churn.
3. Consistent FTD Partition Tracking: OpenThread maintains partition awareness across all FTDs. Even while operating as a child, an FTD that hears an MLE Advertisement from a higher-priority partition will proactively attempt to migrate to it. Considering partition priority during initial parent selection aligns with this ongoing behavior.
4. Local Decision and Interoperability: Parent selection is a local node decision. Preferring the highest-priority partition on an FED does not compromise protocol interoperability with other Thread devices. MTD devices, by contrast, focus purely on link quality and parent priority.

Do you have a specific use case or reason in mind where an FED would benefit from a different behavior?

[EwoutBergsma]

Thanks a lot for the fast and thorough answer, hugely appreciated.

No, I do not have a specific use case or reason in mind where different behavior would be beneficial. I am specifically interested in learning the details on how to stay in spec; the curiosity that I posted above was an attempt at finding how much wiggle room there is between the spec and the implementation.

On that note, I would have a follow-up question. It slightly deviates from the original post, but is a direct reponse to your answer. I hope you don't mind. Two observations:

• I see you write: "Preferring (...) does not compromise protocol interoperability with other Thread devices.";
• in section 4.5.3 Parent Reselection of Thread spec 1.4 I read that the parent selection criteria must be applied when reselecting a parent.

However, in a scenario where an MED would reselect a parent, deviating from the selection criteria may not compromise the protocol interoperability with other Thread devices (i.e. an MED will not become a router and thus have little to no impact on the topology). For example, in anticipation of future changes (say, in a predictable dynamic environment) an MED preemtively changes parent without strictly applying the current comparison criteria.

Would doing so possibly stay within spec? It may not compromise the protocol interoperability and may prevent network churn.

[jwhui]

Here is how to think about this in the context of Thread:

1. Spec Conformance vs. Interoperability

• Wire Interoperability: From a purely functional standpoint, if an MED attaches to a different parent router, the rest of the Thread network will continue to operate normally. Because an MED is a leaf node and does not route traffic or participate in the router topology, selecting a different parent does not corrupt routing tables or break network-wide state. As long as standard MLE message exchanges (Parent Request/Response, Child ID Request/Response) are adhered to, the device remains interoperable on the wire.
• Strict Spec Conformance & Certification: From a formal specification perspective, normative "MUST" statements in Sections 4.5.2 and 4.5.3 are mandatory for compliance. Thread certification test cases explicitly validate parent selection by presenting the Device Under Test (DUT) with multiple Parent Responses containing different link qualities, parent priorities, and buffer capacities to verify that the DUT selects the candidate strictly according to the hierarchical criteria in Section 4.5.2.1. Deviating from these criteria would cause the device to fail certification.

2. Triggering Reselection vs. Candidate Evaluation

It is helpful to separate the process into two distinct parts:

1. When to initiate parent reselection (Trigger): The Thread specification gives implementations considerable flexibility regarding the local heuristics used to trigger parent search/reselection (e.g., RSS degradation thresholds, packet loss, frame retry failures, periodic timers, or even application-level mobility hints). Proactively or preemptively starting a parent search based on predictive environmental factors is fully compatible with the spec.
2. How candidate parents are evaluated (Selection): Once a multicast Parent Request is sent and Parent Responses are received, the evaluation and ranking of those candidate parents must follow Section 4.5.2.1 to remain strictly in-spec.

3. Summary & Contributing to the Specification

• Preemptively triggering parent search: Fully acceptable and often beneficial in dynamic environments to prevent abrupt disconnections and network churn.
• Overriding candidate comparison rules: While it won't break the mesh topology on the wire, it is technically out of spec and would fail automated Thread certification testing.

If you see compelling use cases where adjusting the parent selection/reselection criteria or allowing additional implementation flexibility would benefit the ecosystem, keep in mind that the Thread Group maintains the Thread Specification. We encourage joining the Thread Group to participate in technical working groups and propose changes or enhancements directly to the Thread Specification.

[EwoutBergsma]

Again, thank you! Your answers have been extremely helpful to me.