Figure 2.5 A wearable ECG sensor.

      Generally, users prefer smartwatch devices that provide monitoring heart functions while they continue normal physical activities. Due to the limited battery life and storage capacity of the smartwatch, we assume that the data produced by this device is around 1 KB per second and it is stored in the smartphone. Based on this assumption, daily produced data by a wearable device is around 86 MB per day and 2.6 GB monthly. One must note that smartphones have limited battery life and storage capacity. Hence, the smartphone at some point has to transfer the gathered data to another device that provides more storage capacity.

      Referring to Figure 2.5, one can witness that data streaming is realized between the wearable device and the smartphone. Both devices remain connected to each other during the operation time. In case of any critical event, the wearable device interacts with the edge device and notifies the user for any situations. The process (1) start with getting real-time values from a wearable device to the smartphone. The smartphone application checks (2) periodically the wearable device to see if the connection between them is active. In addition, the smartphone may run out of free disk space and one can configure the application for daily synchronization (3) with another storage capability device, or with a central cloud storage or even with a fog node.

      Since the wearable device and the edge device has limited resource capabilities, one must consider the energy consumption of both devices. In such system architecture, the first recommended approach is to decide what data to transmit to the cloud, what to store locally, and the last is to develop better monitoring algorithms. In the other words, when designing such systems, the critical point is to consider the energy consumption, which is affected by three main functions that are realized between devices, such as (1) communication, (2) storage, and (3) processing requirements. Hence, developers have to code software with highly efficient streaming algorithms, storing essential monitoring information, and avoiding continuously data transfers with the central cloud.

      2.4.1.2 Smart Home

      The smart home or smart apartment is an intelligent home network capable of sensing the home's occupants actions, and assisting them by providing appropriate services. In the following scenario, we will describe an example to illustrate a situation under development at the smart home, where an edge device is considered as a mediator between the IoT things deployed in a home environment. The smart home provides resources to the residents that are deployed in rooms. Each room has smart doors, smart windows, sensors (i.e. temperature, humidity, proximity, fire alarm, smoke detector, etc.), radio-frequency identification (RFID) tags, and readers.

The traditional implementation of the presented use case situation requires collecting data to a back-end cloud-based where system stores, processes, and replies to both real-time user queries. The configuration must be done on the cloud server, and each device sends the information to a central server for further processing of the data. Each of the devices contains a unique identification number and a lot of information saved in the cloud. Even if two devices reside near each other, the retrieval of the data must be done through communication with the cloud. A similar implementation of a system for monitoring environmental conditions by using a wireless sensor network (WSN) is given in [26]. However, just adding a WiFi connection to the current network-enabled devices and connecting it to the cloud is not enough for a smart home. In addition, in a smart home environment, besides the connected device, it must support communication with non-IP based resources, cheap wireless sensors, and controllers deployed in rooms, pipes, and even floor and walls.

      Deploying a huge number of things in a smart home environment results in an impressive amount of produced data. One must consider that the data produced has to be transported to the processing units, assuring privacy and providing high availability. Since personal data must be consumed in the home, an architecture based only on the cloud computing paradigm is not suited for a smart home. In contrast, edge computing is perfect for building a smart home where data reside on an edge device running edge operating system (edgeOS). As a result, all deployed edge devices can be connected and managed easily and data can be processed locally by an edge device.

Figure 2.6 shows the structure of a variant of edgeOS in the smart home environment. EdgeOS provides a communication layer that supports multiple communication methods, such as WiFi, Bluetooth, ZigBee, or a cellular network. By using one of the methods, edgeOS collects data from the deployed things and mobile devices. In a smart home, most of the things will send data periodically to the edge device, respectively to the edgeOS. Collected data from different things need to be fused and massaged in the data abstraction layer. It is desirable that human interaction with edge devices is minimized. Hence, the edge device should consume/process all the data and interact with users in a proactive fashion. Additionally, the data abstraction layer will serve as a public interface for all things connected to edge devices where it enables the applicability of operations on the things.

Finally, on top of the data abstraction layer is the service management layer. This layer is responsible to guarantee a reliable system including differentiation (i.e. critical services must have higher priority compared to a normal service), extensibility (i.e. new things can be added dynamically), and isolation (i.e. if something crashes