Lorawan-stack: Multicast registration and multicast downlink
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:
- Activation mode: Multicast
- LoRaWAN version: MAC V1.0.3
- DevEUI: nothing
- Frequency plan: SF12 for RX2
- Frame counter: 32bit
- Multicast Address: 00 00 00 01
- Multicast NwkSKey: B1-D1-03-3E-FD-AA-C8-D9-1B-C0-D0-F0-F9-C0-07-98
- Multicast AppSKey: 0D-81-06-99-B2-B5-4A-42-18-53-B1-B0-66-1B-27-24
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-cScheduled multicast downlink with MQTT (mosquitto)
_Mosquitto Command:_ C:Programmimosquitto>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
- _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 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.
MatteMoveSRL
All 7 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.
I noticed that the enroll multicast device doesn't result as _Activation mode multicast_ but instead as _Activation mode ABP_. Why is this so?
We need reproduction steps for this, please edit your post to follow the issue template.
I can't send downlink messages from the platform because errors "no downlink path available" occur. I tried also to send a downlink using MQTT on windows as following but nothing arrives on my end device.
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
on 5 Nov 2020
@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:
Is instead the mosquitto_pub downlink answer correct ? Because i didn't see anything arriving on my physical OTAA end-devices
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 is not clear how the multicast downlink can reach my OTAA devices
Thank you a lot in advance for your time and your reply.
MatteMoveSRL
on 5 Nov 2020
@MatteMoveSRL Is instead the mosquitto_pub downlink answer correct ? Because i didn't see anything arriving on my physical OTAA end-devices
Apart from the absolute time, which is in the past, it doesn't look wrong.
But, is gtwid a connected gateway? Do you see the downlink scheduled in the Console, when looking at the gateway traffic?
@MatteMoveSRL 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 is not clear how the multicast downlink can reach my OTAA devices
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
on 6 Nov 2020
@johanstokking Thanks for the quick reply
But, is gtwid a connected gateway?
Yes the gateway is connected and i used "gw-test" instead of "gtwid" in the mosquitto command.
Do you see the downlink scheduled in the Console, when looking at the gateway traffic?
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":
If your end device understands downlink on both the unicast and the multicast channel, you should be fine.
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 ?
MatteMoveSRL
on 6 Nov 2020
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":
Please subscribe to the gateway event log with;
$ ttn-lw-cli events --gateway-id gtw-test
Also enable debug logs (log.level: debug).
Then schedule the downlink message and observe logs and gateway events.
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 ?
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
on 9 Nov 2020
@johanstokking Thanks for your reply.
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.
Thanks I got it. You were really clear.
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.
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.
MatteMoveSRL
on 9 Nov 2020
Please use the forums for additional questions; we don't answer questions on GitHub issues. Please see the issue templates for that also.
johanstokking
on 12 Nov 2020
Related issues
adamsondelacruz
·
7Comments
kschiffer
·
7Comments
htdvisser
·
9Comments
johanstokking
·
8Comments
ecities
·
5Comments
Most helpful comment
Please subscribe to the gateway event log with;
Also enable debug logs (
log.level: debug).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.