45  App Protocol Examples

In 60 Seconds

Real-world IoT deployments rarely use a single protocol – they combine multiple protocols in hybrid architectures where each handles what it does best. This chapter walks through a systematic protocol selection framework using an agricultural sensor network case study, balancing power consumption, bandwidth efficiency, latency requirements, and implementation complexity across sensor-to-gateway (CoAP/UDP) and gateway-to-cloud (MQTT/TCP) communication paths.

45.1 Learning Objectives

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

  • Apply Protocol Selection Frameworks: Systematically evaluate protocol choices for real-world IoT deployments
  • Analyze Agricultural Sensor Networks: Design communication architecture for multi-protocol IoT systems
  • Evaluate Trade-offs: Assess power, bandwidth, latency, and reliability constraints to select the best protocol for each network segment
  • Design Hybrid Architectures: Construct multi-protocol systems that combine CoAP, MQTT, and LoRaWAN to leverage their respective strengths
  • Calculate Power Budgets: Quantify battery life impact of protocol overhead to justify design decisions
  • Configure Reliability: Select appropriate QoS levels and retry strategies for each data urgency class
  • Justify Protocol Decisions: Document technical rationale for protocol selection with quantified evidence

These worked examples show application protocols in action with real IoT scenarios. You will see how to choose between MQTT, CoAP, and HTTP for different situations, and walk through complete message exchanges. Seeing protocols used in context makes the abstract concepts practical and memorable.

“Let’s solve a real problem!” said Max the Microcontroller. “A smart greenhouse has 50 temperature sensors, a cloud dashboard, and a mobile app. Which protocol for what?”

Sammy the Sensor started: “The 50 sensors publish readings every minute. That’s MQTT – lightweight pub-sub, one connection per sensor, the broker handles distribution. Each sensor publishes to greenhouse/zone-{n}/temperature and the dashboard subscribes to greenhouse/# to get everything.”

“The mobile app needs on-demand data,” said Lila the LED. “When a farmer opens the app, it wants the CURRENT temperature instantly – not the next scheduled update. That’s a CoAP GET or HTTP GET to the cloud API. Request-response, not pub-sub.”

Bella the Battery completed the picture: “And for firmware updates to all 50 sensors, use HTTP – it handles large file transfers with reliable TCP connections. See how one greenhouse uses THREE protocols? MQTT for continuous monitoring, CoAP for quick checks, and HTTP for maintenance. Each protocol plays its role!”

45.2 Prerequisites

Before diving into this chapter, you should have completed:

Key Concepts

  • Protocol Selection Worked Example: A structured analysis comparing protocol options for a specific IoT scenario, evaluating overhead, QoS requirements, device constraints, and operational costs.
  • MQTT Topic Design: The practice of designing hierarchical MQTT topic structures (e.g., sensors/{device-id}/{measurement}) for organized, scalable IoT data pipelines.
  • CoAP Resource URI Design: Designing CoAP resource paths following REST conventions to represent IoT device resources in a logical, discoverable structure.
  • Message Rate Analysis: Calculating channel bandwidth, broker capacity, and storage requirements from message frequency, payload size, and device count.

45.3 How This Chapter Fits

Chapter Series Navigation:

  1. Introduction and Why Lightweight Protocols Matter
  2. Protocol Overview and Comparison
  3. REST API Design for IoT
  4. Real-time Protocols
  5. Worked Examples (this chapter)

This final chapter synthesizes all previous concepts through a comprehensive case study of agricultural IoT protocol selection.

45.4 Worked Example: Protocol Selection for Agricultural Sensor Network

45.5 Worked Example: Choosing Protocols for a Smart Agriculture Deployment

Scenario: A farming cooperative is deploying soil sensors across 500 hectares of farmland to monitor soil moisture, temperature, pH, and nutrient levels. The deployment includes 200 battery-powered sensors with 5-year target battery life, 10 solar-powered weather stations, and 5 LoRaWAN gateways with cellular backhaul. Data must reach a cloud platform for irrigation control decisions, with some readings requiring near-real-time response (soil moisture triggering irrigation) and others tolerating hourly batching (soil pH for long-term analysis).

Goal: Select the optimal application protocol(s) for sensor-to-gateway and gateway-to-cloud communication, balancing power consumption, reliability, bandwidth efficiency, and implementation complexity.

What we do: Analyze data patterns, timing constraints, and device capabilities.

Why: Protocol selection depends on matching protocol characteristics to application needs.

Data flow analysis:

Source Count Data Type Size Frequency Urgency
Soil moisture sensor 200 Single value + ID 12 bytes Every 15 min High (irrigation trigger)
Temperature sensor 200 Single value + ID 10 bytes Every 15 min Low (trend analysis)
pH sensor 200 Single value + ID 10 bytes Every 4 hours Very low (monthly reports)
Nutrient sensor (NPK) 200 3 values + ID 18 bytes Every 4 hours Very low
Weather station 10 10 metrics + ID 80 bytes Every 5 min Medium (forecast input)

Aggregate traffic calculation:

Segment Messages/hour Bytes/hour Peak burst
Sensors to gateway 850 ~12 KB 200/min at top of hour
Gateway to cloud 850 (relayed) ~25 KB (with headers) Same
Cloud to gateway (commands) ~10 ~500 bytes Irrigation triggers

Device constraints:

Device Type CPU RAM Power Budget Radio
Soil sensor 16 MHz MCU 8 KB 3 uA sleep, 20 mA TX LoRa (SF7-12)
Weather station 48 MHz MCU 32 KB Solar, 100 mA continuous OK LoRa + cellular
Gateway ARM Cortex-A 512 MB Mains/solar, unconstrained LoRaWAN + LTE

Key insight: Sensors are extremely constrained (8 KB RAM rules out TLS). Gateway has resources for any protocol. Two-stage protocol strategy needed.

What we do: Compare MQTT, CoAP, and HTTP for each network segment.

Why: Different segments have different constraints; one protocol may not fit all.

Sensor-to-Gateway segment (LoRaWAN link):

Protocol Feasibility Pros Cons
CoAP Excellent 4-byte header, UDP-based, fits LoRa Limited QoS, no built-in pub-sub
MQTT-SN Good Designed for sensor networks, QoS options More complex, needs gateway translation
Raw payload Excellent Minimal overhead, maximum battery No standard tooling, custom parsing
HTTP Poor Universal but huge overhead 200+ byte headers kill battery

Gateway-to-Cloud segment (LTE cellular):

Protocol Feasibility Pros Cons
MQTT Excellent Persistent connection, QoS levels, broker ecosystem TCP overhead for small messages
CoAP Good Lightweight, works over UDP Less ecosystem support, NAT issues
HTTP Good Universal, RESTful, debugging tools High overhead, no push without SSE
AMQP Good Enterprise routing, transactions Overkill for this scale

Cloud-to-Device commands (irrigation triggers):

Protocol Feasibility Pros Cons
MQTT Excellent Bidirectional on same connection, subscribe pattern Already connected for telemetry
CoAP Observe Good Lightweight subscription Less mature than MQTT
HTTP polling Poor Constant overhead, latency Wastes battery, slow response

What we do: Select protocols for each segment and design the message flow.

Why: The right combination leverages each protocol’s strengths.

Recommended architecture:

[Soil Sensors]                    [Gateway]              [Cloud]
      |                               |                     |
      |----CoAP/LoRaWAN (minimal)--->|                     |
      |                               |                     |
      |                               |---MQTT/TLS/LTE---->|
      |                               |<--MQTT subscribe---|
      |                               |                     |
      |<--LoRaWAN Class C downlink---|<--MQTT command-----|

Protocol selection rationale:

Segment Protocol Rationale
Sensor to Gateway CoAP over LoRaWAN Minimal overhead (4 bytes), confirmable option, fits 51-byte LoRa payload
Gateway to Cloud MQTT with TLS Reliable delivery (QoS 1), persistent connection (no handshake per message), cloud platform support
Cloud to Gateway MQTT subscribe Same connection, instant push for irrigation commands
Gateway to Sensor LoRaWAN Class C Downlink for urgent commands, sensors listen continuously when powered

Why not MQTT-SN on sensors?

  • Requires UDP and broker—LoRaWAN provides reliability at MAC layer
  • CoAP NON (non-confirmable) for low-priority data = 4 bytes
  • CoAP CON (confirmable) for moisture = 4 bytes + ACK
  • MQTT-SN PUBLISH = 7+ bytes minimum

What we do: Optimize payload encoding for each protocol and link.

Why: Every byte matters for battery life; LoRa energy scales with payload size.

Sensor payload format (binary, 12 bytes total):

Byte 0-1:  Sensor ID (uint16)
Byte 2:    Message type (0=moisture, 1=temp, 2=pH, 3=NPK)
Byte 3-4:  Value 1 (uint16, scaled)
Byte 5-6:  Value 2 (uint16, for NPK only)
Byte 7-8:  Value 3 (uint16, for NPK only)
Byte 9:    Battery level (0-255)
Byte 10:   Sequence number (0-255, for dedup)
Byte 11:   Checksum (CRC8)

CoAP message structure (sensor to gateway):

CoAP Header (4 bytes):
  Ver=1, T=CON, TKL=1, Code=POST
  Message ID (2 bytes)
  Token (1 byte)

Options (3 bytes):
  Uri-Path: "d" (delta=11, len=1, value="d")

Payload (12 bytes):
  Binary sensor data as above

Total: 19 bytes over LoRa (vs 200+ for HTTP)

MQTT message structure (gateway to cloud):

Topic: farm/gateway-01/sensors/moisture
Payload (JSON for cloud compatibility):
{
  "sensor_id": "S-0142",
  "type": "moisture",
  "value": 34.7,
  "unit": "%",
  "battery": 92,
  "seq": 128,
  "ts": "2024-07-15T10:30:00Z",
  "gateway": "GW-01"
}

Total: ~180 bytes (acceptable over LTE)

Why binary on LoRa, JSON on LTE?

  • LoRa: 12 bytes binary vs 100+ bytes JSON = 8x battery savings
  • LTE: Bandwidth abundant, JSON enables debugging, cloud parsing

What we do: Quantify battery life impact of protocol choices.

Why: 5-year battery life is the primary constraint; wrong protocol = frequent replacement.

LoRa transmission energy (SF7, 125 kHz, 14 dBm):

Payload Size Time on Air Energy (uJ) Per Day (200 sensors)
12 bytes (binary) 36 ms 1,000 4,800 messages/day
51 bytes (max) 77 ms 2,100 -
100 bytes (JSON) N/A Would need SF12 Infeasible

Let’s calculate the battery life for CoAP over LoRaWAN vs HTTP over cellular.

Given: Transmissions \(T = 96\)/day, battery \(B = 6{,}000\) mAh (2× AA lithium)

CoAP/LoRaWAN energy per day: \[E_{\text{sleep}} = 0.003 \text{ mA} \times 23.8 \text{ h} = 0.07 \text{ mAh}\] \[E_{\text{sensor}} = 96 \times 5 \text{ mA} \times 0.5 \text{ s} / 3600 = 0.07 \text{ mAh}\] \[E_{\text{TX}} = 96 \times 40 \text{ mA} \times 0.036 \text{ s} / 3600 = 0.04 \text{ mAh}\] \[E_{\text{RX}} = 96 \times 12 \text{ mA} \times 0.2 \text{ s} / 3600 = 0.06 \text{ mAh}\] \[E_{\text{total}} = 0.07 + 0.07 + 0.04 + 0.06 = 0.24 \text{ mAh/day}\]

Battery life (CoAP): \(L = \frac{B}{E_{\text{total}}} = \frac{6{,}000}{0.24} = 25{,}000\) days \(\approx\) 68 years (practical limit: ~7 years due to battery shelf life)

HTTP/Cellular energy per day: \[E_{\text{wake}} = 96 \times 100 \text{ mA} \times 5 \text{ s} / 3600 = 13.3 \text{ mAh}\] \[E_{\text{HTTP}} = 96 \times 50 \text{ mA} \times 2 \text{ s} / 3600 = 2.7 \text{ mAh}\] \[E_{\text{total}} = 13.3 + 2.7 = 16 \text{ mAh/day}\]

Battery life (HTTP): \(\frac{6{,}000}{16} = 375\) days \(\approx\) 1 year

CoAP achieves far longer battery life than HTTP, making it economically viable for 5+ year deployments (capped by battery self-discharge at ~7 years).

Battery life calculation (2x AA lithium, 6,000 mAh):

Activity Current Duration Daily mAh
Sleep (23.8 hours) 3 uA 23.8 h 0.07
Sensor reading (96x) 5 mA 0.5 s each 0.07
LoRa TX (96x) 40 mA 36 ms each 0.04
LoRa RX (Class A) 12 mA 200 ms each 0.06
Daily total - - 0.24 mAh
Battery life - - ~7 years

If HTTP were used (hypothetical, requires cellular modem):

Activity Current Duration Daily mAh
Cellular wake 100 mA 5 s each 13.3
HTTP request 50 mA 2 s each 2.7
Daily total - - 16+ mAh
Battery life - - ~1 year

Key insight: CoAP over LoRaWAN achieves 7-year battery life. HTTP over cellular would last only 1 year. Protocol choice directly determines project economics.

What we do: Configure QoS and retry strategies for each data type.

Why: Not all data is equally important; over-protecting low-priority data wastes energy.

Reliability configuration by data type:

Data Type Urgency CoAP Mode MQTT QoS Retry Strategy
Soil moisture High CON (confirmable) QoS 1 3 retries, exponential backoff
Temperature Low NON (non-confirmable) QoS 0 No retry (loss acceptable)
pH Very low NON (batched) QoS 0 Daily batch upload
Irrigation command Critical N/A (downlink) QoS 2 Retry until ACK

Gateway buffering for connectivity loss:

class GatewayBuffer:
    def __init__(self, max_size_mb=100):
        self.buffer = []  # Persisted to SD card
        self.max_size = max_size_mb * 1024 * 1024

    def receive_from_sensor(self, msg):
        # Always accept from sensors
        self.buffer.append({
            'timestamp': time.time(),
            'priority': self.get_priority(msg),
            'data': msg
        })
        self.enforce_size_limit()

    def sync_to_cloud(self, mqtt_client):
        if not mqtt_client.is_connected():
            return  # Buffer until connected

        # Sort by priority, send critical first
        sorted_buffer = sorted(self.buffer, key=lambda x: -x['priority'])

        for msg in sorted_buffer:
            qos = 1 if msg['priority'] > 5 else 0
            if mqtt_client.publish(msg['data'], qos=qos):
                self.buffer.remove(msg)

    def get_priority(self, msg):
        # Moisture > 80% or < 20% = critical
        if msg['type'] == 'moisture':
            if msg['value'] > 80 or msg['value'] < 20:
                return 10
            return 5
        return 1

Outcome: A two-stage protocol architecture using CoAP over LoRaWAN for sensor-to-gateway and MQTT over TLS for gateway-to-cloud, achieving 7-year sensor battery life while meeting all reliability requirements.

Key decisions made and why:

Decision Choice Rationale
Sensor protocol CoAP (not MQTT-SN) 4-byte header vs 7+, simpler implementation on 8KB MCU
Sensor encoding Binary (12 bytes) 8x smaller than JSON, directly impacts battery
Gateway protocol MQTT with TLS Reliable, bidirectional, cloud platform compatibility
Cloud encoding JSON Debugging, analytics tools, bandwidth not constrained
Moisture reliability CoAP CON + MQTT QoS 1 Critical for irrigation timing
Temperature reliability CoAP NON + MQTT QoS 0 Loss of individual readings acceptable
Command delivery MQTT QoS 2 + LoRaWAN Class C Must guarantee irrigation commands execute

Protocol overhead comparison for this deployment:

Protocol Stack Sensor Payload Total on LoRa Efficiency
CoAP + binary 12 bytes 19 bytes 63%
MQTT-SN + binary 12 bytes 22 bytes 55%
HTTP + JSON 100 bytes Infeasible N/A

Quantified outcomes:

  • Battery life: 7 years (exceeds 5-year target)
  • Message overhead: 19 bytes total (63% payload efficiency)
  • Reliability: 99.9% for moisture readings (CoAP CON + retries)
  • Command latency: < 2 seconds from cloud trigger to sensor
  • Gateway buffer: 100 MB = 7 days of data during cellular outage
  • Cloud bandwidth: ~25 KB/hour (600 KB/day) - minimal LTE costs

45.5.1 Interactive: Protocol Overhead vs Payload Size

Common Mistake: Over-Engineering Reliability for Non-Critical Data

The mistake: Using MQTT QoS 2 (exactly-once delivery) for all messages because “we want reliability,” without analyzing whether duplicates or occasional loss actually matter.

Real-world example:

  • Smart building deploys 1,000 temperature sensors
  • Each sensor publishes readings every 60 seconds to MQTT broker
  • Architect chooses QoS 2 because “temperature data is important”
  • Result: 4x message overhead (PUBLISH, PUBREC, PUBREL, PUBCOMP)
  • Broker CPU usage spikes to 80% (vs 20% with QoS 1)
  • 3-month-old broker runs out of disk space from QoS 2 state files

Why it’s wrong: Temperature readings are idempotent time-series data: - Each reading is independent (no cumulative state) - Next reading arrives in 60 seconds (staleness window is tiny) - Analytics systems interpolate missing points - Duplicates are harmless (take latest by timestamp)

Appropriate QoS levels:

# Temperature telemetry: QoS 0 sufficient
sensor.publish("building/floor3/temp", temp_reading, qos=0)
# Loss of 1-2 readings in 1,000 is acceptable

# Low battery alert: QoS 1 appropriate
sensor.publish("building/floor3/battery_low", alert, qos=1)
# Must arrive, duplicates harmless (alert remains active)

# Actuator command: QoS 2 required
controller.publish("hvac/zone-12/setpoint", new_temp, qos=2)
# Duplicate setpoint commands cause oscillation, exactly-once essential

Impact of QoS 2 overuse:

  • Throughput: 4x more messages (1,000 sensors × 4 msgs = 4,000 msg/sec)
  • Latency: 2-4 RTT per message (vs 1 RTT for QoS 1)
  • Storage: Persistent QoS 2 state grows unbounded if not configured properly
  • Cost: AWS IoT Core charges per message – QoS 2 costs 4x more

The fix: Default to QoS 0 for telemetry, QoS 1 for alerts, QoS 2 only for non-idempotent commands. Document QoS requirements per message type in your design specification.

Common Pitfalls

Worked examples should include explicit rationale for protocol choices — why MQTT over CoAP, why QoS 1 over QoS 0. Without documented reasoning, future engineers cannot evaluate whether assumptions still hold.

A worked example for smart meter MQTT design has different constraints than one for medical IoT. Always identify which constraints from a worked example apply to your specific domain before applying the solution.

Worked examples often optimize for specific scenarios. Don’t over-optimize protocol selection for rare edge cases at the cost of simplicity — maintainability and team familiarity often outweigh marginal performance gains.

:

45.6 What’s Next?

Continue your IoT learning journey with protocol-specific deep dives:

Chapter Focus Why Read It
MQTT Fundamentals QoS levels, Last Will, retained messages, topic design Deepen your understanding of the gateway-to-cloud protocol used in this chapter’s case study
CoAP Fundamentals and Architecture CoAP message types, block transfers, observe pattern Master the sensor-to-gateway protocol that achieved 7-year battery life in the worked example
LoRaWAN Overview Long-range, low-power WAN — link layer below CoAP Understand the radio technology that carries CoAP packets across 500 hectares of farmland
Transport Protocols TCP vs UDP trade-offs, reliability mechanisms Strengthen the transport-layer foundations behind CoAP/UDP and MQTT/TCP decisions
IoT Security Fundamentals Threat modelling for protocol stacks Evaluate TLS configuration choices for the MQTT gateway-to-cloud segment
Data Management and Analytics Ingesting and processing IoT time-series data Apply the cloud-side analysis that consumes the MQTT data stream from your gateway