## 2 Materials and Methods
### Background
#### 2.1.3 Scalability and Energy Efficacy Issues Caused from Bidirectional Traffic  
In LoRaWAN, link reliability is optionally achieved with acknowledgment (ACK) of uplink messages with a downlink [8]. In this way, the performance improves by adjusting the uplink transmission settings [15]. Once this feature is enabled, each ED waits for an ACK message after an uplink; if this message is not received, this uplink is perceived as not acknowledged and retransmitted, if retransmissions are enabled. The LoRaWAN specification recommends retransmitting up to eight times, while also recommending reducing the data rate between every two unsuccessful transmission attempts in order to achieve more robust connectivity [3]. If the number of retries is set to zero and ACK is not received, the packet is not automatically retransmitted and the send functions indicate failure [7]. LoRa unacknowledged configuration defines transmissions according to the worst link budget by using the lowest data rate since there is no feedback. Such configuration leads to a long time on air and high collision rates [15]. To ensure network scalability, it is a common practice that LoRaWAN EDs are set to minimize the use of ACKs. Apart from the feedback of receiving a message, EDs are also able to periodically validate the link quality by checking if the link still exists. In this case, the ED requests a link check message and a GW will respond, which indicates that the ED is still connected [7]. If the link quality is good, it could be possible to transmit with a higher data rate and lower transmission power. Each application should specify the number of link check failures that indicate that network connection is lost and how often these checks should be applied [7]. At the moment, it is quite common for studies to report optimistic achievements regarding LoRaWAN network capacity. On the contrary, some findings are reported that conclude that introduction of downlink traffic can have a significant impact on the uplink throughput [3]. There are a number of required and optional functions that use downlink messages apart from just data transmitted from the application. A downlink message is coming in response or prior to an uplink from an ED on the following cases: acknowledgement of confirmed uplink packets; reporting of uplink quality for EDs; adapting communication parameters for uplink transmissions; settings for RX2 window and offset between uplink and RX1 window; setting transmission duty cycle for EDs; requesting battery status and quality of downlink from EDs; creation or modification of settings of the channels to be used for communication; and setting the time offset between the uplink TX and the RX1 window. Some findings showed that the GW duty cycle limitations, and also the collisions, are introducing an unreliable downlink delivery. There is a huge impact on this when the network scales, especially in relation with the ACKs. For Class A EDs, the GW transmits any downlink messages and ACKs in the two receive windows (RX1 and RX2). By default, in Europe, window two is fixed to use 869.525 MHz and SF12. In this case, the channel is occupied for a very long time if the GW replies to EDs [5]. In addition, if the GW must transmit an ACK it is unable to receive other packets simultaneously [7], while there is also a delay window between the receipt of a message from the GW and the first receive window of the sender ED opens [5]. Apart from these, as the network size increases, the GW is required to transmit more downlink traffic, exhausting its regulatory time on air allocation more often. Each time this happens, the GW gets blocked for some time and cannot transmit. For a network of 5000 EDs, successful downlink transmissions, with ACKs enabled, drops to about 35% while without ACKs it dropped to 60%. So, there is evidence that as the percentage of uplink messages requiring an ACK increases, the network performance degrades, which means that the network cannot scale in such a case.