Continuous mac reply retries

[Lambosaurus]

My device is aggressively sending mac only uplinks when there is a pending mcps response.

Typical pattern seen below. Because the mac uplink goes unacknowledged, then the device continuously retries.

This is due to a pending sticky command. This behavior seems pretty clearly defined in LoRaMacHandleScheduleUplinkEvent. Due to the sticky command, an mac mlme indication is sent.

In my case the mac uplink contains RXParamSetupAns and DlChannelAns - which from reading the 1.0.4 spec I understand that they may go unacknowledged, and should be repeated with subsequent data uplinks until confirmed - but not repeated urgently.

Unfortunately my device is based on the ST modified stack targeting the STM32WLEx. To their credit it mostly just worked, but I am not aware at what point this was branched from the Semtech stack.

I cannot figure out how by what mechanism the device is supposed to stop sending uplinks in this case. It seems like as long as the sticky command is pending, then mlme indications will be continuously and rapidly emitted. Any clarification on the expected device behavior in this case would be greatly appreciated.

[MedadRufus]

I have the same issue, with the Things Network v3, running v4.4.7 of the loramac-node Semtech stack.

[Lambosaurus]

I have 'resolved' this issue by commenting out LoRaMacHandleScheduleUplinkEvent. This seems like a filthy hack.

However it actually produces the behavior I expect - sticky mac messages only get sent as part of periodic uplink.

I'd really love a comment from an expert on the ramifications of this.

[adriansmares]

Hey - I am one of the maintainers of TheThingsNetwork/lorawan-stack.

My interpretation of the specification is that the NS does not necessarily have to send a downlink for each uplink that contains the sticky answer. I interpret it the same way the original poster does - they are piggybacked to the normal application uplinks.

My understanding is that the current specifications do not require a three way handshake ({Cmd}Req -> {Cmd}Ans -> potentially empty downlink).

[mluis1]

The MAC commands requiring the answers to be repeated with every uplink up until a downlink is received goal is to ensure that the end-device and NS physical parameters are in sync.

Therefore, as the NS is the one sending those MAC commands it is natural to assume that once it receives an answer from the end-deive it should schedule a downlink as soon as possible in order for the end-device to stop sending those commands.

[HeadBoffin]

is to ensure that the end-device and NS physical parameters are in sync

Why this one particular setting when all others can wait for the next uplink to occur. Particularly given that mandating another downlink in short order is not good for a local network.

As for any assumption, given the rigorous committee-based decision making that the specifications undergo and the depth of the compliance testing for devices, what is the process by which such assumptions are made & not promulgated amongst all the technical committee members.

If TTI who are publicly developing a LNS and have a director on the LA Technical Committee weren't in the loop, perhaps there should be a firewall placed between the updates to this code base such that there is greater transparency - having a code maintainer who authorises commits who is also on the committee puts that person in a unique and conflicted situation.

[mluis1]

I suppose that @Lambosaurus is using a version smaller than v4.6.0.

LoRaMacHandleScheduleUplinkEvent has been completely removed since v4.6.0 release with commit 083de80

If you are using a previous version you have 2 possibilities:

1. Apply the changes done with commit 083de80
2. Remove the below case handling
   

   LoRaMac-node/src/apps/LoRaMac/common/LmHandler/LmHandler.c

   Lines 831 to 846 in e54d3ec

   	case MLME_SCHEDULE_UPLINK:
   	{// The MAC signals that we shall provide an uplink as soon as possible
   	// Send an empty message
   	LmHandlerAppData_t appData =
   	{
   	.Buffer = NULL,
   	.BufferSize = 0,
   	.Port = 0
   	};
   	if( LmHandlerPackages[PACKAGE_ID_COMPLIANCE]->IsRunning( ) == false )
   	{
   	LmHandlerSend( &appData, LORAMAC_HANDLER_UNCONFIRMED_MSG );
   	}
   	}
   	break;

[Lambosaurus]

Thanks, that's very helpful to know.

After some digging I found that ST's stack is based off the v4.4.7 release - same version as @MedadRufus.

I'll apply the changes as per 083de80 as you recommend. This looks like it will resolve my issues.

[HeadBoffin]

ST's LRWAN Cube v2.1.0 was released 10th Aug 21 and implements their LoRaWAN middleware package v2.3.0 released 18th May 21 which implements LoRa Mac (sic) v4.4.7 from 18th Jan 21.

Referencing the v4.6.0 release is rather disingenuous and the supposition feels condescending. Creating hardware & firmware in the current climate of chip shortages is hard enough at present without assumptions that there is a ready supply of bleeding-edge modules that the vendor provides the latest libraries for. Not that that would help much as the very latest Cube WL for the STM32WL range has a similar pattern of dates as above ending with LoRaMac-node v4.5.2.

There are now devices in the supply chain that when they are deployed on AU915 will ideally need an LNS that is aware of the assumptions made or a material change to the LNS in short order to accommodate them.

The economic impact on a whole raft of device developers with support issues arising - either during development (days of un-billable time for me) or when the devices are found wanting by the end-user and the supplier has to take out time to figure out what's happening, could easily add up to 6 figures or more.

Maybe the LoRa Alliance should fund a minimalist reference version of both LNS & Mac written for the 99%. Or Semtech calve off a lightweight version that is far less opinionated and support the user base in its implementation rather than impose functionality that is not explicitly specified.