777  Network Topologies: Communication Patterns

777.1 Learning Objectives

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

  • Distinguish Communication Typologies: Understand unicast, broadcast, multicast, and many-to-one patterns
  • Apply Addressing Schemes: Use appropriate IP addressing for each communication pattern
  • Optimize Bandwidth Usage: Select efficient patterns for IoT data flows
  • Design Data Collection: Implement many-to-one patterns for sensor networks
  • Map Protocols to Patterns: Match IoT protocols to their dominant communication typologies

Deep Dives: - Network Topologies Overview - Chapter index and navigation - Basic Topology Types - Fundamental topology concepts - Topology Analysis - Graph theory and failure analysis - Hybrid Design - Real-world hybrid topologies

Protocol Details: - MQTT Architecture - Pub/sub communication patterns - CoAP Fundamentals - Observe pattern (1-to-N notifications) - RPL Routing - DODAG routing for N-to-1 traffic patterns

777.2 Prerequisites

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

777.3 Introduction: Data Flow Patterns

Beyond physical and logical topologies, understanding communication typologies (data flow patterns) is essential for IoT system design. These patterns describe how many senders communicate with how many receivers.

Analogy: Think of these patterns like different types of conversations:

  • 1-to-1 (Unicast): A phone call between two people - only you and your friend are talking
  • 1-to-N (Broadcast/Multicast): A radio station - one DJ speaks, millions listen
  • N-to-1 (Many-to-One): Customer service hotline - many callers, one call center
  • N-to-N (Many-to-Many): Group video chat - everyone can talk to everyone

In IoT, sensor networks typically use N-to-1 (many sensors report to one gateway), while firmware updates use 1-to-N (one server broadcasts to many devices).

777.4 The Three Fundamental Communication Patterns

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'background': '#ffffff', 'mainBkg': '#2C3E50', 'secondBkg': '#16A085', 'tertiaryBkg': '#E67E22'}}}%%
graph TB
    subgraph Unicast["1-to-1: Unicast (Telephony Model)"]
        U_Alice["Alice<br/>Sender"] -->|"Direct<br/>Point-to-Point"| U_Bob["Bob<br/>Receiver"]
        U_Addr["Address: 192.168.1.100<br/>Single destination"]
    end

    subgraph Broadcast["1-to-N: Broadcast/Multicast (TV/Radio Model)"]
        B_Source["Source<br/>One Sender"] --> B_DevA["Device A"]
        B_Source --> B_DevB["Device B"]
        B_Source --> B_DevC["Device C"]
        B_Source --> B_DevD["Device D"]
        B_Addr["Broadcast: 255.255.255.255<br/>Multicast: 224.0.0.0-239.255.255.255"]
    end

    subgraph ManyToOne["N-to-1: Many-to-One (Sensor Network Model)"]
        M_S1["Sensor 1"] --> M_Sink["Sink/Gateway"]
        M_S2["Sensor 2"] --> M_Sink
        M_S3["Sensor 3"] --> M_Sink
        M_S4["Sensor 4"] --> M_Sink
        M_Addr["Many sources to One collector<br/>Typical IoT data collection"]
    end

    classDef unicastStyle fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
    classDef broadcastStyle fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    classDef manyStyle fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    classDef addrStyle fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff,font-size:10px

    class U_Alice,U_Bob unicastStyle
    class B_Source,B_DevA,B_DevB,B_DevC,B_DevD broadcastStyle
    class M_S1,M_S2,M_S3,M_S4,M_Sink manyStyle
    class U_Addr,B_Addr,M_Addr addrStyle

Figure 777.1: Three fundamental communication typologies. 1-to-1 Unicast (Navy): telephony model with direct point-to-point addressing. 1-to-N Broadcast/Multicast (Teal): TV/radio model where one source sends to many receivers using broadcast (255.255.255.255) or multicast (224.0.0.0-239.255.255.255) addresses. N-to-1 Many-to-One (Orange): sensor network model where many sources converge data to a single sink or gateway.

777.4.1 Communication Pattern Comparison

Pattern Direction Addressing Bandwidth Usage IoT Examples When to Use
1-to-1 (Unicast) Single sender to Single receiver Specific IP/MAC (e.g., 192.168.1.100) Efficient (targeted) Device commands, actuator control, remote debugging Point-to-point control, secure communication
1-to-N (Broadcast) Single sender to All receivers 255.255.255.255 (local), ff:ff:ff:ff:ff:ff (L2) High (all process) Device discovery, ARP, DHCP, emergency alerts Network-wide announcements, local discovery
1-to-N (Multicast) Single sender to Group members 224.0.0.0 - 239.255.255.255 Moderate (group only) Firmware updates, time sync, video streaming Targeted group communication, scalable updates
N-to-1 (Many-to-One) Many senders to Single receiver All to Gateway IP Aggregated at sink Sensor data collection, telemetry, logging Data aggregation, centralized processing
N-to-N (Many-to-Many) Many senders to Many receivers Mesh routing High (complex routing) Peer-to-peer mesh, collaborative sensing Distributed systems, decentralized control

777.5 1-to-1 Communication: The Telephony Model

Concept: Like a traditional phone call where Alice calls Bob directly.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph LR
    Alice["Alice<br/>192.168.1.10"] -->|"Unicast packet<br/>Dest: 192.168.1.20"| Bob["Bob<br/>192.168.1.20"]

    style Alice fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
    style Bob fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff

Figure 777.2: Unicast (1-to-1): Direct point-to-point communication between specific sender and receiver.

Characteristics: - Addressing: Specific destination IP or MAC address - Bandwidth: Most efficient - only sender and receiver process the packet - Reliability: Can use TCP for guaranteed delivery - Security: Easy to encrypt (TLS/DTLS) for point-to-point security

IoT Use Cases: - Sending commands to a specific actuator (e.g., “unlock door #5”) - Reading sensor data from a specific device - Remote SSH/debugging sessions to individual devices - MQTT publish to specific device topics

777.6 1-to-N Communication: The Broadcast/Multicast Model

Concept: Like a TV or radio station - one broadcaster, many listeners.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph LR
    Server["Server<br/>(One Source)"] --> A["Device A<br/>(listens)"]
    Server --> B["Device B<br/>(listens)"]
    Server --> C["Device C<br/>(listens)"]
    Server --> D["Device D<br/>(listens)"]

    style Server fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
    style A fill:#16A085,stroke:#2C3E50,color:#fff
    style B fill:#16A085,stroke:#2C3E50,color:#fff
    style C fill:#16A085,stroke:#2C3E50,color:#fff
    style D fill:#16A085,stroke:#2C3E50,color:#fff

Figure 777.3: Broadcast/Multicast (1-to-N): Single source transmits to multiple listening devices simultaneously.

777.6.1 Broadcast vs. Multicast Addressing

Type IPv4 Address IPv6 Address Scope Efficiency
Local Broadcast 255.255.255.255 N/A (uses multicast) Single subnet Low (all devices process)
Directed Broadcast 192.168.1.255 N/A Specific subnet Medium
Multicast 224.0.0.0 - 239.255.255.255 ff00::/8 Group members only High (only subscribers process)

777.6.2 Common Multicast Groups

Address Purpose
224.0.0.1 All hosts on local network
224.0.0.2 All routers on local network
224.0.0.251 mDNS (Multicast DNS) for device discovery
224.0.1.1 NTP (Network Time Protocol)
239.255.255.250 SSDP/UPnP device discovery

IoT Use Cases: - Device discovery: mDNS (224.0.0.251) for finding IoT devices on network - Firmware updates: Multicast OTA updates to thousands of devices simultaneously - Time synchronization: NTP multicast (224.0.1.1) for synchronized sensor readings - Emergency alerts: Broadcast alerts to all devices in a zone - Video streaming: Multicast IPTV/surveillance to multiple monitors

777.6.3 Bandwidth Efficiency Example

Firmware update to 1000 devices (10 MB file):

Unicast approach:
  - 1000 x 10 MB = 10 GB total network traffic
  - Server sends 1000 separate copies

Multicast approach:
  - 1 x 10 MB = 10 MB total network traffic (at source)
  - Network replicates at routers
  - 99.9% bandwidth reduction

777.7 N-to-1 Communication: The Sensor Network Model

Concept: Many sensors report to a single data sink or gateway - the dominant pattern in IoT.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph LR
    S1["Sensor 1"] --> GW["Gateway/Sink<br/>(One Collector)"]
    S2["Sensor 2"] --> GW
    S3["Sensor 3"] --> GW
    S4["Sensor 4"] --> GW
    GW --> Cloud["Cloud"]

    style S1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style S2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style S3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style S4 fill:#E67E22,stroke:#2C3E50,color:#fff
    style GW fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
    style Cloud fill:#16A085,stroke:#2C3E50,color:#fff

Figure 777.4: Many-to-One (N-to-1): Multiple sensors converge data to single gateway/sink for aggregation and cloud forwarding.

Characteristics: - Data aggregation: Sink collects, processes, and forwards data - Bottleneck: Sink can become overwhelmed (single point of congestion) - Routing: All routes converge toward sink (e.g., RPL DODAG) - Energy: Nodes near sink consume more energy (relay more traffic)

IoT Use Cases: - Environmental monitoring: 100s of temperature/humidity sensors to central logger - Industrial telemetry: Machine sensors to SCADA/HMI system - Smart agriculture: Soil moisture sensors to irrigation controller - Smart city: Parking sensors to central management platform - Wearables: Body sensors to smartphone gateway

777.7.1 Scalability Considerations

Scale Sink Requirement Typical Solution
10-50 sensors Single gateway Raspberry Pi, Arduino gateway
50-500 sensors High-throughput gateway Industrial gateway, edge server
500-5000 sensors Hierarchical aggregation Multi-tier edge to cloud
5000+ sensors Distributed sinks Multiple gateways with load balancing

777.7.2 The Hotspot Problem in Mesh Networks

In N-to-1 scenarios within mesh networks, nodes close to the sink relay traffic for distant nodes, creating energy hotspots:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    subgraph Row1["Distant Sensors"]
        A1["Node"] --- A2["Node"] --- A3["Node"] --- A4["Node"]
    end

    subgraph Row2["Middle Layer"]
        B1["Node"] --- B2["Node"] --- B3["Node"] --- B4["Node"]
    end

    subgraph Row3["Hotspot Zone (3x traffic)"]
        C1["Node"] --- C2["Node"] --- C3["Hotspot"] --- Sink["Sink"]
    end

    A3 --- B3
    B3 --- C3

    style A1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style A2 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style A3 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style A4 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style B1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style B2 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style B3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style B4 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style C1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style C2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style C3 fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style Sink fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff

Figure 777.5: Hotspot problem: Nodes near sink (Orange) relay traffic for distant nodes, experiencing 3x higher traffic load and faster battery drain than distant sensors (Gray).

Mitigation strategies: - Multiple sinks: Distribute data collection points - Mobile sink: Move sink location to balance energy consumption - Data aggregation: Compress data at intermediate nodes - Load balancing: Rotate routing paths

777.8 Communication Patterns in IoT Protocols

Protocol Dominant Pattern Why Example
MQTT N-to-1 (pub to broker), 1-to-N (broker to subs) Centralized broker model Sensors publish to broker, subscribers receive
CoAP 1-to-1 (request/response), 1-to-N (observe) REST-like resource access Client requests sensor value, server responds
LoRaWAN N-to-1 (uplink dominant) Star topology, battery optimization 1000 sensors to gateway to network server
Zigbee N-to-1, with multicast support Mesh routes to coordinator Sensors to routers to coordinator
Thread N-to-N (mesh), N-to-1 (border router) IPv6 mesh with external connectivity Devices mesh internally, aggregate to cloud via border router
BLE Mesh 1-to-N (managed flooding) Publish/subscribe model Lightswitch to all lights in group

777.9 Topology Selection Decision Matrix

Requirement Star Ring Tree Partial Mesh Full Mesh Protocol Example
High bandwidth Excellent Poor Good Moderate Excellent Wi-Fi, Ethernet
Fault tolerance SPOF Dual ring SPOF Good Excellent Zigbee, Thread
Low cost $50-200 $100-500 $100-300 $500-2K $5K-20K LoRaWAN, Zigbee
Scalability Hub limit O(n) latency O(log n) O(n) O(n^2) LoRaWAN, Thread
Energy efficiency Direct paths Multi-hop Hierarchical Routing overhead High overhead LoRaWAN, Zigbee
Deterministic latency 2 hops max Token passing Depth-limited Variable 1 hop Industrial bus
Easy deployment Simple Simple Hierarchical Complex Very complex Wi-Fi, LoRaWAN

777.9.1 Decision Flowchart

  1. Life-safety or critical? -> Mesh (fault tolerance) or Dual-star (failover)
  2. High bandwidth (>1 Mbps)? -> Star (Wi-Fi) or Tree (Ethernet)
  3. Battery-powered? -> Star-of-stars (LoRaWAN) or Mesh with sleep (Zigbee)
  4. Large area (>100m)? -> Star-of-stars (LoRaWAN) or Mesh (Zigbee)
  5. Low cost priority? -> Star (Wi-Fi/Zigbee hub) or Bus (industrial)
  6. Deterministic timing? -> Ring (token) or Star (time-slotted)
NoteKey Insight: Hybrid Topologies Are the Norm

Real-world IoT deployments rarely use pure topologies. A smart building might use:

  • Star for Wi-Fi cameras (high bandwidth)
  • Mesh for Zigbee lights (fault tolerance)
  • Star-of-stars for LoRaWAN outdoor sensors (long range)
  • Tree for Ethernet backbone (scalability)

This hybrid approach optimizes cost, performance, and reliability for different device classes.

777.10 Summary

Communication typologies describe data flow patterns independent of physical topology:

1-to-1 (Unicast): - Direct point-to-point communication - Most efficient bandwidth usage - Used for: Device commands, secure communication

1-to-N (Broadcast/Multicast): - One source to many receivers - Broadcast: All devices, Multicast: Subscribers only - Used for: Device discovery, firmware updates, emergency alerts

N-to-1 (Many-to-One): - Dominant IoT pattern for sensor data collection - Creates hotspots near sink nodes - Used for: Environmental monitoring, telemetry, smart city

N-to-N (Many-to-Many): - Full mesh communication - Highest complexity and overhead - Used for: Distributed control, peer-to-peer systems

Protocol Mapping: - MQTT: N-to-1 (sensors) + 1-to-N (subscribers) - CoAP: 1-to-1 (request/response) + 1-to-N (observe) - LoRaWAN: N-to-1 (uplink dominant) - Zigbee/Thread: N-to-1 with mesh routing

777.11 What’s Next

In the next chapter, Hybrid Topology Design, we’ll explore how to combine multiple topologies in real-world IoT deployments, with detailed design patterns, cost-benefit analysis, and quantitative examples.