13  Topology Visualizer

Key Concepts

• Interactive Simulation: A software tool that allows users to modify topology parameters and observe changes in real time without physical hardware
• Node Failure Simulation: Removing or disabling a node in a simulation to measure the impact on connectivity and routing
• Link Quality Slider: An interactive control that adjusts packet error rate on a simulated link to model RF interference
• Topology Visualisation: A graphical representation of network nodes and links, often colour-coded by node type or link quality
• Live Metric Display: A real-time dashboard showing hop count, packet delivery ratio, and latency as topology parameters change
• Parameter Sweep: Running a simulation across a range of values for one variable (e.g., number of nodes) to find optimal operating points
• Reproducible Experiment: A simulation with fixed random seeds that produces identical results when re-run, enabling peer verification

13.1 In 60 Seconds

This interactive chapter lets you experiment with star, mesh, tree, ring, and hybrid topologies in a browser-based visualizer. Adjust node counts and compare metrics like connection count, fault tolerance, and latency to build intuition about which topology fits different IoT deployment scenarios.

13.2 Learning Objectives

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

• Operate Interactive Visualizers: Manipulate topology parameters and observe how metrics change in real time
• Compare Topology Metrics: Contrast connection counts, failure modes, and performance across topology types
• Interpret Physical Topology Diagrams: Analyse building floor plans and device placement for coverage
• Apply Knowledge to Scenarios: Evaluate topology choices through scenario-based design questions

For Beginners: Topology Visualizer

This interactive tool lets you explore different network topologies by selecting a topology type and adjusting the number of nodes with a slider. The diagram updates instantly showing you how devices connect, and a summary table explains the characteristics of each topology. It is a visual, hands-on way to understand network layouts and trade-offs.

Sensor Squad: Play with Network Shapes!

“This is the fun chapter!” said Sammy the Sensor. “You get to build networks yourself and see what happens when you change things. Try a star with 6 nodes, then switch to a mesh —watch how the number of connections explodes!”

“My favorite experiment is the failure test,” said Max the Microcontroller. “Build a star network and remove the central hub. Everything disconnects! Now build a mesh and remove a node —the other nodes still have paths to each other. Seeing it visually really drives the lesson home.”

Lila the LED suggested, “Try building a tree topology and counting the hops from the leaf nodes to the root. Then compare it to a mesh —the tree has more hops but uses fewer connections. You can literally see the trade-off between efficiency and resilience.”

“Adjust the node count slider and watch the metrics change,” added Bella the Battery. “With 5 nodes, a full mesh needs 10 links. With 10 nodes, it needs 45 links. With 20 nodes, 190 links! The visualizer makes it obvious why full mesh does not scale and why we use partial mesh and hybrid designs instead.”

13.3 Prerequisites

• Topologies Introduction: Physical vs logical topology concepts
• Topology Types: Understanding of star, mesh, ring, bus, tree characteristics

---

13.4 Interactive Topology Visualizer

Interactive: Network Topology Visualizer

Experiment with different network topologies to understand their characteristics and trade-offs for IoT deployments.

Select Topology: Star Full Mesh Partial Mesh Tree (Hierarchical) Ring Bus Number of Nodes: 6

Topology Characteristics

Key Insights for IoT:

• Star topology is ideal for simple deployments where all devices can reach a central gateway (smart homes, office sensors)
• Mesh topology provides self-healing for critical applications but scales poorly beyond ~100 nodes due to connection overhead
• Tree topology efficiently aggregates traffic in large facilities by organizing devices hierarchically
• Partial mesh balances redundancy and cost by protecting only critical communication paths
• Bus and Ring are rarely used in modern wireless IoT but remain common in wired industrial systems (CAN bus, I2C)

Design Rule of Thumb: Start with star for simplicity. Use mesh when reliability trumps cost. Choose tree for large-scale hierarchical deployments.

---

13.5 Physical Topologies

Figure 13.1: Physical topology examples showing actual device placement and cable layouts

13.5.1 Purpose and Features

Physical topology shows actual layout of network in real space.

Includes:

• Building floor plans
• Device locations (to scale)
• Cable routes and lengths
• Wireless coverage areas
• Wall materials (for RF planning)
• Data points and outlets

13.5.2 Physical vs Logical Topology: Key Differences

Figure 13.2: A building floor plan physical topology showing sensor placement, cable runs, and room boundaries

Key differences from logical:

• Drawn to scale (or dimensioned)
• Shows actual physical locations
• Includes building structure
• Cable routes show actual paths (not straight lines)

13.5.3 IoT Physical Topology Considerations

In IoT environments, physical topology shows:

1. Sensor/actuator exact locations
   • Temperature sensors on exterior walls
   • Motion detectors at entry points
   • Smart lights in ceiling grid
2. Wireless coverage optimization
   • Wi-Fi access point placement
   • LoRa gateway coverage areas
   • Zigbee mesh node distribution
3. Power and connectivity
   • PoE (Power over Ethernet) cable runs
   • Power outlet locations
   • Battery-powered device accessibility
4. Environmental factors
   • Wall materials (concrete blocks wireless signals)
   • Metal structures (interference)
   • Distance limitations for protocols

---

Common Mistake: Confusing Connection Count with Network Resilience

The Mistake: Many students assume that “more connections = always better” and conclude that full mesh topology is always the most reliable choice.

Why This Is Wrong: Connection count and resilience are NOT linearly related. Adding connections beyond a threshold provides diminishing returns while dramatically increasing cost and complexity.

Real-World Example with Numbers:

A facility management company deployed 40 temperature sensors across a warehouse:

Attempt 1 - Full Mesh (Incorrect):

• Connections: 40 × 39 / 2 = 780 links
• Configuration time: 780 × 2 minutes = 26 hours
• Cost: 780 × $50 (wireless link setup) = $39,000
• Routing table size: Each node maintains 39 neighbors
• Network convergence time after failure: 45-90 seconds (large tables)
• Result: Installation took 3 weeks. Network experienced routing instability (oscillating paths) due to large routing tables.

Attempt 2 - Partial Mesh with 40% Connectivity (Correct):

• Connections: 780 × 0.40 = 312 links
• Configuration time: 312 × 2 minutes = 10.4 hours
• Cost: 312 × $50 = $15,600
• Avg connections per node: (312 × 2) / 40 = 15.6 neighbors
• Routing table size: 15-16 neighbors per node
• Network convergence time: 15-25 seconds
• Fault tolerance test: Shut down 5 random nodes → network remained connected
• Result: Deployment completed in 2 days. Network stable. 60% cost savings.

Attempt 3 - Strategic Partial Mesh (Optimal):

• Core routers (8 nodes in center): 50% connectivity = 14 connections
• Edge sensors (32 nodes): 25% connectivity = 124 connections
• Total: 138 connections
• Cost: 138 × $50 = $6,900
• Fault tolerance test: Core router failure → edge nodes reroute via other core routers
• Result: 82% cost savings vs full mesh, comparable reliability

Key Insight: The optimal connectivity ratio for IoT mesh networks is typically 40-60% of full mesh. This provides: - 3-5 alternate paths for most node pairs (survives 2-3 simultaneous failures) - Manageable routing table size (15-30 neighbors per node) - Fast convergence (< 30 seconds) - Reasonable cost (40-60% of full mesh investment)

When Full Mesh Makes Sense:

• Very small networks (< 10 nodes)
• Ultra-high reliability requirements (aerospace, medical devices)
• When all nodes are equidistant and forming mesh is trivial

Design Rule: For N > 15 nodes, use partial mesh with 40-60% connectivity. Place extra connections strategically at network core and bottleneck points, not uniformly across all nodes.

Putting Numbers to It

Let’s quantify the scaling behavior of different topologies as node count increases:

Link count formulas: \[ \begin{aligned} \text{Star:} &\quad L_{\text{star}} = n \\ \text{Ring:} &\quad L_{\text{ring}} = n \\ \text{Tree (binary):} &\quad L_{\text{tree}} = n - 1 \\ \text{Full mesh:} &\quad L_{\text{mesh}} = \frac{n(n-1)}{2} \\ \text{Partial mesh (40\%):} &\quad L_{\text{partial}} = 0.4 \times \frac{n(n-1)}{2} \end{aligned} \]

Scaling comparison (5, 10, 20, 50 nodes):

Topology	n=5	n=10	n=20	n=50	Growth rate
Star	5	10	20	50	O(n)
Ring	5	10	20	50	O(n)
Tree	4	9	19	49	O(n)
Partial (40%)	4	18	76	490	O(n²)
Full mesh	10	45	190	1225	O(n²)

Connection growth ratio (links added per new node): \[ \begin{aligned} \text{Star:} &\quad \frac{dL}{dn} = 1\text{ link/node} \\[0.5em] \text{Full mesh:} &\quad \frac{dL}{dn} = n - 1\text{ links/node} \\[0.5em] \text{At } n=50\text{:} &\quad 49\text{ new links per added node!} \end{aligned} \]

Cost impact (adding 51st node @ \(50/link):\)$ \[\begin{aligned} \text{Star addition cost:} &\quad 1 \times 50 = \$50 \\ \text{Tree addition cost:} &\quad 1 \times 50 = \$50 \\ \text{Partial mesh (40\%) cost:} &\quad 20 \times 50 = \$1000 \\ \text{Full mesh addition cost:} &\quad 50 \times 50 = \$2500 \end{aligned}\]

$$

Network diameter impact (theoretical bounds): \[ \begin{aligned} \text{Star diameter:} &\quad D = 2\text{ (constant)} \\ \text{Ring diameter (bidirectional):} &\quad D = \lfloor \frac{n}{2} \rfloor \\ \text{Tree diameter (balanced binary):} &\quad D = 2\lfloor\log_2(n)\rfloor \\ \text{Mesh diameter:} &\quad D = 1\text{ (full) or } 2\text{-}3\text{ (partial)} \end{aligned} \]

At n=50 nodes:

• Star: 2 hops always
• Ring: 25 hops worst case (bidirectional: floor(50/2) = 25)
• Tree: 2×floor(log₂(50)) = 2×5 = 10 hops
• Mesh: 1-3 hops

Result: Topology choice determines both scaling economics (O(n) vs O(n²) link growth) and latency scaling (constant vs logarithmic vs linear diameter growth).

Try It: Topology Link Count & Cost Calculator

viewof n_nodes = Inputs.range([3, 100], {value: 20, step: 1, label: "Number of nodes (n)"})
viewof cost_per_link = Inputs.range([10, 500], {value: 50, step: 10, label: "Cost per link ($)"})
viewof mesh_pct = Inputs.range([10, 100], {value: 40, step: 5, label: "Partial mesh connectivity (%)"})

{
  const n = n_nodes;
  const cpl = cost_per_link;
  const pct = mesh_pct / 100;

  const links = {
    star:    n,
    ring:    n,
    tree:    n - 1,
    partial: Math.round(n * (n - 1) / 2 * pct),
    mesh:    Math.round(n * (n - 1) / 2)
  };
  const costs = Object.fromEntries(Object.entries(links).map(([k, v]) => [k, v * cpl]));

  const fmt = (v) => v.toLocaleString();
  const color = (v, max) => {
    const ratio = v / max;
    if (ratio < 0.25) return '#16A085';
    if (ratio < 0.6)  return '#E67E22';
    return '#E74C3C';
  };

  return html`<table style="width:100%;border-collapse:collapse;font-family:Arial,sans-serif;font-size:14px;">
    <thead>
      <tr style="background:#2C3E50;color:white;">
        <th style="padding:10px;text-align:left;">Topology</th>
        <th style="padding:10px;text-align:right;">Links</th>
        <th style="padding:10px;text-align:right;">Total Cost</th>
        <th style="padding:10px;text-align:right;">vs Full Mesh</th>
        <th style="padding:10px;text-align:right;">Links added per new node</th>
      </tr>
    </thead>
    <tbody>
      ${[
        ['Star',                  links.star,    costs.star,    n - 1 > 0 ? ((links.star  / links.mesh)*100).toFixed(1)+'%' : '-', '1'],
        ['Ring',                  links.ring,    costs.ring,    ((links.ring  / links.mesh)*100).toFixed(1)+'%', '1'],
        ['Tree (binary)',         links.tree,    costs.tree,    ((links.tree  / links.mesh)*100).toFixed(1)+'%', '1'],
        [`Partial mesh (${mesh_pct}%)`, links.partial, costs.partial, ((links.partial/links.mesh)*100).toFixed(1)+'%', Math.round((n-1)*pct)+''],
        ['Full mesh',             links.mesh,    costs.mesh,    '100%',  (n-1)+'']
      ].map(([name, lc, tc, ratio, marginal], idx) => html`
        <tr style="background:${idx%2===0?'#f8f9fa':'white'};">
          <td style="padding:8px;font-weight:600;">${name}</td>
          <td style="padding:8px;text-align:right;color:${color(lc, links.mesh)};font-weight:600;">${fmt(lc)}</td>
          <td style="padding:8px;text-align:right;">$${fmt(tc)}</td>
          <td style="padding:8px;text-align:right;">${ratio}</td>
          <td style="padding:8px;text-align:right;">${marginal}</td>
        </tr>`)}
    </tbody>
  </table>
  <p style="margin-top:8px;font-size:12px;color:#7F8C8D;">
    Marginal cost to add one more node to a full mesh of ${n} nodes: <strong>$${fmt((n) * cpl)}</strong>
    vs <strong>$${fmt(cpl)}</strong> for star/tree/ring.
  </p>`;
}

---

13.6 Knowledge Check Questions

13.7

Interactive: IoT Network Topology Simulator

Match: Topology Metrics

Order: Evaluating a Topology Using the Visualizer

Common Pitfalls

1. Treating Interactive Simulation Results as Ground Truth

Simulations use simplified radio models that omit multipath, near-far effects, and hardware variation. Fix: clearly label simulation results as “model predictions” and plan physical validation before deployment.

2. Only Exploring Default Parameter Settings

The default simulation configuration is usually a best-case scenario. Fix: systematically vary at least three parameters (node count, packet error rate, traffic load) and record how each affects the chosen metrics.

3. Not Recording Simulation Configurations for Reproducibility

Running a simulation without saving the configuration means results cannot be replicated or reviewed. Fix: export or screenshot simulation parameters alongside every result.

Label the Diagram

Code Challenge

13.8 Summary

• Interactive visualizer helps understand topology characteristics through hands-on experimentation
• Connection formulas: Star = n, Ring = n, Tree = n−1, Full mesh = n(n−1)/2, Partial mesh (40%) ≈ 0.4×n(n−1)/2
• Physical topology shows actual device locations, cable routes, and building layouts
• Logical topology shows network connections independent of physical placement
• Both views needed for complete IoT network documentation and planning

13.9 Concept Relationships

Foundation Concepts:

• Topology Types - Understanding basic topology structures enables effective use of this visualizer
• Physical vs Logical Topologies - The visualizer shows logical topology (how data flows)

Related Tools:

• Network Topology Lab - Hands-on ESP32 simulation implements these topologies in code
• Simulations Hub - Additional network topology simulation tools

Apply What You Learned:

• Topology Selection - Use visualizer metrics to support topology selection decisions
• Hybrid Design - Combine multiple topologies explored here

13.10 See Also

Interactive Learning:

• Knowledge Graph - See how topologies connect to protocols and routing
• Wokwi Simulators - ESP32 topology implementations you can modify

Deep Dives:

• Mesh Analysis - Graph theory metrics for the mesh topologies shown here
• Failure Scenarios - What happens when nodes fail in each topology type

13.11 What’s Next

If you want to…	Read this
Apply findings from simulation to real hardware	Topology Lab
Understand the analysis metrics used in simulations	Topology Analysis
Design a hybrid topology based on simulation insights	Hybrid Design
Review topology selection criteria	Topology Selection
See comprehensive review and assessment	Comprehensive Review