7  Transport Layer Protocols for IoT

In 60 Seconds

This chapter series covers transport layer protocols for IoT: TCP provides reliable, ordered delivery at the cost of 20-60 byte headers and connection overhead; UDP offers minimal 8-byte headers with no delivery guarantees; and DTLS secures UDP for protocols like CoAP. For battery-powered sensors sending small payloads, UDP typically reduces data overhead by 5x or more compared to short-lived TCP connections. The series includes selection frameworks, optimization techniques, and DTLS security analysis.

Key Concepts

• Layer 4 in IoT Stack: Transport layer sits between network layer (IP addressing, routing) and application layer (MQTT, CoAP, HTTP); provides communication channel for application protocols
• IoT Protocol Landscape: Physical → Data Link → Network (IP) → Transport (TCP/UDP) → Application (MQTT, CoAP, HTTP, AMQP); each layer has IoT-specific optimizations
• Constrained Device Protocol Stack: 8-bit MCU (1 KB RAM): UDP only + custom app; 32-bit MCU (64 KB RAM): UDP + CoAP + DTLS; Cortex-A (512 MB RAM): full TCP + TLS + MQTT/HTTP
• IPv6 for IoT: IoT requires IPv6 for address space (NAT-breaking for direct device addressability); 6LoWPAN compresses IPv6 headers to 6–7 bytes for IEEE 802.15.4; critical for Internet of Things (not Intranet of Things)
• Transport Protocol Overhead in IoT Context: Typical IoT payload: 20–50 bytes; UDP header: 8 bytes (16–40% overhead); TCP header: 20 bytes (40–100% overhead); minimize overhead especially on metered cellular connections
• LPWAN Transport Considerations: LoRaWAN: application layer only (no TCP/UDP — LoRa PHY + MAC); NB-IoT/LTE-M: full IP stack, TCP or UDP; Sigfox: 12-byte uplink, no IP at device
• Connection State Management: TCP maintains connection state (sequence numbers, window, retransmission queue) requiring ~4–8 KB per connection on server; UDP is stateless; relevant for high-density IoT servers handling 100K+ devices
• Transport in MQTT Architecture: MQTT broker manages TCP connections from thousands of devices simultaneously; efficient TCP connection pooling essential for broker performance at scale

Learning Objectives

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

• Identify the role of transport layer protocols in the IoT networking stack and classify each protocol by its delivery guarantees
• Compare TCP and UDP characteristics and use cases, distinguishing their header structures, connection models, and reliability mechanisms
• Explain why UDP is preferred for many IoT applications and justify this choice using quantified overhead calculations
• Apply DTLS (Datagram Transport Layer Security) concepts to design secure UDP-based IoT communication systems
• Analyze trade-offs between reliability, overhead, and power consumption to evaluate protocol fitness for constrained devices
• Select the appropriate transport protocol for different IoT scenarios by applying a structured decision framework
• Assess TCP optimization techniques for constrained networks and determine when to apply keep-alive, Fast Open, or QUIC instead

For Beginners: Transport Layer Protocols

The transport layer is like the delivery service of the internet. It takes data from an application, packages it up, and makes sure it gets to the right application on the other end. Different transport protocols offer different guarantees – some promise every package arrives (TCP), while others prioritize speed over certainty (UDP).

Sensor Squad: Choosing Your Delivery Service!

“The transport layer is all about how we deliver our data,” said Sammy the Sensor. “Do we use registered mail with tracking, or do we just drop a postcard in the mailbox and hope for the best?”

“TCP is like registered mail,” explained Max the Microcontroller. “It sets up a connection with a three-way handshake, numbers every packet, gets acknowledgments, and retransmits anything that gets lost. Super reliable, but all that overhead means bigger headers and more battery drain.”

“UDP is like the postcard,” added Lila the LED. “Just 8 bytes of header, no connection setup, no acknowledgments. Fire and forget! If a temperature reading gets lost, who cares – another one is coming in 30 seconds anyway.”

“For battery-powered sensors like me, UDP is a lifesaver,” said Bella the Battery. “TCP uses about 5 times more energy for small payloads because of all those handshakes and acknowledgments. With UDP, I can last much longer on a single charge. DTLS adds encryption to UDP when we need security without TCP’s weight.”

7.1 Prerequisites

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

• Layered Network Models: Understanding the OSI and TCP/IP protocol stack is essential since transport protocols (Layer 4) sit between application protocols and network routing, managing end-to-end communication
• Networking Basics: Knowledge of fundamental networking concepts including packets, headers, ports, addressing, and basic data transmission provides the foundation for understanding transport protocol operation
• IoT device constraints: Familiarity with power consumption, memory limitations, and bandwidth constraints of IoT sensors helps you appreciate why choosing between TCP and UDP significantly impacts battery life and network efficiency

Key Takeaway

In one sentence: TCP guarantees delivery but adds latency and power cost; UDP is fast but unreliable – choose based on whether you can tolerate lost data.

Remember this: Use the 3-question framework: (1) Can I tolerate loss? (2) Am I battery-powered? (3) Do I transmit frequently? If the answer to all three is yes, UDP is almost always the right choice. If reliability is critical and power is not a concern, TCP provides the strongest guarantees.

7.2 Chapter Overview

This comprehensive guide to transport layer protocols for IoT has been organized into focused chapters for easier learning. Each chapter builds on the previous, taking you from fundamentals to practical decision-making.

Figure 7.1: Transport protocol learning path from fundamentals to practical decision-making

7.3 Chapter Guide

7.3.1 1. Transport Protocol Fundamentals

Transport Protocol Fundamentals covers the core concepts of TCP and UDP:

• Introduction to transport layer protocols
• UDP characteristics, header structure, and IoT use cases
• TCP characteristics, 3-way handshake, and reliability mechanisms
• Side-by-side comparison of TCP vs UDP
• Energy and overhead analysis

Best for: Understanding the basics of how transport protocols work and their fundamental trade-offs.

7.3.2 2. DTLS Security for UDP

DTLS Security explains how to secure UDP communications:

• Why DTLS exists (TLS for UDP)
• DTLS handshake and cookie mechanism
• Replay protection with sequence numbers
• Session resumption for energy efficiency
• PSK vs certificate-based authentication
• Trade-offs between TLS/TCP and DTLS/UDP

Best for: Understanding how to add security to UDP-based IoT applications without TCP overhead.

7.3.3 3. Protocol Selection for IoT Scenarios

Protocol Selection helps you choose the right protocol:

• Decision tree for protocol selection
• Selection criteria based on reliability, latency, power, and security
• Real-world scenario analysis (sensors, locks, video, firmware)
• Hands-on overhead calculation lab
• Protocol selection quizzes

Best for: Applying knowledge to make informed protocol decisions for specific IoT use cases.

7.3.4 4. TCP Optimizations and QUIC

TCP Optimizations covers advanced topics:

• TCP keep-alive for connection reuse
• TCP Fast Open (TFO) for reduced latency
• Lightweight TCP implementations (uIP, lwIP)
• QUIC protocol deep dive (0-RTT, no head-of-line blocking)
• When to optimize TCP vs switch to UDP

Best for: Making TCP work better in constrained environments, or understanding modern alternatives like QUIC.

7.3.5 5. Decision Framework and Pitfalls

Decision Framework provides comprehensive guidance:

• Quick decision tree for protocol selection
• Detailed scenario-based comparison tables
• TCP vs UDP trade-off matrix
• Hybrid approaches (UDP+ACK, FEC, QUIC)
• Common pitfalls and how to avoid them
• Comprehensive knowledge check quizzes

Best for: Final reference for making protocol decisions and avoiding common mistakes.

7.4 Quick Reference

7.4.1 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

Putting Numbers to It

For a network of 1000 sensors, each sending 50-byte readings every 5 minutes over cellular (3% packet loss), compare total monthly data costs.

UDP per reading: \[ \text{Size} = 50 + 8 \text{ (UDP)} + 20 \text{ (IP)} = 78 \text{ bytes} \]

With 3% loss requiring retries: \[ \text{Effective} = 78 \times 1.03 = 80.3 \text{ bytes per reading} \]

TCP per reading (short-lived connection): \[ \text{Handshake (SYN + SYN-ACK + ACK with options)} = 180 \text{ bytes} \] \[ \text{Data} = 50 + 20 \text{ (TCP)} + 20 \text{ (IP)} + 40 \text{ (ACK)} = 130 \text{ bytes} \] \[ \text{Teardown (FIN/ACK exchange)} = 120 \text{ bytes} \] \[ \text{Total} = 430 \text{ bytes per reading} \]

Monthly data (1000 sensors, 8,640 readings/sensor/month):

UDP: \(1000 \times 8{,}640 \times 80.3 = 694 \text{ MB}\)

TCP: \(1000 \times 8{,}640 \times 430 = 3{,}715 \text{ MB}\)

Cost at $5 per GB cellular:

UDP: \(694 / 1000 \times \$5 = \$3.47\) per month

TCP: \(3715 / 1000 \times \$5 = \$18.58\) per month

Annual savings with UDP: $(18.58 - 3.47) = $181.32$ for 1000 sensors, showing how protocol choice directly impacts operational costs at scale.

7.4.2 Interactive: Protocol Overhead Cost Calculator

Adjust the parameters below to compare UDP vs TCP monthly data costs for your IoT deployment.

viewof numSensors = Inputs.range([10, 10000], {value: 1000, step: 10, label: "Number of sensors"})
viewof payloadBytes = Inputs.range([1, 500], {value: 50, step: 1, label: "Payload size (bytes)"})
viewof readingsPerHour = Inputs.range([1, 60], {value: 12, step: 1, label: "Readings per hour"})
viewof packetLoss = Inputs.range([0, 20], {value: 3, step: 0.5, label: "Packet loss (%)"})
viewof costPerGB = Inputs.range([0.5, 20], {value: 5, step: 0.5, label: "Cost per GB ($)"})

{
  const udpHeader = 8;
  const tcpHeader = 20;
  const ipHeader = 20;
  const tcpHandshake = 180;
  const tcpTeardown = 120;
  const tcpAck = 40;

  const udpPerReading = (payloadBytes + udpHeader + ipHeader) * (1 + packetLoss / 100);
  const tcpPerReading = tcpHandshake + (payloadBytes + tcpHeader + ipHeader + tcpAck) + tcpTeardown;

  const readingsPerMonth = readingsPerHour * 24 * 30;
  const udpMonthlyMB = (numSensors * readingsPerMonth * udpPerReading) / 1e6;
  const tcpMonthlyMB = (numSensors * readingsPerMonth * tcpPerReading) / 1e6;

  const udpMonthlyCost = (udpMonthlyMB / 1000) * costPerGB;
  const tcpMonthlyCost = (tcpMonthlyMB / 1000) * costPerGB;
  const annualSavings = (tcpMonthlyCost - udpMonthlyCost) * 12;

  const maxMB = Math.max(udpMonthlyMB, tcpMonthlyMB);
  const barWidth = 300;
  const udpBarW = (udpMonthlyMB / maxMB) * barWidth;
  const tcpBarW = (tcpMonthlyMB / maxMB) * barWidth;

  return html`<div style="font-family: Arial, sans-serif; background: #f8f9fa; border-radius: 8px; padding: 20px; border: 1px solid #dee2e6;">
    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 16px; margin-bottom: 16px;">
      <div style="background: white; padding: 12px; border-radius: 6px; border-left: 4px solid #16A085;">
        <div style="color: #7F8C8D; font-size: 12px;">UDP per reading</div>
        <div style="color: #2C3E50; font-size: 20px; font-weight: bold;">${udpPerReading.toFixed(1)} bytes</div>
      </div>
      <div style="background: white; padding: 12px; border-radius: 6px; border-left: 4px solid #E67E22;">
        <div style="color: #7F8C8D; font-size: 12px;">TCP per reading</div>
        <div style="color: #2C3E50; font-size: 20px; font-weight: bold;">${tcpPerReading.toFixed(0)} bytes</div>
      </div>
    </div>
    <div style="margin-bottom: 12px;">
      <div style="display: flex; align-items: center; margin-bottom: 6px;">
        <span style="width: 60px; font-size: 13px; color: #2C3E50; font-weight: bold;">UDP</span>
        <div style="background: #16A085; height: 24px; width: ${udpBarW}px; border-radius: 4px; margin-right: 8px;"></div>
        <span style="font-size: 13px; color: #2C3E50;">${udpMonthlyMB.toFixed(0)} MB/mo ($${udpMonthlyCost.toFixed(2)})</span>
      </div>
      <div style="display: flex; align-items: center;">
        <span style="width: 60px; font-size: 13px; color: #2C3E50; font-weight: bold;">TCP</span>
        <div style="background: #E67E22; height: 24px; width: ${tcpBarW}px; border-radius: 4px; margin-right: 8px;"></div>
        <span style="font-size: 13px; color: #2C3E50;">${tcpMonthlyMB.toFixed(0)} MB/mo ($${tcpMonthlyCost.toFixed(2)})</span>
      </div>
    </div>
    <div style="background: #2C3E50; color: white; padding: 10px; border-radius: 6px; text-align: center;">
      <strong>Annual savings with UDP: $${annualSavings.toFixed(2)}</strong> (${(tcpPerReading / udpPerReading).toFixed(1)}x overhead ratio)
    </div>
    <div style="font-size: 11px; color: #7F8C8D; margin-top: 8px;">
      ${readingsPerMonth.toLocaleString()} readings/sensor/month | TCP assumes short-lived connections (handshake + data + teardown per reading)
    </div>
  </div>`;
}

7.4.3 Protocol Comparison Summary

Feature	TCP	UDP
Connection	Connection-oriented	Connectionless
Reliability	Guaranteed delivery	Best-effort
Header Size	20-60 bytes	8 bytes
Power	Higher (state, ACKs)	Lower (stateless)
Best For	Firmware, config, MQTT	CoAP, telemetry, streaming

7.4.4 Common Use Cases

Scenario	Protocol	Reasoning
Temperature sensor	UDP + CoAP	Periodic data, loss tolerable
Door lock command	UDP + DTLS + CoAP CON	Security needed, app-layer reliability
Firmware update	TCP + TLS	100% reliability, security required
Video streaming	UDP + RTP	Real-time, loss tolerable

Check Your Understanding: The 3-Question Framework

7.5 Videos

Transport Fundamentals (Part 1)

Transport Fundamentals (Part 1)

Lesson 4 - UDP/TCP concepts that underpin CoAP and MQTT behavior.

Transport Fundamentals (Part 2)

Transport Fundamentals (Part 2)

Lesson 4 - reliability, congestion, and power trade-offs for IoT.

Cross-Hub Connections

Enhance your understanding of transport protocols with these learning resources:

• Simulations Hub: Try the Network Topology Explorer to visualize how TCP and UDP behave differently across various network architectures
• Videos Hub: Watch animated explanations of TCP handshakes, UDP packet flow, and DTLS security mechanisms
• Quizzes Hub: Test your protocol selection skills with interactive scenario-based questions
• Knowledge Gaps Hub: Clarify common misconceptions about transport overhead, reliability guarantees, and power consumption

These resources provide hands-on practice and visual learning to complement the theoretical concepts in this chapter.

7.6 Worked Example: Transport Protocol Assignment for a Smart City Traffic System

Scenario: A city deploys a traffic management system with four subsystems, each with different transport requirements. The system architect must assign transport protocols and justify each choice with quantified trade-offs.

Subsystem 1: Intersection traffic counters (2,000 units)

• Battery-powered inductive loop sensors
• Send 16-byte vehicle count every 60 seconds
• 3% packet loss acceptable (counts are averaged hourly)
• Battery target: 7 years on 2x AA lithium (6,000 mAh)

Protocol choice: UDP (plain, no CoAP)

Metric	UDP	TCP	Ratio
Bytes per transmission	16 + 8 (UDP) + 20 (IPv4) = 44	16 + 20 (TCP) + 20 (IPv4) = 56 + 162 (handshake/teardown) = 218	5x
TX time at 250 kbps (data only)	1.4 ms	7.0 ms	5x
Total radio active time (wake + TX + RX window)	~25 ms	~125 ms	5x
Energy per reading (80 mA active)	0.00056 mAh	0.0028 mAh	5x
Readings per day	1,440	1,440	-
Daily TX energy	0.80 mAh	4.0 mAh	5x

Battery life (TX only, ignoring sleep current): UDP = 6,000 / 0.80 = 7,500 days (~20 years). Adding sleep current at 10 uA: 10 uA * 24 h = 0.24 mAh/day, total = 1.04 mAh/day, giving 6,000 / 1.04 = 5,769 days (~16 years) – achievable with UDP.

TCP comparison: 6,000 / (4.0 + 0.24) = 1,415 days (~3.9 years) – falls well short of the 7-year target, confirming UDP is the only viable option at the transport layer.

Corrected calculation with LoRaWAN (SF7, 30 mA TX, 25 ms airtime):

Metric	UDP/LoRaWAN	TCP impossible
Energy per reading	0.000208 mAh	N/A (LoRaWAN is UDP-only)
Daily energy (TX)	0.30 mAh	-
Sleep energy (2 uA)	0.048 mAh	-
Battery life	6,000 / 0.35 = 17,143 days = 47 years	-

Transport layer overhead matters less than physical layer choice, but UDP is mandatory since LoRaWAN only supports UDP-like Class A uplinks.

Interactive: Battery Life Explorer

Adjust sensor parameters to see how transport protocol choice affects battery life.

viewof batteryCapacity = Inputs.range([500, 20000], {value: 6000, step: 100, label: "Battery capacity (mAh)"})
viewof txCurrent = Inputs.range([10, 200], {value: 80, step: 5, label: "TX current (mA)"})
viewof udpActiveTime = Inputs.range([1, 200], {value: 25, step: 1, label: "UDP radio active time (ms)"})
viewof tcpOverheadFactor = Inputs.range([2, 10], {value: 5, step: 0.5, label: "TCP overhead factor (x)"})
viewof readingInterval = Inputs.range([10, 3600], {value: 60, step: 10, label: "Reading interval (seconds)"})
viewof sleepCurrent = Inputs.range([1, 100], {value: 10, step: 1, label: "Sleep current (uA)"})

{
  const readingsDay = (24 * 3600) / readingInterval;
  const udpEnergyPerReading = (txCurrent * udpActiveTime) / 3600000; // mAh
  const tcpEnergyPerReading = udpEnergyPerReading * tcpOverheadFactor;
  const udpDailyTX = readingsDay * udpEnergyPerReading;
  const tcpDailyTX = readingsDay * tcpEnergyPerReading;
  const sleepDaily = (sleepCurrent / 1000) * 24; // mAh
  const udpTotalDaily = udpDailyTX + sleepDaily;
  const tcpTotalDaily = tcpDailyTX + sleepDaily;
  const udpLifeDays = batteryCapacity / udpTotalDaily;
  const tcpLifeDays = batteryCapacity / tcpTotalDaily;
  const udpLifeYears = udpLifeDays / 365;
  const tcpLifeYears = tcpLifeDays / 365;

  const maxDays = Math.max(udpLifeDays, tcpLifeDays, 1);
  const barW = 280;
  const udpBar = Math.min((udpLifeDays / maxDays) * barW, barW);
  const tcpBar = Math.min((tcpLifeDays / maxDays) * barW, barW);

  const targetMet = udpLifeYears >= 7;

  return html`<div style="font-family: Arial, sans-serif; background: #f8f9fa; border-radius: 8px; padding: 20px; border: 1px solid #dee2e6;">
    <div style="display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 12px; margin-bottom: 16px;">
      <div style="background: white; padding: 10px; border-radius: 6px; border-left: 4px solid #3498DB;">
        <div style="color: #7F8C8D; font-size: 11px;">Readings/day</div>
        <div style="color: #2C3E50; font-size: 18px; font-weight: bold;">${readingsDay.toLocaleString()}</div>
      </div>
      <div style="background: white; padding: 10px; border-radius: 6px; border-left: 4px solid #16A085;">
        <div style="color: #7F8C8D; font-size: 11px;">UDP daily energy</div>
        <div style="color: #2C3E50; font-size: 18px; font-weight: bold;">${udpTotalDaily.toFixed(2)} mAh</div>
      </div>
      <div style="background: white; padding: 10px; border-radius: 6px; border-left: 4px solid #E67E22;">
        <div style="color: #7F8C8D; font-size: 11px;">TCP daily energy</div>
        <div style="color: #2C3E50; font-size: 18px; font-weight: bold;">${tcpTotalDaily.toFixed(2)} mAh</div>
      </div>
    </div>
    <div style="margin-bottom: 12px;">
      <div style="display: flex; align-items: center; margin-bottom: 6px;">
        <span style="width: 50px; font-size: 13px; color: #2C3E50; font-weight: bold;">UDP</span>
        <div style="background: #16A085; height: 24px; width: ${udpBar}px; border-radius: 4px; margin-right: 8px;"></div>
        <span style="font-size: 13px; color: #2C3E50;">${udpLifeYears.toFixed(1)} years</span>
      </div>
      <div style="display: flex; align-items: center;">
        <span style="width: 50px; font-size: 13px; color: #2C3E50; font-weight: bold;">TCP</span>
        <div style="background: #E67E22; height: 24px; width: ${tcpBar}px; border-radius: 4px; margin-right: 8px;"></div>
        <span style="font-size: 13px; color: #2C3E50;">${tcpLifeYears.toFixed(1)} years</span>
      </div>
    </div>
    <div style="background: ${targetMet ? '#16A085' : '#E74C3C'}; color: white; padding: 10px; border-radius: 6px; text-align: center;">
      <strong>7-year target: ${targetMet ? 'ACHIEVED with UDP' : 'NOT MET -- consider LoRaWAN or longer intervals'}</strong>
    </div>
    <div style="font-size: 11px; color: #7F8C8D; margin-top: 8px;">
      Sleep current contributes ${sleepDaily.toFixed(2)} mAh/day | UDP advantage: ${(tcpTotalDaily / udpTotalDaily).toFixed(1)}x less daily energy
    </div>
  </div>`;
}

Subsystem 2: Traffic signal controllers (350 units)

• Mains-powered at every intersection
• Receive timing commands (128 bytes) from central server
• Execute commands controlling red/green/yellow lights
• Zero tolerance for lost or corrupted commands (safety-critical)
• Latency requirement: <500 ms end-to-end

Protocol choice: TCP + TLS

Rationale: A lost “change to green” command at a busy intersection could cause accidents. TCP’s guaranteed delivery and TLS’s authentication (preventing spoofed commands) are non-negotiable. The devices are mains-powered, so TCP’s energy overhead is irrelevant.

Requirement	TCP + TLS delivers	UDP would risk
Guaranteed delivery	ACK + retransmit within 200 ms	Lost command = intersection stuck on red
Command authentication	TLS mutual auth, certificate-based	Spoofed commands could cause green-green conflicts
Ordering	Sequence numbers prevent stale commands executing	Old “turn green” arriving after “turn red” = dangerous

Connection strategy: Persistent TCP connection with 30-second keep-alive. Reconnect within 5 seconds on failure. Average 2.1 commands per minute per intersection during peak hours.

Subsystem 3: CCTV traffic cameras (500 units)

• Mains-powered, streaming 720p video (1.5 Mbps average)
• Real-time display at traffic operations center
• Frame loss causes brief visual artifact but is acceptable
• 24/7 continuous streaming

Protocol choice: UDP + RTP/RTSP

Metric	UDP/RTP	TCP
Latency (stream delay)	50-100 ms	500-2000 ms (buffering + retransmit)
Behavior on 2% packet loss	Brief pixelation, auto-recovers	Stalling, buffering, then burst of stale frames
Bandwidth efficiency	1.5 Mbps stream + 0.02 Mbps RTP overhead = 1.52 Mbps	1.5 Mbps + TCP ACKs (~2%) + retransmits at 2% loss (~3%) = ~1.58 Mbps
Concurrent streams (1 Gbps backbone)	~658 cameras	~633 cameras

TCP’s head-of-line blocking would cause 1-2 second video freezes whenever a packet is lost, then deliver a burst of stale frames. For traffic monitoring, a current frame with a few missing pixels is more useful than a perfect frame that is 2 seconds old.

Subsystem 4: Emergency vehicle preemption (50 units)

• Vehicle-mounted units on fire trucks and ambulances
• Send GPS + priority request (64 bytes) when approaching intersection
• Must arrive within 200 ms (vehicle approaching at 60 km/h covers 3.3 m per 200 ms)
• Zero tolerance for lost requests (lives at stake)

Protocol choice: UDP + DTLS + CoAP Confirmable

Requirement	Why not plain UDP	Why not TCP
Reliability	Cannot risk lost preemption request	TCP’s 3-way handshake adds 150-300 ms delay on each new approach
Low latency	CoAP CON retry at 2s (well within safety margin)	TCP retransmit timeout starts at 1s, but handshake adds initial 150-300 ms
Security	DTLS prevents spoofed preemption requests	TLS requires TCP, adding connection overhead
Mobility	DTLS Connection ID handles cell handover	TCP connection breaks on cell change, requires reconnection

CoAP CON timing: Initial request at T=0, if no ACK by T=2s retry (but intersection is 200 m away at 60 km/h = 12 seconds of approach time). Probability of 2 consecutive UDP losses at 5% loss rate = 0.25%. Acceptable.

Decision summary:

Subsystem	Protocol	Key Driver
Traffic counters	UDP (LoRaWAN)	Battery life (power)
Signal controllers	TCP + TLS	Safety (guaranteed delivery + authentication)
CCTV cameras	UDP + RTP	Real-time video (latency)
Emergency preemption	UDP + DTLS + CoAP CON	Low latency + reliability + security + mobility

Key insight: No single transport protocol serves all four subsystems. The traffic counter’s 7-year battery requirement makes TCP impossible. The signal controller’s safety criticality makes UDP unacceptable. The camera’s real-time requirement makes TCP’s head-of-line blocking a liability. And the emergency vehicle’s combination of mobility, security, reliability, and low latency requires the most sophisticated solution: DTLS-secured CoAP over UDP. This is why transport protocol selection must be per-data-flow, not per-system.

---

7.7 Knowledge Check

Quiz: Transport Layer Protocols for IoT

🏷️ Label the Diagram

💻 Code Challenge

7.8 Concept Relationships