18  Network Topologies: Design Analysis

Key Concepts
  • Review Objective: Consolidating the topology analysis methods and metrics learned in earlier chapters before assessment
  • Graph Metric Summary: A reference table of diameter, connectivity, average path length, and betweenness centrality for each topology type
  • Failure Impact Matrix: A table showing how different failure scenarios (single node, single link, gateway) affect each topology type
  • Complexity vs Resilience Trade-off: The inverse relationship between deployment simplicity (favouring star) and fault tolerance (favouring mesh)
  • Scalability Analysis: Calculating how connection count and routing table size grow with node count for different topologies
  • Worked Example Review: Re-solving representative topology analysis problems to reinforce calculation methods
  • Common Error Patterns: Mistakes that frequently appear in assessments, such as confusing connectivity with average degree

18.1 In 60 Seconds

This review chapter focuses on analyzing topology designs through network diameter calculations (how diameter affects latency), protocol-topology matching (which IoT protocols use which topology types), and distinguishing physical from logical topologies. You will work through scenario-based problems that test your ability to evaluate how different topologies respond to node failures.

This chapter focuses on analyzing network topology designs:

  • We examine network diameter and its impact on latency
  • You will learn protocol-topology matching for IoT systems
  • We analyze physical vs logical topology differences

Review Topology Comparison and Trade-offs first if needed.

18.2 Learning Objectives

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

  • Calculate Network Diameter: Compute diameter for star, ring, tree, and mesh topologies and predict latency impact
  • Match Protocols to Topologies: Map IoT protocols (Zigbee, LoRaWAN, Wi-Fi) to their native topology types
  • Distinguish Physical from Logical Topologies: Identify when and why these views differ in real deployments
  • Analyse Failure Scenarios: Predict how each topology type degrades when nodes or links fail

18.3 Prerequisites

Required Chapters:

Estimated Time: 25 minutes

18.4 Network Diameter Analysis

Two topologies both have 20 nodes. Topology A (star) has diameter=2, Topology B (line) has diameter=19. How does this affect IoT performance?

A) No significant difference B) Topology A has better latency (fewer hops) C) Topology B has better scalability D) Topology A has more redundancy

Show Answer

Answer: B) Topology A has better latency (fewer hops)

Network Diameter Explained:

  • Diameter = Maximum shortest path between any two nodes
  • Topology A (Star): Diameter = 2
    • Any device -> Central hub -> Any other device
    • Maximum 2 hops for any communication
  • Topology B (Line): Diameter = 19
    • Node 1 to Node 20 requires 19 hops
    • Messages traverse entire line

Latency Impact:

# Assume 10ms latency per hop
latency_per_hop = 10  # ms

# Topology A (Star): diameter = 2
max_latency_A = 2 * latency_per_hop  # = 20 ms

# Topology B (Line): diameter = 19
max_latency_B = 19 * latency_per_hop  # = 190 ms

speedup = max_latency_B / max_latency_A  # = 9.5x
print(f"Topology A is {speedup}x faster!")

IoT Implications:

  • Low diameter = Fast communication (critical for real-time control)
  • High diameter = Slow propagation (problematic for time-sensitive data)
  • Battery impact: More hops = more energy consumption
  • Reliability: Longer paths = more failure points

Topology selection:

  • Real-time control -> Low diameter (star, partial mesh)
  • Periodic sensing -> Diameter less critical (line, tree acceptable)

Network Diameter Impact on End-to-End Latency

Compare latency for different topologies with 50 nodes, 20 ms per hop:

Star topology (50 devices + 1 hub): \[ \text{Diameter} = 2 \text{ (device → hub → device)} \] \[ \text{Max latency} = 2 \times 20 \text{ ms} = 40 \text{ ms} \]

Tree topology (3 levels: root + 7 routers + 42 end devices): \[ \text{Diameter} = 4 \text{ (end device → router → root → router → end device)} \] \[ \text{Max latency} = 4 \times 20 \text{ ms} = 80 \text{ ms} \]

Ring topology (50 nodes in circle): \[ \text{Diameter} = \lfloor \frac{n}{2} \rfloor = \lfloor \frac{50}{2} \rfloor = 25 \text{ hops} \] \[ \text{Max latency} = 25 \times 20 \text{ ms} = 500 \text{ ms} \]

Mesh topology (60% connectivity, avg 3.2 hops): \[ \text{Avg path length} = 3.2 \text{ hops} \] \[ \text{Avg latency} = 3.2 \times 20 \text{ ms} = 64 \text{ ms} \]

Conclusion: For real-time control systems requiring <100 ms response, use star (40 ms) or tree (80 ms). Avoid ring (500 ms). Mesh provides good average (64 ms) with fault tolerance.

Try It: Network Diameter Latency Calculator

18.5 Protocol-Topology Matching

Which IoT protocol automatically forms a mesh topology and self-heals when nodes fail?

A) Wi-Fi B) Bluetooth Classic C) Zigbee D) LoRaWAN (Class A)

Show Answer

Answer: C) Zigbee

Zigbee Mesh Features:

# Zigbee network formation
class ZigbeeNode:
    def __init__(self, node_type):
        # Router nodes can relay
        # End devices cannot relay
        self.can_route = (node_type in ['coordinator', 'router'])

    def form_mesh(self):
        """
        Zigbee automatically:
        1. Discovers neighbors
        2. Forms mesh connections
        3. Calculates routing tables
        4. Self-heals when nodes fail
        """
        pass

# Example Zigbee network
# Coordinator creates network
# Routers join and form mesh
# End devices connect to nearest router
# If router fails, devices rejoin via alternate path

Why others don’t:

Wi-Fi:

  • Star topology (all devices -> Access Point)
  • No mesh in standard Wi-Fi (Wi-Fi Mesh is separate standard)

Bluetooth Classic:

  • Piconet topology (1 master, up to 7 slaves)
  • No mesh (Bluetooth Mesh is separate specification)

LoRaWAN Class A:

  • Star-of-stars topology
  • Devices -> Gateway -> Network Server
  • No mesh routing between devices

Zigbee advantages:

  • Automatic mesh formation
  • Self-healing (nodes reroute around failures)
  • Range extension (messages hop through routers)
  • No infrastructure (unlike Wi-Fi AP)

Use cases:

  • Smart home lighting (devices relay for each other)
  • Industrial sensors (redundant paths)
  • Building automation (self-healing network)

18.6 Physical vs Logical Topology

## Mesh Self-Healing Analysis {#net-topo-analysis-self-healing}

## Switch vs Hub Topology {#net-topo-analysis-switch-hub}

## LoRaWAN Star Architecture {#net-topo-analysis-lorawan}

## Bus Topology Failure Analysis {#net-topo-analysis-bus}

## Token Ring Latency {#net-topo-analysis-token-ring}

Try It: Token Ring Wait Time Calculator

18.7 Star vs Mesh Selection

Scenario: A warehouse automation system must choose between two network topologies for 30 robotic picking stations. The system requires real-time coordination where picking stations query the central inventory database for item locations with strict latency requirements.

Requirement: Maximum 200ms round-trip time (RTT) from any picking station to central database and back.

Given Information:

  • 30 robotic picking stations
  • 1 central database server
  • Per-hop latency: 25ms (includes processing + transmission)
  • Query size: 512 bytes
  • Response size: 256 bytes
  • Network operates at 1 Mbps

Topology Option A: Star Topology

Network structure:
[Picking Station 1] ─┐
[Picking Station 2] ─┤
      ...            ├─── [Central Switch] ─── [Database Server]
[Picking Station 29]─┤
[Picking Station 30]─┘

Diameter calculation:

  • Diameter = maximum shortest path between any two nodes
  • Worst case: Picking Station 1 → Central Switch → Database Server
  • Hops: Station → Switch (1 hop) + Switch → Server (1 hop) = 2 hops
  • Star diameter: 2

Latency analysis:

Query path:
Picking Station → Switch (25ms) → Database Server (25ms)
= 50ms

Response path:
Database Server → Switch (25ms) → Picking Station (25ms)
= 50ms

Total RTT = 50ms (query) + 50ms (response) = 100ms

Result: Star topology meets requirement (100ms < 200ms) with 100ms margin.

Topology Option B: Line Topology (Daisy-Chain)

Network structure:
[Station 1] ─ [Station 2] ─ ... ─ [Station 29] ─ [Station 30] ─ [Database Server]

Engineers considered this to “save cabling” (only 30 cables vs 31 in star).

Diameter calculation:

  • Worst case: Station 1 → all intermediate stations → Database Server
  • Hops from Station 1 to Server: 30 hops (through all 29 other stations + final hop to server)
  • Line diameter: 30

Latency analysis for worst-case station (Station 1):

Query path:
Station 1 → (through 29 stations) → Station 30 → Server
= 30 hops × 25ms = 750ms

Response path:
Server → Station 30 → (through 29 stations) → Station 1
= 30 hops × 25ms = 750ms

Total RTT = 750ms (query) + 750ms (response) = 1,500ms

Result: Line topology FAILS requirement (1,500ms >> 200ms). Exceeds latency budget by 7.5x.

Even average case fails:

Average station position: 15 (middle of line)
Average hops to server: 15
Average RTT = 2 × (15 hops × 25ms) = 750ms

Still exceeds 200ms requirement by 3.75x

Comparison Table:

Topology Diameter Worst RTT Avg RTT Meets Requirement? Margin
Star 2 100ms 100ms ✅ YES 100ms under budget
Line 30 1,500ms 750ms ❌ NO 1,300ms over budget

Real-World Impact:

The engineering team initially chose line topology to save $800 in cabling costs (31 cables vs 30). After deployment:

  • Week 1: Picking stations at far end of line (Stations 25-30) experienced 1.2-1.5 second delays
  • Week 2: Warehouse throughput dropped 45% (robots waiting for database responses)
  • Week 3: System declared inoperable, line topology ripped out
  • Week 4: Replaced with star topology (31 cables to central switch)
  • Cost of failure: $38,000 (labor for rework + 3 weeks lost productivity)

Key Lessons:

  1. Diameter matters more than hop count alone: Line topology saved only 1 cable (30 vs 31) but produced 15x worse diameter

  2. Latency scales linearly with diameter: Each hop adds consistent delay; diameter directly multiplies worst-case latency

  3. Star topology optimizes diameter: Diameter = 2 regardless of node count (30 nodes or 300 nodes, still 2 hops worst case)

  4. Never use line topology for real-time systems: Line diameter = N (number of nodes). Unacceptable for time-sensitive IoT.

  5. Cost of wrong topology choice: $800 cabling savings cost $38,000 in rework. Topology selection has business impact.

Design Rule: For real-time IoT applications with latency requirements, always choose topologies with low diameter (star: 2, mesh: 3-5, tree: 3-6). Avoid high-diameter topologies (line: N, ring: N/2).

Common Pitfalls

Knowing the formula for full-mesh connections (n(n-1)/2) but being unable to apply it quickly under assessment conditions is common. Fix: practise calculating connection counts, diameter, and availability for at least 5 different topology configurations.

Connectivity is the minimum node-cut size; degree is connections per node. These are related but different metrics. Fix: write one example that distinguishes the two: a star of 10 nodes has average degree ≈ 2 but connectivity kappa=1.

Computing that a topology has diameter=6 without explaining what that means for latency shows shallow understanding. Fix: for each metric, write one sentence explaining its practical implication for the deployment.

18.8 Summary

  • Network diameter directly impacts latency - star topology (diameter 2) is 9.5x faster than line topology (diameter 19) for 20 nodes
  • Zigbee automatically forms self-healing mesh networks, while Wi-Fi, Bluetooth Classic, and LoRaWAN use star topologies
  • Physical vs logical topology often differ - sensors physically distributed in grid can logically form star to central gateway
  • Mesh self-healing allows automatic recovery within 10-60 seconds when routers fail
  • Ethernet switches create logical star (isolated ports), unlike hubs which create logical bus (shared medium)
  • LoRaWAN star topology has gateway as single point of failure and scalability bottleneck
  • Bus topology fails completely when cable is cut due to signal reflection issues
  • Token ring provides deterministic access but adds latency proportional to ring size

18.9 What’s Next

If you want to… Read this
Attempt topology review scenarios Review Scenarios
Go back to topology fundamentals review Review Fundamentals
Study the comprehensive review Comprehensive Review
Revisit the topology analysis chapter Topology Analysis

18.10 Concept Relationships

Foundation Concepts:

Analysis Techniques:

Protocol Implementations:

Design Applications:

18.11 See Also

Interactive Learning:

Advanced Analysis:

Troubleshooting:

Continue to: Network Topologies: Scenario-Based Review