[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 )

[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.]

[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?

[MultiTech@NETRONICS-PE.com]

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

[Author]

Posts