No, you do not need a gateway. You can easily implement simple protocols using LoRa, either with modules or with the chips themselves.
Note that LORaWAN layer 2 protocol requires the use of a gateway, or alternately a Relay with gateway
There are three primary reasons why you should use a module/modem:
- It accelerates development, and you don't have to write a whole bunch of underlying code to implement the radio system.
- It's already fully FCC or ETSI certified, so you don't have to go through expensive testing.
- You can leverage LoRaWAN modular certification and reduce LoRa Alliance certification costs.
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.
With SX1261/62 and LR1110 it is possible to transmit and receive the LoRa modulation at any frequency between 150 MHz and 1 GHz, such as 169 MHz, 433 MHz, etc. even in the licensed spectrum.
Additionally, LR1120/21 offers also the possibility to operate in the 2.4GHz ISM Band, as well as in the licensed bands used by SATCOM.
The Semtech gateway reference designs have been engineered to operate in the 490MHz, 868MHz , 915MHz and 2.4GHz bands, although they 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 gateways or concentrators are multi-channel RF devices that 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 modulation.
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.
There are different gateway versions depending the desired capacity and installation location (home vs. tower for example).
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.
NetID identifies the network.
It is used for roaming. A private network which does not require roaming can freely use NetID=0 or NetID=1.
Other network IDs are allocated by the LoRa Alliance. There are 7 types of NetID, overall 10 million networks can be identified.
A device's uplink can be received by two or more networks simultaneously, Typically the gateways are configured to ensure overlapping over multiple channels, at least the joining channels.
Passive roaming is transparent for the device, it has no specific action to undertake. Passive roaming is defined for two flavours:
- Stateless, where the visited network forwards all uplinks and downlinks, of a given netID.
- Statefull, where the visited network may perform some filtering on the traffic from the devices.
Each network ID type corresponds to a different addressing space for end-devices, ranging from 128 addresses to 33 million addresses.
Many end-devices may share the same address in a network, as the device identifier is the combination of DevAddr and network session key.
The devices number can thus reach 1 billion for a single NetID. If a network exceeds this value, it will be allocated additional NetID(s) by the LoRa Alliance.
LoRa (and the standardized embodiment LoRaWAN) and NB IoT are both LPWAN technologies. The 3GPP consortium drives the standardization of NB IoT, targeting operation in licensed spectrum whereas LoRaWAN is an open standard targeting unlicensed spectrum operation driven by the LoRa Alliance. As there are material differences between the technologies, the addressable markets and use cases are not identical. Overall the vision of the LoRa Alliance is that both technologies are complementary and suitably empoloyed based on the specific properties of a given customer use case and/or application. You can download the public whitepaper which explores these trade-offs here.
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.
The gateway reference designs are specified to coexist with 3G, and more importantly with 4G base stations, when co-located with a 4G base station with 50 dB of antenna isolation. The main risk is the injection by the LoRa® GW of noise into the LTE uplink band 20, but this is taken care of by the Semtech reference designs.
The length of a receive window must be at least the time required by the end-device’s radio transceiver to effectively detect a downlink preamble. Minimum 6 symbols are required to do so e.g.:
- For BW = 125kHz, SF7 it should be at least 6.1ms
- For BW = 125kHz, SF12 it should be at least 196.6ms
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).
Having two receive windows is a way to optimize network downlink capability, but offering two downlink opportunities, which can be made different in terms of channel/SF.
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, and all values are provided in the LoRaWAN Regional Parameters document. 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.
- 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.