74  802.15.4 Beacon Networks

In 60 Seconds

IEEE 802.15.4 beacon-enabled networks use a superframe structure controlled by Superframe Order (SO) and Beacon Order (BO) to synchronize devices and allocate Guaranteed Time Slots (GTS) for time-critical traffic. The duty cycle equals 2^(SO-BO), and the constraint BO >= SO ensures an inactive sleep period exists for power savings.

Minimum Viable Understanding

IEEE 802.15.4 beacon-enabled networks use a superframe structure controlled by Superframe Order (SO) and Beacon Order (BO) to synchronize devices and allocate Guaranteed Time Slots (GTS) for time-critical traffic. The duty cycle equals 2^(SO-BO), and the constraint BO >= SO ensures an inactive sleep period exists for power savings.

Beacon-enabled networks provide synchronized operation with guaranteed time slots. This review covers:

  • Superframe Structure: Understanding SO (Superframe Order) and BO (Beacon Order)
  • GTS Allocation: Guaranteed Time Slots for time-critical traffic
  • Duty Cycle Control: Managing active/inactive periods for power efficiency

Master these concepts for time-critical IoT applications.

“Beacon mode is like a school timetable!” explained Max the Microcontroller. “The coordinator sends out a beacon – think of it as the school bell. It tells everyone exactly when the next class starts, how long it lasts, and who has reserved time slots for special activities.”

Sammy the Sensor raised a hand. “So instead of just talking whenever I want, I wait for my scheduled slot?” Max nodded. “Exactly! The superframe has an active period where everyone can communicate, and an inactive period where everyone sleeps. The Superframe Order controls how long you stay awake, and the Beacon Order controls how often the bell rings.”

“And the duty cycle formula is really simple,” added Lila the LED. “If SO equals 2 and BO equals 6, the duty cycle is 2 to the power of (2 minus 6), which is 1/16 or about 6 percent. That means you are asleep 94 percent of the time!”

Bella the Battery beamed. “That is wonderful for me! And the best part is Guaranteed Time Slots – devices that need to send time-critical data, like a fire alarm, get their own reserved slot so they never have to wait or compete with other devices.”

74.1 Learning Objectives

By the end of this review, you will be able to:

  • Calculate beacon intervals, active periods, and duty cycles from Superframe Order (SO) and Beacon Order (BO) parameters
  • Design Guaranteed Time Slot (GTS) allocation plans that satisfy latency constraints for time-critical traffic
  • Evaluate duty cycle trade-offs between network capacity and power consumption for a given deployment
  • Differentiate beacon-enabled and non-beacon operation modes and justify the appropriate choice for a given traffic pattern

74.2 Prerequisites

Required Chapters:

Estimated Time: 30 minutes

Key Concepts

  • Beacon Frame: A periodically broadcast frame from the PAN coordinator containing superframe structure, PAN ID, GTS allocation, and pending addresses
  • Superframe Order (SO): Parameter controlling the active superframe duration; \(T_{active} = 2^{SO} imes 15.36\) ms base unit
  • Beacon Order (BO): Parameter controlling beacon interval; \(T_{beacon} = 2^{BO} imes 15.36\) ms; must have BO >= SO
  • CAP (Contention Access Period): The portion of the superframe using CSMA/CA; all non-GTS transmissions occur here
  • CFP (Contention-Free Period): The GTS portion of the superframe with guaranteed, collision-free slots; up to 7 slots maximum
  • Slotted CSMA/CA: Modified CSMA/CA within beacon-enabled networks where backoff slots align with superframe boundaries
  • Inactive Period: Time between end of active superframe and start of next beacon; devices can deep sleep to save power
  • Duty Cycle in Beacon Mode: \(DC = 2^{SO-BO}\); e.g., SO=3, BO=6 gives 2^(3-6) = 12.5% active duty cycle

74.3 Superframe Structure Overview

In beacon-enabled mode, the coordinator broadcasts periodic beacons that define the network timing structure.

Key Parameters:

  • aBaseSuperframeDuration: 15.36 ms (base timing unit)
  • Superframe Order (SO): Controls active period duration
  • Beacon Order (BO): Controls beacon interval (total cycle)
  • Constraint: BO >= SO (ensures inactive period exists)

Timing Formulas:

Active Superframe Duration = aBaseSuperframeDuration x 2^SO
Beacon Interval = aBaseSuperframeDuration x 2^BO
Inactive Period = Beacon Interval - Active Duration
Duty Cycle = Active Duration / Beacon Interval = 2^SO / 2^BO = 2^(SO-BO)

The exponential timing relationship creates a wide range of duty cycles for energy management:

\(\text{Active Duration} = t_{base} \times 2^{SO}\)

\(\text{Beacon Interval} = t_{base} \times 2^{BO}\)

where \(t_{base} = 15.36\ \text{ms}\). For SO=4 and BO=7:

\(\text{Active} = 15.36 \times 2^4 = 15.36 \times 16 = 245.76\ \text{ms}\)

\(\text{BI} = 15.36 \times 2^7 = 15.36 \times 128 = 1{,}966.08\ \text{ms}\)

The duty cycle formula simplifies elegantly:

\(\text{DC} = \frac{2^{SO}}{2^{BO}} = 2^{(SO-BO)} = 2^{(4-7)} = 2^{-3} = \frac{1}{8} = 12.5\%\)

This means devices sleep \(1 - 0.125 = 87.5\%\) of the time. With \(I_{sleep} = 3\ \mu\text{A}\) and \(I_{active} = 20\ \text{mA}\):

\(I_{avg} = 0.125 \times 20{,}000 + 0.875 \times 3 = 2{,}500 + 2.625 \approx 2{,}503\ \mu\text{A} = 2.5\ \text{mA}\)

Battery life with 2000 mAh: \(\frac{2000}{2.5} = 800\ \text{hours} = 33\ \text{days}\). Reducing to SO=3, BO=6 (still 12.5%) halves beacon interval but maintains the same duty cycle and battery life.

74.4 Interactive: Superframe Timing Calculator

74.5 Superframe Slot Structure

The active superframe is divided into 16 equal slots:

Segment Slots Description
Beacon 0 Coordinator beacon for synchronization
CAP 1-13 Contention Access Period (CSMA/CA)
GTS (CFP) 14-15 Guaranteed Time Slots (Contention-Free Period)

Example Configuration (SO=4, BO=6):

Base duration: 15.36 ms
Active superframe: 15.36 ms x 2^4 = 245.76 ms
Beacon interval: 15.36 ms x 2^6 = 983.04 ms
Slot duration: 245.76 ms / 16 = 15.36 ms per slot
Duty cycle: 245.76 / 983.04 = 25%
Inactive period: 983.04 - 245.76 = 737.28 ms

74.5.1 Knowledge Check: Superframe Timing

74.6 GTS Allocation for Time-Critical Traffic

74.6.1 HVAC Control Example

A smart building uses IEEE 802.15.4 in beacon-enabled mode for HVAC control: - SO=4, BO=6 (25% duty cycle) - HVAC commands require guaranteed delivery within 50 ms - 2 GTS slots allocated (1 slot each)

CAP Availability Calculation:

Active superframe: 16 slots
Beacon: slot 0 (implicit)
GTS allocation: 2 slots (slots 14-15)
CAP: slots 0-13 = 14 slots

Available for contention-based access:
14 slots / 16 total = 87.5%

GTS Timing:

Slot duration: 15.36 ms
GTS duration: 2 x 15.36 ms = 30.72 ms
HVAC command delivery: < 50 ms requirement met (15.36 ms per slot)

GTS capacity depends on how many frames fit within allocated slots. With SO=4:

\(T_{slot} = \frac{t_{base} \times 2^{SO}}{16} = \frac{245.76}{16} = 15.36\ \text{ms}\)

An HVAC command frame (16-byte payload + overhead) takes \(T_{frame} = 1.15\ \text{ms}\) at 250 kbps. Frames per GTS slot:

\(N_{frames} = \left\lfloor \frac{T_{slot}}{T_{frame}} \right\rfloor = \left\lfloor \frac{15.36}{1.15} \right\rfloor = \left\lfloor 13.36 \right\rfloor = 13\ \text{frames/slot}\)

With 2 GTS slots allocated, total capacity is \(13 \times 2 = 26\ \text{frames per superframe}\). Superframes per second:

\(f_{SF} = \frac{1000\ \text{ms}}{BI} = \frac{1000}{983.04} = 1.017\ \text{SF/sec}\)

Maximum HVAC frame rate: \(26 \times 1.017 \approx 26.4\ \text{frames/sec}\) for guaranteed delivery. With 30 HVAC controllers sending every 30 seconds (\(1\) frame/sec total), utilization is \(\frac{1}{26.4} = 3.8\%\) – ample headroom for bursts.

74.7 Why Increase Superframe Order (SO)?

Current Configuration (SO=4):

Active period: 245.76 ms (16 slots x 15.36 ms)
Each slot: 15.36 ms
CAP traffic: 13 slots x 15.36 ms = 199.68 ms per superframe

Increased Configuration (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 within single superframe
+ Better accommodation of mixed traffic
+ 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

To maintain 25% duty cycle with SO=5:

SO=5, BO=7
Active: 491.52 ms
Beacon interval: 15.36 ms x 2^7 = 1966.08 ms
Duty cycle: 491.52 / 1966.08 = 25%

74.8 Configuration Comparison

Parameter SO=4, BO=6 SO=5, BO=7
Active superframe 245.76 ms 491.52 ms
Beacon interval 983.04 ms 1966.08 ms
Slot duration 15.36 ms 30.72 ms
CAP slots 14 (87.5%) 14 (87.5%)
GTS slots 2 (12.5%) 2 (12.5%)
CAP duration 215.04 ms 430.08 ms
GTS duration 30.72 ms 61.44 ms
Duty cycle 25% 25%

Trade-off: Increasing SO doubles slot duration (more capacity per slot) but doubles beacon interval (higher latency to first transmission opportunity).

74.9 Knowledge Check: Beacon Networks

74.9.1 Knowledge Check: Superframe Duty Cycle

74.9.2 Knowledge Check: GTS Allocation

74.9.3 Knowledge Check: Beacon vs Non-Beacon Selection

74.10 Non-Beacon vs Beacon-Enabled Mode

Aspect Non-Beacon Mode Beacon-Enabled Mode
Synchronization None Beacon-based
Channel Access Unslotted CSMA/CA Slotted CSMA/CA + GTS
Power Management Device-controlled sleep Superframe-synchronized sleep
Time-Critical Traffic Best effort Guaranteed (GTS)
Complexity Lower Higher
Best For Event-driven, sparse traffic Periodic, time-sensitive

When to Use Beacon Mode:

  • Time-critical applications (HVAC control, industrial automation)
  • Synchronized networks with predictable traffic
  • Need for guaranteed bandwidth allocation

When to Use Non-Beacon Mode:

  • Event-driven sensors (motion, alarms)
  • Sparse, unpredictable traffic
  • Simpler deployments, lower coordinator requirements

Scenario: You are deploying an 802.15.4 beacon-enabled network in a 10-story smart building with the following device types:

  1. Fire/smoke alarms (50 devices): Send alarm frames (20 bytes) when triggered. Require < 100 ms latency. Battery-powered.
  2. HVAC controllers (30 devices): Send temperature/humidity readings (16 bytes) every 30 seconds. Require < 500 ms latency. Mains-powered.
  3. Occupancy sensors (200 devices): Send motion events (8 bytes) when triggered. Require < 1 second latency. Battery-powered.
  4. Energy meters (40 devices): Send power readings (32 bytes) every 5 minutes. No latency requirement. Mains-powered.

Goal: Configure Superframe Order (SO), Beacon Order (BO), and GTS allocation to meet latency requirements while maximizing battery life.

Step 1: Calculate Traffic Load

Frame transmission times (802.15.4 at 250 kbps, 2.4 GHz):

Device Type Payload Frame Size (w/ overhead) TX Time @ 250 kbps
Fire alarm 20 bytes 40 bytes (20 + 20 overhead) 1.28 ms
HVAC 16 bytes 36 bytes 1.15 ms
Occupancy 8 bytes 28 bytes 0.90 ms
Energy meter 32 bytes 52 bytes 1.66 ms

Average frames per second (steady state, no alarms):

Device Type Count Interval Frames/sec
Fire alarms 50 Event-driven (1/day avg) 0.001
HVAC 30 30 seconds 1.0
Occupancy 200 Event-driven (1/min avg) 3.33
Energy meters 40 300 seconds 0.13
Total 320 - 4.46 fps

Channel utilization:

Total TX time per second = (1.0 × 1.15 ms) + (3.33 × 0.90 ms) + (0.13 × 1.66 ms) + (0.001 × 1.28 ms)
                         = 1.15 + 3.00 + 0.22 + 0.001 = 4.37 ms/sec
Channel utilization = 4.37 ms / 1000 ms = 0.44% (very light load)

Conclusion: Network is lightly loaded. Latency will be dominated by beacon interval wait time, not CSMA/CA contention.

Step 2: Determine GTS Requirements

Fire alarms need guaranteed low latency (< 100 ms):

  • Criticality: Life safety (highest priority)
  • Traffic pattern: Burst (all 50 alarms may trigger simultaneously in a fire)
  • Requirement: < 100 ms from alarm trigger to coordinator reception

GTS allocation strategy:

  • Allocate 4 GTS slots for fire alarms (enough for 4 simultaneous alarms per superframe)
  • With 50 alarms, worst case = 13 superframes to deliver all alarms (if all 50 trigger at once)

Other devices use CAP:

  • HVAC, occupancy, energy meters send in Contention Access Period (no guaranteed slots)
  • Lower criticality, can tolerate collisions and retransmissions

Step 3: Choose SO and BO

Constraints:

  1. Fire alarm latency < 100 ms: Maximum beacon interval (BI) should be ≤ 100 ms
  2. Battery life for occupancy sensors: Minimize duty cycle (low SO relative to BO)
  3. Adequate CAP capacity: With 4 GTS slots, need enough CAP slots for regular traffic

Option A: SO=3, BO=5

Active superframe = 15.36 ms × 2^3 = 122.88 ms
Beacon interval = 15.36 ms × 2^5 = 491.52 ms
Duty cycle = 2^(3-5) = 25%

Latency for fire alarm:
  Worst case: Device triggers just after active period ends
  Wait for next beacon: 491.52 - 122.88 = 368.64 ms (inactive period)
  + GTS transmission: 7.68 ms (slot duration)
  Total: 376.32 ms ❌ EXCEEDS 100 ms requirement

Option B: SO=2, BO=4

Active superframe = 15.36 ms × 2^2 = 61.44 ms
Beacon interval = 15.36 ms × 2^4 = 245.76 ms
Duty cycle = 2^(2-4) = 25%

Latency for fire alarm:
  Worst case wait: 245.76 - 61.44 = 184.32 ms (inactive)
  + GTS transmission: 3.84 ms
  Total: 188.16 ms ❌ STILL EXCEEDS 100 ms

Option C: SO=2, BO=3

Active superframe = 15.36 ms × 2^2 = 61.44 ms
Beacon interval = 15.36 ms × 2^3 = 122.88 ms
Duty cycle = 2^(2-3) = 50%

Latency for fire alarm:
  Worst case wait: 122.88 - 61.44 = 61.44 ms (inactive)
  + GTS transmission: 3.84 ms
  Total: 65.28 ms ✅ MEETS < 100 ms requirement

Trade-off: 50% duty cycle doubles power consumption compared to 25%.

Alternative: SO=3, BO=4

Active superframe = 15.36 ms × 2^3 = 122.88 ms
Beacon interval = 15.36 ms × 2^4 = 245.76 ms
Duty cycle = 2^(3-4) = 50%

Latency for fire alarm:
  Worst case wait: 245.76 - 122.88 = 122.88 ms ❌ EXCEEDS 100 ms by 22.88 ms

Best option: SO=2, BO=3 (meets latency, 50% duty cycle)

Step 4: Allocate GTS Slots

Active superframe structure (SO=2):

  • Total slots: 16
  • Slot duration: 61.44 ms / 16 = 3.84 ms per slot

GTS allocation:

  • Beacon: Slot 0 (implicit)
  • CAP: Slots 0-11 (12 slots = 75% of superframe)
  • GTS: Slots 12-15 (4 slots = 25% of superframe)

Fire alarm GTS capacity:

Frames per GTS slot: floor(3.84 ms / 1.28 ms) = 3 alarms per slot
Total GTS capacity: 4 slots × 3 alarms = 12 alarms per superframe

Superframes per second: 1000 ms / 122.88 ms = 8.14
Fire alarm throughput: 12 × 8.14 = 97.7 alarms/sec

Worst case (50 alarms burst):
  Superframes needed: ceiling(50 / 12) = 5 superframes
  Total latency: 5 × 122.88 ms = 614.4 ms

Wait, this violates the < 100 ms requirement!

Realization: With 50 fire alarms, we need MORE GTS capacity to handle burst traffic.

Revised GTS allocation (6 slots instead of 4):

  • CAP: Slots 0-9 (10 slots = 62.5%)
  • GTS: Slots 10-15 (6 slots = 37.5%)

Revised fire alarm capacity:

Frames per GTS slot: 3 alarms
Total GTS capacity: 6 slots × 3 = 18 alarms per superframe

Worst case (50 alarms burst):
  Superframes needed: ceiling(50 / 18) = 3 superframes
  Total latency: 3 × 122.88 ms = 368.64 ms ❌ STILL TOO HIGH

Problem: Even with 37.5% of superframe allocated to GTS, burst traffic from 50 alarms exceeds latency budget.

Solution: Use Application-Layer Alarm Prioritization

Instead of sending all 50 alarms immediately, implement:

  1. First alarm triggers immediately (uses GTS): < 100 ms latency ✅
  2. Subsequent alarms (2-50) send every 500 ms: Acceptable for redundancy (first alarm already delivered)

Revised requirement:

  • First alarm: < 100 ms (meets life-safety requirement)
  • Redundant alarms: < 5 seconds (verification)

With this strategy, GTS allocation of 4 slots is sufficient:

GTS capacity: 12 alarms/superframe × 8.14 superframes/sec = 97.7 alarms/sec

For 1 immediate alarm + 49 delayed (at 2 alarms/sec):
  Immediate: 1 alarm in first available GTS (< 100 ms) ✅
  Delayed: 49 alarms over 24.5 seconds (acceptable for verification)

Step 5: Calculate Power Consumption

Occupancy sensor (battery-powered, SO=2, BO=3, 50% duty cycle):

Active period: 61.44 ms per 122.88 ms cycle
Sleep period: 61.44 ms per cycle

Active current: 20 mA (listening during CAP)
Sleep current: 3 µA = 0.003 mA

Average current = 0.50 × 20 mA + 0.50 × 0.003 mA = 10.0015 mA ≈ 10 mA

Battery life (2000 mAh CR123A):
  2000 mAh / 10 mA = 200 hours = 8.3 days ❌ UNACCEPTABLE (target: 1 year)

Problem: 50% duty cycle drains battery too quickly.

Solution: Allow occupancy sensors to sleep through beacon cycles

Modified MAC behavior (optional beacon tracking):

  • Occupancy sensors track beacons but do NOT wake for every beacon
  • They wake every Nth beacon (e.g., N=10)
  • When triggered, they wake immediately and send in the next available superframe

Effective duty cycle with beacon skipping (N=10):

Wakeups per second: 8.14 / 10 = 0.814 wakeups/sec
Active time per wakeup: 61.44 ms
Total active time per second: 0.814 × 61.44 ms = 50 ms

Effective duty cycle: 50 ms / 1000 ms = 5%

Average current = 0.05 × 20 mA + 0.95 × 0.003 mA = 1.003 mA ≈ 1 mA

Battery life: 2000 mAh / 1 mA = 2000 hours = 83 days

Still not ideal, but closer to target. Let’s reduce duty cycle further.

Option: Use non-beacon mode for occupancy sensors

Occupancy sensors are event-driven (motion-triggered), not periodic. Beacon mode adds unnecessary synchronization overhead.

Hybrid network:

  • Fire alarms + HVAC: Use beacon mode (SO=2, BO=3) with GTS
  • Occupancy sensors + energy meters: Use non-beacon mode (wake on event, transmit immediately)

Occupancy sensor power in non-beacon mode:

Motion events: 1 per minute average = 0.0167 events/sec
Transmission time: 0.90 ms per event
Duty cycle: 0.0167 × 0.90 ms / 1000 ms = 0.0015%

Average current = 0.000015 × 15 mA (TX) + 0.999985 × 0.003 mA (sleep) = 0.003225 mA ≈ 3.2 µA

Battery life: 2000 mAh / 0.003225 mA = 620,155 hours = 70.8 years ✅

Final Configuration:

Beacon-enabled subnetwork (fire alarms, HVAC):

  • SO=2, BO=3 → 50% duty cycle, 122.88 ms beacon interval
  • GTS: 4 slots (25% of superframe) for fire alarms
  • CAP: 12 slots (75%) for HVAC and overflow

Non-beacon subnetwork (occupancy sensors, energy meters):

  • Unslotted CSMA/CA
  • Devices sleep freely, wake on event
  • 70.8-year battery life for occupancy sensors

Coordinator behavior:

  • Transmits beacons every 122.88 ms for beacon-enabled devices
  • Accepts non-beacon frames outside active superframe from occupancy/energy devices

Step 6: Verify Latency Requirements

Device Type Mode Latency Requirement Actual Latency Meets?
Fire alarm (first) Beacon GTS < 100 ms < 65 ms (worst case wait + GTS) ✅
Fire alarm (redundant) Beacon GTS < 5 seconds < 500 ms (delayed by app logic) ✅
HVAC Beacon CAP < 500 ms < 200 ms (beacon wait + CSMA/CA) ✅
Occupancy Non-beacon < 1 second < 10 ms (immediate TX) ✅
Energy meter Non-beacon No requirement < 50 ms (CSMA/CA) ✅

All requirements met!

Step 7: Network Management

Coordinator responsibilities:

  • Beacon transmission every 122.88 ms
  • GTS slot assignment for fire alarms (pre-allocated)
  • Accept non-beacon frames from occupancy/energy devices

Device association:

  • Fire alarms request GTS during association (indicate criticality)
  • HVAC, occupancy, energy meters associate as CAP-only devices

Monitoring:

  • Track per-device PER (Packet Error Rate)
  • Alert if fire alarm GTS utilization exceeds 80% (need more slots)
  • Monitor beacon reception at edge devices (ensure coverage)

Key Lessons:

  1. Latency drives BO selection — For < 100 ms latency, BO ≤ 4 (beacon interval ≤ 245.76 ms)
  2. GTS is for burst traffic, not sustained load — With 50 alarms, GTS handles first alert; application logic staggers redundant transmissions
  3. Duty cycle kills battery life — 50% duty cycle = 8.3 days; 5% = 83 days; event-driven = 71 years
  4. Hybrid beacon/non-beacon is powerful — Critical devices use beacon mode for guaranteed latency; event-driven devices use non-beacon for power efficiency
  5. Real-world deployments need application-layer intelligence — MAC layer provides primitives (GTS, CSMA/CA); application layer provides smart traffic management

74.11 Concept Relationships

Concept Formula/Value Impact
Beacon Order (BO) Controls beacon interval 15.36 ms × 2^BO
Superframe Order (SO) Controls active period 15.36 ms × 2^SO
Duty Cycle 2^(SO-BO) Power consumption
GTS Slots Up to 7 slots Deterministic latency
CAP Contention period CSMA-CA traffic

Common Pitfalls

The beacon interval (BO) must be >= superframe order (SO). Setting BO < SO is invalid — the beacon would arrive before the current superframe finishes. This error is easy to make when mistakenly thinking BO controls the active period.

Every beacon period requires transmitting the beacon frame itself. For very short beacon intervals, beacon overhead becomes a significant fraction of channel time. Calculate beacon duty cycle (beacon frame transmission time / beacon interval) separately from data traffic.

GTS requests can fail silently if all 7 available slots are already allocated. Applications must handle GTS allocation failure gracefully by falling back to CAP/CSMA/CA access. Assuming GTS is always available causes application failures in dense deployments.

During inactive periods between beacons, device clocks drift. With long inactive periods (high BO - SO), clock drift can cause a device to miss the next beacon. 802.15.4 specifies clock accuracy requirements; always verify your hardware meets them for your chosen beacon interval.

74.12 Summary

This beacon networks review demonstrated:

  • Superframe Timing: SO controls active duration, BO controls beacon interval
  • GTS Allocation: 87.5% CAP available with 2 GTS slots allocated
  • Duty Cycle Control: BO-SO difference determines duty cycle (25% for SO=4, BO=6)
  • Design Trade-offs: Higher SO increases capacity but requires proportional BO increase to maintain duty cycle

74.13 See Also

74.14 What’s Next

Chapter Focus
802.15.4 Review: Security AES-128 security overhead, channel hopping, and self-healing mesh mechanisms
802.15.4 Review: Frame Efficiency Frame structure analysis and protocol overhead calculations
802.15.4 Review: Power Management Battery life analysis and duty cycle optimization strategies