SEND with ack=false: RX1, RX2 waste time

[MultiTech@NETRONICS-PE.com]

Sending without ack seems like a way to trade off reliability in favor of speed.
Send and move on, with fingers crossed, without ack confirmation, right?

So why wait for any reply from server at all, if ack=false?
We don’t understand why an uplink message (from mDot or xDot) with no ack requested, still wastes time (and power!) with RX1 and RX2 downlink receive windows (time slots).

We understand that even with ack=false, if the server has a queued downlink message, it may transmit that to the endpoint, even though no ack was expected.
We would prefer when ack=false that no return message is transmitted, that no RX window times are required, that downlink messages be deferred until an ack=true uplink is received.

If the standard demands RX windows even when ack=false, please refer us with citations to the standards and where such a requirement might be debated. OTOH, if this is not a matter of standards compliance but rather implementation discretion, please explain the rationale.

[MultiTech@NETRONICS-PE.com]

[additional submission merely to check “Notify me via email”]

[Jason Reiss]

Windows can be canceled and the dot can be put to sleep or send another packet without waiting for Rx Windows if AT+TXW=0.

With libmDot sends can be performed in non-blocking mode and Rx windows can be canceled.

Both of these methods are not recommended and not compliant with LoRaWAN.

The Rx windows are needed for LoRaWAN compliance so the network can issue MAC commands to control the end-device.
If a device does not respect the windows it cannot receive updates for channel usage, frequency changes, etc…
The network even has the ability to reduce the rate the end-device can transmit via DutyCycle MAC command.

[MultiTech@NETRONICS-PE.com]

If the endpoint (Dot) cancels the RX windows and/or sleeps immediately after uplink, any pending queued downlink message is simply spewed into the ether and loss, without knowledge of such loss to the gateway or upstream app. What is the sense in that?

Does LoRaWAN compliance explicitly obligate RX windows for both ack=true and ack=false transmissions, or is that requirement mute WRT ack alternatives?

The suggestions to cancel RX windows, or sleep, or transmit without waiting, all appear to exacerbate violation of MAC protocol, rather than accomodate. What is the sense in that?

It seems to make more sense to provide expeditious upstream delivery and speedy behavior with optional ack=false messages that don’t break MAC expectations, that don’t result in silent downstream message deletions, with the understanding that an endpoint must alternate with some ack=true uplinks to continue participating properly.

It seems that conditioning downstream MAC and queued message transmissions upon ack=true vs. ack=false would support selective per-message optimization without breaking LoRaWAN objectives.

Is the potential advantage of this scheme understandable?

[Jason Reiss]

Application payloads will not be lost unless the application queues a downlink packet. The application can choose which uplinks it wants to queue downlink packets for. If ack=true uplinks signify the device is listening for downlinks the application can queue the downlink at that time and it will be sent as expected.

This behavior is defining an application protocol, use of the ACK bit for this purpose is extraneous state information that is not intended by the original protocol. The application is in full control of the downlink queue.

If the device were to send before the Rx windows have expired the network server will not schedule additional downlinks. i.e. Two uplinks received less than 1 second apart will only result in a downlink scheduled for the first packet, the second uplink is accepted without downlinks added to the queue. Downlinks will be scheduled for the device after at least one second elapses between uplinks from that device.

What extra functionality is required of the network server?

[MultiTech@NETRONICS-PE.com]

In one possible configuration of our application, endpoint devices sleep between relatively sparse (e.g., once per minute) uplink check-ins. Meanwhile, the back-end upstream application may develop an update message for that endpoint asynchronously at any time during endpoint device sleeping, and, without knowing the exact timing of endpoint device wakeup, the application sends a downlink message to the network server, to be held in queue until the endpoint device wakes up and “polls” the network server for any queued downlink messages. In other words, downlink messages are “pre-queued” for the next endpoint device check-in.

Our endpoint devices may wake up either to transmit urgent information, or for routine check-in and downlink polling. In the case of urgent wakeup, the extra time required for RX windows is a hindrance.

The implied workaround for the current network server limitations would require nearly flawless zero-latency end-to-end delivery of uplink messages from endpoint to application, as well as near-immediate production of downlink message from the application, conditioned upon whether the endpoint uplink was urgent or routine, which seems to demand unrealistic performance expectations of both the overall network as well as the application (hosted on a PC). That design seems to obviate the network server queue: if the application must determine, on a message-by-message basis, and within the time margin remaining after uplink and downlink travel is deducted from RX window, then what is the point of having a network server queue at all?

The extra functionality required of the network server: is to provide the means for the endpoint device to modulate downlink message transmissions, most obviously by conditioning upon the ack=true/false value, or by any other means that enables unhindered messaging without RX windows in urgent conditions. [Alternatively, if downlinking can be dynamically configured “suspended” by default, and then temporarily reconfigured “enabled” during the leisure of routine scheduled check-ins, this would allow extra RF dialog around non-urgent messaging.]

[Jason Reiss]

I agree, the queue of the network server is not providing a benefit to the application in this use case. The queue is better managed by the application, part of which can reside on the Conduit to provide a timely response to the uplink.

[MultiTech@NETRONICS-PE.com]

Thank you, Jason –
We (at least I) have not considered how much of our application programming might possibly be implemented in the Conduit. If it is not merely a black-box fixed-purpose appliance, but rather an extensible environment/platform/host for our programming, then indeed that could be where can succeed by distributing some of our logic, algorithms, and traffic management. (As long as breaking that seal does not void our warranty! :^p )

[Author]

Posts