## 4 Partition Aware-RPL Protocol Overview
### Parent Selection Algorithm
Straightforwardly, data aggregation techniques are tightly coupled with how aggregator nodes are elected, how the data is gathered, as well as how aggregated packets are routed through the network to the sink. Then, one of the key elements of in-network aggregation deals with the problem of building a routing topology that facilitates aggregation. ### Standard RPL and Its Limitations

When using RPL, the communication is driven by the constructed DODAG, see Figure 3. Recall that this DODAG is incrementally created/built based on an objective function (OF) to be satisfied. In principle, the standard RPL intrinsically enables a certain level of aggregation. However, in the context of farms that are composed of several parcels, the aggregation feature is no longer beneficiary nor practical, see both cases below:

* Need of lossy aggregation at parcel level: It is worthy to note, that most smart-farming decision support system (DSS), need parcel information that results from lossy type aggregation. As an instructive example, in greenhouses, DSS exploits periodically collected information about climatic parameters, in order to find the most suitable growth conditions for the cultivated crops. In the case of strawberry, we need to maintain the temperature at 30 \({}^{\circ}\)C during the day and 15 \({}^{\circ}\)C during the night, for one year. Straightforwardly in this context, only the minimum and maximum temperatures of the sensed data are required by the DSS in order to control the greenhouse temperature. As shown in Figure 9, standard RPL makes the generated data flowing from all nodes, converging to the sink, without any consideration of the parcels' boundaries. This prevents from any local aggregation function to be applied at the parcel level. * Lossless aggregation for highly heterogeneous LLN: When the farmland is cultivated by different crops, the proposed topology provides efficiency for performing lossless data aggregation, (such as fusion and compression). This is due to the high heterogeneity of the collected data. Obviously, in standard RPL the flow of data messages from different parcels, though different crops, will be of high heterogeneity because of the several kinds of collected parameters, their frequenciesof measurement, etc. Inherently, the application of any compressing/fusion algorithm on this heterogeneous data will give a poor efficiency. The Figure 10 gives an illustrative example of this situation. This motivates the need for a built DODAG that reflects the physical distribution of crops over the parcels: it turns out that in-network aggregation is easier to implement for smart farming applications whenever this property is achieved. Luckily, our proposal, PA-RPL builds its DODAG to perfectly suit this spatial distribution, which makes it a perfect fit to support in-network aggregation. In the literature, and to the best of our knowledge, none of the proposed OFs paid enough attention to these partitions, but PA-RPL. ### PA-RPL and In-Network Aggregation

As a result of its capacity to reflect the spatial distribution of crops over the parcels, PA-RPL solves most of the needed ingredients to easily implement in-network aggregation: electing special nodes as aggregators, and defining preferred paths to route data towards these aggregators or to the sink. In fact, gathered data of a target parcel will converge to the Parcel Head node (by construction), and thus, in-network processing operations can be easily executed in each sub-DODAGD's root, i.e., PH node. As shown in Figure 11, periodical gathering of the entire parcel data in one elected aggregator node (i.e., the Parcel Head), can simply be processed using a lossy aggregation function like maximum, minimum, average, etc., then only the result will be sent to the sink. Figure 10: Standard RPL DODAG: high data heterogeneity decreasing the aggregation efficiency. Figure 9: Standard RPL DODAG: difficult to support aggregation at parcel level.