Frequently Asked Questions
From a data prospective, a gateway 15 km away from an end device can still perfectly receive the data in a rural environment. However, to be geo-located, you will need a minimum of three gateways receiving the message.
Keep in mind that the more gateways that are receiving the message, the more accurate will be the geo-location. If you are in the center of an imaginary triangle with one gateway at each corner, and each gateway is 15 km from you, you will be able to be geo-located with an accuracy of 20 to 50 meters.
Accuracy is affected by many parameters, however, with good network planning and coverage, one can expect a mean uncertainty of 120m to 200m in an 8-channel urban LoRaWAN deployment. Packet repetition (time and frequency) diversity has a powerful effect. The sensor will normally randomly select one of the configured channels to transmit any particular packet. This inherently implies frequency diversity with packet repetition.
In field trials conducted in an urban environment configured with eight LoRaWAN uplink channels, the advantage of packet repetition diminishes significantly after 6-8 packets. This suggests that the most significant part of the gain in packet repetition is provided by the frequency diversity effect of transmitting on different channels. Therefore, it is not recommended to configure for packet repetitions beyond the number of channels configured in the LoRaWAN system.
An example is shown below (an 8-channel system in an urban environment):
What are the requirements for reporting usage to Semtech? What entity is responsible and what information must be provided?
The licensee of the location service is responsible for providing the information to Semtech.
Semtech is flexible in supporting various formats for the provision of the usage report. However, the information required should be; Device EUI, date of first use, data of last use, ‘on service’ or ‘home network’ flag, indication if the device EUI is unique or private.
Semtech and the licensee will come to an agreement of the precise format that makes sense for the usage information.
Semtech believes that, in general, the provision of a location service is a feature that is added to the network server solution alongside the operation of LoRaWAN network. It is expected that optimization of the air interface with parameters like adaptive data rate etc. will become an integral part of the location service and therefore, this feature sits most obviously within the domain of the provider of the LoRaWAN network operation and network controller features that can optimise the radio resource management.
Since the capture of high resolution time-stamps is the basis for offering the geolocation service, the time-stamps have value to the provider of the location service. Gateways have no knowledge of which devices require location service so the gateway must time-stamp every packet.
The encryption of the time-stamps protects the valuable time-stamps from unauthorized use. Thus, the owner/operator of the network can choose precisely where the decrypted time-stamps are sent.
LoRa location is built around the requirement that the same transmission is received by multiple antennas.
The difference in the time of arrival is the primary piece of information used to determine the location from which the transmission came. In order to make this system work it requires two things:
- a consistent time-base at easy receiving gateway,
- a consistent way to detect and time-stamp an arriving packet.
Since a 3ns error represents 1m in distance, these two things need to be as accurate and consistent as possible. Semtech designed the LoRa radio scheme so is in the best position to generate the technology to time-stamp the arriving packet. Semtech decided to create such I.P. and embed it into a reference design that is licensed to manufacturers. Ensuring that all licensed gateways use similar I.P. to capture the packet arrive time-stamps ensures that the location technology works even if there is more than one type of gateway deployed in the network.
If my sensor is detected by 3 or more gateway then LoRa Location will give me a position even if the sensor is deep indoors right?
As long as the algorithm gets time-stamps from 3 or more receiving gateways, then it will attempt to resolve a location.
Many tests have been conducted with ‘light indoor’ sensors. In general, with indoor sensors, the location uncertainty increases but the system still works.
LoRa transmissions are almost unaffected by vehicle speeds due to the type of modulation used.
LoRa is one of the most robust low power transmissions with respect to moving objects and does not suffer the kind of Doppler issues that limit ultra-narrow-band transmissions to very slow speed. LoRa can happily accommodate normal vehicular speeds.
With respect to location, as frequency diversity (read multiple transmissions on different frequencies) is a powerful tool in reducing the uncertainty this is not so easy with high-speed moving objects. With a moving object algorithms that analyse the speed and direction of movement and other things like ‘is it tracking a road’ can be used. Semtech’s first release does not include moving sensor optimisation.
Semtech is actively looking at all options for improving the performance offered to all licensees. Semtech has been in active development both internally and with third parties up to the point of the first release and this is expected to continue. Semtech does not believe that the common solver approach will best serve the specific use cases of all users so is expecting Licensees to integrate multiple solvers some of which might be application specific in order to cover the needs of the wider use cases.
Semtech has built a system upon which development and differentiation is expected in the market place. Licensees are given the source code for Semtech’s solver. The Licensee is then entirely at liberty to use any means to improve the solution to reach the performance that is important to the use cases that drive the Licensee’s business. The Licensee can choose whether to invest development resources, sub-contract, purchase I.P. or rely on Semtech.
Semtech has built ‘base camp’. This is a generalised solver without any knowledge of the application of the sensor. There are many ways that the solution could be improved such as knowing if and when a sensor moves, bursting several packets rapidly, knowing any geographic constraints such as ‘stick to roads’ etc. etc.
With the release of version 1, Semtech is involving the partners in the eco-system to build more networks, capture data and develop the solution to fit various use cases.
How will updated Semtech solvers be made available to the market; system integrators, network operators and end customers?
Semtech will make the updated solvers available directly to the licensees of the Location service. This, in general is the system integrator. Semtech makes the solvers available as source code and, following receipt, the system integrator will choose whether to integrate the new version into their product. Since the solver is provided in source code, it is expected that the development of the solvers are not limited to the work conducted within Semtech. It is expected that third parties will become involved and create differentiation in the market place. Therefore, the schedule of updates should be discussed between the end user and the provider of the location service.
The time-stamping firmware has been extensively tested. The performance in the resolution of the received signal is very close to the lower bound of Cramer Rao lower bound for estimation of arrival time. As shown in the graph below, the uncertainty is dependent on the signal-to-noise ratio at the receiver compared to the sensitivity level. The development of the time-stamping firmware is not expected to make any big leaps forward. There may be some minor improvements but in general, it is felt that improvements will come from the solver and statistical analysis of packets and location rather than time-stamp improvement.
As can be seen the estimation uncertainty reduces very rapidly with increasing signal-to-noise ratio above the threshold of sensitivity. This is one of the reasons why antenna diversity is important; as when a packet arrives with poor signal-to-noise ratio on one antenna there is a chance that the second antenna will receive it at s significantly better signal-to-noise ratio and, hence have a much improved arrival time estimation.
The GPS time-base has been measured to generally contribute less than 20-30 meters uncertainty to the calculation. A more stable time-base and one that mitigates the problems of GPS (GNSS) transmissions and multipath would remove one of the uncertainties. Semtech has measured some different GNSS receivers with a variety of antennas and it is possible to improve the precision. The GPS time-base error is, however, one of the smaller parts of the uncertainty in the resolved location.
It is feasible to create a near-line-of-sight deployment in a rural area. It is almost impossible to create a true line-of-sight deployment (ie. without any multipath element to the signal received). Semtech has made experiments with NLOS deployment and even without keeping the first Fresnel zone clear (due to lack of antenna height) very good results were achieved.
Semtech states that target gateway diversity is 4 for location and 2 for data, does that mean that a deployment for location requires twice as many gateways?
The answer to this question is ‘not necessarily’. It is always recommended to have a gateway diversity of at least 2 for data coverage for a fixed sensor for a number of reasons including minimization of black spots in coverage, downlink collisions, interference local to the gateway etc.To answer the question on the density of gateways required for LOC one first has to answer,
a: is the data coverage planned to cover indoor?
b: Is the location required primarily outdoor?
If the answer to both of the questions above is ‘yes’, then the additional gateways required for location is likely to be very small. The reason for this is that the path loss from outdoors to indoors is normally well in excess of 20db. Therefore, if a deployment provides the recommended diversity of two indoors, then it is highly likely that outdoors in a similar location will have a gateway diversity of 4.
If, however, the answer to the above question is that indoor coverage is only targeted at one or even not at all, then additional gateways should be planned to operate the location service.
If gateways are using GPS for precision timing, do you have any guidelines for the GPS installation?
There is a lot of data to confirm that GPS timing performance is significantly affected by (1) the constellation of satellites in view, (2) interference or multipath. The recommendation is that the GPS antenna location is carefully considered to give the maximum ‘view’ of the open sky and if possible to reduce the effects of signal reflections from other sources. Semtech can provide a short study on the effects of GPS antennas and chipset configuration on the timing accuracy of the recovered 1pps signal. For deployment, the main influence is the antenna installation.
Results show that location uncertainty reduces with the number of packet repetitions, but the effect diminishes after 6 to 8 packets, why is that? Would increasing the number of channels help?
Evidence suggests that increasing the number of channels would make a positive impact on accuracy since it would increase frequency diversity. Any kind of diversity aids the algorithms in the solver to make better choices and weight the data presented in a more effective manner. Until now, the field data has only been collected for 8 channel European LoRaWAN deployment. Once more data is available this assumption can be validated and more detail added to this.
Results show that location uncertainty reduces with the number of packet repetitions, but the effect diminishes after 6 to 8 packets. Why is that, if I need better precision can I just send more packets?
To some extent the answer is yes, however, that is not the whole story. The main benefit of packet repetition is obtained due to the fact that the different packets are sent on different frequencies. Since the channel selection is random, there is no guarantee that 8 packets sent will cover all the channels in an 8 channel system, however, one would expect that, statistically most of the channels would have been used. The effect of changing the frequency is to change the multipath effects experienced by the signal bouncing off the different buildings and other objects. Once the algorithm has received a packet on each available frequency then the improvement becomes rather small. There is some variance of the multipath due to time but field data suggests that it is rather less than the frequency related and would, therefore, give minimal benefit. So, for an N channel LoRaWAN deployment, the benefit is mostly brought with approximately N packets transmitted.
Until June 2016 the only non-urban data that is available is a rural near-line-of-sight trial. The trial is detailed in a separate report but the summary is that in a near-line-of-sight trial, the mean uncertainty measured was 20 to 50 metres as shown below: