# Multiple Instances QoS Routing in RPL: Application to Smart Grids +
## 3 Proposed Solution
### mOFQS Metric  
To enable RPL to consider the remaining energy, the latency and the multiple instances beside the reliability using _ETX_, _mOFQS_ includes the Power State _PS_, the delay \(d\) of delivering a packet within two nodes in milliseconds and two parameters \(\alpha\) and \(\beta\). _mOFQS_ formula is shown below:  
\[mOFQS=\frac{\alpha(ETX\times d)}{PS^{\beta}}\]  
where \(\alpha\) and \(\beta\) are two tunable parameters with \(\alpha=1-\beta\), \(0<\alpha<1\) and \(0<\beta<1\). _mOFQS_ is an additive metric whose values over the path is the sum of the values at each hop. The idea is to multiply _ETX_ by the delay \(d\) for every hop to get the links reliability while considering the delay of the packet delivery, then multiply the factor \(ETX\times d\) by \(\alpha\) to foster link quality and end-to-end delay for critical applications by increasing \(\alpha\). \(\alpha(ETX\times d)\) is then divided by _PS_ to the power of \(\beta\). Increasing or decreasing \(\beta\) will similarly foster _PS_. If the application is critical, \(\beta\) should be decreased (resp. \(\alpha\) increased). For delay tolerant applications, increasing \(\beta\) will result in a longer route while conserving the nodes power since the metric will weight more node energy level rather than link quality or end-to-end delay. Figure 3 shows how _mOFQS_ behaves as a function of \(\alpha\) for the different _PS_ values (with \(ETX=1\) and \(d=1\)). The higher \(\alpha\) values and the more critical energy level (the worst the conditions), the higher the _mOFQS_ value to be considered. Each node chooses the path upward in its DODAG with the lowest value provided by _mOFQS_. As mentioned, the lowest value of _mOFQS_ defines the best quality links. First of all, varying \(\alpha\) and \(\beta\) allow us to differentiate between instances depending on their criticality level. Less critical applications will tolerate the use of less good links. Dividing \(\alpha(ETX\times d)\) by _PS\({}^{\beta}\)_ aims to foster routes where the nodes consumed less their batteries or are main powered. For one application, we favor \(\alpha\) or \(\beta\) against the other, and since \(\alpha+\beta=1\), when one parameter increases the other decreases and vice-versa. Figure 4 depicts a small network of 6 nodes running RPL, considering two different applications: one is critical and belongs to Instance 1 and the other is regular and belongs to Instance 2. When node 6 needs to send a packet to node 1, we consider the following paths: path 1: \(6\to 5\to 2\to 1\) or path 2: \(6\to 4\to 3\to 1\) or path 3: \(6\to 4\to 3\to 2\to 1\). Table 2 shows the different paths metric values with _ETX_, _HC_ and _mOFQS_. For _ETX_ alone, path 1 is the optimal one since it is the only metric used. We can thus note that each path features different QoS and can be favored by using a metric rather than another one. This is how we will achieve the multi-instance routing and QoS differentiation. For _ETX_ & _HC_, _ETX_ is used for the critical traffic (Instance 1) and _HC_ for the regular one (Instance 2), as we can see Instance 2 optimal path will be 1 or 2 since they count less hops, and for Instance 1,it will be path 1 which has \(ETX\) = 7.5. Neither \(ETX\) or \(HC\) take energy consumption and delay into consideration, unlike \(mOFQS\) where \(\alpha\) and \(\beta\) values will foster one path over the other. With \(mOFQS\), in Instance 1 with critical traffic which requires minimal latency, we have to route the packets as fast as possible while guarantying a reliable link. Thus, we increment \(\alpha\) (\(\alpha\) = 0.9) fostering \(ETX\times d\) (reliability and latency), which means decreasing \(\beta\) (\(\beta\) = 0.1). \(mOFQS\) fosters path 1 since it has better \(ETX\) and \(d\) values than paths 2 and 3. In Instance 2, where the traffic is not critical, we increment \(\beta\) (\(\beta\) = 0.9) and foster \(PS\), which means that we might pass by a longer and less reliable route, while guaranteeing load balancing.