Analytical Assessment of Binary Data Serialization Techniques in Iot Context [Evaluating Protocol Buffers, Flatbuffers, Messagepack

Analytical Assessment of Binary Data Serialization Techniques in IoT Context [Evaluating Protocol Buffers, FlatBuffers, MessagePack,

and BSON for Sensor Nodes]

Amrit Kumar Biswal Obada Almallah Student Id: 873052 Student Id: 894304

Advisor: Prof. Marco Brambilla

Dipartimento di Elettronica, Informazione e Bioingegneria Politecnico di Milano

This thesis is submitted for the degree of Master of Science in Computer Science and Engineering

December 2019 We would like to dedicate this thesis to our families, near and far. Acknowledgements

First and foremost, we would like to express our appreciation to the power of teamwork and synchronized efforts that led the execution of this thesis. We would like to express our gratitude to our supervisor Prof. Marco Brambilla, who guided us in the right direction and helped us overcome the obstacles faced. Moreover, we would like to express our appreciation and acknowledge the power and vigorous efforts of the open-source community in developing and maintaining technologies that helped us conduct our experiments. Last but not least, we would like to thank our families and friends for the support, motivation, and inspiration they empowered us with that helped us stay on track. Special thanks to our friend Giacomo Tento for providing us with the Italian translated abstract. Abstract

The exceptional development of IoT-enabled technologies has been pervasively fostering smart solutions that drive the innovation in various industries. This wide-scale and rapid development in the IoT market faces different challenges related to interoperability, due to fragmented technologies and applications, and related to the need of more IoT-specific standardization applied to the IoT infrastructure that considers the constraints and limitations of IoT applications. These issues can be traced back to the need of achieving a better resource efficiency in IoT systems due to the resource-constrained nature of IoT devices andthe limitations posed by the low power networks bandwidth, which in turn induces the IoT industry to apply different measures in order to achieve efficiency on the devices and on the network. These measures aim at reducing the overall traffic at the network level as well as reducing power and memory consumption at the device level. By achieving optimal network and device settings, the IoT system can in turn have the capacity to offer more services on the application level which consequently accelerates the achievement of the vision and expectations of IoT. One of the operations affecting device-level efficiency lies in the mechanism applied to structure and serialize the payload data. In this thesis we evaluate the resource-efficiency of a group of binary-based mechanisms in dealing with sensor nodesdata in purpose of arriving to candidate technique(s) that have the potential of being standardized within the IoT infrastructure as interoperable data format protocol(s). Keywords: IoT, Internet-of-things, Performance, Evaluation, Binary, Semantic, Data Serialization, Protocol Buffers, FlatBuffers, MessagePack, BSON Sommario

L’eccezionale sviluppo di tecnologie abilitate all’IoT ha pervasivamente promosso l’adozione di smart solutions che guidano l’innovazione in vari settori industriali. Questo rapido e consistente sviluppo avvenuto del mercato IoT deve tuttavia affrontare, a causa della fram- mentazione di tecnologie e applicazioni utilizzate, diverse sfide legate all’interoperatibilita’, collegate alla necessita’ di una standardizzazione maggiormente specifica applicata all’infrastruttura IoT che tenga conto di vincoli e limitazioni delle applicazioni IoT. Tali questioni hanno radici nella necessita’ di un uso piu’ efficiente delle risorse disponibili nei sistemi IoT, a causa della limitatezza dei mezzi dovuta alla natura dei dispositivi IoT e ai vincoli imposti dalla capacita’ delle reti, le quali, d’altra parte, stimolano l’industria IoT ad appliccare differenti soluzioni volte all’efficienza di tali dispositivi su tali reti. Queste soluzioni mirano alla riduzione del traffico complessivo a livello della rete e al contempo a limitare l’utilizzo energetico e di memoria a livello del dispositivo. Con l’utilizzo di impostazioni ottimali sia per la rete che per il dispositivo il sistema IoT diventa in grado di fornire maggiori servizi a livello di applicazioni, i quali di conseguenza accelerano l’avvicinamento verso l’obiettivo dell’IoT. Una delle operazioni che influenzano l’efficienza a livello di dispositivo si trova nel meccanismo utilizzato nella strutturazione e serializzazione del carico di dati. In questa tesi, valutiamo un gruppo di meccanismi a base binaria sulla base della loro efficienza nel confrontarsi con dati dei sensor nodes con l’obiettivo di isolare le tecniche con il potenziale di essere standardizzate all’interno dell’infrastruttura IoT come protocolli interoperativi di data format. Contents

Acknowledgments iv

Abstract v

Sommario vi

1 Introduction 1 1.1 Context & Motivation ...... 1 1.2 Research Goals ...... 3 1.3 Thesis Structure ...... 4

2 Background 5 2.1 Internet of Things ...... 5 2.2 Key Features and Challenges ...... 6 2.3 The Internet of Things Architecture ...... 8 2.4 Connectivity Protocols/Standards ...... 9 2.5 Models ...... 13 2.6 Data Exchange Protocols ...... 16 2.7 Data Format Protocols ...... 18 2.7.1 Text-Based Protocols ...... 19 2.7.2 Binary-based Protocols ...... 21

3 Related Work 24 3.1 Data Exchange Protocols Evaluation ...... 24 3.2 Payload Optimization Approaches ...... 26 3.3 Comparative Discussion ...... 29

4 Binary Data Serialization in Sensor Nodes 31 4.1 Introduction and Case Statement ...... 31 4.2 Implemented Protocols ...... 32

vii 4.3 Performance Metrics ...... 34 4.3.1 Qualitative Analysis ...... 34 4.3.2 Quantitative Analysis ...... 35

5 Hardware Setup and Implementations 37 5.1 NodeMCU Specifications ...... 38 5.2 Arduino IDE ...... 39 5.3 Platform Configuration ...... 39 5.4 Protocol Buffers Implementation ...... 39 5.5 FlatBuffers Implementation ...... 40 5.6 MessagePack Implementation ...... 41 5.7 BSON Implementation ...... 42

6 Simulation Setup and Implementation 43 6.1 Contiki OS ...... 43 6.2 Cooja Simulator ...... 44 6.3 Simulation setup ...... 45 6.4 Benchmarking ...... 47 6.5 Nanopb (Protocol Buﬀers) ...... 50 6.6 FlatCC (FlatBuﬀers) ...... 50 6.7 CWPack (MessagePack) ...... 51 6.8 BINSON (BSON partial implementation) ...... 51

7 Experiments and Discussion 52 7.1 Payload Structure Types ...... 52 7.2 Hardware Runs ...... 54 7.3 Simulation Runs ...... 54 7.4 Results ...... 55 7.4.1 Hardware Results & Discussion ...... 55 7.4.2 Simulation Results & Discussion ...... 57 7.5 Qualitative Outlook ...... 61

8 Conclusions 63 8.1 Workﬂow Summary ...... 63 8.2 Critical Discussion ...... 64 8.3 Future Work ...... 66

viii List of Tables

7.1 Resulted Payload Size (H/W) ...... 55 7.2 Serialization Speed (H/W) ...... 55 7.3 Deserialization Speed (H/W) ...... 55 7.4 Total Speed Performance (H/W) ...... 56 7.5 Library Overhead (H/W) ...... 56 7.6 Total Payload Size (simulation) ...... 57 7.7 Serialization time (simulation) ...... 58 7.8 Deserialization time (simulation) ...... 58 7.9 Library Overhead (simulation) ...... 58 7.10 Memory Footprint - serialization (simulation) ...... 58 7.11 Memory Footprint - deserialization (simulation) ...... 59 7.12 Memory Footprint – Serialization with Deserialization (simulation) ...... 59 7.13 Average Power Consumption (simulation) ...... 60 7.14 Qualitative View ...... 62

ix List of Figures

2.1 IoT Verticals ...... 6 2.2 IoT Building Blocks ...... 8 2.3 IoT Application Model ...... 9 2.4 Bus-Based Model ...... 14 2.5 Broker-Based Model ...... 15

6.1 Size command outputs ...... 48

7.1 Visualizing Average Power Consumption ...... 61

x Chapter 1

Introduction

1.1 Context & Motivation

Internet of Things has been the driving force behind the intelligence embedded in various environments. These complex networks that connect millions of devices and people around the world is the backbone of “Industry 4.0” enabling fast and autonomous bi-directional data communication between machineries and devices. With its constant growth and incorporation into numerous and diverse industries, the expectations and figures of IoT applications and technologies show how it will become an essential infrastructure powering and driving people’s daily activities and interactions due to the rapidly increasing number of connected “things”. The capabilities and advancements of self-identification, localization, and data acquisition through positioning and sensing technologies remain at the heart of IoT-powered innovations. Substantially, sensor data constitutes the majority of the IoT business logic, since IoT applications rely mainly on sensor data to effectively perform operations of monitoring, control, optimization that eventually enable automation capabilities paving the way of novel applications. In an IoT system, these sensor devices can be deployed via Wireless Sensor Networks (WSN) where sensors communicate with each other either in a multi-hop or in a single-hop fashion relying on radio frequency mechanisms to exchange information and then send target data over the internet, or be deployed in a client/server architecture where each sensor node sends data to the application server over the internet that is then processed to offer various services to end-users such as smart parking, smart factory, and smart city applications. Regardless of the IoT system architecture, applications feed intensively on sensors’ data and these data harvesting devices have resource constraints related to computing power, memory, energy consumption, and limited bandwidth tolerance. These constraints are due to the nature of sensor nodes that run on batteries and on low powered microprocessors and microcontrollers with limited memory and clock frequency. Also, for IoT environment setting, deployment, and operations to

1 CHAPTER 1. INTRODUCTION 2

achieve the IoT vision and expectations, connected devices need to seamlessly communicate through low-bandwidth networks (e.g. 6LoWPAN) where the data link layer payload is extremely limited (e.g. 81 bytes in IEEE 802.15.4 link headers) and thus fragmentation becomes more probable leading to increasement in the sent and received data packets. This in turn result in bandwidth exhaustion over time preventing other services to be offered on the network. The main factors that contribute to increasing the amount of data traffic are the overheads of IoT application layer protocols, the payload size, and retransmissions of data resulted from data loss [1]. While several papers address and evaluate application layer protocols impact on the overall data traffic for example [2, 3, 4], the payload size remain an essential contributing factor to the overall traffic as it could result in fragmentation at the data link layer which should be avoided as it has negative impacts on the battery life of the node [5, 6], the payload size also typically contributes to the usage of the limited storage capacity of sensor nodes. In addition, due to the vast and rapid development of IoT technologies, several interoperability issues have emerged threatening the success and service quality of IoT applications including issues related to semantic and cross-domain interoperability [7]. These issues threaten the IoT vision defined by International Telecommunication Union’s Telecommunications Standardization sector (ITU-T) of utilizing IoT as a global infrastructure enabled by interoperable information and communication technologies [8] that emphasizes the role of machine to machine (M2M) paradigm as a key driver in IoT. To achieve that, the ITU highlights the importance of IoT standardization that should underly the different components of the IoT infrastructure. In fact, standardization and interoperability constitute the major challenges in scaling out IoT and M2M system to match the various market demands [9]. One of these components encompass the methodology of data representation formats that also should adhere to the interoperability condition. Several research papers have surveyed, analyzed, and evaluated enabling technologies across the different layers of IoT stack in order to provide a standardization reference to follow, few examples are [10, 11, 12]. Therefore, optimization of the payload structuring and size is an important task to perform, and the mechanisms chosen to perform this task are required to support heterogeneity and interoperability in order to fully achieve the IoT visions and expectations. In this thesis, the mechanisms we evaluate operate on the semantic layer concerned with format of IoT sensor nodes payload. Cur- rently, text-based formats such as JSON and XML remain common practices for structuring and serializing sensors nodes data. These formats were mainly to utilize due to the increasing number of embedded systems connected to the internet where this connectivity requires a simple yet efficient format for interchanging data between connected devices /cite6861361, and between the devices and the web applications that in many cases rely mainly on these formats. This due to their standardized support for web applications interoperability and simplicity requirements represented. In IoT system, the advantages of these formats represented in human-readability and simplicity of serialization and parsing processes are outweighed by the resulted sizes of messages exchanged in these CHAPTER 1. INTRODUCTION 3

formats due to the overhead of additional characters and labels required, and the processing effort taken to serialize and deserialize these messages. These consequences are affordable in standard web applications computer systems but impactful in resource constrained IoT sensor nodes. Moreover, in M2M communication that does not require human involvement [8], lightweight messages, speed, and power efficiency are considered major priorities, while messages in a human readable format is not necessary.

1.2 Research Goals

The research aims at evaluating the performance of a selected binary-based data serialization techniques in structuring and preparing sensors data. The goal is to achieve an analytical assessment of these techniques through testing each protocol performance in different payload settings, in purpose of exploring and examining resource optimization gains that these techniques could bring in terms of the resulted payload size and the effort of serializing and deserializing such payloads, and thus provide achieve a more optimal and resource-efficient IoT settings that could also achieve the interoperable IoT vision. The selected data serialization techniques are: Protocol Buffers, Flat Buffers, Message Pack, and Binary JSON (BSON). The hypothesis is that binary-based serialization techniques will show an advantage in terms of resulted payload size, and lower consumption of sensor nodes resources mainly memory, processing, and energy. This is regardless of the temporal/ spatial nature of transmitted data. It is also hypothesized that a ranking of techniques will be achieved based on each performance parameter arriving at candidate technique(s) to be potential standard data formats in IoT systems. To carry out the experiments that constitute the benchmark of our comparison, the selected data serialization techniques are tested on two platforms: a microcontroller-based platform NodeMCU, and an OS-based platform where Cooja simulator is utilized to run tests on Zolertia z1 motes that use Contiki OS. CHAPTER 1. INTRODUCTION 4

1.3 Thesis Structure

The rest of this thesis is organized as follows: Chapter 2 walks through the background knowledge describing the concepts that are related to the work that has been performed for this thesis. Chapter 3 presents the literature work relevant to this thesis along with the insights they provide. Chapter 4 explains the details of the employed methodology, tools and technology used in this thesis. Chapter 5 describes the development and implementations of the experiments done on Hardware. Chapter 6 describes the development and implementations of the Simulation based experiments. Chapter 7 presents the results of the experiments and discusses the outcomes. Chapter 8 concludes this report by summarizing the work, providing a critical discussion and advising on the outlook of future work. Chapter 2

Background

This chapter provides a primer in the theoretical background in the domain of IoT, which shall deem useful to follow the rest of the thesis.

2.1 Internet of Things (IOT)

According to the McKinsey Global Institute’s 2015 report - The Internet of Things: Mapping the value beyond the Hype1, IoT is estimated to have a potential economic impact of as much as $11.1 trillion per year by 2025 [13] and as per current trends, Gartner forecasts a 32.9% compound annual growth rate (CAGR) from 2015 through 2020 [14], reaching an installed base of 20.4 billion units for Internet of Things endpoints. Cisco estimates that IoT will consist of 50 billion devices connected to the Internet by 2020 [15]. With a paradigm shift towards service driven businesses, the potential for IoT seems limitless. IoT application settings can be organized into multiple verticals. Undoubtedly, the main aim of IoT is to create smart environments for applications that can be deployed in: Cities - Public health, environment and transportation, Vehicles - Autonomous vehicles and maintenance, Home - chore automation and security, Oﬃces - security and energy, Factories - Operations and equipment optimization, Retail environments - transactions and customer experience, Work Sites - Operations, regulations, health and safety, Human - health and ﬁtness, Outside - logistics and navigation. Examples of these application solutions can be: Smart Parking, Infrastructure Health maintenance and management, Smart Lighting solutions, Waste Management, City Safety and Forest Fire detection, Air Pollution monitoring, Snow Level monitoring, Earthquake early detection, Gas & Water Leakage monitoring, Supply Chain Control solutions, Inventory management, NFC pay- ments, , Smart Shopping applications, Medical Fridges and Transport, Heart rate and Sleep Quality

1https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/the-internet-of-things-the-value-of- digitizing-the-physical-world

5 CHAPTER 2. BACKGROUND 6

Figure 2.1: Verticals in IoT monitoring, Energy & Water Consumption, Remote Control Appliances, Security Systems, Indoor Climate Control, Smart Power Grid, Water Flow control, Goods Shipment Control, Fleet Tracking and many others.

2.2 Key Features and Challenges

In recent times, developments in AI, smart sensors, communication technologies, and communication protocols have empowered IoT, fuelling the concept of smart environments around us. Our environments have been pervasively enabled with physical, virtual, augmented and mixed reality experiences by smart objects that communicate with each other (M2M) as well as with us (H2M). All of this is encapsulated in the broad umbrella of IoT where the Internet of Things has become an enabler of new solutions and experiences impacting our daily lives.

Key Features

Some key features that signify an IoT system include: Intelligence - some degree of intelligence aides in smarter decision making, Connectivity - anything can be connected to the internet, Dynamic nature - everchanging and ever evolving state of things around us are pools of data that enable modern problem solving, Enormous scale - scalability is at the pinnacle of needs for today’s high demand applications, Sensing - sensors are key to data acquisition, Things - related services - services in the physical world, Heterogeneity - diﬀerences in networks or device hardware and software are integral part of the solution and naturally don’t pose a problem, Seamless connectivity - eﬀortless transitions across use case scenarios, Security - as much so for data, privacy and security of deployed systems is crucial, Autonomy - operation of devices should be free from intervention, Pervasiveness - device integration can range from natural to austere environments. CHAPTER 2. BACKGROUND 7

Challenges

The term IoT refers to a concept in which interconnected things are integrated into situational decision support, asset management and new services which in turn bring business opportunities and add to the existing complexity of IT. IoT is a fast-emerging ecosystem that integrates both IP- connected and non-IP devices. To accommodate the diversity of the IoT, there is a heterogeneous mix of communication technologies, which need to be adapted in order to address the needs of IoT applications such as energy efficiency, security, and reliability. IoT solutions have to constantly make careful design decisions that deal with balancing among several trade-offs across a board of factors starting from Cost, Throughput, Complexity, Intelligence, Autonomy, Robustness, Efficiency, and Energy requirements. These factors are crucial to evaluating any IoT solution. To briefly summarize the challenges that IoT is posed with, we can enumerate them under four main categories, namely, Connectivity, Power, Security, Complexity and Rapid Evolution.

• Connectivity: There is not one clear winner with respect to connectivity standards. As of now, it seems that, cellular networks are winning in lieu of their established infrastructures but a wide variety wired and wireless standards as well as proprietary implementations growing in popularity pose the challenge of getting the connectivity standards to talk to one another with one common worldwide data currency.

• Power management: Self-sustaining, energy-harvesting and battery powered devices are on an endless path trying to extract every bit of eﬃciency with respect to energy consumption and device life.

• Security: With data serving as the most important asset of IoT, privacy of data and security of both data and devices is prime. Here challenges can be improving the security of connectivity protocols and hardware as well as educating consumers about the same.

• Complexity: From designing new solutions to choosing between options at every layer of the architecture, simplifying poses another challenge.

• Rapid evolution: IoT is fast evolving although it is considered to be in its early days. The industry needs to be prepared to face new challenges, opportunities and ﬁnd new solutions every day. Adaptability is a key quality any new development should possess.

Data is the essence in IoT applications, and much development has been done regarding the core philosophies of IoT. To utilize the collected data into services, data must be propagated. Therefore, a wide variety of wired and wireless connectivity technologies have been developed to meet the demands of the IoT industry. Moreover, various types of hardware platforms with connectivity solutions and power-eﬃcient technologies continuously being developed provide the interface to IoT solutions. CHAPTER 2. BACKGROUND 8

Figure 2.2: Building Blocks of IoT

In the following sections, we first describe the IoT architecture, communication protocols/ standards and models then we briefly cover some of the most common data exchange protocols (also referred to as application layer and sometimes session layer protocols) before finally describing the data format protocols that we primarily focus on in this thesis.

2.3 The Internet of Things Architecture

An architecture for IoT implementations consists of several layers: from the data acquisition layer at the bottom to the application layer at the top /cite 8058399. The layered architecture has two distinct divisions with an Internet layer in between to serve the purpose of a common media for communication. The two lower layers contribute to data capturing while the two layers at the top are responsible for supporting Internet of Things applications /cite8058399. The ﬁgure2.3 below represents an implementational model of Internet of Things for data utilization in applications. If we visualize the umbrella term of IoT Solutions, these solutions encompass either one or all of the following: Hardware (end nodes and sensor devices), The Internetworking (Wired, wireless mediums and protocols) and the Software (Node software, Cloud deployment, remote applications and dashboards). Having this segregation enables decoupled development of parts of a complete solution. An interesting aspect of IoT applications is that most of them are deployed using new wireless communication standards and protocols. In the context of IoT, Sensor Networks seem to dominate moving towards the future. When it comes to deployment, networks can be conﬁgured in a variety CHAPTER 2. BACKGROUND 9

Figure 2.3: Model for IoT Applications2 of ways broadly these can be single hop and multi hop networks. The topology can accordingly use the above application layer communication protocols. HTTP is slow (conn ack) and HTTP header size overhead for energy constraint devices is not feasible. The IIoT landscape is dominated by two application protocols – MQTT and CoAP. On top of it the data/message interchange is filled with multiple protocols and libraries enabling more efficient communication. At the base of these protocols lies the data / message itself. By design, these data need to be serialized to be sent across the network over the protocol. Usually these data contain telemetry and identification data. And in more than one way, serialization solves many issues that would exist without them. The popular serialization formats are JSON, BSON, etc. However, their applicability far exceeds the context of IoT further into the Distributed Systems domain.

2.4 Connectivity Protocols/Standards

Taking into account the range covered and characteristics of connectivity protocols they can be divided into:

• Personal Area Network – ANT, Bluetooth/LE, 6LoWPAN

• Local Area Network – ZigBee, WiFi

• Cellular – GPRS, 3G, LTE

2https://developer.bosch-iot-suite.com/service/gateway-software/ CHAPTER 2. BACKGROUND 10

• Cellular-like Radio - LoRaWAN, SigFox, Weightless

• Radio Frequency Network – RFID, NFC

Given that in this thesis we focus on optimizing payload operations in sensor nodes IoT applications, the connectivity protocols discussed in this chapter are limited to the ones that are designed to deal with relatively small intermittent payloads generated from devices requiring low power networks and hence beneﬁting from payload optimization techniques that further reduce resources consumption. Therefore, the connectivity protocols that are utilized in other more power, data, and bandwidth demanding IoT applications (e.g. real-time video surveillance) are not discussed for the sake of brevity. This in turn limits the connectivity protocols discussion to commonly used low power protocols deployed in sensor applications and include: 6LoWPAN, ZigBee, LoRaWAN, and Wi-Fi.

6LoWPAN

As the full name implies – “IPv6 over Low-Power Wireless Personal Area Networks” – 6LoWPAN is a networking technology or adaptation layer that allows IPv6 packets to be carried efficiently within small link layer frames, such as those defined by IEEE 802.15.4. Low-power, IP-driven nodes and large mesh network support make this technology a great option for Internet of Things (IoT) applications [5]. From the end-nodes, the 6LoWPAN gateway that connects with the IPv6 domain forwards the packets to the destination IP-enabled device by using the IP address. The protocol also utilizes IP communication implementing open IP standards including TCP, UDP, HTTP, COAP, MQTT, and web sockets, the standard offers end-to-end addressable nodes, allowing a router to connect the network to IP leveraging the wide spectrum of IP applications [5]. 6LowPAN is a mesh network that is robust, scalable and self-healing with 128-bit AES link layer encryption. It is ideal for direct connectivity to internet applications in the context of Home Automation, Smart Infrastructure, Smart Agriculture and Industrial IoT. However, supporting IPv6 over IEEE 802.15.4 networks in 6LoWPAN typology poses different challenges due to the resource-constrained devices operating in low-power mesh network. One of the main challenges is that the effective payload size can be limited by the IEEE 802.15.4 link headers to 81 bytes which could also be compromised to IPv6 and UDP headers resulting in 33 bytes left for application data [16], a limitation that can result in packet fragmentation and hence more traffic on the network. Therefore, efficient data format techniques that optimize the payload size is an essential practice in 6LoWPAN network.

ZigBee[17]

ZigBee is one of the most widely used transceiver standards in wireless sensor networks. ZigBee over IEEE 802.15.4., deﬁnes speciﬁcations for low data rate WPAN (LR-WPAN) to support low power monitoring and controlling devices. ZigBee and 802.15.4 are not the same and the ZigBee CHAPTER 2. BACKGROUND 11

alliance is responsible for the development from the network layer all the way up to application layer of the ZigBee stack. ZigBee supports multiple network topologies, has low duty-cycle, low latency and 128bit AES encryption. With low throughput of about 250kbps, ZigBee systems are useful for applications in Home Automation and control, Residential & commercial utility systems and Health care. Despite the ZigBee-speciﬁc development of the network layer, the reliance on IEEE 802.15.4 global standard for low power wireless communication in the lower layers poses the same payload limitations [5], and hence utilizing optimized payload formats is also beneﬁcial.

Cellular

Cellular technologies are utilized in IoT due to the powerful cellular infrastructure that supports fast and large data transmission that has been crystalized with the 4G standard. Cellular technologies encompass technologies developed and maintained by the 3rd Generation Partnership Project 3GPP 3 such as GSM with its 2G and 2.5G standards, UMTS with its 3G standards, LTE with its 4G standards and the 5G NR and its 5G standards. These technologies have essentially been developed targeting mobile phone systems offering high quality voice and data services offering powerful range and high bandwidth. These benefits come with trade-offs represented in higher power consumption that doesn’t pose critical issues on easily chargeable or electricity connected devices but has drasti- cally draining impacts IoT applications that rely on battery-powered devices aiming to last as much as possible [18]. Additionally, since connectivity is backed by the coverage of cellular devices, this limits their applicability to remote IoT applications. However, since that the mobile phone market has been moving away from 2G cellular networks, the freed-up network bandwidth of 128Kbps (for data) is being utilized by IoT applications. In addition, cellular technologies have been developed to specifically target IoT applications such as Narrowband IoT (NB-IoT) and LTE-M providing lower costs and power connectivity [18]. Nevertheless, cellular technologies remain power hungry compared to other connectivity technologies, and therefore connected devices would benefit from optimizations at the payload structuring level that require less processing support and hence less power consumption.

Wi-Fi

Being IEEE standardized under the IEEE 802.11 wireless standards family, Wi-Fi is a wireless connectivity protocol that was initially designed in purpose of replacing Ethernet providing short-range wireless connectivity that supports interoperability. It was essentially targeting desktop devices and due to its ubiquitous coverage, it has been utilized by mobile devices. Additionally, this common deployment of Wi-Fi access points has made it a popular easy solution to utilize by IoT devices. However, power eﬃciency was not a built-in requirement and therefore it’s considered power draining when applied in IoT context. For that reason, new standards under the family of 802.11 have

3https://www.3gpp.org/ CHAPTER 2. BACKGROUND 12

been implemented (802.11ah, and 802.11ax) addressing the power efficiency requirements in IoT applications [19, 20]. However, in the majority of 802.11 deployments, payloads are recommended to be of a max of 1500 bytes [21], this added to the fact that these IoT-specific 802.11 amendments still considered more power consuming than other low power technologies, and the increased power consumption due to congestion faced as a result of using Wi-Fi to reach a target cellular network in order to eventually connect to IoT servers [22] all these scenarios highlight the importance of optimization in payload operations which benefit IoT applications relying on Wi-Fi technologies.

LoRaWAN[23]

LoRaWAN is a Low Power Wide Area Network (LPWAN) specification intended for wireless battery operated things. With longer long-range communication capabilities, LoRa enables solutions to connect to the broader network of things without additional expensive hardware. The LoRaWAN network architecture typically uses the star-of-stars topology to successfully enable communication between end-nodes and servers via gateways that can connect to the internet servers via standard IP connections. End-nodes communicate with the gateways only via single-hop wireless communications. LoRa also supports multicast messages due to its complete bidirectional communication model. Utilizing multiple frequency channels, LoRaWAN networks regulate the data rates depending on range and payload. An adaptive data rate (ADR) scheme allows for the management of data rates and radio frequency parameters of each end node individually. Today LoRaWAN is already being used across the world to scale citywide IoT application projects. However, it has a limitation when it comes to the maximum transmission unit payload size (MTU); this size depends on the distance of the nodes from the gateway and cannot be known beforehand which in turn drives firmware developers to assign the smallest available MTU, the typical payload size ranges between 51 and 222 bytes maximum, and could be assigned to be as small as 12 bytes [23]. This means that the higher the payload the more fragmentation imposed on the network. It’s also recommended for LoRaWAN devices to send small payloads in order to achieve higher throughput and packet success rate [23]. Therefore, payload optimization becomes also beneficial in LoRaWAN networks. When it comes to choosing between IoT protocols made available by the industry organizations and standards, both commercial solutions as well as open source projects, for each of them, the basis of choice considers the main functionalities provided, architectures employed, communication models, protocols, data exchange mechanisms and messaging techniques [24]. In one way we can look at these communication protocols as IP based where IP network is leveraged to directly propagate information to cloud and Non-IP based where Gateways or Protocol Translators act as intermediary connecting to the IP Network. This distinction is important in the IoT context as it helps solution architects to choose the protocols based on their device characteristics and capabilities. The Non-IP based protocols help connect the last mile devices. A complete IoT solution can contain both IP-based as well as Non-IP based protocols for example, a non-IP network CHAPTER 2. BACKGROUND 13

might ultimately connect to the IP network to enable its solutions through the cloud. From the above protocols we can observe clearly that ﬁrst, low bandwidth or low throughput networks are critical when it comes to protocol design. Hence, the need to further decrease the network load. Second, the role of middleware hardware and software iins IoT system cannot be overlooked and are an absolute necessity in the context of IoT. Finally, protocol overheads are a contributing a factor in IoT systems implementation choices and thus, the scope of optimization at every level.

2.5 Models

IoT communication can be conceptualized as 4 major communication models, which are mostly derived from the traditional web models, namely, Request-Response model, Publish-Subscribe model, Push-Pull model and the Exclusive Pair model. The Request-Response communication model, simply put, is the client sending requests to the server and the server responding to the requests. Request-response is a stateless communication model and each request-response pair is independent of others. Examples are implementations using HTTP or CoAP protocols. The Publish-Subscribe communication model involves publishers, brokers and subscribers (consumers). Publishers are the source of data [25]. Publishers send the data to the topics which are managed by the broker. Publishers are not aware of the subscribers. Consumers subscribe to the topics which are managed by the broker. When the broker receive data for a topic from the publisher, it sends the data to all the subscribed consumers. Examples are implementations using rabbitMQ (AMQP), mosquitto (MQTT), ejabberd (XMPP), and ZeroMQ [25]. The Push-Pull communication model is a model which uses queueing buﬀers [26]. Data producers push the data to queues and the consumers Pull the data from the queues. Producers do not need to be aware of the consumers. Queues help decouple the messaging between the Producers and Consumers [26]. Buﬀering with queues helps in situations when there is a mismatch between the rate at which the producers push data and the rate which the consumers pull data. Examples are implementations that exploit MQTT or AMQP to achieve Push-Pull functionalities [26]. The Exclusive Pair communication model uses a persistent connection to achieve fully duplex, bidirectional data transfer. This implementation conducts stateful communication where the server keeps the connection open till the client requests to close it. Here the communication can happen only after a connection is established and the server is fully aware of all the connections. This model is more of a consequence of the choice of connectivity protocol, examples of which are implementations over Bluetooth and NFC. It is important to understand that most of the deployments today use commercially available IoT platforms ranging from IIoT to Smart cities. Here once data acquisition is complete at the CHAPTER 2. BACKGROUND 14

edge sensor nodes, the information is sent all the way up to these platforms(usually cloud) and as a result the communication models as mentioned above can be adapted into: Direct Communication (directly using MQTT or CoAP), Using a Gateway(ZigBee, Zwave) or Agent-based (for distributed deployments). One common scenario when developing IoT systems is Protocol Translation. This is a consequence of the convergence of Protocol fragmentation in IoT. This is achieved by the support mechanisms designed to exchange information across the myriad of protocols that empower these systems. One most used paradigm is the use of Gateways. Based on complexity, gateways can be basic bridges or embedded control devices. End sensor nodes use Gateways for protocol translation, connect them to the bigger back bone of internetworking. Here we would also like to introduce the Data exchange protocols also known as Application layer communication protocols. Henceforth, we refer to these as data exchange protocols which further make use of some sophisticated data format protocols that, as the name suggests, format the data contained in the payload that these data exchange protocols carry. It is not wrong to call some of these data exchange protocols – cloud enabling standards as they help connect edge-sensor networks to the broader IP based Internet as we know it. In data exchange protocols, Bus-based and Broker-based are the two reigning architectural [27].

Bus-based

In the Bus-based architecture, basically there is a Bus Coordinator in charge of delivering messages to the intended subscriber. This architecture oﬀers a queuing subsystem that mediates accesses between Publisher and Subscriber. Example are DDS, REST and XMPP which support broker-less architecture [27].

Figure 2.4: Bus-Based Model (Note: Node can be any application) CHAPTER 2. BACKGROUND 15

Broker-based

In this case, broker(s) act as controller(s) for the distribution of information to forward, ﬁlter or prioritize and even store publish packets from the publisher (the source of data) nodes to the subscriber (data consumer)nodes. Depending on their objectives, clients can switch between publisher and subscriber roles. One additional important feature of brokers is the implementation of QoS (Quality of Service levels). Examples of broker–based protocols include Advanced Message Queuing Protocol (AMPQ), Constrained Applications Protocol (CoAP), Message Queue Telemetry Transport (MQTT) and Java Message Service API (JMS) [27].

Figure 2.5: Broker-Based Model (Note: Node can be any application)

Alternatively, we can classify these protocols as data-centric or message-centric. A data-centric protocol such as CoAP focuses on delivering the data and assumes the data is understood by the receiver. Middleware understands the data and ensures that the subscribers have a synchronized and consistent view of the data. Message centric protocols such as AMQP, MQTT, and REST focus on the delivery of the message to the intended receiver, regardless of the data payload it contains. Additionally, an important aspect of these protocols is whether they are web-based like CoAP or application-based such as with MQTT and AMQP Sensor networks juggle through resource constraints on energy, storage and bandwidth while communicating over lightweight protocols to oﬀer divergent solutions and services. Eﬃciency is required in both, communication as well as computation. This makes addressing resource optimization a primary task. Further evolution in IoT has led to optimizations at the Application layer. This has led to a myriad of Data Exchange Protocols also known as Application Layer Protocols along with many novel Data Format protocols which we elicit in the following pages. CHAPTER 2. BACKGROUND 16

2.6 Data Exchange Protocols

Application layer protocols deﬁne how applications (clients and servers) pass messages (data) to each other. These run on the application layer of the communication model hence known as application layer protocols. Such protocol deﬁnes the syntax to use, the semantics to follow and the types of messages that can be sent along with the rules determining when and how messages are exchanged. The term Data Exchange Protocol can be alternatively used to address most of these protocols. Henceforth, in this document, we refer to our selection of protocols below as Data Exchange Proto- cols.

MQTT

MQTT4 stands for Message Queueing Telemetry Transport. It is a publish/subscribe model-based protocol. The design principles behind MQTT were to be a simple, lightweight and open source messaging protocol for constrained devices with low-bandwidth and high-latency whilst also ensuring some degree of reliability and assurance of delivery. This protocol enables exchanging messages among publisher and subscriber nodes using a broker-based architecture. This seems to be ideal for Machine to Machine communication (M2M) contexts. List of available brokers for MQTT include, but are not limited to, ActiveMQ, Apollo, HiveMQ, IBM MessageSight, JoramMQ, Mosquitto, RabbitMQ. These brokers vary in establishment of communication and additional features over standard MQTT functionalities. Although MQTT is very eﬃcient, high numbers oﬀ nodes from clients to the central broker might lead to poor performance.

MQTT-SN

MQTT-SN [28] is a derivative of the original MQTT protocol with one specific goal which is to cater to wireless sensor networks (WSNs). The SN abbreviation stands for Sensor Networks. Such networks are dynamic and constitute of large number of wirelessly connected devices which are prone to link instability and failure. This problem is addressed with the Pub-Sub paradigm’s data-centric communication approach rather than an address-based one. The difference is that information is delivered based on contents and interests rather than the addresses of subscribers. All of this is already provided by the MQTT protocol mentioned above but however, MQTT requires an underlying network, such as TCP/IP, that provides an ordered lossless connection capability and this is too complex for very simple, small footprint, and low-cost devices such as wireless sensor nodes. MQTT-SN is designed to be network protocol agnostic, in other words it supports any network that provides bidirectional communication between any node and a gateway, for example UDP. Compared to MQTT, MQTT-SN can cope with short message lengths, provide predefined topic ids and short

4mqqt.org CHAPTER 2. BACKGROUND 17

topic names and an auto discovery procedure to cater to multiple brokers in the same network for load sharing. All of these work in favour of more constrained devices and scalability of deployments.

CoAP

The Constrained Application Protocol5(CoAP) is a Data exchange protocol derived from the web for use with constrained nodes and constrained (e.g., low-power, lossy) networks. They have been widely adopted for nodes with limited memory over constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). It supports a one-to-one protocol for transferring state information between client and server. CoAP utilizes User Datagram Protocol (UDP), and supports broadcast and multicast addressing. It does not support TCP. The CoAP communication is through connectionless datagrams and can be used on top other packet-based communications protocols with Low header overhead and parsing complexity. CoAP supports content negotiation and discovery, allowing devices to probe each other to ﬁnd ways to exchange data. CoAP was designed for interoperability with the web (including HTTP and RESTful protocols).

AMQP

AMQP[29] stands for Advance Message Queuing Protocol, which is an open source undertaking as part of the Apache Software Foundation Incubator application. AMQP is a message-oriented protocol designed with end to end routing and queuing of data. It is a brokered protocol in which the broker is capable of making routing choices and as a consequence it falls under the category of middleware protocols. AMQP is a binary transfer protocol and today widely used in IoT applications. Being a binary protocol, it has less overhead that test basedtestbased test-based protocols like HTTP. For security though, it depends on an underlying reliable transport layer protocol. With multiplexing capabilities, each connection allows for separated data ﬂows among client-server as well as peer-to-peer communications. The reliability features in AMQP provide three diﬀerent levels of QoS (Quality of Service).

REST

REST is a paradigm rather than a protocol. Rest stands for Representational State transfer. It is defined as an architectural style for designing applications utilizing HTTP. REST enables web-based services referred to as RESTful services which use the same verbs as HTTP(GET,POST,PUT,DELETE). Utilizing URI(Uniform Resource Identifiers) as points of access, REST enables point-to-point, stateless client/server, cacheable protocol for simple client/server (request/reply) communications from devices to the cloud over TCP/IP. REST is fit for use over the internet due to these characteristics. It is a preferred choice when it comes to web applications, and certainly for cloud services. JSON

5https://coap. technology/ CHAPTER 2. BACKGROUND 18

is a common data exchange format used in RESTful services. REST comfortably finds its place in IoT solutions [27] today where the web is leveraged to offer service-oriented applications. In the review, Towards Efficient Mobile M2M Communications: Survey and Open Challenges [30] , the authors conclude, “Future work should focus in exploring [. . . ] mechanisms to efficiently collect and aggregate data while attaining the time requirements of data, to reduce energy and bandwidth consumption, as resource usage efficiency is a common denominator in the literature due to mass scale envisioned for mobile M2M communications”. We tend to agree and add that one such mechanism is optimization at the data translation level, where information is formatted for optimal transmission over these protocols. Each protocol, when used adds more data in the form of headers for its own functioning. As we note that every protocol designed for IoT aims to reduce the header overhead it introduces, we can safely say that reducing the overhead introduced by data-format protocols serves the same goal. Hence, as deliberated in this thesis, among other resources, we believe, these data exchange protocols can also benefit from optimization done on payload structuring and transmission process which in turn will aggregate to result in a reduction of the overall system traffic.

2.7 Data Format Protocols

Data formats protocols are concerned with the semantic and representation of IoT data generated from connected devices. This involves structuring and converting the payload data into a format using mechanisms that support reliability and interoperability with emphasis on lightweight. In this section we discuss the need of data serialization in IoT and we present the common text-based data serialization formats used in IoT applications, then we introduce a background discussion on the selected binary-based data serialization techniques. Data Serialization in IoT: IoT applications objective remains to exploit the power of data harvested from connected devices. This is achieved through different processes that runs in reaction to the collected data, and involve monitoring, re- porting, control, prediction, and other analytical solutions enabled by the collected data that aim at providing a wide spectrum of services delivering value to an increasingly wide range of users. This vivid communication requires IoT devices to have a structured messaging method for interchanging data between different endpoints. Considering that these endpoints could differ in nature from other sensor nodes, mobile devices, web applications, or other back-end tiers, it’s very common for these endpoints to be developed in different environments, utilizing different platforms and programming languages, while harnessing data from mutual sources. These scenarios create the necessity of maintaining the structure and content of messages as well as supporting different platforms and application requirements that are subject to change [31]. To attain that, data serialization mechanisms are utilized to assure heterogeneity and support of multiple systems. Data serialization deals with converting data structures into another format that enables efficient storage and transmission CHAPTER 2. BACKGROUND 19

of data. The main feature of this process is the enabling of relatively fast and easy reconstruction of serialized data in order to be utilized accordingly by another completely different platform given that the serialization mechanism is known by both points. There exist several data serialization techniques that are standardized and initially developed and optimized for high-level programming languages, main examples of these techniques are JSON and XML and. The strong standardization and support these formats have driven their popular utilization in IoT devices [32] that use low-level programming languages such as C/C++ , are resource-constrained, and deal with lightweight messages, therefore they require more optimized data serialization mechanisms to handle the messages format. In the next sections, we briefly describe the highlighted mechanisms in this research with emphasis on target techniques to be analyzed in sensor nodes context. These data serialization techniques are referred to as Data Format Protocols given that they’re applied to the process of structuring and formatting of the message payload. We distinguish between three different ways of classifications these protocols can follow:

1. Schema and Schema-less: Those that have predefined schemas supporting an interface description language (IDL) of the data needs to be propagated: example HTTP, XML(optional), Protobuff, Flatbuffers are schema based whereas JSON, Message Pack, and BSON are schema less. The inexistence of schema adds more flexibility but impacts the size of encoded data as the data fields’ names need to be serialized too.

2. Encoding: The payload could be encoded as a text utilizing further character encoding mechanisms such as ASCII or UTF-X or encoded directly in binary format.

3. Library: Protobuf, Flatbuffers and MessagePack require library support whereas XML, JSON work with plain text. This classification is a result from the encoding mechanism used, as text- based encoding require merely additional characters to be added for the parsing/unparsing of data whereas binary-based encoding differs from one protocol to the other depending on the how each protocol handles the encoding of different data types.

In this thesis, the encoding mechanism is used as the main classiﬁcation method due to its uniformity with respect to our context.

2.7.1 Text-Based Protocols

XML

Extensible Markup Language6(XML) is a flexible standardized known as self-describing or self- defining, meaning that the structure of the data is embedded with the data in addition to text- based headers called tags that define the specifications of each element, thus when the data arrives there is no need to pre-build the structure to store the data; it is dynamically understood. XML

6https://www.w3.org/TR/xml/ CHAPTER 2. BACKGROUND 20

allows to store binary data; however, this data must be converted to text using Base64 encoding that requires additional bytes to store binary data. The criticism XML faces stems from the nature of the mechanism that makes it verbose [33] and thus not appropriate to be utilized in resource- constrained devices. Moreover, it’s stated in the official XML specifications that compactness is not a priority [33]. Therefore, this makes the utilization of XML in IoT applications not efficient due to the size overhead and complex encoding mechanisms which pose more resource and bandwidth consumption impacting the performance of IoT devices. Several benchmarking projects and papers that are referred two in the following chapters have shown results that support the argument of XML not being an efficient data format to utilize in IoT resource-constrained devices.

JSON

JavaScript Object Notation7(JSON) is a lightweight data-interchange format. One of the main features is that it advertises itself to be more human readable than many other formats. It is easy for machines to parse and generate. JSON is a text-based format that is completely language independent but uses conventions that are familiar to programmers and majority of popular programming languages. These properties make JSON an ideal data-interchange language. JSON is built on two structures: a collection of name/value pairs. In various languages, this is realized as an object, record, structure, dictionary, hash table, keyed list, or associative array. The other structure is an ordered list of values. In most languages, this is realized as an array, vector, list, or sequence. These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures. Moreover, in JSON, additional characters are required for the notation basically including:

• Objects: Objects begin and end with curly braces ({}).

• Object Members: Members consist of strings and values, separated by colon (:). Members are separated by commas.

• Arrays: Arrays begin and end with braces and contain values. Values are separated by commas.

• Values: A value can be a string, a number, an object, an array, or the literals true, false or null.

• Strings: Strings are surrounded by double quotes and contain Unicode characters or common backslash escapes.

JSON is referred to as more lightweight and efficient compared to XML [34]. However, in addition to the fact that JSON encodes the field labels and field values as strings, the additional

7https://www.json.org/ CHAPTER 2. BACKGROUND 21

required characters for JSON formatting impose larger payload sizes, longer time to encode/decode the payloads and thus additional power consumption on the IoT device. This is where binary-based data serialization mechanisms prove to be more eﬃcient, this is discussed further in Chapter 3 where we refer to research papers comparing JSON with other binary-based techniques.

2.7.2 Binary-based Protocols

The choice of this set of binary based protocols to be evaluated is based on the eﬃciency and speed claims on the oﬃcial implementations sites, supported by several benchmarking results that evidently endorse these claims. In addition, proper documentation, presence of active community, maintained implementations, platform and language neutrality remain essential contributing factors to the choice.

Protocol Buﬀers

Also known as protobuf8, is an open-source data serialization mechanism that has been developed and maintained by Google. It’s used to serialize structured data for use in communications protocols, data storage and other application scenarios where cross-platform communication is heavily applied. Protocol buffers is platform-neutral and language-neutral supporting a flexible, efficient, automated mechanism for serializing. Practically, utilizing a schema-based technique, it is specified what type of structured information to be serialized by defining protocol buffer message types in “.proto” schema files. The schema is structured to define two types of objects: a “message” and an “enum”. A “message” is the aggregate object type where all fields and “enum” objects are included. The “enum” is used to have a message field that contain a list of values. Built-in data types supported in protobuf include all the major scalar data types excluding 16-bit scalar types, in addition to string and byte data types. The schema also supports the definition of several messages and nested messages. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs. Once data has been structured, the message will be encoded using the protocol buffers compiler from the .proto file, the compiler generates the code in the chosen language in order to work with the message types that have been described in the schema file, including getting and setting fields’ values, serializing messages to an output stream, and parsing them from an input stream. The encoding happens utilizing a by concatenating keys and values into a concatenate byte stream. The keys are constructed using the field number defined in the schema, and wire type that protocol buffers defines for group of data types in a way that make protocol buffer messages self-explanatory. Depending on the programming language (C++, Java, or Python for example), the compiler generates a “.java”, “.py” or “.h” and “.c” file from each “.proto”, with a class for each message type described in the file. Each protocol buffer class has methods for writing and reading messages of the chosen type using the protocol buffer binary format. Protocol buffers are claimed to

8https://developers.google.com/protocol-buﬀers/docs/overview CHAPTER 2. BACKGROUND 22

outperform both JSON and XML specifically in numeric-based data where protobuf encoding and decoding performance is claimed to be significantly faster. Google Developers Protocol Buffers site claims that protobuf are simpler, 3 to 10 times smaller, 20 to 100 times faster, less ambiguous, easier to use programmatically [35]. Additionally, several online benchmarking projects show how protobuf outperforms JSON being 5 to 6 times faster and showing better performance even in environments that run JavaScript where JSON is a native format, benchmarking examples are the open-sourced benchmarking project by a Google developer [36] and an interesting comprehensive benchmarking by Bruno Krebs on ‘auth0’ platform [37]. Specifically, protobuf shows significant advantages when dealing with numeric data which makes it a very interesting candidate to be tested in IoT application scenarios and specifically sensor nodes that deal mostly with numeric sensor readings.

FlatBuﬀers

Also known as flatbuf9, is another open-source cross-platform and binary-based data serialization mechanism developed and maintained by Google. It’s essentially developed to deal with game development and other performance-critical applications. It’s claimed to be developed to have better memory efficiency and speed compared to protobuf due to the utilization of the concept of a flat binary buffer that doesn’t require unpacking/parsing to another representation before accessing the data. It’s also a platform-neutral language-neutral schema-based communication protocol but with the additional support for schema language features like unions. Built-in data types supported in flatbuf include all the major scalar data types including 8-bit and 16-bit integer data types, in addition to string that can hold only UTF-8 or 7-bit ASCII, and byte data types Flatbuf schema language relies on two ways of defining objects, tables and structs. Tables are the main and less constrained way and can include fields of different data types, structs and other nested tables. Structs are more constrained in terms of as they can only include scalar values or other structs, they are used for smaller objects and in turn can be accessed faster. In all cases, a ‘root type’ definition is needed the end; it declares what will be the root table for the serialized data in case multiple tables are used. The way flatbuf works is like protobuf as once the “.fbs” schema file is written, the file is compiled using the target language flatbuf compiler, the compilation generates the header files that includes helper classes to access and construct serialized data. For reading the buffer back, only the pointer to the root object needs to be obtained in order to have an in-place access to the fields. According to Google benchmarks, it’s claimed that flatbuf is approximately 60 times faster than protobuf in and 200 times faster than JSON in encoding. In decoding, given the implementation of flatbuf, it extremely outperforms other protocols that require unpacking processes before data can be decoded being approximately 3000 times faster than potobuf and could achieve a 7000 times faster performance than JSON /citeflatbufbench .

9https://google.github.io/ﬂatbuﬀers CHAPTER 2. BACKGROUND 23

MessagePack

MessagePack10 is an open-source binary-based object serialization mechanism. Since it’s a schema- less mechanism, the implementation concept is simpler than protobuf and flatbuf. It relies mainly on two concepts, the Type System and the Formats. Type System defines the data types supported which covers main data types with some limitations on integer value range and String object maximum byte size. The type system also includes the concept of Map that represents key-value pair of objects, a concept that is utilized in our implementation to encode the field label and the value. The Formats concept describes how each data type is binary-encoded. For example, a single byte is used to encode small integers while strings require an additional byte to encode beside the strings encoding. MessagePack uses packing/unpacking logic to refer to encoding/decoding processes. The mechanism is designed to be lightweight and to have small memory footprint, which makes it applicable and beneficial to utilize in IoT devices.

BSON

Short for Binary JSON, is and like MessagePack, an open-source schema-less binary data serialization mechanism11. The protocol is claimed to be designed to be lightweight minimizing spatial overhead, easily traversable as it’s represented as a main data representation format in MongoDB, efficient due to the utilization of C data types that results in relatively faster encoding and decoding processes. BSON deals with data as documents that store key/value pairs as a single entity, where keys are represented as strings and values could hold any of the supported data types. MongoDB was the first project to utilize BSON as a data format, as it prioritizes speed of encoding decoding and faster traversal over size of encoded message. BSON also has different open-source library implementations that support numerous languages and platforms including a C and C++ library implementations. Although many of BSON libraries focus on MongoDB applications, it’s stated that these libraries will be made stand-alone and independent of MongoDB to allow other applications to benefit from the protocol. These criteria make BSON a candidate protocol to be utilized in IoT context, and especially sensor nodes where data types tend to be basic. Based on the efficient mechanisms, specifications, and the advantages these binary-based data serialization techniques are claimed to have compared with text-based data formats, they become interesting to explore and evaluate the value they could bring in IoT applications that would highly benefit from resource-efficiency and further optimizations.

10https://msgpack.org 11http://bsonspec.org Chapter 3

Related Work

The rapid implementations and scaling of IoT systems has emphasized the need for optimization techniques to be explored and implemented in order to reduce the amount of data transmitted between devices in purpose of saving memory, power consumption, and network bandwidth from exhaustion. Therefore, several approaches have been implemented addressing these issues from diﬀerent aspects. In this section some of these investigations are surveyed. We classify the researches under approaches analyzing and evaluating data exchange protocols that are also referred to as application layer protocols and session layer protocols, and their impact on the mentioned metrics, and another category that includes approaches addressing payload data optimizations techniques. In both categories, our interest focuses on the aspects of reducing the overall data transmission either by targeting the data exchange protocols overheads, or the methodology of collecting and storing payload data.

3.1 Data Exchange Protocols Evaluation

Due to the nature of IoT systems requirements that vary from one application to the other, systems cannot rely on a single messaging protocol and thus creating a dilemma for the IoT industry [38]. This indeed motivated the academia community to perform analytical studies aimed comparing and ranking protocols based on different performance metrics that impact the overall IoT system. In their analysis, the focus remains on analyzing protocol generated overheads, communication speed, and power consumption, in purpose of driving optimality on IoT resource constrained applications. In [2], a comparative analysis is done over a subset of commonly implemented protocols in IoT applications namely: MQTT, CoAP, AMXP with reference to HTTP as a baseline. The comparative analysis uses several metrics to compare the performance but what makes it relevant to us is how the choice of protocol significantly affects the message size and overhead, power and resource consumption, bandwidth consumption, and latency. The performances variances can be attributed

24 CHAPTER 3. RELATED WORK 25

to the way each protocol was implemented. The paper illustrates that CoAP performs better in all these metrics due to its reliance on UDP rather than TCP which eliminates the connection overheads caused using TCP that impact the performance metrics. MQTT then follows as a TCP-based but lightweight protocol. However, from the angle of adoption rate among industries and organizations, MQTT, however, is an established M2M protocol and is used by many reputed and leading organizations. Following is AMQP that showed international and large-scale adoption in big projects such as Oceanography’s monitoring of the Mid-Atlantic Ridge, NASA’s Nebula Cloud Computing and India’s Aadhar Project. These significant adoption trends are powered by the ability of these protocols to perform in a nimble and lightweight manner minimizing processing overheads that exhaust the device resources as well as the operating network. In [39], a more quantitative approach is undertaken comparing CoAP, MQTT, and XMPP with emphasis on real-time communications of sensors data. The interesting results showed how MQTT outperforms the other two protocols when it comes to packet creation and transmission. That is, and despite relying on TCP, the design of MQTT attempts at optimizing the process of message generation minimizing synchronization delays resulting in two times faster packet delivery than CoAP. Moreover, XMPP shows significantly the slowest performance and is mainly because of the relying on XML formats for reading and sending messages. With the focus on the optimization advantages that could be leveraged using UDP as the underlying transport protocol; In [40], a comparative analysis is done between CoAP and MQTT-SN, which is a UDP-based extension and even more lightweight implementation of MQTT that is designed with low bandwidth and small message payloads in mind, and thus it profiles and fits itself for resource-constrained sensor devices. The experiment uses seven text files with varying sizes starting from 2.25 Kbit to 63 Kbit in purpose of gaining comprehensive results on the efficiency of each protocol, the results suggest that MQTT-SN is approximately 1000 times faster than CoAP and thus, from a resource utilization aspect of sensor devices and WSN, MQTT-SN shows a more efficient and optimal behavior with significantly less messages overhead and transmission time which comes beneficial in a WSN environment where data is transmitted in a frequently. Moreover, in a 2016 Master’s thesis by Thomas Wickman [1], different lightweight and known to be efficient communication protocols are compared with emphasis on generated data transmission overheads. Applied to the context of vehicle to server communication, the author examines the performance of MQTT, MQTT-SN, and AMQP. The study scope is motivated by data trends and transmitted data amount optimization priorities from Scania vehicles; It’s expected that in 2020, Scania’s will have 600 thousand connected vehicles, and thus the amount of data these vehicles would generate is also expected to significantly increase along with the number of offered services. This increasing trend does not only apply for Scania’s vehicle, a report by McKinsey suggests that connected cars will continue to increase and win 2020 there will be one connected car in every 5 cars which round to 290 million connected cars [41]. This highlights the importance and the need of CHAPTER 3. RELATED WORK 26

reducing the aggregate amount of transferred data between connected vehicles and the server due to the data cap limitations of 10 MB per day for each vehicle in Scania’s case which concludes that the lower the protocol overheads the more data will be available to utilize by other services. These protocols, that are designed to minimize transmission overheads and speed up the communication, are yet to show variances in their performance citethomaswickman2016. In addition to protocol- generated overheads, the thesis focuses on how protocols behave in the situation of packet loss in terms of the amount of data needed in the process of retransmission where the case is that Scania’s GSM network has a 4% retransmission rate and is subject to high packet loss due to vehicle’s operations in remote areas with unstable or non-existent connection. The thesis tests the protocols sending an aggregate of 1 MB of data constructed in three diﬀerent payloads sizes of 100B, 1KB, and 10KB. The thesis concludes that despite the fact the MQTT-SN failed to work for the 10KB payload messages, M1TT-SN was still considered the potential candidate to be the lightest protocol of the three. The breakdown of MQTT-SN was attributed to the minimal and nimble implementation nature of MQTT-SN that results in a lot more overhead due to fragmentation at the application layer. Substantially, thesis highlights the fact that the overhead size of each of the three protocols grows in a directly proportional manner to the payload size, and that MQTT-SN performs way better at the 100B payloads with 217% overhead compared to 366% and 389% overheads generated by MQTT and AMPQ respectively. This conclusion supports the motivation of our thesis that if the payload itself is reduced, then the protocol overheads are reduced and in turn the total data transmitted is reduced. This argument can be understood clearly from the overhead formula used in Thomas’s thesis to theoretically calculates the MQTT-SN overhead. The formula shows that even on 1KB payloads, which makes 98% of Scania’s payloads, MQTT- SN generates 19% overhead for a 1 MB transfer, a performance that beats MQTT 32% and AMPQP 34% overheads. It also highlights the direct impact of higher payloads on MQTT-SN overheads. In this section of related work, we observe that protocols designed to be lightweight remain favourable communication protocols in the context of IoT which emphasizes the importance of minimal overheads and fast data transmissions in all IoT applications in purpose of leaving capacity for the increasing number of services made available. While these investigations focus their eﬀorts and analysis on data exchange protocols operating at the application layer, our thesis focuses on the layer where the payload acquisition and structuring happen at the physical layer and before its encapsulation through the data link and transmission through the upper layers, a focus we share with several other investigations that are discussed in the second section of this chapter.

3.2 Payload Optimization Approaches

In this section, we review approaches that target the optimization of transmitted payloads in purpose of minimizing the resulted data traﬃc and reducing resource consumption resource-constrained CHAPTER 3. RELATED WORK 27

devices. These approaches focus mainly on the efficiency of different data serialization techniques. In [42], a comparative analysis of a set of data serialization techniques is performed in the environment of mobile applications. Even though the experimental settings in this paper does not incorporate IoT context, the overlap occurs in the research goals that stem from the same motivations represented in scarcity of memory and processing resources and bandwidth limitations of internet-connected devices, which in their research scope are represented in mobile devices. Their selected serialization formats include two text-based formats: JSON and XML, and two binary-based formats: Thrift and Protobuf. The experiments are run on Android devices and utilizes text-heavy and number-heavy messages. The paper uses metrics of comparison like the ones we aim to analyse and include serialized data size, average serialization time, and average deserialization time. Two test objects were used in the experiment a Book object that is designed to be text-heavy and mimic an object that might be used in a book store application, and a Video object that is designed to be number-heavy and mimic an object that might be used within a streaming video website. The results showed how binary-based serializers outperformed text-based ones. XML showed the highest resulted data size followed by JSON then Thrift making Protobuf the best performer out of the four. An interesting highlight is that the binary-based techniques showed apparent higher performance having much smaller data sizes when testing with the number-heavy Video object, a result that suggest the significant advantages these protocols bring when dealing with numeric data. On the speed metrics, results were obtained after one thousand iterations of serialization and deserialization tests for each of the two objects. The results show that XML again is the slowest being 5 times slower than the other formats, JSON being way faster than XML and yet slower that the two binary-based formats. Thrift and Protobuf showed very close results in serialization while Protobuf was slightly faster to deserialize than Thrift. The paper concludes the superiority of binary-based techniques and shows that in the context of mobile development, Thrift could be more favourable due to its support of Objective-C that is used by iOS devices, an advantage that we found to be currently outdated due to Protobuf current support of Objective-C as well. A more relevant paper is [43] that shows a performance analysis of data serialization techniques in the context of M2M wireless sensor networks that lie at the core of IoT systems. The motivations remain shared with ours and focusing on reducing the amount of data exchanged, coping with the limited resources on sensor nodes as well as reducing power consumption. The research scope compares data serialization techniques that fall under the ETSI M2M protocol group that defines formats specified for M2M communication which incorporate WSNs [44]. According to this protocol, three data formats are recommended: XML, JSON, and Efficient XML Interchange EXI which is a lightweight binary-based extension of XML aimed at resource constrained devices. Given the inferior performance of XML suggested by previous research works discussed and known to the literature, the paper focuses the analysis on JSON and two configurations of EXI that are EXI Schema-Less and EXI Schema-Enabled. The experiment utilizes a set messages taken from the standard ETSI CHAPTER 3. RELATED WORK 28

CoAP M2M interoperability test [45]. The experiment also runs on a simulated environment utilizing Cooja and Contiki OS in purpose of performing the tests in a controlled environment and to allow other researchers to perform replications before moving to hardware implementations. Additionally, the experimental setup consisted of Wismote wireless sensor nodes emulated in Cooja that represent the communication end points where three sensor nodes were used as client, server, and 6LoWPAN border router and CoAP was the choice of the application layer. The comparison of JSON and EXI was done over two main criteria:

1. Performance over ETSI M2M CoAP Interoperability Tests focusing on the execution time, channel usage and energy consumption of several M2M operations

2. Serialization complexity that measures the complexity with respect to the memory usage, serialization and deserialization times

The paper concludes that, EXI SE performs better that both JSON and EXI SL in terms of energy consumption, channel usage on the network, and the execution times while showing higher memory usage that is claimed to be affordable by the sensor nodes. Moreover, EXI SL showed close performance to JSON on execution time. The paper also concludes that JSON shows less memory usage and is recommended for devices with strong memory constraints. Similarly, and motivated by the same reasons, another relatively recent paper [46] valuates the performance of using Protocol Buffers compared with JSON and JSON’S binary representations format, BSON in the scope of transportation IoT namely, Internet of Vehicles (IoV) that demands huge communication field between compute nodes and requires lightweight methodologies of sending and receiving data. The experiments were performed on a proprietary vehicle tracking system protocol that is protected by copyrights and was not disclosed. However, the types and names of messages are shown and claimed to resemble messages from any tracking system. Types of messages include querying, updating, inserting, responses, status, and acknowledge messages where responses and status messages make up to 90% of the traffic. Approximately, fifty thousand real- world messages are listened to and recorded in a log file where messages are extracted and converted to JSON, BSON, and Protobuf and placed in an ad-hoc database with the respected resulted sizes. The research concludes that Protocol Buffers remains a strong candidate for standardized way of communication in IoT systems due to its lesser network load where messages serialized in Protobuf were 5 times and in specific cases 8 times smaller than BSON messages and JSON obviously showed the poorest performance where the resulted message sizes were the highest and almost 6 times bigger than Protobuf messages and almost two times bigger than BSON messages. The paper also highlights the interoperability advantages of protocol buffers given their language-independent and platform-independent design. Another approach focuses on optimizing the process of collecting the data from the physical environment by the distributed sensor nodes in a wireless sensor network [47]. When the design CHAPTER 3. RELATED WORK 29

aims at collecting huge amount of data from a sensor environment, it’s significant for scalability reasons to control and reduce the data loss due to the limited storing capacity of the sensor node, to uphold energy efficiency, to upgrade the performance, and to prolong the lifespan of the network [47]. Therefore, the paper surveys efficient data collection techniques and classifies them under compression based and network-based techniques. The paper also discusses novel and complicated compressive sensing techniques that are designed for energy efficiency involving simple encoding and complex decoding mechanisms and which can be further used to implement algorithms that addresses other resource-constrained issues of wireless sensor networks such as preserve data fidelity, to recover data with minimal error, in reduction of communication cost and communication overhead. The paper provides a qualitative analysis that lists and describes the techniques with the features of each one. Given that this paper addresses a lower level of optimization compared to our focus it was decided to merely and briefly discuss it to provide a comprehensive alternative look on possible optimization approaches. In the end, an honorable reference should be made to a research paper that applies live machine learning and deep sleep to achieve a self-adaptive efficient configuration of battery powered sensors [48]. Although the paper targets the issue of power consumption only, the novel and comprehensive approach, and the motivation that the authors share with us in efficiency of resources consumption in IoT devices has been though to be relevant to be mentioned in our thesis given it the right to be mentioned in our research. Motivated mainly by the necessary use of limited bandwidth networks and battery-powered devices in sensor nodes, their proposal aims at introducing a middleware that with the support of a deployed regression-based prediction model, continuously generates and exposes to the sensor network an energy-efficient sensors configuration based on live observations of data.

3.3 Comparative Discussion

To conclude this chapter, we have seen how the constrained-resources nature of IoT systems has been driving research efforts to analyze, evaluate, and compare different technologies at different levels with the goal of achieving an optimal IoT settings that can be scaled out to meet any IoT system requirements. Despite the different technologies and approaches undertaken, the common fact remains that IoT applications require more examination and research endeavors to arrive at standardized methodologies to cope with the resource challenges and in turn help achieve the massive vision and expectations of IoT. In the next chapters, we describe in detail the methodology undertaken to contribute to these endeavors; the approach goes through exploring and evaluating techniques of payload serialization in the context of IoT sensor nodes. To define a starting point, and based on the literature works that is highlighted in this chapter, it has been tested and proven that text-based data formats such as JSON and XML result in relatively larger messages’ sizes which remains an expected result given their reliance on special characters and tags overheads, which also CHAPTER 3. RELATED WORK 30

contributes to the slower serialization and deserialization speed when compared with other binary- based techniques. These techniques hence require further exploration and investigation in order to accentuate their performance when tested in IoT context, a requirement that shapes the scope of this thesis. Chapter 4

Binary Data Serialization in Sensor Nodes

4.1 Introduction and Case Statement

From the discussion in previous chapters and the surveyed literature work, it’s concluded and proven that reducing the overall data transmission is a crucial and beneficial process in IoT applications and especially in sensor-based IoT systems due to the resources impacted by high data transmission and the limitations and constraints that apply to these resources. It’s also proven that the increase of the amount of transmitted data remains the result of several contributing factors mainly: the overhead of the data exchange protocols, retransmissions occurring due to packet loss which in turn becomes more probable when more fragmentations occurs by OSI higher layers, and the fragmentation itself becomes more probable with higher payload sizes that could result in fragmentation at the data link layer. In addition to that, IoT applications must comply with the network of uplink and downlink constraints determined usually by the network operators such as the case discussed in the chapter of Related Work [1]. Moreover, the resource-constrained nature of IoT sensor nodes require the operations on the payload to be as resource-efficient as possible for these nodes to have a longer lifecycle and to have the capacity to combine more services. Many of the research approaches focus their efforts on methods that reduce data traffic by evaluating overheads generated by data exchange protocols that operate at the application layer such as MQTT, MQTT-SN, AMQP, and CoAP. This is done in purpose of proposing best candidates that can cover the different IoT application cases. However, and due to the correlation that payload size has with the reasons behind higher transmitted data, we found the need to test, evaluate, analyze, and propose candidate techniques that optimize the payload serialization process and payload size to be as nimble as possible. Currently, the common utilized standardized data format techniques relied on in IoT are text-based and include: JSON,

31 CHAPTER 4. BINARY DATA SERIALIZATION IN SENSOR NODES 32

XML, HTTP-based messages [11]. However, the ETSI M2M specification standard [44] recommends in addition to JSON and XML, one binary-based format called Efficient XML Interchange (EXI) which is a binary extension of the XML format [49]. In our research, the selected candidate techniques that operate at the data format layer are compared in order to arrive to the best-fit one with the potential of becoming a standardized data format that fits a wide spectrum if not all IoT application scenarios. For the implementation of this thesis, the scope focuses on a comparative analysis on the selected set of binary-based data serialization mechanisms that includes: Protocol Buffers, Flat Buffers, MessagePack, and BSON. The aim is not to show how these techniques outperform common text- based techniques, as this has been sufficiently tested and proven by previous research works referred two in Chapter 3 and by several benchmarking projects referred to in Chapter 2, but rather to have an outlook on how these techniques compare to each other in order to arrive to candidate(s) mechanisms to be potential data format standard in IoT infrastructure. To achieve this, each mechanism is implemented, tested, quantitatively evaluated, and then qualitatively overviewed. This chapter focuses on the implementations chosen for each mechanism to be used in the experiments, and it also defines the qualitative and quantitative concept of the analysis.

4.2 Implemented Protocols

For each of the selected protocols in this research, several libraries and implementations exist. We used criteria of official implementation reference, lightweight characteristics, and compatibility with embedded devices platforms to finalize the selection of the protocols implementations to use in our experiments. We distinguish here between two concepts, a library and an implementation. A library is an implementation designed for specific purposes like less memory usage and higher speed, but applies the same mechanisms relied on in the official protocols, this comes as a feature of the open-source community and allows interoperability between the different platforms utilizing different libraries. An implementation on the other hand, utilizes the same abstract concept of the official one, but with modifications applied to the mechanism for purposes of simplicity and fast development speed, which in turn could affect interoperability or require additional logic to be understood by platforms following libraries. In this research, beside the constraints and errors encountered trying to use the same library/implementation for each of two test platforms, the utilization of different implementations yielded beneficial as it provided a wider scope of analysis for the different protocols. This in turn serves our purpose given that the research aims at exploration of a standardizable candidate data serialization mechanism. CHAPTER 4. BINARY DATA SERIALIZATION IN SENSOR NODES 33

Protocol Buﬀers

For the implementation of this protocol, Nanopb is chosen 1. Nanopb is an open-source C-based library for encoding and decoding messages in Protocol Buﬀers format designed to be used by memory-restricted systems. It’s actively maintained on a GitHub repository 2. This implementation was chosen due to its minimal code space and RAM requirements and its customized to be used by 32-bit microcontrollers. Code space is claimed to range from 2 to 20 kB depending on processor and RAM usage is claimed to be typically 300 bytes. Therefore, it’s optimal for a limited-resource platform like the typical sensor nodes used in an IoT system. Additionally, Nanopb supports almost all Protobuf features and data types so that the use case advantages are not compromised. It’s also noted that in our tests, “proto 2” version of protocol buﬀers is used which is the default version supported by the Nanopb C compiler.

FlatBuﬀers

For this protocol, two libraries are used. The native C++ library with the ‘FlatC’ compiler is used on the NodeMcu platform to compile the schema and creating the buﬀers. This is due the better programmability and integration with the IDE used to program the board. On the other hand, the C library ‘FlatCC’ with a C compiler is used for the Cooja Z1 mote implementation to compile the schema and generate the header ﬁles. This is due to the very restricted Contiki OS C-based implementation that does not support libraries and code based on versions higher than ANSI C89. This library is a separate GitHub project maintained by a members-only group called Dvidelabs.

MessagePack

For this protocol, also two implementations are used. For the NodeMcu. For the first round of experimentation the latest ArduinoJSON library version 6.12.0 was used. ArduinoJSON is a C++ library designed for the IoT applications and the full support for MessagePack serialization and deserialization with minimal memory footprint has been added in its 6th version 3. However, it was concluded that utilizing such a library where the serialization/deserialization happen from/to JSON objects specified as “Documents” creates a sort of biased results. This is because all the other protocols are implemented and defined to serialize and deserialize to the original message rather than a JSON format. Therefore, the choice of protocol implementation was switched to another simple lightweight pure C implementation called “MessagePack” 4. For the Cooja Contiki motes, a C library open-source implementation of MessagePack serialization is used “CWPack”. This implementation is and ANSI C encoder/decoder for MessagePack format is claimed to be lightweight and is actively

1https://jpa.kapsi.ﬁ/nanopb/ 2https://github.com/nanopb/nanopb 3https://arduinojson.org/2018/06/07/version-6-0-0/ 4https://github.com/xoseperez/messagepack CHAPTER 4. BINARY DATA SERIALIZATION IN SENSOR NODES 34

maintained on a GitHub repository5.

BSON

For this protocol, a C++ stack-based library “bsonpp” is utilized 6. This library is designed to be utilized by devices with low memory as the library does no dynamic memory allocation as compared to other BSON libraries which allows BSON documents to be only appended after creation without the possibility to modify them, a limitation that does not have an impact on sensor nodes IoT applications. For Contiki motes, another C library implementation is used, which is claimed to have minimal footprint targeting embedded devices and allowing the possibility to avoid dynamic memory allocation 7. This library, however, is not very well maintained and still under development lacking some features and support for several functionalities.

4.3 Performance Metrics

The research scope focuses on two types of comparative analysis: Quantitative and Qualitative. Each category includes a set of metrics that are chosen in order to arrive to a comprehensive inspection on the performance and features of each selected protocol.

4.3.1 Qualitative Analysis

This category includes metrics that impact the overall data transmission process with emphasis on size and speed. Given resource-constrained and limited processing capabilities that sensor nodes have, it’s important to measure the processing eﬀort, the consumption, and the memory footage these protocols’ implementations have. Moreover, it’s also important to state that these metrics are platform-dependent and are subject to change based on the platform speciﬁcations, platform architecture, and the actual implementations chosen for each protocol. Even though, these metrics remain essential factors in determining the best candidate performance. The metrics shall include:

• Resulted payload size: the size of the payload after its encoded into the protocol speciﬁc format and ready to be transmitted, the size is measured in bytes.

• Serialization Speed: the average time it takes for the payload data fields to be converted into the protocol format through protocol-specific encoding mechanism and serialized into a buffer/stream.

• Deserialization Speed: the average time it takes to decode the payload and deserialize the received buﬀer/stream and retrieve the data in its original format.

5https://github.com/clwi/CWPack 6https://github.com/timstableford/bsonpp 7https://github.com/alialavia/binson CHAPTER 4. BINARY DATA SERIALIZATION IN SENSOR NODES 35

• Implementations overhead: the total size of the utilized libraries/implementations, this only includes the size of the header/source ﬁles that are used in the experiments and ignores the ones that are not utilized.

• Memory footprint: the amount of main memory used by the protocol implementation on Contiki OS Z1 motes, this is measured after summing the memory space used in serialization and in deserialization.

• Power consumption: this metric is measured only in the simulation experiments using the “powertrace” tool available in Contiki OS.

It’s important to elaborate how the Serialization/Deserialization terminology is used in this context. It’s common for the term Serialization to be used to indicate the conversion from specific data format into another different format, for example converting a message from its JSON format into another format that results in a smaller size and easier handling in the target environment. Likewise, the term Deserialization is also commonly utilized to indicate the process of converting a serialized payload data format into another format specific to the application. This is a common case in IoT-based web applications where the web server relies on XML or JSON formats, this itself is a factor in the popularity of utilizing these formats in IoT embedded system devices and sensor nodes due to the uniformity advantage of using one data format across the IoT system. In our research, we consider the case where the payload data is transmitted to any endpoint in an IoT system and hence, there’s no ruling format assumed that require the resulted payloads from each selected protocol to be converted to. Moreover, as discussed before, there exist several benchmarks done by the open-source online community which shows how binary-based formats outperform some of the most common text-based formats even in an environment where these text-based formats are considered native to the application and where the binary-based formats need to be serialized/deserialized to/from the application format (example: JSON on a JavaScript environment) [36, 37]. Therefore, for the reasoning behind the payload size baseline, data type storage size of C/C++ is used given the coding environment of both platforms utilized in our experiments.

4.3.2 Quantitative Analysis

This category includes metrics that highlight protocols support of interoperability, usability, and ease of use. This is due to the diversity of IoT applications and platforms that require the data serialization mechanisms to be interoperable and to support multiple languages and platforms. Ad- ditionally, the existence/inexistence of schema has an impact on the resulted payload size and the parsing effort required to convert the serialized data to another desired format native to the application. This is due to the additional effort required to encode data fields names as strings in order to map their corresponding values back correctly when decoding. Therefore, the qualitative metrics include the following: CHAPTER 4. BINARY DATA SERIALIZATION IN SENSOR NODES 36

• Supported Languages: the programming languages that the mechanisms support on terms of schema compilers in case of schema-based mechanisms and library implementations in case of schema less mechanisms

• Target Platform Support: based on the two platforms utilized in the research and the library support for their build systems, compilers and linkers

• Documentation and resources clarity: determined based on the clarity of the mechanism’s/library’s development guide, and the current variety of examples and tutorials.

• Implementation eﬀort: the learning curve represented by the eﬀort it takes to adopt the mechanisms in all system endpoints, this depends on code size and developers’ expertise level (beginner, intermediate, advanced), so the evaluation given is based on our current expertise level and the issues found and solved by referring to the community

• Activity level: the presence of active developers’ community and support, this is determined based on the level of support in the open-source online community dedicated to published issues and problems.

• Library Status: this is speciﬁc to the library implementation chosen for each mechanism and it could be: maintained, deprecated, or archived Chapter 5

Hardware Setup and Implementations

This and the next chapter aim to walk the reader through the implemented systems for conducting our experiments. In this chapter we first cover the of hardware-based implementations followed by the details of the simulations on the next one. As discussed thoroughly before, the protocols to be evaluated are implemented in each of the two settings: simulation as well as concrete hardware settings. The objective is to validate our hypothesis as well as achieve a possibly broader implementational experience. Separate experimental settings provide critical differences in platform hence our study covers multiple mote level IoT architectures: achieving comprehensive results on h/w MCU based environment (no OS) and on simulated environment (with OS) . Another consequence of this methodology is the fact that, for these non-standardized protocols, multiple libraries/implementations could be tested. Additionally, the simulation environment enables gathering energy consumption data for controlled performance benchmarking. The market remains rich in IoT development boards due to the large DIY community and numerous projects implemented in the academia that rely mainly on open-source tools. However, for the selection process, we gave priority to several factors that determined our final hardware development platform. These factors are used in order to assure that generated results can consistently indicate the performance of the protocols in IoT applications deployed in real-world scenarios. These factors consist of: standards followed, available on-board resources, power consumption, programming level supported, active community, compatibility with sensors and actuators, supplier reliability, and compatibility with our hardware development experience. Additionally, the W3C web of things community group was referred to [50] which contributed to the final choice of the development platform. Eventually, version 3 of the single-board NodeMCU microcontroller was the platform of choice. The technical specifications of the board are listed in the next section.

37 CHAPTER 5. HARDWARE SETUP AND IMPLEMENTATIONS 38

5.1 NodeMCU Speciﬁcations

NodeMCU is an open-source IoT platform. Its firmware runs on ESP8266 Wi-Fi system-on-chip 1 that has an established and large community support due to its wide use in open-source IoT projects 2, two factors that have made NodeMCU in turn widely supported and utilized. In addition to that, the NodeMCU is a development board rather than a module which means that it has several extended capabilities specifically designed to make the programming and interfacing processes uncomplicated as well as having an affordable cost for its different versions. For our experiments, Lolin NodeMCU v3.0 is used that has the following specifications:

• Microcontroller: Tensilica 32-bit RISC CPU Xtensa LX106

• Operating Voltage: 3.3V

• Input Voltage recommended: 7-12V

• Digital I/O Pins (DIO): 16

• Analog Input Pins (ADC): 1

• UARTs: 1

• SPIs: 1, I2Cs: 1

• Flash Memory: 4 MB

• SRAM: 64 KB

• Clock Speed: 80 Mhz

• Wi-Fi: IEEE 802.11 b/g/n

Despite having relatively large memory and processing speed, the downside to using this board in an IoT sensor network environment could be the limited number of input/output pins in addition to having only one analogue input pin. This in turn could pose limitations on large IoT applications where utilizing large-scale sensor networks. Additionally, several Arduino C89 based libraries implementations have turned to be incompatible with the board due to its esp8266 architecture that is not designed to compile C89-based programming style that utilizes many type conversions. This limitation in turn aﬀected the choice of protocol implementation to use for the NodeMCU, speciﬁcally for the BSON and MessagePack Implementations.

1https://www.espressif.com/en/products/hardware/esp8266ex/overview 2https://www.esp8266.com/viewforum.php?f=25 CHAPTER 5. HARDWARE SETUP AND IMPLEMENTATIONS 39

5.2 Arduino IDE

Essentially, the NodeMCU ﬁrmware uses Lua scripting language that is built on the Espressif Non- OS SDK for ESP8266. However, Arduino.cc introduced a “Board Manager” that utilizes several cores allowing the installation of third-party platform packages. With this feature, the Arduino Integrated Development Environment can support the compilation of an Arduino C/C++ code for the target Microcontroller machine language using the IDE avr-gcc compiler 3. This gives the advantage of using familiar Arduino’s functions, libraries, and programming style. Therefore, to program the NodeMCU, Arduino IDE is used with the ESP8266 core that supports diﬀerent versions of NodeMCU board.

5.3 Platform Conﬁguration

ESP8266 core file was sourced from the official ESP8266 core website that maintain the stable core package in JSON format that Arduino IDE requires for third-party cores 4. Then the updated core version 2.5.2 was installed on Arduino IDE, this core allows to program different ESP8266-based boards including the NodeMCU. The uploading baud rate speed is set to 115200 as recommended for the NodeMCU board. Additionally, ESP826-based boards use a built-in UART flashing which allows for a seamless code flashing from using a USB Type-A to micro USB cable from the USB port of the computer. Therefore, there’s no Programmer used which leaves the programmer setting in Arduino IDE to default ArduinoISP since it has no impact on the programming process in this case. Additionally, the IDE is run on a machine that runs on a 64-bit Windows 10 version 1909.

5.4 Protocol Buﬀers Implementation

The Nanopb latest release of 0.3.9.2 was downloaded 5. The library package includes the C compiler used to compile the proto schema file. In purpose of utilizing Nanpob as an Arduino library in order to use the protocol buffers functions seamlessly in the Arduino IDE, a library folder named nanopb is created in the Arduino libraries directory. This folder contains files that are copied from the installed Nanopb package. The copied set of files include: pb.h, pb common.h, pb common.c, pb ecnode.h, pb encode.h, pb encode.c, pb decode.h, pb decode.c, pb decode.h. The utilization of a library allows the IDE to handle the used file hierarchy in a more efficient way avoiding complexities in maintaining a correct including structure of header files. After that, the schema file is compiled from the command line running the command: protoc --nanopb out=.#pathschemafile#.

3https://www.arduino.cc/en/guide/cores 4https://github.com/esp8266/Arduino 5https://jpa.kapsi.ﬁ/nanopb/ CHAPTER 5. HARDWARE SETUP AND IMPLEMENTATIONS 40

This generates two files that are specific to the defined schema structure with the extensions pb.h and pb.c, these two files are placed in a src folder inside the Arduino sketch folder. In the code, four header files are included in the preprocessor directive: pb common.h, pb encode.h or pb decode.h, pb.h and the header file generated from schema compilation with the pb.h extension type. Only one of the encode/decode header files need to be included in the program and this depends on the needed process. In our approach, the payload serialization and deserialization processes are chosen to run separately on two different Arduino sketches, and therefore each sketch includes either the encode or the decode header files. The schema fields are filled, encoded, and serialized into a predefined-size buffer that stores the protobuf encoded message. The other program in turn, takes the encoded buffer, decodes it, deserializes it, and accesses the schema fields’ values to be able to process them or assign them to other variables. For serialization, an output stream is created which takes an empty buffer. Then an instance of the message defined in the schema is created, and after filling the values for the message fields, pb encode() function is called to encode the message fields and serialize them into the output stream. For the string fields of the message, a special encoding function pb encode string() is used since that strings are defined as callback functions by default. For the deserialization part, thanks to the header files generated from the schema that are also added to the include directive by the deserialization program, a message instance is created to map the decoded data to the appropriate message fields, an input stream is also created and passed the buffer that has the encoded message, the decode() method is then called to decode and deserialize the data back to the message fields. The fields’ values can be accessed normally using their variables’ names (e.g. mymessage.myvariable). There’s also a special function needed to decode any string fields from the message.

5.5 FlatBuﬀers Implementation

As discussed before, no third-party library/implementation is used in flatbuf due to the inexistence of an implementation specific and optimized for embedded systems constrained platforms. There- fore, the official native C++ library is used. Following the same methodology, flatbuf source code repository is cloned 6. For that, the C++ schema compiler ’flatC’ is built and used to compile the fbs schema file from the command line by using the command: flatc --cpp #pathtoschemafile#, which generates on header file. Then, a flatbuf library folder is created in the Arduino libraries directory and includes subset of files from the include directory in flatbuf root folder. This subset comprises the only required files for using flatbuf in an Arduino environment, it includes base.h, flatbuffers.h, and stl emulation. Additionally, the needed header files include paths are modified accordingly after relocation. Moreover, and like the protobuf case, a src file is created in the Ar- duino sketch folder where the header file generated after the schema compilation is placed. In the

6https://github.com/google/ﬂatbuﬀers CHAPTER 5. HARDWARE SETUP AND IMPLEMENTATIONS 41

code, the three header library files are added to the #include directive in addition to the header file generated after schema compilation resulting in a total four header files. Similarly, two separate Arduino sketches are used to serialize and deserialize the payload. A distinguish between flatbuf and protobuf is that the flatbuf implementation source code uses only header files that declare the different functionalities unlike protobuf that relies on “.c” source code for functionalities declaration. However, it’s the total size of these files that has an impact on the resulted library overhead each of the protocols imposes on the platform. In all the tests, only the Table flatbuf data structure is used in the schema and has all the fields defined inside it. For serialization, firstly, a FlatbufferBuilder instance is created which contains an empty buffer that can automatically grow if needed. It’s used to encode and serialize the data into the buffer utilizing add fieldname(&fieldvalue) functions defined in the header files, string variables require a special function to be called builder.CreateString("stringvalue"). For deserialization, thanks to the schema generated header file that is included in the preprocessor directive in the deserialization code, a root type class instance conforming to the root type data structure defined in the schema. This instance is assigned the address of the pointer that points to the root object inside the received buffer which in turns is used to access the different payload fields instantly without the need to create a message instance to deserialize the fields values into. This mechanism is what gives flatbuf a great advantage when it comes to deserialization speed.

5.6 MessagePack Implementation

Unlike the previous two protocols, MessagePack is a schema less serialization technique that does not require any compilation mechanisms before implementation. However, this requires the encoding of payload fields’ labels as well, given that each data field value has a specific field name that needs to be mapped out appropriately at the deserialization part. This results in an additional data to be encoded and thus a larger totally payload size. In the tests, the only file that needs to be included in the preprocess directive is the library header file MessagePack.h which has all the classes and functionalities declared within. The tests done on NodeMCU relies on a MessagePack implementation referred to previously and it utilizes an addDataType() class functions to encode different data types; for example addFloat(float variable) is used to encode float variables and so on. Also, length() fucntion is used to retrieve the size of the encoded message in order to store it in a buffer. On the deserialization side, unpack() function is used to unpack the message data from the buffer to the MessagePack class instance, then a count method is used to retrieve the number of values that were successfully unpacked. The library uses a loop-based sequential check for each byte to match a specific data type to be decoded accordingly using the get() methods for each data type, this results in significantly slower deserialization speed compared to the other protocols especially when more values are serialized. CHAPTER 5. HARDWARE SETUP AND IMPLEMENTATIONS 42

5.7 BSON Implementation

BSON is also a schema-less protocol and thus requires the encoding of data fields’ names like Mes- sagePack. For the implementation, a BSONPP document is created and passed a buffer of a defined size. The only file that needs to be included in the preprocess directive is the library header file BSONPP.h which relies on a cpp file for the functionalities’ declarations. Then, and thanks to the simple yet efficient implementation of the library, only the append(arg1,arg2) member function is used; the function is utilized to take a string in the first argument that is used to encode the fields’ labels, and a variable in the second argument to encode the fields’ values. The getter function getSize() is used to determine the actual size of the encoded data. For the deserialization part, a BSONPP parsed type of document is created and it takes the input buffer and the size of that buffer then another getter method get(arg1,arg2) is used to decode the data where first argument is the string value of the field label, and the second argument is a variable created to store the corresponding decoded field value which also needs to correspond to the field value data type. Therefore, in this implementation, it’s important to note that the deserialization part should be aware of the fields’ label names and fields data types in order to be able to retrieve their values correctly which adds a bit more of security layer that is usually missing in schema less protocols like MessagePack. In all the implementations, the Arduino time function micros() is utilized to capture the time at the beginning and at the end of the serialization process, and likewise for the deserialization process. The function returns an unsigned 32-bit integer which represents number of microseconds since the board began running the program and it’s utilized in many Arduino-based implementations to measure the time a target process takes by subtracting the captured time before the process begins from the captured time value after it ends. It’s also important to note that the resolution of the function depends on the clock speed of the microprocessor. Chapter 6

Simulation Setup and Implementation

Simulation is a key practice for rapid prototyping. It reduces time-to-market by relaxing physical hardware constraints, as well as, allowing for controlled experimentation, debugging and development. Today, the IoT community has multiple tools at its disposal for simulating virtual platforms, hardware and networks. One very popular simulator is Cooja, the Contiki network simulator. In the bevy of Operating Systems available to mote class devices for IoT applications, among other options like RIoT, Android Things, et. cetera, Contiki stands out with great community backing, range of device support and market adoption. As a consequence, Cooja network simulator, which simulates nodes based on Contiki OS, provides a close to complete environment for our target simulations. We would like to point out that this setup’s possibility to scale implementations and better visualize communication was also a driving factor for choosing this suite. In the following sections we cover the details of the simulation implementations.

6.1 Contiki OS

Contiki OS is a lightweight open source IoT operating system, conceptualized in 2002, targeted at constrained devices based on low power microcontrollers and scarce resources [51]. It runs com- petently using Internet protocol IPv6, and IPv4 while supporting wireless standards like MQTT, CoAP, 6LowPAN, RPL. There is a new version of Contiki operating system – Contiki NG, which is a fork of the original Contiki OS and aimed at the next generation of devices. To test our implementations for a wider market, we decided to develop the applications on Contiki 3.0. The core language of this operating system is C. Contiki is suitable for low powered internet connectivity, it is

43 CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 44

a highly portable OS and Open source. Within Contiki, all processes share one stack to save memory. Lastly, developer community is still very active and ﬁnding solutions to problems encountered during development is usually uncomplicated. The utilized version of Contiki OS is Contiki 3.0 (released on 26.08.2015)

• Ships with a built-in internet protocol suite.

• Uses event-driven programming model to handle concurrency.

• Only 10kb of RAM and 30 kb of ROM is needed to run the OS.

• Uses Protothread memory-eﬃcient programming model.

• Uses Rime stack – a lightweight communication stack for sensor networks.

• Manageable by hardware platform, for example, TI MSP430x, Atmel AVR, Atmel Atmega128rfa1.

• Written in the C programing language and all programs for it are also in C

• Supported device hardware platforms: TI MSP430x, Atmel AVR, Atmel Atmega128rfa1.

6.2 Cooja Simulator

Cooja is the Contiki network simulator which is widely used to test applications in small and large networks of Contiki motes (simulated sensor modules). This tool has two emulator software packages: Avrora and MSPSim. Cooja use Avrora, for emulation of Atmel AVR- based devices, and MSPSim for emulation of TI MSP430-based devices as a result, it can emulate multiple platforms like: TelosB/SkyMote, Zolertia Z1 mote, Wismote, ESB, MicaZ mote.

• Supports simulation of the radio medium and integration with the external tools

• Provides option to easily estimate power consumptions of nodes in simulations

• Visualize radio transmissions and receptions.

• Can scale testing of nodes and network

• Written in Java (Java Swing based GUI)

• Works with Avrora or MSPSim supported device images/ﬁrmware CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 45

6.3 Simulation setup

To setup our simulation workbench, we make use of the Instant Contiki 3.0 development environment which ships with all the tools and compilers needed for Contiki development and debugging. Instant Contiki is, in fact, an Ubuntu Linux based virtual machine (VM) image with Contiki OS installed. More importantly, the Cooja simulator is preinstalled and set up to work out of the box. It is an open source project and comes with Contiki’s BSD license. For this we refer to the Cooja simulator manual [52]. We ﬁrst download the Instant Contiki 3.0 image. Once the archive is downloaded, we use Vir- tualBox 6.0.14 in our host machine running Mac OS Catalina Version 10.15.1 to attach and start the vm. The Instant Contiki vm might not contain the MSPSim tool which is required for simulating our target MCU platform (Zolertia Z1). MSPSim is a Java-based instruction level emulator of the MSP430 series microprocessor platform. For missing MPSim, we can download: MSPSim version 0.9x separately from GitHub1, unzip the archive and rename it from mspsim-master to mspsim and paste them inside the tools folder of the Contiki installation replacing the existing empty home/contiki/tools/mspsim and home/contiki-3.0/tools/mspsim directories Now we can open a new terminal and navigate to the cooja directory user@instant-contiki:˜/contiki-3.0/tools/cooja$ and execute the command ant run. This should build and start the Cooja simulator where we can now simulate our devices. Our target hardware, the Zolertia Z1 is a general-purpose mote class device development platform for wireless sensor networks (WSN) designed for researchers, developers, enthusiasts and hobbyists. It supports Contiki OS and is well suited for our testing needs of low powered IoT sensor node platform, the Z1 Mote Platform has the following speciﬁcations2:

• MCU: Ultra-Low Power MSP430F2617

• Clock speed: 16 MHz

• Operating Voltage: 3V

• RAM: 8 KB

• Flash Memory: 92 KB

• Connectivity: 250 Kbps, 2.4 GHz, IEEE 802.15.4, CC2420 transceiver

• Sensors: temperature, 3-Axis accelerometer

Note: The Z1 sensor node runs at a clock speed of 8 MHz in Cooja.

1https://github.com/contiki-os/mspsim 2http://zolertia.sourceforge.net/wiki/images/e/e8/Z1 RevC Datasheet.pdf CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 46

We can find example applications ready to be simulated as running on z1 motes inside the example subfolder of out Contiki installation directory. These directories contain the source code and build instructions for the MSP430-gcc compiler that compiles the source for us into a firmware image with the file extension .z1. The Contiki build system can compile Contiki applications for different hardware platforms by providing different parameters to the make command, or by editing the Makefile and/or application code. Makefile contains the instructions for the compilation tools. So, as needed we can modify the makefile per our needs; for example, adding external libraries, passing additional source files and build instructions. Once an application source is ready, we can build the application by running the command make, in the project directory of our application. Additionally, we provide it a TARGET parameter to specify the platform we wish to compile for which is z1 in our case. make TARGET=z1 this compiles the project and a Contiki system for the Z1 Zolertia platform is created. Alterna- tively, this can be added to the file in Project source directory named Makefile.target as: TARGET = z1 In this case, the application does not need to be build using the make command and can be directly compiled when creating a device during a simulation. Cooja can be run from terminal by going to the Cooja folder inside Contiki’s tools folder: Contiki 3.0/tools/Cooja and then using the command: ant run We can create simulations, add motes to which we compile and deploy the Contiki project application. We can add multiple motes as per our needs with the ability to also run different types with different compiled system images. To create a new simulation, click on motes then create new mote and select the mote type z1 in our case. Then select the firmware we wish to flash and click compile. Once compiled we can click create and the number of motes we wish to create. Once the motes are created, we can move them around in the Cooja network visualizer. Once we have all the desired motes placed on the network, we can click on start to start our simulation. Note, that the DWGM window of the Cooja network visualiser window relates to physical world distances over the wireless sensor networks. Eventually, we can see the mote outputs in the mote output window while the motes running. The outputs and debug info of the motes are all colour coded in the output window. At the end of our simulation we can export the output to a log text file for further processing. To validate implement ability of the data-serialization protocols, first, we design our setup as a MQTT-SN based sensor network over 6LowPAN and RPL. Enabling communication over MQTT- SN posed a little bit of challenge. MQTT-SN being relatively new has next to none documented implementation for any Contiki device. There was a need for an MQTT-SN capable broker for which there can be a number of MQTT-SN Clients. Our chosen broker is the RSMB Broker as that CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 47

is the only open source broker we could find. Aignacio’s MQTT-SN implementation3 is the only implementation work we found to suit the needs. The project is hosted on git-hub [53] and is an ongoing work and as far as the bare minimum for proof of concept goes it serves the purpose. Hence, we clone the repository which contains the necessary Zolertia z1 firmware sources with MQTT-SN capable communication implemented. Also, there was a need for an MQTT-SN capable broker for which there can be several MQTT-SN Clients. Our chosen broker is the RSMB Broker as that is the only open source broker we could find. After this we proceed to create applications which implement our desired test setups. So, for each of the chosen protocol, one application each is developed for the Zolertia z1 mote running Contiki. This gives us the proof of concept to validate a complete working implementation of our protocol. We validate that the implemented protocols work as a complete solution exchanging massages before creating the final project files that serve as test cases for our research experiments.

6.4 Benchmarking

Moving on with our benchmarking experiments, for each of our selected protocol, after validating their implementations along with mqtt-sn, we create new mote source projects which only contain the protocols implemented , without any additional library or protocol. This achieves 2 objectives:

1. A simpler interpretation of protocols impact on storage and memory of the motes,

2. A more accurate representation of impact of power consumption of the motes.

Speed (serialization and deserialization)

To benchmark speed, we use record the lapsed time while performing either serialization, deserialization or both. Contiki provides multiple timer libraries for scheduling wake up from low power mode, performing timed events and real-time scheduling. We use the rtimer library if Contiki for our speed benchmarks due to its higher resolution. rtimer counts time in clock ticks which depends on the RTIMER ARCH SECOND value. Checking for the value in our simulation, we get:

CLOCK_SECOND=128UL RTIMER_ARCH_SECOND=(4096U*8)

This can be interpreted as, the CLOCK SECOND value is 128 Unsigned (U) Long (L), and that the RTIMER ARCH SECOND value is 4096 Unsigned (U) * 8, which means RTIMER ARCH SECOND value is 32768. So the lowest resolution for etimer is 1 / CLOCK SECOND = 1 / 128 s = 7,8125ms. Besides, the lowest resolution for rtimer is 1 / RTIMER ARCH SECOND = 1 / 4096U*8 = 1 / 32768 = 30.5175ms(rtimer resolution).

3https://github.com/aignacio/mqtt-sn-contiki example CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 48

Clocking the time interval is pretty straightforward and simple. The example code for which is below:

static uint32_t elapsedTime; rtimer_clock_t start; start = RTIMER_NOW();

// Payload Serialize / Deserialize Code goes here

elapsedTime = (RTIMER_NOW() - start);

the elapsedTime variable provides us with an absolute time diﬀerence in clock ticks which is divided by the RTIMER ARCH SECOND value to obtain the equivalent time in seconds.

Memory (RAM and Flash occupancy)

We can see the memory usage of a Contiki application (our protocol buﬀer implementation for the mixed payload application) in terminal using the command: size core_pb.z1

Where core pb.z1 is the generated platform ﬁle compiled in Cooja From the ﬁgure 6.1, we can see

Figure 6.1: Output of size command on compiled z1 system image the memory usage in bytes for the memory segments. “Text” denotes the code and read-only data in the application, the “Data” label shows the read-write data and the “Bss” segment shows the zero initialized (‘bss’ and ‘common’) data. “Dec” is a sum of text, data and bss. “Hex” is the hexadecimal equivalent of “Dec”. Typically, the ﬂash consumption of application will be text+data, and RAM consumption will be data+bss. RAM consumption includes only global data and it will not include the memory consumed by stack and heap, when application is actually executing[54].

Power Consumption

To analyze the power consumption of a sensor node, powertrace was used. Powertrace is a tool that is supplied with Contiki OS and can be enabled by adding the following line to the Makeﬁle of our application project. CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 49

Parameter & Value Meaning clock time()= 9063 clock time rimeaddr = 193.12 rime address seqno = 6 sequence number all cpu = 21116 accumulated CPU energy consumption all lpm = 2271779 accumulated Low Power Mode energy consumption all transmit = 5305 accumulated transmission energy consumption all listen = 13512 accumulated listen energy consumption all idle transmit = 0 accumulated idle transmission energy consumption all idle listen = 0 accumulated idle listen energy consumption cpu = 6226 CPU energy consumption for current cycle lpm = 321333 LPM energy consumption for current cycle transmit = 2652 transmission energy consumption for current cycle listen = 1968 listen energy consumption for current cycle idle transmit = 0 idle transmission energy consumption for current cycle idle listen = 0 idle listen energy consumption for current cycle

APPS += powertrace We run powertrace as a background process on the sensor node. Powertrace reports the power consumption and resource utilization of a node printing the statistics to the console. Our implementation captures the power consumption every 10 seconds when running the program, the mote output window displays power consumption statistics on the screen. An example of the output and the explanation are given as follows:

01:11.245 ID:1 9063 P 193.12 6 21116 2271779 5305 13512 0 0 6226 321333 2652 1968 0 0 (radio 0.82% / 1.41% tx 0.23% / 0.80% listen 0.58% / 0.60%)

Powertrace tracks the duration of activities of a node being in each power state showing the fraction of time that a node remains in a particular power state. In the above example, there are 6 defined power states, out of which we only concern ourselves with the following 4 parameters namely: CPU, LPM, TX(listen), RX(listen). Again, the clock frequency is defined in RTIMER SECOND (or 32,768 Hz for Z1). The statistics can be saved into a named file which can be further processed to gather our inferences. parameters1We calculate the power consumption by using the following formula [55]: Power consumption = Energest Value * Current * Voltage / RTIMER SECOND * Runtime Energest Value is the difference between the number of ticks in two time intervals (the energy consumed by a state in current cycle). We get a value of current for CPU, LPM, TX and RX from the Z1 datasheet [56] Current CPU: 10 mA(CPU: Active 16MHz ) + 4 mA(Memory: minActiveMem) Current LPM: 0.0005 mA(CPU: Low power) + 0.001 mA(Memory: deepPowerDown)+ 0.020 mA(CC2420 WiFi IDLE) CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 50

Current TX: 17.4 mA + 10 mA + 4 mA Current RX: 18.8 mA + 10 mA + 4 mA Voltage: 3V RTIMER SECOND: 32768 Runtime: 10 seconds where the total time interval is 360 * 10 = 3600 Seconds = 1Hour for each experiment. We export the generated figures as log files .We obtain the average of the new total power consumption to get our benchmark figures using R to process the logs. One additional base application was created with only powertrace running to provide the baseline for the comparisions. This z1 Zolertia based Contiki application contains no additional library or protocol implemented and only runs the loop mechanism used for all experiments.

All the steps, starting from creating to running the simulations above remain the same for each of the 4 implementations as mentioned below. The exact implementations diﬀer from each other with respect to the implementational details regarding the individual protocol library chosen. As the protocols have been discussed well before, the purpose of the following sections is to mostly highlight and discuss these diﬀerences.

6.5 Nanopb (Protocol Buﬀers)

The Nanopb is a small code-size Protocol Buﬀers implementation in ansi C. It is especially suitable for use in microcontrollers but ﬁts any memory restricted system. There are 2 parts to this implementation : the namopb library and the nanopb compiler. For implementing the nanopb library, we do the following:

1. We use the nanopb compiler: protoc to compile test data schema ﬁle.

2. Include pb encode.c, pb decode.c and pb common.c to your project. To add these we make no changes to makeﬁle, rather just simply add the libraries to the core pb.c ﬁle and burn the image to our mote.

6.6 FlatCC (FlatBuﬀers)

The FlatCC is the C implementation library of the FlatBuﬀers written in C for C based platforms. Its implementation depends on the use of build and compiler tools, and the C runtime library. Built primary in c11 standard and hence has backward incompatibility issues with c89 compilers used in our case. In this case faltcc needs to be built for the target platform and then the ﬂatcc compiler CHAPTER 6. SIMULATION SETUP AND IMPLEMENTATION 51

is used to compile and generate the flatbuffers code for C, given the FlatBuffer schema file. The implementation is a bit more complicated in this case than all other protocols here. As it depends on the library being cross compiled for the MSP340 platform along with the Contiki build process which can be tricky as we could not track helpful resources regarding this. Even the compatibility library, 178 KB Portable library proved problematic to include in the application bound to run with 8KB RAM and 92KB Flash memory in the simulated platform. Searching for options to increase memory in simulation lead to acceptance of the fact that options are not worth exploring and deviates from the whole purpose of using the hardware. Plus, although we made it work, it required code level changes in the library files themselves that was still far from ideal and which we do not recommend.

6.7 CWPack (MessagePack)

CWPack is a C implementation of the MessagePack serialization format. It currently implements version 5 of the MessagePack Spec [57]. There is no build system for CWPack. The programmer can drop cwpack.c, cwpack.h and cwpack deﬁnes.h in their source tree and modify the header includes as necessary. No special compiler settings are required to build it, and it generates no compilation errors in either clang or gcc.

6.8 BINSON (BSON partial implementation)

BINSON is a minimal implementation of the BSON specification. Currently it only decodes BSON serialized data. Hence, we only included BSON in decoding tests and the energy figures from the same were only considered. The maintainer Alialavia [58] claims that the implementation targets embedded devices, thus is focused on minimum memory and flash footprints. It oncly comes with two files required for implementation: binson.c and binson.h. It is also claimed that binson.h has a minimum memory footprint as it doesn’t allocate any dynamic memory. Implementing binson is straightforward and we can use directly include the header and c file in our application souce and compile with no c89 compatibility issues. Chapter 7

Experiments and Discussion

This chapter describes the experiments building blocks utilized to run tests of each protocol implementation to obtain the results that shape the comparative analysis of this thesis. We start by describing the experiment settings utilized, then we show the results obtained with a discussion.

7.1 Payload Structure Types

In purpose of examining how each protocol behave under different scenarios that utilize different payload structures. Each structure is designed to refer to common IoT payload data taken from real use cases. Additionally, each structure is designed to be purposely biased towards a specific data type category in order to have a better understanding of protocols behavior under different circumstances. To have a baseline of payload size, we refer to the sizes of different data types used, the reference is based on how each C language data type is stored in a 32-bit CPU. In all cases -unless explicitly stated- the variable data types used to calculate the original message size correspond to the same types used in each protocol test.

Payload Structure P1: numeric-only

This structure includes seven variables: two 32-bit integer variables to store the device ID and the event ID respectively, one 16-bit integer variable taking a Smoke sensor reading, three ﬂoat variables taking temperature, humidity, and pressure sensor readings, and one Boolean variable taking an active status value of true. It’s worth noting that most smoke sensor readings are sampled into decimal numbers that do not go beyond hundreds in value (i.e: a max of 3-digit number) and thus require only a 16-bit integer variable to be stored. However, given that protobuf doesn’t support 16-bit integers, a 32-bit integer variable is used in protobuf payload schema deﬁnition, and a 16-bit integer variable is used in all the other protocols.

52 CHAPTER 7. EXPERIMENTS AND DISCUSSION 53

//Numeric Payload Example int32_t deviceId; int32_t eventId; int smoke; float temp; float humidity; float pressure; bool act;

Payload Structure P2: mixed data types

This structure refers to use case of Smart Bakery IoT application where the payload data is a mix between numeric data and one short string that represents the status of the bakery oven. The payload includes six variables: two 32-bit integer variables that take the device ID and the event ID values, two ﬂoat variables to store the temperature and humidity values, one Boolean variable set to true representing oven is on, and one String variable to store the status of the oven that in the tests is always set to include seven characters.

//Mixed Payload Example int32_t deviceId; int32_t eventId; float32 temp; float32 humidity; string status; bool act;

Payload Structure P3: string-only

This structure emphasizes the scenario where sensor nodes need to send a pair of long strings, API Key/Token pair or cryptographic key pairs used to perform authentication or source veriﬁcation. This scenario gives the opportunity to evaluate how each protocol perform when dealing with long strings, a case that doesn’t make the majority of sensor nodes traﬃc, but still an essential scenario. For that, two string variables that store relatively long strings are used; API Key string that stores a 67-character key value, and a Token string that stores a value of 155 characters. These values are taken from real-case authentication payload.

//String Payload Example String APIKey; String Token; CHAPTER 7. EXPERIMENTS AND DISCUSSION 54

In schema-less mechanisms, we utilized minimum number of characters to represent fields’ names. This is done to avoid biased results obtained due to unnecessarily long fields’ names, and generally such a practice remains healthy in IoT context due to the size and processing overhead string values impose. Specifically, “did” and “eid” are used for deviceId and eventide fields’ names respectively, “t” and “h” as temperature and humidity fields’ names, “st” is used in the mixed payload for the oven status field, “act” is used for the active field, “sm” and “pr” are used for smoke sensor and pressure sensor fields’ names respectively.

7.2 Hardware Runs

The NodeMCU is conﬁgured to have an uploading speed of 115200 and programmed using Arduino IDE version 1.8.10. For each protocol implementation, a test is performed for each payload structure resulting in total of 12 tests. Each test is composed of two subtests including serialization and deserialization of the payload. The serialization and deserialization speed metrics are taken from the average results after running each serialization and deserialization program 10 times in which after that the results do not show any type of variation. Given that the payload structures utilized are ﬁxed, the payload size metric remains the same across all the runs.

7.3 Simulation Runs

The simulation experiments were executed in 3 phases. In phase 1, validation of protocol with MQTT-SN was checked. Once a protocol was validated i.e. the z1 motes were able to send payload across the simulated RPL network through MQTT-SN, we moved on to phase 2. In this phase, the MQTT-SN implementation was discarded and the protocols were deployed separately for the 3 specified payload types on bare minimum Contiki applications. Each of this was turn split into 3 applications where each separately implemented the tasks of serialization, deserialization and both (serializing and then deserializing). As discussed before, FlatCC’s incompatibility rendered it unfit for the implementations and it was discarded completely. Also, BINSON only was considered for the deserialization tests as it does not have serialization capabilities. This resulted in a total of 22 applications(experiments) including the baseline application with no protocol implementation. Much care was taken while implementing all the experiments such that they are comparable. Then each simulation was run for benchmarking the protocol speeds. In phase 3 the powertrace application and code was added to each application and they were executed again for measuring the power consumption parameters. Every simulation was run with one mote running for 1 hour collecting the power consumption figures every second. The results were exported as plain text log-files and further processed in RStudio using R with Tidyverse packages. A total of 22 log files with 7920 records in total were processed to compute the average impact on power consumption for each protocol in the CHAPTER 7. EXPERIMENTS AND DISCUSSION 55

diﬀerent tasks and settings.

7.4 Results

7.4.1 Hardware Results & Discussion

The tables below show the performance results and payload size resulted from each protocol implementation across the three diﬀerent payload structures that are numeric based, numeric with a string (mixed), and string based. Table 7.1 shows the diﬀerent payloads sizes after being serialized using each mechanism.

Payload Size (Bytes) Payload Type Numeric Mixed String Original Size 23 25 221 Protobuf 29 30 224 Flatbuf 52 60 256 MsgPack 52 51 230 BSON 71 67 242

Table 7.1: Resulted Payload Size (H/W)

Table 7.2 shows the serialization time taken by each mechanism across the three payloads structures

Serialization Speed (Microsecond) Payload Type Numeric Mixed String Protobuf 200 220 166 Flatbuf 252 155 102 MsgPack 136 114 86 BSON 257 245 175

Table 7.2: Serialization Speed (H/W)

Table 7.3 shows the deserialization time taken by each mechanism across the three payloads structures.

Deserialization Speed (Microsecond) Payload Type Numeric Mixed String Protobuf 324 345 254 Flatbuf 1 1 1 MsgPack 2126 1876 718 BSON 170 155 88

Table 7.3: Deserialization Speed (H/W) CHAPTER 7. EXPERIMENTS AND DISCUSSION 56

In Table 7.4, we can see the overall speed performance in both serialization and deserialization tasks across the three payloads.

Total Speed Comparison (Microsecond) Protobuf 524 565 420 Flatbuf 253 156 103 MsgPack 2262 1990 804 BSON 427 400 263

Table 7.4: Total Speed Performance (H/W)

In Table 7.5, we can see the size required by each mechanisms library that occupies the ﬂash memory of the platform.

Library Overhead (KB) Nanopb 123 Flatbuf 216 MessagePack 8 Bsonpp 14

Table 7.5: Library Overhead (H/W)

Discussion

When comparing the resulted payload size from Table 7.1, protocol buffers shows the best performance having 3-6 bytes in addition to the original size of the payload in numeric-only and mixed data payloads. In numeric-only payload, this is approximately two times smaller than flatbuffers and MessagePack encoded payloads and almost 2.5 smaller than BSON-encoded payload. In a mixed data type payload, protobuf message is two times smaller than flatbuf and more than two times smaller than BSON, while MessagePack message is the second smallest in size but still 1.7 larger than protobuf message. In a numeric-only data, protobuf-encoded payload is still an order of mag- nitued smaller than flatbuf and MessagePack encoded messages, and even two times smaller than BSON messages. This puts protocol buffers ahead in application scenarios that prioritize minimal payload sizes. However, when looking at the serialization time taken by each protocol in Table 7.2, we see a different ranking. In a numeric-only payload, Messagepack shows the fastest serialization speed, followed by protobuf, while flatbuf and BSON remain the slowest in serialization. The difference is around an order of magnitude and half between the fastest protocol and slowest protocol in serialization. Comparing the deserialization speed, from Table 7.3 we can observe that flatbuf is significantly faster than the other protocols, taking an average of only one microsecond to access the input buffer, decode, and deserialize the data fields. This is because flatbuffers doesn’t need to deserialize the CHAPTER 7. EXPERIMENTS AND DISCUSSION 57

whole message before accessing the field of interest. This performance puts flatbuf out of comparison when it comes to deserialization speed. Moreover, the slowest protocol to deserialize is MessagePack taking around 718 microseconds in string-only payloads and up to 2 milli seconds in the other two payloads. In numeric-only payload, BSON shows a faster performance being almost two times faster than protobuf, and this gap remains the same on a mixed payload. In a string-only payload, however, the gap is heightened in dealing with the string-only payload as BSON shows a 3 times faster performance than protobuf. To have an overall evaluation on the speed metric, we summed up the serialization and deserialization speed in Table 7.4. This highlights the higher performance of flatbuf outperforming all other protocols across all the tested payloads. Second comes BSON being average 1.5 time faster than protobuf. In the end, MessagePack shows the slowest performance impacted mainly by the slowest deserialization process compared to other protocols. Considering the library/implementation overhead size, from Table 7.5 it’s observed that Mes- sagePack is the lightest with 8KB overhead, that’s due to the simple implementation that is en- compassed in one header file making the size-speed tradeoff. Second comes bsonpp with 14 KB overhead. Flatbuf and Nanopb library sizes are considerably larger taking around 122KB-123KB for Nanopb, where Flatbuf library size is approximately double that ranging from 215KB-216KB due to the several header files required.

7.4.2 Simulation Results & Discussion

Payload size

Table 7.6 below shows the resulted payload size for each payload type in a protocol wise manner.

Payload Size (Bytes) Original Size 23 25 221 Protobuf 29 30 224 MsgPack 52 49 230 BSON 71 67 242

Table 7.6: Total Payload Size (simulation)

Speed benchmarks

In Table 7.7, the average Serialization time for the implemented protocols is displayed. In Table 7.8, the average Deserialization time of each protocol for the payloads can be seen. CHAPTER 7. EXPERIMENTS AND DISCUSSION 58

Serialization Speed (Microsecond) Protobuf 823.9746094 732.421875 640.8691406 MsgPack 335.6933594 274.6582031 396.7285156 BSON NA NA NA

Table 7.7: Serialization time (simulation)

Deserialization Speed (Microsecond) Protobuf 1312.255859 1129.150391 418.0908203 MsgPack 140.3808594 112.9150391 54.93164063 BSON 396.7285156 305.1757813 61.03515625

Table 7.8: Deserialization time (simulation)

Memory benchmarks

In Table 7.9 describes the approximate overhead added by each library

Library Overhead (KB) Protobuf(nanopb) 123 MsgPack(CWPack) 47 BSON(BINSON) 6(decode only)

Table 7.9: Library Overhead (simulation)

Table 7.10, below, summarizes the memory footprint of each implementation employing Serial- ization only

Serialization Memory Footprint (bytes) BASELINE Nanopb CWPack P1 P2 P3 P1 P2 P3

text 48085 51241 51259 51433 50611 50595 49097 data 328 328 328 328 352 354 550 bss 4912 4942 4952 5136 4964 4962 5142

Parameter total 53325 56511 56539 56897 55927 55911 54789

FLASH text + data 48413 51569 51587 51761 50963 50949 49647 RAM data + bss 5240 5270 5280 5464 5316 5316 5692

Table 7.10: Memory Footprint - serialization (simulation)

In Table 7.11, we summarize the memory footprint of the applications implementing deserialization only. In Table 7.12, we present the memory ﬁgures for each application implementing both serialization and deserialization tasks in sequence. CHAPTER 7. EXPERIMENTS AND DISCUSSION 59

Deserialization Memory Footprint (bytes) BASE Nanopb CWPack Binson P1 P2 P3 P1 P2 P3 P1 P2 P3 text 48085 53351 53343 53507 58553 58483 56903 48841 48785 48579 data 328 328 328 328 352 354 550 400 396 570 bss 4912 4912 4912 4912 4966 4962 5142 4914 4914 4914

Parameter total 53325 58591 58582 58747 63851 63799 62595 54155 54095 54063

FLASH text+data 48413 53679 53671 53835 58905 58837 57453 49241 49181 49149 RAM data+bss 5240 5240 5240 5240 5318 5316 5692 5314 5310 5484

Table 7.11: Memory Footprint - deserialization (simulation)

Serialization + Deserialization Memory Footprint (bytes) BASE Nanopb CWPack P1 P2 P3 P1 P2 P3 text 48085 56175 56193 56367 58527 58493 56911 data 328 328 328 328 352 354 550 bss 4912 4942 4952 5136 4964 4962 5142

Parameter total 53325 61445 61473 61831 63843 63809 62603

FLASH text + data 48413 56503 56521 56695 58879 58847 57461 RAM data + bss 5240 5270 5280 5464 5316 5316 5692

Table 7.12: Memory Footprint – Serialization with Deserialization (simulation)

Table 7.13 below presents the ﬁnal average power consumption ﬁgures for all the cases in experiments.

Discussion

Our simulation results regarding payload size, shown in Table 7.6, provide the same results we obtained with the hardware implementation except for the Mixed payload in Messagepack, which came out to be 2 bytes less than that of the hardware-based implementation. Regarding serialization time, from Table 7.7, we can only compare between the CWpack (Mes- sagepack) and nanopb (protocol buﬀers). We observe that CWPAck is almost twice as fast as nanopb in all the payload types. In deserialization as well, referring to Table 7.8, CWPack turns out to be the fastest followed by binson and ﬁnally nanopb. CWPack’s deserialization is 7.7 times faster than nanopb with the string only payload and upto 10 times faster in case of the mixed and numeric payloads. Binson appears closer to CWPack than nanopb in this experiment with roughly 9 times higher speed in numeric and mixed payload and 6.8 times higher speed in the string only payload twhen compared to nanopb. Binson appears 20% slower than CWPack regarding string payloads and up to 3 times slower when given numeric and mixed payloads. CHAPTER 7. EXPERIMENTS AND DISCUSSION 60

Protocol Mean Power Consumption (mW) CPU LPM TX RX TOTAL

BASELINE NA NA 0.3354476 0.06396068 0.1279809 0.5789523 1.106342

Payload 1 Serialization 0.3468323 0.06394321 0.1279258 0.5789532 1.117655 (Numeric) Deserialization 0.3539008 0.06393234 0.1280344 0.5789532 1.124821 Both 0.365101 0.06391516 0.1278707 0.578954 1.135841

Payload 2 Serialization 0.3458411 0.06394469 0.1285216 0.578954 1.117261 (Mixed) Deserialization 0.3512675 0.06393638 0.1279258 0.5789532 1.122083 Both 0.3619041 0.06392002 0.1284122 0.5789548 1.133191 Protobuf (Nanopb) Payload 3 Serialization 0.34561 0.06394507 0.130113 0.5789448 1.118613 (String) Deserialization 0.3427158 0.06394953 0.1280328 0.5789532 1.113651 Both 0.351166 0.06393652 0.130113 0.5789448 1.12416

Payload 1 Serialization 0.339838 0.06395396 0.1279418 0.578954 1.110688 (Numeric) Deserialization 0.3385188 0.06395592 0.127065 0.5789548 1.108495 Both 0.3439317 0.06394763 0.1279961 0.5789523 1.114828

Payload 2 Serialization 0.339933 0.06395379 0.1286861 0.5789523 1.111525 (Mixed) Deserialization 0.3374269 0.06395761 0.1285766 0.5789532 1.108914 Both 0.3434599 0.06394837 0.1286317 0.5789523 1.114992

MessagePack (CWPack) Payload 3 Serialization 0.3431042 0.06394892 0.1270387 0.5789523 1.113044 (String) Deserialization 0.3356246 0.06396038 0.1270403 0.5789532 1.105578 Both 0.3445829 0.06394665 0.1270418 0.578954 1.114525

Payload 1 Deserialization 0.3415103 0.06395137 0.1287012 0.5789515 1.113114 (Numeric)

Payload 2 Deserialization 0.3397625 0.06395406 0.06395406 0.06395406 1.110758 (Mixed)

Payload 3 Deserialization 0.3366991 0.06395874 0.1285926 0.5789523 1.108203

BSON (BINSON) (String)

Table 7.13: Average Power Consumption (simulation)

Table 7.9 gives us an approximate idea regarding the library overheads and we do not claim CHAPTER 7. EXPERIMENTS AND DISCUSSION 61

this to be conclusive as other factors like programmers implementation inﬂuence how much more memory is consumed by an application. For this reason we refer to Tables 7.10, 7.11 and 7.12 where the memory footprints of each implementation is presented. Memory usage

Figure 7.1: Visualizing Average Power Consumption

From Figure 7.1, it’s observed that MessagePack comes ﬁrst as the mechanism with the lowest power consumption across all the payloads and tasks. In deserialization task speciﬁcally, BSON comes second after MessagePack while protobuf shows the maximum power consumption across all payloads and tasks.

7.5 Qualitative Outlook

The table 7.14 shows a qualitative view of each of the data serialization mechanisms implemented in this research. The criteria and description of each ﬁeld is discussed in Chapter 4. This view provides a relative idea on the qualities, criteria, eﬀort backing the implementation of each mechanism, in purpose of having an outlook for implementers before moving from the current technology to adopt one of the evaluated. It’s important to note that this view has been obtained at the time of development of this thesis and some qualities might change over time. CHAPTER 7. EXPERIMENTS AND DISCUSSION 62

Protocol Supported Languages Library/ Target Document-Implemen-Activity Library Imple- Platform ation tation Level Status men- Support and re- Effort tation sources Used clarity Procol C++, C (third party), Nanopb Contiki High Low High Maintained Buffers C#, Dart, Dart, Go, MSP430: Java, Python, Ruby Yes ESP8266: Yes C, C++, C#, Dart, FlatCC Contiki Average Average High Maintained FlatBuffers Go, Java, JavaScript, MSP430: Lobster, PHP, Python, YES, cross Rust, TS compilation ESP8266: NO FlatC Contiki Average Average High Maintained MSP430: NO ESP8266: Yes Message- Through third-party CWPack Contiki High Low Medium Maintained Pack implementations: C, MSP430: C++, C# / .NET, D, Yes Dart, Delphi, Go, Java, ESP8266: Lua, Lisp, Python, No Perl, Prolog, Ruby, Message- Contiki High Low Low Under Scala, Swift, PHP, and Pack MSP430: Develop- many more (an Yes ment imple- ESP8266: menta- Yes tion) Through third-party Bsonpp Contiki High Low Medium Maintained BSON implementations: C, MSP430: C++, C# / .NET, D, No Dart, Delphi, Go, Java, ESP8266: Lua, Lisp, Python, Yes Perl, Prolog, Ruby, Binson Contiki Low Low Low Under Scala, Swift, PHP, (an MSP430: Develop- imple- Yes ment menta- ESP8266: tion) No

Table 7.14: Qualitative View Chapter 8

Conclusions

8.1 Workﬂow Summary

Motivated by the rapid development rate of IoT technologies and the numerous sectors and industries leveraging these technologies to create, elevate, or reshape services, experiences, and values offered, and the fact that sensors data constitute a major stream in the data flow of IoT systems, in addition to the resource-constrained nature of nodes harvesting these data, we selected, tested, and evaluated a subset of binary-based data serialization format in purpose of exploring the resource-optimization advantages such formats could bring the field of IoT, hoping to evidently provide the industry with an evaluation reference on the avails, applicability, and limitations of adopting these techniques. To do so, several implementations that substantially aim at optimized resource consumption were selected to test these protocols on two platforms: a microcontroller-based hardware platform with relatively high specs and performance, and a much more constrained simulated OS-based platform, this is in order to be as comprehensive as possible in evaluating the performance and impact of each protocol implementation. Three payload structures were tested where each structure emphasizes on a specific sensor nodes message type. The analysis was based on six performance metrics where each metric highlights the impact of the protocol mechanism has on the constrained sensor node resources: resulted payload size, serialization speed, deserialization speed, library overhead, memory footprint, and energy consumption. As a result, for each platform, we demonstrated the protocol(s) that showed better performance in each metric. Considering the combination of qualitative and quantitative characteristics that each mechanism possesses, it is evidently concluded that: When speed is the priority and/or the node bottleneck is represented by the low clock cycles, MessagePack protocol should be the choice for data serialization format, followed respectively by flatbuf, BSON, and protobuf. When payload size and memory footprint are prioritized, protobuf remains on top adding only few bytes to the original message size and utilizing less Flash and RAM than the others, while flatbuf shows the highest memory consumption and library overhead.

63 CHAPTER 8. CONCLUSIONS 64

On the power consumption part, all protocols showed relatively minimal power consumption, but MessagePack shows the lowest consumption. On the schema side, when self-explanatory payloads are critically required, and hence a schema is considered advantageous, we recommend utilizing protobuf as a schema-based mechanism. If more flexibility is needed, then MessagePack outperforms BSON in schema-less mechanisms. However, protocol buffers implementations trade speed and efficiency for energy consumption by a significant margin hence it might not be well suited for nodes that are strictly energy constrained. On the other hand, when a schema-less mechanism is preferred MessagePack showed faster performance and lighter memory footprint compared with BSON. Also owing to the fact that BSON is largely focused around the MongoDB community, it finds itself in a position where it is hard to recommend for specific IoT solutions.

8.2 Critical Discussion

From the experimental results, protocol buffers performed the best in optimizing the payload size having the smallest payload across the three payload structures and therefore being ideal for IoT applications that aims at minimizing overall traffic size in order to reduce packet fragmentation, comply with the network cap on downlink/uplink constraints, or to save the network b/w for other services to be offered. In the h/w experiments, flatbuffers shows very efficient speed performance being significantly faster especially in the deserialization task that almost takes one microsecond, this makes flatbuffers ideal when the payload contains numerous fields and only few fields need to be extracted. This however comes at the cost of having a significantly larger library overhead compared to other mechanisms and thus making flatbuffers appropriate for nodes with relatively large memory capacity in comparison to typical memory available in sensor nodes as flatbuffers code and library will most probably occupy a significant portion of the Flash memory of around 200 KB and an extra RAM capacity of at least 6 KB excluding the runtime stack and heap allocations which can further consume RAM depending on the application. The utilization of schema-based mechanisms gives protobuf and flatbuf an advantage in interoperability and cross-platform applications, this is combined with the advantage that having a schema generates smaller payload size due to the fact that payload field names do not need to be encoded into the message. However, the reliance on a schema also poses scalability issues as the schema needs to be shared among all system endpoints, and updates or modifications on the schema in one side need to be appropriately handled by the mechanism to avoid misplaced or missing values on other sides. In this aspect, flatbuffers has more flexible schema definitions than protocol buffers supporting for example union of types. Moreover, the solid and continuous support of Google in both protocol buffers and flatbuffers and the open-source community incorporating the developments into implementations targeting constrained devices, these two factors strengthen their profile and candidature as potential standardized CHAPTER 8. CONCLUSIONS 65

IoT data format mechanisms. However, beside the official Google documentation, protobuf and flatbuf have smaller communities compared to JSON and XML (e.g. StackOverflow shows few hundred questions tagged with flatbuffers, few thousands tagged with protocol buffers, while it shows more than five hundred thousand posts tagged with JSON) this is expected as these formats are relatively new and still to be exploited and unlocked in terms of applicable scenarios. MessagePack and BSON have significantly smaller library overhead (8KB and 14KB respectively). Additionally, being schema less also gives higher flexibility when implementing in an end- to-end application. However, these advantages of lighter weight and better flexibility represent a tradeoff with considerably larger payload size. Consequently, due to being schema-less, extra atten- tion is required to field names when encoding and decoding given their string nature that makes them character and case sensitive. It has been also concluded that the payload type plays a role in the performance of each protocol. Specifically, despite having only two fields in the String-only payload, the serialization/deserialization speed readings are relatively comparable with the other payloads that include even more data fields, this could be due to the large string values utilized or due to strings data taking longer to encode and decode than other numeric data. However, as discussed in the protocols’ implementations, string variables are more complex to handle and require special functions to be encoded and decoded in protobuf and flatbuf, which in turn emphasizes the drawback of using these techniques in encoding large strings. If strings are heavily utilized due to the application requirements representing the majority of the node payload data, then the MessagePack library CWPack should be utilized as it shows significantly faster string serialization and deserialization with the lowest power consumption. However, it’s observed that all protocols require more time to serialize string values compared numeric values, this combined with the fact that string values result in larger encoded payloads due to additional bytes encoded to indicate string length, and the several benchmarks that show how a character-heavy data format such as JSON and XML fall behind a numeric binary-based formats like protobuf and flatbuf, all these factors strengthen that numeric-based data are much more efficient in IoT context and specifically in sensor nodes application where numbers constitute the majority of the payload data. Consequently, schema-based mechanisms become a better fit as they do not require fields’ names to be encoded into the payload as additional strings. It’s also important to distinguish between the different implementations utilized for each protocol, and how each implementation might have an impact on the experiments results. The protobuf library nanopb is implemented based on the same logic and source code of protocol buffers but adapted to embedded systems environments running on C language. Due to the lack of C support in official protocol buffers Google implementation, there exist several other open source protobuf third party C libraries [59] that could have generated different results. However, nanopb was chosen because its more lightweight with the drawback that it doesn’t store message and field names in the code and therefore doesn’t support introspection. For flatbuffers, the official C++ library was implemented CHAPTER 8. CONCLUSIONS 66

so there’s no implementation-based threats to the validity of the obtained results. For MessagePack, the hardware platform utilized a simple implementation rather than a library and therefore the experiments could imply a less reliable results if compared with MessagePack libraries. This issue has been however overcome by utilizing a MessagePack C library in the simulation platform that showed the advantage that MessagePack possesses being the fastest in both serialization and deserialization. For BSON implementation, both the hardware and the simulation relied on BSON libraries despite the existence of different implementations. This could also suggest possible variations in results if the experiments were to run on the alternative libraries or implementations. However, we strongly believe that due to the logic and development reasons anchored in the characteristics of each protocol, the variations that could result from replicating the experiments in different environments or by using different implementations would not impact the overall evaluation of the selected protocols. From a qualitative point of view, and between the two schema-based protocols, protobuf shows an overall more adequate and resource-efficient performance in handling typical sensor node payloads supported by a more interactive community. Between the two schema-less protocols, MessagePack has more potentiality to be applied in IoT context as its implementations are more directed towards embedded systems and low-level platforms, while BSON development is mainly driven by MongoDB requirements.

8.3 Future Work

There are several ways that this thesis results could be leveraged and expanded. Firstly, the evaluation can include additional binary-based data serialization mechanisms such as Concise Binary Ob- ject Representation CBOR1 which is standardized by the Internet Engineering Task Force IETF and designed to have small code size and small message size with encryption and schema support through an special interface data definition language, all makes it a potential candidate to be compared to Protocol Buffers and FlatBuffers. Another example to include in sensor nodes data serialization is the XML binary extension Efficient XML Interchange EXI2 which is also standardized by ETSI for M2M communication and showed an interesting superior performance to JSON and standard XML in the research paper discussed in Chapter 3 [43]. Additionally, other JSON-based binary encoding mechanisms such as Smile 3 and UBJSON4 that both support C libraries could also be potential candidates to be evaluated in future work in order to have a wider scope of possible binary formats applicable in an IoT system. Another target future work is to evaluate protocol buffers and BSON impact in an end-to-end IoT system across three main industry standard application layer protocols that already prioritize less complex and small-size overheads MQTT, MQTT-SN, AMQP, and

1https://cbor.io/spec.html 2https://www.w3.org/XML/EXI/ 3https://github.com/FasterXML/smile-format-speciﬁcation 4http://ubjson.org/ CHAPTER 8. CONCLUSIONS 67

CoAP. This would carry valuable outcome as these protocols were designed to be lightweight and power-eﬃcient with minimal overhead hence when combined with eﬃcient data formats could bring optimal full-stack IoT settings. Additionally, alternative OS-based IoT platforms can be utilized such as Contiki NG, TinyOS, RIoT, among others. Bibliography

[1] Thomas Wickman. Evaluation of communication protocols between vehicle and server: Evalu- ation of data transmission overhead by communication protocols. Master’s thesis, KTH, 2016.

[2] N. Naik. Choice of eﬀective messaging protocols for iot systems: Mqtt, coap, amqp and http. In 2017 IEEE International Systems Engineering Symposium (ISSE), pages 1–7, Oct 2017. doi: 10.1109/SysEng.2017.8088251.

[3] Sai Mahesh Reddy.L Vamsi Krishna.A Bhagyasree.B Anusha.M, Suresh Babu.E. Performance analysis of data protocols of internet of things: A qualitative review. International Journal of Pure and Applied Mathematics, 115(6):37–47, 2017.

[4] D. Thangavel, X. Ma, A. Valera, H. Tan, and C. K. Tan. Performance evaluation of mqtt and coap via a common middleware. In 2014 IEEE Ninth International Conference on Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), pages 1–6, April 2014. doi: 10.1109/ISSNIP.2014.6827678.

[5] Jonas Olsson. 6lowpan demystiﬁedj. Technical report, Texas Instruments, 2014.

[6] J. Pope and R. Simon. The impact of packet fragmentation on internet-of-things enabled systems. In Proceedings of the ITI 2013 35th International Conference on Information Technology Interfaces, pages 13–18, June 2013. doi: 10.2498/iti.2013.0588.

[7] M. Aly, F. Khomh, Y. Gu´eh´eneuc,H. Washizaki, and S. Yacout. Is fragmentation a threat to the success of the internet of things? IEEE Internet of Things Journal, 6(1):472–487, Feb 2019. ISSN 2372-2541. doi: 10.1109/JIOT.2018.2863180.

[8] V. P. Kaﬂe, Y. Fukushima, and H. Harai. Internet of things standardization in itu and prospec- tive networking technologies. IEEE Communications Magazine, 54(9):43–49, Sep. 2016. ISSN 1558-1896. doi: 10.1109/MCOM.2016.7565271.

[9] European Telecommunications Standards Institute. Industry trends for m2m/iot survey results. In ETSI M2M WORKSHOP, 2014.

68 BIBLIOGRAPHY 69

[10] V. Gazis. A survey of standards for machine-to-machine and the internet of things. IEEE Communications Surveys Tutorials, 19(1):482–511, Firstquarter 2017. ISSN 2373-745X. doi: 10.1109/COMST.2016.2592948.

[11] Raj Jain Tara Salman. A survey of protocols and standards for internet of things. arXiv, 2017.

[12] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash. Internet of things: A survey on enabling technologies, protocols, and applications. IEEE Communications Surveys Tutorials, 17(4):2347–2376, Fourthquarter 2015. ISSN 2373-745X. doi: 10.1109/COMST.2015. 2444095.

[13] McKinsey Global Institue. The internet of things: Mapping the value beyond the hype. Tech- nical report, McKinsey&Company, 2015.

[14] Ted Friedman Sanjit Ganguli. Iot technology disruptions: A gartner trendinsight report. Tech- nical report, Gartner, jun 2017.

[15] Cisco. Internet of thing at a glance. Technical report, Cisco, 2016.

[16] E. Callaway, P. Gorday, L. Hester, J. A. Gutierrez, M. Naeve, B. Heile, and V. Bahl. Home networking with ieee 802.15.4: a developing standard for low-rate wireless personal area networks. IEEE Communications Magazine, 40(8):70–77, Aug 2002. ISSN 1558-1896. doi: 10.1109/MCOM.2002.1024418.

[17] Muthu Chellappa, Shanmugaraj Madasamy, and R. Prabakaran. Study on zigbee technology. pages 297–301, 04 2011. ISBN 978-1-4244-8678-6. doi: 10.1109/ICECTECH.2011.5942102.

[18] ERICSSON. Cellular networks for massive iot. Technical report, ERICSSON White Paper, 2016.

[19] 802.11ah standard, .

[20] 802.11ax standard, .

[21] 802.11 standard, 2016.

[22] Zeeshan Abbas and Wonyong Yoon. A survey on energy conserving mechanisms for the internet of things: Wireless networking aspects. In Sensors, 2015.

[23] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melia-Segui, and T. Watteyne. Understanding the limits of lorawan. IEEE Communications Magazine, 55(9):34–40, Sep. 2017. ISSN 1558-1896. doi: 10.1109/MCOM.2017.1600613. BIBLIOGRAPHY 70

[24] Seppo Leminen, Mika Westerlund, Mervi Rajahonka, and Riikka Siuruainen. Towards iot ecosystems and business models. In Sergey Andreev, Sergey Balandin, and Yevgeni Kouch- eryavy, editors, Internet of Things, Smart Spaces, and Next Generation Networking, pages 15–26, Berlin, Heidelberg, 2012. Springer Berlin Heidelberg. ISBN 978-3-642-32686-8.

[25] Daniel Happ, Niels Karowski, Thomas Menzel, Vlado Handziski, and Adam Wolisz. Meeting iot platform requirements with open pub/sub solutions. Annals of Telecommunications, 72, 07 2016. doi: 10.1007/s12243-016-0537-4.

[26] Partha Pratim Ray. A survey of iot cloud platforms. Future Computing and Informatics Journal, 1(1):35 – 46, 2016. ISSN 2314-7288. doi: https://doi.org/10.1016/j.fcij.2017.02.001. URL http://www.sciencedirect.com/science/article/pii/S2314728816300149.

[27] Peter Friess Ovidiu Vermesan. Internet of Things From Research and Innovation to Market. River Publishers, 2014.

[28] Hong Linh Truong Andy Stanford-Clark. Mqtt for sensor networks (mqtt-sn)protocol speciﬁ- cation. Technical report, IBM, 2013.

[29] OASIS Standard. Oasis advanced message queuing protocol(amqp) version 1.0. Technical report, OASIS, 2012.

[30] Carlos Pereira and Ana Aguiar. Towards eﬃcient mobile m2m communications: Survey and open challenges. Sensors (Basel, Switzerland), 14:19582–19608, 10 2014. doi: 10.3390/ s141019582.

[31] K. Thoelen, W. Joosen, and D. Hughes. Putting sense inside sensor systems: A coordinated approach to messaging. In 2015 IEEE 14th International Symposium on Network Computing and Applications, pages 22–26, Sep. 2015. doi: 10.1109/NCA.2015.20.

[32] P. Wehner, C. Piberger, and D. G¨ohringer. Using json to manage communication between services in the internet of things. In 2014 9th International Symposium on Reconﬁgurable and Communication-Centric Systems-on-Chip (ReCoSoC), pages 1–4, May 2014. doi: 10.1109/ ReCoSoC.2014.6861361.

[33] Tim Bray, Jean Paoli, C Michael Sperberg-McQueen, Eve Maler, and Franois Yergeau. Exten- sible markup language (xml) 1.0, 2000.

[34] Nurzhan Nurseitov, Michael Paulson, Randall Reynolds, and Clemente Izurieta. Comparison of json and xml data interchange formats: A case study. In CAINE, 2009.

[35] Google Developers. Protocol buﬀers. URL https://developers.google.com/ protocol-buffers/docs/overview. BIBLIOGRAPHY 71

[36] Eishay Smith. Jvm serializers, 2016. URL https://github.com/eishay/ jvm-serializers/wiki.

[37] Bruno Krebs. Beating json performance with protobuf, 2017. URL https://auth0.com/ blog/beating-json-performance-with-protobuf/.

[38] N. Naik and P. Jenkins. Web protocols and challenges of web latency in the web of things. In 2016 Eighth International Conference on Ubiquitous and Future Networks (ICUFN), pages 845–850, July 2016. doi: 10.1109/ICUFN.2016.7537156.

[39] Burak H. Corak, Feyza Yildirim Okay, Metehan Guzel, Sahin Murt, and Suat Ozdemir.¨ Com- parative analysis of iot communication protocols. 2018 International Symposium on Networks, Computers and Communications (ISNCC), pages 1–6, 2018.

[40] Yaquang Chen. Performance f message queue telemetry transport protocol and constrained application protocol in wireless sensor networks. Master’s thesis, The University of Mississipp, may 2017.

[41] McKinsey&Company. The road to 2020 and beyond: What’s driving the global automotive industry? Technical report, McKinsey&Company, aug 2013.

[42] Audie Sumaray and S. Kami Makki. A comparison of data serialization formats for optimal eﬃciency on a mobile platform. In Proceedings of the 6th International Conference on Ubiquitous Information Management and Communication, ICUIMC ’12, pages 48:1–48:6, New York, NY, USA, 2012. ACM. ISBN 978-1-4503-1172-4. doi: 10.1145/2184751.2184810. URL http: //doi.acm.org/10.1145/2184751.2184810.

[43] Francesca Pacini, Femi Aderohunmu, Andrea Azzar`a,Stefano Bocchino, Paolo Pagano, and Matteo Petracca. Performance analysis of data serialization formats in m2m wireless sensor networks. 02 2015.

[44] Etsi ts 102 690 v2.1.1 (2013-10) machine-to-machine communications (m2m). URL https://www.etsi.org/deliver/etsi_ts/102600_102699/102690/02.01. 01_60/ts_102690v020101p.pdf.

[45] ETSI TS 103 104 V1.1.1. Machine-to-machine communications (m2m);interoperability test speciﬁcation for coap binding of etsi m2m primitives. Technical report, European Telecommu- nications Standards, 2013.

[46] S. Popić,D. Pezer, B. Mrazovac, and N. Teslić.Performance evaluation of using protocol buffers in the internet of things communication. In 2016 International Conference on Smart Systems and Technologies (SST), pages 261–265, Oct 2016. doi: 10.1109/SST.2016.7765670. BIBLIOGRAPHY 72

[47] S. Denis Infanteena and E. A. M. Anita. Survey on compressive data collection techniques for wireless sensor networks. In 2017 International Conference on Information Communication and Embedded Systems (ICICES), pages 1–4, Feb 2017. doi: 10.1109/ICICES.2017.8070765.

[48] Cyril Cecchinel, Fran¸coisFouquet, SébastienMosser, and Philippe Collet. Leveraging live machine learning and deep sleep to support a self-adaptive efficient configuration of battery powered sensors. Future Generation Computer Systems, 92:225 – 240, 2019. ISSN 0167-739X. doi: https://doi.org/10.1016/j.future.2018.09.053. URL http://www.sciencedirect. com/science/article/pii/S0167739X18305740.

[49] World Wide Web Consortium. Eﬃcient extensible interchange working group. URL https: //www.w3.org/XML/EXI/.

[50] World Wide Web Consortium. Web of things community group, 2015. URL https://www. w3.org/community/wot/.

[51] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a lightweight and ﬂexible operating system for tiny networked sensors. In First IEEE Workshop on Embedded Networked Sensors, Tampa, Florida, USA, pages 1–4, Feb 2004.

[52] Craig Thomson, Imed Romdhani, Ahmed Al-Dubai, Mamoun Qasem, Baraq Ghaleb, and Isam Wadhaj. Cooja simulator manual, 07 2016.

[53] URL https://github.com/aignacio/mqtt-sn-contiki_example.

[54] Application ﬂash and ram size[online]. URL http://support.code-red-tech.com/ CodeRedWiki/FlashRamSize. (access date: 8/9/2019).

[55] Contiki os: Using powertrace to estimate power consumption. URL [Online].Available:http://thingschat.blogspot.com/2015/04/ contiki-os-using-powertrace-and.html. (access date: 3/9/2019).

[56] Zolertia z1 datasheet. URL http://zolertia.sourceforge.net/wiki/images/e/e8/ Z1_RevC_Datasheet.pdf.

[57] URL https://github.com/msgpack/msgpack/blob/master/spec.md.

[58] Ali Alavi. binson: A minimum bson implementation for embedded systems. URL https: //github.com/alialavia/binson.

[59] Third-party add-ons for protocol buﬀers. URL https://github.com/protocolbuffers/ protobuf/blob/master/docs/third_party.md.