Multicast for permanent Class C device

[frederik-funk]

I have a device which permanently runs in class C. It joins the network using OTAA and I can successfully schedule unicast downlinks. Now I would like to schedule multicast downlinks (and later also fragements / fuota) and I came across some points:

• In general I was thinking that the continous class C operation would ease the whole process and I can get rid of clock syncronization and class C session starting / stopping. Is that true?
• The lorawan multicast specification and example code (LmhpRemoteMcastSetup) always assume class A operation with a temporary switch to class B/C. Are there any pitfalls in adapting this for my case? How should I react e.g. in case of a McClassCSessionReq coming from the server? I am already in class C and I cannot send the the time until start in the answer, as there is no clock sync.
• Is there maybe an example somwhere for this case?
• Maybe not the correct place for the question, but: Has anyone experience using AWS IoT for this use case? I am able to create the multicast group, I see the group being setup on the end device. But I do not receive any downlinks (hence alle these questions).

[mluis1]

From the Remote Multicast Setup specification the multicast group setup and multicast session setup commands are almost independent.
The McGroupSetupReq/Ans commands create the multicast group (cryptographic context). This command can be used stand alone.
The McClassBSessionReq/Ans and McClassCSessionReq/Ans commands can only be used if a previous multicast group was setup.

1. The "Application Layer Clock Synchronization" and multicast session management are not mandatory.
   Please note that the clock synchronization can be achieved by using the DeviceTimeReq MAC command instead of the "Application Layer Clock Synchronization" specification. In addition the use of the MAC command will provide a more precise clock synchronization.
2. Once the multicast group is setup and you are already in Class C you can use it right away.
   For your use case what you could do when receiving the McClassCSessionReq command is just to answer as if you accepted it (clock synchronization is required).
3. I am not aware of an example for this use case.
4. No real experience with AWS IoT. However if you are using a standard FUOTA server based on the LoRa Alliance specifications I would recommend to follow that server required steps to get it working properly.

My recommendation would be to change your end-device application to use the DeviceTimeReq MAC command instead of the "Application Layer Clock Synchronization" and modify the following command to not revert to Class A at the end of the session.

LoRaMac-node/src/apps/LoRaMac/common/LmHandler/packages/LmhpRemoteMcastSetup.c

Lines 280 to 283 in 2bf36bd

	case REMOTE_MCAST_SETUP_SESSION_STATE_STOP:
	// Switch back to Class A
	LmHandlerRequestClass( CLASS_A );
	break;

With these changes your end-device will behave as expected by a standard FUOTA server.

[frederik-funk]

Thanks a lot, we will try that!