8 Topology Analysis & Metrics
8.2 Learning Objectives
By the end of this section, you will be able to:
- Apply Graph Theory to Networks: Use connectivity, node degree, and path length metrics
- Analyze Failure Modes: Identify single points of failure and calculate availability
- Evaluate Routing Overhead: Compare routing protocol bandwidth consumption across topologies
- Calculate Scalability: Determine connection counts and bandwidth requirements
- Design for Fault Tolerance: Apply redundancy strategies to meet reliability targets
For Beginners: Topology Analysis
Analyzing a network topology means studying how devices are connected and measuring how well the arrangement performs. Think of it like evaluating different seating arrangements for a classroom – some layouts make communication easier, some are more resilient when a seat is removed, and some are cheaper to set up.
Sensor Squad: The Math Behind Networks!
“We can use actual math to measure how good a network topology is,” said Max the Microcontroller. “Node degree tells you how many connections each device has. In a star, most devices have degree 1 – they only connect to the hub. In a full mesh, every device connects to every other device.”
“Connectivity – called kappa – tells you how many nodes must fail to split the network in two,” explained Sammy the Sensor. “A star has kappa = 1, because removing the hub disconnects everything. A full mesh of 10 nodes has kappa = 9 – you would have to remove 9 devices before the network splits!”
Lila the LED did some calculations. “The number of links in a full mesh grows fast: n times (n minus 1) divided by 2. With 10 nodes, that is 45 links. With 100 nodes, it is 4,950 links! That is why full mesh is only practical for small networks.”
“And diameter measures the worst-case path length,” added Bella the Battery. “In a star, the diameter is always 2 – any message goes through the hub. In a mesh, it depends on the layout. Lower diameter means lower latency. These metrics help you compare topologies objectively instead of just guessing which one is best!”
Related Chapters
Deep Dives:
- Network Topologies Overview - Chapter index and navigation
- Basic Topology Types - Fundamental topology concepts
- Communication Patterns - Data flow patterns
- Hybrid Design - Real-world hybrid topologies
Advanced Topics:
- Routing Fundamentals - Routing protocols and algorithms
- WSN Fundamentals - Wireless sensor topologies
8.3 Prerequisites
Before diving into this chapter, you should be familiar with:
- Basic Topology Types: Understanding of star, bus, ring, and mesh topologies
- Basic Mathematics: Familiarity with logarithms and combinatorics helps with scalability calculations
8.4 How It Works: Analyzing Network Topologies with Graph Theory
Graph theory lets you predict network behavior before deployment:
Step 1 - Model as a graph: Treat each device as a node and each connection as an edge. A star with 5 devices becomes 1 hub node + 4 device nodes + 4 edges.
Step 2 - Calculate key metrics:
- Node degree: How many connections each device has (star hub has degree 4, devices have degree 1)
- Connectivity (κ): Minimum nodes to remove to split the network (star has κ=1 because removing hub disconnects all)
- Diameter: Maximum path length between any two devices (star always has diameter 2)
Step 3 - Predict failure behavior: If κ=1, you have a single point of failure. If κ=3, the network survives 2 simultaneous failures.
Example: A mesh with 10 nodes where each has 3 neighbors has κ=3 and diameter ~3-4. If 2 nodes fail, the remaining 8 stay connected because κ=3 means you need to remove 3 nodes to fragment the network.
Key Insight: Higher connectivity = more fault tolerance, but also more infrastructure cost. Partial mesh with κ=3 provides good balance.
8.5 Graph Theory Fundamentals
Network topologies can be analyzed using graph theory, where devices are nodes and connections are edges. Understanding these mathematical properties helps predict network behavior.
8.5.1 Key Graph Metrics
| Topology | Edges (n nodes) | Avg Node Degree | Connectivity (k) | Diameter | Path Length |
|---|---|---|---|---|---|
| Star | n - 1 | ~2 | 1 | 2 | 2.0 hops |
| Bus | n - 1 | ~2 | 1 | n - 1 | n/3 hops |
| Ring | n | 2 | 2 | floor(n/2) | n/4 hops |
| Full Mesh | n(n-1)/2 | n - 1 | n - 1 | 1 | 1.0 hop |
| Tree (binary) | n - 1 | ~3 | 1 | 2*log2(n) | log2(n) |
| Partial Mesh | 2n to n^2/4 | 2-6 | 2-4 | 2-4 | 1.5-2.5 hops |
8.5.2 Scalability Impact
Understanding how topologies scale is critical for IoT deployments:
- Star: O(n) connections - scales linearly, but hub bandwidth is bottleneck
- Full Mesh: O(n^2) connections - for 100 nodes = 4,950 edges (unmanageable)
- Partial Mesh: O(n*k) where k = avg degree - for 100 nodes with k=4 = 200 edges (feasible)
- Tree: O(n) connections - scales well, but depth increases as O(log n)
Putting Numbers to It
Connectivity κ (kappa) quantifies how many node failures the network can survive before fragmenting.
For a star topology with \(n\) devices: \[\kappa = 1\]
This means removing just the central hub disconnects all \(n\) devices. For a full mesh: \[\kappa = n - 1\]
With 10 nodes in full mesh, \(\kappa = 9\) — you must remove 9 nodes to fragment the network. For partial mesh with average degree \(k\): \[\kappa \approx k\]
In practice, a partial mesh with \(k = 3\) neighbors per node survives 2 simultaneous failures. This is why industrial Zigbee networks target \(k = 3\) to 4 for critical deployments — balancing cost (connections) against resilience (failure tolerance).
Real Numbers:
| Nodes | Full Mesh Connections | Partial Mesh (k=4) | Reduction |
|---|---|---|---|
| 10 | 45 | 20 | 56% |
| 50 | 1,225 | 100 | 92% |
| 100 | 4,950 | 200 | 96% |
| 500 | 124,750 | 1,000 | 99.2% |
8.6 Failure Analysis and Fault Tolerance
Different topologies respond dramatically differently to node and link failures. Understanding failure modes is critical for IoT reliability engineering.
8.6.1 Single Point of Failure (SPOF) Identification
| Topology | SPOF Type | Failure Impact | Mitigation Strategy | Cost Multiplier |
|---|---|---|---|---|
| Star | Central hub | 100% network outage | Dual-hub with failover | 2x |
| Bus | Backbone cable | 100% network outage | Redundant bus (dual cable) | 2x |
| Ring | Any single link | 50% devices isolated | Dual ring (FDDI-style) | 2x |
| Tree | Root node | 100% outage; branch = subtree | Redundant root + meshing | 1.5-3x |
| Full Mesh | None | Isolated device only | N/A (already redundant) | 1x |
| Partial Mesh | Depends on design | 10-50% devices affected | Increase connectivity (k>=3) | 1.2-1.5x |
8.6.2 Quantitative Availability Calculations
Availability = MTBF / (MTBF + MTTR)
Star with single hub (MTBF=8760h, MTTR=4h):
Availability = 8760/(8760+4) = 99.954%
Annual downtime = 4.0 hours
Star with dual-hub active-standby (each MTBF=8760h, MTTR=0.5h):
MTBF_dual = MTBF² / (2 × MTTR) = 8760² / (2 × 4) ≈ 9,594,900h
Availability = 9594900/(9594900+0.5) ≈ 99.99999%
Annual downtime < 1 minute
Mesh with k=3 (MTBF=50000h, MTTR=1h):
Availability = 50000/(50000+1) = 99.998%
Annual downtime = 0.88 hours8.7 Message Complexity and Routing Overhead
Routing overhead varies dramatically by topology. This affects bandwidth consumption, energy usage, and latency.
8.7.1 Routing Protocol Overhead by Topology
| Topology | Routing Type | Table Size | Update Frequency | Bandwidth Overhead | Convergence Time |
|---|---|---|---|---|---|
| Star | None (direct) | 1 entry | N/A | 0% | Instant |
| Ring | Distance-vector | n entries | 30-60 sec | 2-5% | 30-90 sec |
| Tree | Hierarchical | log2(n) entries | 60 sec | 1-3% | 10-30 sec |
| Partial Mesh | Link-state | n*k entries | 5-10 min | 5-15% | 1-5 min |
| Full Mesh | Link-state/flooding | n^2 entries | 5-10 min | 15-30% | 1-10 min |
8.7.2 Example: 50-Node Industrial IoT Network
Star topology (1 hub + 49 sensors):
Routing overhead: 0 bytes/sec
Each sensor -> hub -> destination (2 hops maximum)
Ring topology (50 sensors in ring):
Routing updates: 50 nodes x 100 bytes x (1/60 Hz) = 83 bytes/sec
Average path: 50/4 = 12.5 hops
Partial mesh (50 sensors, k=4 avg degree):
Link-state updates: 50 nodes x 800 bytes x (1/300 Hz) = 133 bytes/sec
Average path: 1.5-2.5 hops (much better than ring!)
Full mesh (50 sensors, all-to-all):
Link-state updates: 50 x 2450 bytes x (1/300 Hz) = 408 bytes/sec
Direct paths: 1 hop always8.8 Real-World IoT Protocol Examples
Understanding how real IoT protocols map to topologies helps with practical design decisions.
8.8.1 Protocol-to-Topology Mapping
| IoT Protocol | Topology | Typical Scale | Key Characteristics | Real-World Use Case |
|---|---|---|---|---|
| Wi-Fi | Star | 15-50 devices | Hub bandwidth 100-1000 Mbps, 30m range, SPOF at AP | Smart home cameras, voice assistants |
| Zigbee | Mesh | 50-200 nodes | k=3-4 redundancy, self-healing, coordinator-based | Industrial sensors, smart lighting |
| Thread | Mesh | 100-250 nodes | IPv6 native, border router, 2-4 hops typical | Matter smart home, building automation |
| LoRaWAN | Star-of-stars | 1000+ devices/GW | 10km range, 99.99% uptime (multi-GW), 10-year battery | Smart city parking, agriculture |
| BLE Mesh | Mesh | 30-100 nodes | Flooding-based, managed flooding, provisioner | Retail beacons, asset tracking |
| Z-Wave | Mesh | 232 nodes max | Source routing, 4 hops max, controller-based | Home security, door locks |
| NB-IoT | Star | 50,000+ devices/cell | 10km range, licensed spectrum, 99.9% uptime | Utility meters, asset tracking |
8.9 Deployment Examples
8.9.1 Smart Home Example (Hybrid Star)
Topology: Star around Wi-Fi router + Zigbee hub
Why hybrid?
- Cameras need high bandwidth (Wi-Fi star provides 100 Mbps centralized)
- Lights tolerate multi-hop latency (Zigbee mesh provides fault tolerance)
- Zigbee mesh survives individual bulb failures (lights stay functional)
- Wi-Fi AP is single point of failure (but cameras are monitoring, not life-safety)
8.9.2 Industrial Mesh Example (Zigbee in Factory)
Topology: Partial mesh with k=3-4 average degree
50-sensor factory floor monitoring:
- 10 Zigbee routers (always-on, AC-powered)
- 40 temperature/vibration sensors (battery-powered end devices)
- Each router connects to 3-4 other routers (redundant paths)
- Coordinator connects to SCADA system via Ethernet
Mesh properties:
- Connectivity k=3 (survives 2 simultaneous router failures)
- Average path length: 2.3 hops
- Routing overhead: 8% (link-state updates every 5 min)
- Self-healing: 30 sec convergence after router failure
- Battery life: 5 years (sensors sleep 99% of time, wake every 60 sec)Failure scenario:
- 1 router fails -> 3 redundant paths remain -> 0% data loss
- 2 routers fail -> some sensors use 3-hop paths -> <5% latency increase
- 3 routers fail -> network partitions -> SCADA alarm triggers
8.9.3 LoRaWAN Example (Star-of-Stars)
Topology: Star-of-stars (devices -> gateways -> network server)
Smart city parking (1000 sensors):
- 1000 parking sensors (Class A LoRaWAN)
- 3 gateways (10km range each, overlapping coverage)
- 1 network server (cloud-based)
Sensor transmits every 5 minutes:
- Uplink: 20 bytes (occupied/vacant + battery level)
- Airtime: 200 ms (SF7, 125 kHz bandwidth)
- Battery life: 10 years (2x AA batteries)
Gateway diversity:
- 75% of sensors heard by 2+ gateways (redundancy)
- Network server deduplicates packets
- If 1 gateway fails, 90% sensors still connected
- 99.99% uptime (multiple gateways cover same area)
Scalability:
- Each gateway handles 1000+ devices (duty cycle <1%)
- 3 gateways provide redundancy + load balancing
- Total cost: 3x $1000 gateways + $1000 server = $4K infrastructure8.10 Worked Example: Topology Selection for a Hospital IoT Network
Scenario: A hospital is deploying 80 medical-grade environmental sensors (temperature, humidity, air pressure) across 4 floors. The sensors must achieve 99.99% data availability because HVAC failures in operating rooms can compromise patient safety. The IT team has budget for either (a) a star topology with dual hubs, or (b) a partial mesh with Zigbee routers.
Given:
- 80 sensors, 4 floors (20 sensors per floor)
- Required availability: 99.99% (maximum 52.6 minutes downtime/year)
- Star hub cost: $2,000 each (enterprise-grade); sensor radios: $15 each
- Zigbee router cost: $45 each; mesh sensor radios: $25 each
- Downtime cost: $5,000/hour (regulatory penalties + patient safety risk)
Step 1: Calculate star topology metrics
Single hub per floor: MTBF = 8,760 hours, MTTR = 4 hours
Availability = 8,760 / (8,760 + 4) = 99.954%
Annual downtime = (4 / 8,764) × 8,760 ≈ 4.0 hours per floor
With 4 independent floors: any single floor failing = system below target
Annual downtime cost = 4.0 hours × $5,000 = $20,000 per floor
Dual hub per floor (active-standby failover): For two identical standby hubs, both must fail within the repair window. Using the redundant-system approximation: MTBF_dual = MTBF²/(2 × MTTR) = 8,760²/(2 × 4) ≈ 9,594,900 hours, MTTR = 0.5 hours
Availability = 9,594,900 / (9,594,900 + 0.5) ≈ 99.99999%
Annual downtime ≈ 0.003 minutes per floor – easily meets requirement
Infrastructure cost = 4 floors × 2 hubs × $2,000 + 80 sensors × $15 = $17,200
Step 2: Calculate mesh topology metrics
Partial mesh with k=3 average degree: MTBF > 50,000 hours, MTTR = 1 hour
Availability = 50,000 / (50,000 + 1) = 99.998%
Annual downtime = 0.175 hours = 10.5 minutes per floor – does NOT meet 99.99%
To reach 99.99%: need k=4 (MTBF ~80,000 hours)
k=4 availability = 80,000 / (80,000 + 1) = 99.9988% – meets requirement
Annual downtime (k=4) = (1/80,001) × 8,760 ≈ 0.11 hours = 6.6 minutes per floor – meets 99.99% target
Infrastructure: 4 floors × 5 routers × $45 + 80 sensors × $25 = $2,900
Step 3: Decision matrix
| Factor | Dual Star | Mesh (k=4) | Winner |
|---|---|---|---|
| Availability | ~99.99999% | 99.9988% | Star (significantly) |
| Infrastructure cost | $17,200 | $2,900 | Mesh |
| Annual downtime cost | <$1 | ~$550 | Star |
| Self-healing | No (manual failover) | Yes (automatic) | Mesh |
| Management complexity | Low (2 hubs/floor) | Medium (routing config) | Star |
| Scalability (add sensors) | Connect to hub | Add to mesh | Mesh |
Conclusion: The mesh topology at $2,900 is 83% cheaper than dual-star at $17,200. While the dual-star achieves slightly higher theoretical availability (~99.99999%), the mesh’s automatic self-healing is practically more valuable in a 24/7 hospital environment where manual intervention is slow and failure detection can take hours. For this scenario the mesh with k=4 redundancy is the recommended choice, ensuring at least 5 Zigbee routers per floor with overlapping coverage to maintain the 99.99% target.
Common Pitfalls
1. Using Network Diameter as the Sole Latency Predictor
Diameter gives worst-case hop count but ignores per-hop latency, queuing delay, and retransmissions. Fix: multiply hop count by realistic per-hop latency (including retransmission probability) for accurate end-to-end estimates.
2. Confusing Connectivity With Redundancy
A network with kappa=2 requires removing two nodes to disconnect it, but specific node pairs may still become isolated with fewer removals depending on placement. Fix: analyse failure scenarios for critical node pairs, not just the global connectivity value.
3. Computing Graph Metrics on the Logical Topology Instead of the Radio Topology
Two nodes may appear connected in the logical topology but have a marginal RF link that fails frequently. Fix: weight graph edges by link quality indicator (LQI) or packet error rate when computing metrics.
4. Ignoring Dynamic Topology Changes in Metric Calculations
Static graph metrics assume the topology does not change. IoT mesh networks constantly gain and lose nodes. Fix: compute metrics periodically and monitor trends rather than relying on a single snapshot measurement.
8.11 Summary
Network topology analysis uses graph theory to predict network behavior and make informed design decisions.
8.11.1 Key Metrics
Graph Theory:
- Connectivity (k): Star k=1, Ring k=2, Full Mesh k=n-1
- Scalability: Star O(n) edges, Mesh O(n^2), Partial Mesh O(n*k)
- Path Length: Star 2 hops, Mesh 1 hop, Ring n/4 hops average
- 100-node comparison: Full mesh 4,950 edges vs Partial mesh (k=4) 200 edges (96% reduction)
Failure Analysis:
- Star MTBF: 8,760 hours (99.954% availability, ~4.0h annual downtime)
- Mesh MTBF: >50,000 hours (99.998% availability, ~0.88h annual downtime)
- Dual-hub failover: ~99.99999% availability (MTBF²/(2×MTTR) ≈ 9.6M hours)
Routing Overhead (50-node network):
- Star: 0% overhead (direct paths)
- Ring: 2-5% overhead (distance-vector, 30-60 sec updates)
- Partial Mesh: 5-15% overhead (link-state, 5-10 min updates)
- Full Mesh: 15-30% overhead (flooding)
8.11.2 Design Guidelines
- Use connectivity (k) to determine fault tolerance requirements
- Calculate edge count to estimate infrastructure cost
- Measure routing overhead for bandwidth-constrained networks
- Model failure scenarios before deployment
8.12 Knowledge Check
8.13 Concept Check
Quick self-test (answers at the end):
- What does connectivity κ=1 indicate about a network?
- How many connections does a full mesh of 20 nodes require?
- Why does mesh routing overhead increase with network size?
Answers
- Single point of failure - removing 1 node disconnects the network (typical of star at hub)
- 190 connections - formula n(n-1)/2 = 20×19/2 = 190
- Link-state updates scale as O(n²) - each node must announce its neighbors to all others
8.14 Concept Relationships
Builds Upon:
- Basic Topology Types: Understanding star, mesh, ring, bus
- Networking Basics: Network fundamentals
Enables:
- Communication Patterns: Data flow analysis
- Topology Failures: Failure mode understanding
Related Concepts:
- Connectivity (κ) determines fault tolerance
- Network diameter affects worst-case latency
- Partial mesh balances redundancy against connection count
8.15 See Also
Analysis Tools:
- Graph Metrics Calculator: Online graph theory tool
- Network Simulator: Cisco Packet Tracer
Related Topics:
- Routing Fundamentals: Routing protocol overhead analysis
- WSN Fundamentals: Sensor network topologies
- Zigbee Architecture: Mesh implementation
Academic:
- Graph Theory Basics: Wolfram MathWorld
- Network Science: Barabási textbook (free online)
8.16 Try It Yourself
Exercise: Calculate metrics for your home network
- Draw your network: Map all devices (router, sensors, cameras, etc.)
- Count connections: How many total links?
- Identify topology: Mostly star? Partial mesh?
- Calculate connectivity κ: What’s the minimum nodes to remove to fragment it?
- Find diameter: What’s the maximum hops between any two devices?
Example: A home with Wi-Fi router + 15 devices is a star with: - 15 connections (n-1) - κ=1 (router is single point of failure) - Diameter = 2 (any device to any other through router)
Challenge: How would adding a mesh extender change these metrics?
8.17 What’s Next
| If you want to… | Read this |
|---|---|
| Study failure modes and resilience in detail | Topology Failures |
| Explore hybrid topology designs | Hybrid Design |
| Understand communication flow patterns | Communication Patterns |
| Practise with hands-on topology labs | Topology Lab |
| Review all topology content | Comprehensive Review |