Amine Dhraief

Abdelfettah Belghith

Hassan Mathkour

Khalil Drira

An M2M gateway-centric architecture for autonomic healing and optimizing of Machine-to-Machine overlay networks

An M2M gateway-centric architecture for autonomic healing and optimizing of Machine-to-Machine overlay networks

Amine Dhraief, Abdelfettah Belghith, Hassan Mathkour, Khalil

Introduction

Embedded systems such as sensors, smart meters and smart cards are experiencing a tremendous proliferation. Several market forecast predict that the number of these devices will soon outnumber the people on earth. According to the Wireless World Research Forum (WWRF), by 2017 we will have 7 trillion wireless devices serving 7 billion people [START_REF] Mikko | Global vision for the future wireless world from the wwrf[END_REF]. Juniper Networks predicts that in 2015, the number of connections between embedded equipments will reach over 500 millions [START_REF] Networks | Machine-to-Machine (M2M) The Rise of the Machines[END_REF]. Machine-to-machine (M2M) communication is considered to be an adequate framework to handle the communication between these embedded systems 1 and their corresponding applications. M2M communication is a novel communication technology under standardization at both the European Telecommunications Standardization Institute (ETSI) [START_REF][END_REF][START_REF][END_REF] and the 3rd Generation Partnership Project (3GPP) [START_REF]Study on facilitating machine to machine communication in 3GPP systems. 3GPP TR[END_REF]. M2M communication is based on an autonomous communication between sensors/actuators and correspondent application over the Internet. The M2M architecture introduces a new level of indirection between the sensors/actuators and the application namely the M2M gateway. The M2M gateway aggregates data packets received form sensors and sends them to the M2M application. It generally communicates with M2M devices via short range communication technologies.

The telecommunication industry is energetically supporting the spreading of the M2M technology as it is expected to be one of the most promising revenuegenerating service. Nonetheless, from a standardization point of view, the M2M paradigm is still in its infancy [START_REF] Lu | Grs: The green, reliability, and security of emerging machine to machine communications[END_REF]. Both ETSI and 3GPP standards do not provide a secure, fault-tolerant and self-managed M2M architecture, which is a sine qua none condition to the healthy and sustained development of the M2M market [START_REF]Service Requirements for Machine-Type Communications[END_REF]2,[START_REF][END_REF][START_REF][END_REF]. If neither security nor reliability is provided for M2M communications, this newly emerging paradigm will not be widely adopted. As M2M communication do not intrinsically require human intervention, they should be self-managed and fault-tolerant. Besides, as machines are generally low cost and unattended equipments, they are exposed to several attacks [START_REF] Inhyok Cha | Trust in m2m communication[END_REF]. Furthermore, M2M communications are expected to be primary used for monitoring and telemetry applications such as in Advanced Metering Infrastructure (AMI) of the smart grids [START_REF] Fadlullah | Toward intelligent machine-to-machine communications in smart grid[END_REF]. Fadlullah et al. forecasts in [START_REF] Fadlullah | Toward intelligent machine-to-machine communications in smart grid[END_REF] that AMI is the most promising M2M market growth. However M2M communications over AMI must be secure, faulttolerant and self-managed to reach a healthy and sustained M2M market expansion.

Several researcher have already pointed out this problem. Rongxing et al. noted in [START_REF] Lu | Grs: The green, reliability, and security of emerging machine to machine communications[END_REF] that M2M communications reliability and security have not been well investigated. Geng et al. stated in [START_REF] Wu And Talwar | From mobile to embedded internet[END_REF] that securing M2M communication will be of paramount concern. He also indicates that "zero-touch" manageability is a serious challenge to an M2M network. Zhang et al. listed in [START_REF] Zhang | Home m2m networks: Architectures, standards, and qos improvement[END_REF] the challenges raised by M2M communications. Among the presented challenges, he stressed on the security and the self-organization issues. Hence, providing a secure, fault-tolerant and self-managed M2M communication is no more an option, it is a crucial necessity. For this purpose, we propose to build a secure and autonomic M2M overlay network over the Internet.

A previous work [START_REF] Dhraief | HBMON: A HIP-Based M2M Overlay Network[END_REF] proposed an M2M overlay network over the Internet based on the Host Identity Protocol (HIP) [START_REF] Moskowitz | Host Identity Protocol (HIP) Architecture. RFC 4423[END_REF][START_REF] Moskowitz | Host Identity Protocol[END_REF], named HBMON (HIP-based M2M Overlay Network). This previous work have addressed the formation and the maintenance of the overlay. Other works have already focused either on building overlay M2M devices networks or on enabling autonomic properties in M2M/IoT architectures but to the best of our knowledge none of these works uses an autonomic architecture to build and manage an overlay network. Wan et al. consider in [START_REF] Wan | Enabling cyber-physical systems with machine-to-machine technologies[END_REF] that M2M networks are, at the present stage, the main pattern for the Inter-net of Things (IoT). They review in their work the main features of M2M technologies and stress on their autonomous decision-making and control capabilities. [START_REF] Wan | Node placement analysis for overlay networks in iot applications[END_REF] studies the node placement problem in an M2M devices/IoT internet-based overlay network. Ashraf et al. survey in [START_REF] Qazi | Autonomic schemes for threat mitigation in internet of things[END_REF] different autonomic-based security approach for the IoT. In [START_REF] Ashraf | Autonomic protocol and architecture for devices in internet of things[END_REF], the author propose an autonomic framework for device communication in an IoT context. Jara et al. propose in [START_REF] Jara | Secure and scalable mobility management scheme for the internet of things integration in the future internet architecture[END_REF] to add a secure mobility management support to the M2M devices in the HIMALIS (Heterogeneity Inclusion and Mobility Adaptation through Locator ID Separation) architecture. It adds the self-protecting (security) and self-healing (mobility) autonomic properties. The proposed architecture targets to extend the Internet of Things through the usage of two distinct levels of indirections: naming and addressing. It also relies on several registries which map the device names to their addresses. Kirsche et al. propose in [START_REF] Kirsche | Unify to bridge gaps: Bringing xmpp into the internet of things[END_REF] to use the Extensible Messaging and Presence Protocol (XMPP) in order to simplify the interconnection of M2M devices and actuators.

In this paper, we propose to add the autonomic management of the overlay at the M2M gateway level. We focus on the self-healing and self-optimization autonomic properties. We enable at the M2M gateway level the REAP protocol, a failure detection and locator pair exploration protocol for IPv6 multihoming nodes [START_REF] Arkko | Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming[END_REF]. Thus, in our overlay, M2M gateways are able to autonomically detect failures of the overlay links and recover from them. Furthermore, M2M gateways are able to monitor the available overlay paths and dynamically select the best path in term of Round Trip Time (RTT). We implement our solution on the OMNeT++ network simulator. Results show that our solution is able to detect overlay link failures and recover from them. It is also able to self-optimize the selection of the overlay paths.

The remaining of this paper is organized as follows. Section 2 highlights the motivation of our work, the challenges that face the deployment of such solution and the fundamental properties to be satisfied. Section 3 presents the key building blocks of our solution. Section 4 gives an overview of HBMON [START_REF] Dhraief | HBMON: A HIP-Based M2M Overlay Network[END_REF][START_REF] Dhraief | Mobility management in the hip-based m2m overlay network[END_REF][START_REF] Dhraief | Simultaneous mobility management in the hip-based m2m overlay network[END_REF]. Section 5 focuses on our contribution; namely the self-healing and optimizing of the HIP-based M2M overlay network. Section 6 presents our simulation results. Section 7 review some related work. Finally, section 8 concludes the paper.

Problem Statement

In the following we first detail in section 2.1 the motivation for building an M2M overlay network. Then, we highlight in section 2.2 the constraints that face the deployment of an M2M overlay network. Finally, we present in section 2.3 the fundamental properties of such solution.

Motivations

M2M technology targets a wide range of applications such as: smart grids, remote maintenance and control, healthcare, security and public safety and vehicular telematics. This large spectrum of uses cases requires a secure, reliable and fault-tolerant end-to-end communications [START_REF] Wu And Talwar | From mobile to embedded internet[END_REF]. For example, for both healthcare (such as monitoring vital signs) and remote maintenance and control applications (such as industrial automation and metering), providing a reliable and fault-tolerant communications is extremely important. Nonetheless, standard Internet protocols do not include efficient failure detection and recovery mechanisms. Labovitz et al. demonstrated in [START_REF] Labovitz | Delayed internet routing convergence[END_REF] that Border Gateway Protocol (BGP) fault-recovery mechanisms may require several minutes before a consistent convergence of routes. Therefore, we cannot solely rely on current Internet protocols to ensure reliable M2M communications.

An overlay network is a private virtual network built on the top an existing network (which is usually Internet) in order to add a network service not available in the underlying network [START_REF] Andersen | Resilient overlay networks[END_REF]. At the early stages of its development, Internet (previously named catenet [START_REF] Pouzin | A proposal for interconnecting packet switching networks[END_REF][START_REF] Cerf | The catenet model for internetworking[END_REF]) was conceived as concatenation of different scattered networks (ARPANET, MILNET, MINET, SATNET, TELENET ). To enable packet switching over these network, Internet predecessor was designed as an overlay over the telephony network. Peer-to-peer (p2p) networks [START_REF] Eng Keong Lua | A survey and comparison of peer-to-peer overlay network schemes[END_REF], Multicast networks [START_REF] Jannotti | Overcast: reliable multicasting with on overlay network[END_REF] and Content Distributed Networks (CDN) [START_REF] Saroiu | An analysis of internet content delivery systems[END_REF] are some examples of current overlay networks.

Overlay networks do not require any change in the current Internet infrastructure, they only add additional servers. Thus, overlay network can be incrementally deployed over the Internet [START_REF] Jannotti | Overcast: reliable multicasting with on overlay network[END_REF]. Moreover, the overlay paradigm breaks the end-to-end principal. Instead of "keep-it simple in the middle, intelligent at the edge" [START_REF] Saltzer | End-to-end arguments in system design[END_REF], overlay networks move the intelligence toward the middle. Indeed, overlay networks rely on middle-boxes (such as overlay router) connected through logical links referred as overlay links. Middle-boxes translates on-demand overlay links into Internet paths.

Consequently, we target to build an M2M overlay network over the existing Internet architecture which will ensure a secure and fault-tolerant M2M communications.

Constraints

The deployment of an M2M overlay network is subject to several constraints mainly due to the intrinsic nature an M2M network. in the following we detail them.

Resources constraints

M2M devices are expected to be largely deployed in our surrounding environment and this will necessitate very low-cost devices. Consequently, M2M devices will have very limited computation, storage and power capabilities. M2M gateways aggregates the data received from several M2M devices before communicating it to the distant M2M Application. Therefore, M2M gateways will benefit from larger computation, storage and power capabilities than M2M devices. From the above statement, we conclude that we should drastically limit M2M device role in the management of the M2M overlay network. On the other hand, M2M gateways should have a central role in building and managing the M2M overlay network.

Scalability

In order to build a scalable M2M overlay network, M2M gateway should not be dependent on any specific configuration enabled at the upstream Internet Service Provider (ISP) side. An ISP should not give a specific support to the M2M gateway, M2M gateway incoming packets should handled as any packet coming from an Internet router. Otherwise, this will increase the cost of deploying an M2M solution and small and mid-size businesses would not benefit from M2M technology.

Unreliable communications

M2M devices exclusively use wireless communication technologies to send sensed data to their corresponding M2M gateways. The mass deployment of M2M devices will obviously lead to the increase of the wireless channel noise and fluctuations. And as an immediate consequence, M2M communication first-hop reliability will be degraded. Moreover, in order to maintain an M2M overlay network, M2M gateway should exchange periodic control messages with distant M2M application. Therefore, such communication should be fault-tolerant. Without and adequate support, communication within the M2M overlay are subject to failures which can lead to the loss of connectivity between the overlay members.

Properties

We target to build an autonomic M2M overlay network. An autonomic M2M overlay network is formed by a federation of heterogeneous machines self-formed without any managing authorities nor specific infrastructures [START_REF] Kephart | The vision of autonomic computing[END_REF]. Such a network should be able to self-manage itself and take its own decision according to information gathered from its environment. For this purpose, our targeted M2M overlay network should provide some fundamental autonomic properties, namely self-properties [START_REF] Kephart | Research challenges of autonomic computing[END_REF][START_REF] Ganek | The dawning of the autonomic computing era[END_REF], to efficiently handle M2M communications. Each of them is described below:

Self-configuring

A self-configured M2M network is able to dynamically adapts itself to the deployment of new equipments or changes in its environment. The self-configuring property includes overlay membership management (join and leave operations) [START_REF] Voulgaris | Cyclon: Inexpensive membership management for unstructured p2p overlays[END_REF], overlay resource and service discovery [START_REF] He | A decentralized service discovery approach on peer-to-peer networks[END_REF] and overlay information retrieval [START_REF] Tang | Peer-to-peer information retrieval using self-organizing semantic overlay networks[END_REF].

Self-healing

M2M overlay network members should be able to evaluate their current state and perform corrective actions accordingly. In this context, M2M devices should monitor their available overlay paths to detect possible failures and recover from them [START_REF] Zhang | Home M2M networks: Architectures, standards, and QoS improvement[END_REF]. This is the most important property that should be satisfied by our M2M overlay network since we essentially target to build a reliable and fault-tolerant M2M communications.

Self-optimizing

Current M2M gateways are usually multihomed gateways. For example the Cisco 819 4G LTE M2M Gateway natively supports multihoming to ensure a highly available access to the M2M devices [? ]. Therefore, M2M gateways should proactively monitor the available paths in order to ensure an optimal path selection with no human intervention.

Self-protecting

M2M devices are usually deployed in highly distributed insecure networks. M2M overlay members should protect themselves form physical attacks, compromise of credentials, configuration attacks, protocol attacks and attacks on the core network [START_REF] Inhyok Cha | Trust in m2m communication[END_REF].

Key building blocks

In [START_REF] Dhraief | HBMON: A HIP-Based M2M Overlay Network[END_REF], authors proposed an M2M overlay network based on the Host Identity Protocol (HIP). They focused on the self-configuring and the self-protecting autonomic properties. In this work, we target to enhance this solution with the selfhealing and self-optimizing autonomic properties. In the following, we first detail the M2M high-level architecture as defined by the ETSI in [START_REF][END_REF]. Then we detail the Host Identity Protocol (HIP) [START_REF] Moskowitz | Host Identity Protocol (HIP) Architecture. RFC 4423[END_REF] and the reachability protocol (REAP) [START_REF] Arkko | Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming[END_REF]. We target to use REAP alongside with HIP at the M2M gateway level to provide self-healing and self-optimizing autonomic properties.

M2M high-level architecture

The European Telecommunications Standards Institute (ETSI) defines in [START_REF][END_REF] a high level architecture for M2M. This architecture is divided into two main domains: (i) The device and gateway domain and (ii) the network domain (see Fig. 1).

The device and gateway domain consists of several M2M devices connected to an M2M gateway. An M2M device is typically a sensor or meter that collect data from its surrounding and sends it (in a single-hop or multi-hop) to the M2M gateway. According to the targeted M2M application several radio technologies Figure 1: M2M high level architecture can be used to connect an M2M device to an M2M gateway. For example, for human body monitoring and health-care applications, M2M device are equipped with IEEE 802.15.6 interface which is a low-power and low-data rate wireless technology [1]. For smart metering and home automation applications, M2M device can use a wide spectrum of available radio technology. For high data rate communication, M2M devices can use WiFi or UWB technologies; whereas for low-data rate communication M2M devices can use 6LowPan or Zigbee technologies [START_REF] Zhang | Home m2m networks: Architectures, standards, and qos improvement[END_REF]. The set of the M2M devices constitutes an M2M area network. The M2M gateway connects the M2M area network to the Internet via an access network. In order to improve their reliability, M2M gateways are usually multihomed middelboxes. They are at least connected with two different upstream Internet Service Providers to distant M2M applications. At the M2M applications level, information gathered from the different M2M devices are processed. The network domain includes the access network, the core network (usually Internet) and the distant M2M applications.

The Host Identity Protocol (HIP)

A well-known problem in the current Internet architecture is the overloading of the semantic of IP addresses: IP addresses have a dual role, they are simultaneously used as endpoint identifier (as seen by the transport layer) and endpoint locator (as seen by the IP layer) [START_REF] Jain | Internet 3.0: Ten problems with current internet architecture and solutions for the next generation[END_REF]. To ensure the scalability of the routing system and to prevent routes disaggregation, the Rekhter Law [START_REF] Rekhter | An Architecture for IP Address Allocation with CIDR[END_REF] stipulates that "'Addressing can follow topology or topology can follow addressing; choose one."'. This law forces endpoint locators to be topologically correct; whereas, endpoint identifiers are usually not congruent with the Internet topology [START_REF] Dhraief | Multihoming support in the internet: A state of the art[END_REF]. Furthermore, with the democratization of the Internet Protocol version 6 (IPv6), endpoints can concurrently have multiple global IPv6 addresses. They are therefore considered as multi-attached or multihomed end-host whether they received their IPv6 prefix from the same ISP (multi-attached) or from different ISP (multihomed). Without an adequate support, such end-host sessions are halted after a failure in the currently used path or an ISP renumbering operation [START_REF] Dhraief | Mobility and multihoming management and strategies[END_REF][START_REF] Dhraief | A serviceoriented framework for mobility and multihoming support[END_REF]. Finally, we are wit-nessing a tremendous proliferation of smart-phones and laptop. These nodes are equipped with several wireless access technologies and are able to perform a vertical or a horizontal handover while having running sessions. Without an adequate support, such end-host session are halted after changing their point of attachment to the network [START_REF] Dhraief | An experimental investigation of the impact of mobile ipv6 handover on transport protocols. The Smart Computing Revue[END_REF].

Several protocols have already been proposed to efficiently manage end-host mobility and multihoming such as Shim6 [START_REF] Nordmark | Shim6: Level 3 Multihoming Shim Protocol for IPv6[END_REF], Mobile IP protocol family (MIP, MIPv6, HMIP,...) [START_REF] Johnson | Mobility Support in IPv6. RFC 3775[END_REF] and the host identity protocol (HIP) [START_REF] Moskowitz | Host Identity Protocol (HIP) Architecture. RFC 4423[END_REF]. Shim6 is a hostcentric multihoming protocols, it enables multihoming features at the network layer. Shim6 provides session survivability upon any change that may affect the currently used IP address. These changes are usually due to failures affecting the used path or ISP renumbering operations. Mobile IP protocol family provide mobility functions at the network layer. They aim at preserving session survivability when the mobile node performs a layer 3 handover, i.e, it changes it attachment to a new access router. HIP provides both mobility and multihoming functions at the host level. Furthermore, in order to be compatible with the current Internet routing system, Shim6, Mobile IP protocol family and HIP use a topologically correct IP address as endpoint locator. These protocols however use different endpoint identifier. While Shim6 and Mobile IP protocol family use one of the available IP address as identifier, HIP introduces a new cryptographic name space called the Host Identity Tag (HIT). HIP also introduces a proxy element in the network architecture, the rendezvous server which holds a secure binding between end-hosts IP addresses and their HITs. Thus, HIP provides a native secure identity to mobile and multihomed nodes.

As highlighted in [START_REF] Choi | Security based semantic context awareness system for m2m ubiquitous healthcare service[END_REF][START_REF] Granjal | Security issues and approaches on wireless m2m systems[END_REF], securing M2M communication is no more an option as M2M networks are inherently insecure networks prone to attacks. Moreover, as M2M devices are usually low-cost devices with limited computation capabilities, a potential mobility and multihoming protocol to be embedded on M2M devices should have a very low computational overhead. Nikander et al., showed in [START_REF] Nikander | Integrating security, mobility, and multi-homing in a hip way[END_REF] that HIP natively integrates security, mobility and multihoming. Henderson studied in [START_REF] Henderson | Experience with the host identity protocol for secure host mobility and multihoming[END_REF] the computational overhead of HIP and demonstrated that HIP can easily be deployed on 266 MHz Pentium II-based laptops. Therefore, HIP is a potential candidate to be deployed on resource-constrained multihomed and mobile M2M nodes.

HIP insert a shim layer in the TCP/IP stack between the IP and transport layer. This new layer rewrites the IP address into a HIT and vice versa. In order to perform this rewriting procedure, HIP establishes a context between any two communicating HIP-enabled hosts. The HIP context holds a binding between the HIT and its corresponding(s) IP address(es). This context is established after a fourway handshake (see Fig. 2 ) between an Initiator and a Responder. The Initiator triggers the establishment of the context by sending a I1 message. The Responder replies with R1 message holding a cryptographic puzzle in order to is to protect the Responder from denial-of-service attacks. Upon receiving the R1 message, the Initiator solves the puzzle and includes the solution in I2 message. After checking the Figure 2: HIP context establishment solution of the puzzle, the Responder confirms the establishment of the HIP context through an R2 message. Moreover, HIP introduces in the network architecture a registrar element: the Rendez-vous Server (RVS) [START_REF] Laganier | Host Identity Protocol (HIP) Rendezvous Extension[END_REF]. This network function help to maintain a binding between IP addresses and their corresponding HIT. HIP nodes can register with an RVS and update their registration if any change has occurred on their available address sets.

The reachability protocol: REAP

Multihomed terminals are configured with a least two IP addresses each one associated with a distinct Internet Service Provider (ISP). These terminals are then reachable via different paths [START_REF] Dhraief | Multihoming support in the internet: A state of the art[END_REF]. A multihomed terminal can spread its outgoing traffic among the available paths by applying a load sharing or balancing scheduling technique. However, such a scheduling technique has a negative impact on TCP. In fact, TCP segments sent on paths with lower delays may result in an outof-order TCP segments. Upon receiving an out-of-order segment, destination's TCP immediately sends a TCP duplicate acknowledgement. Three duplicates acknowledgements results into the reduction of the TCP congestion window. Therefore, TCP erroneously concludes that these duplicates acknowledgments are due to packet losses and enters in a congestion avoidance phase. Hence, multihomed terminal usually consider one path as primary and the alternate paths as backups. If a failure occurs in the primary path, multihomed terminals migrate their ongoing session to a backup path [START_REF] Dhraief | Rehoming decision algorithm: Design and empirical evaluation[END_REF][START_REF] Dhraief | Mobility and multihoming management and strategies[END_REF]. For this purpose, the IETF has standardized a protocol for failure detection and locator pair exploration protocol for IPv6 multihoming terminals named the reachability protocol (REAP) [START_REF] Arkko | Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming[END_REF]. The IETF has designed this protocol for the specific use of the Shim6 protocol.

REAP relies during its functioning on two timers: the send timer and the keepalive timer. REAP assumes that communicating nodes have a prior knowledge of their locators. At the initiator side, REAP starts the send timer whenever a node sends a packets (step 1 in Fig. 3). If this node has not received any packet until the send timer expires, it performs a full reachability exploration procedure. Upon receving the data packet, the responder starts the keepalive timer. If the node has not sent any packet until the keepalive timer expiry, then it sends a REAP keepalive Figure 3: The reachability protocol: REAP message to its corresponding peer (step 2 in Fig. 3). If the corresponding peer receives a keepalive message, then it stop the send timer and starts the keepalive one. The REAP specification recommends that the keepalive timer should be equal to the send timer divided by three. These two timers are mutually exclusive. In other word, the node is either expecting to receive a payload or preparing to send data. So the send timer is stopped when a payload or keepalive message is received and the keepalive timer is stopped when a payload is generated.

When REAP detects a failure, it starts a full reachability exploration procedure in order to find a new bidirectional working address pair using probe messages (step 3 in Fig. 3). REAP associates a state to each probe indicating the status of the communication. REAP defines three states: OPERATIONAL, INBOUNDOK and EXPLORING. The OPERATIONAL state indicates that communicating peers consider that their ongoing session does not suffer from any failure. The IN-BOUNDOK state reflect the case where a peer considers that its communication has apparently no problem, but its correspondent one has discovered a failure. The EXPLORING state indicates that a peer has just discovered a failure.

REAP failure recovery procedure is as follows. First, REAP creates a list of all possible pair of addresses by combining the local locator list and the peer locator list and sorts this list according to some priority specified by the user. Then, it switches its state to Exploring and sends four probes successively, a probe every 0.5 second. If it does not receive any probe, it retransmits a probe, but this time the retransmission is controlled by a back-off timer. If a node in the OPERATIONAL state receives a probe having EXPLORING state, it concludes that its correspondent peer has not received its outgoing traffic. This peer then sends a probe having an INBOUNDOK state. A peer in the EXPLORING state and receiving an IN-BOUNDOK probe conclude that its correspondent peer has received its probe and also that the probed locator pair address is bidirectionally reachable. Thus, it sends a probe having an OPERATIONAL state and the communication can be resumed (step 3 in Fig. 3).

HBMON: The HIP-based M2M overlay network

A previous work proposed a HIP-based M2M overlay network called HBMON [START_REF] Dhraief | HBMON: A HIP-Based M2M Overlay Network[END_REF][START_REF] Dhraief | Mobility management in the hip-based m2m overlay network[END_REF][START_REF] Dhraief | Simultaneous mobility management in the hip-based m2m overlay network[END_REF]. In the following, we highlight the salient features of HBMON.

The HBMON is a set of HIP-enabled M2M devices associated with HIP Rendezvous Servers (RVSs) and having running sessions with distant correspondent nodes. The HIP RVS embeds M2M gateway functionalities. It uses a modified verion of the HIP base exchange mechanism in order to define, join and distribute information about our M2M overlay. Theses modifications enable the self-configuring and the self-protecting autonomic properties.

If an M2M device (the initiator) wants to create a new HBMON with a given correspond node (the responder), it sends to this responder a I1 HIP message containing a new field named REQUEST-HBMON. The responder acknowledges the reception of the I1 message by sending an R1 message including a new field named ACK-HBMON. Once it receives a positive acknowledgement, the initiator triggers the discovery of the nearest M2M gateway (HIP RVS). All the M2M gateways have pre-defined IPv6 anycast address. The initiator sends a new HIP signalling message called RVS-Discovery-Request to this specific anycast address. When the initiator receives the R1 packet, it sends an RVS-Discovery-Request packet to a pre-defined anycast address to discover the nearest RVS. A responding M2M gateway answers the initiator with a RVS-Discovery-Response. Similarly, the responder performs the same M2M gateway discovery process. After the discovery of the M2M gateway, the initiator sends a I2 HIP message to the responder including its set of locators, its HIT, the IPv6 address of its M2M gateway and a HBMON Tag. The responder acknowledges the reception of the I2 message by sending an R2 message including its set of locators, its HIT and the IPv6 address of its M2M gateway. After that, both the initiator and the responder sends a new HIP message named HBMON-CONTEXT to their respective M2M gateways. The HBMON-CONTEXT message includes the following fields (HBMON Tag, I HIT, R HIT, I IP, R IP, RVS IP). HBMON Tag is an identification of the current context. This context tag -generated by the initiator-should be included in all HBMON packets. I HIT and R HIT are the Host Identity Tag of the initiator and the responder. I IP and R IP are the set of the available IP addresses of the initiator and the responder. RVS IP is the IP address of the currently used RVS. Finally, The HBMON context is stored by all HBMON members and similarly to the HBMON-CONTEXT message it includes the following records (HBMON Tag, I HIT, R HIT, I IP, R IP, RVS IP). If an M2M device (the initiator) wants to join an existent HBMON, it sends a HBMON-JOIN-Request message with the desired HBMON Tag to the anycast address of the M2M gateways. If the M2M device is authorized to join this overlay, an M2M gateway replies with a HBMON-JOIN-Response. Fig. 4 presents the HBMON definition procedure.

In the proposed architecture, the M2M gateway acts as an IPv6 router. It periodically broadcasts an ICMPv6 Router Advertisement (RA) message to the M2M devices registered with it. The RA message includes a private IPv6 prefix dedicated [START_REF] Narten | Neighbor Discovery for IP version 6 (IPv6). RFC 4861[END_REF] to detect if another M2M device member of the overlay has previously configured the same IPv6 address. Finally, the M2M device updates it recording in the M2M gateway with this new address.

From an autonomic networking perspectives, HBMON enabled the self-configuration and self-protection properties. In the HBMON, self-configuration properties is provided by the registration functionality of the HIP protocol which allows M2M devices to autonomically register themselves with a rendezvous server and distribute overlay information between overlay members. The self-protection properties main goal is to give the system the possibility to protect itself from intrusion and any hostile behaviour. The cryptographic namespace HIT [START_REF] Nikander | Integrating security, mobility, and multi-homing in a hip way[END_REF][START_REF] Nikander | Host identity protocol (hip): Connectivity, mobility, multi-homing, security, and privacy over ipv4 and ipv6 networks[END_REF] with the private addresses used within the overlay are the features used by the M2M devices in the HBMON to protect themselves from attacks.

M2M gateway-centric architecture for the autonomic management of the HBMON

The previous work [START_REF] Dhraief | HBMON: A HIP-Based M2M Overlay Network[END_REF] focused on the organization and the membership management of the M2M device within the overlay. We also proposed a novel IPv6 address assigning method in order to configure the overlay members with private IPv6 addresses [START_REF] Dhraief | Mobility management in the hip-based m2m overlay network[END_REF][START_REF] Dhraief | Simultaneous mobility management in the hip-based m2m overlay network[END_REF]. This solution already ensures the self-configuring and the self-protecting properties of the autonomic management of our M2M overlay network. In the following we propose to enable at the M2M gateway level the remaining autonomic properties (self-healing and self-optimization).

Gateway-centric vs. device-centric architectures

The self-healing and self-optimization autonomic properties can be enabled either at the M2M device level or at the M2M gateway level. Enabling these properties at the M2M device level is in concordance with the end-to-end principle, one of the pillars of the current Internet architecture [START_REF] Saltzer | End-to-end arguments in system design[END_REF]. Nonetheless, M2M devices have a very limited computational, storage and power capabilities. Thus, handling the self-healing and self-optimizing autonomic properties will be an unacceptable overhead for them. Furthermore, enabling such networking services at the M2M device will increase wireless channel fluctuation and noise as it usually requires extra signalling traffic. On the other hand, M2M gateway have a central role in the M2M network architecture. In [START_REF] Zhang | Home m2m networks: Architectures, standards, and qos improvement[END_REF], Yan et al. proposed a home M2M architecture where all of the networking related functionalities are implemented at the gateway level. In [START_REF] Wu And Talwar | From mobile to embedded internet[END_REF], Geng et al. consider M2M gateways as an aggregation and a platform for value-added services. Hence, we propose to enable the self-healing and the self-optimizing autonomic properties at the M2M gateway level. Both autonomic properties are fulfilled through the coupling of HIP with REAP at the M2M gateway level.

M2M gateway protocol stack

We propose the following protocol stack for the M2M gateway depicted by Fig. 5.

The network layer of the M2M gateway includes two sub-layers: a routing sublayer and an autonomic management sub-layer. The routing layer is a regular IPv6 networking layer; whereas, the autonomic management sub-layer is responsible for the self-healing and the self-optimization capabilities.

To design a resilient M2M overlay network, we use the REAP protocol alongside with HIP at the autonomic management sub-layer to: (i) monitor the existing overlay paths, and (ii) detect failures and recover to a new working path.

At the autonomic management sub-layer, we implement a bi-directional communication between REAP and HIP (see (1) in Fig. 5). In fact , in our M2M overlay network, several overlay paths might exist between the gateway and the corresponding M2M applications. Each path is bounded to a different network interface of the M2M gateway. This path diversity is highly recommended for specific M2M fault-tolerant system such as M2M health-care applications [START_REF] Royc | M2m-based smart health service for human ui/ux using motion recognition[END_REF]. In order to actively monitor the set of the available overlay paths, REAP retrieves from HIP, for a given HBMON context tag, the set of the available IP addresses. For this purpose, REAP needs to access the information stored by HIP in the HBMON context. Similarly, for a given HBMON context tag, HIP retrieves from REAP the best available overlay path. In fact, the available overlay paths cross different ISPs having different network characteristics (RTT, jitter, errors,...). Moreover, an overlay path can experience for a period of time a degradation of its quality of service (QoS) due to burst traffics and congestion. Meanwhile, this overlay path can be used by an M2M communication requiring a certain QoS level. Without an adequate support, this running M2M session will be affected by the deterioration of this overlay path. Therefore, we enhance the REAP exploring mechanism to offer to a given M2M running communication (identified by a HBMON Context tag) always the best available overlay path.

In order to provide a reliable M2M communication while ensuring session survivability, HIP communicates with the routing sub-layer (see (2) in Fig. 5). Finally, Figure 5: M2M gateway protocol stack REAP sends its probe and keepalive packets via the routing sub-layer (see (3) in Fig. 5).

Gateway-centric self-healing of the HBMON

As we previously sated in sections 2.2.1 and 5.1, M2M devices have a very low computational, storage and power capabilities, and consequently HBMON selfhealing functions should be deployed at the M2M gateway level. M2M gateways are therefore responsible for the monitoring of the currently used overlay path for a given HBMON context tag. For this purpose, we introduce new parameters in HIP messages namely "PROBE" and "KEEP ALIVE" in order to couple REAP with HIP. The "PROBE" message is exchanged between M2M peer's gateways when a failure is detected and the "KEEP ALIVE" message is used to monitor unidirectional communications. We also append HIP with two REAP timers, namely the send and the keepalive timers. If an M2M gateway's send timer expires without receiving any incoming packets, the M2M gateway assumes that a failure has affected this currently used overlay path and starts exploring the remaining available overlay paths. In unidirectional communications, the M2M gateway has to periodically inform its corresponding gateways that the currently used overlay link is working through the keepalive timer. When the keepalive timer expires, the M2M gateway sends a keepalive message.

If REAP detects a failure through the expiry of the send timer, REAP starts the overlay paths explorations. During this exploration, REAP sends probe exploring messages on each available overlay path bound to a given M2M session. The corresponding M2M gateway receiving the probe exploring message replies with a probe Inbound OK message indicating the status of the probed overlay path. Upon receiving a probe message with the status inbound OK, REAP replies with a probe operational message and switch the ongoing communication to this newly operational overlay link.

In order to explain the functioning of the HBMON self-healing procedure, we • C1 is stored in G1 and G3, while C2 is stored in G2 and G4

• C1 is currently using the overlay path (b,f,h,j) between the two M2M gateways G1 and G3

• C2 is currently using the overlay path (c,f,i,k) between the two M2M gateways G2 and G4

• An outage affects the overlay link (f)

REAP is triggered respectively at the M2M gateways G1 and G2 in order to find a new working overlay path. The M2M gateway G1 sends two REAP probe exploring messages on the overlay paths (a,e,j) and (b,f,h,j). Similarly, the M2M gateway G2 sends two REAP probe exploring messages on (c,f,i,k) and(d,g,k). The M2M gateways G3 and G4 answer with a REAP Inbound OK message on (a,e,j) and (d,g,k). Finally, G1 and G2 respond with a REAP operational message on these two paths and the M2M communications are rehomed to these new working overlay paths.

Therefore, by coupling REAP with HIP a the M2M gateway level, an M2M session can resume after an outage affecting a currently used overlay path. This failure recovery is completely transparent to the established M2M session. We can rely on regular routing protocols to detect such overlay path failure but this may require several minutes before a consistent convergence of routes as demonstrated in [START_REF] Labovitz | Delayed internet routing convergence[END_REF].

Gateway-centric self-optimization of the HBMON

Several overlay path migh exisit between two communicating M2M gateway having different RTT. We add to to the M2M gateway the self-optimizing capability by selecting the best available overlay path in term of RTT for a given destination.

Instead of triggering the REAP exploring process at the expiry of the send timer, we modify REAP in order to continuously monitor the available overlay paths and infer their respective RTT. Fro a given M2M session, REAP simultaneously explores all the available overlay paths between two given M2M gateways. For a given overlay path, REAP sends a probe request message and measure the elapsed time between the sending of this probe and the reception of the probe response. If a currently used overlay path experiences a degradation of its RTT, REAP proposes to HIP a new destination/source address pair of an overlay path having a lower RTT.

If we frequently perform the inferring of the RTT and the overlay paths switching, we can cause overlay paths oscillation, known as route flapping [START_REF] Varadhan | Persistent route oscillations in inter-domain routing[END_REF]. To avoid route flapping, we add a new timer, namely probe timer which defines the time between two consecutive path exploration process. We set up the probe timer to 3 seconds. This value is not supported by any analytical studies. Nonetheless, we believe that setting the probe timer to a lower value would potentially increase congestions if several HBMON contexts need to start path exploration. Moreover, authors in [START_REF] Barré | Improved path exploration in shim6-based multihoming[END_REF] proposed to set the reap send timer to 3 seconds for the same reason. Recall that as we previously explained in 3.3, the expiry of the send timer triggers the full reachability exploration procedure. Consequently, our HIP-based M2M overlay network is self-optimized as it always benefits from the best available overlay path in term of RTT.

Self-healing and optimizing signalling cost analysis

In this section, we propose an analytical model to assess the signalling cost of our self-healing and self-optimizing strategies. To do so, we consider theses assumptions:

• An M2M device can simultaneously have several running M2M sessions.

• An M2M session is bound to a HBMON context defining several overlay paths.

• An overlay path is composed of set of overlay links.

• All overlay links fail independently

• The time to fail and the repair time of a link are memoryless, exponentially distributed following a random process with constant means MT T F i and MT T R i [START_REF] Ni | Analytical models of flow availability in two-layer networks with dedicated path protection[END_REF][START_REF] Sahhaf | Availability analysis of resilient geometric routing on internet topology[END_REF].

Tab.I gives notations that will be used in our signalling cost analysis.

6.1 self-healing signalling cost analysis 6.1.1 Overlay path failure probability

In this section we estimate the probability of an overlay path failure. We define A i the steady-state availability of an overlay link i as:

A i = MT T F i MT T F i + MT T R i = µ i µ i + λ i
The mean failure rate of an overlay link λ i is measured in units of Failure in time (FIT). 1 FIT is equivalent to 1 failure in 10 9 hours. A the steady-state availability of an overlay path composed of l rr overlay links is defined as:

A = l rr ∏ i=1 A i
Therefore, the probability that an overlay path is in the failed state can be calculated as:

U = 1 -A = 1 - l rr ∏ i=1 A i = 1 - l rr ∏ i=1 µ i µ i + λ i

REAP update exploring cost

For a given M2M session, once REAP detects a failure, it sends a REAP probe exploring message on all the overlay paths bounded to this session (N SPath ). Several M2M sessions (N session ) may share the same overlay path . Thus, the failure will trigger a REAP exploration process on all these overlay paths bound to these sessions. A REAP update exploring cost includes the transmission cost and processing cost at the M2M gateway for all the involved M2M sessions.

Φ Probe Exploring SH = N session * N SPath * Ψ Probe Exploring SH + γ r T s
where the transmission cost between two M2M gateways of a REAP exploring message is equal to:

Ψ Probe Exploring SH = l rr * δ
According to little theorem, T s can be expressed as N session /λ sa . Therefore, the signalling cost of the REAP probe exploring message is:

Φ Probe Exploring SH = λ sa * N SPath * (l rr * δ + γ r )

REAP probe Inbound OK

M2M gateways receiving a REAP probe exploring message will reply will REAP update Inbound OK on all overlay paths bound to a given M2M session. Upon receiving a REAP probe Inbound OK message, the M2M gateway replies with a REAP probe operational message indicating for each M2M session involved in this process the new working overlay path. The REAP probe Inbound OK signalling cost is is equal to:

Φ Probe InboundOK SH == N session * (N SPath -1) * Ψ Probe InboundOK SH + γ r T s
where the transmission cost between two M2M gateways of a REAP probe Inbound OK message is equal to:

Ψ Probe InboundOK SH = Ψ Probe Exploring SH = l rr * δ
The signalling cost of the REAP probe Inbound OK message is:

Φ Probe InboundOK SH = λ sa * (N SPath -1) * (l rr * δ + γ r )

REAP probe operational

The REAP probe operational message is sent only on the selected overlay path. Its signalling cost is calucalted as:

Φ Probe Operational SH = λ sa * (l rr * δ + γ r )

Total signalling cost of HBMON self-healing

The total signalling cost of HBMON self-healing is the sum of all signalling packets cost (see Eq. 1) multiplied by the probability of an overlay path failure U

Φ Tot SH = U * (Φ U pdate Exploring SH + Φ U pdate InboundOK SH + Φ U pdate Established SH ) Φ Tot SH = 2 * U * N SPath * λ sa * (l rr * δ + γ r ) (1)
6.2 Self-optimizing signalling cost analysis 6.2.1 REAP probe request/response cost REAP continuously monitor the available overlay path to estimate their respective RTTs. This estimation is based on the exchange of REAP Probe Request/REAP Probe Response signalling messages. These two messages have the same signalling cost which can be calculated as follows:

Results

In the following, we evaluate the total signalling cost of the HBMON self-healing procedure while varying the overlay path failure rate from 200 FIT/km to 1000 FIT/km and the self-optimizing procedure while varying the number of overlay paths and the session arrival rate. For all numerical calculations, we use the same parameter values used in [START_REF] Abu S Reaz | Signalling cost analysis of sinemo: seamless end-to-end network mobility[END_REF] and [START_REF] Xie | An optimal location management scheme for minimizing signaling cost in mobile ip[END_REF]: l rr = 35, λ sa = 0.01, δ = 0.2, γ r = 30

In Fig. 7 we measure the overall signalling cost of the self-healing procedure for different number of overlay path per M2M sessions [START_REF]Service Requirements for Machine-Type Communications[END_REF][START_REF] Arkko | Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming[END_REF][START_REF] Cerf | The catenet model for internetworking[END_REF][START_REF] Dhraief | Multihoming support in the internet: A state of the art[END_REF][START_REF] Dhraief | Mobility and multihoming management and strategies[END_REF][START_REF] Ganek | The dawning of the autonomic computing era[END_REF]. We can see that even for a high number of overlay path (25) per M2M session, the signalling cost of the HBMON self-healing procedure still reasonable compared to the HBMON definition signalling cost previously evaluated in [START_REF] Dhraief | A serviceoriented framework for mobility and multihoming support[END_REF]. In Fig. 8 we plot the total signalling cost of the HBMON self-healing procedure for different session arrival rates per seconds (λ sa ) (0.01,0.1,0.5,1,1.5,3) and for a fixed number of overlay paths per M2M sessions (N SPath = 10). Similarly to the results obtained in Fig. 7, even for high M2M session rate arrival per seconds, the self-healing procedure does not introduce any signalling storm on HBMON and has a very low impact on the network load.

In Fig. 7 we measure the signalling cost of the self-optimizing procedure while varying the session arrival rate and the number of overlay paths. The measured signalling cost of our self-optimizing procedure has the same order of magnitude of well-established IETF protocols signalling cost evaluated in [START_REF] Abu S Reaz | Signalling cost analysis of sinemo: seamless end-to-end network mobility[END_REF][START_REF] Fu | Signaling cost and performance of sigma: A seamless handover scheme for data networks[END_REF]. In this section we present a performanc evaluation of our M2M gateway-centric architecture for autonomic healing and optimizing of M2M overlay networks. To evaluate our proposal, we use the OMNeT++ simulator coupled with the HIP-Sim++ framework [START_REF] Bokor | Design and evaluation of host identity protocol (hip) simulation framework for inet/omnet++[END_REF]. We implement the protocol stack for the M2M gateway depicted by Fig. 5 in the HIPSim++ framework.

Simulation set up and evaluation metrics

We set up an M2M device connected to Internet via a mutlihomed M2M gateway.

The M2M gateway has four available overlay paths having the following RTTs: 50ms, 100ms, 150ms and 200ms. The correspondent node is an M2M application. We set all the wireless accesses to 802.11b at 11 Mbit/s. Between the M2M application and the M2M device we use two types of traffic: the first one is an UDP flow having the following characteristics: 20 Bytes the packet length and 40 ms the inter-packet interval, the second traffic is TCP flows, namely an FTP application with hight data rate traffic. A failure affecting the currently used overlay path occurs after 20 s from the beginning of the communication and lasts twice as the send timer.

In order to evaluate our solution, we first focus on the application recovery time metric (ART). The ART was defined by La Oliva et al. in [START_REF] Antonio | Performance analysis of the reachability protocol for ipv6 multihoming[END_REF]. It measure the latency between the last packet received/sent before the outage and the first packet received/sent after the outage. The ART highlight the self-healing capabilities of our solution. After that, we evaluate the impact of our architecture on the instant throughput of an M2M session. First of all, we compare our solution with the regular REAP self-healing capabilities. Recall that regular REAP is deployed at the M2M device side while in our case REAP is deployed at the M2M gateway side. For this purpouse, we measure the instant throughput for both TCP and UDP traffic, depicted in Fig. 10 and Fig. 11 respectively. After 20s from the start of the simulation, the currently used overlay path (having the lowest RTT 50ms) experience a failure. The obtained result show that our self-healing strategy detects and recover from the failure more rapidly than the case of regular REAP. In fact, as the wireless segment is shared between 7 M2M devices and the REAP probe exploring message is simultaneously sent by all these M2M devices. This contention induces a delay in the failure recovery process. In addition, in the regular REAP case, once a new working overlay path is found, the current M2M sessions are simply rehomed to this path. In our case, the M2M gateway continuously monitors all the available overlay paths, and therefore, as soon as the previous path recovers from its failure, HBMON rehome ongoing M2M sessions to it as it has the lowest RTT.

Results

Self-healing evaluation

We evaluate in the following the self-healing capabilities of our solution. We measure the ART of both UDP traffic and the TCP traffic while varying the REAP send timer. Results are presented by Fig. 12, the x-axis is the send timer value while the y-axis is the measured ART. Results show that for an UDP application, the ART time increases linearly while we increase the send timer value; whereas, for TCP application the ART experiences several plateaus. After failure recovery, UDP application immediately sends data packets to the newly selected overlay path. Even if a new overlay path is selected, TCP does not send immediately its data segments, it has to wait until the TCP Retransmission Timeout (RTO) timer It adjusts the RTO timer as if it has experience of a congestion phase which explains the plateaus in Fig. 12. We conclude form the obtained results that our solution effectively detects failures and the established M2M session resumes after failure recovery for both TCP and UDP traffic. The TCP recovery lasts longer than the UDP one as TCP does not distinguish between a failure recovery process and the congestion in the currently used path [START_REF] Dhraief | An experimental investigation of the impact of mobile ipv6 handover on transport protocols. The Smart Computing Revue[END_REF]. To resolve this, we couple the RTO with REAP by a cross-layer design. This optimisation has been proposed by La Oliva et al. in [START_REF] Antonio | Performance analysis of the reachability protocol for ipv6 multihoming[END_REF]. When REAP finishes the exploration process and detects a new working overlay path, it cancels the RTO so that TCP can immediately retransmits the buffered TCP segments. We evaluate in this section the self-optimization capability of our solution. We modify REAP to actively monitor the available paths in order to offer the ongoing M2M communication the best available overlay path in term of RTT.

Self-optimization evaluation

We focus on the following scenario: the currently used overlay path has an RTT of 50ms and a transient failure affects this path after 20s of the beginning of the M2M communication, the failure lasts the double of the probe timer. We firstly evaluate the impact of the probe timer on the recovery of both UDP and TCP traffic. Fig. 13 illustrates the TCP/UDP recovery time for different values of the probe timer. We see that both TCP and UDP traffics have almost the same recovery time value whenever we vary the probe timer. In addition, the recovery time increases whenever we increase the probe timer.

Before the occurrence of the failure (20 s), the M2M gateway has already inferred the RTT of each overlay path (50 ms, 100 ms, 150 ms, 200 ms). These measurements are done respectively each 3s, 8s and 16s (the different proposed values of the probe timer). As soon as the failure has been detected by REAP, the M2M gateway has to wait until the inferring the RTT of the available overlay paths ends. For a probe timer equal to 3 s, the last RTT measurement has be performed 18 s after the beginning of the simulation. After the failure, the RTT inferring will be ready after 21 s of the beginning of the simulation. Thus, the recovery can be performed only after 21 s. It is in fact performed at 21.88 s for the case of the UDP traffic and 22.12 s for TCP one, which represents a recovery time equal respectively to 1.88 s and 2,12s. Similarly for a probe timer equal to 8s (16 s respectively), the recovery can be performed only after 24 s (32 s respectively). Thus, whenever we increase the probe timer, the recovery time increases regardless of the nature of the traffic (TCP or UDP).

We fix in the following the probe timer to 3 s and evaluate the instant throughput of both a TCP and UDP traffics. Fig. 14 shows the obtained results for a TCP session. The x-axis is the time in second and the y-axis is the instant throughput. The obtained results show that during the first 20 s, the throughput reaches its maximum because the used path has the minimum RTT (50 ms). After the failure recovery, REAP detects a new working overlay path having the second best RTT (100 ms). As soon as the best overlay path (50 ms) recovers forms its failure, M2M communication switches to this new path and the throughput reaches again its maximum value. Fig. 15 shows the obtained results for a running UDP session and a probe timer set to 3 s. The obtained results show the same behaviour as for the TCP case in Fig. 14. After the outage, the UDP session is rehomed to a new working overlay path (100 ms). As soon as the new overlay path (50ms) become ready, the UDP session is rehomed to this newly available path, and the throughput reaches again its maximum value. In a last scenario, we explore the self-optimization capability of our solution by modifying the load of the currently used overlay path. The M2M communication starts in the overlay path having the lowest RTT. A congestion appears in this path, so the TCP ongoing connection experiences packet losses, TCP reduces its congestion window which impact the instant throughput of the M2M communication. Our solution detects the quality degradation of the path and switches the communication to the second best path in term of RTT. Results presented by Fig. 16 and Fig. 17 shows this dynamic selection of the most stable path. During the first 20 s, the M2M communication flows via the path having the lowest RTT (50 ms). We inject in this path an aggressive UDP traffic, creating therefore a congestioned path. Our solution detects the degradation of the RTT of this path and its fluctuations. It switches the ongoing communication to the second path. We repeat the same scenario on this second path. Our solution switches one more time the communication to a third path and finally to the last one until it finds a stable path in term of RTT and packet loss.

From Fig. 14, Fig. 15, Fig. 16 and Fig. 17 we clearly see that we build a selfoptimized solution. It is able to detect failure in the currently used overlay path, select a new working path and monitor the remaining paths.

Conclusion

The M2M technology is currently under standardization at both ETSI and 3GPP and actively supported by the telecommunication industry. M2M technology is considered to be the "killer service" which will fill the revenue gap caused by the constant decrease of the voice service. In order to have secure and private M2M communications, a previous work defined an M2M overlay network based on the Host Identity Protocol (HIP) named HBMON. From an autonomic networking perspective, our M2M overlay network is already self-configured and self-protected. In this work we added the self-healing and the self-optimizing autonomic capabilities to our M2M overlay network. To do so, we coupled HIP with the Reachability protocol (REAP) at the M2M gateway level. We implemented and evaluated our proposal on the OMNeT++ network simulation using both TCP and UDP traffic. We have demonstrated that our solution effectively integrates the self-healing and the self-optimized capabilities. We have highlighted that TCP timers impact the self-healing capabilities of our solution as TCP does not distinguish between a failure affecting a currently used overlay path and a congestion episode. We therefore recommend to couple the RTO TCP timers with REAP ones in a cross layer way to accelerate the M2M session recovery process.

Figure 4 :

 4 Figure 4: HBMON definition

Figure 6 :

 6 Figure 6: Gateway-centric self-healing of the HBMON

Figure 7 :Figure 8 :

 78 Figure 7: Impact of the number of overlay path on the self-healing signalling cost

5 Figure 9 :

 59 Figure 9: Impact of the number of overlay path on the self-optimizing signalling cost

Figure 10 :Figure 11 :

 1011 Figure 10: TCP self-healing with regular REAP and HBMON

Figure 12 :

 12 Figure 12: Application recovery time for TCP and UDP traffic

Figure 13 :

 13 Figure 13: Probe Timer impact on the recovery of TCP and UDP traffic

Figure 15 :

 15 Figure 14: TCP recovery time

Figure 17 :

 17 Figure 16: TCP dynamic path selection

Acknowledgement

The authors extend their appreciation to the Deanship of Scientific Research at King Saud University for funding this work through research group No. RGP-1435-090

The mean failure rate for an overlay link i µ i

The mean repair rate for an overlay link i MT T F i

The mean time to fail of an overlay link i. MT

The mean time to repair of an overlay link i.

The steady-state availability of an overlay link i A

The steady-state availability of an overlay path U

The unavailability of an overlay path Self-healing signalling cost Φ