Open christoph-nils opened 2 years ago
johanstokking
commented
2 years ago Would you like to be able to create multicast devices via the integration, or only be able to schedule downlink messages to an already created multicast group?
Are you using the Remote Multicast Setup protocol with end devices? If so, what if The Things Stack takes care of that, assigns a (temporary) DevEUI for the multicast group and allows you to send downlink that way?
christoph-nils
commented
2 years ago The remote multicast setup protocol should be used. If it is possible to create the multicast group with a (temporary) DevEUI, that should be fine.
I thought it would be easier for you to give raw access to the multicast devices. Also, the raw access could be used in more ways than just for the virtual multicast session device.
johanstokking
commented
2 years ago There are indeed three issues here:
I think the best way forward is to implement (3). We should do that anyway. We will issue then temporary DevEUIs, that is also part of the new specs. We can also let Application Server signal a multicast group setup event that the AWS IoT Integration can use to create the virtual thing, so it can be used for downlink. Finally, we should indeed support (2).
So this is a slightly bigger issue. I'll leave it open here in issue triage so we'll discuss this in our internal meeting and see what we can do when and who can pick it up.
NicolasMrad
commented
2 years ago christoph-nils
commented
2 years ago https://github.com/TheThingsIndustries/lorawan-stack/issues/3244
This repository is not publicly viewable so I can't see it. Will it be introduced first in TheThingsIndustries/lorawan-stack?
johanstokking
commented
2 years ago @christoph-nils sorry about that. The integration is proprietary so we track that in proprietary repos, but it's not very helpful indeed.
What we decided on is that we first implement Remote Multicast Setup in the Application Server. That gives a proper API towards upstream integrations (including the AWS IoT Integration) for multicast.
The thing is that IoT things are created solely based on upstream events (join-accepts and uplink messages). However, multicast devices never generate those upstream events. So IoT things for multicast devices are currently not being created. We would need to change quite some stuff to support downlink messages published to the AWS IoT Core MQTT downlink topic to be scheduled as downlink. Basic things like device identifiers, but also the AppSKey, is kept in the IoT thing so it needs to be there to support downlink.
Summary
Add multicast devices creation & multicast downlink scheduling to the AWS IoT Integration.
Why do we need this?
This will provide the capability to use the AWS IoT Integration for FUOTA.
What is already there? What do you see now?
At the moment it is possible to create simple devices with parameters as thing attributes. The thing name is the LoRaWAN DevEUI. Multicast devices created in TTI will not sync with the AWS Integration. They do not have a DevEUI.
What is missing? What do you want to see?
Some multicast device specific parameters are not available as thing attributes and are therefore missing for creating multicast devices. The Thing name could be synchronized with the device ID of the multicast device. The message JSON object requires additional fields to select the gateways used for the downlink and to specify the time of transmission.
Environment
...
How do you propose to implement this?
...
How do you propose to test this?
...
Can you do this yourself and submit a Pull Request?
...