6 Protocols & MAC Basics
6.2 Learning Objectives
By the end of this chapter, you will be able to:
- Classify IoT Protocols by Layer: Identify and categorize common protocols at each OSI/TCP-IP layer and explain their roles
- Differentiate MAC Protocol Categories: Compare contention-based, contention-free, and hybrid MAC protocols across performance metrics
- Select Appropriate MAC Protocols: Evaluate MAC protocols based on power budget, latency constraints, and device density requirements
- Apply Protocol Selection: Use decision trees to match and justify MAC protocol choices to specific IoT deployment scenarios
- Calculate MAC Throughput Efficiency: Apply ALOHA and CSMA/CA throughput formulas to quantify channel utilization trade-offs
6.3 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
Sensor Squad: The Protocol Stack Puzzle!
“There are so many protocols!” Sammy the Sensor exclaimed, looking at a chart. “MQTT, CoAP, TCP, UDP, IPv6, 802.15.4 – how do I know which ones to use?” Max the Microcontroller pointed to the layered model. “Each protocol lives at a different layer, like floors in a building. You pick one from each floor.”
“At the top floor – the Application layer – you choose how your data is formatted,” Lila the LED explained. “MQTT is great for general IoT messaging, CoAP is perfect for tiny constrained devices, and HTTP is for web services. At the Transport floor, TCP guarantees delivery while UDP is faster but less reliable.”
“Down at the bottom floors, you pick your radio technology,” Max continued. “Wi-Fi for high bandwidth, Zigbee for mesh networks, or LoRa for long range. Each one has a different MAC protocol that controls how devices share the airwaves.”
“The beautiful thing,” said Bella the Battery, “is that you mix and match! A temperature sensor might use CoAP over UDP over 6LoWPAN over 802.15.4 – optimized for low power at every layer. A security camera might use HTTP over TCP over Wi-Fi – optimized for high throughput. Same layered system, different protocol choices!”
6.4 Common IoT Protocols by Layer
6.4.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 |
6.4.2 Transport Layer (Layer 4)
| Protocol | Reliability | Overhead | IoT Application |
|---|---|---|---|
| TCP | Reliable, ordered | High (connection setup, ACKs) | MQTT, HTTP, AMQP |
| UDP | Unreliable, fast | Very Low (no handshake) | CoAP, DNS, streaming |
| QUIC | Reliable, encrypted | Medium (built-in TLS) | Modern web IoT, HTTP/3 |
| SCTP | Multi-stream reliable | Medium | Telecom signaling, IoT gateways |
6.4.3 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 |
6.4.4 Data Link Layer (Layer 2)
| Protocol | Range | Data Rate | Power | Use Case |
|---|---|---|---|---|
| Wi-Fi | 50-100m | 1-9600 Mbps | High | Smart home |
| Bluetooth LE | 10-50m | 1-2 Mbps | Very Low | Wearables |
| Zigbee | 10-100m | 250 Kbps | Very Low | Home automation |
| LoRa | 2-15 km | 0.3-50 Kbps | Ultra Low | Wide area sensors |
| Ethernet | 100m | 10-10000 Mbps | N/A | Wired industrial |
6.5 MAC Protocol Classification
For Beginners: What is MAC?
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.
6.5.1 MAC Protocol Taxonomy
Alternative View: MAC Protocol Trade-off Quadrant
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.
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
6.5.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) |
Putting Numbers to It
MAC Protocol Channel Utilization
Different MAC protocols achieve vastly different efficiency rates. Let’s quantify the mathematical limits:
Pure ALOHA (transmit anytime, collisions waste bandwidth): \[S = G \cdot e^{-2G} \quad \text{where } G = \text{offered load}\] Maximum throughput at \(G = 0.5\): \(S_{\text{max}} = 0.5 \cdot e^{-1} \approx 0.184\) (18.4%)
Slotted ALOHA (synchronized time slots): \[S = G \cdot e^{-G}\] Maximum at \(G = 1\): \(S_{\text{max}} = e^{-1} \approx 0.368\) (36.8% – double pure ALOHA)
CSMA/CA (used in 802.11 Wi-Fi, carrier sensing): \[S \approx \frac{T_{\text{data}}}{T_{\text{data}} + T_{\text{DIFS}} + T_{\text{backoff}} + T_{\text{ACK}}}\] Typical: 50–70% for low contention, drops to 20–30% with many competing nodes.
TDMA (fixed time slots per device): \[S = \frac{N \cdot T_{\text{data}}}{N \cdot T_{\text{data}} + T_{\text{guard}} + T_{\text{overhead}}}\] Can reach 85–95% with efficient scheduling.
For an IoT sensor network with 100 nodes sending 1 packet/sec: ALOHA wastes 82% of channel time to collisions, while TDMA wastes only 5–15% to scheduling overhead – explaining why synchronized protocols dominate constrained IoT environments.
Key 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)
6.5.3 IoT MAC Protocol Selection Guide
Choosing 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
6.5.4 Protocol Selection Decision Tree
Use this decision tree to select the appropriate MAC protocol for your IoT application:
6.5.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)
Energy 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.
6.6 Worked Example: MAC Protocol Selection for a Smart Building
Scenario: A commercial office building deploys three types of IoT systems, each with different traffic patterns. You must select the optimal MAC protocol for each to minimize total energy consumption while meeting latency requirements.
System 1: Occupancy sensors (200 sensors, battery-powered)
- Report occupancy changes: average 8 events per sensor per day
- Payload: 12 bytes per event
- Latency tolerance: 5 seconds
- Battery life target: 5 years on CR2032 (225 mAh)
System 2: HVAC control loop (50 actuators, mains-powered)
- Cycle time: 1 command every 500 ms per actuator
- Payload: 20 bytes per command
- Latency tolerance: <50 ms (control loop stability)
- Power: mains, not a concern
System 3: Conference room displays (30 displays, PoE-powered)
- Update when meeting starts/ends: average 12 updates per display per day
- Payload: 200 bytes (room name, attendees, agenda)
- Latency tolerance: 2 seconds
- Power: PoE, not a concern
Step 1: Calculate transmission energy per protocol
| MAC Protocol | Listen energy | Transmit energy | Collision overhead | Total per event |
|---|---|---|---|---|
| ALOHA | 0 mJ (no listen) | 5 mJ | 1% collision = 0.05 mJ | 5.05 mJ |
| CSMA/CA | 8 mJ (carrier sense) | 5 mJ | <0.1% = 0.005 mJ | 13.005 mJ |
| TDMA | 0.5 mJ (sync wake) | 5 mJ | 0% | 5.5 mJ |
Step 2: Evaluate each system
System 1 (Occupancy sensors) – ALOHA wins:
- Events: 8/day x 365 days x 5 years = 14,600 events per sensor
- ALOHA total: 14,600 x 5.05 mJ = 73.7 J (CR2032 capacity: ~2,430 J at 3V, i.e., 225 mAh x 3 V x 3.6) – fits easily
- CSMA/CA total: 14,600 x 13.005 mJ = 189.9 J – fits but 2.6x more energy
- TDMA: Would require all 200 sensors to maintain synchronized slots. With only 8 events/day, 99.97% of slots would be empty. Synchronization overhead dominates.
- Decision: ALOHA (like LoRaWAN Class A). Lowest energy for rare, unpredictable events.
System 2 (HVAC control loop) – TDMA wins:
- 50 actuators x 2 commands/second = 100 transmissions/second
- With CSMA/CA at 100 tx/sec on a 250 kbps Zigbee channel: collision probability = ~15%, average backoff = 20 ms. Worst-case latency = 80 ms – exceeds 50 ms budget
- With TDMA: 100 slots/second = 10 ms per slot. Each actuator transmits in its assigned slot. Worst-case latency = 10 ms – meets 50 ms budget with margin
- ALOHA at 100 tx/sec: the offered load far exceeds ALOHA’s theoretical maximum of 18.4% channel utilization. Beyond the optimal operating point, collision rates exceed 80% and throughput collapses. Unacceptable.
- Decision: TDMA (like Bluetooth connection events or 802.15.4 GTS). Predictable latency for control loops.
System 3 (Conference displays) – CSMA/CA wins:
- 12 events/day per display. Low traffic, no latency criticality.
- Mains-powered, so listening energy is irrelevant.
- 200-byte payloads benefit from CSMA/CA’s collision avoidance (larger packets waste more energy on collision).
- ALOHA: Acceptable, but 200-byte packets have higher collision cost.
- TDMA: Overkill for 12 events/day. Slot synchronization overhead not justified.
- Decision: CSMA/CA (standard Wi-Fi or Zigbee). Best balance of simplicity and reliability for low-rate, powered devices.
Step 3: Summary decision table
| System | Traffic | Power | Latency | MAC Choice | Why |
|---|---|---|---|---|---|
| Occupancy sensors | 8 events/day | Battery | 5 sec | ALOHA | Lowest energy for rare events, 99% sleeping |
| HVAC control | 2 cmds/sec | Mains | <50 ms | TDMA | Deterministic timing for control loop |
| Conference displays | 12 events/day | PoE | 2 sec | CSMA/CA | Simple, reliable for low-rate powered devices |
Key insight: There is no single “best” MAC protocol. The right choice depends on three factors: traffic pattern (bursty vs periodic vs continuous), power source (battery vs mains), and latency requirement (soft vs hard real-time). Most real-world IoT deployments use multiple MAC protocols simultaneously for different subsystems.
6.7 Practice Activities
6.8 Knowledge Check
Common Pitfalls
1. Confusing MAC Address With IP Address
MAC addresses operate at Layer 2 (local network segment). IP addresses operate at Layer 3 (routed networks). A router does not forward based on MAC addresses. Fix: remember that MAC addresses are local-only identifiers; IP addresses are used for end-to-end routing.
2. Assuming MAC Addresses Are Globally Unique in IoT
Some low-cost IoT chips ship with duplicate MAC addresses due to poor manufacturing quality control. Fix: verify MAC address uniqueness during commissioning and program unique addresses where the hardware allows it.
3. Not Accounting for MAC-Layer ACKs in Latency Calculations
IEEE 802.15.4 requires an ACK within 192 µs; each retransmission adds this delay. At 3 retransmissions, 576 µs of MAC-layer latency accumulates before the packet is declared lost. Fix: include MAC-layer retransmission latency in end-to-end latency budgets.
6.9 What’s Next
Now that you can classify MAC protocols, calculate throughput efficiency, and select protocols for IoT deployments, continue with these related chapters:
| Topic | Chapter | Description |
|---|---|---|
| Hands-On Configuration | Networking Basics: Hands-On Configuration | Port numbers, socket programming, network security hardening, and bandwidth calculation exercises |
| Labs and Practice | Networking Basics: Labs and Practice | Interactive simulations, Python protocol implementations, and comprehensive multi-topic knowledge checks |
| Network Topologies | Network Topologies Overview | Bus, star, mesh, tree and hybrid topologies with IoT deployment trade-offs |
| LoRaWAN & ALOHA MAC | LoRa & LoRaWAN | Deep dive into LoRaWAN Class A/B/C MAC behavior, the ALOHA access model, and spreading factors |
| Bluetooth LE & TDMA | Bluetooth BLE Fundamentals | Connection-event scheduling, TDMA slot assignment, and BLE power management |
| Zigbee & CSMA/CA | Zigbee Fundamentals | 802.15.4 CSMA/CA backoff algorithm, superframe structure, and guaranteed time slots |
Return to the Networking Basics Overview for the full chapter navigation map.