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 maximum LoRaWAN packet time-on-air duration is 3 seconds. After the packet is transmitted by the end-device (uplink message), the timer event "OnRxWindow1TimerEvent( )" occurs precisely after 1 second (± 20 µs), corresponding to the RECEIVE_DELAY1. Then the radio goes into Rx mode on the same RF channel as the transmitted packet, with a data rate which is function of the uplink data rate (refer to LoRaWAN specification Section 7). In case a downlink message has not been received, the timer event "OnRxWindow2TimerEvent( )" occurs 2 seconds (± 20 µs) after the uplink message (RECEIVE_DELAY2) and leads to the configuration of the radio for a second receive window in the function "RxWindowSetup()". The RF channel and the data rate used for the second receive window are defined in the LoRaWAN specification, Section 7.

However, before changing the radio, the code checks the radio status with the call GetStatus(). At this stage, either the radio is in "RF_IDLE" state and the code configures the radio to go into Rx mode, or the radio is in another state (meaning the radio is already busy) and the code will simply drop the command until the next IRQ from the radio.

The minimum receive window duration must be at least the time required by the end-device‘s radio to effectively detect a downlink preamble.

In the LoRaWAN specification, the packet time depends on the Regional Parameters, and will never exceed 3 seconds.

On the node side, this is ensured by the function "ValidatePayloadLength (...)" of the LoRaWANstack which checks the amount of data to be transmitted compared to the data rate.

If the frame is longer than the predefined length, the status LORAMAC_STATUS_LENGTH_ERROR will be returned. On the gateway side, the same kind of mechanism is used so that the time-on-air of any given packet over the network will never reach 3 seconds.

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.

The LoRaWAN protocol is not meant for node to node communication. All nodes communicate to one or more gateways that forward all packets to the network server. The network server takes care of de-duplication and forwards the packets from the end-devices to the appropriate application server.

Adaptive Data Rate (ADR) can be enabled or disabled on every node depending on the use case. Usually, this has to be discussed with the network provider. As a rule of thumb, static nodes usually have ADR on and the moving nodes usually have the ADR off.

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.

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 as the propagation radio path might change too rapidly.

Recommended practices include the use of "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.

One way of improving your packet success rate is to use the LoRaWAN "confirmed frames". When implemented, confirmed frames will make devices request an acknowledgement. It is however not recommended to widely use confirmed frames for sensor traffic, as typically the ratio of uplink versus downlink traffic should not exceed 1%.

For sensor data collection, it is advised to implement packet repetition and to send, in every packet, not only the last sensor data, but also the previous and the one before. This maximizes the amount of data you collect, without creating too much downlink traffic.

DevEUI is a 64-bit number. It is the unique ID of the end-device.

AppEUI is a 64-bit number. It is the unique ID of the application server and is the destination of the messages sent by the end-devices. It must be unique so that the end-device knows where to send its messages. The AppEUI can be linked to either a single application (unique customer) or to several applications. In this last case, the manufacturer must re-route the messages to its end customers by using the DevEUI.

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.

AppEUI is usually provided to the end-device manufacturers by the solution providers.

AppKey is a 128-bit key which is used to secure the 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 must be know by both sides. 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.

There are currently no signs that this frequency band is being harmonized in Europe, 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.