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 SX1272, SX1276, SX1261, SX1262, and LR11xx 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 6.1.3 "LoRa Frame" of the SX1261 and SX1262 datasheets.

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 can only be used for devices that are permanaently static, this is because the ADR mechanism typically works over a timescale of many hours. This implies that packets could be lost if the end device were to change locations to a higher path-loss environment.

In mobile devices, it is possible to send a mix of different SF packets to allow more frequent information uplinks when closer to a gateway, in a practice known as "Blind ADR". 

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.

If you are experiencing difficulties with packet reception, then the first question to ask is why?

The answer to this may come in one of two forms - inadequate link budget or such a high sensor deployment density that the probability of packet collision is high. In both cases the best answer is network densification.

In the case of lack of coverage, the addition of a low-cost gateway is the best way of improving your network coverage.

In the case of lack of network capacity, the deployment of an additional gateway to that area will allow other end-nodes in that same area to transition to higher, lower time-on-air data rate - thanks to the ADR mechanism.

With those end devices occupying less transmission time and operating on orthogonal SFs - this will drastically increase your packet success rate - even if your end device setting remain unchanged.

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 a range of unique identifiers 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 (European Conference of Postal and Telecommunications Administrations ) is still discussing 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.

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.