Oana Iova

Gian Pietro Picco

Timofei Istomin

Csaba Kiraly

RPL, the Routing Standard for the Internet of Things . . . Or Is It?

Keywords: RPL, Internet of Things, routing, standards

RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks, is considered the de facto routing protocol for the Internet of Things (IoT). Since its standardization, RPL contributed to the advancement of communications in the world of tiny, embedded, networking devices, by providing, along with other standards, a baseline architecture for IoT. Several years later, we analyze the extent to which RPL lived up to the expectations defined by the IETF requirements, and tie our analysis to current trends, identifying the challenges RPL must face to remain on the forefront of IoT technology.

I. INTRODUCTION

RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks [START_REF] Winter | RPL: IPv6 routing protocol for low-power and lossy networks[END_REF], was standardized by the IETF in 2011 to establish a common ground for building interoperable commercial appliances in growing markets enabled by low-power and lossy networks (LLNs). Meanwhile, the Internet of Things (IoT) emerged, envisioning ubiquitous and global connectivity among the billions objects that we use in the everyday life.

Given the significant overlapping between LLNs and IoT, and the fact that IPv6 is an essential feature for the latter, RPL has rapidly become the routing protocol for IoT, incorporating the protocol stack defined by IETF in this scope, atop the IEEE 802.15.4 MAC and PHY layers (Figure 1a). The success of RPL as an IoT standard is also witnessed by the fact that the companies part of the ZigBee Alliance have adopted RPL as their underlying technology (Figure 1b). We provide a concise overview of RPL in Section II.

Nevertheless, the design goals behind RPL date back to the routing requirements determined by IETF in 2009 by considering the applications domains of home and building automation [START_REF] Brandt | Home automation routing requirements in low-power and lossy networks[END_REF], [START_REF] Martocci | Building automation routing requirements in low-power and lossy networks[END_REF] and of urban and industrial networks [START_REF] Dohler | Routing requirements for urban low-power and lossy networks[END_REF], [START_REF] Pister | Industrial routing requirements in low-power and lossy networks[END_REF]. After several years, it is important to ascertain the extent to which these requirements have been fulfilled by RPL; we offer our analysis of the state of the art in Section III.

A similarly important question, however, is whether RPL is well-prepared to sustain today's rapidly-evolving field of IoT, which defines slightly different scenarios from those examined by IETF in 2009. In Section IV, we identify a few specific challenges that RPL must face to remain on the forefront of IoT technology. Finally, Section V contains concluding remarks concerning the future of RPL.

Manuscript received September 14, 2016. Oana Iova, Timofei Istomin, and Gian Pietro Picco are with University of Trento, Italy (email: {oanateodora.iova, timofei.istomin, gianpietro.picco}@unitn.it. Csaba Kiraly is with Bruno Kessler Foundation, Italy (email: kiraly@fbk.eu).

II. RPL IN A NUTSHELL

As described in the standard [START_REF] Winter | RPL: IPv6 routing protocol for low-power and lossy networks[END_REF], RPL creates a routing topology in the form of a Destination-Oriented Directed Acyclic Graph (DODAG): a directed graph without cycles, oriented towards a root node, e.g., a border router. By default, each node maintains multiple parents towards the root; a preferred one is used for actually forwarding data packets upwards towards the root (Figure 2b), while the others are kept as backup routes. This scheme, called multipoint-to-point communication in RPL, naturally supports communication from the devices to the root with minimal routing state.

The topology is created and maintained via control packets called DODAG Information Objects (DIO), advertised by each node. The packet contains the routing metric (e.g., link quality, residual energy) and an objective function used by each node to select the parents among its neighbors. DIO packets are rebroadcast by each node according to an adaptive technique, the Trickle algorithm [START_REF] Levis | The Trickle Algorithm[END_REF], which strikes a tradeoff between reactivity to topology changes and energy efficiency. Trickle ensures that DIOs are advertised aggressively when the network is unstable, and instead rebroadcast at an increasingly slow pace while the network is stable.

To support the dual traffic pattern from the root to the devices, called point-to-multipoint communication in RPL, the standard requires additional control messages and routing state. Specifically, each node in the network must announce itself as a possible destination to the root by sending Destination Advertisement Object (DAO) control packets. These messages are propagated "upwards" in the DODAG topology, via a parent that may coincide with the preferred parent (Figure 2c), therefore establishing "downwards" routes along the way.

As supporting this type of traffic could put more strain on the nodes memory due to the increased routing state, RPL defines two modes of operation: storing and non-storing. In storing mode, each node keeps a routing table containing mappings between all destinations reachable via its sub-DODAG and their respective next-hop nodes, learned while receiving DAOs. In non-storing mode, the root is the only network node maintaining routing information; the root exploits this global view for source routing, i.e., by including routing information directly into the packet itself.

These two modes of operation affect also the ability to support communication between any two nodes in the network, called point-to-point communication in RPL, and achieved as a combination of the techniques used for the previous two types of traffic. In storing mode, data packets travel upwards until they reach a node with routing information about their destination, i.e., a common ancestor (Figure 2d); from that point on, they proceed downwards, following the routes previously established by DAO packets. The same technique is used in non-storing mode; however, in this case, packets must travel upwards all the way to the root (the only node maintaining routing information) before being redirected to their destination (Figure 2e).

III. DID RPL LIVE UP TO EXPECTATIONS?

RPL was standardized based on requirements published 7 years ago [START_REF] Winter | RPL: IPv6 routing protocol for low-power and lossy networks[END_REF], a relatively long time in the fast-paced world of networked computing in general and IoT in particular. This section revisits the original requirements for RPL stated by IETF, and concisely reports about the extent to which they are met by the state of the art. We frequently refer to the IETF documents that focused on the paradigmatic applications of home [START_REF] Brandt | Home automation routing requirements in low-power and lossy networks[END_REF] and building automation [START_REF] Martocci | Building automation routing requirements in low-power and lossy networks[END_REF], and urban [START_REF] Dohler | Routing requirements for urban low-power and lossy networks[END_REF] and industrial networks [START_REF] Pister | Industrial routing requirements in low-power and lossy networks[END_REF]. Due to space limitations, we focus on what we argue are the key dimensions, therefore omitting considerations on other relevant aspects, e.g., including zeroconfiguration or security.

A. Traffic pattern

Original requirements. RPL was designed to account for different traffic patterns characteristic of the aforementioned reference applications. Multipoint-to-point communication is required by devices with sensing capabilities, which typically monitor the environment by periodically acquiring samples of physical quantities (e.g., temperature, pollution, humidity) and send them to a central unit. Applications may also need the dual point-to-multipoint pattern where communication is directed from the central unit to the rest of the network. This is often required to send queries to sensors or, when a control loop is present, to send actuation commands-e.g., switching lights or activating window blinds in a smart home [START_REF] Brandt | Home automation routing requirements in low-power and lossy networks[END_REF]. This point-to-multipoint pattern may rely on multicast routing, which is actually a requirement in some reference scenarios [START_REF] Martocci | Building automation routing requirements in low-power and lossy networks[END_REF], [START_REF] Dohler | Routing requirements for urban low-power and lossy networks[END_REF]. Finally, in alternative to a centralized controller gathering data and issuing commands, devices might cooperate with each other in a decentralized fashion by relying on pointto-point communication; for instance, lamps and appliances may automatically change their own state or the state of other appliances based on information gathered by sensor nodes nearby.

The routing protocol should support communication: i) from devices to a central unit (multipoint-to-point)

ii) from the central unit to the rest of the network (point-to-multipoint) iii) directly among devices (point-to-point).

Current status. As we discussed in Section II, all three types of traffic patterns above are supported by the RPL standard, although it emphasizes multipoint-to-point communication, naturally supported by the DODAG routing topology. On the contrary, point-to-point communication is inherently costly, as shown in Figures 2d-2e; if two nodes want to communicate with each other, packets must be sent upwards either to the first common ancestor (in storing mode), or all the way up to the root (in non-storing mode), from where they are rerouted downwards to their destination. This strategy creates congestion close to the root and greatly increases overhead and latency, causing problems especially in use cases involving replies, e.g., a query result or a command outcome. In RPL, this is the price to pay for reconciling different patterns in a single protocol, yielding the benefit of broader applicability at the expense of optimal performance. These shortcomings motivated a new IETF standard protocol, Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (P2P-RPL), described in RFC 6697. This protocol is meant to complement RPL by allowing nodes to discover on demand routes to one or more nodes, via a temporary DODAG rooted at the node initiating communication. However, the efficiency of this combined solution is yet to be thoroughly studied.

As for multicast routing in point-to-multipoint communication, RPL supports it only in storing mode. Moreover, the standard only briefly describes how DAO messages should be used for group registration, without providing a full description of multicast operation. However, a complementary RFC 7731, Multicast Protocol for Low-Power and Lossy Networks (MPL), has been recently standardized, defining multicast operation atop two protocols: Trickle and plain flooding. Evaluations in simulation (e.g., [START_REF] Clausen | Performance analysis of Trickle as a flooding mechanism[END_REF]) show that MPL is highly reliable, but can have high delay and energy consumption if Trickle parameters are not chosen carefully.

RPL supports all types of communication. However, for an efficient point-to-point communication and multicast routing, complementary RFCs must be implemented, increasing code complexity and memory footprint.

B. Mobility

Original requirements. In all the motivating scenarios analyzed by IETF it is foreseen that, although devices are currently mostly fixed, a variety of devices with reduced mobility (e.g., remote controls, vacuum cleaner robots, wearable healthcare devices) should be accommodated by RPL. Moreover, it is stated that industrial applications require the support of nodes located on vehicles or machines moving at speeds up to 35 km/h [START_REF] Pister | Industrial routing requirements in low-power and lossy networks[END_REF]. Devices should not act as routers while in motion; on the other hand, they should reestablish end-to-end communication with a static device within 5 s [START_REF] Martocci | Building automation routing requirements in low-power and lossy networks[END_REF].

The routing protocol should allow devices that are moving to connect to the static routing topology.

Current status. The requirement above is fulfilled by RPL by allowing a mobile node to attach as a leaf to any node belonging to the routing topology. Communication from the mobile node to the root is in principle quite straightforward, as the former only requires a preferred parent, which may as well be the point of attachment. Point-to-multipoint communication, instead, is more complex; as the mobile node moves from a parent to another, information disseminated via DAOs may rapidly become obsolete. Solutions for this case are not specified in the standard nor, to the best of our knowledge, realized in publicly-available reference implementations. Moreover, the under-specification in the standard is a problem also for multipoint-to-point; recent studies (e.g., [START_REF] Cobarzan | Analysis and performance evaluation of RPL under mobility[END_REF]) show that currently implemented RPL mechanisms fail to rapidly detect when the preferred parent of a mobile node becomes unreachable as it moves, leading to high packet loss.

RPL allows a mobile node to attach/detach to/from the routing topology, but communication becomes highly unreliable.

C. Resource Heterogeneity

Original requirements. The devices targeted by RPL range from low-end battery-powered embedded devices severely constrained in memory and processing capabilities, up to highend devices like smart watches or smartphones. This is in line with the reference scenarios; for example, home automation devices range from dumb, resource-constrained smoke alarms and temperature sensors to high-resource surveillance cameras. This diversity in hardware capabilities and application scenarios should be accounted for at the network layer. On the other hand, resource-constrained devices are envisioned to constitute the majority of network nodes; the need to limit battery replacement sets a lifetime goal of several years.

The routing protocol must take into account the heterogeneity of devices, and specifically address the memory and energy requirements of resource-constrained devices.

Current status. As mentioned in Section II, RPL defines two modes-storing and non-storing-meant to address different resource capabilities of the network nodes. However, the RPL standard does not allow these two modes of operation to be mixed in the same network, severely undermining their practical use. Research solutions allowing nodes with different modes to operate in the same RPL network exist (e.g., [START_REF] Ko | DualMOP-RPL: Supporting multiple modes of downward routing in a single RPL network[END_REF]) but are yet to be standardized.

Even if this problem were to be solved, however, another threat to memory-constrained devices comes from the protocol footprint. RPL inherits the interoperability benefits of IPv6, but also its complexity; for instance, the need to construct and parse IPv6 packets with floating header options and using 6LoWPAN address compression increases significantly code memory needs. This is evident in that RPL requires almost twice the memory than a collection tree protocol [START_REF] Gnawali | Collection tree protocol[END_REF]; the latter provides only multipointto-point communication, but it can be combined with the Trickle dissemination protocol (providing point-to-multipoint communication) by only marginally increasing the footprint, remaining significantly smaller than in RPL. On the popular TMote Sky platform, the footprint of RPL and of the variants discussed in Section III-A is very close to the 48 kB limit for code memory, leaving almost no memory to the applicationdespite the fact that these RPL implementations are far from supporting all the features specified in the RPL standard. Code memory is not even the most severe problem; for example, in the Contiki implementation the 10 kB RAM of a TMote Sky limits the neighbor and routing tables to 20 and 50 entries, respectively, severely limiting scalability as discussed next.

RPL has too large of a footprint for resource-constrained devices, and requires all devices in a network to run the same mode of operation, limiting heterogeneity.

D. Scalability

Original requirements. Scalability is a very important characteristic of a routing protocol, bearing a direct impact on network reliability and performance. The applications studied by IETF have different scalability requirements, depending on the area where networks are deployed. For example, in home automation the routing protocol must support at least 250 devices, with larger numbers envisioned in the future [START_REF] Brandt | Home automation routing requirements in low-power and lossy networks[END_REF]. Other scenarios imply even higher numbers of deployed devices; in smart cities, networks of 10 2 -10 7 nodes are envisioned, possibly organized into regions containing 10 2 -10 4 devices each [START_REF] Dohler | Routing requirements for urban low-power and lossy networks[END_REF]. While these numbers are very large, and unprecedented in the roll-outs prior to the issuing of the RPL standard, they align with deployment experiences 1 and projected trends 2 .

The routing protocol should support very large networks, possibly organized in sub-networks up to thousands devices.

Current status. Recent real-world evaluations [START_REF] Duquennoy | Let the tree bloom: Scalable opportunistic routing with ORPL[END_REF] show that the scalability of multipoint-to-point communication is quite 1 For instance, e.g., http://www.smartsantander.eu 2 An example are the recent statements by several companies about tens of billions of devices connected by the IoT in the near future. q q q q q q q q q q q q q 0.0 good. It does, however, become questionable when unicast point-to-multipoint communication is used. In non-storing mode, the limiting factor is the size of the packet header containing the source routing information; this can include up to 8 IPv6 addresses (64 with a compressed header), but the longer the header the higher the overhead and the route repair latency. The impact on scalability, however, has yet to be evaluated; non-storing mode has been introduced only very recently in Contiki, and is currently not supported by TinyOS or industrial implementations (e.g., from Cisco3 ).

In storing mode, instead, the limiting factor is the memory available to store neighbor and routing tables. The nodes close to the root must store routing state for almost the entire DODAG, which can be challenging for resource-constrained devices. Moreover, the RPL standard does not specify the action to take after a parent refuses to install a new downward route (e.g., because its routing table is full), therefore undermining the reliability of downward traffic. We recently analyzed the problem in our own work, where we focused on emulation of the Contiki RPL implementation over realistic topologies taken from a smart city deployment [START_REF] Istomin | Is RPL ready for actuation? a comparative evaluation in a smart city scenario[END_REF]. Figure 3 illustrates the problem: the reliability of downward traffic (e.g., for actuation) decreases severely as soon as the size of the network approaches the size of the routing table, which we set to 50 entries-the maximum allowed on TMote Sky, as already discussed. In practice, even for devices slightly more powerful than motes, this means that the scalability of RPL remains a far cry from the thousands of nodes mentioned above.

Until now we considered a flat address space. However, RPL can support prefix-based hierarchical routing, e.g., via the Prefix Information Option (PIO) mechanism, which allows routers to own an independent prefix and distribute it for autoconfiguration in their own sub-DODAG. However, the prefix assignment is not part of the standard, and can lead to performance deterioration [START_REF] Ancillotti | On the interplay between RPL and address autoconfiguration protocols in LLNs[END_REF].

RPL has serious scalability issues with point-to-multipoint traffic, especially when configured in storing mode. Prefix-based sub-netting can alleviate the problem, but requires better integration with RPL topology maintenance.

E. Reliability and Robustness

Original requirements. The quality of radio links among devices can be very unstable, especially in an urban setting, due to wireless channel effects (path loss, shadowing, fading), and interference from other communication systems. It is important for the routing protocol to react to changes in connectivity by rapidly reconfiguring the topology while maintaining a low control overhead and therefore energy expenditure. Specific metrics are stated for some of the reference scenarios considered; for instance, in home automation, the routing protocol is expected to converge within 0.5 s if no nodes have moved, and within 4 s otherwise [START_REF] Brandt | Home automation routing requirements in low-power and lossy networks[END_REF].

Clearly, changes in connectivity ultimately affect communication reliability, whose critical role depends on the target application and functionality. For instance, it is expected that monitoring-only applications can tolerate a reliability as low as 90% [START_REF] Pister | Industrial routing requirements in low-power and lossy networks[END_REF], while those involving actuation require higher reliability [START_REF] Martocci | Building automation routing requirements in low-power and lossy networks[END_REF]; in some application domains, message loss is even considered out of compliance and subject to fines [START_REF] Pister | Industrial routing requirements in low-power and lossy networks[END_REF], requiring a reliability very close to 100%.

The routing protocol should be robust w.r.t. the inherent dynamicity of wireless links, quickly restoring communication to maintain high levels of reliability; some applications cannot afford data loss.

Current status. RPL relies on the Trickle algorithm [START_REF] Levis | The Trickle Algorithm[END_REF] to efficiently maintain the routing topology, enabling quick reaction to connectivity changes while minimizing overhead during stable conditions. Nevertheless, when a link quality metric is used for routing, even small variations in link quality estimation can yield changes of preferred parent, as the objective function constantly searches for the best path towards the root; the consequent reaction of the Trickle algorithm generates unnecessary overhead.

The IETF addressed the problem in RFC 6719, Minimum Rank with Hysteresis Objective Function (MRHOF), allowing a node to change its parent only when the new path towards the root differs significantly from the old one. The latter aspect is defined by a threshold, yielding a tradeoff between route stability and optimality; if the threshold is too high, parents are less likely to change and routes are more stable, but their quality may degrade significantly before they are reconfigured. The proper configuration of the threshold is therefore nontrivial, and not well investigated in the literature.

On the other hand, the overall reliability of RPL has been analyzed by several studies in real-world testbeds. A large 135-node experiment [START_REF] Duquennoy | Let the tree bloom: Scalable opportunistic routing with ORPL[END_REF] showed values of 97% and 92% of delivered packets for the multipoint-to-point and pointto-multipoint traffic respectively, while the most challenging point-to-point traffic showed a very low reliability of 74%, due to scalability problems. For the last two traffic patterns, the authors even had to reduce by half the number of addressable nodes in the network for the routing tables to fit into the RAM, due to the aforementioned memory problems.

For multipoint-to-point traffic, RPL mechanisms deal effectively with the vagaries of wireless communication and yield good performance and reliability; the other two traffic patterns suffer from poor reliability.

IV. RPL FOR IOT: THE CHALLENGES AHEAD

Having examined how RPL fares w.r.t. its original requirements, we now turn our attention to current IoT trends and identify new requirements that may challenge future adoption of RPL as the routing protocol for IoT.

A. What Will Be the Dominant Traffic Pattern?

At the time of RPL standardization, multipoint-to-point communication was the main traffic pattern, motivated by the need to support distributed monitoring applications, and fueled by a decade of research on wireless sensor networks.

Today, monitoring is still a fundamental element of IoT architectures, but it is increasingly associated with control in a plethora of application domains. In its simplest incarnation, control entails the ability to send commands (e.g., for actuation) from a centralized controller via the same network used for monitoring; however, the most disruptive scenarios envision devices that interact and automatically take actions via in-network feedback loops. As a consequence, point-tomultipoint and point-to-point communication become even more critical than multipoint-to-point.

These two traffic patterns are addressed by RPL, which actually has a competitive advantage as it supports the networking requirements of both monitoring and control i) in an integrated fashion, and ii) in a large-scale setting. Unfortunately, as discussed in Section III, these are exactly the traffic patterns for which RPL does not provide efficient solutions. Paradoxically, they are also the paradigms for which the integration with IP is key, as it enables direct addressing of each device.

Point-to-multipoint and point-to-point communication received significantly less attention in RPL, yielding implementations with poor performance; this may prevent future adoption of RPL in the ever-increasing

IoT applications with a control component.

B. Mobile Devices: Norm or Exception?

Scenarios for IoT assume devices embedded in things, which can be relocated (e.g., in asset tracking), or carried and even worn by people, and therefore inherently mobile. In these ever-increasing mobile scenarios, the ability to opportunistically exploit the presence of a networking "backbone" to relay information regardless of the current location is fundamental, yet is largely overlooked by RPL, as discussed in Section III-B.

Moreover, mobility often implies the need for context-aware interactions; for instance, the scope of a query or command issued by a node may need to be restricted to only a portion of the network surrounding it, based on system or application level properties (e.g., the floor building where the person carrying the device is walking).

Mobility is an unavoidable requirement in IoT scenarios, for which RPL currently provides unsatisfactory performance; further developments should also consider support for context-aware routing.

C. Resource-constrained Devices: Norm or Exception?

The devices enabling the IoT vision are inherently resourceconstrained. This is unlikely to change in the future; technological developments will push the boundary of computing and communication power for the devices we know today, but at the same time generate new breeds of devices even smaller and therefore resource-constrained-a recurring trend in the last decades.

In this respect, the current demands of RPL in terms of code and data memory are still too high. In part, this is a consequence of IPv6 compliance. However, it is also the result of a standard that simply addresses (and requires) too much and, ironically, of implementations that neglect the few opportunities the standard allows to explicitly cater for resource-constrained devices-e.g., notably including nonstoring mode. Specialized RPL variants must be devised, guaranteeing a better tradeoff between performance and flexibility and allowing the selection of the appropriate protocol components or variants based on the device (and application) constraints at hand.

Resource-constrained devices are here to stay. However, the current definition of RPL is often at odds with the requirements they pose, and the implementations are often ignoring the few provisions the standard already offers to ameliorate the situation.

D. New Approaches to Network Stack Design

When the RPL standard was in the making, the predominant routing approach was incarnated by the CTP protocol [START_REF] Gnawali | Collection tree protocol[END_REF], from which RPL borrows several techniques. Around the time the standard was issued, however, two alternative routing paradigms emerged in the closely-related wireless sensor network research community: opportunistic routing and synchronous transmissions. The former approach, popularized by ORW [START_REF] Landsiedel | Low Power, Low Delay: Opportunistic Routing meets Duty Cycling[END_REF], considers all neighbors as potential forwarders, therefore reducing delay and energy consumption and increasing robustness by exploiting spatial diversity. The second approach, popularized by Glossy [START_REF] Ferrari | Efficient Network Flooding and Time Synchronization with Glossy[END_REF], removes completely the need for a routing (and MAC) layer, by providing a reliable network flooding primitive; reliability is achieved by guaranteeing that rebroadcasting occurs within a very short time bound necessary to exploit constructive interference and the capture effect, and yielding also network-wide time synchronization.

Both approaches are reported to significantly improve over the state of the art, in terms of reliability, latency, and energy consumption. Opportunistic routing has already inspired a RPL variant [START_REF] Duquennoy | Let the tree bloom: Scalable opportunistic routing with ORPL[END_REF] aimed at improving downward traffic; this is not yet the case for synchronous transmissions, whose even higher performance gains are currently obtained in networks of homogeneous devices using the same radio chip [START_REF] Ferrari | Efficient Network Flooding and Time Synchronization with Glossy[END_REF].

New approaches with significantly better performance have emerged since the RPL standard was defined, and should therefore receive attention.

E. New Wireless Technology

The new scenarios fostered by IoT motivated the development of new wireless technology tackling lower power consumption, increased range, or both. Some of these, e.g., Wi-Fi HaLow (IEEE 802.11ah), are a natural evolution of existing technologies, and likely to be easily accommodated into RPL. At the other extreme, Low-Power Wide-Area Networks (LP-WANs) hold the potential to radically change the picture of IoT networking as currently defined by RPL. With a low-power budget similar to IEEE 802.15.4 devices, LPWANs provide long-range communication (2-5 km in urban environments, 30 km and higher otherwise) at the price of reduced bandwidth and data rates. At a minimum, LPWANs are likely to become an inescapable alternative for interconnecting different subnetworks at a geographical scale; however, they also hold the potential to induce a rethinking of multi-hop routing strategies. In between these extremes, IoT technologies hitherto applied mostly on consumer appliances are being optimized for ultra low-power consumption, as in the case of Bluetooth Low Energy (BLE), therefore becoming an appealing alternative for fulfilling goals similar to RPL.

The scenarios fostered by IoT are triggering a new wave of wireless technologies that can significantly redefine the goals, and therefore the mechanisms, of RPL.

V. WHAT FUTURE FOR RPL?

In this paper we analyzed the extent to which the RPL standard lived up to the expectations defined by IETF requirements, and highlighted other challenges that emerged since its definition as a standard. RPL had its quota of successes, clearly contributing to the advancement of communications in the world of tiny, embedded, networking devices.

The concise analysis we provided in this paper, however, also highlighted several weaknesses that, in our opinion, may undermine a larger IoT adoption of RPL. The complexity of today's IoT makes it difficult for a single standard to paper over the significant differences in application requirements and heterogeneity in hardware constraints, both likely to be exacerbated in the near future.

We argue that, to remain successful in the IoT domain, RPL needs a re-targeting. For example, RPL could become a general standard framework, providing the "glue" for a suite of inter-related standards, each focused on specific communication technologies and/or application profiles. Together, the framework and the specific standards would provide interoperable alternatives for composing the network stack most suitable for the application at hand, therefore balancing the desire to support a broad range of features with the efficiency necessary when a vertical domain is tackled.

In part, this effort is already ongoing, as witnessed by the definition of the ancillary standards we mentioned in Section III. However, standardization bodies must keep up with the latest developments and trends, and accordingly recharter the respective working groups (e.g., IETF ROLL), in an effort to create a "standard ecosystem" around RPL and weave it into state-of-the-art approaches from related research communities.

Fig. 1 :Fig. 2 :

 12 Fig. 1: Protocol stacks for the Internet of Things.

Fig. 3 :

 3 Fig.3: As network size increases, the reliability of downward traffic decreases, as a consequence of more nodes having memory problems.

TABLE I :

 I Table I, which compares the RPL implementations for TinyOS and Contiki, the most popular operating systems for low-power devices, with some wellknown wireless sensor network protocols. The table shows Code memory requirements (OS included), in kB.

	Protocol name	Contiki TinyOS
	Collection tree	25.2	17.5
	Trickle	21.2	14.2
	Collection tree + Trickle	26.0	23.0
	AODV	23.4	-
	RPL	42.9	32.8
	RPL + MPL	46.4	-
	P2P-RPL	44.2	-

RPL configuration guide for Cisco IOS, http://www.cisco.com/c/en/us/ td/docs/ios-xml/ios/rpl/configuration/15-mt/rpl-15-mt-book.pdf.

DATA DATA DATA DATA DATA (b) Multipoint-to-point communication. DATA (B,B),(C,C),(D,B) (E,B),(F,C) DATA DATA DATA (e) Point-to-point communication: non storing mode.

BIOGRAPHIES

Oana Iova is a postdoctoral researcher at the University of Trento. Her research is in creating energy-efficient wireless systems for Internet of Things applications using as building blocks both emerging wide-area wireless communication


N Hammouda

G Habchi

C Barthod

J Lottin

O Duverger
email: olivier.duverger@cetim.fr

Implementation of a methodology for evaluation of the reliability of mechatronic systems

Keywords: methodology, reliability, mechatronics system, modeling, simulation, qualitative and quantitative analysis, interactions, mission profile I

Reliability is one of the most important parameters of dependability. It is addressed whenever we want reliable, available and safe systems. Indeed, reliability acts on the availability and security of systems. It must be considered throughout the overall life cycle of the product or system (design, manufacturing, operation). The objective of this communication is to build an overall approach of reliability for mechatronic systems since they are complex and multi-technology integrating several properties such as: dynamic, hybrid, reconfigurable, and interactive.

INTRODUCTION

The development of mechatronic systems over the past twenty years can be considered as a revolution for the industry. The use of these systems is widespread fast and now affects almost all sectors of industry. Before addressing the "reliability" is the central theme of this paper, let's take a ride background to identify what the literature meant by the term "Mechatronics". Indeed, several definitions exist. Let's quote the main non-exhaustive. Mechatronics International Journal published a definition of this word for the first time in 1991: "Mechatronics in its fundamental form can be regarded as the fusion of mechanical and electrical disciplines in modern engineering process. It is a relatively new concept to the design of systems, devices and products aimed at achieving optimal balance between year basic mechanical structures and its overall control" [START_REF] Daniel | [END_REF]. In 1996, the international journal IEEE Transactions on Mechatronics defined it as followed: "Mechatronics is the synergetic combination of mechanical engineering with electronics and intelligent computer control in the design and manufacturing of industrial products and processes" [START_REF] Commault | Disturbance rejection for structured systems[END_REF]. The IFAC Technical Committee on Mechatronic Systems chose the following definition in 2000: "Many technical processes and products in the area of mechanical and electrical engineering show an increasing integration of mechanics with electronics and information processing. This integration is between the components (hardware) and the information driven function (software), resulting and in integrated systems called expired mechatronic systems" [START_REF] Villemeur | Safe operation of industrial systems[END_REF].

According to standard NF E-010, mechatronics is defined as an "approach to integration synergy of mechanics, electronics, automation and information technology in the design and manufacture of a product to increase and / or optimize its functionality " [START_REF] Afnor | Mechatronics -vocabulary[END_REF].

From these various approaches, we proposed to define mechatronic systems as systems that are characterized by its kind of behaviour: hybrid, dynamic, reconfigurable and interactive i.e. by the existence of interactions between the various components that may be due in part to the integration of several technologies. Hybrid systems are systems characterized by the presence of continuous phenomena and discrete event [START_REF] Verron | Diagnosis and monitoring of complex processes by Bayesian networks[END_REF]. Dynamical systems are characterized by functional relationships between components that constitute them. If these relations remain frozen throughout the mission system, the system is said to be static. If, however, these relationships change during the mission, the system is said to be dynamic [START_REF] Villemeur | Safe operation of industrial systems[END_REF]. The interactive nature of a system is defined by the existence of physical and/or functional interactions between the components of the system. Finally, reconfigurable systems are systems that can change their internal structures to ensure the realization of the function [START_REF] Villemeur | Safe operation of industrial systems[END_REF]. All these characteristics must be taken into account when developing the methodology to estimate the reliability of these systems.

One of the major problems encountered during the design phase of mechatronic systems is the evaluation of the reliability using an overall approach that takes into account all system technologies and cultures of the organization. Indeed, although the existing methods related to the field of reliability are numerous, they are mainly dedicated to electronic and mechanical technologies, but rarely for the software. But more importantly, they are applied independently to these technologies and related components without considering the integration synergy for product as a whole. In recent years, few studies have addressed this scientific theme; we cite two main theses treated assessing the reliability of mechatronic systems by A.Demri [START_REF] Demri | Contribution to the assessment of the reliability of a mechatronic system by functional and dysfunctional modeling[END_REF] and A.Mihalache [START_REF] Mihalache | Modeling and evaluation of the reliability of mechatronic systems: application on embedded system[END_REF]. A. Mihalache has developed a methodology to evaluate the reliability prediction, experimental and operational while A. Demri focused only on reliability prediction taking into account the dynamic of these systems. Although this work is important for the scientific community, they still ignored the other characters such as reconfigurable, hybrid or interactive who are, our sense, essential characteristics and necessary to evaluate the reliability of mechatronic systems. At present, despite the work made over the last decade, there is no knowledge for an overall approach studying the reliability of a mechatronic system and taking into account all the characters mentioned before and the interactions generated between the different technological areas. In addition, due to the complexity of the study area, the gaps in this field are numerous and affect many aspects: many scattering methods, several different technologies, different phases in the life of the system, regardless of the qualitative and quantitative aspects, diversity of available scientific tools, study objectives, etc.

It is on this issue that we propose an overall approach studying the reliability of mechatronic systems during the design phase while taking into account the different characters, the interactions between the different technologies, and the needs of the industrial sector.

The paper is organized as follows. First, we present in Section II the proposed methodology for evaluation of the predictive reliability. Paragraphs A to G detail the different steps of this methodology. Finally, in Section III we propose a conclusion for this work.

II. METHODOLOGY FOR EVALUATION THE PREDICTIVE

RELIABILITY OF MECHATRONIC SYSTEMS

The proposed methodology of the predictive reliability of mechatronic systems must take into account the following points:

-The intrinsic characteristics of mechatronic systems (dynamic, hybrid, reconfigurable, multi-technology, interactive)

-The mission profile -Expert opinion -Qualitative analysis (functional, organic and dysfunctional analysis, functional and dysfunctional modelling)

-Quantitative analysis (modelling and simulation)

-The study of the system reliability, sub-systems and components -The lack of reliability in the industrial sector (especially technological interactions)

Figure 1 present the proposed methodology with steps to evaluate the predictive reliability of mechatronic systems. We describe in the following paragraphs the main steps of this methodology. The external functional analysis illustrates the relationship between the system and its environment. The external functional analysis is built according to the following steps:

A. External functional analysis

• Identification of the elements of the external environment

• Identification of the main functions and constraints (Octopus Diagram)

• Characterization of the main functions and constraints (thermal characteristics, electrical, mechanical, etc.).

• Definition of the mission profile of the system After this analysis, the application of an internal functional analysis is necessary to determine the internal functions of the system.

External functional analysis

Internal functional analysis

Organic analysis

Dysfunctional analysis

Qualitative modeling Data gathering and processing

Modeling and simulation

Analysis of simulation results

Qualitative Analysis

Quantitative Analysis

External functional analysis

Inputs: Expression of need

Outputs: Main functions and constraints

Objective: Relations between the system and its environment The internal functional analysis identifies the internal functions that are necessary to achieve the main functions of the system. There are several methods to achieve this analysis: we include for example, SADT, FAST, SysML, Functional tree, etc. The objective of the organic analysis is to define the architecture of the system, the decomposition into sub-systems and components and the identification of the interactions between the different elements of the system.

B. Internal functional analysis

C. Organic analysis

We define the term "interaction" as the dependence between the elements of the system causing a change in the system reliability. The interaction can be functional or collateral.

Organic analysis is built according to the following steps:

• Definition of the components associated with internal functions (internal functional analysis)

• Building of the organic system architecture

• Decomposition of the system into sub-systems and components

• Identification of the functional interactions between the components of the system (functional interactions matrix)

• Identification of the collateral interactions between the components of the system (physical location of the components) The objective of this step is to identify the dysfunctional failure modes and degradation of the system components and to analyze their effects on the system. To achieve the dysfunctional analysis, the outputs of functional and organic analyzes are needed. In other words, the outputs of functional and organic analyzes are the inputs of dysfunctional analysis.

D. Dysfunctional analysis

The main methods used in a dysfunctional analysis are: the Preliminary Risk Analysis (PRA), Failure Modes, Effects and Criticality Analysis (FMECA), Analysis of the Effects of Software errors (AEEL), Trees Failures (ADD), etc [START_REF] Mihalache | Modeling and evaluation of the reliability of mechatronic systems: application on embedded system[END_REF]. The majority of these methods are adapted only to the hardware (mechanical, electronic, etc.); yet the AEEL is an equivalent of the FMECA that fits perfectly to the software part. The combination of these two techniques (FMECA + AEEL) can process the dysfunctional analysis of a mechatronic system.

For FMECA, we can add a column that specifies the type of damage (intrinsic, collateral or functional) and therefore information about its nature (first or second), in order to take into account the interactions between the components of the system. The objective of the qualitative analysis is to model the functional and dysfunctional behaviours of the system and its components. To achieve this analysis, we rely on the various analyzes carried out previously into the different steps of the Inputs: Interactions between the system and its environment Description of the system internal functions System Architecture and Interactions between the elements of the system Outputs: Failure modes, their causes and their effects on the system Objective: Failure modes and effects

E. Qualitative modelling

Qualitative modelling

Inputs: Interactions between the system and its environment Description of the system internal functions System Architecture and nteractions between the elements of the system Failure modes, their causes and their effects on the system Outputs: Functional and dysfunctional models

Objective: functional and dysfunctional behavior of the system

Organic analysis

Inputs: Interactions between the system and its environment Description of the internal system functions Outputs: System decomposition into sub-systems and components. Identification of interactions between the elements of the system Objective: System Architecture proposed approach and particularly functional, dysfunctional and organic analysis. The study of the FMECA method, enhanced by the classification of failure modes of components depending on their nature (first or second), their speed event (sudden, progressive) and their amplitude (partial or complete) allowed us to introduce new failure modes and additional states. Indeed, the failure modes commonly used in modelling are intrinsic failure modes of components (failure of first type as classified by nature). To take into account the interactions inducing collateral damage, the failure modes of second type must be added.

There are several methods that seem to be adapted for modelling mechatronic systems. We can mention: Petri nets [START_REF] Moncelet | Application of Petri nets to evaluate the dependability of mechatronic systems in the automotive world[END_REF], Markov chains [START_REF] Villemeur | Safe operation of industrial systems[END_REF], dynamic Bayesian networks (DBN) [START_REF] Verron | Diagnosis and monitoring of complex processes by Bayesian networks[END_REF], neural networks [START_REF] Piechowiak | Artificial intelligence and diagnosis[END_REF], etc.

The most appropriate methods for modelling mechatronic systems are state-transition models such as state graphs (Markov graphs, Bayesian networks) and approaches based on Petri nets [START_REF] Medjoudj | Contribution to the analysis of systems controlled by computers: Extraction scenarios feared and verification of time constraints[END_REF]. In this study, we chose to use Petri nets because they allow:

-The modelling of mechatronic systems integrating different technologies -

The use in each stage of the development cycle -

The analysis of functional and dysfunctional behaviour -The modelling of continuous and discrete events (hybrid systems) -Taking into account the dynamic behaviour of the system -The modification of their internal structures ( reconfigurability) -

The specification of interactions between the components.

One of the drawbacks of Petri nets could limit its application in industry due to the lack of use.

To illustrate the use of Petri nets, let's imagine a system where a bearing and a coil are placed so that a collateral interaction exists between them, due to the bearing heating after 6 millions operating cycles [START_REF] Chouket | Implementation of a methodology for evaluation of the reliability of mechatronic system[END_REF]. Figure 7 presents the functional and dysfunctional model of the coil.

Fig. 7: Functional and dysfunctional model of the coil [START_REF] Chouket | Implementation of a methodology for evaluation of the reliability of mechatronic system[END_REF] To model the coil, we considered three states (functioning, degraded and failure), failure mode (intrinsic failure) and a repair mode (repair failure). When the coil is considered alone, the degraded state does not appear because it is induced by the interaction bearing / coil. The interaction is not considered in this first model, the transition from one operating state to a fault state occurs only following the occurrence of the failure mode "intrinsic failure". The mode "repair failure" allows you to operate the coil again. To model the bearing, we considered three states (functioning, degraded and failure), three failure modes (intrinsic failure, wear level 0, and wear level 1) and two modes of repair (repair failure and repair degraded).

Figure 9 presents the functional and dysfunctional model of the guide bearing and the coil taking into account the interaction Bearing /Coil. The degraded state of the bearing has a direct impact on the functioning of the coil. Indeed, for a temperature higher than the nominal temperature (for example 120 °C), reached due to overheating of the bearing in degraded mode, the operation of the coil becomes abnormal (coil degraded state). Over time the degraded state of the coil will induce a failure of the latter due to its overheating. Taking into account the interaction between the two components, it was necessary to define new states and failure modes: a state of partial amplitude called "coil degraded" and two failure modes second called "bearing heating" and "failure by heating." The state "bearing degraded" induces the heating of the bearing that will put the coil in the state "coil degraded."

The "repair degraded" mode of the bearing resets the operating mode of the coil and of the bearing. The state "failure by heating" of the coil is a mode so that complete degradation thereof leads to a fault state.

F.

Gathering and processing of data for the components The objective of this step of the methodology is to identify the laws of reliability associated with the components and then to gather and process the data in order to calculate their parameters. The most databases used for electronic components are FIDES, MIL-HDBK 217F, and RDF 2000. We are interested in our approach to FIDES model that can take into account the mission profile of the product.

Calculating the failure rate of electronic components using FIDES database

The expression of the failure rate depends on several factors: design technology, manufacturing technology and environmental operation of the component. Then, according to FIDES, the failure rate depends on a basic failure rate of component, weighted by factors of technology, design, manufacture, use, environment, etc. [START_REF] Airbus | Nexter Electronics[END_REF]. The failure rate according to FIDES can be written as follows: The method for calculating the failure rate of electronic components according to FIDES includes three steps:

-Defining the mission profile (phases, duration, temperature, humidity, vibration, etc.) -Calculating the values of ∏ factors (∏ process , ∏ PM , ∏ placement , C sensitivity , ∏ application, ∏ ruggedising, ∏ RF-HF, ∏ H-M, ∏ LF ) -Calculating the failure rates (EASYREL tool for example) The objective of this step is to estimate the reliability for the system and its components over the time of use and according to the mission profile of the system. Two methods are used:

G. Modelling and simulation

-Petri Nets for behavioural modelling (functional and dysfunctional) and Monte Carlo simulation for convergence of results. -Modified Reliability Block Diagrams, adapted in order to take into account the mission profile and the considered interactions for exact calculation.

The comparison of the results obtained by the two methods is necessary to verify and validate on the one hand, the model of Petri nets and the parameters chosen for simulation, and on the other hand, the calculation method developed in the context of reliability block diagrams considering the mission profile and interactions.

The modelling and simulation are organized according to the following three steps:

-Implementation of the quantitative models according to the qualitative analysis, -Considering of reliability laws for components and their parameters (models without interaction), -Considering and modelling of the interactions and their hypothesis (models with interaction).

III. CONCLUSION

In this article, we analyzed some of the problems associated with the reliability of mechatronic systems and we proposed an overall methodology evaluating the predictive reliability that takes into account the specificities of these systems.

To evaluate the predictive reliability of a mechatronic system, it is necessary to have a model because the system does not exist at this stage of the development and cannot be physically tested. That is why the first part of the proposed methodology is a qualitative analysis that provides all the necessary information on the functioning and malfunctioning of a mechatronic system. The second part of the methodology is a quantitative analysis to estimate and quantify the reliability of the mechatronic system.

We validated this methodology through industrial mechatronic examples. These examples are selected in collaboration with our partner CETIM which has very close relations with many companies working in the field of mechatronics. Also, we deepened our analysis on more theoretical questions, to respond in particular to the problems of specification and modelling, collateral and functional interactions in terms of reliability and to evaluate the influence of the mission profile of the distribution laws for component reliability.

Fig. 1 :

 1 Fig. 1: Overall Methodology evaluating the predictive reliability of mechatronic systems.

Fig. 2 :

 2 Fig. 2: External functional analysis

Fig. 3 :

 3 Fig. 3: Internal functional analysis

Fig. 4 :

 4 Fig. 4: Organic analysis

Fig. 5 :

 5 Fig. 5: Dysfunctional analysis

Fig. 6 :

 6 Fig. 6: Qualitative modelling

Figure 8

 8 Figure 8 presents the functional and dysfunctional model of the guide bearing.

Fig. 8 :

 8 Fig.8: Functional and dysfunctional model of the bearing[START_REF] Chouket | Implementation of a methodology for evaluation of the reliability of mechatronic system[END_REF]

Fig. 9 :

 9 Fig.9: Functional and dysfunctional model of the bearing and the coil[START_REF] Chouket | Implementation of a methodology for evaluation of the reliability of mechatronic system[END_REF]

Fig. 10 :

 10 Fig. 10: Gathering and processing of the data for the components

  that depends on the dynamic structure of the program p: Number of executions per time unit N 0 : Initial number of faults in the program

λ

  = λ Physical *Π Part_Manufacturing * Π Process * Π RF-HF * Π H-M * Π LF Where λ: Predicted failure rate; λ Physical : Represents the physical contribution; Π Part_Manufacturing : Reflects the quality and technical control of component manufacturing; Π process : Reflects the quality and technical control of the processes of developing, manufacturing and use of products containing the component; Π RF-HF : Reflects the quality and control of the life cycle of the product radiofrequency (RF) or high frequency (HF); Π H-M : Reflects the quality and control of design and manufacture of hybrid or MCM (Multi Chip Modules); Π LF : Reflects the factor of transition to lead-free processes;

Fig. 11 :

 11 Fig. 11: Modelling and simulation

Table 1

 1 presents the distributions of reliability and their parameters for each type of technology.

	Technology	Reliability distributions	Parameters
	Electronic	Exponential	λ
	Electrical	Exponential	λ
	Mechanical	Weibull	β and η
	Software	Exponential	λ ( λ= kpN0 Musa model)

Table 1 :

 1 Reliability distributions associated with the technology of components

Acknowledgment

We thank the ACS (Assembly of the Countries of Savoie) and CETIM that fund this work as part of a doctoral thesis.