Emergency Use of The Things Network Which Abuses Fair Access Policy

I am currently considering to develop a GPS tracking device using LoRaWAN. I want to have a feature which follows the the fair access policy by sending a single lat long message a day, but also want an option to send a message every 5 minutes if the object it is connected to is believed to have been stolen. The second option would only be used in case of an “emergency” and would never be used over extended periods. I do understand that this would abuse the fair access policy normally, however seeings as this would be used in an exceptional circumstances, it’s a bit of a grey area.

What are the rules associated with this and would I be allowed to implement such a feature?

2 Likes

I don’t expect an exception for the type of use case you’re suggesting, but if the device (let’s say a bicycle) detects it has been stolen, it probably will move a short period and then it will be 'static.

At that point it could switch back to one message a day (and sleep alot to save the battery)

Hi BoRRoZ,

Thanks for the comment. Perhaps it’s best to discuss this further.

How would you know when a bike where to be stolen? If location must be known would it be easier if a request is sent for the “tracking mode” to be enabled? I’m interested to hear your idea.

The following is an extreme example, but hear me out. Let’s say in a hypothetical circumstance, the tracking device were to be attached to a car. It is not unheard of for expensive vehicles to be stripped of parts and shipped overseas in a short period of them being stolen.

Take the situation in this video. If the sensor were to still only be sending at a daily rate, the vehicle would be long gone as stripping a car, wrapping it and getting it going again could take only a few hours. Interestingly enough Ed, who is the person talking in the video backs this statement up saying at 10:54 states “But I think that we were really probably 15 to 20 minutes from that car disappearing and never being seen again”.

The regularity of car thefts in Australia is about 147 a day, which would hypothetically mean that at an average max, 147 nodes on one of the available channels for shot blips would be abusing TTN Fair Access Policy. This is over the whole country which have 250 gateways that is growing in size. Remember, this “tracking” setting would only be enabled if specified by the owner and disabled when the car was recovered

But then this could open up a can of worms? How would you control “emergency” use? At this point in time, nothing stops people from abusing the policy already. I don’t mean to sound one sided, but does not making an exception limit the security functionality and possibilities of the network?

You are probably asking, why not use a SIM card for such an important asset? The issue is a matter of scale. It would be too expensive to put a sensor on every asset, however LoRaWAN only has a single upfront cost, meaning you can be less picky about what you can put the tracking devices on.

Hopefully we can have a constructive discussion about this topic. I would be interested to hear your opinion and ways in developing a solution which both maintains security and is not frowned upon by TTN community.

Some comment.

  • fair access is per node.
  • 30/seconds day per node at SF12 may roughly correspond to 25 messages/day. If you need to track the path, you could send every 10 minutes, and you have 4 hours coverage. If you are mostly interested in an alarm when moved and the arrival point, you can send one message when moving, one when stopping (and when loosing fix, if the car ends indoors - last known position), and then is up to you what to do next.
  • The fair access policy is for a free service that needs to be shared. If you are developing a commercial service, you could consider TheThings Industries version, where no fair access but only the duty cycle limitations are active.
  • However, I have seen trackers with SIM for 8€ (plus SIM of course), which means not far from a LoRaWAN device.
1 Like

my first thought is

Australia is a big continent and I’m sure there is not 100 % LoRaWAN coverage.
That means that if an object is stolen, it would be very fast ‘of the LoRaWAN radar’

It can start transmitting it’s location as soon as movement is detected when the alarm is set, but the signal won’t be received when there are no gateways around, hence the object is ‘lost’

’ You are probably asking, why not use a SIM card for such an important asset? ’

indeed … use the most suitable platform… and in your case that’s probably not LoRaWAN

Thanks for the clarification UdLoRA. I didn’t realise how many messages you could send without exceeding the fair access policy. It’s more than I expected, therefore the likelihood that the fair access policy would need to be exceeded is significantly reduced. I’m just curious, how did you calculate that and can you determine the maximum messages per day per SF?

There is an airtime calculator here, however if you ever sent a packet from a node to TTN , you had seen the airtime in the console. And since I did, I know that at SF12 (almost needed for moving nodes), you could expect 1.2-1.4 seconds, depending on how much extra information you send, like battery status, message type, etc.

1 Like

BoRRoZ, totally understand your point. There absolutely isn’t 100% LoRaWAN coverage in Australia, however there is good coverage in capital cities where the majority of the population live, meaning there is little benefit of covering all of Australia at this point in time. Trust me when I say that there are parts of the country where there is no telephone coverage and the closest shop can be hundreds of kilometres away.

According to this website, “Over 85% of Australians lived in urban areas and nearly 70% lived in our capital cities, making Australia one of the world’s most urbanised countries” which leads me to believe that thefts would follow similar statistics. The next question would be, where would a thief the take for example a stolen car. The likelihood would be that they wouldn’t drive it to the middle of the desert as they have to get away. In my opinion they would either remain in the metropolitan area or drive interstate to another city, of which there is a likely a LoRaWAN connection, so even though there may be no connection along the way, by the time they reach their destination, the node would transmit a message and be received.

Regarding your idea about an alarm feature, would you propose that this could occur through the receiving functionality of a node on the LoRaWAN network?

What if I load your ’ Lambo’ into my prepared truck, which acts as a faraday cage… :sunglasses:

bottomline ’ if you need realtime object tracking… don’t use LoRaWAN ’ imho

1 Like

You need software that sends intelligently (motion recognition, etc), and there is no need to receive (unless you want to lock the car), also because on downlinks the fair access policy is stricter.

@BoRRoZ: I participated in a project on tracking (and from that started the personal curiosity that brought me here :slight_smile: ), and indeed is possible, provided that tracked objects have limited mobility, or that their security area could be identified (geofencing). Not sure this is the case :slight_smile:

1 Like

Sure thing @BoRRoZ, where can I sign up? :stuck_out_tongue_winking_eye:

Yeah, totally get what you mean, just curious as to the technology’s limitations, what’s allowed, what’s possible and what’ll work. I do now understand that real time tracking is not possible, but I’ll sure look into the 10 minute process @UdLoRa described.

I just finished a hackathon and had to rule out the use of LoRa (unfortunately) for emergency tracking if someone is injured in a high rick activity such as rock fishing, and falls in the water, and position of their life vest and bio stat’s needs to be tracked. similar use case (internationally) for elderly person who’ve had a fall and lives alone. It would be good if possible to apply for a special class license in safety related use cases.

1 Like

in a few years there will be a special 5G ‘lane’ for these ‘life threatening’ applications imho, they are on the drawingboard, also for medical devices that patients can wear and need to be 100% connected

choose the right platform … LoRaWAN is great but not for everything

1 Like

Having done my fair share of dangerous activities (for fun) it is clear to me that LoRa would be next to useless for emergency tracking in such circumstances. Where a lot of these activities take place you will often not get even get mobile phone coverage, even with the billions that have been spent on building telecom infrastructures.

2 Likes

I agree that 5G will probably take over the aged care monitoring market.

In the speciific case of dive charters to remote locations (that often have fierce currents) If you had a dive vessel fitted with a private gateway it may serve as a diver location platform - if each dier had a wearable (unclear of aerial arrangement required for LoRa in Water - if sea state creates large troughs and swells and line of site is interrupted…

that’s an idea , I remember an article about LoRaWAN underwater but can’t find it right now

@BoRRoZ, I remember this as well but propogation in water does not go far. in the order of metres.

yes that’s true… the higher the frequency’s the shorter the range.
that’s why subs use ultralow frequencies to communicate.

Geez, this conversation has really grown a bit. On the idea of LoRaWAN penetration in water you stated that:

the higher the frequency’s the shorter the range

Would there be a recordable difference between 428MHz and 915MHz? Unfortunately, I lack a comprehensive understanding about radio strength, so we we assumed it had the same power, would the distance be approximately half on 915?

@Custom-IoT The idea sounds good, however I think the first issue would be infrastructure. The LoRaWAN network is very new and in comparison to the other networks is not that widely available. I do understand that my asset theft idea faces similar issues, but unfortunately you would also face the problem that the majority of gateways are in populated or metropolitan areas, often were these dangerous activities are not undertaken.

By the way, I think this may be the discussion about LoRaWAN’s ability in water that you were talking about:

Hi there, I’ve been looking at LoRaWAN for tracking for a while now. One thing I can say that it potentially opens up new markets for tracking low to medium value assets. Contrast that to SIM-based tracking solutions, which are, right now, really only suitable for tracking high value assets - think trains planes and automobiles. Objects that can tolerate bulky batteries or provide a DC supply.

LoRaWAN’s trade-off against SIM is small size for higher latency and lower reliability, hence the suitability for low-medium value asset tracking. Now I will admit there is a consumer-product bias in this discussion, which has a big factor in driving the cost of the solution down. It’s actually not a great place to be playing in right now - the hardware will only get more commoditized as costs drive to 0. Tracking solution vendors are scrambling to find differentiation in the total solution which is relying more and more on the cloud services offering.

And as we know, cellular operators are moving in with competing solutions based on technologies like NB-IoT. For safety of life or any kind of emergency-based solution these regulated solutions will be the only way to realistically proceed.

Now that’s just the uplink technology.

What about the actual position fixing? Here I think there is a little more room for innovation because the traditional solution of using GPS is really poor for tracking low-medium value assets (or many kinds of assets). GPS is power-hungry, finicky, unreliable. Why does it work on your cellphone? That’s because your mobile super-computer is using its vast bandwidth to keep the GPS engine running in top form in so-called Assisted GPS mode.

Here, LoRaWAN could offer a competitive advantage over even similarly priced SIM-based solutions that must rely on GPS. Unlink cellular, LoRaWAN is not limited in the number of gateways that can be placed. As a result, network-based positioning of the sensors is possible and with useful accuracy.

I really see only one way forward for LoRaWAN to compete with cellular for tracking low to medium value assets - and that is with network-based positioning so that the sensor size and cost can drive down, commensurate with the asset they are tracking.

The question is how do we get to the right density of gateway deployment? It’s chicken and egg in some ways. What if you were compensated to run and maintain a gateway? Would that incentivize the mass deployment of gateways to support sufficient RSSI and/or TDoA network-based location of sensors? What if you were compensated a portion of a crypto-token or reward for recognition of your efforts of moving data packets from sensor to cloud?

Food for thought.