751  Transport Selection and Scenarios

751.1 Learning Objectives

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

  • Apply Selection Frameworks: Use decision trees to choose appropriate transport protocols for IoT scenarios
  • Evaluate Trade-offs: Balance reliability, latency, power consumption, and security in protocol selection
  • Design for Constraints: Select TCP, UDP, or DTLS based on device capabilities and application requirements
  • Analyze Real-World Scenarios: Map common IoT use cases (telemetry, control, streaming) to optimal protocols
  • Justify Protocol Choices: Provide technical rationale for transport layer decisions in system designs
  • Plan Hybrid Approaches: Combine multiple transport strategies for complex IoT deployments

What is this chapter? Guidance for selecting transport protocols based on IoT application requirements.

When to use: - When designing IoT systems - To understand protocol trade-offs - For making informed architecture decisions

Selection Criteria:

Scenario Recommended
Low latency needed UDP
Reliable delivery TCP
Constrained devices UDP + app-level reliability
Secure communication TLS/DTLS

Recommended Path: 1. Review Transport Fundamentals 2. Study scenarios here 3. Apply to your project requirements

Deep Dives: - Transport Fundamentals - TCP/UDP characteristics and operation - Transport Optimizations - Advanced TCP/UDP tuning - Transport Comprehensive Review - Complete protocol review

Comparisons: - IoT Protocols Overview - Application protocol comparison - CoAP vs MQTT - Transport layer impact

Security: - DTLS and Security - Securing UDP with DTLS

Products:

Learning: - Networking Labs - Hands-on practice - Simulations Hub - Protocol testing tools

751.2 Prerequisites

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

  • Transport Protocols: Fundamentals: Understanding TCP and UDP characteristics, connection vs connectionless protocols, and DTLS security is essential for making informed protocol selection decisions
  • Networking Basics: Knowledge of basic networking concepts including latency, throughput, packet loss, and reliability helps evaluate trade-offs in transport protocol choices
  • IoT Protocols Overview: Familiarity with application-layer protocols (CoAP, MQTT) provides context for how transport layer choices affect IoT application behavior

751.3 Transport Protocol Selection for IoT Scenarios

⏱️ ~15 min | ⭐⭐ Intermediate | 📋 P07.C34.U01

751.3.1 Scenario Analysis

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22'}}}%%
flowchart LR
    subgraph "Scenario Analysis Framework"
        S1["📊 Identify<br/>Requirements"]
        S2["⚖️ Evaluate<br/>Trade-offs"]
        S3["🎯 Select<br/>Protocol"]
        S4["✅ Validate<br/>Performance"]

        S1 --> S2 --> S3 --> S4
    end

    subgraph "Requirements"
        R1["Reliability"]
        R2["Latency"]
        R3["Power"]
        R4["Security"]
    end

    subgraph "Protocol Options"
        P1["TCP + TLS"]
        P2["UDP + DTLS"]
        P3["UDP + CoAP"]
        P4["UDP"]
    end

    S1 --> R1
    S1 --> R2
    S1 --> R3
    S1 --> R4

    S3 --> P1
    S3 --> P2
    S3 --> P3
    S3 --> P4

    style S1 fill:#E67E22,color:#fff
    style S2 fill:#E67E22,color:#fff
    style S3 fill:#E67E22,color:#fff
    style S4 fill:#E67E22,color:#fff
    style R1 fill:#2C3E50,color:#fff
    style R2 fill:#2C3E50,color:#fff
    style R3 fill:#2C3E50,color:#fff
    style R4 fill:#2C3E50,color:#fff
    style P1 fill:#16A085,color:#fff
    style P2 fill:#16A085,color:#fff
    style P3 fill:#16A085,color:#fff
    style P4 fill:#16A085,color:#fff

Figure 751.1

This variant shows the analysis framework as a time-based process, emphasizing when each step occurs during system design:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085'}}}%%
gantt
    title Protocol Selection Process Timeline
    dateFormat X
    axisFormat %s

    section Analysis
    Gather Requirements    :a1, 0, 2
    Document Constraints   :a2, 2, 2

    section Evaluation
    Compare TCP vs UDP     :e1, 4, 2
    Assess Security Needs  :e2, 6, 2
    Calculate Power Budget :e3, 8, 2

    section Selection
    Choose Protocol        :s1, 10, 1
    Select Stack Options   :s2, 11, 1

    section Validation
    Prototype Test         :v1, 12, 3
    Power Measurements     :v2, 15, 2
    Final Approval         :v3, 17, 1

This timeline view helps project managers understand that protocol selection is an iterative process requiring analysis, evaluation, selection, and validation phases.

This variant shows how different IoT scenarios prioritize trade-offs differently using a comparative view:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085'}}}%%
graph TB
    subgraph TEMP["Temperature Sensor"]
        T1["Reliability: LOW"]
        T2["Latency: MEDIUM"]
        T3["Power: HIGH priority"]
        T4["Security: LOW"]
    end

    subgraph FW["Firmware Update"]
        F1["Reliability: HIGH"]
        F2["Latency: LOW priority"]
        F3["Power: LOW priority"]
        F4["Security: HIGH"]
    end

    subgraph LOCK["Smart Lock"]
        L1["Reliability: HIGH"]
        L2["Latency: HIGH"]
        L3["Power: MEDIUM"]
        L4["Security: CRITICAL"]
    end

    TEMP -->|"Leads to"| UDP["UDP + CoAP NON"]
    FW -->|"Leads to"| TCP["TCP + TLS"]
    LOCK -->|"Leads to"| DTLS["UDP + DTLS + CON"]

    style T1 fill:#16A085,stroke:#2C3E50,color:#fff
    style T2 fill:#16A085,stroke:#2C3E50,color:#fff
    style T3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style T4 fill:#16A085,stroke:#2C3E50,color:#fff
    style F1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style F2 fill:#16A085,stroke:#2C3E50,color:#fff
    style F3 fill:#16A085,stroke:#2C3E50,color:#fff
    style F4 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L3 fill:#16A085,stroke:#2C3E50,color:#fff
    style L4 fill:#2C3E50,stroke:#E67E22,color:#fff
    style UDP fill:#16A085,stroke:#2C3E50,color:#fff
    style TCP fill:#2C3E50,stroke:#16A085,color:#fff
    style DTLS fill:#E67E22,stroke:#2C3E50,color:#fff

Orange-highlighted requirements indicate high priority for that scenario, showing how different priority profiles lead to different protocol choices.

751.3.2 Example Scenarios

NoteScenario 1: Temperature Sensor (Battery-Powered)

Requirements: - Reports temperature every 5 minutes - Battery-powered (must last years) - Occasional reading loss acceptable - Low latency preferred

Protocol Selection: UDP (with CoAP)

Reasoning: - Low overhead: 8-byte UDP header - Low power: No connection state, no ACKs - Loss tolerable: Missing one reading OK (next reading in 5 min) - CoAP: Application-level confirmable messages if needed

Power Impact: - UDP: ~10-20 ms radio on time per reading - TCP: ~50-100 ms (handshake, ACKs, teardown) - 5× power savings with UDP

NoteScenario 2: Firmware Update (Battery or Mains)

Requirements: - 500 KB firmware image - Must be 100% reliable - Can tolerate latency (not time-critical) - Corrupted firmware = bricked device

Protocol Selection: TCP (with TLS for security)

Reasoning: - Reliability: Cannot tolerate any packet loss - Ordering: Firmware must be received in correct order - Error recovery: Automatic retransmission - Security: TLS prevents malicious firmware injection

Power Impact: - TCP overhead acceptable for infrequent operation (once per month) - Device can stay awake during update (user-initiated)

NoteScenario 3: Video Surveillance (Mains-Powered)

Requirements: - 1080p video stream (2-4 Mbps) - Real-time display (< 200 ms latency) - Mains-powered (no battery concern) - Some frame loss acceptable

Protocol Selection: UDP (with RTP/RTSP)

Reasoning: - Low latency: No retransmission delays - Real-time: Predictable latency - Bandwidth: High bitrate requires efficient protocol - Loss tolerable: Missing frame causes brief artifact, not fatal - TCP would cause: Buffering, variable latency (unacceptable for live video)

Security: Can add DTLS/SRTP if needed

NoteScenario 4: Smart Lock (Battery-Powered, Critical)

Requirements: - Lock/unlock commands - Must be 100% reliable (security critical) - Battery-powered - Low latency desired (user waiting)

Protocol Selection: UDP + DTLS (with CoAP confirmable)

Reasoning: - Security: DTLS encryption + authentication (prevent spoofing) - Reliability: CoAP confirmable messages (application-level ACK) - Power: UDP more efficient than TCP - Compromise: Slightly higher overhead than plain UDP, but necessary for security

Why not TCP + TLS? - TCP adds connection overhead (3-way handshake) - TLS handshake is heavy - UDP + DTLS with session resumption more efficient

751.4 Hands-On Lab: Protocol Selection Analysis

NoteLab Activity: Calculate Overhead and Power Consumption

Objective: Compare TCP vs UDP overhead and power impact for IoT sensor

Scenario: Temperature sensor sending 10-byte readings

Device: nRF52840 - TX current: 5 mA - RX current: 5 mA - Sleep current: 5 µA - Data rate: 250 kbps (802.15.4)

751.4.1 Task 1: Calculate Packet Overhead

Payload: 10 bytes (temperature + humidity + battery)

Calculate total packet size for: 1. UDP/IPv6 2. TCP/IPv6

Assume: - IPv6 header: 40 bytes (uncompressed) or 6 bytes (6LoWPAN compressed) - Use compressed headers

Click to see solution

UDP Packet:

IPv6 header (compressed): 6 bytes
UDP header: 8 bytes
Payload: 10 bytes
Total: 24 bytes

Overhead: 14 bytes / 24 bytes = 58% overhead
Efficiency: 10 bytes / 24 bytes = 42% efficiency

TCP Packet (data transmission):

IPv6 header (compressed): 6 bytes
TCP header (minimum): 20 bytes
Payload: 10 bytes
Total: 36 bytes

Overhead: 26 bytes / 36 bytes = 72% overhead
Efficiency: 10 bytes / 36 bytes = 28% efficiency

TCP Handshake (before data):

SYN: 6 (IPv6) + 20 (TCP) = 26 bytes
SYN-ACK: 26 bytes
ACK: 26 bytes
Total handshake: 78 bytes

TCP Data + ACK:

Data: 36 bytes (as calculated above)
ACK: 6 (IPv6) + 20 (TCP) = 26 bytes
Total: 62 bytes

TCP Connection Teardown:

FIN: 26 bytes
ACK: 26 bytes
FIN: 26 bytes
ACK: 26 bytes
Total teardown: 104 bytes

Total TCP (one reading):

Handshake: 78 bytes
Data + ACK: 62 bytes
Teardown: 104 bytes
Total: 244 bytes

Comparison: - UDP: 24 bytes total - TCP: 244 bytes total (10× more!)

If TCP connection kept open (multiple readings): - Handshake: 78 bytes (once) - Per reading: 62 bytes (data + ACK) - Much better, but still 2.6× overhead vs UDP

751.4.2 Task 2: Calculate Radio On Time

Using packet sizes from Task 1, calculate radio on time:

Data rate: 250 kbps = 31.25 KB/s

Calculate: 1. TX time for UDP packet 2. TX time for TCP (connection + data + teardown) 3. TX time for TCP (keep-alive, per reading)

Click to see solution

UDP (24 bytes):

TX time = 24 bytes / 31.25 KB/s
        = 24 / 31,250 bytes/s
        = 0.768 ms

Total radio on: ~1 ms (including processing)

TCP (full connection, 244 bytes):

TX time = 244 bytes / 31.25 KB/s
        = 244 / 31,250
        = 7.8 ms

RX time (waiting for ACKs): ~5 ms

Total radio on: ~13 ms (TX + RX + processing)

TCP (keep-alive, 62 bytes per reading):

TX+RX time = 62 bytes / 31.25 KB/s
           = 2 ms

Total radio on: ~3 ms per reading
Comparison: - UDP: 1 ms - TCP (full): 13 ms (13× longer) - TCP (keep-alive): 3 ms (3× longer)

751.4.3 Task 3: Calculate Power Consumption

Sensor reports every 5 minutes. Calculate daily power consumption.

Assumptions: - Radio TX/RX: 5 mA - Sleep: 5 µA - Readings per day: 24 × 60 / 5 = 288

Click to see solution

UDP:

Active time per reading: 1 ms
Active time per day: 288 × 1 ms = 288 ms = 0.288 s

Active power: 5 mA × 0.288 s = 1.44 mA·s = 0.4 µA·h
Sleep power: 5 µA × (86,400 - 0.288) s / 3600 = 119.99 µA·h

Total per day: 0.4 + 120 = 120.4 µA·h = 0.12 mA·h

TCP (full connection per reading):

Active time per reading: 13 ms
Active time per day: 288 × 13 ms = 3.744 s

Active power: 5 mA × 3.744 s = 18.72 mA·s = 5.2 µA·h
Sleep power: 5 µA × (86,400 - 3.744) s / 3600 = 119.97 µA·h

Total per day: 5.2 + 120 = 125.2 µA·h = 0.125 mA·h

TCP (keep-alive):

Active time per reading: 3 ms
Active time per day: 288 × 3 ms = 864 ms = 0.864 s

Active power: 5 mA × 0.864 s = 4.32 mA·s = 1.2 µA·h
Sleep power: 5 µA × (86,400 - 0.864) s / 3600 = 119.99 µA·h

Total per day: 1.2 + 120 = 121.2 µA·h = 0.121 mA·h

Battery Life (2000 mAh battery): - UDP: 2000 / 0.12 = 16,667 days = 45.7 years (limited by self-discharge) - TCP (full): 2000 / 0.125 = 16,000 days = 43.8 years (similar, limited by self-discharge) - TCP (keep-alive): 2000 / 0.121 = 16,529 days = 45.3 years

Analysis: For this scenario (infrequent transmission, small payload), sleep current dominates. Radio on time is < 0.01% of day, so protocol overhead has minimal impact on battery life.

However: If transmitting every 10 seconds (864 times per day): - UDP: 864 ms/day active → 0.36 mA·h/day → 5,556 days = 15 years - TCP (full): 11.2 s/day active → 15.6 mA·h/day → 128 days = 4 months ❌ - TCP (keep-alive): 2.6 s/day active → 3.6 mA·h/day → 556 days = 1.5 years

Conclusion: Protocol choice significantly impacts battery life for frequent transmissions.

751.6 Protocol Trade-off Analysis

Understanding the key trade-offs between transport protocols helps you make informed decisions for IoT deployments.

WarningTradeoff: Reliable Delivery vs Low Latency

Option A (TCP Reliable Delivery): Guarantees packet delivery through acknowledgments and retransmissions. Adds 1-3 RTT latency (50-300ms on typical IoT networks) for connection setup. Retransmission timeout (RTO) starts at 1 second, doubles on each retry. Total overhead: 244 bytes for single 10-byte sensor reading (handshake + data + teardown).

Option B (UDP Best-Effort): Zero connection latency, immediate transmission. Single packet overhead: 8-byte header + payload = 18 bytes for 10-byte reading. Average latency: 1-5ms on local networks. Packet loss rate depends on network: 0.1-1% on Wi-Fi, 5-30% on lossy wireless sensor networks.

Decision Factors: Choose TCP when data loss is unacceptable (firmware updates, financial transactions, actuator commands) and latency tolerance exceeds 100ms. Choose UDP when fresh data arrives frequently (sensor telemetry every 5-60 seconds) and occasional loss is acceptable. For critical IoT alerts over UDP, add application-layer reliability with CoAP Confirmable messages (2s initial timeout, exponential backoff).

WarningTradeoff: Connection State vs Connectionless Simplicity

Option A (TCP Connection State): Maintains per-connection state: sequence numbers, acknowledgment tracking, congestion window, receive buffer. Memory cost: 280-500 bytes per connection on constrained devices. Connection timeout: 2-4 minutes idle before TCP keepalive triggers. Maximum connections limited by device RAM (e.g., ESP8266: 5-8 concurrent TCP connections).

Option B (UDP Connectionless): Zero connection state, zero memory per “connection.” Each datagram independent: source/destination ports, length, checksum only. Supports unlimited concurrent communication partners. Memory footprint: single 8-byte header structure reused for all transmissions.

Decision Factors: Choose TCP when you need long-lived bidirectional communication (persistent MQTT connections, command channels). Choose UDP when devices communicate with many endpoints (multicast sensor networks), have severe memory constraints (<10KB RAM), or need to support hundreds of simultaneous peers. For battery devices sleeping between transmissions, UDP avoids connection re-establishment overhead on each wake cycle.

751.7 Summary

  • Protocol selection frameworks use decision trees based on data loss tolerance, real-time requirements, security needs, and power constraints
  • Temperature sensors (battery-powered, periodic data) work best with UDP + CoAP for minimal overhead and maximum battery life
  • Firmware updates (critical reliability) require TCP + TLS despite higher overhead due to zero-tolerance for packet loss or corruption
  • Smart locks (security-critical, real-time) benefit from UDP + DTLS with CoAP confirmable messages balancing security, reliability, and power efficiency
  • Packet overhead calculations reveal UDP uses 24 bytes total vs TCP’s 244 bytes for complete connection lifecycle - 10× difference for single transmission
  • Radio-on time directly impacts battery life - UDP 1ms vs TCP full connection 13ms affects daily energy consumption significantly
  • Transmission frequency determines protocol impact - infrequent transmissions (every 5 min) minimize protocol overhead importance, frequent transmissions (every 10 sec) make TCP consume 4× more battery than UDP

751.7.1 Real-World Case Study: Smart Agriculture Deployment

Deployment: 500-acre farm with 200 soil moisture sensors

Initial Design (Failed): - Protocol: TCP + MQTT - Battery Life: 4.2 months (target: 12 months) - Operational Cost: $12,000/year battery replacements - Problem: TCP overhead drained batteries in high-loss RF environment (20% packet loss from barn interference)

Redesigned System: - Protocol: UDP + CoAP Confirmable - Battery Life: 18 months (50% above target) - Operational Cost: $2,800/year replacements - Reliability: 98.5% packet delivery (application-layer retry with exponential backoff)

Measured Improvements: - Radio Time: 13ms → 2ms per reading (6.5× reduction) - Retransmissions: TCP storm (5-10 retries) → CoAP selective (1-2 retries) - Battery Cost Savings: $9,200/year (77% reduction) - Network Congestion: 85% → 12% (TCP retransmissions eliminated)

Key Lesson: In high-loss networks, TCP’s reliability mechanisms become the problem—application-layer selective retry (CoAP CON) outperforms TCP’s blind retry-everything approach for periodic telemetry.

751.8 Knowledge Check

Question: For a battery-powered sensor sending small updates every hour, which transport approach is most appropriate?

💡 Explanation: B. UDP avoids long-lived connection state; application-layer reliability can be enabled only when needed, saving energy during long sleep intervals.

Question: When is TCP typically preferred over UDP in IoT systems?

💡 Explanation: B. TCP’s ordered delivery and retransmissions are valuable when correctness matters more than latency and overhead.

Question: What makes CoAP over UDP suitable for constrained IoT networks?

💡 Explanation: B. CoAP is designed for constrained nodes and lets you choose reliability per message instead of paying TCP costs all the time.

Question: Which protocol is commonly used to secure UDP traffic (similar to how TLS secures TCP)?

💡 Explanation: C. DTLS provides TLS-like security properties over UDP.

For a battery-powered sensor sending small updates every hour, which transport is most appropriate?

Options: - A) TCP with keep-alive - B) UDP with application-level acknowledgment - C) WebSocket - D) HTTP/2

Correct: B) UDP with application-level acknowledgment

UDP’s lower overhead conserves battery. Application-level ACKs provide reliability without TCP’s connection maintenance overhead during long sleep periods.

When is TCP preferred over UDP in IoT scenarios?

Options: - A) Real-time sensor streaming - B) Command and control messages requiring guaranteed delivery - C) Broadcast announcements - D) Time-sensitive telemetry

Correct: B) Command and control messages requiring guaranteed delivery

TCP’s reliable, ordered delivery is essential when commands must be executed exactly once, such as actuator control or configuration updates.

What makes CoAP over UDP suitable for constrained IoT networks?

Options: - A) Built-in encryption - B) Smaller message overhead and optional reliability - C) Faster than HTTP - D) Better security than MQTT

Correct: B) Smaller message overhead and optional reliability

CoAP uses compact binary headers and offers confirmable (reliable) or non-confirmable (best-effort) messages, letting developers choose the right trade-off.

751.9 What’s Next

Build on your transport protocol selection knowledge: