Wi-Fi Multicast Telemetry: Design Delivery Evidence Without Assuming Unicast Reliability
One successful multicast send does not prove that every intended Wi-Fi receiver obtained the record. Define the required receiver set, collect receiver-specific completion evidence and distinguish ordinary group-addressed transmission from AP replication into unicast frames. A useful telemetry contract states whether success means any receiver, every required receiver, or a declared quorum.
This guide uses Linux 6.12 mac80211 and hostapd 2.11 as inspectable implementations, with RFC 9119’s multicast analysis. It concerns application telemetry on an authorized infrastructure WLAN. Discovery protocols, DTIM tuning and OPC UA delta reconstruction are separate topics. No multicast radio experiment was performed.
Identify the actual wireless hop
For ordinary group-addressed Wi-Fi delivery, the AP does not receive an individual acknowledgement from every destination and therefore cannot infer complete group reception. RFC 9119 also describes rate, power-save and replication tradeoffs, along with enhancement mechanisms. Do not generalize the ordinary case to every enhanced multicast implementation. Record which mechanism the deployed AP actually uses. RFC 9119, sections 3.1 and 4.6–4.7
The distinction is per hop. A station sending an IP multicast packet upstream can transmit it to the AP’s unicast receiver address. An acknowledgement on that hop only establishes the corresponding link exchange; it does not prove that the AP subsequently delivered the multicast payload to other stations. In Linux 6.12, the transmit preparation checks the 802.11 receiver address when setting the ordinary no-ACK multicast flag. Linux 6.12 ieee80211_tx_prepare() and header construction
Capture or obtain equivalent supported evidence at the AP’s wireless egress. An IP destination alone does not reveal whether the air carried one group frame or multiple unicast copies. Preserve the observed rate and frame addressing instead of substituting the high unicast bitrate displayed for one station.
Define success before counting packets
| Contract | Required evidence | Typical hidden failure |
|---|---|---|
| Best-effort observation | Per-receiver valid arrivals and missing sequences | Sender counts mistaken for reception |
| All required receivers by deadline | One timely validated result per required receiver and record | Good average hides one persistently missing device |
| Quorum by deadline | Explicit eligible membership and sufficient distinct completions | Duplicates counted as different receivers |
| Latest-state service | Freshness and replacement policy per receiver | Old repair traffic displaces a newer useful state |
Assign a sender epoch and record identity. Freeze the required membership for each operation or define an explicit membership-version rule. A receiver that leaves unexpectedly remains a failed obligation under an all-required contract; silently deleting it from the denominator makes delivery appear better. A newly joining receiver need not be accountable for records sent before its admission unless the protocol promises replay.
Choose a bounded feedback and repair design
If the product requires delivery evidence, use an application protocol that supplies authenticated receiver identities and record acknowledgements, or collect equivalent trusted receiver logs during qualification. A group address is not a membership roster, and a link ACK is not proof that the receiving application validated or stored the sample.
For small fixed groups, individual acknowledgements may be practical. For larger groups, account for feedback bursts, scheduling, aggregation or a supported reliable-multicast protocol. Negative acknowledgements alone need a defined way to detect a silent receiver; silence cannot simultaneously mean “nothing missing” and “device unreachable.” Do not invent an unbounded retry loop around every absent response.
Declare a repair cutoff and memory limit. Preserve record identity across retries so duplicate arrivals do not repeat downstream effects. If a record is obsolete or past its deadline, report that outcome rather than keeping it indefinitely in a repair queue. Repair over unicast is an architectural option to qualify, not a guarantee that the original multicast operation met its deadline.
Treat multicast-to-unicast as a different workload
Hostapd 2.11’s multicast_to_unicast requests separate station-addressed copies for supported ARP, IPv4 and IPv6 traffic. Its configuration warns about changed receiver expectations and explicitly says this is not IEEE 802.11 DMS. Verify driver support and actual egress behavior before claiming the option took effect. hostapd 2.11 multicast-to-unicast configuration
Replication can change acknowledgement behavior, rates and airtime consumption. Compare it at the required receiver count and payload cadence; a one-receiver trial cannot expose replication scaling. Also verify group membership and forwarding policy so unintended stations do not become part of the delivery experiment. Keep application validation and deadline rules unchanged across comparisons.
Run a multi-receiver loss campaign
- Inventory membership and topology. Use dedicated test receivers with stable test identities. Record AP/client versions, multicast forwarding behavior, isolation policy and awake/sleep state. Establish the required set for each run.
- Send a finite numbered workload. Define payload size, rate, sender epoch and observation cutoff. Log enqueue failures separately from records actually admitted to the transport.
- Collect receiver outcomes. Record unique validated arrivals, duplicates, late arrivals and missing records per receiver. Use synchronized timestamps with stated uncertainty or a same-clock acknowledgement deadline with its extra return-path cost.
- Vary one condition. Compare receiver count, representative background load and supported receiver power states. Do not keep every device awake with continuous probes if the product normally sleeps.
- Compare the supported delivery modes. Repeat ordinary group delivery, qualified AP replication or application unicast using the same useful workload and membership. Record total traffic and feedback costs as well as completion.
- Exercise membership changes. Join a receiver, remove another unexpectedly and restart one receiver. Verify that epoch changes and missing obligations remain visible rather than being rewritten into success.
For a synthetic four-record example, receivers R1, R2 and R3 each receive three records, but their missing records differ. If only record one reaches all three, each receiver has 75% completeness while all-required completeness is 25%. Combining all observed sequences into one set would misleadingly show that every record arrived somewhere.
A Python 3.12.14 analysis fixture verified this receiver matrix, duplicate suppression, late completion, changing expected membership and rejection of unexpected receiver evidence. It did not transmit packets or estimate radio loss. Target tests must establish actual forwarding, contention, sleep behavior and protocol processing.
Release with per-receiver results, the all-required or quorum metric, deadline failures and repair costs. Multicast remains useful when its measured delivery contract fits the application. It should not inherit unicast reliability claims merely because the sender reported success.
