12  Network Design Fundamentals

12.1 Network Design Fundamentals

This section covers the foundational concepts of IoT network design, including topology selection and requirements analysis.

12.2 Learning Objectives

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

• Understand fundamental IoT network design principles and topologies

In 60 Seconds

IoT network design fundamentals cover the four primary topologies (star, mesh, tree, hybrid), their tradeoffs in scalability, reliability, and energy consumption, and the requirements analysis process that maps a deployment scenario to the right topology choice.

• Identify key network requirements and constraints for IoT applications
• Compare and contrast star, mesh, tree, and hybrid topologies
• Select appropriate network topologies based on application requirements
• Analyze trade-offs between latency, throughput, reliability, and energy consumption

12.3 Prerequisites

Before diving into this chapter, you should be familiar with:

• Networking Basics: Understanding network fundamentals including IP addressing, routing, protocols, and the OSI model is essential for designing IoT networks
• Wireless Communication Protocols: Knowledge of IoT communication protocols (Wi-Fi, Zigbee, LoRaWAN, BLE) provides context for selecting appropriate technologies
• IoT Reference Models: Understanding IoT architectures including edge, fog, and cloud layers helps design network topologies that match application deployment patterns

For Beginners: What is Network Design?

Think of network design like planning the roads for a city.

Before you build roads, you need to ask: How many cars will use them? Where are people going? Should we have one main highway or many small streets? Network design is the same—planning how devices will communicate before you build anything.

Why does network design matter for IoT?

Without Design	With Design
Devices can’t reach each other	Every device connected reliably
Messages get lost	99%+ delivery rate
Batteries die in weeks	Batteries last years
Adding devices breaks network	Network scales smoothly

Key decisions in network design:

Decision	Options	Impact
Topology	Star, Mesh, Tree, Hybrid	Coverage, reliability, complexity
Protocol	Wi-Fi, Zigbee, LoRa, BLE	Range, power, data rate
Gateway placement	Central, distributed	Coverage, latency
Redundancy	Single path, multiple paths	Reliability vs cost

Real-world analogy: Airport designers don’t just build runways randomly—they study traffic patterns, weather, and growth projections. IoT network designers do the same: study communication patterns, interference, and scalability before deploying thousands of devices.

Key takeaway: Good network design saves money, improves reliability, and enables future growth. Always design before you deploy!

For Kids: Meet the Sensor Squad!

Network Design is like planning a treasure hunt with your friends!

Imagine you’re organizing a treasure hunt in a huge park. You need to figure out: - How will everyone communicate? (Walkie-talkies? Flags? Runners?) - Where should the team captains stand? (Near the center? At different corners?) - What happens if someone gets lost? (Backup plan!)

That’s exactly what network designers do for IoT devices!

12.3.1 The Sensor Squad Adventure: Planning the Perfect Network

The Sensor Squad had an exciting mission: connect all the animal exhibits at the zoo! But where should they put the message towers (gateways)?

“Let’s put one big tower in the middle!” suggested Sammy the Sensor.

“But what if it breaks?” worried Bella the Battery. “Then NO messages get through!”

Max the Microcontroller had an idea: “What about three smaller towers that can help each other?”

They drew different plans on paper:

Plan A - Star (one center): Fast and simple, but risky if the center breaks.

Plan B - Mesh (everyone connected): Super reliable, but uses more battery.

Plan C - Tree (groups with leaders): Good for organizing, but leaders are extra important.

After testing with toy blocks, they chose Plan C for the zoo—with extra backup paths just in case!

12.3.2 Key Words for Kids

Word	What It Means
Topology	The shape or map of how things connect (like a family tree)
Star	Everything connects to one center (like spokes on a bicycle wheel)
Mesh	Everything connects to everything nearby (like a fishing net)
Gateway	A big helper that passes messages between areas
Redundancy	Having a backup plan (like bringing an extra snack!)

12.3.3 Try This at Home!

Play Network Designer!

1. Get 10 small objects (toys, blocks, or coins)
2. Pick one to be the “gateway” (make it bigger or different color)
3. Arrange in a STAR: all objects point to the center gateway
4. Now try MESH: connect each object to 2-3 neighbors
5. Ask yourself: What happens if you remove the gateway in each design?

You’re thinking like a real network engineer!

12.3.4 Network Simulation Tool Visualizations

The following visualizations provide insights into network design concepts for IoT systems.

Fog, Edge, and Cloud Network Architecture

Figure 12.1: Understanding the three-tier IoT network architecture is essential for network design. This visualization shows how edge devices connect to fog nodes for local processing before data reaches cloud services, with typical latency values (edge: 1-10ms, fog: 10-100ms, cloud: 100-500ms) annotated at each tier.

Interactive: Packet Analysis: Protocol Layers and Filtering

Interactive: Network Topology Comparison

colors = ({
  navy: "#2C3E50",
  teal: "#16A085",
  orange: "#E67E22",
  blue: "#3498DB",
  gray: "#7F8C8D",
  purple: "#9B59B6",
  red: "#E74C3C"
})

// Topology data with trade-offs
topologyData = [
  {
    name: "Star",
    latency: 10,
    reliability: 40,
    power: 90,
    cost: 30,
    scalability: 40,
    complexity: 20,
    color: colors.teal
  },
  {
    name: "Mesh",
    latency: 50,
    reliability: 95,
    power: 40,
    cost: 70,
    scalability: 80,
    complexity: 85,
    color: colors.orange
  },
  {
    name: "Tree",
    latency: 30,
    reliability: 60,
    power: 70,
    cost: 40,
    scalability: 75,
    complexity: 50,
    color: colors.blue
  },
  {
    name: "Hybrid",
    latency: 40,
    reliability: 85,
    power: 60,
    cost: 80,
    scalability: 90,
    complexity: 90,
    color: colors.purple
  }
]

// Radar chart dimensions
viewof selectedTopology = Inputs.select(
  topologyData.map(d => d.name),
  {
    value: "Star",
    label: "Select Topology to Highlight"
  }
)

// Create radar chart
{
  const width = 600;
  const height = 500;
  const margin = 80;
  const radius = Math.min(width, height) / 2 - margin;

  const metrics = ["Latency", "Reliability", "Power Efficiency", "Cost", "Scalability", "Complexity"];
  const levels = 5;

  const svg = d3.create("svg")
    .attr("width", width)
    .attr("height", height)
    .attr("viewBox", [0, 0, width, height])
    .attr("style", "max-width: 100%; height: auto;");

  const g = svg.append("g")
    .attr("transform", `translate(${width/2}, ${height/2})`);

  // Draw circular grid
  for (let i = 1; i <= levels; i++) {
    const levelRadius = radius * i / levels;
    g.append("circle")
      .attr("r", levelRadius)
      .attr("fill", "none")
      .attr("stroke", colors.gray)
      .attr("stroke-opacity", 0.3);

    // Add level labels
    g.append("text")
      .attr("x", 5)
      .attr("y", -levelRadius)
      .attr("font-size", "10px")
      .attr("fill", colors.gray)
      .text((i * 20) + "%");
  }

  // Draw axis lines and labels
  const angleSlice = Math.PI * 2 / metrics.length;
  metrics.forEach((metric, i) => {
    const angle = angleSlice * i - Math.PI / 2;
    const x = radius * Math.cos(angle);
    const y = radius * Math.sin(angle);

    // Axis line
    g.append("line")
      .attr("x1", 0)
      .attr("y1", 0)
      .attr("x2", x)
      .attr("y2", y)
      .attr("stroke", colors.gray)
      .attr("stroke-opacity", 0.3);

    // Axis label
    const labelX = (radius + 30) * Math.cos(angle);
    const labelY = (radius + 30) * Math.sin(angle);
    g.append("text")
      .attr("x", labelX)
      .attr("y", labelY)
      .attr("text-anchor", "middle")
      .attr("font-size", "12px")
      .attr("font-weight", "600")
      .attr("fill", colors.navy)
      .text(metric);
  });

  // Draw topology polygons
  topologyData.forEach(topology => {
    const values = [
      topology.latency,
      topology.reliability,
      topology.power,
      100 - topology.cost, // Invert cost (lower is better)
      topology.scalability,
      100 - topology.complexity // Invert complexity (lower is better)
    ];

    const points = values.map((value, i) => {
      const angle = angleSlice * i - Math.PI / 2;
      const r = radius * value / 100;
      return [r * Math.cos(angle), r * Math.sin(angle)];
    });

    const isSelected = topology.name === selectedTopology;

    // Draw filled polygon
    g.append("polygon")
      .attr("points", points.map(p => p.join(",")).join(" "))
      .attr("fill", topology.color)
      .attr("fill-opacity", isSelected ? 0.3 : 0.1)
      .attr("stroke", topology.color)
      .attr("stroke-width", isSelected ? 3 : 1.5)
      .attr("stroke-opacity", isSelected ? 1 : 0.5);

    // Draw data points
    if (isSelected) {
      points.forEach((point, i) => {
        g.append("circle")
          .attr("cx", point[0])
          .attr("cy", point[1])
          .attr("r", 4)
          .attr("fill", topology.color)
          .attr("stroke", "white")
          .attr("stroke-width", 2);
      });
    }
  });

  // Add legend
  const legend = svg.append("g")
    .attr("transform", `translate(20, 20)`);

  topologyData.forEach((topology, i) => {
    const legendRow = legend.append("g")
      .attr("transform", `translate(0, ${i * 20})`);

    legendRow.append("rect")
      .attr("width", 15)
      .attr("height", 15)
      .attr("fill", topology.color)
      .attr("opacity", topology.name === selectedTopology ? 1 : 0.5);

    legendRow.append("text")
      .attr("x", 20)
      .attr("y", 12)
      .attr("font-size", "12px")
      .attr("font-weight", topology.name === selectedTopology ? "700" : "400")
      .attr("fill", colors.navy)
      .text(topology.name);
  });

  return svg.node();
}

md`**How to use this visualization:**

Select a topology from the dropdown to highlight it. The radar chart shows six key metrics:

- **Latency**: How quickly messages are delivered (higher = better)
- **Reliability**: Ability to handle failures (higher = better)
- **Power Efficiency**: Battery life for wireless nodes (higher = better)
- **Cost**: Inverted scale - higher means lower cost (higher = better)
- **Scalability**: Ability to grow the network (higher = better)
- **Complexity**: Inverted scale - higher means simpler to manage (higher = better)

**Key Insights:**

- Star excels at low latency and power efficiency but lacks reliability
- Mesh provides best reliability and scalability but at higher complexity
- Tree offers balanced approach for hierarchical deployments
- Hybrid maximizes scalability but requires most expertise to deploy`

12.4 Introduction

Network design is a critical phase in IoT system development that enables architects to plan network topology, select appropriate protocols, and optimize configurations before physical deployment. Unlike traditional IT networks, IoT networks present unique challenges including massive scale (thousands to millions of devices), resource constraints (limited power and bandwidth), diverse communication patterns, and stringent reliability requirements.

Definition

IoT Network Design is the systematic process of planning network topology, protocol selection, gateway placement, and addressing schemes to meet application requirements for performance, reliability, and cost. Good design prevents costly rework and enables successful large-scale deployments.

12.4.1 Why Network Design Matters for IoT

Cost Reduction: Proper planning prevents deploying too many gateways or choosing protocols that don’t scale. Design decisions made early can save thousands of dollars.

Risk Mitigation: Identifying coverage gaps, single points of failure, and capacity bottlenecks during design phase prevents production issues.

Performance Optimization: Topology selection and gateway placement directly impact latency, throughput, and battery life. Design enables optimization before deployment.

Scalability Planning: Networks that work with 100 devices may fail at 1,000. Design validates that architecture can handle projected growth.

Reliability Engineering: Mesh topologies, redundant gateways, and failover mechanisms must be planned during design, not retrofitted after deployment.

12.5 Network Topology Patterns

Time: ~25 min | Difficulty: Intermediate | Unit: P13.C05.U02

12.5.1 Overview

IoT networks employ various topologies based on application requirements, scale, and communication patterns. The following diagram compares the four primary IoT network topologies:

Figure 12.2: Comparison diagram of four IoT network topologies: Star topology shows central hub with 4 sensor nodes connected directly, offering simple design and low latency but creating single point of failure.

Alternative View: Topology Selection Decision Tree

Figure 12.3: Alternative view: Decision tree for selecting IoT network topology based on requirements. Start with network scale (small/medium/large), then consider fault tolerance and range requirements. Star topology (teal) suits simple deployments under 50 devices. Mesh (orange) provides self-healing for medium-scale networks. Tree is ideal for hierarchical data aggregation. Hybrid combines approaches for large-scale deployments. Each topology maps to recommended protocols.

12.5.1.1 Star Topology

Description: All devices connect to a central hub or gateway. Most common for short-range protocols like Wi-Fi, Bluetooth, and Zigbee.

Advantages:

• Simple to design and implement
• Easy troubleshooting and device management
• Hub provides centralized security and control
• Low device complexity (nodes only talk to hub)

Disadvantages:

• Single point of failure at hub
• Limited range (all devices must reach hub)
• Hub becomes bottleneck as network scales
• No device-to-device communication

IoT Applications:

• Smart home systems (devices to hub to cloud)
• Bluetooth Low Energy sensor networks
• Wi-Fi-connected IoT devices

Design Considerations:

• Hub capacity (maximum concurrent connections)
• Radio coverage area (ensure all devices within range)
• Hub redundancy for critical applications
• Bandwidth allocation per device

12.5.1.2 Mesh Topology

Description: Devices form peer-to-peer connections, enabling multi-hop routing where messages can relay through intermediate nodes.

Advantages:

• Self-healing (automatic rerouting around failures)
• Extended range through multi-hop
• No single point of failure
• Scalable to large areas

Disadvantages:

• Complex routing protocols
• Higher latency (multi-hop delays)
• Increased power consumption (routing duties)
• Network instability if nodes frequently join/leave

IoT Applications:

• Zigbee and Thread networks
• Smart city street lighting
• Industrial sensor networks
• Agricultural monitoring across large fields

Design Considerations:

• Maximum hop count limits
• Routing protocol selection (AODV, RPL, etc.)
• Network density (enough nodes for connectivity)
• Power budget for routing overhead

12.5.1.3 Tree/Hierarchical Topology

Description: Organized in parent-child relationships, forming a hierarchical structure often used in industrial and building automation.

Advantages:

• Scalable organization
• Clear data aggregation paths
• Efficient for many-to-one traffic patterns
• Simplified addressing schemes

Disadvantages:

• Parent node failure affects all children
• No path diversity (no alternate routes)
• Unbalanced trees create hotspots
• Limited flexibility

IoT Applications:

• Building automation systems (floors to wings to building to campus)
• Industrial control hierarchies
• Wireless sensor network clusters

Design Considerations:

• Tree depth (impacts latency)
• Balancing branches (avoid hotspots)
• Parent node reliability requirements
• Aggregation strategies

12.5.1.4 Hybrid Topologies

Description: Combination of topologies to leverage strengths of each. For example, mesh clusters connected via backbone, or star networks linked through gateways.

Advantages:

• Optimized for specific requirements
• Flexibility in design
• Can combine best features of multiple topologies

Disadvantages:

• Increased design complexity
• More complex management
• Potential interoperability challenges

IoT Applications:

• Smart city infrastructure (mesh zones + backbone)
• Campus IoT deployments
• Multi-protocol IoT systems

12.5.2 Network Design Requirements

12.5.2.1 Scale and Density

Device Count: How many devices must the network support simultaneously?

• Small: <100 devices (home/office)
• Medium: 100-10,000 devices (building/campus)
• Large: 10,000-1M+ devices (city/industrial)

Spatial Density: How many devices per unit area?

• Sparse: <1 device/100m² (agriculture)
• Medium: 1-10 devices/100m² (office)
• Dense: >10 devices/100m² (factory, stadium)

Design Impact: Dense networks require modeling collision avoidance, channel contention, and interference. Sparse networks focus on coverage and routing efficiency.

12.5.2.2 Latency Requirements

Real-Time (< 10ms): Industrial control, robotics, autonomous vehicles requiring immediate response.

Near Real-Time (10-100ms): Interactive applications like smart home controls, gaming, AR/VR.

Soft Real-Time (100ms-1s): Environmental monitoring, health tracking with timely but not critical updates.

Batch/Delay-Tolerant (>1s): Data logging, firmware updates, analytics where delay is acceptable.

Design Impact: Latency requirements affect topology choice (star for low latency vs mesh for reliability), routing protocol selection, and edge processing decisions.

12.5.2.3 Bandwidth and Throughput

Data Rate Per Device:

• Ultra-low: <1 kbps (temperature sensor reporting hourly)
• Low: 1-100 kbps (sensor streams)
• Medium: 100 kbps-1 Mbps (video doorbell, audio)
• High: >1 Mbps (HD camera, bulk transfers)

Aggregate Network Throughput: Total bandwidth = devices x per-device rate x duty cycle

Example: 1,000 sensors x 10 kbps x 10% duty = 1 Mbps aggregate

Design Impact: Model channel capacity, collision probability, retransmission overhead, and bandwidth allocation strategies.

Putting Numbers to It

To determine if a mesh network can support the aggregate load, compare throughput to channel capacity using Shannon-Hartley theorem.

\[ C = B \log_2\left(1 + \frac{S}{N}\right) \]

Worked example: Zigbee uses 2.4 GHz with bandwidth \(B = 2\) MHz and typical SNR = 10 dB (ratio 10). Channel capacity = \(2 \times 10^6 \times \log_2(1 + 10) = 2 \times 10^6 \times 3.459 = 6.92\) Mbps theoretical. With protocol overhead reducing efficiency to 40%, effective throughput ≈ 2.77 Mbps. For 200 sensors at 10 kbps with 5% duty cycle: aggregate = \(200 \times 10 \times 0.05 = 100\) kbps, leaving 96% headroom—design is viable.

Interactive: Shannon-Hartley Channel Capacity Calculator

viewof bandwidth = Inputs.range([0.1, 10], {
  value: 2,
  step: 0.1,
  label: "Bandwidth (MHz)"
})

viewof snr_db = Inputs.range([0, 30], {
  value: 10,
  step: 1,
  label: "Signal-to-Noise Ratio (dB)"
})

viewof efficiency = Inputs.range([0.1, 1], {
  value: 0.4,
  step: 0.05,
  label: "Protocol Efficiency"
})

viewof numDevices = Inputs.range([10, 1000], {
  value: 200,
  step: 10,
  label: "Number of Devices"
})

viewof dataRate = Inputs.range([1, 100], {
  value: 10,
  step: 1,
  label: "Data Rate per Device (kbps)"
})

viewof dutyCycle = Inputs.range([0.01, 1], {
  value: 0.05,
  step: 0.01,
  label: "Duty Cycle"
})

// Calculate capacity
snr_ratio = Math.pow(10, snr_db / 10)
theoretical_capacity = bandwidth * Math.log2(1 + snr_ratio)
effective_capacity = theoretical_capacity * efficiency
aggregate_load = numDevices * dataRate * dutyCycle / 1000 // Convert to Mbps
headroom = ((effective_capacity - aggregate_load) / effective_capacity * 100).toFixed(1)
isViable = aggregate_load < effective_capacity

// Create visualization
{
  const width = 700;
  const height = 400;
  const margin = {top: 40, right: 150, bottom: 60, left: 80};

  const svg = d3.create("svg")
    .attr("width", width)
    .attr("height", height)
    .attr("viewBox", [0, 0, width, height])
    .attr("style", "max-width: 100%; height: auto;");

  const chartWidth = width - margin.left - margin.right;
  const chartHeight = height - margin.top - margin.bottom;

  const g = svg.append("g")
    .attr("transform", `translate(${margin.left}, ${margin.top})`);

  // Draw bars
  const barWidth = 60;
  const spacing = 100;

  // Theoretical capacity bar
  const maxCapacity = Math.max(theoretical_capacity, effective_capacity, aggregate_load) * 1.2;
  const yScale = d3.scaleLinear()
    .domain([0, maxCapacity])
    .range([chartHeight, 0]);

  g.append("rect")
    .attr("x", 0)
    .attr("y", yScale(theoretical_capacity))
    .attr("width", barWidth)
    .attr("height", chartHeight - yScale(theoretical_capacity))
    .attr("fill", colors.blue)
    .attr("opacity", 0.7);

  g.append("text")
    .attr("x", barWidth / 2)
    .attr("y", yScale(theoretical_capacity) - 10)
    .attr("text-anchor", "middle")
    .attr("font-size", "14px")
    .attr("font-weight", "600")
    .attr("fill", colors.navy)
    .text(theoretical_capacity.toFixed(2) + " Mbps");

  g.append("text")
    .attr("x", barWidth / 2)
    .attr("y", chartHeight + 25)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("fill", colors.navy)
    .text("Theoretical");

  g.append("text")
    .attr("x", barWidth / 2)
    .attr("y", chartHeight + 40)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("fill", colors.navy)
    .text("Capacity");

  // Effective capacity bar
  g.append("rect")
    .attr("x", spacing)
    .attr("y", yScale(effective_capacity))
    .attr("width", barWidth)
    .attr("height", chartHeight - yScale(effective_capacity))
    .attr("fill", colors.teal)
    .attr("opacity", 0.7);

  g.append("text")
    .attr("x", spacing + barWidth / 2)
    .attr("y", yScale(effective_capacity) - 10)
    .attr("text-anchor", "middle")
    .attr("font-size", "14px")
    .attr("font-weight", "600")
    .attr("fill", colors.navy)
    .text(effective_capacity.toFixed(2) + " Mbps");

  g.append("text")
    .attr("x", spacing + barWidth / 2)
    .attr("y", chartHeight + 25)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("fill", colors.navy)
    .text("Effective");

  g.append("text")
    .attr("x", spacing + barWidth / 2)
    .attr("y", chartHeight + 40)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("fill", colors.navy)
    .text("Capacity");

  // Aggregate load bar
  const loadColor = isViable ? colors.orange : colors.red;
  g.append("rect")
    .attr("x", spacing * 2)
    .attr("y", yScale(aggregate_load))
    .attr("width", barWidth)
    .attr("height", chartHeight - yScale(aggregate_load))
    .attr("fill", loadColor)
    .attr("opacity", 0.7);

  g.append("text")
    .attr("x", spacing * 2 + barWidth / 2)
    .attr("y", yScale(aggregate_load) - 10)
    .attr("text-anchor", "middle")
    .attr("font-size", "14px")
    .attr("font-weight", "600")
    .attr("fill", colors.navy)
    .text(aggregate_load.toFixed(2) + " Mbps");

  g.append("text")
    .attr("x", spacing * 2 + barWidth / 2)
    .attr("y", chartHeight + 25)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("fill", colors.navy)
    .text("Aggregate");

  g.append("text")
    .attr("x", spacing * 2 + barWidth / 2)
    .attr("y", chartHeight + 40)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("fill", colors.navy)
    .text("Load");

  // Y-axis
  const yAxis = d3.axisLeft(yScale).ticks(5);
  g.append("g")
    .call(yAxis)
    .style("font-size", "12px");

  g.append("text")
    .attr("transform", "rotate(-90)")
    .attr("x", -chartHeight / 2)
    .attr("y", -50)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("font-weight", "600")
    .attr("fill", colors.navy)
    .text("Throughput (Mbps)");

  // Status indicator
  const statusBox = svg.append("g")
    .attr("transform", `translate(${spacing * 2 + barWidth + 20}, ${margin.top})`);

  statusBox.append("rect")
    .attr("width", 140)
    .attr("height", 100)
    .attr("fill", isViable ? colors.teal : colors.red)
    .attr("opacity", 0.1)
    .attr("rx", 5);

  statusBox.append("text")
    .attr("x", 70)
    .attr("y", 25)
    .attr("text-anchor", "middle")
    .attr("font-size", "14px")
    .attr("font-weight", "700")
    .attr("fill", isViable ? colors.teal : colors.red)
    .text(isViable ? "VIABLE ✓" : "OVERLOADED ✗");

  statusBox.append("text")
    .attr("x", 70)
    .attr("y", 50)
    .attr("text-anchor", "middle")
    .attr("font-size", "12px")
    .attr("fill", colors.navy)
    .text("Headroom:");

  statusBox.append("text")
    .attr("x", 70)
    .attr("y", 70)
    .attr("text-anchor", "middle")
    .attr("font-size", "18px")
    .attr("font-weight", "700")
    .attr("fill", isViable ? colors.teal : colors.red)
    .text(headroom + "%");

  return svg.node();
}

md`**Shannon-Hartley Formula:**

$$C = B \\log_2\\left(1 + \\frac{S}{N}\\right)$$

**Current Calculation:**

- **Bandwidth**: ${bandwidth} MHz
- **SNR**: ${snr_db} dB (ratio: ${snr_ratio.toFixed(2)})
- **Theoretical Capacity**: ${theoretical_capacity.toFixed(2)} Mbps
- **Protocol Efficiency**: ${(efficiency * 100).toFixed(0)}%
- **Effective Capacity**: ${effective_capacity.toFixed(2)} Mbps
- **Aggregate Load**: ${numDevices} devices × ${dataRate} kbps × ${(dutyCycle * 100).toFixed(0)}% = ${aggregate_load.toFixed(2)} Mbps
- **Headroom**: ${headroom}% ${isViable ? "(Network is viable)" : "(Network is overloaded!)"}

**Try adjusting the parameters** to see how bandwidth, SNR, efficiency, device count, data rate, and duty cycle affect network capacity.`

12.5.2.4 Reliability and Availability

Packet Delivery Ratio (PDR):

• Critical: >99.99% (medical, safety systems)
• High: 95-99.99% (industrial monitoring)
• Medium: 90-95% (smart home)
• Low: <90% (delay-tolerant sensor networks)

Mean Time Between Failures (MTBF): Network uptime requirements drive redundancy needs.

Design Impact: Model packet loss, retransmission mechanisms, error correction, and redundancy strategies.

12.5.2.5 Energy Constraints

Battery-Powered Devices: Lifetime requirements (months to years) dictate duty cycling, transmission power, and protocol efficiency.

Energy Harvesting: Variable power availability requires buffering and adaptive protocols.

Mains-Powered: No energy constraint but may still optimize to reduce infrastructure load.

Design Impact: Model transmission energy costs, sleep/wake cycles, and battery lifetime under various traffic patterns.

12.6 Key Concepts

Network Topologies:

• Star: Central hub with spoked connectivity
• Mesh: Full or partial interconnection
• Tree: Hierarchical multi-hop structure
• Hybrid: Combination approaches (mesh + tree)

Design Requirements:

• Scale: Device count and spatial density
• Latency: Real-time to delay-tolerant
• Bandwidth: Data rate per device and aggregate
• Reliability: PDR and availability targets
• Energy: Battery constraints and lifetime goals

Design Factors:

• Radio characteristics: Range, power, data rate
• Coverage: Ensure all devices reachable
• Redundancy: Failover for critical applications
• Scalability: Performance as network grows

12.7 Worked Example: Designing a Smart Building Network

Scenario: A 10-story commercial building (5,000 m² per floor) requires IoT monitoring for HVAC, occupancy, lighting, and energy metering. The building has 200 offices, 10 conference rooms, 2 server rooms, and underground parking.

Step 1: Requirements Analysis

Subsystem	Devices	Data Rate	Latency	Power Source	Reliability
HVAC temp/humidity	250	20 bytes / 5 min	Soft RT	Battery (5 yr)	95%
Occupancy (PIR)	210	10 bytes / event	Near RT	Battery (3 yr)	90%
Smart lighting	400	50 bytes / 1 min	Near RT	Mains	99%
Energy meters	50	200 bytes / 15 sec	Soft RT	Mains	99.9%
Parking sensors	120	10 bytes / event	Delay OK	Battery (5 yr)	90%
Server room env	20	100 bytes / 10 sec	Real-time	Mains	99.99%
Total	1,050

Step 2: Traffic Modeling

HVAC aggregate:       250 × 20 bytes / 300s = 16.7 bytes/s = 0.13 kbps
Occupancy aggregate:  210 × 10 bytes × 5 events/hr / 3600 = 2.9 bytes/s
Lighting aggregate:   400 × 50 bytes / 60s = 333 bytes/s = 2.7 kbps
Energy meters:        50 × 200 bytes / 15s = 667 bytes/s = 5.3 kbps
Parking aggregate:    120 × 10 bytes × 3 events/hr / 3600 = 1.0 byte/s
Server room:          20 × 100 bytes / 10s = 200 bytes/s = 1.6 kbps

Total aggregate: ~10 kbps sustained (well within any gateway capacity)
Peak (all lighting + meters simultaneously): ~25 kbps

Step 3: Topology and Protocol Selection

Subsystem	Topology	Protocol	Rationale
HVAC + Occupancy + Parking	Star-of-stars	BLE Mesh → Gateways	Battery-powered, low data rate, need 5-year life
Smart lighting	Mesh	Zigbee 3.0	Mains-powered nodes can relay, self-healing critical for lighting
Energy meters	Star	Modbus TCP/IP over Ethernet	High reliability needed, mains-powered, short cable runs per floor
Server room	Star	Wi-Fi → dedicated VLAN	High data rate, low latency, existing infrastructure

Step 4: Gateway Placement and Cost

BLE gateways:       1 per floor × 10 floors = 10 gateways @ $80 each = $800
Zigbee coordinators: 1 per 2 floors × 5 = 5 coordinators @ $60 each = $300
Ethernet switches:  1 per floor (existing), 1 new for parking = $200
Wi-Fi APs:          Existing building Wi-Fi, 1 dedicated for server = $150

Gateway subtotal: $1,450
Sensor hardware:    ~$45,000 (1,050 sensors at avg $43 each)
Installation:       ~$12,000 (2 technicians × 15 days × $400/day)
Cloud platform:     ~$3,600/year (1,050 devices × $0.29/device/month)

Year 1 total: ~$62,050
Annual recurring: ~$5,000 (cloud + battery replacements)

Step 5: Redundancy and Failure Analysis

Single Point of Failure	Impact	Mitigation	Cost
BLE gateway down	1 floor loses HVAC data	Dual gateways per floor on critical floors	+$400
Zigbee coordinator down	2 floors lose lighting control	Manual override + failover coordinator	+$300
Internet connection down	Cloud reporting stops	Edge gateway buffers 7 days locally	Included
Power outage	All mains sensors down	UPS on gateways + battery sensors unaffected	+$2,000

Design Decision: For a $62K investment covering 1,050 sensors, the building gains 15-20% energy savings ($30K-50K/year in a 50,000 m² building), achieving ROI in 12-18 months.

12.8 Topology Selection Quick Reference

Use this decision matrix when choosing between topologies for a new IoT deployment:

Factor	Star	Mesh	Tree	Hybrid
Best device count	<50	50-500	100-10,000	1,000+
Best for	Home, small office	Factory floor	Multi-floor building	Campus, city
Latency	Low (1 hop)	High (multi-hop)	Medium	Varies
Power efficiency	High (sleep friendly)	Low (routing duty)	Medium	Medium
Fault tolerance	Poor (hub = SPOF)	Excellent	Moderate	Good
Setup complexity	Simple	Complex	Moderate	Complex
Cost per device	Low	Medium	Low	Medium
Recommended protocol	BLE, Wi-Fi	Zigbee, Thread	LoRaWAN, RPL	Mix
Self-healing	No	Yes	No	Partial

Decision rule of thumb: If you need reliability above all else, choose mesh. If you need simplicity and low latency, choose star. If you have a clear hierarchy (floors, zones, regions), choose tree. If requirements differ across subsystems, choose hybrid with segmented networks.

Try It Yourself: Design a Network for a Multi-Tenant Office Building

Scenario: A 5-story office building has 3 different tenants on different floors. Each tenant wants independent IoT systems for their space: - Floors 1-2: Law firm needs 40 sensors (temperature, occupancy) with 99% reliability for HVAC optimization - Floor 3: Creative agency needs 15 sensors (ambient light, noise) with flexible placement and low cost - Floors 4-5: Medical clinic needs 30 sensors (air quality, occupancy) with <100ms latency for real-time alerts + HIPAA security

Your Design Task (30 minutes):

1. Topology Selection: For EACH tenant, choose topology (star/mesh/tree/hybrid) with written justification referencing the chapter’s topology comparison table

2. Network Segmentation: Should all three use the same physical network or separate networks? Consider security (HIPAA), reliability needs, and cost

3. Gateway Placement: How many gateways total? Where located? (Draw simple floor plan)

4. Protocol Selection: For each tenant, recommend Wi-Fi, Zigbee, or BLE based on their requirements

Success Criteria:

• Law firm solution achieves 99%+ reliability (hint: requires redundancy)
• Medical clinic solution meets <100ms latency (hint: star topology needed)
• Creative agency solution minimizes cost (hint: shared infrastructure if possible)
• HIPAA security achieved through network segmentation

Deliverable: One-page design document with: (1) Topology choice per tenant, (2) Gateway count and placement sketch, (3) Protocol selection with reasoning, (4) Total cost estimate

Concept Check: Network Topology Selection

Match the Design Decision to Its Impact

Order the Network Design Decision Process

Label the Diagram

💻 Code Challenge

12.9 Summary

• Network Topology Selection: Choose star topology for simplicity and low latency (under 50 devices), mesh for self-healing and extended range, tree for hierarchical aggregation, or hybrid for large-scale deployments requiring flexibility
• Requirements Analysis: Systematically define device count, spatial density, latency requirements, bandwidth needs, reliability targets, and energy constraints before selecting topology and protocols
• Trade-off Understanding: Network design involves balancing competing requirements where improving one metric (like reliability through mesh) may impact another (like latency or power consumption)
• Scalability Planning: Design networks with headroom for growth (2-3x initial capacity) to avoid costly redesigns as deployments expand

Concept Relationships: Network Fundamentals in IoT System Design

Depends On:

• Networking Basics: IP addressing, OSI model, routing concepts prerequisite
• Wireless Protocols: Protocol characteristics (range, power, data rate) inform topology selection
• System Architecture: Edge/fog/cloud tiers map to network topology layers

Feeds Into:

• Network Simulation Tools: Topology designs are validated through simulation
• Network Design Methodology: Requirements analysis guides systematic design process
• Gateway Design: Topology determines gateway count and placement

Related Concepts:

• Scaling Patterns: Star scales to ~100 devices, mesh to ~500, tree/hybrid to 10,000+
• Fault Tolerance: Mesh > Tree > Star for resilience; inversely proportional to simplicity
• Energy Efficiency: Star best for battery (minimal routing), mesh worst (relay duty)
• Latency Profiles: Star lowest (1-hop), Mesh highest (multi-hop), Tree medium (depth-dependent)

Cross-Module Integration:

• Security: Topology affects attack surface—mesh has more attack paths than star
• Data Flow: Topology determines aggregation points and bandwidth bottlenecks
• Deployment: Physical layout (building, campus, city) suggests natural topology fit

Related Chapters & Resources

Continue Learning:

• Network Simulation Tools - Simulation tools for validating designs
• Network Design Methodology - Systematic design process
• Network Design Exercises - Hands-on practice

Network Fundamentals:

• Networking Fundamentals - Network basics
• Topologies - Network topologies
• Routing - Routing protocols

12.10 Knowledge Check

Quiz: Network Design Fundamentals

Common Pitfalls

1. Choosing Topology Based on Familiarity Rather Than Requirements

Engineers often default to the topology they know best (e.g., star with Wi-Fi) rather than the one that best matches requirements. A dense indoor asset-tracking application may need mesh to avoid coverage gaps that star leaves behind walls. Always start from requirements, not technology preferences.

2. Underestimating the Energy Cost of Mesh Routing

Mesh topologies require nodes to forward packets for neighbors, which keeps radios active longer and drains batteries faster than star nodes that only send their own data. Account for routing overhead in your energy budget when choosing mesh over star.

3. Ignoring Time Synchronization Requirements

Some IoT applications (industrial TDMA, synchronized sampling, event correlation) require tight time synchronization across all nodes. Mesh topologies with multi-hop paths accumulate synchronization error at each hop. Verify that your chosen topology and protocol can meet your timing requirements.

4. Designing for Current Scale, Not Future Growth

An IoT network designed for exactly 50 nodes with no headroom will struggle when the 51st node is added. Design for 2–3× the initial node count, and verify that your chosen topology, protocol, and gateway hardware can handle that scale before deployment.

12.11 What’s Next

The next section covers Network Simulation Tools, which examines the software tools available for validating your network designs before deployment. You’ll learn about NS-3, Cooja, OMNeT++, and other simulators to test your topology and protocol choices.

Previous	Current	Next
Network Design and Simulation	Network Design Fundamentals	Network Simulation Tools