Frequently Asked Questions
Yes. The core function is not reliant on storage and is architected to be able to scale within a cloud or on-site computing platform.
Does LoRa® Location support the requirements of historical track and trace and other forms of legislation?
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.
If a licensed network decides to assign ‘local’ or ‘private’ device EUI then it is not possible to support movement between networks.
If this is the case, then devices should be indicated as ‘private’ in the usage report. In this case, the usage will not be covered on any other LoRaWAN network.
Yes. The first time a device appears in the usage log of a licensed network, that device will be invoiced and covered for one year of service on any licensed network.
The first licensed network to record usage of the device is charged. No other network will be charged within a calendar year.
Semtech levies a small annual fee for each LoRaWAN device to cover enabling the location service and coordinating global free movement of devices.
Each licensed network operator is required to submit a list of active devices within their network each month. Semtech aggregates all the usage data across all licensed networks word-wide and invoices each licensed network operator (via the licensee who would normally be the system integrator or the network server provider). Each licensee has the option to list a device as ‘on service’ in the network server provider). Each licensee has the option to list a device as ‘on service’ in starting period for the service for any device will be the first month that it appears in a usage list or as ‘on service’.
The usage fee covers a calendar year of world-wide service and any device that is already paid on one network will not be invoiced on any other network. For devices that are not listed as ‘on service’ within any licensed network then, the first time a device appears in the usage report of a licensed network, that licensed network will be invoiced and cover world-wide usage for a calendar year.
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.
The license requires the gateway manufacturer to stick with certain components to ensure consistency and also to submit a sample for time-stamping consistency tests. This will ensure consistency across different vendor’s products and allows best-in-class choices for network deployment at all stages.
Manufacturing partners wishing to manufacture location-ready gateways can license the technology by signing an agreement with Semtech. Semtech will ensure that the partner can offer the consistency and quality required of such a gateway.
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.
What sensors support ‘data fusion techniques' and what does it do to the accuracy, cost and power consumption?
There are already GPS based sensors available in the LoRa catalog. There is currently a lot of activity within the ecosystem combining sensors with gyros, sniffers and other technology that will open up a whole range of possibilities for accurate location determination. It is currently too early to demonstrate these with Semtech’s in-house system however, it is expected that within 2016 some of these will start to appear on the market.
Semtech says that multi-path is the largest contribution to location uncertainty, how can multi path be mitigated in the sensor?
Frequency diversity is a really powerful way to mitigate multipath. Sensor firmware can be optimised to change the data-rates, channels and pack burst rates can certainly help. Also, data fusion techniques can have very powerful effects.
Data fusion with sniffing has been proven in mobile phones over several years. These kind of techniques could be used to significantly reduce the location uncertainty.There are a great many possibilities by using the LoRa uplink to convey meta-data for use in the solver. Semtech is expecting that many partners and third parties will work to add features to the sensor and solver that work together to bring a high accuracy low cost solution.
Semtech says that multi-path is the largest contribution to location uncertainty how can multi path be mitigated in the deployment?
The best mitigations for multi path are to increase diversity:
- Increased antenna diversity- adding multiple antennas to gateways. This is good for all sensors.
- Gateway diversity- adding more gateways. This is good for all sensors.
- Gateway height- reducing the objects present within the first Fresnel zone in the transmission field. This is good for all sensors.
- Frequency diversity- more channels spread over a wider spectrum allow more packets to be analysed and discarded. This is particularly good for static or semi-static sensors.
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.