Knowledge Base
HOME » KNOWLEDGE BASE » FAQ

Frequently Asked Questions

The LoRaWAN certification process with Espotel is as follows:

  1. Contact Espotel for a quote. We can guide you through the whole process.
  2.  Prepare your product(s) for certification. We can guide you through these requirements.
    • Must fulfill 2015-LoRaWAN_Specification_1R0_611_1. The specification is available from the LoRa Alliance.
    • Must fulfill LoRa Alliance End Device Certification Requirements for EU. The specification is available from the LoRa Alliance.
  3. Fill in the certification questionnaire. The questionnaire is available from the LoRa Alliance.
  4. Send your product to us. It should be ready for Over the Air activation or already personalized.
  5. We run the certification tests and send you the results.
  6.  If test passed, either we or you can provide the results to LoRa Alliance.
  7.  If test failed we will give you the diagnostics and help you to fix the problem. Then follows a retest (step 4 again).
  8.  Alliance reviews the passed test result and produces the LoRaWAN certificate.

Results and basic product information are released on LoRa Alliance web page. This can be delayed if a certain product launch date is requested.

Full guidance through the LoRaWAN certification process. The certification testing includes test diagnostics and instructions for corrections in case your node fails.

Also a single retest round is included in the price if the node fails.

No, regulatory testing can take place before, after or at the same time as the LoRaWAN certification testing.

Espotel can also help you with the regulatory approvals, so that you get a full turnkey solution for your testing, certification and regulatory approval needs.

Every network operator agrees that they can only connect 10-15% of the predicted volume of IoT devices with cellular. WiFi and BTLE serve some applications well, but clearly are not going to connect moisture sensors for agriculture with WiFi. LPWAN, with the inherent long range and low power characteristics will be the ‘goto’ technology for IoT applications where remote locations, easy deployment, thousands of connections per gateway and long battery life are required.

Most analysts predict that 45-55% of predicted IoT volumes will be in the LPWAN space, see also the comparative volumes below as per SNS Research.

The main IoT applications for LPWA technology need a long battery life to enable 'fit and forget' or disposable end-devices, a low cost sensor or end-device BOM, and long range connectivity.

The applications where LPWAN's are applicable are endless, but if you look at the main applications driving the current network deployments they are intelligent building, supply chain, Smart City and agriculture. In intelligent building the main value driver is in insurance premiums and servicing.

In cold regions a broken water pipe has an approximate insurance claim of $50K, so insurance companies offer a premium discount if a building management solution is utilized. Having sensors know if the building or room was used can have significant reductions in service management and related expenses.

In supply chain any application that has a delivery or pick-up with associated inventory can have huge savings in inventory management and delivery route optimization. A smart trash monitoring solution reduces pick-ups by 40%.

In agriculture the needs are driven by growing food demands. Agricultures accounts for 80% percent of water usage, and the value of crops is extremely high, so having sensors to determine water usage, health of soil/crop, etc. is extremely important. Accurate irrigation and soil monitoring translates into significant cost savings in resource usage and improved profit with improved yields.  

The 64 bit Extended Unique Identifier (EUI) is comprised of two parts, the 24 bit Organisationally Unique Identifier (OUI) and a 40 bit serial number. The OUI is allocated  by the IEEE, and the serial number by anyone that owns an OUI, together they form the EUI. AppEUI and DevEUI are both special cases of EUI.

FPort values 1..223 are application specific with their meaning being defined by the application provider. The LoRa Alliance has not specified an assignment for any port in this range to a particular application.

Application payload encryption is typically carried out by the application server which may not have a record of Frame Count (FCnt). The Frame Payload (FRMPayload) is encrypted using the Application Session Key (AppSKey) which does not require FCnt and so this is not an issue.

Authentication however requires the Network Session Key (NwkSKey)  and this does require FCnt. This process is handled by the Network Server which does keep track of counters. 

If a time is booked for certification and an end node provided,  the test report will be delivered within one weeks’ time from the booked date.

The LoRaWAN certification testing tests for end node functionality, in other words it tests that node’s LoRaWAN protocol stack and application are compliant with the LoRaWAN specification.

The certification does not cover radio performance. Radio performance includes things such as the radiated power, radio sensitivity etc. These are key parameters for good performance when signal strength is poorer. This is also something where Espotel can help you.

For a network operator it would be useful to set minimum acceptable performance requirements for nodes. This would ensure that end customers get the best possible network coverage. If you are a LoRaWAN network operator, Espotel could help you to setup end node requirements. If you are an end node manufacturer Espotel may perform performance testing for your nodes.

This is possible, but there would be a need to convert an existing 802.15.4 or other mesh protocol to use the modulation format. Because of some of LoRa's features such as longer transmission time which increases link budget, single-hop is usually the best choice.

No, you do not need a gateway. You can easily implement simple protocols using LoRa, either with modules or with the chips themselves.

There are two primary reasons why you should use a module:

  1. It accelerates development, and you don’t have to write a whole bunch of underlying code to implement the radio system.
  2. It’s already fully FCC or ETSI certified, so you don’t have to go through expensive testing.

The open source code available online for LoRaWAN is implementing the LoRaWAN protocol for a chip-down implementation. If you go down this route the RF certification and LoRaWAN Certification will need to be re-done. 

The SX1301 device is the baseband signal processor for LoRa gateways. It takes 32 MHz, 1-bit I/Q digital baseband samples as an input. It is generally paired with two SX1257 front end digitizers, though it can be used with other forms of digital RF. This is often done with the 8 x SX1301 gateway architecture Senet uses in its network deployment.

It is possible to transmit and receive the LoRa modulation at many frequencies between 150 MHz and 1 GHz, such as 169 MHz, 433 MHz, etc. even in the licensed spectrum. However, most of the LoRa devices from Semtech have gaps in the sub-GHz band where they can’t transmit or receive. The Semtech gateway architecture is designed to operate only at 850 MHz to 1 GHz, although it could be easily adapted for other frequencies.

SX1272 has three programmable LoRa bandwidth settings: 500 kHz, 250 kHz and 125 kHz. It covers bands from 850-1 GHz.

SX1276 has bandwidths from 500 kHz to 7.8 kHz, and covers 150 MHz bands, 433 MHz, and 850-1 GHZ.

LoRa is a modulation format and the associated family of chips are from Semtech.

SIGFOX is a company that uses narrowband D-BPSK modulation to do wide area IoT networking.

NWave is a company that does some very similar things to SIGFOX using the Weightless standard.

Other ultra-narrowband companies work with a broader family of transceiver chips, but LoRa is available mostly from Semtech, and more recently from ST Microelectronics.

Semtech’s spread-spectrum modulation is well adapted for mobile applications, being insensitive to Doppler shift, and it also enables GPS-less geo-location, two areas where any narrow-band technology would struggle.

Lora gateways or concentrators are designed to be used in long range star network architectures and are utilized in a LoRaWAN system. They are multi-channel, multi-modem transceivers and can demodulate on multiple channels simultaneously and even demodulate multiple signals on the same channel simultaneously due to the properties of LoRa.

The gateways use different RF components than the end-point to enable high capacity and serve as a transparent bridge relaying messages between end-devices and a central network server via standard IP connections while end-devices use single-hop wireless communication to one or many gateways.

All end-point communication is generally bi-directional, but also supports operations such as multicast enabling, software upgrade, over the air or other mass distribution messages to reduce the on air communication time.

There are different gateway versions depending the desired capacity and installation location (home vs. tower).

The term gateway and concentrator are both used, but they are equivalent components in a LoRa system. In other industries the definition of gateway and concentrator may imply different components.

Accuracy is affected by many parameters, however, with good network planning and coverage, one can expect a mean uncertainty of 120m to 200m in an 8-channel urban LoRaWAN deployment. Packet repetition (time and frequency) diversity has a powerful effect. The sensor will normally randomly select one of the configured channels to transmit any particular packet. This inherently implies frequency diversity with packet repetition.

In field trials conducted in an urban environment configured with eight LoRaWAN uplink channels, the advantage of packet repetition diminishes significantly after 6-8 packets. This suggests that the most significant part of the gain in packet repetition is provided by the frequency diversity effect of transmitting on different channels. Therefore, it is not recommended to configure for packet repetitions beyond the number of channels configured in the LoRaWAN system.

An example is shown below (an 8-channel system in an urban environment): 

Two kinds of complimentary roaming processes for mobile devices have been defined in LoRaWAN R1.1

  • Passive roaming
  • Hand over roaming

Together with:

  • Class B
  • Temporary class A/C mode switching