# Energy Performance of LR-FHSS: Analysis and Evaluation
## 3 Overview of LoRaWAN and LR-FHSS
### LoRaWAN  
LoRaWAN networks are composed of end devices (EDs), gateways (GWs), and a network server (NS). To enable communication between EDs and GWs, the former use pure ALOHA as the medium access mechanism and one of the PHY modulations allowed by the protocol--LoRa, frequency shift keying (FSK), or LR-FHSS--to transmit frames. After the frames are demodulated by the GW, they are forwarded to the NS, typically over an IP backhaul. The LoRaWAN specification defines the communication protocol and system architecture [27], while the Regional Parameters specification tailors LoRaWAN networks to operate efficiently and in compliance with regional regulatory requirements [28]. The topology of LoRaWAN networks is a star-of-stars. EDs use one or more GWs to transmit uplink frames to the NS, as shown in Figure 1. However, the NS replies to an ED via downlink messages through a single GW. To accommodate diverse application needs, LoRaWAN supports three different classes of EDs: Class A, Class B, and Class C.  
* **Class A**: This is the default operational mode for LoRaWAN networks, and all devices must support it. Class A devices by default remain in a sleep state and perform uplink transmissions asynchronously when needed. There are two downlink (or receive) windows that follow each uplink frame. These windows are used to receive commands or data from the NS. The parameters RECEIVE_DELAY1 and RECEIVE_DELAY2 specify the time between the end of the uplink transmission and the start of the first and second receive windows, respectively. Figure 2 presents a diagram of this behavior, where the specification recommends a default value for RECEIVE_DELAY1 of 1 s and  
Figure 1: LoRaWAN network architecture. RECEIVE_DELAY1 + 1 s for RECEIVE_DELAY2. Downlink transmission can only happen after an uplink frame: a mechanism that enhances energy efficiency but limits the device's applicability. For the EU68 region, the LoRaWAN standard specifies that the DR used for the first receive window should match that of the corresponding uplink frame, with an additional parameter called Rx1 DRO offset, which can range from 0 to 5. In our study, we set this value to 0, which is the default in the specification. * **Class B**: In addition to Class A operation, Class B devices can schedule additional receive slots. The key characteristic is that they allow for more predictable and regular opportunities for the NS to send downlink messages to the devices. Because of this, Class B devices can receive commands or downlink data independently of uplink traffic. Support for Class B is optional. * **Class C**: Except for when they are transmitting, Class C devices offer practically continuous receive windows. Although it is the most power-consuming out of the three classes, it is suitable for equipment that runs on-grid, and it minimizes downlink latency. Support for Class C is likewise optional. In this article, we base our study on Class A devices, as they are the most popular and are used in the most energy-constrained applications. Transmission via LoRaWAN can be set to be confirmed or unconfirmed. When reliable transmission is required, the ED transmits an uplink frame and then waits for a confirmation from the NS during a receive window. On the other hand, in the unconfirmed mode, the ED is unaware of whether the data were correctly received because there is no confirmation frame from the NS. Figure 3 shows the MAC frame structure in LoRaWAN. The first field, the one-byte sized MAC header (MHDR), identifies the type of transmission. Three components make up the MAC payload: the frame payload (FRM Payload), the frame header (FHDR), and the FPort. The FPort is only present when data are carried via the FRM Payload, which has a one-byte size limit. The FOpts field, which has a size of 0 (no operations included) to 15 bytes, is part of the FHDR, which has a size that ranges from 7 to 22 bytes. The message integrity code (MIC), the final field in the MAC frame, enables the verification of frame integrity. Figure 3: LoRaWAN MAC frame structure.