## 5 Platform Preparation for the Field Test  
While the platform prototype was still in the early stages of development, it became unexpectedly necessary to prepare all of its components (the sensor and gateway nodes and the server) for an extended two and a half month field test (end of June to early September). The test was set to start in less than two months using 50 sensor nodes and two gateways deployed in an olive tree field in the south-west of Greece. In the following, we will present how we selected, developed and assembled in this short time a platform prototype with the most important features to test in the field. We will also show how we used the results and experience from the test to refine and enhance platform functionality and reliability.  
The time to field test was too short to design, produce and test new sensor nodes, and we decided to adapt the functionality and ruggedize the node prototypes designed for laboratory tests (described in Section 4). As expected, this adaptation has led to several issues during the test, but also fostered a thorough analysis of the platform operation before, during and after the test, ultimately helping us to significantly improve its reliability and cost, as we will show below.  
Because the test field was located far away (nearly 2000 km), on-site maintenance would have been costly and time-consuming. On the other hand, since the components of the platform were not developed with the quality necessary to withstand an extended environmental exposure in field, we expected to encounter hardware issues during the test.  
Thus, we made a development priority to add the necessary monitoring features to collect enough data about defects and anomalies that may manifest during the test, in order to understand their causes and effectively help with improving the future versions of the platform. Most of these features would be needed anyway, since QoS control is always important for long-term outdoor environmental monitoring platforms, especially when monitoring for potentially dangerous events, like wildfires, as was discussed in Sections 3.1.3 and 3.2.3.  
Based on the analysis in Sections 3.1.2 and 4.1, we chose a star network topology and a very simple communication protocol, because they can considerably simplify the sensor nodes: reduce the requirements for hardware resources, the size and complexity of the communication protocol stack, the energy consumption and the cost. All of these are important specifications for pervasive monitoring platforms and, most importantly, they simplify network deployment to a level where it can be efficiently done by application domain experts or low-skill workers.  
With the above considerations, we split the network into independent cells, as shown in Figure 5.  
The sensors in each cell are distributed with the density defined by the domain experts based on terrain and vegetation characteristics (e.g., every 20 m) and are covered by two gateways. Each gateway can independently contact the server in order to ensure redundant field message aggregation and upload. Larger application areas can be covered by joining elementary network cells, as shown in Figure 5.  
Although with a link budget of, e.g., 110 dBm, the communication range in the 433-MHz band can well exceed 10 km in optimal propagation conditions, the actual range in forest (or in the test field) conditions may be much shorter. Thus, the distances in Figure 5 assume a sensor communication range of 200 m, and the test field shown in Figure 6 of about 195 \(\times\) 45 m can be adequately covered by one cell.  
This layout simplifies network deployment (presented in Section 6.1) and ensures full redundancy for field data collection, storage and communication to the server.