[NKE Bodbus Bridge] Cyclic behavior (uplink / downlink) followed by a re-join

Hi,
I have an issue with a sensor (NKE Modbus Bridge) at one particular gateway: in the grafic below you can see that after the initial join, a downlink is sent to the sensor for each uplink received. After x Uplinks (not consistent), the sensor stops sending Uplinks. Some time (not consitent) later, he will send again a Join request to restart the cycle.

The Sensor supports LoRaWAN 1.0.2. and is setup as Class C Device with OTAA. A second sensor is working fine (connected through another gateway and different organization to the same network server).

Step 1

The phyPayload of the first uplink looks as follow:

"phyPayload": {
  "mhdr": {"mType": "UnconfirmedDataUp","major": "LoRaWANR1"},
  "macPayload": {
    "fhdr": {
      "devAddr": "0181707c",
      "fCtrl": {
        "adr": true,
	"adrAckReq": false,
	"ack": false,
	"fPending": false,
	"classB": false},
      "fCnt": 0,
      "fOpts": null
      },
      "fPort": null,
      "frmPayload": null
    }
  },
  "mic": "f2613547"
}

Step 2

The network-server immediately sends the first downlink:

"phyPayload": {
  "mhdr": {"mType": "UnconfirmedDataDown", "major": "LoRaWANR1"},
  "macPayload": {
    "fhdr": {
      "devAddr": "0181707c",
      "fCtrl": {
        "adr": true,
        "adrAckReq": false,
        "ack": false,
        "fPending": false,
        "classB": false
      },
      "fCnt": 0,
      "fOpts": [
        {
          "cid": "LinkADRReq",
          "payload": {
            "dataRate": 5,
            "txPower": 0,
            "chMask": [true,true,true,true,true,true,true,true,false,false,false,false,false,false,false,false],
            "redundancy": {
              "chMaskCntl": 0,
              "nbRep": 1
            }
          }
        },
        {
          "cid": "DevStatusReq",
          "payload": null
        }
      ]
    },
    "fPort": null,
    "frmPayload": null
  },
  "mic": "a8e05de7"
}

Two MAC commands are contained:

  • LinkADRReq: requesting the sensor to perform a rate adaptation to dataRate 5
  • DevStatusReq: requesting status information. According to LoRaWAN specs, the sensor must respond with DevStatusAns.

Step 3

This is followed again by the second uplink:

"phyPayload": {
  "mhdr": {"mType": "UnconfirmedDataUp","major": "LoRaWANR1"},
  "macPayload": {
    "fhdr": {
      "devAddr": "0181707c",
      "fCtrl": {
        "adr": true,
        "adrAckReq": false,
        "ack": false,
        "fPending": false,
        "classB": false
      },
      "fCnt": 1,
      "fOpts": [
        {
          "cid": "LinkADRReq",
          "payload": {
            "channelMaskAck": true,
            "dataRateAck": true,
            "powerAck": true
          }
        },
        {
          "cid": "DevStatusReq",
          "payload": {
            "battery": 0,
            "margin": -10
          }
        }
      ]
    },
    "fPort": null,
    "frmPayload": null
  },
  "mic": "408a0929"
}

Apparently, the sensor acknowledged the LinkADRReq and responded to the DevStatusReq.
According to the LoRaWAN specs, he should however do so with LinkADRAns and DevStatusAns.

Step 4

The network server sends an immediate downlink again:

"phyPayload": {
  "mhdr": {"mType": "UnconfirmedDataDown","major": "LoRaWANR1"},
  "macPayload": {
    "fhdr": {
      "devAddr": "0181707c",
      "fCtrl": {
        "adr": true,
        "adrAckReq": false,
        "ack": false,
        "fPending": false,
        "classB": false
      },
      "fCnt": 1,
      "fOpts": [
        {
          "cid": "LinkADRReq",
          "payload": {
            "dataRate": 5,
            "txPower": 2,
            "chMask": [true,true,true,true,true,true,true,true,false,false,false,false,false,false,false,false],
            "redundancy": {
              "chMaskCntl": 0,
              "nbRep": 1
            }
          }
        }
      ]
    },
    "fPort": null,
    "frmPayload": null
  },
  "mic": "d8e05f48"
}

This time, only LinkADRReq is send.

Step 5

The sensor comes back with the following uplink:

"phyPayload": {
  "mhdr": {"mType": "UnconfirmedDataUp","major": "LoRaWANR1"},
  "macPayload": {
    "fhdr": {
      "devAddr": "0181707c",
      "fCtrl": {
        "adr": true,
        "adrAckReq": false,
        "ack": false,
        "fPending": false,
        "classB": false
      },
      "fCnt": 2,
      "fOpts": null
    },
    "fPort": 125,
    "frmPayload": [
      {
        "bytes": "NiLnCxlbWQXj7XnUYNk/ubgYW4mVogb3ze6Yc21ACg=="
      }
    ]
  },
  "mic": "43999959"
}

The LinkADRReq has been completly ignored, the sensor sends only regular payload.

Now the cyclic behavior starts:

  • an upload arrives (without any MacCommands) (message as in Step 5)
  • a downlink is send with LinkADRReq (message as in Step 4)
    -…

After some time, the sensor stops sending uplinks. Some time later, it rejoins the network. This has been consistent over the last few days, with typically 5-200 iterations and 30-90min breaks in between.

Any idea how to stop this / what might cause this?

inspect the sensor configuration and events in modbus to which first sensor is connected.
do the same with second sensor and find the difference.

Have already triple checked this: device Profile, service Profile and gateway profile are identical for both.

The only differences I see:

  • they are under different organizations
  • the gateway is different (one is based on an nfuse-mpcie-card, the other one is a RAK7258)
  • one is connected through broadband, the other through a GSM link
  • other sensors (Class A) connected to the same gateway work perfectly fine

I had witnessed the same cyclic behavior with another Class C device before, however that sensor is currently not located within the reach of the antenna and hence I cannot reproduce.

I doubt that the actual payload (i.e. what is being read out through the modbus interface) has an influence. In my opinion, something is wrong with our configuration or there is still a bug hidden somewhere, as the atycpial behavior is initated by the LoRaServer (sending a downlink message, once an uplink arrives).

not profiles in the server. I talking about the sensor configuration inside it.

I just made an interesting discovery: the other Class C device, that was showing the same behavior as above, was actually not removed physically but only deleted in the Application-Server.

On the packet forwarder, I can see that the sensor has continuosly been sending uplinks without issues, the counter of packages is > 1000. As long as it was active in the application server, it typically rejoined the server after a 5-200 uplinks.

I do not see how the setup of the sensor could influence this, as this would only affect the payload.

This is from NKE-device doc. here
“The ModBus sensor automatically executes a reassociation procedure if no downlink frame is received by the sensor during a given periodicity (4 days by default) or if a given number of confirmed frames (100 by default)”