École Sigle

Doctorale

Renée El

Melhem Bat

Blaise Pascal

Insa : R Gourdon

M Stéphane

M C Havgoudoukian

M Gérard Scorletti
email: gerard.scorletti@ec-lyon.fr

Sylvie Roberjot

M Philippe
email: philippe.normand@univ-lyon1.fr

M Lagarde

Mme Emmanuelle
email: emmanuelle.canet@univ-lyon1.fr

M Luca

Marion Combe

Jean-Yves Buffiere
email: jean-yves.buffiere@insa-lyon.fr

M Jocelyn Bonjour

Viviane Polsinelli
email: viviane.polsinelli@univ-lyon2.fr

Brigitte Dubois

J Y Toussaint

M Christian Montes

Prof Valeria Anne Julien-Vergonjanne

Prof Emmanuel Loscri

Chaput

Yota, Oana, Sophie, Giulia, Jad Elli

Walid, Amjed, Khaled, Aderrahman, Domga Ahmed Fabrice

Aziz Manoel

Fabien

Didier Corentin

Marc Sylvain

Keywords: Communication par Lumière Visible, Internet des Objets, Smartphone, Optical Camera Communication, Communications Sans-Fil, Codage Linéaire

Foremost, I would like to express my sincere gratitude to my advisors Razvan Stanica and Herve Rivano for the continuous support of my PhD study and research, for their patience, motivation, enthusiasm, and for always having taken me in the right direction. Their guidance and caring reviews always helped me

Abstract

With the exponential growth of the Internet of Things (IoT), people now expect every household appliance to be smart and connected. At the same time, smartphones have become ubiquitous in our daily life. Their continuous performance improvement and their compatibility with a broad range of radio protocols as WiFi, Bluetooth Low Energy (BLE) or Near Field Communication (NFC) make them the most convenient way to interact with these smart objects. However, providing wireless connectivity with BLE or NFC means adding an extra chipset and an antenna, increasing the object size and price. Also, this kind of hardware modification is not without impact: even if the radio chip cost is negligible for a single unit, it may become huge when millions of products are sold.

On the other hand, previous works already have demonstrated the possibility of receiving information through visible light using an unmodified smartphone thanks to its camera. Also, LED-to-LED communication for smart devices like toys has been shown previously. However, past efforts in light-emitting diode (LED) to camera communication for IoT device-to-device communication have been limited.

In this work, we address this question and design LightIoT, a bidirectional visible-light communication (VLC) system between a low-cost, low-power colored LED that is part of an IoT device and an off-the-shelf smartphone. The IoT device is thus able to send and receive information through its LED, while the smartphone uses its camera to receive data and its flashlight to send information.

We implement and experimentally evaluate a LED-to-camera VLC system, designed specifically for small LEDs. The proposed solution exploits the rolling shutter effect of unmodified smartphone cameras and an original decoding algorithm, achieving a throughput of nearly 2 kb/s in ordinary illumination conditions. Based on the insight gained from an extensive experimental study, we model, for the first time in the literature, the LED-to-camera communication channel, characterized by an on/off behavior resulting in a close to regular frame error pattern. We propose a Markov-modulated Bernoulli process model, which vi allows us to easily study the performance of different message retransmission strategies. We further exploit this model to implement a simulator for LED-to-Camera communications performance evaluation.

In order to achieve bi-directional communications, we evaluate flashlight-to-LED communications using non-rooted smartphones and small LEDs. With these hardware constraints, our implementation achieves a throughput of 30 bits/second. While obviously limited, this is enough for a feed-back channel coming to support the required redundancy mechanisms. Some of these redundancy mechanisms are based on random linear coding, long time considered as a possible solution in VLC, but never tested previously. Therefore, we design and implement, for the first time in the literature, a pseudo random linear coding scheme especially fitted for line-of-sight LED-to-camera conditions. Experimental evaluation highlights that this type of approach increases the goodput up to twice compared to classical retransmission strategies.

Finally, many of the small objects we address through LightIoT have significant energy constraints. Therefore, we compare the energy consumption of LightIoT with the one of a BLE module with similar activity. Our results show that using the LED for communication purposes reduces the energy consumption under a normal usage behavior. Rtone [START_REF]Rtone -IOT Makers[END_REF] is an innovative small and medium-sized enterprise (SME) funded in 2007, whose main activity is the design and the development of smart wireless IoT devices for third party companies. The team counts about thirty engineers with expertise in hardware conception, firmware, mobile phone or web application development. Thus, Rtone is able to build a whole IoT system from the specifications to the cloud. This PhD work falls into an evolution of the company strategy started in 2015.

KEYWORDS: Visible

Focusing on achieving competitive advantage with a high added value, Rtone decided to increase the research and development investments to develop an intellectual property portfolio. p In this context, the purpose of this thesis was the design and the implementation of an innovative wireless communication system using visible light for highly constrained IoT devices. One of Rtone expectations is the integration of such visible light communication system in its customer products. The green packets are succesfully received, the orange ones are truncated and the reds are lost between two consecutive frames and so do not appear in any frame. . . . . . . . . . . . . . . . . . . . List of tables

Table of contents

List of figures xv

List of tables xix

List of acronyms xxi

List of acronyms

AOT Ahead-Of-Time

ART Android Runtime

Chapter 1

Introduction

Visible Light Communication

Visible-light communication (VLC) is an enabling technology that exploits illumination to provide a short-range wireless communication link. VLC systems take advantage of the license-free light spectrum and their immunity to radio frequency (RF) interference. In such systems, information is often relayed by modulating the output intensity of the LEDs, whereas, at the receiver side, the data signal is recovered using simple photodiodes (PDs).

The firsts efforts of using LEDs both for illumination and communication date to the year 2000 when researchers from Keio University in Japan proposed the use of white LED in homes for building an access network [START_REF] Tanaka | Wireless optical transmissions with white colored led for wireless home links[END_REF]. The topologies supported by the MAC layer are peer-to-peer, broadcast and star.

In the star topology, all the nodes communicate with each other through a single centralized controller. In the peer-to-peer topology, the controller role is performed by one of the two nodes involved in communication with each other.

Three classes of devices are considered: vehicles, mobile and infrastructure.

Nonetheless, many VLC use cases and VLC technologies are not taken into account in these standards. Also, VLC systems can use other types of light source and light sensors, according to the requirements of the application environment.

That is why the IEEE Task Group 7m, firstly known as IEEE 802.17.5r1, has been initiated in late 2014 to revise the IEEE 802.15.7-2011 standard. The IEEE 802.15.7m amendment will be released by the end of 2018.

In fact, any light sources which can switch states at a high rate (i.e. transition between ON and OFF) can be used as transmitters for VLC systems. Consequently, screens can also be used as transmitters, as suggested in [START_REF] Li | Real-Time Screen-Camera Communication Behind Any Scene[END_REF][START_REF] Hao | COBRA: color barcode streaming for smartphone systems[END_REF][START_REF] Hu | Strata: Layered coding for scalable visual communication[END_REF][START_REF] Li | HiLight[END_REF].

These techniques use barcodes or QR codes displayed on screens to encode in- formation. HiLight [START_REF] Li | HiLight[END_REF] is a new form of a screen-to-camera link, which encodes data into pixels translucency. This technique can efficiently transmit information without being obstructive to the displayed image or video.

Any electronic device which can detect the presence or absence of visible light can be utilized as a VLC receiver. Most of the work is focused towards using PDs as receivers, because of their fast response and high bandwidth. Works like [START_REF] Schmid | An LED-to-LED Visible Light Communication system with software-based synchronization[END_REF] show that regular LEDs can operate as a receiver in reverse bias mode, but they have limited sensitivity as compared to PDs. Smartphone cameras can also be used to detect high-frequency light patterns, as discussed in [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF].

In a nutshell, VLC emitters can either be 1) modulated ceiling LED, 2) low power and often colored LED, 3) screens, and 4) passive light, such as the incandescent light bulbs and fluorescent light tubes. VLC receivers are for their part 1) photodiodes specifically built to sense light, but also 2) LED which first purpose is to emit light, and finally 3) cameras.

To get a clearer view on VLC capabilities and sort manifold VLC systems, we propose a taxonomy in Tab.1.1, where each cell corresponds to a type of emitter and receiver.

Motivations

The recent years witnessed a tremendous increase in connectivity requirements.

In the age of smart-*, people now expect all of their daily usage objects to be connected, including the cheapest ones. RF technologies, such as Bluetooth Low Energy (BLE), Near Field Communication (NFC) or WiFi, represent the main choice in terms of wireless communications nowadays, and their adoption in this new context seems logical. Nevertheless, this vision is challenged by a simple costvolume-profit analysis. At a price of around 1$ per module, BLE is already one of the cheapest RF technologies on the market, but adding a BLE module on millions of small objects would represent an important investment for manufacturers. This is especially true as most of these objects only have sporadic connectivity needs, ranging from a few times per day to a few times per year, not justifying the investment.

At the same time, most daily usage objects, e.g. household appliances, smoke and gas detectors, temperature and humidity sensors, toys, etc, already integrate small LEDs, to facilitate the regular user interactions. This enables the use of VLC, where LEDs have been shown to be effective as both transmitters and receivers [START_REF] Schmid | An LED-to-LED Visible Light Communication system with software-based synchronization[END_REF]. Moreover, at a cost of around 0.05$ per unit, LEDs can communicate with regular, unmodified smartphones, using the smartphone camera as a receiver [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF] and the flashlight as a transmitter [START_REF] Hesselmann | FlashLight -Optical Communication Between Mobile Phones and Interactive Tabletops[END_REF].

However, LED-to-smartphone communication has only been studied in the context of relatively large lighting LEDs, for information broadcast [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF] or localization [START_REF] Kuo | Luxapose[END_REF] purposes. The feasibility of communication between small LEDs, as those integrated in most objects, and a smartphone remains an open question.

We address this question in this work and design a bidirectional VLC transmission system between a low-cost, low-power colored LED that is part of an IoT device and an unmodified and non-rooted smartphone. The IoT device is thus able to send and receive information through its LED, while the smartphone uses its camera to receive data and its flashlight to send information. The additional costs to make a traditional device part of the IoT are therefore minimal.

Contributions

Referring to the classification priorly introduced in Sec. 1.1, the focus of this thesis is on the green cells in Tab.1.1. That is to say, in the fields of low power LED-to-camera VLC and flashlight-to-LED VLC. Our main contribution are summarized below:

• Design and implementation of methods to enable low power LED-tocamera communication. We introduce an original decoding algorithm that decodes every frame in real-time. By bypassing computer vision techniques, our algorithm processes every 1920x1080 picture in 18.4 ms on average on a Nexus 5 with a Java implementation. Using native C code, the whole processing takes only 3.6 ms. These results outperform previous works [START_REF] Lee | RollingLight[END_REF] and add robustness against user motion. This contribution is detailed in Chap. 3.

• Evaluation of a LED-to-camera communication system for IoT devices.

We propose, for the first time in the literature, a thorough experimental evaluation of a VLC system composed of a low power colored LED and a smartphone. The experimental evaluation studies the impact of the symbol rate, the payload size, the ambient lighting conditions, the model and color of the LED, and finally the users behaviors, i.e. the motion, the angle between the LED and the smartphone, or the distance. The experimental evaluation results are given in Chap. 3.

• Analytical study of a LED-to-camera communication system. We propose a generic analytical model for LED-to-Camera communication systems based on the theory of Markov-modulated Bernoulli processes (MMBP).

This model can be applied to all LED-to-camera communication systems

Its validation with extensive experimental results proves it is very accurate. This contribution is introduced in Chap. 4.

• Implementation of a LED-to-camera communication simulator. We design and implement CamComSim, the first LED-to-camera communication simulator. The simulator can be finely tuned to evaluate not only our contributions, but also any LED-to-camera communication system. That allows fast prototyping and evaluation of LED-to-camera communication network protocols. CamComSim is detailed in Chap. 4 and is also available as an open source software.

• Design and implementation of methods enabling flashlight-to-LED communication. To make any smartphone able to send data using its flashlight to an IoT device, we propose smart mechanisms and protocols that cope with the flashlight signal jitter and that detect the flashlight clock rate whatever the smartphone model. Our frame format includes synchronization patterns that let the device detect the beginning of a transmission, acquire the clock rate, correct both the clock jitter and bias by adapting the signal sampling itself at runtime. This flashlight-to-LED channel is suitable for feedback, wake-up or communication purposes. Thus, we were able to build LightIoT, the first bidirectionnal smartphone-to-LED communication system. The design of the flashlight-to-LED communication channel is presented in Chap. 5.

• Design of a coding sheme optimized for LightIoT. We provide the first random linear coding (RLC) coding scheme optimized for VLC and LightIoT, that we called SeedLight. In particular, we reduce the RLC overhead by using a pseudo-random linear coding (PRLC) method and keep the encoding complexity low. Our coding scheme works with small physical layer service data units (PHY-SDUs), an important constraint for the kind of small LEDs we use as emitters. We implemented SeedLight on cheap MCUs and show that it is perfectly fitted for devices with low memory and low computation capabilities. We detail this contribution in Chap. 6.

• Evaluation of LightIoT energy requirements. We studied the energy needs and evaluate through experimental measures the impact of LightIoT on the power consumption of an IoT device and a smartphone. We compare the results for several utilization profiles with an equivalent system based on BLE. That gives essential insights to choose the adequate communication interface during the conception of energy constrained smart devices. This last contribution is described in Chap. 7.

Chapter 2

State of the Art

In this chapter, we give further details on the background works upon which we build within this thesis. For that purpose, we follow the classification we have proposed in Tab.1.1 in the previous chapter. Section 2.1 presents the past works utilizing PDs as VLC receiver. Then, we show in Section 2.2 that LEDs can also be used as a receiver. Finally, because they are close to the scope of our work, we dedicate the last two sections to past efforts on leveraging cameras as VLC receiver. We start with screen-to-camera links in Sec. 2.3 before concluding this chapter with studies that enable LED-to-camera communications in Sec. 2.4.

Photodiode as VLC Receiver

This section details notable works that rely on photodiodes to receive a VLC signal. According to the classification shown in Sec. 1, we start focusing on studies that use lighting ceiling LED as VLC emitter in Subsec 2.1.1 and low power LED in 2.1.2. Finally, we end this section introducing research that leverages passive lights for VLC purpose.

Ceiling LED-to-Photodiode communication Modulation

As discussed, LED-to-photodiode is the most convenient way to enable high-speed VLC. Even if current VLC standards only cover OOK, VPPM and CSK modulations with data rates below 96 Mbps, much higher throughputs are feasible and have already been demonstrated in laboratory conditions.

A straightforward approach that has been considered to increase the data rate is to use known RF or optical fiber solutions. By following this path, a pro-State of the Art totype VLC system utilizing high-power LEDs and OOK to achieve bidirectional real-time transmission with a total rate of 230 Mbps was implemented in [START_REF] Vučić | 230 mbit/s via a wireless visible-light link based on ook modulation of phosphorescent white leds[END_REF].

Inspired by optical fiber communications, a full-duplex bi-directional VLC system utilizing RGB LEDs and a commercially available phosphor-based LED is proposed in [START_REF] Wang | Demonstration of 575-mb/s downlink and 225-mb/s uplink bi-directional scm-wdm visible light communication using rgb led and phosphor-based led[END_REF]. The authors used Wavelength Division Multiplexing (WDM) and Subcarrier Multiplexing (SCM) to achieve the bi-directional transmission.

Furthermore, Orthogonal Frequency Division Multiplexing (OFDM) and Quadrature Amplitude Modulation (QAM) were employed to increase the throughput [START_REF] Afgani | Visible light communication using OFDM[END_REF].

OFDM has been widely used in wired and wireless communication systems due to its high spectrum efficiency and the capability of inter-symbols interferences (ISI) mitigation. Applying OFDM in VLC, the speed of the VLC system in [START_REF] Chi | Ultra-highspeed single red-green-blue light-emitting diode-based visible light communication systemutilizing advanced modulation formats[END_REF] was increased to 3.75 Gbps as compared to that in [START_REF] Wang | Demonstration of 575-mb/s downlink and 225-mb/s uplink bi-directional scm-wdm visible light communication using rgb led and phosphor-based led[END_REF] which was 575 Mbps downlink and 225 Mbps uplink. The potential of OFDM has been further studied in the recent years.

Considering the specific properties of VLC, several optical OFDM techniques have been developed, such as the direct current (DC) biased optical OFDM (DCO-OFDM) [START_REF] Kahn | Wireless infrared communications[END_REF], the asymmetrically clipped optical OFDM (ACO-OFDM) [START_REF] Armstrong | Power efficient optical OFDM[END_REF] and the asymmetrically clipped DC-biased optical OFDM (ADO-OFDM) [START_REF] Dissanayake | Comparison of ACO-OFDM, DCO-OFDM and ADO-OFDM in IM/DD systems[END_REF]. DCO-OFDM was first introduced for wireless infrared optical communications [START_REF] Kahn | Wireless infrared communications[END_REF].

It adds a DC bias to the bipolar analog signal and clips any remaining negative values. If the DC bias is set a to high value, the optical signal-to-noise ratio (SNR) will become very large, leading to low optical power efficiency. Thus, ACO-OFDM has been proposed to overcome the disadvantages of DCO-OFDM. ACO-OFDM transmits information only on odd subcarriers. Besides, the clipping noise is added only on the even subcarriers, thus it will not interfere with the information on the odd subcarriers. That improves the power efficiency of DCO-OFDM but results to a low spectrum efficiency, which is half of DCO-OFDM and quarter of RF OFDM.

In [START_REF] Dissanayake | Comparison of ACO-OFDM, DCO-OFDM and ADO-OFDM in IM/DD systems[END_REF], ADO-OFDM has been proposed to combat ACO-OFDM and DCO-OFDM disadvantages by combining both of them. In their system, ACO-OFDM is transmitted on the odd subcarriers and DCO-OFDM is transmitted on the even subcarriers. In such way, ADO-OFDM outperforms DCO-OFDM in terms of power efficiency and outperforms ACO-OFDM in terms of spectrum efficiency. This modulation is the background of LiFi [START_REF] Haas | What is LiFi?[END_REF] and the PureLiFi LiFi-X [START_REF] Purelifim | pureLiFi[END_REF] ready-to-market LiFi access point and USB dongle.

MIMO For providing both illumination and uninterrupted communication coverage, the attocell architecture has been proposed [START_REF] Yi | Interference mitigaion between femtocell and macrocell[END_REF]. Every LED light bulb in an attocell LiFi network is treated as an access point and a light source for covering a limited region. Based on this attocell architecture, a promising multiple input multiple output (MIMO) method called spatial modulation (SM) can be employed. This MIMO method was first proposed for RF communication in [START_REF] Chau | Space modulation on wireless fading channels[END_REF],

where only one transmitter sends data at any point of time. RF SM was further adapted for VLC by Fath et al. [START_REF] Fath | Spatial Modulation Applied to Optical Wireless Communications in Indoor LOS Environments[END_REF]. Each transmitter LED is assigned a specific symbol and, when data to be transmitted matches the symbol, the LED is activated. The receiver estimates which LED was activated based on the received signal and uses this to decode the transmitted data. In [START_REF] Fath | Performance comparison of mimo techniques for optical wireless communications in indoor environments[END_REF], the authors show that SM is robust to correlated channels and provides high spectral efficiency.

Due to the advantages showed in [START_REF] Fath | Performance comparison of mimo techniques for optical wireless communications in indoor environments[END_REF], SM has been further investigated in the recent years [START_REF] Masuda | Spatial modulation in layered space-time coding for image-sensor-based visible light communication[END_REF][START_REF] Di Renzo | Spatial Modulation for Generalized MIMO: Challenges, Opportunities, and Implementation[END_REF].

Networking Many works address VLC through the PHY layer perspective, putting aside the networking and medium sharing aspects. Indeed, building robust and effective medium sharing protocols is necessary to enable VLC networking and VLC deployment. In the attocell architecture, users must be associated with one or some LED lamps for accessing and downlink, and they should be able to move from an attocell to another, using mechanisms for horizontal handover. The mobility models of users and performance metrics such as the download file size and average connectivity are studied in [START_REF] Chowdhury | Cooperative data download on the move in indoor hybrid (radio-optical) WLAN-VLC hotspot coverage[END_REF].

On the other hand, challenges remain regarding the VLC uplink transmission: the optical uplink may interfere with the downlink signal, the optical uplink from a device may be uncomfortable to the users, or the high power consumption may make the device integration impractical. For these reasons, LiFi leverages these concerns using IR for the uplink [START_REF] Haas | What is LiFi?[END_REF].

An alternative is the combination of VLC and the existing RF network as WiFi [START_REF] Rahaim | A hybrid Radio Frequency and broadcast Visible Light Communication system[END_REF][START_REF] Huang | Design and demonstration of room division multiplexing-based hybrid VLC network[END_REF][START_REF] Li | Cooperative load balancing in hybrid visible light communications and WiFi[END_REF][START_REF] Shao | An indoor hybrid WiFi-VLC internet access system[END_REF][START_REF] Chowdhury | Cooperative data download on the move in indoor hybrid (radio-optical) WLAN-VLC hotspot coverage[END_REF]. The indoor integration system of VLC and WiFi is proposed in [START_REF] Rahaim | A hybrid Radio Frequency and broadcast Visible Light Communication system[END_REF][START_REF] Huang | Design and demonstration of room division multiplexing-based hybrid VLC network[END_REF], where VLC is only used for broadcasting.

However, these hybrid schemes require that WiFi should manage the uplink acknowledgments of VLC frames, which creates frequent small-packet traffic.

Their simulation results showed that this approach reduces the throughput of WiFi only devices [START_REF] Rahaim | A hybrid Radio Frequency and broadcast Visible Light Communication system[END_REF]. The other insight is that these WiFi devices negatively influence the VLC latency and transmission rate. These problems need to be further investigated.

For hybrid VLC networks, vertical handover between LiFi and WiFi is the most important issue to provide continuous network access even with a moving station. Hou and O'Brien [START_REF] Hou | Vertical handover decision-making algorithm using fuzzy logic for the integrated radio-and-OW system[END_REF] proposed a fuzzy-logic decision-making algorithm for the vertical handover in a hybrid system in which the optical link is subject to blocking. Depending on the duration of the blocking, the system performs handover to an RF network. Similar to the RF handover protocols, received signal strength (RSS) based handover procedures are introduced by Vegni et al. [START_REF] Vegni | Handover in VLC systems with cooperating mobile devices[END_REF].

Finally, in [START_REF] Wang | Dynamic Load Balancing With Handover in Hybrid Li-Fi and Wi-Fi Networks[END_REF][START_REF] Wang | Load Balancing Game With Shadowing Effect for Indoor Hybrid LiFi/RF Networks[END_REF], the authors introduced a novel protocol for mobile stations that enables efficient vertical and horizontal handover mechanisms in a hybrid network of LiFi and WiFi system.

Other concerns A relevant question regarding VLC is what happens to data communication when LED lights are turned OFF? A basic answer is that communication is no longer sustained. Indeed, the works discussed above have taken it for granted that lights are switched ON. Nonetheless, there are some scenarios where users do not want indoor lighting, as in a sunny day or during the night just before or during sleep, while the devices still require network connectivity. This is the case for smart home scenarios where smart thermostats are sending temperature data or IP cameras are streaming video. To address such scenarioss where VLC and no perceivable artificial indoor lighting must coexist, [START_REF] Tian | The darkLight rises[END_REF]. DarkLight relies on the fact that light beams are not perceptible by humans when LEDs are extremely dimmed. To achieve this goal, DarkLight modulates the LED with 500-ns light pulses and 0.007 % LED duty cycle. Then data are encoded with 12PPM modulation. Note that, to be able to receive and perceive the pulse position with a nanosecond scale, the system must have a very precise clock. For this reason, the authors implement Dark-Light on a testbed, using FPGAs and a costly PIN-Photodiode. The experimental evaluation showed DarkLight achieves 1.6 kbit/s data rate and supports up to 1.3 m communication distance, while keeping the perceptible light negligible.

Tian et al. proposed DarkLight

Ceiling LED-to-photodiode for localization A popular application field

for LED-to-photodiode communication is indoor localization. With the huge deployment of IoT devices for which accurate location provisioning is often a key, the interest in location-based services is continuously growing. GPS has largely solved the problem for outdoor scenarios; however, accurate localization remains a challenge for indoor environments. WiFi-based indoor localization has attracted lots of research attention for its advantage of low deployment cost by leveraging on-device WiFi transceivers and existing WiFi infrastructure, but its accuracy remains up to few meters [START_REF] Bahl | Radar: An in-building rf-based user location and tracking system[END_REF]. However, VLC does not suffer from the drawbacks of radio-like wireless channel dynamics, fading, interference or multipath. In [START_REF] Li | Epsilon: A Visible Light Based Positioning System[END_REF], the authors introduced Epsilon to provide indoor localization with a decimeter accuracy, leveraging LED luminaries and any device equipped with a photodiode. The ceiling LEDs serve as anchors that beacon an ID, their position and their duty cycle. Epsilon adopts binary frequency shift keying (BFSK) along with frequency hopping to enable reliable transmission from multiple and uncoordinated light sources. Then, the receiver measures the RSS from the LEDs in its field of view and computes the distance to each one using a channel model. Finally, it estimates its location with trilateration using the received beacon information and distance measurements from the light sources. Experimental results confirmed the accuracy of the system: the 90th percentile accuracies are 0.4 m, 0.7 m and 0.8 m for three typical office environments with 5 LEDs. Nonetheless, the reliability of this method is still poor and the system is not robust against the device orientation or the motion, and the distance estimation accuracy is correlated with the quality of the channel model.

Ceiling LED-to-photodiode for sensing Recent advances in augmented reality and smart home appliances have enriched user experience and entertainment in indoor environments. To sense free-hand gestures, common and commercial approaches use cameras (RGB, infrared or time of flight cameras), onbody sensors, ambient radio frequency signals, and acoustic signals. In [START_REF] An | Visible Light Knows Who You Are[END_REF], the authors proposed for the first time to leverage the light for body motion sensing and user identification. The system consists, on one side, of VLC-enabled LED lights on the ceiling that emit light beacons and, on the other, of PDs on the floor.

The PDs capture a continuous stream of shadow maps, each corresponding to an LED light. These shadow maps then help to localize the user's body joints in the 3-dimensions space and recognize the user based on the estimated body parameters, such as the shoulder width or the arm length. The experimental results showed the system correctly identifies 8 participants out of 10 with a mean error of the body parameter estimation of 0.03 m.

A complementary system that uses a table lamp to reconstruct the 3D hand skeleton in real time is proposed in Aili [START_REF] Li | Reconstructing Hand Poses Using Visible Light[END_REF]. Aili consists in a LED panel with several arrays of PDs embedded in the lamp base. To reconstruct a hand skeleton, Aili combines 2-dimensions light blockage maps from different PDs, which describe if a hand blocks light rays from individual LEDs to all PDs. To identify the contribution of a specific LED, each light emits a unique flashing frequency between 20.8 kHz and 40 kHz. The authors built and evaluated a prototype of their system. The results show that their algorithm reconstructs a hand pose within 7.2 ms on average, with 10.2 °mean angular deviation and 2.5 mm mean translation deviation.

A drawback of these works is their cost and deployment complexity, even on the sensor side. This concern makes these solutions not compatible with the IoT sensors constraints for which the cost, the power consumption, and the integration complexity must remain as low as possible.

Low Power LED to Photodiode communication

The greater part of research on LED-to-photodiode communication aims to achieve high-speed communications. However, there are some use cases where high data rate is not needed. This is especially true with the IoT context. In fact, interacting with smart objects or gathering sensors values only requires few bits, nay kilobits. Such situation is depicted in [START_REF] Schmid | From Sound to Sight : Using Audio Processing to enable Visible Light Communication[END_REF][START_REF] Corbellini | Connecting networks of toys and smartphones with visible light communication[END_REF] where a user is interacting with smart toys using a smartphone. Since today smartphones do not embed a photodiode, the authors leverage the device audio jack to plug a small VLC board embedding a PD and an LED. This approach has been proposed first in HiJack [START_REF] Kuo | Hijacking power and bandwidth from the mobile phone's audio interface[END_REF], where the authors brought heart rate sensing capabilities to an unmodified smartphone. The device is powered from the jack output signal and no additional battery is required. The audio signals directly modulate light emissions of the LED, whereas the incoming light is detected by a photodiode. The VLC clock rate is set to 10 kHz, a convenient value for an audio sampling rate of 48 kHz. The generated electrical signals are fed into the microphone input and the audio-like signal is finally demodulated by a mobile phone application.

The authors have implemented their system on an iPhone and the experimental results showed that the throughput stays stable up to 25 cm, with a maximum of 700 bps for a packet size of 150 bytes.

With the huge dependence of the users on their smartphones and the technological advances in their design, almost all smartphones now embed a camera. As a consequence, many of them also have a flashlight, which is basically an LED. For that reason, it is of great interest to use such smartphones as an off-the-shelf VLC emitter.

In this context, the authors in [START_REF] Galal | Smartphones for Payments and Withdrawals Utilizing Embedded LED Flashlight for High Speed Data Transmission[END_REF][START_REF] Galal | Employing smartphones Xenon flashlight for mobile payment[END_REF] use the smartphone LED flashlight as a secure visible light replacement of magnetic cards. They use a return-tozero (RZ) OOK modulation after demonstrating that non-return-to-zero (NRZ) modulation scheme is inefficient for data reception since it is vulnerable to synchronization problems. The experimental evaluation using a rooted Android smartphone and a PD as receiver shows that the system can reach an error-free bitrate of up to 500 bps. However, by relying on a rooted smartphone, the authors cut down the scalability of their system. In fact, such applications that require root permissions cannot be distributed through conventional stores. Also, to gain root permissions, users need advanced knowledge of the smartphone operating-system [START_REF] Sun | Android Rooting[END_REF], which is not the case of most of the smartphone users.

Note that rooting a smartphone has many drawbacks: the device becomes more sensitive to malwares or information leaks and invalidates its warranty.

Since the bitrate is radically limited by the mobile operating systems and the API offered by the platforms software development kit (SDK), there were not so many works that try to improve flashlight based communications. Nonetheless, flashlight VLC will be integrated into the upcoming IEEE 802.15.7m standard [START_REF]WPAN 15.7 Amendment Study Group[END_REF].

Passive Lights to Photodiode communication

A new research paradigm inspired by the RF backscatter [START_REF] Liu | Ambient backscatter: Wireless communication out of thin air[END_REF], is brought by Wang et al. [START_REF] Wang | Passive Communication with Ambient Light[END_REF][START_REF] Wang | Passive Sensing and Communication Using Visible Light: Taxonomy, Challenges and Opportunities[END_REF] as Passive VLC sensing. The authors present the remaining challenges and research direction to create a novel sensing and communication method that exploit passive light sources, such as the sun and/or passive receivers (i.e. the external surfaces of objects) such as fingers and car roofs. [START_REF] Wang | Passive Communication with Ambient Light[END_REF] studies the channel of such particular VLC systems, whereas [START_REF] Wang | Passive Sensing and Communication Using Visible Light: Taxonomy, Challenges and Opportunities[END_REF] introduces a taxonomy and points out three main challenges: (1) there is no universal solution since the object shape is uncontrolled, (2) the need for more flexible and robust methods for reception as of the uncontrolled emitters, (3) monitoring passive objects requires high density of receivers. The authors classify such system as full-active, passive source, passive receiver and full passive.

A recent research in this field is presented in [START_REF] Varshney | Batteryfree Visible Light Sensing[END_REF]. The authors built a batteryfree receiver for sensing and recognizing hand gesture patterns using visible light. Their system uses energy harvesting to be totally battery-less by using solar cells enabling sub-µW power consumption. Indeed, their full passive architecture requires no modification to the existing light infrastructure. Above all, they leverage RF backscatter to transmit the sensing and hand gesture information through RF up to distances of 330 m.

LED as VLC receiver

PDs are most commonly used as VLC receiver because they are the most appropriate electronic components to sense and receive light. They operate by converting photons to current. In this work, when we talk about PDs, we mean PDs specially conceived as light receivers. Nonetheless, in [START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF], the authors proposed for the first time in the literature to use conventional LED as photosensors in a VLC application. They rely on the fact that LEDs and PDs are intrinsically close to each other. More precisely, both LEDs and PDs are semiconductors and LEDs are technically PDs specifically manufactured to emit light. Thus, by wiring an LED in reverse-bias, the LED produces a very weak current.

Even if the current intensity is negligible compared to the one produced by a PD, it can be improved with the help of additional amplifier circuit and analogical filters. The other way to make an inexpensive photodetector out of an LED is to tie the anode to ground and connect the cathode to a micro-controller (MCU) I/O pin driven high. This reverse biases the diode and charges its internal capacitance. Then, switching the I/O pin to input mode allows the photocurrent to discharge the capacitance down to the digital input I/O pin of the MCU. Finally, by timing how long this takes, we get a measurement of the photocurrent and thus the amount of incident light. By relying on these properties, Dietz et al. [START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF] proposed LEDComm, the first bidirectional LED-to-LED communication protocol. The data are encoded using pulse width modulation (PWM): 0 is a short light pulse, while 1 is a long light pulse. Their prototype achieved 250 bps both in uplink and downlink in a limited communication range of a few centimeters. Following these first demonstrations, LED-to-LED communication has been further studied and improved by Giustiniano et al. [START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF], Schmid et al. [START_REF] Schmid | An LED-to-LED Visible Light Communication system with software-based synchronization[END_REF][START_REF] Schmid | LEDto-LED visible light communication networks[END_REF] and Corbellini et al. [START_REF] Corbellini | Connecting networks of toys and smartphones with visible light communication[END_REF].

In [START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF], the authors give a major improvement on the seminal work [START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF] described above. Unlike Dietz et al., they used On-Off-Keying and Manchester coding on the physical layer to encode and decode a message. On the MAC layer, the authors develop an efficient collision detection medium access (CSMA/CD) protocol [START_REF] Colvin | CSMA with collision avoidance[END_REF], enhanced with mechanisms to eliminate the light flicker.

The flicker elimination scheme works as follows. The channel is partitioned into Data (D) and Energy (E) symbols. E symbols are used both by the receiver and the emitter to compensate, if necessary, the flicker: the receiver emits light only during the E period, while the emitter emits light during D, and eventually during E if the light emitted during D does not suffice. The same pattern is sent when the channel is idle. This work allows for the first time to establish a robust bidirectional LED-to-LED network with up to four LEDs.

The authors apply this to a network of toys prototype showing that their system achieves a throughput of 870 bps within a range of 90 cm. They also evaluate the impact of the LED color (yellow, green, blue, red), showing that red LEDs offer the best performances. That is because the color affects the LED internal resistance and capacitance and so the discharge cycle time. Also, yellow and green LEDs are more sensitive to the corresponding component of the visible spectrum making them more sensitive to the ambient light noise.

More recently, Wang et al. [START_REF] Wang | OpenVLC[END_REF] introduced the OpenVLC platform. OpenVLC is an open-source software-defined networking platform for prototyping LEDto-LED along with LED-to-Photodiode communication. OpenVLC simply relies on low cost off-the-shelf electronic components and leverages the Beaglebone Black, an embedded Linux board, on which a VLC frontend is plugged through a "cape". The OpenVLC software provides a Linux kernel driver on which the authors have implemented signal sampling, symbol detection, coding, decoding, carrier sensing and communication with the Internet layer of the Linux operating system. The PHY layer relies on OOK modulation and Manchester coding, the same as [START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF][START_REF] Schmid | An LED-to-LED Visible Light Communication system with software-based synchronization[END_REF]. The medium access control (MAC) protocol is based either on CSMA/CD or CSMA with Collision Avoidance (CSMA/CA) [START_REF] Colvin | CSMA with collision avoidance[END_REF]. The first version of OpenVLC [START_REF] Wang | OpenVLC[END_REF] achieves a MAC layer data rate of 2.2 kbit/s at distances up to 1 m. Then, further improvements and studies have been successively brought by the authors to improve the MAC layer. In [START_REF] Wang | Communication Networks of Visible Light Emitting Diodes with Intra-Frame Bidirectional Transmission[END_REF], they propose a CSMA with Collision Detection and Hidden Avoidance (CSMA/CD-HA) MAC protocol for a network where each node solely uses one LED to transmit and receive data. The CSMA/CD-HA enables intra-frame bidirectional transmission in a network with up to 4 nodes. The key idea is to exploit the intra-frame data symbols without emission of light, the "LED OFF period", to introduce an embedded communication channel. As a result of intra-frame bidirectional transmission, a device denoted as R can send signals in parallel to receiving a frame. Since parts of this signal are "LED ON" symbols, they can be sensed by the nodes in R com-munication range. Thus, these nodes will not send frames to device R during this period, and the potential hidden-node problem is avoided. This approach enables the transmission of additional data while receiving in the same optical channel and it makes the communication robust to different kinds of field of view (FOV). The authors implement the CSMA/CD-HA protocol on the OpenVLC driver, and experimental results show that collisions caused by hidden nodes can be reduced and the network capacity can be increased up to 100%.

Finally, Galisteo et al. [START_REF] Galisteo | OpenVLC 1.2 : Achieving Higher Throughput in Low-End Visible Light Communication Networks[END_REF] introduce OpenVLC 1.2. The main change in the platform comes from the exploitation of the Programmable Real-time Units (PRUs) of the BeagleBone Black board. The author moved the VLC demodulation implementation from the Linux kernel to the PRUs. Note that PRUs are programmed in assembler and allow to control the hardware more precisely and faster. That increases the achievable throughput of OpenVLC to 100 kbit/s, i.e. by a factor of 8 with respect to previous versions, without adding any hardware cost. We notice that a similar approach is proposed in PurpleVLC [START_REF] Yin | Purple VLC: Accelerating Visible Light Communication in Room Area through PRU Offloading[END_REF].

With [START_REF] Wang | OpenVLC[END_REF][START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF][START_REF] Yin | Purple VLC: Accelerating Visible Light Communication in Room Area through PRU Offloading[END_REF], the FOV of the LED is limited to the direction of the LED axis. This limits its coverage to a specific direction. To overcome this limitation, the authors in [START_REF] Klaver | Shine: A Step Towards Distributed Multi-Hop Visible Light Communication[END_REF] designed an LED front end with 20 LEDs put in a circular printed circuit board (PCB). In Shine [START_REF] Klaver | Shine: A Step Towards Distributed Multi-Hop Visible Light Communication[END_REF], the LEDs are equally spaced to provide coverage in 360 °. The advantage of such front-end compared to already existing platforms is that a VLC device with many LEDs can communicate with multiples nodes in different directions, enabling a VLC multi-hop network. Shine front-end is based on a PCB compatible with many low-cost evaluation boards, such as BeagleBone, Raspberry Pi or Arduino. These prototyping platforms allow fast development of VLC system at a low cost. Nonetheless, their performance remains limited by the hardware, e.g. the MCU frequency, which makes them suitable for low data-rate use cases only, with low-complexity modulations. However, such VLC systems meet the needs of IoT communications and can therefore become one of the IoT communication technologies for indoor environments.

In a similar fashion, a recent research [START_REF] Yang | CeilingSee: Devicefree occupancy inference through lighting infrastructure based LED sensing[END_REF] shows that a lighting power LED also works as a light sensor. Nonetheless, its sensitivity is much weaker than the LEDs used by [START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF][START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF][START_REF] Schmid | An LED-to-LED Visible Light Communication system with software-based synchronization[END_REF][START_REF] Schmid | LEDto-LED visible light communication networks[END_REF][START_REF] Wang | OpenVLC[END_REF]. Yang et al. solved this problem by using a LEDs array and adapting the method in [START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF]: they add an analogical amplifier and modify the circuit schematics to be able to sense the signal without the need for reverse biasing the LED. CeilingSee [START_REF] Yang | CeilingSee: Devicefree occupancy inference through lighting infrastructure based LED sensing[END_REF] leverages this sensing-capable lighting infrastructure to infer the room occupancy as well as the occupant's mo- room with more than 80 % occupancy, even in dynamic scenarios.

Screen-to-Camera

The rising number of cameras and screens in today environment gives a great opportunity for using these devices for communication. The key feature of these screen-to-camera links is that they are highly directional enabling a form of interference-free wireless communication. Also, since both screens and cameras are 2-dimensions emitter and receiver respectively, the screen-to-camera link can be seen as a multiple-input-multiple-output (MIMO) communication channel, where each pixel is an antenna. Thus, screen-to-camera communication has the potential to provide ubiquitous broadcast communication with a higher throughput than LED-to-camera communication. Nonetheless, enabling screen-to-camera communication raises several challenges. Table 2.1 summarize the previous studies in the field that are introduced in this subsection.

In PixNet [START_REF] Perli | PixNet[END_REF], the authors present a system for transmitting information over LCD-to-camera links. PixNet leverages OFDM transmission algorithms to address the characteristics of the LCD-to-camera link, namely the perspective distortion, blur, and sensitivity to ambient light. In fact, PixNet is a kind of 2-D barcodes but, rather than encoding data directly in the visual domain, PixNet encodes informa-tion in the frequency domain. This approach is quite similar to OFDM, but unlike RF-based OFDM that encodes data in time frequencies, PixNet encodes data in 2-D spatial frequencies. Perli et al. [START_REF] Perli | PixNet[END_REF] implemented PixNet using off-the-shelf

LCDs and cameras and conducted experimental evaluation showing that their system offers a throughput of up to 12 Mbps at a distance of 10 m, and works with view angles as wide as 120 °.

Another approach for screen-to-camera communication was presented in COBRA [START_REF] Hao | COBRA: color barcode streaming for smartphone systems[END_REF]. COBRA is designed to achieve broadcast communication between small size screens and smartphone cameras using 2-D color barcodes. At the emitter, a header and the CRC checksum are added to the original data. Then, each byte of the data block is encoded by a certain color to generate a color barcode that is then displayed on the screen. The barcode is divided into the following three types of areas: 1) corner trackers, 2) timing reference blocks and

3) a code area in the center. The corner trackers (1) are used to locate the barcode on the screen using green and red blocks at the top-left and bottom-right corners respectively, and blue blocks at the other two corners. They also can be used by the smartphone to detect the black and white timing reference blocks [START_REF]RenderScript | Android Developers[END_REF]. These timing blocks (2) are used as the reference for detecting the data blocks in the code area (3). In the code area, the data is encoded by a sequence of color blocks: red, green, blue and white colors represent 00, 01, 10, and 11

respectively. According to COBRA bit-mapping, this means that 10110001 can be encoded in the color blocks blue-white-red-green.

At the receiver, since the camera frame rate is higher than the barcode rate, COBRA selects the best quality for each barcode for further processing and decoding. The experimental results show that COBRA can achieve a throughput of up to 172 kbit/s.

The limited available throughput in screen-to-camera links was further increased in LightSync [START_REF] Hu | LightSync[END_REF]. By improving the frame synchronization between the transmitter and receiver, Hu et al. [START_REF] Hu | LightSync[END_REF] nearly double the achievable throughput of COBRA. LightSync leverages linear erasure coding to recover the lost frames.

Then, color tracking is used to decode the data correctly from imperfect frames.

Another coding scheme referred to as Styrofoam [START_REF] Likamwa | Styrofoam[END_REF] addressed the problem of ISI due to lack of synchronization, by inserting empty frames in the generated set of frames.

More recently, in HiLight, Li et al. [START_REF] Li | HiLight[END_REF] introduced a new method for screen-tocamera communication without any coded images. By leveraging the properties of the transparency channel, called alpha channel, HiLight embeds the bits by changing the pixel transparency, instead of modifying the RGB color. The transmitter modulates bits using BFSK, where bit 0 and 1 are represented by different frequencies of transparency changes over a certain number of frames. Experimental results demonstrate HiLight reaches up to 240 bps by using off-the-shelf smartphones.

To improve the robustness of the screen-to-camera system mentioned above, Du et al. [START_REF] Du | SoftLight: Adaptive visible light communication over screen-camera links[END_REF] introduced SoftLight, a channel coding approach that automatically adapts the transmission data rate to the link qualities over various scenarios.

SoftLight enhances the state of the art by proposing a color modulation scheme on top of existing barcode-like modulation, providing a soft hint about the bit error rate (BER). That is to say, the receiver will discern if a bit can be considered as trustful or not. This allows establishing a bit-level VLC erasure channel instead of a packet erasure channel. Thus, the authors were able to develop a rateless coding scheme that achieves rateless transmissions at the bit level with low computation complexity. In fact, SoftLight is orthogonal to the previous screento-camera coding schemes and can be applied on top of any barcode layouts like QR Code or COBRA [START_REF] Hao | COBRA: color barcode streaming for smartphone systems[END_REF]. Their system exploits the independent components in YUV color space, along with a specific set of colors to reduce the interference between adjacent symbols for better color conservation on a picture.

The lightweight bit-level rateless coding scheme first encodes the data by a FEC code, like Reed-Solomon (RS) code or Low-Density Parity-Check (LDPC) code, before performing XOR operations at frame level to produce a set of rateless frames. On the receiver side, the smartphone decodes the frame by performing the reverse operations. Then, the soft hint provided by the color modulation allows determining the error probability for each bit position, which enables bitlevel rateless coding. Also, a majority vote algorithm is used to eliminate the impact of bits with high error probability.

Experimental evaluation on Android smartphones shows that this approach can correctly transmit a 22 kB photo between two smartphones within 0.6 s and improves the average goodput of COBRA [START_REF] Hao | COBRA: color barcode streaming for smartphone systems[END_REF] by 2.2 times.

With the increasing popularity of screen-to-camera links for near-field communication, it has become necessary to address the security aspects of the channel. Zhang et al. [START_REF] Zhang | SBVLC: Secure barcode-based visible light communication for smartphones[END_REF] addressed screen-to-camera communication security challenges, and proposed enhancements by manipulating the screen viewing angles and user motion tracking.

Propagation Modulation Use case Shutter Throughput Error correction

LED-to-camera

The majority of the VLC research is focused towards creating efficient and highspeed data links. For this purpose, LED-to-photodiode links are used, as PDs provide fast-response and high bandwidth, that can support complex spectrallyefficient modulation schemes. Nonetheless, smartphones can also be used as a receiver in VLC systems when high throughput is not a requirement.

Danakis et al. [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF] illustrate the fact that the cameras of smartphones with the so-called rolling shutter mechanism, further detailed below, can capture patterns from fast modulating light sources. Using this mechanism, a camera can be used as a VLC receiver for data transfer and localization.

Rajagopal et al.

[99] use a BFSK scheme with iOS devices as a receiver, which results in a throughput of 10 bps up to a distance of 1 m. The authors of [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF] employed OOK and Manchester encoding schemes and achieved a data-rate of 1-3 kbit/s at close proximity of 9 cm by using the frame-rate of 20 fps. Rolling-Light [START_REF] Lee | RollingLight[END_REF] presents a frequency shift keying (FSK) modulation scheme and, using iPhone 4 as the receiver, they reported a throughput of 90.56 bps up to a distance of 1.6 m using a light source of 60 cm x 60 cm.

A recent work presented by Schmid et al. [START_REF] Schmid | Using smartphones as continuous receivers in a visible light communication system[END_REF] achieved a throughput of more than 1.2 kbit/s with a pulse position modulation (PPM) encoding scheme. They implemented their receiver on iPhone 6s with a frame-rate of 240 fps and reported a maximum distance of 2.75 m.

All of these works use different encoding schemes and utilize different smartphones, which results in different throughputs generated by the system. Comparing these works only on the basis of throughput would not be fair, as at least four components are involved here: the data encoding method, the smartphone camera, the light propagation, i.e. line of sight (LOS) or non-line of sight (NLOS), and finally the emitter characteristics.

Such differences are illustrated by the following facts. Works [START_REF] Lee | RollingLight[END_REF] and [START_REF] Roberts | Undersampled frequency shift ON-OFF keying (UFSOOK) for camera communications (CamCom)[END_REF] implemented different methods and had different camera capabilities, i.e with rolling or global shutter respectively, and managed to get similar throughput values. Also, Schmid et al. [START_REF] Schmid | Using smartphones as continuous receivers in a visible light communication system[END_REF] and Ferrandiz-Lahuerta et al. [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF] obtain two orders of magnitude higher throughput than [START_REF] Roberts | Undersampled frequency shift ON-OFF keying (UFSOOK) for camera communications (CamCom)[END_REF] and [START_REF] Lee | RollingLight[END_REF] but they rely on non line-ofsight (NLOS) propagation, whereas [START_REF] Roberts | Undersampled frequency shift ON-OFF keying (UFSOOK) for camera communications (CamCom)[END_REF] and [START_REF] Lee | RollingLight[END_REF] leverage a line-of-sight (LOS) channel.

We introduce a taxonomy to help the classification of the previous studies in the field. Tab. 2.2 classifies using this taxonomy the works that are further de-tailed in the following of this section. To better understand the key mechanisms involved in LED-to-camera communication, we first give insights on the camera operations and the rolling shutter effect, and sum up the modulation schemes often used in LED-to-camera communications. Finally, we conclude this section by further describing LED-to-camera communication systems we found in the literature.

Proposed Taxonomy

To classify and better compare the different LED-to-camera implementations, we propose the following taxonomy:

• rolling vs global shutter mode: leveraging the rolling shutter effect has been proposed to improve the throughput by two orders of magnitude [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF]. However, such methods have the downside to reduce the range, the reliability, and the resistance against ISI or background noise.

• LOS vs non-LOS: depending on the application requirements, LOS or NLOS communication has been considered. Because the channel properties are distinct, different loss mitigation and modulation methods have been investigated.

• modulation: a wide range of modulation schemes have been tested in LEDto-camera communication, such as OOK, FSK, undersampled frequency shift OOK (UFSOOK) or grayscale shift keying (GSK).

• LED type: three types of LED have been used for LED-to-camera communication. They are ceiling power LED (CP), low-power monochrome LED (LPM) and RGB LED.

• application: LED-to-camera communications have been proposed mainly for localization (LOC), communication (COM), and privacy protection (PRIV).

• redundancy and error correction: different mechanisms to improve the LED-to-camera communication reliability have been studied, such as Reed-Solomon (RS) code, repeat packets (R), Raptor codes, or Luby Transform (LT) codes.

We notice that the light propagation has a major impact on the LED-to-camera system design, and mainly influences the other classification criteria introduced

Rolling Shutter Effect

Nowadays cameras widely use two types of image sensors, Charge Coupled Devices (CCD) and Complementary Metal Oxide Semiconductors (CMOS). These two technologies have some similarities but one major distinction is the way each sensor exposes its pixels to light. CCD sensors often use the Global Shutter readout mode, where all pixels are exposed simultaneously and then each A key camera property in determining the rolling shutter speed is the exposure time. Today, smartphone cameras are equipped with CMOS image sensors due to their low power consumption and low cost. Mid-range image sensors can capture a video of 25 to 30 fps in full resolution mode, while the top of the line smartphones can capture up to 940 fps. However, these cameras emphasize more towards picture quality, which leads to an unstable frame rate.

LED-to-Camera Modulations

The rolling shutter phenomenon enables communication between an LED and a camera where multiple data symbols can be transferred within one camera frame. The literature reports several modulations that have been investigated.

In the following, we summarize the advantages and downsides inherent to each method.

• On-Off Keying (OOK): In OOK modulation, LED ON and OFF states are used to encode 1 and 0 respectively. Because OOK symbols need to be short enough to avoid a visible change in the LED brightness, which is the flickering effect, this scheme is affected by the ambient noise. OOK can also produce human perceivable LED flickering in the case of long sequences of 0 or 1 in the transmission data. That is why OOK is often combined with a duty-cycle (DC) balanced run-length limited (RLL) code like

Manchester [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF][START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF][START_REF] Hao | CeilingCast: Energy efficient and location-bound broadcast through LED-camera communication[END_REF][START_REF] Yang | CeilingTalk: Lightweight Indoor Broadcast Through LED-Camera Communication[END_REF][START_REF] Kuo | Luxapose[END_REF] or 4B6B [START_REF]IEEE Standard for Local and metropolitan area networks -Part 15.7: Short-Range Wireless Optical Communication Using Visible Light[END_REF].

• Frequency Shift Keying (FSK): To address the limitations of OOK, [START_REF] Kuo | Luxapose[END_REF][START_REF] Lee | RollingLight[END_REF][START_REF] Rajagopal | Visual light landmarks for mobile devices[END_REF] have proposed to use FSK where different symbols consist of many ON-OFF bands at different frequencies. FSK reduces the demodulation error due to longer symbol duration and multiple ON-OFF bands in each symbol. That leads to a capacity an order of magnitude lower than OOK, with a throughput of 90.56 bps and 10 bps in [START_REF] Lee | RollingLight[END_REF] and [START_REF] Rajagopal | Visual light landmarks for mobile devices[END_REF].

• Undersampled Frequency Shift ON-OFF Keying (UFSOOK): The technique encodes the bits using a duty cycle (DC) balanced differential encoding. The modulation concept proposed in [START_REF] Roberts | Undersampled frequency shift ON-OFF keying (UFSOOK) for camera communications (CamCom)[END_REF] is similar to FSK inasmuch as UFSOOK defines two OOK frequencies for encoding bits that are high enough to avoid flicker. Howewer, the logic 1 and logic 0 frequencies are selected in such way that when undersampled by a low frame rate camera, they alias to low pass frequencies that can then be further processed to decode the bit values. For example, if the camera has a frame rate of 30 fps, and the frequencies are 120 Hz and 105 Hz, then the aliased frequencies as seen by the camera are respectively 0 Hz and 15 Hz.

• Color Shift Keying (CSK): CSK was first proposed by the IEEE 802.15.7 standard [START_REF]IEEE Standard for Local and metropolitan area networks -Part 15.7: Short-Range Wireless Optical Communication Using Visible Light[END_REF] for visible light communication and further studied in LED-tocamera communication in [START_REF] Hu | Color-Bars[END_REF]. CSK exploits the design of RGB LED fixtures which use three separate LEDs to generate a variety of colors, including white, using R, G and B mixture. CSK modulates the signal by modifying the intensity of the three colors. It uses the color space chromaticity diagram defined by the International Commission on Illumination (CIE) [START_REF] Tkalcic | Colour spaces: perceptual, historical and applicational background[END_REF].

The diagram maps colors perceivable by human eyes to a set of x and y coordinates. The IEEE 802.15.7 standard provides 8 and 16 CSK constellation symbols. The constellation symbols are chosen inside the CIE colors triangle such that the inter-symbol distance is maximized.

• Grayscale shift keying (GSK) and relative intensity modulation (RIM)

To improve the communication throughput of OOK, modulation based on light intensity variation has been proposed in [START_REF] Du | Martian: Message Broadcast via LED Lights to Heterogeneous Smartphones[END_REF][START_REF] Yang | ReflexCode[END_REF]. Light intensity modulation is achieved in two different ways: by dimming the LED [START_REF] Du | Martian: Message Broadcast via LED Lights to Heterogeneous Smartphones[END_REF], or by superposing light reflexions. The main drawback of such kind of modulation is the high bit error induced by ISI: the light intensity strongly depends on the distance or the angle between the enlightened surface and the camera, the surface color, the ambient lighting conditions, etc. Also, accurately dimming an LED is not straightforward and it increases the emitter complexity.

Line of Sight Communications

This subsection focuses on the past efforts on leveraging a LOS LED-to-camera link. In such situation, the optical signal only occupies part of the image unless the camera is very close to the LED.

CamCom [START_REF] Roberts | A MIMO protocol for camera communications (CamCom) using undersampled frequency shift ON-OFF keying (UFSOOK)[END_REF] uses UFSOOK by encoding data at frequencies that are harmonics of the frame rate and decoding data by processing the subsampled aliased frequencies. The key advantage of this scheme is that it works with both global as well as rolling shutter sensors. Note that UFSOOK has been contributed to the IEE 802.15.7m standard. However, it operates at frequencies around 120Hz, which can cause flickering.

In [START_REF] Kuo | Luxapose[END_REF], the authors present Luxapose, a method for indoor positioning using VLC that achieves positioning and orientation with decimeter accuracy. Their system consists of a camera sensor capturing multiple LED luminaries positioned on the ceiling, which use a unique blinking frequency as the device identifier.

Then, by querying a cloudlet, the mobile device translates the LED identifiers into location coordinates that can be used to derive its position via triangulation.

The authors have developed a LED detection and frequency detection method using computer vision processing with the OpenCV library [START_REF] Itseez | Open source computer vision library[END_REF] as follows: they convert the image to grayscale, blur it, apply a binary Otsu filter [START_REF] Otsu | A Threshold Selection Method from Gray-Level Histograms[END_REF] before finding the contours for each blob. After finding each region of interest (ROI), i.e.

each transmitter, they perform YIN algorithm [START_REF] De Cheveigné | YIN, a fundamental frequency estimator for speech and music[END_REF] for frequency estimation on each ROI. The median processing time for the full 33 MP images captured by the smartphone is about 9s: taking pictures: 4.46 s, upload: 3.41 s, image processing: 0.3 s, estimate location: 0.87 s).

Visible light positioning with unmodulated light has been widely studied by

Zhang et al. in [START_REF] Zhang | LiTell[END_REF][START_REF] Zhang | Pulsar : Towards Ubiquitous Visible Light Localization[END_REF][START_REF] Zhu | Enabling High-Precision Visible Light Localization in Today's Buildings[END_REF]. LiTell [START_REF] Zhang | LiTell[END_REF] is a localization scheme that employs unmodified fluorescent lights (FLs) as location landmarks and relies on the observation that each FL has an inherent characteristic frequency which can serve as a discriminative feature. The authors proposed a set of sampling, signal amplification and camera optimization mechanisms that enable a smartphone to capture high frequency (> 80 kHz) features. The experimental evaluation showed that LiTell provides sub-meter accuracy and orientation with less than 3 °error.

Pulsar [START_REF] Zhang | Pulsar : Towards Ubiquitous Visible Light Localization[END_REF] extends LiTell by using a compact PD sensor board plugged into a smartphone. It leverages the PD to better discriminate existing ceiling lightseither fluorescent lights or conventional LEDs -based on their intrinsic optical emission features. Also, it overcomes the photodiode lack of spatial resolution by using the smartphone front-camera. Thus, Pulsar resolves the light source angle-of-arrival by photogrammetry to triangulate the device 3D location and even orientation.

iLamp [START_REF] Zhu | Enabling High-Precision Visible Light Localization in Today's Buildings[END_REF] uses a smartphone camera to extract visual features in unmodified LED/FL lamps, i.e the color and geometric form, and identify each lamp as a landmark. iLAMP further introduces a sensor-assisted photogrammetry technique to estimate the 3D location with a small 90-percentile error of 3.5 cm (2.8 °). The authors implement iLamp on an Android smartphone and reduce both the power consumption and latency by duty-cycling the camera usage. The experimental evaluation shows their system is low-latency, between 400 and 700 ms, with a power consumption of 927 mW. That is less than 1/2 compared with LiTell [START_REF] Zhang | LiTell[END_REF] or Luxapose [START_REF] Kuo | Luxapose[END_REF]).

In ColorBars [START_REF] Hu | Color-Bars[END_REF], Hu et al. propose a system that exploits RGB LEDs to improve the LED-to-camera communication throughput. ColorBars operates as follows. On the transmitter side, the input data bit stream is divided into blocks of bits, and error correction coding is applied to each block. ColorBars uses RS coding to deal with the data loss due to the inter-frame gap (IFG) and ISI errors.

The blocks of data and parity bits are then used to form packets, where a header and a packet delimiter are added to each packet. The encoded bits of the packets are then modulated into a stream of symbols using CSK modulation: the bits are split into blocks of 3-bits and each of the blocks is mapped to a color symbol according to the CSK constellation. To keep the perceived colors always the same, dedicated illumination symbols of white light are inserted. Also, to

State of the Art face the color diversity on the smartphone, ColorBars emitter sends calibration packets periodically. The symbols in the calibration packets are used as reference symbols for demodulating the symbols in the data packets. Like Lahuerta et al. [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF], the authors determine a packet size large enough to not be missed during the IFG, but small enough to fit into a single picture. The drawback of such method is that the distance between the receiver and the emitter must be constant and must be small enough to make the rolling shutter stripes cover the whole image. For demodulation on the receiver side, ColorBars uses the CIELab color space. CIELab is a three channels color space with one channel for lightness L and two channels for colors (a and b). The authors implement ColorBars in a testbed and experimental evaluation showed that it could achieve a data rate of 5.2 kbit/s on Nexus 5 and 2.5 kbit/s on iPhone 5S devices.

The authors in RollingLight [START_REF] Lee | RollingLight[END_REF] extensively studied the rolling shutter effect and found an unpredictable and varying idle time gap (jitter) between two consecutive frames. This idle gap leads to loss of the data packets in the captured picture, which is depicted in Figure 2.3. This packet loss was observed in the case when the frame duration was slightly greater than the packet duration.

This means that one picture can capture at most one packet, but the varying idle time gap can result in random packet loss and frames without a complete packet. To face this issue, RollingLight adds a parity symbol every two packets by XORing these two symbols. Thus, if any of those two symbols is lost, it can be recovered by XORing the remaining one with the parity symbol.

More recently, Hao et al. presented CeilingCast [START_REF] Hao | CeilingCast: Energy efficient and location-bound broadcast through LED-camera communication[END_REF]. Their VLC LED-to-camera system leverages commercial off-the-shelf (COTS) LED stripes to create a LOS broadcast channel with a Nexus 5 smartphone. Relying on the combination of OOK and Manchester coding proposed in [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF], they innovated in both encoding and decoding schemes to improve link reliability and throughput. They leverage the rateless Raptor Code [START_REF] Shokrollahi | Raptor codes[END_REF] to face the unavoidable packet erasure caused both by the camera and the distance. Hesselmann et al. [START_REF] Hesselmann | FlashLight -Optical Communication Between Mobile Phones and Interactive Tabletops[END_REF] have proposed a method to enable bidirectional communication between smartphones and vision-based tabletops camera. In their approach, high and low bits are represented by turning the smartphone flash ON and OFF within a defined time frame. At the PHY layer, they use NRZ OOK modulation with 50 ms pulse length. Besides, the authors did not implement upper layer protocols for error detection or framing. On the tabletop side, because the symbol rate is lower than the camera frame rate, the signal can be recorded without loss and the demodulation is therefore straightforward. To evaluate the throughput of this flash-based communication, they implemented a test application on a non-rooted Nexus One and showed that their system could achieve a maximum throughput of approximatively 20 bps.

Non Line of Sight Communications

NLOS LED-to-camera communications use an illuminated surface as the source of the data, i.e. the reflected light, instead of the direct LOS, eliminating the need to point the phone directly at the LED. The NLOS LED-to-camera communication typically has higher throughput because the light signal occupies the whole image. However, RSS of a NLOS link is attenuated significantly due to the diffuse reflection, which increases the demodulation error. The following works rely on NLOS rather than LOS light propogation.

Unlike CeilingCast, Ferrandiz-Lahuerta et al. [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF] exploits the light reflexion on a wall instead of the LED luminary thoroughly. In such situation, the rolling shutter pattern that encodes information covers the whole pictures. Thus, detecting the emitter and extracting the ROI becomes unnecessary. With respect to the Danakis et al. [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF] seminal work using OOK modulation and Manchester coding, the contributions of [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF] are two-fold. First, the authors took a deep dive into State of the Art the Android Camera2 API [START_REF]Android Developers Camera2 API Guide[END_REF] in November 2014. They also gave engineering insight into the Android settings, which let them observe a rolling shutter artifact with a finer definition than the legacy camera API. This allowed increasing the emitter frequency compared to prior implementations. Secondly, the authors proposed a protocol and error detection and correction mechanisms to face asynchronous communication between the LED and the camera. The error detection and correction consist in CRC codes and is built in the following way: the input bit stream is split into 24 bits groups and an individual CRC4 is computed for each group. The set of 24 CRCs is appended at the end of the bitstream to be transmitted. Then, a block is built by prepending a 7-bits sequence number and a synchronization bit to a group. Finally, each block is sent twice, to be sure that each picture contains at least one whole block and that two consecutive blocks are captured into two successive pictures. Nonetheless, this design assumes the communication is continuous, without any loss, so missing just one block will make the transmission fail.

In [START_REF] Rajagopal | Visual light landmarks for mobile devices[END_REF], the authors introduce an asynchronous protocol using BFSK between an LED and an iPad. They designed a prototype able to transmit at a data rate of 10 bps on 29 channels concurrently to devices with CMOS cameras. However, they did not perform the demodulation in real-time on a smartphone, but pro- On the receiver side, the decoding process combines traditional amplitude demodulation with slope detection to decode the grayscale modulated signal, and it tunes decoding thresholds dynamically depending on the spatial symbol distribution. Also, the authors design a DC-balanced code to avoid flicker from individual transmitters. They addressed demodulation errors and intra-frame packet losses using Raptor Code, as in [START_REF] Yang | CeilingTalk: Lightweight Indoor Broadcast Through LED-Camera Communication[END_REF][START_REF] Hao | CeilingCast: Energy efficient and location-bound broadcast through LED-camera communication[END_REF]. ReflexCode experimental evalua-tion demonstrates that it can achieve a throughput up to 3.2 kbit/s at a distance of 3 m.

In [START_REF] Du | Martian: Message Broadcast via LED Lights to Heterogeneous Smartphones[END_REF], the authors propose a new modulation scheme and design link-layer protocols for improving the network data rate in an NLOS scenario. Their protocol, MARTIAN, allows broadcast communication from the light reflexion on a wall or a picture, to a group of smartphone cameras.

On the physical layer, MARTIAN uses Manchester coding along with light intensity based modulation. Since the light intensity strongly depends on various factors such as the distance or the angle between the lighted surface and the camera, MARTIAN exploits the pattern of intensity variation rather than absolute intensity value. For instance, they encode 00, 01, 10, 11 in four light intensity changes: 0% to 50%, 0% to 75%, 50% to 75% and 75% to 75% respectively, were 0% is the lowest intensity level, 50% the middle and 75% the highest.

On the link layer, to handle the IFG, the authors divide the original message into sub-messages and use Fountain Code [START_REF] Mackay | Fountain codes[END_REF] to encode the data packets. To manage the overhead introduced by Fountain Code regarding the extremely limited packet size in the light-camera communication, Du et al. [START_REF] Du | Martian: Message Broadcast via LED Lights to Heterogeneous Smartphones[END_REF] propose to minimize its encoding overhead by introducing a Fountain code table, which allows us to use only a few bits to maintain the encoding index and significantly improves the achievable data rate. MARTIAN can achieve a data rate of about 1.6 kbit/s even with an NLOS link.

In LiShield, Zhu et al. [START_REF] Zhu | Automating Visual Privacy Protection Using a Smart LED[END_REF] leverage the rolling shutter artifact to protect a physical scene from photographing, by illuminating it with smart LEDs modulated by FSK modulation. This will cover any picture taken with a CMOS camera with dark vertical stripes. They also designed mechanisms to unblock authorized cameras: using a specific frequency hopping pattern on the LEDs side, a smartphone perfectly synchronized with the emitter adapts its camera exposure time to follow the emitter frequency hops, which removes the rolling shutter artifact.

Conclusion

In this chapter, we have detailed the background works upon which we build within this thhesis. For this purpose, we followed the classification we have proposed in the previous chapter. We began with the works utilizing PDs as VLC receiver in Sec.

Design and Evaluation of a LED-to-Camera Communication System

Introduction

In this chapter, we focus on the design of a VLC transmission system between a low-cost, low-power colored LED that is part of an IoT device and an unmodified and non-rooted smartphone. The IoT device is thus able to send information through its LED.

Achieving this requires us to cope with several issues unsolved so far. Our first implementation based on state of the art solutions [START_REF] Lee | RollingLight[END_REF][START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF] gave us the following engineering insights:

1. Image processing with computer vision algorithms and filters to detect the LED position on the picture was too slow to achieve real-time processing.

2. Since the LED on the picture is small, the system becomes very sensitive to the user motion as the LED position highly varies between consecutive frames. Thus, performing LED detection only once to fasten the process cannot be envisaged [START_REF] Lee | RollingLight[END_REF];

We describe our LED-to-smartphone VLC system and the experimental platform in Sec. 3.2. Section 3.3 presents the design and the implementation of decoding processes that resolve the concerns pointed out above. Then, we present the testbed performance evaluation results in Sec. 3.4 Finally, we conclude this chapter summing up the lessons learned achieving this work.

Our main contributions introduced in this chapter are two-fold:

1. We deal with the LED-to-smartphone issues discussed above and introduce an original decoding algorithm that decodes every frame in real-time.

By bypassing computer vision techniques, our algorithm processes every 1920x1080 picture in 18.4 ms on average, on a Nexus 5 with a Java implementation. Using native C code, the whole processing takes only 3.6 ms.

These results outperform previous works [START_REF] Lee | RollingLight[END_REF] and add robustness against user motion.

2. We propose for the first time in the literature a thorough experimental evaluation of a VLC system composed of a low power colored LED and a smartphone. The experimental evaluation studies the impact of the PHY layer parameters, environmental factors, and also the user behavior, i.e.

the motion, the angle between the LED and the smartphone, or the distance.

System description

As we have shown before in the Chap. 2, previous studies [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF][START_REF] Rajagopal | Visual light landmarks for mobile devices[END_REF] demonstrate the performance of LED-to-camera communication, by using commercial lighting LED bulbs. Instead, our focus is on small color LEDs, such as those integrated in most daily usage objects.

For instance, RollingLight [START_REF] Lee | RollingLight[END_REF] uses a 500 mA, 1340 lm LED (Bridgelux bxra-56c1100 LED), while the LEDs we use in our study are CREE C503B-RAN, with 20 mA and 1.2 lm. While many concepts from the literature can be reused, regardless the type of the LEDs, the reduced size and power create some new challenges, as detailed below.

We designed a 40x20 mm printed circuit board (PCB) shown in Fig. 3.1 that supports a red 5 mm LED, a micro-controller unit (MCU), a surface mount device (SMD) RGB LED whose color can be easily changed, and a temperature sensor, to broadcast the ambient temperature through the light.

To evaluate the system, we also

Smart VLC device design

We choose the STM32L051 low cost and low power MCU from ST Microelectronics, an MCU similar to those already integrated in most household appliances.

The core is a Cortex M0+, running up to 32 MHz, with 32 Ko Flash and 8 Ko RAM.

To get a better clock accuracy and avoid clock bias due to the temperature, we use an 8 MHz high speed external crystal oscillator as the clock source and make the core run at this speed.

As proposed in [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF], [START_REF] Lee | RollingLight[END_REF], the LED signal is modulated using the OOK modulation scheme. We consider a clock-rate varying from 2 to 10 KHz, which is a suitable bandwidth for Optical Camera Communication (OCC) using the rolling shutter effect [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF]. To ensure a balanced duty cycle signal and avoid any flickering effect, we use the Manchester coding proposed in [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF], [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF], [START_REF] Nguyen | High-speed asynchronous Optical Camera Communication using LED and rolling shutter camera[END_REF]. This RLL code ensures the signal is DC balanced and will not cause flickering.

The information is divided and transported in physical layer service data units (PHY-SDUs) 1 with a size between 20 to 128 bits. Fig. 3.3 show our PHY-SDU format with a PHY-payload of 20 bits; four bits for the SYNC sequence, prepended to this

Receiver design

On the receiver side, we use a LG Nexus 5 smartphone running Android Marshmallow version number 6.0. We have developed an Android application that sets up the camera parameters to observe the rolling shutter effect produced by the modulated LED. For that, based on [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF], we set a very short exposure time and an increased sensor sensitivity, respectively to 100 µs and ISO 10000. As soon as a new frame is available, the application creates and starts a new thread to process and decode the picture on the background. This processing consists of a LED detection algorithm that extracts the region of interest (ROI) before performing signal processing methods to retrieve the transmitted information. This step in described more precisely in Sec. 3.3.

Enabling Real Time Computation

Computation time is an important metric in OCC, and even more when a real time transmission is required. For real time operations, all the image processing operations must be completed within the camera frame interval, i.e. the time needed to acquire a picture, which is in our case 30 ms. A higher processing duration would reduce the system throughput or introduce delay. Besides, loading the receiver with intense processing tasks will alter the capture rate regularity, and flood the RAM of the smartphone.

Algorithm presentation

The current state of the art solution, RollingLight [START_REF] Lee | RollingLight[END_REF], functions on ROIs of at least 600 pixels, achieving a throughput of 12 bytes/s. In RollingLight, the picture frame processing time is around 18 ms. However, this only counts the time required to extract the embedded information, and it does not take into account the ROI detection step, which is time consuming and performed only once, when the first frame is processed. Without skipping the ROI detection step, a feature which makes it deeply sensitive to motion, RollingLight would not be able to decode the transmitted information in real-time, i.e. it would not be able to decode information fast enough to receive the 30 frames/s allowed by most modern smartphone cameras. As a matter of fact, all the previous LED-to-camera solutions [START_REF] Lee | RollingLight[END_REF][START_REF] Kuo | Luxapose[END_REF][START_REF] Hao | CeilingCast: Energy efficient and location-bound broadcast through LED-camera communication[END_REF] rely on computer vision (CV) filters to detect the ROIs, which results in a frame processing time much higher than 30 ms (the time required to process 30 frames per second).

Instead, our method is specifically designed for small colored LEDs, allowing to process ROIs as small as 160 pixels and integrating a real-time decoding algorithm, able to determine the ROI position in each frame. The frame processing algorithm is decomposed in five steps:

Step 1. Image acquisition (S1): handling incoming captures in the YUV color space and extracting only the luma component Y, which allows to distinguish between dark and illuminated stripes.

Step 2. ROI detection (S2): finding the LED position on the picture, excluding LEDs that are not transmitting and reducing the length of the Y component vector.

Step 3. Signal equalization (S3): enhancing the received signal to deal with ISI and background noise, which allows to recover the signal clock rate.

Step 4. Signal quantization (S4): thresholding and binarization of the signal to recover the digital signal.

Step 5. Decoding and error checking (S5): decapsulating the PHY-SDUs, decoding the Manchester chip and checking data integrity with vertical redundancy check (VRC).

Indeed, as already explained, we first produced an implementation following the state of the art guidelines. This first implementation took up to 165 ms processing time per picture, which is not an acceptable value, as it constrains the frame-rate to avoid the system overflow, forcing the Android scheduler to randomly kill threads or drop camera captures. Thus, we investigate possible improvements at different layers: pure algorithmic, software implementation on the Android Execution Runtime (ART), and the Android Camera2 framework.

The following subsections details the five algorithm steps and the successive improvements we brought.

S1: Image Acquisition

Image format Since the release of Android Lollipop (API 21) and the new Cam-era2 API, developers are now able to control the smartphone CMOS sensor and the camera subsystem without any modification in the lower layer of the operating system. Numerous parameters can be chosen that can affect the efficiency and the amount of processing performed by the Android system.

The most relevant of these parameters are the image size, format and its compression ratio. We tried different image sizes, from 800x600 up to 3264x2448 pixels. Augmenting the resolution increases the rolling shutter stripes length, and so, reduce the ISI error [START_REF] Do | Analysis on Visible Light Communication using Rolling Shutter CMOS Sensor[END_REF]. However, this also increases the matrix size to process. To deal with this, we choose an intermediary value of 1920 pixels width per 1080 height: this is about 2.5 smaller than the largest possible choice, and provides sufficient precision regarding the symbol length.

Also, choosing the right color space makes the processing easier and affects the smartphone computing load. If a JPEG encoded RGB image representation has a lower memory footprint, it also requires more post-processing, due to color conversion and compression, which affects frame rate and the global system CPU and GPU load.

In contrast, RAW format contains the sensor value without any post-processing but is not exploitable as is, due to its size. To take advantage of this representation, we choose the YUV _ 420 _ 888 uncompressed format as suggested in [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF].

YUV representation has three channels, the luma (Y) and the chroma (U and Y plane contains the luminosity level, while U and V represent the color information). As we modulate the LED light, only the Y plane is relevant for us, reducing the size of the required data.

Capture workflow

As soon as a new frame is available, the Android application UI thread invokes the onCaptureCompleted callback. However, if the UI Thread is overloaded or busy, the newer frame, and as consequence data, can be lost. That means we should take care to keep the CPU and memory offloaded. To face frame loss, we can allocate an Image buffer to queue a limited number of frames upstream the callback. We follow the API recommendation setting this buffer to five.

An Image object in Android contains a ByteBuffer for each plane, and metadata, such as the capture timestamp. Accessing and manipulating big sized Java objects can be memory costly and not efficient, particularly when they contain huge buffers, most of them useless. This is typically our case, as U and V planes will be ignored. As soon as we acquire a new image, we allocate a new bytes array with the same size of the Y plane ByteBuffer , and fill it using the Java NIO ByteBuffer.get method, which generates optimized native code after Ahead-Of-Time (AOT) code compilation. We prefer moving to primitive type bytes array because read operations are notably faster.

Once this processing is done, we call the Image.close method to quickly release and free the memory.

Finally, we create a new Java Thread , passing the buffer and frame metadata to its constructor, and push it into the ThreadPoolExecutor set up at the application initialization.

Background processing on Android can be achieved in several ways: using Java Thread class implementing the Runnable interface, or the Android way using AsyncTask . Even if AsyncTask is generally preferred, we chose the Java Thread way. In fact, by implementing both solutions, our experiments showed that the processing is 8% slower, and with a larger distribution, when using AsyncTask (Fig. 3.5). An LED captured by the camera will result in a ROI R i in the frame. Multiple ROIs can be present in a picture frame, but some of these ROIs might be produced by regular LEDs, not carrying any information, while others, under a certain size, are too small to carry any useful information (e.g. R 2 in Fig. 3.6). As further explained in Chap. 2, rolling shutter cameras sequentially expose their if SYNC detected then 12:

V roi [i] ← (c, y) end while 20:

x ← x + ∆x 21: end while encoded over a set of ∆ lim pixels. The ROI detection algorithm consists in looking for a SYNC symbol in I by processing only the relevant pixels in order to keep the process duration as low as possible.

Let us denote by I max the pixel with the highest luma intensity. The ROI detection algorithm starts scanning a row r x , looking for the brightest pixels in I.

However, to speed up the process, only 1/∆y pixels in r x are considered, i.e. the red squares in Fig 3 .6, with ∆y < D/2 in order not to miss any meaningful ROI.

More precisely, the algorithm checks whether r x (y) < γ • I max , where γ is a predefined decoding threshold. Whenever this condition is true, the algorithm starts scanning the column c y for ∆ lim pixels, looking for a sequence of symbols that matches the predefined SYNC pattern. In the same way as for the row scan, only 1/∆x of the ∆ lim pixels are considered, where ∆x < S ensures that each symbol is detected. If a SYNC pattern is found, the position is marked as ROI start. We note that a ROI will contain as many SYNC sequences as PHY-SDUs, which allows us to estimate the end of the ROI as well. Finally, by adding a margin ∆z to the detected ROI, we extract the signal v roi , the red line in Fig. 3.6, to be further processed in S3. The ROI detection algorithm is summarized in Algorithm 1.

S3: Signal Equalization

Because of the reduced LED luminance, corroborated with the blooming effect and possibly low SNR conditions, the v roi signal is difficult to quantize directly.

An example is depicted on the left side of Fig. 3.7, where a sequence of falling and rising fronts can be noticed in the signal, but the luma intensity highly varies throughout v roi .

To equalize the signal and prepare it for decoding, we use an averaging technique with a window ∆z. More precisely, we compute the output of S3, v ′ roi on the right side of Fig. 3.7, as:

v ′ roi (x) = 1 2∆z y+∆z i=y-∆z I(x, i)
For performance consideration, we put these values into an integer array. In a first time, we considered using a new byte array, to reduce the memory impact and keep 8 bits representation. However, using 32 bits integers proved to be faster. The explanation is that the Nexus 5 processor has a 32-bit architecture, so the Android Runtime (ART) and its AOT does the operations using 32-bit instructions in each case. Hence, in the byte case, it executes extra instructions to convert the intermediate 32-bit value to a byte in each loop iteration. This makes performance worse in our arithmetic and compute intensive algorithm.

The cost of this operation depends on the ROI width (the column length), and averaging a lot of values can be useless or inefficient. So, after some exper-iments, we decide to limit it to 50 points, which is enough to obtain a proper signal without impacting the system performance. The result of this step is shown in Fig. 3.7.

Since S, the duration of a symbol, slightly varies depending on the CMOS sensor [START_REF] Do | Analysis on Visible Light Communication using Rolling Shutter CMOS Sensor[END_REF], our algorithm first recovers the symbol rate SR by scaling the SYNC falling and rising fronts in v ′ roi (x). This steps is crucial to make the algorithm robust against the smartphone camera diversity and it is a requirement for a commercial implementation.

S4: Signal Quantization and Clock recovery

We next determine the threshold level by computing the mean value of the array defined in Subsec. 3.3.3, to binarize it. While we run through the array during the quantization, we count how many successive 0 or 1 pixel will follow, in order to convert them to bit symbols.

Then, we continue by dividing this counter by the number of consecutive pixels per symbol we expect, which depends on the value of SR that we have computed just before.

To avoid potential decoding errors and face the inconstant symbol size, we add an error correction mechanism based on the Manchester RLL code and the PHY-SDU format expected.

S5: Manchester decoding and parity check

Since we now have a short character string of bit symbols, we can take advantage of Java String API, to easily decode symbols to data information.

Then, we compute the parity checksum and compare it with the received one.

Finally, we convert Manchester symbols to data symbols and return the result to the Android activity.

Algorithm Experimental Benchmark

Multiple LEDs compatibility

Our first implementation, noted no-MIMO, assumes that the only light source in a picture is the LED used for data transmission. However, the algorithm could be easily broken if any additional LED that is not a VLC emitter, or any other intense light source like a reflective surface, appears in the same picture. Indeed, this is often the case on consumer electronics.

To solve this concern, we improve our solution to offer two additional features: first to discern emitting from non-emitting LEDs and then, to decode several LEDs embedded in the same picture. We note this version of our algorithm, at can smartly take advantage of several emitters, MIMO. That makes it less sensitive to noise, robust against non-emitting LEDs and enables N -LEDs-to-camera communication.

For that purpose, unlike the no-MIMO implementation, the MIMO algorithm does not stop when a ROI is detected, but continues looking for others SYNC symbols in the picture, before trying to decode each one. Also, I max is not longer constant but continuously updated and smoothed using a moving average filter.

It adds a non-negligible computational overhead, but the processing delay still acceptable. That is shown in the left plot in Fig. 3 To test the accuracy and the gain of these two additional features, we place two LEDs spaced 5cm apart and record the throughput in three different scenes using the no-MIMO or the MIMO algorithms.

In the first scene, only one LED is transmitting data (1 TX). In the second one, we leave the first LED transmitting data and lighten the second LED without VLC modulation (1 TX + 1nTX). For the last scene, we use the two LEDs as VLC emitter

(2 TX).

The right plot in Fig. 3.9 compare the throughput between the no-MIMO (the red bars) and MIMO (the blue bars) algorithms, for the three different scenes introduced above.

That puts in evidence that the first method works well with just one transmitter on the image, but it completely fails, i.e. the throughput becomes 0 kbit/s when we add an other LED on the scene. On the contrary, the second version (MIMO) is efficient in every cases and smartly takes advantage of the two emitters to nearly double the throughput.

Experimental Results

This section presents a thorough evaluation of the LED-to-camera communication system described above.

We first evaluate the system performance as a function of the distance between the LED and the smartphone. We set the emitter symbol rate to 8 KHz and place it in standard indoor illumination conditions, that is about 650 lux. We make the distance vary from zero to the farthest one where we can still detect a signal, without using a zoom or an additional lens. To avoid any external noise and ensure constant experimental conditions, we control the scene illumination with a light meter, and fix the smartphone position. We repeat each measure on different days, at the same place and same conditions, to record enough data to consider them sterling.

The emitter broadcasts continuously 50 different PHY-SDU built according to Subsec. 3.2.1.

We compute the throughput as the number of received information bits per second, error free, including duplicated PHY-SDU. The goodput is calculated removing duplicates until the smartphone receives all the 50 PHY-SDU.

Environment Impact

In this subsection, we propose an evaluation of the environment impact on the performance of LED-to-camera communication using small color LED. We study the effect of the ambient light and of the angle between the camera and the transmitting LED. We first evaluate the LED-to-camera communication performance as a function of the distance between the LED and the smartphone.

The left curve in Fig. 3.10 shows the goodput achieved by the system. This is around 1500 bit/s at 5 cm, but is divided by two at 15 cm and smoothly decreases with the distance up to 40 cm. On the other hand, the throughput, obtained before removing duplicate PHY-SDUs, is close to 2750 bit/s at 5 cm, corresponding to a duplicate PHY-SDUs ratio of about 45%. While the performance of the system is clearly limited, we believe it satisfies the envisioned scenario, allowing any device to transmit information through VLC to a smartphone nearby.

Noise Impact

The interference of the ambient light, coming from the indoor ceiling lights or the sun, is a major issue in VLC, and even more so when using low power LEDs that are not intended for lighting purposes. In rolling shutter camera communication, this interference reflects in smaller ROIs and in a reduced difference between dark and bright stripes on the picture, which makes the decoding more error-prone. To test the noise impact, we evaluate the performance of our system in different illumination conditions, indoor and outdoor: i) in a room, normally lighted but not exposed to the sun through a window (210 lux); ii) on a laboratory work table, near a window and illuminated with neon lights (650 lux); iii) outdoor, during a very cloudy day (3000 lux), and iv) outdoor, during a sunny day (40000 lux).

In 40000 lux conditions, the signal is totally lost, even when the receiver and emitter are very close. Results for the other cases are depicted on the right side of Fig. 3.10, showing that the system is robust against interference from indoor lighting. Sunlight on the other hand has a stronger impact, but the results show that the throughput stays correct, only 25% less than in a room at 10 cm, if we avoid the direct sunlight.

Symbol Rate Impact

The symbol rate of the OOK modulation used by the emitter has a direct impact on the amount of information embedded in each picture taken by the camera. Indeed, for higher transmission frequencies (i.e. for higher data rates), the width of the dark and bright stripes on the picture decreases. Similar to what happens in RF communications for more complex modulations, the bit error probability increases when the width of the stripe decreases. After testing three different symbol rates (6 kHz, 8 kHz, and 10 kHz), the best results, shown in Fig. 3.11 are obtained for a symbol rate of 8 KHz, which we use in the rest of this work.

PHY-SDU Size Impact

Finally, an important property of the LED-to-camera communication is the fact that information losses are unavoidable and almost regular. Indeed, even when functioning at the maximum frame rate of 30 frames per second, the pictures taken by the smartphone do not represent a continuous view of the LED, as between any two pictures there is a camera inactivity time. To cope with these losses, the data needs to be segmented into PHY-SDUs, which can be easily reassembled and retransmitted.

However, the size of the PHY-SDU has a significant impact on the PHY-SDU loss probability. This is shown in Fig. 3.12, for a PHY-SDU size varying between 20 bits and 128 bits. We notice that the PHY-SDU loss ratio becomes unmanageable as the PHY-SDU size increases, e.g. almost all the 128-bits PHY-SDUs are lost, even at a few centimeters from the LED. Even for small 24-bits PHY-SDUs, the loss ratio is important (around 25% close to the transmitter); this is the con- sequence of the PHY-SDUs that are transmitted between the camera captures, which do not fully appear in any picture. Overall, the results in Fig. 3.12 show a clear advantage for small PHY-SDUs of 24-40 bits.

User and Angle Impact

During our experiments, we noticed the user can have a significant impact on the system performance. This can be observed by comparing the results obtained when the smartphone was held by the user and those obtained when using a fixed support. As Fig. 3.14 shows, the average throughput is the same in both cases, but a wider distribution can be noticed for a handheld device. To understand the factor that causes this phenomenon, we make the LED direction and its angle with the camera change from -10°to +10°, when at 0°they are perfectly aligned with both plans. Fig. 3.14 brings out the sharp dropping of the throughput with the variation of the angle. In fact, due to the directivity of the LED used (C503B-GAN), which is 30°, the angle has a huge influence on the ROI size on the picture. This can be avoided by choosing a LED with a large angle of view, but the side effect is that the light reflection on the camera lens will be weaker.

LED Model Impact

Finally, we studied the impact of the LED model and the LED color on the communication performance. We test eight LED with different characteristics,as summarized in Tab. 3.1. The LEDs #1, #2 and #3 are equivalent models for which only the color changes. Note that they have a clear transparent lens. The LED Figure 3.14: On the left, the impact of the angle between the LED and the camera at 10 cm. On the right, the throughput when he user is holding the smartphone compared to a mechanical support. #2 is the one we use in our testbed above. For the LEDs #6, #7 and #8, the same RGB LED is used to produce red, green and blue light respectively. Unlike the LEDs #1, #2, and #3, the lens is white and diffused. Also, LED #5 is a surface mount device LED, while all the others are through-hole LEDs. color filters [START_REF]CCD and CMOS sensor technology[END_REF]. Putting these result alongside the LED characteristics, we can see that the performance is directly linked to the LED intensity in candela.

Lessons Learned

Several observations can be made following this experimental campaign. First of all, although the throughput of our system, in the order of a few kb/s, is obviously limited by the low quality receiver and transmitter, this is still better than the performance of competing solutions, e.g. RollingLight [START_REF] Lee | RollingLight[END_REF] obtains a throughput in the order of 100 bit/s.

A second observation consists in the small PHY-SDU size used. Our results indicate that the PHY-SDU size must be in the order of tens of bits. Therefore, we propose the PHY-SDU format introduced in Sec. 3.2.1 and depicted in Fig. 3.3.

Because of the significant PHY-SDU losses in the system, a sequence number is still needed, in order to recompose the correct message sequence and allow retransmissions. While representing a significant overhead, this sequence number is essential for the retransmission strategies, further discussed in Chap. 4.

This small PHY-SDU size implies that standardized message formats with a size of hundreds of bytes, such as those proposed by the IEEE 802.15.7 or 802.15.7m standards, cannot be applied for small LED-to-camera communication. The same is true for previous works using lighting LED bulbs [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF], which propose a message format that includes a header, sequence numbers and tail bits for error detection. However, lighting LEDs installed on the ceiling, and even more in a non-line of sight configuration, produce a larger ROI on the picture, allowing the design of these larger messages, which is not the case for our small LED, as shown above.

This reduced payload is problematic for the networking layer, where packets usually add their own header, containing addressing information and a sequence number for reassembly purposes. However, with 20 available bits, the required control overhead would be too important, especially as some of this information is not always needed. This is the case, for example, for addressing: the communication range in our system is very limited, in terms of both distance and directivity. Therefore, a receiver does not necessarily needs MAC or network layer identifiers to distinguish the different transmitters; an application layer identifier is sufficient for this purpose.

However, the data fragmentation issue is still open, that is why, in the following Chap. 4, we propose analytical and simulation models to design and evaluate the performance of several redundancy mechanisms.

Chapter 4 Performance Evaluation of LED to Camera Communication

The use of LED-to-camera communication opens the door to a wide range of use cases and applications, with diverse requirements in terms of quality of service.

However, while analytical models and simulation tools exist for all the major RF technologies, the only way of currently evaluating the performance of a network mechanism over LED-to-camera is to implement and test it. Our work described in this chapter aims to fill this gap by proposing models and tools that help in the assessment of LED-to-camera communication network mechanisms. Our contributions are threefold:

1. We propose an analytical model for LED-to-camera communication systems in Sec. 4.1.

2. We design and implement a LED-to-camera communication simulator in Sec. 4.3.

The model and the simulator allow us to benchmark several redundancy

mechanisms proposed in the literature. By checking against experimental results, we are able to confirm the correctness of our models in this context.

Modeling LED-to-camera communication

In this section, we describe, for the first time in the literature from our knowledge, a LED-to-camera communication channel model. Based on the theory of Markov-modulated Bernoulli processes (MMBP) [START_REF] Ozekici | Markov modulated Bernoulli process[END_REF], discussed in Sec. [START_REF] Abedi | Examining Relationships Between 802.11n Physical Layer Transmission Feature Combinations[END_REF]

Model design

In a LED-to-camera system, data is received as a series of dark and illuminated stripes in a picture frame captured by the camera. In the following, we note by f i the i-th frame captured by the camera and by δ f the time between the beginning of two consecutive frames. Obviously, even at the highest frame rate allowed by the camera, data is not continuously received, as a minimum time δ g exists between two frames. This is denoted as the inter-frame gap (IFG). Moreover, as depicted in Fig. 4.1, the distance between the LED and the camera also has an impact: when the camera is farther away, the LED transmission is captured for a shorter time, resulting in a smaller ROI. In the S 1 state, the system is capturing a frame. The camera is receiving packets, and the reception probability is 1 -p e where p e is the packet decoding error probability. In the S 2 state, the camera is not capturing any pictures, therefore we consider the reception probability is 0. The transition probability between S 1 and S 2 (respectively S 2 and S 1 ) is denoted p (respectively q). We assume that p, q, p e are independent and constant.

The probability of being in state S 1 under the steady-state regime can be easily computed as p s1 = p p+q . The probability of being in state S 2 is so p s2 = q p+q . The values of p and q are function of the duration of the IFG, δ g , the frame duration, δ f , and the camera capture time δ c , depicted in Fig. 4.1, and linked as the following:

p = 1 -q = δ f -δ g δ f = δ c δ f (4.1)
MMBP model: If the model introduced just before is straightforward and widely used, it is not realist since, in our case, the transitions between ON and OFF states are almost deterministic. Practically, in our system, the transition probability from a state to another depends on the residence time in this state.

To improve this approach, we model the LED-to-camera channel using a Markovmodulated Bernoulli process (MMBP, represented in Fig. In S ON states, the camera is receiving packets, and the arrival rate is

λ 1 = (1 - p e )
, where p e is the packet decoding error probability. In S OF F states, the camera is not capturing any pictures, therefore we consider the arrival rate λ 2 = 0.

We denote as s a state in the Markov chain and we define state s + j as the state reached after j transitions, starting from state s. The probability of being in state s under the steady-state regime can be easily computed as π s = 1 N +M . At the same time, the probability of noticing no arrivals (i.e. no packet reception) in state s is p 0 (s).

This can be written as:

p 0 (s) =    1, if s ∈ N p e , if s ∈ M (4.2)
As it can be seen from both models, the relatively high packet loss probability (compared with RF technologies) is an intrinsic property of the LED-to-camera communication channel. To overcome this problem, redundancy mechanisms are needed.

In the following, we show that the classical Gilbert-Elliot model is inaccurate, which highlights the need to rely on the MMBP theory. Then, we use the MMBP channel model to compare two simple, but widely used redundancy solutions: repeating a packet or repeating a sequence of packets.

Repeat Packet

The first strategy to cope with the inherent losses in the LED-to-camera communication system, used for example by Ferrandiz-Lahuerta et al. [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF], is to send each packet twice in a row, to increase the probability that at least one of the transmissions will be fully captured by the smartphone camera. We generalize this approach in the Repeat Packet (RP) strategy, where each packet is repeated r times, one after the other. In this case, the r value needs to be chosen in order to attain a desired reception probability, its optimal value depending on the inter-frame time and on the packet size.

In the following, we study the probability of receiving a packet at least once when considering the RP strategy, for the two models introduced above.

Gilbert-Elliott Model:

p RP 0 = s (p 0 (s) • p 0 (s + 1) • p 0 (s + 2) • ... • p 0 (s + r -1)) N + M (4.4)
The value of p RP 0 will depend on m s , defined as the number of S ON states during the r retransmissions, when the first packet transmission is in state s:

p RP 0 = 1 N + M • M +N s=1 (p e ) ms (4.5)
Depending on the values of r, M and N , several cases can be distinguished.

We present results for the two most current cases:

• If r < M, N : This means that the number of retransmissions does not always cover the δ g period (which counts N states). In this case, p RP 0 can be written a follows.

p RP 0 = P [s ∈ N ∧ (s + r) ∈ N ] + P [s ∈ M ∧ (s + r) ∈ M ] + P [s ∈ M ∧ (s + r) ∈ N ) + P [s ∈ N ∧ (s + r) ∈ M ] = N -r + 1 M + N + M -r + 1 M + N • p e r + 1 M + N r-1 i=1 p e i + 1 M + N r-1 i=1 p e r-i = N -r + 1 M + N + M -r + 1 M + N • p e r + 2 M + N • p e -p e r 1 -p e (4.6)
• If N < r < M : This is the most common case, where the number of repetitions is chosen to cover the entire inter-frame period. However, a reception is still not certain in this case, because of the decoding error p e .

p RP

0 = P [s ∈ M ∧ (s + r) ∈ M )] + P [s ∈ M ∧ (s + r) ∈ N ] + P [s ∈ N ∧ (s + r) ∈ M ] = M -r + 1 M + N • p e r + 2 M + N N i=1 p e r-i + r -N -1 M + N • p e r-N (4.7)
When r becomes larger than N and M , the number of repetitions covers the entire inter-frame period and becomes large enough to combat the decoding error p e . Thus, we assume that p RP 0 ≈ 0.

We compare the analytical results given by the two aforesaid models to experimentation results in Fig.

Repeat Sequence

A different approach to improve reliability is the Repeat Sequence (RS) strategy, consisting in the transmission of a sequence of N p packets, repeated r times. In contrast with the previous mechanism, RS does not try to cover the inter frame time at the packet level, and it does not ensure that a packet is received before sending the next one. Instead, the reliability and presumed efficiency is based on the fact that the probability of losing the same packets over different transmitted sequences is low.

In the case of an RS strategy with a sequence of N p packets retransmitted r times, the probability of receiving a packet at least once can be written as

p RS s = 1 -p RS 0 .
Using the MMBP model, the probability of failing to receive a packet r times in a row, p RS 0 , can be written as:

p RS 0 = 1 M + N . M +N s=1 r-1 j=0 p 0 (s + rN p ) (4.8)

Evaluation results

We use our MMBP analytical model to study the RP and RS strategies by focusing on the probability of delivering the entire quantity of information in a given number of transmissions. We provide both analytical and experimental results, allowing us to validate the proposed MMBP model. To better understand the performance of the two retransmission strategies, we compare them in Fig. 4.6. This figure shows that, for the RS strategy, 3 retransmissions are needed to achieve a reception probability higher than 0.9, while this value raises to 4 for the RP strategy. On the right side of the figure, we show that the performance of the two strategies depends on the ratio between the number of S ON and S OF F states, M : N . When this ratio changes from 5 : 2 to 2 : 5, which practically corresponds to increasing the distance between the LED and the camera, RP gives better results than RS. Indeed, for the RS method, the success probability sharply decrease when M < 3 and stays below 0.6 even for 10 retransmission.

Practically, this means that RP is more suitable when the distance between the LED and the camera is higher, while RS is better for short communication distances. This phenomenon was previously unknown in the research community, but it is straightforward to study with our analytical model

ROI model

As shown in Chap 3, the distance between the LED and the camera reduces the ROI size and, as a consequence, cuts down the number of PHY-SDU that the camera can receive per frame, i.e. the M states in Fig. 4.1.

To include this performance factor into our model, we propose an analytical function that gives the ratio between the ROI and the picture size. In the model discussed in Subsec. 4.1.1, this is the ratio of M states in the M + N states.

We apply photogrammetry rules to give the ROI ratio as a function of the distance d, the LED size l, the camera CMOS sensor size ss, the image size on the sensor i and the camera focal distance f c.

According to the optical system depicted in Fig 4 .7, basic lens optic rules give the following Eq. 4.9. We introduce the CMOS sensor size ss to obtain the ROI as the ratio of the total number of pixels in the picture. We apply the min function to have ROI ∈ [0, 1] even if the image size on the sensor, i, is larger than the sensor size, ss. The result is given in the following Eq. (4.10).

i f c = l d ⇐⇒ i = l • f c d (4.9)
ROI = min 1, l • f c d • ss (4.10)
To validate the results given by Eq. 4.10, we measure the ROI experimentally, using the testbed introduced in Sec.

The CamComSim Simulator

If network simulation has been largely studied in the field of wireless communication [START_REF] Sharif | Ubiquitous sensor network simulation and emulation environments: A survey[END_REF], VLC simulation remains poorly investigated and VLC simulation tools are still missing.

The main efforts on simulating VLC systems have focused on the indoor channel simulation [START_REF] Tagliaferri | Development and testing of an indoor VLC simulator[END_REF], or on the IEEE 802.15.7 PHY [START_REF] Aldalbahi | Extending ns3 to simulate visible light communication at network-level[END_REF][START_REF] Ley-Bosch | Implementing an IEEE802.15.7 Physical Layer Simulation Model with OMNET++[END_REF] and MAC [START_REF] Musa | The design and implementation of IEEE 802.15.7 module with ns-2 simulator[END_REF] layers.

These approaches rely on classical network simulation frameworks such as the ones used in the context of wireless and ad hoc networks, e.g. NS-2 [START_REF] Musa | The design and implementation of IEEE 802.15.7 module with ns-2 simulator[END_REF], NS-3 [START_REF] Aldalbahi | Extending ns3 to simulate visible light communication at network-level[END_REF], OMNET++ [START_REF] Ley-Bosch | Implementing an IEEE802.15.7 Physical Layer Simulation Model with OMNET++[END_REF] or MATLAB [START_REF] Tagliaferri | Development and testing of an indoor VLC simulator[END_REF].

Since all these works consider LED-to-Photodiode communication, LED-tocamera communication remains completely unexplored. Our work is the first such effort reported in the literature, making CamComSim the first implementation of a LED-to-camera VLC simulator.

Simulator Implementation

Software architecture

CamComSim is an event-driven LED-to-camera simulator we developed in Java.

Java makes it easy to maintain and distribute code, and it provides built-in multiplatform compatibility for systems with a Java Virtual Machine. Fig. 4.9 shows the CamComSim software architecture that consists of a simulator kernel class and four core packages.

The topology package groups classes that describe the system components: Led , Camera and Channel .

The classes in the data package implement the data encapsulation Message is a set of PHY-SDU that encapsulates a PhysduPayload . A Packet is a PhysduPayload child class, with a sequence number as header and a payload that contains data.

Before each simulation, a Message is created according to the user settings.

The resulting set of Physdu is initialized with Packet filled with arbitrary data in the payload and a unique sequence number in the header.

The broadcast strategy abstraction is implemented in the strategy package. The Strategy interface lets the users implement their transmission strategy. This package also contains the straightforward ReapeatPhysduStrategy (RP) implementation that consists in repeating each PHY-SDU r times, one after the other. When the last PHY-SDU of the message is reached, the process is repeated from the beginning.

Finally the scenario package proposes an interface to build a simulation, wiring altogether the Message , the Channel , the Led , the Camera and the Strategy with the Simulator kernel.

Besides, the package utility provides helper classes used to compute the simulation results statistics, format and save the results as a JSON file and load or save the simulation parameters. The ui package contains a command-line interface (CLI) used to run a simulation scenario.

Simulator parameters

Our simulator exposes a set of finely grained parameters to describe the LEDto-camera communication system behavior. Further parameters, introduced in Sec. 4.2, that refer to the CMOS sensor characteristics, are optional but can be considered to refine the channel model, as they impact the ROI. However, smartphone manufacturers rarely provide them. They are, for example, the sensor size ss and the focal distance f c.

The PER p e is the consequence of the errors occurring in a M state when a PHY-SDU is well included in a picture but is wrongly decoded by the smartphone. These errors are bits substitutions induced by interference, low SNR, and artifacts on the picture.

The PhysduPayload payload size P and the PhysduPayload header size

H

Kernel Implementation

The CamComSim kernel is implemented in the Simulator class. Its role is to produce PHY-SDU emission events (TX) and manage their result.

The number of events, i.e. the number of PHY-SDU sent, is noted c and is up- The simulator loops over (1), ( 2) and ( 3) until the stop condition X happens, i.e. c has reached the maximum number of PHY-SDU emissions or the complete message is received.

dated
The simulation is repeated n r times using the Java ThreadPoolExecutor for multi-threading purpose. Finally, the simulations results and statistics are saved in a JSON file for further processing.

CamComSim validation

In this section, we present LED-to-camera simulation results given by CamCom-Sim. To assess the correctness of our simulator, we conduct a series of experiments with the testbed introduced in Sec. 3.2. We set the emitter symbol rate to 8 kHz and place it in standard indoor illumination conditions, near a window and illuminated with neon lights. The illuminance has been measured with a luxmeter at around 650 lux. We compare the testbed performance with the results given by CamComSim for a set of key parameters: the message size G, the number of consecutive PHY-SDU emissions r, the distance d and the PHY-SDU payload length P .

PHY-SDU Retransmission

As discussed in Sec. 4.1.2, to face the IFG bits erasure and ensure that all the packets are well received, [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF] proposes to transmit consecutively each PHY-SDU r times in a row. The authors proved experimentally that, for their system, r = 2 gives the best performance. We name this strategy RP and implement it in the ReapeatPhysduStrategy class. 50000R, meaning that the message transmission restarts when each PHY-SDU has been transmitted r times, until the message is received. To avoid infinite loops, we stop the simulation when 50000 PHY-SDU are sent even if the message is not received. In such case, the goodput is 0. The results highlight that the simulation and testbed goodput follow the same tendency when r varies.

The best case is when r = 1 for which the goodput is 1.6 kbit/s according to CamComSim and 1.7 kbit/s for the testbed, an estimation error of only 6%.

Based on these results, note that all the simulations that follow use, unless mentioned otherwise, the RP strategy implementation with r = 1, which is equivalent to the RS strategy discussed in Sec. 4.1.3.

Message size

We now consider the impact of the message size G on the goodput at a 5 cm distance, with r = 1 and a 24 bits length PHY-SDU. Fig. 4.11 shows that CamComSim results are very close to those of the testbed, confirming that the simulator well considers the impact of the message size. We notice that the goodput reduces when the message size increases, as the RP strategy leads to a large number of useless transmissions: the simulator gives 1.6 kbit/s of goodput for G = 50 bytes, while this falls to 670 bit/s when G = 1000 bytes. These results differ from the testbed in no more than 7%.

PHY-SDU length

Fig. 4.13 shows the impact of the PHY-SDU payload size on the goodput at 5 cm, with G = 50. The packets are built using the best value for P and H, that is to say with just enough bits in the header to label each packet with a unique sequence number.

Both experimental and simulation results show that the optimal PHY-SDU payload size is 24 bits: CamComSim gives a goodput of 1.9 kbit/s, while the testbed reaches 2.1 Kbit/s. As Sec 3.5 explains, large PHY-SDU reduce the encapsulation overhead, but they increase the probability that the IFG and a small ROI truncate the PHY-SDU.

Fig. 4.13 brings out that CamComSim well considers this behavior: the goodput becomes 0.9 kbit/s when the PHY-SDU payload size is 64 bits, very close to the experimental results.

This section highlights that CamComSim gives results very close to the testbed for all the parameters we have studied. The difference is around 10% and often less. For all the cases we consider, CamComSim respects the behavior of the LED-to-camera communication system implemented by the testbed.

Use case

In this section, we detail a case study for CamComSim, applied to a real life scenario. Then, we compare simulations with experimental results for the given application. These results will help us design and optimize the broadcast protocol used in the application.

Use case description

A common issue with cheap consumer electronics is the lack of diagnostics when a dysfunction happens. Manufacturers often blink the state LED with a pattern and color that match with an error code. Such mechanism is easy to implement but leads to inaccurate diagnostics. In such cases, we propose to benefit from this LED to perform LED-to-camera communication and broadcast a log file that would include helpful information to diagnose a dysfunction. We consider a worst case file size of 1 kbyte that is large enough for events history or debug traces.

Running the Simulation

As Sec. 4.3.1 explains, the simulation has to be described in a class implementing the Scenario interface. More precisely, the function runScenario(SimulationParams params) that takes as arguments the simulation settings must be implemented.

The implementation must perform the following operations:

(1) Set the transmission strategy to be used during the simulation. That is the RP strategy for this use case. If the simulation aims to evaluate another communication protocol, it must be defined in a class that implements the Strategy interface.

(2) Build the Message choosing a kind of PhysduPayload , for example a Packet .

(3) Create the Led and the Camera objects to build the Channel next.

(4) Initialize the Simulator kernel with the Channel , the Message , and the Strategy .

After implementing the simulation scenario in CamComSim, we run the simulator with the CLI through the following command: java -jar camcomsim-1.0.jar -v=1 -i=100 -r=1 -P=14 -H=10 -d=5 -F=8000 -G=1000 -e=0.0001 -X=50000R -dg=0.1 -sc=TestScenario -output=path.

Note that the parameter -v=1 sets the verbosity level and -output=path the folder where the results will be saved. At 5 cm, the simulation brings out that, to obtain the higher goodput, the emitter should send each PHY-SDU one or three times consecutively, i.e. r = 1

Results

Fig

or r = 3. The goodput is respectively 680 and 720 bit/s in these cases. This finding is the same on the testbed for which the goodput is 570 bit/s when r = 1 and 540 bit/s when r = 3.

Because the ROI decreases with the distance, the behavior is different when the smartphone is 10 cm far from the LED. In this situation, r = 4 stands out clearly to be the best choice both for the simulation and the experiments. The goodput then becomes 620 bit/s on the testbed and 540 bit/s with CamComSim.

Since the results are very close to the reality, using CamComSim highly reduces the search space for the experimental optimization of a system. As shown RP( 1) RP( 2) RP( 3) RP( 4) RP( 5) RP( 7 by these results, the best value for r can be decided using simulations only, removing the need for a lengthy experimental campaign.

Lessons learned

Modeling the LED-to-camera communication using a Markov-modulated Bernoulli process allows us to easily study the performance of the RP and RS strategies.

For both cases, experimentation validates analytical and simulation results and outlines that RP is more suitable when the distance between the LED and the camera is higher, while RS is better for short communication distances. Nonetheless, having an adaptive strategy that switches between RS and RP depending on the distance between transmitter and receiver is not possible without a feedback from the smartphone side. Also, these strategies inefficiently exploit the channel capacity by replicating information and dot not guarantee the successful data delivery, since the emitter never receives acknowledgement from the smartphone. We further discuss these issues in Chap. 5 and Chap. 6 by studying first the addition of a feedback channel and then a coding approach to avoid duplication.

Relying on this model, we were able to design the first LED-to-camera communication simulator. We have validated CamComSim comparing simulation results with the performance reached by a real life testbed. Then, we illustrated with a practical use case the complete usage of CamComSim to tune a broadcast protocol that implements the transmission of a 1 kbyte log file. The results highlight that our simulator is very precise and can predict the performance of a LED-to-camera system with less than 10% of error in most cases. The availability of very accurate simulators offers a great ease of use and the opportunity to tune protocols without the burden of realizing experiments on a testbed.

We hope these tools will allow researchers to focus on the design of network solutions for LED-to-camera communication, without going each time through cumbersome experimental campains. For that purpose, we made CamComSim

available as an open-source software under Apache license at http://vlc.project. citi-lab.fr/camcomsim.

Chapter 5

Flashlight-to-LED Communication

In Chap. 4, we demonstrated that our LED-to-camera communication system would benefit a lot from a feed back channel. Also, many smartphones already have a flashlight that can be used as VLC emitter [START_REF] Galal | Smartphones for Payments and Withdrawals Utilizing Embedded LED Flashlight for High Speed Data Transmission[END_REF]. On the smart device side, conventional LEDs can be leveraged as VLC receivers and so, are the only requirement to enable bidirectional visible light communication [START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF]. We gave further details on flashlight-to-photodiode and LED-to-LED communication in Chap. 2.

Therefore, in this chapter, we improve the system we depicted in Chap. 3 and introduce LightIoT. LightIoT enables bidirectional VLC transmission between a low-cost, low-power colored LED that is part of an IoT device and an unmodified and non-rooted smartphone.

The IoT device is thus able to send and receive information at the same time through its LED, while the smartphone uses its flashlight and camera, respectively to send and receive data. The LightIoT system is depicted in Fig 5 .1.

This bidirectional system allows the design of more complex and robust redundancy mechanisms. Nonetheless, achieving this requires us to cope with several issues unsolved so far:

• Smartphone manufacturers do not allow applications to control the flashlight at the kernel level without root access, enforcing the use of their highlevel API.

• The flashlight clock rate varies between smartphones, and even on the same device, depending on the system load. • The flashlight API is not time accurate, which adds latency and heavy jitter to the signal.

This chapter presents the design and the implementation of decoding processes that resolve these concerns. Our contribution is the proposal of smart mechanisms and protocols that cope with the flashlight signal jitter and that detect the flashlight clock rate whatever the smartphone. We designed a modulation scheme based on a variable pulse width modulation (VPWM), that we adapted abetted by our experimental observations of the smartphones flashlight behavior. Our frame format includes synchronization patterns that let the device detect the beginning of a transmission, acquire the clock rate, correct both the clock jitter and bias by adapting the signal sampling itself at runtime.

These key features harden the flashlight-to-LED channel.

The rest of this chapter is organized as follow. We describe the design of the flashlight-to-LED communication in Sec. 5.1, and we evaluate the performance of our implementation in Sec. 5.2. Finally, we present uses-cases for this flashlightto-LED communication channel in Sec. 5.3.

Enabling Smartphone-to-LED Communication

A feed-back channel from the smartphone to the object is required if we want to transform the LED from a simple beacon, continuously broadcasting the same information, in a real network device, capable of transmitting different types of information in unicast communication. Moreover, this smartphone-to-LED communication might prove useful not only for control purposes, but even for In this section, we present the main design principles of the communication link from the smartphone, more precisely from the flashlight, to the LED. PDs are often considered as receivers for VLC, as they are the appropriate and most efficient electronic components for light sensing, by converting the incoming light into electrical current. However, to be efficiently exploited, PDs require a fitted piece of hardware, based on a trans-impedance amplifier (TIA) and analogical filters, making this solution not suitable for our system, which aims to be as unobtrusive and cheap as possible. Therefore, in our design, we exploit the fact that a regular LED can also be used as a photo-receptor, by reverse-biasing it.

Communication principles

Although they possess a low light sensitivity, LEDs have already been used as receiver in VLC, as detailed in [START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF][START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF]: by charging a reversed biased LED, and measuring its electric tension after a short time interval following this charging, the variations in the incoming light intensity can be detected. This allows us to easily detect the on/off periods of an incoming OOK modulated beam of light.

However, previous works [START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF][START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF] only investigated LED-to-LED communication;

our implementation of smartphone-to-LED communication is therefore a first in the literature.

As explained, a regular LED can also be used as a photoreceptor, by reversebiasing it, as further detailed in Chap. 2. Nonetheless, wired in this way, the light generates a very weak reverse current. The light sensitivity of the LED is low and can not be directly measured by the MCU ADC. Even if this method avoids the use of a photodiode, an amplification circuit is needed to achieve correct performances.

In [START_REF] Giustiniano | Lowcomplexity Visible Light Networking with LED-to-LED communication[END_REF] and [START_REF] Dietz | Very Low-Cost Sensing and Communication Using Bidirectional LEDs[END_REF], the authors propose a smart way to solve this issue, by taking advantage of the intrinsic capacitance characteristic of the LED and the fact that the incoming light creates a current flow that can make the discharge duration shorter.

This is what is shown in Figure 5.2. After charging the LED internal capacitance during 1 µs, the voltage at its bounds is measured with an oscilloscope 100 µs later. When the LED is lighted by the ambient light only, the full discharge takes 600 µs (the left curve), while it is less than 100 µs with a supplementary lighting source that is the smartphone flashlight in our case.

This design only necessitates MCU software changes and does not repose on additional hardware: the LED anode is directly wired to a digital GPIO pin of the MCU and its cathode to an ADC alternate function capable pin.

On the smartphone side, two possibilities exist: using the LCD screen of the smartphone by controlling its back-light intensity [START_REF] Wilson | BlueTable: Connecting Wireless Mobile Devices on Interactive Surfaces Using Vision-Based Handshaking[END_REF], or triggering the flashlight built into most current mobile phones [START_REF] Hesselmann | FlashLight -Optical Communication Between Mobile Phones and Interactive Tabletops[END_REF]. Since using the screen makes it impossible to use the back camera as a receiver at the same time, we adopt the flashlight as VLC transmitter in LightIoT. with an API higher than 23. The first one is much slower because it relies on the Camera CaptureSession settings. Thus, turning the flashlight ON or OFF is done by updating the CaptureSession configuration and reloading it, which induces latency. The second one is faster, but it needs a full and exclusive access to the camera. That means no capture can be done at the same time, so the smartphone can not receive data anymore.

The listings in

Modulation characteristics

Controlling hardware components, such as an LED generating a signal, is generally achieved by a real time system, such as an MCU or a field-programmable gate array (FPGA), using hardware oscillators and timers to achieve time synchronization and turn on or off the light at precise time intervals. However, this precision is not possible for application-based implementations on a mobile operating system, e.g. an application controlling the smartphone flashlight, where these tasks are performed by the central processing unit (CPU).

An alternative would be to build a driver at the operating system kernel level, to take advantage of its ISR, and thus get a better time accuracy, such as in the OpenVLC platform [START_REF] Wang | OpenVLC[END_REF]. Nonetheless, this strategy is not feasible in our case, since mobile application developers can not access the lower levels of the operating system and they are constrained to use the programming interfaces offered by the native development kit (NDK), in the best case, or the SDK, otherwise. For instance, flashlight control is not implemented in the Android NDK; therefore, changing the flashlight state through its file descriptor is not allowed on a non-rooted smartphone, imposing the SDK implementation introduced in Sec. 5.1.1.

The clock jitter is therefore avoidable in our case. To add robustness against it, we propose a modulation scheme based on VPWM, where a pulse is a period during which the flashlight is turned ON. In this scheme, the data bits are mapped on VPWM symbols, as shown in Fig. 5.4, where each symbol is built using an initial pulse duration P , and a variable offset of the flash-ON duration,

V .

The two modulation parameters, P and V , should be determined based on some properties of the smartphone in order to alleviate the clock jitter problem.

First of all, the smartphone must be able to turn on and off the flashlight in a time interval P . Ideally, the smartphone needs to be able to correctly measure the period P and the execution of the switch on/off command should take a constant time. The clock jitter is produced by imprecisions on all these points, Symbol Data Pulse width hence the use of parameter V , which should be larger than the worst case jitter.

S 0 0 P + 0V S 1 1 P + 1V
Since the optimal values of P and V depend on the smartphone, the LED needs to estimate their duration at the beginning of the reception. We cope with the jitter of the flashlight signal and with heterogeneous clock rates between devices with a smart synchronization and clock recovery method that we detail in Sec. 5.1.3.

Receiver synchronization

As explained before, the optimal values of the modulation parameters vary depending on the smartphone and the timing inaccuracy of the mobile OS, producing signal pulses of inconsistent width during a transmission. To address this point, the receiver must synchronize with the transmitter and retrieve the signal characteristics, P and V , to correctly demodulate the signal. For that purpose, the smartphone emits two kind of synchronization symbols as shown in Fig. 5.5:

1) a start sequence (SS) at the beginning of each transmission and 2) a SYNC REQ symbol (SR) periodically sent to recalibrate the smartphone symbols table. This is the key point to recover from clock jitter and harden the demodulation. This mechanism is depicted in Fig. 5.6: the receiver detects a rising edge [START_REF]Metal | Apple Developer Documentation[END_REF], that signals the start of a transmission; it then measures the pulse width (2) by sampling the signal until a falling edge is detected. Thus, the receiver recovers the pulse width period P and it can continue receiving data symbols to retrieve V on the fly, by measuring the longest next pulse. To compensate for a potential loss of synchronization and recover from a link loss, an SR control symbol is inserted after the parity bit, if the next symbol is S 0 , as shown in Fig. 5.5. Thus, if a light off pulse of duration 2P occurs, the receiver knows that the next light on pulse represents the beginning of a byte, and it can recalibrate.

Experimental evaluation

To evaluate the flashlight-to-LED communication system, we implement a smartphone application that randomly generates series of 1000 bytes and transmits them to the LED using the flashlight. The application toggles the flashlight using the API 23 method shown in List. A.2. We maintain the smartphone in a fixed position, while controlling the angle it makes with the LED axis. On the smartphone side, we record the transmitted symbols and timing information, while on the VLC module we log the LED discharge voltage and the received symbols, as computed by the MCU.

We begin by evaluating the smartphone ability to transmit symbols at a fixed frequency, in order to deduce the optimal modulation parameters, P and V . We note that the system can not achieve a pulse duration as low as 5 ms; this can be noticed from the blue curve, where the effective pulse duration is around 8 ms. Another important observation is that the distribution of the effective pulse duration is rather wide and the results obtained for two configured values separated by less than 10 ms are overlapping. Based on these results, we consider V = 1.5P safe to avoid ISI in the worst case scenario and let the receiver synchronization algorithm, described in Sec. 5.1.3, retrieve the correct clock rate whatever the smartphone.

Next, we evaluate the communication range of the flashlight-to-LED technology and its potential limitations, especially the ambient light interference and the LOS condition. For this, in Fig. 5.8, we show the signal-to-noise ratio (SNR), measured at the LED receiver, for different communication distances and angles. Regarding the communication throughput, we notice an on/off behavior: for an SNR above 1 dB, a throughput of 30 bit/s is achieved, regardless the quality of the channel, while the throughput quickly drops to zero for an SNR under 1 dB. This 1 dB SNR threshold is represented by the red line in Fig. 5.8. We observe in these results a maximum communication range of 110 cm and a very constrained communication angle between the LED and the smartphone, lower than 15°. These results can not be compared with previous works on flashlight usage [START_REF] Galal | Smartphones for Payments and Withdrawals Utilizing Embedded LED Flashlight for High Speed Data Transmission[END_REF][START_REF] Fan | Visible light communication using the flash light LED of the smart phone as a light source and its application in the access control system[END_REF], as these studies use a photo-diode as a receiver, and not a small LED as we do in our work. Although the throughput achieved for the flashlight-to-LED communication is very low, this channel can still be useful for some applications: 1) for control purposes, e.g. switching a device ON-OFF or sending a short command, 2) for configuration, e.g. modifying the default settings of a device, and 3) for security purpose, e.g. enhancing BLE security using light as a side channel for key provisioning or proximity assessment.

Flashlight-to-LED as wake-up channel

Beyond communication, the Flashlight-to-LED channel might be used for other purposes. The first example is the use of flashlight-to-LED as a wake-up channel.

Indeed, the use of a low-energy wake-up side channels has gained a lot of popularity in energy-constrained RF networks [START_REF] Gu | Radio-Triggered Wake-Up for Wireless Sensor Networks[END_REF]. This allows switching off the main radio transceiver, with a significant impact on the overall power consumption.

We notice that this wake-up feature is innate in our system, since the LED does not need to be powered in order to detect an incoming transmission from the smartphone. Coming back to the LED-to-camera communication in Chap. 3, this means that the LED does not need to act like an RF beacon, continuously transmitting the information in a loop. Instead, by sending a short light message, the smartphone can wake up the object from stand-by mode and initiate a unicast communication. This mode of functioning has important advantages, not only from an energy point of view, but also for security reasons: the object will transmit the information only when it knows that the smartphone is in its proximity.

Flashlight-to-LED as feedback channel

A third usage of the flashlight-to-LED system is its integration in a bidirectional communication technology between a small colored LED and an unmodified smartphone. However, our results indicate that the flashlight-to-LED average throughput is 30 bit/s, while it can be about 2 kbit/s for the LED-to-camera link.

With such an asymmetry between the channels, acknowledging every packet reception on the smartphone side does not seem realistic. Nevertheless, this feedback capacity still allows us to refine the redundancy mechanisms introduced in Chap. 4.

For the case of the RS mechanism, we propose two acknowledgment strategies. In the first one, denoted as RSc, the LED module continuously transmits the entire sequence of packets until the smartphone receives it completely and sends an acknowledgment. In the second strategy, named RSs, after sending the whole sequence of packets, the LED module stops and waits as feedback from the smartphone the list of missing sequence numbers, thus retransmitting only the missing packets in the following iteration. This is repeated until the smartphone notifies the reception of all the packets. These two solutions can also be combined with the RP strategy, by sending a packet i consecutive times instead of only once. This results in two other redundancy mechanisms, denoted as RSc(i) and RSs(i).

Results in Fig. 5.9 show the goodput of these four strategies, as well as the number of packets that need to be sent in order to recover 600 bits of data split into 50 packets. The results on the left side of the figure evidence that, in terms of packet transmissions, the RSs strategy takes advantage of the feedback channel and performs better than all the others approaches. However, on the right side of the figure, we notice that the goodput for the RSs and RSs(i) strategies falls dramatically. This performance drop is produced by the time spent sending the flashlight-to-LED feed-back, which is about 50 times higher that the transmission on the LED-to-camera link. On the other hand, the RSc Goodput (kbit/s) Figure 5.9: On the left, the number of transmissions needed in order to receive the information for the different redundancy mechanisms when feed-back on the flashlight-to-LED channel is used. On the right, the goodput achieved in the same conditions. The distance between object and smartphone is 5 cm. strategy offers a goodput twice higher than all the RSc(i) mechanism, with a moderate overhead.

We note that, with all the retransmission and feed-back overhead, we obtain a goodput of 1.2 kbit/s between an LED-equipped object and an unmodified smartphone. Moreover, this communication can be launched on demand by the smartphone and makes use of unicast messages, allowing to transmit different types of information to different users (e.g. usage statistics to the owner and troubleshooting logs to a customer service employee).

These results show that using the flashlight as a feedback channel helps hardening the communication system. Nonetheless, because the flashlight-to-LED throughput is only 30 bit/s, these feedback strategies add a non-negligible overhead making their use not realist.

Chapter 6 SeedLight

Introduction

As we have shown in Chap. 3, with a LOS-Channel like in our system, the ROI is only a part of the picture and decreases rapidly with the distance between the LED and the camera [START_REF] Yang | CeilingTalk: Lightweight Indoor Broadcast Through LED-Camera Communication[END_REF][START_REF] Lee | RollingLight[END_REF]. Losses are important and intra-frame losses are added to these caused by the IFG. This highly constrains the PHY-SDU size since the PHY-SDU must fit into the ROI to be received. To get around these issues, we show in Chap. 3 that our system basically retransmits packets continuously. This leads to useless transmissions and makes the sending of large messages arduous. Therefore, this chapter introduces an appropriate mechanism to overcome these drawbacks by developing SeedLight, a coding scheme based on random linear coding (RLC) to improve the goodput and reduce the number of retransmissions in LED-to-Camera broadcast.

Several similar approaches are presented in Sec. 6.2 below but our work is distinguished through the following contributions:

• We provide the first RLC coding scheme optimized for VLC and OCC.

• We reduce the RLC overhead by using a pseudo-random linear coding (PRLC) method.

• Our coding scheme works with smaller PHY-SDUs, an important constraint for the kind of small LEDs we use as emitter.

• The code complexity enables its implementation on cheap MCUs.

The rest of this chapter is organized as follow. Sec. 6.2 presents previous works and spotlights the remaining challenges this work addresses. We then detail the coding scheme that is the main contribution of this chapter in Sec. 6.3, before evaluating its performances by experimentations in Sec. 6.4. Sec. 6.5 focuses on the algorithm implementation and its performances evaluation on low-end IoT devices, before ending with the lessons learned in Sec. 6.6.

Related work

To overcome the loss and asynchronous communications between emitter and receiver in LED-to-Camera broadcast, several methods have been studied in the literature. [START_REF] Ferrandiz-Lahuerta | A Reliable Asynchronous Protocol for VLC Communications Based on the Rolling Shutter Effect[END_REF] proposes to repeat consecutively every packet r times to ensure that each of them can be captured, regardless of the misalignment between the LED and the camera. It is clear that this scheme leads to a reduced data rate. Moreover, the smartphone must receive all the packets independently to decode the frame. A single missing or erroneous packet hence imposes to wait for a whole frame retransmission.

More recently, [START_REF] Nguyen | Data rate enhancement of optical camera communications by compensating inter-frame gaps[END_REF] proposes a combination of Hamming codes and bit interleaving to avoid packet retransmission. Similarly, [START_REF] Hu | Color-Bars[END_REF] uses Reed-Solomon encoding to recover both IFG losses and inter-symbol interferences. These approaches assume that missing bits occur only during the IFG, and that the whole picture contains information. These all require a channel estimation, to set the appropriate number of retransmissions r, Hamming blocks or redundancy bits.

As a consequence, this makes them unsuitable for LOS scenario, where the bit loss highly increases with the distance between the emitter and the receiver.

Recovering the loss in LOS channel is more challenging. Fountain codes [START_REF] Mackay | Fountain codes[END_REF] have been employed to improve the data rate and the link reliability in LED-to-Camera broadcast. [START_REF] Yang | CeilingTalk: Lightweight Indoor Broadcast Through LED-Camera Communication[END_REF] leverages Raptor Codes [START_REF] Shokrollahi | Raptor codes[END_REF] and proposes an experimental evaluation using ceiling LEDs. Their approach reduces the latency at the cost of 25% overhead. In a close way, [START_REF] Du | Martian: Message Broadcast via LED Lights to Heterogeneous Smartphones[END_REF] studies LT-codes [START_REF] Luby | LT codes[END_REF] and proves their implementation can reach 1.6 kbit/s of goodput. Nonetheless, the overhead induced by these approaches would be unacceptably large for the extremely small PHY-SDU size we use. Another flaw of LT-codes and Raptor codes is the coding complexity at the emitter side, which is why studies like [START_REF] Du | Martian: Message Broadcast via LED Lights to Heterogeneous Smartphones[END_REF][START_REF] Yang | CeilingTalk: Lightweight Indoor Broadcast Through LED-Camera Communication[END_REF] perform the encoding step on a computer.

Another class of rateless codes, called RLC, are widely used in the context of network coding (NC) [START_REF] Nguyen | Wireless broadcast using network coding[END_REF]. However, RLC has not been considered yet for VLC.

RLC can be applied within a NC framework, but also as a good packet-level error correction solution: they are simple to implement at the emitter side and per- form similarly to optimal erasure codes for a sufficiently large finite field used for creating the linear combinations of source symbols. The major obstacle in the application of RLC is the decoding complexity of Gaussian elimination decoding.

In [START_REF] Nazir | Performance evaluation of Raptor and Random Linear Codes for H.264/AVC video transmission over DVB-H networks[END_REF] the authors compare RLC and Raptor code performance, showing that, for moderate loss values, the performance of both codes is almost the same but, with higher loss rates, RLC has a better performance.

SeedLight design

These solutions already proposed for VLC in the literature can hardly apply to our system, since we use small color LEDs that constrain the PHY-SDU length, as explained in Chap. 3. Also, implementing these codes on a low-resources MCU, as those we use is not feasible. Therefore, this section presents a coding scheme that overcomes these limitations and improves LED-to-camera communication reliability and goodput compared to a systematic retransmission method.

SeedLight implements a PRLC approach and considers the following requirements: (a) the code overhead must remain as low as possible, (b) the complexity should be low on the emitter side, since the end-devices are low-cost embedded devices with limited computational, memory and energy capabilities, (c) application layer message size cannot be larger than a few hundreds bytes as a consequence of (b).

We begin by introducing RLC, which is the root of SeedLight, and a few notations used in this chapter, before proposing our alternative implementation to reduce the code overhead.

Random Linear Coding

We assume that an emitter T x wants to send a message of G bytes to a receiver Rx, split into N blocks b 1 , . . . , b N that will be encapsulated in a PHY-SDU with payload size p. In the RLC terminology, G is usually termed as the generation size and chunks designate the coded blocks. RLC performs the coding over blocks using a Galois Field GF (q) where q = 2 γ , γ ∈ Z + , is the field size. GF is a key parameter in RLC since it significantly impacts the code performance: a small field size will result in linear dependent chunks, lower overhead and lower computation cost. Because linearly dependent chunks contain the same information, their number must remain as low as possible. However, [START_REF] Lucani | Random Linear Network Coding for Time-Division Duplexing: Field Size Considerations[END_REF] demonstrated that a field size of 2 8 is large enough to have a nearly non-linear dependency.

Following the RLC method further detailed in [START_REF] Nguyen | Wireless broadcast using network coding[END_REF], a set of N coefficients of γ bits c = (c 1 , . . . , c N ), c i ∈ GF (q), is used to generate the coding vector v by linearly combining uncoded blocks as follow:

v = N i=1 (c i • b i ) (6.1)
For successfully decoding and solving the linear equations, Rx must know the coding coefficient c for each coding vector v. This is usually achieved by building a chunk C = [c, v], appending c to v, which results in an overhead of N * γ bits.

Considering GF(256), a 50B message and a 2B payload, this adds an overhead of 25 • 8 bits coefficients for each chunk. That does not fit into a PHY-SDU in our system, where the size l is only 24 bits.

Compressing the coding vector

To avoid transmitting the coding coefficients c, our method is inspired by [START_REF] Astudilloy | PRAVDA: Pseudo random network coding in vanet for data download[END_REF] and uses a seed of a pseudo-random generator (PRNG) to determine c. Our PRLC scheme works as follows.

Encoding: For each chunk C, E randomly generates a seed s ∈ [0 . . .

2 α ],
where α is the seed length. Then, a Mersenne-Twister PRNG that follows the implementation proposed in [START_REF] Matsumoto | Mersenne twister: a 623dimensionally equidistributed uniform pseudo-random number generator[END_REF] and initialized with s is used to produce the N coefficients c 1 , . . . , c N .

Since c i ∈ GF (q) and γ ≤ α, c i is built with the γ lowest significant bits of the PRNG results. The coding vector v is then computed using Eq. ( 6.1) and sent with In this way, the overhead remains low: only α bits to describe the seed, which replaces a sequence number no further needed with SeedLight approach.

Decoding: The decoding step on the receiver side is straightforward and works iteratively. Each time a chunk is received, Rx reconstructs the coding vector c using the seed s included in C: the same PRNG described above is initialized with s and used to produce the N coefficients that build c. Then, c and v are added to the decoding unit matrix and used to solve the linear equations by Gaussian elimination: c v c -1 = 1 b .

Rx can then successfully decode G if it has received at least N linear independent packets. Complexity and implementation are discussed in Sec. 6.5.

SeedLight evaluation

In this section, we evaluate and present the achievable performance of Seed-Light LED-to-camera broadcast under realistic conditions and compare this with a conventional retransmission method. We mainly focus on two aspects: 1) the coding parameters, namely the seed length α and the generation size G, and 2) the distance between Tx and Rx.

Seed and Generation size

An important property of the LED-to-camera communication is the fact that information losses are unavoidable and almost regular. Indeed, even when functioning at the maximum frame rate of 30 frames per second, the pictures taken by the smartphone do not represent a continuous view of the LED, because of the IFG. To cope with these losses, the data needs to be segmented into packets, which can be easily reassembled and retransmitted. However, the size of the packet has a significant impact on the packet loss probability as discussed before in Sec. 3.4.4. These results expose that the seed length and the overhead ratio have to be carefully designed and are major influence factors of SeedLight performance.

Therefore, we evaluate by simulation with CamComSim the impact of the seed length (α) on the ratio of linearly dependent chunks produced when the minimum number of blocks N , required to recover the message, increases. Results

in the left plot in Fig. 6.2 highlight that, to get less than 10% duplicated chunks, 8 bits are necessary for N = 50 while 10 bits are needed for N between 100 and 150. We also see that less than 8 bits are not enough, even when N is small. The duplicate ratio becomes negligible for seeds larger than 10 bits and for values of N higher than 100.

Right plot in Fig. 6.2 shows the goodput when varying the seed length for a PHY-SDU error rate P e of 0.3, 0.5 and 0.7, respectively at 5, 10 and 20 centimeter, taking a generation size G = 100B. The best goodput is always obtained with a 8 bits seed and decreases progressively when the seed length increases. This is mostly because the overhead rises, even if the amount of linearly dependent blocks highly reduces. As the duplicated chunks ratio with a 6 bits seed is larger than that of 8 bits, the goodput is in such case lower.

Communication Performance

We now evaluate by experimentation the LED-to-camera communication performance as a function of the distance between the LED and the smartphone. We use a slightly modified version of the testbed we described in Sec. Light, the encoding of the set of chunks is done before the transmission starts.

Thus, the computation does not affect the communication performance.

We compute the throughput as the number of received bits per second, error free, including duplicated packets or linearly dependent chunks. The goodput is calculated by removing duplicates and transmitting until the smartphone receives all the 100B message. Fig. 6.3 compares the throughput and the goodput for transmissions with and without the benefits of SeedLight. The three curves follow the same tendency: the throughput drops from 3 kbit/s at 5 cm to less than 0.2 kbit/s at 40 cm. We notice two sharp decreases, respectively at 5 cm and 15 cm. From 0 to near 5 cm, the LED lightens the full surface of the CMOS sensor and the loss is mainly due to the SNR decrease and the blooming effect [START_REF] Chow | Enhancement of Signal Performance in LED Visible Light Communications Using Mobile Phone Camera[END_REF]. The second, between 15 to 20 cm, is less straightforward and we make some assumptions to explain the phenomena. First, at this distance, the ambient light, that has been measured at 650 lux, starts interfering with the LED signal. Then, the ROI becomes small enough that no more than one packet is received at once and a non negligible amount of frames do not contain any information. The red curve

shows that, at 5 cm, the goodput with SeedLight is 2.25 kbit/s while it is 1.4 kbit/s without, bringing out a gain of 60%. Also, we can see that the relative gain grows with the distance: a gain of 90% is noticed at distance of 30 cm.

Implementation discussion

We show that SeedLight improves the LED-to-Camera transmission goodput compared to a systematic retransmission method. However, this is achieved at the cost of an additional coding step before transmission. Nonetheless, as explained in Sec. 6.3, SeedLight focuses on low-end IoT devices for which available resources are very limited. In such situation, software development and computation intensive algorithm optimization is complicated. Therefore, in this section, we discuss SeedLight implementation problems on aforesaid embedded platforms and evaluate the coding impact on two distinct MCUs and smartphones.

PRLC implementation on IoT devices

Several RLC algorithm benchmarks have been implemented previously. These studies were performed on computers [START_REF] Xing | On minimizing coding operations in network coding based multicast: an evolutionary algorithm[END_REF], smartphones [START_REF] Fitzek | Network Coding: Applications and Implementations on Mobile Devices[END_REF] or high-end embedded devices, at least able to run a UNIX operating system [START_REF] Hernández Marcano | On Goodput and Energy Measurements of Network Coding Schemes in the Raspberry Pi[END_REF]. There is not a known implementation on low powerful platform like ours. As a comparison, a Raspberry Pi has 256 Mo RAM and 700 MHz CPU while the STM32L0 is only 32

MHz and 8 Ko RAM. That spots the large gap in the expected performances.

As shown in Sec. 6.3, PRLC relies on the widely used GF(256): its optimization has been discussed in [START_REF] Greenan | Optimizing Galois Field Arithmetic for Diverse Processor Architectures and Applications[END_REF], where the authors propose several solutions optimized for speed or memory. Tab. 6.1 shows the number of operations and memory requirement for three of those solutions that comply with our system:

(1) uses full multiplications LTs, is the fastest method but its LTs are larger than our MCU flash size; (2) uses log and anti-log LTs, is well balanced between memory requirement and complexity; (3) requires the largest number of operations and will be restricted to cases in which the low available RAM forbids the use of lookup tables (LTs).

Comparing these solutions with the constraints of the emitter and the receiver of our system, using method (1) is preferred for the decoding considering the 1 GB non-volatile memory available on the Nexus 5, while method (2) is preferred for the encoding, considering the low memory and the low computation resources available on the MCU we use.

According to Tab. 6.1 for (2) and the PRLC scheme proposed in Sec. 6.3, the code complexity to produce N chunks of P symbols is then O(N 2 P ). In the same way, the complexity to decode a matrix of N • (N + P ) bytes is given by O(N 3 + N 2 P ).

Method Operation Memory

(1) Mult. LT

Evaluation

We now evaluate the PRLC algorithm introduced in Sec. 6.3 and implementations discussed in Sec. 6.5.1 in our testbed. We benchmark the algorithm on Algorithm benchmark: Considering the optimizations discussed in the previous section, Tx uses the method (2), i.e. using the log and anti-log LTs to perform GF(256) arithmetic operations, while Rx uses the method (1), i.e. using a full multiplication LT. The left plot in Fig. 6.4 shows that the encoding computation time per chunk, when the MCU is used for communication only, increases linearly with the generation size. For the 8 MHz MCU (blue line), the time remains below the chunk transmission time when the generation size is smaller than 150 B and is about 5 ms with a 25 B generation, doubling when G = 400. This emphasizes that, with an appropriate mechanism, performing coding in parallel with modulating the LED is feasible, even for a low MCU frequency, when less than 150 B are transmitted.

The right plot in Fig. 6.4 shows the decoding and Gaussian elimination computation time for each chunk. The evaluation was performed while the smartphone was capturing and processing camera frames using the VLC decoding algorithm introduced in Sec.3.2. Unlike the encoding algorithm, the increase is exponential. The benefits of the Nexus 6P, that has a 8-cores CPU while the Nexus CPU has only 4 cores, is high and the chunk processing remains below 2 ms even with a generation size of 400 B. Since the camera frame rate is 30 fps and about 6 chunks are decoded in each, this shows the operations can be done in real-time. Also, further improvements are left pending, as developing the decoding algorithm in a C library to replace the current Java implementation.

MCU mode:

The results discussed above were obtained when the MCU was used for communication only. However, the main functionality of consumer IoT MCU is not usually communication. This can be gathering data from sensors or performing main application logic algorithms. Radio transmission and signal generation can be realized by a dedicated chip but that is not always the case and, as a consequence, the MCU resources must be shared. In such cases, communication happens during reserved time slots or concurrently in a multi-tasking approach. To conform with these needs, we propose three scheduling strategies for PRLC and transmission:

1. Pre-computed mode computes a set of chunks before transmitting them in a row, as in Sec. 6.4. This increases the needed RAM.

2. Sequential mode computes a chunk and transmits it right away. This increases the delay, since the transmission is interrupted between each chunk.

3. Parallel mode takes advantage of multi-tasking to compute a chunk when the previous one is transmitting. If the chunk computation time is larger than the transmission time, the transmission will stop during this time gap. This solution has the highest impact on then CPU load.

The pre-computed mode ( 1) is relevant when the data source, e.g. a sensor, stores the data immediately as encoded chunks, the sequential mode (2) when a prioritized task is running at the same time and the parallel mode (3) when the communication is prioritized regarding the main application task or when the MCU speed is hight enough to run both. We now focus on the end-to-end goodput evaluation, considering these three implementations to depict real use cases of IoT devices. Fig. 6.5 shows the goodput transmitting a message of 100 B (blue) and 400 B (green) with SeedLight (α = 8) using the software implementations discussed above. We place Tx and Rx at 5 cm and 15 cm distance. We note that the goodput falls as the message size increases, mainly because of the amount of linear dependent chunks transmitted. The plot highlights that, when working with a generation size of 100 B, the chunk computation can be achieved in real time even at 8 MHz and both transmission and chunk computation can be paralleled without throughput loss compared to the Pre-computed implementation. The Sequential mode for the 100 B message is half the values of the others since it adds a delay to compute the chunk before its transmission. With a generation size of 400 B, the goodput decreases between the Pre-computed and Parallel modes. This highlights that, in such cases, the MCU reaches its limit and a small gap between chunk transmission appears. Nonetheless, SeedLight still boosts the goodput observed with a systematic retransmissions scheme.

These results conform quiet well with Fig. 6.4 and bring out that SeedLight can be implemented even on the cheapest MCU with a minor impact on the communication performance. Note that reducing the GF size would alleviate the load on the MCU at the cost of few linearly dependency overhead. Furthermore, SeedLight will not increase the MCU power consumption, since this can be done without any modification on the MCU clock and during the same time interval the device modulates the LED. Moreover, since it reduces the number of transmissions that are necessary to receive the full message, SeedLight hence reduces the energy consumed.

Lessons Learned

In this chapter, we have introduced SeedLight, a novel lightweight erasure coding method that leverages RLC theory to face the inevitable and large packet losses in LOS LED-to-Camera broadcast. The key idea of SeedLight is to take advantage of a PRNG to avoid the systematic transmission of the mandatory coding header introduced by RLC.

This work provides practical engineering insights and puts in evidence two points. First, experimental evaluation shows that this approach increases the goodput from 1.5 to 2.5 kbit/s compared to a packet retransmission mechanism.

Compared to the erasure coding scheme recently proposed for OCC [START_REF] Yang | CeilingTalk: Lightweight Indoor Broadcast Through LED-Camera Communication[END_REF][START_REF] Du | Martian: Message Broadcast via LED Lights to Heterogeneous Smartphones[END_REF],

SeedLight introduces a much smaller overhead that makes it suitable when the PHY-SDU can not be larger than few tens of bits.

Secondly, the major benefit of SeedLight is the low computational overhead on the emitter side. A careful implementation of SeedLight on low-cost MCUs, like those often used in IoT devices and smartphones, brings out that our solution does not affect the communication performance and is compatible with such applications.

Chapter 7

Insight on Energy Consumption

Many of the objects we wish to see connected are generally powered by batteries, which are limited in size and, therefore, capacity. Also, wireless modules are known to be important power consumers, and energy considerations like the product autonomy are major constraints during the design and the conception phase of smart objects. Thus, choosing the appropriate communication technology, best fitting the user expectations in term of data rate, availability and battery life, is often challenging. In this context of personal objects, BLE is usually used when power efficiency is preferred to data rates. Similar energy considerations stand true for mobile phones, where software, battery or radio optimizations are major research topics and crucial problems for phone manufacturers [START_REF] Ravi | Context-aware Battery Management for Mobile Phones[END_REF]. Therefore, in this chapter, we measure the Ligh-tIoT energy requirements and compare them with an equivalent system based on BLE, more precisely, on the Nordic Semiconductor nRF51 module. We measure the energy consumption on the object side in Sec. 7.1, and the one on the smartphone side in Sec. 7.2, before studying in detail representative use cases in Sec. 7.3.

Wireless module battery drain

We measure the power consumption of both BLE and VLC modules, using the Keysight N6705B Power Analyzer, that we also used as a power source to supply a 3.3 V voltage. The measurements are recorded on a computer to be further analyzed. The power measurement testbed in shown in Fig. 7.1.

These measurements were done in different conditions. In BLE Wait, the object is in the peripheral mode defined by the Bluetooth 4.0 specifications, with On the VLC side, the energy consumption is measured under the following settings: in VLC Wait, the module is placed in low power mode and wakes up every 750 ms to detect the beginning of a transmission, using an LED receiver as described in Chap. 5; in VLC Tx, the module is continuously sending packets using the LED; finally in VLC Rx, the module is actively sampling the LED and receives data from the smartphone flash. The leakage current profile for the VLC Wait, VLC Tx, and VLC Rx is shown in Fig. 7.3.

Then, using the leakage current measurements from the Keysight Power Analyzer, we compute the power consumption P and the consumed energy E.

The results in Fig. 7.4 show the average power consumption for the six scenarios defined above. Consumption in the wait state for the BLE and VLC devices are similar, 0.9 and 0.11 mW respectively. We can see that VLC Tx consumption is 39 mW, while it is only 18.4 mW for the BLE. This can be explained by the short duration of the RF energy consumption peaks compared to the time the LED needs to be on for a transmission, although the current intensity is around 20 mA in both cases. On the contrary, the VLC receiver is power efficient, for it We note that the consumption of the VLC Tx module, while superior to its BLE counterpart, is actually produced by the energy required to turn on the LED.

Since the modulation scheme and the driving circuit have a low complexity, the processing and signal generation contribution to the energy consumption is very low, quite similar to the contribution of the module in wait mode (0.61 mW). This means that, for devices that already keep LEDs turned on during their usage, no extra energy is consumed for transmission. Moreover, since the LED-to-camera transmission is based on alternating on and off periods, the communication module practically reduces the energy consumption of the LED, as if the intensity of the LED was dimmed.

This can be noticed in Fig. 7.4, by taking as reference the consumption in the LED On state, where the LED is simply on, without transmitting any information.

These results show that VLC becomes advantageous compared to BLE when the device is inoperative most of the time or if it has to wait a master request before transmitting. In that way, the LED can be kept off and the device in a very low power mode.

Smartphone battery drain

Measuring the power consumption on a smartphone is not obvious, as accessing its motherboard or removing the battery may affect its integrity. Another issue is to isolate the contribution of a single component, or that of an application, from the global power consumption. Different approaches based on hardware or software solutions have been proposed and compared. Relying on the study in [START_REF] Brouwers | NEAT[END_REF], we use the Qualcomm Trepn Profiler application and compare these results with the battery drain estimation provided by the Android OS. During the tests, we shut down all the useless radio interfaces and we set the screen brightness to its minimal value following the recommendations in [START_REF] Carroll | An analysis of power consumption in a smartphone[END_REF][START_REF] Brouwers | NEAT[END_REF][START_REF] Hoque | Modeling, Profiling, and Debugging the Energy Consumption of Mobile Devices[END_REF][START_REF] Bakker | Comparing Energy Profilers for Android[END_REF]. Fig. 7.5 shows that VLC highly increases the leakage current both in RX and TX modes. On the other side, the impact of BLE remains low for both cases.

As expected, the results in Fig. 7.6 highlight the high power consumption of the VLC application, mainly due to the flashlight (1.35 W) when transmitting, and to the camera (1.92 W) when receiving. As a consequence, smartphone auton- omy for a continuous use of LightIoT is less that 2 hours, while it is 9 hours using BLE.

Tab. 7.1 summarizes the LightIoT energy consumption per byte of information transmitted. As a consequence of its low data rate, communication using Ligh-tIoT is overall more energy consuming compared to BLE, especially because of the increased consumption on the smartphone side. However, taking into account that most of the targeted products already keep an LED turned on during functioning, the VLC transmission practically becomes energy-free in this case. Also, most of the energy consumption is moved towards the smartphone, which can be much easily recharged compared with battery-powered objects.

Use cases energy balance

We now compare the average VLC module power consumption along the product life with its BLE equivalent for several scenarios and usage profiles.

Scenario 1 assumes the wireless connectivity is used for a firmware Over-The-Air (OTA) update, resulting in a 2 kB file transfer from the smartphone to the object. On the contrary, Scenario 2 is a 2 kB troubleshooting log file transfer from the object to the smartphone. Scenario 3 and Scenario 4 represent much smaller transmissions, respectively a 10 B configuration command from the smartphone to the object or a 10 B sensor value reading from the object to the mobile phone. On the LightIoT side, we use the flash-to-LED wake-up feature, meaning that the object consumes energy only for transmission and reception of data. On the BLE side, we consider the object is in peripheral mode, broadcasting an advertising packet every 750 ms, as defined by the Bluetooth 4.0 standard. In Fig. 7.7, we show the object average power consumption as a function of the number of uses per day, for the two scenarios where the object is a receiver (i.e. scenarios 1 and 3) on the left side, and for the two where the object is the show identical results, as the consumption in BLE Rx and BLE Tx is the same.

For Scenario 1, the results show that using VLC brings an advantage if the OTA update does not occur more than ten times a day, which is well below the expected firmware update frequency. For the transfer of a log file from the object to the smartphone, the VLC solution consumes less energy than its RF counterpart if we remain under 28 transmissions per day. Finally, for the short message exchanges, the results show that LightIoT saves energy even for a high number of events.

Lessons Learned

Results in this chapter underline that VLC improves the product battery life when the connectivity function is an auxiliary one, by decreasing the average power consumption of the communication module. Of course, this conclusion can be challenged by totally turning off the BLE radio and turning it on only when needed, for instance with a wake-up receiver, or with a power switch. Nonetheless, this would be either impractical or expensive to integrate in daily usage objects.

Chapter 8 Conclusion and Perspectives

Conclusion

Visible Light Communication is unquestionably a great opportunity for the future of wireless communication. This is particularly true in the context of smart cities, where the number of devices connected to Internet or a local network is continuously and quickly growing. In such cases, leveraging visible light spectrum allows radio communication offloading and thus results in an overall communication capacity and bandwidth increase. We show in Chap. 1 and Chap. 2 that this is the main focus of VLC research nowadays.

On a smaller scale, with the rise of Internet of Things, today consumers expect every object to be smart, allowing wireless interaction with them through their smartphone. Radio solutions already exist, like BLE or WiFi, but they have many drawbacks that make their use sometimes unwanted, and even impossible. Companies such as Rtone have widely observed this fact, and have faced this issue many times during the design of IoT devices with strict customers constrains. Looking for a solution raises the following question: since these IoT devices already integrate LEDs and people already own smartphones with a camera, can we leverage them for communication using VLC? That is this question that has driven this thesis and which we answered with this work. Thus, the main purpose of this thesis focuses on the use of VLC to enable bidirectional communication between small IoT devices and off-the-shelf smartphone.

To reach this goal, we have solved many issues which improve the baseline state of the art. As a matter of fact, we summarize the state of the art through a taxonomy of VLC systems in Chap. 2. We divide previous works into three different groups according to the receiver they are using: photodiodes, LED or camera.

This study highlights the lack of contributions and solutions for low-power LED-to-camera on one side, and for flashlight-to-LED communication systems on the other side.

We begin our work by enabling low power LED-to-camera communication in Chap. 3. We implement and experimentally evaluate this LED-to-camera VLC system, designed specifically for small LEDs. Our solution exploits the rolling shutter effect of off-the-shelf smartphone cameras and an original decoding algorithm, achieving a throughput of nearly 2 kbit/s in ordinary illumination conditions. Our extensive evaluation studies many performance factors and brings out the high loss rate that is inherent to such channel and the need to add redundancy mechanisms to make the communication robust.

Based on these insights, we model the LED-to-camera communication channel, characterized by an on/off behavior resulting in a close to regular frame error pattern. In Chap. 4, we propose a MMBP model, which allows us to easily study the performance of different message retransmission strategies. Relying on this model, we also implement a simulator for LED-to-camera communication performance evaluation. Then, we use both tools to benchmark two trivial redundancy methods we found in the literature. The similar results between experimental, analytical and simulation approaches prove the accuracy both of our analytical model and our simulator.

To make our system bidirectional, in Chap. 5 we leverage the flashlight of unrooted smartphone and use a small LED as receiver. The LED is exactly the same as those we used as an emitter in Chap. 3. We design smart mechanisms and protocols that cope with the flashlight signal jitter and that detect the flashlight clock rate whatever the smartphone type. With these hardware constraints, our system, LightIoT, achieves a throughput of 30 bps, from the phone to the object.

With such an asymmetry between the channels, acknowledging every packet reception on the smartphone side does not seem realistic. Instead, the flash can be efficiently used as a feed-back channel by acknowledging the reception of the whole message. Thus, in combination with an erasure code on the emitter side, such as random linear coding, the flash-to-LED channel would significantly improve the system performance and robustness.

Therefore, in Chap. 6, we design and implement SeedLight, a pseudo random linear coding scheme especially fitted for LOS LED-to-camera communication. Experimental evaluation highlights that this type of approach increases the goodput from 1.5 to 2.5 kbit/s with respect to packet retransmission mechanisms.

Finally, many of the small objects we address through LightIoT have significant energy constraints. Therefore, in Chap. 7 we compare the energy consumption of LightIoT with the one of a BLE module with similar activity. Our results

show that using the LED for communication purposes reduces the energy consumption under a normal utilization profile.

Industrial Ouputs

Short Term Perspective

RGB LEDs as emitter

As a continuation of our work, we propose to study the feasibility of replacing the small monochrome LEDs we used in this thesis with an equivalent RGB LED.

In fact, RGB LEDs are often preferred to monochrome LEDs in commercial electronics, since their color can be changed at runtime. The use of RGB LEDs for LED-to-Camera communication may help increase the system throughput or its reliability. After some investigations, we show bellow our first findings and discuss the remaining challenges.

An RGB LED is composed in fact of three LEDs: red, green, and blue, inside one package. Typically an RGB LED has four pins: one common pin that is connected to ground and one for each of the three LEDs. This allows a program to vary both the color and the color intensity level of the RGB LED.

While OOK combined with the Manchester line code is usual for monochrome LEDs [START_REF] Danakis | Using a CMOS camera sensor for visible light communication[END_REF][START_REF] Duque | Unleashing the power of LED-to-camera communications for IoT devices[END_REF], Wavelength Division Multiplexing (WDM) and Color-Shift-Keying (CSK) have been proposed for RGB LEDs respectively by Liang et al. [START_REF] Liang | RGB visible light communication using mobile-phone camera and multi-input multi-output[END_REF] and by Chen et al. [START_REF] Chen | Color-Shift Keying and Code-Division Multiple-Access Transmission for RGB-LED Visible Light Communications Using Mobile Phone Camera[END_REF]. WDM schemes modulate the three color channels independently with distinct input data. On the contrary, in the CSK scheme, the transmitted bits match specific color coordinates in the color space.

We experimentally found the color we can obtain with our low-cost hardware to establish a suitable CSK modulation scheme and we defined a constellation of symbols. This allowed us to identify the following challenges: The RGB LED without modulation. On the left, the LED is strongly dimmed with the 3 channels ON. On the right, the LED is normally dimmed with only the red and green channels ON.

Limited number of symbols that the RGB LED can produce: the RGB LED can produce only a few colors. Some of these symbols seem to be very close and so, are often difficult to distinguish. The experiments bring out that the green channel state is not easily determinable for the symbols for which the green is mixed with another color.

Color diversity across devices, camera settings and ambient light: various smartphones will render the colors differently and that behavior also happens on the same device when the ambient lighting conditions change or by modifying the ISO, exposure and white balance settings. Color mixing issue with the cheap low-power RGB LEDs: as shown in Fig. 8.3, even without modulation and with proper use of the RGB LED, the colors are not perfectly mixed so that two or three color beams are visible. However, to exploit the rolling shutter effect, we expect that the color remains the same along a row of pixels when the LED is not modulated.

Real-time implementation: color detection requires complex computer vision algorithms that need a three-dimensional matrix as input. That is three times larger than the one for a monochrome LED. Previous works [START_REF] Hu | Color-Bars[END_REF][START_REF] Chen | Color-Shift Keying and Code-Division Multiple-Access Transmission for RGB-LED Visible Light Communications Using Mobile Phone Camera[END_REF][START_REF] Ryu | RGB MIMO optical camera communication with Histogram equalization[END_REF] all present a compute-intensive demodulation method using Matlab or OpenCV on a computer. A real-time algorithm implementation on a smartphone has not been unveiled yet.

Figure 8.4: On the bottom, the red channel input with the regular f csk CSK modulation. On the middle, the CSK modulation is combined with a f pwm PWM and a f pwm /2 PWM on the top, so that dark and light stripes will appear within the CSK symbol period. our observations, we found that the M frequencies f i pwm must be 16 ≤ f i pwm ≤ 22 kHz to comply with the camera shutter bandwidth. To avoid ISI, i.e. to be able to determine the difference on the stripes spacing, two adjacent PWM frequencies f i pwm and f i+1 pwm must be spaced with ∆ f ≥ 2 kHz. Thus, each channel has 6 states, e.g. for the green channel:

G f 1 pwm , G f 2 pwm , G f 3 pwm , G f 4
pwm , G ON , G OF F with f i pwm = {16, 18, 20, 22} kHz, i = 1, . . . , 4. However, we make the hypothesis that choosing symbols where f pwm varies more than one channel will cause unmanageable ISI. Furthermore, using the PWM modulation on only the green channel will help the color identification process so that the green channel state can be inferred from the presence of stripes.

Until today, we pointed out through a series of experiments the challenges of RGB LED to camera communication and proposed several ideas that we expect to ease the decoding process. These algorithms and methods are left under development. In a future work, we plan to conduct an extensive experimentation campaign to evaluate and (in)validate the hypothesis we presented just before.

Multiple LEDs to Smartphone[s]

We have shown in Chap. 3 that our algorithm can discriminate the LEDs used for VLC, between many LEDs used only to emit light. Also, our algorithm can decode data from several LEDs captured within a same picture, in real time.

Nonetheless, we never took advantage of this property, nor study MIMO communication. Because consumer electronics often have many LEDs, N -LEDs to camera communication is a realistic scenario that allows the following improvement to LightIoT:

• increasing the communication system throughput in the N -LEDs-to-smartphone topology, with the benefits of SeedLight to smartly combine packets from several emitters.

• sending different information at the same time, e.g. data with localization information or data with signaling.

• enabling multi-user communication in the N -LEDs-to-N -smartphones scenario.

Open Perspectives

This thesis and our results also open long term research perspectives. In this section, I will introduce two research topics on which I personally would enjoy working toward.

Coexistence of VLC and RF on IoT Devices

In the next generation of wireless communication systems, or 5G, the dense deployment of IoT devices will add an increasing amount of RF congestion. New wireless access techniques are required to maximize the use of the available RF bandwidth and increase aggregate throughput in these environments. Indeed, these RF standards such as 802.11n [START_REF] Paul | Wireless LAN Comes of Age: Understanding the IEEE 802.11n Amendment[END_REF] offer many features (i.e., channel width, number of streams, length of guard interval, and modulation and coding scheme index) that can be selected to improve the communication performances in dense environments. In fact, 128 and 640 combinations exist for 802.11n and 802.11ac respectively [START_REF] Abedi | Examining Relationships Between 802.11n Physical Layer Transmission Feature Combinations[END_REF]. Nonetheless, since neither 802.11n nor 802.11ac have a signaling channel, parameters selection algorithms remains inefficient [START_REF] Abedi | Examining Relationships Between 802.11n Physical Layer Transmission Feature Combinations[END_REF]. Thus, using a low data rate VLC for out-of-band signaling channel for RF parameters optimization can improve the utilization of the RF resources. Also, IoT devices must be energy efficient and the wireless connection must provide security and privacy. Low data rate VLC can thus serve as a light based wake-up receiver to improve the IoT energy use on the first hand, or the IoT security using light as a side channel for secrets or certificates provisioning on the other hand.

Adaptative Protocols and Mechanisms for Smartphone to IoT Network Communication

Our work allows short range bidirectional communication and interaction between user and consumer electronics. Since this network topology only has two nodes and the communication range is very limited, we never considered nor studied networking scenarios.

Besides, today consumers often have many smart devices at home, and Schmid et al. [START_REF] Schmid | LEDto-LED visible light communication networks[END_REF] demonstrated that LED-to-LED communication between IoT devices is feasible within a range up to 2m, allowing IoT networking.

Combining our approach with the one proposed in [START_REF] Schmid | LEDto-LED visible light communication networks[END_REF] to make a smartphone able to communication with any device within a multi-hop IoT network raises the following questions:

• How to solve the devices addressing issue?

• Can we increase the smartphone-to-device communication range by relaying packets?

• How to route packets efficiently?

• Since the smartphone-to-device and device-to-device channel characteristics are totally different, how can we automatically adapt them?

• What about the security and confidentiality consideration?

Enabling smartphone to multi-hop IoT network definitely opens many challenges and interesting research opportunities. Evaluating and modeling such a system will be a shining example of that.

To sum up, our future works are mainly related to studies of more complex systems: first by considering different system topologies, i.e. different kind of emitters or devices, and then studying the networking aspects.

  Light Communication, Internet of Things, Smartphone, Optical Camera Communication, Wireless Communication, Random Linear Coding, LED-to-Camera Communication Résumé Avec la croissance exponentielle de l'Internet des objets, les utilisateurs s'attendent maintenant à ce que chaque appareil ménager soit intelligent et connecté. Dans le même temps, les smartphones sont devenus omniprésents dans notre vie quotidienne. L'amélioration continue de leurs performances et leur compatibilité avec de nombreux protocoles radio tels que le WiFi, le Bluetooth Low Energy (BLE) ou le Near Field Communication (NFC) en font le moyen le plus pratique pour interagir avec ces objets connectés. Cependant, offrir une connectivité sans fil utilisant le BLE ou le NFC implique d'ajouter un chipset supplémentaire et une antenne, ce qui augmente la taille et le prix de l'objet. En outre, ce type de modification matérielle n'est pas sans impact: même si le coût unitaire de la puce radio est négligeable, il peut devenir très important lorsque des millions de produits sont vendus. Par ailleurs, des travaux antérieurs ont déjà démontré la possibilité de recevoir de l'information par la lumière visible (VLC) à l'aide d'un smartphone non modifié grâce à sa camera. Aussi, des communications bidirectionnelles entre diodes électroluminescentes (DEL) pour les objets connectés comme les jouets ont déjà été démontrées précédemment. Cependant, les efforts afin de proposer une communication sans fil utilisant des petites DELs et la caméra des smartphones restent à ce jour inexistants. Dans ce travail, nous abordons donc cette question et proposons LightIoT, un système de communication bidirectionnel par VLC entre une DEL de couleur et de faible puissance qui est intégrée à un objet connecté et un smartphone non modifié. Le dispositif est ainsi capable d'envoyer et de recevoir des informations à travers sa DEL, tandis que le smartphone utilise sa caméra pour recevoir des données et son flash pour envoyer des informations. Nous mettons en oeuvre et évaluons expérimentalement ce système VLC DELà-camera conçu spécifiquement pour les DEL de couleurs à faible puissance. La solution proposée exploite l'effet de l'obturateur déroulant de la caméra des smartphones associé à un algorithme de décodage original et atteint un débit Foreword This thesis compiles my PhD work on the Design of a bidirectionnal visible light communication system for Internet of Things devices and off-the-shelf smartphones. This work is a collaboration between the Rtone company and the Inria AGORA team (ex-URBANET) from the CITI laboratory (Centre d'Innovation en Télécommunications et Intégration de services) at INSA de Lyon. This cooperation happened under the ANRT CIFRE (Conventions Industrielles de Formation par la Recherche) program.

3. 1 54 4. 1 63 4. 5 64 4. 6 65 4. 7 66 4. 9 The 76 5. 1 80 5. 2 81 5. 3 84 5. 6 85 5. 7 87 5. 9 89 6. 1 93 6. 2 95 6. 3 96 6. 4 100 xviiiof figures 7 . 1 105 7. 4 105 7. 5 107 7. 6 108 8. 1 114 8. 2 114 8. 4

 154163564665766976180281384685787989193295396410071105410551076108111421144 On the left, our LED-to-Camera VLC system. On the right, our smart VLC device prototype. . . . . . . . . . . . . . . . . . . . . . . . 3.2 The Nucleo STM32L0 development board . . . . . . . . . . . . . . . . 3.3 PHY-SDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Algorithm computation time. State of the art implementation (left) and our implementation (right) . . . . . . . . . . . . . . . . . . . . . . 3.5 Total process duration distribution comparing AsyncTask and Thread 3.6 A picture frame containing three ROIs. The smaller ROI on the left will be skipped by the decoding algorithm, as it does not contain any valid PHY-SDU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Comparison of the signal before S3 (left) and after S3 (right). . . . . 3.8 Steps duration repartition of the optimized algorithm. . . . . . . . . 3.9 On the left, the algorithm duration for one to four emitters. On the right, the comparison of the algorithm efficiency (throughput) over different scenes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 The throughput as a function of distance, compared with the goodput (left) and for various illumination conditions (right). . . . . . . . 3.11 The throughput as a function of distance, for various OOK symbol rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi List of figures 3.12 The goodput (left) an throughput (right) for different PHY-SDU sizes. 51 3.13 The PHY-SDU loss ratio as a function of distance, for different PHY-SDU sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.14 On the left, the impact of the angle between the LED and the camera at 10 cm. On the right, the throughput when he user is holding the smartphone compared to a mechanical support. . . . . . . . . . 53 3.15 The average number of PHY-SDU received per camera frame for several LED models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frame capture time and inter-frame interval, and their relation with the MMBP parameters. . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2 The Gilbert-Elliott model of the LED-to-camera channel. . . . . . . . 59 4.3 The MMBP model of the LED-to-camera channel. . . . . . . . . . . . 60 4.4 Probability to successfully receive N p packets for the RP strategy. Dotted-lines show analytical results for the Gilbert-Elliott and MMBP models, while plain lines represent experimental results. . . . . . . Probability to successfully receive N p packets for the RS (left) and RP (right) strategies as a function of the number of retransmissions r. Dotted-lines show analytical results while plain lines represent experimental results. . . . . . . . . . . . . . . . . . . . . . . . Comparison between RS and RP. On the left, analytical and experimental results for M = 5 and N = 3. On the right, analytical results when M +N = 7, but the M : N ratio changes. In both cases, N p = 50. Formation of an image on a sensor by a converging lens. . . . . . . 65 4.8 ROI as a function of distance. The orange line shows experimental results, while the green line represents analytical results given by Eq. 4.10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CamComSim software architecture and packages dependency graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.10 The experimental goodput (blue) compared with the simulation goodput (green) as a function of the number of consecutive PHY-SDU emissions. The bars on top are 95% confidence intervals. . . . 71 4.11 The experimental goodput (blue) compared with the simulation goodput (green) for different message size (G, bytes). . . . . . . . . 72 4.12 The throughput (red) as a function of the distance, compared with the goodput (green). Dotted-lines show experimental results while plain lines represent simulation results. . . . . . . . . . . . . . . . . 73 List of figures xvii 4.13 The experimental goodput (blue) compared with the simulation goodput (green) for different PHY-SDU payload size (bit). . . . . . . 73 4.14 The experimental goodput (blue) compared with the simulation goodput (green) for the use case as a function of the number of consecutive PHY-SDU emission at 5 cm (left) and 10 cm (right). . . . Our bidirectional VLC system. . . . . . . . . . . . . . . . . . . . . . . . On the left, the LED discharge tension when it is lighted by ambient light only. On the right, the same LED lighted with the smartphone flashlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . From the top left to the bottom, the LED is wired in transmitter, charging and receiver operating mode respectively. . . . . . . . . . . 82 5.4 Symbol data mapping and diagram. . . . . . . . . . . . . . . . . . . . 84 5.5 On the top, the SR symbol. On the bottom, a frame that includes a SR symbol sent to initiate the synchronization process. . . . . . . Receiver synchronization process. . . . . . . . . . . . . . . . . . . . . Distribution of effective pulse duration for different configured pulse duration values. . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.8 SNR when varying the flashlight distance (green curve) and the smartphone-LED angle (orange curve). The red line represents the minimum required SNR for correct decoding. . . . . . . . . . . . . . On the left, the number of transmissions needed in order to receive the information for the different redundancy mechanisms when feed-back on the flashlight-to-LED channel is used. On the right, the goodput achieved in the same conditions. The distance between object and smartphone is 5 cm. . . . . . . . . . . . . . . . . Packet sent without coding (middle) and chunk format generated by PRLC (bottom) encapsulated into a PHY-SDU (top). . . . . . . . . The chunk redundancy introduced by duplicated chunks vs the seed length and N . Goodput with G=100B for some PHY-SDU error probability vs the seed length (left). . . . . . . . . . . . . . . . . . . . Throughput compared with the goodput vs the distance, with and without coding for G=100B (right). . . . . . . . . . . . . . . . . . . . . Computation time on a MCU to build 1 chunk (left). Computation time on the Nexus 5 and 6P to process 1 chunk and perform decoding (right). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.5 Goodput using different implementations for G=100B and G=400B. List Our power measurement testbed. The smart device is directly powered by the Keysight Power Analyzer. . . . . . . . . . . . . . . . . 104 7.2 The BLE module leakage current in slave mode (left) or master mode (right). In master mode, the BLE device is scanning for peripherals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.3 The VLC module leakage current in TX mode and RX mode. . . . . . The communication module power consumption for BLE and VLC. The leakage current on the Nexus 5 using BLE (blue) or VLC (orange) for communication relative to the baseline current. . . . . . . Nexus 5 power consumption (left) and battery drain (right) in different VLC and BLE states. . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.7 Wireless module average power consumption when it is used to receive data from the smartphone (left) or to send (right) for the four scenarios described below. . . . . . . . . . . . . . . . . . . . . . The same symbols observed with different ISO and white balance camera settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The same 8-CSK symbols sent consecutively and repetitively are perceived differently in the picture. . . . . . . . . . . . . . . . . . . . 114 8.3 The RGB LED without modulation. On the left, the LED is strongly dimmed with the 3 channels ON. On the right, the LED is normally dimmed with only the red and green channels ON. . . . . . . . . . . On the bottom, the red channel input with the regular f csk CSK modulation. On the middle, the CSK modulation is combined with a f pwm PWM and a f pwm /2 PWM on the top, so that dark and light stripes will appear within the CSK symbol period. . . . . . . . . . . . 115 8.5 The 8-CSK modulation symbols combined with a 20 kHz PWM on the green channel only. . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Figure 2 . 1 :Figure 2 . 2 :

 2122 Figure 2.1: On the left, the picture is taken by a global shutter camera. On the right, the camera has a rolling shutter. Source: smartereveryday.com.

Figure 2 . 3 :Figure 2 . 2 .

 2322 Figure 2.3: The time gap between two consecutive frames causes packet loss. The green packets are succesfully received, the orange ones are truncated and the reds are lost between two consecutive frames and so do not appear in any frame.

Raptor

  Code has been proposed to improve the efficiency of the Luby Transform (LT) Code [79] using an inner and outer code as follows: a set of intermediate packets are firstly derived from the original packets so that the intermediate packets can sufficiently reconstruct the original ones. The repair packets are then produced by applying LT encoding. Each is derived by XORing some intermediate packets. The final encoded packets are the combination of the original and repair ones. As for LT Code, the downside of such method is the overhead introduced by the k extra packets and the information added to each one to let the receiver correctly reconstruct the initial message. Also, since CeilingCast relies on the full lighting system, it has the opportunity to leverage multiple LED stripes to perform MIMO communications. The system assigns the n packets to broadcast to each emitter before encoding them using Raptor Codes. Thus the receiver would successfully reconstruct the broadcast message by receiving any of the n + k packets from any emitter. The experimental evaluations show that CeilingCast achieves 0.4 kbit/s with a single LED and can reach 1.35 kbit/s with 3 LEDs at 2.2 m distance. The authors indicate that the communication range is up to 5 m.

  vided a Matlab implementation on a laptop. Their method uses a sliding window followed by a 1-D Fourier transform for preamble and frequency detection. If their work mainly focuses on the communication channel, they also propose to localize devices by simply selecting the nearest landmark with the highest RSSI. Recently, Yang et al. propose ReflexCode [135] to improve the state of the art NLOS VLC system performance by using GSK modulation. Essentially, Reflex-Code system codes information by superposing light emissions from multiple emitters and by smartly converting destructive interferences into collaborative transmissions. The 4-GSK modulation is obtained by superposing different ON-OFF states of three synchronized LED luminaries as follows: a) all three transmitters OFF to generate a dark band for 00 (S0), b) the middle transmitter ON while others OFF for 01 (S1), c) the complement of S1 for 10 (S2), d) all ON to build S3.

  use a Nucleo development board to interface the MCU with more convenience, and so, change without hardware modification the LED type, the General Purpose Input/Output (GPIO) mapping or the firmware implementation. The development board is depicted in Fig. 3.2.

Figure 3 . 1 :

 31 Figure 3.1: On the left, our LED-to-Camera VLC system. On the right, our smart VLC device prototype.

Figure 3 . 2 :

 32 Figure 3.2: The Nucleo STM32L0 development board

Figure 3 . 3 :

 33 Figure 3.3: PHY-SDU format and its duration assuming a 8 KHz clock rate and 20 bits payload.

Figure 3 .

 3 Figure 3.4 shows the duration distribution of the whole decoding chain on the Nexus 5 smartphone. On the left part of the figure, we show that a naive implementation, respecting the state of the art approaches[START_REF] Lee | RollingLight[END_REF], does not cope with real time constraints. However, as the right part of the figure highlights, after modifying the receiver Android application, we can process each frame in real time, by detecting the LED and decoding the signal, on average, in 18ms. The rest of this section describes the steps we followed to achieve this major gain in computation time.

Figure 3 . 4 :

 34 Figure 3.4: Algorithm computation time. State of the art implementation (left) and our implementation (right)

Figure 3 . 5 :

 35 Figure 3.5: Total process duration distribution comparing AsyncTask and Thread

Figure 3 . 6 :Algorithm 1 6 :y < H do 7 : 8 : 9 : c ← y 10 :

 361678910 Figure 3.6: A picture frame containing three ROIs. The smaller ROI on the left will be skipped by the decoding algorithm, as it does not contain any valid PHY-SDU.

Figure 3 . 7 :

 37 Figure 3.7: Comparison of the signal before S3 (left) and after S3 (right).

Fig. 3 .

 3 Fig. 3.8 summarizes the average execution time of the processing thread functions on the Nexus 5 smartphone, with a Java implementation.

Fig. 3 .

 3 Fig.3.8 shows that our algorithm can recover the data information in 18.4 ms on average, in various illumination conditions. Moreover, when we implement the same algorithm in a C shared library, which is then called from our Android

Figure 3 . 8 :

 38 Figure 3.8: Steps duration repartition of the optimized algorithm.

. 9 :Figure 3 . 9 :

 939 Figure 3.9: On the left, the algorithm duration for one to four emitters. On the right, the comparison of the algorithm efficiency (throughput) over different scenes.

Figure 3 . 10 :

 310 Figure 3.10: The throughput as a function of distance, compared with the goodput (left) and for various illumination conditions (right).

Figure 3 . 11 :

 311 Figure 3.11: The throughput as a function of distance, for various OOK symbol rates.

Figure 3 . 12 :

 312 Figure 3.12: The goodput (left) an throughput (right) for different PHY-SDU sizes.

Figure 3 . 13 :

 313 Figure 3.13: The PHY-SDU loss ratio as a function of distance, for different PHY-SDU sizes.

Fig 3. 15 showsFigure 3 . 15 :

 15315 Figure 3.15: The average number of PHY-SDU received per camera frame for several LED models.

Figure 4 . 1 :

 41 Figure 4.1: Frame capture time and inter-frame interval, and their relation with the MMBP parameters.

Figure 4 . 2 :

 42 Figure 4.2: The Gilbert-Elliott model of the LED-to-camera channel.

4 . 3 .

 43 In this figure, we depict a Markov chain with a total number of M + N states. Each of these states represents a packet reception time slot, i.e. the time duration needed in order to receive one PHY-SDU (5.75 ms using the values discussed in Chap. 3). The transition between a state representing a given slot and the state representing the following slot is automatic, i.e. it happens with a probability 1.Practically, the M + N states in Fig.4.3 represent a δ f time interval, and they are divided in two groups: M states corresponding to the camera capture time δ c (S ON states), and N states corresponding to the inter-frame time δ g (S OF F states). A Bernoulli arrival process is associated with each of these M + N states, representing the reception of a packet.

Figure 4 . 3 :

 43 Figure 4.3: The MMBP model of the LED-to-camera channel.

( 4 . 3 )

 43 If we consider the Gilbert-Elliott model, the probability of receiving a packet at least once can be written as p RP s = 1 -p RP 0 , where p RP 0 represents the probability of failing to receive a packet r times in a row, written as: p RP 0 = (P S1 • p e + P S2 ) r = p • p e + q q + p r MMBP Model: If we consider the MMBP model, the probability of failing to receive a packet r times in a row p RP 0 can be written as:

4 . 4 .

 44 This figure shows the success probability of receiving a message of N p = 50 packets of data, as a function of the number of retransmissions r.The very different results between the Gilbert-Elliott model and the experimentation confirms that the stochastic transition assumptions of this model are too unrealistic. On the other hand, MMBP approximates quite well the experimental behavior. This highlights the need for the more complex, but finer grained, MMBP model.

Figure 4 . 4 :

 44 Figure 4.4: Probability to successfully receive N p packets for the RP strategy. Dotted-lines show analytical results for the Gilbert-Elliott and MMBP models, while plain lines represent experimental results.

Fig. 4 .

 4 Fig. 4.5 shows, for the two mechanisms, the probability of integrally receiving N p packets of data as a function of the number of retransmissions r. In this figure, we set M = 5 and N = 3; these values are in line with the packet length,

Figure 4 . 5 :

 45 Figure 4.5: Probability to successfully receive N p packets for the RS (left) and RP (right) strategies as a function of the number of retransmissions r. Dotted-lines show analytical results while plain lines represent experimental results.

Figure 4 . 6 :Figure 4 . 7 :

 4647 Figure 4.6: Comparison between RS and RP. On the left, analytical and experimental results for M = 5 and N = 3. On the right, analytical results when M + N = 7, but the M : N ratio changes. In both cases, N p = 50.

Figure 4 . 8 :

 48 Figure 4.8: ROI as a function of distance. The orange line shows experimental results, while the green line represents analytical results given by Eq. 4.10.

3 . 2

 32 for distances from 0 to 40 cm. Fig.4.8 plots in orange the ROI ratio we observed during our experiments and in green the analytical results computed with the Nexus 5 sensor characteristics: f c = 35, ss = 5.7 and l = 10. This shows that the analytical curve approximates quite well the experimental ROI ratio. However, we notice that the experimental results are better for a distance between 10 and 30 cm, and they become worse than the model at 35 cm. In fact, the light radiance on the camera lens, that our model does not take into account, artificially increases the LED size on the picture when the camera is close to the LED. The difference at larger distance is a consequence of the ambient light which was measured at 650 lux during the experiments, also neglected in Eq. (4.10). This ROI model and the MMBP reception model described in Sec. 4.2 are the basis of the simulator implementation discussed in the following section.

Figure 4 . 9 :

 49 Figure 4.9: The CamComSim software architecture and packages dependency graph.

  configure the data encapsulation, as Fig.3.3 shows. Given these two settings, the PHY-SDU size is computed as P + H + SY N C + P B, where SY N C is the PHY-SDU delimiter symbol, which size is 4 bits, and P B consists of 2 parity bits. This PHY-SDU size, along with d, l, δ f and the modulation frequency f , determines the number of the M time slots in Fig.4.3.Parameter sc lets us choose the transmission strategy among the Strategy interface implementations. We have implemented and considered only the RP strategy, for which the parameters are the size of the message to broadcast, G, the number of consecutive PHY-SDU emissions, r, and the simulation stop condition X.Three possible stop conditions are defined: (1) a limit on the total number of PHY-SDU sent during the simulation, (2) stopping the simulation when all the PHY-SDU are received (R), and (3) one of the two conditions above. Finally, the CLI parameter n r gives the number of simulation runs.

Figure 4 . 10 :

 410 Figure 4.10: The experimental goodput (blue) compared with the simulation goodput (green) as a function of the number of consecutive PHY-SDU emissions. The bars on top are 95% confidence intervals.

Figure 4 . 11 :

 411 Figure 4.11: The experimental goodput (blue) compared with the simulation goodput (green) for different message size (G, bytes).

Fig. 4 .

 4 Fig. 4.10 shows the goodput at 5 cm for different values of PHY-SDU consecutive retransmissions r, with G = 50, P = 19, H = 5. The stop condition X is set to

Figure 4 . 12 :Figure 4 . 13 :DistanceFig. 4 .

 4124134 Figure 4.12: The throughput (red) as a function of the distance, compared with the goodput (green). Dotted-lines show experimental results while plain lines represent simulation results.

. 4 .Fig. 4 . 11 .

 4411 Fig. 4.14 compares the goodput given by CamComSim with the goodput that our testbed achieved for the transfer of a 1 kbyte log file as a function of the number of PHY-SDU retransmissions r. Note that this is equivalent to G = 1000 bytes in Fig. 4.11. The transmission restarts until the message is received. The left side plot shows the results when the LED and the smartphone are 5 cm apart, while the distance is 10 cm on the right side figure.

Figure 4 . 14 :

 414 Figure 4.14: The experimental goodput (blue) compared with the simulation goodput (green) for the use case as a function of the number of consecutive PHY-SDU emission at 5 cm (left) and 10 cm (right).

Figure 5 . 1 :

 51 Figure 5.1: Our bidirectional VLC system.

Figure 5 . 2 :

 52 Figure 5.2: On the left, the LED discharge tension when it is lighted by ambient light only. On the right, the same LED lighted with the smartphone flashlight

Figure 5 . 3 :

 53 Figure 5.3: From the top left to the bottom, the LED is wired in transmitter, charging and receiver operating mode respectively.

  Appendix A show the two methods we can use to switch the flashlight ON or OFF using the Android Software Development Kit (SDK). The first one in List. A.1 with an API version lower than 23 and the second in List. A.2

Figure 5 . 4 :

 54 Figure 5.4: Symbol data mapping and diagram.

Figure 5 . 5 :

 55 Figure 5.5: On the top, the SR symbol. On the bottom, a frame that includes a SR symbol sent to initiate the synchronization process.

Figure 5 . 6 :

 56 Figure 5.6: Receiver synchronization process.

Figure 5 . 7 :

 57 Figure 5.7: Distribution of effective pulse duration for different configured pulse duration values.

Fig. 5 .

 5 Fig. 5.7 shows the distribution of the effective pulse duration for several configured values, from 5 ms to 25 ms.

Figure 5 . 8 :

 58 Figure 5.8: SNR when varying the flashlight distance (green curve) and the smartphone-LED angle (orange curve). The red line represents the minimum required SNR for correct decoding.

5. 3 Flashlight-to LED Usages 5 . 3 . 1

 3531 Flashlight-to-LED for communicationThe experimental evaluation discussed in Sec 5.2 shows that the Flashlight-to-LED communication channel achieves 30 bit/s of throughput, at a maximum communication range of 110 cm.

Figure 6 . 1 :

 61 Figure 6.1: Packet sent without coding (middle) and chunk format generated by PRLC (bottom) encapsulated into a PHY-SDU (top).

Figure 6 . 2 :

 62 Figure 6.2: The chunk redundancy introduced by duplicated chunks vs the seed length and N . Goodput with G=100B for some PHY-SDU error probability vs the seed length (left).

Figure 6 . 3 :

 63 Figure 6.3: Throughput compared with the goodput vs the distance, with and without coding for G=100B (right).

Figure 6 . 4 :

 64 Figure 6.4: Computation time on a MCU to build 1 chunk (left). Computation time on the Nexus 5 and 6P to process 1 chunk and perform decoding (right).

the 8

 8 figured at 50 and 100 MHz. Both MCUs are often used in consumer IoT. For the receiver, we use an LG Nexus 5 with a Snapdragon 800 4-Cores 2,26 GHz CPU and the newer Huawei Nexus 6P with a Snapdragon 810 8-Cores 2.0 GHz CPU. The LG Nexus 5 runs Android Marshmallow version number 6.0.1 while the Nexus 6P runs Android Nougat version number 7.1.2. Both operating system are unmodified.

Figure 6 . 5 :

 65 Figure 6.5: Goodput using different implementations for G=100B and G=400B.

Figure 7 . 1 :

 71 Figure 7.1: Our power measurement testbed. The smart device is directly powered by the Keysight Power Analyzer.

Figure 7 . 2 :

 72 Figure 7.2: The BLE module leakage current in slave mode (left) or master mode (right). In master mode, the BLE device is scanning for peripherals.

Figure 7 . 3 :

 73 Figure 7.3: The VLC module leakage current in TX mode and RX mode.

Figure 7 . 4 :

 74 Figure 7.4: The communication module power consumption for BLE and VLC.

Figure 7 . 5 :

 75 Figure 7.5: The leakage current on the Nexus 5 using BLE (blue) or VLC (orange) for communication relative to the baseline current.

Figure 7 . 6 :

 76 Figure 7.6: Nexus 5 power consumption (left) and battery drain (right) in different VLC and BLE states.

Figure 7 . 7 :

 77 Figure 7.7: Wireless module average power consumption when it is used to receive data from the smartphone (left) or to send (right) for the four scenarios described below.

Figure 8 . 1 :

 81 Figure 8.1: The same symbols observed with different ISO and white balance camera settings.

Figure 8 . 2 :

 82 Figure 8.2: The same 8-CSK symbols sent consecutively and repetitively are perceived differently in the picture.

Figure 8 . 3 :

 83 Figure 8.3: The RGB LED without modulation. On the left, the LED is strongly dimmed with the 3 channels ON. On the right, the LED is normally dimmed with only the red and green channels ON.

  Fig 8.1 shows the color rendered when changing the ISO setting of the camera.Intra-frame color diversity: this phenomenon is shown in Fig.8.2, where the symbols are completely disparate across the regions considered in the picture.

Figure 8 . 5 : 4 .

 854 Figure 8.5: The 8-CSK modulation symbols combined with a 20 kHz PWM on the green channel only.

  FOLIO ADMINISTRATIF THÈSE DE L'UNIVERSITÉ DE LYON OPÉRÉE AU SEIN DE L'INSA LYON Nom : DUQUE Date de soutenance : 09/10/2018 Prénoms : Alexis Titre : BIDIRECTIONAL VISIBLE LIGHT COMMUNICATIONS FOR THE INTERNET OF THINGS Nature : DOCTORAT Numéro d'ordre : 2018LYSEI072 Ecole doctorale : InfoMaths Spécialité : Informatique RÉSUMÉ : Dans cette thèse, nous concevons et étudions un système de communication bidirectionnel par lumière visible (VLC) entre une diode électroluminescente (DEL) de couleur, intégrée à un objet connecté, et un smartphone. Le dispositif est ainsi capable d'envoyer et de recevoir des informations à travers sa DEL, tandis que le smartphone utilise sa caméra pour recevoir des données et son flash pour envoyer des informations. Nous mettons en oeuvre et évaluons expérimentalement ce système VLC DEL-à-camera conçu spécifiquement pour les DELs de couleur à faible puissance. En nous appuyant sur les résultats d'une vaste étude expérimentale, nous modélisons, pour la première fois dans la littérature, le canal de communication DEL-à-caméra. Nous proposons alors un modèle de processus de Bernoulli modulé par une chaîne de Markov, qui nous permet d'étudier facilement l'efficacité de différentes stratégies de retransmission des messages. Nous exploitons ce modèle afin de concevoir un simulateur pour l'évaluation des performances des communications DEL-à-caméra. Afin d'obtenir un système de communication bidirectionnel, nous étudions ensuite les communications de type flash-vers-DEL entre un smartphone non-modifié et une petite DEL de couleur. Les performances, bien que limitées, sont suffisantes pour établir une voie retour qui permet de mettre en oeuvre des mécanismes de fiabilisation. Nous proposons alors un mécanisme de codage linéaire pseudo-aléatoire, spécialement adapté aux conditions et contraintes du système DEL-à-caméra en ligne de visée directe. Notre évaluation expérimentale souligne que ce type d'approche augmente le rendement jusqu'à deux fois par rapport aux stratégies de retransmission classiques. Enfin, la plupart des objets que nous adressons ont des contraintes énergétiques importantes. Par conséquent, nous comparons la consommation d'énergie de notre système avec celle d'un module Bluetooth Low Energy avec une activité similaire. Nos résultats montrent que notre système réduit la consommation d'énergie dans le cadre d'un profil d'utilisation classique. MOTS-CLÉS : Communication par Lumière Visible, Internet des Objets, Smartphone, Optical Camera Communication, Communications Sans-Fil, Codage Linéaire Aléatoire Laboratoire (s) de recherche : CITI Directeur de thèse: Hervé RIVANO Président de jury : Luc CHASSAGNE Composition du jury :

  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 System description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Smart VLC device design . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Receiver design . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction 1.1 Visible Light Communication . . . . . . . . . . . . . . . . . . . . . . . 1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 State of the Art 2.1 Photodiode as VLC Receiver . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Ceiling LED-to-Photodiode communication . . . . . . . . . . . 2.1.2 Low Power LED to Photodiode communication . . . . . . . . 2.1.3 Passive Lights to Photodiode communication . . . . . . . . . 2.2 LED as VLC receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Screen-to-Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 LED-to-camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Line of Sight Communications . . . . . . . . . . . . . . . . . . 2.4.2 Non Line of Sight Communications . . . . . . . . . . . . . . . 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Design and Evaluation of a LED-to-Camera Communication System 3.1 3.3 Enabling Real Time Computation . . . . . . . . . . . . . . . . . . . . . 3.3.1 Algorithm presentation . . . . . . . . . . . . . . . . . . . . . .

the Flashlight of Off-the-Shelf Android Smart- phones List of figures 2

  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 SeedLight design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Random Linear Coding . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Compressing the coding vector . . . . . . . . . . . . . . . . . 6.4 SeedLight evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Seed and Generation size . . . . . . . . . . . . . . . . . . . . . 6.4.2 Communication Performance . . . . . . . . . . . . . . . . . . 6.5 Implementation discussion . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 PRLC implementation on IoT devices . . . . . . . . . . . . . . .1 On the left, the picture is taken by a global shutter camera. On the right, the camera has a rolling shutter. Source: smarterevery-

	Table of contents	xiii
	6 SeedLight
	6.1 References
	Appendix A Controlling

6.5.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Insight on Energy Consumption 7.1 Wireless module battery drain . . . . . . . . . . . . . . . . . . . . . . 7.2 Smartphone battery drain . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Use cases energy balance . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Conclusion and Perspectives 8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Industrial Ouputs . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Short Term Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 RGB LEDs as emitter . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 Multiple LEDs to Smartphone[s] . . . . . . . . . . . . . . . . . 8.3 Open Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Coexistence of VLC and RF on IoT Devices . . . . . . . . . . . 8.3.2 Adaptative Protocols and Mechanisms for Smartphone to IoT Network Communication . . . . . . . . . . . . . . . . . . . day.com. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Stripe formation and LED state. The width of each strip corresponds to the duration of the LED state (ON or OFF) . . . . . . . . . 2.3 The time gap between two consecutive frames causes packet loss.

Table 1 .

 1 1: VLC systems classification and contributions presented in this thesis.

	1.1 Visible Light Communication

Table 2 .

 2

2: LED-to-camera systems summary

Table 2 .

 2 State of the ArtAll these works are summarized in Tab. 2.3, that is a filled version of Tab. 1.1 introduced in the previous chapter. The table brings out that past VLC research mainly focused on lighting power LED-to-photodiode communication. Also, it highlights the lack of studies related, first, to small color LED-to-camera communication, and secondly, to flashlight-to-small color LED communication. These fields, that are shown in green in Tab. 2.3, are thus addressed in this thesis.

	Camera	[51]			[22, 68, 48, 132, 103, 66, 140, 141]	[56, 98, 29, 36, 134, 142, 143, 98]			[71, 58, 71, 30, 95, 49, 139]	[141, 140]
	Small Color LED	[21]				[41, 136]	[41, 26, 42, 108, 124]	[122, 107, 136, 65]	∅		∅
	PD	[40, 38]	[138, 24, 85, 116, 82, 54]	[55, 91, 100, 104, 96, 45, 131, 127, 5]	[17, 127, 64, 8, 27, 27, 15]	[35, 34, 47, 97, 60, 74, 110, 19, 53]	[120, 137, 128, 117, 109, 70, 7, 73]	[41, 124, 122, 136]	∅	[126, 123, 119]
		Flashlight			Lighting	Power LED	Small	Color LED	Screen	Passive	Light

2.1, and continued showing in Section 2.2 that LEDs can also be used as a receiver. Then, we dedicate the last two sections to past efforts on leveraging cameras as VLC receiver. 3: VLC systems classification Chapter 3

Table 3 . 1 :

 31 Characteristics of different LEDs we used

	#	Color	AOV Intensity	Ref	Size	DC
	1 R (630nm) 30°5.1cd	C503B-RCN-CW0Z0AA1 5mm 20mA
	2 G (535nm) 30°34cd	C503B-GAN-CB0F0791 5mm 20mA
	3 B (480nm) 30°4.1cd	C503B-BCN-CV0Z0461 5mm 20mA
	4 G (584nm) 25°0.64cd	TLLG440	3mm 7mA
	5 G (530nm) 115°1.6cd	ASMB-MTB1-0A3A2	3mm 25mA
	6 R (640nm) 60°1cd	L-154A4SUREQBFZGEW 5mm 30mA
	7 G (520nm) 60°1.7cd	L-154A4SUREQBFZGEW 5mm 30mA
	8 B (461nm) 60°0.5cd	L-154A4SUREQBFZGEW 5mm 30mA

  .1.1, this model can be applied to all LED-to-camera communication systems, not only to the particular case of ours. The proposed model is not only generic, but also

	very accurate, as demonstrated by its validation with extensive experimental re-
	sults in Sec. 4.1.4. As an example, we use the analytical model to compare two
	simple redundancy mechanisms, required to cope with the inherent losses of
	LED-to-camera communication and described in Sec. 4.1.2 and Sec. 4.1.3.

Table 4 .

 4 [START_REF]Metal | Apple Developer Documentation[END_REF] shows the parameters we use in this work and expose through CamComSim CLI. As we discuss in Sec.3.5,

	Param. Description

the performance of the LED-to-camera communication is significantly affected by the distance d, the IFG noted δ g in Fig.

4

.3, and the LED size l.

Table 4 .

 4

1: Simulator parameters.

  at runtime. At each clock tick, c is incremented, a TX event is created and

		1.8
	Goodput (kbit/s)	0.4 0.6 0.8 1 1.2 1.6 1.4		Simulation goodput Experimental goodput
		0.2
		0	RP(1)	RP(2) Retransmission number RP(3) RP(5)	RP(10)
	processed as follow: (1) the next PHY-SDU in the transmission strategy queue is
	associated with this event; (2) considering p e , f , P , H, c, the channel response
	function gives the event result. The result is one among reception success, re-
	ception with errors or loss during IFG; (3) this result is stored in a list to further
	determine if all the PHY-SDU that form the message are received.

  3.2. We set the emitter symbol rate to 8 KHz and place it in standard indoor illumination conditions, near a window and illuminated with neon lights. The illuminance has been measured with a luxmeter, around 650 lux. The PHY-SDU size is 24 bits and is build as depicted in Fig.6.1, with a 8 bits seed or a 8 bits sequence number. The emitter broadcasts continuously a 100 B message, which is transformed with SeedLight in a set of chunks, built with a 8 bits seed or, without SeedLight, in 50 different packets containing a 8 bits sequence number. For the case with Seed-

Table 6 .

 6 1: Several multiplication implementations in GF(256). The operations are abbreviated LK for table lookup, BR for branch and MOD for modulus. γ is the GF size.

		1 LK	2 γ • 2 γ
	(2) Log. LT 3 LK + 2 BR + 1 MOD + 1 ADD 2 • 2 γ
	(3) No LT	γ . (2 XOR + 2 SHIFT + 1 AND) 0

Table 7 .

 7 2: Summary of the use cases scenarios. transmitter (i.e. scenarios 2 and 4) on the right. Note that, for BLE, both plots

		Description	Data Size	Direction
	Scenario 1	firmware OTA update	2 kB	smartphone to object
	Scenario 2	log file transfer	2 kB	object to smartphone
	Scenario 3 configuration command	10 B	smartphone to object
	Scenario 4	sensor value reading	10 B	object to smartphone

  This research work lead to a patent application filed by Rtone and INSA de Lyon with the Institut National de la Propriété Industrielle (INPI) in February 2017 and with the European Patent Office (EPO) in January 2018. The patent application has been approved and will be delivered soon by the French patent office. The EPO is currently processing and reviewing our deposit. Furthermore, LightIoT is exploited commercially by Rtone since December 2017 under the registered trademark Kiwink®. Several companies have shown a high interest in the technology and are now developing proof of concept products using Kiwink®.

Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2018LYSEI072/these.pdf © [A. Duque], [2018], INSA Lyon, tous droits réservés

The physical layer service data unit is generally known as a frame. However, in order to avoid any confusions with the picture frames, we denote it as PHY-SDU throughout the paper.Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2018LYSEI072/these.pdf © [A. Duque], [2018], INSA Lyon, tous droits réservés

Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2018LYSEI072/these.pdf © [A. Duque], [2018], INSA Lyon, tous droits réservés Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2018LYSEI072/these.pdf © [A. Duque], [2018], INSA Lyon, tous droits réservés

Acknowledgements

Appendix A

Controlling the Flashlight of Off-the-Shelf Android Smartphones

Controlling the smartphone flashlight with the Android SDK below 23