Skip to main content
Bezac
Associate II
November 20, 2019
Solved

Lora - Sticky Mac commands / sheduled uplink

  • November 20, 2019
  • 1 reply
  • 1117 views

Hi there,

I am working on Murata cmwx1zzabz (i.e. STM32L072CZ) and my code is based on the ST en.i-cube_lrwan. For all the basic stuff (joining, sending messages) it runs fine. The Mac commands, that actually manage the network, are OK except the "sticky" ones.

As stated in the Semtech library, "The sticky answers were introduced to the specification in order to ensure that critical MAC commands have been understood by the end-device. You can see the sticky answers like an acknowledgement." So these sticky Mac commands require some acknowledge from the device because it is related to critical parameter (sticky Mac commands are SRV_MAC_RX_PARAM_SETUP_REQ, SRV_MAC_RX_TIMING_SETUP_REQ, SRV_MAC_DL_CHANNEL_REQ). So when the device is receiving one of these, the Mac layer notifies the application layer that an uplink is required as soon as possible. The MlmeIndication callback is then executed.

But looking at the ST library lora.c (more specially LORA_TxNeeded() ) nothing is implemented. Nothing is send back to the gateway so it does not get its acknowledge.

It seems that the Mac command is ready to be send (it is processed and stored in the sMacCommandsList) but I do not get how to tell the Mac layer to send it (It must be obvious!)

Any idea about how to send a scheduled up link?

Thanks!

This topic has been closed for replies.
Best answer by Bezac

-> Finally it was obvious: the Mac commands are part of messages, they are encapsulated ("piggybacked") in the header. So the Mac layer takes care of these commands and the device sends its own data frame that eventually integrates the Mac command in its header. In the case of these sticky mac commands, one can just wait for the next application data frame or decide to force the sending of one (empty) message asap: Mac commands will be send anyway.

1 reply

Bezac
BezacAuthorBest answer
Associate II
November 21, 2019

-> Finally it was obvious: the Mac commands are part of messages, they are encapsulated ("piggybacked") in the header. So the Mac layer takes care of these commands and the device sends its own data frame that eventually integrates the Mac command in its header. In the case of these sticky mac commands, one can just wait for the next application data frame or decide to force the sending of one (empty) message asap: Mac commands will be send anyway.