15 Transport Review: Knowledge Check
15.2 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
15.3 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
15.4 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:
- How would you calculate the radio on-time difference between these approaches?
- 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.
15.5 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.
15.6 Quiz 1: TCP vs UDP Overhead
The answer becomes easier to audit when the acknowledgement and retransmission behavior are followed as a sequence rather than remembered as protocol labels. Inspect Figure 15.1 before comparing the reliability claims in the answer choices.
Read the sequence diagram Figure 15.1 from the sender’s Confirmable message to the receiver’s acknowledgement. Then follow the timeout path that retransmits a missing exchange and compare it with the receiver’s message-ID handling for duplicates. The sequence connects lightweight reliability to explicit application-layer state: UDP still carries datagrams, while CoAP supplies the bounded acknowledgement, retry, and deduplication behavior the alarm flow requires.
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
15.7 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.
A) Strategy 1: 120 µJ/handshake, fails 10-year target (lasts ~2 years) B) Strategy 2: 40 µJ/resumption, achieves 10-year target C) Both strategies achieve 10-year target (handshake energy negligible) D) 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:
- Session resumption saves 67% handshake energy (120 mJ → 40 mJ)
- Full handshake per transmission kills battery (Strategy 1 fails)
- NB-IoT high power requires careful PSM configuration
- 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.
The arithmetic is only defensible when every wrapper is assigned to the correct layer. Use Figure 15.2 to inspect the encapsulation stack before accepting a total transmission size.
Read the flowchart Figure 15.2 from the 50-byte application payload outward through the DTLS record, UDP header, and IP header, adding only the fragmentation term stated by the question. Keep link-layer framing outside this network-layer total. The ordered walk-through explains why the correct answer counts required wrappers once and connects the quiz calculation to the module’s wider packet-budget discipline.
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.
15.8 Quiz 3: Comprehensive Review
15.9 Summary
Key concepts tested in this knowledge check:
Read the results as one selection argument rather than five isolated facts. Requirements determine whether loss is tolerable, which transport or higher-layer reliability behavior fits, where DTLS session state changes the energy cost, and how wrapper bytes alter the battery estimate. The points below should therefore be explained with the message flow and receiver consequence that made each answer correct.
- 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
15.10 What’s Next
Having completed the transport protocols review:
Continue according to the next layer in the same message path. Topology explains how endpoints are arranged, MQTT develops publish-subscribe behavior over TCP, CoAP develops constrained request-response behavior over UDP, and DTLS deepens the protected-datagram boundary. Carry the quiz’s reliability, latency, energy, and security assumptions forward so the next protocol chapter tests rather than resets the decision.
- 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