Title Page

Next

[[2021112611]]

The Internet of Things (IoT) evolved from its theoretical possibility to connect anything and everything to an ever-increasing market of goods and services. Its underlying technologies diversified and IoT now encompasses various communication technologies ranging from short-range technologies as Bluetooth, medium-range technologies such as Zigbee and long-range technologies such as Long Range Wide Area Network.

IoT systems are usually built around closed, siloed infrastructures. Developing interoperability between these closed silos is crucial for IoT use-cases such as Smart Cities. Working on this subject at the application level is a first step that directly evolved from current practice regarding data collection and analysis in the context of the development of Big Data. However, building bridges at the network level would enable easier interconnection between infrastructures and facilitate seamless transitions between IoT technologies to improve coverage at low cost.

The Domain Name System (DNS) basically developed to translate human-friendly computer host-names on a network into their corresponding IP addresses is a known interoperability facilitator on the Internet. It is one of the oldest systems deployed on the Internet and was developed to support the Internet infrastructure's growth at the end of the 80s. Despite its old age, it remains a core service on the Internet and many changes from its initial specifications are still in progress, as proven by the increasing number of new suggestions to modify its standard.

DNS relies on simple principles, but its evolution since its first developments allowed to build complex systems using its many configuration possibilities. This thesis investigates possible improvements to IoT services and infrastructures. Our key problem can be formulated as follow: Can the DNS and its infrastructure serve as a good baseline to support IoT evolution as it accompanied the evolution of the Internet?

We address this question with three approaches. We begin by experimenting with a federated roaming model IoT networks exploiting the strengths of the DNS infrastructure and its security extensions to improve interoperability, end-to-end security and optimize back-end communications. Its goal is to propose seamless transitions between networks based on information stored on the DNS infrastructure. We explore the issues behind DNS and application response times, and how to limit its impact on constrained exchanges between end devices and radio gateways studying DNS prefetching scenarios in a city mobility context. Our second subject of interest consists of studying how DNS can be used to develop availability, interoperability and scalability in compression protocols for IoT. Furthermore, we experimented around compression paradigms and traffic minimization by implementing machine learning algorithms onto sensors and monitoring important system parameters, particularly transmission performance and energy efficiency.

Next section

The next section is the French Résumé available at [[2021112612]]

L'Internet des Objets (IdO) a évolué depuis cette possibilité théorique de connecter tous les appareils à un réel marché de biens et de services en constante expansion. Les technologies sous-jacentes ont évolué et l'IdO repose aujourd'hui sur de nombreuses technologies de communication différentes: Des technologies à courte portée comme Bluetooth, moyenne portée comme Zigbee ou longue portée comme la technologie LoRa (Long-Range).

Les systèmes de l'IdO sont habituellement construits autour d'infrastructures fermées basées sur des systèmes en silo. Créer de l'interopérabilité entre ces silos fermés est un enjeu pour certains cas d'usages cruciaux dans le déploiement des technologies de l'IdO comme les villes intelligentes. Développer la problématique au niveau applicatif est une première étape directement inspirée des pratiques courantes en matière de collecte et d'analyse de données dans le cadre du développement des technologies de traitement de données massives. Cependant, construire des ponts au niveau réseau permettrait de faciliter l'interconnexion entre infrastructures et faciliterait la transition fluide entre technologies de l'IdO afin d'améliorer à bas coût la couverture réseau.

Le Système de Nom de Domaine (Domain Name System, DNS), initialement développé pour traduire les noms, lisibles et compréhensibles par les utilisateurs en adresses IP, utilisées par les appareils connectés, est reconnu comme un facilitateur sur les question d'interopérabilité sur Internet. C'est l'un des systèmes les plus anciens déployés sur Internet, développé à la fin des années 1980 pour supporter la croissance de l'infrastructures Internet. Bien qu'ayant beaucoup évolué ces dernières années, en témoignent les nombreuses propositions de modifications au standard publié à son sujet, le DNS reste aujourd'hui l'une des infrastructures les plus centrales du réseau Internet.

Le DNS repose sur des principes simples, mais son évolution depuis ses premiers développements ont permis de construire des systèmes complexes grâce à ses nombreuses possibilités de configuration. Dans le cadre cette thèse, qui étudie les possibles améliorations aux services et infrastructures de l'IdO, nous étudions la problématique suivante : Le DNS et son infrastructure peuvent-ils servir de support efficace à l'évolution de l'IdO de la même manière qu'il a accompagné l'évolution d'Internet ?

Dans cette optique, nous étudions de possibles améliorations de systèmes de l'IdO sous trois angles. Nous testons tout d'abord un modèle d'itinérance pour réseaux de l'Internet des Objets au travers de la construction d'une fédération reposant sur l'infrastructure du DNS et ses extensions pour en assurer l'interopérabilité, la sécurité de bout-en-bout et optimiser les communications entre infrastructures. Son objectif est de proposer des transitions fluides entre réseaux sur base d'informations stockées à l'aide de l'infrastructure DNS. Nous explorons également les problématiques introduites par le DNS, notamment en termes de latence et d'influence sur les temps de réponse des applications, et comment en limiter l'impact sur les échanges, déjà grandement contraints, entre objet connecté et passerelle radio. Pour cela nous étudions les conséquences de l'utilisation de requêtes DNS anticipées dans un contexte de mobilité en milieu urbain. Nous étudions ensuite la façon dont le Système de Nom de Domaine peut renforcer l'interopérabilité, la disponibilité de ressources et le passage à l'échelle de systèmes de compression de paquets de l'IdO. Enfin, nous explorons la question de la minimisation de trafic en implantant des algorithmes d'apprentissage sur des capteurs et en mesurant les paramètres du système final, en particulier en terme de performances de transmissions et d'efficacité énergétique.

Next section

The next section is the Acknowledgements available at [[2021112613]]

Looking back on this adventure, now comes the time to thank all those who believed in me and accompanied me for these three years.

First of all, I would like to express my sincere gratitude to my director Michel Marot, who followed this work as closely as possible. I was fortunate to have the opportunity to work with him. I learned a lot from our discussions; I won't forget his advice for the years to come.

I also thank Sandoche Balakrichenan, who supervised my day-to-day work within Afnic, pushed me to move forward with my work, challenged me about the propositions I made and helped improve them with his knowledgeable comments.

My thanks also go to Benoit Ampeau, our boss at Afnic, who accompanied the execution of our projects, offered his expertise when necessary and contributed to the valorization of our experiments and results. And I thank the Afnic, and its director Pierre Bonis, for financing my work for these three years.

I thank André-Luc Beylot, who agreed to preside my mini-defence and shoulder this manuscript's review. In both these instances, his advice and critics helped me improve. I also thank Laurent Toutain, whose work was a real inspiration for this thesis and who also accepted the task to review it.

My thanks also go to Philippe Cola and Ahmed Kamal, who agreed to participate to my defence as jury. And to Monique Becker, who, on top of her participation in the jury, put her experience to use by reviewing my work.

My next thanks are addressed to all my colleagues from Afnic: Pierre-Aymeric Massé, for his advice at the beginning of this adventure, Hélène Boudon, Alexandre Pion and Gaël Berthaud-Müller for our discussions, not always related to work but always insightful, Michal Toma, Samia Mtimet, Lotfi Benyelles and Lucien Castex for their feedbacks, Regis Massé for following our work and offering to review and comment it when necessary and Stéphane Bortzmeyer for his insight and well of knowledge regarding DNS and all IETF-related topics.

I also thank all my colleagues from Telecom SudParis, namely Aicha Dridi and Mohamed Laroui, for our joint work in our shared office, Hossam Afifi for his advice, his insight and his answers when working together on machine learning, back when I was a complete novice on the subject, Vincent Gauthier for his insight and advice that taught me a lot about possible solutions to the issues I encountered, Hassine Moungla for his advice on how to valorize our work. I thank Bruno Defudes, who was tasked to review my first year's work and check that everything was doing fine and Hind Castel, who accompanied André-Luc in my mini-defence. My thanks to Véronique Guy, Ydalia Garcia, Sandra Gchweinder and Valérie Mattheus, each for accompanying my work for these years, be it assisting with conference registration or for accompanying my teachings. Speaking about teachings, I would also like to thank Olivier Paul for accepting me as a part of his networking course's teachers. I also thank Cedric Adjih and Alexandre Abadie for their insight when discovering IoT technologies.

The remaining people to thank are, of course, my friends: Adrien, Paul, Victor, Erwan, Pierre, Fabien, Lauriane, Mockie and Mad, to acknowledge a few, for so much but I'll only mention our games periods, behind a computer screen or around a table. A thought to all my former colleagues, schoolmates and teachers, with special thanks to Dominique Chiaroni for introducing me to research through my internship with him at Nokia Bell Labs and to MiNET's members, past, present or future, who are doing formidable work and with whom I discovered networking.

Last but not least, I would like to thank my family: my grandparents, parents and brothers for supporting me throughout all my life or theirs and Clara, who supported me during our, already, four years together.

This website is built using a tool called Cosma made by GraphLab's team. Cosma is a tool to visualize graphically notes or documents, and the links and relations between those documents

This work was partly financed by the French National Research Agency through the CIFRE program [2018/0668].

This work benefited from the support of the Energy4Climate Interdisciplinary Center (E4C) of IP Paris and Ecole des Ponts ParisTech. It was supported by 3rd Programme d'Investissements d'Avenir [ANR-18-EUR-0006-02].

Next section

The next section is the Abbreviations table available at [[2021112614]]

6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks
AA Authentication and Authorization
AAA Authentication, Authorization and Accounting
API Application Programming Interface
AS Application Server
CA Certificate Authority
CoAP Constrained Application Protocol
DANE DNS Authentication of Named Entities
DNS Domain Name System/ Domain Name Service
DNS-SD DNS-Based Service Discovery (RFC 6763)
DNSSEC DNS Security Extensions
Do53 DNS over UDP (port 53)
DoH DNS over HTTPS
DoQ DNS over QUIC
DoT DNS over TLS
EAP Extensible Authentication Protocol
ED End Device
EPC Electronic Product Code
EUI Extended Unique Identifier (aka MAC address)
fNS forwarding Network Server
HN Home Network
HTTP(S) (Secured) HyperText Transfer Protocol
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force
IoT Internet of Things
ISO International Organization for Standardization
JR Join Request
JS Join Server
LoRa Long-Range
LoRaWAN Long Range Wide Area Network
LPWAN Low Power Wide Area Network
LSTM Long Short Term Memory
LTE-M Long Term Evolution - cat M1
M2M Machine-to-Machine
MAPE Mean Absolute Percentage Error
MQTT Message Queuing Telemetry Transport
NB-IoT Narrow-Band IoT
NS Network Server
ONS Object Naming Service
OS Operating System
OTAA Over The Air Activation
OUI Organizational Unique Identifier
PSK Pre-Shared Key
RDF Resource Description Framework
RFC Request For Comments
RFID Radio-Frequency IDentification
RG Radio Gateway
RNN Recurrent Neural Network
RR DNS Resource Record
RTT Round Trip Time
SCHC Generic Framework for Static Context Header Compression and Fragmentation
SDO Standards Developing Organization
SF Spreading Factor
sNS serving Network Server
SPARQL SPARQL Protocol and RDF Query Language
SQL Structured Query Language
TCP Transmission Control Protocol
TFLite TensorFlow Lite
TLS Transport Layer Security
U/D-RTT Uplink/Downlink Round Trip Time
UDDI Universal Description Discovery and Integration
UDID Unique Device IDentifier
UDP User Datagram Protocol
URI Uniform Resource Identifier
VN Visited Network
WBA Wireless Broadband Alliance
WSN Wireless Sensor Network\

Next section

The next section is Chapter 1 - Introduction available at [[202111262]]

Introduction

From the early development of the Internet, identifying machines inside the network has been a necessity. One of the first systems to identify and design machines on the network was a single file (called the host.txt file) shared across the network, which contained all the identifier/name tuples. As the number of machines grew, the identification system moved away from this single shared file to the newly developed Domain Name System (DNS).

The DNS is a hierarchical system that allows users to generate names for their devices on the network. DNS is often presented as the phone book for the Internet, allowing users to remember domains, URLs and email addresses instead of the corresponding IP addresses. With its roots spread in various locations, the DNS tree proved to be a resilient distributed system, easy to access from anywhere on the planet and support interoperability and services discovery on the network.

The DNS is a massively deployed and scalable system supporting worldwide communications on the Internet. Its deployment was a valuable tool to accompany the increase in the number of machines on the network. Additionally, the ease of use and registration of domain names helped create new markets on the Internet, one of which was the popularization of Web technologies. The system has many uses and is regularly improved by continuous development and standardization efforts.

The DNS is sometimes exploited to develop new uses such as Apple's Hello, proposed for standardization as DNS Service Discovery (DNS-SD). This sort of hacking to the DNS principal goal, exploiting its main characteristics (interoperability, global repartition) to create new uses of the DNS paradigms and architecture, is precisely the kind of possible uses we aim to develop in this thesis.

This thesis aims to study and develop such transverse uses of DNS regarding the Internet of Things (IoT) and its infrastructure. We hypothesize that the DNS might prove a useful tool as it would permit developing new IoT uses without specific overcost; that the DNS might improve solutions linked to IoT and help build a Web of Things through registries containing devices information. Building such a system should help IoT evolve the same way as the Internet, building interoperable systems and networks backed by cloud servers sharing actions and data. Moreover, reusing existing technology such as the DNS should prove an efficient way to accompany IoT integration toward the rest of the Internet.

This thesis focuses on wireless communication in Wide Area Networks.

Most IoT, among those Low Power Wide Area Networks (LPWANs), systems are now built as incompatible isolated data silos with each technology transmitting over its waves, using its infrastructure and centralizing data in data warehouses for exploitation. Nowadays, around 99% of these Things are not connected to the Internet [@iot_internet_access]. Using the DNS to break data and communication silos would allow infrastructures and devices to communicate freely and build interoperable networks between IoT technologies.

Another key similarity between the Internet and the Internet of Things comes from the similarity in their problems. IoT is riddled with scalability, interoperability, mobility and roaming, transmission efficiency, availability, reliability and other security issues such as privacy. The DNS contributes to solving many of these issues on the Internet, hence our interrogation on possible improvements to IoT systems backed by the DNS infrastructure.

This thesis studies IoT systems regarding the following key aspects: Naming, Roaming, Header Compression and Payload Compression. Though security aspects will be detailed in various part of the thesis, security weaknesses of IoT End Devices (EDs) is outside the scope of this thesis.

We focused our studies on LPWANs; LPWANs are constrained networks built, in general, as star typologies supporting a massive quantity of EDs around a single antenna. Among these LPWAN, our work focuses on Long-Range Wide Area Network (LoRaWAN) as the network is open and easy to access, provides interesting constraints but necessitate no additional cost. It is easy to build LoRaWAN networks and participate in the evolution of the specifications.

Next section

The next section is Research issues available at [[2021112621]]

Research issues

IoT systems are usually built around closed, siloed infrastructures. Interconnecting such silos at the network level is not an easy task, and, as LPWANs are usually used to gather data from sensors, it is usually more straightforward for a user to build Application Programming Interface (API) for each application based on its needs than to break the network silos.

Breaking the silos is a key subject to opening the IoT Infrastructures and bringing the IoT work to the global Internet. Breaking them at the applicative level is a first step that directly evolves from current practice regarding data collection and analysis in the context of the development of Big Data. However, breaking the silos on a network level would permit easier interconnection between infrastructures and help to build seamless transitions between IoT technologies to improve coverage at low cost.

DNS is a known candidate to break such a silo. DNS relies on simple principles but its evolutions since its first development allows us to build complex systems using its many configuration possibilities. Possible uses of DNS to develop IoT systems are not extensively studied for the following reasons:

• Most IoT research studies perceive IoT as a separate network from the Internet. Hence existing Internet protocols are not a research focus for IoT developments.

• DNS is usually developed in Standards Developing Organization (SDO) and DNS extensions are seen as operational issues (academic work on DNS is often performances or security issues/solutions);

• DNS which has been conceived for the Internet is considered not to be appropriate for constrained IoT requirements.

DNS is a naming service wherein the basic use of DNS is to map the identifier to its specific service over heterogeneous applications/services in the decentralized Internet. Since the IoT systems are mostly siloed and centralized, the usage of DNS as a naming service is still not well studied. Based on these observations, studying DNS through academic work as a possible tool to break IoT silos and support IoT infrastructures seems an interesting subject. Considering our third requirement described above, our goal is not to embark DNS protocols onto sensors but instead use DNS on the infrastructure side to support IoT improvements. Proposing such improvements is our first goal.

The IoT research community would also benefit from additional experimental work with IoT systems to verify the experimental feasibility of its solutions. Thus our second goal is to run experiments to test hypothesis for IoT based on DNS. This experimental approach introduces additional constraints such as working with reference implementations of the solutions, generating actual IoT traffic for measurements and analysis, respecting airtime constraints or device lifecycle.

Next section

The next section is Research Motivation available at [[2021112622]]

Motivation

IoT Roaming

Roaming requires an interconnection agreement between network operators. Interconnection in IoT becomes possible by establishing a direct 'One-to-One' interconnection or building an interconnection 'Hub' for operators. Establishing an interconnection agreement with a single hub makes it possible to exchange traffic with the other operators connected to that hub. Both the hub and the One-to-One interconnection models evolve as independent Silos wherein the device in the coverage area of a Visited Network (VN) can connect to its service only if there is a prior interconnection agreement between its Home Network (HN) and the VN or between the HN and the interconnection hub.

The interconnection agreement serves as a basis for mutual authentication and authorization between the operators. In the 'One-to-One' interconnection model, bootstrapping trust is a key security concern. The ED needs to be cryptographically authenticated by the VN based on credentials such as its identifier and a Pre-Shared Key (PSK). Cryptography-based authentication usually relies on one or more trust anchors [@Symington_Polk_Souppaya_2020]. In the proprietary silo scenarios, the trust anchor information may be preset on the ED or established out of band.

Also, interconnection agreements define how operators should communicate between themselves, including setting up mutual authentication between backend elements to secure backend exchanges on the network. In the 'Hub' scenario, the operators are asked to ultimately trust the centralized hub, whereas, in a 'One-to-One' model, the agreement usually defines the specific backend authentication and authorization method to be used between the operators.

The goal of the first part of this thesis is to address these issues by proposing an architecture, IoTRoam, federating different organizations to allow flexible, mutual authentication and authorization between any backend element in a roaming situation, without a direct and explicit roaming agreement (e.g. for the LoRaWAN case, interconnection of Network, Application and Join Servers between operators). The agreement is implicitly given when the organization joins the IoTRoam federation.

Moreover, any architecture proposing solutions to the technological barriers mentioned earlier should consider the constrained characteristics of IoT environments. LoRaWAN is one of the most constrained IoT networks, having heavy constraints on payload size and latency. Any roaming approach for LoRaWAN is expected to obtain satisfying results with other IoT networks. LoRaWAN mainly consists of various siloed infrastructures deployed by small operators with no prior agreements and common configuration between them. Furtherly, LoRaWAN, as a single connectivity solution among the LPWANs, is a communication silo as communicating between a LoRaWAN ED and a SigFox ED needs specific backend development and usually consists of exchanging data through a broker. We can even say that LoRaWAN is a single connectivity solution among all IoT instead of LPWANs and that communicating between a LoRaWAN ED and a WiFi ED requires specific interfaces or connectivity between backend through a data broker. Thus we designed and experimented with our proposed method as a LoRaWAN interconnection architecture as a benchmark.

Our approach to building our roaming architecture was to use the combination of the DNS infrastructure and a PKI to build a secure open roaming infrastructure accessible to public and private LoRaWAN operators. The possibility to set up private networks for free is a competitive advantage of LoRaWAN. We designed, built and deployed a proof of concept architecture to test the Roaming capabilities offered by the ChirpStack solution and test roaming between private and public LoRaWAN. We also validated our infrastructure by testing LoRaWAN connectivity for EDs in a roaming context by studying various onboarding scenarios, measuring onboarding time and communication delays.

Complementary, we study roaming data prefetching in a multi-tenant scenario through simulation based on device mobility at the scale of a megapolis, Rome. This permits us to experiment on predicting movements to increase prefetching efficiency. We simulate an antenna placement and design DNS caching and prefetching scenarios based on vehicle movement traces. Antennas activation and DNS queries handling is studied to understand differences between handling data from querying the DNS when needed or prefetching information in a localized cache to reduce on-the-fly latency when the information is actually necessary.

Combining an ML predictor and a prefetching mechanism would reduce eventual latency introduced by the DNS while soliciting a limited amoun of antennas within the movement perimeter. Exploiting this solution, usually used by web browsers to reduce latency, is an interesting topic to address in a different scenario with such a different use case.

Header Compression

Compression is a well-studied subject, be it when compressing images or files. However, compressing communications is still an evolving aspect of the compression research. Let us first consider header compression, the case of payload compression being addressed later. One such compression technology is Robust Header Compression (ROHC), which compress data based on redundancy between packets in a given flow. Another is SCHC: Generic Framework for Static Context Header Compression and Fragmentation [@rfc8724]. SCHC is a recent standard developed by the Internet Engineering Task Force (IETF) to compress, decompress, fragment and reassemble packets transmitted over LPWANs.

Compressing data using SCHC relies on realizing a pattern matching on the packet header before transmitting it over a constrained network, from the ED to its backend or from the Radio Gateway (RG) to the ED. In order to compress the data sent and received between the ED and the backend, SCHC uses a predefined group of rules called Context, which is deployed on both the ED and on the backend.

For every Context, there could be a single or multiple rules. When sending data from the ED to its RG, the SCHC Context rule enables compression by suppressing redundant, superficial, predictable or most used data inside an IPv6 header and replacing them with a Rule Identifier chosen in a given set of predefined rules. For instance, the ED's IP address may be added to the Context allowing it to avoid transmitting 128 bits IP address data if all the packets sent by a sensor have the same IP address.

When using SCHC, one element from the backend should realize SCHC operation (compression, decompression, fragmentation, reassembly) for all associated EDs. That is why we propose that the RG, the Network Server (NS) or the Application Server (AS) retrieve the Context dynamically from a remote server. Thus, the owner of the rules could easily modify them. Only the Rule IDs and versions are stored in either the RG, the NS or the AS.

Also, storing all SCHC rules, considering they might be unique for each ED, might introduce scalability issues to the system. We can consider around 20 rules per ED when working with such rules (as the rule ID + rule length is encoded on 1 byte), with thousands of EDs around a single antenna and multiple antennas for a given server (as LoRaWAN is built as a star of stars topology). When considering hundreds of thousands of EDs around a single server with around 10kb per Context rule, we end up storing gigabytes of data to enable SCHC on a given LoRaWAN infrastructure.

At last, the current way to store the SCHC Context rules statically does not allow to roam easily. It lacks the necessary flexibility which would enable to development of roaming capabilities when using SCHC. The use of an Administration Management System (AMS) as proposed by [@BWCCA.ayoub2019schc] could be a solution. It is a proposition to supervise roaming agreements and manage the use, generation and exchange of SCHC Contexts. However, such roaming accords would prove experimentally tricky when working with multiple operators, thus building accords between each LoRaWAN AMS, considering that operating a LoRaWAN network is possible at low cost without paying licenses for emitting data over the air.

There are multiple options for storing these Context rules. For example, it could be done in a private server, stored in the cloud or directly embedded within the operator's server. However, we think that it could be wise to use an open, distributed mechanism to find the location of the server where the Context rules are stored. We propose to experiment possible use of DNS as a way to support SCHC compression/decompression mechanism. As an optimized, hierarchical and distributed database, DNS could enable identifying the server's location where the Context rules are stored feasibly on the Internet. Hopefully, using such a mechanism would allow for a seamless transition, from preconfiguring the information needed on the backend to building it dynamically, on the fly, based on actual needs when operating the network.

DNS would prove an efficient solution to introduce more flexibility and improve scalability when using SCHC. Our solution would provide open access to SCHC parameters as a way to support roaming capabilities. Considering these three aspects of the SCHC framework, namely improving its flexibility, scalability, and assisting SCHC when an ED is roaming, and how DNS might help, we ask ourselves if it is possible to host rules outside the scope of the ED's NS without hindering the transmissions. To solve this problem, we deployed a dynamic Context resolution architecture based on DNS for SCHC compression/decompression and studied the consequences of such mechanism on the system latency and other possible consequences on LoRaWAN communications.

Data compression

After our work on compressing headers in LPWAN, we decide to further our approach regarding transmission efficiency by studying payload compressing. The easiest way to reduce data transmission is to delete redundancies or to round them to near values. When working with sensors, data is often time-correlated. For example, the temperature may vary slowly. Recently, Neural network-based techniques entered the landscape of IoT data compression techniques. Data can be compressed by their regression curve inferred from a neural network. More complex prediction methods can also be used. Neural networks are known as universal function approximators with the capability to learn arbitrarily complex mappings, and in practice, show excellent performance in prediction tasks. Other approaches include the use of Long Short-Term Memory networks (LSTMs) to perform predictions.

Many compression techniques appeared over the years. Nevertheless, if the "classical" methods present efficient compression ratios, they do not avoid transmitting data. Periodically a sensor senses data, may compress it and then send the compressed payload, but compressed data payload (plus header) are still sent. New neural network-based techniques appeared, and they avoid sending data in situations where the prediction is good. A neural network-based predictor is implemented in the ED and also at the back end. If the sensed data is well predicted, no data is sent, and the backend uses the prediction. Otherwise, the measurement is sent.

These approaches raise several questions. First of all, they have not been tested in real experiments yet. We like to push theoretical subjects further by implementing solutions directly on EDs. Thus we aim to experiment with an actual LSTM implementation on sensors to back or disprove the results obtained through simulations by the scientific community.

An important issue has not been addressed in the literature: questions on the complexity of a given Machine Learning (ML) model considering its integration to constrained devices lead us to study the efficiency of a given neural network regarding its size and the possible consequences of embarking such an algorithm directly on devices. It is commonly admitted that ML algorithms are too heavy for the constrained devices which are the sensors: their memories and processing capabilities are too small and their battery requirements too strong. Even if machine-learning algorithms may be embedded on a device, would its energy consumption be compatible with the small battery and the requirement to be alive for years? At last, there are coding issues related to the precision of the numbers processed by the ED: the number of digits is often limited in such a device, leading to weights quantization. Also, the number of weights of a neural network may be huge, and it makes sense to try minimizing the memory size by shortening the number of digits the weights are coded with. In this case, what is the impact of weights quantization on the algorithm's accuracy, and in fine the compression efficiency?

Lastly, we aim to study possible uses of the DNS infrastructure to back such compression mechanism by embarking the weights directly on the DNS. With DNS being an efficient open distributed database, using DNS would permit to open the access to ML models and weights, for example, when an ED is roaming. Three scenarios are studied about publishing ML weights in the DNS, each with its own strengths and weaknesses:

• one of them relies on asking the backend to publish the ML weights in the DNS.

• a second consists is to rely on the DNS to store the address of a given API which would allow to retrieve and modify ML algorithm

• a last possibility consists of learning the lessons from the DNS-SD paradigm [@rfc6763] in a dual connectivity infrastructure to support discovery and advertising of ML model within a given local coverage, for example, as a way to support compressed LoRa Mesh communication.

Next section

The next section is Research contributions available at [[2021112623]]

Contributions

Our work mainly consists in breaking the silo between multiple LoRaWAN deployments, but as mentioned above, we expect similar results when working with less constrained networks.

Our work with LoRaWAN led us to collaborate with various parties from the community and contribute to the LoRaWAN Specifications, and collaborate with the lead developer of the ChirpStack open-source software, which is the most massively used and reference LoRaWAN infrastructure backend solution. Our focus when working with ChirpStack mostly consisted of providing insight on the interconnection between the ChirpStack Solution and the DNS infrastructure regarding the actual use of DNS in the LoRaWAN specifications.

This work also leads us to reflect on a possible use of DNS prefetching to reduce the impact from usual DNS querying in a mobility use case. When querying information necessary for device's functionalities, prefetching the necessary information beforehand allows interesting improvements in terms of DNS cache hit. We provide simulation results based on a comparison between three querying scenarios based on mobility traces in an urban area.

After extending roaming capabilities in a LoRaWAN network, we worked on compressing headers to develop IP connectivity in LPWANs. Our contribution relies on extending the existing SCHC standard by leveraging the DNS infrastructure in its capability to increase connectivity and accompany application scalability.

Thus we proposed an experiment to measure the time delay induced by using the SCHC compression/decompression framework, then extended the time delay study by adding new interfaces to SCHC, enabling remote context querying. We also provide experimental measurements on DNS querying time to improve the quality of our time measurements by studying actual resolution time outside our lab scope.

Finally, we extend our work on compression by working on compressing payload using ML techniques and studied possible strengths and weaknesses of such system.

Next section

The next section is Thesis structure available at [[2021112624]]

Structure of the thesis

This thesis is structured as follow.

Chapter [Chapter_state_art]{reference-type="ref" reference="Chapter_state_art"} presents a state of the Art regarding naming, and more specifically and IoT. It first presents the scope for identification in the IoT ecosystem, then presents a few aspects on querying and its underlying mechanisms (architecture, performances, methodology). After that, scalability and security are presented with a focus on the specific aspects that are of interest for the thesis. Coverage and roaming as solutions to support mobility are described as well as the DNS, its functioning and evolutions. Finally, we provide references on various approaches to combine ML paradigms and IoT.

Chapter [Chapter_iotroam]{reference-type="ref" reference="Chapter_iotroam"} presents our work on roaming and how DNS improves roaming capabilities and break IoT silos. The work is first introduced in [section:iotroam_intro]{reference-type="ref" reference="section:iotroam_intro"} and compared to other approaches ([section:iotroam_related_work]{reference-type="ref" reference="section:iotroam_related_work"}). Then we provide insight on LoRaWAN with regards to interconnecting networks ([section:iotroam_interconnection_in_lorawan]{reference-type="ref" reference="section:iotroam_interconnection_in_lorawan"}) and our focus and design choices with regard to identification ([section:iotroam_design_choice]{reference-type="ref" reference="section:iotroam_design_choice"}) and security integration ([section:iotroam_pki]{reference-type="ref" reference="section:iotroam_pki"}). After that, we dig into our experiment and present our setup ([section:iotroam_validation]{reference-type="ref" reference="section:iotroam_validation"}) and measured performances ([section:iotroam_performance]{reference-type="ref" reference="section:iotroam_performance"}). We propose to extend this solution by provisionning the DNS queried information beforehand using a combination of prefetching techniques and mobility prediction algorithms ([section:prefetching]{reference-type="ref" reference="section:prefetching"}). Finally, we sum up our contributions ([section:iotroam_contribution]{reference-type="ref" reference="section:iotroam_contribution"}), provide our conclusions ([section:iotroam_conclusion]{reference-type="ref" reference="section:iotroam_conclusion"}) that summarize the work and propose future steps for the experiments.

Chapter [Chapter_SCHC]{reference-type="ref" reference="Chapter_SCHC"} describes our work on SCHC and its extension using the DNS infrastructure to support rules management. It starts with a short presentation on SCHC ([section:schc_intro]{reference-type="ref" reference="section:schc_intro"}) before digging into the experiment ([section:schc_experiment]{reference-type="ref" reference="section:schc_experiment"}) in which our propositions, scenarios and testbed are described. Then our results are described ([section:schc_results]{reference-type="ref" reference="section:schc_results"}) and discussed ([section:schc_ccl]{reference-type="ref" reference="section:schc_ccl"}).

Chapter [Chapter_ML]{reference-type="ref" reference="Chapter_ML"} presents our implementation of LSTM on constrained devices using our own development working with pre-calculated weights from TFLite. An introduction centers the subject around our usual scope ([section:machine_learning_introduction]{reference-type="ref" reference="section:machine_learning_introduction"}) and put it into perspective with usual compression techniques ([section:machine_learning_motivation]{reference-type="ref" reference="section:machine_learning_motivation"}). Then we describe our experimental approach ([section:machine_learning_experiment]{reference-type="ref" reference="section:machine_learning_experiment"}) and discuss our results regarding our various measurements points ([section:machine_learning_discussion]{reference-type="ref" reference="section:machine_learning_discussion"}) and weight storage modalities ([section:machine_learning_weight_storage]{reference-type="ref" reference="section:machine_learning_weight_storage"}). The chapter ends with a short conclusion ([section:machine_learning_conclusion]{reference-type="ref" reference="section:machine_learning_conclusion"}) that summarize our contributions and describe possible further approaches to the subject

Finally, the last chapter (Chapter [Conclusion]{reference-type="ref" reference="Conclusion"}) concludes the thesis by providing an overview of our contributions and presents possible extensions to the work we realized.

Next section

The next section is Chapter 2 - State of the Art available at [[202111263]]

State of the Art

This page is here for consistency reasons but is actually empty, the Chapter directly starts with delimitating the manuscript scope regarding IoT. [[2021112631]]

IoT Scope

The term "Internet of Things" (IoT) encompasses several meanings depending on the communities/technologies involved. The basic purpose is to connect the "Things" in the physical world to the Internet infrastructure. The things could be anything from computers to people to medicines to books.

The things could be connected to the Internet infrastructure directly or indirectly. A Computer or a mobile phone could be connected to the Internet directly using an IP stack and some type of layer-2 connectivity, such as Wi-Fi or Ethernet. People or books will have indirect connections to the Internet, which may be enabled via some intermediate equipment, typically a non-IP carrier device, such as sensors, Radio Frequency Identification (RFID) or Near Field Communication (NFC), tagged with the things.

These carrier devices do not use the Internet protocol suite (TCP/IP) for communication. Instead, they use their proper communication technologies such as Bluetooth, Zigbee or Long-Range (LoRa). To link the non-IP-capable devices to the IP network (i.e. the Internet), there is a need for a gateway device, which can handle communication at two levels: on the one hand with the non-IP-capable devices, and on the other hand, with the IP network; thus bridging between non-IP and IP worlds.

Making "things" "smart"

{#fig:smart_things width="\linewidth"}

The basic idea for IoT is to make the "things" "smart", which are otherwise considered dumb by default, from a technical perspective. Let us take the example of a cow in a herd, which is an entity of interest (Figure 1.1{reference-type="ref" reference="fig:smart_things"}) for the farmer. Every 21 days, the cow has a 12 to 18 hours window, which is considered as the optimum period for mating [@connected_cow]. The cow is highly active during this window, and hence the IoT application is attaching pedometers to the cow. The pedometer tagged to the cow periodically sends information, and a message is triggered to be sent to the farmer when the cow is walking more than its usual average. There are such a plethora of applications where things in the physical world can be tagged to make it smarter.

The progress in hardware development, decline of size, cost and energy consumption has enabled the feasibility of tagging non-IP devices to the physical things. This is why there is much talk about IoT currently, even though the idea is not new.

Identifying "things"

Taking the cow example described previously, the farmer needs to identify a cow individually in his herd. For this purpose, the pedometer tagged to each cow in the herd should have a unique identifier. The scope for the uniqueness of the identifiers is limited within the herd.

However, IoT envisions billions of devices connected to the Internet. Hence, the identifier for each thing should be unique in the IoT. In the current Internet infrastructure, identifying a thing (a computer or a router is also a thing from an IoT perspective) uniquely on the Internet is based on IP addresses (either IPv4 or IPv6). The IP addresses follow a specific naming convention [@naming_convention]. There is a hierarchical structure [@rfc2050] which provisions the IP address and makes sure that there is no duplicity (i.e. no two devices on the Internet has the same IP address). Some other things may not use global IP addressing, using private addressing instead. Things having a private address are still connected to the Internet, with the help of a gateway device, which uses a global IP address to transport data from a private network to the Internet and vice versa.

As mentioned earlier, IoT involves non-IP capable devices; hence they do not use IP addresses for identification. The way these devices are identified could be classified into legacy and emerging identification. The legacy identifiers have their existing naming conventions, their proper structure to provision their identifiers to end-users, well before the emergence of the IoT theme. These legacy identifiers range from EUI-48, EUI-64 for MAC addresses (Extended Unique Identifier), Digital Object Identifiers (DOI) for electronic content, and Electronic Product Code (EPC) for RFID or barcodes. The emerging ones are new naming conventions with their proper provisioning structure, developed to satisfy specific needs of a particular section of the IoT industry.

Identification plays a vital role in interconnecting heterogeneous IoT networks. When an IoT ED is roaming, the VN should retrieve its identifier and bootstrap the interconnection process to access the service related to the identifier on the Internet. If the obtained identifier is not unique, then there is a possibility of collision. Hence the identifier for an IoT ED should be unique.

Identifiers used in IoT includes heterogeneous identifiers encoded in different standardized naming formats such as IPv6, EUI-48, EUI-64, EPC, DOI, RF-ID, non-standardized identifiers for a specific industry such as Apple Unique Device Identifier (UDID) and user-generated identifiers.

One possible way to solve the issue of heterogeneity in identifiers is for all IoT stakeholders to move to a globally unique identifier, such as the IPv6 address (since it has a large addressing space and is capable of allocating a unique identifier for every IoT ED on the planet). In reality, migrating to one globally unique identifier for the whole IoT industry is impossible. The reason being cost and the technical complexities in migrating the IoT infrastructure with their existing identifiers to IPv6. A feasible alternative would be to let the different sectors in the IoT use their existing identifiers but to use a mapping service, which can map the identifier of an IoT ED to its network.

The well-known mapping service on the Internet is the DNS [@rfc1034] [@rfc1035], basically conceived to translate human-friendly computer host-names on a TCP/IP network into their corresponding "machine-friendly" IP addresses. Afnic's previous work [@dinr] provided arguments based on existing standards and deployments to illustrate why DNS should be the naming (i.e. mapping) service for IoT.

Examples of leveraging DNS for mapping identifiers other than domain names include E.164 Number to URI Mapping (ENUM [@rfc3953]) for telephone numbers. For IoT, there exists already standards such as Object Naming Service (ONS) [@ons] for the consumer industry, Object Resolution System (ORS) standardized jointly by the ITU-T and ISO/IEC and the Handle system standardized by the ISO, which uses the DNS infrastructure to resolve the IoT identifiers to its related service on the Internet.

IoT identifiers are structured into two different categories: Hierarchical and Flat. The hierarchical identifiers are allocated hierarchically, control is decentralized, and the nature of allocation ensures no duplicity exists. These features are similar to the domain name allocation and management, and thus these types of identifiers could naturally leverage the DNS infrastructure for allocation and resolution.

An example of a hierarchical identifier used in the supply chain industry is the EPC. The barcodes attached to consumer products follow the EPC naming convention, which can be hierarchically partitioned into Country, Organisation and product levels.

An example of a flat identifier is UDID, a unique serial number assigned to each Apple manufactured device. Apple uses UDID to track and record Apple manufactured devices, and it does not have a hierarchical allocation as that of EPC. The UDID is unique within the Apple UDID namespace. It is a 40-character alphanumeric string of code as follows:

::: center 2b6f0cc904d137be2e1730235f5664094b831186 :::

Provisioning both identifiers types; EPC and UDID could be included into the Internet via the DNS namespace. Then it is up to the client libraries to make the conversion and add the specific sub-domain suffix ("udid.apple" for UDID and "gs1" for EPC) to the identifiers. Once the identifier is converted to a fully qualified domain name as follows:

::: center 2b6f0cc904d137be2e1730235f5664094b831186.udid.apple.
3.1.3.1.6.2.3.3.9.3.4.0.3.gs1. (supposing that there is a TLD called 'gs1') :::

They will follow the standard DNS resolution to resolve their associated resource, ED or metadata.

We hypothesize is that DNS is the only infrastructure that could scale to billions of EDs in the context of IoT interconnection, similar to how it has withstood the meteoric rise from hundreds of domains at the beginning of the Internet to billions currently [@number_website]. Thus, we propose using DNS infrastructure as a scalable solution to satisfy the requirements outlined by Wireless Broadband Alliance (WBA)[@wba_roaming].

Overcoming interoperability challenges

Interoperability is the ability of a system to work with or use the components of another system. As mentioned in the article [@interop_of_things], there are four levels of interoperability; we will narrow our focus on an Organizational Interoperability approach to overcome interoperability challenges. Organizational Interoperability is the ability of organizations to communicate and transfer information across different information systems effectively, infrastructures spanned over different geographic regions, and cultures [@platform_interop]. The European project - symbIoTe [@symbiote], proposes a finer granularity of Organizational Interoperability, enabling IoT platforms to collaborate by forming federations, thus supporting roaming where the EDs could find their core services while in the coverage area of the VN with the help of their unique identity.

[@Bandyopadhyay_Sen_2011] points our the necessity of adopting a standardization approach to improve IoT technologies. Without such approach, the IoT ecosystem would end up fragmented between specific technologies and use cases. Another key aspect pointed out is the importance of improving interoperability between IoT solutions and the necessity of a clear legislative framework to ensure the right to privacy and improve security for all users.

Next section

The next section lists reflexions regarding querying available at [[2021112632]].

Querying

Querying in IoT raises many research issues: data storage and database comparison, temporal and spatial retrieval, the architecture of IoT, data and query distribution (and, subsequently, caching mechanisms), interoperability, data contextualization (and what is related that is discovery), and query performance. Concerning the used methods, they are numerous, for example, probabilistic ones, machine-learning-based ones or, of course, graph-based ones and blockchains.

Data storage

[@8756793] compares relational and graph databases. [@7887957] compares SQL and NoSQL databases for a small scale IoT application of water sprinkler system and investigates whether NoSQL performs better than SQL in different scenarios. NoSQL is the database technology that allows the rapid organization of different non-relational data types. NoSQL databases are divided into four categories, which are key-value based, column-oriented, document-oriented and graph databases. In [@8620837], it is aimed to evaluate the storage and query performance of MongoDB on IoT data. The authors of [@7279070] address the issue of data storing with a big data approach using MongoDB to spread data over servers and maximize query speed uniformly. Resource Description Framework (RDF) is a graph-based data model employed for representing the Uniform Resource Identifiers (URIs), and SPARQL is the standard query language used for processing the query of RDF data. The growth of data throws a big challenge to data storing and processing. In [@8088597] a new data storing and query processing approach is proposed using a weighted predicate tree. The predicate tree is used to effectively store data and extract the weights indicating the relation of the data. [@8334437] devises a SPARQL query engine able to factorize on-demand and semantically enrich stream data in a knowledge graph. The problem with ontologies to describe concepts, relationships between entities in various application domains is that semantic technics increase the complexity. Based on RDF as data format and SPARQL as a query language, [@7396786] propose an in-network query processor to face the challenge of handling verbose RDF data and SPARQL queries execution in embedded devices. Most XML (eXtensible Markup Language) data are indexed by partitioning them into several data streams, which results in processing multiple data streams simultaneously when querying, and it is heavy. [@9051692] uses a novel index storing only a subset of the data nodes, the rest of the nodes being generated efficiently and its authors propose an algorithm to process one data stream at a time.

To eliminate the adverse effects on massive data processing in IoT, a novel skyline preference query strategy based on massive and incomplete data set is proposed in [@7858739]. [@8257956] presents a single-node datastore able to ingest multidimensional sensor data at very high rates. Its design centers around a two-level indexing structure, wherein the global index is an in-memory R*-tree and the local indices are serialized k-d trees. [@8855575] designs a memory-efficient high-performance key-value system called RadixKV, which offers efficient improvements on the Radix Tree. [@8651860] proposes a lightweight and secure IoT remote monitoring mechanism using DNS with privacy preservation. The communication between IoT devices and gateways uses conventional protocols such as Constrained Application Protocol (CoAP) and Message Queuing Telemetry Transport (MQTT), while only remote monitoring uses DNS protocol. That is encrypted IoT data, after being encoded with base64, is stored as a DNS TXT record of the domain name of the IoT device and only the designated users are allowed to query and decrypt the data based on TSIG (Transaction SIGnature) authentication of DNS protocol and asymmetric cryptography.

Temporal and spatial retrieval

Time-series

In order to exploit and analyze the time-series data efficiently, [@9064768] develop an index and the matching approach for the continuous time-series data, contrary to most of the static indexing approaches. Its authors propose a lightweight index structure, L-index, and a matching approach, L-match, for the constraint normalized subsequence matching problem ([@8731498]), which is a two-layer structure and built on the simple series synopsis, the mean values of the disjoint windows. Using disjoint windows is faster to update than sliding ones. The constraint normalized subset matching problem provides a knob to control the offset shifting and amplitude scaling flexibly. When storing event data in existing Time-Series Databases (TSDBs), the retrieval may have performance problems. Also, existing TSDBs do not have a specific query language defined for event analysis. [@8953028] develops a model for event specifications and use it to specify abnormal system states to be captured to allow timely mitigation. The event model is integrated into the TSDB by translating them to continuous queries defined in some TSDBs. The authors of [@8953028] develop a model of event specification since TSDBs do not have specific query language. In [@8633895], the authors study the approximate range emptiness problem, which answers an emptiness query of the form "$S \cap [a;b]=0?$" for an interval [a;b] of length L $(a,b \in U)$, over sliding windows in the IoT data streams. [@8785795] designs a real-time and historical multi-view IoT trend system. Using an information graph, it displays the relationship between different sensor data and, using the method combining real-time and history, it proposes a buffered batch data loading algorithm to form a dual-display mode system. About data quality validation, the contribution of [@8753999] is to enhance the stream processing system such as C-SPARQL with production rules, instead of statistical approaches, to achieve a Continuous Time-Aware reasoning. It is used to provide stream validation for the quality problem relating to inconsistencies in sensor streams. Errors in measurements may cause bad procedure (and even sometimes dangerous) triggers.

Spatio(-temporal) retrieval

[@8975799] aims at designing a distributed framework of massive trajectory data analysis based on Hbase to realize spatio-temporal query more efficiently for urban computing scenarios. They design a temporal-based pre-partitioning strategy to improve the performance of data written. Then they develop a Multi-Level Index to speed up the process of spatio-temporal query. [@8710770] consider the case of IoT databases along roads to organize the storage according to road segment, instead of the cell, as the unit of space mapping and data storage so that data requested in a road query can be stored together to enable efficient I/O. Then, one can efficiently found the units covered in a road query, which is usually concerned only about data on a few segments of roads. [@9092903] offers location-aware services based on data messaging and aggregation techniques. Its authors design a taxonomy for the classification of the IoT devices based on their mobility frequency and leverage it to design a priority scheme to address the co-located devices that offer similar services. In [@7050822], considering that stream processing must not be limited to the temporal dimension but also consider the spatial one, a query language is developed to process temporal and geographical data, based on an index taking into account both dimensions. With in-network processing, generated queries are routed to the nodes belonging to the specific region of interest, mainly using standard WSN (Wireless Sensor Network) geographic routing algorithms. The IoT IETF standard routing algorithm RPL (Routing Protocol for Low-Power and Lossy Networks) builds a tree-like routing topology that is inefficient for a spatial type of query because it floods the message to all nodes either inside or outside the target region. The authors of [@8766512] improve RPL in particular by considering spatial partitioning. IoT applications use more or less two kinds of data: either time-series or contextual information (or graph), mainly stored through massive data (times-series) or graphs and ontologies (contextual information). [@7195642], [@8276872] and [@8894466] address the issue of designing search engines including both spatial and temporal dimensions, for example, using dual temporal and spatial stores.

IoT architectures, data and query distribution and caching

It is critical to perform communication-efficient data aggregation to answer complex queries (e.g., skyline queries and equality joins) from IoT applications. [@8543244] investigates the problem of constructing an aggregation tree for complex queries with the minimum communication cost. [@8560260] addresses the issue of data replication and keeping only necessary data to process them and respond in a limited time. Nodes can act as a team and cooperate to store the data close to processing tasks defined as queries. Every node decides, in real-time, if the observed data are correlated with the available datasets or if they are outliers. When data are accepted to be locally stored, nodes select their peers where data will be replicated. [@8703942] proposes a multi-attribute aggregation query mechanism in the context of edge computing. [@8411011] considers the problem of query placement on edge and cloud resources for dynamically arriving and departing analytic dataflows. This is an optimization problem to minimize the total makespan for all event analytics while meeting energy and compute constraints of the resources. [@7471353] proposes a framework aiming at reducing the energy at the sensor level and the billing cost at the cloud level. [@7302489] designs a centrally managed distributed infrastructure based on the state of the art big data technologies for processing many real-time queries. [@7184865] and [@8433724] design multitenancy cloud for IP traffic flow. [@8850107] addresses the issue of time-series database in the edge between the sensors and the cloud, taking into account the low space and processing capabilities of the edge. [@8731646] employs the parallelism in edge computing environments to facilitate the top-k dominating query process over multiple uncertain IoT data streams. The challenges of this problem include how to quickly update the result for processing uncertainty, reduce the computation cost, and provide highly accurate results. In [@Moeini_Zeng_Yen_Bastani_2019], an edge-centric architecture is considered, and a routing method is proposed to find the information efficiently. [@8804809] proposes a multicast algorithm that is data-centric (based on feature information) and intended for low power networks. [@8818410] and [@8975877] propose semantic-based algorithms for routing and IoT service discovery (with appropriate information compression). In order to save bandwidth, [@8884845] uses a gossip-based protocol for nodes to organize into groups based on attributes and current value. [@8567667] addresses the issue of resource allocation in heterogeneous edge/fog devices. [@7925549] takes advantage of data aggregation and both spatial and temporal reuse by exploiting long-term static scheduling for periodic data to ensure the latency and data rate and by employing short-term dynamic scheduling for event-driven, query-based data to improve transmission efficiency.

[@8863936] implements caching in cloud for frequent n-hop neighbor activity regions.[@8361300] uses proactive caching in placeholders to decrease query delays. According to [@8587857], the data queries often are similar or overlapped to the previous queries, especially when the user adjusts the query parameters on the same time-series data for displaying on a visualization tool. The article proposes a cache mechanism to help reduce the query response time if the current query range overlaps with the previous query ranges. [@8453789] observes that memory object caching are inefficient in case of unrepeated queries, and it proposes pro-active caching. The prefetching is done according to rules customized according to the workload.

Interoperability

The authors of [@8905178] describe a semantic data model, rules, and a reasoning platform taking SPARQL queries as rules to enable high-level data abstraction and knowledge extraction. [@8766510] integrates existing ontologies to provide semantic interoperability among heterogeneous devices and users in the healthcare domain. [@8107003] focuses on facilitating the understanding of messages exchanges between artefacts founded in different ontologies by semantic translation based on ontology alignment. In [@7045421], the authors leverage semantic technologies like Linked Data to disseminate data to relevant data consumers. Time-series databases are used to store IoT data, but they lack a good semantic model to support data sharing. That is why [@8953028] proposes a monitoring data annotation model to guide the systematic specification of monitoring data streams. In [@Bonfitto_Hachem_Belay_Valtolina_Mesiti_2019], the authors propose IoT-Directory, which makes it possible to manage packet brokers using different communication technologies and formats in an ontology-based way, and in particular, to ingest data from them in the IoT-Directory. Another issue is the necessity for processing IoT data from multiple heterogeneous data stores: in [@9044318], a multi-store query system for IoT data is proposed. The IoT is characterized by a wide variety of data sources, large scale and heterogeneous structures. However, those characteristics bring great difficulties to the storage and rapid retrieval of IoT data. By considering the common attributes of IoT data, based on plug-in ideas, combined with Redis and HBase, the paper [@8393258] proposes a framework named HSFRH-IoT, which solves the problem of efficient storage and retrieval of massive heterogeneous IoT. [@8585679] presents an ontological model which improves semantic searching and querying capabilities by hiding the heterogeneity of entities and their produced data. [@8665668] addresses the issue of semantic relationships between the data over data/event streams using Complex Event Processing to derive time-annotated RDF data from the basic events streams and C-SPARQL for processing online queries over a domain ontology for property inference. In [@8558513] an agent-based server system approach, which improves the resource sharing between heterogeneous WSNs in IoT/CPS (Cyber Physical Systems) providers, is proposed. [@El-Hassan_Ionescu_2018] presents a versatile architecture of a broker named X2CBBR and based on XML-base publication data and Xpath-based subscription data that can operate in IoT with different publish/subscribe systems. The EPC network is a collection of industrial standards designed to build an Internet of physical objects. ONS, a directory based on the DNS, is one of the important components of the EPC network. ONS provides a connection between the product code and Information Services in IoT systems. [@Ding_Li_Zhu_2018] proposes an extension of ONS architecture to support heterogeneous object code identification dynamically.

Data contextualisation and discovery

Contextualisation

A classical approach is to use the data context to facilitate the query: [@7301477]. Contextualization of IoT data is the technique that excludes irrelevant IoT data from processing and dissemination [@7980140]. It involves query rewriting, semantic web and rule-based context management or ML and data science-based solutions. [@8534571] proposes a generic approach to represent and query situations in IoT environments. [@8304116] performs the reasoning process to change existing data on the ontology according to the rule created and produce more representative and contextual data. [@8730847] present an application that allows users to look back on their memories by prioritizing photographs that were taken in contexts that are similar to the current context. It is built on a contextual database middleware that provides context storage and context-sensitive queries that determine the similarity between pairs of contexts. Reminisce uses the contextual database to store the contexts of a user's photos, including location, time, neighboring devices, and weather conditions. Later, the app identifies the photos whose stored contexts are most similar to the user's current context by querying the contextual database.

Context sharing and discovery

Applying semantic techniques to IoT can support interoperability, collection, annotation, validation, effective data access, integration, resource discovery, but also processing and storing as well as reasoning and querying for data knowledge extraction ([@8454974],[@7106951]). The IoT requires a semantically rich, dynamically extensible, low complexity service discovery mechanism. It differs from classic discovery approaches such as UPnP or DNS-based approaches which are well suitable for connecting resource constraint devices but do not match the required semantic richness of the IoT. [@8717904] present a solution that is extensible at runtime, contrary to mechanisms such as UDDI (Universal Description Discovery and Integration). It is based on a distributed modular directory of service properties. [@8480240] proposes a platform enabling smart things and IoT silos to discover, validate and share relevant and dependable context. [@8770069] proposes a distributed service discovery algorithm intended for a highly dynamic network environment. In [@8923352], a distributed model for resource discovery in IoT is based on a structured peer-to-peer scheme, which supports multi-attribute queries and uses a distributed hash table as an overlay to organize the discovery process. In [@8766367], ontologies like W3C's (World Wide Web Consortium) and OGC's (Open Geospatial Consortium) Semantic Sensor Network (SSN) and Sensor, Observation, Sampler, and Actuator (SOSA) are extended to annotate IoT streams for search and discovery. To share and publish the domain knowledge of IoT objects, developing a semantic IoT model-based directory system that manages meta-data and relationships of IoT objects is required. [@7050819] proposes a directory that supports semantic description, discovery and integration of IoT objects. [@8813884] proposes semantic accessors, including a local semantic repository for maintaining the context, accessors for querying and dynamically updating the repository and servicing. [@7439336] presents an approach covering both service discovery and invocation for IoT-aware processes. It proposes a novel concept for integrating semantic queries into process activities to support runtime discovery and dynamic invocation of IoT services. It extends a generic process meta-model by a set of process step types supporting SPARQL queries. This approach provides runtime flexibility in terms of resource allocation and therefore increases the reusability of process models. With this solution, it becomes possible to specify commands like "switch on all lights in the kitchen" directly in a process step without knowing which Things are capable of executing this command. In [@8581709], the authors speed up the discovery process by centralizing the RDF semantic information instead of keeping it distributed in the resource tree.

Query performance

In [@8766395], the authors propose an index to compare query languages from both performance and expressive points of view, taking into account the « richness » of a query. In [@Bermudez-Edo_Elsaleh_Barnaghi_Taylor_2016], IoT-Lite proposes a minimal lightweight semantic. In [@El_Kaed_Khan_Hossayni_Nappey_2016], a semantic query engine for Industrial IoT, SqenIoT, is designed together with multi-level ontologies and mechanisms and a things query language targeted for resource-constrained gateways and non-technical personnel. In [@8526800], IoTm, a framework for measuring IoT performance metrics, is presented, which include both IoT network's Quality of Service (QoS) metrics and IoT node's resource utilization metrics. IoTm has two key properties: 1) it is lightweight and thus amenable for implementation on resource-constrained IoT nodes; 2) it can perform measurements at fine-grained levels and not just at aggregate levels. [@7581503] an advanced high-level formalization - Performance Evaluation Process Algebra (PEPA), a kind of stochastic process algebra (SPA), is adopted to model the process of real-time traffic status query in Intelligent Traffic System (ITS).

Meanwhile, using the fluid approximation approach to analyze the performance of the model, and then the performance parameters of the system in practical applications can be achieved accurately. A dedicated testing procedure has been configured in [@8827164] for evaluating InfluxDB, one of the most effective and widespread TSDBs. The performance analysis, carried out on a specific use case, demonstrated that the database write and read performance can be significantly affected by the used data model, with queries executed on the same data requiring times from hundreds of ms to seconds in the worst cases.

Methods

Probabilistic approaches

[@8768205] address the issue of aggregation query (e.g. give the maximum pollution level in an area) via probabilistic sampling. Reverse Nearest Neighbors query finds the objects that have the query as the nearest object and plays an important in many applications. [@8394733] thus studies probabilistic Reverse Nearest Neighbors query over the uncertain data streams. IoT is used to monitor natural phenomena, but spatial queries are costly. Efficient sampling-based approaches are proposed in [@9014291]. To balance the retrieval efficiency and the maintenance cost, [@8392686] adapts the probability that a thing property is indexed to its change frequency and also to its query frequency. [@Muni_Subudhi_2018] uses a probabilistic flood search algorithm to find devices distributed in heterogeneous and dynamic environments. Sampling-based approximate data analytics are the most widely used, which trade the output quality for efficiency. [@8896627] proposes a real-time data flow system for edge computing and analysis.

Fuzzy approaches

[@6542861] uses fuzzy ontology query and reasoning to generate complex event query plans, and context-aware queries are rewritten into context-independent sub-queries. Data windows are partitioned according to different event patterns and contexts. The sub-queries are optimized and executed in parallel based on data partitioning.

Machine-learning methods

[@8629991] consider a neuronal approach to minimize storing and processing of image data in IoT using neural networks to extract relevant information. To achieve efficient storage management, [@9086607] classifies and reduces data using a Support Vector Machine (SVM) classification algorithm.

Graph methods

In recent years, the Social IoT paradigm, where objects establish social-like relationships, has become popular as it presents several interesting features to improve network navigability and implement efficient discovery methods ([@7845506], [@7096253]). Using social relationships can help to accumulate experience knowledge and also optimize the network traffic load ([@8701947]). In [@7519392] various graph algorithms are used to respond to the user's queries smartly. In [@8230010], graph databases in clouds are used to represent data. [@8910344] addresses the problem of community search in social IoT, which is beneficial to resource/service discovery, from the viewpoint of a dense subgraph query. In [@8070066], the issue of faster query processing of data is addressed. It presents a Log Based Method (LBM) to store and query IoT data in Resource Description Framework RDF format. LBM exploits skewness in access patterns of records by analyzing query workload and partitions the basic triple table into hot and cold sections. To facilitate data retrieval and analytic, [@8647180] ranks the web pages where the information is stored in function of the quality of the content and the interconnection between the web pages.

Blockchain

[@8998490] designs a distributed IoT blockchain ledger for managing the metadata needed to describe IoT devices and the data they produce. It is not controlled by any individual or organization. The paper also proposes a marketplace that provides the functionality needed for IoT device registration, query, integration, payment and security via the proposed blockchain. [@8935016] proposes a solution called Semantic Smart Contracts (SSC), which integrates RESTful semantic web technologies in smart contracts, deployed on the Ethereum Blockchain platform, for indexing, browsing and annotating smart contracts. The solution also exposes the relevant distributed ledgers as Linked Data for enhancing the discovery capability.

Next section

The next section presents reasearch articles on Scalability available at [[2021112633]]

Scalability

IoT faces well-known scalability issues. EDs hardware have small power resource, limited memories and processing capabilities, bandwidth is either sparse or it may be overloaded due to the huge quantity of transmitted data. Legal regulations impose limitations on the spectrum usage (e.g. respect of duty cycle constraints). Most of the problems arise at the network front-end but also in the back end since all the data are finally routed to servers or clouds on which they are stored and processed ([@8091030], [@7179026]). Thus, economising bandwidth, batteries, memory, storage and processing are ways to increase IoT scalability. Compression techniques are solution but also subtle tradeoff between information loss, energy, storage, time and bandwidth minimisation ([@8923112]). Most of the time these efforts lead to design new compression methods ([@6803222], [@7888991], ([@8631929], [@8653620], [@8478466], [@8756995], [@8108772], [@8622282], [@8368985], [@8796782], [@7469055], [@8662558],[@8249368], [@8718179], [@7737055], [@8595614], [@6697924], [@8767300], [@7149287], [@8766590], [@8767351], [@8343232], [@8767326], [@8039067], [@8712659], [@Di-Vincenzo_Heusse_Tourancheau_2019]). Some are lossy while others are lossless. Deleting redundancy, data aggregation, quantization, approximation by simpler functions, use of dictionary-based methods, entropy coding, transform methods, compressed sensing and neural network approaches have been applied for IoT.

The easiest way to reduce data transmission is to delete redundancy or to round them to near values. Sensors often generate time-correlated data. For example, the temperature may vary slowly. Run-Length Encoding (RLE) takes advantage of the adjacent clustering of symbols that occur in succession. It replaces a "run" of symbols with a tuple that contains the symbol and the number of times it is repeated. The authors of [@8766590] apply Delta Encoding followed by RLE at the end node. At the gateway tier towards the back end, they apply the hierarchical clustering for grouping datasets received from sensor nodes dependent on the Minimum Description Length (MDL) principle. If any pairs of received datasets can be compressed by the MDL principle, they will be combined into one cluster. For every cluster, it is preferred to look for a model or representation of the dataset to compress the others based on it. They call this model or representation a hypothesis. For studied each cluster, they send the hypothesis followed by the difference vector between the hypothesis and the other datasets belonging to this cluster. In [@8249368] delta compression allows sending only the difference between two consecutive temperature measurements. In [@8039067], only significant differences between surveillance video frames are sent. In [@8653620], GPS locations are shortened by substracting the common latitude and longitude parts of the measured positions. Data are also usually quantized to round the measures to significant approximations requiring fewer bits for coding. They are often aggregated ([@8653620] or [@8108772]). Also, fields of measured IoT data may change at different speeds depending on the nature of the measured quantities. Observing the change in frequency allows adapting the way they are sent or pruned ([@8796782]). The paper [@8718179] uses aggregate approximation based on Symbolic Aggregate approXimation (SAX) ([@ACMSigmod.lin2003]) and symbol encoding. The idea is to replace fixed sized data windows by their average, and successive averages are differentially encoded and replaced by codewords. Also, in [@8622282], the authors suggest that applying repeated pattern-based graph compression techniques may be used to compress IoT data represented by graphs.

Approximating the measurements reduces their size also ([@8478466]). One can compress signals by approximating them with auxiliary, more straightforward functions. Lightweight Temporal Compression (LTC) ([@1367273]) is an energy-efficient lossy compression algorithm that maintains memory usage and per-sample computational cost in O(1). LTC estimates data points using a piece-wise linear function that guarantees an upper bound on the maximum absolute error between the reconstructed signal and the original one while maintaining memory usage and per-sample latency in O(1). Such an LTC method is proposed in [@8767351] which increases the compression efficiency by exploiting the latitude offered by the error bound to find a better approximation in terms of compression ratio. Fan algorithm ([@52340]) is an adaptive sub-sampling approach that operates by drawing the longest possible straight line between the starting sample and the ending sample in such a way that the error in reconstruction of the intermediate samples are less than the maximum specified error value. In [@7737055], the authors take profit of the high compression ratios of lossy compression with lossless entropy coding compression for the resulting error compressions. For the lossy compression, any lossy algorithm could work, but it must be implementation efficient (in terms of energy, memory...). The authors choose the Fan algorithm. They use Huffman coding for the lossless compression algorithm.

Classical compression approaches based on dictionaries or entropy coding have been adapted to IoT. In [@8767326], a specific dictionary is created for different kinds of data depending on their change frequency. In [@7888991], a dictionary is created online at run time for biomedical signals. In [@8595614], the LZW compression algorithm is applied to the differences between sample measures. In [@8368985], an offline frequency distribution is used to create a symbol-code lookup table. They use an extensive set of data from a previous study, and they present an analysis of the entropy of activities of daily living accelerometer data. Lossless Entropy Compressor, a Huffman based compression method, has been made dynamic to handle possible heterogeneity and changes of the signal ([@6697924]). Obviously, depending on the operating conditions, the best among uncompressed, lossy or lossless modes can be chosen dynamically ([@6803222]).

Transform methods are classical tools for compressing data but might be CPU resource consuming. [@8091030] evaluates several lossy compression algorithms for efficiently storing weather sensor data based on the encoding of temporal changes and three signal transformation algorithms on spatial data. Specifically, they evaluate the fidelity of reconstructed weather sensor data using Discrete Cosine Transform, Fast Walsh-Hadamard Transform and Discrete Wavelet Transform (and also Lossy Delta Encoding). The objective is to provide useful information for minimizing data reconstruction errors, and more importantly, make sure they are within a tolerable range. Chebyshev compression is considered in [@7179026] and [@7149287].

Compressed sensing is a new technique. As stated in [@4004], in a series of pioneering works by Candes ([@candes2006], [@4472240],[@1614066]), and their co-authors, it was shown that when a signal has a sparse representation in a known basis, one can vastly reduce the number of samples that are required---below the Nyquist rate and still be able to recover the signal perfectly (under appropriate conditions). This framework suggests compressing the data while sensing it; hence the name compressed sensing. Nevertheless, on the one hand, compressed sensing reduces the number of measurements and the sampling rate, but on the other hand, it increases the computational complexity of the signal recovery ([@8868926]). Actually, the signal is approximately recovered by solving a convex relaxation of a non-convex optimization problem. [@8662558] proposes a unified approach for compression and authentication of smart meter reading in advanced metering infrastructure. In [@7469055] an algorithm is designed which combines the accuracy of standard lossless compression with the efficiency of a compressive sensing framework. It balances the tradeoff of each technique and optimally selects the best compression mode by minimizing reconstruction errors, given the sensor node battery state.

Recently, Neural network-based techniques entered the landscape of IoT data compression techniques. In [@8343232], data are compressed by their regression curve obtained from a neural network. In [@7239543], biomedical signals are compressed using autoencoders. These neural networks are three-stage networks whose input and output dimensions are the same, while the hidden stage has a smaller dimension. The output of the first stage has thus a reduced dimension compared to the input and constitutes the compressed data. Prediction methods are also used. Actually, neural networks are known as universal function approximators with the capability to learn arbitrarily complex mappings, and in practice, show excellent performance in prediction tasks. Thus, the authors of [@8712659] train a Recurrent Neural Network (RNN) predictor followed by encoding with a traditional arithmetic coder block using the probabilities generated by the trained neural network. The decompression is performed symmetrically and requires the trained model for arithmetic decoding. In [@8664582] a prediction scheme is implemented on cluster nodes and cluster heads to reduce data transmission. If the measured data corresponds to the predicted one, it has not to be transmitted. Neural networks (NNs) and, more specifically, LSTMs are proposed to perform predictions.

ML can simplify signal detection by training a general data-driven signal detection model. However, fully connected neural networks would introduce processing latency and extra power consumption, making them unsuitable for deployment on IoT devices. That is why neural networks themselves must be compressed. Therefore, the motivation of [@8885830] is to investigate different neural network compression schemes for system simplification. Three compression strategies are studied, including topology compression, weight compression and quantization compression. These methods show efficient neural network compression with tradeoffs between computational complexity and bit error rate (BER) performance. Also, compression technology through pruning research has gained momentum and is an important tool for improving performance during inference. [@8767300] focuses on pruning unwanted filters and nodes in all layers of a network. The network is pruned iteratively during training, and a significant number of filters/nodes are removed while ensuring any loss in accuracy is within a predetermined range. Other methods exist like efficient convnets, ThiNet and Cross-Entropy Pruning.

Most of the time, IoT solutions are scenario-specific and application-specific and rely on standard layer-2 solutions like LoRaWAN or IEEE 802.15.4. One example of such application-specific solution is [@Di-Vincenzo_Heusse_Tourancheau_2019] that proposes improvements to LoRaWAN communications by fine-tuning the communications parameters to the device's situation (location, number of RGs, scheduling...). However, for interoperability purposes, IPv6 is an obliged interconnection solution, and it raises the issue of header overload. Header compression algorithms like Robust Header Compression version 2 (ROHCv2) from Request For Comments (RFC) 5225 may solve this problem. It sends context information packets like "initialization and refresh" to transmit persistent information to the receiver and consecutive compressed "sequential" packets, which can be decoded from the previously transmitted context. Nevertheless, if context packets are lost due to transmission errors or overflows, sequential packets cannot be decoded. Also, most classical compression algorithms (e.g. delta compression, LSB compression, table-based compression...) assume that an up-to-date reference value exists on the decompressor side; thus, they face the same problem in case of possible packets losses. The solution the authors of [@8891332] is to prepend context information onto sequential packets using Random Linear Network Coding. Another solution is SCHC [@rfc8724] which is a framework that provides both compression and fragmentation functionalities. It is being standardized by the lpwan [@wg.lpwan] working group at the IETF. RFC 8724 and its related works [@wg.lpwan] at the IETF are also closely followed by other SDOs such as IEEE 802.15, LoRa Alliance. It is considered an efficient solution to connecting the LPWANs using IPv6, thus enabling end-to-end IP connectivity. With the help of the SCHC framework, it is possible to compress an IPv6 header from its original size of sixty bytes down to two bytes, thus reducing bandwidth usage and increasing communication efficiency. In [@WF-IoT.moons2019schc], SCHC is used as a unifying transport layer for multimodal LPWAN solutions. The main drawback of SCHC is that it works under the assumption that LPWANs are preprogrammed with known data flows, thus uses a static context. However, this assumption is not always valid in an IoT context, where devices should be accessible from any IPv6 address. In [@8510958] a dummy mapping technique that can effectively compress/decompress some header fields of unknown flows is proposed. The dummy mapping creates a fixed-size list of dummy values mapped dynamically at the gateway compressor to the values of headers fields.

Also, reducing traffic by compression contributes to scalability and optimizing signalling and header information transmission. Over dissemination of packets during Neighbor Discovery (ND) and headers with larger sizes lead to prodigal power consumption leading to short network life in 6LoWPAN (cf. [@7566144]).

Next section

The next section introduces a few security concerns and is available at [[2021112634]]

Security

Generic Approach

Security of IoT devices and infrastructures is an extensively studied subject; there are articles and surveys regarding many aspects of security in IoT, taking into account the strengths, weaknesses and specificities of IoT devices to point out new research opportunities and concerns to improve security.

[@Babar_Stango_Prasad_Sen_Prasad_2011] highlights various needs regarding security for IoT and points out the need to build tailor-made security measures adapted to devices resources, embedded protocols and system specifications. An embedded security framework is also provided to propose a co-design methodology that helps design security features by considering their hardware and software constraints. [@rfc8576] responds to a need for standardization and documentation regarding general points of vigilance when building IoT solutions. It provides a state of the art regarding security threats and risks for IoT as well as security guidelines.

[@Coppolino_DAlessandro_DAntonio_Levy_Romano_2015] studies the vulnerability introduced by bridges between the Internet and non-IP devices connected to a HN. By introducing new hardware or protocols into the network, the system creates attack and defense scenarios that need to be extensively studied as devices need to handle attacks from more powerful attackers. [@Alaba_Othman_Hashem_Alotaibi_2017] uses a similar approach, compares security threats in the IoT, discuss IoT scenarios, analyses possible attacks, and provides insight on security threats and vulnerabilities in the IoT environments. One of the most documented in such IoT environment are sinkhole attacks[@sinkhole_attack_defintion]; these attacks rely on the trust built among devices in a wireless network to build their routing strategy. [@Coppolino_DAlessandro_DAntonio_Levy_Romano_2015] already evokes them, but an extensive study of sinkhole attacks and how to defend against them is provided by [@Kurniawan_Yazid_2017]. [@Kurniawan_Yazid_2017] documents how to detect and mitigate these attacks, how to balance security and usability for devices and which tradeoffs are necessary for these scenarios.

[@Aras_Ramachandran_Lawrence_Hughes_2017] and [@Yang_Karampatzakis_Doerr_Kuipers_2018] document LoRa and LoRaWAN security vulnerabilities and various attack scenarios. [@Aras_Ramachandran_Lawrence_Hughes_2017] focuses on the LoRa technology, studies the LoRa network stack and provides attack scenarios built on existing hardware and technology. [@Yang_Karampatzakis_Doerr_Kuipers_2018] tackles LoRaWAN and points out its vulnerability to replay, man-in-the-middle and battery exhaustion attacks by analyzing the packet exchange between LoRaWAN devices and backend. The attacks scenarios mentioned are put into test through various proof-of-concept.

Rather than focusing on attack scenarios or building security countermeasures specific to given hardware, other papers focus on generic security approaches built regardless of the underlying technology. [@Hong_Kim_Ha_Bae_Park_Jung_Kim_2010] proposes an All-IP IoT architecture to support a complete IP adaptation method for IoT applications around four key topics: mobility, web enablement, time synchronization, and security. [@Cirani_Ferrari_Veltri_2013] indicates that IPv6 will become the de-facto standard for interoperability in IoT and point out security challenges related to processing power in the context of lightweight cryptographic algorithms and standardization. The paper studies the complete IP stack at large regarding IoT constraints and provides an overview of possible solutions to improve IoT systems at each layer. [@Cirani_Ferrari_Veltri_2013] also evokes issues regarding authorization and privacy concerns which will be detailed furtherly.

Authentication

[@Raza_Voigt_Jutvik] proposes a key management solution to handle the IPSec key exchange as well as support 802.15.4 channel securitization.

[@Garcia-Morchon_Wehrle_2010] details specific needs for medical IoT regarding authorization such as privacy requirements or data confidentiality, taking into account specific constraints from resource-constrained devices. The paper proposes a context-aware security architecture handling access control and privacy-preserving data silos and provides an access control engine running on resource-constrained sensor nodes.

[@Roman_Alcaraz_Lopez_Sklavos_2011] details key exchange scenarios in WSN to establish a secure channel to protect the data transmitted over the air. Various scenarios are described, such as public-key cryptography and PSK. Backend considerations are also considered. [@Fongen_2012] studies identity management systems to support data integrity protection and proposes a framework for authentication suited for IoT environments.

[@Yao_Han_Du_Zhou_2013] propose an authentication mechanism based that uses multicast communications to save transmission during the authentication handshake for resource-constrained devices, evaluating its performances and analyzing the security paradigms in place to support IoT development despite its constraints. [@Sanchez_Lopez_Gomez_Skarmeta_2013] is a reflection on authentication, authorization and accounting on constrained devices by leveraging the PANA (Protocol for carrying Authentication for Network Access) paradigm, which was ongoing work at IETF back in 2013. The paper provides a study of the EAP/PANA paradigm in constraint devices and an implementation that serves as a proof of concept to both the IETF standardization community and the scientific community. The paper is based on a Contiki implementation of EAP/PANA called PANATIKI based on simulations and results from an experimental testbed.

[@Kothmayr_Schmitt_Hu_Brunig_Carle_2013] presents a two-way authentication scheme based on the Datagram Transport Layer Security (DTLS) protocol. The authors provide a solution based on existing standards and protocol to embark the algorithm on 6LoWPAN EDs and evaluate the solution through experiments. [@Singla_Mudgeri_Papapanagiotou_Yavuz_2015] targets V2X communications building a delay-aware, reliable, scalable and secure network. The paper aims to provide insight on the handshake mechanism to build for such systems considering their constraints (mobile devices, protocol overhead, transmission delays) while keeping the system reliable. The proposed mechanism reduces delays in the handshake mechanism by leveraging the capabilities of edge infrastructure to reduce delays and improve the efficiency and reliability of vehicular communications.

[@Cirani_Picone_Gonizzi_Veltri_Ferrari_2015] uses the CoAP protocol to propose an authorization framework that can build authorization based on an external OAuth authorization service (OAS). The proposed scenario benefits from the OAS's strength while keeping the solution with IoT's usual constraints: low processing load, customizable and easily scalable. The solution is not energy efficient due to the multiple transmission necessary to fragment the messages but is efficient regarding other primordial aspects such as memory footprint. The solution is also efficient for developers as OAuth is a well known, well-documented technology and the solution benefits from the existing implementation of the OAS paradigm.

Scalable Authentication and Authorization framework compatible with different IoT technologies

:

Authentication, Authorization and Accounting (AAA) functionalities are usually consolidated in a single centralized database [@auth_services]. The centralized AAA framework has its advantages but also has significant disadvantages, such as creating a single point of failure, and the issue of consolidating all user information into one database would probably go against European's General Data Protection Regulation. Blockchain using distributed ledger has been experimented and deployed[@block_cyb_priv][@block_aaa] to accomplish a scalable de-centralized Authentication and Authorization AAA framework. However, the blockchain model has several drawbacks as a feasible operational model [@distr_pki] in an open/global scenario.

eduroam uses the distributed Public Key Infrastructure (PKI) based on X.509 digital certificates for AA. The PKI model has been tested both on the Internet and in IoT for dynamicity and scalability. The primary issue with the X.509 digital certificates is their size and compatibility with resource-constrained IoT networks. Since our focus is on Organizational Interoperability between the networks in the federation operating in the IP space, we plan to employ PKI for AA.

eduroam uses a combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP) and RADIUS to provide [@rfc7593] AA of the Wi-Fi ED to the network. The trust fabric in eduroam is a PSK between the RADIUS servers (organizational, national, global) based on the DNS hierarchy. The organizational RADIUS servers agree on a shared secret with a national server, which agrees on a shared secret with the root (i.e. global) server. The RADIUS hierarchy forwards user credentials securely to the users' home institutions for verification and validation.

Such a trust fabric, wherein there is a PSK to be shared hierarchically, hinders the federated model that we envision for IoTRoam. Different IoT networks use different mechanisms to share the PSK between the ED and the AA servers on the Internet to securely onboard the ED in the HN. Forcing them to transition to a newly proposed PSK mechanism is not operationally possible since multiple stakeholders are involved. For secure onboarding of the ED, we will use the existing mechanisms used by the respective IoT technologies and propose a global mechanism tested on the Internet to mutually authenticate different servers (in IP space) in the federation involved in ED onboarding.

Using a combination of an existing PSK mechanism and a global PKI mechanism proposes a design that satisfies the requirements outlined by WBA for a scalable (even when there are millions of networks interconnected in the federation) AA framework applicable for all IoT technologies/applications.

Authentication at IETF

:

IETF worked on designing authentication frameworks, one of them was the Protocol for Carrying Authentication for Network Access (PANA) [@rfc5191] designed by the pana working group. According to its charter[@wg.pana], the pana working group aims to build generic frameworks to support authentication in various scenarios around mobile IP networks. The working group proposed 6 Standard RFCs detailing each component necessary to build such a security framework as part of its work.

Authentication frameworks were also proposed for adoption to other working groups, [@draft.dcaf] proposed to the Constrained RESTful Environments (core) working group, then to the Authentication and Authorization for Constrained Environments (ace) working group to work on Delegated CoAP Authentication and Authorization Framework (DCAF). The objective of DCAF was to delegate authorization and authentication information to a trusted third party with less processing limitation than the constrained device that requires it.

Trust

Trusting a third party or a communication peer is an important issue when discussing security in general and IoT security in particular. IoT's constraints regarding processing power and needs for energy efficiency usually come with a necessity to rely on others to delegate certain operations. Building and evaluating trust frameworks when working with constrained devices has been a subject of interest since the beginning of IoT research.

[@Liu_Wang_2010] summarizes the issues and requirements for building trust within heterogeneous networks. The main topic studied is building trust regarding routing protocols and trusting peers when bridging the connection. Another studied aspect of building trust to decide where to route the traffic consists in creating a network trust model to decide which level of trust a device gives to another peer. In trust delegation models, another critical aspect is deciding on a key exchange and management policy; the paper evokes possible protocols to exchange keys and negotiate trusted channels.

[@Chen_Chang_Sun_Li_Jia_Wang_2011] proposes a trust management model based on building a fuzzy reputation system within the IoT network. The article extensively studies trust in networks, then uses the NS-3 simulator to generate traffic and build trust within the IoT network. The proposed mechanism, TRM-IoT, performs better regarding routing performances, packet loss and other network metrics while keeping the system lightweight and within IoT specific constraints but seems less reliable when attacked by malicious third parties. [@Nitti_Girau_Atzori_Iera_Morabito_2012] proposes to establish trust models by building social reputations between devices the same way reputation is built within human social networks. Contrary to [@Chen_Chang_Sun_Li_Jia_Wang_2011], the simulations from [@Nitti_Girau_Atzori_Iera_Morabito_2012] show many benefits regarding excluding malicious nodes within the network based on a feedback system that evaluates trust level based on nodes centrality.

[@Quan_Gui_Xiao_Tang_2012] studies WSNs in a countryside environment, builds a trust framework and experiments upon it. The model shows interesting results regarding data reliability and isolation of malicious nodes.

[@Bao_Chen_2012] identifies trust issues within heterogeneous network environments and builds a trust consensus based on social IoT paradigms in a similar way to [@Nitti_Girau_Atzori_Iera_Morabito_2012] but focusing on other key aspects on building trust within a network such as handling large scale infrastructure and taking into account devices capabilities in terms of storage and processing power. The approach is studied furtherly in [@Bao_Chen_Guo_2013] with additional analysis regarding trust assessment and trust convergence time. The tradeoff between these two is studied and show significant results compared to non-trust-optimized systems.

[@Gessner_Olivereau_Segura_Serbanati_2012] concerns itself with building reliable IoT infrastructure while keeping the system privacy-preserving and building trust into the network. Their system relies on a trust policy handler that defines operations between devices, a key management component that assists in securing communications, an identity manager and a reputation manager that assists in trust management within the network. Their system provides a generic approach to IoT security but, as they point out, lacks an actual proof-of-concept. [@Yan_Zhang_Vasilakos_2014] described extensively the issues and solutions regarding trust management in IoT and [@Abera_Asokan_Davi_Koushanfar_Paverd_Sadeghi_Tsudik_2016] surveys trust establishment in IoT.

Privacy

[@Chiang_Wang_Liau_Hsu_2005] proposes a framework to measure possible invasion of privacy in protocols using a mathematical method. However, this method does not apply to all protocol as the protocol need to fit certain algebraic properties but should apply to IoT specific solutions. [@Lioudakis_Koutsoloukas_Dellas_Kapellaki_Prezerakos_Kaklamani_Venieris_2007] proposes a technical solution to enforce privacy protection using a middleware system as a privacy broker. [@Mendez_Papapanagiotou_Yang_2018] sums up many challenges within IoT systems regarding privacy protection and security. [@Huang_Fu_Chen_Zhang_Roscoe_2012] aims to improve privacy protection in IoT using a solution that gives control to the user and then designing complex privacy policies and filters. Such a solution aims to identify finely all the elements that need access to personal data and which specific access they need.

The question of privacy is not only a technical issue to monitor but a transverse issue to address from various experts, not only from the computer science field. [@Peppet_2014] is a multi-disciplinary approach study that reflects on privacy and security of IoT hardware, software and protocols from a regulation point of view. It extensively studies sensors networks and the possibility of break privacy protections, creating discrimination, or making more secure devices with a combined juridic and technical approach.

[@Kubler_Framling_Buda_2015] proposes a novel approach around Quantum Lifecycle Management (QLM) that allows devices to keep communicating, bypassing firewalls. Such a solution, should it work, would prove interesting regarding access to information from isolated devices but also pose real threats regarding security from a generic point of view, especially with regards to the issues discussed by [@Peppet_2014].

To support all threats identified in the previous papers, [@Lai_Li_Liang_Lu_Zhang_Shen_2014] proposes a conditional privacy-preserving authentication with access linkability (CPAL) for roaming service. The idea behind CPAL is to offer a secure roaming service that respects user's privacy using a multi-layer approach to information access within the system. The system and its performances are also studied to prevent the solution from being too heavy for IoT solutions. [@Wan_Xu_Liu_Ni_Ye_2020] also defines a roaming protocol for IoT solutions exploiting the strength of edge computing to authenticate the devices. The solution seems to protect against various known attacks, and simulations underline interesting authentication delays and energy consumption results.

Next section

The next section introduces the notions of coverage and roaming, available at [[2021112635]]

Coverage and Roaming

Device mobility management is one of the most important points when designing an IoT system. When working with things as fridges or doors, mobility would not be significant. However, mobile devices such as sensors, watches, phones, luggage or cars should be provided coverage as often as possible.

Many parameters are considered when handling mobility, such as covered devices' output power, antenna direction, data payload, speed, size, environment, and duty cycle. Much of these parameters are also encountered on the RG side.

Coverage evolution is a well documented subject (cf. [@andreev_understanding_2015] [@sanchez-iborra_state_2016] [@bardyn_iot:_2016] [@persia_nb-iot_2017] [@tadayoni_internet_2017] [@palattella_enabling_2018] [@ayoub_internet_2019], [@Attia_Heusse_Tourancheau_Duda_2019]). As IoT developed outside of its small scale industrial use, the need for coverage became prominent and new technologies were introduced [@zorzi_todays_2010] to increase the scale from which to connect things [@group_internet_2015]. Consumer IR, Bluetooth, Wi-Fi, which are still developed as of today. But also long coverage communication ([@bardyn_iot:_2016] [@tadayoni_internet_2017]) ranging up to tens of kilometers such as LoRaWAN (cf. [@vangelista_long-range_2015] [@vangelista_worldwide_2019]), Sigfox, Narrow-Band IoT (NB-IoT). Network topology may also change the way mobility is handled. [@andreev_understanding_2015] gives a unique perspective on the way to improve coverage and mobility, though Machine-to-Machine Technologies, listing the then-emerging Unlicensed LPWAN and evolutions to the 3GPP Standard (also known as LTE-M and NB-IoT). Vehicular networks are an excellent example of the evolution of M2M networks and how mobile M2M networks can use their environment's infrastructure as good support to mobility [@10.1007/978-981-16-0965-7_55]. [@sanchez-iborra_state_2016] after an overview on various IoT technologies, from short-range technologies such as ZigBee, Bluetooth and Wi-Fi to long-range such as GSM, LTE and Satellite, provides a complete overview of LPWANs offers in the context of Industrial IoT and listing their strength and limitations. LPWANs are presented as a good opportunity regarding coverage, with an evolving community developing interesting standards and with increasing deployment. LPWANs also enable new channels to communicate as a substitute or a complement to the existing GSM networks [@bardyn_iot:_2016]. Coverage was also studied through simulations, [@duda_spatial_2019] provides an extensive study on LoRaWAN performances through a study on packet delivery in a realistic context and aim to provide reference assumptions and numbers for people willing to modelize a LoRaWAN infrastructure. [@Attia_Heusse_Tourancheau_Duda_2019] expands this work by providing numerous measurements on link quality based on actual LoRaWAN payloads, studying Packet Reception Ratio based on Packet Length, Spreading Fractor (SF) or Signal to Noise Ratio. Their experiments show that the most significant impact on LoRaWAN communication comes with the scalability of the solution as the recommendation is to group data transmit long payload instead of short chirps to prevent packet losses from interferences from other devices. [@persia_nb-iot_2017] studies theoretical LoRaWAN and NB-IoT coverage for connecting smart meters. The solution aims to cover a whole population with various population densities (urban, suburban, rural) and device positioning (deep indoor, indoor and outdoor). This document also points out the importance of network deployment to enable an efficient service.

On the other hand, development on roaming was less significant compared to coverage. Roaming is an essential factor if one wants to improve its mobility. While coverage is important when considering small scale mobility (neighborhood, warehouses... ), roaming is the technology to develop to improve coverage for things moving far from their HN. Roaming allows building a network of interconnected antennas from various partners to provide universal access to the network.

This lack of development regarding roaming in IoT-enabling technologies is pointed out by [@andreev_understanding_2015] as roaming seems to be an excellent way to improve coverage in Smart Cities. This is especially important in a dense area where antennas might interfere a lot.[@sanchez-iborra_state_2016] while providing many details regarding coverage, data rates and energy consumption, does not provide much input regarding roaming. Only pointing out that each technology handles roaming. [@ghaleb_mobility_2016] draws a comprehensive view on connecting WSN to the IP world and provides a lot of insight on mobility management for devices. The authors point out that key improvements to develop new efficient IoT systems are energy efficiency, security and operational autonomy of mobile nodes.

Roaming improvement might also come from enabling dual connectivity for a device. Thus [@palattella_enabling_2018] provides insight on various projects worldwide improve LPWA communications by plugging it into a satellite network as a backup link. [@ayoub_internet_2019] provides a complete comparative study of various LPWAN technologies, providing numbered information on mobility support, deployment cost comparison, packet loss, energy management, mobility latency. The study also put the solutions studied into perspective with other operated mobile networks (GSM, LTE) and provides insight on various possible use cases from asset tracking to healthcare. Vangelista et al. in [@vangelista_worldwide_2019] sums up recent LoRaWAN Standards evolution regarding roaming and other improvements. LoRaWAN is presented as the most promising candidate for worldwide interoperability and connectivity.

In this context, researchers have proposed various solution to mobility issues allowing for a user to access its data wherever his device is located. Most of them focus on gathering the user data using various solution, from data aggregation [@fredj_scalable_2013] [@almajali_framework_2018] to publish/subscribe mechanisms [@hakiri_publishsubscribe-enabled_2015] [@luzuriaga_handling_2015]. Researchers also looked for ways to trace devices in order to fit the network to their movements [@wu_ubiflow_2015] [@bera_mobility-aware_2016] [@meddeb_afirm_2018]. Finally improvements to the infrastructure were also studied from implementing a blockchain-based mechanism [@durand_resilient_2018] [@bezahaf_bcwan:_2018], devices improvements were proposed [@chun_mobile_2015] and interoperability solution were evoked [@persia_nb-iot_2017] [@BWCCA.ayoub2019schc].

[@fredj_scalable_2013] uses aggregation and clustering to search services in a pool of IoT devices. It uses a semantic-based approach to explore heterogeneous networks using a decentralized approach to aggregate information fast and precisely. Their method theoretically ensures an accurate search system and shows good experimental results regarding time efficiency. In [@almajali_framework_2018], Almajali et al. study mobile edge computing under the scope of mobility. They focus on highly mobile devices and solutions to improve device connectivity in unusual mobility cases.

[@luzuriaga_handling_2015] proposes a solution that consists in improving the MQTT to fit better to mobile scenarios. By managing data using an MQTT internal buffer, devices can re-deliver all their messages in the correct order even when some packets are lost or the connection is interrupted.

[@hakiri_publishsubscribe-enabled_2015] explores how Software-Defined Networking paradigms might work in accord with a Data Distribution Service to create an efficient publish/subscribe mechanism as network backend to IoT infrastructures while addressing some key challenges to IoT infrastructures such as interconnectivity with an existing and standard network, mobility, service discovery and scalability.

[@wu_ubiflow_2015] also builds an infrastructure based on Software-Defined Networking, which is used to divide the territory spatially in order to follow the devices and adapt the backend infrastructure based on its movements. Their solution also presents a global view on the network, which is acceptable for home networks but might present issues in a fully interoperable infrastructure with multiple actors and solutions. [@bera_mobility-aware_2016] uses Software Defined Networking to manage flows in order to efficiently forward data to a given location thanks to an efficient path estimator and flow manager. The solution tries to predict the path taken by a flow based on prior observations, thus reducing message overhead and energy consumption for flow tables. [@meddeb_afirm_2018], with AFIRM (Adaptive Forwarding based Link Recovery for Mobility support) tries to use Named Data networks as a middle layer to support IoT mobility. Through an extensive study on routing, Meddeb et al. compare their solution to other approaches by studying data availability in a sensor mobility context.

[@durand_resilient_2018] explores a different solution. Exploiting the capabilities of blockchain, the authors propose a fully decentralized LPWAN backend. Using blockchain allows building trust between networks, roaming agreements as smart contracts and resolving identities using a blockchain application. The paper builds a decentralized LoRaWAN architecture that would support roaming without building complex roaming agreements between partners. [@bezahaf_bcwan:_2018] also presents a blockchain-based infrastructure, building a federation using blockchain to enable truthful exchanges at the cost of around 0.5 to 2 ms loss in latency and which makes it hard for users outside of the federation to take control of the exchanges.

[@chun_mobile_2015] creates a protocol called CoMP (CoAP-based Mobility Management Protocol) which keeps track of devices address and enable reliable data delivery when communicating. This solution can mitigate packet loss while keeping a short retransmission delay and handover latency.

In their work ([@BWCCA.ayoub2019schc]), Ayoub et al. exploit the newly-developed SCHC framework as a workaround to support roaming between LoRaWAN operators. They introduce an Application Mobility Service (AMS) in the LoRaWAN architecture which is contacted by the device using IPv6 after SCHC compression and is used to prevent uplink message repetition and improve session continuity.

Next section

The next section is an introduction to DNS, available at [[2021112636]]

DNS

How it works

DNS is a distributed lookup service used to translate between domain names and IP addresses. It already exists and is global. It is the most efficient, open and scalable system for name resolution. There can be no communication on the Web like email or web page resolution without DNS. At the beginning of the Internet, a simple host.txt file located on a single computer was responsible for the translation between IP addresses (such as 192.134.5.37) and domain names (Such as "www.afnic.fr"). As Internet grew Paul Mockapetris designed a more suitable distributed database (RFC 1034 [@rfc1034] and RFC 1035 [@rfc1035]) which is the DNS.

A host who wishes to access the web page of "www.afnic.fr" uses a client application such as web browsers or mail clients on the host computer. Such applications send a request to the local DNS resolver in the local Operating System (OS). The DNS resolver will invariably have a cache containing recent DNS lookups. If the cache can answer the request, the resolver will return the value in the cache to the application that made the request. If the cache does not contain the answer, the resolver will send the request to one or more designated DNS servers.

Assuming that the answer is not found in the local cache of the hosts computer, the resolver (client) sends a UDP recursive query to one of its configured local nameservers. In the case of home users, it will mostly be their Internet Service Provider(ISP). The local nameserver, in turn, looks for the answer in its local cache and, if an appropriate record is found, returns the cached address to the client.

On the contrary, if the answer is not found in the cache of the local nameserver, then the burden of finding the response for the resolver's query becomes the responsibility of the local name servers. The local nameserver queries the root nameserver for the address of www.afnic.fr. There are 13 root servers (from a.root servers.net to m.root servers.net). The root server process the query, and even though it does not know the address of www.afnic.fr, it knows that the information should be under the control of the "Top Level Domain (TLD)" fr servers. In this case, one of the root servers will refer the query to the .fr nameservers. The local nameserver asks the .fr nameserver the same question and is referred to the "afnic.fr" nameservers. Finally, the local nameserver asks "afnic.fr" nameserver for the queried domain name address and gets the answer.

DNS has been studied since its first RFCs were published. [@Jung_Sit_Balakrishnan_Morris_2002], the reference paper within the ecosystem, first documented DNS effectiveness compared to its concurrent solutions, as well as DNS latency and DNS cache hit rate within a university campus. [@Danzig_Obraczka_Kumar_1992] provides additional insight regarding caching efficiency within a network, [@Danzig_Obraczka_Kumar_1992] also documents the quantity of DNS queries and responses observed compared to the overall traffic within their campus. [@Osterweil_McPherson_DiBenedetto_Papadopoulos_Massey_2012] is a greater study that evaluates the responses from the .net and .com TLDs. The article also drafts a definition of a "normal" DNS resolver, leading them to study DNS "top-talkers", the  40000 resolvers that account for 90% of the traffic DNS in 2012. [@Pappas_Xu_Terzis_Lu_Zhang_Massey] studies DNS wrong configuration and its consequences (packet loss, NX domain, increase in latency ...) by studying various configurations (random sampling, zone transferred, 500 most popular web servers...) based on a custom DNS resolver.

Standards

The IETF is responsible for DNS-related standardization in RFCs. Initial discussion about having a structure such as the DNS started with [@rfc819] based on the domain concept. [@rfc974] discusses how the domain concept could be used for mail routing. [@rfc1034] defines the concepts and [@rfc1035] describes how the concepts could be implemented. There have been several RFCs focus on the type of Resource Records (RRs) used in the DNS starting with [@RFC1183] which specifies the five new DNS types for experimental purposes, [@rfc2052] for specifying the location services, [@rfc2168] to specify the type on how the URIs could use the DNS and so on.

Another category of DNS standardization is on clarification of existing standards, such as [@rfc2181] clarifying the initial DNS specifications in [@rfc1034] and [@rfc1035]. There are number of standards on DNS Operational issues such as [@rfc1537] on common DNS data file configuration errors, [@rfc1912] on common DNS operational and configuration errors, [@rfc2010] on operational criteria for Root Name servers and [@rfc2219] on use of DNS aliases for Network Services.

As per Bert Hubert [@dns_camel] there are about 297 RFCs related to DNS. Hence it is impossible to provide an exhaustive list of all DNS related standardization documents. There have been even efforts from the DNS community to limit the number of Standards in the DNS [@herding_dns_camel]. The reason being with the growth in the DNS standards over the past three decades, it has become nearly impossible for DNS developers and users to read thousands of pages of standards work before any DNS related implementation could be done.

DNS Evolutions

As mentioned in the previous section [@dns_camel], DNS is a vast domain in constant evolution from the first DNS standard published [@rfc819]. It should be noted that this section will not mention every modification related to the evolution of DNS; instead, we will focus on four specific aspects of DNS evolutions:

• the evolution to the transport of data over the network: DNS over DTLS, DNS over TLS, DNS over HTTPS and DNS over QUIC; that secures the link between the server and the user.

• the signature of DNS authoritative zone, with DNSSEC, which authenticates the integrity of the data sent from the server.

• the integrity check enabled by the use of DANE to countersign data and certificates

• the new paradigms introduced by the development of DNS-SD to improve local network self-configuration

All these aspects will be studied in the following part of the chapter.

Transporting DNS information securely

From the beginning of its use, DNS was mostly based on UDP connections, which allowed quick exchange between client and server without maintaining sessions or keeping track of packet losses . But DNS supported different possibility to transport its content from the first RFCs ([@rfc1034][@rfc1035]), as "queries are carried in UDP datagrams or over TCP connections" [@rfc1034].

Thus DNS evolved to support additional transport layers, including more secure transport to encrypt its payload and prevent malicious third parties to listen to, intercept or modify DNS payloads. Its first notable development is the support for TLS encrypted channel usually called DNS over Transport Layer Security (DNS over TLS or DoT, RFC 7858 [@rfc7858]) and its equivalent over Datagram Transport Layer Security (DNS over DTLS, RFC 8094 [@rfc8094]). The work from RFC 7858 [@rfc7858] aims to prevent eavesdropping from attackers as described in [@rfc7626] by transporting both the DNS query and response over a TLS channel. The TLS connection was kept standard to support interoperability and stick to well-known implementations of the protocol. RFC 8094 [@rfc8094], written around the same time, proposes to use DTLS implementations instead of TLS to prevent head-of-line blocking as well as to reduce the necessary handshake from TCP.

The issues behind DNS queries over TLS, which lead to the development of RFC 8484 [@rfc8484], were twofold. On the one hand, it was noticed while developing DNS over TLS that the channel might be censored for technical or political reasons; thus, finding another way to transmit the information was deemed necessary to prevent "on-path devices from interfering with DNS operations". On another, as the most common use for the general public of the Internet is through a web browser, exploiting web technologies to share its channel consistently with Cross-Origin Resource Sharing (CORS) best practice and exploiting the capabilities of recent web browsers. Thus came DNS Queries over HTTPS (DoH), labeled RFC 8484 [@rfc8484] to support these evolutions.

Another evolution today up for discussions is embedding DNS queries over QUIC. QUIC is a protocol developed by Google's team to improve the performance of their browser Google Chrome. QUIC relies on recent development and best practices from transports protocols to provide secure, fast and reliable encrypted communications over UDP. QUIC combines the low connection set up time and head of queue blocking from UDP with the retransmission efficiency and support from long messages from TCP while supporting the encryption and authentication introduced by TLS or DTLS. The current version of the DNS over QUIC draft is accessible through ([@draft.dns_over_quic]).

These standards were also backed by performance measurements, tests and considerations by the research community. [@Hounsel_Borgolte_Schmitt_Holland_Feamster_2020] studies the tradeoff from the loss in response time and packets that comes from securing and improving reliability when navigating the Web by comparing the response times from classic DNS (DNS over UDP or Do53), DoT and DoH. [@Doan_Tsareva_Bajpai_2021] provides additional information regarding DoT resolution with RTTs around 15ms for traditional DNS resolution and RTTs over 100ms for DoT use. They observe that securing DNS resolution with DoT comes with a 100ms tradeoff and multiplies the DNS response time by a 7-factor.

DNSSEC, signing a DNS authoritative zone

An important set of standards concerning DNS involves extending the DNS infrastructure for security purposes. DNS security extensions provide origin authentication and integrity assurance services for DNS data, including mechanisms for authenticated denial of existence of DNS data. [@rfc4033] provides an introduction to DNS security and requirements, [@rfc4034] defines the RRs for the Domain Name System Security Extensions (DNSSEC), [@rfc4035] on the modifications required in the initial DNS protocols following the introduction of DNSSEC. [@rfc4398] on storing certificates in the DNS, [@rfc5155] on DNSSEC hashed authenticated denial of existence and [@rfc6014] algorithm identifier allocation of DNSSEC.

DNS as an external integrity checker with DANE

Another important security extension envisioned with the DNS infrastructure is to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using DNSSEC [@rfc6394]. The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA [@rfc6698] standardizes a way to authenticate TLS client and server entities with and without a certificate authority. [@rfc7218] precises acronyms to replace numerical values and simplify conversations about DANE, [@rfc7671] Updates the DANE protocol and also provides Operational Guidance. [@rfc7672] adds SMTP Security via Opportunistic DANE TLS, [@rfc7673] adds the usage of SRV RRs with DANE and RFC 7929 [@rfc7929] adds DANE Bindings for OpenPGP.

Discovering services using DNS

Standardizing Services discovery using DNS is the work of a specific group within the IETF called Extensions for Scalable DNS Service Discovery (dnssd) [@wg.dnssd]. Born from the work from IETF Zero Configuration Networking (zeroconf) [@wg.zeroconf] working group, from Stuart Cheshire and Marc Krochmal's independent RFC DNS-Based Service Discovery (RFC 6763) [@rfc6763] and upon the work from Apple Computer Inc.'s trademark, Bonjour algorithm. DNS-SD and hostname resolution aim to provide a framework for users and devices to automatize configurations, advertize services and connect to them.

The working group proposed two standards: DNS Push Notifications [@rfc8765], and Discovery Proxy for Multicast DNS-Based Service Discovery [@rfc8766], and three informational RFC: Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions [@rfc7558], Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery [@rfc8222] and DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements [@rfc8882] to pave the way for possible implementations of DNS-SD applications from anyone on the market.

zeroconf working group published a single RFC [@rfc3927] that paved the way for devices' self-configuration on the network. Their Dynamic Configuration of IPv4 Link-Local Addresses provides a method for hosts to automatically configure their IP interface with an IPv4 address for Link-Local communications. This solution uses the 169.254/16 IPv4 prefix registered for this specific purpose and is not routed on the Internet.

Then RFC 6763 [@rfc6763] provides the first insight on using DNS for services discovery; it provides insight on structuring DNS resource records to facilitate service discovery. The document describes the necessary tools to deploy a self-configuration mechanism and support it within a local network, then describes a standardized syntax for devices to provide their identity and describe their services within the network. Finally, the document describes service discovery and how devices may access the data advertised by their network peers.

Evolutions to RFC 6763 were necessary to improve the solution's scalability, solve security concerns and extend the work from the RFC's author. Thus the dnssd working group came to provide these extensions.

RFC7558 [@rfc7558] paved the way by providing the requirement to improve the scalability of DNS-SD extensions, and RFC 8222 [@rfc8222] provided standardized labels to use when designing, advertising and researching a service using DNS-SD. RFC 8765 [@rfc8765] is a first step to improve scalability by standardizing updates to a DNS-SD database, by updating a local DNS zone of authority and by reversing the standard use of DNS from its polling principle where users request information to a notification, publish/subscribe approach. RFC8766 [@rfc8766] specifies a proxy mechanism that uses Multicast DNS to discover records and push them into a DNS namespace, thus providing a localized and centralized point within the local network that contains advertised services from other devices instead of asking them to listen to every advertisement and save them in their memory. This proves especially interesting in the IoT scope, where devices are not always listening to all communications.

DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements[@rfc8882] provides advice and insight on implementing secure DNS-SD services. The RFC analyzes different scenarios, the RFC proposes various requirements to implement secure and privacy-preserving mechanisms to support DNS-SD-enabled communication. The document does not provide many solutions to its scenarios but asks all the questions necessary in a DNS-SD context regarding client and server security requirements to support new contributions in the DNS-SD community.

DNS-SD was also studied by the scientific community ([@Jara_Martinez-Julia_Skarmeta_2012], [@Djamaa_Richardson_2014], [@Stolikj_Verhoeven_Cuijpers_Lukkien_2014], [@Stolikj_Cuijpers_Lukkien_Buchina_2016], [@Ismail_Kastner_2016], [@Kaiser_Waldvogel_Strittmatter_Haase_2016], [@Kim_Lee_Jeong_2017], [@Klauck])

[@Jara_Martinez-Julia_Skarmeta_2012] listed the first requirements for DNS-SD in IoT applications. Requirements that were expanded and studied in a thesis [@Klauck] that proposed to connect the Smart Objects to the IP world using a combination of XMPP for messages and mDNS/DNS-SD for service discovery. [@Klauck], in his PhD defense, proposed various adaptation layers for IoT, including a lightweight Bonjour implementation called uBonjour and a lightweight XMPP Stack called uXMPP2.

[@Djamaa_Richardson_2014] developed a discovery protocol based on DNS-SD in Contiki OS and identified issues to solve in order to propose an efficient and interoperable service discovery for IoT. [@Stolikj_Verhoeven_Cuijpers_Lukkien_2014] also proposed such a solution for constrained devices based on Apple's mDNS/DNS-SD implementation and extended their work in [@Stolikj_Cuijpers_Lukkien_Buchina_2016] to propose scalability improvements to their solution to support large scale IoT deployments.

In [@Ismail_Kastner_2016], an extension to DNS-SD paradigms for Industrial IoT is proposed, and its reliability, efficiency and latency is tested extensively and show promising results. [@Kaiser_Waldvogel_Strittmatter_Haase_2016] proposed enhancements to the DNS-SD standard by exploiting the capabilities of DNS caches using techniques from the stateless DNS (sDNS) community. [@Kim_Lee_Jeong_2017] continues the work on Service Discovery for IoT by leveraging the capabilities from DNS Name Autoconfiguration (DNSNA) implemented with a CoAP stack to support user configuration, monitoring and remote control.

Next section

The next section, [[2021112637]], introduces a few notions on Machine Learning.

Machine Learning and IoT

Artificial Intelligent approaches are efficient solutions to many issues, [@8343232] is such an example where neural networks are exploited to support IoT specific issues such as improving compression capabilities by compressing data. Autoencoders are another interesting neural network approach to compression in IoT applications ([@7239543])

Our work regarding Artificial Intelligent approaches for IoT applications mainly relies on improvements to compression techniques. A state-of-the-art on compression techniques, backed by such approaches, is provided at the beginning of [[202111266]] in section [[2021112662]]. This section will mostly summarize other Artificial Intelligent approaches related to IoT solutions to provide insight on possible applications of the techniques developed by researchers from this field to IoT solutions.

Leveraging Artificial Intelligent approaches in IoT contexts usually consist of two possible solutions: leveraging AI to exploit IoT data or empowering IoT devices using AI technologies.

An excellent example of leveraging AI to exploit IoT data is encountered in Industrial IoT use cases, for which sensor deployment can be massive and controlled and in which data can be centralized and easily exploited. [@Sun_Liu_Yue_2019], for example, exploits a framework build on cloud technologies to propose edge AI in an IIoT context, in which IoT data is pushed to the edge where data is processed. [@Calo_Touna_Verma_Cullen_2017] reduces processing time in edge computing required in IoT applications by exploiting the resources from cloud infrastructures. [@Li_Ota_Dong_2018] evaluates deep learning approaches in a combined IoT/Edge environment. [@Lv_Qiao_Verma_Kavita_2021] also exploits the edge infrastructure to improve IoT applications using a complex storage/processing system between edge and cloud to optimize all the tenants in processing IoT devices efficiently and with low latency.

Two other scenarios are usually studied: healthcare and agriculture. In [@Pandey_2017], IoT devices are used to monitor a patient's heartbeat rate, and ML detects stress based on heartbeat data and enhances patient care based on its physiological condition. [@D._2019] proposes a combination of sensors, actuators and edge computing for smart farming with improvements in terms of resources scheduling compared to classic approaches. [@Debauche_Mahmoudi_Mahmoudi_Manneback_Lebeau_2020] and [@Debauche_Mahmoudi_Elmoulat_Mahmoudi_Manneback_Lebeau_2020] build systems for water grid management that combines sensors and actuators to manage the water infrastructure according to the needs detected by the combination of real-time measurements and predictions. [@Debauche_Mahmoudi_Elmoulat_Mahmoudi_Manneback_Lebeau_2020] also exploits edge computing infrastructures to process videos, manager fertilizers supply and treat plant diseases and pests.

[@Piccialli_Cuomo_Cola_Casolla_2019] exploits data collected in a museum from IoT devices to classify users behaviour to provide insight regarding customers to the museum stakeholders. [@Adi_Anwar_Baig_Zeadally_2020] summarizes a lot of these approaches and provides a framework to exploit federated learning between IoT applications and exploit sensor data and behavior from other applications to kickstart IoT applications based on ML data analysis.

Many approaches for empowering IoT devices exploiting the strengths of AI consist of security enhancements, in [@Cañedo_Skjellum_2016] proposes to embark a ML component within an IoT gateway to detect traffic anomalies. [@Xiao_Wan_Lu_Zhang_Wu_2018] investigates attack models in IoT systems and present various machine-learning (ML) techniques for authentication or access control to protect users and data privacy. [@Alrashdi_Alqazzaz_Aloufi_Alharthi_Zohdy_Ming_2019] analyses network traffic from IoT devices in a smart city environment to propose an Anomaly Detection system for IoT devices to detect compromised devices and mitigate attacks. [@Lv_Qiao_Kumar_Singh_Wang_2021] exploits ML capabilities to improve LoRa communications security and avoid security threats at the cost of scalability.

The LIMITS (LIghtweight Machine Learning for IoT Systems) [@Sliwa_Piatkowski_Wietfeld_2020] open-source framework is an interesting tool that proposes to validate and assist in integrating ML models in IoT applications. Such a solution helps developers and researchers to design embedded trained ML models onto sensors by estimating the feasibility of their project. Unfortunately, it cannot take into account framework-specific dependencies and keeps a generic approach.

Our approach differs from the approaches from this section as our work consists in embedding ML algorithms directly onto devices and realize ML-based calculations despite their constrained storage and processing power.

Next section

The next section summarize all the previous ones and discuss their relation with regards to the rest of the manuscript [[2021112638]]

Discussion

Our readings regarding IoT, naming and its related applications lead us to work on various subjects. The general state of the IoT and its expected growth within the next years justify our approach to focus on interoperability and other performances challenges within IoT ecosystems, such as scalability or mobility support. These challenges lead us to study the possibility offered by querying mechanisms for IoT solutions, and their associated systems such as ONS [@ons], ORS or the Handle system.

The issue of querying mechanism is vast; thus, we focus on data storage, data retrieval, caching and discovery. Query performances and query approaches are also studied. Data storage usually rely on databases, from SQL to NoSQL, but also linked to other technologies, blockchain being one of them, the DNS another. Spatio-temporal data retrieval raise concerns regarding the location of databases and the cache expiration. Caching is a concern when working with mobile devices or changing information, for which cache duration, renewal or expiration are an operational focus. Various architectures can be discussed for querying; some are built within cloud approaches, while others rely on edge storage for lower response time. The DNS provides an efficient middle ground between cloud-centric solutions and edge approaches. A key necessity with querying is also discovery, various approaches were studied, and DNS provides its own solution to the problem. Finally, we provide insight on query performances and approaches; recent work focused on new, innovative technologies, but DNS, as old as it is, remains the most used on the Internet.

Improving the scalability of IoT solutions might come with different approaches, we chose to focus on compression techniques to reduce payload size or network congestion. However, other approaches were mentioned, such as improving transmission scheduling or fine-tuning transmission parameters.

One of the major concerns within IoT is security. IoT solutions notoriously offer poor security qualities and rely on outdated authentication paradigms and cryptographic algorithms. Our focus regarding security relied on working with authentication, trust and privacy. We studied various authentication approaches for IoT, their strengths and weaknesses, from the research community and the SDOs such as IETF's work on authentication as part of the pana working group. Key concerns with trust are also addressed on building secure and efficient handshakes to bootstrap trust in IoT scenarios, which is a key concern for our work on IoTRoam. Finally, privacy preservation techniques are studied. In an all-connected world, privacy threats are a key concern to the security research community and evaluating the invasion of privacy and surfaces of attacks are essential to users' acceptance of IoT solutions.

Mobility management is one of the most important points when designing an IoT system. The devices studied within this thesis, such as sensors, watches, phones, luggage or cars, are highly mobile and supporting mobility is a key factor to improve IoT solutions. Mobility is, for example, a major concern in smart city environments. We studied mobility support through two aspects, coverage and roaming. Coverage is well documented; building solutions to improve coverage include developing new modulation techniques, developing new hardware or improving its knowledge of existing techniques to fine-tune the transmissions parameters. Roaming is a more organizational approach that rely on globally accessible RGs; within IoT ecosystems and its various network operators, roaming needs to rely on easy-to-deploy solutions, with collaboration inside an open ecosystem and communication in-between parties. Our focus on the LoRaWAN technology, and its open backend solution and specifications, is directly linked to this observation.

DNS, and its 297 RFCs, is a reference solution for information querying and discovery within the Internet. We detailed its functioning as well various DNS-linked standards that participate in the improvement of the global DNS ecosystem, including building trust through signed resources, securing transport channels and discovering resources.

Finally, we provided relevant information with regards to ML implementations for IoT ecosystems. ML is a popular subject that encompasses various approach section [[2021112662]] will detail more specific information regarding compression techniques for IoT traffic. Thus, we provided insight into the way IoT solutions usually interact with the ML world. We observed that ML is often used to improve users' knowledge of their studied datasets or to support and complement existing solutions such as placement solutions or tracking solutions.

Next section

The next section is Chapter 3 - IoTRoam available at [[202111264]]

IoTRoam

As presented in the previous chapter, mobility management is one of the most important points when designing an IoT system. We presented two possibility to support mobility of IoT devices:

• improving antennas coverage, by studying interferences, developing directional antennas or developing new modulations to support more device

• developing roaming between infrastructure, a more organizational approach that rely on collaborative work between operators that mutualize their infrastructure to reduce their costs.

Within IoT ecosystems and its various network operators, roaming needs to rely on easy-to-deploy solutions, with collaboration inside an open ecosystem and communication in-between parties. This chapter presents our work on improving Roaming capabilities in various IoT scenarios, with a focus on the LoRaWAN technology, and its open backend solution and specifications, using the DNS infrastructure as a facilitator. We describe our experimental platform and tests. Then present the consequences of introducing a distributed structure that satisfies the requirements of constrained IoT environments.

Next section

The next section is the chapter's introduction available at [[2021112641]]

Introduction

Roaming is an ED's capability to transmit and receive data on a VN. A classic example is cellular roaming, wherein a subscriber can use the VN infrastructure (such as the radio spectrum, base station) - when the subscriber's HN does not provide coverage. Roaming between the HN and the VN needs to consider three broad criteria: technical, economic and regulatory. Technically, roaming requires an interconnection between the HN and the VN directly or via a third party. Economically, the interconnections between different network operators are governed by agreements, which define the terms of interconnection. There should be an external body (such as governments) which regulates these agreements so that the terms and conditions are beneficial both to subscribers and network operators. Our work focuses only on interconnection from the technical perspective.

Interconnection in IoT becomes possible either by establishing a direct 'One-to-One' interconnection or using a 'Hub' model. The 'One-to-One' interconnection is similar to the Internet peering model wherein two IoT networks interconnect. 'Hub' is similar to an Internet transit model, wherein by establishing an interconnection with a single hub, it is possible to exchange traffic with the networks connected to that hub as well as with the networks connected to its peers. Both the 'Hub' and the 'One-to-One' interconnection models evolve as independent Silos wherein the ED in the coverage area of a VN can connect to its service only if there is a prior interconnection agreement between its HN and the VN or between the HN and the 'Hub'. The 'One-to-One' or 'Hub' interconnection deployments have been done following out-of-band mechanisms, and to our knowledge, there are no standardized interconnection procedures for interconnecting different IoT networks for roaming. In the independent silo scenario, when an IoT ED onboards to a VN, bootstrapping trust [@IoTBootstrapping_Survey_Draft] is a crucial security concern. The ED needs to be cryptographically authenticated by the VN based on credentials such as its identifier and a PSK. Cryptography-based authentication usually relies on one or more trust anchors [@Symington_Polk_Souppaya_2020]. In the proprietary silo scenarios, the trust anchor information may be preset with the ED or established out of band.

We started with the idea of setting up an open roaming federated platform integrating all IoT connectivity technologies. We debated this idea by discussing it with the IETF IoT onboarding mailing list [@iot_onboard_ml]. This discussion made us realize that we should focus on a specific IoT connectivity technology and, if possible, extend the concept to other IoT technologies. IoT connectivity technologies could be classified broadly into three categories [@wba_roaming]: short-range (Bluetooth, Zigbee, Zwave), medium-range (Wi-Fi) and long-range (LoRa, NB-IoT, Wi-Sun, Sigfox). We eliminated from our focus technologies that cannot support roaming, such as Short-range technologies and closed networks such as Sigfox, which do not require the roaming feature due to its vertical ecosystem. Narrowing our focus based on requirements, we short-listed LoRaWAN [@lorawan_specifications], which falls under the LPWAN Technologies [@rfc8376] category. Compared to other IoT connectivity technologies, the LoRaWAN ecosystem provides freedom to its stakeholders to choose the ED manufacturers, network service providers and application service providers. Since the radio connectivity uses a license-free spectrum, the freedom of choice in LoRaWAN also extends to deployment options. There are public LoRaWAN having nationwide coverage; private LoRaWAN focusing on specific use-cases and community networks that can be used for free by end-users.

We intend to test the federated platform with academic institutions as an open and accessible interconnected IoT network without considering economic factors. We started roaming testings using this platform with research and academic institutions. This initiative was presented to the LoRa Alliance (the SDO responsible for LoRaWAN specifications) and will be included as part of their academic outreach program.

Any architecture proposing solutions to the technology barriers mentioned earlier consider account the constrained characteristics of IoT environments. If the proposed architecture is validated with LoRaWAN having constraints such as the maximum frame size of 51 bytes (or 222 bytes for lower SFs) and latency requirements of two seconds for default uplink/downlink exchange, we hypothesize that architecture is extendable to other IoT networks. Mobility between the three different types of LoRaWAN networks (public, private, community) is a significant issue. A company may use LoRaWAN to monitor the battery level of vehicles in its fleet, an agricultural cooperative may use LoRaWAN to monitor the stock flows of its associates, or an emergency service may use LoRaWAN to coordinate its teams in the field. Most existing studies on LoRaWAN consider scenarios where the EDs are mobile, but remain under the umbrella of the same NS [@lian19].

We labeled this platform IoTRoam and its objective is to achieve, with IoT connectivity technologies the same interconnection functionalities that eduroam [@eduroam_site] proposes with Wi-Fi connection. In eduroam, an end-user who has credentials to connect to a particular eduroam Wi-Fi network for Internet access can access the Internet from any other eduroam network seamlessly. The first requirement is that an ED having credentials to connect to a particular IoTRoam network should be able to access its service seamlessly (with minimum prior configuration requirements) in the event of finding itself in the coverage area of the VN. The second requirement is that the proposed federated model should be operationally feasible. The vision is to start with LoRaWAN and extend the design to apply them to other IoT networks. The IoTRoam architecture aims to enable interoperability between the silos in the IoT domain by leveraging the DNS protocol, its security extensions (DNSSEC [@rfc2535]) and a PKI using self-signed X.509 digital certificates, thus bringing in the following contributions:

• The proposed architecture enables roaming between different LoRaWAN networks without the need of having any prior interconnection agreement

• The architecture includes an AA framework based on PKI enabling secure onboarding of the IoT ED;

• The architecture satisfies basic IoT operational requirements such as scaling, viability by not incurring additional costs, ease of deployment, interoperability between different IoT networks involving multiple stakeholders;

• Experiences from the implementation as a Proof of Concept (PoC) has enabled us to propose three accepted change requests (Change request is the procedure to provide modifications to the LoRaWAN specifications);

• With this PoC, we tested different LoRaWAN roaming scenarios with two Institutions in France - IMT Atlantique and Telecom SudParis (TSP). We ran measurements to assess whether the additional overhead introduced by the proposed architecture meets the constrained requirements of LoRaWAN;

IoTRoam's added value is the possibility of using core Internet infrastructures such as DNS and PKI to enable interconnection and security of IoT ED onboarding. The objective is to extend Internet resolution and security infrastructure services to be adapted to IoT, thus enabling seamless interoperability.

The remaining parts of this chapter are structured as follows: Based on the literature, Section [[2021112642]] identifies the requirements for a secure and seamless interconnection architecture. Section [[2021112643]]summarize LoRaWAN key aspects regarding authorization and authentication, section [[2021112644]] presents our design choices and section [[2021112645]] describes our integration of PKI paradygmes in the network. Then section [[2021112646]] describes our experimental setup to validate our proposed architecture for LoRaWAN passive roaming. In Section [[2021112647]], we evaluate whether the proposed mechanisms satisfy LoRaWAN constraints. We propose to extend this solution by provisionning the DNS queried information beforehand using a combination of prefetching techniques and mobility prediction algorithms ([[2021112648]]). Finally, we sum up our contributions in [[2021112649]] and conclusion in [[20211126410]].

Next section

The next section presents our motivation with this work [[2021112642]]

Motivation for a federated interconnection model

Since the focus of the chapter is on interconnecting IoT networks, our initial approach was to reuse existing standardized Interconnection models for roaming. The hurdle is that there is no single SDO that has the sole responsibility of making IoT Standards. As to our knowledge, there is no standardization work on IoT interconnection for roaming, satisfying the following basic roaming requirements:

• The VN should be able to provide the roaming service even if it does not have a prior interconnection agreement with the ED's HN;

• The VN should be able to control the terms under which a roaming ED is allowed to use its resources securely;

• The infrastructure interconnecting the home and the VN should be able to scale;

• The interconnecting infrastructure should be open, global and viable operationally;

A recent research study [@lorawan_meets_5g] proposed a mechanism to enable roaming between LoRaWAN and 5G network. This proposal includes a handover roaming mechanism for LoRaWAN that relies on 5G to authenticate the ED to the network. To our knowledge, as part of the LoRaWAN community, tests have been done for passive roaming, but handover roaming scenarios are still in the pipeline. Also, in the article, the ED is intended to be equipped with both 5G and LoRa interfaces. Adding a 5G interface to the ED will considerably reduce the battery life, which is a disadvantage when considering operational feasibility. Keeping our focus on building an operationally feasible interconnected IoT platform, we turned to the WBA Open Roaming [@openroaming] initiative for guidelines. Concerning the basic requirements for designing an architecture for an Open, seamless IoT interconnection, a WBA study [@wba_interop] outlined a set of requirements to consider.

When an IoT ED is roaming, the VN should retrieve its identifier from the incoming Join Request (JR) packet to identify the ED's HN. Therefore, identifiers play a vital role in IoT interconnection [@AIOTI-Identifiers] [@AFTAB2020333]. IoT identifiers are structured into two different categories: Hierarchical and Flat. An example of a hierarchical identifier is EPC [@EPC]. The barcodes attached to consumer products are based on EPC identification. An example of a flat identifier is UDID, a unique serial number assigned to track and record each Apple manufactured device. Both Apple and the EPC identity management infrastructures use closed databases to provision the identifiers. Mapping the ED's identifier to its appropriate network or service is only possible for entities who are provided access to these databases. From a global (not just limiting to LoRaWAN) IoT perspective, the first issue to resolve is to let different IoT sectors use their existing identifiers but to use a global database for IoT allocation and resolution.

The second issue is to use a global AA model, which controls the terms under which a roaming ED is allowed to securely use the resources in the environments operated by the VN. AA functionalities are usually consolidated in a single centralized database [@auth_services]. The centralized AA framework has its advantages and significant disadvantages, such as creating a single point of failure. Blockchain using distributed ledger has been experimented with and deployed [@block_cyb_priv][@block_aaa] to accomplish a scalable decentralized AA framework. Nevertheless, the blockchain model has several drawbacks as a feasible operational model [@distr_pki] in an open/global scenario.

A third technology barrier that we consider is that any proposed architecture should satisfy IoT environment constraints requirements. Narrowing our focus on requirements, we short-listed LoRaWAN due to its open standard characteristics and its ability to set up a private roaming set up.

The DNS infrastructure serves, among many other uses, to link domain names and IP addresses and is scalable and operationally viable on the Internet. Standards such as ONS [@ons] for the consumer industry, Object Resolution System (ORS) standardized jointly by the ITU-T and ISO/IEC, and the Handle system standardized by the ISO uses the DNS infrastructure to resolve the IoT identifiers to its related service on the Internet. DNS has been used by Mobile Network Operators (MNOs) on the inter-operator IP backbone network to enable data roaming [@EPS-RoamingGuideline].

eduroam [@eduroam_site], a Wi-Fi-based roaming platform widely adopted in the academic community, uses a distributed PKI based on X.509 digital certificates for AA. The trust fabric in eduroam is a PSK between the RADIUS servers (organizational, national, global) based on the DNS hierarchy. Such a trust fabric, wherein a PSK is shared hierarchically, hinders the design that we envision for IoTRoam. Different IoT networks use different mechanisms to share the PSK between the ED and the AA servers on the Internet to securely onboard the ED to its HN. Forcing them to transition to a newly proposed PSK mechanism is not operationally possible since multiple stakeholders are involved. We proposed to use the PKI based on X.509 self-signed digital certificates and DNSSEC trust anchor fabric that allows the IoT stakeholders to use their existing PSK mechanism.

IoT Roaming is different from cellular roaming and thus posing new challenges. In cellular roaming, interconnection is usually geographically defined and shared between different public MNOs (usually three to four MNOs in a country). In the IoT scenario, there are public, private, community-based network operators, and there could be thousands of private network operators within a Country. Adding to this complexity, IoT roaming mostly needs to have multi-layer interconnection agreements. For example, the authentication and authorization of the ED to the roaming network may be governed by a security solution provider or by the ED manufacturer rather than the network operator.

The IoTRoam experience brings the following contributions:

• A model that seamlessly interconnects the multi-stakeholders, IoT connectivity technologies using standards and infrastructure currently employed on the Internet

• A model that is operationally feasible and can be deployed with minimum prior configuration requirements

• A PoC[@iotroam_global] in place, which is open, can be accessed freely and used by the community. In this process, we have also contributed to software developments [@IoTRoam_quickstart]

Next section

The next section provide insight on authentication and authorization when talking about interconnexion in LoRaWAN [[2021112643]]

LoRaWAN Interconnection w/r Authentication and Authorization

LoRaWAN is an asymmetric protocol, with a star topology as shown in (Figure 1.1{reference-type="ref" reference="fig:lorawan_setup"}). Data transmitted by the ED is received by a RG, which relays it to a NS. The NS decides on further processing the incoming data based on the ED's unique identifier (DevEUI). The NS has multiple responsibilities like forwarding the uplink from the ED to the AS, queuing the downlink from the AS to the ED, forwarding the ED onboarding request to the appropriate AA servers, named as Join Server (JS) in LoRaWAN terminology. The AS handles all the application-layer payloads of the associated EDs and provides application-level service to the end-user. While the ED is connected to the RG via LoRa modulated messages, the connection between the RG, the NS and the AS is done through IP traffic and can be backhauled via Wi-Fi, hardwired Ethernet or Cellular connection.

{#fig:lorawan_setup width="\linewidth"}

The JS acting as the AA server control the terms on how the ED gets activated (i.e. onboarded) to a selected LoRaWAN. There are two types of ED activation: Over the Air Activation (OTAA) and Activation by Personalization (ABP). With ABP, the ED is directly connected to a LoRaWAN by hardcoding the cryptographic keys and other parameters required for secured communication. With OTAA, the parameters necessary to create a secured session between the ED and the servers on the Internet are dynamically created for a session. This is similar to TLS handshake. OTAA is preferred over ABP since it is dynamic, decouples the ED and the backend infrastructure and does not need configuration parameter hardcoding. This chapter will focus only on the OTAA process. In the HN scenario, the ED performs a Join procedure with the JS during OTAA by sending the JR. The JR payload contains the ED's unique identifier (DevEUI), the cryptographic AES-128 root keys: NwkKey, AppKey and JoinEUI (unique identifier pointing to the JS).

The JS associated with the ED also has prior information such as the ED's DevEUI, the cryptographic keys: NwkKey and AppKey required for generating session keys to secure the communication between the ED and the NS and AS. These are the pre-shared information between the ED and JS (the AA server) on the Internet, which we proposed not to modify. Once the JS authenticates the ED, it responds with a JoinAns message to the NS. The JoinAns message contains different session keys derived from the root keys: one set of cryptographic keys for securing the ED <---> NS interface and another for securing the communication between the ED <---> AS interface, for a particular session.

In the VN scenario, a non-activated ED should first activate itself and then transmit/receive the payload. Roaming scenarios in LoRaWAN are classified into passive and handover roaming. We limit ourselves to passive roaming since handover roaming is still in the testing stage and an open LoRaWAN software stack for handover roaming is not yet available.

In passive roaming, the MAC layer control of the ED is maintained by the home NS, which becomes the serving NS (sNS), as shown in Figure 1.2{reference-type="ref" reference="fig:roaming_message_flow"}. The roaming ED uses the NS of the VN named forwarding NS (fNS) to send messages to its sNS. The fNS forwards messages between the sNS and the ED. If the ED is not yet activated, then it has to get activated using passive roaming activation process as shown in Figure 1.2{reference-type="ref" reference="fig:roaming_message_flow"}. When the fNS does not have prior information about the sNS, the fNS SHALL use the DNS to find the roaming ED's JS IP address.

{#fig:roaming_message_flow width="\linewidth"}

As per the LoRaWAN backend specifications, the LoRa Alliance has allocated a DNS Zone file (joineuis.lorawan.net) for provisioning the information mapping the JoinEUI to its corresponding JS operator. Each nibble of the JoinEUI represented in the hexadecimal format "0x00005E100000002F" is first reversed. Then periods are inserted between each nibble and the domain name joineuis.lorawan.net is concatenated as the suffix. The final result is a domain name that can be provisioned in the DNS zone file joineuis.lorawan.net pointing to their respective JS as follows:

::: center f.2.0.0.0.0.0.0.0.1.e.5.0.0.0.0.joineuis.lorawan.net. IN A 192.168.1.1 :::

Thus the fNS, by running a standard DNS resolution, can retrieve the IP address of the JS corresponding to the JoinEUI and kickstart the Join procedure. The fNS then queries and obtains the NetID (i.e. the 24 bit Unique Network Identifier of the sNS represented in the hexadecimal format: "0x60050A") from the JS. Similar to JoinEUI, the LoRaWAN backend specifications has allocated a specific DNS Zone file (netids.lorawan.net) for mapping the NetID's to their corresponding NS. Any LoRaWAN operator(either private, public or community) needs to obtain from the LoRa Alliance a unique NetID and provision it in the DNS zone file "netids.lorawan.net", a standardized DNS resource record pointing the allocated NetID to its sNS as follows:

::: center 60050a.netids.lorawan.net. IN A 192.168.1.2 :::

Thus for a fNS, it is possible to resolve the sNS of an ED by querying the NetIDs DNS zone file, even if there is no prior roaming agreement. The sNS and the fNS exchange data, and finally, the ED is activated once the ED receives the JoinAccept (JAccept) with the session keys for transmitting uplink or downlink messages. The DNS provisioning mechanism has ensured that both JoinEUI and NetID could be provisioned or updated by different entities in their respective DNS Zones (Servers); they are unique in the global scope and cannot be duplicated. The DNS resolution mechanism ensures that both the JS and the NS can be accessed from anywhere on the Internet with a simple DNS resolution. Figure 1.2{reference-type="ref" reference="fig:roaming_message_flow"} demonstrates how multi-stakeholders interconnection complexities are solved due to DNS provisioning and resolution since for a single ED onboarding, the JS could be operated by a different entity than the NS operator. Thus, the LoRaWAN architecture design by itself provides a partial solution to the WBA requirements described in section [[2021112642]].

Next section

The next section presents our design choices [[2021112644]]

Design choices regarding IoT identifiers provisionning

Both previously mentioned IoT identifier types, hierarchical (EPC) and flat (UDID), could be accessed from the global Internet if they are provisioned in the global DNS database (Figure 1.3{reference-type="ref" reference="fig:identifier_provisioning"}). Then it is up to the client libraries to make the conversion and add the specific sub-domain suffix (udid.apple for UDID and gs1.fr for EPC) to the identifiers. Once the identifier is converted to a domain name as follows:

::: center 2b6f0cc904d137be2e1730235f5664094b831186.udid.apple. 3.1.3.1.6.2.3.3.9.3.4.0.3.gs1.fr. :::

It will follow the normal DNS resolution process to resolve the identifier's associated resource/service/metadata globally.

{#fig:identifier_provisioning width="\linewidth"}

Some parameters such as ED's HN identity, the AA server identity, the authentication credentials and the port numbers must be configured in proprietary roaming models such as a hub before an ED can roam outside its HN. Except for the authentication credentials, all other information could be retrieved from the DNS database. Thus, by provisioning their IoT identifiers and related information in the DNS database under their own domain namespace, different IoT sectors could interoperate by using their existing identifiers, thus satisfying operational viability. The ED is configured with a PSK that is only shared with an AA server, creating the session keys for encrypted communication between the ED and the different associated servers on the Internet. When the ED is onboarding in a VN, the VN should establish mutual authentication with the ED's AA servers and the HN. To establish mutual authentication dynamically between different servers on the Internet managed by multiple stakeholders, our hypothesis is to use the DNSSEC infrastructure as trust anchors and a PKI based on self-signed X.509 digital certificates. The DNSSEC extensions use asymmetric cryptographic signature mechanisms to authenticate the data provisioned in the DNS database. The Signatures and public keys come in the form of new DNS records that provide authentication. With DNSSEC, the origin and integrity of received data can be verified using one or more key pairs associated with the DNS zone.

DNS is a time-tested infrastructure and had scaled from hundreds of domains from the Internet's beginning to billions currently [@number_website]. These factors influenced our choice to use the DNS infrastructure, its security extensions and a PKI in the LoRaWAN roaming architecture. A DNS infrastructure, similar to the LoRa Alliance's lorawan.net, was set up under the domain iotreg.net for provisioning the JoinEUIs and NetIDs, as shown in Figure 1.3{reference-type="ref" reference="fig:identifier_provisioning"}. Each nibble of the JoinEUI represented in the hexadecimal format 0x00005E100000002F is first reversed. Then, periods are inserted between each nibble and the domain name joineuis.iotreg.net is concatenated as the suffix. The final result is a domain name provisioned in the DNS database pointing to their respective JS as follows:

::: center f.2.0.0.0.0.0.0.0.1.e.5.0.0.0.0.joineuis.iotreg.net. IN A 192.168.1.1 :::

Similar to the JoinEUI, the NetID represented in the hexadecimal format are provisioned into the DNS without reversing and adding periods between each digit, pointing the allocated NetID to its NS is as follows:

::: center c0002f.netids.iotreg.net. IN A 192.168.1.2 :::

The JoinEUI is reversed, and periods are added since it benefits from a hierarchical model and the NetID is based on the flat model. The DNS provisioning mechanism has ensured that both JoinEUI and NetID could be provisioned or updated by different entities in their respective DNS Zones; they are unique in the global scope and cannot be duplicated. Both JS and the NS can be accessed from anywhere on the Internet, and with a simple DNS resolution, the JoinEUI can be resolved to its JS and NetID to its NS dynamically without any prior interconnection agreements shared in advance. The JS and the NS DNS resolution information are secured from being spoofed on the wire and modified at the DNS database since the DNS infrastructure is signed by DNSSEC. We developed and provided a secure, automatized DNS provisioning platform that could be used by the community. With a secured API key, any authorized user can access the User Interface (UI) (via web or API). The UI enables authorized users to do multiple operations (creation, modification, deletion) of only their data in the DNS database. To make it easy for the community to understand and use the interface, a video tutorial [@video_afnic] is provided. While testing the UI with some LoRa Alliance community members, we encountered operational issues such as validating that the data provisioned in the DNS is done by the rightful owner. The need to validate the JoinEUI (an IEEE EUI-64 identifier provisioned by the IEEE and has Organizational Unique Identifier (OUI) in the IEEE EUI-64) with the IEEE OUI database, were identified and implemented, thanks to the PoC. The implemented solution has been provided as feedback to the LoRa Alliance, which could be integrated when the DNS service operated by the LoRa Alliance is deployed.

There was no existing off-shelf or open-source LoRaWAN network stack software that uses DNS for ED onboarding or roaming. We collaborated with the open-source Chirpstack network stack [@chirpstack] author to update the software to integrate both functionalities. The NS, JS and the AS in our PoC are installed with appropriate software from Chirpstack, thus enabling DNS resolution.

Next section

The next section [[2021112645]] details security integration

Security integration to the experimental set up and validation

For secure ED onboarding, the interface between the servers (NS, JS and the AS, which could be grouped as backend elements) in the IP space (Figure [fig:passive_roaming]{reference-type="ref" reference="fig:passive_roaming"}) should be mutually authenticated (i.e., both the client and the server authenticate each other), as per the LoRaWAN Backend Interface Specification [@lorawan_specifications]. However, the mechanisms for mutual authentication is left to the implementer's choice and is not normative.

The PKI using the X.509 digital certificates signed by a trusted Certificate Authority (CA) is widely used to secure web traffic. However, the CA trust model for issuing the X.509 digital certificates is not operationally feasible for IoTRoam. On the web, the browser client (such as Chrome, Firefox) has a certificate store containing thousands of Root CA certificates. The browser authenticates any server that delivers a X.509 certificate digitally signed by anyone of the Root CA in its certificate store. Such certificate store infrastructure is not available in the LoRaWAN backend network elements or any IoT backend infrastructures. Even if we assume the infrastructure exists, the digital certificates come at a cost, which is not viable for most IoT services. We tried with Let's Encrypt, which provides X.509 digital certificates for free. However, it was not possible to benefit since they do not provide certificates for domain names with more than ten labels (JoinEUI has more than 16 labels). A viable solution to resolve the operational and cost issue is to generate our Self-Signed certificates.

{#fig:certificate_provisioning width="\linewidth"}

Our certificate provisioning model is that any institution willing to test roaming based on the IoTRoam architecture can request intermediate certificates from a trusted Root CA. Figure 1.4{reference-type="ref" reference="fig:certificate_provisioning"} shows a scenario wherein Afnic plays the role of Root CA and generates intermediate certificates for two independent LoRaWAN networks - TSP & Afnic Labs. The intermediate CAs will, in turn, generate the leaf certificates for backend elements. Details on obtaining an intermediate certificate and generating the leaf certificates are documented [@iotroam_global]. We further simplified the process, wherein the institutions can generate the leaf certificates by just running a makefile after customizing their JSON configuration files and adding the provided leaf certificates information into each of the backend elements configuration files.

Next section

The next section details our Experimental Setup [[2021112646]]

Experimental Setup

To validate the architecture, two independent LoRaWAN networks were set up separated by a distance of 34 kilometres. The two locations are Afnic (in the Yvelines department in France) and Télécom SudParis (in the Essonne department in France). The backend elements are installed with the open-source Chirpstack network stack and are configured with their respective intermediate and leaf certificates.

::: figure* :::

Figure [fig:passive_roaming]{reference-type="ref" reference="fig:passive_roaming"} shows that the ED configured with TSP as HN uses the RG in Afnic's coverage area to onboard (Step 1). The RG forwards (Step 2) the incoming JR to the Afnic NS, which in turn uses the DNS infrastructure (Step 3) to retrieve the TSP-JS IP address (based on the JoinEUI in the JR) since the ED is unknown to it. Afnic-NS and the TSP- JS runs a TLS handshake for mutual authentication (Step 4). During mutual authentication testing, we identified that combining the intermediate and the server leaf certificate (a combined trust chain) during a TLS handshake could bypass the need for having a certificate store with all intermediate certificates and store only the Root CA certificate. The certificate validation process is done by sending the combined trust chain to the server's IP address. On receiving the combined trust chain, the server first verifies the leaf certificate in the combined trust chain. When the leaf certificate is unknown, it checks the following certificate in the chain, the intermediate certificate. Since the Root CA signs the intermediate certificate, the combined certificate chain becomes trusted. Thus, the backend network elements (NS, AS and the JS) could be mutually authenticated even if they are in different networks since they have a common Root CA at the top of the chain of trust.

On a successful mutual authentication between the Afnic-NS and the TSP-JS, Afnic-NS retrieves the NetID of the ED from the TSP-JS (Step 4). Using the retrieved NetID, the IP address of the ED's NS (i.e., TSP-NS) is obtained (Step 5) via DNS resolution, and mutual authentication is established between the Afnic-NS and TSP-NS (Step 6). Once the mutual authentication is established between the different servers in the IP interface, the JR is sent to the TSP-JS to create the cryptographic session keys. The cryptographic session keys are sent back to the ED via the PKI secured mutual authentication channel as Join Answer (JAns) and Join Accept (JAccept) (Step 7). Finally, a secured session between the ED and the associated servers on the Internet using the generated session keys (Step 8).

Next section

The next section provides performance measurements [[2021112647]]

Performance evaluation

The time taken for the ED to onboard (i.e. Steps 1-7 in Figure [fig:passive_roaming]{reference-type="ref" reference="fig:passive_roaming"}) is the metric that we want to measure to study the latency influenced by DNS and PKI. In the LoRAWAN terminology, the onboarding process is termed as OTAA.

::: figure* {#fig:iotroam_uplink width="\textwidth"}

{#fig:iotroam_otaa width="\textwidth"} :::

Following an uplink, a Class 'A' ED in LoRaWAN opens a receive window for one second (default value), and if no downlink is received during the period, it opens a second receive window after another second (default value) as shown in the figure 1.5{reference-type="ref" reference="fig:iotroam_uplink"}. If no downlink communications are received from the server between the two-receiver window, it must wait until the ED triggers the next uplink and opens a receive window. For the ED onboarding process (i.e. OTAA), in the EU 868 Mhz channel, the default Join Delay window, as described in [@rfc8376], and illustrated on Figure 1.6{reference-type="ref" reference="fig:iotroam_otaa"}, is five seconds meaning the RG will transmit the downlink JAccept exactly five seconds after the uplink.

The performance evaluation objective is to check whether the introduction of DNS and PKI influences the onboarding process time. We defined three scenarios for our measurements:

• Scenario 1: The ED is in the HN without the latency introduced by DNS or PKI

• Scenario 2: The ED is in the HN, but the NS and JS are resolved using DNS resolution

• Scenario 3: The ED is in the VN's coverage area with the latency introduced by DNS and PKI for mutual authentication

{#fig:activation width="0.85\linewidth"}

To ensure that the measurement is precise and get rid of any synchronization error between the ED and the backend network elements, the measurements were realized directly on the ED. We ran the measurements for around 30 hours of transmissions and gathered more than 2000 measurements for each scenario.

Figure 1.7{reference-type="ref" reference="fig:activation"} shows the time-to-join for the three scenarios obtained by monitoring the delay between the JR and the "Join Success" message received at the ED. In the EU 868 Mhz channel plan for LoRaWAN, the Join Delay window is 5 seconds [@rfc8376] meaning the RG will transmit the downlink JAccept exactly 5s after the uplink (Figure 1.6{reference-type="ref" reference="fig:iotroam_otaa"}). The RG may receive the downlink JAccept well in advance, but it will stay in the queue until the requested TX time. This means that the ED will receive the JAccept after 5s. Our measurements show that the device receives its JAccept around 90% of the time in all scenarios, around 5.2s after sending its JR. The ED can onboard as soon as possible independently of using DNS or experimenting with a roaming ED. Therefore, DNS seems to have no significant impact on the activation delay. A fact that can be explained considering that the ED's Join Delay is significantly lower than the standard times for DNS resolutions (usually around 300ms).

{#fig:uplink width="0.85\linewidth"}

Figure 5 shows the first delay for end-to-end communication after activation. Once again, we see that our data is gathered around two values, 1.2s and 2.4s, which correspond to the two receive windows available when class A LoRaWAN ED communicate and illustrated on Figure 1.5{reference-type="ref" reference="fig:iotroam_uplink"}. The ED can receive the acknowledgement within the receive window's time limit regardless of the scenario studied.

These measurements lead us to believe that introducing DNS and PKI to the LoRaWAN system would not significantly add to the latency in LoRaWAN communications. It is of note that when working on our measurements, we configured our infrastructure to work without DNS caching. A regular infrastructure would further benefit from DNS caching as a way to reduce the impact of DNS[@Jung_Sit_Balakrishnan_Morris_2002]. However, we propose to expand our reflection on the impact of DNS by studing possible prefetching and caching scenarios for DNS data in a mobile environment.

Next section

Prefetching is actually the subject of the next section [[2021112648]].

Prefetching of mobile devices information to reduce DNS impact

The DNS is a key component in IoTRoam, as a focal point to support roaming, it might incur additional latency and hinder device connectivity. From a user's point of view, it is important that access is provided as smoothly as possible, without additional cost, to develop the technology's adoption. And in roaming scenarios, serving all users as soon as possible would decrease the impact from other networks on their own gateways. Thus, reducing the impact from DNS requests when a device is joining becomes a key connectivity concern. From an operator's point of view, increase in latency might incur congestion or gateway overload which would decrease the QoS for IoT solution.

Beyond our use case, the issue behind storing and sharing DNS data, or where to locate a DNS cache, how long to keep information cached and when to access it as an operator, is crucial to improve network for mechanisms such as those presented in Chapter [[202111265]] and [[202111266]].

Prefetching information is a common strategy to reduce latency within networks. Web browsers make use of such techniques to obtain IP addresses for domains within a web page, predicting that the user may click on a link, thus sparing the DNS requests when a user clicks by performing the request beforehand.

DNS prefetching relies on a prediction mechanism; the user could click on the link, so its browser performs the query beforehand. This simple prediction mechanism can be applied to any circumstances. [@Fujiwara_Sato_Yoshida_2013] analyzed DNS traffic with the increase of IPv6 technologies in web hosting and put it in perspective with network traffic increase in Japan; and offered a prefetching-based solution to increase cache hit rate and reduce response times on web browsers. [@Allman_2020] proposes to study DNS queries in their context by studying when DNS queries are performed and when the information is needed. Their conclusion regarding prefetching is that no supplementary DNS cost apply thanks to prefetching and that the overcost is minimal when data is not prefetched.

A good tutorial on prefetching and its consequences is provided by the chromium project ([@DNS_Prefetch_chromium]).

We hypothesize that we can exploit DNS prefetching to query DNS servers based on devices mobility to resolve for device-specific information between the gateway and a DNS server. The prefetching can be as simple as requesting that nearby gateways prefetch the information but could also rely on recent mobility models based on ML predictions. The presented use case focuses on provisionning connectivity data based on the join exchange in the IoTRoam use case, but this method is applicable to other DNS data querying as defined at the beginning of this section

This section studies the consequences of prefetching DNS information on antennas with regards to devices mobility but also studies antennas occupation based on mobility scenarios to further understand the possible impact of prefetching on antenna cache filling. We consider mobile vehicles in the Roma city, and we aim to analyze how we could reduce the overhead of DNS querying in our IoTRoam solution in a context of a vehicular application.

Use cases

Our IoTRoam use case [[2021112647]] introduces two DNS queries for channel establishment between gateway and backend. Fetching data using DNS comes with a short delay. Our measurements from [dns_resp] showed that such a delay could be measured around 200ms. [@Jung_Sit_Balakrishnan_Morris_2002] studied DNS responses with overall results outlining this 200ms response for 70% of their queries, and 90% of queries are realized within 1s. More recent analysis, such as [@Hounsel_Borgolte_Schmitt_Holland_Feamster_2020] or [@Doan_Tsareva_Bajpai_2021] outline better results by combining anycast technologies and Content Delivery Networks for DNS. [@Hounsel_Borgolte_Schmitt_Holland_Feamster_2020] studies responses from top resolvers which answer 90% of their requests within 100ms. Moreover, [@Doan_Tsareva_Bajpai_2021] provides additional information regarding DoT resolution in which they outline failure rates with responses between 130ms and 230ms from top resolvers. Overall, the time inflation from additional security can be outlined around these values.

DoH would add another supplementary cost up to 150ms as outlined by [@Hounsel_Borgolte_Schmitt_Holland_Feamster_2020] measurements on public resolvers. Adding an integrity check with DNSSEC would increase the requests even further. Overall, sending two complete DNS requests completed with integrity check and secured with DoH would cumulate up to 1.1s of queries done within the first exchange between the ED and the RG. Our problem is as such: "Would it be possible to reduce that delay in a mobility context to reduce the impact from DNS querying on channel establishment?"

This work provides a few insights on possible solutions based on Machine-Leaning-based mobility predictions and information prefetching from DNS servers.

We consider mobility traces from devices moving within the city of Roma; Figure 1.9{reference-type="ref" reference="fig:roma_mobility"} shows part of the studied traces traced as a function of latitude and longitude.

![Vehicle mobility around Roma[[fig:roma_mobility]]{#fig:roma_mobility label="fig:roma_mobility"}](Figures/Chapter3/Prefetching/1- Roma mobility.png){#fig:roma_mobility width="\linewidth"}

We virtually place antenna within the movement perimeter. These antennas, regularly placed, provide independent coverage for our vehicles. Figure 1.10{reference-type="ref" reference="fig:roma_mobility_antenna"} shows a vehicular trace with the antenna disposition within its sector. Regularly placed antennas help us realize the closest one at glance, which is helpful when trying to infer the results and prototype. Our test antenna positioning algorithm places the antennas regularly in squares; thus, each antenna has 8 immediate neighbor for all scenarios.

![Vehicle and antennas around Roma[[fig:roma_mobility_antenna]]{#fig:roma_mobility_antenna label="fig:roma_mobility_antenna"}](Figures/Chapter3/Prefetching/2- Roma mobility single road with antenna.png){#fig:roma_mobility_antenna width="\linewidth"}

In our simulated fog LoRaWAN deployment, each antenna would act independently and provide access to its devices. To cover a city the size of our perimeter (200 km x 170km), a regular deployment will need around 520 independent antennas deployed.

Figure [fig:vehicle_antenna_distance]{reference-type="ref" reference="fig:vehicle_antenna_distance"} provides insight on vehicle to antennas distances. With a regular antenna placement and about 8 km between two antennas at most, the vehicle-to-antenna distance will always be bounded between 0 and 4 km.

::: figure* ![vehicle to closest antenna distance reparition [[fig:distance_antenna_repartition]]{#fig:distance_antenna_repartition label="fig:distance_antenna_repartition"}](Figures/Chapter3/Prefetching/3- distance repartition.png){#fig:distance_antenna_repartition width="\linewidth"}

![Vehicle to closest antenna distance reparition (cumulative) [[fig:distance_antenna_repartition_cumulative]]{#fig:distance_antenna_repartition_cumulative label="fig:distance_antenna_repartition_cumulative"}](Figures/Chapter3/Prefetching/4- distance repartition cumulative.png){#fig:distance_antenna_repartition_cumulative width="\linewidth"} :::

Based on our IoTRoam use case [{46]], we infer that each independent antenna will provide roaming access to devices within its reach. As described in the IoTRoam section, this means that the antenna will request the device's key from its HN and establish its connection to the ED thanks to them.

We separated our study into three scenarios. In the first scenario, no prefetching is realized, and the device uses the standard DNS query mechanism. In the second scenario, we improve the mechanism with a basic prefetching mechanism realized by nearby antennas. Finally, in the third scenario, we run mobility predictions, using ML, for our devices, plan their possible future location and prefetch the information based on the predictions.

First Scenario

For this first scenario, we studied the movements of 6992 devices within the Roma metropolis. Each vehicle is tied to 10 successive locations. We survey the nearest antenna for each location and check if the device's information is available on the antenna's cache or should be queried. Actually, depending on the vehicle movements, DNS configuration (number of entries in cache, TTL...) or antenna placement, it may come under the coverage of an antenna where it has already been before. The first location of the device is put on the side as "First DNS Query" for consistency with the other scenarios as we would not prefetch information for the first point of the time series.

Figure 1.13{reference-type="ref" reference="fig:cache_no_prefetch"} describes our results. For the 10 locations of our 6992 vehicles, the antenna either query the DNS as part of the vehicle's first localization, query the DNS as part of an antenna change for the device or query its own cache as the device was already known.

![Cache Hit Rate distribution between queries - No Prefetching [[fig:cache_no_prefetch]]{#fig:cache_no_prefetch label="fig:cache_no_prefetch"}](Figures/Chapter3/Prefetching/5- cache stat no prefetch.png){#fig:cache_no_prefetch width="\linewidth"}

Our studied traces are not heavily mobile for now as we study an urban scenario, and additional studies would be necessary to study possible other equilibrium between DNS caching and DNS querying for mobile devices.

Our first insight into these results would be that devices are moderately mobile, switching antennas once within the 10 points of their movements, moving around 35km per hour. We observe the 6992 initial DNS requests and around 8 thousand additional DNS queries, consistent with a 2.1 mean antenna per vehicle. The remaining DNS queries are prevented as the request hits the DNS cache within the antenna.

Second Scenario

For the second scenario, we studied the movements of the same 6992 devices; each vehicle is still tied to 10 successive locations. We survey the nearest antenna for each location and check if the device's information is available on the antenna's cache or should be queried.

Our test antenna positioning algorithm places the antennas regularly in squares; thus, each antenna has 8 immediate neighbors. In this scenario, we prefetch the information on these 8 closest antennas to anticipate possible device movements.

As signalled above, the first DNS query for each vehicle is put on the side as "First DNS Query" as these DNS queries cannot be anticipated.

Figure 1.14{reference-type="ref" reference="fig:cache_nearby_prefetch"} describes our results. As above, for the 10 locations of our 6992 vehicles, the antenna either query the DNS as part of the vehicle's first localization, query the DNS as part of an antenna change for the device or query its own cache as the device was already known through low mobility or prefetching.

![Cache Hit Rate distribution between queries - Nearby prefetching case [[fig:cache_nearby_prefetch]]{#fig:cache_nearby_prefetch label="fig:cache_nearby_prefetch"}](Figures/Chapter3/Prefetching/6- cache stat nearby prefetch.png){#fig:cache_nearby_prefetch width="\linewidth"}

The simulations show that prefetching permits us to prevent on-the-fly DNS querying. The DNS is still queried but at a time where the information is not yet necessary. The DNS cache handles all queries necessary for device communication, preventing additional DNS query time during handshakes. Nearby prefetching permits us to attain an important hit rate on our cache, whether filled by our first classic DNS query, DNS refreshes or prefetched DNS queries. A similar situation would be as described in the introduction of section [[2021112648]], where prefetching every DNS zone encountered within web page URLs allow to quicken load time by pre-filling the DNS cache with prefetched DNS queries.

Third Scenario

In this third scenario, we predict car mobility using deep learning algorithms and identify antennas candidate for device coverage. Based on these predictions, the DNS (or its cache) is queried once by the antenna corresponding to the device's position for each given point within the device's movement. Then for the four following predicted positions, the corresponding antenna will perform DNS prefetching to heat its cache for a possible change of coverage from the device.

Figure 1.15{reference-type="ref" reference="fig:prefetching_scenario"} provides a rundown on interactions between antennas and DNS Servers in the third use case.

For a given position A, we consider the 25 possible antennas (B to Z) from the previous prediction and positions of the vehicle:

• Antennas B to E are antennas corresponding to the prediction of position A in previous moments in time $\big{ f_{T-i}(T+i), i \in [[202111261,4]] \big}$). If antenna A corresponds to one of these antennas, we consider that our prediction is successful, and we hit the cache of our gateway as the information was prefetched in previous moments in time.

• Antennas F to O correspond to the predictions for previous positions of the device ($\big{ f_{T-i}(T+j), i \in [[202111261,5]], j \in [[202111261,4]], i-j>0 \big}$). If antenna A corresponds to one of these antennas, but not antennas B to E, our prediction was a failure, but the actual corresponding prediction was correct with a time shift. Furthermore, the prefetching for these antennas was realized; thus, the information is still present in the gateway's cache, and despite the prediction failure for this exact timestamp, we hit our gateway's cache as the information was not purged yet.

• Antennas P to S are a similar case ($\big{ f_{T-i}(T+j), i \in [[202111261,5]], j \in [[202111261,4]], i-j<0 \big}$), our prediction was a failure, but the predicted antennas was correct considering a time shift (and would probably be correct for future device positions). Furthermore, the prefetching for these antennas was realized; thus, the information is present in the gateway's cache, and despite the prediction failure for this exact timestamp, we hit our gateway's cache as the information was not purged yet.

• Finally, antennas V to Z are the actual antennas solicited for the device in previous moments in time ($\big{ f_{T-i}(T), i \in [[202111261,5]] \big}$). Should all other prediction fail but antenna A correspond any antennas from V to Z, the prediction is a failure and so is the prefetching as the other prefetched information expired, but the information corresponding to these antennas are still present in the DNS cache from previous requests, we labelled this result "DNS Cache - No Prefetch"

• In the case where antenna A ($\big{ f_{T}(T) \big}$) does not correspond to any antenna between B and Z, prefetching was a failure, and a new antenna was solicited; thus, it must realize a DNS request (labelled "DNS Query")

• Additionally, we separated from these DNS queries the DNS query for the first device's location as antenna B to Z constitute an empty ensemble for this given location.

![Possible solicited antennas in Scenario 3[[fig:prefetching_scenario]]{#fig:prefetching_scenario label="fig:prefetching_scenario"}](Figures/Chapter3/Prefetching/Prefetching scenarios.png){#fig:prefetching_scenario width="\linewidth"}

Figure 1.16{reference-type="ref" reference="fig:cache_predict_prefetch"} combines the results from the 69920 vehicle location based on the scenario breakdown from figure 1.15{reference-type="ref" reference="fig:prefetching_scenario"}.

![Cache Hit Rate distribution between queries - Predictor prefetching case[[fig:cache_predict_prefetch]]{#fig:cache_predict_prefetch label="fig:cache_predict_prefetch"}](Figures/Chapter3/Prefetching/7- cache hit.png){#fig:cache_predict_prefetch width="\linewidth"}

Results are, satisfying compared to the first scenario. Successful prediction lead to hitting an antenna linked to a correctly predicted position in 63.4% of cases. Cache hit rate linked to predictions, whether correct predictions or incorrect prediction by lateness or earliness, would add up to 77.4% of requests. The remaining 22.6% are divided between the first query (10%), DNS cache after prediction error (10.3%) and actual DNS queries (2.3%).

Antenna occupation

Another important subject to study is antenna occupation. As part of our study, antennas prefetch information based on the possibility that the associated device will pass under its coverage. What is the consequences of such additional operation on our antennas:

• We placed 520 virtual antennas around the city

• Out of them, the first scenario activates 301 antennas. That means that our 6992 vehicles pass near these 301 antennas and that 301 is our minimum number of active antennas as a whole.

• The second scenario activates as whole 393 antennas, a bit over twice more antennas than in the first scenario. The 'nearby case' shows excellent results but would probably create congestion within the network should these results confirm at a larger scale.

• Finally, the third scenario activates 380 antennas, globally around the same amount as the antennas solicited as part of the second scenario, figure 1.17{reference-type="ref" reference="fig:antenna_activation"} gives us more insight on the distribution of these antennas.

Figure 1.17{reference-type="ref" reference="fig:antenna_activation"} shows the comparison of the number of activated antennas between scenario 2 and scenario 3.

![Sample from activated antennas in all scenarios [[fig:antenna_activation]]{#fig:antenna_activation label="fig:antenna_activation"}](Figures/Chapter3/Prefetching/8- comparison antennas curve.png){#fig:antenna_activation width="\linewidth"}

The mean amount of antennas, described on 1.18{reference-type="ref" reference="fig:antenna_activation_box"} activated is as follows:

• Scenario 1 leads to activating 2.1 antennas per moving vehicle on average.

• Scenario 2 leads to activating 12.3 antennas per moving vehicle on average.

• Scenario 3 leads to activating 9.7 antennas per moving vehicle on average.

![Activated antennas repartition for each scenario [[fig:antenna_activation_box]]{#fig:antenna_activation_box label="fig:antenna_activation_box"}](Figures/Chapter3/Prefetching/9- comparison antennas box.png){#fig:antenna_activation_box width="\linewidth"}

Figure 1.18{reference-type="ref" reference="fig:antenna_activation_box"} provides additional insight on these values, Scenario 1 has at least 50% of its values between 1 and 3, Scenario 2 between 9 and 14 and Scenario 3 between 7 and 12. This result fits with the moderate mobility from our values as devices that move within 3 antennas would activate within to 15 through their movement in Scenario 2. The predictor performs better than the simple nearby prefetching, with more than 75% of its values under the median for Scenario 2. Also, Scenario 2 has many outliers with over 21 antennas solicited per device on highly mobile roads, in which the predictor performs better.

On prefetching efficiency

DNS prefetching is an efficient tool to reduce on-the-fly DNS queries necessary for devices communication. Prefetching the information on nearby antennas can completely prevent DNS queries by performing them in advance around the closest antennas, but at a cost as devices request more antennas, especially in a highly mobile environment.

By exploiting recent ML capabilities for traffic prediction, we could provide a solution that heats the cache for 78% of requests and that lead to a cache hit for 88% of them, the remaining 12% consist of the first DNS query (10%), and on-the-fly DNS queries following prediction failures (2%).

Overall, the ML system would outperform its nearby-activation counterpart in terms of antennas solicitation. However, additional simulations with different antenna positioning would be interesting to study. Another interesting point would be the study of possible antennas overload. Also, considering that our traces amount for taxis which represent around 1% of actual cars circulating around a country, studying actual overload within the network by increasing the number of vehicles by a 100-factor then decreasing it considering the number of cars that would actually transit within the system would be feasible.

Next section

The next section sums up our contributions [[2021112649]]

Contributions

The IoTRoam experience enabled us to set up a federated platform that has been documented and the software provided as open-source to the community. It also helped us to identify operational issues that have not been encountered earlier since there is no LoRaWAN operational infrastructure using DNS for OTAA and Roaming. The PoC tests proposed solutions to some of the operational issues and also led to three change requests adopted by the LoRaWAN backend specifications. This section will detail the contributions.

Contribution 1

The networks based on 'One-to-One' interconnection or hub drop the incoming packet from an ED if it is not part of its network or its partners. With the IoTRoam federated model, these networks could make a DNS resolution to identify the HN of the ED. Thus, the IoTRoam federated model caters to the whole ecosystem wherein networks based on the 'Hub' or 'One-to-One' interconnection could co-exist.

Contribution 2

In the cellular model, portability between operators becomes possible since there is a human subscriber involved, which is not the case in LoRaWAN. In LoRaWAN, the EDs with a battery life spanning for a decade are supposed to be set up in remote places and not readily accessible in the necessity of a network operator change. IoTRoam enables portability between different operators; thanks to the DNS database, the JS pointing to a JoinEUI can be modified without making any modification at the ED level.

To understand the importance of operator portability, a brief background of how the ED is provisioned with the JoinEUI and DevEUI are needed. The JoinEUI 64 bit address could be divided into three broad ranges: OUI of the manufacturer, the Batch ID of the manufacturer and the JoinEUI value assigned to the batch. The DevEUI is also a unique IEEE EUI-64 bit address divided in the same categorization as the JoinEUI. The difference is - for every ED there is a unique DevEUI, but thousands of EDs could be assigned a single JoinEUI as shown in the table 1.1{reference-type="ref" reference="table:sample"}:

::: {#table:sample} DevEUI JoinEUI

OUI-ABBB-0001 OUI-ABBB-FFF1 OUI-ABBB-0002 OUI-ABBB-FFF1 OUI-ABBB-0003 OUI-ABBB-FFF1 .... ... OUI-BBBB-0001 OUI-BBBB-FFF2 OUI-BBBB-0002 OUI-BBBB-FFF2 OUI-BBBB-0003 OUI-BBBB-FFF2 .... ...

: Fictional representation of how DevEUI and JoinEUI 64 bits are partitioned, wherein certain bit blocks are allocated for OUI, certain bits for the batch (e.g. ABBB) & the remaining bits at the serial level :::

[[table:sample]]

During the JoinEUI assigning process, the ED manufacturer is not yet aware of who will be the buyer. If a client is buying only 500 EDs from a batch of 1000, the remaining 500 EDs' JoinEUI need to be re-provisioned with a new JoinEUI if a new buyer wants the remaining 500 EDs to point to a different JS. Similarly, if the buyer who has bought 500 EDs from a batch needs to assign a different JS for a set of 100 EDs, the JoinEUI needs to be modified in each ED. This modification is done by re-flashing the EDs with the new JoinEUI and thus is operationally time-consuming and costly.

The PoC experience enabled us to suggest a change request to provide an operationally feasible solution, which has been accepted and included in the LoRaWAN backend specifications. The solution proposed by the change request is to create a combination of the DevEUI (which is unique for each device) and JoinEUI and provision them in the DNS. In order to adapt to this requirement, the NS should first make a DNS query using the concatenation of DevEUI and JoinEUI, and if the resolution fails, it falls back in making a DNS query only using the JoinEUI.

Taking an example where two EDs (0xACDE480001020234, 0xACDE480001020ABC) should point to two different JSs, but has a single JoinEUI represented in the hexadecimal format as 0x00005E100000002F. The DevEUI JoinEUI combination could be provisioned in the DNS pointing to two different JSs as follows:

::: center 4.3.2.0.2.0.1.0.0.0.8.4.e.d.c.a.f.2.0.0.0.0.0.0.0.1.e.5.0.0.0.0.
joineuis.lorawan.net IN 192.168.2.4
a.b.c.0.2.0.1.0.0.0.8.4.e.d.c.a.f.2.0.0.0.0.0.0.0.1.e.5.0.0.0.0.
joineuis.lorawan.net IN 192.168.2.5 :::

Based on the longest match algorithm, the DNS resolution will resolve to two different JS's for the two ED's even though the JoinEUI are the same for both the EDs.

Contribution 3

The second change request that was adopted into the LoRaWAN backend specification includes modifying the subdomains for join and roaming from lora-alliance.org to lorawan.net, thus separating the LoRa Web and DNS service.

Contribution 4

A third change request that was adopted into the LoRaWAN backend specification consists of updating the DNS provisioning and resolution section to enable the usage of any DNS resource record for OTAA and roaming functionalities. Before the change request, the LoRaWAN backend specifications were normalized using a NAPTR DNS resource record, which is considered quite complex (Explained in RFC 3401, 3402 & 3403) for operational purposes.

Contribution 5

We developed and provided a secure, automatized DNS provisioning platform that could be used by the community. With a secured API key, any authorized user can access the User Interface (UI) (via web or API). The UI enables authorized users to do multiple operations (creation, modification, deletion) of only their data in the DNS database.

While testing the UI with some LoRa Alliance community members, we encountered operational issues such as validating that the data provisioned in the DNS is done by the rightful owner. The need to validate the JoinEUI (an IEEE EUI-64 identifier provisioned by the IEEE and has OUI in the IEEE EUI-64) with the IEEE OUI database, were identified and implemented, thanks to the PoC. The implemented solution has been provided as feedback to the LoRa Alliance, which could be integrated when the DNS service operated by the LoRa Alliance is deployed.

Next section

The next section details our conclusions [[20211126410]]

Conclusion

Our objective with IoTRoam is to achieve the same service as cellular or Wi-Fi roaming built on a global resolution and security infrastructure, namely the DNS and PKI. We added a hard requirement that the infrastructure or technologies used to achieve this vision should be viable, operationally feasible and could be integrated into existing IoT infrastructures with minimum changes. To achieve our vision, we followed the WBA guidelines for open roaming and satisfied the requirements outlined by employing open standards used on the Internet, such as DNS and PKI.

We chose LoRaWAN, an evolving standard, and demonstrated that seamless IoT roaming with minimum prior configuration is possible using the IoTRoam architecture. In this process, we have deployed a PoC and provided all necessary building blocks (documentation, software, UI, video tutorial) so that each one in the community could make use of them to implement his own network.

This experience has also helped us to propose three Change Requests that have been adopted into the LoRaWAN Backend Interface Specification. The first one includes the possibility of using any DNS resource record ED activation and roaming functionalities. The second is creating a combination of the DevEUI (which is unique for each ED) and JoinEUI and provision them in the DNS. This solution was proposed to resolve the device manufacturer's issue of providing the ED's configured in the same batch with same the JoinEUI and different DevEUI to be sold to different buyers. The third includes modifying the domain names for join and roaming from lora-alliance.org to lorawan.net, thus segregating the LoRa Alliance Web and DNS service.

The IoTRoam initiative was advertized through various press releases and with academic partners. We discussed running interoperable testing using the federated platform with several institutions in France, Denmark, and Italy. We also discussed with network operators to run experiments with massive public network infrastructures. Running additional tests with these institutions would help us study the impact of heterogeneous backend infrastructures and their effect on the quality of the communication channel. It would also allow us to gather additional data on the impact of DNS complete resolution on the LoRaWAN/IoT traffic.

As the objective is to interconnect networks using different IoT technologies, the next steps consist of testing roaming interoperability with NB-IoT, 5G or Wi-Fi. For ED onboarding, we are also working on integrating DANE with DNSSEC since the certificate data itself can be stored in the DNS, possibly replacing or completing the PKI.

On the subject of reducing the impact from DNS, we studied through simulations the consequences of caching and prefetching DNS information with mobile devices in a city. Our combination of an ML predictor and prefetching allow for an interesting reduction of DNS requests realized compared to a caching-only solution and a reduction in the number of gateways realizing prefetching operation compared to soliciting the closest nearby antennas. This mechanism, already crucial for cloud providers in the context of the development of the web, proves efficient and useful for operators and asks interesting question on locating caches and optimizing caching delays.

The application of DNS prefetching in a mobility context is applicable when querying other connectivity information from the DNS infrastructure such as the querying presented in Chapter [[202111265]] or the one presented in Chapter [[202111266]], Section [[2021112665]].

Next section

The next section is Chapter 4 - DNS-based dynamic context resolution for SCHC available at [[202111265]]

DNS-based dynamic context resolution for SCHC

Next section

This page is here for consistency reasons but is actually empty, the Chapter directly starts with an introduction to the SCHC technology [[2021112651]]

SCHC, connecting LPWANs to the IP stack

Complementary to developing LPWANs infrastructure, a key aspect in developing LPWANs relies on connecting them to the Internet. Indeed, LPWANs are fundamentally non-IP networks. We already detailed a few constraints of LPWAN communications in the previous chapters. The maximal frame size for LPWAN payloads, a constraint that limits the connection of LPWANs to the Internet drastically. Table 1.1{reference-type="ref" reference="table:frame_size"} explicit this limitation. When working with small frame sizes such as LoRaWAN's or SigFox's, signalization size, and in the case that interests us, headers size, become a significant issue. Table 1.2{reference-type="ref" reference="table:header_occupation"} sums up the main header size for layer 2, layer 3 and layer 4 when working with various technologies usually embedded onto wireless devices, as well as the percentage of frame size it corresponds to in the context of LPWANs.

::: {#table:frame_size} LoRaWAN (bytes) NB-IoT/LTE-M (bytes) SigFox (bytes)

Frame size 250 1600 29

: Max Frame size from the main LPWANs technologies [[table:frame_size]]{#table:frame_size label="table:frame_size"} :::

::: {#table:header_occupation} Headers LoRaWAN NB-IoT/LTE-M SigFox

        L2 header            8 octets    14 octets     10 octets
                              3.2 %       0.875 %       34,4 %

L3 / IPv6 header (40 bytes) 16 % 2.5 % 138 % L4 / UDP header (8 bytes) 3.2 % .5 % 27.6 % L5 / CoAP header (4 bytes) 1.6 % .25 % 13.8 % L3+L4+L5 / SCHC (2 bytes) 0.8 % .125 % 6.9 % Cumulative (no SCHC) 24 % 4.125 % 213.8% Cumulative (SCHC) 4 % 1 % 41.3 %

: Frame Header Occupationas percentage of frame size for the main LPWANs technologies [[table:header_occupation]]{#table:header_occupation label="table:header_occupation"} :::

Based on this observation, the lpwan working group designed a framework to reduce the IPv6 header size to embark the IP stack onto LPWAN devices. SCHC [@rfc8724] is a framework that provides both compression and fragmentation functionalities. It was standardized by the lpwan [@wg.lpwan] working group at the IETF. It is considered an efficient solution to connect the LPWANs to the Internet using IPv6, thus enabling end-to-end IP connectivity. Figure 1.1{reference-type="ref" reference="fig:schc_acklio"} illustrates SCHC compressing capabilities and effect onto layers with regards to each layer size in different connectivity setups. With the help of the SCHC framework, it is possible to compress an IPv6 header from its original size of sixty bytes down to two bytes, thus reducing bandwidth usage and increasing communication efficiency. Enabling IPv6 connectivity for LPWANs is a key issue to connect the LPWANs to the Internet via the IP stack.

{#fig:schc_acklio width="\linewidth"}

The SCHC solution was also designed to break the IoT siloes. Using SCHC allows applications embedded onto devices to communicate using a common, standard system, the IP stack, with SCHC handling the adaptation between the applicative and lower layers, specific to each IoT technology.

Finally, SCHC enables technologies to be embedded with a common, global, underlying adaptative technology, assisting developers when working on IoT solutions allowing them to work regardless of the actual underlying layers.

SCHC is designed keeping in mind that the LPWANs are star-oriented technologies, with EDs usually communicating to a single network gateway or linked to a single backend element. Thus its operating principle is based on the assumption that the device will compress data, and the center of the star topology, usually the network gateway or another centralized backend element, will take care of the decompression. The framework also considers that the IP header expected for LPWANs EDs can be predefined as the ED is less likely to change its internal software and usually evolve in a known network environment. To compress the data sent and received between the ED, its backend element, SCHC uses a predefined group of rules called context which is deployed on the ED and one of the backend element (RG or backend servers). This context may be specific for each ED or common for a group of EDs. Fig. 1.2 presents such an example of such a context rule.

{#schc_rule width="\linewidth"}

Based on this context rule, a pattern matching operation is realized on the packet header emitted by the LPWAN ED. These operations usually match each IP header field with their expected values and remove them if the values correspond to the rule defined in the context. When an ED receives a SCHC compressed packet, the reverse operation is realized to build the IP header back, allowing the applications to communicate on the network without considering the underlying IoT specificities.

To prove the operational feasibility of SCHC, members of the lpwan working group at the IETF designed a PoC implementation called OpenSCHC ([@openschc]). OpenSCHC is a reference Python codebase for the SCHC protocol, which we used in our experiments. SCHC works as follow: when sending data from the ED to its RG, the SCHC context rules enable compression by suppressing redundant, superficial, predictable or most used data inside an IPv6 header and replacing them with a Rule Identifier (Rule ID) chosen in a given set of predefined rules. Among multiple rules hosted on the devices, a single rule is selected to fit as precisely as possible to the corresponding application that needs to transmit its data. All the rules associated with a given ED are hosted on its corresponding backend to realize the opposite operation and decompress the data received over the air.

Our interrogation regarding SCHC can be summarized as follow: SCHC is a protocol built on static information. It relies on identical information stored on both the ED and the network backend. This identical information, the context, usually consists of multiple rules corresponding to the associated ED. When using SCHC, one element from the backend is supposed to realize SCHC operation (compression, decompression, fragmentation, reassembly) for all associated EDs. Allowing the owner to host his rules and to modify them quickly at a later date, storing only a piece of information on either the RG, the NS or the AS such as the Rule Identifier or Version might help to introduce more flexibility to the SCHC protocol and simplify the user's maintenance. Also, storing all SCHC rules, considering they might be unique for each ED, might introduce scalability issues to the system. We can consider around 20 rules per ED when working with such rules, with thousands of EDs around a single antenna and multiple antennae for a given server. LoRaWAN, built as a star of star topology, is a good example where multiple RGs, each handling multiple EDs, can be connected to a single NS. When considering hundreds of thousands of EDs around a single server with around 10kb per context rule, we end up storing gigabytes of data to enable SCHC on a given LoRaWAN infrastructure. Finally, considering SCHC's static design, building a system supporting both SCHC and roaming might prove complicated. SCHC's static design might harm communication when working in a mobility scope, typically when an ED is roaming.

To assist SCHC's development in these three scopes: hosting rules, supporting scalability and developing mobility scenarios, we propose that the RG, NS or AS retrieve the context dynamically from a remote server. Hosting such information on a remote server separates traffic from its underlying protocol, separating the interfaces, each dedicated to its use. Storing outside the main servers' scope lightens the weight associated with local storage by introducing a tradeoff between storing SCHC's most used rules and querying rules used less often. Retrieving the context from an accessible remote server strengthens mobility and roaming capabilities for EDs, which can work anywhere once their context is retrieved.

This section provided information regarding SCHC, such as the motivation that leads to its development and the questions that we aim to address in this chapter. We presented the SCHC framework and explained how, by enabling IPv6 for LPWAN communication, SCHC creates a bridge between the siloed LPWAN and the Internet. In section [[2021112652]] we present the experiment we realized as part of our work with SCHC, the key research issue we identified, the mechanism we designed to address it and the experimental setup we deployed to test our hypothesis. Lastly, we present our experimental results in [[2021112653]], regarding the SCHC framework and how our mechanism introduces more flexibility in the system. Results that we discuss further in section [[2021112654]] by opening the discussion on possible evolutions to the framework.

Next section

The next section introduces our experimental setup [[2021112652]]

Experimenting with SCHC and DNS

There are multiple options for storing these context rules. It could be done in a private server, using, for example, an Administration Management System as proposed by [@BWCCA.ayoub2019schc], stored in the cloud or even shared on a blockchain. However, we hypothesize it could be wise to use an open, distributed mechanism to find the location of the server where the context rules are stored. We propose to experiment possible use of DNS as a way to support SCHC compression. As an optimized, hierarchical and distributed database, DNS could support the determination of the location of the server where the context rules are stored feasibly on the Internet. Hopefully, using such a mechanism would allow for a seamless transition, from preconfiguring the information needed on the backend to building it dynamically, on the fly, based on actual needs when operating the network.

DNS would prove an efficient solution to introduce more flexibility and improve scalability when using SCHC. Our solution aims to provide open access to SCHC parameters to support roaming capabilities, improving flexibility and scalability. We study the possibility of introducing a context registry outside the scope of the ED's NS. To study this problem, we deployed a dynamic context resolution architecture based on DNS for SCHC compression and decompression and studied its consequences on system latency and LoRaWAN communications.

Our experiment proposal for this section aims to study and improve SCHC's compression and decompression mechanisms. It relies on multiple scenarios, defined in the following parts of this section, that aim to study SCHC compression and decompression mechanism and the delays added by the system concerning transmission delays. Then we added two possible remote rule management systems to introduce more flexibility to the SCHC standard to solve the scalability issue identified in the previous subsection and permit SCHC rules to be easily shared across the network, for example, in a roaming context.

Fig. 1.2 presents such a context rule whereas the experimental testbed and its components is described in the later part of this section.

In order to prevent synchronization issues, a frequent issue when working with constrained devices such as LPWAN-enabled devices, the delays are always measured on either the ED (e.g. full round trip time) or the backend (e.g. DNS resolution)

For our experiments, we chose not to focus on transmitting the rules to the devices over the air and considered that the rules would already be on the devices as the current standard proposes it.

{#lora_platform width="\linewidth"}

Proposing querying mechanisms for context resolution

Querying information can rely on various technologies: Edge technologies ([@8703942], [@8411011]) can be leveraged to place information in the most efficient location possible wih regards to the ED's location. [@Moeini_Zeng_Yen_Bastani_2019] propose a routing method to query information more efficiently and [@8804809] proposes a data-centric approach intended for low power networks. Another key evolution in edge technologies is the Information Centric Network ([@Ghodsi_Shenker_Koponen_Singla_Raghavan_Wilcox_2011], [@Ullah_Ahmed_Kim_2018]) approach that rely on a decentralized naming convention to distribute the information efficiently within the network. Our method differs as we leverage known techniques from the DNS world to improve Context rules distribution.

The proposed mechanism delocalizes the SCHC rules on a remote server and uses DNS to retrieve them. When the ED sends data, they are received by the RG, then transferred to the NS and retrieved by the AS. To decompress the data, the AS needs access to the rule. We use the DNS to retrieve a hash of the rule (since it is not possible to store the entire rule in the DNS) and possibly an address of an HTTP server on which the corresponding rule might be stored. An HTTP server is used to store the rules themselves. The rules can be uniquely linked to the tuple (DevEUI, RuleID). This tuple is constructed by extracting the DevEUI from the LoRa frame and the RuleID using the first bits from the LoRa payload compressed by SCHC. The AS stores the rules corresponding to the device under its coverage in a rules cache for a set duration. The rules in the AS are indexed in a hash table. When the AS receives data, it constructs the tuple (DevEUI, RuleID) as indicated above, then uses the DNS to retrieve the hash of the corresponding rule and search for this rule in its rules cache. If it is not found because it is a new tuple (DevEUI, RuleID), a new rule must be stored in the cache, and the HTTP server where the rule is stored is interrogated to get it. Then, the rule is inserted into the cache. Note that even when a rule is present in the cache, the DNS is systematically queried because the freshness of the information must be checked to ensure that the rule has not been modified since its last cache insertion.

Finally, the data can be decompressed. Once the data are decompressed, the server may send a response back depending on the application's needs. Fig. 1.3{reference-type="ref" reference="lora_platform"} presents the interactions between the AS, the DNS and the HTTP server in the case where a new rule is needed.

Measurement scenarios

Our study focuses on AS Response Time and ED Uplink Round Trip Time (U-RTT) through different scenarios. Scenarios 1 and 2 serve as references to compare with other scenarios. They provide the minimum communication time with and without SCHC decompression. Scenario 3 aims to study the mechanism presented in [[2021112652]]. Scenario 4 studies the case where most of the information is always present in the cache. These four scenarios are described more precisely below:

• Scenario 1: The first measurement is designed to be used as an experimental reference for our platform. Data are sent without compression from the ED over LoRa and a response is sent back from the ChirpStack AS in order to measure the RTT $t1-t0$ (cf. Fig. 1.4{reference-type="ref" reference="ex_diag_no_decomp"}). We also measure the AS Response Time $t1' - t0'$. No decompression operation is performed on the data.

  {#ex_diag_local width="\linewidth"}

• Scenario 2: The second measurement adds the SCHC mechanism for the communication over LoRaWAN. The ED sends the data compressed using the SCHC context, and the received data are decompressed using the same context rule stored in a file locally on the AS. We measure $t1-t0$ (cf. Fig. 1.5{reference-type="ref" reference="ex_diag_local"}) We also measure the AS Response Time $t1' - t0'$. The comparison with results from Scenario 1 allows us to estimate the decompression time.

  {#ex_diag_all width="\linewidth"}

• Scenario 3: The third measurement is the key scenario of our study. It aims to add the mechanism presented at the beginning of [[2021112662]] and illustrated by Fig. 1.3{reference-type="ref" reference="lora_platform"} to provide the AS with the SCHC context that is stored in a remote server. In this measurement, instead of using a locally stored context rule for decompression, the AS is asked to download the context file from a remote HTTP server with a request such as "HTTP GET myschcrules.net/DevEUI/RuleID". We measure the total RTT $t1 - t0$, the AS Response Time $t1' - t0'$, the RTT of the DNS query $t1'' - t0''$ and the RTT of the HTTP Request $t1''' - t0'''$ (cf. Fig. 1.6)

  {#ex_diag_dns width="\linewidth"}

• Scenario 4: In most cases, EDs will be static (e.g. water meters) and well known by the AS, so their context rules will always be present in the AS cache of rules. In this case, the DNS is still queried to check that there has been no change to the rule, but there is no need to interrogate the HTTP server as the rule is still present in the cache. The third measurement corresponds to this scenario. We measure the total RTT $t1 - t0$, the AS Response Time $t1' - t0'$ and the RTT of the DNS Query $t1'' - t0''$ (cf. Fig. 1.7)

Experiment Testbed

As mentioned earlier, our study is done using LoRaWAN. ChirpStack[@chirpstack] is an open-source solution to build a ready-to-use LoRaWAN easily. It provides the software components of our infrastructure for the RG, NS and AS.

ChirpStack works with the RG to ensure that the data received from the devices can be relayed to the AS. For our experiment, we chose to connect directly to an MQTT broker and subscribe to the message queue associated with our devices, but MQTT can also be used to monitor the RG or contact all the devices linked to a specific LoRa Application using various topics. ChirpStack AS also offers a REST API, a gRPC API and a web interface to offer multiple ways to operate a LoRaWAN network.

We used PyCom FiPy development cards as LoRa-enabled devices, and we made them send SCHC compressed data based on a context over LoRa to a Multitech Conduit RG which forwards the data to the ChirpStack NS. Then we can retrieve the data using the ChirpStack AS or subscribe to the MQTT broker hosted on the NS to retrieve the data sent and decompress it based on the same context used for decompression. The SCHC implementation used to decompress data is OpenSCHC [@openschc]. OpenSCHC is developed by the authors of the SCHC draft as a PoC. It serves as the base reference for other SCHC implementations.

FiPy cards are Class A compliant devices as defined by the LoRa Standard [@lorawan]; hence they respect a strict emission/reception schedule. Our experimentation is realized respecting the EU regulations on duty cycle, communicating in the EU 868 MHz frequency, and all communications are done using SF7 considering that, for our experiment, it is the one we expect to include most constraints regarding latency. If our system works without hindering RTT for SF7, it has no reason to hinder the RTT for higher latency SF.

Next section

The next section details our results [[2021112653]]

Experimental results

Fig. 1.8 illustrates the cumulative distribution functions of the AS-side Response Time $t1'-t0'$ with or without SCHC (cf. Fig. 1.4{reference-type="ref" reference="ex_diag_no_decomp"} and 1.5) to show the order of magnitude of the sole decompression mechanism. For this case, we consider that a locally stored context file is used for the decompression. The curves show that integrating SCHC adds a few milliseconds to the operations necessary to work on the data independently to the possible delays added by the rule-querying mechanism.

{#srt_schc_int width="\linewidth"}

Fig. 1.9 shows the cumulative distribution functions of the Server-side Response Time $t1'-t0'$ for all the studied scenarios, thus including also context remote querying for the non-local solutions (HTTP, DNS).

{#srt_all width="\linewidth"}

We observe that the order of magnitude of the AS Response Time is for the worst-case (HTTP-base mechanism) around 0.6s.

Note that the DNS response time in our case (between 5 ms and 15 ms) is faster than the usual DNS response time due to DNS caching [@Jung_Sit_Balakrishnan_Morris_2002] from our local network's DNS resolver. We keep interrogating our resolver with data already in its DNS cache, so the DNS Response Time is cut down. This caching will remain in a wide LoRa deployment, but considering the frequency with which the LoRa devices are expected to communicate on the network, the cache will probably be emptied from the necessary data.

In order to provide a more realistic model to study the influence of adding DNS queries in an IoT system, we decided to gather additional data on DNS response time. We used RIPE Atlas [@atlas] which is a system that assists in performing Internet measurements through a set of probes available all over the world. RIPE Atlas is a global network of probes deployed under the scope of RIPE NCC. Its 12000 probes enable Internet connectivity testing throughout the globe, resources availability testing, and real-time measurements of the state of the Internet. RIPE Atlas is a valuable and powerful tool for troubleshooting, monitoring, testing, and experimenting over the network. While most of the probes are in Europe, we realized measurements asking for interrogations from all other continents (Oceania, Americas, Asia and Africa) to test the responses for a single DNS query from multiple locations worldwide. The measurements performed using RIPE Atlas allow us to determine the DNS Response Time in a more realistic case, as it allows us to query when the DNS cache is expired.

{#dns_resp width="\linewidth"}

Fig. 1.10 provides a comparison between DNS response time for our DNS Queries and DNS response time obtained through measurements from RIPE Atlas interrogations. According to this figure, DNS Response will be slower in a real case than with our platform, but a time within 200ms is still in the margins with regards to the response times we measured for our platform.

This observation is consistent with data from the literature, [@Jung_Sit_Balakrishnan_Morris_2002] provides additional information regarding latency distribution through a study of the Massachusetts Institute of Technology's DNS resolver. In their study, DNS lookups range from a few milliseconds (when accessing from the cache) up to 120 seconds, with most domains resolved within a 1s timeframe (and 70% within 200ms). The study also provides additional information linking latency to the number of referrals, with more referrals linked to more lookups and thus more latency observed.

Our case can be correlated with their 1-referral resolution. In 2001, when the study was realized, 60% of the resolutions were made within a 200 ms timeframe. Considering the evolution of DNS deployments, such as the deployment for massive DNS resolvers such as Google's or Cloudflare's, and the improvements linked to the hosting of DNS zones, such as the massive use of anycast and the development of cloud technologies, a 200ms latency seems coherent.

This timeframe would be further increased with the use of newly developed DoT or DoH, [@Hounsel_Borgolte_Schmitt_Holland_Feamster_2020] and [@Doan_Tsareva_Bajpai_2021] provide insight by comparing the technologies through the same tool as ours, RIPE Atlas probes. [@Hounsel_Borgolte_Schmitt_Holland_Feamster_2020] concludes that DoT and DoH indeed increase response time, an observation that can be linked to the use of TCP instead of UDP and the additional cost from encryption. The tradeoff from this loss in response time comes from securing and improving reliability when navigating the Web. Our use case is fairly different from web navigation and does not necessarily require additional encryption, thus relying on traditional DNS seems acceptable. [@Doan_Tsareva_Bajpai_2021] provides additional information regarding DoT resolution with RTTs around 15ms for traditional DNS resolution and RTTs over 100ms for DoT use. Securing DNS resolution with DoT seems to come with a 100ms tradeoff.

{#rtt width="\linewidth"}

Fig. 1.11 presents the measured U-RTT (From ED to AS, then back to ED) $t1 - t0$. We measure at least about 4s for 99% of the packets transmitted through our platform for all the studied scenarios. Considering the case of LoRa Class A devices [@lorawan], a downlink frame from the RG can only be sent during a given time interval called "receive window" (cf. [@draft_lpwan_rto] & Fig. 1.12). The RG implementation we are working with does not allow a frame to be transmitted to the device unless it has been en-queued before the RG receives an uplink frame from the device (cf. Fig. 1.6). The last receive window is opened two seconds after the last uplink frame has been transmitted. It lasts twice the transmission time, which depends on the SF. In our case, we use SF7 and our transmission time is around 100ms. For the majority of our measurements, our total measured RTT is around 4.2s, as illustrated in Fig. 1.13. Note that we use the OpenSource ChirpStack implementation, the reference solution for LoRaWAN OpenSource deployments. We would expect the same behaviour for class B devices, whereas Class C would allow an immediate response and a shorter RTT.

{#ltw width="\linewidth"}

{#ltw_rtt width="0.8\linewidth"}

Next section

The next section concludes this chapter [[2021112654]]

Conclusion

SCHC can efficiently compress headers from the 44-octets IPv6+CoAP header down to a few octets, which leads to reduce header size up to a 22-factor and enable the use of IPv6 over networks that would be unable to support it, such as SigFox and its 29 octets frame or LoRaWAN which ranges from 59 octets to 250 octets. Using SCHC to send IPv6 packets over LPWAN is proven to be an efficient way to account for the scarcity of radio resources. SCHC is also able to work within a reliable timeframe. Querying time within a large database was not studied and would need additional data regarding actual SCHC usage on LPWAN to provide interesting insight, but when working with a few devices, SCHC can decompress data consistently with a few microseconds; an operation that is almost transparent with regards to other mechanisms specific to LPWAN, such as LoRaWAN's reception delays.

In our experiment, we deployed all the components of a LoRaWAN infrastructure in order to build a SCHC-enabled LoRa network. Because of the expected large number of devices and the variety of possible things profiles, it seems necessary to envisage a mechanism to retrieve SCHC context rules dynamically. DNS is a globally and well-known system that is a fundamental stepping stone when designing a dynamic system.

Thus our method proposes to accompany the SCHC mechanism with a context querying system to support device mobility and network scalability. Using DNS, one can query the context signature within a satisfying timeframe (between 30 and 100 milliseconds) and fall back onto the associated context storage API within 650 ms. In a best-case scenario, the 650 ms delay would be reduced furtherly by caching the information; our Atlas probes measurements lead us to believe that using a DNS-only mechanism and building a context cache would reduce the 650ms delay down to tens of milliseconds. These results concerning the DNS-only system and its performances are consistent with results measured in other studies. Such a mechanism does not hinder the communication as it is kept under the delay of the first reception windows and benefits from the information caching should the answer need a different SCHC rule. Should we need to respond to the device within the first reception window, we are left with around 350ms of data handling in the worst-case to enqueue our response onto the RG.

Considering LoRaWAN RTT, working with SF7 measurements, we only observe a 4.1s mean RTT when considering the listening window used by the device to receive communication from the RG. This observation is consistent for all scenarios and is easily explained by the prevalence of the delay linked to data reception. We constated that LoRa Server does not handle responding to the device after information treatment unless we consider the Join procedure, which leads us to propose RTT measurements based on sending two information within two successive transmission windows to acknowledge and respond to the data sent from the device.

Problems may arise considering upper-layer protocols such as CoAP. This question was asked at the IETF by C. Gomez and J. Crowcroft in their draft RTO considerations in LPWAN [@draft_lpwan_rto] for which the authors signal that "LoRaWAN policies may lead to U-RTT up to 282 seconds in the worst-case" (SF12). SCHC should not hinder CoAP, as packet handling is done within a few microseconds. However, as our mechanism may induce additional treatment up to 650 ms, additional measurements linked to CoAP compression/decompression considering CoAP handling on top of SCHC remote context querying might be an interesting subject to study in further work. However, considering that "LoRaWAN policies may lead to U-RTT up to 282 seconds in the worst-case", a 650 ms additional delay is negligible by several orders of magnitude.

Actually, according to [@rfc7252], CoAP message transmission has a default ACK_TIMEOUT parameter which is set to 2 seconds. In this case, the ACK_TIMEOUT has to be adjusted carefully to respect end-to-end delays. In this case, adjusting the delay to handle RTO consideration in LPWAN should prove a sufficient adjustment to handle SCHC remote context querying.

Should one decide to add security to the channel between the NS and the context storage servers, exploiting TLS by using either DoT (DNS over TLS) or HTTPS (HTTP with SSL/TLS) would add another 100 ms to the mechanism, which keeps us within a sufficient timeframe. Unfortunately, it is to note that DNS, or any remote querying mechanism, would be hindered in locations that benefit from a slow or distant connection to the backbone. One such example is Oceania, in which the Atlas probes signal either a significant amount of packet loss or high latency in DNS resolution. Using SCHC without DNS or building a proximity context registry would be the solution in such a rare context. Additional insight regarding storing and sharing data within the DNS will be provided in section [[2021112665]], with a focus on the size of DNS RRs.

Further work regarding the SCHC protocol would require additional data from the actual use of the SCHC protocol. Studying SCHC uses would help define the research direction by contrasting them with the production issues introduced by the protocol. Studying SCHC context rules outside their theoretical construction, but based on actual rules used in production, would help further identify eventual new constraints introduced by the protocol and define useful research direction.

As a matter of fact, improving the compression capabilities of LPWANs is a key concern for the technology. Reducing packet size reduces airtime, which is an efficient way to improve the scalability of LPWAN solutions. Another solution to reduce airtime of LPWANs transmissions is transmission minimization. Our approach with transmission minimization is complementary to compressing header using SCHC. SCHC relies on suppressing and optimizing predictable data within the transmission's header. However, what if the actual relevant data from the payload is predictable. In this case, would it be possible to study transmission minimization paradigms in which compressing communications rely on predicting a device's transmission payload and preventing its transmission if it is unnecessary? That is the subject of the next chapter. [[202111266]]

Machine Learning

Next section

This page is here for consistency reasons but is actually empty, the Chapter directly starts with an introduction to Machine Learning [[2021112661]]

Introduction

In the previous chapter, we've seen how SCHC improves LPWANs by offering them interconnection with the rest of the Internet, circumventing the high constraints and notably the limited payload size. In LPWANs, traffic compressing is of the utmost importance, our previous approach revolved around header compression mechanisms, this chapter will dive into minimizing traffic by compressing LoRaWAN traffic, more precisely by reducing its data payload, using a ML-based compression scheme.

Many IoT applications consist of monitoring: power grid or water distribution network metering, electric vehicle battery level monitoring, meteorological, temperature, or humidity monitoring. In most cases, the observed time series are highly correlated and can be forecast easily unless unexpected events occur. Thus, it is not necessary to transmit the data in most cases, but only of unexpected events. With a good time-series predictor both on the sensor and on the network backend, the data can be deduced at the backend without sensors transmissions. However, if the sensor, using the same predictor, observes that the measured data is different from the predictor's forecast, if it notes it is an unexpected event, then the sensor must send the data. With such a mechanism, we can avoid many transmissions and produce highly compressed traffic. Our compression approach differs from usual compression methods, based on pattern frequency analysis, as our studied compression proposal suppresses transmission entirely instead of compressing the payload. However, those two approaches can be complementary, suppressing unnecessary transmission and compressing the remaining transmission payload.

Our goal is precisely to test to what extent such an approach is well suited for IoT, particularly in LoRaWAN. We want to observe the efficiency in network performance (e.g. compression ratio) and power consumption since it is essential to save the batteries of sensors that are expected to have a long life. We also want to test whether our solution is feasible practically by setting up an experiment with actual sensors.

Different predictors may be envisioned, but ML, particularly neural networks, is well suited to model any repeated pattern. Here, we use an LSTM neural network (as described in [@lstm] and Figure 1.2{reference-type="ref" reference="fig:lstm_presentation"}) for two scenarios: power production and consumption metering and cellular base station load monitoring. We trained the neural network model on a powerful computer, and then we injected the trained model into the sensors. We measured the compression ratio and the sensor's electric consumption, considering the transmission and the computation cost. We run our experiments with real measured data and LoRaWAN equipment.

This work also presents our thoughts on LSTMs' accuracy and how the device's compression capabilities are impacted by LSTM accuracy.

In part [[2021112662]], the related works are reviewed. Then, in part [[2021112663]] we present our experiment setup, tools and software, implementation choices and the walls we encountered. Lastly, in part [[2021112664]], we present our results and discuss possible improvements to the system. [[2021112666]] sums up our experiments and conclusions.

Next section

The next section details machine learning uses to compress data [[2021112662]]

Compression and Machine Learning

The easiest way to reduce data transmission is to delete redundancies or to round them to near values. Sensors often generate time-correlated data. For example, the temperature may vary slowly. Run-Length Encoding (RLE) takes advantage of the adjacent clustering of symbols that occur in succession. It replaces multiple symbols with a tuple that contains the symbol and the number of times it is repeated. The authors of [@8766590] apply Delta Encoding followed by RLE at the end node. In [@8249368] delta compression allows sending only the difference between two consecutive temperature measurements. Data are also usually quantized to round the measures to significant approximations requiring fewer bits for coding. They are often aggregated ([@8653620] or [@8108772]).

Approximating the measurements reduces their size also [@8478466]. One can compress signals by approximating them with auxiliary, more simple functions. Lightweight Temporal Compression (LTC) [@1367273] is an energy-efficient lossy compression algorithm that maintains memory usage and per-sample computational cost in O(1). LTC estimates data points using a piece-wise linear function that guarantees an upper bound on the maximum absolute error between the reconstructed signal and the original one while maintaining a memory usage and per-sample latency in O(1).

Classical compression approaches based on dictionaries or entropy coding have been adapted to IoT, like [@8767326] where a specific dictionary is created for different kinds of data depending on their change frequency.

Transform methods are classical tools for compressing data but may be CPU resource consuming. [@8091030] evaluates several lossy compression algorithms for efficiently storing weather sensor data based on the encoding of temporal changes and three signal transformation algorithms on spatial data. Specifically, they evaluate reconstructed weather sensor data fidelity using Discrete Cosine Transform, Fast Walsh-Hadamard Transform and Discrete Wavelet Transform (and Lossy Delta Encoding). The objective is to provide useful information for minimizing data reconstruction errors, and more importantly, make sure they are within a tolerable range. Chebyshev compression is considered in [@7179026] and [@7149287].

Compressed sensing is a new technique. As stated in [@4004], in a series of pioneering works by Candes ([@candes2006], [@4472240],[@1614066]) and their co-authors, it was shown that when a signal has a sparse representation in a known basis, one can vastly reduce the number of samples that are required---below the Nyquist rate and still be able to recover the signal (under appropriate conditions) perfectly. This framework suggests compressing the data while sensing it; hence the name compressed sensing. Nevertheless, on the one hand, compressed sensing reduces the number of measurements and the sampling rate. However, on the other hand, it increases the computational complexity of the signal recovery ([@8868926]). The signal is recovered approximately by solving a convex relaxation of a non-convex optimization problem. [@8662558] proposes a unified approach for compression and authentication of smart-meter reading in advanced metering infrastructure. In [@7469055] an algorithm is designed which combines the accuracy of standard lossless compression with the efficiency of a compressive sensing framework. Given the sensor node battery state, the algorithm balances each technique's tradeoff and optimally selects the best compression mode by minimizing reconstruction errors.

Recently, Neural network-based techniques entered the landscape of IoT data compression techniques. In [@8343232], data are compressed by their regression curve obtained from a neural network. In [@7239543], biomedical signals are compressed using autoencoders. These neural networks are three-stage networks with the same input and output dimensions, while the hidden stage has a smaller dimension. Thus, the first stage's output has a reduced dimension compared to the input and constitutes the compressed data.

Another part of transmission compression is header compression, recent work from IETF develops possible ways to improve payload efficiency by compressing packet headers such as ROHC [@rfc3095], or SCHC [@rfc8724].

Prediction methods are also used. Neural networks are known as universal function approximators with the capability to learn arbitrarily complex mappings, and in practice, show excellent performance in prediction tasks. In such context, a sufficiently well trained neural network shows better results than more classic approaches[@Kumar_Rao_Soni_1995]. Thus, the authors of [@8712659] train a RNN predictor followed by encoding with a traditional arithmetic coder block using the probabilities generated by the trained neural network. The decompression is performed symmetrically and requires the trained model for arithmetic decoding. In [@8664582] a prediction scheme is implemented on cluster nodes and cluster heads to reduce data transmission. If the measured data corresponds to the predicted one, it has not to be transmitted. LSTMs are proposed to perform predictions. We decided to push the subject further by implementing the algorithm directly on the sensors instead of relying on simulation. Our PoC experiment aims to back these simulations or disprove them should the system prove unreliable.

On the subject of traffic data prediction, some articles propose to use a similar approach using large LSTMs such as [@zhao2017lstm]. Their multi-feature approach allows them to correlate data and obtain interesting results regarding traffic prediction. We hope to obtain similar results with our curves as we work with network traffic. However, our approach differs in our decision to focus on the effect of predictions on transmission: improvements to LSTM capabilities are out of our scope.

This approach was also tested with energy production forecasting. LSTMs are presented as a possible candidate for energy production forecasting in [@7844673]; the solution seems adaptative enough for our approach to be reliable enough when using LSTM as a forecasting tool, [@hossam] validates this approach by comparing it to other neural networks.

Thus, many compression techniques appeared for many years. Nevertheless, if the "classical" methods present efficient compression ratios, they do not avoid transmitting data. Actually, periodically a sensor senses data, may compress it and then send the compressed payload. Nevertheless, compressed data payloads (plus header) are still sent. New neural network-based techniques appeared, and they avoid sending data at all in some situations where the prediction is good, but to our knowledge, they have not been tested with actual data and on real equipment. The goal of our test is precisely to propose a validation in real conditions.

For this approach, the prediction algorithms used rely on the approach from[@hossam]. We aim to have a reliable data prediction based on an LTSM neural network and run the predictor on both the sensor and the network infrastructure. As we can expect prediction performance reliable within a 10% Mean Absolute Percentage Error (MAPE) (equation [equation:mape]{reference-type="ref" reference="equation:mape"}), we might expect a complementary compression coefficient up to 90% for our experiment. Such a compression ratio would allow us to build sensor networks where each device consumes less bandwidth, thus further improving the scalability of LPWANs solutions.

MAPE in this experiment was calculated as follow: $$\label{equation:mape} MAPE = \frac{1}{n} \sum_{i=1}^n \bigg| \frac{C_i-M_i}{C_i} \bigg|$$ With $M_i$ as Measured value, $C_i$ as consolidated value and $n$ as sample size

With our experiment, we test various neural network sizes and transmission thresholds to measure how these parameters might influence the compression ratio of our device's transmissions.

Next section

The next section details our experiments [[2021112663]]

Experiment

{#fig:schem_cartes_dev width="0.95\linewidth"}

We embarked an LSTM algorithm similar to the ones studied in [@8664582] and [@hossam] onto an electronic device as a way to test the experimental feasibility of these solutions. These articles propose to use LSTMs that are sufficiently simple to be implemented and embarked onto devices.

The devices used for this experiment are STM32L476 [@stm32l476] as measurement and calculation device which generates prediction data and compares it to measurements, Semtech's SX1276MB1MAS [@lora_transmitter] as LoRa transmission board, and STM32 Nucleo Expansion Board [@measurement_card] to measure the energy consumption of LoRaWAN transmissions.

The datasets we used are occupancy data of cellular base stations for the 1st dataset and power consumption of a smart building for the 2nd one, in function of the time. We used the 1st dataset for all experiments except for those presented Figure 1.5{reference-type="ref" reference="fig:courbe_2D_1h_2_dataset"}.

For these experiments, all experiment are realised with 16-bits operations except for 1.7{reference-type="ref" reference="fig:courbe_quantification"} where 32-bit operations are realised through simulation in Python using the TensorFlow library and 8-bit operations are realised onto the device. All experiments with fixed threshold are run on sensors with transmission minimisation and all variable thresold are simulated.

Hand coding the neural network

Initially, we thought of basing our experiment on EdgeImpulse [@edgeimpulse]. EdgeImpulse is an easy-to-use and well-documented framework to generate ML models from actual sensor data and automatically embed them onto the device. EdgeImpulse was a strong candidate to support our experiments on sensors. Unfortunately, the framework offered from EdgeImpulse did not support LSTM functionalities, thus was not adapted to our use case.

LSTM are a special kind of RNN capable of handling short-term memory while keeping tabs on long-term information. LSTM consists of a repeating module that consists of five gates detailed on 1.2{reference-type="ref" reference="fig:lstm_presentation"}, and keeps part of its long term memory with its cell value ($c_t$).

![LSTM Network extracted and reworked from [@colah]](Figures/Chapter5/LSTM Cell Colah - Thèse.png){#fig:lstm_presentation width="0.65\linewidth"}

The first sigmoïd gate (a sigmoïd is a $\sigma(x) = \frac{1}{1+e^{-x}}$ function) serves to amend the cell state by forgetting a part of it based on the inputs and the weights. The associated operation is as follow:

$$f_t = \sigma(W_f \cdot [h_{t-1},x_t] + b_f)$$

where $W_f$ and $b_f$ are the weights for the forget gate, determined during training, and $h$ is the cell's previous output (which can be a vector considering multiple hidden cells in parallel).

Then we input new information into the memory by combining the sigmoïd input gate with a cell candidate determination function input gate is

$$i_t=\sigma(W_i \cdot [h_{t-1},x_t] + b_i)$$

and cell candidate is

$$\tilde{c}t = tanh(W_c \cdot [h,x_t] + b_c)$$

These operations flush part of the input information and select which part of the data is to be kept as long term information by adding it to the amended previous cell value.

The new cell state $c_t$ is determined by combining the previous cell state $c_{t-1}$, forget gate output $f_t$, input gate output $i_t$ and cell candidate $\tilde{c}_t$, and will pass onto the following iteration of the LSTM. The associated operation based on the previous variables is as follow:

$$c_t = f_t \times c_{t-1} + i_t \times \tilde{c}_t$$

Finally, the cell outputs its results by combining an output gate and the new cell state:

$$o_t = \sigma(W_o \cdot [h_{t-1},x_t] + b_o)$$ $$h_t = o_t \times tanh(c_t)$$

$h_t$ serves as output to the system, and input to the next iteration for our calculation.

As mentioned above, EdgeImpulse did not support this kind of LSTM. By studying the source code of the program generated by EdgeImpulse, we constated that the basic library used to execute the ML algorithm was the TensorFlow Lite (TFLite) [@tflite] library. So, we built an mbed OS firmware that embarks the TFLite exported neural network and transmits data based on the predictions but could not exploit the strength of the TFLite for microcontrollers library as the LSTM operations are not supported yet.[^1]

We trained our LSTM network with TensorFlow [@tensorflow] and exported the LSTM weights and parameters necessary to our implementations (weights, bias and hidden layers' state). We ported the LSTM code successfully onto basic STM32 boards. We injected the parameters into our own implementation of the LSTM network, developed in C, and embarked the LSTM network directly on the sensor.

Our implementation is available following [@clstm_implem]. This implementation was built thanks to the explanations from Christopher Olah [@colah], and the following tutorial on weights and parameters extraction [@fairyonice_lstm].

Dual prediction with LSTM

The usual approach with LSTM is to use measured values as input to the system and obtain a predicted value based on these measurements, as proposed in [@sak2014long]. A modified LSTM architecture is proposed hereafter as this approach does not fit with dual prediction since the backend (i.e. the network side receiving the traffic) does not have access to the sensor's measurements. Our experiment relies on a dual prediction of data to reduce transmission. It relies on two types of data: On the one hand, we have measured values from sensors, and on the other, we have calculated (i.e. predicted) values. Our LSTM needs to keep calculating based on values on both the backend and the sensor as long as transmissions are unnecessary. Actually, as long as no data is transmitted, the backend has only the calculated values, as the backend realizes the same ML-based calculations as the sensor, not the measured ones. Thus, the backend must run the LSTM by re-injecting these calculated data into the LSTM, and, consequently, the device must do the same to check to which extent the data predicted by the backend is far or near the data just measured. When transmissions occur, we can recalibrate the LSTM and use the new transmitted value as a new baseline for calculations.

The firmware we developed is then flashed onto an STM32L476 card to exploit the capability of LSTM combined with LoRaWAN transmissions. This algorithm, built on mbed OS, uses an LSTM Neural Network to predict a theoretical value at a given time. It compares these theoretical values to experimental measurements at the corresponding time. We define a threshold that determines a transmission policy: if the experimental measurements differ from the predicted value within a given margin, the transmission is not realized. However, if the experimental measurements are too far from the predictions, the data is sent over the air from our LoRaWAN device to our LoRaWAN backend. This threshold might be fixed as in Figure 1.6{reference-type="ref" reference="fig:courbe_transmission"}, or we might study the effect of changing the value of the threshold through simulations such as with Figure 1.4{reference-type="ref" reference="fig:courbe_2D_1_3_6"} which studies the compression ratio one can expect with this system when picking various threshold values. Such a data transmission policy may allow us to reduce the band usage for our device.

We plug our transmission card (SX1276MB1MAS) into an STM 32 Nucleo Expansion Board to monitor its energy consumption using STM32CubeMonitor [@STM32CubeMonitor]. We do the same with our STM32L476 card in order to study the overcost of running the LSTM.

On the backend side, we monitor data reception and aggregate the data predicted from the neural network on the infrastructure side with the data received from the sensors, allowing us to plot on a graph the combination of the actual measured data, for which we consider that the information is 100% reliable, and the predicted data which was inferred by the neural network and not disproved by sensor transmission (which is reliable up to a certain threshold). The effect of this threshold will also be studied. In this experiment, our LoRaWAN RG is accessible through SF7 communications and is a part of TheThingsNetwork [@TTN] community LoRaWAN Network. Figure 1.1{reference-type="ref" reference="fig:schem_cartes_dev"} sums up our experimental setup and illustrates the various hardware components we use.

Alongside this real experimental setup, we studied the effect of changing the system's variables through extensive simulations allowing us to shorten the experimental exploration, find interesting parameters for our embedded experiment and confront simulation results to experiments.

We also studied the system's reliability. We defined the system's reliability as the MAPE of the data perceived by the backend compared to the real values. This reliability study investigates the consequences of a bounded lossy compression on the values obtained at the system's output. Our compression is lossy because the data recorded by the backend is not the measured one but the predicted one as long as the predicted one is within the tolerated threshold interval, and thus defining a threshold means we study the tradeoff between accepting a given error on our data and improving the compression ratio. Our compression is bounded because we set it back to the actual data if the loss exceeds the given threshold.

With this experiment, we aim to evaluate:

• the energy cost added by the ML-based compression scheme at the device side;

• the energy saved on the transmission card thanks to data prediction;

• the compression ratio expected with regards to a given neural network size and data prediction threshold;

• the bounded loss introduced by the solution compared to transmitting all values;

• the impact of quantizing the weights of the neural network predictor by running these experiments with quantized parameters instead of floating-point numbers to improve neural network complexity, memory size and finally energy efficiency.

Next section

The next section presents and discuss the results [[2021112664]]

Discussion

Energy

::: {#tab:compare_consumption_calc} With Machine Learning Without Machine Learning

  Mean value (W)          Variance           Mean value (W)           Variance
  $6.31*10^{-4}$       $7.57*10^{-5}$        $7.76*10^{-4}$        $7.61*10^{-5}$

: Comparison of the mean energy consumption of the calculation card and its variance, with and without LSTM-based compression (in Watts) :::

::: {#tab:compare_consumption_trans} With Machine Learning Without Machine Learning

  Mean value (W)          Variance           Mean value (W)           Variance
  $5.48*10^{-4}$       $4.10*10^{-5}$        $9.87*10^{-4}$        $7.12*10^{-5}$

: Comparison of the mean energy consumption of the transmission card and its variance, with and without LSTM-based compression (in Watts) :::

The comparison of the consumption of our cards (Table 1.1{reference-type="ref" reference="tab:compare_consumption_calc"} & 1.2{reference-type="ref" reference="tab:compare_consumption_trans"}) shows a save of around 40% on transmission cards. Considering IoT systems similar to our own with measurements stating that calculation and transmission consume about the same, this would represent savings of around 20% on both transmission and battery life. Considering the card we are using, an LR6 battery with a 1200mAh charge would power our device for around ten months without embedded ML calculations and about a year with ML calculations.

{#fig:stm32cubemon width="0.8\linewidth"}

Figure 1.3{reference-type="ref" reference="fig:stm32cubemon"} presents the energy passing through both our network card and calculation card, measured using STM32CubeMonitor, which permits us to measure and log instantaneous consumption for our device, in function of the time. The device lifecycle follows a two-step routine. Most of the device's life is spent in a sleeping state with low energy consumption. Here in our illustration, the device's sleeping state is around 9s long to respect LoRaWAN's duty cycle. The device will, exceptionally or regularly, transmit data based on its measurements. Transmitting is the other step in the routine. Transmissions translate in power consumption as three transmission spikes corresponding to data emission and the opening of two LoRaWAN listening windows. A residual energy consumption of about $4.10^{-4}$W can be noticed for the calculation card, while it is about $5.10^{-5}$W for the transmission card. The calculation card embarks a dedicated OS which requires more permanent consumption. Irregular energy spikes can be observed for the calculation card, which is due to OS eventing. Our ML algorithm directly results in transmission spikes. Except for the operations realized by the OS on the calculation card, no transmission means no power spike, which leads to less power consumption as a whole, a result that can be observed on the transmission card's power consumption. We would observe regular power spikes with regular transmissions, but with our method, these spikes are completely cut off.

Compression and Mean Absolute Percentage Error

{#fig:courbe_2D_1_3_6 width="0.8\linewidth"}

Figure 1.4{reference-type="ref" reference="fig:courbe_2D_1_3_6"} presents the MAPE and the compression ratio we can expect with regards to the size of the neural network and the decision threshold. We observe that, as expected, the compression ratio improves with the threshold but that the MAPE worsens. The consequences of the number of hidden layers is not significant.

{#fig:courbe_2D_1h_2_dataset width="0.8\linewidth"}

Experimenting with different datasets (Figure 1.5{reference-type="ref" reference="fig:courbe_2D_1h_2_dataset"}) show how the performances of the neural network in its prediction greatly influence the quality of the compression scheme. With a better overall MAPE, one might achieve around 60% compression accepting as little as 1% error in its transmissions.

The questions that come with these curves need to be addressed directly by the user. A user with concern with precision will prefer a lower MAPE, thus obtaining a lower compression ratio. If a user accepts a 1% error on its global data, setting its transmission threshold around 8%, He would end up with a 30% compression ratio for our first dataset and 85% compression ratio for the second one. Accepting more errors would permit compression ratios up to 90%. We note that the compression ratio is low with a strict threshold, but remember that contrary to classical compression methods where at least a header is sent, no packet is sent with our method when we compress. Thus, for a strict threshold of 10%, we decrease the overall traffic by one packet over five (20%) while keeping a global error on our overall data around 2%.

Backend considerations

{#fig:courbe_transmission width="0.8\linewidth"}

Figure 1.6{reference-type="ref" reference="fig:courbe_transmission"} presents a comparison between the measured time-series as transmitted without ML and the calculated time-series improved with transmissions. The Calculated Data curve consists solely of data calculated by the LSTM neural network. The Measurements Data curve corresponds to our LSTM target data, and its value end up transmitted should the calculated data end up being too far from the measurements. Finally, the Combined Data is the data curve as seen on our backend-side: the calculated data improved by the measured transmission should the two curves differ above a given threshold.

Quantization

{#fig:courbe_quantification width="0.8\linewidth"}

Figure 1.7{reference-type="ref" reference="fig:courbe_quantification"} presents our backend-side time-series as a function of the time index, combining calculated data and received measurements. The three curves on this figure differ by the number of bits necessary to code the LSTM weights, hidden layer parameters, cell state and input data. The dotted blue curve is obtained by running the dual prediction algorithm in a Python simulated environment and operating with 32-bits-encoded floats. The plain orange curve is obtained by directly running the dual prediction algorithm on the device with an LSTM operating with 16-bits-encoded floats. The dash-dot green curve is obtained by directly running the dual prediction algorithm on the device with an LSTM operating with quantized parameters encoded on 8-bits integers.

Measurements of the compression ratio for the three above curves show no significant degradation between the three systems (the compression ratio almost does not change and remains around 70% for the three curves). 8-bit quantization is a well-documented solution to reduce the operations' complexity while working with neural networks on constrained devices. This also proves to be confirmed with our implementation of LSTM. Efficient quantization is essential when working with Neural Networks; it reduces the complexity of the operations, which might, in turn, allow for savings in processing power and battery life. Further works would be necessary on quantization efficiency once the LSTM operation is ported to the TFLite for microcontrollers library.

Next section

The next section discusses possible storage of Neural Network weights within the DNS [[2021112665]]

Storing and sharing ML weights

When working with dual prediction, synchronizing data between backend and device is crucial should one want to exchange information regarding its own neural network. In a similar way that we did in [[2021112652]], we aim to exchange Machine Learning information on the backend side using the DNS infrastructure. Such a solution would allow to benefit from the DNS's deployment, security and trust network to address issues such as keeping the information available, easy-to-use and exchanged using standard protocol.

This section provides insight on possible solution for storing and exchanging the ML weights using the DNS, its infrastructure and extensions, based on different use cases depending on the size of the neural network, but also on possible different IoT network topologies.

Classic DNS use

A first possible scenario for storing and sharing weights would be to host the weights directly on the DNS infrastructure. This first scenario is the same as the Context rule DNS storage from the previous chapter. Thus the only question for storing rules within the DNS would be the size of the neural network.

A DNS TXT RR consists of records with a total size of up to 65535 bytes. However, as mentioned in [@rfc6763]:

"the total size of a typical DNS-SD TXT record is intended to be small -- 200 bytes or less. In cases where more data is justified (e.g., LPR printing [BJP]), keeping the total size under 400 bytes should allow it to fit in a single 512-byte DNS message"

thus a DNS TXT RR with this paradigm ought to be of reasonable size.

Each ML weight can be encoded on 24 bits (3 digits, 8 bits per digit) thanks to 8-bit quantification, as a DNS TXT RR stores bytes of text, thus would store the ML values as text instead of using more optimized space, but conversion to another base could be considered to reduce storage size.

An LSTM network number of weights can be calculated based on its number of cells.

The calculation for a simple, single-input, network is as follow:

Let $H$ be the number of hidden cells within the LSTM.

Number of weights = $4 * H^2 + 11 * H + 1$

The details for such calculation is as follow:

• $4 * H$ values for the weights associated with the input value

• $4 * H * H$ values for the weights associated with the hidden layers

• $4 * H$ values for the LSTM bias

• $2 * H$ values for the initial state of the hidden layers and the initial state of the cell

• $H$ values for the dense layer's weights

• $1$ value for the dense network's bias

Using this 24 bit "standard" for ML values, a simple LSTM network with $1$ hidden cell within the LSTM should fit within 48 bytes, thus would fit within the 200-bytes classic DNS message.

The 200 bits limit is attained by using 3 hidden cells within the LSTM (210 bits), and the 400 bits is reached with 4 (327 bits).

Thus heavier neural networks would hardly fit within a 512-bytes message, thus needing additional messages for which the DNS would hardly fit. Using a different encoding for the values, changing the base up to base 36, for example, would allow for LSTMs of size up to 6 hidden layers (7 would be within reach as it fits within 548 bytes).

For even heavier networks, the DNS would prove non-competitive and requesting data from an API would prove better and allow for more functionalities.

Using DNS and APIs for heavier networks

We can design a fallback mechanism for the backend for heavier networks based on a common API for ML models.

Designing such an API model would allow additional functionality to the user, such as generating the neural network via a web interface based on its own time-series.

This solution would help popularise ML transmission minimization by providing to its user a pre-coded compression source code, directly embeddable onto its sensors, and would take care of provisioning both the ML parameters' API and provision the DNS to reference the API location.

Additionally, the time-series provided by the user could help to gather data to improve the neural network training, thus exploiting each individual time-series to improve the overall system performances and provide better solutions to its user over time.

Exploiting DNS-SD paradigms in mesh communications

Considering IoT networks, designing the system to allow communication directly between devices would help improve the overall performance.

The LoRa modulation allows for such a communication solution as it can work with mesh topologies. Using ML compressed communication would allow to upscale LoRa mesh networks by limiting interferences between communicating devices.

However, how would a device transmit the details for its ML model to its peers?

We propose to learn the lessons from the DNS-SD paradigm in a dual connectivity infrastructure to support the discovery and advertising of ML model within a given local coverage.

In this case, a LoRa device would transmit its ML data to its peers as a service advertisement which would be saved by its peers to process its time series and follow the variations from its parameters, increasing the knowledge of its peer within the network.

In the case of a newly arrived device, the overall ML parameters could be forwarded from the RG, which could serve as a DNS proxy as described in [@rfc8766].

The ML parameters would need to be encoded as base-64 values, allowing for easier transmission of the 8-bit quantified values instead of fitting to the 3-byte-per-value, text-readable constraint from the DNS TXT record.

Additional information can also be advertized through DNS-SD, such as the nature of the sensor, its version, its functionality, or listening cycle, making DNS-SD an interesting candidate for weight advertising in mesh communications.

Next section

The next section concludes the chapter [[2021112666]]

Conclusion

We built an experimental testbed to check the capabilities of on-boarding LSTM algorithm on-sensor to forecast data, achieve dual prediction, and eventually compress data traffic and save energy. An LSTM algorithm was developed and integrated into small, constrained hardware to obtain these results; its source code is accessible following [@clstm_implem]. Our findings show that it can efficiently minimize traffic while preventing non-relevant transmissions to occur with a significant impact on energy consumption. We observed the impact of the neural network size and the decision threshold on the compression ratio and the MAPE. Our system allows efficient compression while keeping the user within a reasonable error margin. It can be customized depending on precision and compression tradeoff requirements. We also check the impact of the quantization of the LSTM parameters because of device constraints and decrease the algorithm's complexity. We observed no significant degradation in the system when using 8-bit quantization.

Compressing data with this kind of Bounded Lossy Compression allows to expend battery lifetime depending on the accepted margin of error. Our results show an excellent compression ratio compared to the state-of-the-art. Note that our scheme avoids sending any data while classical compression mechanisms at least send a frame header every time some compressed data is sent. Moreover, an extensive energy consumption study proves that our algorithm saves an important energy ratio that can be used in further communication.

Storing the ML weights in the DNS seems feasible once we run the number seem possible. We presented three approach for storing and sharing the ML weights within a network with a straightforward approach based on the DNS, an accompanying approach combining APIsand DNS and an autonomous approach based on DNS-SD paradygms.

Further approach would consist of selecting multiple features on multiple values to attain more precision in the calculation with a more complex recalibration. Works are carried by contributing to the actual TFLite community to propose a complete port of the LSTM libraries from the global TensorFlow project to the TFLite for microcontrollers community.

[^1]: We discussed this issue with contributors from both EdgeImpulse and TFLite for microcontrollers and will do our best to carry on with this work and use it to contribute to the support of LSTM capabilities on TFLite.

Next section

The next section is the final conclusion [[202111267]]

Conclusion

This thesis presented various approaches to improve interoperability and performances of LoRaWAN-based IoT solutions by leveraging the existing DNS infrastructure as a common ground for application developers and researchers. The DNS is a known protocol for the Internet community, with various open-source implementations for clients, servers or within frameworks. Tools were deployed to measure its performances and modulate its use. Its community is open and proposes new use-cases and improvements that keep the DNS community up to date with new developments, protocols and network paradigms developed by the industrial world or the research community.

Within the IoT ecosystem, LoRaWAN is flexible; backed by an ever-increasing community of industrial stakeholders and a newly-created official academic community, the LoRa Alliance and its LoRaWAN protocol poses as a major actor of the IoT ecosystem. The evolutions from the discussions of the Alliance are closely followed by LoRaWAN applications developers as the reference LoRaWAN open-source Stack, ChirpStack, encountered 17 minor releases and 1 major release within the last 3 years.

Current IoT applications encounter, with their latest development, the same issues as the Internet. IoT technologies are riddled with scalability, interoperability, mobility and roaming, transmission efficiency, availability, reliability and other security issues such as trust and privacy. The DNS contributes to solving many of these issues on the Internet, hence our interrogation on possible improvements to IoT systems backed by the DNS infrastructure.

This thesis studied IoT systems regarding the following key aspects: Naming, Roaming, Header Compression and Payload Compression. This study did not aim to embark DNS protocols onto sensors but instead to use DNS on the infrastructure side to support IoT improvements. This thesis presented experimental work on LoRaWAN regarding various scenarios to test IoT solutions, applications and use-cases. This experimental approach introduced additional constraints such as working with reference implementations of the solutions, generating actual IoT traffic for measurements and analysis, respecting airtime constraints or device lifecycle.

Experimenting with roaming requires an interconnection agreement between network operators, usually based on a 'One-to-One' interconnection or by building an interconnection 'Hub'. We exploited a federated approach to the IoT interconnection by proposing the IoTRoam architecture, federating different organizations to allow flexible mutual authentication and authorization between any backend element in roaming situations, without a direct and explicit roaming agreement (by interconnecting Network, Application and Join Servers between operators). The interconnection agreement is implicitly given when the organization joins the IoTRoam federation.

By experimenting with LoRaWAN, our architecture proposes a solution that considers the constrained characteristics of IoT environments. Our approach to building our roaming architecture was to use the combination of the DNS infrastructure and a PKI to build a secure open roaming infrastructure accessible to public and private LoRaWAN operators. We leverage the possibility to set up private LoRaWAN networks for free. We designed, built and deployed a proof of concept architecture to test the Roaming capabilities offered by the ChirpStack solution and test roaming between private and public LoRaWAN. The infrastructure was validated by testing LoRaWAN connectivity for devices in a roaming context by studying various onboarding scenarios, measuring onboarding time and communication delays.

We studied the consequences of caching and prefetching DNS information with mobile devices in a city through simulations of communications between mobile device and IoT infrastructure. DNS prefetching is an efficient tool to reduce on-the-fly DNS queries necessary for devices communication. Prefetching the information on nearby antennas can completely prevent DNS queries by performing them in advance around the closest antennas, but at a cost, as devices request more antennas, especially in a highly mobile environment.

Our combination of an ML predictor and prefetching allow for an interesting reduction of DNS requests realized compared to a standard caching-only solution and a reduction in the number of gateways realizing prefetching operation compared to soliciting the closest nearby antennas. Using DNS allow us to exploit its strength as a known distributed database solution to fill localized caches to provide information as soon as needed as well as purge it through time when mobile devices leave the antennas' coverage.

Our simulations were realized within the frame of providing roaming connectivity information to devices, but could be applicable when querying other information necessary for device communication such as certificates stored with DANE, compression parameters or any device specific information stored in the DNS such as pointers to additional servers.

We built a viable and operationally feasible infrastructure that could be integrated into existing IoT infrastructures with minimum changes. We followed the WBA guidelines for open roaming and satisfied the requirements outlined by employing open standards used on the Internet to achieve our vision. We deployed a PoC infrastructure and provided all the necessary building blocks so that the community could make use of them. These experiments lead to three adopted Change Requests after submission to the LoRa Alliance.

We discussed the IoTRoam initiative with several institutions to run interoperable testing using the federated platform; running additional tests with these institutions would help us study the impact of heterogeneous backend infrastructures and their effect on the quality of the communication channel and would also allow us to gather additional data on the impact of DNS complete resolution on the LoRaWAN/IoT traffic. As the objective is to interconnect networks using different IoT technologies, the next steps consist of testing roaming interoperability with NB-IoT, 5G or Wi-Fi. For ED onboarding, we are also working on integrating DANE with DNSSEC since the certificate data itself can be stored in the DNS, possibly replacing or completing the PKI.

Complementary to our work with interconnecting IoT infrastructure, we experimented with SCHC remote rules management and sharing as a solution to improve the scalability of LPWANs solutions. Providing a way to exchange rules information between backend would offer new possibilities to provide more flexibility to the network, thus improving the flexibility of IoT solutions in contexts such as roaming devices. The proposed mechanism exploits the DNS infrastructure as a solution to leverage DNS performances and improve rules querying capabilities within the network. Unfortunately, rules are too heavy to be embedded directly as DNS Resource Records; thus, a fallback mechanism was designed based on APIs and exploit DNS caching mechanism to store rules identifiers and version numbers. DNS, as an optimized, hierarchical and distributed database, could assist in identifying the location of the server where the context rules are stored feasibly on the Internet. Hopefully, using such a mechanism would allow for a seamless transition, from pre-configuring the information needed on the backend to building it dynamically, on the fly, based on actual needs when operating the network.

DNS would prove an efficient solution to introduce more flexibility and improve scalability when using SCHC. Our solution would provide open access to SCHC parameters as a way to support roaming capabilities. Improving SCHC flexibility, scalability and assisting SCHC when a device is roaming are key considerations to increase the technology's adoption, and DNS might help by hosting rules outside the scope of the ED's associated backend without hindering the transmissions. To assist with this problem, we deployed a dynamic context resolution architecture based on DNS for SCHC compression/decompression and studied the consequences of such mechanism on the system latency and other possible consequences on LoRaWAN communications.

For this experiment, we built a SCHC-enabled LoRaWAN infrastructure. SCHC was able to efficiently compress headers from the 44-octets IPv6+CoAP header down to a few octets, which leads to reduce header size up to a 22-factor and enable the use of IPv6 over networks that would be unable to support it, such as SigFox and its 29 octets frame or LoRaWAN which ranges from 59 octets to 250 octets. Using SCHC to send IPv6 packets over LPWAN is proven to be an efficient way to consider the scarcity of radio resources. SCHC is also able to work within a reliable timeframe. Querying time within a huge database was not studied and would need additional data regarding actual SCHC usage on LPWAN to provide interesting insight, but when working with a few devices, SCHC can decompress data consistently with a few microseconds; an operation that is almost transparent with regards to other mechanisms specific to LPWAN, such as LoRaWAN's reception delays.

By exploiting the DNS infrastructure, one can query the context signature within a satisfying timeframe (between 30 and 100 milliseconds) and fall back onto the associated context storage API within 650 ms. In a best-case scenario, the 650 ms delay would be furtherly reduced by caching; our Atlas probes measurements lead us to believe that using a DNS-only mechanism and building a context cache would lead to reducing the 650ms delay down to tens of milliseconds. These results concerning the DNS-only system and its performances are consistent with results measured in other studies. Such a mechanism does not hinder the communication as it is kept under the delay of the first reception windows and benefits from the information caching should the answer need a different SCHC rule. Should we need to respond to the device within the first reception window, 350ms of data handling are left in the worst-case to enqueue the response onto the RG.

Further work regarding the SCHC protocol would require additional data from the actual use of the SCHC protocol. Studying SCHC uses would help to define the research direction by putting them into contrast with the production issues introduced by the protocol. Studying SCHC context rules outside their theoretical construction, but rather based on actual rules used in production, would help further identify eventual new constraints introduced by the protocol and define useful research direction. Improving the compression capabilities of LPWANs is a crucial concern for the technology. Reducing packet size reduces airtime, which is an efficient way to improve the scalability of LPWAN solutions. Another solution to reduce airtime of LPWANs transmissions is transmission minimization. Our approach with transmission minimization is complementary to compressing header using SCHC. SCHC relies on suppressing and optimizing predictable data within the transmission's header. But what if the actual relevant data from the payload is predictable. In this case, would it be possible to study transmission minimization paradigms in which compressing communications would rely on predicting a device's transmission payload and preventing its transmission if it is unnecessary?

We decide to further our approach regarding transmission efficiency by compressing data. The easiest way to reduce data transmission is to delete redundancies or to round them to near values. When working with sensors, data is often time-correlated. For example, the temperature may vary slowly. Recently, Neural network-based techniques entered the landscape of IoT data compression techniques. Data can be compressed by their regression curve inferred from a neural network. More complex prediction methods can also be used. Neural networks are known as universal function approximators with the capability to learn arbitrarily complex mappings, and in practice, show excellent performance in prediction tasks. Nevertheless, if the "classical" methods present efficient compression ratios, they do not avoid transmitting data. Actually, periodically a sensor senses data, may compress it and then send the compressed payload, but compressed data payload and its associated header are still sent.

New neural network-based techniques appeared, and they avoid sending data in situations where the prediction is good. A neural network-based predictor is implemented in the ED and also in the backend. If the sensed data is well predicted, no data is sent, and the backend uses the prediction. Otherwise, it is sent. We experimented around these approaches by testing them in real experiments. Thus an actual LSTM implementation was developed and embedded on sensors to back or disprove the results obtained through simulations by the scientific community.

Our experiment studied the parameters to deploy such a neural network-based approach by experimenting with various use-cases such as varying the transmission decision threshold, the size of the neural network and the number of digits necessary to encode the weights and the variables. These parameters lead us to study the subsequent compression ratio and error rate, the energy consumption of the algorithm, the effect of quantization.

We built an experimental testbed to check the capabilities of onboarding LSTM algorithm on-sensor to forecast data, achieve dual prediction, and eventually compress data traffic and save energy. A deep LSTM algorithm was developed and integrated into small, constrained hardware to obtain these results; its source code is accessible following [@clstm_implem]. Our findings show that it can efficiently minimize traffic while preventing non-relevant transmissions to occur with a significant impact on energy consumption. The overall system shows no significant impact from varying the neural network size and studied the impact from the decision threshold on the compression ratio and the MAPE. Our system allows efficient compression while keeping the user within a reasonable error margin. It can be customized depending on precision and compression trade-off requirements. The impact of the quantization of the LSTM parameters is checked because of device constraints and also to decrease the algorithm's complexity. No significant degradations in the system are observed when using 8-bit quantization. Our experiment shows that these machine learning algorithms can be easily embarked onto EDs, their performances are not lacking, and their storage size and energy consumption does not hinder the device's usual functioning.

Compressing data with this kind of Bounded Lossy Compression allows expending battery lifetime depending on the accepted margin of error. Our results show an excellent compression ratio compared to the state-of-the-art. It is to note that our scheme avoids sending any data, while classical compression mechanisms at least send a frame header every time compressed data is sent. Moreover, these two approaches are complementary, and data can be compressed using classical compression mechanisms once the irrelevant information was suppressed. An extensive energy consumption study proved that our algorithm saves a portion of the device's energy that can be used in further communication. We developed arguments regarding ML weights storage capabilities for IoT infrastructure backed by DNS approaches. Such a solution seem feasible with regards to the binary size of the parameter file, but would require experimental work to back our assumptions with numbers.

Further approach would consist of selecting multiple features on multiple values to attain more precision in the calculation with a more complex recalibration. Works are carried by contributing to the actual TensorFlow Lite community to propose a complete port of the LSTM libraries from the global TensorFlow project to the TensorFlow Lite for microcontrollers community. Other works include studying the maximum supported size for neural networks to further our knowledge of small size neural networks and their performances.

In a nutshell, backing the DNS as a core service for interconnecting networks, hosting communication protocol rules to enhance IoT solution architecture in our different experimentation showed relevant results. We worked on building a roaming, easy to use, federated infrastructure to interconnect LoRaWAN networks as a solution to improve interoperability between IoT infrastructure backed by the DNS. We developed improvements to the SCHC protocol by hosting rules on the DNS infrastructure and allowing backend elements to query a global DNS zone that hosts the rules IDs and version number. Finally, we developed a transmission minimization algorithm by embedding a machine learning algorithm based on the LSTM algorithm onto LPWANs sensors and studied its impact on the underlying data and infrastructure. The results presented in this thesis show that the DNS, despite being one of the oldest protocols used on the Internet, can propose relevant improvements to infrastructure deployments and accompany new IoT use cases. The latest and ongoing work from the DNS community might assist in securing the aforementioned applications, such as switching from classical DNS to its more secure, latest implementations, as well as confirm information authenticity or assist in service discovery to support IoT applications.

Next section

This section is the last.