737  Transport Protocol Selection for IoT Scenarios

NoteLearning Objectives

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

  • Select appropriate transport protocols for different IoT scenarios
  • Apply decision criteria based on reliability, latency, power, and security needs
  • Analyze real-world IoT scenarios and justify protocol choices
  • Calculate overhead and power consumption for protocol comparison

737.1 Prerequisites

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

NoteKey Takeaway

In one sentence: Protocol selection depends on your specific requirements - thereโ€™s no universal โ€œbestโ€ protocol.

Remember this: Ask three questions: (1) Can I tolerate loss? (2) Am I battery-powered? (3) Do I transmit frequently? The answers guide your choice.

Prerequisites: - Transport Protocol Fundamentals - TCP/UDP basics - DTLS Security - Securing UDP

Deep Dives: - Transport Protocols Overview - Index page - TCP Optimizations - Making TCP efficient - Decision Framework - Detailed decision matrices

737.2 Protocol Selection Decision Tree

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','background':'#ffffff','mainBkg':'#2C3E50','secondBkg':'#16A085','tertiaryBorderColor':'#95a5a6','clusterBkg':'#ecf0f1','clusterBorder':'#95a5a6','titleColor':'#2C3E50','edgeLabelBackground':'#ffffff','nodeTextColor':'#2C3E50'}}}%%
graph TD
    Start{IoT Application} --> Q1{Reliability<br/>Critical?}

    Q1 -->|Yes| Q2{Real-time<br/>Required?}
    Q1 -->|No| Q3{Security<br/>Needed?}

    Q2 -->|Yes| SCTP[Consider SCTP<br/>or UDP+App-layer]
    Q2 -->|No| Q4{Security<br/>Needed?}

    Q4 -->|Yes| TLS[TCP + TLS<br/>Firmware Updates]
    Q4 -->|No| TCP[Plain TCP<br/>Configuration]

    Q3 -->|Yes| DTLS[UDP + DTLS<br/>CoAPS]
    Q3 -->|No| UDP[Plain UDP<br/>CoAP/Telemetry]

    SCTP -->|Example| E1[VoIP, Streaming]
    TLS -->|Example| E2[OTA Updates]
    TCP -->|Example| E3[MQTT]
    DTLS -->|Example| E4[Secure Sensors]
    UDP -->|Example| E5[Temp Readings]

    style Q1 fill:#E67E22,stroke:#16A085,color:#fff
    style Q2 fill:#E67E22,stroke:#16A085,color:#fff
    style Q3 fill:#E67E22,stroke:#16A085,color:#fff
    style Q4 fill:#E67E22,stroke:#16A085,color:#fff
    style SCTP fill:#9b59b6,stroke:#8e44ad,color:#fff
    style TLS fill:#2C3E50,stroke:#16A085,color:#fff
    style TCP fill:#2C3E50,stroke:#16A085,color:#fff
    style DTLS fill:#16A085,stroke:#2C3E50,color:#fff
    style UDP fill:#16A085,stroke:#2C3E50,color:#fff
    style E1 fill:#95a5a6,stroke:#7f8c8d,color:#fff
    style E2 fill:#95a5a6,stroke:#7f8c8d,color:#fff
    style E3 fill:#95a5a6,stroke:#7f8c8d,color:#fff
    style E4 fill:#95a5a6,stroke:#7f8c8d,color:#fff
    style E5 fill:#95a5a6,stroke:#7f8c8d,color:#fff

Figure 737.1: Transport protocol selection decision tree based on reliability, real-time, and security requirements
Decision tree for selecting transport protocol based on reliability, real-time, and security requirements

This variant presents the transport protocol selection through a decision-tree lens - useful for engineers choosing between TCP and UDP based on specific IoT application requirements.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D', 'fontSize': '11px'}}}%%
flowchart TD
    START["IoT Transport<br/>Protocol Selection"]

    Q1{"Data loss<br/>acceptable?"}
    Q2{"Latency<br/>critical?<br/>(<50ms)"}
    Q3{"Transmission<br/>frequency?"}
    Q4{"Need multicast/<br/>broadcast?"}
    Q5{"Reliable<br/>delivery<br/>required?"}

    UDP["Use UDP<br/>--------<br/>8-byte header<br/>No connection state<br/>Best for: CoAP,<br/>real-time sensors,<br/>video streaming"]

    TCP["Use TCP<br/>--------<br/>20-byte header<br/>Connection state<br/>Best for: MQTT,<br/>firmware updates,<br/>critical commands"]

    COAP["Use CoAP + UDP<br/>--------<br/>Application-level<br/>reliability with<br/>CON messages"]

    START --> Q1
    Q1 -->|"Yes<br/>(sensors, telemetry)"| Q2
    Q1 -->|"No<br/>(commands, files)"| Q5

    Q2 -->|"Yes"| UDP
    Q2 -->|"No"| Q3

    Q3 -->|"High<br/>(>1/10s)"| UDP
    Q3 -->|"Low<br/>(<1/min)"| Q4

    Q4 -->|"Yes"| UDP
    Q4 -->|"No"| COAP

    Q5 -->|"Yes"| TCP
    Q5 -->|"No"| COAP

    style START fill:#2C3E50,stroke:#16A085,color:#fff
    style Q1 fill:#16A085,stroke:#2C3E50,color:#fff
    style Q2 fill:#16A085,stroke:#2C3E50,color:#fff
    style Q3 fill:#16A085,stroke:#2C3E50,color:#fff
    style Q4 fill:#16A085,stroke:#2C3E50,color:#fff
    style Q5 fill:#16A085,stroke:#2C3E50,color:#fff
    style UDP fill:#E67E22,stroke:#2C3E50,color:#fff
    style TCP fill:#E67E22,stroke:#2C3E50,color:#fff
    style COAP fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 737.2: Decision flowchart for selecting TCP, UDP, or CoAP based on IoT application requirements

737.3 Selection Criteria

ImportantDecision Guide

Use TCP when: - Reliability is critical: Firmware updates, configuration - Data must be ordered: Sequential commands, file transfers - Data loss unacceptable: Financial transactions, critical commands - Network is reliable: Wired connections, stable Wi-Fi - Power not a constraint: Mains-powered devices

Use UDP when: - Low latency required: Real-time monitoring, video streaming - Periodic data: Sensor readings every N seconds - Data loss tolerable: Occasional reading loss OK - Broadcast/multicast needed: One-to-many communication - Power constrained: Battery-powered sensors - Overhead matters: 6LoWPAN, constrained networks

Consider hybrid approach: - UDP for telemetry (sensor data) - TCP for critical ops (firmware, config) - Application-level reliability on UDP (CoAP confirmable messages)

737.4 Example Scenarios

737.4.1 Scenario 1: Temperature Sensor (Battery-Powered)

NoteAnalysis

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) - 5x power savings with UDP

737.4.2 Scenario 2: Firmware Update (Battery or Mains)

NoteAnalysis

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)

737.4.3 Scenario 3: Video Surveillance (Mains-Powered)

NoteAnalysis

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

737.4.4 Scenario 4: Smart Lock (Battery-Powered, Critical)

NoteAnalysis

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

737.5 Overhead Calculation Lab

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 uA - Data rate: 250 kbps (802.15.4)

737.5.1 Task 1: Calculate Packet Overhead

Payload: 10 bytes (temperature + humidity + battery)

Assumptions: - 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 (10x more!)

737.5.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

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)
Comparison: - UDP: 1 ms - TCP (full): 13 ms (13x longer)

737.5.3 Task 3: Calculate Battery Life

Sensor reports every 5 minutes. Calculate battery life.

Assumptions: - Radio TX/RX: 5 mA - Sleep: 5 uA - Battery: 2000 mAh - Readings per day: 288

Click to see solution

UDP:

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

Active power: 5 mA x 0.288 s = 1.44 mA-s = 0.4 uA-h
Sleep power: 5 uA x (86,400 - 0.288) s / 3600 = 119.99 uA-h

Total per day: 0.4 + 120 = 120.4 uA-h = 0.12 mA-h

Battery life: 2000 mAh / 0.12 mAh/day = 16,667 days = 45.7 years

TCP (full connection per reading):

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

Active power: 5 mA x 3.744 s = 18.72 mA-s = 5.2 uA-h
Sleep power: 5 uA x (86,400 - 3.744) s / 3600 = 119.97 uA-h

Total per day: 5.2 + 120 = 125.2 uA-h = 0.125 mA-h

Battery life: 2000 mAh / 0.125 mAh/day = 16,000 days = 43.8 years

Key Insight: For infrequent transmission (every 5 min), sleep current dominates. Protocol overhead has minimal impact.

However, at 10-second intervals: - UDP: 45.5 years - TCP (full): 8.6 years - Difference: 81% reduction

Protocol choice significantly impacts battery life for frequent transmissions.

737.6 Protocol Selection Quiz

Youโ€™re designing four different IoT systems. For each system, select the most appropriate transport protocol (UDP, TCP, UDP+DTLS, TCP+TLS) and justify your choice.

System A: Smart door lock - Battery-powered (2x AA, must last 1 year) - Lock/unlock commands (must be 100% reliable) - Security critical (prevent unauthorized access) - Latency: Interactive (<200 ms) - Frequency: ~10 operations per day

System B: Industrial sensor network - 200 temperature/vibration sensors - Wired Ethernet (power available) - Reports every 1 second - Reliability: Some loss tolerable (0.1% OK) - No security requirement (internal network)

System C: Firmware update service - Over-the-air updates for IoT devices - 500 KB firmware images - Must be 100% reliable (corruption = bricked device) - Security: Prevent malicious firmware - Frequency: Monthly updates

System D: Video surveillance camera - 1080p stream (2-4 Mbps) - Mains-powered - Real-time display required (<100 ms latency) - Security: Encrypt video stream - Some frame loss acceptable

Click to reveal answer

Answer: A->UDP+DTLS, B->UDP, C->TCP+TLS, D->UDP+DTLS

System A: Smart Door Lock -> UDP + DTLS + CoAP Confirmable - DTLS provides encryption and authentication - UDP more power-efficient than TCP for infrequent operations - CoAP Confirmable provides reliability at application layer - Session resumption reduces handshake overhead

System B: Industrial Sensor Network -> UDP (plain) - 0.1% loss acceptable for monitoring - 200 sensors at 1 Hz = 200 msg/sec (TCP connection overhead wasteful) - Wired Ethernet = reliable medium - Internal network = no security requirement - Consistent latency for real-time monitoring

System C: Firmware Update Service -> TCP + TLS - 100% reliability required (corrupted firmware bricks device) - TCP provides automatic segmentation, ordering, retransmission - TLS prevents malicious firmware injection - Monthly updates = TCP overhead acceptable

System D: Video Surveillance Camera -> UDP + DTLS - Real-time <100ms latency = UDP (no retransmission delays) - Frame loss acceptable (minor glitches OK) - DTLS encrypts video stream - TCP head-of-line blocking would cause buffering

Question: A sensor sends critical alarm events that must arrive even if some packets are lost. You need ordered delivery but canโ€™t afford TCPโ€™s overhead. What solution?

Explanation: Application-layer reliability over UDP balances efficiency with guarantees:

CoAP Confirmable (CON) messages provide: - Send: Alarm with Message ID, wait for ACK - Timeout: Retransmit with exponential backoff (2s, 4s, 8s) - ACK received: Move to next alarm - Deduplication: Receiver tracks processed IDs, ignores duplicates

Comparison: | Approach | Packets | State | Energy | Reliability | |โ€”โ€”โ€”-|โ€”โ€”โ€”|โ€”โ€”-|โ€”โ€”โ€“|โ€”โ€”โ€”โ€”-| | UDP plain | 1 | None | 1x | ~70% (30% loss) | | UDP + 5x repeat | 5 | None | 5x | ~99.9% | | TCP | 8+ | Yes | 8x | 100% | | UDP + CoAP CON | 1-3 | Minimal | 1.5x | ~99.5% |

CoAP achieves near-TCP reliability with 20% of TCPโ€™s energy cost.

737.7 Summary

TipKey Takeaways

Selection Criteria: 1. Reliability: TCP if critical, UDP if tolerable loss 2. Latency: UDP for real-time, TCP if not time-sensitive 3. Power: UDP more efficient (no connection state, ACKs) 4. Security: DTLS for UDP, TLS for TCP 5. Overhead: UDP 8 bytes, TCP 20-60 bytes 6. Application: CoAP (UDP), MQTT (TCP)

The 3-Question Framework: 1. Can I tolerate loss? YES = UDP, NO = TCP or UDP+App-Layer ACK 2. Am I battery-powered? YES = prefer UDP, NO = either works 3. Do I transmit frequently? YES = UDP critical, NO = TCP acceptable

Common Patterns: - Telemetry: UDP + CoAP NON (non-confirmable) - Commands: UDP + CoAP CON or TCP - Firmware: TCP + TLS - Video: UDP + RTP

737.8 Whatโ€™s Next?

Continue to TCP Optimizations and Implementation to learn techniques for making TCP more efficient in constrained IoT environments.