1010  Thread Network Architecture and Device Roles

1010.1 Thread Network Architecture

NoteLearning Objectives

By the end of this section, you will be able to:

• Understand Thread’s mesh network architecture and topology
• Identify and explain all Thread device roles (Border Router, Leader, Router, REED, FED, MED, SED)
• Design Thread networks with proper router placement for reliable coverage
• Understand the Border Router’s gateway functions including NAT64/DNS64
• Use interactive visualization to explore Thread network behavior

Thread networks consist of different device types, each with specific roles:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    Internet((Internet))
    BR[Border Router<br/>Gateway + Leader Capable]

    subgraph "Always-On Mesh Backbone"
        R1[Router]
        R2[Router]
        R3[Router]
        REED[REED<br/>Router Eligible]
    end

    subgraph "End Devices"
        FED[FED<br/>Full End Device<br/>Always Listening]
        MED[MED<br/>Minimal End Device<br/>Polls Parent]
        SED[SED<br/>Sleepy End Device<br/>Low Power Polling]
    end

    Internet <--> BR
    BR <--> R1
    BR <--> R2
    R1 <--> R3
    R2 <--> R3
    R2 <--> REED
    R1 --> FED
    R2 --> MED
    R3 --> SED

    style Internet fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style BR fill:#E67E22,stroke:#2C3E50,color:#fff
    style R1 fill:#16A085,stroke:#2C3E50,color:#fff
    style R2 fill:#16A085,stroke:#2C3E50,color:#fff
    style R3 fill:#16A085,stroke:#2C3E50,color:#fff
    style REED fill:#3498db,stroke:#2C3E50,color:#fff
    style FED fill:#2C3E50,stroke:#16A085,color:#fff
    style MED fill:#2C3E50,stroke:#16A085,color:#fff
    style SED fill:#2C3E50,stroke:#16A085,color:#fff

Figure 1010.1: Complete Thread network architecture with Border Router, routers, REED, and end devices

NoteAlternative Views: Thread Network Architecture Visualizations

Thread Network Architecture

Figure 1010.2: Thread network architecture with IPv6 mesh backbone

The Thread network architecture enables seamless connectivity from constrained IoT devices all the way to cloud services. The Border Router bridges between the Thread mesh (802.15.4 radio) and IP infrastructure (Wi-Fi/Ethernet), translating between the compact Thread packets and standard IPv6 traffic while maintaining end-to-end addressing.

Thread Mesh Network

Figure 1010.3: Thread mesh network with redundant routing paths

The mesh topology provides inherent reliability through path redundancy. If any router fails, the network automatically discovers alternative routes through neighboring routers, maintaining connectivity without manual intervention. This self-healing behavior is critical for smart home reliability.

1010.2 Border Router (Thread-Wi-Fi Gateway)

Role: Connects Thread network to other IP networks (Wi-Fi, Ethernet, Internet)

Functions: - Routing: Routes packets between Thread network and external networks - NAT64: Translates IPv6 (Thread) ↔︎ IPv4 (Internet) - DNS64: DNS service for Thread devices - Service Discovery: Advertises network services - Firewall: Secures Thread network from external threats

Examples: - Google Nest Hub (2nd gen) - Apple HomePod mini - Amazon Echo (4th gen) - Dedicated Thread border routers

Requirements: - Two radios: Thread (802.15.4) + Wi-Fi/Ethernet - Always powered on (mains power) - Sufficient CPU/memory for routing

Thread Border Router

Figure 1010.4: The Thread Border Router bridges Thread mesh networks to IP infrastructure. Multiple Border Routers can exist in one network for redundancy, each providing NAT64 translation for IPv4 cloud services and forwarding multicast discovery messages between Thread and Wi-Fi networks to enable seamless Matter commissioning.

{
  const container = document.getElementById('kc-thread-arch-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A building manager is deploying Thread in a 4-story office building with 180 devices across all floors. The network architect recommends placing only one Border Router (Google Nest Hub) in the server room on Floor 1, arguing 'Thread mesh will route traffic through routers on all floors.' What critical flaw should you identify?",
      options: [
        {text: "One Border Router cannot support 180 devices; Thread requires one Border Router per 50 devices", correct: false, feedback: "A single Border Router can technically handle 250 devices (Thread's per-network limit). The issue is not capacity but availability and backhaul performance."},
        {text: "Server rooms typically have metal enclosures that block 802.15.4 radio signals, isolating the Border Router from the mesh", correct: false, feedback: "While radio interference is a valid concern, modern server rooms often have Thread-compatible locations. The bigger issue is the single point of failure and lack of redundancy."},
        {text: "Thread mesh cannot span more than 2 floors due to hop count limitations in the RPL routing protocol", correct: false, feedback: "Thread can support 4-5 hops (or more), which is sufficient for a 4-story building with proper router placement. Hop count is not the limiting factor here."},
        {text: "A single Border Router creates a single point of failure; if it fails, all 180 devices lose cloud connectivity and remote access", correct: true, feedback: "Correct! While the Thread mesh continues operating locally without a Border Router, all cloud services, remote access, and voice assistant control stop. Thread supports multiple Border Routers for redundancy. Best practice: deploy 2-3 Border Routers across different floors with different power circuits."}
      ],
      difficulty: "hard",
      topic: "thread"
    }));
  }
}

1010.3 Leader (Network Manager)

Role: Manages router ID assignment and network partition merging

Functions: - Router ID Assignment: Assigns 16-bit router IDs - Partition Management: Merges network partitions - Network Data Distribution: Maintains network configuration - Automatic Failover: If leader fails, new leader elected

Characteristics: - One per partition: Only one leader in connected network - Elected automatically: From routers using distributed algorithm - Transparent to applications: Leadership is invisible to apps - Dynamic: Leader can change if network topology changes

Important: Applications don’t need to know which device is leader

{
  const container = document.getElementById('kc-thread-arch-2');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "In a Thread smart office, the current Leader is a smart plug in Conference Room A. A power outage affects only Conference Room A, taking the Leader offline. What happens to the Thread network?",
      options: [
        {text: "The entire network goes offline until the Leader is restored; all devices must wait for the original Leader to return", correct: false, feedback: "Thread has no single point of failure. The Leader role can transfer to any Router in the network through automatic election."},
        {text: "The Border Router automatically becomes the new Leader since it has the highest priority in Thread networks", correct: false, feedback: "While the Border Router is eligible to become Leader, Thread's election algorithm considers multiple factors (connectivity, stability, weight), not just device type. The Border Router doesn't have automatic priority."},
        {text: "Routers detect the Leader failure within ~90 seconds and elect a new Leader from available Routers; network continues operating with minimal disruption", correct: true, feedback: "Correct! When routers stop receiving MLE (Mesh Link Establishment) advertisements from the Leader (typically within ~90 seconds), they initiate distributed Leader election. The router with the best 'weight' (connectivity, stability) becomes the new Leader. Network operation continues with 10-30 seconds of election time. No data loss occurs."},
        {text: "The network partitions into two segments, with each segment electing its own Leader and operating independently", correct: false, feedback: "Partition occurs only when routers lose connectivity to each other (e.g., physical separation), not just from Leader failure. If routers can still communicate, they elect a single new Leader and remain unified."}
      ],
      difficulty: "medium",
      topic: "thread"
    }));
  }
}

1010.4 Router (Always-On Routing Devices)

NoteRouter (Always-On Routing Devices)

Role: Forward packets and provide routing services

Functions: - Packet Routing: Route packets between devices - End Device Parent: Serve as parent for end devices - Network Stability: Always on to maintain mesh - Leader Eligible: Can become leader if needed

Characteristics: - Always On: Never sleep (mains powered or large battery) - Limit: Maximum 32 routers per network - Automatic: Devices automatically promote/demote to maintain optimal count

Examples: - Smart light bulbs (mains powered) - Smart plugs - HVAC controllers - Mains-powered sensors

1010.5 REED (Router-Eligible End Device)

NoteREED (Router-Eligible End Device)

Role: End device that can be promoted to router if needed

Functions: - Normal Operation: Acts as end device - Automatic Promotion: Becomes router if network needs more routers - Network Optimization: Helps maintain optimal router count

Characteristics: - Conditional: Promoted only when needed - Flexible: Can be router or end device - Typically: Mains-powered devices

Example Scenario: - Start as REED (11 active routers in network) - If routers drop to < 16, REED promotes to router - If routers reach 32, router may demote to REED

{
  const container = document.getElementById('kc-thread-arch-3');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A Thread network has 25 mains-powered devices but only 8 are currently acting as Routers. The rest are REEDs (Router-Eligible End Devices). A network administrator wants more devices to become Routers for better mesh coverage. Why aren't the REEDs promoting automatically?",
      options: [
        {text: "Thread's router promotion algorithm is conservative; with 8 routers already meeting the MIN_ROUTERS threshold (typically 10), REEDs won't promote unless routing cost increases", correct: true, feedback: "Correct! Thread's REED-to-Router promotion is conservative to avoid network instability. A REED promotes only when: (1) router count is below MIN_ROUTERS, OR (2) the REED's routing cost to the Leader is too high, OR (3) the REED has too many children. If 8 routers provide adequate paths, REEDs stay passive. Solution: configure critical devices to become Routers explicitly."},
        {text: "REEDs can only promote during network formation; once the network is stable, new Routers cannot be added", correct: false, feedback: "REEDs can promote at any time when conditions warrant. The network continuously evaluates topology and promotes/demotes devices as needed."},
        {text: "Each Router requires a license from the Thread Group; the network administrator has only purchased 8 Router licenses", correct: false, feedback: "Thread is an open standard with no per-device licensing for Router roles. Any router-eligible device can become a Router without additional fees."},
        {text: "The network has reached its Router limit; Thread networks are limited to 8 Routers per Border Router", correct: false, feedback: "Thread supports up to 32 Routers per network, not 8. The 8-router count is not a hard limit but rather the result of the automatic promotion algorithm."}
      ],
      difficulty: "hard",
      topic: "thread"
    }));
  }
}

1010.6 FED (Full End Device)

NoteFED (Full End Device)

Role: End device with full rx-on-when-idle capability

Functions: - Always Listening: Receiver always on (low latency) - Direct Communication: Can send/receive anytime - No Routing: Doesn’t forward packets for others

Characteristics: - Always On: Receiver enabled continuously - Higher Power: More power than sleepy devices - Faster Response: Low latency communication

Examples: - Mains-powered sensors requiring fast response - Security keypads - Smart displays

1010.7 MED (Minimal End Device) & SED (Sleepy End Device)

NoteMED (Minimal End Device) & SED (Sleepy End Device)

Role: Battery-powered devices that sleep to conserve power

Functions: - Poll for Messages: Wake periodically to poll parent router - Transmit When Needed: Wake, send data, return to sleep - Years on Battery: Ultra-low power consumption

Characteristics: - Sleep Cycle: Sleep 99%+ of time - Parent Router: Must have router parent to hold messages - Low Power: Optimized for battery life

Polling Intervals: - MED: Poll every few seconds (moderate latency) - SED: Poll every tens of seconds to minutes (higher latency)

Examples: - Door/window sensors - Motion sensors - Temperature sensors - Smart locks (battery powered)

1010.8 Device Type Comparison

Type	Always On	Can Route	Can Be Leader	Power	Use Case
Border Router	Yes	Yes	Yes	Mains	Gateway to internet
Leader	Yes	Yes	Yes	Mains	One per network (auto)
Router	Yes	Yes	Yes	Mains	Mesh backbone
REED	Yes	If promoted	If promoted	Mains	Flexible role
FED	Yes	No	No	Mains/Battery	Low latency
MED/SED	No (sleeps)	No	No	Battery	Ultra-low power

{
  const container = document.getElementById('kc-thread-arch-4');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "In a Thread smart home, a homeowner unplugs a smart plug in the hallway that was acting as a Router. The hallway has 3 battery-powered door sensors (SEDs) that were using this smart plug as their parent. What happens to the door sensors?",
      options: [
        {text: "The door sensors immediately lose connectivity and must be re-commissioned to join the network again", correct: false, feedback: "Thread devices do not need re-commissioning when they lose their parent. They have network credentials stored and can automatically rejoin by finding a new parent router."},
        {text: "The door sensors automatically search for and attach to a nearby router within 1-2 minutes, maintaining connectivity through the mesh", correct: true, feedback: "Correct! SEDs poll for their parent periodically. When polls fail, they enter orphan mode and scan for router advertisements (sent every ~32 seconds). They attach to the strongest available router, typically within 1-2 minutes. No re-commissioning needed."},
        {text: "The door sensors continue operating normally because they store messages locally and batch-upload when a router becomes available", correct: false, feedback: "While SEDs can buffer some messages, they need an active parent router to communicate. They cannot operate indefinitely without a parent. The self-healing mechanism is about finding a new parent, not offline storage."},
        {text: "The network Leader automatically reassigns the sensors to new parent routers within milliseconds through centralized management", correct: false, feedback: "Thread uses distributed self-healing, not centralized reassignment. The Leader manages router IDs and network state but does not assign parent-child relationships. SEDs autonomously find new parents through scanning."}
      ],
      difficulty: "medium",
      topic: "thread"
    }));
  }
}

1010.9 Interactive Thread Network Demo

NoteInteractive: Thread Network Demo

Explore how Thread networks self-organize with different device roles. Adjust network size to see how routers form the mesh backbone, end devices attach to parents, and the leader coordinates the network. Simulate leader failure to watch automatic failover in action.

viewof networkSize = Inputs.range([5, 40], {
  value: 15,
  step: 1,
  label: "Network Size (devices)"
})

viewof routerRatio = Inputs.range([0.2, 0.6], {
  value: 0.4,
  step: 0.05,
  label: "Router Ratio"
})

viewof simulateFailure = Inputs.toggle({
  label: "Simulate Leader Failure",
  value: false
})

viewof showLinkQuality = Inputs.toggle({
  label: "Show Link Quality",
  value: true
})

threadRoles = ({
  BORDER_ROUTER: { name: "Border Router", color: "#E67E22", canRoute: true, canLead: true, power: "Mains" },
  LEADER: { name: "Leader", color: "#9b59b6", canRoute: true, canLead: true, power: "Mains" },
  ROUTER: { name: "Router", color: "#16A085", canRoute: true, canLead: true, power: "Mains" },
  REED: { name: "REED", color: "#3498db", canRoute: false, canLead: false, power: "Mains" },
  SED: { name: "SED", color: "#2C3E50", canRoute: false, canLead: false, power: "Battery" },
  MED: { name: "MED", color: "#7F8C8D", canRoute: false, canLead: false, power: "Battery" }
})

// Generate Thread network with proper role distribution
generateThreadNetwork = (size, routerRatio, leaderFailed) => {
  const nodes = [];
  const links = [];

  // Calculate role counts
  const numRouters = Math.max(3, Math.floor(size * routerRatio));
  const numREED = Math.floor(numRouters * 0.2);
  const numEndDevices = size - numRouters - numREED - 1; // -1 for border router
  const numSED = Math.floor(numEndDevices * 0.6);
  const numMED = numEndDevices - numSED;

  // Border Router (always first, at center-top)
  nodes.push({
    id: 0,
    role: "BORDER_ROUTER",
    x: 300,
    y: 60,
    weight: 100,
    isLeader: false,
    parentId: null,
    children: []
  });

  // Generate routers in a mesh pattern
  let nodeId = 1;
  const routerNodes = [];

  // First router becomes Leader (unless failed)
  for (let i = 0; i < numRouters; i++) {
    const angle = (i / numRouters) * Math.PI * 1.5 + Math.PI * 0.25;
    const radius = 100 + (i % 2) * 40;
    const node = {
      id: nodeId,
      role: i === 0 && !leaderFailed ? "LEADER" : "ROUTER",
      x: 300 + Math.cos(angle) * radius,
      y: 180 + Math.sin(angle) * radius,
      weight: 90 - i * 2,
      isLeader: i === 0 && !leaderFailed,
      failed: i === 0 && leaderFailed,
      parentId: 0,
      children: []
    };
    nodes.push(node);
    if (!node.failed) routerNodes.push(node);
    nodeId++;
  }

  // If leader failed, elect new leader from remaining routers
  if (leaderFailed && routerNodes.length > 0) {
    const newLeader = routerNodes.reduce((best, node) =>
      node.weight > best.weight ? node : best, routerNodes[0]);
    newLeader.role = "LEADER";
    newLeader.isLeader = true;
    newLeader.electedLeader = true;
  }

  // Add REED devices
  for (let i = 0; i < numREED; i++) {
    const angle = Math.random() * Math.PI * 2;
    const radius = 160 + Math.random() * 30;
    nodes.push({
      id: nodeId,
      role: "REED",
      x: 300 + Math.cos(angle) * radius,
      y: 200 + Math.sin(angle) * radius,
      weight: 50,
      isLeader: false,
      parentId: routerNodes.length > 0 ? routerNodes[Math.floor(Math.random() * routerNodes.length)].id : 0,
      children: []
    });
    nodeId++;
  }

  // Add SED (Sleepy End Devices)
  for (let i = 0; i < numSED; i++) {
    const parentRouter = routerNodes.length > 0
      ? routerNodes[Math.floor(Math.random() * routerNodes.length)]
      : nodes[0];
    const angle = Math.random() * Math.PI * 2;
    const dist = 30 + Math.random() * 25;
    nodes.push({
      id: nodeId,
      role: "SED",
      x: parentRouter.x + Math.cos(angle) * dist,
      y: parentRouter.y + Math.sin(angle) * dist,
      weight: 10,
      isLeader: false,
      sleeping: Math.random() > 0.3,
      parentId: parentRouter.id,
      children: []
    });
    nodeId++;
  }

  // Add MED (Minimal End Devices)
  for (let i = 0; i < numMED; i++) {
    const parentRouter = routerNodes.length > 0
      ? routerNodes[Math.floor(Math.random() * routerNodes.length)]
      : nodes[0];
    const angle = Math.random() * Math.PI * 2;
    const dist = 35 + Math.random() * 20;
    nodes.push({
      id: nodeId,
      role: "MED",
      x: parentRouter.x + Math.cos(angle) * dist,
      y: parentRouter.y + Math.sin(angle) * dist,
      weight: 20,
      isLeader: false,
      parentId: parentRouter.id,
      children: []
    });
    nodeId++;
  }

  // Generate mesh links between routers
  const allRouters = nodes.filter(n =>
    (n.role === "ROUTER" || n.role === "LEADER" || n.role === "BORDER_ROUTER") && !n.failed
  );

  for (let i = 0; i < allRouters.length; i++) {
    for (let j = i + 1; j < allRouters.length; j++) {
      const dist = Math.sqrt(
        Math.pow(allRouters[i].x - allRouters[j].x, 2) +
        Math.pow(allRouters[i].y - allRouters[j].y, 2)
      );
      if (dist < 200) {
        const quality = Math.max(30, 100 - dist * 0.4 + Math.random() * 20);
        links.push({
          source: allRouters[i].id,
          target: allRouters[j].id,
          quality: quality,
          type: "mesh"
        });
      }
    }
  }

  // Generate parent-child links for end devices
  nodes.forEach(node => {
    if (node.parentId !== null && node.role !== "BORDER_ROUTER" && !node.failed) {
      const parent = nodes.find(n => n.id === node.parentId);
      if (parent && !parent.failed) {
        const dist = Math.sqrt(
          Math.pow(node.x - parent.x, 2) + Math.pow(node.y - parent.y, 2)
        );
        links.push({
          source: node.parentId,
          target: node.id,
          quality: Math.max(40, 95 - dist * 0.3),
          type: node.role === "SED" || node.role === "MED" ? "parent" : "mesh"
        });
      }
    }
  });

  return { nodes, links };
}

network = generateThreadNetwork(networkSize, routerRatio, simulateFailure)

// Visualization
{
  const width = 600;
  const height = 420;
  const svg = d3.create("svg")
    .attr("viewBox", [0, 0, width, height])
    .attr("width", "100%")
    .attr("height", height)
    .style("max-width", "100%")
    .style("background", "#f8f9fa")
    .style("border-radius", "8px");

  svg.append("text")
    .attr("x", width / 2)
    .attr("y", 25)
    .attr("text-anchor", "middle")
    .attr("font-size", "16px")
    .attr("font-weight", "bold")
    .attr("fill", "#2C3E50")
    .text("Thread Network Topology");

  const linkGroup = svg.append("g").attr("class", "links");

  network.links.forEach(link => {
    const source = network.nodes.find(n => n.id === link.source);
    const target = network.nodes.find(n => n.id === link.target);
    if (source && target) {
      linkGroup.append("line")
        .attr("x1", source.x)
        .attr("y1", source.y)
        .attr("x2", target.x)
        .attr("y2", target.y)
        .attr("stroke", link.type === "mesh" ? "#16A085" : "#7F8C8D")
        .attr("stroke-width", link.type === "mesh" ? 2 : 1)
        .attr("stroke-dasharray", link.type === "parent" ? "4,2" : "none")
        .attr("opacity", showLinkQuality ? link.quality / 100 : 0.6);
    }
  });

  const nodeGroup = svg.append("g").attr("class", "nodes");

  network.nodes.forEach(node => {
    const role = threadRoles[node.role];
    const g = nodeGroup.append("g")
      .attr("transform", `translate(${node.x}, ${node.y})`);

    const radius = node.role === "BORDER_ROUTER" ? 18 :
                   node.role === "LEADER" ? 16 :
                   node.role === "ROUTER" ? 14 :
                   node.role === "REED" ? 12 : 10;

    if (node.failed) {
      g.append("circle")
        .attr("r", radius + 4)
        .attr("fill", "none")
        .attr("stroke", "#c0392b")
        .attr("stroke-width", 3)
        .attr("stroke-dasharray", "4,2");
    } else if (node.sleeping) {
      g.append("circle")
        .attr("r", radius)
        .attr("fill", role.color)
        .attr("opacity", 0.4)
        .attr("stroke", role.color)
        .attr("stroke-width", 2)
        .attr("stroke-dasharray", "2,2");
    } else {
      g.append("circle")
        .attr("r", radius)
        .attr("fill", role.color)
        .attr("stroke", node.isLeader ? "#FFD700" : "#fff")
        .attr("stroke-width", node.isLeader ? 3 : 2);
    }

    if (node.electedLeader) {
      g.append("circle")
        .attr("r", radius + 5)
        .attr("fill", "none")
        .attr("stroke", "#FFD700")
        .attr("stroke-width", 2)
        .attr("stroke-dasharray", "4,2");
    }

    if (!node.failed) {
      g.append("text")
        .attr("y", radius + 14)
        .attr("text-anchor", "middle")
        .attr("font-size", "9px")
        .attr("fill", "#333")
        .text(node.sleeping ? `${role.name} (zzz)` : role.name);
    }
  });

  if (simulateFailure) {
    svg.append("text")
      .attr("x", width / 2)
      .attr("y", height - 10)
      .attr("text-anchor", "middle")
      .attr("font-size", "12px")
      .attr("fill", "#c0392b")
      .attr("font-weight", "bold")
      .text("New Leader Elected! Network recovered in ~10-30 seconds");
  }

  return svg.node();
}

How to Use This Demo:

1. Adjust Network Size: Slide to add/remove devices. Watch how routers form the mesh backbone.
2. Change Router Ratio: Higher ratios mean more mains-powered devices that can route traffic.
3. Simulate Leader Failure: Toggle to see automatic leader election.
4. Show Link Quality: Toggle to see simulated link quality percentages.

Key Observations: - Orange node (Border Router) connects Thread mesh to Internet - Purple node (Leader) manages network state - any router can become leader - Teal nodes (Routers) form always-on mesh backbone - Blue nodes (REED) can become routers if needed - Dark/Gray nodes (SED/MED) are battery-powered end devices - Dashed circles indicate sleeping devices (power saving)

1010.10 Summary

This chapter covered Thread network architecture and device roles:

• Border Router: Gateway between Thread mesh and Wi-Fi/Internet, provides NAT64/DNS64
• Leader: Network coordinator elected from routers, manages partition state
• Router: Always-on mesh backbone, forwards packets, can host end devices
• REED: Can be promoted to router when network needs more routing capacity
• FED: Always-listening end device for low-latency applications
• MED/SED: Battery-powered devices that sleep to conserve power

1010.11 What’s Next

Continue to Thread Deployment Guide for real-world deployment examples, common pitfalls, and best practices for Thread network design.