Multicast registration and multicast downlink #3427
Comments
|
@MatteMoveSRL thanks for your issue. If you are a TTI customer with a support plan, best is to use the support channel. We use issue templates here so that we get information in a structured way.
We need reproduction steps for this, please edit your post to follow the issue template.
See https://thethingsstack.io/devices/class-c-multicast/, then the second note under Multicast Group, and the example below with how to schedule downlink. |
johanstokking
changed the title
|
@johanstokking Thanks a lot for the answers! I Updated my issues tring to get the information in a structured way as you suggested. I hope that it's understandable I still don't understand this two points:
Thank you a lot in advance for your time and your reply. |
Apart from the absolute time, which is in the past, it doesn't look wrong. But, is
We haven't implemented the Remote Multicast Setup protocol in the Application Server yet. So we don't correlate this. The multicast device is a virtual device. If your end device understands downlink on both the unicast and the multicast channel, you should be fine. |
|
@johanstokking Thanks for the quick reply
Yes the gateway is connected and i used "gw-test" instead of "gtwid" in the mosquitto command.
No I don't see any downlink arriving in my gateway "live data" but instead i saw some data arriving in the section "live data" of my application "foo":
So do you mean that the downlink message arrives to all OTAA devices connected to the gateway like a broadcast message and not to a specific group of OTAA devices ? |
Please subscribe to the gateway event log with; $ ttn-lw-cli events --gateway-id gtw-testAlso enable debug logs ( Then schedule the downlink message and observe logs and gateway events.
Yes, that is how LoRaWAN works. Every class C device listening on that frequency with that specific data rate will receive the message. They will look at the DevAddr of the message to see if it matches a (multicast) session that they have session keys for. If so, they process the message and see if the NwkSKey matches the MIC etc. Speaking of which; are you sure that the frequency and data rate are correct? Class C uses the RX2 parameters for this. The end devices should be listening on those parameters for the multicast downlink frames. |
|
@johanstokking Thanks for your reply.
Thanks I got it. You were really clear.
I'm pretty sure that i've set the right parameters. In my opinion the problem could be how I schedule downlink with MQTT or something regarding the gateway. I'll try this week following your good tips and get back to you. |
|
Please use the forums for additional questions; we don't answer questions on GitHub issues. Please see the issue templates for that also. |
Hello every one,
Summary
Issues regarding MULTICAST DEVICES REGISTRATION and MULTICAST DOWNLINK via the console and CLI
Steps to Reproduce multicast registration via the console
I added an end-device with the following parameter:
I scheduled a multicast downlink via the console
Observation: Multicast Address, Multicast NwkSKey and Multicast AppSKey are the same setup multicast parameters that i've generated inside my physical OTAA End Devices following the protocol released by Lora Alliance " LoRaWAN® Remote Multicast Setup Specification v1.0.0 (https://lora-alliance.org/resource-hub/lorawanr-remote-multicast-setup-specification-v100)".
What do I see now?
The registration goes fine and the downlink was scheduled succesfully
What is the problem?
After the registration I noticed that the enrolled multicast device doesn't result as Activation mode multicast but instead as Activation mode ABP. Why is this so? Can I schedule a valid multicast downlink via the console even if the device is in Activation mode ABP?
Steps to Reproduce multicast registration via CLI
Following The Things Stack instruction (https://thethingsstack.io/devices/class-c-multicast/) :
Add multicast device :
$ ttn-lw-cli end-devices create app1 mc1
--frequency-plan-id EU_863_870
--lorawan-version 1.0.3
--lorawan-phy-version 1.0.3-a
--session.dev-addr 00000001
--session.keys.app-s-key.key 0D810699B2B54A421853B1B0661B2724
--session.keys.nwk-s-key.key B1D1033EFDAAC8D91BC0D0F0F9C00798
--multicast
--supports-class-c
Scheduled multicast downlink with MQTT (mosquitto)
Mosquitto Command: C:\Programmi\mosquitto>mosquitto_pub -h movexxxx.xxx.xxxx.xxxx.xxxx.com -t "v3/app1@movexxxx/devices/mc1/down/push" -u "app1@movexxxx" -P "NNSXS.YNQ5LIW5SExxxx" -m '{"downlinks":[{"frm_payload":"ciao","f_port":42,"priority":"NORMAL","class_b_c":{"gateways":[{"gateway_ids":{"gateway_id":"gtwid"}}],"absolute_time":"2020-10-28T20:20:00Z"}}]}' -d
What do I see now?
The added multicast device results as Activation mode multicast like it should.
The answer of the mosquitto downlink is the following:
Mosquitto Answer: Client mosqpub|23216-LAPTOP-OE sending CONNECT
Client mosqpub|23216-LAPTOP-OE received CONNACK
Client mosqpub|23216-LAPTOP-OE sending PUBLISH (d0, q0, r0, m1, 'v3/app1@movexxxxx/devices/mc1/down/push', ... (154 bytes))
Client mosqpub|23216-LAPTOP-OE sending DISCONNECT
What is the problem?
If I try to send a multicast downlink message from the platform, errors: "no downlink path available" occur.
Is instead the mosquitto_pub downlink answer correct ? Because I didn't see anything arriving on my physical OTAA end-devices.
What is missing? What do you want to see?
I don't understand how to correlate my OTAA devices with my multicast group via the console. I would like to see for example a multicast group (with his McAddress and Mckeys) where i can add my OTAA devices because it is not clear how the multicast downlink can reach my OTAA devices.
The text was updated successfully, but these errors were encountered: