# Toward a Detailed Evaluation of Wireless Industrial Data Distribution Approaches +
## 4 Simulation Model
### Channel Scheduling for WirelessHART  
One main problem we encountered in modeling WirelessHART is that the channel scheduling mechanism has yet to be standardized, and just some requirements are indicated in the standard document [34]. Two problems have been dealt with: how to assign slots to pairs of nodes in order to avoid collisions and how to form the superframe. As far as the former problem is concerned, we implemented a graph coloring algorithm on the tree topology with two constraints to be fulfilled. Considering the maximum number of neighbors owned by inner nodes, five colors are needed for the solution, and they must be assigned to nodes so that two neighbor nodes have different colors, so as to send their frames in different slots and avoid collisions between their transmissions. Moreover, the neighbors of a certain node \(n\) must have different colors in order to avoid the hidden terminal problem. The example coloring in Figure 1 satisfies both requirements; e.g., contemporary transmissions from nodes with coordinates \((0,0)\) and \((1,1)\) cannot occur, thus avoiding collisions in nodes with coordinates \((0,1)\) and \((1,0)\). Graph coloring is computed offline as well, and assigned slots are configured in the nodes when the simulation starts. As far as the latter problem is concerned, we opted for assigning slots in the superframe with the aim of maximizing the sleep time of nodes and minimizing latency. The Trivial solution of building a superframe formed by \(N\) slots, with \(N\) the number of nodes in the network, is unsatisfactory. Indeed, it neglects the possibility of nodes that contemporarily use a slot of a given color without provoking collisions. This is for instance the case of nodes with coordinates \((0,0)\) and \((1,2)\) in Figure 1, which are not neighbors, nor do they have any neighbor in common. Moreover, it forces a node with \(k\) neighbors to use \(k\) superframes to send one frame to each one of them. As an example, in a network with 180 nodes and with slot duration of 10 ms, a node with four neighbors will spend \(180\times 4=720\) ms to send a frame to each one of its neighbors. A node stays awake for up to five slots (one for transmission and four for reception to/from neighbors) in each superframe. The alternative solution of having one slot per color in a superframe is disadvantageous under the point of view of energy consumption. Indeed, a node with four neighbors must stay awake in all five slots of the superframe to both send in its slot and receive from its neighbors. In our solution (we indicate it as em Broadcast), by contrast, a superframe is such that, for each node, there are as many slots as the number of its neighbors; e.g., node \((1,1)\) in Figure 1 is entitled to use four blue slots in each superframe. This way, in a certain superframe, a node \(n\) may send a frame to each one of its neighbors, and parallelism between distant nodes is allowed. With this policy, the upper bound on the superframe size is \(\#colors\times node\_degree\), which in our networks amounts to \(5\times 4=20\) slots--corresponding to 200 ms--thus being independent of the network size \(N\). The minimum superframe length is achieved when the tree degenerates to a list: in this case, three colors are enough, each node has two neighbors, and \(3\times 2=6\) slots per superframe are needed. Hence, latency is limited. Furthermore, this solution allows to save battery energy with respect to the choice of using one slot per color. In fact, a node stays awake for at most eight slots per superframe (four for transmission and four for reception to/from neighbors), if it owns four neighbors. As shown in Figure 3, this is seldom the case in our simulations: with 180 nodes, we obtained a superframe size of 15 slots, and the maximum node degree is 3 in the CNC-centered [PERSON]'s tree. The _Broadcast_ solution showed a drawback with the C2 model: it supplies low latencies in uplink paths toward the CNC, while downlink paths show worse delays since up to one superframe is needed to perform one hop.