1. Introduction
Farmers who irrigate have always had to guess how much water a crop needs and when. The agronomic basis for doing better is long established. The reference method of the Food and Agriculture Organization computes crop water requirement from weather data through the Penman-Monteith equation and crop coefficients, and tracks a soil water balance from which irrigation dates follow (Allen et al., 1998). Soil moisture sensors offer a direct check on that balance. The obstacle in practice has been getting readings from the field to the person or controller who decides, at a cost a smallholder can bear.
Low-power wide-area networks have changed the cost. They trade data rate for range and battery life, carrying a few bytes over several kilometres from a device that runs for years on a small cell (Raza et al., 2017). Reviews of the Internet of Things in agriculture record their growing use for irrigation monitoring and control (Farooq et al., 2019; García et al., 2020). Of the available technologies, LoRaWAN stands out for rural cooperatives because it needs no operator: anyone may install a gateway and run a network in licence-exempt spectrum, whereas cellular alternatives such as NB-IoT depend on coverage that a mobile operator may not provide in thinly populated areas (Mekki et al., 2019).
Technical descriptions of LoRaWAN are plentiful, and so are reports of individual farm deployments. Less is written on how a group of farmers who share an irrigation scheme should go about building and keeping such a network. This article proposes a procedure for that purpose. It is a methodological guide derived from the literature and the standards. It describes no particular cooperative, presents no field results, and has not been validated in use.
2. Background
Three sets of facts shape the procedure: how LoRaWAN works and where its limits lie, how radio propagates over farmland, and how cooperatives govern shared resources.
2.1. LoRaWAN in brief
LoRa is a chirp spread spectrum modulation. Each transmission uses a spreading factor, from 7 to 12 in the usual 125 kHz channels, and each step up in spreading factor roughly doubles the time on air while improving receiver sensitivity by about 2.5 dB (Augustin et al., 2016). LoRaWAN is the medium access and network protocol built on it. End devices transmit to any gateway in range, gateways forward frames over an Internet connection to a network server, and the server removes duplicates, checks integrity and passes payloads to an application (LoRa Alliance, 2017). Class A devices, the most frugal, can receive only in two short windows after each of their own uplinks. Class C devices listen continuously and can be commanded at any time, at the cost of a receiver that is always on.
Capacity is limited in ways that matter for design. Devices access the channel without listening first, in the manner of ALOHA, so collisions rise with traffic (Bor et al., 2016; Georgiou and Raza, 2017). In Europe the 868 MHz band is governed by duty-cycle limits, typically one per cent per sub-band, that apply to gateways as well as to devices (ETSI, 2018). Because a gateway serves many devices, its downlink allowance is the scarcest resource in the network, and applications that expect frequent acknowledgements or commands exhaust it quickly (Adelantado et al., 2017). Frequency plans, power limits and dwell-time rules differ by region and are laid down in the regional parameters document (LoRa Alliance, 2020).
2.2. Propagation over farmland
Open, flat land is favourable to sub-gigahertz radio, and measurements of LoRa have shown ranges of many kilometres with an elevated gateway (Petäjäjärvi et al., 2015). Farmland is not always open, however. Sensor nodes sit close to the ground, often below the canopy of the crop they monitor, and attenuation through vegetation increases with foliage depth and varies with season and moisture (ITU-R, 2021). Orchards, windbreaks, embankments and farm buildings obstruct the first Fresnel zone. Empirical models of the Hata type, with their open-area correction, give a first estimate of path loss (Hata, 1980), but they were fitted to antenna heights and environments unlike a node at crop height, and should be treated as a starting point for a survey and not a substitute for one.
2.3. Cooperatives and shared infrastructure
An irrigation scheme is a common-pool resource, and the conditions under which users sustain such resources themselves have been studied closely. Ostrom (1990) found that long-lived irrigation institutions tend to have clear membership, rules matched to local conditions, monitoring by the users or people accountable to them, graduated sanctions and accessible means of resolving disputes. A sensor network enters this setting as a new shared asset and also as a new instrument of monitoring. It makes each member's water use more visible. Whether members welcome that depends on who controls the data and what may be done with them, which is why the procedure below starts with governance and not with radio.
3. The Proposed Procedure
The procedure has six phases, set out in order in Figure 1. Table 1 gives the main decision and the record to be kept for each. The phases are sequential, but the last feeds back into the first, since every season teaches something about needs.
| Phase | Main decision | Record kept by the cooperative |
|---|---|---|
| 1. Needs and governance | What is measured, what is controlled, who owns equipment and data | Written agreement adopted by the members |
| 2. Survey and radio plan | Where gateways go and which plots they reach | Map of sites, link budgets, survey readings |
| 3. Devices and architecture | Sensor types, device classes, network server, backhaul | Equipment list, key register, configuration |
| 4. Pilot | Whether the design works on a few representative plots | Pilot log and list of changes made |
| 5. Roll-out | Order of installation and training of members | Asset register with locations and install dates |
| 6. Operation and review | Maintenance duties, budget and seasonal changes | Fault log, battery changes, annual review note |
3.1. Phase 1: Needs and governance
The cooperative first decides what the network is for. Monitoring alone, meaning soil moisture at one or two depths, a weather station, and perhaps water level or flow in the main channel, is a well-behaved LoRaWAN application: readings every fifteen minutes to an hour are ample for scheduling, and traffic is almost entirely uplink. Remote control of valves or pumps is a different matter, because it requires reliable downlink and has consequences if a command is lost. A prudent first network monitors and advises, and leaves actuation to a later stage. The members then settle ownership of gateways and sensors, who may see plot-level data, how long data are kept, how costs are shared, and who is responsible for upkeep. These decisions are written down and adopted in the manner the cooperative uses for its other rules.
3.2. Phase 2: Site survey and radio planning
Planning starts on a map. Candidate gateway sites are places with height, power and an Internet connection: a water tower, a grain silo, the pump house, the cooperative office. For each, a link budget is drawn up from the permitted radiated power, antenna gains, cable losses, the receiver sensitivity at each spreading factor and an estimated path loss with a margin for vegetation and fading. The estimate is then checked on the ground. A portable device transmitting at a fixed spreading factor is carried to the far and awkward corners of the scheme, at the height and in the kind of crop where sensors will sit, and the signal strength and signal-to-noise ratio reported by a temporary gateway are noted. Surveys made when fields are bare should be repeated, or given extra margin, for the months of full canopy. Two gateways with overlapping coverage are preferable to one tall mast, since any gateway that hears a frame will forward it and the loss of one site then does not silence the network.
3.3. Phase 3: Devices and network architecture
Sensors are chosen for the soil and the crop, with attention to calibration, since capacitive probes respond differently in clay and sand. Battery-powered monitoring nodes should be Class A, with adaptive data rate enabled once they are fixed in place so that the network server can lower their spreading factor and transmit power where the link allows. The energy cost of a transmission rises steeply with spreading factor, and models of device consumption show that reporting interval and spreading factor together largely determine battery life (Casals et al., 2017). If valves are to be controlled, their controllers need a local power source in any case and can run as Class C. Commands should be few, should carry a schedule and not a moment-by-moment instruction, and the valve should default to closed if contact is lost.
On the network side the cooperative chooses between a public community network, a hosted network server and a server it runs itself. Open-source servers make the last option realistic for a group with some technical help, and it keeps data within the cooperative. Devices should join over the air, so that session keys are derived afresh and not fixed at manufacture, and the root keys, which are AES-128 keys unique to each device, should be held in a register with restricted access (LoRa Alliance, 2017). Gateways need backhaul. Where there is no fixed line, a cellular modem at the one site with mobile coverage, or a point-to-point radio link to the office, will carry the small volume of traffic involved.
3.4. Phase 4: Pilot
Before equipment is bought for the whole scheme, a pilot is run on a handful of plots chosen to include the hardest cases: the most distant, the most heavily vegetated, the one behind the embankment. The pilot should span at least one full irrigation cycle and preferably a period in which the canopy closes. Its purpose is to answer set questions. Do frames arrive at the expected rate from every node? At which spreading factors do the nodes settle? Do the readings make agronomic sense to the farmers who know the plots? Are enclosures, mounting posts and cable glands surviving machinery, livestock, rodents and water? The answers are logged, and the design is changed where they are unsatisfactory.
3.5. Phase 5: Roll-out
Installation proceeds sector by sector so that each can be checked before the next is begun. Every node is entered in an asset register with its identifier, plot, position, depth of probes and date, and its first readings are compared with a manual measurement. Members are shown how to read the dashboard or the messages they will receive and, just as usefully, how to recognise a node that has stopped reporting. At least two people in the cooperative should be able to replace a node and add it to the network server, so that the skill does not rest with one person or with an outside supplier.
3.6. Phase 6: Operation, maintenance and review
A network of this kind fails quietly. Batteries run down, probes lose contact with shrinking soil, antennas are knocked, and a gateway loses its backhaul without anyone noticing until advice stops arriving. The operating routine therefore includes an automatic alert when any node or gateway has been silent for longer than a set period, a pre-season inspection, a budget line for batteries and replacements, and a note of every fault and its remedy. Nodes are lifted before harvest or tillage where machinery would destroy them. Once a year the cooperative reviews whether the readings are being used in irrigation decisions, whether the data rules are being respected, and whether the network should grow, for instance towards valve control.
4. Fitting the Procedure to Local Conditions
The procedure is written generally and must be adjusted to the country and the scheme. Regulation comes first. Outside Europe the frequency band, the power limit and the form of the access rule change: some regions impose dwell-time limits or listen-before-talk in place of duty cycle, and the cooperative or its supplier must configure equipment to the correct regional plan (LoRa Alliance, 2020). Scale matters too. A scheme of a few dozen plots within sight of one building needs little planning, while one that stretches along a valley may need several gateways and a relay for backhaul. Where a mobile operator offers good NB-IoT coverage and the cooperative has no wish to maintain infrastructure, a cellular solution may serve better, and the comparison should be made honestly (Sinha et al., 2017).
5. Limitations and What Remains to Be Shown
The procedure has been reasoned from published sources and has not been tried. Whether its phases are in the right order, whether the pilot questions are the right ones, and whether a cooperative can carry the maintenance load without outside support are matters that only application will settle. The agronomic benefit is also assumed and not shown: that members who receive soil moisture readings will change how they irrigate, and that the change will save water or raise yield, depends on water pricing, allocation rules and trust in the readings as much as on the network.
Two technical cautions should be added. The scalability analyses cited concern networks far denser than a rural scheme, so collisions are unlikely to be the binding limit. Interference from other users of the licence-exempt band, which the cooperative cannot control, may be. And security rests on key management that small organisations often neglect. A documented application of the procedure, reporting what had to be changed, would be the most useful next contribution.
6. Conclusion
A cooperative can own and run a LoRaWAN network for irrigation, and the technology suits the task provided its limits are respected: sparse uplinks, scarce downlinks, spreading factors kept low by good gateway siting, and radio plans checked in the field under full canopy. The six-phase procedure proposed here begins with agreement among members about purpose, ownership and data, and ends with a seasonal review, because the durability of the network will depend on the cooperative's own rules at least as much as on its link budgets. The procedure awaits testing in practice.
Conflict of interest
To be declared by the author(s) before publication.
Funding
To be declared by the author(s) before publication.