0% found this document useful (0 votes)
228 views

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.

Uploaded by

Marko Simić
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
228 views

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.

Uploaded by

Marko Simić
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

LoRa

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.

Why is LoRaWAN so awesome?


● Ultra low power - LoRaWAN end devices are optimized to operate in low
power mode and can last up to 10 years on a single coin cell battery.
● Long range - LoRaWAN gateways can transmit and receive signals over a
distance of over 10 kilometers in rural areas and up to 3 kilometers in
dense urban areas.
● Deep indoor penetration - LoRaWAN networks can provide deep indoor
coverage, and easily cover multi floor buildings.
● License free spectrum - You don’t have to pay expensive frequency
spectrum license fees to deploy a LoRaWAN network.
● Geolocation- A LoRaWAN network can determine the location of end
devices using triangulation without the need for GPS. A LoRa end device
can be located if at least three gateways pick up its signal.
● High capacity - LoRaWAN Network Servers handle millions of messages
from thousands of gateways.
● Public and private deployments - It is easy to deploy public and private
LoRaWAN networks using the same hardware (gateways, end devices,
antennas) and software (UDP packet forwarders, Basic Station software,
LoRaWAN stacks for end devices).
● End-to-end security- LoRaWAN ensures secure communication between
the end device and the application server using AES-128 encryption.
● Firmware updates over the air - You can remotely update firmware
(applications and the LoRaWAN stack) for a single end device or group of
end devices.
● Roaming- LoRaWAN end devices can perform seamless handovers from
one network to another.
● Low cost - Minimal infrastructure, low-cost end nodes and open source
software.
● Certification program- The LoRa Alliance certification program certifies
end devices and provides end-users with confidence that the devices are
reliable and compliant with the LoRaWAN specification.
● Ecosystem- LoRaWAN has a very large ecosystem of device makers,
gateway makers, antenna makers, network service providers, and
application developers.

LoRaWAN use cases


Here are a few great LoRaWAN use cases provided by Semtech, to give you some
insight into how LoRaWAN can be applied:

● Vaccine cold chain monitoring - LoRaWAN sensors are used to ensure


vaccines are kept at appropriate temperatures in transit.
● Animal conservation - Tracking sensors manage endangered species
such as Black Rhinos and Amur Leopards.
● Dementia patients - Wristband sensors provide fall detection and
medication tracking.
● Smart farms- Real time insights into crop soil moisture and optimized
irrigation schedule reduce water use up to 30%.
● Water conservation- Identification and faster repair of leaks in a city’s
water network.
● Food safety- Temperature monitoring ensures food quality maintenance.
● Smart waste bins - Waste bin level alerts sent to staff optimize the pickup
schedule.
● Smart bikes- Bike trackers track bikes in remote areas and dense
buildings.
● Airport tracking - GPS-free tracking monitors vehicles, personnel, and
luggage.
● Efficient workspaces - Room occupancy, temperature, energy usage and
parking availability monitoring.
● Cattle health - Sensors monitor cattle health, detect diseases and
forecast calves delivery time.
● LoRa in space - Satellites to provide LoRaWAN-based coverage
worldwide.

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.

LoRaWAN is now an ITU


standard.
As announced by the LoRa Alliance® on December 7, 2021, LoRaWAN® is officially
approved as a standard for Low Power Wide Area Networking (LPWAN) by the
International Telecommunication Union (ITU).

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 our European frequency plan, we have channels in different sub-bands, so when


considering the duty cycle, we also have to consider these. Let’s say the 3 channels
we used before, are in 2 different sub-bands. Each separate channel still has a duty
cycle of 20%, the device still has a duty cycle of 60%, but we now see that Band 1 is in
use for 2 time units every 10 time units (20%), while Band 2 is in use for 4 time units
every 10 time units (40%).
Maximum Duty Cycle
The duty cycle of radio devices is often regulated by government. If this is the case,
the duty cycle is commonly set to 1%, but make sure to check the regulations of your
local government to be sure.

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:

● g (863.0 – 868.0 MHz): 1%


● g1 (868.0 – 868.6 MHz): 1%
● g2 (868.7 – 869.2 MHz): 0.1%
● g3 (869.4 – 869.65 MHz): 10%
● g4 (869.7 – 870.0 MHz): 1%

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%.

Fair Use Policy


On The Things Network’s public community network a Fair Use Policy applies which
limits the uplink airtime to 30 seconds per day (24 hours) per node and the
downlink messages to 10 messages per day (24 hours) per node. If you use a
private network, these limits do not apply, but you still have to be compliant with the
governmental and LoRaWAN limits.

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

In the European band, a transmission on a channel within a frequency band, also


influences the other frequencies in that band.

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

Addressing & Activation


Addressing
LoRaWAN knows a number of identifiers for devices, applications and gateways.

● DevEUI - 64 bit end-device identifier, EUI-64 (unique)


● DevAddr - 32 bit device address (non-unique)
● AppEUI - 64 bit application identifier, EUI-64 (unique)
● GatewayEUI - 64 bit gateway identifier, EUI-64 (unique)

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 .

The NetworkServer assigns device addresses to devices (based on configuration).


For ABP devices you have to request an address from the NetworkServer (the
console or ttnctl will do this for you). For OTAA devices, the NetworkServer will assign
an address when the device joins.
When a device joins the network, it receives a dynamic (non-unique) 32-bit address
(DevAddr). It’s good to keep in mind that device addresses are not unique. We can
(and probably will) give hundreds of devices the same address. Finding the actual
device that belongs to that address is done by matching the cryptographic signature
(MIC) of the message to a device in the database.

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.

Over-the-Air Activation (OTAA)


Over-the-Air Activation (OTAA) is the preferred and most secure way to connect with
The Things Network. Devices perform a join-procedure with the network, during
which a dynamic DevAddr is assigned and security keys are negotiated with the
device.
Activation by Personalization (ABP)
In some cases you might need to hardcode the DevAddr as well as the security keys in
the device. This means activating a device by personalization (ABP). This strategy
might seem simpler, because you skip the join procedure, but it has some downsides
related to security.

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.

Additionally, RAK Wireless provides a great breakdown of available LoRa hardware.

This page provides a quick description of each of the LoRa concentrators.

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.

● Up to -142.5dBm sensitivity with SX1257 Tx/Rx front-end


● 70 dB CW interferer rejection at 1 MHz offset
● Able to operate with negative SNR, CCR up to 9dB
● Emulates 49x LoRa demodulators and 1x (G)FSK demodulator
● Dual digital TX&RX radio front-end interfaces
● 10 programmable parallel demodulation paths
● Dynamic data-rate (DDR) adaptation
● True antenna diversity or simultaneous dual-band operation

The SX1301 is succeeded by the SX1302.

Read more about the SX1301 on Semtech’s SX1301 product page.


SX1302

The SX1302 succeeds the SX1301. It reduces current consumption, has better
thermal capability, is cheaper, and can handle more traffic than its predecessor.

● Up to -141 dBm sensitivity with SX1250 Tx/Rx front-end


● 125 kHz LoRa reception with:
○ 8 x 8 channels LoRa® packet detectors
○ 8 x SF5-SF12 LoRa® demodulators
○ 8 x SF5-SF10 LoRa® demodulators
● 125 / 250 / 500 kHz LoRa® demodulator
● (G)FSK demodulator
● Direct interface to Semtech transceivers
● SX1255, SX1257 and SX1250
● Single 32 MHz clock

The SX1302 is succeeded by the SX1303.

Read more about the SX1302 on Semtech’s SX1302 product page.

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

Read more about the SX1303 on Semtech’s SX1303 product page.

SX1308
The SX1308 is a less sensitive concentrator than the SX1301/2/3. It is designed for
indoor gateways.

● Up to -139dBm sensitivity with SX1257 or SX1255 Tx/Rx front-end


● 70dB CW interferer rejection at 1MHz offset
● Able to operate with negative SNR
○ CCR up to 9dB
● Emulates 49x LoRa demodulators and 1x (G)FSK demodulator
● Dual digital Tx & Rx radio front-end interfaces
● 10 programmable parallel demodulation paths
● Dynamic data-rate adaptation (ADR)
● True antenna diversity or simultaneous dual-band operation

You might also like