HI ,i am using my company’s devcies to test in TTN server. we develop the linkCheckreq function in our farmwire. We test linkCheck in many servers,like TTN ,senet ,RXHF. But only at TTN server ,the linkCheck seems didnot work , when we uplink the linkCheck commadn from node to server, there is no reponse command from server.The linkCheckreq command is used by an end-device to validate its
connectivity to a network, we think this is very important function for LoRaWAN application. Can someone help us to check this problem? it menas that TTN didnot support linkCheckreq or others reason.
The following is a description of linkCheckreq in LoRaWAN™ 1.0.3 Specification from LoRa Alliance:
I think you do not understand the nature of LoRaWAN if you want to make sure a node is connected. Any LoRaWAN node should avoid using downlink traffic as much as possible and linkCheckReq requires a downlink for the results to be delivered to the node. I certainly hope your firmware does not issue linkCheckReq too often.
not very often ,as i will ask node to uplink the payload in every 12 hours , it measn that each paypload is very important for us , that is why we use linCheck to check the internet.because we need make sure that each payload can aviod network problem.
Thanks for your reply , accodring to your answer, it means that the TTN server would not support the linCheck function ,right ? and TTN will nerver consider to add this function ,is it right ?
Not many community networks would consider having linkCheck available as it would be so wide open to all sorts of issues / abuse. There are too many downlinks running across TTN at present. TTN is using v2 which is feature frozen, you could look at where we are heading with the v3 stack.
LoRaWAN isn’t designed for system critical data transmissions so consider how important your data is - ANYTHING could happen - you should consider a multi-layered approach.
First, linkCheck is best used when there is an issue with local gateways going down or moved - very long term issues. If your devices aren’t moving & you have a reliable network of gateways and if you really need to know your data was received and it really is only 12 hours, then consider a confirmed uplink. Except that only tells you the gateway heard it.
My personal favourite is for the device to keep copies of the uplinks, if my application server detects a missing message, I can queue a resend request. On next uplink, the device will receive the resend and then then, well, resend the uplink that was requested.
This doesn’t help with time sensitive packets of data - which again isn’t LoRaWAN’s forte. But you could put in a bigger battery, send small uplinks more frequently which would reduce the timeframes.
You may be able to tap in to the ADRAckReq functionality which is supported on TTN. I’ve not tried this so I’m not clear if the ADR request is sent with a downlink or standalone.
Another option, something I’m investigating, is for my application server to periodically evaluate link quality from the gateway metadata and at an appropriate interval, send a health message to the device. If the device is being heard by 2, 3 or more gateways at a reasonable DR & RSSI/SNR, it could be told once a month that everything’s fine. If for some reason the number of gateways unexpectedly drops or signal strength or some other combination, then a message can be sent asap to tell the device it’s more vulnerable.
The device can then respond at its end accordingly. Mostly be reducing the time window before it expects another status downlink. Or by smaller more frequent uplinks. Or by having some confirmed uplinks, or all confirmed if right at the edge. Or some combination thereof.
Hopefully this is food for thought?
Thanks for your reply. From the perspective of LoRaWAN technology application, we need think more, as LoRaWAN has its own feature, It’s really worth thinking about.Thanks for your advice about the copies of the uplinks ,actually, this is waht we would to do in future.