LoRa Basics Modem and LoRa Edge documentation

Scenario - Intermittent Network

Introduction

The LoRa Edge™ Asset Management Platform, built with the LR1110, uses LoRaWAN® connectivity as a prerequisite. This connectivity is used for multiple features of an asset management use case, including such things as:

  • Upstream reporting of sensor information (from the End Device to its Application Server).

  • Reporting pseudo-ranges of satellites signals acquired during a GNSS scan.

  • Maintaining the almanac, assistance position, and time for optimal assisted GNSS performance.

There will be situations where the connectivity is not reliable, and may be either cyclic or intermittent. For instance:

  • Changing propagation conditions, preventing End Device transmissions from reaching the network.

  • A gateway providing connectivity to a static device may drop-out for an extended period of time (for example, due to a power outage).

  • An asset tracking device, traversing a country or a continent, may experience a lack of connectivity for a period of time.

  • An end device connected to an LEO constellation, or any sort of non-geostationary satellite, with satellites (i.e., “space vehicles” or “SVs”) coming and going. If the constellation is not sufficiently dense, the network may not be available for hours at a time.

  • An end device connected to a terrestrial LoRaWAN gateway and using satellite back-haul only present at certain times of the day. Although the gateway collects end device packets, it cannot transfer them to its LoRaWAN Network Server. Therefore the connection to the Application Server, LoRa Cloud™ Modem & Geolocation Services, and the LoRa Cloud™ Modem & Geolocation Services are interrupted.

In all these situations, the LoRa Edge Asset Management Platform will experience consequences. These consequences shall be analyzed and forecast. Proper measures will be put in place by the application to improve the end-to-end system behavior.

Compatibility

LoRa Basics™ Modem(s)

LoRa Edge™ LR1110 transceiver

Prerequisites / Dependencies

  • The end device is joined to a LoRaWAN network

  • It has a recent download of the full GNSS almanac

  • The time has been recently updated

  • The assistance position is correct

Consequences of Intermittent Coverage

../../_images/missing_assistance.png

Although it is optimized for low throughput connectivity, the assisted GNSS built into the LoRa Edge Asset Management Platform, relies on the LoRaWAN network to deliver the LR1110 chip with time, assistance position, and orbital information of the GNSS constellations of interest. Intermittent network connectivity will create two issues for the A-GNSS system:

  • Inability to update the assistance position, device time, and almanac for various periods of time

  • Inability to report the scanned pseudo-ranges in near real-time, making the location solving either impossible or delayed

Device Time

Absolute time is an important input of the LoRa Edge assisted GNSS system. It is used to properly interpret the coarse orbital information of the satellites, obtained with the almanac downloads. The almanac data, in turn, is used to minimize the amount of time (and energy) it takes to acquire pseudo-ranges, by more precisely predicting when the satellites will be visible. Likewise, on the LoRa Cloud solver side, the accuracy of the capture time is an important factor with respect to position accuracy and success rate.

../../_images/assistance_specs.png

If the application has the absolute time (with an out-of-band method), the LoRa Basics™ Modem-E or LoRa Basics™ Modem can be time-adjusted by using the SetTime() command. The LoRa Edge Asset Management Platform offers an independent application-layer method to obtain / maintain absolute time, called Clock Synchronization, which is endorsed by the LoRa Alliance®. Despite its dependency on network delays, Clock Synchronization is the proper way to efficiently re-adjust the device time.

@startuml _clk_sync_flowtitle Simplified order of operations for\nClock Synchronizationskinparam linetype orthobox End-Device #ADD8E6 participant "End-Device Application" as UC #ADD8E6 participant "LoRa Basics™\nModem(s)" as modem #00ADEFend boxbox LoRaWAN® #AAAAAA participant "Network Server" as NS #D3D3D3end boxbox "Application Server" #ADD8E6 participant "Application Logic" as AppS #ADD8E6end boxbox LoRa Cloud™ #00ADEF participant "Modem & Geolocation Services" as MGS #00ADEFend boxUC -> modem : Enable Clock Syncmodem -> NS ++: Uplink with Clock Sync requestNS -> AppS : Uplink with Clock Sync requestactivate AppSAppS -> MGS : Call uplink/sendactivate MGSreturn Downlink request with\nClock Sync responsereturn Downlink Clock Sync responsereturn Downlink Clock Sync responsemodem --> UC : Time Updated Clock Sync event@enduml

The assisted GNSS methodology can tolerate up to +/- 120 seconds of error. With up to one hour in error, only satellites with a strong signal may be detected. Beyond one hour, it is most likely that the LR1110 chip will not return any pseudo-ranges, as it will fail to detect any signal broadcast by the GNSS constellations. Best practice, therefore, is to update the device time at least every seven days, which is the time it takes to accumulate up to +/-120 seconds of error, assuming the worst-case of a 200 ppm real-time clock (RTC).

../../_images/time_drift.png

  • Green: Best assistance

  • Blue: Good assistance

  • Grey: Worst assistance

Note

Future versions of the LoRa Basics Modem-E will make it possible to update the time only on a monthly basis.

Applications using SetTime() to synchronize the LR1110 modem or transceiver, should keep track of when the device’s time was updated. This enables an informed decision regarding whether to launch an assisted GNSS scan, depending on the age of the update.

On the LoRa Basics Modem-E, GetTime() informs the application if the LoRa Basics Modem-E has had timing, but does not indicate how old the timing data is. However if that command returns zero (0), it means that the time was never synchronized by the Clock Sync service, or that it was done too long ago.

If the application knows that the LR1110 is not well time-synchronized, it should default to using autonomous GNSS scan, presuming that the resulting NAV message can be sent within two minutes of the acquisition. Otherwise, assisted GNSS scans should be delayed until the LR1110 chip has successfully re-acquired time.

Note

Autonomous GNSS scan results may be sent to the LoRa Cloud services up to two minutes after the scan. If they are sent later, the scan time shall be appended to the request (the API supports this).

Assisted scans permit the acquisition of SVs with a weaker signal, whereas an autonomous scan is restricted to the acquisition of SVs with stronger signals.

Device Assistance Position

Assisted GNSS scans rely on the LR1110 having received approximate location information (within +/-150 km for minimal assistance). This approximate location data helps minimize the scan time and energy. The assistance position can be obtained out-of-band, or can be updated through applicative downlink packets. The source of the location could be information such as a Cell ID, or the result of a recently-solved position, delivered to the application server by the LoRa Cloud Modem & Geolocation Services, and subsequently delivered to the end device as an assistance position.

All use-cases concerning assets travelling over long distances are subject to the obsolescence of the assistance position. For example, consider the case of a truck with a pallet transporting a car engine from a factory in the Czech Republic, through Austria, Switzerland, France, and eventually to Spain. Roaming agreements between incumbent LoRaWAN operators in those countries may be such that the asset (the pallet) could enjoy connectivity in all countries but Switzerland (note: this is not a real-life example). In this situation, the assistance position could become outdated, if for example we consider a 400km journey from St Gallen to Geneva, driven over the span of eight hours by a cargo truck.

An assistance position is good when it is more accurate than +/- 150km from the device. The more accurate it is, the less time and energy it takes to complete a GNSS scan. The best assistance is obtained within +/-50 km, and good assistance within +/-100 km. The least accurate assistance is within +/-150 km.

Note

The modem can be automatically updated with the position resulting from the latest LoRa Cloud™ Modem & Geolocation Services solver result, by parsing the downlink message called SolverUpdate. This field contains the last known position calculated by the service (as well as the frequency error information, computed from the solved doppler error of the satellites).

It is a good practice to update the assistance position relatively often if movement is foreseen and/or bad network conditions are expected. This can be done via the application, or it can be accomplished automatically with the SolverUpdate device management (DM) service. Depending on the application’s constraints, if the assistance position is not known or is predicted to be wrong, there are a couple of options:

  • Energy-wise approach: Elect for an autonomous scan instead of an assisted scan.

  • Best-effort approach: Launch an assisted scan nonetheless, and hope to gather a sufficient number of satellites for a proper location solution. However, with this approach the LR1110 chip will use more time to search for all satellites, and therefore use more energy. Note, too, that solving for the position of an end device may fail if the assistance position is too inaccurate.

Device Almanac

A valid almanac is the third pillar of GNSS assistance. In conjunction with accurate time and assistance position data, a valid almanac makes the LR1110 extremely energy efficient in acquiring pseudo-ranges, which are used by the LoRa Cloud™ Modem & Geolocation Services to resolve a position. The almanac assistance data can be up to 15 weeks old, with improved energy efficiency if it is more up-to-date. However, the LR1110 chip will not perform an assisted GNSS scan if the almanac is more than 15 weeks old. With adequate LoRaWAN connectivity, the LoRa Basics Modem-E and the LoRa Basics Modem implementations of the LR1110 chip, when connected to the LoRa Cloud™ Modem & Geolocation Services, maintain their almanac with as few as one (1) downlink per week. At any given time, by looking at the uplink DM messages, the LoRa Cloud™ Modem & Geolocation Services know which portion of the almanac (and for which SVs) an update is required. Therefore, it will trigger a downlink request, queued to the application server, and eventually served by the LoRaWAN infrastructure down to the end device.

Intermittent coverage can result in the obsolescence of the almanac data; however, it is a very slow process. Whilst local appraisal of the age of the almanac isn’t currently supported, the application should increase the recurrence of uplink DM frames, including DM_INFO_TYPE_GNSS_ALMANAC_STATUS, if intermittent network coverage is expected. This will create more opportunities for the LoRa Cloud™ Modem & Geolocation Services, when coverage is effectively available, to know the almanac status and update it if required. If the application on the end device knows that the almanac is outdated, it shall revert to an autonomous scan.

Position Resolution

Intermittent coverage, even in the case of a successful GNSS or Wi-Fi scan, may prevent the end device from delivering NAV messages to the LoRa Cloud™ Modem & Geolocation Services. Three distinct intermittent network situations lead to different possible implementations for the application:

  1. For situations where the coverage may be intermittent with no predictable pattern, the recommendation for sending NAV messages up to the network is to use Semtech’s LoRa Cloud™ Modem & Geolocation Services’ streaming service. In addition to being capable of fragmenting packets which are potentially too large for the MTU available at the time and region of the request, it adds forward error correction data to the stream. Unreliable uplink traffic, due to a significant Packet Error Rate, or an intermittent connection, can eventually be recovered by the LoRa Cloud™ Modem & Geolocation Services, thanks to the added error correction codes.

  2. If the application knows that the network will only be available for a small portion of the day (for instance, consider a connection to a gateway installed on only a few LEO satellites), a good practice is for the application to anticipate these timeslots and only send or stream NAV messages at times when the infrastructure is predicted to be available. With the device time being maintained to within +/- 120 seconds, such a (loosely) synchronized upstream methodology will be acceptable.

  3. If the system is such that the gateways have a satellite backhaul that is only enabled for small portions of the day, the application behavior may be different. Gateways working in this type of environment will typically propose a “store and forward” mechanism, allowing them to store the LoRaWAN traffic locally and then deliver it when the backhaul is available. The recommendation in this case is to stream NAV messages as they are produced and send them upstream with their timestamps, giving the infrastructure an opportunity to resolve the position(s) offline.

Note

If the timestamp is delivered to the LoRa Cloud™ Modem & Geolocation Services along with the NAV message, positions may be resolved offline by the LoRa Cloud™ Modem & Geolocation Services up to six (6) days after scans are performed.

Appendix: Verifying Connectivity

There are a few different methods for verifying whether connectivity is present. It may be useful to focus the uplink traffic (which is consuming energy), only on those times when the network is available:

  • Beacon Sniffing over LoRaWAN

  • Confirmed Uplinks over LoRaWAN

  • Connection Timeout Verification

Beacon Sniffing over LoRaWAN

LoRaWAN networks supporting Class B include a significant proportion of gateways that participate in “network beaconing”. In principle, there are a sufficient number of beaconing gateways to offer the same coverage as using a confirmed uplink (whereas additional beacon-less gateways, typically placed indoors, may be added for capacity and redundancy purposes, most probably in dense urban locations).

By default, a beacon is sent every 128 seconds. Its main purpose is to provide the time in its “common part”. However, any device can leverage the beacon to see if there is a LoRaWAN network available. The beacon’s common part, sniffed by an end device, maybe that of any LoRaWAN network. Only networks implementing a Gateway Specific (GwSpecific) field appended to the beacon will make it possible to identify the network carrier broadcasting that beacon, as this optional portion of the beacon transports the NetID, unique to a network.

Note

Scanning the beacon, although it has an impact on the energy consumed by the end device, may enable the device to acquire time and position assistance, in addition to checking connectivity.

Connection Timeout Verification

A more elegant, and less downlink-intensive approach to verifying connectivity, is the SetConnectionTimeout() / GetConnectionTimeout() function of the LoRa Basics Modem-E. In steady-state, any LoRaWAN network will generate downlink traffic, either for applicative purposes, or for network maintenance, with carrier-triggered MAC commands. For instance, the deployment of new channels, ADR commands, etc. The LoRa Basics Modem-E counts the number of uplink packets it has sent (via an application or DM messages), without seeing a downlink from the network, and can inform the application if it invokes GetConnectionTimeout().

Note

Support for GetConnectionTimeout() is planned for future releases of LoRa Basics Modem-E.

Used By

Application MCU

Troubleshooting

No suggestion at this time.