The Thread router forward the multicast message from SED twice with the broadcast destination address.

[jinpeng1989]

When the Thread router receives the multicast message from SED, it will forward it twice with the broadcast destination address. Is this behavior correct?

As shown in the figure:
frame 5803, SED (0x0401) sent a multicast message to its parent (0x0400).
frame 5816 and 5820, the parent replayed this message twice, and the destination address was the broadcast address.
Why does the Thread router forward the message twice?

[jwhui]

Yes, Thread routers forward IPv6 multicast packets by broadcasting them a couple time at the MAC layer. Because MAC broadcast messages are unacknowledged, IPv6 multicast packets are transmitted a couple times for redundancy.

[jinpeng1989]

Dear @jwhui
We set up a testing environment with the aim of analyzing the forwarding behavior of multicast messages. A strange phenomenon was discovered.

Testing Environment

• Network topology: 1 TBR + 10 REED + 1 SED

• The awakening cycle of SED is 5 minutes. After waking up, it may send multicast messages.

Expectation

• Each Router will forward the multicast message twice, and 11 Routers should forward it 22 times in total.

Test result

• No 22 multicast message forwarding was observed. For example, for the message with MID 18289, a total of 8 Thread Routers forwarded it 9 times. For the message with MID 18293, a total of 4 Thread Routers forwarded it 4 times.

When a multicast message is received, does the Thread Router simply forward it twice? Or are there any other forwarding conditions?

It is certain that Sniffer is within the radio frequency range of these devices.

[jwhui]

Can you attach the full pcap file and Thread Network key?

Some possible reasons that you may not be seeing all the expected transmissions:

1. Packet sniffer is dropping packets.
2. CCA failures cause the radios to suppress their transmissions.

OpenThread logs of one or more routers can help give more visibility.

[jinpeng1989]

The logs of the routers were not recorded at this site. If there is a combination of router logs and pcap file in the future, I will upload it.
networkkey: 984292b4b31f9d2134afefe4541e1c87
CH26_984292b4b31f9d2134afefe4541e1c87_00001_20250910151642-2.zip

[jinpeng1989]

The root cause of this issue is basically clear.

• This SED device wakes up once every minute. Every time after waking up, three or four multicast messages will be sent.
• A multicast message is divided into two MAC data frames. That is to say, the SED will send 6 or 8 MAC data frames within a few tens of milliseconds after waking up each time.
• There are 11 routers in the network. According to theory, they should broadcast 132 or 176 MAC data frames within a short period of time.

• Based on packets, it can be speculated that during the broadcast period, the channel reached saturation. That is to say, due to network congestion, many devices failed to get the chance to send data. That is exactly what you mentioned, "CCA failures cause the radios to suppress their transmissions. ".

[jinpeng1989]

Based on the 802.15.4 spec, if the result of perform 5 times of CCA is that the channel is not idle, then it will be declared that the channel access failure and discard the data packet. My question is: How long does it take to perform 5 rounds of CCA?