949  IEEE 802.15.4 Review: Device Types and Network Operations

949.1 Learning Objectives

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

  • Compare Device Types: Understand FFD vs RFD capabilities and appropriate use cases
  • Select Network Modes: Choose between beacon-enabled and non-beacon operation
  • Understand CSMA-CA: Analyze the collision avoidance mechanism and its parameters
  • Configure Superframes: Calculate beacon intervals and duty cycles for power optimization

949.2 Prerequisites

Required Chapters:

Deep Dives:

Other Review Topics:

Architecture:

Estimated Time: 15 minutes

949.3 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

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph FFD["Full Function Device (FFD)"]
        F1[Can be Coordinator]
        F2[Can be Router]
        F3[Can be End Device]
        F4[Talks to FFD and RFD]
        F5[32-256 KB Flash]
        F6[4-32 KB RAM]
    end

    subgraph RFD["Reduced Function Device (RFD)"]
        R1[Cannot Coordinate]
        R2[Cannot Route]
        R3[End Device Only]
        R4[Talks to FFD Only]
        R5[8-32 KB Flash]
        R6[1-4 KB RAM]
    end

    style FFD fill:#16A085,stroke:#2C3E50,color:#fff
    style RFD fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 949.1: FFD versus RFD device capabilities and resource requirements

949.3.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

949.3.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%

949.3.3 Device Selection Guidelines

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    START["Device Role?"] --> Q1{"Need to<br/>coordinate network?"}

    Q1 -->|"Yes"| FFD_COORD["FFD<br/>PAN Coordinator"]
    Q1 -->|"No"| Q2{"Need to<br/>route packets?"}

    Q2 -->|"Yes"| FFD_ROUTER["FFD<br/>Router"]
    Q2 -->|"No"| Q3{"Power<br/>source?"}

    Q3 -->|"Mains"| FFD_END["FFD<br/>End Device"]
    Q3 -->|"Battery"| Q4{"Cost<br/>constraint?"}

    Q4 -->|"Minimize cost"| RFD["RFD<br/>Simple Sensor"]
    Q4 -->|"Features needed"| FFD_SLEEP["FFD<br/>Sleeping End Device"]

    style START fill:#2C3E50,stroke:#16A085,color:#fff
    style FFD_COORD fill:#16A085,stroke:#2C3E50,color:#fff
    style FFD_ROUTER fill:#16A085,stroke:#2C3E50,color:#fff
    style FFD_END fill:#16A085,stroke:#2C3E50,color:#fff
    style FFD_SLEEP fill:#16A085,stroke:#2C3E50,color:#fff
    style RFD fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 949.2: Device type selection decision tree {fig-alt=โ€œFlowchart for selecting between FFD and RFD based on network role, power source, and cost constraints.โ€}

949.4 Network Operation Modes

IEEE 802.15.4 supports two fundamental operation modes:

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

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph Beacon["Beacon-Enabled Mode"]
        B1[Periodic Beacons]
        B2[Superframe Structure]
        B3[GTS Slots Available]
        B4[Synchronized Network]
        B5[Power: Higher for frequent TX]
    end

    subgraph NonBeacon["Non-Beacon Mode"]
        N1[No Beacons]
        N2[Unslotted CSMA-CA]
        N3[No GTS]
        N4[Asynchronous]
        N5[Power: Lower for infrequent TX]
    end

    Beacon -.Best for.-> U1[Scheduled Traffic<br/>Time-Critical Data]
    NonBeacon -.Best for.-> U2[Event-Driven<br/>Infrequent Updates]

    style Beacon fill:#E67E22,stroke:#2C3E50,color:#fff
    style NonBeacon fill:#16A085,stroke:#2C3E50,color:#fff
    style U1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style U2 fill:#7F8C8D,stroke:#2C3E50,color:#fff

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

949.4.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

949.4.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

949.4.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

949.5 Superframe Structure

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

949.5.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

949.5.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)

949.5.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%

949.5.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

949.6 CSMA-CA Algorithm

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

949.6.1 Unslotted CSMA-CA (Non-Beacon)

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    Start([Packet to Send]) --> Init[NB=0, BE=macMinBE]
    Init --> Delay[Random Delay<br/>0 to 2^BE-1 backoff periods]
    Delay --> CCA{CCA:<br/>Channel Clear?}
    CCA -->|Yes| TX[Transmit]
    CCA -->|No| Collision[NB++, BE=min BE+1, macMaxBE]
    Collision --> Check{NB ><br/>macMaxCSMABackoffs?}
    Check -->|No| Delay
    Check -->|Yes| Fail([FAILURE])
    TX --> Success([SUCCESS])

    style Start fill:#2C3E50,stroke:#16A085,color:#fff
    style TX fill:#27ae60,stroke:#2C3E50,color:#fff
    style Success fill:#27ae60,stroke:#2C3E50,color:#fff
    style Fail fill:#c0392b,stroke:#2C3E50,color:#fff
    style CCA fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 949.4: Unslotted CSMA-CA algorithm flowchart

949.6.2 Algorithm Steps

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

949.6.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

949.6.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

949.6.5 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

949.6.6 Slotted CSMA-CA (Beacon-Enabled)

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

  1. Backoffs aligned to slot boundaries
  2. CCA performed at slot boundaries
  3. Must have enough time in CAP to complete transaction
  4. 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

949.7 Power Management Considerations

Understanding power consumption is critical for battery-powered devices:

949.7.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

949.7.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

949.8 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

949.9 Knowledge Check

Question: What mechanism does IEEE 802.15.4 use to avoid collisions on a shared channel?

Explanation: B. 802.15.4 typically uses CSMA-CA: devices assess the channel and use randomized backoff before transmitting.

Question: What is the difference between FFD and RFD in 802.15.4?

Explanation: B. Full Function Devices (FFD) can perform all network roles. Reduced Function Devices (RFD) have simpler implementation and can only communicate with FFDs.

Question: Which statement is TRUE about beacon-enabled vs non-beacon 802.15.4 networks?

Explanation: C. Beacon-enabled mode supports a superframe with an optional contention-free period (GTS) for deterministic communication.

Question: If macMinBE = 3, what is the range of backoff periods before the first transmission attempt?

Explanation: B. With macMinBE = 3, the backoff range is 0 to (2^3 - 1) = 0 to 7 unit backoff periods.

Question: In a beacon-enabled network with BO=8 and SO=4, what is the beacon interval?

Explanation: C. Beacon Interval = 15.36 ms x 2^BO = 15.36 ms x 2^8 = 15.36 ms x 256 = 3932 ms = 3.93 seconds.

Continue to Protocols and Performance to explore higher-layer protocols built on 802.15.4 and real-world performance characteristics.