1 Introduction

Low power and Lossy Networks (LLNs) are an essential component of the IoT [1, 2]. They are composed of many resource-constrained embedded devices, with a capacity to sense data related to the environment, and interconnected by a variety of links characterized by high loss rates, low data rates, and instability [3, 4]. The Routing over Low-power and Lossy networks (RoLL) working group of the Internet Engineering Task Force (IETF) has first established routing requirements for four LLN application domains: urban, industrial, building automation, and home automation. The proliferation of multimedia content and the demand for new video services in IoT applications have fostered the development of a novel paradigm which we refer to Internet of Multimedia Things (IoMT) [5, 6]. Globally, multimedia applications will rise up to \(82\%\) in 2022 of all Internet traffic, up from \(75\%\) in 2017 [7]. IoMT has shifted the focus from the typical scalar devices of IoT to ones that deliver multimedia traffic as video, audio, still image in addition to scalar data. Transmitting a high volume of multimedia traffic over wireless multi-hop LLNs constrained resources, such as WMSNs [8, 9], is more challenging, where both the Quality of Service (QoS) in terms of bandwidth, latency, error rate, and jitter, among others, and the end user video experience (QoE), need to be considered [10].

Conventional routing protocols of ad hoc networks such as AODV [11] could not satisfy the requirements of LLNs. The ROLL working group designed the RPL routing protocol with the objective to meet routing requirements of the aforementioned types of LLN applications. However, it is mainly suitable to transport only scalar data and cannot provide QoS and QoE guarantees required by multimedia data. This poses the challenge of designing new routing techniques taking into consideration application requirements in order to ensure acceptable delivery of the multimedia content such as remote monitoring in smart cities (e.g., citizen compliance with the Covid-19 pandemic confinement), remote patient monitoring, borders video surveillance, plants monitoring in smart farming, etc.

Multipath routing has become as a promising technique and an optimal approach that increases bandwidth and reliability, decreases delay, and evenly distributes energy consumption in the network [12,13,14,15,16]. The multiparent feature specified in RFC 6550 is the main pillar that allows the design of the multipath routing version of RPL. Existing work [17,18,19,20,21,22] that focused on the multipath routing in RPL have only addressed some issues related to LLNs such as load balancing, reliability, and congestion avoidance. In addition, these studies use multipath as a mechanism for forwarding data, relying mainly on the available list of parents of each node of the DODAG. On the other hand, few work [23,24,25,26] have been done on video transmission over RPL utilizing only a single path, none of them suggested the use of multiple paths in order to handle video traffic. According to our knowledge, this is the first work that studies the feasibility of transmitting video traffic over LLN based WMSN by using the multipath RPL routing at the same time.

In this paper, we propose a complete methodology, from design to performance evaluation, to construct multiple paths to efficiently transmit video traffic using a low complexity compressed video more adapted to LLNs constrained resources. Towards this goal, we propose a novel multipath extension of RPL that we have designed and implemented, called MP-RPL. Its basic idea is to distribute video traffic comprising frames of different priorities through multiple paths in order to keep IoMT based WMSN applications with acceptable quality level, while optimizing network resource usage. More specifically, during the DODAG construction process and based on radio link quality estimations, MP-RPL establishes multiple end-to-end paths of different qualities from each node towards the DODAG root. In order to provide higher aggregated bandwidth required for WMSN applications, the built paths are thereby used simultaneously by leveraging the video traffic nature. Therefore, the prioritized frames are routed on high-quality paths while frames with low priorities are transmitted along alternatives paths with low-quality. Besides, taking into account the limited resources of LLN/WMSN, a lightweight codec for encoding and decoding the video traffic [27] was adopted. On one side, it allows source nodes to compress the captured video traffic before the transmission over the network. On the other side, it permits the root node to evaluate the quality of the decoded received video in terms of PSNR (Peak Signal to Noise Ratio) and SSIM (Structural SIMilarity) QoE metrics.

In addition, our methodology proposal is designed such that it induces minor changes to the standard RPL routing protocol so that it can be easily implemented on resource-limited real-world sensor motes and adapted to other types of codecs.

Finally, the design, implementation as well as the promising simulation results are considered as a proof of concept for the feasibility of the proposed solution.

The remainder of this paper is organized as follows. Section 2 introduces brief overviews of the RPL routing protocol as well as the existing tools dedicated to video transmission and evaluation. Section 3 presents the related work. Section 4 describes the system model of the IoMT based WMSN. Section 5 gives details of our contribution. Section 6 explains simulations and provides the performance evaluation along with the obtained results from our contribution compared to RPL. Finally, Section 7 concludes our work.

2 Preliminaries

In this section, we describe some basic concepts of the standard RPL routing protocol followed by a presentation of an overview of some existing tools targeted for video transmission and evaluation.

2.1 RPL Routing Protocol

RPL [28,29,30] is a distance vector IPv6 routing protocol designed for LLNs, it constructs a topology as a Directed Acyclic Graph (DAG), which consists of one or more Destination-Oriented DAGs (DODAGs). An RPL instance may contain several DODAGs. An RPL network may regroup more than one RPL instance. RPL uses three ICMPv6 [31] control messages for creating and maintaining RPL topology and routing table:

  • DODAG Information Object (DIO) message is used by RPL to form and maintain the DODAG. Thereby, upward routes are constructed for allowing communication from multiple nodes to the root node. Such multipoint-to-point (MP2P) traffic dominates the RPL applications.

  • DODAG Information Solicitation (DIS) message allows a node to solicit a RPL node’s DIO message .

  • DODAG Destination Advertisement Object (DAO) message is used by RPL to propagate a node prefix to the ancestor nodes in support of downward traffic from the root node to nodes (Point-to-multipoint: P2MP). RPL, also used the node to node (point-to-point: P2P) communication pattern where upward and/or downward routes are used.

Each node has a rank value that represents its individual relative location with respect to the DODAG root. The rank value should monotonically increase when moving from DODAG root to leaves to guarantee a loop-free topology. It is computed according to an Objective Function (OF) and a set of metrics and constraints. Several link metrics such as expected transmission count (ETX), throughput, latency, link quality level (LQL), etc., and various node metrics like hop count, energy, etc., have been specified in [32] and can be used for path computation in RPL. The OF defines how RPL nodes select the preferred parent to optimize routes within an RPL instance. Up to now, only two different objective functions, namely, the Objective Function Zero (OF0) [33], and the Minimum Rank with Hysteresis Objective Function (MRHOF) [34] have been standardized in RPL to optimize the path selection towards the root node. Both the default OFs work with only a single metric. OF0 is based on the node metric hop count, which minimizes the number of nodes present in the route. MRHOF used link metric ETX, an additive metric that sums each link’s ETX of the path towards the destination in order to select routes with minimum ETX, while using an hysteresis to reduce transient churns in response to small metric changes.

2.2 Video Transmission and Evaluation Tools

In order to reduce bandwidth requirements and power consumption when transmitting video traffic, the huge amount of captured video data mandate the need for pre-processing and compression prior to the transmission while considering constrained video sensor nodes in terms of energy, processing, and memory resources. Various tools have been proposed for video transmission and evaluation along with different types of codecs. Table 1 briefly summarizes the features of some of these tools. We can see from this table, that Evalvid [35] and M3WSN (Mobile MultiMedia Wireless Sensor Network) [36] used standard video coding techniques such as MPEG-4, H.263, or H.264 [37, 38] to compress video sequences. For instance, MPEG encoders generate three distinct types of frames, namely I, P and B frames, where I frames are more important than P frames, and in turn P frames are more important than B frames. However, Evalvid and M3WSN rely on resource-hungry encoders and, therefore, are not adapted to constrained networks such as LLNs/WMSNs. WiSE-Mnet++ (Wireless Simulation Environment for Multimedia Networks ++) [39] does not support encoding techniques suitable for LLNs/WMSNs as well as QoE metrics. In our work, we choose the SenseVid tool [27] since it is more suitable for WMSN and provides QoE metrics. In fact, SenseVid enhances EvaVSN [40] while adding new features such as a configurable fine-grain energy model. It is targeted to the limited resources of WMSNs. Indeed, it allows to conserve node energy by reducing the complexity of the compression algorithm leading to prolong the lifetime of wireless multimedia sensors deployed in WMSN. SenseVid follows the main principle behind the popular EvalVid tool [35] by adopting the video traffic trace approach, allowing its use in any simulation environment or real sensor network testbeds. A video sequence is a set of frames. A frame can be encoded either as a Main frame (M-Frame) or as a Secondary frame (S-Frame). This latter, is the inter-coded frame with respect to the previous intra-coded M-Frame. All these different frame types are then combined in a specific repeating order to create what is known as a Group Of Pictures (GOP). In order to adapt to network constraints and dynamics, SenseVid allows to differentiate priority levels of the data to transmit. For an M-Frame, the packet priority level range from 0, the highest, to 12, the lowest packet priority level. However, a secondary frame S-Frame has five priority levels ranging from 0, the highest, to 4, the lowest one. At the sender application side, the SenseVid encoder/packetizer module generates a sender trace file containing information related to each video packet to be transmitted over the network. At the receiver application side, SenseVid generates a receiver trace file (similar to sender trace file) from the received video packets, decodes and evaluates the video in terms of QoE metrics. Table 2 illustrates a sample of a sender trace file where each line gives the required information for each packet. For instance, the second packet (sequence 2) with a payload size of 96 bytes of the first M-Frame has the highest priority level (priority 0).

Table 1 Comparison of existing tools for video transmission and evaluation
Full size table
Table 2 A sample of the st-packet with a maximum packet payload size of 96 Bytes
Full size table

3 Related Work

The main objective of this work is to exploit the multipath routing approach to enable RPL to handle multimedia data, in particular video data, generated by multimedia applications. Before explaining how our proposal works, we mention in this section research work that have enhanced RPL or just tuning its parameters in order to improve its performances. In particular, in the first subsection, we presented work that have studied the feasibility of transporting multimedia traffic over RPL. The second subsection, introduced studies that have used the multipath routing technique to address some LLNs issues. In Table 3, we summarize the main features of work that have enhanced and extended RPL in order to support multipath and/or multimedia, including our proposed solution MP-RPL.

3.1 Multimedia Support Over RPL

In the literature, few work exist that have addressed the question of how to adapt and enhance the native single path RPL so that it can ensure acceptable delivery of heavy traffic such as multimedia content.

In [23], an enhanced version of RPL is proposed where an objective function based on several metrics such as the delay, battery consumption, type of energy sources, and link quality is used in order to minimize carbon footprints emission and energy consumption while assuring applicationspecific QoS. The simulation results indicated that the proposed objective function surpassed the classical objective function OF0 but was not as efficient as MRHOF. To increase the network lifetime, an objective function based on the remaining energy of the node is proposed in [24]. In this work, the video encoder H.264 is used. The obtained simulation results showed that the proposal increases network lifetime by \(34\%\) comparing with ETX based RPL. Authors in [25] proposed a new objective function based on the available bandwidth. The achieved simulation results showed that the enhanced RPL outperforms the native RPL in terms of end-to-end delay, throughput, packet delivery rate and power consumption. A simulation based study of the feasibility of visual data transmission over the standard RPL is presented in [26]. By focusing on the impact of radio duty cycling on the received video quality as well as the network consumed energy, simulation results mainly showed that RPL along with ContikiMAC can not support realtime video transmission. However, transmitting video at low rates up to 35 frames per minute (1 frame per 1.7 s) remained possible.

3.2 Multipath Routing Over RPL

Considerable research efforts have been made to develop a multipath routing version for RPL in order to overcome some problems related to LLNs, such as stability, congestion avoidance, load balancing and QoS improvement.

Authors in [22] have proposed a multipath extension of RPL, named M-RPL, to handle the congestion problem. M-RPL detects congestion on a single routing path based mainly on the buffer size and packet delivery rate at relaying nodes. It then provides temporary multipath routing to mitigate this problem by selecting more than one temporary parent for splitting traffic flow on partially disjoint paths. This helps in reducing congestion on the congested parent node. Simulation results of M-RPL versus RPL showed that M-RPL efficiently avoids congestion while enhancing overall network throughput. Reference [21] proposed a Congestion Avoidance-RPL (CA-RPL) that aims to increase reliability and minimize the latency in the network. To achieve this goal, data is distributed to already awake parents rather than waiting to the preferred parent’s wake up. CA-RPL uses a new routing metric (DELAY ROOT) based on the ContikiMAC duty cycling protocol. However, this new metric assumes that all the nodes have the same wake-up interval which may not be true for all WSNs scenarios. Simulation analysis of the proposal against RPL showed that CA-RPL successfully mitigates congestion and enhances the network throughput. To increase the network lifetime, authors in [19, 20] have proposed an energy-balancing routing scheme where all paths have to consume the same amount of energy while avoiding the use of bottlenecks nodes by measuring the Expected Lifetime (ELT) of nodes and exploiting multiple parents. To ensure network stability, the authors also suggested the use of the multipath mechanism to limit parental exchanges. Simulation based evaluation showed better routing reliability and an enhancement of the network lifetime, while lowering the number of parent changes. In [17] researchers proposed LeapFrog Collaboration (LFC), a cross-layer (MAC and Routing) scheme to improve reliability and minimize jitter in RPL-based industrial networks. LFC is a multipath routing algorithm leveraging route diversity by replicating each data packet on an alternate path and authorized each node to receive only the first copy of each data packet and eliminate the following duplicates. The obtained results show that LFC considerably surpasses the single path routing based on RPL + TSCH approach . The same authors in [18] have proposed an extension of the multipath LFC. The alternative parent selection relies on the child-parent-grand parent relationship, which requires higher overhead and bigger DIOs.

The aforementioned contributions have addressed various enhancements of RPL, but none of these studies has focused on a proposal allowing RPL to support multimedia applications using the multipath routing approach. Thus, there is a need to develop a whole new solution dedicated to IoMT based WMSN applications. In order to guarantee QoS/QoE requirements of multimedia applications, a multipath routing version of RPL is proposed. Moreover, in our proposal, operations of encoding and decoding video traffic before and after its transmission over the network, respectively, are performed by a lightweight codec suitable for constrained WMSNs, unlike the resource-hungry H.264 codec used in [24].

Table 3 Summary of the RPL’s enhancements and extensions to support multipath and/or multimedia solutions
Full size table

4 System Model

We model our IoMT based WMSN system, depicted in Fig. 1, as a graph \(G = (N, E)\) that consists of a set of N sensor nodes with different roles (source, relay or sink), and a set E containing all possible symmetric communication links. In this work, we focus especially on MP2P traffic pattern from WMSN nodes to a single root node (sink). A source node equipped with a camera can capture the video, process it and transmit video packets to the sink through relay nodes in a multi-hop manner. The sink node has two interfaces allowing it to communicate with the WMSN via one interface and the Internet via the other. Indeed, the sink receives all video packets, reconstructs the sequence video, and transmits it to servers for various purposes. In this paper, we mainly focus on RPL routing protocol to construct multiple routes towards the root node. All other communications between the sink and servers are not considered herein.

Fig. 1
figure 1

System model

Full size image

5 Proposed Solution

The main purpose of this work consists on improving the routing functionality of the standard RPL so that it can route heavy data rate traffic such as video traffic generated by IoMT applications. Towards this goal, we have specified and implemented new functionalities about the RPL multipath routing protocol version, named MP-RPL, which operates on the network layer only. MP-RPL is the heart component of our proposal that allows the transmission of video sequences over WMSN. We have also integrated functionalities of the SenseVid tool (see Sect. 2.2). Fig.  2 describes the principal parts of our solution to support encoding, transmission, and decoding with an evaluation of the video traffic quality in LLN based WMSN.

Fig. 2
figure 2

Block diagram of the proposed solution

Full size image

5.1 Multipath RPL Algorithm (MP-RPL)

The single path RPL relies on the default route, established during constructing the DODAG, for packets forwarding. Building a multipath DODAG can be realized thanks to the RPL capability of having a set of parent nodes for each node in a network. Among these parent nodes, a subset of them is used to forward packets to DODAG root.

5.1.1 Objective Function and Rank Calculation

The main goal of MP-RPL, is to find high-quality paths for transmitting video traffic that needs strict QoS requirements to offer a satisfactory QoE user-experience. To achieve this objective, we focus on Minimum Rank with Hysteresis Objective Function (MRHOF) based on the Estimated Transmission Count (ETX) routing metric to select multiple paths with minimum costs among available paths. ETX defined in RFC 6551 is the most widely used routing metric. It allows finding high throughput paths on a multi-hop wireless network, providing a good packet delivery ratio [41]. In addition, ETX helps to achieve low latency since nodes choose to relay their packets along the path with the least number of retransmissions. It also permits to ensure minimal overlap between the established paths, thereby promotes to reduce the negative effects of interference that may exist between multiple paths or among successive links of a path [42] [43]. However, ETX does not balance the energy consumption between nodes. To overcome this disadvantage, multiple parents are used to forwarding packets to the sink over multiple paths, thus ensuring load balancing. Moreover, based on a predefined parent switch threshold Th, MRHOF uses a hysteresis mechanism to reduce transient churns in response to small ETX metric changes. This ETX threshold should be different depending on application requirements. ETX is calculated using Eq. 1.

$$\begin{aligned} ETX = 1 / (D_{f} * D_{r}) \end{aligned}$$
(1)

where \(D_{f}\) is the measured probability that a packet is received by the neighbor and \(D_{r}\) is the measured probability that the acknowledgment packet is successfully received. The rank of each node is calculated according to MRHOF. The path cost associated to a given node \(N_{i}\) which received the DIO from its parent \(p_{i}\), is the sum of the parent rank and the ETX value of the link towards the parent. The path-cost-\(ETX(N_{i})\) calculated by node \(N_{i}\), which represents its rank, is given by the following Eq. 2.

$$\begin{aligned} \left\{ \begin{aligned} path-cost-ETX(N_{i})&= Rank(p_{i}) + linkETX(N_{i},p_{i})\\ Rank(p_{i})&= path-cost-ETX(p_{i}) \end{aligned} \right. \end{aligned}$$
(2)

where \(linkETX(N_{i},p_{i})\) indicates a link quality between the node \(N_{i}\) and its parent candidate \(p_{i}\). The path that minimizes the sum of ETX from the node \(N_{i}\) to the DODAG root represents its upward route towards the DODAG root. Node \(N_{i}\) changes its current preferred parent to a new preferred parent if the difference between its rank and the new rank is greater than the threshold Th. Figure  3 illustrates the parent selection and rank calculation mechanism based on the ETX routing metric.

Fig. 3
figure 3

Parent selection and rank calculation based on ETX

Full size image

5.1.2 Enhanced Preferred Parent Selection

MP-RPL follows almost the same steps of the RPL DODAG construction, the difference is in the preferred parent selection procedure. This latter has been modified to allow the selection of multiple preferred parents. In the native RPL, before transmitting data over the network, a DODAG topology is firstly built. Thus, in this first step, the root broadcasts the DIO message to nodes in its vicinity. This message includes different pertinent information, such as node rank, Objective Function (OF), mode of operation, and metrics. A node receiving the DIO for the first time adds the DIO sender address to its parent list, computes its rank according to the OF specified in the DIO message. In case the node is already joined to the DODAG, but the newly received DIO gives it a better rank in the DODAG, it must discard all nodes in the parents' list that violate the monotonous rank order to avoid routing loops. In both cases, if a node is configured to operate as a router, it forwards the DIO message with the updated rank information to its neighbors. This process repeats at each router node until all the nodes in the network join the DODAG to form a tree-structured topology. Each joined node to the DODAG selects, among the list of its parents, the most preferred parent to relay traffic to the root of the DODAG. Generally, a neighbor that advertises the minimum rank value is the preferred parent so that loop-free operation and convergence are guaranteed. Obviously, the default route is formed by the most preferred parent of each node. Different from RPL, in MP-RPL, the preferred parent selection procedure is triggered several times to retrieve other preferred parents. To better understand the proposed enhanced preferred parents selection process, we provide a flowchart in Fig.  4 that shows the different steps that a node \(N_{i}\) has to perform to select just two preferred parents from a non-empty list of candidate parents based on MRHOF/ETX.

Fig. 4
figure 4

Flowchart of two preferred parents selection

Full size image

Unlike RPL, instead of choosing only one preferred parent by which only one default path to the root will be built, two preferred parents will be selected based on the path-cost-ETX (Eq. 2) which reflects the end-to-end path quality. In other words, a node \(N_{i}\) will select the first primary preferred parent (PPP) as the one with the lower value of path-cost-\(ETX(N_{i})\) and the second preferred parent (SPP) as the one with the next lower value of path-cost-ETX. Therefore, two different end-to-end paths \(P_{d}\) and \(P_{a}\) will be established during the DODAG construction process. Note that the first path \(P_{d}\), which corresponds to the default path, is formed by the most preferred parent of each node. However, nodes that belong to the alternative path \(P_{a}\) are the second preferred parent of each node. Algorithm 1 shows the pseudo-code for the generalized MP-RPL algorithm for selecting m preferred parents from the list parent \(L_{p}\) containing n parents, where \(m \le n\). The selected m preferred parents allow the establishment of m different paths with different qualities from node \(N_{i}\) towards the DODAG root.

figure b

5.1.3 Types of Established Paths

The discovered multi-hop paths by MP-RPL can be categorized as node-disjoint, link-disjoint, or partially disjoint paths. Assume that: (i) at least two paths \(P_{d}\) and \(P_{a}\) between a node in the network and the sink node (DODAG root) are created by MP-RPL, (ii) \(P_{d}\) (resp. \(P_{a}\)) is used to forward high priority (resp. low priority) video traffic towards the sink.

Let \(P_{d} = n_{s} n_{1} n_{2} ....n_{k} n_{d}\) and \(P_{a} = n_{s} n^{'}_{1} n^{'}_{2} ....n^{'}_{l} n_{d}\), where \(n_{s}\) and \(n_{d}\) are source node and sink node respectively, \(n_{i}\) and \(n^{'}_{j}\), (\(i=1..k\), \(j=1..l\)) are intermediates nodes that belong to paths \(P_{d}\) and \(P_{a}\), respectively.

  1. 1.

    \(P_{d}\) and \(P_{a}\) are node-disjoint paths: if there is no common links and nodes, apart source and sink nodes, among the established paths. This happens when the primary preferred parent of each intermediate node \(n_{i}\) belonging to \(P_{d}\) is not in \(P_{a}\) and the second preferred parent of each intermediate node \(n^{'}_{j}\) belonging to \(P_{a}\) does not exist in \(P_{d}\). This case can be formulated by:

    \(\forall i\), \(\forall j\) such that \(PPP_{n_{i}} \notin P_{a}\) and \(SPP_{n^{'}_{j}} \notin P_{d}\), (\(i=1..k\), \(j=1..l\)).

  2. 2.

    \(P_{d}\) and \(P_{a}\) are link-disjoint paths: if there is no shared link between the paths but may contain several common nodes. We find this case when the second preferred parent of at least an intermediate node \(n^{'}_{j}\) that belongs to path \(P_{a}\) is identical to the primary preferred parent of an intermediate node \(n_{i}\) in the path \(P_{d}\). Such case can be expressed by:

    \(\exists j\), \(\exists i\) such that \(SPP_{n^{'}_{j}} = PPP_{n_{i}}\), (\(j=1..l\), \(i=1..k\)).

  3. 3.

    \(P_{d}\) and \(P_{a}\) are partially disjoint paths: it corresponds to the case where several links or nodes may be shared between the two discovered paths. This kind of paths may be obtained when the second best parent of an intermediate node \(n^{'}_{j}\) that belongs to path \(P_{a}\) is identical to the first best parent of an intermediate node \(n_{i}\) that belongs to path \(P_{d}\), and this common intermediate node \(N_{c}\) between \(P_{d}\) and \(P_{a}\) has only one parent, such that all packets received by \(N_{c}\) are transmitted to its parent node through the same link, regardless of the packet priority. Here we can formulate this case by:

    \(\exists j\), \(\exists i\) such that \(SPP_{n^{'}_{j}} = PPP_{n_{i}} = N_{c}\) and \(PPP_{N_{c}} = SPP_{n_{i}}\), (\(j=1..l\), \(i=1..k\)).

Whatever the nature of the built paths, they are however always used in a simultaneous way, so the aggregate bandwidth may satisfy the required bandwidth of multimedia applications.

5.1.4 Path Maintenance

Since nodes that belong to the established path are either first or second preferred parents, this means that any change of the preferred parent results in a path modification. These changes are handled by the Trickle algorithm that provides path maintenance. The trickle timer algorithm [44, 45] governs the transmission of DIO control messages by all the nodes. It is used to schedule the transmission of DIO. This timer allows the DIO intervals to exponentially increase and converge to the maximum interval when the network conditions are stable, after detecting any inconsistency in the network (e.g., changes of parent, rank, etc.), the trickle timer is reset to its minimum interval, triggering a more frequent DIO transmission in order to quickly overcome this inconsistency situation. Consequently, this mainly affects bandwidth and power consumption. So, it is important to minimize changes of preferred parents in order to keep the created paths as stable as possible and thereby reduce the trickle timer resets, resulting in energy saving and extended network lifetime.

5.2 Video Encoding and Transmission

Following the successful multipath DODAG construction, in case a source node wishes to transmit video traffic, it splits the traffic concurrently over multiple already established paths. Before transmitting, the source node performs various pre-transmission processing on the captured huge amount of video traffic based on the lightweight SenseVid tool. As explained above (see Sect. 2.2), two types of frames characterized by different priorities are considered: M-Frames (with high priority) and S-Frames (with low priority). Assuming that at least two routing paths are available, by using the sender trace file (Table 2), the source node starts sending video traffic over each path at the same time: M-Frames are transmitted on the multi-hop primary preferred parent path \(P_{d}\) so as to avoid as much as possible the loss of these prioritized packets, and S-Frames follow the multi-hop second preferred parent path \(P_{a}\).

5.3 Video Decoding and Evaluation

In this phase, post-transmission processing is performed on the received traffic. Video packets received by the DODAG root are recorded in a receiver trace file (similar to the sender trace file) on which SenseVid relies to decode, rebuild the video and evaluate its quality in terms of PSNR and SSIM QoE metrics. Algorithm 2 is executed by each node \(N_{i}\) in the DODAG to handle a video packet \(P_{v}\). To route \(P_{v}\), if the node \(N_{i}\) uses the path \(P_{d}\) then the next-hop is its PPP, otherwise the next-hop is its SPP which belongs to the alternative path \(P_{a}\).

figure c

5.4 Memory Footprint

Table 4 illustrates the memory footprint of the standard RPL against MP-RPL for root, router and source Tmote SkyFootnote 1 motes [46]. As shown in this table, MP-RPL occupies an amount of additional memory usage about 808 Bytes ROM and 250 Bytes RAM (less than 1 KByte) in comparison with RPL, which represents just \(1.78\%\) ROM and \(3.70\%\) RAM of extra memory. In terms of RPL variations, our solution is still compliant with RPL, we have not changed any RPL control message structure or introduced any additional traffic overhead. Consequently, the risk of messages fragmentation, especially DIO messages, and the increase of routing errors are avoided. However, we have only modified the existing structure of the parent list. Besides, we combined the proposed multipath routing strategy with MRHOF based ETX to mitigate the weaknesses of the ETX routing metric, as demonstrated by the results obtained in the following section.

Table 4 Memory footprint in RPL versus MP-RPL
Full size table

6 Performance Evaluation of MP-RPL

We evaluated MP-RPL performance by comparing it to the standard RPL through simulations using Cooja simulator [47] conceived to emulate sensor networks running Contiki operating system [48]. To assess the effectiveness of our solution, we will focus mainly on the impact of the video characteristics, especially on the effect of sending a different number of priority levels of an M-frame, denoted as \(N_{pl}\), on the transmitted video quality.

6.1 M-Frame Priority Levels (\(N_{pl}\))

To adapt to network constraints and dynamics, SenseVid supports video traffic differentiation based on the priority levels of the data to be transmitted (see Sect. 2.2). Each frame of the sequence video is encoded and packetized with different priorities depending on the given priority levels number \(N_{pl}\). For instance, if \(N_{pl}\) is set to n then we have \(n+1\) different priorities, where P0 is the packet with the highest priority 0, Pn the packet with the lowest priority n and P1 to \(P(n-1)\) are packets with intermediate priorities ranging from 1 to \(n-1\). Note that when the priority levels number increases the amount of data to transmit over the network increases too. Furthermore, video packet sizes vary significantly and are largely dependent on the number of priority levels. Such a variation in packet length has an effect on video reliability. Because shorter packet lengths have no bits that are prone to errors, unlike long packet lengths [49]. Figure 5 illustrates an example of a packetized M-Frame pertaining to a GOP of 12 frames, where the priority levels number \(N_{pl}\) is set to 3, and the packet size ranges from 96 Bytes (the longer packet) to 3 Bytes (the smaller packet).

Fig. 5
figure 5

Example of a packetized M-Frame, \(N_{pl}\) set to 3, packets P0, P1, P2 and P3 are of different levels of priority and size

Full size image

6.2 Simulations Settings

We consider a multi-hop random topology of 11 Tmote Sky motes deployed over (\(150m *150m\)) surface. The sink (resp. source) node is located at the top (resp. bottom) of the simulation area. We assume that nodes are stationary. To make it simple, we only consider one video source node. MRHOF based ETX routing metric was used for both MP-RPL and RPL to construct the DODAG structure. Due to the high rate video traffic that characterizes multimedia applications, we have used the null radio duty cycle (Nullrdc) mechanism on the Contiki OS MAC layer because it makes nodes to be awake all the time in order to receive and transmit video packets. Moreover, it has been proven in [26], that RPL under ContikiMAC can not handle realtime video transmission. However, to overcome the inefficiency of power consumption caused by this Nullrdc driver, harvesting energy mechanisms can be integrated at network nodes in order to balance the trade-off between quality of transmissions and the limited resources of WMSNs [5, 6, 50]. The source node starts transmitting video traffic after 60 seconds to allow the establishment of the DODAG topology. It sends five video packets per second (5pps) to the root. Even if MP-RPL is able to construct more than two paths, since SenseVid codec considers only two types of frames, two multi-hop routing paths \(P_{d}\) and \(P_{a}\) are therefore used. High-priority M-Frames are transmitted on \(P_{d}\) path and S-Frames with low priority follow \(P_{a}\) path. To evaluate the video quality, we selected one video sequence Hall Monitor [51] of QCIF resolution (\(88 *72\)), composed of 300 frames captured at 25fps and characterized with a low-motion sequence and a static background. The \(N_{pl}\) value, for an M-Frame, is varied from 0 to 6. For S-Frame, we have set \(N_{pl}\) at 3. All other parameters are keeping unchanged, for instance, the length and the internal structure of the GOP with 8 M-Frames and 4 S-Frames, the frame frequency capture is set to 1fps (frame per second) considering the limited bandwidth of a WMSN (250kbps at 2.4GHz), etc. For each value of the \(N_{pl}\), ten simulations are performed and the overall results are averaged. Table 5 summarizes parameter values used during the simulation.

Table 5 Simulation parameters
Full size table

6.3 Performance Evaluation

The behavior of our multipath RPL routing protocol to handle video traffic was investigated with regard to QoS/QoE metrics:

  • Packet Delivery Ratio (%) it represents the ratio between the number of video packets successfully received by the sink node and the number of video packets transmitted by the source node. A packet that belongs to an M-Frame is noted as M-packet, otherwise, it is noted as S-packet.

  • Average end to end delay (s) is the average time required for all surviving data packets to be sent from the source node to the sink node.

  • Throughput (Kbps) is the ratio between the size of all video packets successfully received by the sink node and the time required to transmit the entire video.

  • Overhead is the number of the transmitted DIO control messages.

  • Stability is the number of preferred parent changes.

  • Energy consumption per node (%) is the energy consumed by each node in the DODAG. It is computed as the sum of the energy spent in transmission, listen/reception, CPU and LPM states. Considering the CC2420 Tmote Sky datasheet [46], we can calculate the energy consumption per node EC by applying the following Eq. 3.

    $$\begin{aligned} EC = \sum (T_{state}*I_{state}*V) \end{aligned}$$
    (3)

    where \(I_{state}\), V and \(T_{state}\) represent the current consumed by the node in the state, voltage supplied to the node and the time during which the node is in that state, respectively.

  • Energy consumption (mJ) is the total energy consumed by network nodes through the simulation period.

  • QoE metrics additionally, objective QoE performance parameters, namely PSNR and SSIM [52], were analyzed. These QoE metrics were used to present the effect of the proposed solution on the user perception and were measured based on the SenseVid tool.

Packet delivery ratio Figure 6 shows the impact of the priority levels number \(N_{pl}\) of an M-Frame on the packet delivery ratio. As we can see, the multipath routing protocol MP-RPL outperforms the single path RPL for all different values of \(N_{pl}\). For both RPL and MP-RPL, the ratio increases and achieves its maximum value: a maximum ratio of \(83.19\%\) is reached by RPL when \(N_{pl}\) is set to 2 compared to the maximum ratio of \(96.75\%\) successfully achieved by MP-RPL at \(N_{pl}\) set to 3. For this value, the increase of the number of packets is better compensated with the decrease of the packet length and consequently, packets are less affected due to fluctuations and errors in the link. Beyond these values of \(N_{pl}\), the ratio starts to decrease. This is due to the fact that high values of \(N_{pl}\) result in forwarding a large amount of video data which causes an increase in packet loss. However, even at higher values of \(N_{pl}\), MP-RPL still gives a good ratio of \(95.34\%\) against \(75.19\%\) for RPL. Such results directly reflect the reliability of MP-RPL.

Fig. 6
figure 6

Impact of priority level number on total packet delivery ratio

Full size image

In Figs. 7 and 8 , we only consider the delivery ratio and the throughput of M-Frames and S-Frames with respect to the variation of the priority levels number using MP-RPL. Considering the big amount of M-packets sent to the root as depicted in Fig. 8, the achieved delivery ratio of M-packets in Fig. 7 is better compared with S-packets. This result confirms the high reliability of the first principal preferred parent path used to deliver the high priority M-packets successfully towards the root.

Fig. 7
figure 7

Impact of priority level number on M-Frame and S-Frame delivery ratio in MP-RPL

Full size image
Fig. 8
figure 8

Impact of priority level number on M-Frame and S-Frame Throughput in MP-RPL

Full size image

Average end to end delay Figure 9 illustrates the average latency of video packets successfully delivered to the root node. We can observe that the end-to-end delay obtained in MP-RPL routing protocol exceeds that of RPL. This can be explained by the fact that there are packets which take a considerable time to reach the root due to the several retransmission attempts that they undergo, and the need to be buffered. Contrary to the RPL protocol, where there are packets which can be retransmitted several times but without success and are dropped, therefore they cannot be received by the root and the end to end delay for these packets cannot be computed. Splitting the heavy video traffic among two better quality paths helps packets to reach the root node even after several retransmissions.

Fig. 9
figure 9

Impact of priority level number on packet end-to-end delay

Full size image

Figure 10 shows that, in general, the end-to-end delay of M-packets is better compared with that of S-packets. This is explained by the fact that the links of the first path taken by M-packets are of good quality which will reduce the number of retransmissions of these packets.

Fig. 10
figure 10

Impact of priority level number on packet end-to-end delay in MP-RPL

Full size image

Network stability To assess the stability of the network, we have measured the number of preferred parent changes for all the network nodes. It can be observed from Fig. 11 that RPL is more unstable having higher parent changes as compared to MP-RPL. This result is expected as all the heavy traffic is transmitted along the single path RPL, which causes more packets loss and consequently, variations in the link quality estimation (ETX increases), resulting in frequent parent changes and therefore sending DIO messages more frequently. On the contrary, since fewer packets are lost when using the multipath routing MP-RPL (see Fig. 6), the number of parent changes is thereby reduced; this leads to a significant improvement in the network stability.

Fig. 11
figure 11

Impact of priority level number on the preferred parent changes number

Full size image

Control messages overhead Figure 12 compares the average number of DIO control messages transmitted during the simulation period for both MP-RPL and RPL. We note that MP-RPL generates less DIO control messages overhead than RPL. This result is directly related to the instability of the network (see Fig. 11) where frequent changes in preferred parents lead to an increase in the sending of DIO messages.

Fig. 12
figure 12

Impact of priority level number on the DIO control messages overhead

Full size image

We note, from Figs. 11 and 12 that, at \(N_{lp}\) set to 3, MP-RPL shows the lowest overhead and number of preferred parent changes values compared to RPL. This result can be justified based on two main reasons: the first one is due to the fact that ETX is a link-based metric that focuses on the packet delivery ratio between communicating nodes, so referred to Fig. 6, the highest packet delivery ratio is obtained when \(N_{lp}\) is setting to 3, herein best links are used to route packets which minimizes preferred parent changes and DIO control messages, while the second one is related to the use of the multipath approach which significantly improves the network stability.

Energy consumption Figure 13 illustrates the total energy consumed by network nodes when transmitting control messages and data packets. Our multipath version of RPL achieves almost the same amount of the energy consumption as the standard RPL despite it allowing to deliver more video traffic than RPL without inducing too more DIO overhead. However, RPL wastes energy due to extensive retransmissions during the data transmission phase and the more frequently sent control packets each time a node changes its preferred parent (see Figs. 11 and 12).

Fig. 13
figure 13

Impact of priority level number on the network energy consumption

Full size image

Figure 14 represents the energy consumed per node during the entire simulation period. As expected, multipath routing helps to balance energy between network nodes more efficiently. All nodes in MP-RPL consume almost the same amount of energy which positively impacts the network lifetime. Unlike in RPL, where the distribution of the energy consumption is not well balanced between all nodes. The reason behind this result is that RPL selects a single path based on ETX metric without considering the nodes's energy consumption.

Fig. 14
figure 14

Energy consumption per node. For the sake of readability, other values of \(N_{pl}\) are not depicted here. Their energy consumption per node and their appearance are almost identical to those depicted in this figure according to the protocol type

Full size image

QoE metrics PSNR and SSIM metrics compare the received video to the original video frame by frame. Figures 15 and 16 illustrate the impact of varying the number of priority levels of an M-Frame on the video quality measured in terms of SSIM and PSNR metrics when using the two different routing approaches.

Fig. 15
figure 15

Impact of priority level number on video SSIM

Full size image
Fig. 16
figure 16

Impact of priority level number on video PSNR

Full size image

Again, the obtained results show that MP-RPL outperforms RPL and confirm the previous observations concerning the delivery packet ratio (Fig. 6). That is, when increasing the number of priority levels up to 3 in the case of MP-RPL (2 for RPL), the video quality is improved. However, beyond these threshold values, the video quality starts to decrease. Figure 15 depicts that for RPL, which performs poorly, the highest SSIM value is no more than 0.82 (at \(N_{pl} = 2\)), whereas when using MP-RPL, all obtained SSIM values are greater than 0.85. In particular, a maximum SSIM value equal to 0.91 is reached at \(N_{pl} = 3\), as confirmed by results shown in Fig. 17, where all the hall video frames have the best SSIM values with respect to other cases illustrated in Fig. 18. Figure 16 shows PSNR results of MP-RPL and RPL. At \(N_{pl}\) set to 3, MP-RPL has 27.78 dB, and RPL has 23.40 dB showing that MP-RPL presents a significant gain of 4.38 dB compared with RPL. Note that a higher gain of about 6.28 dB is achieved when \(N_{pl}\) is equal to 6, however, the video quality is not as better than the one obtained with the value 3. Because, at this later value, the higher packet delivery ratio obtained (see Fig. 6), in particular, the greater ratio of the more important video packets (M-packets) received at the sink (see Fig. 7) permitted to achieve maximum PSNR and SSIM values and therefore a better video quality.

Fig. 17
figure 17

Impact of priority level number on frame quality when \(N_{pl} = 3\) for MP-RPL and \(N_{pl} = 2\) for RPL. For these values, the measured PSNR and SSIM represent maximum values

Full size image
Fig. 18
figure 18

Impact of priority level number on frame quality in MP-RPL and RPL for other values of \(N_{pl}\)

Full size image

Table 6 provides more information and clearly shows that the best video quality obtained with MP-RPL when \(N_{pl} = 3\) is due to the observed high delivery ratio of video packets of different priorities, especially for packets of priority 0 (99.38% for P0), which represent the most important video data. That is, the more packets of priority 0 received successfully by the Sink the better is the video quality in terms of PSNR and SSIM.

Table 6 Packet delivery ratio per packet priority in MP-RPL
Full size table

Figure 19 (resp. Fig. 20) shows the achieved quality of frame number 5 (resp. 6) encoded as an M-Frame (resp. S-Frame) received at the sink node using multipath and single path routing techniques along with the reference frames sent by the source node, respectively (first images). We can notice and validate that the best video quality is obtained when the multipath routing approach is used compared to the mono-path routing technique. Specifically, setting \(N_{pl}\) at 3 gives the highest video quality in accordance with the MP-RPL results found above.

Fig. 19
figure 19

Showing of M-frame 5 with MP-RPL and RPL

Full size image
Fig. 20
figure 20

Showing of S-frame 6 with MP-RPL and RPL

Full size image

6.4 Discussion

Results obtained from extensive simulation experiments carried out allow us to formulate some findings, which we summarize as follows:

  • The significant benefit of combining the preferred multipath routing protocol MP-RPL with the ETX metric-based OF, where their collective advantages allow video traffic to be efficiently routed, leading to better video quality while reducing limitations of the ETX metric such as instability and load imbalance issues.

  • The use of the multipath routing protocol MP-RPL increases network stability, which means less control packets resulting in improved energy efficiency. That is, the energy expected to be consumed by the more frequent sending of DIO control messages will instead be consumed by the video packet transmissions.

  • MP-RPL ensures a balanced distribution of the energy consumption between all nodes allowing to extend the network lifetime not provided by the ETX-based single path.

  • The number of priority levels \(N_{pl}\) of an M-Frame directly influences the quality and reliability of the video while using MP-RPL. By properly tuning this parameter, the amount of data to be transmitted can be adapted to the network conditions. In particular, setting \(N_{pl}\) to 3 results in better transmission with less loss yielding a video delivery rate of about \(96.75\%\), and giving the user better video quality in the order of 27.8 dB as video traffic is dispatched over multiple routing paths.

7 Conclusion

In this paper, we presented a novel solution enhancing video transport over RPL based LLNs. It supports, at the same time, the video traffic and the multipath extension of RPL. Thanks to the multiparent feature natively offered by RPL, MP-RPL tries to establish multiple paths from the source node to the sink during the DODAG construction process, and based on the calculated cost of each path, it gets to select the most preferred routes with better quality for sending video traffic simultaneously to guarantee the multimedia bandwidth requirements. Besides, a lightweight codec SenseVid was used to encode/decode the video traffic. Simulation results show that, under varying the priority levels of the data to transmit, the use of the multipath routing approach along with the ETX based OF provides better network performance while distributing a load of video traffic between all established paths. This was found by evaluating and comparing the MP-RPL protocol with regards to RPL through well-known QoS and QoE performance metrics as well as showing video frames. Moreover, results also highlight that using the multipath technique helps to avoid the network instabilities from which the ETX-based single path RPL network suffers. In the future, we plan to focus more on the priority level of each packet according to the frame type to improve further the efficiency of the video delivery process in IoMT. In addition, we envisage evaluating the effectiveness of our proposal in a real testbed while varying the type of the sequence video.