User Tools

Site Tools


Network and Service Architecture

Our work on the federation of Clouds is described in Research on Cloud Federation.

Realising community cloud involves a lot of challenges both in technological and socio-economic context, but also promises interesting value proposition for communities in terms of local services and applications. We focus here on a distributed architecture for community clouds, which integrates into the cloud the computation and storage hardware contributed by the community network members to the community network, but also the socio-economic contribution these community network members donate to the collective effort in the form of knowledge, time and help.

A community network is managed and owned by the community, where nodes are managed independently by their owners. The capacity, availability and connectivity vary widely among the nodes. Nodes that form the backbone however, i.e. supernodes (SNs), are usually intended to be stable with permanent connectivity. Ordinary nodes(ONs) do more frequently change their connectivity status. An architecture for the community cloud system that manages such infrastructure needs to be robust, self-managing and efficient at handling the heterogeneity among the nodes.

The option for enabling a community cloud on which we focus here is to deploy a cloud management platform tailored to community networks on the nodes attached to the network. There are a few cloud management systems available to manage public and private clouds, for example OpenNebula, OpenStack, CloudStack, Synnefo, Eucalyptus, etc. Such cloud management systems can be tailored for community networks by extending the existing functionality to address the particular conditions of community networks. For example, incentive mechanisms inspired by the social nature of community networks can be built into resource regulation component to encourage users to contribute resources [Khan2014a].

Overview of different layers of the community cloud management system

The architecture for the cloud management system that we propose for community networks is shown below. The nodes along with the communication infrastructure of the community network form the the hardware layer of the cloud architecture. The core layer residing in the SN contains the software for managing and monitoring the virtual machines (VMs) on ONs. The front end layer provides the interface of the infrastructure service (Infrastructure-as-a-Service, IaaS). The components cloud coordinator, economic engine and social engine provide additional services for customizing cloud infrastructure to the community networks.

Architecture of the community cloud management system

Hardware Layer

This consists of the physical infrastructure that is needed to run a cloud system. The hardware in the community networks mostly consists of ONs and SNs and the wireless links provided by the mesh network, along with any attached computation, storage and other resources.

Core Layer

The core layer consists of components that are responsible for creation, allocation, scheduling, monitoring and management of VMs on the nodes. This can include the following main components.

  • Virtual Machines Controller
  • Virtual Machines Scheduler
  • Virtual Machines Monitor
  • Hosts Manager
  • Virtual Network Manager
  • Virtual Machines Image Data Store

The functionality of the core layer is already provided by tools like OpenStack and others. As a result, the Community cloud manager can, therefore, make use of these existing tools and extend their functionality to suit the needs of the community network.

Cloud Coordinator

The cloud coordinator is responsible for the federation of the cloud resources which are independently managed by different SNs. It provides the interface for other components like economic engine and social engine to request information from other SNs. The cloud coordinator components in different SNs connect among themselves in a decentralised manner to exchange relevant information about managing the available resources. By default applications running at a local cloud can only consume resources from the ONs directly managed by the local SN. With the cloud coordinator, the infrastructure service can provide a unified view of the resources contributed by multiple local clouds. When federating multiple local clouds, the cloud coordinator applies a peering regulation mechanism [Khan2014a] fed by the economic engine and social engine to perform resource allocation.

Economic Engine

The role of economic engine is to manage the accounting and auditing for the infrastructure service so that the access can be regulated to the users of the community cloud. In contrast to public clouds, the main incentive for the providers in community clouds is the utility that they will get from the system by consuming its services and applications. The economic engine manages a system of virtual credits that encourages the users to contribute resources to the cloud.

Social Engine

The community cloud is as much a social construct as it is a technical construct. The existence of the community cloud is not possible if there is a lack of participation from the community. Running a community cloud not only requires supply of technical resources like storage and network bandwidth, but also the time and effort of the users who setup and manage the network equipment. Whereas the economic engine takes care of the incentives in the virtual world, the social engine is the component that encourages contribution in the physical world. We discuss here some of the modules that help to achieve this goal. These modules may not be integral to the cloud management platform from a technical point of view, but nevertheless provide functionality necessary for the smooth running of the community cloud.

Frontend Layer

The frontend layer provides the interface to interact with the infrastructure service of the community cloud. This includes modules like command line interface (CLI), graphical user interface (GUI), application programming interface (API), and any other tools that assist with developing cloud application using the infrastructure service.

Components in services architecture

Distributed Architecture in Socio-Economic Context

We have explored the macroeconomic mechanisms [Khan2014c] that can help in adoption and growth of community cloud model. The purpose of economic mechanisms and social and psychological incentives is to let the community cloud transition from inception through early adoption to finally ubiquitous usage The proposed architecture needs to take advantage of socio-economic context of community networks to ensure the success of community cloud model. Such mechanisms must take into account the costs and benefits involved in participating in community cloud. For instance, the initial costs for setting up nodes in the community cloud involve hardware costs including the price of the computing and networking equipment, and installation costs including the manual labour needed. Besides these costs at the individual level, there are also the transaction costs or management overheads to direct the group coordination and collaborative production efforts necessary for the operation of community cloud. The individuals in community cloud act as private enterprises where they offer services to generate revenue. The revenue for the community cloud users include tangible benefits like the services and applications that they will be able to consume, and intangible benefits like the sense of belonging to the community and personal satisfaction because of their contributions. The services can range from infrastructure to platform to software services meeting a spectrum of different needs of the users.

Different policies addressing relevant issues of the technical, social, economic and legal aspects of the community cloud are designed to encourage collaboration, for example commons license and peering agreements can be implemented that extend the idea of reciprocal sharing from Wireless Commons License and Pico Peering Agreement in community networks. The social context of community networks provides opportunity to harness social capital and the different roles of social relationships. Similarly, lowering transaction costs and entry barriers, facilitating participation of developers, exploring different service models to provide value addition and differentiation, and taking advantage of locality and overlay topology of the network can prove useful. Such mechanisms help adapt the ecosystem of community cloud infrastructure and services to the aspirations of the community network members.

Evaluating Scalability of Distributed Architecture

We evaluate here the scalability issues for a community cloud-based infrastructure service [Khan2013a]. The scenarios of community cloud help in obtaining through simulations a preliminary characterization of the behaviour of an infrastructure service in community clouds. It is observed that for community clouds the distribution and capability of resources, which are less powerful than those in commercial centralized clouds, will impact the response time and the resource assignment. Network-aware cloud services, however, seem to have some potential to improve the performance of infrastructure service by reducing its dependency on the conditions of community network. Achieving a reasonable quality of user experience with community clouds will be needed to sufficiently motivate the members of community network to extend the current collective management at the network level to that of cloud services. Once this level of technical performance is assured, community clouds may outperform commercial clouds in their social aspects by offering open and neutral cloud services provided from within the community network. With such simulations we expect to obtain a better understanding of the potential and the design of network-aware infrastructure services for community clouds.

For our simulation experiments, we have used CloudSim simulation toolkit which supports analysing the behaviour of cloud computing environments under various experimental conditions. CloudSim is an event-based simulator that models cloud infrastructures as data centres characterized by the number of physical nodes and the scheduling policy for assigning users' requests to the nodes. The nodes in CloudSim are defined by their processing capacity given in millions of instructions per second (MIPS), memory, storage, bandwidth, the number of VMs and the policy for distributing resources among VMs. The requests from users are termed as cloudlets in CloudSim and dynamic behaviour of applications with respect to resource requirements can be programmed by extending the code for cloudlets. Both VMs and cloudlets have attributes like processing capacity, memory, storage and bandwidth and these attributes are used by the broker process which manages the instantiation and allocation of VMs to map cloudlets to VMs. CloudSim also supports federated cloud architectures by providing a cloud coordinator entity which distributes the users' requests among multiple data centres.

We have modelled commercial centralized clouds as a single data centre and community clouds as a cloud coordinator with multiple data centres in CloudSim. SN in a community network is assumed to be the broker in data centre while ONs in a community network are the nodes hosting VMs. Our goal is to analyse the behaviour of community clouds and compare its profile with commercial clouds and in our preliminary experiments, we have focused on the resource utilization in terms of processing capacity (CPU), memory (RAM), network bandwidth and the quality of service in terms of average response time for users' requests.

Average response time as number of nodes increases

We consider the average response time in order to analyse the quality of service provided by the infrastructure service. This is the difference between the time when a request is submitted to the system and when a VM is allocated for that request. Figure above shows the average response time across all requests as the number of nodes increases in the system for the three scenarios. We find that for limited number of nodes, centralized cloud provides better service because resources are consolidated at one data centre. However, in the case of federated and decentralized scenarios, resources are distributed between multiple data centres and are not sufficient to meet the requests forwarded to the data centres. However, as the number of nodes increases along with the rise in the volume of requests, the overheads for centralized data centre become significant since the requests remain in the queue relatively longer waiting for resources to become available.


  • [Khan2014a] Amin M Khan, Umit C Buyuksahin, Felix Freitag. Incentive-based Resource Assignment and Regulation for Collaborative Cloud Services in Community Networks. In Journal of Computer and System Sciences (JCSS). 2014.
  • [Khan2014b] Amin M Khan, Mennan Selimi, Felix Freitag. Towards Distributed Architecture for Collaborative Cloud Services in Community Networks. In 6th International Conference on Intelligent Networking and Collaborative Systems (INCoS'14). Salerno, Italy. 2014.

* [Khan2014c] Amin M Khan, Felix Freitag. Sparks in the Fog: Social and Economic Mechanisms as Enablers for Community Network Clouds. In ADCAIJ: Advances in Distributed Computing and Artificial Intelligence Journal, 3(8). Universidad de Salamanca, Spain. 2014. * [Khan2013a] Amin M Khan, Leila Sharifi, Luís Veiga, Leandro Navarro. Clouds of Small Things: Provisioning Infrastructure-as-a-Service from within Community Networks. In 2nd International Workshop on Community Networks and Bottom-up-Broadband (CNBuB ’13), within IEEE WiMob. Lyon, France. 2013. * [Khan2013b] Amin M Khan, Umit C Buyuksahin, Felix Freitag. Distributed Architecture for Cloud System tailored for Wireless Community Networks. Department of Computer Architecture, Universitat Politècnica de Catalunya. Technical Report #UPC-DAC-RR-XCSD-2013-4. Barcelona, Spain. 2013.

network_and_service_architecture/overview.txt · Last modified: 2015/09/25 15:55 by felix