Rym Boudjemaa

Karine K Steenkeste

Cédric Jacqueline

Romain Briandet

Jocelyne Caillon

David Boutoille

Virginie Le Mabecque

Pierre Tattevin

Marie-Pierre Fontaine-Aupart

Prof Matthieu Revest
email: matthieu.revest@chu-rennes.fr

Jacqueline Cédric

Marie-Pierre Fontaine- Aupart

Marie-Pierre Fontaine

Live intramacrophagic Staphylococcus aureus as a potential cause of antibiotic therapy failure observations in an in vivo mouse

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Staphylococcus aureus biofilm development plays a significant role in the difficulties encountered when treating prosthetic vascular material infections (PVMIs). Previous literature data provided evidence that S. aureus, classically considered as an extracellular pathogen, can also invade and survive inside immune cells, including the phagocytic cells. Such survival mechanism could be responsible for the lack of antibiotics efficiency and the possibility of relapse of chronic infections. [START_REF] Fraunholz | Intracellular Staphylococcus aureus: live-in and let die[END_REF] This hypothesis was suggested from in vitro co-culture models and data reporting such in vivo interactions between S. aureus and mammalian tissues in the particular setting of PVMIs are scarce.

We recently developed an in-vivo mouse model of S. aureus PVMI evaluating the efficacy of different antibiotic regimen on six clinical and collection S. aureus strains. [START_REF] Revest | New in vitro and in vivo models to evaluate antibiotic efficacy in Staphylococcus aureus prosthetic vascular graft infection[END_REF] While antibiotics MICs were similar for all strains, their antibacterial efficacy was overall limited and straindependent. For instance, mice infected with Methicillin-Resistant S. aureus (MRSA) BCB8 were cured with daptomycin monotherapy while this antibiotic demonstrated no efficacy for Methicillin-Susceptible S. aureus (MSSA) ATCC 27217. To better understand these surprising results, we used the same PVMI model to visualize in situ the S. aureus biofilms structures whether treated or not with antibiotics. In particular, we focused on the interaction between immune cells and bacteria embedded in biofilms to address whether intracellular position of S. aureus could be an explanation of the lack of antibiotic efficacy in PVMIs.

Materials and methods

Based on our previous data 2 on six S. aureus clinical and collection strains, we selected the two most representative bacterial strains: one Methicillin-Susceptible S. aureus (MSSA) ATCC 27217 and one Methicillin-Resistant S. aureus (MRSA) BCB8 isolated from blood cultures. Both strains were fully sensitive to the antibiotics tested (MIC were: daptomycin = 0.125 mg/L for MRSA and 0.25 mg/L MSSA, vancomycin = 1 mg/L for both strains and rifampicin <0.006 mg/L for both strains). Antistaphylococcal agents were provided by drug companies and prepared following label instructions: vancomycin (Sandoz, Levallois-Perret, France), daptomycin (Novartis Pharma SAS, Rueil-Malmaison, France) and rifampicin (Sanofi-Aventis, Paris, France). The in-vivo experiments were approved by the French ministry of research review board and have been described elsewhere. [START_REF] Revest | New in vitro and in vivo models to evaluate antibiotic efficacy in Staphylococcus aureus prosthetic vascular graft infection[END_REF] Briefly, at least 4 Four-weeks old female Swiss mice (RjOrl/SWISS, Janvier laboratory St Berthevin, France) were used for the experiments. Sterile squares of Dacron ® were implanted into a subcutaneous pocket created in the centre of the mice back after general anaesthesia. Two days later, a saline solution containing 10 7 colony forming units (cfu) of S. aureus was transcutaneously inoculated onto the graft surface. Antibiotics treatment started two days later. All the antibiotics used were administered at dose regimens resulting in serum concentrations similar to those obtained in humans and through the respective classical routes used in mice model.

Mice were randomized into different groups: no treatment (controls); vancomycin group (subcutaneous injection (SC), 110 mg/kg/12 h); 3 daptomycin group (50 mg/kg/24 h, SC); [START_REF] Dandekar | Pharmacodynamic profile of daptomycin against Enterococcus species and methicillin-resistant Staphylococcus aureus in a murine thigh infection model[END_REF] rifampicin group (30 mg/kg/12 h, intraperitoneal); 5 vancomycin-rifampicin group; and daptomycin-rifampicin group. Mice were treated for 48 h and then euthanized following international guidelines. Immediately after the procedure, Dacron ® patches were removed and visualized with a confocal laser scanning microscope (Leica TCS SP5 Microsystems, France).

Images were acquired using a ×63 oil immersion objective with a numerical aperture of 1.4.

For all the experiments, the size of the confocal images was 512 x 512 pixels (either 215 by 215 µm² or 82 by 82 µm²), recorded with a z-step of 1 µm and a 3x zoom. For each biofilm, at least four different regions were analysed and biofilms structures were compared by direct observation. For this purpose, nucleic acids (both bacteria and eukaryotic cells) were stained with Syto9 ® (Invitrogen), able to penetrate into all cells, and propidium iodide (PI, Invitrogen), which can only penetrate into damaged-membrane cells. Syto9® and PI were excited with an Argon laser at 488 and 543 nm, respectively, and their fluorescence emissions were collected between 500-600 nm for Syto9® and between 640-750 nm for PI.

To visualize simultaneously the bacteria, the immune cells (neutrophils and macrophages), and the antibiotics, all were specifically stained to well discriminate their fluorescence emission. Neutrophils were stained with Ly-6G ® /mouse specific marker (GR-1, Pacific Blue TM conjugate RB6-8C5), excited using Argon laser at 361 nm; the fluorescence emission was collected in the range 400-450 nm). Macrophages were stained with F4/80 ® macrophagespecific antibody (Alexa Fluor® 647 conjugate BM8), excited with a Neon laser at 633 nm; the fluorescence emission was collected in the range 650-750 nm. BODIPY-FL®-daptomycin (kindly provided by Cubist Pharmaceuticals) and BODIPY-FL®-vancomycin (from Sigma) were excited at 488 nm and the fluorescence emission was collected in the range 500-550 nm.

Results

Typical structures of in vivo MSSA and MRSA-infected Dacron ® patches were illustrated in Figure 1. As expected for an infection site, high amounts of bacteria and immune cells were trapped in a dense and thick reticular extracellular matrix (Figure 1,A,B). We can also note that there are only few amounts of damaged cells after Dacron removal from mice. When antibiotics were applied, the observed structures were antibiotic-and strain-dependent. In the case of antibiotics inefficiency, the visualization of Dacron ® patches was very similar to the controls (Figure 1,E,F,I,L). By contrast, the material surface displayed lightened structures with only scattered immune cells when antibiotics were efficient (Figure 1,C,D,G,H,J,K). In more details, for MRSA BCB8, vancomycin did not show any significant effect on biofilms compared to the control samples by contrast to rifampicin and daptomycin. For MSSA 27217, the effect of daptomycin as well as vancomycin was more limited, yielding bacterial structures close to the control ones while rifampicin was the most active. The combination of rifampicin to vancomycin appeared as very efficient in the overall structure lightening, which was not the case for the daptomycin-rifampicin combination. These results all correlate with bactericidal activity measurements (Table S1). [START_REF] Revest | New in vitro and in vivo models to evaluate antibiotic efficacy in Staphylococcus aureus prosthetic vascular graft infection[END_REF] Additional observations were obtained with the fluorescent staining of immune cells and antibiotics, highlighting that: (i) the eukaryotic cells on the infection site were essentially polynuclears and macrophages (Figure 2A), (ii) live S. aureus bacteria were found inside both live and dead macrophages (Figure 2B) but not in polynuclear cells, and (iii) BODIPYvancomycin and -daptomycin were visualized in polynuclear cells but none of them penetrated macrophages load with live S. aureus bacteria (Figure 2C).

Discussion

The visualization of antibiotics within biofilm-associated bacteria may contribute to our understanding of the differential effects of antistaphylococcal agents on material-associated S. aureus infections and that was the purpose of the present study. Dacron ® implants where biofilms grown in alive mice were visualized by confocal fluorescence microscopy immediately after mice were euthanized. This procedure allowed: i) to observe in situ live bacteria interactions with the prosthetic vascular material but also with the host cells (polynuclear cells and macrophages), widely present on the infection site, ii) to correlate the biofilms structures with antibacterial activity of antibiotics (daptomycin, vancomycin and their association with rifampicin), iii) to highlight live S. aureus bacteria inside the macrophages present at the biofilm sites while antibiotics do not penetrate these immune cells.

These in vivo results are different from the ones found in in-vitro biofilm models [START_REF] Abdelhady | Impact of vancomycin on sarA-mediated biofilm formation: role in persistent endovascular infections due to methicillin-resistant Staphylococcus aureus[END_REF] that do not allow to observe the interactions between bacteria and host-cells occurring in-vivo. [START_REF] Bjarnsholt | The in vivo biofilm[END_REF] Most in-vivo models rely on bacterial counts within infected materials, but do not include imaging techniques visualizing the direct effect of antibiotics on biofilms developed in-vivo. [START_REF] Nishitani | Quantifying the natural history of biofilm formation in vivo during the establishment of chronic implant-associated Staphylococcus aureus osteomyelitis in mice to identify critical pathogen and host factors[END_REF] The S. aureus PVMI mouse model presented herein may provide original data in this field.

Our results do not reveal significant change in the biofilms structures from one S. aureus isolate to another but a differential effect of antistaphylococcal agents. We confirm the dramatic efficacy of rifampicin by comparison with other treatments, [START_REF] Nishitani | Quantifying the natural history of biofilm formation in vivo during the establishment of chronic implant-associated Staphylococcus aureus osteomyelitis in mice to identify critical pathogen and host factors[END_REF][START_REF] Edmiston | Impact of selective antimicrobial agents on staphylococcal adherence to biomedical devices[END_REF][START_REF] Senneville | Outcome and predictors of treatment failure in total hip/knee prosthetic joint infections due to Staphylococcus aureus[END_REF] probably due to its well-known great intracellular penetration and activity. Unexpectedly, daptomycin, often referred as one of the most active antistaphylococcal agent on biofilm, 11 12 can yield to very limited effects. The antibiotic was active on MRSA BCB8-related biofilm onto Dacron ® but not for MSSA 27217 biofilm. These results support previous findings showing that there is no difference between vancomycin and daptomycin activities in-vitro [START_REF] Smith | Comparison of biofilm-associated cell survival following in vitro exposure of meticillin-resistant Staphylococcus aureus biofilms to the antibiotics clindamycin, daptomycin, linezolid, tigecycline and vancomycin[END_REF] or in-vivo. [START_REF] Lefebvre | Efficacy of daptomycin combined with rifampicin for the treatment of experimental meticillin-resistant Staphylococcus aureus (MRSA) acute osteomyelitis[END_REF] We do not have a definitive explanation for such differences of daptomycin efficacy according to the staphylococcal strain but we already reported in an in-vitro model [START_REF] Boudjemaa | New insight into daptomycin bioavailability and localization in Staphylococcus aureus biofilms by dynamic fluorescence imaging[END_REF] that tolerance toward this molecule may be related to a physiological change involving structural modifications of the membrane, a strain-dependent process.

Previous literature findings have reported the capability of S. aureus to survive within osteoblasts in the context of bone and joint infections, resulting in persistent and relapsing infections. [START_REF] Valour | Delta-toxin production deficiency in Staphylococcus aureus: a diagnostic marker of bone and joint infection chronicity linked with osteoblast invasion and biofilm formation[END_REF] We visualize here the same possible capacity to survive inside host cells (i.e., macrophages) during S. aureus PVMIs. An important consequence of such process is that intramacrophagic S. aureus are able to escape the phagolysosome, leading to free replication in the cytoplasm. This can trigger cell death mechanisms from its host cell, multiply actively and disseminate, but also activate anti-apoptotic programs to persist hidden in intracellular position and induce chronic or relapsing infections. [START_REF] Fraunholz | Intracellular Staphylococcus aureus: live-in and let die[END_REF] In addition, intramacrophagic position could represent a shelter for S. aureus against antibiotics: the less able to penetrate host eukaryotic cells they are, the less efficient they could be. Thus, we hypothesize that the persistence of S. aureus inside macrophage during PVMIs could be an explanation to the relative inefficacy of antibiotics without surgery during these infections, and to the high risk of relapse when the infected material is not removed. This could also explain why antibiotic efficacy could be different according to the strain involved, since the capability of S. aureus to invade mammalian cells could vary from one strain to another. [START_REF] Scherr | Staphylococcus aureus Biofilms Induce Macrophage Dysfunction Through Leukocidin AB and Alpha-Toxin[END_REF] This study presents some limitations. First, the site of vascular prosthetic material implantation. For evident technical reasons, it was impossible to implant our Dacron ® along the vascular system. Some authors already described extra-anatomic animal model, with implantation of vascular material in subcutaneous position, to evaluate different prophylactic procedure to prevent PVMIs. [START_REF] Cirioni | Daptomycin and rifampin alone and in combination prevent vascular graft biofilm formation and emergence of antibiotic resistance in a subcutaneous rat pouch model of staphylococcal infection[END_REF] Nevertheless, in a clinical setting, most PVMIs occur from the wound or from an adjacent infectious focus and not through hematogenous route. [START_REF] Jones | Mechanism of late prosthetic vascular graft infection[END_REF] Therefore, the infection process usually starts along the external part of the vascular prosthesis, not the endoluminal layer. In this context, our model reproduces this natural history of infection and may be reasonably used to evaluate different antibiotic regimens for PVMIs treatment.

The limited number of evaluated bacterial strains could be a second weakness of our work.

This study follows a previous published work [START_REF] Revest | New in vitro and in vivo models to evaluate antibiotic efficacy in Staphylococcus aureus prosthetic vascular graft infection[END_REF] dealing with the antibiotics activity on six different S. aureus strains in our mouse model of PVMI. Similar results were obtained for MSSA or MRSA strains and thus, we selected the two more representative bacterial strains to allow more demonstrative differences in the aspect of in-vivo biofilm developed onto Dacron ® upon antibiotics action.

In conclusion, this in-vivo mouse model of S. aureus PVMIs allows the direct observation of the impact of major antistaphylococcal agents on Dacron ® -related biofilm. We visualized intramacrophagic S. aureus onto the biomaterial and we hypothesize that intramacrophagic S. aureus could be also present during PVMIs in clinical settings and may explain why bacteria may persist, and relapse, even after prolonged and appropriate antibacterial therapy. More studies are needed, but we can postulate that the use of antibiotics active against biofilmembedded and intracellular bacteria such as rifampicin could be a very good option in PVMIs.

Figure 2 :

 2 Figure 2: S. aureus bacteria are localized in macrophages that daptomycin and vancomycin cannot penetrate. A: identification of eukaryotic cells. Green staining: Syto9®; Blue staining: Ly6G®(neutrophil polynuclear specific staining); Red staining: F4/80 (macrophages specific staining). Yellow arrow: intramacrophagic live S. aureus (observed on biofilms treated or not with vancomycin and daptomycin). B: antibiotic staining. Yellow staining: BODIPY-FL-vancomycin or -daptomycin; Blue staining: Ly6G® (neutrophil polynuclear specific staining); Red staining: F4/80 (macrophages specific staining).

Acknowledgements

The authors want to acknowledge the Collège des enseignants des Maladies Infectieuses et Tropicales (CMIT) and the Société Française de Pathologie Infectieuse de Langue Française (SPILF) for their support. They also want to acknowledge Prof. Erwan Flecher who kindly provided the Dacron ® .

Funding

This work was support by a grant from the Collège des enseignants des Maladies Infectieuses et Tropicales and by a grant from the Ministère de l'Education Nationale et de la Recherche, Université Paris-Sud, for the PhD thesis (grant n° 2014-172)

Transparency declarations

Nothing to declare


Christophe Lohr

Philippe Tanguy
email: philippe.tanguy1@telecom-bretagne.eu

Jérôme Kerdreux
email: jerome.kerdreux@telecom-bretagne.eu

A Distributed Infrastructure for Heterogeneous Ambient Devices

Keywords: Home automation networks, interoperability, ambient assisted living. 2010 Mathematics Subject Classification: 68, 68M12, 68M14

Ambient assisted living systems are based on sensors and actuators, with a diversity of network protocols and vendors. This commonly leads to the introduction of gateways or middlewares into the technical infrastructure in order to address interoperability issues. The xAAL framework presented in this paper aims to provide interoperability and to redesign such "gateways" into well-defined functional entities communicating with each other via a lightweight message bus over IP. Each entity may have multiple instances, may be shared between several boxes, and may be physically located in any box. Thanks to the distributed architecture of the system, each home automation vendor may peacefully provide its own xAAL box without revealing details of its technology. Also, several applications may be plugged together on the xAAL bus without getting bored with underlying heterogeneity. Moreover, the management of the dynamicity allows sensors or applications to enter and leave the system at any time.

Introduction

Ambient assisted living (AAL) systems focus on improving quality of life by offering integrated products and services for an enhanced living experience. Technical platforms and proposed solutions may include mobile applications, tablets, connected TVs, plain old telephone systems, fellow robots, home automation devices, innovative physiological sensors, actigraphy, coaching services, serious games, social interactions, etc. However, to provide intelligent services, one needs to access physical devices, sensors, and actuators. As it is not realistic for a service provider to reinvent the needed sensors and actuators, it then has to face to a pragmatic issue: interoperability of underlying existing (and possibly already deployed) technologies.

For instance, an AAL system may propose actigraphy services based on the user activity monitored by existing home automation sensors. Many vendors offer home automation solutions. Small devices are plugged everywhere at home. They talk to each other using dedicated link layers and protocols (specific powerline channels, radio channels, data coding scheme, cryptography key, etc.). There are almost as many protocols as manufacturers (or alliances of manufacturers). The consequence is a strong issue about interoperability: how to make a device from vendor A (e.g., a switch) talk with a device from vendor B (e.g., a lamp), and then, how a smart service may collect data or activate a device of some vendor when it needs to. Let us assume that the user wants health-care services with innovative physiological sensors using yet another communication protocol. Should it be a new system separated from the previous one or could it be integrated with it, and how? These are usual practical questions that ALL systems have to tackle. This is not only a matter of technique; this is also a matter of concepts and design.

The rest of the paper is organized as follows. In Section 2, we investigate the main streams to enable interoperability in AAL systems. Section 3 presents our xAAL solution. Finally, Section 4 summarizes conclusions and outlines future work.

Interoperability Issues in AAL Systems

Issues and Existing Solutions in AAL Systems

One of the main issues in home automation systems is the choice of a communication protocol. There are well known protocols (Z-Wave [START_REF]Z-Wave Alliance[END_REF], KNX [START_REF] Knx | [END_REF], EnOcean [START_REF] Enocean | [END_REF], etc.) and some of them are widely used; however, their interoperability is not well considered. Therefore, if someone wants to use a sensor using Z-Wave with an actuator using KNX, it is not feasible without a special gateway in charge of the interoperability between both protocols. In the past, it was not necessarily a big problem. Indeed, when a home automation system was installed, sensors/actuators using the same communication protocols were deployed.

The number of different protocols in home automation systems is the result of several factors. First of all, sensors and actuators do not have the same characteristics in terms of the following:

-Throughput and bandwidth -Usual central frequency: 433 MHz, 868/915 MHz (Eu/Usa), 2.4

GHz.

-Range -Wireless area network, body area network, etc. Devices handling Bluetooth or 802.15.4 do not have the same range.

-Problem of spectral occupancy, interference -Occurs especially in the ISM band at 2.4 GHz.

-Energy consumption -It is a critical topic that has a deep impact on the PHY and MAC layers. A lot of devices are battery powered, and it is not acceptable to change them every day, month, or year.

Those characteristics have a deep impact on the PHY and MAC layers. On the other hand, sensors and actuators are dependent on application domains. Indeed, for e-health (health care based on electronic communication means) and m-health (mobile health) applications, sensors will use WiFi or Bluetooth 4.0 because they are well deployed in smartphones. In the home automation domain, historical vendors have developed their own solution, e.g., X2D [START_REF] Dore | Delta Dore website[END_REF] (Delta Dore), to switch lights on and off, or to pull roller shutters up and down. Finally, the business model has a deep impact on the system architecture currently deployed in a house. The consumer is facing a captive market: few providers with solutions that cover every needs, with few chances to add equipment from others. That is why, the common architecture is composed by a network of sensors/actuators speaking the same proprietary protocol and a gateway gathering all the messages. The gateway also plays the role of manager with an administration interface and offers a connection with Internet to develop access via a mobile application. Nowadays, new services appear, like actigraphy, e-health, preventive care, etc. Health and wellbeing applications are growing, and new devices are proposed on the market every month. They often use smartphones as access points to communicate first in Bluetooth or WiFi, then on Internet in 3G/4G or WiFi. Those new applications also need to use several data from different sensors using different communications protocols to quantify activity, sleeping quality, and environment to give a specialized feedback to the user in order to advice that person to have a healthy life. One of the ideas of preventive care, like in the PRECIOUS project [28], is to change user behavior or to advice the user to have a healthy life and reduce cardiovascular disease or type II diabetes. To achieve this goal, it appears that a model in charge of analyzing user behavior needs a lot of data from different sources like home sensors, social networks, physiological sensors, activity trackers (wearable devices), etc. In new AAL systems, it is necessary to have a seamless sensor/actuator layer to aggregate a huge quantity of data and to allow easy access to developers of new applications for AAL systems.

The main challenge is the interoperability between devices. Actually, there is a lack of standardization in the home automation systems. In the past 10 years, a lot of initiatives, alliances, or standards appeared, like ZigBee, EnOcean, or Z-Wave; however, they still do not promote interoperability with other alliances or standard. At the same time, the AAL domain has been developed in the research domain, and different solutions have been proposed about the interoperability between heterogeneous devices. The next section provides a short review of research and solutions proposed to solve the problem of interoperability between heterogeneous devices used at home.

Proposed Solutions for Home Automation Interoperability

As shown in the previous section, a transparent sensor/actuator layer is needed to propose more ambitious AAL systems. In the literature, we focused our attention on existing solutions in the domains of personal health system architectures, smart home/home automation architectures, smart home, and health system architectures; communications protocol related to the e-health/m-health domain; and communications protocol related to the smart home domain.

Existing solutions have been classified in three categories: protocol of communication, middleware, and architecture/framework. For those three categories, common mechanisms (or functionalities) are used to achieve interoperability. Indeed, most of the solutions have similar components or functionalities that are essential for a system including heterogeneous devices:

-Addressing is an essential functionality to send/receive information to/from devices. Several techniques can be employed, e.g., UUID, IP address, etc.

-Description gives information about the functions available on a device.

-Discovery mechanism gives information to the system about the available devices.

-Communication protocol is the way a device shares its functionality or information.

-Security and privacy are now a necessity to protect user information.

-Store/cache data are essential for sensors that are not queryable, or to verify the state.

Those criteria are used to classify solutions for each of the previous three categories.

Communication Protocols

Standards, consortiums, or alliances are potential solutions to solve the problem of interoperability. Indeed, one can dream of a unique protocol interconnecting every smart devices. The reality is totally different in the smart home domain where there exist several initiatives (e.g., ZigBee, EnOcean, etc.). On the other hand, in the e-health/m-health domain, other protocols or standards are used, e.g., CEN ISO/IEEE 11073, ZigBee alliance [START_REF] Zigbee | [END_REF] or Bluetooth. All of these initiatives are trying to solve the interoperability at a low level; however none of them have established themselves.

Standards are important to allow a better acceptance of one technology by manufacturers, vendors, and users. Like that, interoperability issues can be reduced between smart devices in the same domain. However, in smart home or e-health domains, it is not feasible to have one unique protocol for gathering data from sensors. Business model, frequency, range, throughput, power consumption, physical size, and cost are reasons to explain the diversity of communication protocols. Solutions about communications protocols can be separated into two subcategories: low level and high level. In the first one, we have a communication protocol defining the PHY and MAC layers, and is generally dedicated to devices with constrained resources. The most popular protocols in the smart home domain are KNX, EnOcean, Z-Wave, and ZigBee/IEEE 802.15.4. In the ehealth and m-health domains, there are Bluetooth, ZigBee, ANT/ANT+, etc. In the second one, only communications protocols defining upper layers (e.g., MQTT, XMPP, CoAP, or UPnP) are considered. In Reference [START_REF] Vasseur | Interconnecting Smart Objects with IP: The Next Internet[END_REF], Vasseur and Dunkels explain why interconnecting smart objects with IP is a good solution to develop interoperability. However, it is currently not feasible to deploy a full IP stack on small and smart devices. That is why a compromise has to be found between low-level networks focused on power consumption, physical size, and cost, and high-level protocols. Several solutions trying to solve interoperability issues with high-level protocols have been identified, as shown in Table 1. For example, xPL/xAP is widely used in home automation. It is based on a simple text-based protocol (JSON like) and a single transport (UDP broadcast). However, xAP mixes type and address, and both protocols use a non-standard text format. Reciprocally, UPnP SOA, OSGi-based SM4ALL [START_REF]SM4ALL, SM4ALL European Project[END_REF] SOA, OSGi-based Hydra [START_REF] Hydra | Hydra project[END_REF] SOA Device manager Discovery manager P2P, SOAP tunneling, JXTA backbone EnTimid [START_REF] Nain | Un modèle de composants pour intégrer des objets communicants dans des applications à base de services[END_REF] OSGi-based Component model Message oriented (Pub/Sub)

universAAL [27] OSGi-based UPnP, R-OSGi
is used in home automation products and use a standard implementation based on a strong and clear specification. However, it uses a lot of protocols, events are hard to tailor, it is generally too big to fit in embedded devices, and there are some problems concerning security. Communications protocols defining upper layers than IP are an interesting solution to fight interoperability issues. They allow choosing the network topology, i.e., distributed or not. They allow flexibility, and the network can be extended easily. They do not impose one specific programming language. However, they need to develop gateways to integrate all existing sensor/actuator networks. Finally, a solution based on a communications protocol needs to be widely adopted to guarantee the success of the solution.

Middlewares

Middleware solutions are attractive because a software layer between hardware and applications offers dynamicity and flexibility. The middleware domain is wide with different kind of solutions like SOA-based [START_REF] Amigo | AMIGO European project[END_REF] or model-driven [START_REF] Nain | Un modèle de composants pour intégrer des objets communicants dans des applications à base de services[END_REF] solutions. Several existing middlewares dedicated to AAL have been compared in Table 2. Another review of middleware solutions used for a smart home can be found in Reference [START_REF] Ullah | State of the Art: Embedded Middleware Platform for A Smart Home[END_REF]. The Amigo project [START_REF] Amigo | AMIGO European project[END_REF] defined a middleware to provide a transparent layer related to heterogeneous devices. Four categories of devices have been identified and classified according to their resources. For example, the Legacy Amigo device cannot embed the Amigo middleware compared with Full Amigo home automation devices. Resourceconstrained devices in home automation with their own proprietary protocol are still an issue because it is not currently feasible to embed a middleware layer. Similarly, the SM4All project [START_REF]SM4ALL, SM4ALL European Project[END_REF] defines a pervasive layer where functions of sensors/actuators and devices are exposed as services. Like in Amigo, small devices in terms of resources do not use the SM4ALL middleware, and the interoperability between small devices is realized in one gateway, thanks to the OSGi framework. In 2010, the Hydra project [START_REF] Hydra | Hydra project[END_REF] proposed a middleware usable in three different vertical domains: home automation, e-health, and agriculture. Like Amigo, Hydra separates the devices in non-hydra-enabled devices, hydraenabled devices, and gateways. As we can see, resource-constrained devices are not well adapted for middleware solution. Consequently, the interoperability between devices is often realized by one gateway using the OSGi framework and centralizing all the home automation networks.

More generally, middleware initiatives did not well consider the communication between instances on different nodes (devices). More recently, the universAAL project [START_REF] Universaal | universAAL European project[END_REF] proposed a middleware (based on the PERSONA middleware [START_REF] Amoretti | The PERSONA AAL Platform: Deployment in the Italian Pilot Site of Bardi[END_REF]) solution dedicated to new services and deployment solution in the AAL domain. The middleware allows communicating between several uAAL nodes, [START_REF] Guinard | A Web of Things Application Architecture -Integrating the Real-World into the Web[END_REF] web-based Metadata model, REST+microformats

Local lookup and discovery service web standards openHAB [START_REF]openHAB, openHAB project[END_REF] OSGi-based Non intrinsic DOG gateway [START_REF] Bonino | The DOG gateway: enabling ontology-based intelligent domotic environments[END_REF] OSGi-based Ontology API, XML-RPC IoT-A [START_REF]IOT-A European project[END_REF] Ref. model Rules to build interoperable stacks BUTLER [START_REF] Butler | BUTLER European project[END_REF] OSGi-based, API REST/JSON Java API (same HW device) or HTTP Eclipse M2M project [START_REF]Eclipse, IoT Eclipse -Services & Frameworks[END_REF] Framework MQTT, M3DA

thanks to the peering component. Then, communication can be established between uAAL nodes using the same protocol stack like UPnP or R-OSGi in the so-called AAL space. However, the interoperability between home automation devices is still managed by OSGI in one gateway. Consequently, the distributed approach of universAAL is lost for resourceconstrained devices.

Architecture/Framework

Some solutions provide a whole architecture or a framework. Indeed, AAL systems providing more elaborate services cannot be only built around a protocol or a middleware. Most of the time, they define gateways, servers, services, and communication protocol between all components inside the architecture. Several architectures dedicated to AAL systems are compared in Table 3. According to the table, OSGi is often used to manage interoperability between heterogeneous devices. Home automation protocols are implemented in OSGI bundles, which allow the interoperability between devices in one gateway. The main drawback is that the network topology is fixed. Indeed, the gateway centralizes all the low-level protocols in the same physical place. Another approach, called Web-of-things, has been proposed by Guinard in Reference [START_REF] Guinard | A Web of Things Application Architecture -Integrating the Real-World into the Web[END_REF] and consists in using Web standards to manage the heterogeneity between Internet-of-thing devices. Therefore, the main idea is to bring wireless sensor networks to the Web and use Web standards together with a RESTful architecture. Indeed, Guinard argues that if Web standards have proven in the past that they can connect millions of heterogeneous computers, it may be a good idea to do the same with Internet-of-things. An architecture allows horizontal interoperability between domains: smart home, e-health, mhealth, smart transport, and smart city [START_REF] Butler | BUTLER European project[END_REF][START_REF]IOT-A European project[END_REF]. To manage interoperability, several options are offered to a designer of AAL systems: a unique protocol, a middleware, or a hybrid solution. An architecture needs to deploy several software/hardware components. In that case, designers need to know several technologies (server, gateway, standards, etc.) and different protocol of communications. The deployment of those solutions is generally a task that needs several skills. Finally, complex architectures and systems involve problems in terms of maintenance and reliability.

Findings of the Survey

Solutions exist to address the interoperability issues. Almost all solutions play around the idea of a socalled gateway often implemented with middleware: a box (a small computer) is equipped with two or more modules, each module talking in a given home-automation protocol; then, a piece of software over those modules make it possible to forward messages between protocol A and protocol B. Moreover, those boxes embed additional functions to make all of these usable: HMI (via Web and/or smartphones), configuration facilities, connectors to extra services in the cloud, etc. Such solutions are partial from the interoperability point of view, as each box manages a limited number of low-level protocols, and boxes are hardly able to talk to each other.

There is also a key point about applications. Thanks to middleware approaches, those boxes are also designed to be the dedicated place to run applications. Boxes are not only the gateway for lowlevel physical devices, but they also act as a hub for applications and smart services. Everything that should cover all needs is in the same box: home automation, alarm, telemedicine, actigraphy, etc. Thus, the box provider should provide everything by itself, or should ask (beg) third parties to offer components for its box, based on strong specifications of means to plug such add-ons. Brønsted et al. [START_REF] Brønsted | The Homeport System[END_REF] noticed that "with an approach using a central server, it is more difficult to obtain a balanced business relationship between market actors since one actor is likely gain dominance over the server."

One should also consider sporadic devices. For instance, a newly connected TV may embed applications, which is an opportunity. A TV is not supposed to be mobile, but it may be on or off depending on the time of the day. Moreover, mobile devices such as smartphones or tablets are nowadays common. This may be interesting from the AAL point of view: they embed sensors relating to user activity, and they can run applications. However, such devices may enter or leave the system at any time. This poses questions about means to interconnect such mobile devices to the above-mentioned boxes.

Starting from those basements, we decided to reorganize and formalize the architectures of those boxes, which are in fact all composed of the same functionalities. Therefore, we propose to split functionalities into well-defined functional entities, communicating to each other via a message bus over IP. Each entity may have multiple instances, may be shared between several boxes, and may be physically located in any box. Thanks to the distributed architecture of the system, the xAAL solution can address interoperability. Each sensor's family, each vendor, may peacefully provide its own xAAL box without revealing details of its technology.

Descriptions of the xAAL Solution

xAAL is basically a distributed architecture. A set of functional entities is defined. Those entities may be present several times, be implemented separately and/or grouped into hardware components of various manners, and talk to each other via a message bus.

Functional Architecture

Figure 1 shows the general functional architecture of the xAAL system.

Native equipment: Some devices (sensors, actuators) can communicate natively using the xAAL protocol.

Gateways: In general, home automation devices only support their own proprietary communication protocol. Gateways translate messages between the manufacturer protocols and the xAAL protocol. This is the very classical function found in all other home box solutions. This part is very specific to manufacturers' technologies. It may be the role of vendors to provide it by themselves. All other functions may be shared.

Schema repository: Home automation devices are described by a schema (the nature of the equipment, how to interact with it). These schemas are listed in one or more schema repositories that can be queried by other entities. Those repositories may be fed with specific schemas describing the vendor's devices. Some usual schemas are generic.

Database of meta-data: Each automation device within a facility is likely to be associated with a piece of information: at least location information (e.g., declare that the equipment typed as a lamp and having address X is located in the kitchen) and possibly a symbolic name (e.g., device having address X is called "lamp#1"). This information is stored as a set of tags in one or more databases of meta-data. Those databases somehow contain the configuration of the home automation installed.

Cache: Some sensors can just send information in a sporadic way (e.g., a thermometer that sends the temperature data only if it changes). One or more caches store this information (with a timestamp) so that other entities can query them whenever necessary.

Automata of scenarios: Scenarios are advanced services like, for example, start a whole sequence of actions from a click of the user, or at scheduled times, or monitor sequences of events and then react, etc. To support it, one may have one or more entities of the type automata of scenarios. AAL services usually imply some actions to be triggered locally close to the user at home, and some other actions to be computed somewhere in the cloud. Automata of scenarios are dedicated to the former.

These automata of scenarios are also the right place to implement virtual devices: for example, a scenario could aggregate and correlate a variety of events from real devices, and then synthesizes information such as "presence" and notify it on the bus, in order to be used by other entities. By proceeding in this way, this scenario should appear by itself as a device on the bus, with its address and its schema. This scenario is a kind of a virtual device.

User interfaces: One or many user interfaces are provided by specific entities connected to the xAAL bus. This can be a real hardware device with a screen and buttons, or a software component that generates Web pages (for instance) to be used by a browser on a PC, a connected TV, or other devices; or software that provides a REST API for mobile applications (tablets, smartphones), to an external server on the cloud for advanced services, to an MQTT server, or to offer features for service composition, etc.

The typical workflow of an HMI could be as follows: (i) query the bus to be aware of the present devices; (ii) query the schema repository for the type of these devices, the type of data from the sensors/actuators, the possible actions, and URLs to retrieve icons; (iii) query the database of meta-data about devices to get the configuration of the installation (a friendly name to display, location, and other tags associated with each device); (iv) query the cache for the latest known states of such equipment; and, finally, (v) dynamically build display screens and control interfaces for these devices.

Devices and Schemas

Devices are identified by a unique address on the bus. This is a UUID (RFC 4122): the textual representation of a 128-bit random number. Address 0 is reserved for broadcast and refers to all devices. Device address may be assigned in the factory, or autogenerated (random) at installation time. However, it is recommended that this address remains persistent, e.g., after power breaks.

A device has a type, i.e., a schema name. This name is a string consisting of a pair of words separated by a dot. The first word refers to a class of device type (e.g., lamp, heating, multimedia, etc.). The second word refers to a specific type in a given class (e.g., within the lamp class, one may have lamp.basic, lamp.trigger, lamp.dimmer, etc.) The second word may also refer to a schema extension by a manufacturer. The identifier "any.any" is reserved and refers to all types of all classes.

The schema associated with a device provides semantics to a device and describes its capabilities: a list of possible methods on this device (mechanism of request-response), a list of notifications that it sends spontaneously, and a list of attributes (a device announces any change of values on the bus). Those schemas are inspired by the UPnP approach [START_REF]UPnP Device Architecture 1.1[END_REF].

There is a notion of inheritance between schemas. A schema can extend an existing schema. We define the first three levels of this genealogy: (i) a generic schema common to all existing devices worldwide that everyone has to implement; (ii) a specific schema for every class (e.g., lamp, thermometer, switch, etc.) -such specific schemas thus inherit from the generic schema; and (iii) a specific schema for each type that inherits from a class schema, which indicates the level of functionality (e.g., a lamp type can be on/off, some are of a trigger type, and others with dimmer, etc.). Thereafter, manufacturers of home automation equipment will naturally define their own schemas among their product range that will inherit of schemas of level three.

Messages

Messages are transported by an IP multicast bus (IPv4 and/or IPv6). As proposed by UPnP [START_REF]UPnP Device Architecture 1.1[END_REF], a bus allows the discovery: when a new component appears in the installation, it announces itself. All other entities can then take it into account. Similarly, when a new component enters, it can query the bus to discover the other components already present. This greatly facilitates the configuration and allows dynamicity. However, UPnP use the multicast bus only for discovery, not for transmission of data or control/command that therefore requires a large set of point-to-point TCP communications between UPnP devices (plenty of call-backs to get notifications).

We choose JSON [START_REF] Galiegue | JSON Schema: core definitions and terminology draft-zyp-jsonschema-04[END_REF] as the exchange format on the bus. Many libraries are available in many development environments. A message consists of a header and a body. The header is mandatory, while the body is optional. Figure 2 gives an example of xAAL messages. The header of a message includes the source and destination addresses of the message. A destination address of 0 means a broadcast message: everybody is invited to filter the relevance of the message based on the device type (name of the schema). Note that device type mentioned by the requester may contain the keyword "any" to widen the broadcast request. The body contains parameters and values for

Figure 1 :

 1 Figure 1: Functional Architecture of xAAL.

Table 1 :

 1 Protocol of Communication Related to Smart Home Domain

	Protocols	Description Discovery	Com. sublayer	Event	Security
	xPL/xAP [31] Type based Heartbeat broadcast UDP broadcast	UDP broadcast
	UPnP [12]	XML	SSDP	SOAP	GENA	TLS
	DPWS [24]	WSDL	WS-Discovery	SOAP/HTTP, SOAP/UDP WS-eventing	WS-Security
	CoAP [17]	URI	Built-in	UDP, SMS, TCP (possible) Asynchrous notification DTLS
	MQTT [20]	MQTT topic Pub/sub	TCP/IP	Pub/sub	SSL
	AgoControl [1] Schema	Device announce	AMQP		SSL (AMQP)

Table 2 :

 2 Middleware Related to Smart Home

	Architecture	Type	Description	Discovery	Communication
	Amigo [3]

Table 3 :

 3 Architecture Related to Smart Home

	Architecture	Type	Description	Discovery	Communication
	Web-of-things

This project has received funding from the European Community's Seventh Framework Program for research, technological development and demonstration under grant agreement No.611366 (PRECIOUS).

{ "header": { "version": "0.2", "source": "bd081741...9657", "target": "83c84e87...65a0", "devType": "thermometer.queryable", "msgType": "request", "action": "getAttributes", "cipher": "none", "signature": "" } } { "header": { "version": "0.2", "source": "83c84e87...65a0", "target": "bd081741...9657", "msgType": "reply", "devType": "thermometer.queryable", "action": "getAttributes", "cipher": "none", "signature": "" }, "body": { "temperature": 9.3 } } queries, responses, and notifications, if needed. The body is optional: it depends on what has been defined in the schema for the mentioned action.

In the above example, there is no encryption ("cipher:none"). One keeps the possibility of communicating without encryption. However, one may have "cipher:md5" with the signature of the message with a shared key; to avoid replay attacks, a timestamp parameter is added in the message before signing.

Experiments

Nowadays, a prototype of the xAAL solution is developed in C and in Python. Both implementations [START_REF]xAAL -Home-Automation Interoperability[END_REF] are proposed to the open-source community, which is very active on home automation solutions. In the meantime, several experiments were carried out in the form of student projects with the collaboration of some of our industrial partners (mostly small to medium enterprises and startups).

xAAL is deployed in our Experiment'HAAL living'lab. It can manage X2D, KNX, and Z-Wave devices: lights, shutters, door-opening sensors, heating, water flow sensors, pressure sensors, etc. Ad-hoc xAAL-native devices are prototyped using GrovePi hardware platform, which allows connecting Grove sensors/actuators with a Raspberry Pi [START_REF] Grovepi | GrovePi project[END_REF][START_REF] Pi | Raspberry pi foundation[END_REF].

We drove experiments to interface a Nao robot (by Aldebaran Robotics [START_REF] Aldebaran | [END_REF]) to the xAAL bus of our living'lab. The robot acted like a remote control for the home automation system thanks to its voice recognition facility, and as an alerting device with its gestures and voice. For instance, the user says "Nao, morning scenario please!", then Nao makes a gesture to the direction of the windows and says "I raise shutters." while sending the corresponding xAAL query; then, it does the same to switch off the lights of the bedroom, switch on lights of the bathroom, etc. If the tap water remains open after the user leaves the bathroom, the xAAL system detects it and sends a dedicated notification to Nao that puts its hands on his head and says "Oups! I think the tap water is still open." The idea is to bring a kind of presence near lonely people. The xAAL ecosystem eases developing such smart services.

Conclusion

AAL systems are usually based on a set of subsystems that are vendor dependent or technology specific. This leads to interoperability issues. To handle this, several middlewares or gateways have been proposed, at the cost of extra overhead and constraints between actors involved in an AAL system.

This article has presented xAAL, which provides the same functionalities as existing solutions for interoperability. However, the xAAL solution is more lightweight (only small JSON messages), and, thanks to its distributed architecture, many components may be shared between actors of the market. The use of communication bus over IP allows vendors to freely distribute their products (with an IP socket) without entering within a middleware or a box handled by a competitor. More comprehensive documentation and codes are provided on the project site [START_REF]xAAL -Home-Automation Interoperability[END_REF].

Some points of the xAAL proposal have to be further explored. For instance, xAAL schemas are based on the JSON schema dialect [START_REF] Galiegue | JSON Schema: core definitions and terminology draft-zyp-jsonschema-04[END_REF]. Unfortunately, the corresponding RFC is not yet stabilized; this is still a draft.

A second point is about end-user services. Our first experiments with xAAL are based on classic home automation scenarios. One needs extra experiments involving pure AAL scenarios (actigraphy, health care, etc.). One then may enhance xAAL automation components to become platforms for hosting applications. Approaches extending the white-board paradigm, such as the CSTBox [START_REF] Zarli | CSTBox[END_REF], seem promising.

The last point is about the use of assistive robots in the context of AAL services. We drove experiments to interface a Nao robot to the xAAL bus of our living'lab, with success. However, for a better interconnexion between the home and robots in general, xAAL could be interfaced to ROS (robot operating system), as proposed by Roalter et al. [START_REF] Roalter | A Middleware for Intelligent Environments and the Internet of Things, Ubiquitous Intelligence and Computing[END_REF].

Author information

Christophe Lohr, Telecom Bretagne, Technopôle Brest-Iroise, CS 83818, 29238 Brest Cedex 3, France. E-mail: christophe.lohr@telecom-bretagne.eu


Pratibha Mitharwal
email: pratibha.mitharwal@telecom-bretagne.eu

Christophe Lohr
email: christophe.lohr@telecom-bretagne.eu

Annie Gravey
email: annie.gravey@telecom-bretagne.eu

Boosting NEMO with Multi-Path TCP

This paper is focused on boosting network mobility Basic support protocol (NEMO) with the help of existing Multi-Path TCP (MPTCP). In this paper, the network mobility is studied in context of vehicles. The current NEMO relies on tunneling in order to use multiple available interfaces on a vehicle but does not reach the goal to provide optimum multi-homing benefits because it is unable to balance the traffic over available network interfaces. Moreover in NEMO, the nodes behind the mobile router cannot participate in multi-homing as the mobile router installed on the vehicle makes the mobility transparent to the nodes. In this paper, we propose to combine NEMO with MPTCP which enables the host nodes to participate in mobility and multi-homing and thus improving throughput, handover performance and avoiding excess tunneling.

I. INTRODUCTION

With the evolution of technology the demand for connectivity especially "anywhere and everywhere" has increased. Users want to be connected with the rest of the world via Internet irrespective of their current location as well as through different access technologies. The movement of the user/network invokes a change in its IP address and it is no more reachable from its previous IP address. This breaks the ongoing communication as the conventional TCP sockets are bound to network identifiers (IP addresses). To maintain the ongoing communication, the traffic has to be redirected towards user's new acquired IP address from its current network point of attachment. This traffic redirection also happens during multihoming. In multi-homing a user has more than one active network interfaces at the same time. The conventional TCP makes it impossible to use more than one network interfaces simultaneously for an ongoing communication.

Mobility and multi-homing share one common feature i.e., having to carry a given flow over different network interfaces. During mobility it is due to change in IP address while in multi-homing it can be due to path disruption or an attempt to split the connection over all available network interfaces. The simultaneous use of all the available network interfaces can improve throughput, provide load balancing and make the system more resilient. With an increased demand for connectivity there is an increased demand of bandwidth as well as throughput. Therefore, mobility combined with multi-homing can be beneficial in improving mobility, making handover smooth and increase throughput. This need to solve host/network mobility and multi-homing has resulted in many proposals. All the solutions for mobility provide location management of the host/network and all present pros and cons with respect to deployment, infrastructure changes, handover delay, throughput, tunneling overhead etc.

Most of the mobility protocols are network layer based to easily provide location management. In order to perform "make before break" mobility, the mobility solution requires the transport layer informations regarding RTTs, congestion or path disruption. In absence of this collaboration between network and transport layer, the mobility protocols achieve "break before make", which causes extra handover delay for the flow. However, transport layer solutions need a mechanism for location management. This leaves a room for improvement.

In this paper, we present a solution for multi-homed mobile networks combining network layer approach NEMO with transport layer approach MPTCP in order to achieve better mobility support with optimum multi-homing support in terms of reduced cost, improved through put and load balancing. NEMO is used for location management and network mobility while MPTCP is used for improving multi-homing and enable host to participate in multi-homing related decision making. Moreover, the proposed combination requires minimal infrastructure changes. In section 2, we present the state of art. Section 3 describes the proposed architecture, its signaling and its benefits. Section 4 presents the comparison between classical NEMO and proposed NEMO with MPTCP. Finally we present our conclusion and future work.

II. STATE OF ART

There have been several attempts to solve mobility and multi-homing. NEMO [START_REF] Devarapalli | Rfc 3963 network mobility (nemo) basic support protocol[END_REF], [START_REF] Bernardos | Nemo: Network mobility. bringing ubiquity to the internet access[END_REF], Locator/Identifier Separation protocol (LISP) [START_REF] Farinacci | The locator/id separation protocol (lisp)[END_REF], Identifier Locator Networking protocol (ILNP) [START_REF] Bhatti | Identifier-locator network protocol (ilnp) architectural description[END_REF] are some of the solution to support network mobility. While Mobile IP [START_REF] Perkins | Mobile networking through mobile ip[END_REF], Multi-Path TCP (MPTCP) [START_REF] Ford | Rfc 6824: Tcp extensions for multipath operation with multiple addresses[END_REF], Host Identity Protocol [START_REF] Moskowitz | Host identity protocol[END_REF] are some of the solutions to provide host mobility and multi-homing.

NEMO is a network layer protocol and provides location management using an anchor point in its home network which takes care of the movement of mobile network. Another network layer protocol is LISP which is the most scalable solution for mobility and multi-homing [START_REF] Farinacci | The locator/id separation protocol (lisp)[END_REF]. LISP introduces a new naming convention as end-point identifiers (EID) which are valid only inside the network and routing locators (RLOC) which are valid for locating the networks. In attempt to provide location management it introduces a mapping system which provides a mapping between EID and RLOCs. The routing in between networks is done by encapsulating the packets with its RLOC. In both LISP and NEMO, hosts inside the mobile network does not participate in mobility or multi-homing. Differently from NEMO and LISP, MPTCP is a transport layer protocol which attempts to provide host mobility and multihoming support. MPTCP provides load balancing by spreading the traffic over all the available network interfaces.

There are several proposal to combine network layer approach with transport layer in attempt to improve mobility support with multi-homing. In [START_REF] Bagnulo | Boosting mobility performance with multipath tcp[END_REF], there is novel combination of MIPv6 and MPTCP which improves host mobility and multi-homing. However, it does not support mobility for a whole network. In [START_REF] Coudron | Cross-layer cooperation to boost multipath tcp performance in cloud networks[END_REF], there is a combination of LISP and improved MPTCP in order to improve multi-homing benefits to the host. However, LISP requires major infrastructure changes in conventional Internet and also it introduces a new naming convention as EIDs and RLOCs. On the other hand, NEMO requires the minimal infrastructure changes into conventional Internet architecture as compared to LISP and moreover it does not introduce any new naming convention [START_REF] Mitharwal | Survey on network interface selection in multihomed mobile networks[END_REF]. However, it needs an improvement in multi-homing support. There is also a proposal for network mobility in space [START_REF] Chowdhury | Sinemo: An ip-diversity based approach for network mobility in space[END_REF] combining modified NEMO where its location management is replaced by dynamic DNS with SCTP. However, in this proposal mobiles nodes does not participate in mobility and multi-homing. Our aim is to investigate an approach that requires minimal infrastructure changes in the Internet. To best of our knowledge there have not been any attempt to combine NEMO with MPTCP. The following subsection contains the basic functionalities of NEMO and MPTCP and their limitations.

A. NEMO

NEMO provides a mechanism for network mobility support in the Internet, proposed in RFC 3963 [START_REF] Devarapalli | Rfc 3963 network mobility (nemo) basic support protocol[END_REF], [START_REF] Bernardos | Nemo: Network mobility. bringing ubiquity to the internet access[END_REF]. NEMO provides mobility supports in case of both IPv4 [START_REF] Leung | Network mobility (nemo) extensions for mobile ipv4[END_REF] and IPv6. In this paper, we discuss the solution for IPv6 only. The mobile network has a router inside which is known as mobile router (MR) and different kind of nodes, two of them are mobile network nodes (MNNs) and local fixed nodes (LFN) [START_REF] Ernst | Network mobility support terminology[END_REF] which we will consider in our paper. Local fixed nodes are unable to change their network point of attachment during an ongoing communication whereas the mobile network nodes have this ability. NEMO enables MR to change its network point of attachment in the Internet and continue to receive packets destined to MNN's home address, keeping the mobility transparent from MNNs. This is being done with the help of an anchor point inside mobile network's home network known as home agent (HA). Whenever MR changes its network attachment point in the Internet, it configures a new IP address called as current Care-of-Address (CoA) with the prefix of its current network attachment point using the IPv6 address auto-configuration [START_REF] Narten | Ipv6 stateless address autoconfiguration[END_REF]. After the address configuration, MR creates a binding between its home address and CoA with HA. When HA receives any packet destined for MNN from a communicating node (CN) in the Internet, it encapsulates the incoming packet with MR's CoA in the destination and HA's address in the source and routes it towards MR over the tunnel. Once MR receives the packet, it decapsulates the packet and routes it inside the mobile network. When MNNs receive the The multi-homing support enables mobile network to have one or more MR, HA and MNNs thus different combinations [START_REF] Ng | Analysis of multihoming in network mobility support[END_REF]. Here in this paper, we are going to consider the mobile network with one MR, one HA and more than one MNNs. NEMO has been extended to provide multi-homing support to mobile networks [START_REF] Hossain | Performance evaluation of multihomed nemo[END_REF] with Multiple Care-of-Address registration (RFC 5648 [START_REF] Wakikawa | Multiple care-of addresses registration[END_REF]) and flow binding extension (RFC 6089 [START_REF] Tsirtsis | Flow bindings in mobile ipv6 and network mobility (nemo) basic support[END_REF]).

B. Multi-Path TCP

Multi-Path TCP protocol (MPTCP) is an extension of transmission control protocol (TCP) proposed in RFC 6824 [START_REF] Ford | Rfc 6824: Tcp extensions for multipath operation with multiple addresses[END_REF], which is designed to enable simultaneous use of multiple available network interfaces on a host. MPTCP is backward compatible to TCP therefore, it uses the standard socket API used by most Internet applications which makes it compatible to the current applications and network [START_REF] Paasch | Exploring mobile/wifi handover with multipath tcp[END_REF]. The use of multiple paths between source and destination provides reliability, flexibility, fault tolerance and efficiency. In case of any failure, MPTCP can divert the traffic towards the other active paths. Compared to TCP, MPTCP does not add any overhead to data or tunnels. It just need an additional signaling for starting a communication. This is also needed for adding or removing the sub-flows due to IP address changes. MPTCP uses "make before break" method which is beneficial in providing seamless mobility and smooth handover. The Fig. 2 shows a mobile host having multiple communication paths with a remote host/server using MPTCP.

An MPTCP session start the same way as TCP with SYN flag set, with one addition in the SYN packet i.e., MP CAPABLE option. If the receiving host supports MPTCP, it adds the option MP CAPABLE in SYN-ACK reply. These two hosts create a cryptographic token/key for the secure communication. Finally the connection initiator host sends an ACK packet to the receiving host with MP CAPABLE option. Considering multi-homing or mobility scenario a host During mobility, the loss of a connection through one network attachment point makes one IP address unreachable. This lost IP address can be removed from the remote host's IP address list with REMOVE-ADDR option and then the sub-flows using this IP are removed too.

The MPTCP provides coupled congestion control [START_REF] Raiciu | Opportunistic mobility with multipath tcp[END_REF], [START_REF] Raiciu | Coupled congestion control for multipath transport protocols[END_REF]. The sub-flows maintain their own congestion window and execute the slow start algorithm. Therefore, MPTCP can optimally use the network resources by redirecting the traffic towards the non-congested paths. This feature of MPTCP helps to provide resilience, higher throughput and manage the increased demand of bandwidth more efficiently.

For the users that do not support MPTCP, there are some proposals to use MPTCP proxy implemented on end host or use a global anchor point [START_REF] Hampel | Seamless tcp mobility using lightweight mptcp proxy[END_REF]. If the user is comfortable with implementing proxies on end host, the lightweight proxy is proposed. It is based on packet filter implemented in mobile hosts. Some filter based solutions such as IPsec and tunneling are already being used, which makes it easy to deploy MPTCP on the end host. After implementing the proxies, both the hosts can be benefited with multi-homing benefits.

C. Limitations of NEMO and MPTCP

NEMO introduces tunneling overhead in order to provide mobility as the packets have to be routed through tunnels between HA and MR. In NEMO, all the incoming and outgoing traffic has to pass through HA. If there is any disruption on HA, all the incoming and outgoing traffic will be disrupted.

NEMO tries to use all the existing IP addresses simultaneously with the help of its extensions. However, this requires additional tunnels between HA and MR. The flow binding extension of NEMO tries to manage the traffic distribution of flows over several existing paths. This is an effort to provide an equal distribution of flows over all available interfaces. However, even with flow binding extension it cannot provide a full load balancing and optimum benefits of multi-homing. Thus, there is a requirement of the improvement considering mobility and multi-homing with NEMO to reach the multihoming goals optimally and reduce tunneling overhead.

The mobile network nodes behind MR cannot take part in multi-homing with NEMO. If mobile network nodes take part in the multi-homing the load from MR can be reduced and each user can manage their own connections. Thus, there is a requirement for an improvement considering mobility and multi-homing with NEMO to reach the multi-homing goals optimally.

MPTCP provides "make before break" mobility to the hosts but it does not provide network mobility. MPTCP does not have its own location management to support mobility of the host. There are several proposal for location management with MPTCP using dynamic DNS [START_REF] Sun | Mobility support in multi-path tcp[END_REF] or a rendez-vous mechanism. However, these proposals work only for host mobility but not for mobile networks. Therefore, to solve network mobility and multi-homing with MPTCP, there is a requirement of location management mechanism.

III. NETWORK MOBILITY WITH HOST MULTIHOMING

We propose to choose NEMO for location management and MPTCP for multi-homing. There can be other choices for location management like dynamic DNS or a rendez vous server. To provide location management for mobile networks, these proposals need some addtional functionalities to be introduced. As the use of dynamic DNS lacks in providing a seamless mobility for local fixed nodes due to their inability to change their network point of attachment for an ongoing connection. NEMO is the only solution that will be able to provide seamless mobility to local fixed nodes with the help of its HA route. Also in case of non-friendly visited networks (NAT, paranoiac, firewall, etc.), dynamic DNS cannot be used for incoming traffic [START_REF] Raiciu | Opportunistic mobility with multipath tcp[END_REF]. This would require an rendez-vous mechanism to open the connection simultaneously from both the ends for e.g., VPN (with their tunnels). Whereas, NEMO already uses tunnels which can be used for incoming traffic in non-friendly visited networks. NEMO provides better location management than dynamic DNS in mobile networks.

There can be other choices for multi-homing as well for eg. CMT-SCTP [START_REF] Iyengar | Concurrent multipath transfer using sctp multihoming over independent end-to-end paths[END_REF]. However, unlike MPTCP, SCTP is not transparent to the applications. Moreover, MPTCP performs significantly better than SCTP [START_REF] Becke | Comparison of multipath tcp and cmt-sctp based on intercontinental measurements[END_REF]. Therefore, the combination of NEMO and MPTCP would be a better choice than any other rendez-vous mechanism or dynamic DNS with MPTCP in order to solve network mobility having local fixed nodes and mobile network nodes providing better multi-homing support.

A. Description of the proposed Architecture

In this section, we describe the procedure to combine NEMO with MPTCP protocol. Their integration can be done without any major modifications to NEMO and MPTCP.

In our proposal, NEMO is being used for the location management of mobile network for incoming traffic during connection initiation and afterwards the MPTCP handles the mobility and multi-homing. This proposal enables MNNs to participate in mobility and multi-homing. For implementing this, the MNNs need to be aware of mobility which requires two minor changes in MR. Firstly, the MR needs to advertise its current network prefixes or Care-of-prefixes to MNNs. After receiving the current network prefixes MNNs can configure and add the new acquired IP address to their interfaces. In order to illustrate the key points we consider the following scenario. When a mobile network is outside its home network and a communicating node (CN) initiates a communication with the node which is behind MR, the communication has to pass through the HA because CN is not aware of MNNs current location in the Internet. Home agent then encapsulates the packets and forwards them towards MR's current care-ofaddress which is exactly the same as NEMO shown in Fig. 3.

During the connection establishment, the mobile network node or communicating node adds MP CAPABLE option inside the TCP packet. If both nodes natively support MPTCP then they establish an MPTCP connection and exchange all the existing IP addresses. If any node does not support MPTCP, it can install a lightweight proxy as explained in the state of art of MPTCP. Once the communication is established the mobile network node can set the HA path as BACKUP path with help of MP PRIO option and create sub flows using the rest of the IP addresses. Mobile router should be able to route the packets directly using its current care-of-address rather than through HA. Whenever during mobility, the mobile network attaches to a new point in the Internet, it receives a new prefix. Using this prefix, it creates a care-of-address and updates the binding with HA. It then advertises the new prefix to the MNNs. Once the nodes receive new prefix they can configure the new IP address and communicate it with the communicating node using MPTCP and create another sub-flow as shown in Fig. 4. In presence of multiple CoAs on MR, HA have to make a choice among available interfaces for forwarding the connection initiation packets. This can be solved by implementing policies in between HA and MR with help of flow binding extension [START_REF] Ropitault | Implementation of flow binding mechanism[END_REF] of NEMO.

As MPTCP uses "make before break", the proposed ap-

B. Signaling

For explaining the signaling in the proposed approach, we consider two different scenarios.

• When MNN initiates the communication with CN i.e., for outbound traffic

• When CN initiates the communication with MNN, i.e., for inbound traffic.

1) Signaling for Outbound Traffic: In outbound traffic, MNN initiates a communication with CN. To initiate the communication, MNN creates a SYN packet with MP CAPABLE option and routes it toward MR using its CoIP@MR-AR1. MR then routes this packet towards the Internet. CN receives the packet and routes the reply SYN-ACK packet towards MNN's CoIP@MR-AR1. On reception of SYN-ACK, MNN sends an ACK packet and the MPTCP connection is established. After the connection establishment, MNN can share its existing CoIPs. MNN has an option to share its Home IP address with the CN to keep this path as a back up path, generally it is not required. If mobility occurs in between, then MNN receives a new prefix from MR and configures a new CoIP. It then shares this new CoIP with CN and creates another sub-flow. If the communication is lost with the previous access network, MNN sends a request to remove the previous IP address and the communication continues through other sub-flows. Fig. 5 illustrates the above explained signaling.

The proposed approach shows an expected gain in case of outbound traffic from mobile network nodes compared to classical NEMO as the traffic does not flow anymore through the tunnels between HA and MR. For outbound traffic from local fixed nodes, NEMO will be used and will work in the Fig. 5. MPTCP connection establishment for outbound flow in proposed architecture classical way. Therefore, the proposed approach reduces cost of tunnels and improves load balancing thus throughput for mobile network nodes.

2) Signaling for Inbound Traffic: To illustrate the signaling for inbound traffic, we consider the scenario where mobile network is on move and currently connected to access router 1 (AR1). Once it is connected with AR1, it creates a binding with its HA for its current care-of-address. It then advertises the new prefix to MNN and it then configures and adds the new IP (CoIP@MNN-AR1) to one of its interfaces. When any communicating node from the outside Internet initiates a communication with MNN, the SYN segment packet is generated with MP-Capable option for MNN's home IP address and routed towards its home network. In the home network, HA intercepts the packets and finds a binding entry for MNN's MR. Afterwards, HA encapsulates the packets using careof-address of MR@AR1 (CoIP@MR-AR1) and forwards the packet towards mobile network's visiting network. Upon the reception of the packet, MR decapsulates it and forwards it inside the mobile network. MNN receives the packets and create a SYN-ACK packet segment for IP@CN and route it towards MR. MR encapsulates this SYN-ACK packet and send it to HA. On reception of the packet from MR, HA decapsulate it and route it towards CN's network. CN receives the packet and generates reply as an ACK packet and the packet takes the same route as before. On reception of ACK packet, the MPTCP connection is established. After the connection establishment, MNN sends a request to ADD-ADDR providing CoIP@MNN-AR1 and create a sub-flow using this IP. Once the new sub-flow is added to the ongoing communication MNN sets the HA-MR route as backup path and continues to communicate through its care-of-address. After this step a tunneling overhead is gained with exchange of each packet for the ongoing communication. Fig. 6 illustrates the above explained signaling.

The above explained scenario is valid when MNNs and MR are connected to single access network. There can be multiple available access networks. In that scenario, MNN can create new sub-flows by adding other available CoIP address to the ongoing communication with CN and communicate using all the sub flows.

The only difference between outbound and inbound traffic signaling is during connection initiation. As in case of inbound traffic the proposed approach use tunnels for connection initiation. After the connection initiation both the scenarios show

C. Benefits and Use cases

For describing the benefits of proposed architecture, we have to reconsider the limitations of NEMO and show that the combination of NEMO and MPTCP can improve these limitations. To perform an ideal mobility or "make before break" mobility it requires some path related information from transport layer as talked earlier. The proposed approach is a collaboration between network and transport layer protocols. Therefore, MPTCP helps NEMO to provides "make before break" mobility with smooth handover.

All the traffic having to go through HA makes NEMO less fault tolerant. While in the proposed approach, only the connection initiation takes place over the HA-MR bidirectional tunnel. Afterwards, all the traffic flows through MR as it flows through any normal router towards the Internet. This removes the tunneling overhead of the data packet exchange after the connection establishment between HA and MR and system becomes more fault tolerant than HA-MR route.

In order to support multi-homing with the help of its multiple care-of-address registration (MCoA) extension, NEMO adds more tunnels between HA and MR. While in the proposed approach, MR does not have to perform multi-homing. MPTCP takes over after the connection is established and the rest of the communication happens in a similar way to that of the Internet. The use of MPTCP reduces these additional tunnels and provides multi-homing benefits to the host.

The flow binding extension of NEMO attempts to provide an equal distribution of flows over all available interfaces but optimum load balancing cannot be achieved. While in the proposed scenario, MPTCP helps to achieve an optimum load balancing over all the available network interfaces.

The network nodes behind Mobile router cannot take part into multi-homing in NEMO. While the proposed approach provides a way for MNNs to participate in multi-homing with help of MPTCP and helps to improve the throughput of the whole system. This participation also gives an opportunity to the user to decide the communication mode in terms of cost efficiency, energy efficiency, or best availability of an interface etc.

There can be a scenario where the communicating node is very near to MR. An example of such a scenario in the real world situation can be a boat/ship which resides in France (its home network) and currently sailing near Australian coast. A random user from Australia would want to communicate/transfer a file or video with/to a node on this boat/ship. This will cause the traffic to travel through its home network i.e., France. It can be improved by the proposed architecture as the data transfer takes normal routing path instead of its HA path.

Considering the scenario where two mobile network nodes inside boats of different companies (i.e. different network operators) want to communicate or exchange data with NEMO, the traffic has to pass through both of their HAs and then tunneled towards MRs. The proposed approach shows a gain in this scenario as after the connection establishment these two nodes can communicate independent of HAs-MRs route thus no more tunnels. Moreover, the boats can have several connection to Internet via e.g., satellite, LTE, 3G, WiFi. In this scenario, switching between different terminals becomes difficult. In some circumstance there can be a technician in board to manually perform the commutation between link terminals, set up IP and routing parameters (e.g., on scientific boats). But this is hardly the case (e.g., on merchant vessels). The proposed approach takes care of the switching between terminals. Some other use case scenarios can be considered as in case of boats, mail-servers can receive any amount of data in real time without requiring to pass through tunnels or by polling a cache server. In present time, some commercial ship vessels have some limitations of the file size in the on-board mailservers. This file-size constraint can be removed with the help of the proposed architecture and on-board email servers can be reached at any time instead of polling.

The proposed approach does not need any major modification in already implemented NEMO and MPTCP. This makes its deployment manageable. For UDP connections or in absence of MPTCP proxies, tunnels are still available as a fall-back solution. For non-TCP connections in real-time traffic such as VoIP, IETF is working on standardizing multi-path extension for RTP [START_REF] Raiciu | Opportunistic mobility with multipath tcp[END_REF]. This can also be used with NEMO.

The tunnels of NEMO may have increased overhead in normal scenarios but they are beneficial for the incoming traffic in non-friendly visited networks for e.g., NAT, firewall etc. and for providing seamless mobility to the local fixed nodes inside a mobile network. NEMO's tunnels are also convenient natural fall-back solution in the scenario when there is no MPTCP support. Moreover, the proposed solutions helps to avoid tunnels when it is not necessary. This makes the system more flexible and more robust. Therefore, MPTCP with NEMO helps to provide better network mobility with optimum multihoming benefits. • Routing: In classical NEMO, the traffic has to pass through HA and then it is tunneled towards MR which is inefficient. Whereas, in the proposed approach, the traffic follows a classical Internet path which makes the routing more efficient. The HA-MR route is used only for signaling for incoming traffics and for providing mobility to LFNs.

• Throughput: The throughput of the system can be almost doubled by using MPTCP compared to TCP in mobile scenario [START_REF] Raiciu | Opportunistic mobility with multipath tcp[END_REF]. Therefore, we can expect an improved throughput from the proposed architecture compared to classical NEMO.

• Round Trip Time: Compared to classical NEMO, in proposed approach the traffic takes classical Internet routing path rather than traffic through MR's home network. Thus the proposed architecture improves RTT also.

• Signaling Cost: The classical NEMO will have signaling cost required for NEMO (SC N EM O ). Whereas, the proposed architecture will have NEMO signaling cost with additional MPTCP signaling cost for adding or removing sub-flows during mobility SC = SC N EM O + SC M P T CP .

• Tunneling overhead: The proposed architecture significantly reduces tunneling cost compared to classical NEMO. As in classical NEMO, the whole traffic takes HA-MR route which adds bi-directional encapsulation overhead. Whereas in the proposed architecture, the traffic is routed directly towards Internet from MR rather than towards HA.

V. FUTURE WORK

In future, we would be evaluating the gain obtained using test-bed implementation of the proposed approach shown in Fig. 7. MNN and CN are MPTCP enabled here. We will try to calculate throughput, handover latency, round trip time (RTT) and retransmission during hand-off by downloading some files from CN to MNN and vice-versa, with the help of proposed approach and compare this scenario with classical NEMO. We will also calculate RTT for the outgoing signaling and compare this with the classical NEMO signaling. We can capture the packets using wire-shark and plot the graphs between packet captured versus time to show the difference between the proposed and classical throughput, handover latency, RTT and retransmission during hand off. Through these graphs we will be able to show that NEMO works better with MPTCP.

VI. CONCLUSION

In this paper, we proposed an architecture for providing better multi-homing support in mobile networks by combining NEMO with MPTCP. The proposed architecture requires some minor changes in functionalities of mobile router in NEMO and none in MPTCP. There are two changes that need to be implemented in the MR. First, it should advertise its care-ofprefixes to mobile network nodes for them to configure their own care-of-address. Second, it should be able to route the packets directly using MNNs care-of-addresses instead of routing them towards HA through the tunnel. This solution limits tunneling overhead. The established connection will survive as long as there is atleast one available care-of-address. Moreover, the performance of the communication is surely increased by using MPTCP when compared to TCP [START_REF] Scharf | Multipath tcp (mptcp) application interface considerations[END_REF]. Therefore, this novel combination of NEMO and MPTCP provides a better network mobility with improved multi-homing support compared to classical NEMO in terms of reduced tunneling overhead, increased throughput and improved load balancing.

Fig. 1 .

 1 Fig. 1. NEMO Basic Support Protocol

Fig. 2 .

 2 Fig. 2. Multi-Path TCP

Fig. 3 .

 3 Fig. 3. Connection initiation in proposed architecture

Fig. 4 .

 4 Fig. 4. Communication after connection establishment in proposed architecture

Fig. 6 .

 6 Fig. 6. MPTCP connection establishment for inbound flow in proposed architecture

Fig. 7 .

 7 Fig. 7. Test-bed implementation architecture

TABLE I

 I

	.	CLASSICAL NEMO VS. NEMO WITH MPTCP
	Parameters		Classical NEMO	NEMO with MPTCP
	Routing		Inefficient	Efficient
	Throughput		Low	High
	Round Trip Time		High	Low
	Signaling Cost		Low	High
				Only for incoming Traffic,
	Tunneling overhead	Always	local fixed nodes and in
				non-friendly visited network
	IV. COMPARISON BETWEEN CLASSICAL NEMO AND
			NEMO WITH MPTCP
	In this section, we compare the features of NEMO and our
	proposal NEMO with MPTCP in Table I based on following
	parameters:

ACKNOWLEDGMENT

The research leading to these results has received funding from the European Community Seventh Framework Program FP7/2013-2015 under grant agreement no. 317762 COMBO project.