%% fig-alt: "Sequence diagram showing CoAP Confirmable message reliability over UDP. Security sensor sends Alarm ID 100 (door opened) which gets lost in network. After timeout with no ACK, sensor retransmits same message ID 100. Cloud server receives retry, processes alarm, and sends ACK. Sensor then transmits Alarm ID 101 (window opened) which succeeds immediately. When duplicate Alarm ID 100 arrives late from retry, server detects duplicate ID and ignores it while still sending ACK. Demonstrates application-layer reliability: message IDs enable ordering and deduplication, retransmissions ensure delivery, ACKs confirm receipt. Provides TCP-like reliability over UDP without connection overhead."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'fontSize': '14px'}}}%%
sequenceDiagram
participant S as Security Sensor
participant N as Network (UDP)
participant C as Cloud Server
Note over S,C: Alarm #1 Detection
S->>N: CON POST /alarm<br/>ID=100, "Door opened"
Note over N: Packet lost
Note over S: Timeout - No ACK
S->>N: CON POST /alarm<br/>ID=100, "Door opened" (retry)
N->>C: Deliver message
C->>N: ACK [ID=100]
N->>S: ACK received
Note over C: Process alarm #1
Note over S,C: Alarm #2 Detection
S->>N: CON POST /alarm<br/>ID=101, "Window opened"
N->>C: Deliver message
C->>N: ACK [ID=101]
N->>S: ACK received
Note over C: Process alarm #2
Note over S,C: Duplicate arrives (from retry)
N->>C: CON POST /alarm<br/>ID=100 (duplicate)
Note over C: ID=100 already processed<br/>Ignore duplicate
C->>N: ACK [ID=100]
758 Transport Review: Knowledge Check
758.1 Learning Objectives
By the end of this chapter, you will be able to:
- Validate understanding: Test transport protocol knowledge through quiz questions
- Apply concepts: Solve scenario-based protocol selection problems
- Calculate overhead: Work through battery life and efficiency calculations
- Analyze trade-offs: Evaluate protocol options for different IoT deployments
758.2 Prerequisites
Required Chapters:
- Transport Review: Protocol Selection - Protocol trade-offs
- Transport Review: Overhead Analysis - Battery calculations
- Transport Review: DTLS Security - DTLS architecture
Estimated Time: 45 minutes
758.3 Understanding Check: Battery Life Impact
TipUnderstanding Check: Battery Life Impact in Environmental Monitoring
Scenario: You’re designing a sensor network for a national park with 5,000 environmental sensors. Each sensor transmits a 10-byte temperature/humidity reading every 10 seconds using an nRF52840 module. You have two protocol choices: UDP fire-and-forget or TCP with full connection establishment.
Think about: 1. How would you calculate the radio on-time difference between these approaches? 2. For environmental data where occasional packet loss is acceptable, which design better serves the deployment’s 5-year maintenance cycle?
Key Insight: With UDP fire-and-forget, radio on-time is ~1.3 ms per transmission (24 bytes at 250 kbps) versus TCP’s ~13.3 ms (244 bytes including handshake/teardown). This 10× difference translates to UDP achieving 45.5 years battery life versus TCP’s 8.6 years—a 5.3× improvement.
Verify Your Understanding: - When would the guaranteed delivery of TCP justify its 5× battery life penalty? - For which IoT applications is occasional environmental data loss acceptable versus unacceptable?
Click to reveal answer
Answer: A) Design A (UDP): 1.3 ms radio time, 45.5 years battery | Better: Lower overhead
Explanation:
Step 1: Calculate Packet Sizes (with 6LoWPAN compression)
UDP Packet:
IPv6 header (6LoWPAN compressed): 6 bytes
UDP header: 8 bytes
Payload: 10 bytes
Total: 24 bytes
Overhead: 14 bytes / 24 bytes = 58% overhead
Payload efficiency: 10 bytes / 24 bytes = 42%TCP Packet (full connection):
Handshake (SYN, SYN-ACK, ACK): 3 × 26 bytes = 78 bytes
Data packet: 6 (IPv6) + 20 (TCP) + 10 (payload) = 36 bytes
ACK: 6 (IPv6) + 20 (TCP) = 26 bytes
Teardown (FIN, ACK, FIN, ACK): 4 × 26 bytes = 104 bytes
Total per transmission: 78 + 36 + 26 + 104 = 244 bytes
Overhead: 234 bytes / 244 bytes = 96% overhead
Payload efficiency: 10 bytes / 244 bytes = 4%758.4 Understanding Check: Protocol Selection
TipUnderstanding Check: Protocol Selection Trade-offs
Scenario: You’re consulting for four different IoT deployments, each with distinct requirements for reliability, latency, power, and security.
Smart Door Lock (Battery, Security-Critical): - Think about: Would TCP’s handshake overhead consume excessive battery for 10 daily operations? - Trade-off: Can UDP+DTLS with CoAP Confirmable provide reliability without TCP’s power cost?
Industrial Sensors (200 Devices, Wired Power, High Frequency): - Think about: With 0.1% loss tolerance and no security needs, does TCP’s overhead justify the reliability? - Trade-off: How does UDP’s stateless operation benefit 200 concurrent sensor streams?
Firmware Updates (500 KB, Monthly, Critical Reliability): - Think about: Why is TCP’s guaranteed in-order delivery non-negotiable for firmware? - Trade-off: For infrequent large transfers, when does TCP overhead become acceptable?
Video Surveillance (Real-time, Encrypted, Frame Loss OK): - Think about: Why would TCP’s retransmission of old frames harm real-time video? - Trade-off: How does UDP+DTLS avoid head-of-line blocking while maintaining security?
Key Insight: Smart locks use UDP+DTLS (5× power savings), sensors use UDP (minimal overhead), firmware uses TCP+TLS (guaranteed delivery), and video uses UDP+DTLS (no retransmission delay).
Click to reveal answer
Answer: C) A→UDP+DTLS, B→UDP, C→TCP+TLS, D→UDP+DTLS
Decision Matrix Summary:
System Reliability Latency Power Security Protocol
----------------------------------------------------------------
Lock Critical* <200ms Battery Required UDP+DTLS
Sensors 0.1% loss OK Real-time Mains None UDP
Firmware 100% Background Acceptable Required TCP+TLS
Video Frame loss OK <100ms Mains Required UDP+DTLS
* Reliability via CoAP Confirmable (application layer)758.5 Quiz 1: TCP vs UDP Overhead
758.6 Quiz 2: DTLS Handshake and Session Resumption
758.7 Quiz 3: Comprehensive Review
Question 2: An IoT device needs to send 1 MB firmware update over a cellular network with 10% packet loss and variable latency. Which transport protocol and why?
Explanation: Firmware updates require TCP:
Why TCP is essential: 1. 100% reliability: Missing even 1 byte corrupts entire firmware (brick device) 2. In-order delivery: Firmware must be written sequentially to flash memory 3. Automatic retransmission: 10% loss requires ~100,000 retransmits for 1 MB 4. Flow control: Prevents overwhelming slow flash write operations 5. Congestion control: Adapts to network conditions
Why NOT UDP: - Application-layer reliability: Would need to reimplement TCP’s features (ACKs, retransmit, ordering) - Complexity: Easier to use proven TCP than write custom reliability layer - Efficiency: TCP’s cumulative ACKs more efficient than per-packet UDP ACKs
Real-world: All OTA (Over-The-Air) firmware updates use HTTP/HTTPS over TCP.
Question 8: TCP’s congestion control (slow start, congestion avoidance) is designed for internet traffic. How does this affect IoT over cellular (NB-IoT, LTE-M)?
Explanation: TCP slow start is problematic for IoT:
TCP slow start mechanism: 1. Start with cwnd (congestion window) = 1 MSS (Maximum Segment Size, ~1460 bytes) 2. Send 1 packet, wait for ACK 3. On ACK, cwnd = 2, send 2 packets 4. Exponentially increase until threshold or packet loss
Problem for small IoT payloads:
Scenario: Send 100-byte sensor reading
TCP slow start:
1. Establish connection (3-way handshake)
2. Send 1 segment (100 bytes data + 40 header = 140 bytes)
3. Wait for ACK (~100-200ms cellular RTT)
4. Send remaining data (if any)
5. Close connection (FIN handshake)
Total time: ~500ms for 100 bytesEnergy waste: - TCP slow start + handshakes keep radio in high-power state longer - 100-byte message: ~1.5 seconds in RRC Connected = 300 mJ - UDP message: ~200ms in RRC Connected = 40 mJ - TCP wastes 7.5× energy for small payload!
Solutions: - Use UDP + CoAP for small periodic messages - Use TCP only for large transfers (firmware updates) - Configure TCP to disable slow start (TCP Fast Open) for IoT - Consider QUIC (UDP-based reliable transport)
Question 11: TCP requires 3-way handshake (SYN, SYN-ACK, ACK) before data transmission. For a sensor sending a single 50-byte message, how many total packets and bytes are transmitted?
Explanation: TCP’s overhead is significant for small payloads:
Compare to UDP:
UDP:
- Single packet: Data(50) + UDP(8) + IP(20) = 78 bytes
- No handshake, no ACK, no FIN
Efficiency:
- TCP: 330 bytes to send 50 bytes data (6.6× overhead)
- UDP: 78 bytes to send 50 bytes data (1.56× overhead)Energy implications:
Assume 150ms to transmit 1 packet, radio 15 mW:
TCP:
- 6 packets × 150ms = 900ms active
- Energy: 900ms × 15mW = 13.5 mJ
UDP:
- 1 packet × 150ms = 150ms active
- Energy: 150ms × 15mW = 2.25 mJ
TCP uses 6× more energy!Solutions: - TCP Fast Open (TFO): Include data in SYN (reduces 1 RTT) - Persistent connections: Keep connection open for multiple messages - Switch to UDP: For small, periodic, low-criticality data
Question: Compare TCP and UDP for various IoT scenarios:
| Scenario | Data Type | Latency Requirement | Reliability Requirement | Best Protocol |
|---|---|---|---|---|
| A. Temperature sensor every 60s | Periodic telemetry | Low | Tolerable loss | ? |
| B. Firmware download | Large file | Medium | 100% reliable | ? |
| C. Smart lock command | Single event | Critical | 100% reliable | ? |
| D. Video streaming | Continuous data | Real-time | Tolerable loss | ? |
Which row correctly assigns the best transport protocol for each scenario?
Explanation: Selecting transport protocols requires analyzing data characteristics and requirements: A: UDP for periodic telemetry - Temperature readings every 60 seconds are replaceable; if one reading is lost, the next provides current status. UDP’s low overhead (8 bytes vs 20+ for TCP) saves battery. B: TCP for firmware - 100% reliability required (corrupted firmware bricks device). TCP provides automatic retransmission, in-order delivery, and flow control for large files. C: TCP for smart lock - Critical commands require guaranteed delivery (imagine “unlock” command lost!). TCP ensures reliability, though CoAP Confirmable over UDP also works with application-layer ACKs. D: UDP for video streaming - Real-time video prioritizes low latency over perfect delivery. Lost frames cause minor glitches, but TCP retransmissions would cause stuttering and jitter. UDP allows application to skip lost frames and continue.
Question: Which of the following are key benefits of using UDP for IoT constrained devices compared to TCP? (Select ALL that apply)
Explanation: UDP provides several advantages for constrained IoT devices: (B) Connectionless operation is correct - UDP has no connection setup/teardown, eliminating the 3-way handshake (SYN, SYN-ACK, ACK) and 4-way teardown (FIN, FIN-ACK) that TCP requires. (C) Smaller header is correct - UDP’s 8-byte header is 60% smaller than TCP’s 20-byte minimum. (D) Stateless operation is correct - UDP requires no connection state, allowing sensors to fully power down between transmissions. (A) Automatic retransmission is incorrect - this is a TCP feature, not UDP. (E) Flow control is incorrect - UDP has no flow control mechanism.
Question: Evaluate these statements about transport layer concepts for IoT:
Statement 1: TCP guarantees in-order delivery by using sequence numbers, but this can cause head-of-line blocking where one lost packet delays all subsequent packets.
Statement 2: UDP’s checksum is optional in both IPv4 and IPv6, allowing removal for applications where speed is more important than integrity.
Statement 3: DTLS provides the same security guarantees as TLS but operates over UDP, requiring application-layer handling of packet loss and reordering.
Statement 4: TCP’s congestion control (slow start, congestion avoidance) always improves performance for IoT devices on cellular networks.
Which statements are TRUE?
Explanation: Statement 1: TRUE - TCP ensures in-order delivery using sequence numbers. If packet #5 is lost but #6 arrives, TCP buffers #6 and waits for #5 retransmission. Statement 2: FALSE - UDP checksum is optional in IPv4 but mandatory in IPv6. Statement 3: TRUE - DTLS provides encryption, authentication, and integrity like TLS, but operates over UDP with its own mechanisms for handling packet loss. Statement 4: FALSE - TCP’s congestion control can hurt IoT performance with small payloads.
Question: A fleet of delivery drones needs to stream telemetry (GPS, altitude, battery) to ground control every 500ms. The network has 5% packet loss and 100ms latency.
Requirements: - Real-time updates (500ms period) - Tolerable data loss (next update arrives soon) - Minimize latency jitter - Battery-powered with limited energy
Which protocol best meets all requirements?
Explanation: For real-time telemetry streaming, UDP with timestamps is optimal:
Real-time requirement (500ms): UDP’s connectionless nature provides predictable, low latency.
Tolerable loss: 5% packet loss is acceptable because next telemetry update arrives in 500ms.
Minimize jitter: TCP’s retransmissions cause variable latency (100ms normally, but 200-400ms when retransmitting). UDP provides consistent latency.
Battery efficiency: UDP’s 8-byte header and no connection state save energy.
Why NOT TCP options: Nagle’s algorithm adds delay, TCP_NODELAY still has retransmission jitter.
Question: An industrial IoT system needs to match transport protocols to reliability requirements:
Device Types: 1. Vibration sensor - Periodic measurements (every 10s), 2% loss acceptable 2. Emergency stop button - Critical command, zero loss tolerance 3. Quality camera - Continuous JPEG stream (30 FPS), some frame loss OK 4. Configuration manager - Sends device settings (100KB), must arrive complete
Which matching is correct?
Explanation: Matching transport protocols to reliability requirements:
1. Vibration sensor → A (UDP no ACK): Periodic measurements with tolerable loss don’t need reliability.
2. Emergency stop → B or C (UDP+ACK or TCP): Critical commands require confirmation.
3. Quality camera → D (UDP+FEC): Video streaming benefits from Forward Error Correction.
4. Configuration manager → C (TCP): Large data (100KB) requiring 100% reliability needs TCP.
758.8 Summary
Key concepts tested in this knowledge check:
- Protocol selection depends on reliability, latency, power, and security requirements
- UDP excels for frequent small transmissions with tolerable loss
- TCP is essential for large reliable transfers like firmware updates
- DTLS session resumption dramatically reduces security overhead for IoT
- Overhead calculations directly impact battery life predictions
758.9 What’s Next
Having completed the transport protocols review:
- Topologies: Network structures and their trade-offs for IoT deployments
- MQTT Protocol: Publish-subscribe messaging built on TCP
- CoAP Protocol: RESTful communication over UDP for constrained devices
- DTLS and Security: Deep dive into securing UDP-based IoT protocols