About Multicast groups

Multicast is a crucial feature for downlink transmission, it allows sending the same downlink frame to many devices at the same time. This is particularly interesting for Class B and Class C devices acting as actuators where the application server can control many end-devices by sending a single downlink frame (for instance, switch on/off streetlamps or gas meters...etc.).

Multicast feature drastically optimizes the downlink capacity and avoid overload of the air-interface resources for many class B/C use cases. Additionally, multicast is a mandatory feature to support Firmware Upgrade Over the Air (also known as FUOTA).

How multicast works

To support multicast, an end-device must be configured with a multicast DevAddr, multicast NwkSKey and multicast AppSKey in addition to its unicast DevAddr/session keys.

While the unicast DevAddr/session keys are distinct for each device, the multicast DevAddr/session keys must be the same for all the devices belonging to the same multicast group. Therefore, a multicast group consists of a "virtual" device with a DevAddr, NwkSKey and AppSKey.

End-devices must monitor both unicast and multicast addresses.

There are two ways to configure end-devices with the multicast group DevAddr/session keys:

1. Either via a personalized configuration hardcoded in the device stack, which is analogous to using ABP mode for multicast, even if the device uses OTA mode for unicast.

2. Or using over-the-air configuration via application layer configuration messages, as specified by the LoRa Alliance.

From ThingPark standpoint, the network server does not know the mapping between the "virtual" multicast device and the "real" devices associated to it. The following figure illustrates the end-to-end downlink transmission flow:

To support multicast, end-devices must either use class B or class C mode. Native Class-A devices can still use multicast if they are configured by application-layer to switch to class B or C during the multicast session scheduling period. For more details, see the LoRaWAN® Remote Multicast Setup Specification v1.0.0.

Downlink packet transmission in multicast mode

As specified by LoRaWAN®, downlink multicast frames use "unconfirmed" mode, and do not include any MAC commands.

• Class B multicast session: For Class B multicast, end-devices listen to the multicast address over specific pingslots that are not necessarily the same as unicast ping slots. The multicast pingslot periodicity is directly provisioned in the Multicast Group, alongside the multicast pingslot data rate and channel frequency.

  Since class B operation implies that base stations are perfectly synchronized by GPS, a downlink multicast frame can be safely transmitted synchronously over all the base stations without any risk of collision, leveraging the constructive interference effect which is already the case for the synchronized transmission of beacon signals.

  note

  In case the base station cannot transmit the multicast frame over the programmed pingslot, it automatically reattempts transmission over the remaining available pingslots within the current and next beacon periods (like unicast mode) before sending a failure indication back to the network server.

• Class C multicast session: For Class C multicast, end-devices must use the same RX2 data rate and frequency for both unicast and multicast modes. The multicast frequency and data rate are configured in the Multicast Group.

  To avoid radio collision between the different base stations participating to the same multicast session, the network server applies the collision-avoidance algorithm as illustrated by the following figure:

  

• For all the base stations that are GPS-synchronized (green base stations in the above figure): The network server schedules a simultaneous transmission like for class B devices => Perfectly synchronized transmissions (with +/- 1 μs precision) mitigate collision risk.

• For other base stations (not GPS-synchronized), the network server uses a clustering algorithm to group the base stations that are sufficiently spaced away into the same cluster whereas neighbor base stations are put in different clusters. The minimum distance required between two base stations to share the same cluster is defined as "Class C Collision Avoidance Distance" and set to 7 Km by default.

  The network server schedules multicast transmission sequentially for each cluster: all the base stations within the same cluster transmit their downlink multicast frames at the same time (interference is mitigated by the distance separating those base stations) while the multicast transmission over distinct clusters do not overlap in time to avoid collision. This case is illustrated by the orange gateways in the figure above.

  note

  In case the base station location is not provisioned in ThingPark (blue gateways in the figure above), the network server considers each base station as a separate cluster.

In case the first transmission scheduled by the network server fails for some base stations (eventually after the base station autonomously reattempts the transmission before giving up), the network server shall re-attempt the transmission of the multicast frame until the maximum number of attempts is reached (set to 3 attempts by default).

The following figure illustrates the retransmission scheme used by the network server for multicast frames:

Multicast summary reports

The network server reports the transmission status of each multicast frame to the Application Server, in Multicast Summary Reports. To learn more, see API reference: LRC to AS.

The transmission status of multicast packets is also displayed in the Multicast Group dashboard, with the following color legend:

Type	Downlink status	Report type	Percentage of successful downlink transmissions
	In progress	Partial	≥ 80%
	In progress	Partial	≥ 30% and < 80%
	In progress	Partial	< 30%
	Terminated	Final	100%
	Terminated	Final	≥ 80%
	Terminated	Final	≥ 30% and < 80%
	Terminated	Final	< 30% Note Downlink partially sent (< 30%) is considered if no base station was associated with the multicast group when the multicast downlink was transmitted.