Most commercial gateways have either a built-in GPS or have an input to use an external one. The GPS is mandatory for Class B so that the beacons are all synchronized.
The typical channel spacing for LoRa and LoRaWAN is 200 kHz, which is the separation between two channels (if you have one device running at 912.2 MHz, the next one would be at 912 or 912.4 MHz). In principle, LoRa gives proper separation (selectivity) with more than 1.5*LoRaBW as far as channel separation goes. This would be at the minimum 178.5 kHz. Any lower separation would yield lower isolation and therefore more collision chances, the larger the better.
Transceivers used in LoRa®-connected end-devices are frequency-agile, i.e. they have a fast switching PLL onboard. During the uplink, they use a first channel (say 902 MHz), and it is very easy and fast to change the frequency to, for instance, 920 MHz, before the transceiver is turned to reception mode. This takes typically 100 microseconds to do.
Both the uplink and downlink messages are transmitted on determined channels. For example, on class A devices the uplink channels are controlled by the channel mask (ChMask) , whereas the downlink channels are either a function of the uplink channel or configurable through MAC commands.
Whether private or public, overlapping networks in a specific geographical area will share the medium, and therefore the collision rate will increase.
The common techniques which can be used to alleviate this situation is the use of Clear Channel Assessment, which evaluates the "cleanness" of a channel by using spectral scanning techniques (and therefore adapt the channel plan), and implements retries in packet transmission to maximize success rate.
When it comes to the access point side (gateways), the use of the"private" sync word versus "public" sync word is useful to ensure that the gateways don't report a vast majority of the incoming traffic using a different setting.
The LoRaWAN stack available on Github supports Adaptive Data Rate. The algorithm is actually controlled by the network server and the network server will send a MAC command to increase or decrease the data rate depending on the received signal level. When using confirmed messages on the node side, if the node does not receive the acknowledge, it will automatically decrease the packet data rate.
Yes, ADR support is mandatory and enforced in the LoRa Alliance certification.
The LoRaWAN protocol supports packet repetition to maximize packet success rate in an asynchronous system. The right pointer is the NbTrans parameter in the LoRaWAN specification.
The description of the PHY header is best found in the datasheets of the PHY devices, namely SX1276 and SX1272 RFICs from Semtech.
In explicit header mode, the header carries three values:
- the Coding Rate (CR) of the forthcoming payload
- the size of the forthcoming payload
- if the forthcoming payload is appended by a CRC-16 or not
You can find more detailed information on the LoRa header in sections 4.1.1.6 "LoRa Packet Structure" of theSX1272 and SX1276 datasheets. The datasheet and User Manual of SX1261/61 and LR11xx devices contains similar information"
There is no definite answer to this question as it depends on four dimensions:
- RSSI/SNR of the received packets (simultaneous reception on the same channel)
- Time-on-Air of the packets (equivalent to data rate, the longer the packet, the longer one demodulator of the gateway is used)
- Frequency of the packets (two packets with the same data rate and the same RSSI/SNR will collide unless they are on two different frequencies).
- Number of times per day an end device will send a packet (taking resources another node could use)
ADR is well suited for static end-devices. ADR is not recommended for mobile end-devices in situations where connectivity is intermittent. In these situations it is recommended to use a low spreading factor (e.g., SF7) and high repetition (e.g., NbTrans=8), and to switch quickly to high spreading factor (e.g., SF10).
The network server and application server are software entities that control higher level aspects of a LoRaWAN application. The gateway and end device look after the physical layer connection, the network server looks after the protocol and the application server looks after the application level control and data. All are required.
Typically all LoRaWAN makers use 4/5, but strictly speaking the coding rate is not enforced in the LoRaWAN specification. The choice is up to you.
Several recommendation to follow:
- Leverage ADR (now including also LR-FHSS data rate), reduces traffic congestion and reduces the likelihood of burst interference distruption.
- At network level, implement channel monitoring in order to avoid highly interfered channels (e.g. RFID).
- Use the LoRaWAN "confirmed frames". However one should note that such approach reduces the maximum capacity of the network. It is more reccomended to define a strategy for block acknowledgement at the application level, with selective retransmission of missing payloads.
- At device level, leverage the recently introduced CSMA feature.
DevEUI is a 64-bit number. It is the unique ID of the end-device.
JoinEUI is a 64-bit number. It is the unique ID of the join server, which secures network access and exchanges. In LoRaWAN 1.04, JoinEUI replaced AppEUI.
How to get them:
DevEUI key is linked to the end-device, this means end-device manufacturers should contact the IEEE to get a range of unique identifiers.
JoinEUI is provided by the operator of the join server (e.g. network operator, device manufacturer, solution provider). The join server operator should also get it from IEEE.
AppKey, aka NwkKey is a 128-bit key which is used to secure the Join-time communication between the source of the message (the end-device) and the destination of the message (the join server). This key is unique for each device and is a shared secret between Join server and device (symmetric cryptography). It is at the heart of the security and must only be known by the device and the join server. AppKey is never sent over the air and must remain secured over the lifetime of the end-device.
How to get it:
AppKey is typically a randomly-generated number that is programmed into the end-device and simultaneously communicated to the join server, so that it can authenticate the messages from the end-device.
The CEPT is still discussion the harmonization of this band in Europe, but this is not yet completed, so for now we are sticking to the 865-870 MHz frequency band.
There are some technical differences between LoRaWAN and alternative LPWAN technologies which enable a much broader set of applications to be addressed from a bi-directional connectivity, adaptive data rate and end point class perspective, but the key differentiator is the ecosystem, the Certification Program and standardization. If you look at successful technology adoption over the past 10 years all have followed this model. Having different business models, competition, and a diverse ecosystem with industry leaders is the only way to scale volume and deployments. An open standard is also a proven strategy to get acceptance and wide deployment versus proprietary technology, the choice of the various network components; gateways, end-devices, cloud network servers along with chips, development kits and end products from many different suppliers offers a low risk strategy for potential operators or end users.
Last but not least LoRaWAN protects data and privacy like no other LPWAN, it is the most secure solution available in the market with AES 128 encryption on multiple levels for all data from sensor to application server and back.
No, LoRa devices can be used like any other RF transceiver in existing applications with custom proprietary protocols. However, using LoRaWAN will significantly improve time to market. The stack, having similarities to 802.15.4, is FCC and ETSI compliant and offers all the security needed by a modern RF protocols (network key, unique Id for each end point, AES128 encryption... ). LoRaWAN also offers the possibility to be used in private AND public networks.
The "JoinAccept" message is decrypted by the Application Server (AS) and not the Network Server (NS).
The AS is allowed to see the end-device application data but the NS is not.
The AS exchanges key information with the end-device through the NS (the NS forwards the messages but doesn't understand them).
At the end of the exchange, when the session keys have been calculated, the AS gives the network session key to the NS.