Knowledge Base

Frequently Asked Questions

In the Class B principle, the latency is not defined by the number of nodes, but by the latency that the node requests to the network. If it negotiates 32 seconds with the network, then on average, it will be listening to the network every 32 seconds. When the load increases for Class B on a specific gateway, the impact is not delay but potentially overhearing of more than 1 device on a defined “meeting point”, in other words if the gateway is out of time slots, it may assign the same time slot to multiple devices. This would cause these devices to lengthen their listening time (and therefore consume more energy), even when the “other” device is interrogated. This impact is mild obviously, on the basis that network actuation is meant to be scarce (a few times per day typically).

If the end-device did not receive the downlink frame during the first receive window “RX1”, it must open a second  receive window “RX2”. Note that the end-device does not open the second receive window if a frame intended for this end-device has correctly checked the address and MIC (message integrity code) during the first receive window.

It is region specific. For EU863-870, the maximum application payload length is:

  • 51 bytes at SF12 / 125 kHz (lowest data rate)
  • 51 bytes at SF11 / 125 kHz
  • 51 bytes at SF10 / 125 kHz
  • 115 bytes at SF9 / 125 kHz
  • 222 bytes at SF8 / 125 kHz
  • 222 bytes at SF7 / 125 kHz
  • 222 bytes at SF7 / 250 kHz
  • 222 bytes at FSK / 50 kpbs

ADR stands for Adaptive Data Rate. The ADR feature is used to adapt and optimize the following parameters of a static end-device:

  • Data rate,
  • Tx power level,
  • Channel mask,
  • The number of repetitions for each uplink message.

The end-device decides to enable ADR. Once ADR is requested by the end-device, the network can optimize the end-device’s data rate, Tx power, channel mask and the number of repetitions for each uplink message. 

Commissioning (or on-boarding) an end-device on a network is the process of securely transferring to the network server data base and to the device:

  • The end-device’s DevAddr.
  • The end-device’s Network Session Key (NwkSKey) and Application Session Key (AppSKey).
  • To which destination (IP addr of the application server) the end-device’s uplink frames should be routed.
  • The end-device’s important characteristics (class , type, short description).

This happens only once: at the end-device life start

  • RECEIVE_DELAY1 is a fixed configurable delay in seconds. Default is 1 second. If RECEIVED_DELAY1 implemented in the end-device is different from the default value, RECEIVED_DELAY1 must be communicated to the network using an out-of-band channel during the end-device commissioning process. The network server may not accept parameter different from its default value.
  • RX1 frequency uses the same frequency channel as the uplink.
  • RX1 Data Rate is programmable, can equal or lower than the uplink data rate. By default the first receive window data rate is identical to the data rate of the last uplink.  


  • RECEIVED_DELAY2 is a fixed configurable delay in seconds. Must be RECEIVE_DELAY1 + 1 second. Default is 2 seconds. If RECEIVED_DELAY2 implemented in the end-device is different from the default value, RECEIVED_DELAY2 must be communicated to the network using an out-of-band channel during the end-device commissioning process. The network server may not accept parameter different from its default value.
  • RX2 frequency is a fixed configurable frequency.
  • RX2 Data Rate is a fixed configurable data rate.

It is region specific. For EU863-870, it  is from 250 bps to 11 kbps with LoRa® modulation and up to 50 kbps in FSK modulation mode.

No. ADR does not override the frequency channel but enable the use of the pre-configured channels through a channel mask. 

The maximum number of uplink channels is dependent on the PHY band in use. PHY bands like the European one handle a maximum of 16 channels. 3 default channels which can't be modified + 13 channels which can be created/deleted/enabled/disabled. PHY bands like the US915 handles a maximum of 72 channels. They exist all the time but can be enabled/disabled according to the local regulator rules. PHY bands like the CN470 handles a maximum of 96 channels. They exist all the time but can be enabled/disabled according to the local regulator rules. The channels are defined as described below. Channel frequency between 100 MHz and 1.67 GHz in 100 Hz steps. Data rate range (min. and max.)

Yes, LoRa technology can potentially apply to any frequency band, although its spread-spectrum nature makes it more relevant when at least a few MHz of spectrum is available.Currently, the use of LoRa is limited to the bands of frequency proposed in the SX1276 device. Our next generation devices will implement continuous coverage from VHF to 1 GHz.

Antenna diversity has been tested in the field. Mathematically, one would expect a 3dB gain in link budget with two antennas vs. a single one. The important effect with antenna diversity is that when one antenna is in a deep fade, the other can sometimes been seen to report a 10-12dB gain in signal-to-noise ratio. The uncertainty of the time-stamping in the gateway is significantly improved as signal-to-noise ratio rises. The uncertainty of the time-stamping rapidly rises as the signal approaches the extent of the sensitivity. Therefore, when a gateway is close to the maximum range, or simply in a deep fade caused by strong multipath the antenna diversity can make all the difference between presenting a usable time-stamp and one that is simple thrown away. Statistically the field test data show that increasing antenna diversity form one to two reduces the average uncertainty by 20%. In this test, both antennae were vertical 5dBi omni-directional spaced 1 meter apart horizontally. See the graph below for further details: 


The MAC command RXParamSetupReq/Ans are used to change the RX windows parameters (including the delay between end of TX and start of RX window). This command is acknowledged by a RXParamSetupAns uplink from the device. However if the acknowledgement uplink is lost , the network server has no ways to know if the device did or did not changed the timing , therefore the device can become unreachable.

This issue is addressed by the LoRaWAN specification starting at version 1.0.1 and GitHub LoRaMac-node firmware starting at version 4.3.0.

Mainly the solution is to make RXParamSetupAns and RXTimingSetupAns sticky up until a downlink from the server is received by the end-device.

Please refer to LoRaWAN 1.0.1 specification chapters 5.4 and 5.7 “The RXParamSetupAns / RXTimingSetupAns commands should be added in the FOpt field of all uplinks until a class A downlink is received by the end-device. This guarantees that even in presence of uplink packet loss, the network is always aware of the downlink parameters used by the end device.”

Please note that for end-devices based on versions prior to 1.0.1 of the LoRaWAN specification there is no real solution.  

Tx Power: this should be done with a power-meter or a spectrum analyzer (SA). If using the latter, make sure that the RBW (Resolution Band Width) is made large enough (typically 1MHz for a LoRa BW of 125kHz) to integrate the whole power during CSS modulation. Ensure that the transmitter is set to Tx Continuous mode for this test.

  • Channel masks should be checked with a SA, according to the latest EN 300-220.
  • Spurious emissions and harmonics should be checked as with any other RF transmitter, also in accordance with the European norm.
  • Sensitivity measurement should be performed with a Packet Error Rate (PER) test, as opposed to Bit Error Rate (BER) test, because of the nature of the LoRa modem. At present, none of the instrumentation vendors supports LoRa modulation natively (unlike Wi-Fi or BT for instance). Therefore, we need to use an Arbitrary Waveform Generator (ARB) to perform this test. Semtech supports Rohde &Schwarz's (R&S) SMBV100A ARB, and can provide pre-calculated frame in .wv format in order to perform tests.

LoRa Alliance is an open, non-profit association of members that believe the internet of things era is now. Our mission to standardize Low Power Wide Area Networks (LPWAN) being deployed around the world to enable Internet of Things (IoT), machine-to-machine (M2M), and smart city, and industrial applications. The Alliance members will collaborate to drive the global success of the LoRa protocol (LoRaWAN), by sharing knowledge and experience to guarantee interoperability between operators in one open global standard.

In other words, the Alliance drives the standardization of LoRaWAN such that sensors can be connected anywhere around the world where network operators roll our LoRaWAN networks. The driving forces behind the Alliance are the Mobile Network operators and big industrial companies who all benefit from one global standard: LoRaWAN.

For a short introduction on the LoRa Alliance check this animation

The LoRa Alliance defines the processes for certification of modules, modems and sensors related to the LoRaWAN compliance. The actual certification is executed by test houses around the world and us such a company does not need to be a member of the LoRa Alliance to certify a module, modem or sensor.

When using a pre-certfified module or modem the sensor does not need to be certified for LoRaWAN compliance again. However additional certification for ETSI or FCC compliance (related to output power and duty cycle) will be required for any sensor before it can be subscribed to a LoRaWAN network.

For further information please check the LoRa Alliance website  or send an email to 

Out of the 50 billion predicted nodes to be connected to the Internet by 2020 fewer than 10% are predicted to use cellular technology. Telecommunications companies will need long range, high capacity systems to consolidate the fragmented battery operated wireless market for sensor networks, smart cities, smart metering, security systems, smart home, and industrial control.

With our LoRa RF platform, we have developed a 2-way wireless solution that complements M2M cellular or WiFi infrastructure, and provides a low-cost way to connect battery operated and mobile devices to either the network infrastructure or end point.

To visit Semtech's LoRa website click here.

LoRa is a wireless technology that has been developed to enable the Internet of Things using unique low data rate communication to be made over long distances by sensors and actuators. As LoRa technology is able to provide a wide area network capability, it is often referred to as LoRaWAN.

A LoRa network consists of several crucial elements to build an Internet of Things solution:

End points:  The endpoints are the elements of the LoRa network where the sensing or control is undertaken. They are normally remotely located.

LoRa gateway:  The gateway, also referred to as Base Station or concentrator, receives the communications from the LoRa endpoints and then transfers them onto the backhaul system. This part of the LoRa network can be Ethernet, cellular or any other telecommunications link wired or wireless. The gateways are connected to the network server using standard IP connections. On this way the data uses a standard protocol, but can be connected to any telecommunications network, whether public or private. In view of the similarity of a LoRa network to that of a cellular one, LoRa gateways may often be co-located with a cellular base station. In this way they are able to use spare capacity on the backhaul network.

Network server:  The LoRa network server manages the network and provides OSS, BSS and billing functions. The network server acts to eliminate duplicate packets, schedules acknowledgement, and adapts data rates. In view of the way in which it can be deployed and connected, makes it very easy to deply a LoRa network.

IoT Application:  applications connected to the network server can control the actions of the endpoints or collect /send data - the LoRa network being the transparent, secure and scalable connectivity layer.

The LoRa gateways 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, 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 in the backend. Gateways are connected to the 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 bidirectional, but also supports operation 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 versus tower). 

A LoRa Gateway is buit using the SX1301 whereas the final product operates as a base station in a LoRa Network. The base stations sends/receives all data to and from the sensors (end nodes) and is connected (backhaul) to a network server (OSS/BSS) for further processing of the data.

The LoRa® modulation is the PHY, and LoRaWAN is a MAC protocol for a high capacity long range and low power star network that the LoRa Alliance™ is standardizing for Low Power Wide Area Networks (LPWAN). The LoRaWAN protocol is optimized for low cost, battery operated sensors and includes different classes of nodes to optimize the tradeoff between network latency and battery lifetime. It is fully bi-directional and was architected by security experts to ensure reliability and safety. The architecture of LoRaWAN was also designed to easily locate mobile objects for asset tracking, which is one of the fastest growing volume applications for Internet of Things (IoT). LoRaWAN is being deployed for nationwide networks by major telecom operators, and the LoRa Alliance is standardizing LoRaWAN to make sure the different nationwide networks are interoperable. 

LoRaWAN is designed to provide Low Power Wide Area Networks with features specifically needed to support low-cost, mobile, secure bi-directional communication for Internet of Things (IoT), machine-to-machine (M2M), and smart city, and industrial applications. It is optimized for low power consumption and to support large networks with millions and millions of devices. It has innovative features, supports redundant operation, location, low-cost, low-power and can even run on energy harvesting technologies enabling the mobility and ease of use to Internet of Things.

To see a short introduction about the LoRa Alliance go here.


The specification document describes the LoRaWAN network protocol, this can be downloaded from here.


The LoRa Alliance is committed to interoperability, quality of the network as well as the end-points. LoRa Alliance member products are available throughout the eco-system. The LoRa Alliance Certified program leverages the expertise of industries and certification groups around the world and their expertize to ensure the vision of the alliance is maintained .

Members benefits of such a program are:

  • Certified Product
  • Interoperability testing
  • Use of LoRa Alliance Certified logo
  • Product listing on the Alliance website
  • Product promotion in Alliance collateral
  • Inclusion in Alliance product demonstrations

Types of Certification

LoRa Alliance Certified Product program ensures that product meet national frequency regulations as well as the LoRaWAN required and optional features to ensure interoperability and compliance.

LoRa Alliance Compliant Platform program ensure LoRaWAN interoperability and compliance of network infrastructure, components and offerings according to national frequency regulations and the alliance specification.

Authorized Test Service Providers and certification process

Only LoRa Alliance authorized test houses may perform testing for the alliance certified program. Applicable national conformity test reports and registrations are supplied together with the LoRa Alliance conformity report to the Alliance Certification body before receiving the right of Certified product or Certified platform.

Capacity is, first and foremost, a consequence of the number of packets that can be received in a given time. A single SX1301 with8 channels can receive approximately 1.5 million packets per day using LoRaWAN protocol.

So, if your application sends one packet per hour, then a single SX1301 gateway can handle about 62,500 end devices.