Executive Summary

With substantial advances in hardware and networking technologies, the vision of Internet-of-Things (IoT) and emerging related paradigms, such as the Industrial Internet (II), is fast becoming a reality. At the core of IoT/II is a massive-scale Machine-to-Machine (M2M) communication paradigm involving billions of fixed and mobile objects equipped with sensors that emit data continuously at different spatial and temporal scales. IoT/II combined with traditional cloud resources can be used to create what we call an IoT Cloud, which is a loose federation of a group of heterogeneous resources including computation/storage resources provided potentially by different traditional cloud providers all coming together to serve a purpose. Realizing the IoT Cloud vision will require the resolution of a broad range of challenges. These challenges can be viewed along three different dimensions: software engineering, distributed systems and challenges introduced due to the complex spatio-temporal dimension of the problem space.

IoT gives rise to a large distributed system. Since all the sensors/devices will be part of it, there needs to be some form of low-level network connecting them. Sensors are spatially distributed and it is possible that different sensors operate at different time scales. Each such device requires unique addressing and they need to advertise the services that they provide. Assuming that there is already a network of connected devices and each device advertises their services, local servers need to discover the right services at the right time, and connect to them. Thus, there is the need to orchestrate the services provided by various devices along with processing the algorithms in the back-end servers to form an application. Once connected, they also need to control the devices and regulate or fine-tune the device behavior. Reliability and security will be key considerations.

Our project is called CLARINET (CLoud ARchitectural Innovations for InterNEt of Things), which  addresses these new set of distributed systems challenges by anchoring the challenges as a cloud computing problem, however, that requires radical transformations to contemporary cloud computing platforms that will result in new and reusable architectural and integration patterns for IoT Cloud Computing. Our ideas call for a blurring of the traditional separation of roles between the cloud user and provider as they exist today; instead giving rise to what we call IoT Cloud Peers and algorithms for opportunistic but systematic management of resources and dynamic orchestration of services over the selected resources.

 

Emergence of Internet-of-Things (IoT)

The RFID revolution gave rise to a new distributed systems paradigm called the Internet-of-Things (IoT), which is characterized by the ultra large-scale connectivity among every conceivable object – living (e.g., humans) and non-living (e.g., machines) – that are involved in exchanging and processing valuable information to help solve a multitude of problems of grave societal import that the world faces today. These include problems in the domain of health care, energy, disaster management, and global warming. Additional technologies that are related to IoT, such as Industrial Internet, which also involves M2M communications, exist. We consider all of these related technologies as IoT.

IoT envisions a shift away from traditional stovepiped vertical silos of systems, which focus inwardly within an individual application domain, to a world where significant horizontal interaction among domains will be the norm. It assumes that a large number of objects – stationary and mobile – is fitted with sensors that will emit data, which can then be used to solve one or more problems of interest. The connected devices will comprise a continuum of machines ranging from low-cost/low-performance to high-cost/high- performance. Since the number of connected objects will be orders of magnitude larger than the number of computers and mobile devices that are connected today to the Internet, it is expected that the amount of data generated will be of a scale unimaginable by today’s standards. Data will be both structured and unstructured. It will be required to be transmitted reliably, securely and scalably in real-time between data sources and sinks without overwhelming available communication resources.

Different kinds of applications will benefit from such a network of things embedded within the human society. For example, weather monitoring applications can take advantage of localized low-level climate sensing, traffic applications will leverage localized traffic data. Both regular day-to-day applications and applications deployed in emergency situations, such as hurricane monitoring or wildfire detection can benefit from an IoT. In case of an emergency event, distributed applications can be setup on-the-go by composing services provided by several “things”/sensors along with back-end servers which process the data and disseminate alert information.

 

CLARINET Project

Our project is called CLARINET (CLoud ARchitectural Innovations for InterNEt of Things), which realizes these new set of distributed systems by anchoring their solutions in the patterns and principles of cloud computing, however, in this case the traditional concept of cloud computing and separation of roles between a cloud user and provider are no longer always applicable. Instead we require radical transformations to contemporary cloud computing architectures resulting in new and reusable architectural and integration patterns for IoT Cloud Computing. Our architecture comprises IoT Cloud Peers and algorithms for opportunistic but systematic management of resources and dynamic orchestration of services over the selected resources.

The proposed CLARINET architecture supports a P2P runtime platform for IoT Cloud where some peers may possess specialized capabilities while others may provide generic services as in traditional cloud computing. For example, in an intelligent transportation system comprising autonomous vehicles, individual vehicles may serve as nodes in an ad-hoc network that make specialized decisions, such as maintaining safe inter-vehicle distance and avoiding collisions, while an actual data center may receive traffic data from the vehicles, and make more global-scale traffic management decisions feeding the decisions back to the vehicles. Depending on the urgency and resource availability, it may be necessary for the cluster of vehicles to serve as an ad hoc data center and make localized decisions, such as weather alerting about tornadoes or washed away roads due to incessant rain.

To enable an extensible architecture that supports a P2P model where peers can opportunistically join and leave, we require a component-based approach so that the desired application functionality can be composed dynamically out of basic building blocks and deployed according to resource availabilities and mission requirements. As long as the building blocks support the expected interfaces, their implementations can be supplied by any third party. A component-based architecture also lends itself to ease of migration since functionality can simply be disassembled at runtime in one location, and composed and deployed in another location.

Figure 1 illustrates the cloud provided P2P model showing a symbiotic relationship between the cloud peers where the tasks are executed opportunistically in a decentralized manner. The figure also shows the asymmetric nature of the cloud provider peers. The right side of Figure 1 shows a traditional cloud provider that provides general-purpose services to IoT applications and provides the necessary resource management and optimization algorithms prevalent in traditional data centers. The left hand side of the figure shows computational and resource management architecture intended to perform specialized operations. These peers seamlessly interact with each other. Moreover, the component-based realization of these platform-level capabilities at both the peers makes it easier for functionality to migrate between the peers, if needed.

Figure 1: CLARINET P2P Cloud Architecture for IoT

3.   

Key Technical Requirements to Realize CLARINET

From our experience with prior projects, we believe that adopting a cloud computing approach for IoT will require radical transformations to existing cloud computing architectures and platforms to address a range of requirements described below, which forms the basis for the research proposed in this project.

·        

Requirement 1: Dynamic Service Discovery and Orchestration – In our envisioned IoT solution, first, we must understand that no system will be permanently deployed and operational because they must be activated only on demand; at all other times their resources must be conserved. Thus, the entire system is formed through a dynamic orchestration of individual services across multiple subsystems as the need arises. The existence of multiple cloud peers having to discover each other, and subsequently interact and interoperate deviates from the standard model of a cloud user and a single cloud provider. This new requirement calls for a peer-to-peer (P2P) model of dynamically discoverable cloud providers that can be composed to dynamically form an end-to-end system. Since each cloud provider provides specific and unique capabilities, the peer- to-peer model is made up of asymmetric peers, i.e., heterogeneous peers. What this entails is that when composing larger systems out of building blocks, there is a need for the components to be discoverable, and supporting open interfaces and standard protocols.

·        

Requirement 2: Dynamic Resource Management – In our solution there is no central authority in the system because subsystems belong to different cloud provider peers. The decisions are decentralized in that the resources needed to make the overall system perform its mission must be dynamically discovered and allocated across the different cloud provider peers. It also requires autoscaling of resources depending on workload demands and fluctuations due to failures. Furthermore, since the range of resources and their capabilities can differ significantly, traditional resource management techniques or “one-size-fits-all” approaches may not be applicable. The problem is further complicated by the fact that the resources are spatially separated and may operate at different time scales. Thus, dynamic resource management will require a distributed snapshot of available resources and their capabilities, and a consensus on resource allocations among the orchestrated subsystems belonging to the cloud provider peers.

·        

Requirement 3: Ensuring Highly Available Systems with Predictable Performance – The decentralized and highly uncertain operating environment can result in multiple uncorrelated failures (both transient and permanent). However, in mission-critical systems, it is imperative for the system to ensure high availability and reliability while also ensuring that end-to-end performance criteria, such as timeliness, are satisfied. Therefore, it is essential for the system to be cognizant of redundant mechanisms so that every effort is made to ensure reliable and timely delivery of information. It is possible that some of these redundant mechanisms may be discovered dynamically and it is important to incorporate these capabilities in the system. This requirement implies that it is possible for a cloud provider peer to participate in multiple concurrent P2P-based service orchestrations. Thus, every peer must manage its resources internally in a way that ensures performance isolation among multiple concurrent service orchestrations.

·        

Requirement 4: Security and Trust – Security and trust are vital in these situations. Since multiple cloud provider peers will have to interact dynamically, the issue of trust and security is paramount. How should a cloud provider peer trust another peer? How much information should one peer divulge to another peer? These questions are important for a variety of reasons, such as when it comes to finding the available resources at the other peer, capabilities of the peer, and redundant paths. A capability that can support dynamically allocated multiple security labels and secure transport is a promising technique to address these requirements.