88  802.15.4 Quiz: Superframe

In 60 Seconds

IEEE 802.15.4 superframes divide time into 16 slots controlled by Superframe Order (SO) and Beacon Order (BO), with Guaranteed Time Slots (GTS) reserved for time-critical traffic. FFDs handle routing and coordination while RFDs operate as low-power leaf nodes communicating only with their parent FFD.

Key Concepts
  • Superframe Structure: Time frame between two successive beacons divided into CAP (CSMA/CA slots) and CFP (GTS slots)
  • Beacon Order (BO): Controls beacon transmission interval; BI = 2^BO × aBaseSuperframeDuration (15.36 ms)
  • Superframe Order (SO): Controls active superframe duration; SD = 2^SO × aBaseSuperframeDuration
  • Duty Cycle Formula: Active fraction = SD/BI = 2^(SO-BO); larger SO-BO difference means less duty cycling
  • GTS Descriptor: Entry in beacon frame describing a GTS slot including device address, slot length, and direction
  • Pending Address Field: Section of beacon listing devices with queued data at the coordinator; triggers device wake-up
  • Association Request: MAC command frame from device to coordinator requesting network membership and short address
  • Orphan Scan: Process by which a device that has lost its coordinator searches for a new one by scanning channels

88.1 Minimum Viable Understanding

This quiz tests four superframe and device concepts: (1) GTS allocation – calculating CAP percentage when dedicated time slots are reserved (e.g., 2 GTS = 87.5% CAP); (2) RFD buffer clearing – frame packing efficiency (floor(102/32) = 3 readings per frame, ceiling(24/3) = 8 transmissions); (3) superframe timing – duty cycle = 2^(SO-BO) controls the power/capacity trade-off; and (4) FFD vs RFD RAM architecture – why the 8x memory difference prevents routing in leaf nodes.

88.2 Learning Objectives

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

  • Derive superframe active periods and beacon intervals from SO (Superframe Order) and BO (Beacon Order) parameters
  • Compute CAP (Contention Access Period) percentage when GTS (Guaranteed Time Slots) are allocated within a 16-slot superframe
  • Justify why RFDs cannot perform packet routing based on firmware, RAM, and protocol constraints
  • Evaluate frame packing efficiency for RFD buffer clearing by applying floor and ceiling arithmetic to payload sizes
  • Contrast FFD and RFD memory architectures and predict their impact on network topology design

The superframe is 802.15.4’s way of organizing time into slots for coordinated communication. Think of it as a class schedule that tells each device when to transmit, when to listen, and when to sleep. This quiz tests your understanding of this timing structure and the device roles that depend on it.

Navigation

Overview: Quiz Bank Overview - Learning objectives and study strategy

Part 2 Quiz Sections:

Study Materials:

88.3 Quiz 1: Beacon-Enabled Mode with GTS Allocation

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

88.4 Quiz 2: RFD Buffer Clearing and Routing Limitations

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

88.4.1 Knowledge Check: Duty Cycle Formula

88.5 Quiz 3: Superframe Timing with SO and BO

88.6

88.7 Quiz 4: RFD vs FFD RAM Requirements

88.8

88.9 Interactive: Superframe Timing Calculator

88.9.1 Knowledge Check: GTS Allocation Impact

88.9.2 Knowledge Check: RFD Limitations

Context: You are designing an 802.15.4 network for industrial machine monitoring in a factory with 200 machines across 3 buildings. You must choose between beacon-enabled mode (with superframe structure) and non-beacon mode (asynchronous CSMA/CA).

Step 1: Understand Network Traffic Patterns

Machine monitoring requirements:

Machine Type Count Sensor Data Reporting Interval Criticality Latency Requirement
CNC mills 40 Vibration, temp, speed (32 bytes) Every 10 seconds Medium < 5 seconds
Hydraulic presses 25 Pressure, position (16 bytes) Every 5 seconds High < 1 second (alarm)
Assembly robots 80 Joint angles, torque (40 bytes) Every 30 seconds Low < 30 seconds
Conveyors 30 Belt speed, motor current (12 bytes) Every 60 seconds Low < 60 seconds
HVAC sensors 25 Temperature, humidity (8 bytes) Every 5 minutes Low < 10 minutes

Traffic characteristics:

  • Mixed criticality: Hydraulic presses need guaranteed low-latency delivery (safety-critical alarms)
  • Mixed intervals: 5-second to 5-minute reporting rates
  • Predictable: All traffic is periodic (not event-driven)

Step 2: Evaluate Beacon-Enabled Mode

Beacon-enabled configuration example:

  • Superframe Order (SO) = 4 → Active period = 245.76 ms
  • Beacon Order (BO) = 6 → Beacon interval = 983.04 ms
  • Duty cycle = 25% (devices sleep 75% of the time)
  • GTS allocation: 2 slots (30.72 ms) for hydraulic press alarms

Advantages:

  1. Guaranteed Time Slots (GTS) for critical traffic
    • Hydraulic presses get dedicated slots (no contention, no collisions)
    • Latency: < 50 ms (well under 1-second requirement)
    • Delivery guarantee: 99.97% (3 MAC retries within GTS window)
  2. Synchronized sleep/wake cycles
    • All devices sleep during inactive period (737.28 ms out of every 983.04 ms)
    • Battery-powered sensors save 75% power
    • Predictable power budget for each device type
  3. Reduced collisions in CAP
    • Non-critical traffic uses Contention Access Period (87.5% of active superframe)
    • Slotted CSMA/CA is more efficient than unslotted (shorter backoff windows)
  4. Network-wide time synchronization
    • Beacons provide timing reference for all devices
    • Useful for correlating sensor data across machines (e.g., synchronized sampling)

Disadvantages:

  1. Coordinator overhead
    • PAN coordinator must transmit beacons every 983 ms (cannot sleep)
    • Beacon frames consume 1/16 of superframe (6.25% overhead)
    • Coordinator needs mains power or large battery
  2. Latency for low-priority traffic
    • Conveyors reporting every 60 seconds may miss their beacon window
    • Must wait up to 983 ms for next active superframe
    • Total latency: 983 ms (beacon interval) + CSMA/CA backoff (up to 50 ms) ≈ 1 second
  3. Configuration complexity
    • Must tune SO/BO for optimal duty cycle vs capacity trade-off
    • GTS allocation requires coordinator management (who gets slots?)
    • Adding new devices requires reconfiguring superframe structure
  4. Limited scalability for GTS
    • Maximum 7 GTS slots (out of 16 total slots)
    • Only 7 devices can have guaranteed bandwidth
    • If 25 hydraulic presses need GTS, you would need multiple PANs

Step 3: Evaluate Non-Beacon Mode

Non-beacon configuration:

  • No beacons, no superframes
  • Unslotted CSMA/CA (random backoff, CCA before transmit)
  • Devices sleep independently (no network-wide synchronization)

Advantages:

  1. Simpler deployment
    • No coordinator beacon overhead (coordinator can sleep between transmissions)
    • No SO/BO tuning required
    • Adding new devices requires no network reconfiguration
  2. Lower latency for sparse traffic
    • Devices wake and transmit immediately (no beacon wait)
    • HVAC sensors (5-minute intervals) have instant channel access
    • Average latency: CSMA/CA backoff only (2-10 ms)
  3. Better for event-driven traffic
    • Hydraulic press alarms trigger immediately when pressure exceeds threshold
    • No waiting for superframe window
  4. Coordinator can sleep
    • In non-beacon mode, coordinator is just another device
    • Can use battery power (not mains-only)

Disadvantages:

  1. No guaranteed bandwidth
    • All traffic competes in CSMA/CA (collisions increase with load)
    • Hydraulic press alarms may collide with low-priority conveyor data
    • Latency becomes unpredictable under congestion
  2. No power-saving synchronization
    • Devices cannot coordinate sleep schedules
    • Receiver must stay on or poll frequently (higher power consumption for bidirectional communication)
  3. Higher collision probability
    • Unslotted CSMA/CA has longer backoff windows than slotted
    • With 200 devices, collision probability can reach 20-30% at peak times
  4. Difficult to prioritize traffic
    • No mechanism to differentiate critical vs non-critical frames
    • Hydraulic press alarm may be delayed by conveyor belt status update

Step 4: Calculate Network Load for Each Mode

Total network traffic (frames per second):

Device Type Count Interval Frames/sec per device Total frames/sec
CNC mills 40 10 s 0.10 4.0
Hydraulic presses 25 5 s 0.20 5.0
Assembly robots 80 30 s 0.033 2.67
Conveyors 30 60 s 0.017 0.50
HVAC 25 300 s 0.0033 0.08
Total 200 - - 12.25 fps

Channel capacity (802.15.4 at 2.4 GHz):

Data rate: 250 kbps
Average frame size: 40 bytes (including overhead)
Frame transmission time: (40 × 8) / 250,000 = 1.28 ms
Maximum throughput (100% channel utilization): 1 / 1.28 ms = 781 frames/sec

Network load:

Load = 12.25 fps / 781 fps = 1.57%

Interpretation: The network is lightly loaded (< 2% utilization). Collisions should be rare even in non-beacon mode.

Step 5: Apply Decision Criteria

Criterion Beacon-Enabled Non-Beacon Winner
Guaranteed latency for hydraulic presses ✅ GTS provides < 50 ms ❌ Collisions cause unpredictable latency Beacon
Power efficiency (battery devices) ✅ 75% duty cycle with synchronized sleep ⚠️ Devices must poll or stay on Beacon
Scalability (200 devices) ⚠️ Only 7 GTS slots (need multiple PANs) ✅ Supports 200 devices in one PAN Non-Beacon
Deployment simplicity ❌ SO/BO tuning, GTS config ✅ No configuration Non-Beacon
Low network load (1.57%) ⚠️ Beacon overhead (6% of capacity) ✅ No overhead Non-Beacon
Coordinator power ❌ Mains-only (beacon duty) ✅ Can be battery-powered Non-Beacon

Conclusion: Use Non-Beacon Mode with the following modifications:

Hybrid Approach (Non-Beacon with Application-Layer Prioritization):

  1. Use non-beacon mode for simplicity and scalability
    • All 200 devices in one PAN
    • No coordinator beacon overhead
    • Coordinator can be battery-powered
  2. Implement application-layer prioritization
    • Hydraulic presses use shorter CSMA/CA backoff exponent (macMinBE = 0 instead of 3)
    • Gives critical traffic priority in channel access (lower average backoff time)
    • Low-priority devices (conveyors, HVAC) use longer backoff (macMinBE = 5)
  3. Add application-layer retransmission for critical devices
    • Hydraulic press alarms send 3 duplicate frames (spaced 50 ms apart)
    • Coordinator only needs to receive one of the three → 99.7% delivery probability
    • Adds 100 ms latency but still meets < 1 second requirement
  4. Use redundant coordinators for high availability
    • Deploy 3 coordinators (one per building)
    • Hydraulic presses send alarms to all 3 (multicast)
    • Provides fault tolerance without GTS complexity

Step 6: Verify Solution with Calculation

Hydraulic press latency (non-beacon mode with prioritization):

CSMA/CA backoff (macMinBE = 0, priority):
  Average backoff = 2^0 / 2 = 0.5 unit periods
  Unit period = 320 µs (802.15.4 @ 2.4 GHz)
  Backoff time = 0.5 × 320 µs = 160 µs

CCA (Clear Channel Assessment): 128 µs

Frame transmission: 1.28 ms (40-byte frame)

ACK wait: 192 µs (12-symbol turnaround)

Total latency (first attempt): 160 + 128 + 1,280 + 192 = 1,760 µs = 1.76 ms

With MAC retries (collision on first attempt):
  Average attempts = 1 / (1 - collision_probability)
  Collision probability ≈ 1.57% load × 3 (contention factor) ≈ 5%
  Average attempts = 1 / 0.95 = 1.05
  Average latency = 1.76 ms × 1.05 = 1.85 ms

Application-layer retransmission (3 frames, 50 ms spacing):
  P(all 3 fail) = 0.05^3 = 0.000125 (0.0125%)
  P(at least one succeeds) = 99.9875%
  Latency: 1.85 ms (first attempt) to 101.85 ms (third attempt)

Maximum latency: 101.85 ms << 1 second requirement ✅

Power consumption comparison:

Beacon-enabled mode (SO=4, BO=6, 25% duty cycle):

Active time: 245.76 ms per 983.04 ms cycle
Sleep time: 737.28 ms per cycle
Average current = 0.25 × 20 mA (active) + 0.75 × 0.005 mA (sleep) = 5.004 mA

Battery life (2000 mAh): 2000 / 5.004 = 400 hours = 16.6 days

Non-beacon mode (device-controlled sleep):

Transmission interval: 5 seconds (hydraulic press)
Transmission time: 1.76 ms
Duty cycle: 1.76 ms / 5,000 ms = 0.035%

Average current = 0.00035 × 15 mA (TX) + 0.99965 × 0.005 mA (sleep) = 0.0103 mA

Battery life: 2000 / 0.0103 = 194,175 hours = 22.1 years

Non-beacon mode achieves 500× longer battery life because devices sleep freely instead of waking for every beacon.

Final Decision: Non-Beacon Mode with Application-Layer Prioritization

Implementation checklist:

  1. Configure all devices for non-beacon operation (no beacon synchronization)
  2. Set macMinBE = 0 for hydraulic presses (priority channel access)
  3. Set macMinBE = 5 for low-priority devices (conveyors, HVAC)
  4. Implement 3× redundant transmission for critical alarms (50 ms spacing)
  5. Deploy 3 redundant coordinators (one per building) for fault tolerance
  6. Monitor per-device PER and adjust prioritization if collisions increase

Result:

  • Meets < 1 second latency requirement for critical alarms (actual: < 102 ms)
  • 22-year battery life (vs 16 days in beacon mode)
  • Supports 200 devices in one PAN (vs 7 GTS slots in beacon mode)
  • Simpler deployment (no SO/BO tuning required)
Concept Relationships:
Superframe/Device Concept Formula/Constraint Design Impact When to Use
SO (Superframe Order) Active period = 15.36 ms × 2^SO Higher SO = more capacity, more power Increase for high-traffic networks (> 10 frames/sec)
BO (Beacon Order) Beacon interval = 15.36 ms × 2^BO Higher BO = longer sleep, lower latency Increase for battery-powered sensor networks
Duty cycle DC = 2^(SO-BO) 25% = typical sensor network < 10% for multi-year battery life
GTS allocation Max 7 slots, CAP% = (16 - GTS) / 16 Guaranteed bandwidth vs contention capacity Use for time-critical traffic (< 1 second latency)
RFD memory 8-32 KB RAM (no routing tables) 10× cost savings vs FFD 80-90% of sensor nodes should be RFDs
Frame packing floor(102 / reading_size) readings/frame Transmission efficiency 3× 32-byte readings = 94% efficiency

88.10 See Also

Common Pitfalls

Many students flip BO and SO in the duty cycle formula. Remember: BO (Beacon Order) controls the repetition period (BI); SO (Superframe Order) controls the active duration (SD). Duty cycle = 2^(SO-BO). Higher BO means less frequent beacons; higher SO means longer active period.

The GTS (CFP) slots are carved from the tail of the superframe. The CAP must always be at least aMinCAPLength (440 symbols) long to allow association and emergency traffic. Only the remaining superframe time after the minimum CAP is available for GTS allocation.

End devices that do not wake up to receive beacons will miss the pending address field. If the coordinator has queued data for them, they never know to send a Data Request. Always implement beacon-tracking for end devices in coordinator-polled configurations.

GTS reallocation takes effect at the next beacon, not immediately. Applications that expect immediate GTS changes will experience a full beacon interval delay. Design GTS allocation changes to be requested well before the time they are needed.

88.11 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

88.12 What’s Next

Chapter Focus Why Read It Next
Deployment and Power Quiz Battery life calculations and variant selection Apply duty cycle analysis from superframe timing to real-world power budgets
Security and Interference Quiz AES-128 encryption overhead and channel hopping Evaluate how security features interact with superframe timing and GTS allocation
802.15.4 Comprehensive Review Complete specification coverage across all topics Consolidate superframe, device type, and frame structure knowledge into a unified review
802.15.4 Fundamentals Core standard concepts and PHY/MAC layers Revisit foundational concepts that underpin the superframe and device type architecture
Quiz Bank Overview Learning objectives and study strategy for all quiz sections Plan your study path across all 802.15.4 quiz topics