Chapters

31 IEEE 802.15.4: Collision Analysis

iot
wireless
ieee-802-15-4

31.1 Start With the Decision

A weak IEEE 802.15.4 link may come from a few colliding senders. Sparse tests can find them without checking every pair.

31.2 Route Overview

This is part 1 of 2. Continue with IEEE 802.15.4: Roles, Sleep, and Topology.

31.3 Part Objectives

  • Apply group testing to sparse wireless collisions.
  • Relate wavelength and link evidence to test design.

31.4 Chapter Roadmap

  • Start With the Wireless Story
  • In 60 Seconds
  • Phoebe’s Field Notes: Why “Weak Link” Evidence Should Name A Wavelength
  • Quick Check: 802.15.4 Advanced
  • Advanced Means Evidence-Driven
  • Advanced Decision Path
  • CSMA/CA Tuning
  • Beacon Scheduling And GTS
  • Reservation And Random Access Tradeoff
  • Sparse Collision Identification

31.5 Start With the Wireless Story

Latency is the time a message takes to arrive. A payload is the useful data inside that message. Picture many warehouse sensors that all wake after a door opens and try to send at once.

Measure the failed behavior first. Count clashes, retries, delay, lost messages, radio time, and battery cost. Then decide whether small tuning, set send times, reserved slots, or a different layout fits the traffic.

Check the cost of order. A schedule can cut clashes but needs shared time and may waste empty slots. Random access is simple under light use but can fail in a burst. Extra security and headers also leave less room for useful data.

This warehouse story cannot make one advanced method the default. It does not prove sleep life, channel fit, or a rare collision scheme. Each method needs measured assumptions and a fallback.

Use the Practitioner sections to build the traffic and change record. Use Under the Hood for channel access, timing, frame cost, and device roles. The deeper work explains when the simple burst needs more than tuning.

Walk the door burst. Count all nodes. Count who wakes. Count each useful byte. Count each full frame. Count each reply. Count each retry. Mark the first send. Mark the last send. Mark each clash. Mark each lost event. Mark each late event.

Try light use first. Let nodes wait at random. Keep the same channel. Watch delay. Watch energy. Add more nodes. Open the door again. Find the point where results fail. Do not tune before that point is clear.

Try small tuning. Change one wait range. Repeat the same burst. Keep all other facts. Compare clashes. Compare delay. Compare radio time. Compare missed events. Reject a gain that only moves the harm.

Try a schedule. Give each group a time. Share the clock. Wake for the slot. Send once. Leave an alarm path. Lose the clock. Check recovery. Leave one slot empty. Count wasted time. A schedule pays for order with time care.

Try a reserved slot. Give it to urgent work. Keep normal work outside. Fill the normal queue. Send an alarm. Check its delay. Remove the urgent node. Check unused space. Decide whether the promise is worth that space.

Check sleepy nodes. Let one sleep long. Change its parent. Lose one message. Hold a reply. Check how long state stays. Check battery cost. Check the next wake. Do not assume an always-awake path.

Check frame cost. Start with the useful data. Add the address. Add the check. Add security. Add any mesh part. Add any larger-network part. Compare the final frame. A small reading may carry a large coat.

Check place and channel. Move a shelf. Add metal stock. Start another radio. Change the channel. Change the band. Move one parent. Repeat the burst. Keep the same test time. Record which change caused which result.

Check the rare method. State every guess. State how few nodes send. State the shared clock need. State the error rule. Add a false sign. Add a missed sign. Compare it with the plain method. Keep it only when proof beats added work.

Close the change record. Keep the old result. Keep the new result. Keep the traffic shape. Keep the site state. Keep the energy cost. Keep the time cost. Keep the failure path. Retest after layout, load, code, or security changes.

Advanced 802.15.4 work is mostly contention management. Start with the collision or scheduling problem, then examine beacon order, superframe order, GTS, slotted access, sleepy devices, frame overhead, and the records that prove the trade-off worked.

31.6 In 60 Seconds

Advanced 802.15.4 design is about evidence, not clever mechanisms in isolation. Before changing channel access, scheduling, device roles, frequency band, or frame format, a reviewer should know what behavior is failing and what measurement proves it.

The advanced topics in this chapter focus on:

  • when CSMA/CA tuning is enough
  • when beacon scheduling or guaranteed slots may help
  • when sparse collision identification is worth considering
  • how full-function and reduced-function device roles affect topology and sleep
  • how frequency band and physical layout affect reliability
  • how frame, security, and adaptation overhead reduce usable payload
  • what evidence record is needed before accepting an advanced 802.15.4 decision

Group testing is included as a useful collision-identification model for sparse activation. It should not be treated as a default 802.15.4 MAC feature. It is an advanced design idea that needs careful assumptions about timing, synchronization, device identity, RF errors, and latency.

The mathematical gist. At 2.4 GHz the wavelength is 0.125 m and a 10 m midpoint Fresnel radius is 0.559 m. At 915 MHz they become 0.328 m and 0.905 m. The lower band therefore needs 1.62 times the geometric clearance, while 2.4 GHz pays 8.38 dB more free-space loss and makes a 0.30 m shelf 2.40 wavelengths wide instead of 0.915.

Math Bridge · guided foundationsWhy does sub-GHz need more clear space yet lose less signal?Let Eddie connect wavelength, Fresnel clearance, obstacle scale, and free-space loss.

31.7 Learning Objectives

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

  • identify which evidence should drive an advanced 802.15.4 decision
  • compare CSMA/CA tuning, scheduled access, and sparse collision-identification approaches
  • explain the Boolean OR model used in group-testing-style collision identification
  • recognize when sparse activation makes group testing attractive and when it does not
  • review device role, sleep, frequency, topology, and frame-overhead tradeoffs
  • create an evidence record for advanced 802.15.4 review decisions
  • avoid overstating theoretical gains without deployment measurements
Quick Check: 802.15.4 Advanced

31.8 Advanced Means Evidence-Driven

Advanced 802.15.4 work usually begins after a basic network already exists.

Common triggers include:

  • repeated collisions during event bursts
  • missed packets after many sleepy devices wake together
  • poor battery life from too much listening or retransmission
  • latency that is too high for a bounded control window
  • gateways that cannot keep up with association or reporting bursts
  • payloads that do not fit after headers, security, and adaptation overhead
  • weak links caused by band choice, antenna placement, foliage, walls, or interference

Do not start by choosing a technique. Start by writing the failure claim:

  • What is failing?
  • Which devices are affected?
  • How often does it happen?
  • Is it a collision, weak signal, stale routing, bad scheduling, frame overhead, or application burst problem?
  • What measurement would prove the fix helped?

31.9 Advanced Decision Path

Before selecting an advanced 802.15.4 mechanism, inspect Figure 31.1 to keep the choice tied to a measured failure. The route distinguishes collision evidence from timing, payload, and coverage constraints.

Flow diagram for an advanced 802.15.4 review: observed warehouse burst failure, CCA retry loss and timing evidence, CSMA tuning or GTS or sparse identification choice, bounded normal plus stress test, and review record.
Figure 31.1: Evidence-first advanced 802.15.4 decision path for a warehouse burst, moving from measured retries and missed reports through channel evidence, the smallest matching mechanism, bounded testing, and a review trigger.

Read Figure 31.1, start with the warehouse burst evidence, follow the branch that matches the observed constraint, and choose the smallest relevant mechanism before running a bounded test. This preserves the chapter’s evidence-first narrative: complexity is justified only by a repeatable improvement.

Use Figure 31.1 to keep advanced design work tied to observed behavior.

The path is:

  1. State the observed failure.
  2. Collect evidence from channel, device, timing, and frame behavior.
  3. Choose the smallest mechanism that matches the evidence.
  4. Run a bounded test with normal and stress cases.
  5. Record what improved, what remained risky, and what change should reopen review.

31.10 CSMA/CA Tuning

IEEE 802.15.4 uses carrier sense multiple access with collision avoidance for contention-based traffic. The device listens before transmitting and uses random backoff when the channel appears busy.

CSMA/CA tuning can help when:

  • many devices send short bursts at similar times
  • retries are frequent but the channel is not continuously busy
  • application timing can tolerate random backoff
  • traffic can be spread out without scheduling every device
  • devices can afford the extra listening needed for backoff and clear-channel checks

Evidence to collect:

  • clear-channel assessment failures
  • retry counts
  • packet loss by time window
  • number of devices active in each burst
  • backoff and retry configuration
  • battery impact from listening and retransmission
  • gateway or coordinator receive load

CSMA/CA tuning is usually the first option because it works with the normal contention model. If the evidence shows bounded periodic traffic, scheduled access may be a better fit.

31.11 Beacon Scheduling And GTS

Beacon-enabled 802.15.4 networks can divide time into a superframe. Some traffic can use contention access, while guaranteed time slots can reserve transmission windows for specific devices.

Scheduled access can help when:

  • a small set of devices needs bounded latency
  • traffic is periodic or predictable
  • the coordinator can maintain the schedule
  • devices can synchronize to beacons
  • the schedule is stable enough to justify overhead

Scheduled access can fail when:

  • devices join and leave frequently
  • many devices need slots at the same time
  • clock drift or missed beacons breaks timing
  • the schedule is too rigid for bursty event traffic
  • sleeping devices spend too much energy tracking beacons

Review the schedule as evidence. Do not accept a scheduled design only because it appears orderly. Check whether the timing, beacon reception, slot allocation, and recovery behavior actually match the deployment.

31.12 Reservation And Random Access Tradeoff

Reservation systems allocate frequency and time resources tightly across active devices. Cellular systems such as LTE, GSM, and NB-IoT use this managed approach because the network can coordinate the active set and amortize scheduling overhead across useful payloads.

Small IoT bursts often look different. A large population may have only a few devices active at once, and each active device may send only a few bits or bytes. In that regime, reservation overhead can become the bottleneck: the schedule request, grant, synchronization, and identity exchange may cost more airtime or energy than the payload itself.

Random access systems reduce that coordination burden by letting devices contend. CSMA-style access listens before transmit, which can work well but consumes energy in carrier sensing and backoff. Aloha-style access avoids much of that listening, but accepts higher collision rates. The design question is therefore not “scheduled or random” in the abstract; it is whether the measured burst size, payload size, latency target, and device energy budget justify reservation overhead, carrier sensing, or a collision-tolerant design.

31.13 Sparse Collision Identification

Sometimes the problem is not only avoiding a collision. The system may need to identify which devices were active during a burst.

This is the local 802.15.4 version of the massive multiple-access problem. Phone-centric wireless systems usually assume a moderate number of active users, larger payloads, managed synchronization, and a persistent device identity. Many IoT deployments invert those assumptions: a very large possible device population, only a few active devices at a time, short bursty payloads, tight energy budgets, and cases where the event or aggregate state matters more than a long session for every node.

Sparse collision identification is useful when:

  • the network has many possible devices
  • only a small subset is active during a burst
  • the coordinator needs to identify the active subset
  • latency can tolerate multiple query rounds
  • devices can follow a prearranged test pattern
  • the RF environment is stable enough for reliable group responses

Group testing is a model for this situation. Instead of asking every device individually, the coordinator queries groups. A group response is treated as a Boolean OR:

  • response present means at least one active device is in the group
  • no response means no active device in the group was detected

With a carefully designed test matrix, each device has a unique response pattern. The observed results can be decoded to infer the active devices. The clean classroom model is on-off keying plus energy detection: active devices transmit the bits of their assigned pattern, colliding packets combine as a Boolean OR, and the receiver decodes the active set from the combined pattern.

The scaling law is easier to test against a concrete matrix. Figure 31.2 contrasts one private identity row with shared Boolean-OR tests for two active users.

A Boolean-OR test matrix contrasts private identity slots with shared test rows and decoded active nodes. Sparse designs target fewer tests under stated noise assumptions.
Figure 31.2: Boolean-OR group-testing matrix identifies two active users with shared tests rather than one private slot per node.

Read test T1 and test T3 in Figure 31.2 together: their observed y values eliminate U2, U3, and U5 while retaining U1 and U4. The private identity row reminds us that t=N is the trivial design; sparse recovery targets t proportional to d log N only under the stated OR and noise assumptions.

31.13.1 Group-Testing Scaling Law

Write the activity state as x{0,1}N\mathbf{x}\in\{0,1\}^N, with at most dd ones, and the test design as A{0,1}t×NA\in\{0,1\}^{t\times N}. Entry Aji=1A_{ji}=1 means device ii participates in test slot jj. With ideal on-off signaling and an OR receiver,

yj=i=1N(Ajixi),y=Ax.y_j=\bigvee_{i=1}^{N}(A_{ji}\land x_i), \qquad \mathbf{y}=A\odot\mathbf{x}.

The trivial design is A=INA=I_N: give every device a private slot. It always identifies the active set but needs t=Nt=N tests. Sparsity changes the information requirement. There are (Nd)\binom{N}{d} possible sets of exactly dd active devices, while tt binary outcomes distinguish at most 2t2^t cases, so

tlog2(Nd)dlog2 ⁣(Nd)+O(d).t\ge \log_2\binom{N}{d} \approx d\log_2\!\left(\frac{N}{d}\right)+O(d).

Suitable probabilistic or adaptive designs approach the commonly stated sparse scaling t=Θ(dlogN)t=\Theta(d\log N) under their decoding and error assumptions, instead of NN identity tests. For N=1024N=1024 and d=4d=4, the scale term is dlog2N=40d\log_2N=40, compared with 1024 private tests. Forty is not a guaranteed production slot count: constants, noise protection, nonadaptive exact-recovery requirements, synchronization, and false-positive targets can require more tests.

Decode from negative tests first. If yj=0y_j=0, every device whose column contains a 1 in row jj is inactive. Remove those columns. A candidate that survives all negative tests is possibly active; a dd-disjunct or otherwise suitable matrix ensures the remaining positive-test pattern separates all allowed active sets. In a noisy receiver, use repeated chips, threshold margins, and an error-tolerant decoder rather than interpreting one energy detection as a perfect Boolean value.

Identification can carry information as well as presence. Figure 31.3 assigns multiple columns per user so the decoder recovers identity and one payload bit together.

Five-step collision-resolving-code design where U1, U2, and U3 own code columns, U1 and U3 select columns, the receiver observes 101101, and the decoder recovers both identities and bits.
Figure 31.3: Collision-resolving code path from user-owned columns to Boolean-OR collision, active-user decoding, and payload-bit recovery.

In Figure 31.3, SELECT maps U1 to c2 for bit 1 and U3 to c5 for bit 0; COLLIDE observes only the Boolean OR 101101. RECOVER succeeds because ownership and sparsity constrain the candidates, while the repair note records what to do when that constraint is violated.

31.13.2 Collision-Resolving Code Construction

Each matrix column is a device’s on-off signature. During slot jj, active device ii transmits energy when Aji=1A_{ji}=1 and stays silent when Aji=0A_{ji}=0. Collisions are intentional: the receiver observes the bitwise OR of all active columns.

Distinct columns are enough when at most one device is active. With several active devices, two different column sets can have the same OR. The stronger construction is dd-disjunct: for every column ii and every set SS of at most dd other columns, there is a row where Aji=1A_{ji}=1 and all columns in SS are zero. That private witness prevents any union of up to dd other signatures from covering device ii.

The implementation path is:

  1. choose maximum simultaneous activity dd and acceptable false-positive/negative rates;
  2. generate or select a matrix with the required separability and balanced column weights;
  3. provision each device with its column index and test timing;
  4. align slots, transmit the on-off signature, and record received energy/confidence per row;
  5. form y\mathbf{y}, eliminate candidates contradicted by negative rows, then verify that the decoded set reproduces the positive rows;
  6. request a repair round when residuals, excess activity, or RF errors make the result ambiguous.

Identity and information can be carried jointly by assigning multiple columns per device. If device ii may send message mm, provision a codeword Ai,mA_{i,m} for every allowed message symbol. The device transmits the column matching both its identity and its information. The receiver decodes a set of (i,m)(i,m) pairs from

y=(i,m)AAi,m.\mathbf{y}=\bigvee_{(i,m)\in\mathcal{A}}A_{i,m}.

The expanded codebook must forbid choosing two messages for the same device and must remain separable for the allowed number of simultaneous users. More message choices increase the number of columns and therefore test length or decoding difficulty. Use a small bounded alphabet, include an error-detecting check, and fall back to a scheduled data exchange when payloads are longer than the joint code can carry efficiently.

In practice, RF addition is not a perfect OR. Hidden terminals, capture effect, near-far power imbalance, clock error, fading, and regulatory airtime limits can turn a logical 1 into a missed or ambiguous test. A collision-resolving design is accepted only after testing those conditions against ordinary CSMA/CA or scheduled access on the same workload.

31.14 Continue to the Next Part

Carry this evidence into IEEE 802.15.4: Roles, Sleep, and Topology, which begins with When Group Testing Is A Poor Fit.