Franck Bielsa

Albane Douillet

Tristan Valenzuela

Jean-Philippe Karr

Laurent Hilico
email: hilico@spectro.jussieu.fr

Narrow-line phase-locked quantum cascade laser in the 9.2 micron range

Keywords: numbers: OCIS 120.3930, 140.3470, 999.9999 quantum cascade laser

We report on the operation of a 50 mW continuous wave quantum cascade laser (QCL) in the 9.2 µm range, phase locked to a single mode CO2 laser with a tunable frequency offset. The wide free-running emission spectrum of the QCL (3-5 MHz) is strongly narrowed down to the kHz range making it suitable for high resolution molecular spectroscopy.

Continuous wave high power (≥50 mW) quantum cascade laser sources (QCL) recently became commercially available [1]. They exhibit new features for infrared laser spectroscopy. Mid-IR QCLs are easily and widely tunable over more than 200 GHz by adjusting their temperature or injection current. Since they do not present phase-amplitude coupling, their ultimate linewidth is expected to be very narrow. In practice, due to thermal instabilities, they present a wide free-running emission spectrum, in the MHz range [2,3]. Several experiments have shown a significant reduction of the QCL linewidth down to the 10 kHz range by injection current locking to a molecular line [4], or well below the kHz range by locking to a Fabry Perot cavity [5] using the Pound-Drever-Hall technique.

Phase-locking is a well-known technique used to reduce the relative phase noise between two laser oscillators or to transfer the spectral features of a stable laser to a noisy one [6]. This method consists in comparing the phase of the laser beat note with that of a RF synthesizer signal. It has recently been applied to the frequency control of terahertz QCLs [7], but never so far to infrared QCL linewidth reduction.

Our motivation for developping a frequency controlled QCL source is high resolution vibrational spectroscopy of the hydrogen molecular ions H + 2 or HD + . Indeed, those ions have recently been pointed out as good candidates for optical proton to electron mass ratio determination [8,9,10,11]. Recent calculations have shown that two-photon vibrational spectroscopy of H + 2 in the 9.1-9.3 µm range is feasible [8] with interaction times of a few tens of ms. Transitions frequencies have been predicted with 1 ppb relative accuracy [12,13]. Further progress in QED correction calculations should allow proton to electron mass ratio determination with a relative accuracy of 10 -10 , in significant progress over the present one (CODATA 2002) [14]. This corresponds to an uncertainty of a few kHz on the transition frequencies, hence the need for a kHz linewidth laser source.

In the 9.1-9.3 µm wavelength range, only two kinds of cw laser sources are available : CO 2 lasers and QCLs. Single mode CO 2 lasers can deliver up to several watt of optical power in a narrow bandwidth of less than 1 kHz. Unfortunately, their tunability covers a range of a few tens of MHz and the CO 2 emission lines do not overlap with the H + 2 spectrum. In this paper, we show that it is possible to combine the advantages of both kinds of sources by transferring the spectral properties of a CO 2 laser to a widely tunable QCL using phase-lock loop techniques. We demonstrate the operation of a tunable narrow-line high-power laser source suitable for twophoton spectroscopy of hydrogen molecular ions with a kHz resolution.

The experimental setup is depicted in Fig. 1. The quantum cascade laser (SBCW496DN from AlpesLaser) is a single mode distributed feedback laser. When operated in cw regime under cryogenic conditions, it delivers up to 160 mW and is tunable between 9.16 and 9.24 µm (32.44 and 32.73 THz). Its threshold current is 400 mA at 77 K, and its maximum driving current is 1 A. The temperature and current tunabilities are 3 GHz/K and 150 MHz/mA.

The QCL is mounted in a liquid nitrogen cryostat with a ZnSe output window and driven by a home-made, lownoise stabilized current source. The voltage across the QCL is about 9 V and the dynamic resistance is 1.8 Ω. The electrical power dissipated in the QCL can be as high as 9 W, which requires efficient heat dissipation. For this purpose, the laser chip is fixed on a monolithic copper post, screwed on the cryostat cold plate in order to minimize the thermal resistance. The post can be heated and temperature controlled at the 10 mK level. With a 700 mA driving current, the QCL temperature stabilizes around 80 K without external heating and the QCL delivers an optical power of 50 mW at 9.166 µm, the required wavelength to probe the (v=0, L=2)→(v=1,L=2) two-photon line in H + 2 . The output beam is collimated using ZnSe collimating optics from Cascade Technologies (CO-01, 0.85 mm N.A. and 1.6 mm working distance). The far field transverse structure of the QCL beam presents a nodal structure with one main and two secondary lobes along the vertical axis. Along the horizontal axis, the Gaussian beam shape dependence on propagation distance is consistent with a M 2 parameter of about 3.3. We use the CO 2 laser both as local oscillator to characterize the QCL spectrum properties, and as stability reference to phase lock the QCL. It is a sealed-off, low pressure, dual-discharge-arm, 1 m long single longitudinal mode laser. The cavity is closed by a R max mirror at 9.2 µm and a 150 lines/mm grating in the Littrow configuration. The grating zero th diffraction order is the main output of the laser (95% efficiency). When operated with 13 Torr of standard gas mixture (CO 2 -He-N 2 ) and 24 mA discharge current, the laser oscillation is obtained in the 9 µm band up to the 9R(48) line with more than 1 W of optical power. The CO 2 laser emission spectrum has a linewidth in the kHz range [15] and only very slow drifts (less than 1 MHz/s).

About 10 mW of QCL and 50 mW of CO 2 laser optical powers are mixed on a room temperature HgCdZnTe fast photodetector followed by a 37 dB low-noise RF amplifier. Although the beams' overlap is rather low, we obtain a signal to noise ratio of more than 45 dB in a 1 MHz resolution bandwidth for a beat frequency f 0 up to 1.5 GHz. The free-running QCL emission spectrum (Fig. 3a) is about 3 to 5 MHz wide as already observed with other QCLs [2,3] and exhibits a low frequency jitter over more than 10 MHz.

In order to efficiently phase lock the QCL on the CO 2 laser, we tailor a wideband phase error signal and use a standard second order feedback loop [6,[START_REF] Gardner | Phaselock technique[END_REF][START_REF] Blanchard | Phase-locked loops: applications to coher-ent receiver design[END_REF]. The optical and electronic paths are shortened as much as possible (about 2 m) to minimize time delay. The beat note signal is high-pass filtered above 700 MHz and divided by 8 using a MC12093 high speed frequency divider. The phase comparison with a synthesized reference signal is performed at f 0 /8 using a MCH12140 phase/frequency detector with a ±2π range. As a result, we obtain a very wide band (≥10 MHz) ±16π phase/frequency comparison of the two lasers' spectra. The measured slope of the error signal is s = 0 • 022 V/rad.

The servo loop is depicted in Fig 2 . It simply consists in an integrator with a 600 kHz cut-off frequency built with a fast operational amplifier. The feedback loop gain is adjusted using a variable resistor. The correction signal is directly applied to the QCL through a ≈1kΩ resistor that limits the output current from the amplifier. This resistor is split into two parts. The first one belongs to a phase advanced filter with 2.4 MHz cut-off frequency adjusted to optimize the loop bandwidth. The second part is directly soldered on the QCL pads inside the cryostat in order to minimize wire capacitance effects. Because we use a phase-frequency detector, we have to choose the suitable sign for the correction signal depending on whether the QCL frequency is red or blue detuned with respect to the CO 2 laser frequency. This is the aim of the second inversor follower amplifier. The beat note spectrum, taken with the tracking servo active, is shown in Fig. 3b. It represents the relative phase noise spectral density between the QCL and CO 2 laser. It exhibits an extremely narrow central peak with a -3 dB width of less than 200 Hz, limited by the resolution of the spectrum analyzer. This width is much smaller than the CO 2 laser one, meaning that the CO 2 laser's spectral features are transferred to the QCL. The spectrum's wings show a servo-loop unity gain frequency of the order of 6 MHz with a carrier 53 dB above the phase noise level in a 10 kHz resolution bandwidth. We now estimate the energy concentration ratio in the central peak. The normalized beat note spectrum can be expressed as [START_REF] Blanchard | Phase-locked loops: applications to coher-ent receiver design[END_REF]

S(f ) ≈ e -σ 2 ϕ δ(f ) + S ϕ (f ) (1)
where σ ϕ is the phase error variance, δ(f ) the Dirac delta-function and S ϕ the phase noise spectral density.

We have S ϕ (f ) ≈ 10 -9.3 ≈ 5 • 10 -10 rad 2 /Hz. Graphical integration within the loop bandwidth gives an estimation of half the actual phase variance, i.e. 1 2 σ 2 ϕ = 3 10 -3 rad 2 [START_REF] Gardner | Phaselock technique[END_REF][START_REF] Blanchard | Phase-locked loops: applications to coher-ent receiver design[END_REF]. Fig. 4 shows the phase error spectral density at the output of the phase comparator. Comparison of curves (b) and (c) shows that the integrator reduces phase noise by more than 10 dB up to 200 kHz. The phase noise error signal spectral density exhibits a plateau at the S u =10 -12.4 V 2 /Hz level corresponding to a phase noise spectral density S ϕ = S u /s 2 = 8 • 2 10 -10 rad 2 /Hz. Taking into account the 6 MHz noise bandwidth, we obtain an alternative estimation of the phase variance 1 2 σ 2 ϕ = 0 • 005 rad 2 in good agreement we the first one. From those values, we can deduce that the energy concentration ratio in the narrow central peak e -σ 2 ϕ is higher than 99%. Let us stress that the large feedback loop bandwidth is essential to obtain this result [18]. The phase locked operation of the QCL is easily obtained with a tunable frequency offset in the 200-1500 MHz range around the CO 2 emission line. The high frequency limit is due to the detector cut-off. The low frequency limit is the minimum beat frequency necessary to obtain a wide band error signal after division and phase comparison. It can be overcome by frequency shifting the high power output of the CO 2 laser with an acousto-optic modulator before beating with the QCL. Stable operation of the lock during several hours is obtained.

In conclusion, we have shown that the spectral features of CO 2 lasers can be transferred to a QCL with a tunable frequency offset, making QCLs very interesting tools for high resolution molecular spectroscopy. We have used this source to observe several absorption lines of the ν 6 band of formic acid [START_REF] Rothman | [END_REF] in quasi-coincidence with the 9R36 to 9R42 emission lines of the CO 2 laser with a kHz resolution and measured their absolute frequencies [20] to obtain suitable molecular frequency references for H + 2 vibrational spectroscopy.

FIG. 1 :

 1 FIG.1: Simplified experimental setup. The low power CO2 laser output (≈50 mW) is beated with a fraction of the QCL emission (≈10 mW). The frequency divider and phase comparator are described in text, and the servo circuit in Fig.2.

FIG. 2 :

 2 FIG. 2: Servo electronics of the phase lock loop. The resistor values are in Ω.

FIG. 3 :FIG. 4 :

 34 FIG. 3: (a) Free-running and (b) phase-locked QCL/CO2 beat note spectrum. (a) RBW 500 kHz, VBW 1 kHz, (b) RBW 10 kHz, VBW 1 kHz.

We thank O. Acef, G. Santarelli and M. Lours (LNE-SYRTE), A. Vasannelli (Thales group) and Remy Battesti. Laboratoire Kastler Brossel is UMR 8552 du CNRS. This work was supported by an ACI jeune 03-2-379 and BNM grants 02-3-008 and 04-3-009.


Ella Kolkowska
email: ella.kolkowska@oru.se

Annica Kristofferson
email: annica.kristoffersson@oru.se

Privacy by design principles in design of new generation cognitive assistive technologies

Keywords: Privacy requirements, Privacy by Design, assistive technology, cognitive decline, aging in place

Today, simple analogue assistive technologies are transformed into complex and sophisticated sensor networks. This raises many new privacy issues that need to be considered. In this paper, we investigate how this new generation of assistive technology incorporates Privacy by Design (PbD) principles. The research is conducted as a case study where we use PbD principles as an analytical lens to investigate the design of the new generation of digitalized assistive technology as well as the users' privacy preferences that arise in use of this technology in real homes. Based on the findings from the case study, we present guidelines for building in privacy in new generations of assistive technologies and in this way protect the privacy of the people using these technologies.

Introduction

Assistive technology (AT) is a broad term used to describe any item, object, device or system that enables disabled people to perform a task that they would otherwise be unable to do, or increase the ease and safety by which certain tasks can be performed.

AT plays an important role in supporting elderly people in living independently at home [START_REF] Frennert | Elderly People's Perception of a Telehealthcare System: Relative Advantage, Compatibility, Complexity and Observability[END_REF]. In this paper, we focus on AT suitable for elderly with a mild cognitive decline, e.g., dementia. The rapid development of cognitive assistive technologies (CAT) paves the way for new and more efficient solutions that improve the quality of life for people being affected by cognitive decline while decreasing their caregivers' burden of care [START_REF] Koch | On health-enabling and ambient-assistive technologies. What has been achieved and where do we have to go?[END_REF]. Today, we are rapidly moving from analogue CAT accessible only for the user of the specific device to digital replicas, and further extensions of the CAT involving sensor networks but also technologies accessible by remote caretakers. In this paper, we refer to this technology as the new generation of CAT. The development of CAT raises many new privacy issues which need to be considered [START_REF] Kosta | Mobile-centric ambient intelligence in Health-and Homecare-anticipating ethical and legal challenge[END_REF][START_REF] Shankar | Aging, Privacy, and Home-Based Computing: Developing a Design Framework[END_REF][START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF] but unfortunately, most of today's development projects are technically oriented and focus on functionality and technical effectiveness of the developed solutions [START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF][START_REF] Frennert | Review: Seven Matters of Concern of Social Robots and Older People[END_REF]. Consequently, the privacy of the user is often not sufficiently considered during development and implementation of the new generation of CAT [START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF].

The concept of Privacy-by-Design (PbD) advocated by EU [START_REF]European Commission: Proposal for a regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF] aims to ensure privacy protection and personal control over the information collected when IT systems are used. PbD principles are formulated to support the designers in taking the protection of privacy into account during the development of technologies (such as CAT) that in turn results in better privacy protection for the users of these technologies.

In this paper, we investigate how the new generation of CAT incorporates PbD principles with respect of elderly users' privacy requirements. Based on our findings, we formulate a set of guidelines for building in elderly users' privacy preferences into CAT and in this way protect the privacy of the people using them. A starting point for this research is a set of PbD principles suggested by Cavoukian et al. [START_REF] Cavoukian | Remote home health care technologies: How to ensure privacy? Build it in: Privacy by design[END_REF] for the context of personal health monitoring. The main contribution of the paper is adding a users' perspective to the existing technology-focused PbD principles.

The paper is structured as follows. Section 2 describes and discusses the PbD concept and PbD principles. Section 3 describes the new generation of CAT at focus in this case study. Section 4 presents our research method. Section 5 reports on our analysis of the case study. In section 6, we discuss the results and present a set of guidelines for building into privacy in the new generation of CAT. Section 7 concludes the paper.

Privacy by Design principles

Protection of privacy regarding sensitive personal data, is legally regulated in most countries and therefore cannot be overlooked in design and use of the new generation of CAT. It is also recognized that people, generally are not capable or not interested in protecting their own sensitive information, thus there is a need for standardization and automatization of privacy protection [START_REF]European Commission: Proposal for a regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF]. PbD is a way of embedding privacy into the design specifications of technologies. Cavoukian et al [START_REF] Cavoukian | Remote home health care technologies: How to ensure privacy? Build it in: Privacy by design[END_REF] suggest seven PbD principles for the context of personal health monitoring These seven principles are an adjustment of the general OECD "Guidelines on the Protection of Privacy and Transborder Flows of Personal Data" [START_REF] Cavoukian | Remote home health care technologies: How to ensure privacy? Build it in: Privacy by design[END_REF]. The seven PbD principles formulated by Cavoukian et al. for the context of health care monitoring are [START_REF] Cavoukian | Remote home health care technologies: How to ensure privacy? Build it in: Privacy by design[END_REF]:

1. Proactive not Reactive; Preventative not Remedial. The PbD approach is characterized by proactive rather than reactive measures. The first principle emphasizes that it anticipates and prevents privacy invasive events before they happen.

2. Privacy as the Default Setting. The second principle means that no action is required by the users to protect their privacy because it is built into the system, by default.

3. Privacy Embedded into Design. The third principle emphasizes the importance of embedding privacy into the design and architecture of IT systems and business practices from the beginning and not add it afterwards.

4. Full Functionality -Positive-Sum, not Zero-Sum. The fourth principle considers privacy as an integral part of the system without diminishing its functionality.

5. End-to-End Security -Full Lifecycle Protection. The fifth principle relates to the life cycle management of information and stresses that data should be protected in all data handling from its beginning (collection) to its end (destruction). I.e., this principle is important to ensure privacy of the people using the technology when it is in use.

Visibility and Transparency -Keep it

Open. The sixth principle states that data protection should be visible and transparent to the different stakeholders, e.g. users and providers. In the context of our case study, this principle means that the users are informed about what data is being collected and for what purpose, how the data is being used, and who can access it.

7. Respect for User Privacy -Keep it User-Centric. This principle means that the individual's privacy should be an interest of designers and operators of health systems.

Cavoukian et al. [START_REF] Cavoukian | Remote home health care technologies: How to ensure privacy? Build it in: Privacy by design[END_REF] define information privacy as an individual's ability to exercise control over the collection, use, disclosure and retention of his or her personal information, including personal health information. Nordgren [START_REF] Nordgren | Privacy by Design in Personal Health Monitoring[END_REF] argues that the PbD principles suggested by Cavoukian et al. are supportive in ensuring privacy of the patients in the context of personal health monitoring, although they have two limitations: 1) PbD cannot solve all privacy problems because responsible handling of information by human agents is also important, and 2) automated data protection is useful in many cases, but it is not desirable in all cases. Generally, socially-oriented research on privacy in this context is sparse. Previous research shows that elderly people's privacy preferences are not sufficiently investigated in development of CAT [START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF][START_REF] Mort | Ethical implications of home telecare for older people: a framework derived from a multisited participative study[END_REF][START_REF] Bowes | Implications of Lifestyle Monitoring Data in Ageing Research[END_REF]. Usually, it is assumed-at least implicitly-that a "common" CAT user does not care about privacy [START_REF] Bowes | Implications of Lifestyle Monitoring Data in Ageing Research[END_REF]. Consequently, development of such technologies is often functionality-driven without taking care of privacy issues that arise in use of such technologies in real settings [START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF][START_REF] Frennert | Review: Seven Matters of Concern of Social Robots and Older People[END_REF]. That is against the PbD thinking. Our interest lies in studying the privacy concerns that arise in use of CAT in real settings as well as their potential, in case of unforeseen usage in the future. Since the importance of respecting the users' privacy is especially empathized in the seventh PbD principle we decided to conduct a case study focusing on the users' privacy preferences that come up in use of CAT in relation to Cavoukian et al.'s seven PbD principles.

System description

An example of the new generation of CAT is HOMEbasic1 , which is a "safety and security" package for those who need a combination of time and memory support, environmental monitoring and alarm functionalities. HOMEbasic in its standard package consists of a MEMOplanner and a sensor network (a door magnet, a stove sensor, an on/off sensor, two motion sensors and a lamp actuator). The MEMOplanner supports the user with the calendar reminders and sensor-based reminders listed in Table 1 by issuing an auditory and visual reminder. Additionally, the light is automatically turned on when the user's feet are detected beside the bed to minimize the risk of falls during nighttime. In the current version, all information is saved locally within the MEMOplanner. While disabled by default upon delivery, a USB remote control can be provided to those who need to administer MEMOplanner. Provided that MEMOplanner is connected to the Internet, users (for example relatives or caregivers) with the USB can access all functionalities in MEMOplanner, i.e. also Windows. There is only one access level for remote administrators, hence, users provided with a USB can access and edit the content of the calendar, contacts, and photos from remote. A Vera 3 gateway communicates both with the sensors using the Z-wave protocol2 and with the MEMOplanner (usually via WiFi but a cabled connection is possible). The Vera gateway can also connect the MEMOplanner to the Internet. By default, the triggered reminders are not stored within the Vera or sent remotely to any administrator. An electronic device has been turned on for x minutes. The entrance door is opened while the stove is on. The entrance door is opened. Can be used to remind the user to, e.g., lock the door or to tell the user that it is not an appropriate time to go out. 5. Sensor-based actuation: Lamp automatically turned on when motion beside bed.

Research method

This research was conducted as a case study where we investigated the CAT described in Section 3, as well as privacy concerns that arose in use of this technology in real homes. Although results from case study research cannot be statistically generalized, this approach supports collection of rich context-specific details and in this way reveals important information about the object under study and increases the understanding of the specific context [START_REF] Yin | Case Study Research-Design and Methods[END_REF]. By using this methodology, we were able to study the users' expectations and needs regarding privacy and the new generation of CAT's possibility to address these needs in depth.

Selection of participants

We looked for test persons who had some sort of a cognitive decline. All seven test persons (μ = 71.6 years old) were men and lived together with their wives (μ = 65.7 years old) in ordinary housing/private residences outside nursing homes. All test persons and four of the wives were retired. Two wives were still working full-time and one was working part-time. Additional details about the case settings can be found in [START_REF] Kristoffersson | Assessment of Expectations and Needs of a Sensor Network to Promote Elderly's Sense of Safety and Security[END_REF].

In sum, the CAT was deployed and used in seven Swedish homes during a period of approx. six months.

Data collection

Data was collected in five stages: 1) functionality and privacy in design of HOMEbasic, 2) users' general privacy preferences, 3) observation of users' privacy preferences when using HOMEbasic, 4) users' privacy preferences in relation to HOMEbasic's current and future functionality (scenarios), and 5) users' opinions about the methods used for implementation and introduction of HOMEbasic.

Stage 1: functionality and privacy in design of HOMEbasic. In this stage, we wanted to gain a general understanding about HOMEbasic's functionality and the implemented privacy measures. For that reason, we participated in two demonstrations of HOMEbasic where we could interact with the system and ask questions. We also reviewed the HOMEbasic documentation and manuals and interviewed the developers. Finally, we interviewed experts responsible for prescription of this (and similar) CAT to end-users.

Stage 2: users' general privacy preferences. In this stage, data was collected through semi-structured interviews with the test persons and their relatives when the CAT was deployed. The interviews aimed to collect data about the participants' general requirements and preferences regarding privacy and their expectations/worries regarding privacy of information handled by the CAT. At this first interview session, the test persons and their relatives were interviewed separately. The interviews focused on three areas: 1) general privacy awareness and preferences, 2) privacy preferences in interaction with health care and elderly care, 3) privacy concerns in relation to use of the CAT. Aspects discussed within these areas were related to: the interviewees' privacy enhancing behaviors when using ICT, knowledge about privacy regulation, privacy awareness, privacy concerns etc.

Stage 3: observation of users' privacy preferences when using HOMEbasic's. During the test period, we visited the test sites regularly and observed how the CAT was used. We also discussed users' privacy concerns that come up during the use of CAT.

Stage 4: users' privacy preferences in relation to HOMEbasic's current and future functionality. This stage focused on privacy concerns in relation to present and future potential functionality of the CAT and was conducted when the CAT was removed from the homes. Future scenarios were developed based on the current trends in development of CATs aiming at integrating these technologies as a part of health care and home care. For that reason, it is assumed in some scenarios that health care professionals and home care staff are able to access the data collected by the CAT. Use case-based scenarios steered the interview. We formulated at least one scenario for each CAT existing functionality in the CAT (see Table 2) and several possible scenarios for use of this functionality in the future. By default, the triggered alarms are not stored within the Vera or sent remotely to any administrator. However, accessing information about trigged alarms could allow home care staff and/or health care professionals to monitor changes in behaviors of the person using a CAT. For instance, more frequent actuation of the lamp sensor at nights could indicate that the elderly person has sleep problems or more frequently issued sensor-based reminders could indicate a decline of the elderly person's health condition. Such information could help the caregivers to react on the changes and help the elderly person in a more efficient way. Thus we included scenarios 10-15 assuming that it will be possible in the future.

For each scenario, the participants were asked a few questions revealing their privacy preferences, for instance: How does it make you feel? Why? What emotions does this event raise? Why? How would you like to change the situation to feel okay? Additional functionality (future scenarios) Scenario 7: You use the possibility to store photos in the MEMOplanner, i.e., you keep private photos of your family, photos from your vacation etc. After you come back from the holiday, home care staff comment on your holiday's photos which you have not shown them.

Scenario 8: Would you feel differently if they commented on pictures of your grandchildren from the last party?

Scenario 9: After a while you discover that your private pictures are used in an advertisement of the hotel on the Internet.

Sensor-based reminders (future scenarios) Scenario 10: The stove sensor is installed and you feel that it fulfils its goal and runs the reminders when needed. On the next visit, your doctor tells you that your memory has declined because she/he can see that the reminders from the stove sensor runs more frequently.

Scenario 11: Would you feel differently if you knew that the doctor is able to see this information? Scenario 12: Would you feel differently if it was a home care personnel who told you about the memory decline?

Scenario 13: The doctor points out that [the relative] should take more responsibility for cooking.

Sensor-based actuation (future scenarios) Scenario 14: The motion sensor is installed in the bedroom. You feel that it works well and it feels safe when the lamp automatically turns on when you go up at night. You are contacted by the home care personnel who ask if you need any help with sleeping since they noticed that you go up often at nights.

Scenario 15: On the next visit, the doctor ask why you go up so often at nights. He/she suggests a medicine to help you sleep better.

Stage 5 users' opinions about the methods used for implementation and introduction of HOMEbasic. This interview session, which was conducted one month after the CAT had been removed, focused on the test person's and the relative's reflections on the approach taken in this case study. The questions asked during these interviews were: What do you think about the information you got about the CAT? What do you think about the introduction and training? In relation to each question, we asked several follow up question such as: Was it enough/not enough? How would you like to get the information/training? What was missing?

Data analysis

The collected data was analyzed in 4 steps. First, we identified the privacy preferences highlighted by the users in relation to the CAT's functionality during all stages of data collection. Second, we identified the privacy implementations from the material collected during the first stage of data collection in order to find how PbD principles were incorporated into the design of HOMEbasic. Third, we identified the users' unsolved privacy requirements in relation to each of these principles. Finally, based on the analysis and current literature, we formulated guidelines for applying PbD principles in design of the new generations of CAT.

CAT users' privacy requirements

In this section we describe users' privacy requirements in relation to the current and possible, future functionality of HOMEbasic. The section is structured according to the functionality categories presented in Table 1. For clarity, illustrative examples in relation to each principle are provided.

Calendar visualization

Some privacy concerns regarding this functionality came up already during the second stage of data collection (see Section 4.2), when we asked about users' privacy concerns in relation to HOMEbasic before they started to use it. Mainly the relatives expressed privacy concerns in this stage, while the test persons were less worried about privacy violation when using HOMEbasic. For instance, a relative in the test site that still had a teenage child at home was very concerned about the child's privacy and did not want to add any events that would reveal information about the child into the calendar even if this information would be helpful for the father who suffered from a strong cognitive decline. Another wish that came up during this stage of data collection was the possibility to delete "old" data stored in the MEMOplanner. This requirement was expressed by both the test persons and their relatives. Users preferred the data to be deleted frequently by default but if it was not possible they wanted to be reminded to do it by themselves. The users informed that the MEMOplanner may store detailed descriptions about how the activities should be performed, including sensitive information about the test person's health condition and needs. An interesting reflection that was made by one of the relatives during this stage of data collection was that privacy requirements change in line with progression of the disorder. The respondent explained: I think that when you get to that stage when you can no longer cope with things alone and need home care to help you with everything, the privacy is already forgotten. It is a sad part of it, but so it is. This means that privacy requirements are not static and that the new generation of CAT should be able to handle these changes. During this stage of data collection, two relatives also mentioned a need for limiting access to the information visible in the MEMOplanner. This need becomes more apparent during stage 3 and 4 of the data collection. For instance during stage 3, we could observe that one of the wives kept deleting events that already occurred from the calendar. Asking her about the reason for doing it, she answered: We could have done something in the morning, then maybe we had guests in the afternoon or evening, and then I thought that they did not need to know what we have done in the morning.

When discussing scenarios 1-2 in stage 4 of the data collection, we found that both the test persons and the relatives are concerned about possible privacy violations when the information in the MEMOplanner is visible for strangers who for different reasons are present in the elderly peoples' home. One of our respondents told us: I would not like it if a stranger looked at our planning [in the MEMOplanner]. I would feel uncomfortable. In this case, I would need to turn the calendar off, or somehow make information invisible. For now, the calendar is completely open. Another respondent explained: The idea is to put everything in the MEMOplanner, e.g., that you have to visit a special doctor. You may not want everyone to know about this and about what you do during the days. I think it depends on family relationships and how you are as a person. Some people do not want others to know anything…. Thus, we identified a clear need for a possibility to sometimes hide the information in the MEMOplanner.

Calendar reminders

The users' privacy concerns related to this functionality were identified mainly in stage 3 and 4 of the data collection (see Section 4.2). For instance, while visiting a test site, we noticed that the volume of the reminders was heavily lowered. As a consequence, the test person could hardly hear the voice reminders. When we asked them why they lowered the volume for the reminders, the wife explained that she felt embarrassed when the neighbors could hear the voice reminders so she decided to lower the volume. Additional clear privacy preferences were formulated by the users during stage 4 when we discussed scenarios 5 and 6. We found that the users had different privacy preferences regarding this functionality. While some users did not mind if other people heared the reminders, other users were clearly uncomfortable with this. One of our test persons told us: I don't feel comfortable with this. It makes you feel sick! I try not to think about my disorder all the time. In this case, I would get lots of questions that I do not want to get or discuss. It's a party and I also want to have fun. I would like the MEMOplanner or the reminders to be switched off just then.

Additional functionality and remote access

Privacy concerns related to this, future possible way of using MEMOplanner were revealed during stage 4 when we discussed scenarios 3-4 and 7-9. The current version of the MEMOplanner offers the possibility to store contacts and photos and to use Skype for communication. In the future scenarios, we assumed that home care personnel will have remote access to the MEMOplanner to be able to help the user to plan the activities. In the current version of the CAT, all information is equally accessible for all users and there is no possibility to restrict access to certain parts of the stored data. However, while discussing scenarios 3-4 and 7-9, we found that photos and in some cases contacts are considered as sensitive for some users and for that reason they should not be accessible for all categories of current or future users. One test person told us: I would not like it if the homecare staff looked at my photos without permission. This is not a part of their job! Maybe they would not do it, but because I cannot prevent it, I cannot be sure. Thus, the users emphasized the importance of access control mechanisms allowing them to decide who is permitted to access specific information stored in the MEMOplanner (e.g., planning, details regarding each planned event, photos etc). One of the users said: you do not want

everyone to know what information you put in [the calendar]. Then you can get worried about how that information is disseminated. You should be able to control who sees what. As it is in

other systems; some people can access the information and others cannot.

Sensor-based reminders and actuation

Privacy concerns in relation to the future use of these functionalities were discussed in stage 4 of the data collection using scenarios 10-15. We found that most test persons would welcome such functionality if the main reason for it was to help them in their disorder. However, there was a clear difference in the users' privacy concerns depending on which group of caregivers that would monitor the sensor-based reminders and actuations. The users did not have any restrictions in the case of health care professionals. They did not even care if they would be informed about the monitoring in advance or not. The users were more restrictive in the case of homecare staff. They could accept the monitoring if they were informed in advance about the purpose and extent of the monitoring. They also highlighted it as important to limit the number of home care staff (preferably only one contact person) that could access the log data. Generally, they felt that monitoring could increase their sense of safety at home, when they could no longer cope with the basic things by themselves. Table 3 summarizes the users' privacy requirements (R) in relation to CAT's functionality. Some of the requirements were clearly stated by the users, others were derived by the researchers based on users' statements.

Table 3. Summary of the users' privacy requirnements in relation to CAT's functionality

Calendar visualisation. R 1: a possibility to delete "old" data stored in the CAT (by default) R 2: new generation of CAT needs to handle changes of users' privacy needs R 3: a need for a possibility to sometimes hide the information visible in the CAT Calendar reminders. R 4: a need for a possibility to sometimes switch off voice reminders Additional functionality and remote control R5: a need for access control mechanisms allowing the users to decide who is permitted to access specific information stored in the MEMOplanner

Sensor-based reminders and actualisations R 6: a need to differentiate the access to the collected sensor data dependently of the caregivers R7: a need for knowing in advance about the purpose and extent of the monitoring.

R 8: a need to limit the number of home care staff (preferably only one contact person) that could access the log data

6

Guidelines for applying PbD principles in design of CAT

In this section, we discuss findings from the case study in relation to the PbD principles formulated by Cavoukian et al. [START_REF] Cavoukian | Remote home health care technologies: How to ensure privacy? Build it in: Privacy by design[END_REF] and existing literature. Based on the discussion, we formulate a set of guidelines for applying PbD principles in design and use of the new generation of CAT.

Principle 1: Proactive not reactive; Preventative not remedial

The importance of privacy protection is not emphasized in the documentation of the CAT which focuses on the description of functionality allowing users to live safely and independently in their homes. Based on the documentation, we can conclude that the design of HOMEbasic is safety-and functionality-driven and users' privacy is not especially emphasized. However the users highlighted many privacy concerns in relation to the existing and future possible use of CAT (see Section 5). They also expressed several privacy requirements in relation to this technology (see Table 3). Following the first PbD principle means to design CATs with these privacy requirements in mind to be able to prevent privacy invasive events before they happen. Therefore the identified privacy requirements should be considered when CAT are designed. Another important finding from our case study is that different users experience different events as privacy invasive and that contexts in which CAT are used are very different. The problem of not addressing the diversity of elderly users is highlighted in literature. The elderly users are often treated as a homogenous group with similar needs and preferences [START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF][START_REF] Bowes | Implications of Lifestyle Monitoring Data in Ageing Research[END_REF]. But to be able to truly meet elderly peoples' needs and preferences, the designers need to acknowledge and understand the differences [START_REF] Frennert | Review: Seven Matters of Concern of Social Robots and Older People[END_REF]. Thus, the designers of the new generation of CAT should consider the variety of users and contexts in which CAT can be used and design adaptable privacy solutions that prevent the privacy invasive events to happen (Guideline 1). By adaptable solutions we mean flexible solutions that are possible to adapt to the diverse privacy requirements and diverse context of the elderly users homes.

Principle 2: Privacy as the default

We found that privacy is built into HOMEbasic to some degree. For instance, the product's documentation states that the possibility to remotely access the MEMOplanner is disabled by default and must be turned on manually because of privacy concerns. In this way, the data stored in the MEMOplanner is protected against unauthorized usage by default and the users do not need to take any additional action to protect the sensitive data in the default setup. However, we discovered several examples (see Section 5) when protection of privacy required users to actively take necessary actions, otherwise there was a risk for privacy violation. In some cases, the desired level of protection was not even achievable because of lacking technical implementations, i.e., access control and screen saver. We found that our participants would like the CAT to protect their privacy by default. Protecting privacy by default may result in inflexible and unadaptable solutions that cannot handle changing privacy requirements. As described in Section 5.1, the elderly person's health situation can change over time and this can lead to changed privacy preferences. Treating privacy requirements as static is considered as being problematic in the literature [START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF][START_REF] Remmers | Environments for ageing, assistive technology and self-determination: ethical perspectives[END_REF]. Thus, the designers of the new generation of CAT should investigate users' privacy preferences to find situations when privacy protection can be built into the technology by default. Default settings should be balanced with flexibility (Guideline 2)

Principle 3: Privacy embedded into design

Regarding the third principle, we found that users would like to have additional technical solution to protect their privacy. It is argued in literature that most people are not capable of protecting their own sensitive information [START_REF] Nordgren | Privacy by Design in Personal Health Monitoring[END_REF], thus embedding privacy in technical solutions is important. However it is also argued that solely technical solutions cannot solve the complex privacy challenges that arise when using the new generation of CAT [START_REF] Zwijsen | Ethics of using assistive technology in the care for community-dwelling elderly people: An overview of the literature[END_REF]. Thus, designers of new generation of CAT should provide users with privacy guidelines and recommendations on how to protect privacy when the CAT is in use. Such guidance is missing in the CAT's documentation and manuals. (Guideline 3)

6.4

Principle 4: Functionality-Positive-sum, not zero-sum

Our findings in relation to principle 4 indicate that it is not easy to balance utility and privacy in use of the new generation of CAT. In the provided examples (see Section 5), we can see that privacy measures such as hiding information in the MEMOplanner or lowering the volume of the reminders may lead to a decreased possibility to support the person affected by cognitive decline (see Section 5.1 and 5.2). The conflict between privacy and other values such as safety and autonomy is well known in literature and often highlighted as problematic [START_REF] Nordgren | Privacy by Design in Personal Health Monitoring[END_REF]. Thus, designers of the new generation of CAT should perform a privacy and utility analysis when a new functionality is added to the system (Guideline 4). There are situations where new functionality does not contribute to utility and jeopardize privacy. Such development should be avoided.

Principle 5: End-to-end lifecycle protection

Although we studied only a small sample of seven test sites, we could observe differences in privacy preferences that depended on contextual variables such as family situation, family relationships, how active the elderly people were and how many people who visited their homes. We argue that these different privacy needs would not be identified if we did not studied the use of CAT in real settings. Thus, we can conclude that it is important to study CAT in use to be able to implement privacy measures that are relevant and adapted to the specific needs of the different users. The problem of a lack of real experiences of using CAT in practice and thus a lack of knowledge about possible privacy concerns that can arise when using such technology is highlighted in literature as problematic [START_REF] Kosta | Mobile-centric ambient intelligence in Health-and Homecare-anticipating ethical and legal challenge[END_REF][START_REF] Bowes | Implications of Lifestyle Monitoring Data in Ageing Research[END_REF]. We argue that designers of CAT should consider privacy aspects regarding the use of CAT in real settings already during the development process (Guideline 5). It can be done by involving significant stakeholders, such as primary users, secondary users, health care professionals, and other formal and informal caregivers in design of CAT.

Principle 6: Visibility and transparency

To comply with this PbD principle is a challenge in the CAT context because often elderly people have difficulties in understanding the consequences that the implemented technology have on their privacy. The problem is also highlighted in literature.

For instance Bowes at al. [START_REF] Bowes | Implications of Lifestyle Monitoring Data in Ageing Research[END_REF] argue that elderly people do not have the necessary (technical) background to formulate the appropriate privacy requirements and understand the privacy consequences of the implemented CAT. Although most of the participants told us (see 4.2, stage 5) that they experienced the CAT to be complex and sometimes difficult to use, they were able to discuss privacy issues in relation to it. The understanding came after they had used the CAT for some time in their homes and because we used methods and tolls to exemplify and visualize current and future use of the CAT i.e. scenarios, audio/video presentation .Thus we argue that it is important to use specific methods and tools to make the privacy consequences understandable and clear for the elderly people who will use the new generation of CAT (Guideline 6).

6.7

Principle 7: Respect for the users' privacy

Regarding the seventh principle, we can conclude that elderly people are both capable and willing to engage in discussions about their privacy preferences. We also found (see Section 4.2, stage 2) that elderly people do care about privacy. Generally, they are careful about how they reveal their personal information in use of technology, Internet, social media and even in their everyday life. They are mostly concerned that their personal information may be used by criminals. Regarding revealing health information, they totally trust health care professionals and are not concerned about providing such information to health care organizations. Regarding privacy in relation to information handled by CAT, we can conclude that the preferences differed between the users' depending on personal preferences, environmental factors, and family relationships. Thus, we argue that designers of CAT should involve the elderly users in the design of the new generation of CAT and the design of privacy solutions in relation to this technology (Guideline 7).

Conclusion

The rapid development of cognitive assistive technologies (CAT) from simple analogue assistive devices into complex and sophisticated sensor networks raises many new privacy issues that are not sufficiently addressed in design and use of these technologies in real homes. This paper investigated how the new generation of CAT incorporates PbD principles suggested by Cavoukian et al. [START_REF] Cavoukian | Remote home health care technologies: How to ensure privacy? Build it in: Privacy by design[END_REF]. Special attention was put on that users' privacy preferences that arise in use of new generation of CAT in real homes. Based on our empirical findings and a literature review, we suggest a set of guidelines for applying Cavoukian et al.'s PbD principles in design and use of the new generation of CAT. Using these guidelines will help to build in users' privacy requirements in the design of a new generation of CAT and in this way protect the privacy of the elderly people using these technologies. Generally, we can conclude that the existing PbD principles focus on technical aspects of privacy and often reduce privacy to the protection of personal data. Our examples (see section 5) show that some privacy concerns arising in the use of CAT are beyond this narrow view of privacy. For instance, we found that privacy in this context is not only related to the primary user of the CAT but also to people who are in the user's environment such as a child or wife etc. We argue that more research of nontechnical privacy aspects of privacy in this context is needed.

Table 1 .

 1 Summary of functionality of HOMEbasic Stove on but no motion in kitchen for x minutes.

	1. Calendar visualisation: Information of time. Calendar for structuring daily
	tasks. The user (or a remote user) can add new events to the calendar. Each
	event can consist of sub events. It is also possible to add the relative's daily
	activities helping the person with memory decline keep track of his/her rela-
	tives' activities
	2. Calendar reminders: Reminders about upcoming events.
	3. Additional functionality:Skype, photo album, contacts
	4. Sensor-based reminders:

Table 2 .

 2 CAT's functionality and scenarios used during the interviews How would you feel if someone from your family or acquaintances studied the MEMOplanner with your daily tasks planned in it?Scenario 2: Would you feel differently if it was a stranger e.g., someone helping with the renovation, who looked at your planned tasks? For instance, if you had planned a holiday?Remote access (future scenarios) Scenario 3: In this stage the test person gets help from home care staff and they can remotely access Memoplanner. A number of activities for both the test person and the relative are added in the MEMOplanner The test person is contacted by home care staff, pointing out that he exercises too little.Scenario 4: The relatives is contacted by home care staff pointing out that she should encourage her husband to exercise more. You have a party and there are a number of people in your home, acquaintances and family. The calendar reminds that [name of the test person] needs to take his medicine. The guests look at the calendar, some of them ask what it is. Some ask how [the test person] feels.

	Calendar visualisation.
	Scenario 1: Calendar reminders.
	Scenario 5:

Scenario 6: Would you feel differently if it was a stranger, e.g., someone helping with the renovation who heard the reminder?

Abilia, HOMEbasic i2, http://www.abilia.com/sv/produkt/homebasic-i2?product_category=34

2015-11-09

Abilia, MEMOplanner Handbook, fttp://www.abilia.com/sites/abilia.com/ files/field_re-source_file/4X2650_Handbook_MEMOplanner_S525.pdf 2015-11-06

Acknowledgment. The authors would like to thank the elderly participants and the Länsförsäkringar Research Foundation for making this study possible.


Acosta Fj

E Padilla

T Baccelli

K Eichinger

Schleiser

The Future of IoT Software Must be Updated

Decades of software engineering shows that updating deployed software is not a nice-to-have, but a must-have. Deployed software (e.g. an IP protocol stack) is never bug free, and these bugs must be patched to increase its robustness and security, and as communication standards and application logic evolve, deployed software typically needs to evolve in parallel. As the IoT emerges, the same will apply to deployed IoT software.

1 The Future of IoT Software

The IoT interconnects software running on low-end devices [START_REF] Bormann | Terminology for constrained-node networks[END_REF] via Internet protocol standards. Hence, IoT software resembles more and more software running on other machines on the Internet in that it can be roughly decomposed in:

1. a software platform e.g. a small footprint OS kernel [START_REF] Hahm | Operating Systems for Low-End Devices in the Internet of Things : a Survey[END_REF] and hardware drivers, 2. a network stack e.g. based on IPv6 (and 6LoW-PAN, CoAP...), 3. application(s) logic running on top of the network stack.

Concerns [START_REF] Schneier | The Internet of things is wildly insecure -and often unpatchable[END_REF] were recently voiced, pointing out that many IoT devices deployed so far are liabilities because their firmware is flashed once-for-all, without means or plans to update it, thus left as potential prey for bugs [START_REF] Tanriverdi | Als eine Glühbirne das Smart Home lahmlegte[END_REF] or attacks [START_REF]Researchers Discover a Not-So-Smart Flaw In Smart Toy Bear[END_REF].

IoT software update = Full Firmware Update.

While it is paramount to provide firmware updates to IoT devices, it is important to realize that updating IoT software cannot be limited to full firmware updates. Transmitting minimum-sized binaries updates (less than full firmware) is desirable to fit extreme lack of (energy, throughput, memory) resources on IoT device networks. ). These two parts will typically be updated independently, potentially using different means for this update. The main advantages of such software platforms [START_REF] Hahm | Operating Systems for Low-End Devices in the Internet of Things : a Survey[END_REF] is to spread IoT software development/maintenance costs, and decrease timeto-market for IoT products. For example, one can envision an IoT product (e.g. the infamous Smart Coffee Machine) using RIOT combined with specific low-level drivers and application code, resulting in the ability to update each part independently of the others.

Standard mechanisms and protocols are desirable for the update of the open-source, community-driven part of IoT software. Currently, vendors update devices only when obliged by law (warranty) or through customer pressure, as keeping devices up-todate is expensive. Many device types (e.g. washing machines) have lifetime expectancy exceeding warranties. Nevertheless, fast-evolving Internet and related threats make updates imperative even after vendor obligations run out (e.g. a functional washing machine with an expired warranty is wasted if its IoT component leaks a user's wifi credentials). With standard mechanisms and protocols as well as opensource community-driven IoT software platforms, the bulk of IoT software may thus be kept up-to-date, without significant burden nor obstacle related to vendors.

In the following, we focus mostly on updates of the open-source community-driven part of IoT software. Note however that the below considerations may also be applicable to other parts of IoT software (i.e. the proprietary part).

IoT Software Updates

The typical life-cycle of an IoT device is shown in Figure 1. Once the initial firmware is flashed and the device boots, a commissioning phase starts whereby the device joins the IoT network, comes online and may register with remote servers (e.g. a cloud service). After that, the life of the IoT device starts, during which software updates will be needed from We can distinguish 3 levels of IoT software updates:

• Full firmware update. An entirely new ROM image is fetched and installed.

• Platform update. ROM is partially updated, e.g. a peripheral driver module, or part(s) of the network stack.

• Application update. ROM is partially updated, to replace e.g. higher level, application logic, which can originate either from native code [START_REF] Oliver | Reprogramming embedded systems at run-time[END_REF], or from interpreters [4] [START_REF] Solorzano | leJOS: Java based OS for Lego RCX[END_REF].

Some parts of the ROM may be updated much more often (e.g. fixing critical network stack bugs, or slight modifications of application logic), compared to other parts of the ROM, hence the advantage of a modular approach (e.g. using a micro-kernel architecture such as RIOT's [START_REF] Baccelli | RIOT OS: Towards an OS for the Internet of Things[END_REF]) and not systematically resorting to full-firmware updates.

Basic software updates can be coarsely decomposed in the following phases. At first sight, establishing standards would be useful for (i) meta-data information, (ii) communication protocols between IoT devices and repositories, (iii) authentication of updates, and (iv) potentially, also for in-network caching or proxying of repository role and contents. Some further considerations below.

When to update?

Some logic is needed on the IoT device to evaluate if conditions for the software update are satisfied locally (checking parameters such as: battery level, radio signal strength, free storage memory to store the update, enough memory to run it, sanity/signature checks...). However, updates always imply (even if minimal) downtime. Some level of human control may thus be desirable to ensure downtime does not happen at a critical time (e.g. rebooting smart lights go off during a speech of the Queen of England). The criticality of the update depends both on (i) how central the module is, e.g. if it affects online status for the device, and (ii) how central the IoT device is, e.g. updating and rebooting intermediate, upstream devices may induce failed connectivity for down-stream devices. For large IoT deployments, standard IoT software update strategies may need to capture the system as a whole, instead of per-device.

Who updates?

Humans involvement should be limited to pushing (properly signed) new versions of IoT software to a well-known IoT software repository. The rest should be automatic. However, as mentioned in Section 2.1, authorized humans should also be able to signal "please don't update within this time window" to their IoT devices. Furthermore, as mentioned in Section 1, different authorities may update different parts of IoT software on the same device, independently.

What to update?

Standardization of IoT software name-space and meta-data is needed to identify what to update. These standards will be necessary both for IoT software repository management, and for IoT device system aspects e.g. representing on the device current modules, kernel, applications and detecting new components and versions on the fly. Prior work in this area includes for instance adapting to resource constraints of low-end IoT devices the model@runtime paradigm [START_REF] Padilla | Towards a model@ runtime middleware for cyber physical systems[END_REF] which provides a systematic representation of repository locations, software module specifications, communication bindings between IoT devices. In the future, IoT software will be in large part hardware independent, and may also be software platform independent (e.g similar to POSIX compliant software, outside of IoT), which highlights further the need for standardization in this domain.

How to distribute updates?

There are two aspects to distribution of software updates, (i) where the software updates are stored and (ii) how the software updates are accessed.

Where are software updates stored? Updates may be in a single repository, or may be replicated in several places in the network. Replication "somewhere on the Internet" is a well-known field and out of scope of this paper. On the contrary, replication (or cache/proxy) of software update contents within the LoWPAN is in scope a priori. The wireless sensor network research community worked on this topic, and new approaches such as Information Centric Networking (ICN) in IoT contexts may also be considered to manage in-network caching of software update contents.

How are software updates accessed? The part of the communication outside the LoWPAN is a wellknown field, out of scope of this paper. Inside the LoWPAN, one must distinguish two cases: single-hop scenarios and multi-hop scenarios.

The single-hop scenario typically consists in a starshaped topology, centered on a gateway to the Inter-net. In this case distribution of updates is straightforward through the gateway's point-to-point link with each IoT device, typically over standard protocols including UDP, IPv6, 6LoWPAN and a low-power MAC (optimizations using broadcast from the gateway are of course possible, e.g. to announce the availability of new updates).

The multi-hop scenario is more diverse, and requires routing inside the LoWPAN, and may benefit of in-network caching of software components. Approaches were proposed such as Deluge [START_REF] Hui | The dynamic behavior of a data dissemination protocol for network programming at scale[END_REF] and FiGaRo [START_REF] Mottola | FiGaRo: fine-grained software reconfiguration for wireless sensor networks[END_REF] for software update distribution algorithms on multi-hop networks, to all devices (Deluge), or to a subset fo devices (FiGaRo).

In all cases, simpler logic on IoT devices may be possible if one assumes the gateway is a trusted proxy and takes some tasks from the IoT devices (The update process could also benefit from its potential knowledge of the LoWPAN e.g. duty cycles of devices, parameters on MAC layer level, routing information etc.).

How to update securely?

Aside of network-level security (securing communication channels to transmit the update binary etc.) security is typically provided by checks based on signing [START_REF]Why You Want Firmware Updates, ThingSquare Blog[END_REF] the binary (or a hash, the signature check of which is lighter work for small processors). A trend is developing whereby IoT hardware embarks security chips [START_REF] Nxp | A710x family: Secure authentication microcontroller[END_REF] [START_REF] Technologies | OPTIGA TRUST P SLJ 52ACA[END_REF] to speed up cryptographic computations, and that provide means to store keys securely (such hardware also provide means to store keys securely and aim to make it impossible to install updates when the signature does not match a stored key). Alternatively, the gateway (or home router) might take over some security overhead by checking signatures on behalf of IoT devices etc.

Limits of security through updates? On one hand, the unavailability of updates can be destructive: early adopters of smart home hub Wink were frustrated [START_REF] Barrett | Wink?s Outage Shows Us How Frustrating Smart Homes Could Be[END_REF] when their devices could not be remotely updated to fix a critical bug. On the other hand, forced updates can also be destructive. For example, Nest reportedly decided to remotely "update" IoT software on home automation hubs, in effect bricking [START_REF] Gilbert | The time that Tony Fadell sold me a container of hummus[END_REF] them intentionally, apparently without consent of users...

Figure 1 :

 1 Figure 1: IoT device life-cycle.

1 . 5 .

 15 IoT software repositories push meta-data information about software updates to the IoT device, when newer updates become available 2. The IoT device selects what updates it should/can accommodate 3. The IoT device pulls selected updates from a repository 4. The IoT device proceeds to verify and install received update(s) If the installation fails, roll-back to previous version

  On one hand, compared to the rest of the Internet, the current state of the IoT is

	veloped independently from another part pulled from
	community-driven, open source IoT software develop-
	ment (e.g. RIOT [8][6]
	fragmented in that a plethora of heterogeneous hard-
	ware and network technologies deserve support (more
	or less) equally. Yet, on the other hand, the IoT is
	more captive in that silos dominate, whereby vendors
	typically sell turn-key bundles gathering proprietary
	IoT hardware, software, gateway and network tech-
	nology (and even sometimes cloud services) in the
	same package. However, in the near future we can ex-
	Updates with Multi-User Device Ownership.
	Another important point to realize is that, while
	IoT software updates might be considered a "solved"
	problem in proprietary contexts with homogeneous
	IoT devices (signed images distributed using some
	flavor of multicast, safe upgrading with roll-back
	through ping-pong), future IoT software updates will
	be more complex. Future IoT software updates
	will have to accommodate configurable, multi-user
	ownership, administrative groups etc. For exam-
	ple, a smart house or parts of an apartment com-
	plex equipped with IoT devices will frequently change
	owners, or host short-term leases with only restricted
	access rights. Standard protocols and software will be
	needed for grouping IoT devices and handling own-
	ership in a flexible manner.
	Standards for Community IoT Software.
	Once silos are broken, IoT hardware heterogene-
	ity and open source IoT device software stacks will
	change the way IoT software is conceived. Future
	IoT software will be composed of a vendor-specific
	part (potentially proprietary and closed-source) de-

pect the market to resemble the Internet: basic-level interoperability requirements will break silos, consolidate IoT hardware and network technologies into fewer, dominant approaches. In particular, a natural consequence on IoT software will be the emergence of a market for hardware-independent IoT software, and thus lead to a state where different stake holders could originate and modify different parts of the IoT software on devices (e.g. application separately from software platform).


C Gündogan
email: cenk.guendogan@fu-berlin.de

C Adjih

O Hahm

E Baccelli

Let Healthy Links Bloom: Scalable Link Checks in Low-Power Wireless Networks for Smart Health

Keywords: RPL, Bloom-RPL, Bloom filter, scalable unreachability detection

Low-power, memory-e cient networking mechanisms are an essential part of the Internet of Things (IoT) and thus, fundamental to Smart Health applications leveraging IoT. This paper presents Bloom-RPL, an optimization of RPL, the standard low-power routing protocol for IoT. This paper evaluates Bloom-RPL both on an emulator, and on an IoT testbed using real hardware, to conclude that Bloom-RPL dramatically improves RPL's link check scalability with respect to both IoT device density and convergence time needed to detect a link break.

INTRODUCTION

Sensor networks are a substantial part of the devices expected in the Internet of Things (IoT). Sensors are IoT devices used for distributed and automated monitoring of various environmental parameters such as temperature, movement, noise or radioactivity levels etc. Sensors are also expected to be leveraged in various smart health applications leveraging IoT, such as quantified-self applications [START_REF] Swan | Sensor mania! the internet of things, wearable computing, objective metrics, and the quantified self 2.0[END_REF], and medical applications such as ambient assisted living applications [START_REF] Dohr | The internet of things for ambient assisted living[END_REF]. While some of these sensors will connect to the network via wire or power line communication, most sensors will use radio communications.

Typically, a number of sensors are scattered in the zone to be monitored e.g. a body, a room or a house ACM ISBN .... DOI: ... (for on-premises smart health applications) or a small building (e.g. for smart health applications at a hospital). Each sensor then monitors the parameters to be measured in its vicinity and communicates through its single radio interface with its peers, spontaneously creating a wireless network. Using this network, sensors self-organize distributed computations, or convergecast, i.e. information gathering at a central control pointwhich is generally called the sink, in this context.

As shown in Fig. 1, sensors can directly communicate with the sink (single-hop case), or may require peers to forward information towards the sink (multi-hop case), because the sink is outside of its radio range e.g. due to deliberately lower power transmissions to save energy or limit interferences, or due to heterogeneous wireless technologies. Appropriate network protocols are thus required to enable each sensor to, on one hand, establish direct communication with peers that are within its radio range, and on the other hand, establish communication with other devices, reachable through peers with which the sensor can directly communicate. LLNs. For that matter, recent work enables the use of IP protocols [START_REF] Sheng | A survey on the IETF protocol suite for the internet of things: Standards, challenges, and opportunities[END_REF] in LLNs, allowing IoT applications that are natively interoperable, end-to-end, with the rest of the Internet . In this paper, we will focus on such approaches, using an IPv6 protocol suite on top of LLNs.

The contributions of this paper are as follows. First we overview the interplay of standard IPv6 protocols for link check and routing in LLNs. Then we analyze available implementations of these protocols: we show via testbed measurements that link check mechanisms used in these implementations o↵er poor scalability w.r.t. node density and convergence time. We then introduce Bloom-RPL, an alternative link check mechanism for RPL, which we also evaluate via testbed measurements showing significantly improved scalability.

LLN ROUTING AND LINK-CHECKING

In LLNs, mechanisms are needed at the network layer to (i) check link viability between devices, and (ii) establish paths across multiple intermediate (viable) links, i.e. routing.

Standard Link Checking in LLNs

The most basic form of link check verifies that a neighbor node is reachable through an interface connecting to a given link. Reachability of node B over a link is generally defined for node A as such: B can receive link layer transmissions from A and vice versa, i.e. the link between A and B is bidirectional.

Neighbor Discovery Protocol

The standard link-check protocol in the IPv6 suite is NDP [START_REF] Simpson | Neighbor Discovery for IP version 6 (IPv6)[END_REF]. NDP performs a number of tasks, among others: Neighor Unreachability Detection (NUD), Router and Prefix Discovery.

To perform its tasks, NDP uses ICMP messages. Router Advertisements (RA) and Router Solicitations (RS ) respectively announce and request default router information. Neighbor Advertisements (NA) and Neighbor Solicitations (NS ) respectively announce and request nodes' addresses for purposes including duplicate address detection, link-layer address resolution, and reachability verification. NDP maintains on each node a Neighbor Cache, a set of entries tracking known neighbor's link-layer address, role (router or host), and reachability (determined by NUD).

6LoWPAN-ND [START_REF] Shelby | Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)[END_REF] is an optimization of NDP for LLNs to reduce multicast signaling and support sleeping hosts. 6LoWPAN-ND leverages the central role of the sink (called 6LoWPAN Border Router (6LBR)) to perform (multi-hop) distribution of prefixes and context information, as well as duplicate address detection.

Other Techniques

Various mechanisms have been proposed to reduce bits-over-the-air for link checks. For example in [START_REF] Mutaf | Compact neighbor discovery: a bandwidth defense through bandwidth optimization[END_REF], authors propose to group several su xes in a Bloom filter [START_REF] Bloom | Space/time trade-o↵s in hash coding with allowable errors[END_REF] sent in a "compact neighbor discovery" message (CND) instead of several IPv6 ND messages. In [START_REF] Ellard | DTN IP Neighbor Discovery[END_REF] authors propose to represent neighbors in hello messages with a Bloom filter, to e ciently check link bidirectionality. More elaborate link checks evaluate links beyond mere reachability: a number of metrics have been designed, such as for example ETX [START_REF] Heinzelman | Energy-e cient communication protocol for wireless microsensor networks[END_REF] or DAT [START_REF] Rogge | Directional airtime metric based on packet sequence numbers for optimized link state routing version 2[END_REF], which associate to a link a value (in N or R) representing the quality of the link. However, in this paper we focus on basic link checks testing bidirectionality, associating to a link a value in {0, 1}.

Standard Routing in LLNs

Routing in LLNs is typically performed with RPL [START_REF] Winter | RPL: Routing protocol for low power and lossy networks[END_REF], which organizes routers along a Destination Oriented Directed Acyclic Graph (DODAG), rooted at the sink (router S in Fig. 2). The sink initiates the formation of the DODAG by periodically originating (DIO) messages via link-local multicast. DIO messages carry information that include the root's identity, the routing metric, and the originating router's depth in the DODAG, called the rank. A router joins the DODAG based on DIOs from its neighbors, and can thereby determine its own rank, choosing the parent that would yield the smallest rank. Once a router has joined the DODAG, the router has a path to the sink through its parent, and the router can in turn originate its own DIO messages. RPL thus provides paths from a router to the sink while requiring minimal forwarding/routing information storage.

In order to decrease control tra c overhead, the transmission rate of DIO messages follow a Trickle [START_REF] Levis | The trickle algorithm[END_REF] policy which aims at pruning unnecessary transmissions. When a node's data di↵ers with its neighbors', that node communicates quicker to resolve the inconsistency, otherwise it slows down the propagation of DIO messages.

RPL extensions & other approaches

RPL defines complementary mechanisms for routing from sink to sensors and extensions have been proposed to route from sensor to sensor without going through the sink. For example, ORPL [START_REF] Duquennoy | Let the tree bloom: Scalable opportunistic routing with orpl[END_REF] uses a technique based on Bloom filters [START_REF] Broder | Network applications of bloom filters: A survey[END_REF] to detect shorter paths from sensor to sensor. P2P-RPL [START_REF] Martocci | Reactive discovery of point-to-point routes in low-power and lossy networks[END_REF] uses a reactive routing technique to discover and establish paths from sensor to sensor without going through the sink. However, such mechanisms are optionally, and the focus of this paper is paths from sensors to sink (i.e. convergecast), a purpose for which RPL is currently the dominant approach.

RPL and NDP in Practice

RPL specification mandates that parent-child link checks are performed before being used, but does not specify how to perform these checks. RPL instead relies on external mechanisms to perform link checks, either (i) network layer signaling, e.g. NDP/NUD such as described in section 2.1, or (ii) lower layer signaling e.g. absence of link-layer acknowledgements, or (iii) upper layer signaling e.g. absence of end-to-end acknowledgement of application data.

Reactive vs Proactive Link Checks

Parent-child link checks can either be performed reactively or proactively. In a reactive scheme, link checks are performed only when applications need to send data over the link. In case the link to the parent turns out to be defunct, the child starts the procedure to rejoin the DODAG through another parent. A reactive approach works fine in a single-hop case, while requiring minimal amounts of control tra c and small convergence time in the order of link-layer RTT if link-layer signaling is usable, or else, end-to-end application layer RTT. However, in multi-hop cases, reactive approaches yield terrible worst-case performance as its mechanism may have to be performed recursively along the path towards the sink, potentially leading to unmanageable convergence time. For this reason, proactive approaches are favored, whereby parent-child link checks are performed regularly, independently of application data triggers.

NDP vs RPL Functionalities Overlap

In practice, NDP and RPL functionalities overlap substantially. Router and prefix discovery, next-hop determination and address autoconfiguration are functionalities provided by NDP that can be substituted entirely by RPL. The multi-hop propagation of context information used for header compression is not supported with basic RPL specification [START_REF] Winter | RPL: Routing protocol for low power and lossy networks[END_REF]. However, compression is not mandatory, and if desired, could easily be piggy-backed with the prefix information dissemination mechanism of RPL. In minimal network setups, nodes can use stateless address autoconfiguration [START_REF] Narten | IPv6 Stateless Address Autoconfiguration[END_REF] to derive IPv6 addresses from their (assumed) unique linklayer addresses, which makes the address resolution and duplicate detection functionalities of NDP superfluous. Under these circumstances, unreachability detection is the only mandatory mechanism not supported by RPL.

We evaluated ROM/RAM usage due to NDP in a minimal IoT application implemented on top of RIOT [START_REF] Baccelli | RIOT OS: Towards an OS for the Internet of Things[END_REF] that sends sensor readings from a sensor to a sink using IPv6 and 6LoWPAN protocols. By removing NDP and the neighbor cache from RIOT's network stack, the same functionality can be achieved with ⇡ 5,5 kB less ROM and ⇡ 2 kB less RAM. For perspective, this requires roughly 25% ROM for the binary on popular IoT hardware based on 32-bit ARM Cortex M, thus freeing memory (usually in high-demand on lowend IoT devices) that can be used for high layer applications.

However, as analyzed above, an approach eliding NDP requires to provide mechanism that perform link checks. In the following, we thus study link check mechanisms directly built into RPL.

RPL Link Checks: Available Implementations

To check links between a child and its parent, the most popular RPL implementations available (e.g. in Contiki [START_REF] Dunkels | Contiki -a lightweight and flexible operating system for tiny networked sensors[END_REF] and RIOT [START_REF] Baccelli | RIOT OS: Towards an OS for the Internet of Things[END_REF]), use a mix of dedicated, proactive unicast tra c (DIS/DIO message handshakes mimicking NDP's NS/NA exchanges) and an ETX metric [START_REF] Heinzelman | Energy-e cient communication protocol for wireless microsensor networks[END_REF] computed on both user tra c and control traffic. For simplicity, we consider an approximation of this technique which uses only DIS/DIO message handshakes, which results in the same number of data and control transmissions and the same amount of bytes over-the-air. The scalability of such link check mechanisms is questionable with greater node density, quicker convergence time. In the following we measure the performance of the available RPL implementations using DIS/DIO link checks and we propose an alternative link check mechanism which, as our comparative measurements show, provides much better scalability.

DIS/DIO LINK CHECK PERFOR-MANCE

In the following, we will measure the performance of DIS/DIO link checks. We first use a simple topology of three nodes, emulated on RIOT native [START_REF] Riot | Native[END_REF]: One DODAG root (a) and two children (b, c), initially connected via bidirectional links ab, ac and bc. The links ab and ac alternate every 60 seconds between up and down (when one link is up, the other is down). We then measure in Fig. 3 the average time during which connectivity between child and parent remains down, when connectivity is lost, and link check period is L p . Connectivity was checked by sending sensor readings from b and c to a, and we measured the average time until which an acknowledgement from a was received respectively. Unsurprisingly, we observe that average duration of connectivity loss grows approximately in Lp 2 . In order to minimize down-time, more frequent link checks should be used.

However, more frequent link checks lead to significantly more control tra c, as shown in Fig. 4. In this experiment, we measured the amount of DIS and DIO packets received by the DODAG root, with varying number of children and link check periods. All nodes were in hearing range of the root node, thus forming a star topology and the experiments were carried out on real hardware in the IoT-LAB testbed [START_REF] Adjih | FIT IoT-LAB: A Large Scale Open Experimental IoT Testbed[END_REF]. We observe in Fig. 4 that RPL control tra c explodes when the number of children and/or the link check frequency increases. We can therefore conclude that this approach is not scalable w.r.t. node density and undetected downtime reduction.

BLOOM-RPL

In this section, we present an optimization of RPL that substantially improves the scalability of link-checks between parent and child in the DAG, based on an approach using Bloom filters, loosely inspired from [START_REF] Ellard | DTN IP Neighbor Discovery[END_REF].

Overview of Bloom-RPL

The parent-child relationship that is formed with RPL's DODAG tree structure usually resembles an asymmetric relationship, where few nodes serve as parents for multiple children. Checking and caching bidirectionality information requires a parent to store an amount of states equal to the number of its children and thus is directly related to the node density.

Contrary to the unicast DIS/DIO approach described in section 3, Bloom-RPL reuses RPL's multicast control messages, so that bidirectionality of links between parent and children are verified with less tra c.

However, using multicast DIO messages to verify link bidirectionality requires children information in each of such messages, leading to message sizes that grow proportionally to the number of children instead of be-ing constant. To mitigate this fact, Bloom-RPL utilizes Bloom filters to compress the children information, thusly making it more suitable for a multicast dissemination. The main drawback of Bloom-RPL is that Bloom filters introduce loss of information and potential false positives during link checking. Nevertheless, as demonstrated experimentally below, Bloom-RPL provides a functional and advantageous solution.

Additions to RPL

The following represents a list of conceptual additions that Bloom-RPL introduces to RPL.

• NBF: Neighborhood Bloom filter used to compress and store the children information.

Link Checking Procedure

Bloom-RPL adds NAO and PAO options to classical DIO messages from RPL. They are sent either at expiration of Trickle intervals or as replies to DIS from children. The NAO advertises the current NBF and the PAO advertises parent(s).

The first part of the protocol consists of parents discovering their children. Every time a child is confirmed to the parent, the NBF is updated with the child's linklocal IPv6 address. Confirmation occurs when an unicast DIS, or DAO (in Storing Mode) is sent from child to parent. Upward control messages are also used, if a PAO is included and matches the parent's link-local IPv6 address.

The second part of the protocol consists in a child checking if its parent actually discovered it: this is verified when the child link-local IPv6 address appears in the NAO sent by its parent. If so, then the link towards the parent will be marked as bidirectional. Otherwise: the child will retry the link checking with DIS messages (unicast or multicast) containing a matching PAO, for L cr times. If this procedure fails, a parent's link-local IPv6 address will be blacklisted (stored in the BBF ), its subsequent DIO messages will be ignored and the node will search for another parent. Ultimately, all nodes end up with a parent with a symmetric link.

Finally, to handle the case of disappearing links, if the last received NAO is older than L p seconds, the parent will be marked as unidirectional and the link check procedure is repeated by soliciting a new NAO.

Bloom Filter Maintenance

While basic Bloom filters support insertion and set membership queries, it is not trivial to remove specific entries from the set. The simplest approach is to reset the NBF periodically to trigger the children to perform link checks. The disadvantage of this method is however, that a variety of children would start this procedure at the same time. To alleviate this case, we decided to use the double bu↵ering technique [START_REF] Tarkoma | Theory and practice of bloom filters for distributed systems[END_REF]. Hence, our NBF consists of an active NBF a and an inactive NBF i bitmap of same size. Until a certain point in time NBF w , entries will be inserted into NBF a , and in both bitmaps thereafter (warm-up phase). Once time passes NBF r , both bitmaps switch their roles and the former NBF a will be reset (reset phase). For the dissemination of the children information inside NAOs, NBF a is used and it is noteworthy, that due to warming up the Bloom filter, NBF a consists of recent children information.

Piggy-backing optimization. Once a NAO is requested by DIS messages, a parent delays the solicited DIO for NAO d seconds. Thus, subsequent solicitations falling into this interval can be aggregated and answered with only one multicast DIO in return. The time between link check retries (L cri ) should be greater than NAO d .

Experimental Evaluation of Bloom-RPL

We present below experimental measurements evaluating Bloom-RPL, comparatively to the unicast DIS/DIO approach. Bloom-RPL was implemented on top of RIOT [START_REF] Baccelli | RIOT OS: Towards an OS for the Internet of Things[END_REF] and experiments were carried out on real hardware, on the IoT-Lab testbed [START_REF] Adjih | FIT IoT-LAB: A Large Scale Open Experimental IoT Testbed[END_REF]. In these experiments, we vary both the number of children of the root (i.e. the node density) and the link check frequency. We observe the network for periods of 10 minutes in row. Note that Trickle-induced multicast DIO messages decrease rapidly in the initial minute, and becomes negligible tra c thereafter. The size of NBF was set to 32 bytes in order to support node densities of up to 40 nodes with a false positive rate of less than 5% (derived from the well-known analytic formula, e.g. see [START_REF] Broder | Network applications of bloom filters: A survey[END_REF]). For node densities of larger than 40 nodes and up to 100 nodes, a size of 64 bytes was chosen to provide a maximum false positive rate of ⇡ 10%. The reset phase was entered after NBF r = 90 seconds and the warm-up phase started after NBF w = NBFr 2 seconds.

Fig. 5 shows the ratio of link checks that were performed by Bloom-RPL in relation to unicast DIS/DIO. We note a drop in link checks performed by about 20% to up to 60%. This derives from the dissemination of compressed children information in each multicast DIO, which is in turn received by all children and triggers a refresh of certain link check periods. Additionally, the double bu↵ering technique provides a Bloom filter that is pre-filled reasonably in each warm-up phase. Fig. 6 depicts the amount of control tra c bytes over the air. We observe that Bloom-RPL generates up to 80% less control tra c in bytes compared to unicast DIS/DIO when the node density and/or the link check frequency is bigger, due to the fact that Bloom-RPL eliminates the unicast DIO tra c for link checks. Unsurprisingly, Bloom-RPL requires more control tra c for lowest densities (cases where parents have one child), but this represents a tolerable, small overhead in absolute value. The amount of control packet transmissions of Bloom-RPL compared to the DIS/DIO approach is shown in Fig. 7. We observe that Bloom-RPL requires 60-75% less control packets compared to DIS/DIO when node density grows to 40 nodes per radio range (savings would be even bigger in case of bigger densities). In Fig. 8, we measure sensor data packet delivery ratio in a network with varying node density: each node sends to the sink a sensor reading periodically, with interval of 300 ms and 100 ms jitter. We observe that Bloom-RPL provides a functional network with an acceptable PDR (above 70%) when node density grows to 80 nodes per radio range, while the DIS/DIO approach requires so much control tra c that sensor reading traffic experiences a rather dysfunctional PDR around 30%. In this paper we have presented Bloom-RPL, an optimization of RPL's link check mechanism for low-power wireless networks using IPv6 in Smart Health applications. Both simulations and experiments on real hardware show that Bloom-RPL provides significantly improved scalability in terms of IoT device density and convergence time needed to detect a link break. Using an approach piggy-backing RPL's multicast tra c and compressing children information with Bloom filters, we achieved 75% reduction in control tra c packets and 80% less control tra c bytes when node density is large. Even more gains would be obtained with even larger densities. In e↵ect Bloom-RPL does not only save energy, but also provides an acceptable PDR for larger node densities while detecting faster links that are down, compared to basic RPL implementations that are available to date. These properties allow to significantly decrease the amount of health sensor data that is lost, which can be critical in Smart Health scenarios.

CONCLUSION

Figure 1 :

 1 Figure 1: Low-power wireless network with sink, single hop case (right), multi-hop case (left). Several technologies are used for direct, single-hop wireless sensor communication at the link layer. Prominent low-power radio technologies include for instance IEEE 802.15.4, Bluetooth, DASH7, IEEE 802.11ah. The network obtained using such radio technologies is thus traditionally called a Low-power Lossy Network (LLN). Complementary mechanisms are necessary at the network layer to enable multi-hop communication in

Figure 2 :

 2 Figure 2: DODAG rooted at router S.

Figure 3 :

 3 Figure 3: Average duration of connectivity loss w.r.t. link check interval L p .

Figure 4 :

 4 Figure 4: RPL control tra c transmitted with varying link check interval L p and node density.

Figure 5 :

 5 Figure 5: Comparison of link checks performed between unicast DIS/DIO and Bloom-RPL.

Figure 6 :

 6 Figure 6: Ratio of control tra c in bytes between unicast DIS/DIO and Bloom-RPL.

Figure 7 :

 7 Figure 7: Ratio of control tra c between unicast DIS/DIO and Bloom-RPL.

Figure 8 :

 8 Figure 8: Avg. packet delivery ratio (PDR) between unicast DIS/DIO and for Bloom-RPL.

  • NBF a /NBF i : Active/Inactive bitmap of the double bu↵ering technique. • NBF w /NBF r : Warm-up and reset time of the double bu↵ering technique. • BBF: Bloom filter to blacklist link-local IPv6 addresses of parents with unidirectional links. • NAO/NAO d : Neighborhood Announcement Option in DIO to propagate NBF and time in seconds to delay it. • PAO: Parent Announcement Option in multicast DIS/DIO to propagate parent information. • L p : Period in seconds to check link bidirectionality initiated by a child. • L cr /L cri : Number of retries until link is marked unidirectional and interval in ms between retries.