API Response Times

Integrations for LoRa Cloud™ APIs need to take response time considerations into account which are distinct for each group of APIs. In general, the APIs are optimized for common use cases under which expected response times well below one second. However, certain worst case conditions may lead to longer response times.

In order to maintain expected response times, please take into account the following design considerations:

  • Real time: The geolocation solvers and device communication endpoints are optimized for (close to) real-time data exchange. Consequently, running batches of historic data through the geolocation solvers is generally slower.

  • Device Communication: During the exchange of messages between the end device and LoRa Cloud™, particular uplink messages may trigger the implicit invocation of geolocation solvers. This may lead to response time variability.

  • Input parameters and data quality: The geolocation solvers execute numerically intensive operations whose execution times often depend on the quality of the input data. Also, the choice of control parameters can influence the execution time.

  • Multi- and bulk- APIs: The response times of bulk API operations and multiframe solver calls in the worst case scale linearly with the number of submitted elements.

The following tables give guidance on the expected orders of magnitude in the response times under normal and worst case conditions (excluding network latencies). LoRaCloud API consumers may assume normal latencies for their general system design but shall be able to handle worst case response times in exceptional cases.

Geolocation Solvers

Response time variability of geolocation solvers can be caused by data quality and age, choice of input parameters and use of multiframe APIs. In the case of the GNSS solvers, data quality can be impacted by partial sky view, missing clock synchronization, or aging almanac on device. The accuracy of input parameters like aiding time and aiding position have an impact as well. Furthermore, fastest responses can be expected under real-time operation as opposed to (re-)submission of historic data.

API Response Times Geolocation Solvers (excluding network latencies)

API Endpoint

Response Time normal

Response Time worst case

/api/v2/solve/loraWifi (Wi-Fi)

< 1 s

< 10 s

/api/v3/solve/gnss_lora_edge_singleframe

< 100 ms

< 10 s

/api/v3/solve/gnss_lora_edge_multiframe (N frames)

< 1 s

< 10 s (*N)

/api/v3/solve/singleframe (TOA/RSSI)

< 100 ms

< 1 s [TBD]

/api/v3/solve/multiframe (TOA/RSII) (N frames)

< 100 ms

< 1 s (*N) [TBD]

Real Time Communication API

Response time variability of the real time device communication API is caused by the type of uplink message. Implicitly, a geolocation solver (Wi-Fi or GNSS) may be invoked, where the corresponding response time considerations apply.

API Response Times - Real time communication (excluding network latencies)

API Endpoint

Response Time normal

Response Time worst case

/api/v1/device/send

< 100 ms

< 10 s

/api/v1/uplink/send (N uplinks)

< 100 ms

< 10 s (*N)