Many things influence the quality of a device’s reception e.g. distance, gateway characteristics, device population (e.g. congestion), topography, obstructions, etc. so our users’ networks may be dynamic i.e. gateways and relays being added, antennas adjusted, etc. to extend coverage or capacity.

Entities can be in different states or situations so how long it is OK for an entity to be out of contact may vary by individual and change over time. Some users may need to be able to control energy use for each individual. With some animals, people or equipment in some situations (e.g. the animal is unwell or the equipment near sensitive environmental zones) users can accept missing a many messages in other cases they can not.

There are a number of approaches that can be used. For stationary devices in static networks people may rely on ADR. In other cases people may use our Adaptive Broadcast Energy (ABE) feature to allow specific devices to respond more quickly. People may also use manual overrides to control configurations.

What the user does

For any entity, a user can define:

• if ADR is enabled — energy use is then determined automatically based on simple system wide parameters (and ABE and Manual control is not available)

• if ABE is enabled — energy use is controlled by device (and Manual control is not available). The parameters are:

• Missed message limit — how many Messages can be missed (minutes)

• too Loud Period — how long to accept messages using too much energy/air time to communicate

What the solution does:

The solution automatically:

• Reduces the energy/air time device uses if it is using more than needed.

• Increases the energy/air time a device uses if too many messages are missed.

• Alerts a user if a device:

  • is off line for more than a user defined period

  • has been dropped i.e. is detached from entity

  • is at a strange angle e.g. does not seem to be seated correctly

  • is outside the areas it is meant to be in (wandering, escaped, etc.)

An example — sick or wayward horse

The horse is well within GW range.

The horse moves to the edge of range.

The horse moves out of range so the device increases energy used to ensure connection.

This is what you will see in the Messages console

The horse is well within range.

The horse moves closer and no longer needs to use as much energy to communicate.

The device is asked to reduce its energy use to conserve battery and on air time.

This is what you will see in the Messages console

Thanks to HorseSafe for applying and validating this initially

Another great advantage of LoRaWAN is that one can use existing networks where they are available (at a fair price) from a network utility and extend the network to places only you require at your time, convenience and cost. It is hard for a network utility to extend its network for a single user. Telco’s are also focused on providing 5 nines quality of service while for the vast majority of IoT solutions, 2-3 nines is adequate and the marginal cost of extending this to get an extra 2-3 nines can not be economically justified.

If you have thousands, hundreds or, or possibly just tens, of devices in well-defined areas with no LoRaWAN current coverage it will often make sense for you to add in your own gateways i.e. otherwise you will pay pennies for each device each month and those pennies will add up.

There are several mechanisms for extending LoRaWAN coverage and they each have their pros and cons e.g. gateways (which will require backhaul and power); relays (which can handle a small number of devices at the edge of a network); direct to satellite solutions (which will have latency and cost constraints); Mesh gateways (which require using proprietary protocols). We have been working with all of these and think they all have roles to play.

When looking at extending a LoRaWAN network, you need to know exactly what coverage you need i.e. where you need coverage, what qualities of service you need (based on device populations), etc. A Person at the edge of coverage for a phone can perhaps move a few meters to get better coverage. Things can’t do this if they are fixed, and don’t know how to do this if they are mobile. So you need to know as well as you can the areas and places that coverage is needed at.

Our approach for extending LoRaWAN networks is predicated on a precise an understanding of the requirements and a continuous assessment of the current state. The LoRaWAN solutions we create allow coverage to be mapped (areas and places which are surveyed are an expression of network requirements). Aspects like congestion and outages are dynamically tracked. This allows the current state to be monitored and future potential issues to be predicted (e.g. seeing an area is becoming congested, before it materially affects the utility a solution). The approach is network agnostic and will work with a hybrid network i.e. mix of public and private gateways.

There is seldom any doubt that more information may result in better management however the ROI depends on what will be learned and done and exactly the investment required is to operationalise the information acquisition.

Common risks stem from:

• Allowing off the shelf devices to determine your solution (or worse still your requirements) — as the exact match of sensors, qualities of service, configuration capabilities, diagnostics, etc. may not exist. An off the shelf device may notionally do what is needed but they often come with an overhead (i.e. the off the shelf devices might be overspecified and not optimised)

• Expecting subject matter experts or business users to say exactly what information they want, with what accuracy, how often, with what reliability and to explain what they will do with, and what value it will be

  • things will be overspecified e.g. 5 nines delivered and paid for when 2 nines is completely adequate (and an order of magnitude cheaper) e.g. reliability, accuracy, etc. satellites, relays, adaptive spreading factor, etc.

• Relying on compelling slide deck presentations (that everyone interprets as addressing their needs) that duck the devil in the details so that what is implemented is too expensive, too poor a fit, etc.

• Assuming that knowledge of traditional enterprise IT technologies and practices will work in a domain where hardware, network and operating systems (firmware) can all be bespoke.

• Expecting network utilities not to seek capture and allowing them to convince you you should use a cellular network model instead of a wifi network model (as some once did with wifi).

Many people want to pretend that these things can all be worked out in the abstract but as with so many things in life, often a simple experimental ‘suck it and see’ approach makes sense and everyone is educated on the journey.

These experiments only make sense if there is a guaranteed path to scaling and operationalisation. A proof of concept not based on a long-term approach won’t help validate the true costs. Essentially, thinking an agile approach can be applied to producing an end to end solution is mistaken.

It is natural for people in large organisations to make decisions based on what seems safe, what is convenient, received wisdom, fringe benefits (e.g. corporate hospitality). Often, over the long term, these decisions lead to:

• an order of magnitude higher operational costs e.g. when you lock into a proprietary network utility rather than your own private or hybrid network

• an order of magnitude higher establishment costs i.e. because you choose to use technologies or partners that are not specifically set up to enable bespoke solutions within the required financial and operational envelope.

We would suggest that people accept that there are both known unknowns and unknown unknowns and make a small investment to learn through doing.