# Proposed Fuzzy-NN Algorithm with LoRa Communication Protocol for Clustered Irrigation Systems
## 3 Irrigation Systems Algorithms
### FITRA Protocol Logic  
The FITRA communication protocol is an application protocol that relays network and transport capabilities into lower RF96 LoRa MAC protocol capabilities. Its protocol logic is independent from lower-layer protocols. That is, the FITRA protocol can be encapsulated on top of both GPRS TCP/IP stack and RF96 LoRa radio stack. FITRA protocol logic includes the following: (i) registration to a gateway or to a GPRS service provider; (ii) periodic measurement uploads to the Application Service (AS); and (iii) AS statistical frames and AS control frames send to the actuator's microcontroller. Apart from LoRa frames, FITRA application protocol can also be encapsulated over UDP packets for the purpose of data transmission over GPRS or Ethernet links. The FITRA application protocol node registration is based on the protocol Application ID value. All nodes (microcontrollers attached to actuators) that belong to the same farmer have the same application ID value to their frames and a different valve ID value for each irrigation cluster accordingly. Upon reception of a FITRA frame with a new valve ID, the AS recons the existence of a new FITRA node in a farmer's network, updates its nodes table for that network and acknowledges that frame. If a node does not upload data for an interval called maximum periodic interval (1 h \(\leq T_{period\_max}\leq 24\) h) then that node is considered to be non-reached and is removed from the AS table of known network nodes. If a node's transmission interval is close to \(T_{period\_max}(0.9T_{period\_max})\) then the period control process is initiated for that node. The FITRA statistical information report frames include the \"on\" request report of watering minutes per day from the node to the AS. The AS sets the request day in the past using the Monitor Day request field of an acknowledgment frame. Then the node responds by setting both the monitoring day field as well as the valve \"on\" time field on the next periodic interval frame. The FITRA application protocol acknowledges each received frame and monitors frame flow per node using a sequence numbering schema. A packet loss is indicated if the next frame sequence number is bigger than the previous ACK frame acknowledgment field value. If this difference is more than a value of maximum interval frame loss (3 \(\leq\) MIFL \(\leq\) 10), then the period control process is initiated in order to increase the node's transmission period. The FITRA AS control frames include two distinct control commands: (i) the decision for the next interval watering command send back to the node using the ACK valve next status field; and (ii) the period control command (\(\Delta t_{x}\)). The period control process is initiated for nodes of long periods close to the maximum periodic interval or experience frame losses, in order to modify their transmission intervals. Performance comparison results of the two different OWS implementations proposed both using the FITRA protocol are presented in Table 3. This experimental scenario included two nodes, one using the OWS GPRS infrastructure (Figure 1), sending UDP data streams to the AS and one using the OWS LoRa infrastructure (Figure 2), sending LoRa frames to the AS. Both nodes were equipped with a 5 Ah-6 V battery, placed on the same irrigation field. LoRa node distance from the gateway was set to 1 km. The performance metrics that have been measured were the total number of packets sent to the AS until battery depletion and the average round trip time (RTT) of each frame send and corresponding ACK frame received, measured at the microcontroller nodes. From the experimental results, it is obvious that the LoRa capable OWS system node achieved 5.4 more total frames transmission that the GPRS OWS system node, until battery depletion. Both nodes were using the FITRA protocol.