A P2P multi-path routing algorithm based on Skyline operator for data aggregation in IoMT environments

Routing metrics

An objective function optimizes a specific metric for finding a routing path to meet a particular application requirement or reduce the communication cost. Each metric represents some context information used as a criterion for selecting the best route. The objective function can combine two or more routing metrics.

An IoMT application requirement may ultimately change. Hence, a fixed routing metric can not meet the varying application needs. The combination of the expected number of re-transmissions (ETX) and residual energy measurements, for example, allows the construction of more reliable communication pathways while extending the network lifetime. Such pathways may result in an inconsistent access time, which is unsuitable for real-time applications. As a result, different criteria must be combined to determine the best path.

In this section, We define a set of routing metrics corresponding to various routing QoS requirements.

• Hop count: This metric measures how many hops a message took to travel from a source node  s to a destination node  d. This metric allows the selection of the shortest bath from  s to  d. The hop count (Hc) function determines the number of nodes on a given route  R using Eq. (1). (1)${\displaystyle Hc\left(R\left(s,d\right)\right)=\left|\left(n_1,..,n_k\right)\right|}$

• Energy: This metric refers to the node’s residual battery level. With this metric, it is feasible to avoid selecting low-energy routes allowing the network lifetime to be extended. The energy (En) function, defined in our previous work Laouid et al. (2017), estimates the energy factor value of a given route using Eq. (2). (2)${\displaystyle En\left(R\left(s,d\right)\right)=w_1\times \mu \left(R\left(s,d\right)\right)+w_2\times \sigma \left(R\left(s,d\right)\right)}$ where μ(R(s, d)) represents the energy mean of the route R(s, d), σ(R(s, d)) represents the energy standard deviation of the route R(s, d) where w₁ + w₂ = 1 ∀ w₁ ≥ 0 and w₂ ≥ 0.

• Delay: This metric measures the time it takes a message to travel from s to d. For applications requiring real-time message delivery guarantees, this measure can be used to choose the route with the least delay. The delay (Dl) function defined in Eq. (3), calculates the sum of the transfer time of all the links in the route R. (3)${\displaystyle Dl\left(R\left(s,d\right)\right)=\sum _{i=0}^{k-1}dl\left(n_i,n_{i+1}\right)}$ where dl(n_i, n_i+1) represents the time to carry a message from the node n_i to n_i+1.

• Service cost: It is crucial to compute the service cost for a message to travel from s to d in an IoMT network and with the introduction of SaaS (Hammoudeh et al., 2020). The cost (Co) function, defined in Eq. (4), calculates the sum of each node’s service cost in the route R. (4)${\displaystyle Co\left(R\left(s,d\right)\right)=\sum _{i=1}^{k-1}sc\left(n_i\right)}$ where sc(n_i) represents the service cost necessary to use node n_i as a bridge.

• Link Quality: This metric is required for applications that need a high level of communication reliability. Several parameters, including the ETX, link quality Level (LQL), and received signal strength (RSS), can be used to determine the link’s quality. Eq. (5) defines the link quality (Lq) function, which calculates the minimum between the link qualities of each link in the route R. The “weakest link” approach is applied to calculate Lq (Fang et al., 2008; Chaudhary & Raghav, 2016). (5)${\displaystyle Lq\left(R\left(s,d\right)\right)=mi{n}_{i=0}^{k-1}lq\left(n_i,n_{i+1}\right)}$ where lq(n_i, n_i+1) represents the link quality between node n_i and n_i+1.

• Security level: This metric addresses security-sensitive applications. The security level (Sl) function estimates the minimum between the security levels of each link in the route R, as represented in Eq. (6) (Fang et al., 2008; Chaudhary & Raghav, 2016) (6)${\displaystyle Sl\left(R\left(s,d\right)\right)=mi{n}_{i=0}^{k-1}sl\left(n_i,n_{i+1}\right)}$ where sl(n_i, n_i+1) represents the security level between node n_i and n_i+1.

• Availability level: This metric is relevant for mission-critical applications. Eq. (7) defines the Availability Level (AL) function, which estimates the minimum between the availability levels of each link in the route R (Fang et al., 2008; Chaudhary & Raghav, 2016). (7)${\displaystyle Al\left(R\left(s,d\right)\right)=mi{n}_{i=0}^{k-1}al\left(n_i,n_{i+1}\right)}$ where al(n_i, n_i+1) represents the availability level between node n_i and n_i+1.

One or more metrics can be utilized to determine the best path depending on the unique needs of each IoMT application. P2p-IoMT is designed to accept other routing metrics to meet the unique needs of emerging applications.

P2P-IoMT specifications

This section gives the technical specifications of the proposed P2P-IoMT routing protocol. Routing metrics listed in ‘Skyline Operator’ are used to calculate the best route for a particular IoMT application.

The network is represented as a graph  G that is not necessarily fully connected and supports multi-hop communications. As shown in Fig. 1, G consists of a set N of n nodes, each representing a device, and a set L of links connecting these devices. We define R(s, d) as a sequence of nodes (n₀, n₁,.., n_k) representing the path from s to d while ensuring that the following requirements were met:

• n₀ = s

• n_k = d

• n_i ≠ n_j for i ≠ j

• (n_i, n_i+1) ∈ L for 0 ⩽ i ⩽ k − 1

To choose the optimal route, the source node first broadcasts a route request message (P2P-RReq) to all of its neighbours. The content of the P2P-RReq is described in Table 1 and summarised as follows: (1) P2P-RReq message type, (2) destination IP Address, (3) hop count between n_i and the source node, (4) number of metrics that will be sent, (5) cumulative value of each necessary routing metric of the previous optimal route, (6) weighting value of each critical routing metric, and (7) hop limit. After receiving a P2P-RReq, a node increases the hop count value and computes and updates the cumulative difference value of each metric between the current parameter of the node and its predecessors. Finally, every node determines using an objective function which parent is the best for forwarding messages to the gateway by utilising the saved hop count value and the cumulative metrics.

The P2P-RReq processing method ensures all broadcast messages follow the shortest path to the source node. The distributed computation of the path minimises energy consumption and the number of transmitted messages. P2P-IoMT proceeds with the following steps:

1. Broadcast and distributed computation: A node must perform some computation before broadcasting its P2P-RReq, such as computing the cumulative value of each needed routing metric. Table 2 shows how the best routes are kept in the routing table; the table is arranged into classes, with each class containing routes with the same number of hops. Each node broadcasts the best cumulative value of the used routing metrics just once after a predetermined time from receiving the first P2P-RReq. A node can keep other routes as backups or alternative routes. This approach offers a solution for the joint route problem and the reduction of message exchange during the network initialisation phase. A predetermined delay time is imposed to receive all anticipated P2P-RReq messages before propagating the best route. Although each node incurs an overhead because of the preset delay, this method reduces the joint route problem. The purpose of a network flood is to ensure that the routing table of each node has several entries arranged by hop count to reach the destination. When the optimal path required routing metrics of the objective function are below a specified threshold, the node requests the source node to initiate a discovery process to find alternative paths. Once a message has reached its hop limit, it can not be transmitted further. As a result of reducing node access, resource utilisation at the node level is reduced. P2P-IoMT does not save a routing table for all nodes in the network because it operates in a reactive mode. This strategy reduces routing overhead and memory usage. In addition, P2P-RReq only contains the application request’s needed metrics, which reduces the message size.

2. Route selection: The objective is to determine the optimal route between s and d according to the application’s QoS needs. The application’s QoS need is defined as a request, representing the weightings of various routing metrics of the required objective function. The selection process is divided into three parts. Just the first classes with the fewest hops in the first step are examined to reduce the selection field, as shown in Fig. 1B. In the second step, the Skyline operator chooses the routes that best satisfy the application request, as illustrated in Fig. 1C. The Euclidean distance is then applied in the third stage to rank the best routes to overcome the Skyline problem, not showing the different routes in priority order, as seen in Fig. 1D. Increasing the number of routes in the selected set allows the identification of better routes with higher objective function values. Other classes with a high number of hops can be used to achieve such an increase.

Below is a description of other P2P-IoMT message types:

1. Route Reply (P2P-RRep): When the destination receives the P2P-RReq, it must respond with a P2P-RRep. The P2P-RRep is returned via the preferred parent specified during P2P-RReq forwarding.

2. Route Reply Acknowledgement (P2P-Rrep-ACK): This message is used to confirm the receipt of a routing response message (P2P-RRep).

3. Route Error (P2P-Rerr): This message reports routing errors. It is sent when nodes detect connectivity or route availability issues. Nodes that receive a P2P-Rerr update their routing table accordingly.

Skyline operator

The Skyline operator (Borzsony, Kossmann & Stocker, 2001) and its variations, such as dynamic Skyline (Papadias et al., 2003) and reverse Skyline (Dellis & Seeger, 2007), recently attracted research interest in multiple criteria decisions making. In this subsection, we present the skyline query and describe how to utilize it to solve the route selection problem.

A typical example of the Skyline application is to select the hotel with the lowest price and the closest proximity to the beach (Borzsony, Kossmann & Stocker, 2001). Hotel h1 with a price of 600 and a distance of two miles from the beach is preferable to hotel h2 with a price of 700 and a distance of three miles from the beach. We say that h1 dominates h2.

Given a set R of data points, the routes in P2P-IoMT are represented in d-dimensional space, with each dimension representing a routing metric of the routes described with correctly ordered values. In each metric, we assume that the lowest value is preferred. For routes R_i and R_j, route R_i is better than the route R_j with respect to R, if R_i is not greater than R_j in all metrics. Furthermore, R_i must be smaller than R_j in at least one dimension. We say that R_i dominates R_j. Formally, a route R_i dominates R_j, is denoted as R_i < R_j, if and only if: (8)${\displaystyle R_i\left(k\right)\le R_j\left(k\right)}$ ∀ k with 1 ≤ k ≤ d and exists k with 1 ≤ k ≤ d such that (9)${\displaystyle R_i\left(k\right)<R_j\left(k\right)}$ where R_i(k) represents the value of the k-th routing metrics of the route R_i.

Figure 2 depicts an example using a two-dimensional routing metric space R with the multiple routes depicted in Table 3. The service cost and latency routing metrics correspond to each route. Meanwhile, note that route R₅ is a better choice than R₆, since R₅ has lower service cost and delay values than R₆, i.e., R₅ dominates R₆. Based on this method, we can discover Skyline routes not dominated by other routes. A route selection application can only evaluate the routes in the Skyline {R₂, R₅, R₇, R₈}.

Selection of the best route

The goal is to allow applications to select the path that best fits their QoS needs. P2P-IoMT assumes that at time t₀ = 0, each node has its identifications and the values of each routing metric. The hop counter and the timer reduce redundant message transmissions. Each node that receives P2P-RReq performs some calculations before broadcasting it to all its neighbours. Figure 3 shows a flowchart that explains how P2P-IoMT works. The flowchart has three levels: (1) The source node, which creates and broadcasts a route request message P2P-RReq. (2) The intermediate node receives the messages, chooses the best parent, and rebroadcasts the best-found path. (3) The destination node returns the P2P-RRep message. The computation performed by a given intermediate node n_t is summarised as follows:

1. Increase the hop value of the receiving P2P-RReq and, if not already started, start the timer t_x.

2. Compute the different routing metric values as described in the Equations 1 − 7 to determine the different factor values of the sender node.

3. The routes with the same hops are grouped by class and saved in the routing table.

4. The timer waits t_x to receive all probable P2P-RReq.

5. Finally, once the timer is expired, the node calculates the best route before broadcasting it.

At the end of the timer t_x, each node searches in the routing table for the optimal path to reply to the query. The route selection method is divided into three stages, which were inspired by the critical phases developed in our earlier work (Kertiou et al., 2018):

• Phase 1: The number of nodes in a route directly impacts its quality. The energy usage, response time, and service cost increase when the number of nodes increases. P2P-IoMT evaluates the path with the fewest hops while determining the best route. Then, P2P-IoMT employs the first class of routes, as shown in Fig. 1B. Increasing the class number in the selection phase of the best routes enhances the scope of discovering routes. However, this increases the calculation at the node level and reduces the node’s life.

• Phase 2: The Skyline query reduces the search space and improves route discovery’s efficiency. The skyline is the collection of all routes not dominated by one another. We only consider Skyline routes throughout the route selection process, where Skyline routes dominate non-Skyline routes due to higher routing metrics.

• phase 3: The objective is to find the optimal path that fulfils an application’s requirements. The skyline approach allows a node to choose the best routes but does not rank them. Hence, the skyline must be complemented with a multi-criteria decision technique for this objective. As a result, the list of routes not dominated is utilized in the ranking phase. The following is the order of the routes:

  • The list of Skylines routes is considered as a matrix analysis of Q = (q_ij), i = 1..n, j = 1..m, where each line represents a route, and each dimension (column) represents a routing metric, e.g., delay, energy or service cost. N is the number of routes, and M is the number of routing metrics. Each element of the matrix q_ij represents the value of the routing metric j of the route i.

  • Then use the following formula is applied to normalize the analysis matrix over [0, 1]: ${\displaystyle q_{ij}^{{}^{\prime }}=\frac{q_{i_j}-q_j^{min}}{q_j^{max}-q_j^{min}}}$ where $q_j^{min}$ is the minimal and $q_j^{max}$ the maximal value of column j.

  • The Euclidean distance between each route of the matrix and the origin of the space O (ideal route) is calculated as follows: ${\displaystyle d\left(R,O\right)=\sqrt{\sum _{j=1}^m{w}_j{\left(R^j\right)}^2}}$ where w_j represents the weight of the jth routing metrics required.

  • Finally, the routes are ranked in increasing order based on the Euclidean distance before choosing the first route as the optimal route.

Algorithm 1 details the procedures for selecting the best parent for each node, the acronyms are listed in Table 4.

Application use case

We track the execution of the different P2P-IoMT steps on a use-case to demonstrate its execution in practice. Assume there is a network with 10 nodes, shown in Fig. 4, where the values of the nodes indicate the node’s energy level and service cost, and the values of the links represent the latency, link quality, security level, and availability level of the link. The objective is to select the best route from node 1 to node 10 according to the application’s requirements. We assume that an application requests the optimal route with the lowest latency and service cost, with weights of 0.6 and 0.4, respectively.

First, node 1 prepares the route request message P2P-RReq as needed in the application before broadcasting it to all its neighboring nodes. After receiving all potential P2P-RReq messages before the timer expired, each node generates the routing table containing the different parents connecting it to the destination node (node 10) with the required routing metrics’ cumulative values. The following steps are applied to select the best route that meets the demands of the application:

• Phase 1: Evaluate the first three classes of routes to reduce the selection field for the best route. Then, investigate routes with a minimum, minimum plus one, and minimum plus two hops to route data from the source node (node 1) to the destination node (node 10) with the cumulative values of delay and service cost as shown in Table 5 in columns (2; 3; 4).

• Phase 2: Calculate the list of Skyline routes as presented in the fifth column of Table 5.

• Phase 3: Use the Euclidean distance to rank the list of Skyline routes as presented in the sixth column of Table 5.

Finally, as shown in the two last columns of Table 5, each node chooses the best parent, i.e., the node which provides the best path to the destination node, to transmit back to their neighboring nodes and saves the remaining parents as secondary parents.

Simulation model

We adopt the same testing setup and data described in Laouid et al. (2017). The experiment was run in the TinyOS simulator (TOSSIM) to mimic and extract the TelosB sensor findings. We construct a network with 50 randomly distributed nodes throughout a 60 × 60 m² space. To calculate the communication routes, we employ the P2P-RReq broadcast discovery request. Nodes are homogeneous in that they all have the same specifications.

On Mac 802.15.4, the transmission/reception rate is 250 kbps, with a maximum message size of 29 bytes. A unique ID identifies each device. The TelosB Motes (Prayati et al., 2010) are used to calculate the power consumption characteristics. Each node is powered by a battery with an initial capacity of 9580J. The total simulation phase lasted 27.3 min. The following routing metrics were used to choose the optimal route: hop count, node energy, node cost, and transmission latency (delay).

Performance analysis

In this experiment, our primary goal is to select the optimal route that meets the needs of an application between nodes 1 and 2. The selection efficiency is assessed in the following three scenarios.

Single and two routing metrics

Figure 5 depicts the optimal route determined by a single routing metric. Figure 5A illustrates the chosen route using hop count(traditional LOADng), Fig. 5B depicts the chosen route using the energy metric as demonstrated in our previous work (Laouid et al., 2017), Fig. 5C depicts the chosen route using the node cost, and Fig. 5D describes the chosen route using the transmission delay. It is evident from the various figures that routes with a greater or smaller number of hops are chosen for different requests.

There may need to be more than a single measure to meet the needs of the applications. For example, using node cost as the only routing metric in selecting the optimal route might result in a higher transmission latency. Note that applications that use the same routing measure may require differing metric weights. Figure 6 shows the optimal route chosen using the node cost and the transmission latency routing metrics with varying weightings. Figure 6A shows the chosen route in a request with a weighted cost of 0.6 and a latency of 0.4. Figure 6B depicts the selected route in another request with a weighted cost of 0.7 and a delay of 0.3. Figures 6A and 6B show that different results are obtained for various requests with different weightings while using the same routing metric.

Three and multiple routing metrics

Figure 7 shows the optimal route chosen using three routing parameters, namely, node cost, node energy, and transmission delay, with varying weightings. Figure 7A shows the preferred route in a request with weighted costs of 0.3, 0.2, and 0.5 respectively. Figure 7B depicts the chosen route in another request where the weighted costs are 0.2, 0.5, and 0.3. Figures 7A and 7B illustrate that when the same metric routing is utilized, we obtain different results for various requests (different weightings).

To show the scalability of P2P-IoMT in terms of the number of metrics, we re-executed the experiments using six metrics with different weights and an increased link density. Figure 8 shows the optimal route with six routing metrics (energy, delay, service cost, link quality, security, and availability level) with two different requests.

Performance comparison

In this section, we compare our P2P-IoMT’s performance to LOADng (with hop count as the only routing measure) and LRRE (Sasidharan & Jacob, 2018). LRRE’s composite routing metric reduces network congestion and extends nodes’ life. Three routing metrics are used to select the best route, namely, hop count, residual energy, and the total number of live routes on a node. The same experimental environment was utilized, and the simulation was run five times with the average value used as the outcome. Simulation results show that P2P-IoMT performance exceeds its best rivals in the literature.

Four evaluation parameters are utilized to measure the efficiency of three compared routing strategies. The first parameter is the packet delivery ratio (PDR), which is a measure of reliability and is computed as follows (Sasidharan & Jacob, 2018): ${\displaystyle PDR=100\ast \frac{number-of-packets-delivered}{number-of-packets-generated}}$ where the number of packets created equals the total number of packets generated by source nodes, and the number of packets delivered equals the total number of packets received by destination nodes. Figure 9 compares the PDR versus the number of nodes in the network. We observe that the proposed P2P-IoMT exhibits the best PDR performance while LOADng performs worst. P2P-IoMT effectively avoids congested nodes and nodes with low residual energy based on availability level, link quality, and energy metrics during the route selection. Consequently, P2p-IoMT significantly reduces packet loss caused by congestion and node failures. By maintaining a constant node density, we observe that the average hop count required to reach the destination increases proportionally with the expansion of network nodes. Consequently, the PDR decreases as the number of nodes in the network increases.

The second evaluation metric is the node’s average residual energy, which reflects how well the routing protocol can spread the load across the network. Residual energy measures the network’s lifetime and is used for making energy management decisions. The average residual energy in the nodes is calculated by adding the residual energy levels of all the nodes in the network and then dividing this sum by the total number of nodes. This makes it possible to determine the average energy remaining per node in the network. The average residual energy is computed as follows (Sasidharan & Jacob, 2018): ${\displaystyle AverageResidualEnergy=\frac{\sum _{i=1}^{N}Eng\left(n_i\right)}{N}}$ where Eng(n_i) is the remaining energy of the node (n_i) (in percentage) and N is the total number of nodes in the network. Figure 10 compares the network’s average residual energy. Compared to LOADng and LRRE, P2P-IoMT exhibits the highest average residual energy, and the nodes have a longer lifetime, increasing the whole network’s lifetime. Using the node energy level and link quality metrics in P2P-IoMT achieves better energy utilization. By favoring nodes with higher residual energy, the energy load in the network could be balanced and extend the overall network lifetime. The transmission quality between adjacent nodes when selecting routing paths is also considered. Prioritizing higher-quality links enhances data transmission efficiency and reduces energy-consuming re-transmission attempts. These factors prolong the network lifetime by balancing energy load among nodes, avoiding energy-depleted nodes, and congested routes.

The third factor is the network lifetime. The network lifetime refers to the period by which the network can operate before all nodes completely exhaust their power. This is a crucial measurement to assess the network’s livability and energy efficiency. The network lifetime in IoMT is calculated using the energy capacity of the node’s and the power consumption to perform different tasks. Figure 11 shows that P2P-IoMT has the longest lifetime compared with LOADng and LRRE. P2P-IoMT extends the network lifetime to 4% compared to the LRRE protocol.

The fourth performance evaluation metric is the path discovery time, which is critical in P2P routing. It represents the time required to find a valid path between s and d. Several factors, such as the network size and topology, path discovery method, and the number of routing metrics, may influence the path discovery time of a routing protocol. In our implementation, the path discovery time varies from one experiment to another. Still, in general, P2P-IoMT is slightly lagging compared to other path discovery protocols for the following reasons:

• The number of metrics used increases the computation time

• Larger message size

• The two-phase (Skyline and Euclidean distance) path calculation consumes extra time

This slight delay is tolerable compared to the selected path quality, the increased average residual energy, and the long network lifetime.

In this study, we exploit the Skyline operator in multi-critical decision-making to choose the optimal paths. In contrast to the previous protocols, we have not defined the number of routing metrics or their weighting; every application can configure the relevant metrics and their weightings based on its specific needs. The many routing metrics applicable to IoMT are identified and defined.