954  IEEE 802.15.4 Quiz: Device Types and Security

954.1 Learning Objectives

After completing this quiz section, you should be able to:

  1. Differentiate FFD (Full Function Device) and RFD (Reduced Function Device) capabilities and constraints
  2. Calculate frame capacity and transmission requirements for RFD buffer clearing
  3. Analyze IEEE 802.15.4 security overhead with AES-128 CCM encryption
  4. Explain adaptive channel hopping mechanisms in Thread networks
NoteNavigation

Return to: Quiz Bank Part 1 Overview

Other Quiz Sections: - Addressing and Network Structure - Power and Performance Calculations - Device Types and Security (Current)

Study Materials: - 802.15.4 Fundamentals - Core concepts - 802.15.4 Topic Review - Quick reference

954.2 Quiz: RFD vs FFD Device Types

Question: A healthcare facility deploys IEEE 802.15.4 patient monitors as RFDs (Reduced Function Devices) communicating with FFD (Full Function Device) nurses’ stations. Each RFD has 8 KB RAM and must buffer sensor data if communication fails. If RFDs store 24 sensor readings (each 32 bytes with timestamp and patient ID) plus maintain 2 KB for firmware operation, and the maximum frame payload is 102 bytes, how many transmissions are needed to clear the buffer after reconnection, and why can’t an RFD route for other devices?

Explanation: This demonstrates IEEE 802.15.4 device types (FFD vs RFD) and frame structure constraints:

Device Types:

“Full Function Device (FFD): - Can be coordinator, router, or end device - Can talk to any other device (FFD or RFD) - Implements full MAC protocol

Reduced Function Device (RFD): - Can ONLY be end device (not coordinator/router) - Can ONLY talk to FFD (not other RFDs) - Minimal resources (limited RAM, processing)”

Buffer Transmission Calculation:

Step 1: Analyze memory usage

Total RAM: 8 KB = 8,192 bytes
Firmware operation: 2 KB = 2,048 bytes
Available for buffer: 8,192 - 2,048 = 6,144 bytes

Sensor readings to buffer: 24 readings
Size per reading: 32 bytes
Total buffered data: 24 x 32 = 768 bytes

Verification:
768 bytes << 6,144 bytes available
Buffer utilization: 768 / 6,144 = 12.5%

Step 2: Calculate frame capacity

Maximum frame payload: 102 bytes (from IEEE 802.15.4 spec).

  • Sensor reading: 32 bytes each
  • Readings per frame: floor(102 / 32) = 3 readings
  • Bytes per frame: 3 x 32 = 96 bytes
  • Remaining in frame: 102 - 96 = 6 bytes (insufficient for a 4th reading)

Step 3: Calculate transmissions needed

Total readings: 24
Readings per frame: 3
Transmissions needed: ceiling(24 / 3) = ceiling(8) = 8 transmissions

Verification:
- First 7 frames: 7 x 3 = 21 readings (672 bytes)
- Last frame: 24 - 21 = 3 readings (96 bytes)
- Total frames: 8

Frame Structure Details:

IEEE 802.15.4 frame structure:

Field Size Notes
PHY header 6 bytes Preamble + SFD + length
MAC header 3-23 bytes Depends on addressing mode
Payload 0-102 bytes Application data
FCS 2 bytes Frame Check Sequence (CRC)

Individual sensor reading (32 bytes):

Field Size Example
Patient ID 4 bytes uint32 identifier
Timestamp 4 bytes Unix time
Heart Rate 4 bytes bpm
SpO2 4 bytes Oxygen saturation %
Blood Pressure 8 bytes Systolic/diastolic
Temperature 4 bytes Celsius
Checksum 4 bytes CRC/padding

Why RFDs Can’t Route:

IEEE 802.15.4 Functional Differences:

Capability FFD RFD
MAC layer Complete implementation Minimal (data TX only)
Beacon generation Yes (if coordinator) No
Frame routing Yes No
Neighbor table Yes (10-50 entries) No (only parent)
Network layer routing Yes (RPL, AODV) No
Operating modes Coordinator, router, end device End device only

Architectural Constraints:

  1. Firmware Limitation: RFD firmware doesn’t include routing code; ROM size typically 32-64 KB (vs 128-256 KB for FFD)
  2. RAM Limitation: Routing table ~50-100 bytes per neighbor; 10 neighbors = 500-1000 bytes; RFDs can’t afford this
  3. Processing Limitation: Routing requires route discovery, maintenance, forwarding decisions; RFD has simple MCU (8-bit, 8 MHz)
  4. Protocol Definition: IEEE 802.15.4 explicitly defines: “RFD: Intended for simple applications, talks only to FFD”

Key Insight:

RFDs are intentionally simplified devices optimized for end-node applications: - 8 transmissions efficiently clear 24 readings (3 per frame, 94% utilization) - RFDs can’t route because they implement only device functionality - Network relies on FFDs (coordinators/routers) for routing infrastructure

954.3 Quiz: Security Overhead

Question 16 (Single-Answer MCQ): An IEEE 802.15.4 network uses AES-128 CCM encryption with security level 5 (Enc-MIC-64, encryption + 64-bit MIC). For a 50-byte payload frame, how much additional overhead does security add, and why is this acceptable despite the 127-byte frame size limit?

Explanation: 802.15.4 Security overhead for CCM mode with MIC-64:

(1) Auxiliary Security Header (5-14 bytes): - Security Control (1 byte) - Frame Counter (4 bytes) - Key Identifier (0-9 bytes, typically 1-byte Key Index) - Typical: 5-6 bytes for network-key mode

(2) MIC (Message Integrity Code): 8 bytes for 64-bit MIC (security level 5)

Total overhead: ~13-14 bytes for common configurations.

Frame breakdown (50-byte payload):

PHY Header (6 bytes) + MAC Header (11 bytes) + Security (14 bytes) +
Payload (50 bytes) + FCS (2 bytes) = 83 bytes total
(well within 127-byte limit)

Why acceptable?

Security Feature Protection Importance
Frame Counter (monotonic) Replay attacks Attacker can’t reuse old packets
64-bit MIC Tampering detection 2^64 authentication space
AES-128 encryption Eavesdropping 2^128 key space

Security benefits vs costs:

Aspect Without Security With Security (14 bytes)
Payload capacity 102 bytes 88 bytes (14% reduction)
Eavesdropping Sensors leak private data Encrypted
Packet injection Attacker controls devices Authenticated
Replay attacks Unlock doors repeatedly Frame counter prevents

Why other options are incorrect:

  • Option A (21 bytes): Double-counts frame counter (already in security header)
  • Option C (32 bytes): AES-CCM doesn’t require block alignment padding for MAC
  • Option D (8 bytes): Ignores auxiliary security header (frame counter, key ID)

Security overhead is 11% of frame capacity but critical for home automation, industrial control, and medical IoT where unauthorized access causes physical harm.

954.4 Quiz: Channel Hopping and Interference Adaptation

Question 17 (Single-Answer MCQ): A Thread network (based on 802.15.4) uses channel hopping to avoid interference. The network operates on 4 channels (15, 20, 25, 26) with 30-second hop interval. If a microwave oven suddenly activates, causing persistent interference on channel 20, how does the network detect and adapt, and what is the impact on devices that happened to be transmitting when the channel blacklisting occurs?

Explanation: Adaptive channel hopping in Thread (802.15.4-based):

(1) Monitoring: Each router tracks per-channel PER (Packet Error Rate = failed_packets / total_packets) over a sliding window (typically 100-500 packets or 5-10 hop cycles).

(2) Detection: If Ch20 PER exceeds threshold (50-70% depending on implementation) for multiple consecutive observations (avoiding false positives from transient interference), Ch20 is marked “bad”.

(3) Blacklisting: Thread Network Manager distributes blacklist update via multicast to all routers, removing Ch20 from hopping sequence (now 3 channels: 15, 25, 26).

(4) In-flight transactions: Devices currently transmitting on Ch20 when blacklist activates experience immediate impact: - Ongoing frame completes if started (ACK might fail) - Next frame switches to new channel - Impact: 1-2 lost packets during transition (<100 ms with retransmission)

Adaptive Channel Management:

Before blacklisting:
Hopping sequence: Ch15 -> Ch20 -> Ch25 -> Ch26 -> Ch15...
PER per channel: Ch15: 5%, Ch20: 65%, Ch25: 8%, Ch26: 3%

Detection criteria:
- Ch20 PER (65%) > threshold (50%)
- Consistent across 5 consecutive hop cycles
- Decision: Blacklist Ch20

After blacklisting:
Hopping sequence: Ch15 -> Ch25 -> Ch26 -> Ch15...
Network capacity: 75% (3/4 channels)
Recovery time: 30-60 seconds (1-2 hop cycles)

Benefits of adaptive hopping:

Scenario Without Adaptation With Adaptation
Microwave interference 25% throughput loss indefinitely 30-60 sec recovery, 0% loss
Wi-Fi channel overlap Permanent degradation Automatic avoidance
Multi-network deployment Channel conflicts Dynamic coordination

Why other options are incorrect:

  • Option B: Thread implements adaptive channel management, not fixed hopping
  • Option C: 802.15.4 provides RSSI/LQI metrics; Thread adds network-layer intelligence
  • Option D: 802.15.4 operates only in 2.4 GHz (and sub-GHz for some variants); no 5 GHz backup

Thread insight: This adaptive behavior is why Thread claims “self-healing mesh” - network-layer intelligence (channel monitoring, blacklist distribution) built on 802.15.4 link-layer (channel hopping primitive). Standard 802.15.4 provides the PHY/MAC primitives (multi-channel operation, RSSI/LQI metrics); Thread’s network layer adds intelligence.

954.5 Summary

This quiz section covered IEEE 802.15.4 device types and security mechanisms:

Topic Key Concept Practical Impact
RFD vs FFD Device capability hierarchy 80-90% RFDs (sensors), 10-20% FFDs (routers)
Frame Capacity 102-byte max payload 3 readings per frame (94% efficiency)
Security Overhead 14 bytes (header + MIC) 88 bytes usable payload with AES-128
Channel Hopping Adaptive PER monitoring Self-healing in <100 ms

954.5.1 Key Formulas

Frame Packing Efficiency:

Readings per frame = floor(Max_Payload / Reading_Size)
Transmissions needed = ceiling(Total_Readings / Readings_per_Frame)
Efficiency = (Readings_per_Frame x Reading_Size) / Max_Payload

Security Overhead:

Auxiliary Header: 5-14 bytes (typically 6 bytes)
MIC: 4-16 bytes (8 bytes for MIC-64)
Total: 13-14 bytes typical
Available Payload: 102 - 14 = 88 bytes

Channel Blacklisting:

PER threshold: 50-70%
Detection window: 5 consecutive hop cycles
Recovery time: 1-2 hop intervals (30-60 seconds)
Transition impact: <100 ms (1-2 packets)

954.6 Device Type Comparison

Attribute FFD RFD
ROM 128-256 KB 32-64 KB
RAM 64-256 KB 8-32 KB
MCU 32-bit, 48 MHz 8-bit, 8 MHz
Roles Coordinator, router, device Device only
Communication Any device Parent FFD only
Routing Yes No
Cost Higher Lower
Power Higher Lower
Use case Infrastructure Sensors

954.7 What’s Next

Continue to: - Addressing and Network Structure - Addressing modes and Cskip algorithm - Power and Performance Calculations - Battery life, GTS, variant selection - Quiz Bank Part 1 Overview - Return to main navigation - Quiz Bank Part 2 - More comprehensive review questions