Optionally disable downlinks to save power (Caution: renders device non-compliant)

[dberenguer]

I added a LMIC_DISABLE_DOWNLINK definition in lmic/config.h in order to remove DNW2_SAFETY_ZONE + LMICcore_rndDelay(2) in processRx2DnData and then save around 5 seconds between transmission and reception of EV_TXCOMPLETE.

Low-power nodes which do not need downlinks can take advantage of this feature in order to save a lot of current.

I'm still looking around how to remove the 1.5-2 second delay still happening before EV_TXCOMPLETE

[terrillmoore]

Thanks for your contribution.

Unfortunatley, this would violate the spec. In order to pass compliance testing, class A devices must accept MAC downlinks. That means this change is not a good candidate for library. Any change must be able to pass compliance testing, otherwise it will be too confusing and will make for a big support load....

Best regards,
--Terry

[dberenguer]

I'm not sure about the LoRaWAN spec but current settings will ruin batteries on most low-power devices unless they transmit a few packets per day. Anyway, people reaching this pull request can learn about how to do this hack.

Thanks for your work,

Daniel.

[terrillmoore]

I have reviewed the spec and the operation of the network. I caution all users NOT to use this patch on The Things Network or other public networks. The network depends on class A devices accepting downlink for MAC commands. This is not optional.

Also, bear in mind that this will silently break ADR, Link Integrity checking, and other important features. This pull request will not be merged.

[dberenguer]

Well, downlinks do not need to be disabled forever. With my last addition, they can be turned off and on dynamically by the user application. Let's assume that ADR and ACK's are disabled on the device. Then, there is IMO no downlink that might result of interest for the device. If the LoRaWAN specs forbid this behavior then I really don't understand the specs.

[terrillmoore]

Sorry, the spec is quite clear. A device SHALL open an RX window one second after each uplink (and a second one a second later, if nothing was received in the first window). The network is allowed to rely on this for MAC downlinks. Won't merge any changes that defeat this required behavior. Sorry.

[dberenguer]

Understood. From LoRaWAN™ Specification v1.1:

3.3.6 Important notice on receive windows
An end-device SHALL NOT transmit another uplink message before it either has received a
downlink message in the first or second receive window of the previous transmission, or the
second receive window of the previous transmission is expired.

It's only that imposing this requirement just from a timing perspective and not so strictly would open a lot of possibilities to low power applications.

[altishchenko]

Understood. From LoRaWAN™ Specification v1.1:

3.3.6 Important notice on receive windows
An end-device SHALL NOT transmit another uplink message before it either has received a
downlink message in the first or second receive window of the previous transmission, or the
second receive window of the previous transmission is expired.

It's only that imposing this requirement just from a timing perspective and not so strictly would open a lot of possibilities to low power applications.

I think you misunderstood this requirement a little bit. It says that the device is not allowed to transmit anything while the RX windows are nominally open, just during this time. It can freely transmit after the RX2 window closes any time, taking duty cycle regulations into account of course.

As for the other matters of this post, the power economy of this request will be next to nothing at the price of violating the spec compliance. Most importantly, adherence to the network's ADR control is vital in managing device's TX power and spread factor - this provides real power economy.
Listening for downlinks just after transmission does not ruin anyone's battery at all, because the usual standard modem is already in "warm" state and does not require the same amounts of energy as used for initial startup and preparation for transmission. This patch will not save anything in reasonable amount of time. Do you have tests to prove the save?
From my own experience, usual devices with not a lot of traffic can leave up to 3 years on a decent AA sized 3.6V accumulator battery (stationary, not wearable).
The real power economy for such devices comes from utilizing your CPUs sleep/stop power-saving modes between transmissions. To give you a real life example: our standard production module (STM32L based, SX1276 modem, bunch of sensors, GPS receiver) "lives" ~5-7 days without MCU energy saving and much more than a month with MCU energy saving mode enabled, with transmission rate of at least 1 message in 2 minutes. It happily receives downlinks after its transmissions and it even requires them, for it sends confirmed uplinks - it is a wearable tracking device and its rechargeable accumulator is extremely slim (300-400mAh).
@terrillmoore Terry, these are just my 5 cents and my experience in production grade LoRaWAN devices - this Hack will be much more trouble and problem than virtual and unmeasured benefit of visual potential of saving a few micro-amps, which will get spent anyway in either re-transmissions because of inadequate TX power setting or in utilization of non-optimal spread factor uselessly extending required time-on-air.

[altishchenko]

Well, downlinks do not need to be disabled forever. With my last addition, they can be turned off and on dynamically by the user application. Let's assume that ADR and ACK's are disabled on the device. Then, there is IMO no downlink that might result of interest for the device. If the LoRaWAN specs forbid this behavior then I really don't understand the specs.

The specs insist on network's control over device's TX power, datarate/spread factor and radio channel used - these are resources "owned" by the network. Devices that violate this ownership break network's performance and integrity. This is usual Regulation and radio networks even more so. LoRaWAN devices should never behave in ham-radio mode - that will never do good anyone.

[altishchenko]

Giving this thread a bit more attention, I can see where the original misconception comes from.
@dberenguer Daniel, I think you misunderstood the spec. Class A device DOES NOT constantly listen for incoming downlink messages. Never. Class C does that. Class A devices listen for incoming messages ONLY IN RESPONSE to their uplink messages and only for a very SHORT period of time. There is absolutely no way that network can send a message to your device otherwise. And your device is not listening for anything all the time, as I said, only the very short period after its own transmission. No uplink - No downlink.