32  Transport Review: Knowledge Check

In 60 Seconds

This knowledge check validates your transport protocol understanding through scenario-based quiz questions, overhead calculations, and battery life analysis. Key problems include comparing UDP vs TCP radio on-time for environmental sensors (1.3ms vs 13.3ms per transmission, yielding 45.5 vs 8.6 years battery life) and evaluating protocol choices for industrial monitoring, smart agriculture, and fleet tracking deployments.

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

32.2 Prerequisites

Required Chapters:

Estimated Time: 45 minutes

32.3 Understanding Check: Battery Life Impact

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%
Summary: For battery-powered environmental sensors with frequent transmission (every 10 sec), UDP is vastly superior due to 5× longer battery life. TCP’s reliability benefits don’t justify the 81% battery life reduction for non-critical telemetry data. If reliability is needed, use UDP with CoAP Confirmable messages for better performance than TCP.

32.4 Understanding Check: Protocol Selection

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)
Key Takeaway: Protocol selection requires analyzing reliability, latency, power, and security together. No single protocol optimal for all scenarios.

32.5 Quiz 1: TCP vs UDP Overhead

{#fig-mermaid-transport-quiz-0}

Sequence diagram showing CoAP Confirmable message reliability over UDP

Why this works: - Reliability: CON messages retransmitted until ACK (max 4-5 attempts) - Ordering: Message ID allows receiver to sequence events - Deduplication: Receiver tracks processed IDs, ignores duplicates - Efficiency: Only retransmit lost messages (not all like TCP) - Stateless: No persistent connection state

Why NOT other answers: - A: Unacceptable for critical alarms - B: Can’t disable TCP congestion control easily, still has connection overhead - D: Wastes 5× bandwidth, no confirmation of delivery

:::

::::

32.6 Quiz 2: DTLS Handshake and Session Resumption

A smart city deploys 10,000 parking sensors. Each sensor: - Reports parking status every 30 seconds - Uses NB-IoT cellular (RTT = 200 ms, TX power = 23 dBm = 200 mW) - Security required: DTLS with Pre-Shared Key (PSK) - Battery: 5 Ah (must last 10 years)

The network architect proposes two DTLS strategies:

Strategy 1: Full DTLS handshake for every transmission - Handshake: 6 messages, 620 bytes, 3 RTT (600 ms) - Data record: 10 bytes payload + 13 bytes DTLS overhead

Strategy 2: DTLS session resumption (abbreviated handshake) - Initial handshake: 620 bytes, 600 ms (once at deployment) - Resumption: 200 bytes, 1 RTT (200 ms) when session expires (every 24 hours) - Data record: 10 bytes payload + 13 bytes DTLS overhead

Calculate handshake energy cost and determine which strategy enables 10-year battery life.

  1. Strategy 1: 120 µJ/handshake, fails 10-year target (lasts ~2 years)
  2. Strategy 2: 40 µJ/resumption, achieves 10-year target
  3. Both strategies achieve 10-year target (handshake energy negligible)
  4. Neither strategy works (DTLS too expensive for battery IoT)
Click to reveal answer

Answer: B) Strategy 2: 40 µJ/resumption, achieves 10-year target

Key Insights: 1. Session resumption saves 67% handshake energy (120 mJ → 40 mJ) 2. Full handshake per transmission kills battery (Strategy 1 fails) 3. NB-IoT high power requires careful PSM configuration 4. Real parking sensors report less frequently (every 5-30 minutes, not 30 seconds)

Answer B is conceptually correct: Session resumption is essential for achieving long battery life with DTLS in IoT deployments.

{#fig-mermaid-transport-quiz-1}

Flowchart showing DTLS packet encapsulation layers for 50-byte payload

Actual calculation: - Application data: 50 bytes - DTLS encryption: +8 bytes (GCM auth tag) - DTLS record header: +13 bytes - UDP header: +8 bytes - IP header: +20 bytes (IPv4) - Range: 91-99 bytes typical

Answer B (92 bytes) is closest to the realistic total including minimal auth tag.

:::

::::

32.7 Quiz 3: Comprehensive Review

32.8 Summary

Key concepts tested in this knowledge check:

32.9 What’s Next

Having completed the transport protocols review: