Chirp Spread Spectrum (CSS) : Lora Alliance
Chirp Spread Spectrum (CSS) : Lora Alliance
LoRa is a wireless modulation technique derived from Chirp Spread Spectrum (CSS)
technology. It encodes information on radio waves using chirp pulses - similar to the
way dolphins and bats communicate! LoRa modulated transmission is robust
against disturbances and can be received across great distances.
Don’t be alarmed about the complex terms; LoRa modulation and Chirp Spread
Spectrum technology are simple to understand in practice. In case you are curious,
in this video, Richard Wenner explains how Chirp Spread Spectrum technology
works:
LoRa is ideal for applications that transmit small chunks of data with low bit rates.
Data can be transmitted at a longer range compared to technologies like WiFi,
Bluetooth or ZigBee. These features make LoRa well suited for sensors and
actuators that operate in low power mode.
LoRa can be operated on the license free sub-gigahertz bands, for example, 915
MHz, 868 MHz, and 433 MHz. It also can be operated on 2.4 GHz to achieve higher
data rates compared to sub-gigahertz bands, at the cost of range. These frequencies
fall into ISM bands that are reserved internationally for industrial, scientific, and
medical purposes.
LoRaWAN
LoRaWAN is a Media Access Control (MAC) layer protocol built on top of LoRa
modulation. It is a software layer which defines how devices use the LoRa hardware,
for example when they transmit, and the format of messages.
The LoRaWAN protocol is developed and maintained by the LoRa Alliance. The first
LoRaWAN specification was released in January 2015. The table below shows the
version history of the LoRaWAN specifications. At the time of this writing the latest
specifications are 1.0.4 (in 1.0 series) and 1.1 (1.1 series).
Bandwidth vs. Range
LoRaWAN is suitable for transmitting small size payloads (like sensor data) over
long distances. LoRa modulation provides a significantly greater communication
range with low bandwidths than other competing wireless data transmission
technologies. The following figure shows some access technologies that can be
used for wireless data transmission and their expected transmission ranges vs.
bandwidth.
LoRa Alliance
The LoRa Alliance® is an open, non-profit association established in 2015. It
supports development of the LoRaWAN protocol and ensures interoperability of all
LoRaWAN products and technologies. Today, the LoRa Alliance has over 500
members around the globe.
The LoRa Alliance provides LoRaWAN certification for end devices. Certified end
devices provide users with confidence that the end device is reliable and compliant
with the LoRaWAN specification. You can learn more about LoRaWAN certification
by visiting the LoRa Alliance website. Certification is only available for device
manufacturers that are members of the LoRa Alliance. Once certified, the
manufacturer can use the LoRaWAN Certified mark with the product.
Read the Lora Alliance® Press Release, LoRaWAN® Formally Recognized as ITU
International Standard for Low Power Wide Area Networking for more information.
Duty Cycle
Duty Cycle indicates the fraction of time a resource is busy.
When a single device transmits on a channel for 2 time units every 10 time units, this
device has a duty cycle of 20%.
However, if we also consider channels, things get a bit more complicated. When we
have a device that transmits on 3 channels instead of one, each individual channel is
still occupied for 2 time units every 10 time units (so 20%). However, the device is
now transmitting for 6 time units every 10 time units, giving it a duty cycle of 60%.
In Europe, duty cycles are regulated by section 7.2.3 of the ETSI EN300.220
standard. This standard defines the following sub-bands and their duty cycles:
Additionally, the LoRaWAN specification dictates duty cycles for the join frequencies,
the frequencies devices of all LoRaWAN-compliant networks use for over-the-air
activations (OTAA) of devices. In most regions this duty cycle is set to 1%.
Compliance
Every radio device must be compliant with the regulated duty cycle limits. This
applies to both nodes and gateways.
In practice, this means that you should program your nodes in such a way, that they
stay within the limits. The easiest way to do this, is to calculate how much airtime
each message consumes using one of the many airtime calculators and use that
information to choose a good transmit interval.
Some radio modules (such as the RN2483) also enforce the duty cycle limits. If you
exceed the limits, the module will complain with a message no_free_ch. Specifically,
the RN2483 limits the duty cycle on a per-channel basis. This means that if you only
have 1 channel configured, the module will start enforcing the duty cycle after the
first message.
The figure below shows enforcement on a resource with a 20% duty cycle limit
The figure below shows enforcement on two bands, each with a 20% duty cycle limit
As a per-channel duty cycle limit is easier to implement, you can also divide the
sub-band duty cycle over the number of channels in that sub-band. So for example, in
a sub-band with 8 channels and a duty cycle of 1%, each channel has a duty cycle of
1/8% (that’s 0.125%).
This method is also implemented by the RN2483 module, and as a result, instead of
seeing the no_free_ch when you send too quickly after the first message you can send
multiple messages before all 8 channels are “blocked” and the duty cycle is
enforced.
The figure below shows enforcement on those same two bands, but enforced per
channel
Devices
The Things Network Foundation has received a 7-bit device address prefix from the
LoRa Alliance. This means that all TTN device addresses will start with 0x26 or 0x27
(although addresses that start with these might also belong to other networks with
the same prefix). Within TTN, we assign device address prefixes to “regions” (for
example, device addresses in the eu region start with 0x2601). Within a region, the
NetworkServer is responsible for assigning device addresses. We are using prefixes
here too for different device classes (for example, ABP devices in the eu region start
with 0x26011) or to shard devices over different servers, see .
Applications
Applications in LoRaWAN and The Things Network have a 64 bit unique identifier
(AppEUI). When you create an application, The Things Network’s account server
allocates an AppEUI from the address block of The Things Network Foundation. This
means that every application has at least an AppEUI that starts with 70B3D57ED. If you
have your own AppEUIs, you can also add those to your application.
Gateways
Gateways are manufactured with an embedded EUI, which can then be used to
register the gateway on The Things Network. Although the configuration files of
some gateways suggest that you can just choose an EUI for the gateway, this is not
true. If your gateway did not come with an embedded EUI, you can use another EUI
that you own, or configure an AppEUI that is registered to your account. You may also
use an MQTT-based forwarder, which only needs a GatewayID (that you can choose
yourself) instead of a GatewayEUI.
Activation
LoRaWAN devices have a 64 bit unique identifier (DevEUI) that is assigned to the
device by the chip manufacturer. However, all communication is done with a dynamic
32 bit device address (DevAddr) of which 7 bits are fixed for The Things Network,
leaving 25 bits that can be assigned to individual devices, a procedure called
Activation.
LoRaWAN® Concentrators
Semtech’s LoRa concentrators power all LoRa communication.
Semtech has produced four LoRa concentrators and all LoRaWAN gateways use one
of these devices to receive and transmit LoRa messages.
Read about all of Semtech’s LoRa products on their LoRa product page.
SX1301
The SX1301 is Semtech’s first outdoor LoRaWAN concentrator, designed to provide
worldwide LoRaWAN gateway capability in ISM bands. It is the first digital baseband
chip to integrate Semtech’s LoRa Concentrator IP.
The SX1302 succeeds the SX1301. It reduces current consumption, has better
thermal capability, is cheaper, and can handle more traffic than its predecessor.
SX1303
The SX1303 succeeds the SX1302, and is Semtech’s most modern LoRa
concentrator. It is pin and size compatible to its predecessor, and further reduces
current, improves thermal capability, and is cheaper. In addition, it supports Time
Difference of Arrival (TDOA) geolocation via a new Fine Timestamp capability.
● Fine Timestamp
● Up to -141dBm sensitivity with SX1250 Tx/Rx front-end
● 125kHz LoRa reception with:
○ 8 x 8 channels LoRa packet detectors
○ 8 x SF5-SF12 LoRa demodulators
○ 8 x SF5-SF10 LoRa demodulators
○ Up to 8 packets can be received simultaneously when Fine
Timestamp is enabled
● 125/250/500kHz LoRa demodulator
● (G)FSK demodulator
● Direct interface to Semtech transceivers
● SX1255, SX1257 and SX1250
● Single 32MHz clock
SX1308
The SX1308 is a less sensitive concentrator than the SX1301/2/3. It is designed for
indoor gateways.