622  Networking Basics: Protocols and MAC Classification

622.1 Learning Objectives

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

  • Understand IoT Protocols by Layer: Identify common protocols at each OSI/TCP-IP layer
  • Master MAC Protocol Classification: Explain contention-based, contention-free, and hybrid MAC protocols
  • Select Appropriate MAC Protocols: Choose MAC protocols based on power, latency, and density requirements
  • Apply Protocol Selection: Use decision trees to match protocols to IoT use cases

622.2 Prerequisites

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

  • Networking Basics: Introduction: Understanding core networking concepts including the layers model, IP addressing, and network types
  • Layered Network Models: The OSI and TCP/IP models provide the framework for understanding how protocols operate at different layers

622.3 Common IoT Protocols by Layer

Time: ~12 min | Intermediate | P07.C14.U02

622.3.1 Application Layer (Layer 7)

Protocol Transport Use Case Overhead
MQTT TCP/UDP General IoT messaging Low
CoAP UDP Constrained devices Very Low
HTTP/HTTPS TCP Web services, REST APIs High
AMQP TCP Enterprise messaging Medium
WebSocket TCP Real-time bidirectional Medium

622.3.2 Network Layer (Layer 3)

Protocol Purpose IoT Application
IPv4 Internet routing Legacy IoT, NAT required
IPv6 Next-gen routing Modern IoT, 6LoWPAN
RPL Routing for LLNs Sensor networks
ICMP Error reporting Ping, traceroute

622.4 MAC Protocol Classification

Time: ~10 min | Intermediate | P07.C14.U03

MAC stands for Medium Access Control. Think of it as the “traffic rules” for how devices share a network channel:

  • The Problem: Multiple devices want to send data at the same time on the same channel
  • The Solution: MAC protocols provide rules so devices can take turns without interfering
  • Real-World Analogy: Like people in a meeting raising hands to speak (polling), or taking turns in order (TDMA), or just talking when there’s silence (CSMA)

Different MAC protocols make different trade-offs between fairness, efficiency, and complexity.

At the Data Link Layer, the Medium Access Control (MAC) sublayer determines how devices share access to the physical medium. For IoT, choosing the right MAC protocol directly impacts battery life, latency, and scalability.

622.4.1 MAC Protocol Taxonomy

%%{init: {'theme': 'base', 'themeVariables': {
  'primaryColor': '#E67E22',
  'primaryTextColor': '#fff',
  'primaryBorderColor': '#C0392B',
  'lineColor': '#2C3E50',
  'secondaryColor': '#16A085',
  'tertiaryColor': '#7F8C8D',
  'clusterBkg': '#ECF0F1',
  'clusterBorder': '#2C3E50',
  'fontSize': '14px',
  'fontFamily': 'Inter, system-ui, sans-serif'
}}}%%

graph TB
    MAC["<b>MAC Protocols</b><br/>Medium Access Control"]

    %% Main categories
    Contention["<b>Contention-Based</b><br/>(Random Access)"]
    Free["<b>Contention-Free</b><br/>(Scheduled Access)"]
    Hybrid["<b>Hybrid Schemes</b><br/>(Mixed Strategies)"]

    %% Contention-based protocols
    ALOHA["<b>ALOHA</b><br/>Simple, inefficient<br/>~18% max throughput"]
    CSMA["<b>CSMA</b><br/>Carrier sense before send<br/>Better collision avoidance"]
    CSMACA["<b>CSMA/CA</b><br/>Wi-Fi, Zigbee<br/>Collision avoidance"]
    CSMACD["<b>CSMA/CD</b><br/>Ethernet<br/>Collision detection"]

    %% Contention-free protocols
    TDMA["<b>TDMA</b><br/>Time slots<br/>Bluetooth, 802.15.4"]
    FDMA["<b>FDMA</b><br/>Frequency slots<br/>LoRa channels"]
    CDMA["<b>CDMA</b><br/>Spreading codes<br/>Cellular networks"]

    %% Hybrid protocols
    Poll["<b>Polling</b><br/>Master-slave<br/>Deterministic access"]
    Token["<b>Token Passing</b><br/>Ordered access<br/>CAN bus, Token Ring"]
    Reservation["<b>Reservation</b><br/>Request-grant<br/>S-ALOHA, DQDB"]

    MAC --> Contention
    MAC --> Free
    MAC --> Hybrid

    Contention --> ALOHA
    Contention --> CSMA
    Contention --> CSMACA
    Contention --> CSMACD

    Free --> TDMA
    Free --> FDMA
    Free --> CDMA

    Hybrid --> Poll
    Hybrid --> Token
    Hybrid --> Reservation

    classDef contentionStyle fill:#E67E22,stroke:#C0392B,stroke-width:2px,color:#fff
    classDef freeStyle fill:#16A085,stroke:#117A65,stroke-width:2px,color:#fff
    classDef hybridStyle fill:#7F8C8D,stroke:#566573,stroke-width:2px,color:#fff
    classDef rootStyle fill:#2C3E50,stroke:#1A252F,stroke-width:3px,color:#fff

    class MAC rootStyle
    class Contention,ALOHA,CSMA,CSMACA,CSMACD contentionStyle
    class Free,TDMA,FDMA,CDMA freeStyle
    class Hybrid,Poll,Token,Reservation hybridStyle

Figure 622.1: Medium Access Control Protocol Classification Tree

This variant visualizes the same MAC protocols but arranges them by their key trade-offs: Latency Predictability vs Energy Efficiency. Different IoT use cases prioritize different quadrants.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'fontSize': '11px'}}}%%
quadrantChart
    title MAC Protocol Trade-offs for IoT
    x-axis Low Energy Efficiency --> High Energy Efficiency
    y-axis Variable Latency --> Predictable Latency

    quadrant-1 Industrial Control
    quadrant-2 Real-Time Monitoring
    quadrant-3 Smart Home Devices
    quadrant-4 Battery-Powered Sensors

    TDMA: [0.85, 0.90]
    Token: [0.60, 0.85]
    Polling: [0.55, 0.80]
    CDMA: [0.40, 0.70]
    CSMA-CA: [0.50, 0.35]
    ALOHA: [0.90, 0.20]
    FDMA: [0.70, 0.65]

Figure 622.2: MAC Protocol Trade-off Quadrant - Visualizes energy efficiency vs latency predictability for different IoT scenarios

Reading the Quadrant:

  • Top-Right (Best for Battery + Real-Time): TDMA excels - scheduled slots enable deep sleep AND predictable timing
  • Bottom-Right (Battery Priority): ALOHA maximizes sleep time but has unpredictable collisions
  • Top-Left (Latency Priority): Polling/Token ensure timing but require constant coordination
  • Bottom-Left (General Purpose): CSMA/CA offers flexibility at cost of both metrics

622.4.2 MAC Protocol Performance Comparison

Protocol Throughput Latency Fairness Energy Efficiency Best For
ALOHA Low (18% max) Variable, high collisions Poor Low overhead Very simple, low traffic (LoRaWAN Class A)
CSMA/CA Medium (50-70%) Variable, backoff delays Fair Medium Wi-Fi, Zigbee, general wireless
TDMA High (90%+) Fixed, predictable Excellent Very Low (sleep in unused slots) Scheduled IoT (Bluetooth, 802.15.4)
Polling Medium Bounded, depends on cycle Excellent Medium (wait for poll) Deterministic industrial systems
CDMA High Low, simultaneous Good High complexity Cellular (NB-IoT, LTE-M)
Token Passing High (90%+) Bounded, token wait Perfect Medium Industrial buses (CAN, Profibus)
NoteKey Trade-Offs

Contention-Based (Orange):

  • Pros: Simple, scalable, no synchronization needed
  • Cons: Variable latency, collisions waste energy
  • IoT Impact: Good for bursty, unpredictable traffic (sensor alerts)

Contention-Free (Teal):

  • Pros: Predictable latency, no collisions, excellent for sleep scheduling
  • Cons: Requires synchronization, fixed overhead even when idle
  • IoT Impact: Best for battery-powered, scheduled reporting (smart meters)

Hybrid (Gray):

  • Pros: Combines benefits, adapts to traffic patterns
  • Cons: More complex implementation
  • IoT Impact: Industrial IoT with mixed traffic (time-critical + best-effort)

622.4.3 IoT MAC Protocol Selection Guide

ImportantChoosing MAC for Battery-Powered IoT

Low Traffic, Simple Devices (e.g., soil moisture sensor reporting 3x/day):

  • Use: ALOHA variants (LoRaWAN Class A)
  • Why: 99% of time sleeping, rare collisions, minimal overhead

Scheduled, Predictable Traffic (e.g., smart meter reading every 15 min):

  • Use: TDMA (Bluetooth, 802.15.4 beacon mode)
  • Why: Devices wake only for assigned slot, predictable latency

Bursty, Unpredictable Traffic (e.g., motion sensor sending alerts):

  • Use: CSMA/CA with aggressive sleep (Wi-Fi PSM)
  • Why: Flexible access, sleep when idle, listen before send reduces collisions

Real-Time, Deterministic (e.g., industrial robot control):

  • Use: TDMA or Polling (TSN, 802.15.4 GTS)
  • Why: Guaranteed latency bounds, no collisions

High Density, Interference (e.g., stadium with 10,000+ devices):

  • Use: CDMA or FDMA (NB-IoT, LoRa channels)
  • Why: Orthogonal access, simultaneous transmissions without collision

622.4.4 Protocol Selection Decision Tree

Use this decision tree to select the appropriate MAC protocol for your IoT application:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D', 'fontSize': '12px'}}}%%
flowchart TD
    Start["SELECT MAC PROTOCOL<br/>What are your constraints?"]

    Q1{"Battery<br/>Powered?"}
    Q2{"Latency<br/>Critical?<br/>(<100ms)"}
    Q3{"Traffic<br/>Pattern?"}
    Q4{"High<br/>Density?<br/>(>100 devices)"}
    Q5{"Real-time<br/>Required?"}
    Q6{"Existing<br/>Infrastructure?"}

    %% Outcomes
    ALOHA["ALOHA/LoRaWAN Class A<br/>Minimal overhead<br/>Sleep 99%+ of time<br/>Best: 10+ year battery"]
    TDMA["TDMA (BLE/802.15.4)<br/>Sleep between slots<br/>No collisions<br/>Best: Scheduled sensors"]
    CSMA["CSMA/CA (Wi-Fi/Zigbee)<br/>Flexible access<br/>Good for bursty traffic<br/>Best: Smart home"]
    POLL["Polling/Token<br/>Deterministic latency<br/>Industrial grade<br/>Best: Factory automation"]
    CDMA["CDMA/FDMA (NB-IoT)<br/>Handles density<br/>Orthogonal access<br/>Best: Smart cities"]

    Start --> Q1

    Q1 -->|"Yes<br/>(years of life needed)"| Q3
    Q1 -->|"No<br/>(mains power)"| Q2

    Q3 -->|"Infrequent<br/>(<1x/hour)"| ALOHA
    Q3 -->|"Scheduled<br/>(every N minutes)"| TDMA
    Q3 -->|"Bursty/Random<br/>(event-driven)"| CSMA

    Q2 -->|"Yes<br/>(<10ms latency)"| Q5
    Q2 -->|"No<br/>(best effort OK)"| Q4

    Q5 -->|"Yes<br/>(control systems)"| POLL
    Q5 -->|"No<br/>(monitoring only)"| CSMA

    Q4 -->|"Yes<br/>(stadium/city)"| CDMA
    Q4 -->|"No<br/>(<100 devices)"| CSMA

    style Start fill:#2C3E50,stroke:#16A085,color:#fff
    style Q1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q4 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q5 fill:#E67E22,stroke:#2C3E50,color:#fff
    style ALOHA fill:#16A085,stroke:#2C3E50,color:#fff
    style TDMA fill:#16A085,stroke:#2C3E50,color:#fff
    style CSMA fill:#16A085,stroke:#2C3E50,color:#fff
    style POLL fill:#16A085,stroke:#2C3E50,color:#fff
    style CDMA fill:#16A085,stroke:#2C3E50,color:#fff

Figure 622.3: Interactive decision tree for selecting the optimal MAC protocol based on IoT system requirements including power constraints, latency needs, traffic patterns, and device density.

622.4.5 Real-World Examples

Wi-Fi (CSMA/CA):

  • Listen for silence (carrier sense)
  • Wait random backoff if busy
  • Send when clear
  • Acknowledgment required
  • IoT Use: Smart home devices with AC power

Bluetooth LE (TDMA):

  • Central device assigns 1.25ms time slots
  • Peripheral transmits only in assigned slot
  • Sleep between slots
  • IoT Use: Wearables, sensors with predictable 1-second updates

LoRaWAN Class A (ALOHA):

  • Device transmits whenever it wants
  • No carrier sense (ultra-low power radio off between sends)
  • Accepts ~1% packet loss due to collisions
  • IoT Use: Agricultural sensors, asset tracking (battery life > 10 years)

CAN Bus (CSMA/CR - Collision Resolution):

  • Listen before send (like CSMA)
  • If collision, highest priority message wins
  • Losers retry immediately
  • IoT Use: Automotive, industrial control (deterministic, fault-tolerant)
TipEnergy Impact Example

Scenario: 100 battery-powered sensors, 1 reading/hour

ALOHA:

  • Device wakes, transmits immediately, sleeps
  • Average energy: ~5 mJ/transmission
  • Collision rate: ~1% (99 devices sleeping)
  • Battery life: 5-10 years (dominant factor is sleep current)

CSMA/CA:

  • Device wakes, listens for clear channel, sends, waits for ACK
  • Average energy: ~15 mJ/transmission (3x ALOHA due to listening)
  • Collision rate: <0.1%
  • Battery life: 2-3 years (listening overhead significant)

TDMA:

  • Device wakes only at assigned slot (e.g., slot 47 of 100)
  • Average energy: ~3 mJ/transmission (no listening, no collisions)
  • Collision rate: 0%
  • Battery life: 10+ years (minimal overhead, perfect sleep scheduling)

Verdict: For ultra-low-power IoT with infrequent transmissions, TDMA or ALOHA variants dominate.

622.5 Knowledge Check

Question: An IoT gateway bridges a Zigbee sensor network (PAN) to a cloud server via the internet (WAN). At which OSI layer does the gateway primarily operate to perform this routing function?

Explanation: The gateway operates as a Layer 3 (Network layer) router, forwarding packets between different networks based on IP addresses. Process: (1) Zigbee sensor sends data on 2.4 GHz radio (Layers 1-2) with 6LoWPAN compressed IPv6 header (Layer 3). (2) Gateway decapsulates to Layer 3, examines destination IP address. (3) Gateway re-encapsulates with Ethernet/Wi-Fi Layer 2 headers and forwards toward internet. (4) Cloud server receives packet. Why Layer 3? Routing decisions use IP addresses (Layer 3). Layer 2 switches forward based on MAC addresses within a single network segment - cannot bridge different network technologies. Layer 1 only handles physical signals - no routing intelligence. Layer 4 (TCP/UDP) ensures end-to-end reliability but doesn’t make forwarding decisions. Many IoT gateways also perform protocol translation (MQTT to HTTP), data aggregation, and security functions, but the core routing function is Layer 3.

Question: A factory’s industrial IoT network has strict latency requirements for machine control (<10ms). Which network topology provides the most predictable and lowest latency, and why?

Explanation: Wired star with switch provides most predictable latency for industrial control. Why wired beats wireless: Wireless (Wi-Fi, Zigbee) has variable latency from channel contention (CSMA/CA), interference, retransmissions, hidden node problems. In factory with 50 devices, a device might wait 5-50ms for channel access - unpredictable. Wired Ethernet with switch: Dedicated bandwidth per port, simultaneous transmissions (full-duplex), microsecond forwarding latency. Switch benefits: Stores and forwards frames only to destination port (no collisions), buffers handle burst traffic, supports VLANs for traffic separation. Industrial protocols (PROFINET, EtherNet/IP, EtherCAT) rely on wired Ethernet’s determinism for real-time control. Mesh wireless topology: While resilient, multi-hop routing adds variable latency (each hop = 1-10ms + queuing delays). For 10ms total budget, 3-hop mesh path is risky. Bus topology: Collisions increase with traffic. Star hub (vs switch): Half-duplex, shared collision domain. Industrial best practice: Wired switched Ethernet backbone, wireless only for non-critical sensors. For <1ms latency, use Time-Sensitive Networking (TSN) extensions to Ethernet.

Question: A smart building uses the OSI model’s layered approach. If you need to replace Zigbee (Layer 2) with Thread (Layer 2) while keeping IPv6 addressing (Layer 3) and MQTT (Layer 7) unchanged, which concept enables this modularity?

Explanation: Layer independence is the OSI model’s core principle - each layer provides services to the layer above through well-defined interfaces, hiding implementation details. Your scenario: Before: MQTT (Layer 7) -> TCP (Layer 4) -> IPv6 (Layer 3) -> Zigbee (Layer 2) -> 2.4 GHz radio (Layer 1). After: MQTT (Layer 7) -> TCP (Layer 4) -> IPv6 (Layer 3) -> Thread (Layer 2) -> 2.4 GHz radio (Layer 1). Only Layer 2 changes; Layers 3-7 unchanged. How it works: IPv6 (Layer 3) doesn’t care if Layer 2 is Zigbee, Thread, Ethernet, or Wi-Fi - it simply hands packets to Layer 2 and says “deliver to next hop.” MQTT application sees same IPv6 addresses, same TCP reliability, unchanged. Real-world benefit: You can upgrade building’s sensor network from Zigbee to Thread (better mesh routing, more vendors) without modifying applications, reconfiguring IP addresses, or changing MQTT broker.

Question: A building automation system uses a bus topology with 50 devices. A new HVAC controller is added. Compared to a star topology with a switch, what is the primary disadvantage?

Explanation: Bus topology disadvantages: Single point of failure: One break in bus cable disconnects all devices downstream. In 50-device system, maintenance risk is high. Collision domain: All 50 devices share same medium, compete for access using CSMA/CD. With 51st device, collision probability increases. More collisions = more retransmissions = lower throughput. Example: At 30% load, 10 devices might have 5% collision rate. At 70% load, 50 devices might have 40% collision rate (exponential increase). No simultaneous communication: Only one device transmits at a time. Troubleshooting difficulty: Finding fault location on shared bus is hard. Star topology with switch advantages: No single point of failure: One cable break affects only that device; others function normally. No collisions: Switch provides dedicated bandwidth per port (full-duplex), simultaneous bidirectional communication. 50 devices x 100 Mbps = 5 Gbps aggregate bandwidth. Scalability: Adding 51st device doesn’t degrade others’ performance. Easy troubleshooting: Switch port LEDs indicate which device has issues.

622.6 What’s Next

Now that you understand protocols and MAC classification, continue to learn about:

You can also return to the Networking Basics Overview for navigation to all related chapters.