Internet of Things Networks

We stand at a pivotal moment in computing history. For decades, the Internet connected computers—first mainframes, then desktops, then laptops, then smartphones. But a profound transformation is underway: the Internet is expanding beyond computers to encompass the physical world itself.

The Internet of Things (IoT) represents this paradigm shift—a world where sensors monitor soil moisture in agricultural fields, actuators control factory robots, wearable devices track human health metrics, and smart meters optimize energy consumption in real-time. By 2030, projections suggest over 30 billion connected IoT devices worldwide, generating zetabytes of data annually.

But here's the critical insight: IoT networking is fundamentally different from traditional IP networking. The devices are smaller, power-constrained, bandwidth-limited, and deployed in environments where conventional TCP/IP stacks are impossibly heavy. Understanding these differences is essential for any network engineer working with modern connected systems.

The term "Internet of Things" is attributed to Kevin Ashton, who used it in 1999 while working at Procter & Gamble to describe a system where physical objects could be tagged with RFID sensors and tracked via the Internet. Since then, the concept has evolved dramatically.

A modern definition:

IoT networking encompasses the communication infrastructure enabling physical devices—embedded with sensors, software, and network connectivity—to collect, exchange, and act upon data with minimal human intervention.

This definition reveals several key aspects:

1. Physical devices — Not general-purpose computers, but specialized hardware designed for specific functions (temperature sensing, motion detection, valve control, etc.)

2. Embedded intelligence — Devices contain microcontrollers or microprocessors capable of local processing, not just passive data transmission

3. Network connectivity — Communication occurs over various media (wireless, wired, cellular) using diverse protocols suited to device constraints

4. Minimal human intervention — Systems operate autonomously, with machines communicating with machines (M2M communication) in most interactions

Not all IoT devices face the same constraints. The IETF has developed classifications to categorize devices based on their capabilities, which directly influences protocol selection and network architecture.

The RFC 7228 Classification:

The Internet Engineering Task Force (IETF) published RFC 7228 to establish a common vocabulary for constrained-node networks. This document defines three classes of constrained devices:

Beyond the IETF Classes:

Real-world IoT deployments often include devices across a broader spectrum:

Tier 1: Bare Metal Sensors

• Microcontrollers: 8-bit AVR, ARM Cortex-M0
• RAM: 2-32 KB
• Power: Microwatts in sleep, milliwatts active
• Communication: Proprietary protocols, 802.15.4, BLE
• Example: Soil moisture sensors in precision agriculture

Tier 2: Smart Sensors

• Microcontrollers: ARM Cortex-M3/M4, RISC-V
• RAM: 64-512 KB
• Power: Milliwatts in operation
• Communication: 6LoWPAN, LoRaWAN, NB-IoT
• Example: Smart parking sensors, industrial vibration monitors

Tier 3: Edge Nodes

• Processors: ARM Cortex-A series, low-power x86
• RAM: MB to GB range
• Power: Watts in operation
• Communication: Wi-Fi, Ethernet, LTE
• Example: Video analytics cameras, edge servers

Tier 4: IoT Gateways

• Processors: Multi-core ARM, x86
• RAM: GB range
• Power: Tens of watts
• Communication: Multiple protocols (aggregation)
• Example: Industrial protocol converters, smart building controllers

IoT networks employ various topologies depending on device capabilities, coverage requirements, and application constraints. Understanding these topologies is essential for network design and protocol selection.

Star Topology (Hub and Spoke)

In star topology, all end devices communicate directly with a central coordinator or gateway. The gateway handles all routing, aggregation, and external connectivity.

Characteristics:

• Simple device implementation (no routing logic needed)
• Single point of failure at the gateway
• Limited range to gateway coverage area
• Gateway bears all traffic load

Use cases: LoRaWAN networks, Bluetooth Low Energy piconets, many cellular IoT deployments

Mesh Topology

Mesh networks allow devices to relay messages for other devices, extending coverage and providing redundancy. Any node can potentially reach any other node through multi-hop routing.

Characteristics:

• Self-healing: network reroutes around failed nodes
• Extended coverage beyond single-hop range
• Higher complexity in devices (routing protocols required)
• Increased latency due to multi-hop paths

Use cases: Zigbee networks, Thread, industrial wireless sensor networks

Tree (Cluster Tree) Topology

A hierarchical structure where routers form a tree backbone, and end devices connect as leaves. Combines some benefits of star and mesh.

Characteristics:

• Hierarchical routing simplifies protocol design
• Reduced complexity compared to full mesh
• Parent node failure can orphan child devices
• Natural fit for aggregation patterns

Use cases: Some Zigbee configurations, hierarchical sensor networks

Traditional Internet protocols were designed for powerful, always-connected devices. IoT devices require a modified protocol stack optimized for constrained environments. Let's examine each layer:

Physical Layer (PHY)

IoT devices use diverse radio technologies based on range, power, and data rate requirements:

• Sub-GHz bands (433 MHz, 868 MHz, 915 MHz): Excellent propagation, building penetration. Used by LoRa, Sigfox, many proprietary protocols.
• 2.4 GHz ISM band: Global availability, higher data rates. Used by Zigbee, Thread, Bluetooth, Wi-Fi.
• Cellular bands: Wide-area coverage, carrier-managed. Used by LTE-M, NB-IoT.
• 5 GHz and beyond: High bandwidth, limited range. Used by Wi-Fi, emerging 5G IoT.

Data Link Layer (MAC)

IoT MAC protocols focus on energy efficiency far more than traditional Ethernet or Wi-Fi:

• IEEE 802.15.4: Foundation for Zigbee, Thread, 6LoWPAN. Defines low-power, low-rate wireless networks with 10-20 Kbps typical rates.
• LoRa PHY + LoRaWAN MAC: Long-range (kilometers), ultra-low power, but very low data rates (0.3-50 Kbps).
• BLE (Bluetooth Low Energy): Short range, medium data rate, advertising-based discovery.

Network Layer

Traditional IPv4/IPv6 headers are too large for constrained networks. Adaptations include:

• 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks): Header compression reduces IPv6's 40-byte header to as few as 2-3 bytes for local communication. Enables native IP connectivity for constrained devices.
• RPL (Routing Protocol for Low-Power and Lossy Networks): Distance-vector routing protocol designed for lossy links and constrained devices. Builds DODAGs (Destination-Oriented Directed Acyclic Graphs) optimized for specific metrics.
• Thread: Mesh networking protocol using 6LoWPAN and RPL, designed for smart home applications.

Transport Layer

TCP's overhead and connection-oriented nature make it unsuitable for many IoT applications:

• UDP: Preferred for IoT due to lower overhead, but lacks reliability.
• DTLS (Datagram TLS): Security layer over UDP, used by CoAP.
• QUIC: Emerging option for more capable IoT devices.

Application Layer

HTTP/REST is too heavy for constrained devices:

• CoAP (Constrained Application Protocol): REST-like semantics over UDP. Compact binary format. Supports observe pattern for subscriptions.
• MQTT (Message Queuing Telemetry Transport): Publish-subscribe messaging over TCP. Popular for aggregated IoT data.
• MQTT-SN: MQTT for Sensor Networks—UDP-based variant for constrained devices.
• LwM2M (Lightweight M2M): Device management protocol built on CoAP.

Beyond individual protocols, IoT systems follow architectural patterns that define how data flows from sensors to applications.

Three-Tier Architecture

The foundational IoT architecture consists of three layers:

1. Perception Layer (Edge)

   • Physical sensors and actuators
   • Local data acquisition and control
   • Constrained device protocols (Zigbee, BLE, LoRa)

2. Network Layer (Gateway/Fog)

   • Protocol translation and aggregation
   • Edge computing and filtering
   • IP connectivity to cloud

3. Application Layer (Cloud)

   • Data storage and analytics
   • Business logic and dashboards
   • Device management and OTA updates

Edge Computing Architecture

As IoT generates massive data volumes, transmitting everything to the cloud becomes impractical. Edge computing moves processing closer to data sources:

Benefits:

• Reduced latency for time-critical applications
• Lower bandwidth consumption (only relevant data transmitted)
• Continued operation during connectivity outages
• Privacy preservation (sensitive data processed locally)

Implementation Patterns:

• Filtering: Only send data exceeding thresholds
• Aggregation: Transmit summaries instead of raw readings
• Local analytics: Run ML models at the edge for real-time inference
• Caching: Store frequently accessed data at gateways

Fog Computing Extension

Fog computing extends the edge paradigm with a distributed compute layer between edge devices and cloud:

• Multiple fog nodes provide redundancy
• Geographic distribution for low-latency coverage
• Hierarchical processing: device → edge → fog → cloud
• Policy-based data routing and processing

No single networking technology suits all IoT applications. The choice depends on range, power consumption, data rate, latency requirements, and deployment costs. Here's a comprehensive taxonomy:

Short-Range Technologies (< 100m)

Long-Range Technologies (> 1km)

Selection Framework

When choosing IoT connectivity, evaluate against these criteria:

1. Coverage requirements: Indoor penetration, rural/urban, building materials
2. Data volume: Bytes per message × messages per day × number of devices
3. Latency tolerance: Real-time control vs. periodic monitoring
4. Power budget: Mains-powered, battery with replacement access, or harvest-only
5. Deployment cost: Hardware, network infrastructure, ongoing connectivity fees
6. Ecosystem maturity: Available devices, cloud integrations, developer tools
7. Regulatory compliance: Licensed vs. unlicensed spectrum, regional variations

IoT networking faces unique challenges that require specialized solutions:

1. Power Management

For battery-operated devices, network activity is the primary power consumer. Strategies include:

• Deep sleep modes: Radio off 99%+ of time, wake on schedule or interrupt
• Duty cycling: MAC protocols coordinate transmission windows
• Transmission aggregation: Buffer data, transmit in bursts
• Adaptive rate control: Reduce transmission power/frequency based on conditions

2. Addressing and Discovery

Billions of devices require addressability and discoverability:

• IPv6 adoption: 128-bit addresses accommodate IoT scale; 6LoWPAN compresses for constrained networks
• DNS-SD (Service Discovery): mDNS for local discovery, DNS-SD for service advertisement
• CoAP Resource Directory: Centralized discovery for constrained devices
• Device provisioning: Secure onboarding at scale is a significant challenge

3. Intermittent Connectivity

IoT devices frequently experience disconnection:

• Store-and-forward: Buffer messages during disconnection
• Delay-tolerant networking: Protocols designed for high latency and disruption
• Conflict resolution: Handle data updates during partition
• Quality of service degradation: Graceful handling of reduced connectivity

4. Heterogeneity

IoT ecosystems contain diverse devices and protocols:

• Protocol translation: Gateways convert between incompatible protocols
• Data normalization: Standard formats (SenML, WoT Thing Description) for interoperability
• Semantic interoperability: Common data models enable cross-vendor integration
• API standardization: REST/CoAP patterns for uniform access

We've established the foundational concepts of IoT networking. Let's consolidate the key takeaways:

What's next:

Now that we understand IoT networking fundamentals, we'll dive deep into the Low-Power Protocols that enable battery-operated devices to communicate for years without replacement. The next page examines the unique MAC layer mechanisms, duty cycling strategies, and energy-aware routing that make constrained IoT communication possible.