Knowledge Base
HOME » KNOWLEDGE BASE » FAQ

Frequently Asked Questions

  • The mobile device is handed over to another network operator
  • Data is still routed through the home network

  • For handover roaming the device must periodically broadcast a special"rejoin request” frame.
  • The rejoin request frame has been defined in LoRaWAN Rev 1.1
  • LoRaWAN Rev 1.1 is required for mobile roaming between networks without interruption.
  • Service provided over multiple public partner networks with non-nomadic devices.

  • NetID is a 24 bit network identifier which gives the possibility of 16 million networks.
  • NetID is part of the Rejoin frame broadcast by roaming end devices used to find the home network of a device.
  • NetID is allocated by the LoRa alliance.
  • NwkID consists of the 7 LSBs of NetID.
  • All DevAddr of a network start with NwkID

  • A device's uplink can be received by two networks simultaneously
  • The device doesn't even know that it is roaming

  • For passive roaming we need to use different network session keys for uplinks and downlinks:
    • LoRa V 1.1 implements a new dual NettSkey key derivation.
    • The scheme reverts back to 1.0 if the server does not support it.
  • A lot more than 2^25 = 33 million
  • Actual device identifier is DevAddr+NetSKey so the same DevAddr can be reused many times.

The answer is many billions. Once you reach a billion a new NetID will be allocated by the Alliance. 

With the early trial data, Semtech is recommending a 3km ISD in most rural cases as a guideline. There is, however, no substitute for detailed network planning and the coverage target should be four gateways. Targeting a configuration giving a four gateway redundancy means that in most cases, the sensor will be in coverage of all four, and in almost all cases will have the required minimum of three. 

Version 1 of Semtech’s solver requires approximately 1.2kB of storage per device. 

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.

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:

  1. a consistent time-base at easy receiving gateway,
  2. 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. 

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.