# Rural Healthcare IoT Architecture Based on Low-Energy LoRa
## 4 System Architecture
### Fog Computing and E-Healthcare Gateway
To illustrate the ML process within the proposed architecture and to state the challenges given the architecture constraints, we will use a scenario that falls under the user story \"Detecting Abnormal Changes in Daily Living\", described in Section 2.2. More precisely, we consider how sleep monitoring of a person can be used to indicate underlying health conditions. In our previous work, we have elaborated that a combination of piezoelectric and PIR sensors that measure different physical properties, thus minimizing the possibility of noise signal contamination, show a strong correlation, and can be used to detect the person's movement in bed during sleep [35]. For the data collection, the microcontroller can operate in the ESP32 Deep Sleep state. This sleep pattern of the microcontroller is known as ULP sensor-monitored pattern and the stated current usage is 10 uA [36], while higher when it is part of a microcontroller. Additionally, the sensors should be modified to minimize elements that dissipate energy in the form of heat, such as the linear voltage regulators. The data collected from the sensors is stored in the real time clock (RTC) memory, which, based on the hardware revision, is 8 MB or 16 MB. When the RTC memory is full, the microcontroller wakes up, compresses the data, and begins transmission to the e-healthcare gateway. The e-healthcare gateway must first filter the data to determine its validity and filter for possible noise by correlating data from multiple sensors. Then, using its pretrained ML model, the gateway detects events of interest about the care receiver's sleep. The challenge presented in this case is transmitting the sensor data and labeling it for reinforcement learning in the cloud. The LoRaWAN bandwidth limitation implies that not all data can be continuously transmitted to the communication hub and from there to the cloud. Thus, the system should contain thresholds either by the number of non-zero readings from the sensor or by the number of low confidence classifications. The data can then be analyzed by a medical specialist who can label the data by the patient's current diagnosis. This may include if the patient is known to have developed respiratory symptoms or has been diagnosed with sleep apnea. More granular labeling can be made if the care receiver, in addition to non-invasive sensors, was using body area sensors such as a wristband to detect pulse and oxygen saturation. Thus, data from patients that use such sensors should be prioritized for transmission and, upon reaching the cloud, is added to the reinforcement training set. To minimize the energy dissipation of dropped packages from the IoT sensor nodes, the gateway should maximize the receive slots to capture data from the nodes. Furthermore, sleep times for the healthcare gateway should overlap with all potential sending nodes' sleep times. However, the dependency of the IoT cloud analytics or storage facility must be minimized for the exploitation of the proposed solution [37]. For ease of operation and maintenance, the gateway will feature functionality for auto-update, and remote reboot [38]. A block diagram of the e-healthcare gateway is shown in Figure 4.  
Figure 4: E-healthcare gateway components. The healthcare gateway should manage user interfacing with the system either as a built-in interface or via a separate user interface (UI) module. Smartphone interface could be used as an extension but should not be mandated as it will introduce additional complexity. A consideration for accessibility should be part of the UI design.