Hi everyone. I have found one problem sending multicast downlink on my end-nodes registered on TTI “The Things Industries”.
My multicast channel setting
Data Rate = DR 0 ( SF 12 / BW = 125KHz )
RX frequency class C = 869,525 MHz
Band = EU863-870
Analysis of the Problem
When I schedule a multicast downlink this is received by my end-nodes but if the frame payload is more than 29 bytes it is aborted, while if it’s less than 29 bytes it is processed correctly. I’ve seen inside the code of my end-nodes that the packet is aborted because the MIC “Message Integrity Code” check fail. I tried with other network server (like A2A) and this didn’t happen, I mean I could send the entire 51 bytes as expected.
Code
Here is my code in LoRaMac.c file:
static void ProcessRadioRxDone( void )
{
... Other Rx control ....
macCryptoStatus = LoRaMacCryptoUnsecureMessage( addrID, address, fCntID, downLinkCounter, &macMsgData );
if( macCryptoStatus != LORAMAC_CRYPTO_SUCCESS )
{
if( macCryptoStatus == LORAMAC_CRYPTO_FAIL_ADDRESS )
{
// We are not the destination of this frame.
MacCtx.McpsIndication.Status = LORAMAC_EVENT_INFO_STATUS_ADDRESS_FAIL;
}
else
{
// MIC calculation fail
MacCtx.McpsIndication.Status =LORAMAC_EVENT_INFO_STATUS_MIC_FAIL;
}
PrepareRxDoneAbort( );
return;
}
... Other code ...
}
Questions
Why does this happen on TTI/TTN even if the maximum frame payload is guaranteed to 51 bytes with SF 12 ? Is there a different limit of the maximum payload size downlink in multicast case on TTI/TTN ?
I’m working in Europe so I’m referring to EU863-870 table.
All my end-devices and gateways registered on TTI platform are set with EU863-870 band limitation so I don’t understand why TTI should append a wrong MIC to packet with frame payload size greater than 29 bytes.
Addition : for scheduling downlink multicast i’m using MQTT, maybe there is a limitation reguarding MQTT maximum payload size.
Probably you are right but I’m tring to do FUOTA for updating different devices switching them in class C in a multicast session. I have chosen SF12 because I wanted to make sure that all end-devices received all the packages without loss.
I thougth I’d change DR from 0 to 3 (SF 9) on RX2 window but a multicast profile in TTI is a virtual profile that is not associated with the physical end-nodes.
If I’ve understood correctly the setup of RX2 window is done on the join request-accept so a virtual profile can’t do this . Is that true ?
Even if it’s utterly absurd use SF12 with 51 bytes I would like to understand what is the problem in the chain NS-Gateway-End Node.
When i Schedule less than 29 bytes TTI send on my end-nodes that data:
MIC (TTI) : “BRVf6g==” (base64) —> 0xEA5F1505 (hex)
My end-nodes when receive that packet save MIC(TTI) inside “expectedCmac” variable than calculate the MIC from the MAC payload and save the result inside “compCmac”. Finally check if “expectedCmac” is equal to “compCmac”, if it’s not there is a problem on message integrity.
Here is my code (this section inside LoRaMAC.c was written by Semtech):
I have chosen SF12 because I wanted to make sure that all end-devices received all the packages without loss.
At 2.8 seconds in duration, the chances of something interfering before the packet is done start to be significant. And you’ll probably burn through your legal airtime limit for the gateway and be throttled by that.
There was work done for FUOTO by TTN people in a way that attempts to work with limitations; you should probably study that. Or if you are going to do something custom, do something which could actually work.
Even if it’s utterly absurd use SF12 with 51 bytes I would like to understand what is the problem in the chain NS-Gateway-End Node
Presumably some step in the chain is refusing to carry out the absurd (and quite possibly illegal) operation of making such a transmission.
I would not be surprised if your nodes are receiving a shorter packet than 51 bytes, which means that the MIC is no such thing but simply the last bytes of whatever got through before truncation.
Really though the stack or gateway should be rejecting the transmit attempt entirely.
@cslorabox Thank you very much for your answer, I agree with all that you have said.
the MIC is no such thing but simply the last bytes of whatever got through before truncation.
I’ll check if what you said is true and i’ll get back to you. Under the circumstance I’ll find another way to implement FUOTA.
I thougth I’d change DR from 0 to 3 (SF 9) on RX2 window but a multicast profile in TTI is a virtual profile that is not associated with the physical end-nodes.
If I’ve understood correctly the setup of RX2 window is done on the join request-accept so a virtual profile can’t do this . Is that true ?
I would like to know only how to set RX 2 of multicast profile on DR 3 (SF 9 / BW = 125KHz) because even if I set this on multicast profile (as you can see on the picture down) my gateway continue to schedule downlink on SF 12
I’ve found this topic on GitHub. I would like to do the same SF switching with multicast TTN virtual devices.
Switching to a higher spreading factor
LoRaServer has no notion of multicast, thus always sends out Class C packets on the RX2 data rate and frequency. This will be very slow in most regions (e.g. EU868). You can however overwrite this with some changes. This is how to use SF7 in EU868.
Log in to the LoRaServer server, and open /etc/loraserver/loraserver.toml .
Any updates? I have the same issue, i am working on FUOTA campaing, and multicast class c devices are in DR0 (SF12) RX2… more than one hour to update them.
In TTI Front end is not option to change RX2 (
It is still in SF12 in lieu SF9 as it is showed in above image.
I would recommend everyone to move to a LoRaWAN 1.0.4 based stack as a lot of points have been clarified by the LoRa-Alliance under this specification release.
Hi @mluis1 generally agree with all you say - however, I was posting in the context of TTN deployments where I get the impression it’s still early days for significant deployments, and novice/general/newbie users vs those with the expertise to dive in and sort details & debug MAC issues etc., and especially in context of broader or more exotic deployments/use cases - extending to e.g. Class C or certainly FUOTA - not ideal given TTN FUP and downlink limits This based on own observations and listening to other users - with more detailed knowledge of the ins and outs of LoRa MAC node behaviour and operations. I dont live on Github as not a Softie, and didnt see the discussion you called out but I did note that despite your tangential invite to TTI/TTN leadership and team to contribute it hadn’t led to a thread contribution 6 mnths later - maybe it happened elsewhere as “I dont live on github”! - which re-enforces my perspective…perhaps a bit ambitious yet? Wish it wasnt that way, and am sure it will mature in the end. The good thing is these forum threads and dicussions can only bring that maturity about faster One other observation is I still see lots of 1.02b deployments and new users so many havent got the memo yet - even about stepping up to 1.0.3!
We often suggest that if folk are struggling with 1.0.4, and certainly 1.1 (which is even more of a maturity concern) that they step back and try 1.0.3 to get up and running then step up to 1.0.4 or 1.1 if possible.
This is another one of those reality gaps - many of us use the vendor supplied library or framework to which they make extensive modifications (ST) or close source it (Microchip).
Apart from the technical feasibility of updating a library, there are professional indemnity issues - if we use the vendor provided library as they intend then we are not open to arising issues from us performing surgery when we don’t have a Grays Anatomy to guide us.
If you want people to move to 1.0.4, get ST to close the 6 to 12 month gap they appear to be running behind on. Microchip’s MLS has been at 1.0.4 for a while, all good but as @Jeff highlights above, there’s much for people to learn to get a configuration working that doesn’t issue a blizzard of downlinks, some of which persist for weeks until the LNS gives up.
The consequences of this sort of situation is that a well known value vendor has ST code base with a version of LMn from 2018 and has just released a new board to replace it, presumably as ST’s MCU’s are unobtainium and have tripled in price, using a LMn of a similar vintage.
I’m happy to help move compliance in the right direction, but there has to be a balance between commercial reality and technical implementation.
We will get there in the end … but our perspective, influenced by fact we are on TTN/TTS(CE)/TTSx, and potentially others (Chirpstack, LoRiot, …etc.) each of which has its own quirks in how it interacts with LMIC/LoRaMAC-node/Loraxxxx delete as needed, whilst TTS is driving towards compliance we have to recognise that there will be twists and turns on the road - and us dumbo’s will rely heavily on those of you with the expertise and experience to navigate the way through…
This based on own observations and listening to other users - with more detailed knowledge of the ins and outs of LoRa MAC node behaviour and operations. I dont live on Github as not a Softie, and didnt see the discussion you called out but I did note that despite your tangential invite to TTI/TTN leadership and team to contribute it hadn’t led to a thread contribution 6 mnths later - maybe it happened elsewhere as “I dont live on github”! 
One other observation is I still see lots of 1.02b deployments and new users so many havent got the memo yet - even about stepping up to 1.0.3! 
