Thread MLE Parent Selection Workbench

See how a Thread child evaluates Parent Responses, chooses a parent, and searches for a better parent without treating the teaching score as a specification formula

animation
thread
mle
parent-selection
mesh
routing
Learner-ready Thread MLE parent selection workbench with Parent Request/Response flow, link-margin evidence, candidate scoring guardrails, REED promotion notes, better-parent search, quick reference, guided practice, and primary OpenThread source links.
Thread MLE Parent selection Link margin Teaching score

Thread MLE Parent Selection Workbench

A joining Thread device does not simply attach to the nearest radio. It sends an MLE Parent Request, studies Parent Responses from nearby Routers and eligible REEDs, then establishes a Child-Parent link with the best acceptable candidate.

Chosen parent Hall Router
Active MLE stage Network known
Teaching score Lower is better
Guardrail Not a spec formula
Interactive workbench

Choose a parent from real MLE evidence

Use the presets first, then move the device, add child load, and toggle REED responses. The table keeps the formula units visible: link margin is in dB, RSSI is in dBm, and the score is a labeled teaching aid.

Run the scenario

Step through the attach flow or let it play. Reset returns to a stable, easy-to-read home mesh.

Negative values favor left-side routers; positive values favor right-side candidates.
Add children to the scenario focus router to show why capacity can block an otherwise good parent.
Used by the better-parent search card. OpenThread exposes this as configurable behavior.
The attach exchange is still a Child-Parent link; the mode changes the operational note.
When enabled, Router Eligible End Devices may answer Parent Requests and upgrade before accepting a child.

MLE attach scene

The child already has Thread network credentials and is ready to discover nearby parents on the selected Thread network.

Best link: 24 dB SED polls parent Teaching score only
Decision

Hall Router selected

Hall Router has the strongest acceptable two-way evidence and enough child capacity.

Guardrail

Score is instructional

This page combines link quality, connectivity, load, priority, and role into a teaching score. It is not a normative Thread specification formula.

Parent search

Stay attached unless improvement is clear

The best candidate must beat the current parent by a configurable RSS margin before a better-parent search is worth the energy.

Evidence table

Compare Parent Responses

OpenThread exposes Parent Response fields such as RSSI, parent priority, and link-quality buckets. This workbench also shows child capacity as a practical acceptance guardrail.

Candidate Role / eligibility Radio evidence Connectivity Capacity Teaching score Result
Guided flow

Follow the MLE attach steps

Each step changes the scene, packet label, candidate highlights, and diagnosis cards together.

1

Network known

The device already has Thread credentials and network identifiers.

2

Parent Request

The child multicasts MLE Parent Request to neighboring Routers and selected REEDs.

3

Responses

Candidates reply with link margin, connectivity, Leader Data, counters, and challenges.

4

Compare

The child ranks acceptable candidates and filters blocked or weak parents.

5

Child ID

The child sends Child ID Request to the chosen parent and receives Child ID Response.

6

Monitor

The child watches link quality and may search for a better parent if the improvement is clear.

Beginner ramp

What to know before the knobs

Parent means next hop for a child

A Thread End Device does not forward for others. It sends ordinary network traffic through its selected parent Router or upgraded REED.

Strong radio is not enough

The candidate also needs useful connectivity to the Thread partition, available child capacity, and acceptable parent priority.

Better-parent search saves energy

Children should not constantly roam. Search thresholds and intervals avoid wasting battery for tiny RSSI changes.

Quick reference

Selection terms in one screen

Parent Request

Multicast MLE request from the attaching child.

  • Includes Mode, Challenge, Scan Mask, and Version.
  • The scan mask controls which device types may answer.

Parent Response

Unicast reply from a Router or eligible REED.

  • Includes link margin, connectivity, Leader Data, source address, and counters.
  • RSSI and link quality are useful evidence, not the only decision.

REED

Router Eligible End Device.

  • May respond if the scan mask allows it.
  • Must upgrade before accepting a Child ID Request.

Parent priority

A parent can advertise preference.

  • Use it as one signal alongside radio and connectivity.
  • Do not use it to hide weak links or full capacity.
Guided practice

Try these checks

Find the reliable parent

  • Select Weak close router.
  • Increase the position bias toward the right.
  • Watch when a stronger but farther parent becomes better.

Test REED behavior

  • Select REED can help.
  • Toggle Include REEDs in scan mask.
  • Check the Child ID stage to see the upgrade note.

Diagnose roaming

  • Select Better-parent search.
  • Move Current parent RSSI from -76 dBm to -58 dBm.
  • Notice when the diagnosis changes from search to stay.
Deeper notes

Technical guardrails

Formula and unit validation

This page intentionally uses a teaching score: score = link penalty + connectivity penalty + load penalty + role/priority guardrail. Lower is better. Link margin is shown in dB, RSSI in dBm, child capacity as children used over accepted maximum, and priority as a Parent Response signal. The formula is not presented as a normative Thread parent-selection formula.

Why link margin dominates many examples

A parent with excellent connectivity but poor link quality can burn battery through retries and missed polls. That is why the workbench makes weak radio evidence visible before route convenience. A production stack may combine more signals and implementation-specific thresholds than this page shows.

Primary source links