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.

You can perform firmware upgrade from the server, the time needed for the upgrade depends on the size of the firmware to be updated. The LoRa Alliance has standardized a way to group devices together in a Multicast group for concurrent update, and an efficient Transport layer with built-in redundancy for optimized file delivery. The idea is to switch the node in class B or in class C and to send data from the server. There are examples of FUOTA (firmware upgrade over the air) available from several partners of the LoRa Alliance.

There are three primary reasons why you should use a module/modem:

1. It accelerates development, and you don't have to write a whole bunch of underlying code to implement the radio system.
2. It's already fully FCC or ETSI certified, so you don't have to go through expensive testing.
3. 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 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

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.

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

The LoRa endpoints are the elements of the LoRa network where the sensing or control is undertaken. They are remotely located and are most probably battery operated. These endpoints can be setup to communicate with a LoRa Gateway (Concentrator or Base Station) using the LoRaWAN network protocol.