957  IEEE 802.15.4 Quiz: Superframe Structure and Device Types

957.1 Learning Objectives

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

  • Calculate superframe timing using SO (Superframe Order) and BO (Beacon Order)
  • Determine CAP (Contention Access Period) and CFP (Contention Free Period) allocation
  • Explain why RFDs cannot route packets and their memory constraints
  • Calculate frame packing efficiency for RFD buffer clearing scenarios
  • Compare FFD vs RFD capabilities and RAM requirements
NoteNavigation

Overview: Quiz Bank Overview - Learning objectives and study strategy

Part 2 Quiz Sections: - Deployment and Power - 2 questions on battery life and variant selection - Superframe and Device Types (Current) - 4 questions on timing and FFD/RFD - Security and Interference - 2 questions on encryption and channel hopping

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

957.2 Quiz 1: Beacon-Enabled Mode with GTS Allocation

Question: A smart building uses IEEE 802.15.4 in beacon-enabled mode with superframe order SO=4 and beacon order BO=6. HVAC control commands require guaranteed delivery within 50 ms using GTS (Guaranteed Time Slots). If the base superframe duration is 15.36 ms and the coordinator allocates 2 GTS slots of 1 slot each, what percentage of the active superframe is available for contention-based CSMA/CA, and why might the network engineer increase SO?

Explanation: This demonstrates IEEE 802.15.4 beacon-enabled superframe structure with GTS allocation:

From the text - Beacon-Enabled Networks:

“Beacon-Enabled Networks: - Coordinator broadcasts periodic beacons - Superframe Structure: Divided into 16 equal slots - GTS (Guaranteed Time Slot): Allocated for time-critical traffic”

Superframe Calculation:

Step 1: Calculate superframe duration

Superframe Order (SO) = 4
Beacon Order (BO) = 6
Base superframe duration = 15.36 ms

Active superframe duration = base x 2^SO
Active duration = 15.36 ms x 2^4 = 15.36 ms x 16 = 245.76 ms

Beacon interval = base x 2^BO
Beacon interval = 15.36 ms x 2^6 = 15.36 ms x 64 = 983.04 ms

Duty cycle = Active / Beacon interval
Duty cycle = 245.76 / 983.04 = 25%

Step 2: Superframe slot structure

Total slots in active superframe: 16 Slot duration: 245.76 ms / 16 = 15.36 ms per slot

Superframe structure:

Segment Slots Description
Beacon 0 Coordinator beacon for synchronization
CAP 1-13 Contention Access Period (CSMA/CA for regular traffic)
GTS (CFP) 14-15 Guaranteed Time Slots for time-critical HVAC commands

So we have: - Beacon: slot 0 (1 slot) - GTS: 2 x 1-slot allocations (slots 14-15) - CAP: Remaining 14 slots for contention-based traffic

Step 3: Calculate CAP percentage

CAP slots: 14 slots (slots 0-13, including beacon transmission time)
Total active slots: 16 slots
CAP percentage = 14 / 16 = 87.5%

Why Increase SO (Superframe Order)?

Current configuration:

SO = 4 -> Active period = 245.76 ms (16 slots x 15.36 ms)
Each slot: 15.36 ms

Impact on traffic:
- HVAC command: Requires 1 GTS slot = 15.36 ms
- Requirement: Delivery within 50 ms (15.36 < 50)
- CAP traffic: Has 14 slots x 15.36 ms = 215.04 ms per superframe

If we increase SO to 5:

SO = 5 -> Active period = 15.36 ms x 2^5 = 491.52 ms
Each slot: 491.52 / 16 = 30.72 ms

Benefits:
- More time per slot for longer packets
- More time for CSMA/CA backoff without spanning superframes
- Better accommodation of mixed traffic (sensor data + commands)
- Reduced probability of CAP contention

Drawback:
- Higher duty cycle = more power consumption
  If BO stays same: duty cycle = 491.52 / 983.04 = 50% (2x increase)
  Need to increase BO proportionally to maintain 25% duty cycle

Why other options are incorrect:

Option A: 75% available (WRONG percentage)

75% would mean: 12 slots / 16 = 0.75
This implies: 4 slots used for beacon + GTS

But with 1 beacon + 2 GTS = 3 slots, we'd need 4 slots
This doesn't match the calculation.

Option C: 50% available (WRONG percentage)

50% would mean: 8 slots / 16 = 0.50
With only 1 beacon + 2 GTS = 3 slots, we have 13 slots for CAP
50% is mathematically impossible with given configuration.

Option D: 93.75% available (WRONG reasoning)

93.75% would mean: 15 slots / 16 = 0.9375
This implies: Only 1 slot used for non-CAP (contradicts 2 GTS slots!)

Reasoning "extend sleep period and save battery":
- Confuses SO (Superframe Order) with BO (Beacon Order)
- Increasing SO makes active period LONGER (more power)
- To extend sleep: Increase BO, not SO

957.3 Quiz 2: RFD Buffer Clearing and Routing Limitations

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:

From the text - 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) = floor(3.1875) = 3 readings

Bytes per frame: 3 x 32 = 96 bytes
Remaining in frame: 102 - 96 = 6 bytes (insufficient for 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 Description
Patient ID 4 bytes uint32 identifier
Timestamp 4 bytes Unix time
HR 4 bytes Heart rate in bpm
SpO2 4 bytes Oxygen saturation (%)
BP 8 bytes Systolic/diastolic blood pressure
Temp 4 bytes Temperature in C
Checksum 4 bytes Record integrity check

Why RFDs Can’t Route:

IEEE 802.15.4 Functional Differences:

  • FFD (Full Function Device)
    • MAC layer: complete implementation
      • Beacon generation (if coordinator)
      • Frame routing
      • Address resolution
      • Association management
      • GTS management
    • Maintains a neighbor table with routing information
    • Network layer: can run routing protocols (Zigbee/Thread)
    • Can operate as: coordinator, router, or end device
  • RFD (Reduced Function Device)
    • MAC layer: minimal implementation
      • Data transmission only
      • No beacon generation
      • No routing capability
      • Simple ACK handling
    • No neighbor table (only knows its parent FFD)
    • No network-layer routing
    • Can operate only as: end device

Key difference: RFD firmware intentionally omits routing functionality to save memory, processing, and power.

Architectural Constraints:

Why RFD can't route:

1. **Firmware Limitation**:
   - RFD firmware doesn't include routing code
   - ROM size typically 32-64 KB (vs 128-256 KB for FFD)
   - Routing algorithms removed to save space

2. **RAM Limitation**:
   - Routing table: ~50-100 bytes per neighbor
   - 10 neighbors = 500-1000 bytes
   - RFD has only 6 KB available (after firmware)
   - Can't maintain routing tables

3. **Processing Limitation**:
   - Routing requires:
     - Route discovery protocols
     - Route maintenance
     - Packet forwarding decisions
     - Multiple simultaneous connections
   - RFD has simple MCU (8-bit, 8 MHz)
   - FFD has more powerful MCU (32-bit, 48 MHz)

4. **Protocol Definition**:
   - IEEE 802.15.4 standard explicitly defines:
     "RFD: Intended for simple applications, talks only to FFD"

Why other options are incorrect:

Option A: 2 transmissions (WRONG calculation) - Rounding should be UP (ceiling), not down - 7.53 rounded down = 7, not 2 - Must fit complete 32-byte readings, can’t split - Correct: 24/3 = 8 transmissions

Option B: 6 transmissions (WRONG - 4 readings don’t fit) - 4 readings x 32 bytes = 128 bytes - Maximum payload = 102 bytes - 128 > 102 - CAN’T FIT 4 READINGS

Option D: 24 transmissions (WRONG - inefficient) - 1 reading = 32 bytes per 102-byte frame - 68.6% waste per frame - Guaranteed delivery comes from ACK, not frame size

957.4 Quiz 3: Superframe Timing with SO and BO

Question 12 (Single-Answer MCQ): An industrial 802.15.4 network uses beacon-enabled mode with Superframe Order (SO) = 3 and Beacon Order (BO) = 5. If the base superframe duration (aBaseSuperframeDuration) is 15.36 ms, how often does the coordinator transmit beacons, and what percentage of time is the network active?

Explanation: Superframe calculation:

Beacon Interval (BI) = aBaseSuperframeDuration x 2^BO = 15.36 ms x 2^5 = 15.36 x 32 = 491.52 ms (coordinator beacons every 491.52 ms).

Superframe Duration (SD) = aBaseSuperframeDuration x 2^SO = 15.36 ms x 2^3 = 15.36 x 8 = 122.88 ms (active period).

Active percentage = SD / BI = 122.88 / 491.52 = 25%.

This means devices wake during the 122.88 ms active period (contention access + GTS), then sleep for 368.64 ms inactive period, repeating every 491.52 ms.

Why 25% duty cycle? Industrial sensors report every few seconds; spending 25% awake provides enough time for data transmission while achieving 3-5 year battery life.

Relationship: BO >= SO (Beacon Order >= Superframe Order) ensures inactive period exists; if BO = SO, network is 100% active (no sleep).

Trade-offs: - Higher SO = longer active period (more capacity, higher power) - Higher BO = longer beacon interval (better battery, higher latency)

957.5 Quiz 4: RFD vs FFD RAM Requirements

Question 13 (Single-Answer MCQ): Why do IEEE 802.15.4 RFDs (Reduced Function Devices) typically have significantly lower RAM requirements (8-32 KB) compared to FFDs (64-256 KB), and what network capability does this prevent?

Explanation: RFD vs FFD memory architecture:

RFDs are leaf nodes (end devices) implementing only device functionality: transmit to parent, receive from parent, no routing table. This saves RAM because:

(1) No neighbor table - FFDs maintain neighbor discovery table (10-50 entries x 20 bytes = 200-1000 bytes), RFDs only store parent address (10 bytes).

(2) No routing table - FFDs implement routing protocol (RPL, AODV) requiring route cache (20-100 entries x 30 bytes = 600-3000 bytes), RFDs have no routing logic.

(3) No forwarding buffers - FFDs buffer packets for forwarding (5-10 packets x 127 bytes = 635-1270 bytes), RFDs only buffer own transmissions.

Result: RFD firmware ~8-16 KB RAM (sensor application + 802.15.4 MAC + buffer), FFD firmware ~64-128 KB RAM (routing + neighbor management + multi-packet buffering).

Trade-off: RFDs achieve 10x lower cost and longer battery life, but cannot participate in mesh routing, requiring strategic FFD placement for network coverage. Typical network: 80-90% RFDs (sensors), 10-20% FFDs (routers/coordinators).

957.6 Summary

This quiz section tested your understanding of:

  1. Superframe Structure: How SO and BO determine active/inactive periods and duty cycle
  2. GTS Allocation: How to calculate CAP percentage when Guaranteed Time Slots are allocated
  3. RFD vs FFD Capabilities: Why RFDs cannot route and their memory constraints
  4. Frame Packing: How to calculate efficient frame packing for buffer clearing

Key Takeaways: - Superframe duration = base x 2^SO; Beacon interval = base x 2^BO - Active percentage = SD/BI determines duty cycle and power consumption - RFDs are intentionally limited to end-device functionality to save cost and power - Frame packing efficiency matters for buffer clearing scenarios

957.7 What’s Next