ABSTRACT:
The Internet of Things (IoT) represents a new class of applications that can benefit from cloud infrastructure. However, the current approach of directly connecting smart devices to the cloud has a number of disadvantages and is unlikely to keep up with either the growing speed of the IoT or the diverse needs of IoT applications.
In this paper we explore these disadvantages and argue that fundamental properties of the IoT prevent the current approach from scaling. What is missing is a well architected system that extends thefunctionality of the cloud and provides seamless interplay among the heterogeneous components in the IoT space.
We argue that raising the level of abstraction to a data-centric design focused around the distribution, preservation and protection of information provides a much better match to the IoT. We present early work on such a distributed platform, called the Global Data Plane (GDP), and discuss how it addresses the problems with the cloud-centric architecture.
BACKGROUND
In this section, we review the state of the art in the distributed application space for IoT. The cloud has become the de facto foundation around which distributed applications are constructed a trend that, while understandable,is not the best long-term approach.
Massive Adoption of Cloud Platforms:
Over the last few years, cloud computing has shaped the software industry and made the development and deployment of web services easier than ever. Public cloud providers such as Amazon, Microsoft, Google, Rackspace offer pay-as-you-go services for the general public. Such a service model has reduced capital expenses, enabled elasticity for dynamic load adaption, and simplified resource management.
Embedded Platforms:
At the same time, we have seen a dizzying array of embedded platforms, from powerful computing units to low-power micro controllers.
The World of IOT Includes a Wide Spectrum of Computing platforms.
IOT Application Status Quo:
Many of today’s IoT solutions arise by connecting embedded platforms to the cloud. For example, Bolt provides data management for the Lab of Things (LoT) and uses Amazon S3 or Azure for data storage. Such direct connections often require an application-level gate-way to support low-power radios such as Z-Wave or Bluetooth Low Energy (BLE).
PITFALLS WITH TODAY’S APPROACH TO IOT
In this section, we argue why the current approach of connecting IoT devices directly to the cloud is incompatible with the evolving world of IoT applications. This incompatibility arises from the fundamental nature of IoT applications.
Although Applications Usually View the Cloud as the Center of all Connected Devices ( Upper diagram ), in Reality the Cloud is usually on the Edge of the Internet Backbone, just like other devices (lower diagram).
A DATA-CENTRIC PROPOSAL
The Global Data Plane (GDP) is a data-centric abstraction focused around the distribution, preservation, and protection of information. It supports the same application model as the cloud, while better matching the needs and characteristics of the IoT by utilizing heterogeneous computing platforms, such as small gateway devices, moderately powerful nodes in the environment and the cloud, in a distributed manner.
Single-writer time-series logs:
For each IoT device or application component that generates data, this data is represented as a log where the owner has the sole write permission. This model is based on our observation that peripherals are physical devices in our environment. We assume that devices have cryptographic keys for signing and encryption. 4 Logs are append-only; most data is read only and can be securely replicated and validated through cryptographic hashes.
The Global Data Plane (GDP) Operates Above the Network Level and Offers Common Access APIs (CAAPIs) to Applications Rather than Raw Packet Routing.
Location-independent Routing:
Logs must be physically stored in the infrastructure. As previously discussed, the current reliance of IoT on cloud storage provides few guarantees about the placement, latency of access, or durability of information. Instead, to embrace heterogeneous platforms and support a variety of storage policies, the GDP employs location-independent routing in a large, 256-bit address space.
Pub/Sub and multicast tree:
The publish/subscribe pattern has been shown to support a wide variety of fundamental communication services (for mobility, multicast, anycast). This fits nicely with our log abstraction and can support building interactive applications. To alleviate the growth of sensor data bandwidth, when multiple subscribers exist, multicast trees can be built on top of the overlay network using techniques proposed earlier, so that effective bandwidth is reduced.
Common Access API (CAAPI):
Although the single writer log abstraction shelters developers from low-level machine and communication primitives, many applications are likely to need more common APIs or data structures. In fact, logs are sufficient to implement any convenient, mutable data storage repository.
The GDP Design Illustrated: (a) Single-Writer Logs are Appended to the Head and Compositions are Achieved by subscription; (b) Logs are Split into Chunks and Stored in a Distributed Fashion; (c) Overlay Multicast Trees are Constructed when there are Multiple Subscribers; (d) Location-independent Routing Enables Log Migration for Optimizing Performance.
Source: University of California
Authors: Ben Zhang | Nitesh Mor | John Kolb | Douglas S. Chan | Nikhil Goyal | Ken Lutz | Eric Allman | John Wawrzynek | Edward Lee | John Kubiatowicz
>> 200+ IoT Led Projects for Final Year Students
>> IoT Software Projects for Engineering Students