25 Collision Mitigation Strategies

25.1 Start With the Failure, Not the Protocol

Imagine two trackers appearing with the same name. Now imagine two radios speaking at the same time. Both are called collisions, but they need different fixes. IPv6 is a network addressing system with a very large address space.

First decide whether the clash is about identity, radio time, or shared capacity. More possible addresses can reduce random identity clashes. A wait-and-retry rule can spread radio messages. Neither fix solves the other problem. Test a duplicate address, a busy channel, and a large group recovering together. Record which limit the chosen control changes.

Use a three-column check. In the first column, name the thing that clashes. In the second, name the shared space or time. In the third, name the control. Unique assignment helps device names. Listening and waiting can help radio traffic. Smaller groups can reduce shared load. A schedule can reserve time. A retry cap can stop recovery from making the load worse.

Measure the failure before and after the control. Count repeats and lost work. Watch the busiest recovery period. Keep a clear rule for duplicate records. Reopen the design when the group size, traffic, or attacker model changes.

This opening uses simple random choices and clean failure types. Real systems mix assignment rules, attackers, retries, and changing radio load. The Practitioner section compares controls and evidence. Under the Hood derives the chance and recovery costs.

Two sensors can “collide” in two very different ways:

• they can be given the same identity, so the system cannot tell them apart; or
• their radio transmissions can overlap, so a receiver cannot decode one or both frames.

A larger identifier space helps the first problem. It does not create more airtime. Backoff helps spread retransmissions. It does not repair two records that share an identifier. Good collision design starts by naming the failure before choosing the control.

25.2 Learning Objectives

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

• separate identity, airtime, and correlated-retry failure modes;
• select a prevention and recovery pattern for each;
• explain what IPv6 Duplicate Address Detection does and does not prove;
• keep release evidence that can reveal scale drift.

25.3 Three Collision Problems

The same deployment can suffer all three. Keep separate metrics for duplicate identities, decode failures, retries, latency, and user-visible outcomes.

Checkpoint: Name the Failure

Before proposing a fix, complete this sentence: “Two ___ can choose or occupy the same ___ inside one ___, causing ___.” If the blanks are unclear, the control is premature.

25.4 Identity Assignment Patterns

25.5 Choose the Probability Target Explicitly

For (n) independent uniform choices from (m) values, the birthday approximation is

Solving for the population at a chosen probability (p) gives

For a 10% reference contour, the multiplier is about (0.459\sqrt{m}). Ten percent is not a general safety limit; it is simply a visible contour learners can compare. An identity used for billing, safety, or actuation may need a much tighter target and coordinated prevention. A recoverable laboratory token might accept more.

25.5.1 Worked decision: 200 local random identifiers

A custom commissioning tool chooses 16-bit local identifiers independently for 200 devices. The approximation gives

$$P\approx1-e^{-200\times199/(2\times65{,}536)}\approx26.2\%.$$

That is not proof that 26.2% of devices fail. It means there is about a one-in-four chance of at least one duplicate in that commissioning domain under the stated model.

Possible decisions include:

• make the tool choose from known-unused values;
• increase the random identifier space;
• partition sites into disjoint prefixes;
• reject duplicate registration atomically and generate a new value;
• stress-test a simultaneous commissioning burst and retain the logs.

The best choice depends on packet overhead, governance, offline operation, recovery cost, and the consequence of a temporary duplicate.

Checkpoint: Match Control to Variable

• Larger space increases (m).
• Partitioning reduces (n) per domain.
• Coordinated allocation changes the choice process.
• Detection and reassignment reduce duration and consequence; they do not erase the original event.

25.6 IPv6 Duplicate Address Detection

IPv6 does not “remove” address collisions. It supplies a very large address architecture and a link-scoped verification procedure.

RFC 4862 defines Duplicate Address Detection (DAD):

1. the candidate address is tentative;
2. the node sends Neighbor Solicitation messages for that address;
3. evidence that another node is using or testing it makes DAD fail;
4. the duplicate address must not be assigned to the interface.

DAD verifies uniqueness on the link according to the messages observed during the procedure. It is not a mathematical guarantee against every failure: packet loss, disabled DAD, non-conforming nodes, link partition, or later misconfiguration can undermine the result. Release evidence should include DAD configuration, duplicate outcomes, and the recovery path—not only the size “128 bits.”

25.7 Shared-Medium Controls

Avoid absolute statements such as “TDMA eliminates collisions” or “CSMA prevents collisions.” A schedule can still fail through clock error, hidden interference, reuse, or configuration mistakes. Carrier sensing reduces some overlaps but does not hear every contender. The release test should reproduce hidden-node, burst, and recovery conditions expected in the deployment.

25.8 Knowledge Check: Assignment Strategy

25.9 Knowledge Check: DAD Evidence

25.10 Collision-Control Record

One release record should connect failure, model, control, and observation.

For a shared medium, replace allocator evidence with a traffic trace: offered load, packet lengths, channel settings, received frames, retry count, p95 latency, and energy cost. Test power restoration or an alarm burst, not only steady-state traffic.

Checkpoint: Evidence Before Release

• Prove uniqueness enforcement or duplicate recovery under concurrent joins.
• Prove airtime recovery under the busiest credible burst.
• Keep user-visible outcomes beside protocol counters.

25.11 Recovery Has a Load Limit

Recovery consumes the same constrained resources as useful work. Duplicate-address repair can require discovery, reassignment, route or cache updates, application reconciliation, and audit logging. Media recovery can require acknowledgements, backoff, retransmission, longer wake time, and application timeout handling.

Do not define a universal percentage at which recovery “works.” Instead, set measurable budgets:

• maximum bounded assignment attempts;
• p95 commissioning time;
• retry count and airtime per delivered message;
• p95 command or telemetry latency;
• energy consumed per successful delivery;
• stale, duplicated, or misattributed application records;
• operator alerts and time to resolution.

If recovery becomes ordinary load, change the dominant variable: increase the value space, partition the domain, coordinate assignment, reduce offered traffic, schedule critical messages, stage reconnects, or add capacity supported by the protocol.

25.12 Knowledge Check: Recovery Pressure

Use this check to distinguish eventual delivery from acceptable recovery. First identify the outage-recovery burst, then compare p95 latency and radio energy with the control and battery budgets. A design can deliver every message and still fail its purpose if contention, backoff, and retries make commands late or drain the fleet. The defensible answer therefore changes offered load, scheduling, or retry correlation and records the new recovery evidence; it does not hide retry telemetry or treat identifier length as an airtime control.

Checkpoint: Recovery Is Capacity

• Detection does not make a collision free.
• Eventual success can still miss latency, energy, or correctness budgets.
• Persistent recovery is an escalation signal, not normal background noise.

25.13 The Birthday Problem in IoT Networks

25.13.3 The Surprise Is Pair Counting

With 23 people and 365 equally likely birthdays, there are

$$\binom{23}{2}=\frac{23\times22}{2}=253$$

pairs that could match. The exact probability that at least one pair shares a birthday is about 50.7%.

For an IoT choice space, the same pair count applies:

$$\text{pairs}=\binom{n}{2}=\frac{n(n-1)}{2}.$$

If each pair has probability (1/m) of matching, the expected number of matching pairs is

$$\lambda=\frac{n(n-1)}{2m}.$$

When choices are independent and uniform, a useful approximation is

$$P(\text{at least one duplicate})\approx1-e^{-\lambda}.$$

The approximation is most useful when (n) is much smaller than (m). The exact no-collision probability is

$$P(\text{no collision})= \prod_{k=0}^{n-1}\left(1-\frac{k}{m}\right),$$

so the exact collision probability is one minus that product.

Checkpoint: Pair Counting

• A population of (n) creates (n(n-1)/2) possible pairs.
• Pair opportunities grow approximately with (n^2).
• Compare the population with (sqrt{m}), not with half of (m), for an early warning.

25.13.5 Try It: Random-Choice Calculator

The calculator uses the (n(n-1)) approximation. Change one input at a time and describe the model before interpreting the percentage.

Checkpoint: Model Boundary

Before using the calculator, write down:

1. what value is chosen;
2. why choices are uniform and independent;
3. which devices share one collision domain;
4. what happens if two choices match.

25.13.7 From Identifier Choices to Airtime Overlap

Birthday-style pair counting can also be an early screen for random arrivals, but a radio collision is not simply an address duplicate.

Imagine 250 independent starts distributed uniformly through one hour. If each packet occupies 0.19 seconds, two equal-duration transmissions overlap when their start times are within a vulnerable interval of about 0.38 seconds. A first pair-counting estimate is

$$E(\text{overlapping pairs})\approx \binom{250}{2}\frac{0.38}{3600}\approx3.28.$$

Under an additional Poisson approximation, the chance of at least one overlapping pair is

$$1-e^{-3.28}\approx96.2\%.$$

That result is not a packet-loss rate. Turning overlap into loss needs a radio model: channel selection, bandwidth, modulation, capture effect, coding, receiver count, interference, packet lengths, acknowledgements, retry policy, and whether starts are really independent. Correlated alarm bursts can be worse than the uniform model; scheduling can be much better.

Quantity	Birthday-style screen	Deployment evidence
Identifier duplicate	Same random value in one namespace	allocator logs, duplicate alerts, reassignment audit
Airtime overlap	Starts within one vulnerable period	packet timestamps, channel/SF settings, receiver outcomes
User-visible failure	Not predicted by pair count alone	delivery ratio, latency, stale data, duplicate commands

Checkpoint: Collision Domain

• Address collisions and transmission overlaps can share pair-counting mathematics but have different consequences.
• “At least one overlap” is not the same metric as “percentage of packets lost.”
• If traffic is synchronized, independent-uniform assumptions are not credible.

25.13.10 Collision Release Budget

A release record turns the calculation into an auditable engineering decision.

Record field	Question	Evidence
Choice space	What exactly is selected, and how many usable values exist?	specification, reserved-range list, allocator configuration
Collision domain	Which simultaneous devices or events can conflict?	namespace, PAN, subnet, channel, or time-window definition
Choice process	Are choices independent, uniform, and with replacement?	generator test, allocator design, traffic trace
Consequence	What breaks if a match or overlap occurs?	failure analysis and learner-visible or operator-visible symptom
Control	Increase (m), reduce (n), coordinate, partition, schedule, detect, or reassign?	design and stress-test output
Field signal	How will drift be noticed?	duplicate count, retry rate, latency, delivery ratio, alert

Test the busiest credible window, not only the daily average. Commissioning, power restoration, a firmware rollout, or an alarm burst can make choices correlated and expand the effective (n).

Checkpoint: Release Evidence

• Keep the model inputs and acceptance target with the release record.
• Stress duplicate detection or airtime recovery under the busiest credible event.
• Compare the estimate with field evidence and revise the model when they disagree.

25.14 Summary

• Separate duplicate identity, airtime overlap, and correlated retry before choosing a control.
• Coordinated allocation, larger spaces, partitioning, and detection change different parts of the risk.
• A birthday contour is a model output, not a universal protocol limit or safety label.
• IPv6 DAD checks a tentative address on a link; it does not make every future configuration failure impossible.
• Release evidence must include peak-event behavior, recovery cost, and application outcomes.

25.15 Engineering References

• RFC 4862: IPv6 Stateless Address Autoconfiguration—tentative addresses, Duplicate Address Detection, and failure handling.
• NXP MCUXpresso SDK: Zigbee network addressing—examples of real allocation and conflict-handling behavior that changes the generic random-choice model.

25.16 What’s Next

25.17 Key Takeaway

Choose collision controls by the failure they prevent, then prove the busiest assignment or traffic path with measurements. “Large address,” “DAD,” “CSMA,” and “retry” are mechanisms—not release evidence by themselves.