7 Network Topology Types
7.2 Learning Objectives
By the end of this section, you will be able to:
- Classify Topology Types: Categorize star, bus, ring, full mesh, and partial mesh by structural properties and connection formulas
- Evaluate Topology Characteristics: Compare advantages, disadvantages, and failure modes of each type
- Select Topologies for IoT Scenarios: Justify which topology best fits a given deployment based on cost, reliability, and scale
- Interpret Network Diagrams: Analyse logical topology symbols and hierarchical layout conventions
For Beginners: Network Topology Types
This chapter explores the main types of network topologies used in IoT: star, bus, ring, full mesh, and partial mesh. Each type is like a different way of arranging desks in a classroom – some make it easy for the teacher to reach everyone, others make it easy for students to talk to each other directly.
Sensor Squad: Meet the Topology Family!
“Let me introduce the five topology types,” said Max the Microcontroller. “Star: everyone connects to one central device. Think Wi-Fi – all your gadgets connect to the router. Simple, but the router is a single point of failure.”
“Bus: everyone shares one cable,” said Sammy the Sensor. “Old-school Ethernet used this. Cheap but collision-prone. Ring: data passes around a circle – fair but fragile. If one link breaks, the whole ring stops.”
“Full mesh: every device connects to every other device,” added Lila the LED. “Maximum resilience, but the number of connections grows incredibly fast. With 10 devices, you need 45 connections! Partial mesh is more practical – key devices get extra links for reliability while others save on connections.”
“In IoT, you will mostly see star and mesh,” concluded Bella the Battery. “Star for Wi-Fi and LoRaWAN where simplicity matters. Mesh for Zigbee and Thread where self-healing and range extension through hopping matter. Understanding all five types helps you recognize and design the hybrid networks used in real deployments.”
7.3 Prerequisites
- Topologies Introduction: Understanding of physical vs logical topology concepts
7.4 Logical Topologies Overview
7.4.1 Purpose and Features
Logical topology explains network operation, not physical layout.
Key features:
- Symbols - Simplified device icons
- Flow lines - Represent connections and data flow
- Layout - Hierarchical arrangement
- Labels and addresses - Device identification and IP information
7.4.2 Network Device Symbols
Common symbols (Cisco-style):
Note: No official international standards for network symbols (unlike electrical symbols). Cisco conventions are widely adopted.
7.4.3 Link Symbols
| Symbol | Meaning |
|---|---|
| Solid line | Ethernet (wired) |
| Dashed line | Wireless connection |
| Wavy line | Serial connection |
| Lightning bolt | High-speed link |
| Thick line | Multiple connections bundled |
7.4.4 Hierarchical Layout
Best practice: Arrange logical diagrams hierarchically
Layout principles:
- Core devices at top/center
- Connected devices radiating outward
- Two-way data flow understood
- Hierarchy shows message routing
7.5 Star Topology
Configuration: All devices connect to central node (switch/hub)
Characteristics:
- Easy to install and manage
- Failure of one device doesn’t affect others
- Easy to add/remove devices
- Central node is single point of failure
- Requires more cable than bus topology
IoT Use Cases:
- Smart home with central hub
- Office sensors connected to gateway
- Industrial sensors to local controller
7.6 Extended Star Topology
Configuration: Multiple star topologies interconnected
Characteristics:
- Highly scalable
- Fault tolerance (one switch fails, others continue)
- Hierarchical management
- More complex configuration
IoT Use Cases:
- Multi-building campus network
- Large industrial facility
- Smart city infrastructure
7.7 Bus Topology
Configuration: All devices share common medium (bus)
Characteristics:
- Minimal cable required
- Easy to extend
- Well-suited for temporary networks
- Bus failure affects entire network
- Difficult to troubleshoot
- Performance degrades with many devices
IoT Use Cases:
- I2C sensor bus (on same PCB)
- CAN bus in vehicles
- Legacy building automation systems
7.8 Ring Topology
Configuration: Devices connected in circular sequence
Characteristics:
- Equal access for all devices
- Predictable performance
- No collisions (token-based)
- Single device failure can break ring
- Difficult to reconfigure
IoT Use Cases:
- Fiber optic industrial networks
- FDDI (legacy)
- Token Ring (legacy)
Modern variant: Dual ring for fault tolerance
7.9 Full Mesh Topology
Configuration: Every device directly connected to every other device
Putting Numbers to It
Let’s derive the connection formula for full mesh and understand why it scales poorly.
For \(n\) nodes, each node connects to \((n-1)\) others. Total directed links \(= n(n-1)\).
Undirected links (each link counted once): \[L = \frac{n(n-1)}{2}\]
Examples:
- \(n=5\): \(L = \frac{5 \times 4}{2} = 10\) connections
- \(n=10\): \(L = \frac{10 \times 9}{2} = 45\) connections
- \(n=25\): \(L = \frac{25 \times 24}{2} = 300\) connections
Cost scaling: If each radio costs \(\$15\), a 25-node full mesh requires \(300 \times \$15 = \$4{,}500\) in radios alone (plus configuration complexity). This is why full mesh is impractical above 30 nodes — connections grow as \(O(n^2)\) while benefits plateau. Partial mesh with 2-3 connections per node (\(L \approx 2.5n\)) provides similar fault tolerance at 10% of the cost.
Characteristics:
- Maximum redundancy
- No single point of failure
- High fault tolerance
- Multiple simultaneous connections
- Expensive (many connections)
- Complex configuration
- Number of connections = n(n-1)/2
IoT Use Cases:
- Critical infrastructure monitoring (backbone routers)
- Emergency communication systems
- Military and safety-critical sensor networks (<15 nodes)
Example: 5 devices = 10 connections, 10 devices = 45 connections!
7.10 Partial Mesh Topology
Configuration: Some devices fully connected, others not
Characteristics:
- Balance between cost and redundancy
- Critical paths have backup routes
- Less expensive than full mesh
- Not all devices have direct paths
IoT Use Cases:
- Zigbee and Thread networks (self-healing partial mesh)
- Multi-site WAN connections
- Smart city infrastructure
7.11 Topology Selection Decision Tree
7.12 Topology Scalability Comparison
7.13 Topology Comparison Summary
| Topology | Connections | Fault Tolerance | Complexity | Best For |
|---|---|---|---|---|
| Star | n-1 | Low (hub = SPOF) | Simple | Small networks, central control |
| Extended Star | n-1 (per level) | Medium (branch isolation) | Moderate | Multi-floor buildings |
| Bus | 1 segment | Very Low | Simple | Legacy systems, PCB buses |
| Ring | n | Low (single break fails) | Moderate | Token-based systems |
| Full Mesh | n(n-1)/2 | Very High | Complex | Critical systems (<30 nodes) |
| Partial Mesh | ~2-3n | High | Moderate | Balanced cost/reliability |
7.14 Hands-On: Mesh Routing Simulation
Understanding topology types is easier when you can simulate packet delivery through them. The Python code below creates a 10-node mesh network and compares three fundamental routing algorithms: flooding, distance-vector, and link-state. You can directly observe the convergence time and message overhead differences.
7.14.1 Flooding vs Distance-Vector vs Link-State in a 10-Node Mesh
Full Routing Simulation Code (click to expand)
# --- Mesh Routing Algorithm Comparison ---
# Demonstrates: flooding, distance-vector, link-state routing in a 10-node mesh
import heapq
from collections import defaultdict
class MeshNetwork:
"""A simple mesh network graph for routing simulation."""
def __init__(self):
# Adjacency list: {node: [(neighbor, cost), ...]}
self.links = defaultdict(list)
self.nodes = set()
def add_link(self, a, b, cost=1):
"""Add bidirectional link between two nodes."""
self.links[a].append((b, cost))
self.links[b].append((a, cost))
self.nodes.add(a)
self.nodes.add(b)
def neighbors(self, node):
return self.links[node]
def simulate_flooding(net, source, destination):
"""
Flooding: source broadcasts to ALL neighbors, each re-broadcasts.
Simple but generates massive traffic (broadcast storm problem).
"""
messages_sent = 0
visited = set()
queue = [(source, [source])]
all_paths = []
while queue:
current, path = queue.pop(0)
if current in visited:
continue
visited.add(current)
if current == destination:
all_paths.append(path)
continue # Don't stop -- flooding explores ALL paths
for neighbor, _ in net.neighbors(current):
messages_sent += 1 # Each forward is a message
if neighbor not in visited:
queue.append((neighbor, path + [neighbor]))
return {
"method": "Flooding",
"messages_sent": messages_sent,
"paths_found": len(all_paths),
"shortest_path": min(all_paths, key=len) if all_paths else None,
}
def simulate_distance_vector(net):
"""
Distance-Vector (Bellman-Ford): each node shares its routing table
with neighbors. Converges after diameter iterations.
"""
# Initialize: each node knows distance 0 to itself, infinity to others
tables = {n: {n: (0, n)} for n in net.nodes} # {dest: (cost, next_hop)}
messages_exchanged = 0
iterations = 0
converged = False
while not converged:
converged = True
iterations += 1
for node in net.nodes:
for neighbor, link_cost in net.neighbors(node):
messages_exchanged += 1 # Sharing routing table with neighbor
# Check if neighbor offers better paths
for dest, (dest_cost, _) in tables[neighbor].items():
new_cost = link_cost + dest_cost
current = tables[node].get(dest, (float('inf'), None))
if new_cost < current[0]:
tables[node][dest] = (new_cost, neighbor)
converged = False
return {
"method": "Distance-Vector",
"iterations_to_converge": iterations,
"messages_exchanged": messages_exchanged,
"routing_tables": tables,
}
def simulate_link_state(net, source, destination):
"""
Link-State (Dijkstra): each node floods its link info to ALL nodes,
then each node computes shortest path independently.
"""
# Phase 1: Link-State Advertisement (LSA) flooding
# Each node sends its neighbor list to all other nodes
lsa_messages = len(net.nodes) * (len(net.nodes) - 1) # Full flood
# Phase 2: Dijkstra's shortest path from source
dist = {n: float('inf') for n in net.nodes}
prev = {n: None for n in net.nodes}
dist[source] = 0
pq = [(0, source)]
while pq:
d, u = heapq.heappop(pq)
if d > dist[u]:
continue
for v, w in net.neighbors(u):
if dist[u] + w < dist[v]:
dist[v] = dist[u] + w
prev[v] = u
heapq.heappush(pq, (dist[v], v))
# Reconstruct path
path = []
current = destination
while current is not None:
path.append(current)
current = prev[current]
path.reverse()
return {
"method": "Link-State (Dijkstra)",
"lsa_messages": lsa_messages,
"path": path if path[0] == source else None,
"cost": dist[destination],
}
# --- Build a 10-node partial mesh (realistic IoT network) ---
net = MeshNetwork()
# Core mesh (high connectivity)
net.add_link("GW", "R1", cost=1) # Gateway to Router 1
net.add_link("GW", "R2", cost=2) # Gateway to Router 2
net.add_link("R1", "R2", cost=1) # Routers interconnected
net.add_link("R1", "S1", cost=3) # Router 1 to Sensor 1 (poor link)
net.add_link("R1", "S2", cost=1) # Router 1 to Sensor 2
net.add_link("R2", "S3", cost=1) # Router 2 to Sensor 3
net.add_link("R2", "S4", cost=2) # Router 2 to Sensor 4
net.add_link("S1", "S5", cost=1) # Sensor chain
net.add_link("S2", "S3", cost=2) # Cross-link
net.add_link("S3", "S6", cost=1) # Sensor chain
net.add_link("S4", "S6", cost=3) # Alternative path (lossy)
net.add_link("S5", "S7", cost=1) # Leaf sensors
net.add_link("S6", "S7", cost=2) # Cross-link at edge
print("=== Mesh Routing Algorithm Comparison ===")
print(f"Network: {len(net.nodes)} nodes, partial mesh topology")
print(f"Source: S7 (farthest leaf sensor)")
print(f"Destination: GW (gateway)\n")
# 1. Flooding
flood = simulate_flooding(net, "S7", "GW")
print(f"--- {flood['method']} ---")
print(f" Messages sent: {flood['messages_sent']}")
print(f" Paths found: {flood['paths_found']}")
print(f" Shortest path: {' -> '.join(flood['shortest_path'])}")
print(f" Problem: O(E) messages per packet -- broadcast storm!\n")
# 2. Distance-Vector
dv = simulate_distance_vector(net)
print(f"--- {dv['method']} ---")
print(f" Iterations to converge: {dv['iterations_to_converge']}")
print(f" Messages exchanged: {dv['messages_exchanged']}")
path_cost, next_hop = dv['routing_tables']['S7']['GW']
print(f" S7 -> GW: cost={path_cost}, next hop={next_hop}")
print(f" Advantage: distributed, no global knowledge needed")
print(f" Problem: slow convergence, count-to-infinity risk\n")
# 3. Link-State
ls = simulate_link_state(net, "S7", "GW")
print(f"--- {ls['method']} ---")
print(f" LSA flood messages: {ls['lsa_messages']}")
print(f" Optimal path: {' -> '.join(ls['path'])}")
print(f" Path cost: {ls['cost']}")
print(f" Advantage: finds globally optimal path")
print(f" Problem: O(N^2) LSA messages, memory for full topology\n")
# Summary comparison
print("=== Comparison Summary ===")
print(f"{'Metric':<25} {'Flooding':>12} {'Dist-Vector':>12} {'Link-State':>12}")
print("-" * 65)
print(f"{'Messages (setup)':<25} {'0':>12} {dv['messages_exchanged']:>12} {ls['lsa_messages']:>12}")
print(f"{'Messages (per packet)':<25} {flood['messages_sent']:>12} {'1':>12} {'1':>12}")
print(f"{'Convergence':<25} {'instant':>12} {str(dv['iterations_to_converge'])+' iters':>12} {'1 Dijkstra':>12}")
print(f"{'Optimal path?':<25} {'yes (finds)':>12} {'yes':>12} {'yes':>12}")
print(f"{'Memory per node':<25} {'O(1)':>12} {'O(N)':>12} {'O(N+E)':>12}")
print(f"{'Best for IoT':<25} {'discovery':>12} {'small mesh':>12} {'large net':>12}")What to observe: Flooding requires zero setup but sends messages to every link for every packet – unsustainable in a battery-powered mesh. Distance-vector converges in a few iterations with only neighbor-to-neighbor communication, making it suitable for small IoT meshes. Link-state finds the globally optimal path but requires every node to know the full topology, which is expensive for memory-constrained devices. This trade-off directly explains why IoT mesh protocols like Zigbee use simplified distance-vector, while enterprise SDN networks use link-state.
Worked Example: Designing Partial Mesh for 25-Node Industrial Sensor Network
A chemical plant needs to monitor 25 sensors across 4 process areas. Full mesh would require 25 × 24 / 2 = 300 connections (expensive). Star topology risks total failure if central hub fails (unacceptable for safety-critical plant). How to design cost-effective partial mesh?
Step 1: Identify critical vs non-critical nodes
- Critical (Tier 1): 5 safety sensors (pressure relief valves, toxic gas detectors) — must never lose connectivity
- Important (Tier 2): 10 process sensors (flow, temperature, level) — brief outages tolerable but reduce efficiency
- Monitoring (Tier 3): 10 environmental sensors (ambient temp, humidity) — data nice-to-have, outages acceptable
Step 2: Calculate connection requirements
- Full mesh for Tier 1 only: 5 × 4 / 2 = 10 connections among critical sensors
- Tier 2 connects to 2 Tier 1 nodes each: 10 × 2 = 20 connections (dual-parent for redundancy)
- Tier 3 connects to 1 Tier 2 node each: 10 × 1 = 10 connections (no redundancy needed)
- Total: 10 + 20 + 10 = 40 connections vs 300 for full mesh (87% reduction)
Step 3: Validate failure resilience
- Tier 1 node fails: Remaining 4 Tier 1 nodes still fully meshed → critical data continues flowing to gateway
- Tier 2 node fails: Its children (Tier 3) lose connection, but process data from other Tier 2 nodes maintains plant visibility
- Tier 3 node fails: Only that single environmental reading lost — no cascading impact
- Gateway failure: Tier 1 full mesh allows any Tier 1 node to become emergency coordinator until gateway replaced
Cost comparison:
- Full mesh (300 connections): 25 nodes × $50/node (mesh radio + routing CPU) = $1,250 hardware + complex configuration
- Partial mesh (40 connections): 5 nodes × $50 (Tier 1 mesh) + 20 nodes × $25 (dual-parent radios) = $250 + $500 = $750 total
- Savings: $500 (40% cost reduction) while maintaining safety-critical redundancy
The partial mesh design protects the 5 critical sensors with full mesh (no single point of failure), provides dual-path redundancy for important process sensors (survives 1 node failure per pair), and uses simple single-connection for non-critical environmental monitoring (minimal cost).
Decision Framework: Choosing Topology Based on Network Size and Criticality
Use this decision matrix to select the optimal topology for your deployment:
| Network Size | Criticality | Reliability Budget | Recommended Topology | Example Use Case |
|---|---|---|---|---|
| <20 nodes | Low | <$500 | Star (single hub) | Home automation, office sensors |
| <20 nodes | Medium | $500-2,000 | Star (dual hub failover) | Small building HVAC |
| <20 nodes | High | >$2,000 | Partial mesh (core nodes) | Hospital patient monitoring |
| 20-100 nodes | Low | <$2,000 | Extended star (2-3 layer) | Campus environmental monitoring |
| 20-100 nodes | Medium | $2,000-10,000 | Partial mesh (tiered) | Factory floor automation |
| 20-100 nodes | High | >$10,000 | Full mesh (critical) + star (non-critical) | Chemical plant safety systems |
| >100 nodes | Any | Any | Hierarchical hybrid (mesh core + star/tree branches) | Smart city infrastructure |
Topology selection decision flowchart:
1. Nodes < 20?
YES → Criticality High? → YES → Partial mesh
→ NO → Star (+ dual hub if medium criticality)
NO → Nodes < 100?
YES → All nodes critical? → YES → Full mesh (if budget allows) or tiered partial mesh
→ NO → Partial mesh core + star branches
NO → Always use hierarchical hybrid (mesh core, star/tree edge)Additional deployment considerations:
- Outdoor/harsh environment: Mesh topology helps because cable runs are expensive and failure-prone — wireless mesh self-heals around failed nodes
- Dense urban RF interference: Star with wired Ethernet backhaul avoids wireless reliability issues — use mesh only when wired infeasible
- Battery-powered sensors: Star topology saves power (sensors sleep, wake only to transmit to hub) vs mesh (must relay neighbors’ packets, 3-5× power drain)
- Frequent reconfiguration: Star allows adding/removing nodes without affecting others; mesh requires network reformation (10-30 min convergence)
Common Mistake: Choosing Ring Topology Because “It Distributes Load Better Than Star”
What they do wrong: An engineer designs an industrial control network with 15 PLCs using Token Ring topology because they believe “star topology overloads the central hub, but ring distributes traffic evenly across all nodes, improving throughput.” They install Token Ring switches (harder to find, more expensive than Ethernet), configure token passing with 5ms token rotation time, and expect better performance than a star topology with an Ethernet switch.
Why it fails — token passing serializes access, not parallelizes it:
Token Ring operation (15 devices):
- Only ONE device transmits at a time (token holder)
- Token rotates every 5ms × 15 devices = 75ms full rotation
- Each device gets 1/15th of bandwidth = 6.7% utilization per device
- If 5 devices need to transmit simultaneously, 4 must wait for token (0-75ms delay)
- Effective throughput: Limited by single token passing sequentially around ring
Ethernet Star operation (modern switch, full-duplex):
- Switch has dedicated 100 Mbps full-duplex per port
- All 15 devices can transmit simultaneously (no collisions in full-duplex)
- If 5 devices transmit at once, switch buffers and forwards in parallel
- Each device gets 100% of its link bandwidth
- Effective throughput: 15 × 100 Mbps = 1.5 Gbps aggregate (vs Ring’s ~100 Mbps shared)
Performance comparison with bursty IoT traffic (5 PLCs send 1 KB status every 100ms): - Ring: 5 PLCs wait for token, average delay = (75ms / 2) = 37.5ms, plus transmission time = ~45ms total latency - Star: Switch forwards immediately, latency = switching delay (~10 microseconds) + transmission time = ~0.1ms total latency - Star is 450× faster despite the engineer’s intuition that ring “distributes load”
Correct understanding: Token Ring made sense in the 1980s-1990s when Ethernet HUBS (not switches) created collision domains — multiple devices transmitting simultaneously caused collisions requiring retransmission. Token Ring guaranteed collision-free access by serializing transmission. However, modern Ethernet SWITCHES eliminate collisions entirely via full-duplex links and per-port buffering, making star topology strictly superior to ring for load distribution.
Real-world consequence: A factory automation system used Token Ring for 80 field controllers because “ring topology is more reliable than star” (based on 1990s knowledge). They paid $150/port for Token Ring switches vs $30/port for Ethernet. Performance issues emerged when adding real-time motion control (requires <10ms latency) — Token Ring’s 80 × 5ms = 400ms token rotation time was 40× too slow. They replaced the entire network with Ethernet star topology, cutting hardware cost by 80% and reducing latency by 99.97%. The Token Ring choice cost $9,600 excess hardware + $15,000 labor to rip-and-replace a network that was obsolete before installation.
Common Pitfalls
1. Treating Tree Topology as a Simple Extension of Star
Tree topology’s parent nodes are SPOFs for all their children. Deeper trees have more layers of SPOFs. Fix: map the failure impact of each level of the tree hierarchy before committing to the design.
2. Confusing Point-to-Multipoint With Multicast
Point-to-multipoint is a physical/MAC layer concept (one transmitter, multiple receivers on the same channel). Multicast is a network-layer concept (addressed to a group). Fix: distinguish the layer at which each concept operates.
3. Not Recognising That IoT Products Often Use Vendor-Specific Topology Extensions
A “Zigbee mesh” product may actually implement cluster-tree topology with limited mesh routing capability. Fix: read the product data sheet for the actual routing behaviour, not just the protocol’s theoretical topology.
7.15 Summary
- Star topology provides simple management with central hub but creates single point of failure
- Extended star scales star topology through hierarchical layers
- Bus topology uses minimal cabling but bus failure affects entire network
- Ring topology offers equal access but single device failure can break the ring
- Full mesh provides maximum redundancy but connection count grows quadratically
- Partial mesh balances redundancy and cost by protecting only critical paths
- Topology selection depends on device count, reliability needs, and budget
7.16 Knowledge Check
7.17 What’s Next
| If you want to… | Read this |
|---|---|
| Study the fundamental four topology types | Basic Types |
| Learn how topologies are selected for deployments | Topology Selection |
| Understand hybrid topology design | Hybrid Design |
| Analyse topology metrics and failure modes | Topology Analysis |
| See the module overview | Topologies Overview |