Lots of pointless downlinks

[MedadRufus]

{
  "name": "ns.mac.new_channel.request",
  "time": "2021-05-08T02:22:08.144659990Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "icspace26-ttnv3-abp-eu-v1-0-3-1",
        "application_ids": {
          "application_id": "icss-lora-tracker"
        },
        "dev_addr": "260B7397"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.NewChannelReq",
    "channel_index": 5,
    "frequency": "867500000",
    "max_data_rate_index": 5
  },
  "correlation_ids": [
    "ns:downlink:01F54WGD8FDPS37XT14ARWHERP",
    "ns:uplink:01F54WGCVDXBCZ3GGC99YGF4W8",
    "pba:conn:up:01F4S0S1VDKJV6PHSBWY4PYEWG",
    "pba:uplink:01F54WGCQZMN8SDRXJ91HTHHRH",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F54WGCVDMMC5MC8HAW7PPWXF"
  ],
  "origin": "ip-10-100-5-72.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F54WGD8G8T2GAE6DA6QJ23WP"
}

[MedadRufus]

Read this thread: https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525/34?u=medadnewman

[MedadRufus]

It could be that on device registration, the server txes on RX delay of 1 second, which is the LoRaWAN standard. I have by default changed the rx window to 5 seconds, hence the requests are not reaching the tracker.

It appears that only the first downlink message has to be sent after registration: the message to switch rx delay from 1 second to 5 seconds. The server just needs an ack, so it may be possible to do that on another device altogether and keep the rx delay to 5 seconds by default.

However, in other country settings(JP, US), it would be better to use the default settings. It appears that TTN does not change this rx delay for other countries, although it could just send up a message to tracker to switch it. Better to do it this way. There is no way I can receive this instruction to switch without an US/JP gateway, so let it just happen in the air as its meant to be.

[MedadRufus]

Confirmed, using the default lorawan settings, where rx1 delay is 1 second, all the instructions are received.

[MedadRufus]

After this first rx1 delay change request is made, it is never sent again. This is a problem on stateless machines, that do not store the fact that it rx1 delay is now 5 seconds, up from default 5. Same issue with setting data rate of RX2, which is by default DR0. The Things stack sends a request to swtich RX2 datarate to DR3, which is not saved either.

I think best solution is to hardcode these 2 settings for EU868 as default. The server can change that in the future if it wants, but at least it will be able to communicate with the tracker.

1. For other regions, I think we can ignore the statelessness. In the US, there is a chance of a successful downlink to tracker and subsequent ack that will satisfy the server, telling it that it has changed settings. However, the tracker will forget these settings. The downside is rx1 will always be wrong on the tracker over the US, which means downlinks will never work.

2. But if we hardcode the rx1 delay to 5 seconds, the tracker will never receive the first switch command because that will be sent expecting rx1 delay of 1 second. One workaround is to acquire an US915 gateway, carry out the transaction under default settings(rx1 delay == 1 second) then hardcode RX1 delay to 5 seconds on the tracker.

3. Third solution is to set the rx 1 delay on the Things network app to 1 second during creation of the application. Then we will have no future problems. However, there are some known downsides of using rx 1, something todo with latency. Info from The Things Stack documentation: https://www.thethingsindustries.com/docs/getting-started/migrating/major-changes/#rx1-delay

In all The Things Stack deployments, the recommended RX1 delay is 5 seconds to accommodate for high latency backhauls and/or peering with Packet Broker.

Solution 1 is worst, as we loose the downlink capablity forever. Solution 2 heavily depends on acquiring a US915 gateway, and legally transmitting on US frequencies. May not be feasible. Solution 3 is the most attractive, as the default LoRaWAN settings are all used, and there is a good change it will work with the 1 second rx 1 delay, with (slight) performance decline. In my opinion, the performance decline is not high enough risk. Only some remote gateways that have high latency internet connections(e.g satellite links, cellular internet) are the issue, as they can take close to 1 second for round trip from gateway-server-gateway.

[MedadRufus]

I would say go for solution 3 for US, JP, AU but go for solution 2 for the EU.

In the EU, solution 2 can easily be carried out with a second end-node. Only risk is in the future, if rx1 delay is somehow changed from 5 to 1(lorawan default), then downlinks become impossible. What I am doing is not LoRaWAN compliant, as the default rx1 delay is switch from 1 second to 5 seconds, which means I could endure future surprises if the things stack changes behaviour. But the change of this in the near term is very low.

The issue here is the statelessness of the tracker implementation in this repo. In the latest loramac-node releases(https://github.com/Lora-net/LoRaMac-node/releases/tag/v4.5.1), the settings are all saved to EEPROM. I don't think it is feasible to port over everything by launch this week.

[MedadRufus]

For EU, maybe its better to just set the ttn settings to set to RX1 delay to 1 second, as before. no code changes at all, fully LoRaWAN default settings.

[MedadRufus]

Occasionally, a device status request is enqueued(ns.mac.dev_status.request). If the tracker does not respond, it will repeat forever. This could happen if the rx delay1 is wrong.