71 802.15.4 Network Ops

In 60 Seconds

IEEE 802.15.4 defines two device types – FFDs (coordinators and routers with full MAC) and RFDs (low-cost leaf-only sensors). Networks operate in non-beacon mode (asynchronous, event-driven using unslotted CSMA-CA) or beacon-enabled mode (synchronized superframes with guaranteed time slots via slotted CSMA-CA).

Minimum Viable Understanding

The critical design decisions are: (1) FFD vs RFD – RFDs save 500x power but cannot route, so plan FFD placement first to define mesh coverage; (2) beacon vs non-beacon mode – for sensors transmitting less than once per minute, non-beacon mode uses 2-3x less power because devices avoid forced beacon wake-ups; (3) CSMA-CA parameters – macMinBE=3 and macMaxCSMABackoffs=4 are good defaults for most deployments.

71.1 Learning Objectives

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

Differentiate Device Types: Classify FFD and RFD capabilities and justify which device type suits a given deployment scenario
Evaluate Network Modes: Contrast beacon-enabled and non-beacon operation and recommend the optimal mode for a specified traffic pattern
Trace CSMA-CA Execution: Step through the unslotted and slotted CSMA-CA algorithms, predicting backoff behaviour for given parameter values
Calculate Superframe Timing: Derive beacon intervals, active-period durations, and duty cycles from BO and SO values to optimise power consumption

For Beginners: 802.15.4 Network Operations

This review covers how 802.15.4 networks operate day-to-day – forming networks, adding new devices, handling communication failures, and managing power states. Think of it as the operational manual for running a low-power wireless sensor network.

Sensor Squad: The Network Neighborhood

“Running a wireless network is like organizing a neighborhood!” said Max the Microcontroller. “Some of us are Full Function Devices – we are like houses with mailboxes that can receive AND forward mail. Others are Reduced Function Devices – they can only drop letters in the nearest mailbox.”

Sammy the Sensor raised a hand. “I am an RFD, right? I just send my readings to the nearest router.” Max nodded. “Exactly! And there are two ways to run the neighborhood. In non-beacon mode, everyone just talks whenever they have something to say – like knocking on a door any time. In beacon-enabled mode, the coordinator sends out a schedule, like a bus timetable, so everyone knows exactly when to transmit.”

Bella the Battery asked, “Which mode saves more of my energy?” Lila the LED jumped in. “Beacon mode! Because the coordinator tells you exactly when to wake up and listen. The rest of the time, you can sleep. It is like setting an alarm clock instead of staying awake all night waiting for a phone call.”

“And CSMA-CA keeps everyone from talking at the same time,” added Max. “Before transmitting, each device listens to check if the channel is clear – like raising your hand in class before speaking. If someone else is already talking, you wait a random amount of time and try again.”

71.2 Prerequisites

Required Chapters:

802.15.4 Fundamentals - Core standard introduction
Protocol Stack and Specifications - Stack architecture
Frame Structure and Security - MAC frames

Key Concepts

Network Formation: PAN coordinator selects channel, sets PAN ID, begins beacon transmission, and accepts associations
Active Scan: Device transmits Beacon Request on each channel and collects beacon responses to discover available PANs
Passive Scan: Device listens on each channel for beacons without transmitting; less disruptive but takes longer
Association Sequence: Beacon Request → Beacon → Association Request → ACK → Data Request → Association Response
Short Address Assignment: Coordinator allocates a unique 16-bit short address during association; 0x0000 = coordinator, 0xFFFF = broadcast
PAN Coordinator Election: In simple networks, PAN coordinator is manually designated; hierarchical protocols add automatic failover
Data Polling: RFD devices periodically send Data Request frames to retrieve queued messages from their parent FFD
Indirect Transmission: Coordinator buffers data for sleeping devices and delivers it upon Data Request; enables deep sleep for RFDs

Estimated Time: 15 minutes

71.4 Device Types and Capabilities

IEEE 802.15.4 defines two device types with different capabilities:

FFD (Full Function Device): Can perform all network roles
RFD (Reduced Function Device): Optimized for simple, low-cost sensing

Figure 71.1: FFD versus RFD device capabilities and resource requirements

71.4.1 Detailed Capability Matrix

Capability	FFD	RFD	Reasoning
PAN Coordinator	Yes	No	Network formation requires full stack
Router/Relay	Yes	No	Routing tables need memory
End Device	Yes	Yes	Both can be leaf nodes
Talk to FFD	Yes	Yes	Both need uplink
Talk to RFD	Yes	No	RFD only talks to parent FFD
Send Beacons	Yes	No	Coordination requires FFD
GTS Management	Yes	Request only	Allocation requires coordinator
Typical RAM	4-32 KB	1-4 KB	Memory footprint
Typical Flash	32-256 KB	8-32 KB	Code size
Power Profile	Higher	Ultra-low	RFD sleeps more
Cost	Higher	Lower	Simpler hardware
Use Cases	Gateway, router	Sensor, actuator	Network role

71.4.2 Typical Device Configurations

Device Type	Role	Hardware Example	Power Source	Duty Cycle
PAN Coordinator	Network root	Raspberry Pi + 802.15.4	Mains/PoE	100% (always on)
Router FFD	Range extender	Mains-powered sensor	Mains	100% (always on)
Sleeping FFD	Mobile device	Tablet/smartphone	Battery	1-10%
RFD Sensor	Temperature sensor	MCU + radio + sensor	Coin cell	<1%
RFD Actuator	Door sensor	Ultra-low-power MCU	CR2032	<0.1%

71.4.3 Device Selection Guidelines

Flowchart for selecting between FFD and RFD based on network role, power source, and cost constraints. — Figure 71.2: Device type selection decision tree

71.5 Network Operation Modes

IEEE 802.15.4 supports two fundamental operation modes:

Non-Beacon Mode: Asynchronous, event-driven
Beacon-Enabled Mode: Synchronized, scheduled

Figure 71.3: Beacon-enabled vs non-beacon network operation modes

71.5.1 Non-Beacon Mode

In non-beacon mode, devices operate asynchronously:

Channel Access: Unslotted CSMA-CA
Communication: Device-initiated when data available
Coordinator: Always listening (high power)
End Devices: Sleep freely, transmit when ready
Latency: Variable (depends on contention)

Best for:

Event-driven sensors (door/window, motion)
Infrequent transmissions (hourly temperature)
Mobile devices that move between networks
Simple star topologies

71.5.2 Beacon-Enabled Mode

In beacon-enabled mode, the coordinator sends periodic beacons:

Channel Access: Slotted CSMA-CA in CAP
Guaranteed Slots: GTS in CFP for deterministic access
Synchronization: All devices aligned to beacon timing
Power: Devices sleep during inactive period
Latency: Bounded by superframe structure

Best for:

Time-critical data (industrial sensors)
Scheduled data collection
Networks requiring guaranteed bandwidth
Deterministic latency requirements

71.5.3 Mode Comparison

Aspect	Non-Beacon	Beacon-Enabled
Synchronization	None	Beacon timing
CSMA-CA	Unslotted	Slotted
Guaranteed Slots	No	Yes (GTS)
Coordinator Power	High (always RX)	Medium (active period)
End Device Power	Low (sleep freely)	Medium (wake for beacons)
Latency	Variable	Bounded
Best Traffic Pattern	Event-driven	Scheduled
Complexity	Simple	Higher

71.6 Superframe Structure

The superframe is the fundamental timing unit in beacon-enabled networks:

71.6.1 Superframe Components

Component	Duration	Purpose
Beacon	1 slot	Synchronization, network announcements
CAP (Contention Access Period)	Variable	CSMA-CA for general traffic
CFP (Contention-Free Period)	Variable	GTS for time-critical data
Inactive Period	Variable	Coordinator and devices can sleep

71.6.2 Timing Calculations

The superframe timing is controlled by two parameters:

BO (Beacon Order): Controls beacon interval (0-15)
SO (Superframe Order): Controls active period duration (0-15, SO <= BO)

Formulas:

Beacon Interval (BI) = aBaseSuperframeDuration × 2^BO
                     = 15.36 ms × 2^BO

Superframe Duration (SD) = aBaseSuperframeDuration × 2^SO
                         = 15.36 ms × 2^SO

Duty Cycle = SD / BI = 2^SO / 2^BO = 2^(SO-BO)

Putting Numbers to It

How much power can we save by selecting the right BO and SO values for a sensor transmitting every 5 seconds?

Setup: Factory vibration sensor reporting 30-byte payload every 5 seconds.

Beacon Mode Power (BO=8, SO=4):

Beacon Interval: $BI = 15.36 \text{ ms} \times 2^8 = 3.93 \text{ s}$

Sensor wakes every 3.93 seconds to listen for beacons (RX current = 18 mA for 5 ms):

\[\text{Beacon Energy} = 18 \text{ mA} \times 5 \text{ ms} = 0.09 \text{ mA·s}\] \[\text{Wakeups/Hour} = \frac{3600 \text{ s}}{3.93 \text{ s}} = 916\] \[\text{Beacon Power} = \frac{916 \times 0.09}{3600} = 23 \text{ µA avg}\]

Non-Beacon Mode Power:

Sensor sleeps until 5-second timer expires, wakes only to transmit (TX = 22 mA for 3 ms):

\[\text{TX Energy} = 22 \text{ mA} \times 3 \text{ ms} = 0.066 \text{ mA·s}\] \[\text{TX/Hour} = \frac{3600}{5} = 720\] \[\text{TX Power} = \frac{720 \times 0.066}{3600} = 13 \text{ µA avg}\]

Comparison: Beacon mode = 23 + 13 = 36 µA average, Non-beacon mode = 14 µA average. Non-beacon uses 2.6× less power for infrequent transmission. On CR2032 (220 mAh): Beacon mode = 254 days, Non-beacon mode = 635 days.

71.6.3 Example Configurations

BO	SO	Beacon Interval	Active Period	Duty Cycle
0	0	15.36 ms	15.36 ms	100%
4	4	245.76 ms	245.76 ms	100%
6	3	983 ms	123 ms	12.5%
8	4	3.93 s	245 ms	6.2%
10	6	15.7 s	983 ms	6.2%
14	6	251 s (~4 min)	983 ms	0.4%
14	14	251 s (~4 min)	251 s (~4 min)	100%

71.6.4 Guaranteed Time Slots (GTS)

GTS provides contention-free access for time-critical data:

Up to 7 GTS slots can be allocated
Allocated in the CFP portion of superframe
Device requests GTS from coordinator
Guaranteed bandwidth and latency

GTS Use Cases:

Real-time control loops
Audio/video streaming (limited)
Safety-critical alarms
Time-synchronized sampling

71.6.5 Knowledge Check: Superframe Duty Cycle

71.7 CSMA-CA Algorithm

CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance) is the primary channel access mechanism:

71.7.1 Unslotted CSMA-CA (Non-Beacon)

Flowchart of the IEEE 802.15.4 unslotted CSMA-CA algorithm showing initialization of NB and BE, random backoff delay, Clear Channel Assessment, transmission on idle channel, and backoff increment with retry on busy channel until macMaxCSMABackoffs is exceeded — Figure 71.4: Unslotted CSMA-CA algorithm flowchart

71.7.2 Algorithm Steps

Initialize: Set NB=0 (number of backoffs), BE=macMinBE
Random Backoff: Wait random(0, 2^BE-1) backoff periods
CCA (Clear Channel Assessment): Check if channel is idle
If Clear: Transmit the frame
If Busy: Increment NB and BE, retry from step 2
If Max Backoffs Exceeded: Report failure

71.7.3 CSMA-CA Parameters

Parameter	Default	Range	Impact
macMinBE	3	0-3	Initial backoff exponent
macMaxBE	5	3-8	Maximum backoff exponent
macMaxCSMABackoffs	4	0-5	Max attempts before failure
macMaxFrameRetries	3	0-7	Max retransmissions

71.7.4 Backoff Period Duration

One backoff period = 20 symbol periods = 320 us (at 2.4 GHz)

BE Value	Range	Max Delay
BE = 0	0-0	0 (immediate)
BE = 1	0-1	320 us
BE = 2	0-3	960 us
BE = 3	0-7	2.24 ms
BE = 4	0-15	4.8 ms
BE = 5	0-31	9.92 ms

71.7.5 Interactive: CSMA-CA Backoff Explorer

See how backoff exponent (BE) and retry count affect maximum channel access delay.

Show code

viewof csmaMinBE = Inputs.range([0, 5], {step: 1, label: "macMinBE", value: 3})
viewof csmaMaxBE = Inputs.range([3, 8], {step: 1, label: "macMaxBE", value: 5})
viewof csmaMaxBackoffs = Inputs.range([0, 5], {step: 1, label: "Max backoffs", value: 4})

Show code

backoffPeriod_us = 320
csmaRows = {
  let rows = [];
  let be = csmaMinBE;
  for (let i = 0; i <= csmaMaxBackoffs; i++) {
    let currentBE = Math.min(be, csmaMaxBE);
    let maxSlots = Math.pow(2, currentBE) - 1;
    let maxDelay = maxSlots * backoffPeriod_us;
    rows.push({attempt: i + 1, be: currentBE, maxSlots: maxSlots, maxDelay_us: maxDelay});
    be = Math.min(be + 1, csmaMaxBE);
  }
  return rows;
}
totalWorstCase = csmaRows.reduce((sum, r) => sum + r.maxDelay_us, 0)

Show code

html`<div style="background: linear-gradient(135deg, #f8f9fa 0%, #e9ecef 100%); border-radius: 8px; padding: 20px; border-left: 4px solid #9B59B6; margin: 10px 0;">
<table style="width: 100%; border-collapse: collapse; font-family: Arial, sans-serif;">
<tr style="background: #2C3E50; color: white;">
  <th style="padding: 6px;">Attempt</th><th style="padding: 6px;">BE</th><th style="padding: 6px;">Max Slots</th><th style="padding: 6px; text-align: right;">Max Delay</th>
</tr>
${csmaRows.map(r => html`<tr style="border-bottom: 1px solid #dee2e6;">
  <td style="padding: 4px; text-align: center;">${r.attempt}</td>
  <td style="padding: 4px; text-align: center; color: #9B59B6; font-weight: bold;">${r.be}</td>
  <td style="padding: 4px; text-align: center;">0-${r.maxSlots}</td>
  <td style="padding: 4px; text-align: right;">${(r.maxDelay_us / 1000).toFixed(2)} ms</td>
</tr>`)}
<tr style="border-top: 2px solid #2C3E50;">
  <td colspan="3" style="padding: 6px; font-weight: bold; color: #2C3E50;">Worst-case total delay</td>
  <td style="padding: 6px; text-align: right; color: #E74C3C; font-weight: bold;">${(totalWorstCase / 1000).toFixed(2)} ms</td>
</tr>
</table>
</div>`

71.7.6 Performance Implications

Configuration	Behavior
Lower macMinBE	Faster initial access, more collisions
Higher macMaxBE	Less collisions, higher worst-case latency
More backoffs	Better reliability, more power consumption
Fewer retries	Lower latency, less reliability

71.7.7 Slotted CSMA-CA (Beacon-Enabled)

In beacon-enabled mode, CSMA-CA is aligned to slot boundaries:

Backoffs aligned to slot boundaries
CCA performed at slot boundaries
Must have enough time in CAP to complete transaction
Otherwise, wait for next superframe

Additional Complexity:

Battery Life Extension (BLE) mode reduces CAP duty cycle
Transaction must fit within remaining CAP
Coordinator may defer to avoid CFP overlap

71.8 Power Management Considerations

Understanding power consumption is critical for battery-powered devices:

71.8.1 Mode Power Comparison

For a sensor transmitting once per hour:

Mode	Description	Average Current	Battery Life (CR2032)
Non-Beacon	TX when needed	~3 uA	8+ years
Beacon (BO=8)	Listen every 3.93s	~640 uA	1.4 years
Beacon (BO=14)	Listen every 251s	~50 uA	~5 years

71.8.2 Why Non-Beacon Can Be More Efficient

For infrequent transmitters:

Non-beacon: Only wake for transmission (~0.003% duty cycle for hourly TX)
Beacon: Must wake for every beacon to stay synchronized
Power difference: 213x more energy with BO=8 beacons

Rule of Thumb:

Infrequent TX (<1/minute): Non-beacon typically better
Frequent TX (>1/minute): Beacon may be better
Time-critical requirements: Beacon with GTS

71.8.3 Knowledge Check: Device Type Selection

71.8.4 Knowledge Check: CSMA-CA Backoff

71.8.5 Knowledge Check: Power Mode Trade-off

71.9 Choosing BO and SO: A Practical Decision Guide

The superframe configuration (Beacon Order and Superframe Order) is one of the most impactful decisions in an 802.15.4 deployment, yet many developers use defaults without analysis. Here is a systematic approach.

Step 1: Determine your traffic pattern.

Traffic Pattern	Example	Recommended Mode
Event-driven, rare (<1/min)	Door/window sensor	Non-beacon
Periodic, infrequent (1-10/min)	Temperature sensor	Non-beacon or beacon with high BO
Periodic, frequent (>10/min)	Vibration monitor	Beacon with BO=6-8
Real-time control (<50ms latency)	Motor controller	Beacon with GTS

Step 2: If using beacon mode, select BO and SO.

The key trade-off is coordinator power vs end device power:

BO controls beacon interval: Higher BO = longer sleep = lower coordinator power, but higher end device latency
SO controls active period: Lower SO (relative to BO) = shorter active period = lower coordinator power, but less time for contention access
BO - SO determines duty cycle: Duty cycle = 2^(SO - BO)

Worked example: Industrial vibration sensor reporting every 2 seconds.

Need beacon interval > 2 seconds to avoid unnecessary wake-ups: BO >= 8 (3.93s)
Need active period long enough for 50 sensors to transmit: SO = 4 (245ms, enough for ~30 CSMA-CA transmissions)
Duty cycle: 2^(4-8) = 6.25% – reasonable for mains-powered coordinator
End device wakes every 3.93s, listens for beacon, transmits during CAP, sleeps

Worked Example: Beacon Interval Selection for Factory Vibration Sensors

Scenario: A factory has 50 vibration sensors reporting every 2 seconds. Each sensor sends a 30-byte payload. You need to select beacon-enabled mode parameters (BO and SO) that balance power consumption, latency, and reliability.

Step 1: Determine minimum beacon interval

Sensors report every 2 seconds, so beacon interval should be ≤ 2 seconds to avoid unnecessary wake-ups
BO = 8 → Beacon Interval = 15.36 ms × 2^8 = 3.93 seconds (too long, sensors wake only every 3.93s)
BO = 7 → Beacon Interval = 15.36 ms × 2^7 = 1.97 seconds ✓ (matches reporting period)

Step 2: Calculate required active period

50 sensors × 30 bytes per transmission
Frame overhead: 11 bytes (addressing) + 2 bytes (FCS) = 13 bytes → Total frame = 43 bytes
Transmission time per sensor: (43 bytes × 8) / 250 kbps = 1.38 ms
CSMA-CA overhead: ~1.5 ms average (including backoff)
ACK turnaround + ACK: ~0.5 ms
Total airtime per sensor: 1.38 + 1.5 + 0.5 = 3.38 ms
50 sensors × 3.38 ms = 169 ms minimum active period

Step 3: Select SO to provide headroom

SO = 4 → Active Period = 15.36 ms × 2^4 = 245.76 ms ✓ (45% margin for collisions/retries)
SO = 3 → Active Period = 15.36 ms × 2^3 = 122.88 ms (too tight, only 27% margin)

Step 4: Calculate duty cycle

Duty Cycle = 2^(SO - BO) = 2^(4 - 7) = 2^(-3) = 12.5%
Coordinator is active 12.5% of the time, sleeps 87.5%

Result: BO = 7, SO = 4 - Beacon every 1.97 seconds (matches sensor reporting period) - Active period 245 ms (enough for 50 sensors with collision headroom) - Coordinator duty cycle 12.5% (acceptable for mains-powered coordinator) - Sensors wake every 1.97s, listen for beacon, transmit during CAP, sleep (average current ~250 µA → 3-5 year battery life)

Decision Framework: FFD vs RFD Selection for Smart Building Deployment

Device Type	Recommended Type	Power Source	Reasoning
Temperature sensors (200 units)	RFD	CR2032 coin cell	Leaf-node only (no routing needed), sleep 99.9% of time, 5-7 year battery life required
Occupancy sensors (150 units)	RFD	CR2032 coin cell	Simple on/off reporting, infrequent transmissions (motion events), no routing function needed
Smart light switches (80 units)	FFD (Router)	AC mains	Always-on AC power available, extend mesh coverage, provide routing for battery sensors
HVAC controllers (20 units)	FFD (Router)	AC mains / PoE	Continuous power, high-bandwidth control commands, act as mesh backbone
PAN Coordinator (1 unit)	FFD (Coordinator)	AC mains / PoE	Network root, always-on requirement, manages addressing and synchronization
Door/window sensors (300 units)	RFD	CR2032 coin cell	Event-driven (open/close), ultra-low duty cycle (<0.1%), 5-10 year battery target

FFD power budget reality check:

FFD router: Always listening → 15-25 mA average current
RFD end device: Sleep 99.9% → 50 µA average current (500× difference)
On 220 mAh CR2032: FFD lasts 11 hours, RFD lasts 5-7 years

Decision rule:

Battery-powered + multi-year life required → RFD only
AC/PoE powered + need mesh extension → FFD Router
Mobile device (tablet) with user interaction → FFD End Device (can route but may sleep)

Common Mistake: Configuring Battery Sensors as FFDs for “Better Connectivity”

The Error: A building integrator configures all 200 occupancy sensors as Full Function Devices (FFDs) with routing enabled, believing this will improve mesh coverage and reliability.

Why it fails catastrophically:

FFD current consumption:
  RX mode (listening):      18 mA (always on to route packets)
  TX mode (transmitting):   22 mA (during own transmissions)
  Average duty cycle:       ~95% RX, ~5% TX
  Average current:          (0.95 × 18) + (0.05 × 22) = 18.2 mA

Battery life on CR2032 (220 mAh):
  220 mAh / 18.2 mA = 12 hours

RFD comparison (correct configuration):
  Deep sleep:               0.5 µA (99.9% of time)
  RX (beacon listen):       18 mA (0.05% of time)
  TX (own transmission):    22 mA (0.05% of time)
  Average current:          50 µA
  Battery life:             220 mAh / 0.05 mA = 4,400 hours = 5+ years

Actual deployment result:

Week 1: 30 sensors go offline (battery exhausted)
Week 2: Another 80 sensors fail
Week 3: Remaining 90 sensors critically low
Total cost: 200 sensors × $25 labor to replace batteries × 4 replacements/year = $20,000/year in maintenance

The correct fix:

200 occupancy sensors: Configure as RFD end devices
50 AC-powered light switches: Configure as FFD routers to provide mesh backbone
Result: 5-year battery life for sensors, full mesh coverage via AC-powered infrastructure

Common Pitfalls

1. Not Handling Association Failure Gracefully

Association can fail if the coordinator’s address table is full or if association is disabled. Devices must implement association retry with exponential backoff. Applications that treat association failure as fatal will leave deployed devices permanently disconnected when the coordinator temporarily rejects them.

2. Polling Rate Mismatch Between Device and Coordinator

End devices must poll frequently enough to retrieve data before the coordinator’s indirect transmission timeout expires. If the poll interval exceeds the coordinator’s macTransactionPersistenceTime, queued data is discarded. Always align poll intervals with coordinator persistence settings.

3. Forgetting That Active Scan Causes Network Disruption

Broadcasting Beacon Requests during an active scan causes all coordinators in range to transmit beacons simultaneously, potentially causing collisions. In dense deployments, active scanning by new devices disrupts existing traffic. Use passive scanning where possible in operational networks.

4. Assuming Network Operation Continues After Coordinator Loss

All management operations (association, GTS, key distribution) require the coordinator. Devices can still communicate peer-to-peer using cached addresses, but no new devices can join and GTS allocations cannot change. Plan for coordinator redundancy in critical deployments.

🏷️ Label the Diagram

💻 Code Challenge

71.10 Summary

This chapter covered device types and network operations in IEEE 802.15.4:

Device Types: FFDs can be coordinators, routers, or end devices; RFDs are optimized for simple, battery-powered sensing
Network Modes: Non-beacon for event-driven operation, beacon-enabled for synchronized access
Superframe Structure: Controlled by BO and SO, with CAP for contention and CFP for guaranteed access
CSMA-CA: Collision avoidance with configurable backoff parameters balancing latency and reliability
Power Trade-offs: Non-beacon often better for infrequent transmissions; beacon mode adds synchronization overhead

71.11 Knowledge Check

Quick Check

Matching: 802.15.4 Concepts and Characteristics

Ordering: Unslotted CSMA-CA Channel Access Sequence

71.12 What’s Next

Chapter	Focus
Protocols and Performance	Higher-layer protocols (ZigBee, 6LoWPAN, Thread) built on 802.15.4 and real-world throughput, latency, and reliability metrics
Frame Structure and Security	MAC frame formats, addressing modes, and AES-CCM security suites that protect 802.15.4 traffic
802.15.4 Topic Review	Comprehensive review hub linking all 802.15.4 sub-topics for exam preparation

71.1 Learning Objectives

71.2 Prerequisites

71.3 Related Chapters

71.4 Device Types and Capabilities

71.4.1 Detailed Capability Matrix

71.4.2 Typical Device Configurations

71.4.3 Device Selection Guidelines

71.5 Network Operation Modes

71.5.1 Non-Beacon Mode

71.5.2 Beacon-Enabled Mode

71.5.3 Mode Comparison

71.6 Superframe Structure

71.6.1 Superframe Components

71.6.2 Timing Calculations

71.6.3 Example Configurations

71.6.4 Guaranteed Time Slots (GTS)

71.6.5 Knowledge Check: Superframe Duty Cycle

71.7 CSMA-CA Algorithm

71.7.1 Unslotted CSMA-CA (Non-Beacon)

71.7.2 Algorithm Steps

71.7.3 CSMA-CA Parameters

71.7.4 Backoff Period Duration

71.7.5 Interactive: CSMA-CA Backoff Explorer

71.7.6 Performance Implications

71.7.7 Slotted CSMA-CA (Beacon-Enabled)

71.8 Power Management Considerations

71.8.1 Mode Power Comparison

71.8.2 Why Non-Beacon Can Be More Efficient

71.8.3 Knowledge Check: Device Type Selection

71.8.4 Knowledge Check: CSMA-CA Backoff

71.8.5 Knowledge Check: Power Mode Trade-off

71.9 Choosing BO and SO: A Practical Decision Guide

Common Pitfalls

71.10 Summary

71.11 Knowledge Check

71.12 What’s Next