9  Topology Communication Patterns

Key Concepts
  • Unicast: One-to-one communication where a message is addressed to a single recipient
  • Multicast: One-to-many communication where a single message is delivered to a group of subscribed receivers
  • Broadcast: One-to-all communication where a message is sent to every node in the network
  • Anycast: One-to-nearest communication where a message is delivered to the closest or most available member of a group
  • Many-to-One (Convergecast): Multiple sensors sending data to a single sink; the dominant pattern in IoT telemetry
  • Publish-Subscribe: A decoupled messaging pattern where publishers emit messages to named topics without knowing who receives them
  • Request-Response: A synchronous pattern where a client sends a request and waits for a reply; used by CoAP and HTTP

9.1 In 60 Seconds

IoT networks use four main communication patterns: unicast (one-to-one), broadcast (one-to-all), multicast (one-to-group), and many-to-one (sensor aggregation). Choosing the right pattern directly affects bandwidth usage, power consumption, and scalability – for example, multicast reduces source traffic by up to 99.9% compared to individual unicast messages when updating a large group of devices.

9.2 Learning Objectives

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

  • Distinguish Communication Patterns: Classify unicast, broadcast, multicast, and many-to-one data flows
  • Apply Addressing Schemes: Select appropriate IP addressing (unicast, broadcast, multicast) for each pattern
  • Optimize Bandwidth Usage: Calculate bandwidth savings from multicast versus unicast delivery
  • Design Data Collection Architectures: Architect many-to-one aggregation patterns for sensor networks
  • Map Protocols to Patterns: Justify why specific IoT protocols favor particular communication typologies

Deep Dives:

Protocol Details:

9.3 Prerequisites

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

9.4 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).

“There are different ways to communicate in a network,” said Sammy the Sensor. “When I send my temperature reading to the gateway, that is unicast – one sender, one receiver. Like a phone call between two people.”

“When the cloud server needs to update the firmware on ALL sensors at once, that is broadcast,” explained Max the Microcontroller. “One sender, every device listens. Like a radio station broadcasting to millions.”

Lila the LED added, “There is also multicast – sending to a SPECIFIC GROUP. If the server wants to update only the light bulbs and not the temperature sensors, it sends to the ‘lights’ multicast group. Way more efficient than sending individual messages to each light!”

“In IoT, the most common pattern is many-to-one,” said Bella the Battery. “Hundreds of sensors all reporting to one gateway. That is why RPL routing was invented – it builds tree-shaped routes that funnel all sensor data toward the gateway efficiently. Choosing the right communication pattern – multicast instead of unicast for 1,000 devices – can cut network traffic by up to 99.9% and save tons of my energy!”

9.5 The Three Fundamental Communication Patterns

Three fundamental network communication typologies shown side-by-side. Left panel shows 1-to-1 Unicast pattern (Navy) with single sender Alice connected to single receiver Bob via direct point-to-point link, labeled as telephony model with example IP address 192.168.1.100. Center panel shows 1-to-N Broadcast/Multicast pattern (Teal) with single source at top connected via arrows to multiple receivers (Device A, B, C, D) arranged in a row below, labeled as TV/radio model with broadcast address 255.255.255.255 for local broadcast and multicast range 224.0.0.0-239.255.255.255. Right panel shows N-to-1 Many-to-One pattern (Orange) with multiple sensors (Sensor 1, 2, 3, 4) at top all sending data via converging arrows to single sink/gateway at bottom, labeled as sensor network model typical of IoT data collection. Each pattern includes typical use cases and addressing schemes.
Figure 9.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.

9.5.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

9.6 1-to-1 Communication: The Telephony Model

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

Unicast 1-to-1 communication pattern showing Alice at IP 192.168.1.10 sending a direct unicast packet to Bob at IP 192.168.1.20, illustrating point-to-point telephony model where only sender and receiver process the packet.
Figure 9.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

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

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

Broadcast 1-to-N communication pattern showing single server as one source sending data to multiple listening devices A B C and D simultaneously, illustrating TV/radio broadcast model where one sender transmits to many receivers.
Figure 9.3: Broadcast/Multicast (1-to-N): Single source transmits to multiple listening devices simultaneously.

9.7.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)

9.7.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

9.7.3 Bandwidth Efficiency Example

Try It: Multicast vs Unicast Bandwidth Calculator

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

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

Many-to-One N-to-1 communication pattern showing Sensors 1 2 3 and 4 all converging their data streams to a single Gateway/Sink collector which then forwards aggregated data to Cloud, illustrating dominant IoT sensor network data collection pattern.
Figure 9.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: Hundreds 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

9.8.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
Try It: N-to-1 Sensor Network Traffic Calculator

9.8.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:

Mesh network hotspot problem diagram showing three rows of 4 sensors each connected in a grid pattern, with all traffic converging toward the sink node at bottom right. Nodes near sink are highlighted as hotspot zone experiencing 3x more traffic because they relay packets from distant nodes in addition to their own data, illustrating energy consumption imbalance in many-to-one mesh routing.
Figure 9.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

9.9 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

9.10 Topology Selection Decision Matrix

Communication patterns are tightly coupled to topology choice: the dominant data flow (N-to-1, 1-to-N, or unicast) often dictates which physical topology and protocol is the best fit. Use this matrix to map requirements to topology options.

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²) 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

9.10.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)
Key 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.

9.11 Worked Example: Choosing Communication Patterns for a Smart Farm

Scenario: A precision agriculture deployment covers 500 hectares with the following devices:

Device Type Count Data Pattern Frequency Data Size
Soil moisture sensors 2,000 Report to gateway Every 15 min 64 bytes
Weather stations 10 Report to gateway Every 5 min 256 bytes
Irrigation valves 200 Receive commands On-demand 32 bytes
Firmware server 1 Push updates Monthly 500 KB

Analysis: Match communication pattern to each data flow

1. Soil sensors to gateway – N-to-1 (Many-to-One)

Traffic volume:
  2,000 sensors x 4 msgs/hour x 64 bytes = 512 KB/hour
  = 8.5 KB/min aggregate at the gateway

Bottleneck analysis:
  Gateway receives 133 msgs/min (2.2 msgs/sec)
  LoRaWAN gateway handles ~1,000 msgs/hour comfortably
  Result: Single gateway sufficient for this traffic pattern

2. Commands to irrigation valves – 1-to-1 (Unicast)

Each valve needs individual commands:
  "Open valve #47 for 30 minutes at 2.5 L/min"

Why unicast, not broadcast:
  - Different zones need different watering schedules
  - Accidental broadcast could flood all 200 zones
  - Each command must be acknowledged (confirmed delivery)

Protocol choice: MQTT QoS 1 with per-valve topics
  Topic: farm/zone/{zone_id}/valve/command

3. Firmware updates – 1-to-N (Multicast)

Without multicast:
  2,200 devices x 500 KB = 1.1 GB network traffic
  At LoRaWAN data rates (5 kbps): 500 KB x 8 bits/byte / 5,000 bps = 800 seconds per device
  Sequential update: 2,200 x 800s = 20.4 days (!)

With multicast (grouped by device type):
  Group 1: 2,000 soil sensors -- one 500 KB multicast stream
  Group 2: 200 valves -- one 500 KB multicast stream
  Group 3: 10 weather stations -- one 500 KB multicast stream
  Total: 3 x 500 KB = 1.5 MB network traffic

Bandwidth savings: 1.1 GB / 1.5 MB = 733x reduction

4. Weather alerts – 1-to-N (Broadcast)

When a weather station detects frost risk, ALL devices need the alert:

Alert message: {"type": "frost_warning", "temp_c": -1.2, "action": "close_valves"}
Broadcast to all 200 valves simultaneously via MQTT topic: farm/alerts/#
Result: 200 valves close within 5 seconds (vs 30+ seconds for sequential unicast)

Decision summary:

Flow Pattern Protocol Rationale
Sensor data N-to-1 LoRaWAN uplink Low power, infrequent, convergecast
Valve commands 1-to-1 MQTT QoS 1 unicast Targeted, acknowledged delivery
Firmware updates 1-to-N Multicast 733x bandwidth reduction
Emergency alerts 1-to-N MQTT broadcast All devices must respond fast

Common Pitfalls

Broadcasting a configuration update to 500 nodes wakes every device unnecessarily, draining batteries and consuming channel capacity. Fix: use multicast groups or unicast to target only the devices that need the update.

In many-to-one patterns, the sink node receives traffic from all sensors simultaneously after a trigger event (e.g., power restore). Fix: implement jitter (random back-off delays) at each sensor to spread transmissions over time.

Polling 100 sensors every second with request-response doubles traffic (request + response) and adds latency. Fix: use event-driven publish-subscribe for high-frequency telemetry and reserve request-response for occasional queries.

Multicast requires routing protocols to establish and maintain group membership trees. Fix: account for the control traffic overhead of multicast group management when sizing the network.

9.12 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

9.13 Knowledge Check

9.14 What’s Next

Direction Chapter Focus
Next Hybrid Topology Design Combining topologies for real-world IoT deployments
Previous Topology Analysis Graph theory metrics and failure analysis
Related Topology Failures Failure modes and resilience strategies