## 6 Proof of Concept  
When several Base Stations which can communicate among themselves but do not have Internet access are deployed, the problem of data consistency arises. This can be solved by designating a Master Base Station to which all the other stations (now called slaves) must refer to disseminate any change of content. This will also support roaming of a mobile node as shown in Figure 6.  
Figure 4: General architecture. Figure 5: Detailed architecture. The Master acts as an authoritative data base and, through its LoRa-gateway bridge, centralizes the data coming from the slave base stations. Any change in a Slave station will reach the Master base station, which also provides coverage of its surrounding area. The Slaves can choose to be their own Master or can join an existing one. They thus have the capability of managing their own data but can also contribute to a community network (LCN). A community can choose its coverage area and that of the roaming mobile nodes. The architecture of Both Master and Slave base stations comprises the four parts shown in Figure 7: LoRaWAN Gateway (GW), Network and Application servers, TIG (Telegraph, Grafana, Influx) and WiFi Access Point with content server. LoRaWAN is used to collect data from the end nodes and WiFi to communicate final users to the web server through the Access Point. The 8 channel Base Station is shown on the left of Figure 8  
Figure 6: Operating principle. Figure 7: Four main parts of the Base Station. and the end-node on the right. In the middle is the single channel Base Station which constitutes the cheaper and less power consuming solution. 1. The _LoRaWAN gateway_ acts as packet forwarder between the end nodes and the Network server, based on the open implementation proposed by Semtech, and built with a Raspberry Pi and additional hats. For the eight channel version, the concentrator hat is based on the SX1301 chip which allows listening simultaneously in eight different frequencies with several orthogonal spreading factors. The single channel gateway uses a cheaper hat based on the RFM96W RF module (see Figure 8). 2. _Lorserver_: The role of the network server _(LoRa Server)_ is to authenticate nodes to make sure that only data from registered nodes will be forwarded. It is also responsible for the deduplication and processing of uplink frames, MAC layer processing and downlink transmission planning. The application server _(LoRa App Server)_ provides payload processing and decryption. It offers to the end user the requested data, like weather, air quality index, alarms and so on. Data are locally processed, stored, and made available through the WiFi Access Point. 3. _TIG_: The Telegraf tool is used to subscribe to the MQTT Mosquitto broker, to collect the messages (in JSON format) transmitted by the LoRa App Server and to inject it into the InfluxDB time series database. By using the retention strategy proposed by InfluxDB, the data of a given period can be automatically deleted to save storage space. This can also be done manually on the Service UI. Using Grafana open platform, measurements can be retrieved on influx DB for analysis and monitoring. 4. The _Content Server_ provides access to both static content like educational material, health information, farming best practices, etc., as well as Community Bulletin Board services. The WiFi Access Point makes this material available to the community through a web interface. The output of the eight channels concentrator is sent to the Packet forwarder (PF) via a Serial Peripheral Interface (SPI). The PF transfers it to the LoRa Gateway Bridge by IP/UDP (see Figure 9). We wrote the edge-gateways.service that invokes a start.sh script which installs and executes the dependencies specified in the Mainfile and then launches the packet forwarder if all executions are successful. It also allows to upgrade the firmware as needed. For the single channel GW, everything is included in the packet forwarder, including the HAL library.