Identification of the downscaled testbed

• Estimation of the connectivity in the real world deployment

The first step is the characterisation of the real world deployment, that is the es-timation of the level of connectivity among its nodes. This can be performed in several ways. Among the different approaches there are: i) direct measurement of the path loss between each pair of devices; ii) direct measurement of the path loss between some pairs of devices and estimation of the path loss among all the remaining pairs of devices; iii) use of adequate statistical models to describe the propagation environment; iv) use of ray tracing tools. Therefore this step could be implemented through experiments on the field and/or mathematical evaluation; for this reason the block in Fig. 3.4 is white and grey.

Let I be the set of nodes in the real world deployment, whose size, |I|, is equal to N^(r); P_ik^(r) denotes the average power received by node i ∈ I when node k ∈ I is transmitting, provided that the number of received packets is larger than a given threshold. If the number of packets received over the link is lower than the threshold, the two nodes are considered as not connected and a null element will be present in the matrix.

Therefore, once a suitable or feasible method to compute connectivity among nodes is found, the connectivity matrix, P^(r), of size N^(r)xN^(r) can be derived.

The matrix P^(r) will represent the outcome of this first step.

It is important to underline that in this work the average received power was used as metric, instead of its full statistics, to keep the complexity of the method-ology under control. In fact, for the procedure to be really useful to IoT devel-opers, the amount of processing on the real deployment tests should be as small

as possible.

• Measurement of the connectivity in the controllable testbed

The second step requires the measurement of the connectivity matrix of the controllable testbed. Note that different matrices could be derived by setting different parameters affecting the connectivity among nodes, as the transmit power, or the receiver sensitivity. Similarly to the case of the real word deploy-ment, J denotes the set of nodes in the controllable testbed of size |J| = N^(c) and P^(c)_jl denotes the generic element of the generic matrix P^(c), representing the average power received by node j ∈ J when node l ∈ J is transmitting.

Therefore, the outcome of this step will be the set of all possible connectivity matrices of the controllable testbed, each of size N^(c)xN^(c). As the controllable testbed is well accessible and deployed in relatively small environments, this step can be executed through direct measurements on the field (white block in Figure 2).

• Downscaled testbed nodes selection For each node of the real world deploy-ment a counterpart in the controllable testbed has to be selected with the aim of reproducing the same connectivity properties. More precisely, let us denote with φ(i) : I → J a function mapping each node of the real world deployment to a node of the controllable testbed, i.e., for each i ∈ I, φ(i) is its counterpart in the controllable testbed and φ(i) 6= φ(k)∀i, k ∈ I. In the ideal case, we would like to have P_ik^(r) = P_φ(i),φ(k)^(c) for all pairs of nodes i, k ∈ I. Usually this is not achievable, but we want to get as close as possible to the ideal case by finding

the mapping function φ that minimizes the sum of the distances

The problem can be modeled as a Rectangular Quadratic Assignment Problem (RQAP) [66], which calls for the determination of an assignment of each element of I to a distinct element of J (with |I| < |J|), so that the objective function, D, representing the distance between the two connectivity matrices, is minimised.

More precisely, if node i ∈ I is assigned to node j ∈ J and node k ∈ I is assigned to node l ∈ J, their distance, dijkl, is defined as

dijkl = |P_ik^(r)− P^(c)_jl | + |P^(r)_ki − P^(c)_lj |.

Quadratic assignment problems are among the most difficult and studied Com-binatorial Optimization problems found in the Operations Research literature.

RQAP is strongly NP -hard, i.e., it does not have an approximation algorithm running in polynomial time for any factor, unless P = NP [67]. We introduce a set of |I|x|J| binary decision variables

xij =

RQAP can be formulated as the following Integer Program with a quadratic objective function.

Constraints (3.2.1b) impose that each node in I is assigned to a node of J and constraints (3.2.1c) impose that each node of J is assigned to at most one node of I. For the sake of completeness, it should be noted that more sophisticated models and ad-hoc algorithms for quadratic assignment problems can be found in the literature, but their investigation is out of the scope of this work and the method described here was adequate to tackle the instance of the problem of interest. According to preliminary computational experience, model (3.2.1) turned out to be not solvable in reasonable computing time by state of the art quadratic programming solvers for the size of the instances arising in practical cases. Therefore a standard linearized integer programming model for RQAP was adopted. Consequently, a second set of decision variables is introduced:

yijkl = xijxkl (i < k ∈ I, j, l ∈ J).

and then RQAP can be written as the following 0-1 linear program:

min D =X

The new constraints (3.2.2d) link the two sets of variables, forcing yijkl = 1 if node i ∈ I has been assigned to node j ∈ J and node k ∈ I has been assigned

to l ∈ J. Such formulation is valid since in this case all the coefficients dijkl are non negative. Thus, it is never convenient to set yijkl = 1, if not imposed by constraints (3.2.2d). Model (2) brings to the selection of a different subset of nodes, for each of the connectivity matrices P^(c). The final subset, identifying the downscaled testbed, is selected by comparing the values of D obtained for the different matrices P^(c), taking the case with minimum D.

• Utilization of the downscaled testbed (Steps 4-7) Once the subset of nodes of the controllable testbed has been identified, the resulting downscaled testbed can be used. As shown in Figure 3.4, the first step of this second part of the methodology (step 4) is to run the intended application/protocol on the downscaled testbed, in order to derive the performance metrics of interest. In case the achieved performance does not satisfy the application requirements, the designer can work on protocols optimisation and/or parameters tuning (step 5), before repeating experiments (i.e., moving back to step 4). The designer will remain in this loop (steps 4 and 5) until the desired performance is reached, and then he/she will move to step 5, running the application on the real world deployment. Results obtained on the real environment could be then compared to those achieved on the downscaled testbed (step 7), in order to check the presence of possible differences. In particular, the reasons causing unexpected network behaviors and performance could be investigated and taken into ac-count for possible future deployments.