LoRaWAN® Geolocation Server

Any LoRaWAN®
device can be
geo-located

The LoRaWAN® Geolocation Server operates under a variety of algorithms. The simplest option involves computing the signal-to-noise ratio for each copy of a packet. The Geolocation Server will then return the device’s most probable location based on the information in each packet. LoRa Geolocation Server supports multiple-frame queries and can also process multiple packets sent from the same location at the same time.

The LoRaWAN® Geolocation Server needs several gateways, each with their own antenna. Each gateway will transmit multiple packets, and one will receive one of them. The gateways will measure RSSI to determine location accuracy. Then the LoRaWAN® Geolocation Server will match these two sets of packets and determine its location. This way, the data will be more accurate than ever. This technology will also reduce the number of errors in the LoRaWAN® network.

No requirement for GPS enabled devices

Any LoRaWAN® device can be geo-located

KONA Mega and Macro integration

Unencrypted Timestamps

TEKTELIC or 3rd Party Network Server integration

  • Functions
  • Basic Features
Gateway Information Provided

The Packet Forwarder uses a localization API that resides in the hardware abstraction layer (HAL) to timestamp received UL packets. The packet forwarder calls functions provided by this particular software architecture, which are selective for certain end devices depending on their importance or value within your solution.

The timestamp and other meta data from an UL packet are sent up to the network server using a special TOA Packet (as opposed to attaching them directly). This guarantees that your packets won’t be delayed because of estimation signal processing delays. The formatting for these types or interfaces between forwarders/servers is decided by their respective vendors; integration with Actility and Loriot’s products has been progressing recently too.

Localization API Features
  • In a Mega gateway, the localization API calculates the TOA on all installed antennas even if antenna diversity is not configured for packet reception
  • The RMS uncertainty values reported by the localization API enable the resolver to ignore unreliable TOA and FO estimates resulted from interference in the ISM band.
  • The current version of the TOA estimation engine supports spreading factors 7 to 12.
  • The localization API returns five numbers per received UL packet per antenna:
    • toa_sec: the seconds portion of the time of arrival in unix epoch time coordinate
    • toa_nsec: the nanoseconds portion of the time of arrival
    • fo_hz: the frequency offset of the received packet in units of Hertz
    • toa_u_nsec: the RMS uncertainty in the calculated time of arrival (in units of nanoseconds)
    • fo_u_hz: the RMS uncertainty in the calculated frequency offset (in units of Hertz)
TEKTELIC Packet Forwarder

The current version of the TEKTELIC packet forwarder performs TOA estimation on a best-effort basis, meaning all received UL packets are included for time-of-arrival estimation. Other scheduling algorithms can be implemented in order to prioritize certain packets based upon application needs.