LoRa and LoRaWAN are both commonly used for IoT devices, but each has its own niche capabilities and applications. LoRa is a proprietary chirp spreading spectrum modulation scheme developed and patented by Semtech. This enables long-range, low data rate communication over the license-free sub-1 GHz industrial, scientific, and medical (ISM) bands. The effectiveness of LoRa depends on a link budget, which can be modified through changes in code rate (CR), bandwidth (BW), transmission power (Tx), and spreading factor (SF) [11,13], wherein the selection of data rate (from 0.3 kbps to 50 kbps) is a tradeoff between the time on air and the communication range, given that communications with different SFs do not interfere.

Spreading factor (SF) is defined as the ratio between the symbol rate and chip rate. LoRa uses different SFs, where 𝑆𝐹∈{7,8,…,12} [14]. SF has a great impact on range, sensitivity, and signal-to-noise ratio (SNR), as represented in Table 1. Different SFs enable orthogonal signal transmission, so a receiver can successfully receive distinct signals sent over a given channel at the same time [15]. SF is also referred to as the number of bits that LoRa encodes in a symbol, wherein a chirp using an SF represents 2^𝑆𝐹 bits using a symbol and 𝑀=2^𝑆𝐹 frequencies for a chirp. Therefore, researchers can also determine the chirp duration, as shown in Equation (1), where 𝐵∈{125,250} kHz.

Transmission power (Tx): A LoRa radio can transmit in the range of [−4, 20] dBm in 1 dB steps. In normal cases, the transmissible ranges are mostly limited to the range of [2, 20] dBm.

Code rate (CR): This defines the level of protection against interference. In this case, the forward error correction code (FEC) uses a CR of 4/5 to 4/8 [9,16]. The higher the CR, the more protection against burst interference, and vice versa. The SF bits of information are transmitted per symbol, and the raw bit rate (𝑅_𝑏) is given in Equation (2).

Bandwidth (BW): LoRa transceivers operate at 125 kHz, 250 kHz, and 500 kHz. Therefore, BW is considered to be a paramount parameter in terms of modulation.

According to [17,18] LoRa currently operates in the sub-GHz ISM band, subjecting its transmission to strict duty cycle (a maximum of 1%) and transmission power regulations. Herein, three regions are defined in which LoRaWANs are expected to operate at a fixed frequency based on local regulations [19]: channel frequencies in MHz for the United States (US902-923), Europe (EU868-870), and Korea (KR920-923).

Nevertheless, the LoRa Alliance built the LoRaWAN protocol on top of LoRa, adding a networking component to it. LoRaWAN network operates over a star of star topology and exploits a mechanism that enables multiple EDs to communicate with the central network server through the gateway(s) [20]. LoRaWAN comprises three types of device classes (A, B, and C) with different capabilities:

Class A: This class of LoRaWAN devices has the lowest power consumption. Class A devices spend most of their time in sleep mode [21,22]. In Class A, after the device sends an uplink, it listens for a message from the receive windows RX1 and RX2 after the uplink before going back to sleep, as shown in Figure 2.

Class B: Similar to Class A; however, this class opens extra downlink receive windows at scheduled times. End devices also wake up and open a receive window to listen for a downlink according to a configurable, network-defined schedule [23,24]. Periodic beacon signals transmitted by the network allow end devices to synchronize their internal clocks with the network server.

Class C: This class supports bi-directional communication with no restriction on the downlink receive window [23]. End devices in Class C mode are used when extremely low power consumption and latency are trivial. Class C end devices implement the same two receive windows as Class A devices, but they do not close the RX2 window until they send the next transmission back to the server [25]. Therefore, they can receive a downlink in the RX2 window at almost any time.

One of the first attempts to define multi-hop networks using LoRa is LoRaBlink [26]. The authors propose a TDMA protocol that assumes the communication is only between the nodes and a sink and uses beacons to synchronize the nodes in each epoch, thus benefiting from the concurrent transmission feature of LoRa to decode correctly at most one packet in each slot and receiver. Works in [12,27,28] presented a forwarding relay node and clustering approach to not only enhance coverage and concurrent transmission of LoRa networks using multi-hop communication but also make the system more energy efficient. In addition, devices are categorized into several clusters with the motive of streamlining the operations of the network to maximize energy efficiency and consequently prolong the network lifetime. Unfortunately, the forwarding node increases network traffic and redundancy. Authors in [29] presented a novel architecture for a LoRa hybrid that combines over the air activation (OTAA) and activation by personalization (ABP) features to utilize the multi-hop function. In [30,31], authors introduce a multi-hop LoRa linear protocol where every leaf node is capable of transmitting a data packet to the parent node with a different time slot and e2McH, which performs energy-efficient communication in a multi-hop manner over LPWAN, respectively. In [32], the authors propose a minimized latency multi-hop LoRa network protocol for IoT applications. The scheme aims to achieve reliability and low latency when transmitting the data packet. However, the IOMC scheme only overhears and relays data packets from distant nodes with weak transmission power and demodulation failure at the gateway.

Thenceforth, more concerns have also motivated various studies to overcome connectivity drawbacks by having nodes listen to the medium using overhearing techniques. Fundamentally, if the nodes overhear the neighbor’s traffic, they store the packets in their memory for a short period of time for retransmission. Moreover, in [11,33], authors created a study regarding the use of specially programmed e-nodes and cooperative relay nodes, respectively, to perform overhearing. Here, Class C devices act as a transparent range extender with the primary importance of coexisting with other normal nodes, performing overhearing, storing, and forwarding of all overhead packets to the GW. The crux of the matter is that both schemes perform the same service but differ in methodology. In [11], the e-node scheme deploys a single range extender that takes advantage of the network server (NS) capability to deduplicate the same message received from multiple GWs, while a cooperative relay scheme deploys multiple relays. However, these schemes neglect the reliability and energy efficiency of constrained nodes in the IoT LoRa network. Therefore, the IOMC scheme considers a reasonable, energy-efficient OH node selection technique to mitigate the energy challenges.