Knowledge Base

Sticky Mac Commands - How to tell the Mac layer to send a scheduled uplink

Hi there,

I am working on Murata cmwx1zzabz (i.e. STM32L072CZ) and using the Semtech stack. 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 Lora-node example,nothing looks 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?

The sticky meesages are sent automatically by the stack when the application sends any uplink.
These answers will be usually sent on the FOpts field of every uplink message up until the network server makes use of the new parameters.

The `MlmeIndication` stack callback has an event named `MLME_SCHEDULE_UPLINK`. This event is used to notify the upper layer that it could send an uplink as soon as possible in order to finalize the sitcky messages handling. Please note that handling this event is optional. It can manly be used to speed up the process.

All the provided examples schedule an uplink transmission as soon as the `MLME_SCHEDULE_UPLINK` event happens.

* \brief MLME-Indication event function
* \param [IN] mlmeIndication - Pointer to the indication structure.
static void MlmeIndication( MlmeIndication_t *mlmeIndication )
printf( "\r\n###### ===== MLME-Indication ==== ######\r\n" );
printf( "STATUS : %s\r\n", EventInfoStatusStrings[mlmeIndication->Status] );
if( mlmeIndication->Status != LORAMAC_EVENT_INFO_STATUS_OK )
switch( mlmeIndication->MlmeIndication )
{// The MAC signals that we shall provide an uplink as soon as possible
OnTxNextPacketTimerEvent( NULL ); // <--- uplink scheduling
The LoRa-Alliaince certification process checks if the end-device correctly handles the sticky messages.

Please refer to pre-certification report below link. (For instance: Chapter "11 DIChannelReq MAC command" on page 22).
Thanks for this detailed answer!

So, as I expected, I overlooked an obvious solution... If I clearly understood, as the Mac commands are integrated to payload, any message will transport Mac commands. As stated in the specifications: "FOpts transport MAC commands of a maximum length of 15 octets that are piggybacked onto data frames".

In other words, when the MLME_SCHEDULE_UPLINK is called, the app is noticed and may send an empty message in order to bring the sticky Mac command to the gateway. Is that correct?

Last remaining question: what about the delay expected by a gateway regarding sticky Mac commands? Since the duty cycle is defined as 2'30 (REGION_EU868 for what I know), this can be seen as a bit long from the gateway point of view.
Yes, your understanding looks to be correct.

There is no delay to be respected. That's why we are not obliged to make the uplink as soon as possible.
The LoRaWAN protocol relies on end-device constraints. Thus, for example if your application only sends an uplink per day it will just take at least 3 days to have everything synchronized.

Please, it should also be noted that we should not talk about `gateway` but `network server` instead.
A `gateway` in LoRaWAN networks is a dumb device that just receives/transmits LoRa packets on the air interface and receives/transmits them to the `network server` on the other side.
This means that virtually it is like if the end-device is directly connected to the `network server`.

Crystal clear, thank you.