We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.I2ND.CE - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.I2ND.CE
Chapter I2ND,
Catalogue-Link to Implementation [N/A ]



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Legal Notice

Please check the following FI-WARE Open Specification Legal Notice to understand the rights to use these specifications.


This specification describes the Cloud Edge GE, which is located beside the cloud, acting as the cloud agent in the end consumer home network. The Cloud Edge, because located at the border between the cloud and the home network can be considered from these two view points. The description from the cloud view point is given in the Cloud Hosting chapter. We here focus on the relation between the cloud edge and the home network.

The Cloud Edge consists in an unique equipment called "cloud proxy". This equipment is located in the consumer home network. The cloud proxy is in charge of ensuring the link between the end user (and her/his device, a laptop for instance) and the cloud. It takes benefit of its position in the home network to anticipate user needs, in particular in terms of data storage. This is why it may store data, quickly available inside the home network. It also takes benefit of its position to organize access to home devices and enhance user experience.

The Cloud Proxy can have 2 main roles:

  1. It can act as a small local datacenter helping supporting in-home applications like NAS (file server), video / audio streamer (DLNA/UPnP compatible, for example), home automation …
  2. Its most advanced role is to act as a proxy to cloud based applications. It then can help the cloud-based application to overcome the traditional limitations of remotely controlling applications such as continuity of service, keeping on with QoS …

An illustrative example of the Cloud Proxy helping keeping on with continuity of service is the following: a sophisticated cloud-based application can be created in order to provide heating (or Airco) home automation to a user. This application could provide a very features-rich environment to the user, for example, by providing a link to weather forecast, to energy pricing, to past statistics etc… The chosen temperature value can be sent to a local small application running inside the Cloud Edge that will regulate the devices even if the link between internet and the home falls down. This minimal application may also offer the local user a way to do some simple modifications to the setup temperatures without requiring the data link to be restored thus providing a minimal continuity of service.

Another example is related to the help the Cloud Edge can bring to the user in term of QoE (Quality of Experience). For example, when someone wants to upload big quantity of data to a server (for the illustration, says, numerous pictures to a Picasa-like service), this upload is limited by the small upstream bandwidth of ubiquitous ADSL links (typically in the 500kbps range). With the increasing size of files (pictures), this can take hours. The Cloud Edge can host a small caching application that acts as a local proxy to the remote cloud-based service and that can accept the files at the speed of the LAN and subsequently uploads them (with the user being offline) at the data link speed. This sort of application could save a substantial quantity of time for the user.

The Cloud Proxy in the Home Network

In the I2ND chapter, for what regards the cloud proxy, we are focusing on the relation with the home network. The cloud proxy is acting as an organizing agent of the home network, in particular unifying the access to the data contained in the home network.

The following figure illustrates the concept of cloud proxy.

Cloud Proxy concept

The IaaS Cloud-edge Resource Management GE defined in the Cloud Hosting chapter comprises those functions that enable to allocate virtual computing, storage and communication resources in cloud proxies. However, FI-WARE will not only define and develop the software linked to the IaaS Cloud-edge Resource Management GE but also software linked to middleware technologies and common facility libraries that will be used in VM images to be deployed in cloud proxies. These middleware technologies and common facility libraries are defined and developed with the I2ND chapter and described in the following section in more detail.

Detailed architecture

This specification describes the Cloud Edge GE, which is located beside the cloud, acting as the cloud agent in the end consumer’s private network.

The Cloud Edge consists of an equipment called "Cloud Proxy". Its main function is to offer local Services hosting capabilities as a complement to the standard Service hosting capabilities provided by traditional Cloud infrastructure.

By Services hosting, we mean, the ability for the Cloud Edge to host various downloadable applications. These applications will provide the “services”.

Services hosted in such Cloud Proxy can benefit of this unique position inside the private network area of a consumer to provide new enhanced Services that will have a direct access to the LAN-located devices (see the previous examples of applications that can provide a better User Experience or a continuity of service) . It can leverage on the proximity between the consumer and the Service itself to offer Services that require strong connectivity. It can also offer access to private capabilities that are hosted or accessible via the cloud proxy (for example sensors or private home network storage).

The following diagram shows the main components of the Cloud Proxy and the interactions with the different potential actors.


The Cloud Proxy offers a single public interface to manage the local service hosting capabilities: the Service Platform Management Interface (SPMI).

Main Concepts

To use the Service Platform Management interface, you should understand the following concepts:

  • Virtual Appliance: this entity represents the kind of Service that the cloud proxy is able to host. It is an operating system and application packaged together that can to run on top of the virtualized system supported by the Cloud Proxy.
  • Image: this corresponds to a set of files that compose a virtual appliance and the associate metadata that describe requirement and configuration needed for installing this virtual Appliance
  • Instance: in our context, it represents the virtual machine that runs the Service. It is an instantiation of a Virtual Appliance.

Actors and Roles

We consider four different types of actors that can interact directly or indirectly with the Cloud Proxy.

  • Application Provider (AP): entity that creates applications for any users and deploys them on the Cloud.
  • Service Aggregator (SA): entity that is in charge to manage a catalogue of applications that are compatible with a set of Cloud Proxies. Its role is to make sure that the proposed applications are sufficiently safe and secure to be deployed in any private consumer environment. If it gets all the required agreements and authorizations, it can deploy specific applications on a set of Cloud Proxies.
  • Device Administrator (DA): root administrator of the Cloud Proxy Devices. The DA has complete control over the Cloud Proxy which includes:
    • The management of the administration rights of all the other users that can connect to the Cloud Proxy Service Platform Management system. Note that only one user per Cloud Proxy (the ISP client) is supported in release 2. This might be changed in R3 depending on the use cases projects requests.
    • The full control of any virtual appliances hosted on the cloud proxy
  • End-User (EU): any user (person) that subscribes and consumes a service that runs on the Cloud Proxy. Register EUs have the ability to selects the applications that need to be installed and executed on their local Cloud Proxy.

Platform Components

The Cloud Proxy GE is composed of four main components: the Service Platform Manager, the Virtual Environment System, the Resource Monitoring and the Resource Controller.

SPM: The Service Platform Manager Interface is the REST interface that supports all features offer by the Cloud Proxy. It is the single point of connection for any client (DA, SA or EU) that needs to control and manage any Virtual Appliances. This module is also in charge of managing the users that are allowed to connect and manage the set of images available on the platform.

VES: The Virtual Environment System is the module in charge of running the system-level virtualized commands. In our case, we select LXC (Linux Container) as this virtualization system. This choice is govern by the fact that the cloud proxy is targeted to run in any hardware environment, from PCs to small embedded systems (e.g. broadband access Gateway). Compared to other virtualization framework (ex KVM, XEN, VMWARE) LXC fits perfectly this requirement because it is lightweight (very low overhead in term of memory and CPU), fast (ability to start or stop any Virtual Appliance in very few seconds), and does not require any specific hardware (i.e. no specific processor instructions).

RM: The Resource Monitoring System is in charge of returning metrics related to the system health and resources consumption to the management entities. For example, it will give access to CPU load, available memory, data exchanged on the communication devices etc ...

RC: The Resource Controller System allows the management entities to set up some key parameters while the Cloud Proxy is running. For example, limit the available memory or CPU load available to one of the running virtual machines.

Note: the API description document lists the metrics and controls that are available for these last 2 sub-systems (RC & RM).

Examples of deployment scenarios

The service hosting capabilities are managed either directly by the end user consumer or by a third party that can deploy a catalogue of application on set of cloud proxies.

Individual on-demand deployment scenario

Summary: While browsing from his laptop at home, an end-user decides to install an application on his local Cloud Proxy. In this example, the installed application is a small web portal accessible from the home network.

  1. A user connects to a web Application and is proposed to install an application into her/his private Cloud Proxy
  2. The user accepts and provides to the Web Application the description of the Cloud proxy environment. In response to that information, the Web application provides the URL of the compatible Virtual Appliance that could run on the consumer’s cloud proxy
  3. The user registers this Virtual Appliance into the Cloud Proxy. The Virtual Appliance is downloaded on the system. If this Virtual Appliance is certified by a third party, the Cloud Proxy checks the validity of the certificate. Note that for R2, the certification is a simple CRC-like calculation.
  4. After reviewing the specific usage’s condition of this Virtual Appliance, the user creates a virtual machine based on this Virtual Appliance and starts it.
  5. As soon as the local Service is started on the Cloud Proxy, the web browser redirects the user to the local web provided by the new running application.

Large scale deployment scenario

Summary: A service Aggregator deploys a catalogue of Virtual Appliances on a set of Cloud Proxies.

Prior to any transactions, the DA and the SA needs to find a formal authorisation that allows the Application Provider (AP) to use the Cloud Proxy owned by the DA.

  1. An AP requests from the SA to deploy a specific service on a set of Cloud Proxies.
  2. The SA checks in its database what are the Cloud Proxies currently available, and among them, select only the ones that can support the application of the AP.
  3. As soon as the set of compatible Cloud Proxies is selected, the SA can start to deploy this application on those cloud proxies.
  4. Then, each End-User can browse the catalogue of her/his own Cloud Proxy and decide to install this application or not.
  5. Once an instance of Virtual Appliance is created, any End-User can start, stop or remove the created Service.

Main Interactions

In this section, the SPMI operations are described. These operations are classified in the following area:

  • Platform features operation: these operations are used to provide generic information about the platform itself and the resources that can be shared or offered to virtual applications.
  • Images Features operation: These operations are related to the management of images that are available on the cloud proxy.
  • Instances Features operation: These operations are used to manage Instances that runs on cloud proxy.
  • Users Features operation: These operation are used to manage the user’s authentication and authorization.
  • Monitoring Feature operation: These operations are used to provide information about the state and the behaviour of any Instance.

Platform Features

  • Platform version: Provide the current version of the Cloud Proxy SW.
  • Platform Description: Provide the general information that describes the platform in term of product, hardware and firmware. Used by any client that needs to provide the right image for a specified Cloud Proxy.
  • Platform Metrics: Provide basic platform HW information.

User Features

  • User Create: Create an account for an End-User. Any user that wants to interact directly with the Services Hosting Platform (install, uninstall a Virtual Appliance) need to be registered. This is performed by the DA, or any local administrator.
  • User Attributes Update: Allow the authorized client to change attributes of a user account.
  • User Delete: Delete a user account.

Note: for R2, only one user is supported. The implementation of this feature depends on what the use-cases projects will require for R3

Images Features

  • Image Register: Registrar a particular Image into the system so that it is available into the local application’s catalogue.
  • Image Detail: Provide detailed description of an image and resources it needs to run on the system.
  • Image List: Provide the list of all the available images for a given user.
  • Image Delete: Delete all the files related to an image and remove the application from the local catalogue.

Instances Features

  • Instance Install: create a Virtual Appliance using a registered image
  • Instance Detail: provide detailed description and metrics of a specified Virtual Appliance
  • Instance Uninstall: delete a Virtual Appliance and free all the resources used by this instance.
  • Instance List: Provide all available Virtual Appliances created on the Cloud Proxy.
  • Instance Action: Perform a set of actions (start, stop, pause, resume, reboot) on Virtual Appliances.

Detailed Specifications

Open API Specifications

Following is a list of Open Specifications linked to the CDI Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Re-utilised Technologies/Specifications

The Cloud Edge is using several open source technology blocks:


The Cloud Edge is using LxC pseudo-virtualisation for executing remotely downloaded applications

Ruby (including libraries)

Parts of the Cloud Edge are written in Ruby. Although this is a language and not an embedded technological block, it must be noticed that many open source librairies are coming with the language and are used in the Cloud Edge (database management, XML-RPC and RESTFull APIs implementations, various utility APIs etc ...)

More information here: http://www.ruby-lang.org/en/

NaDa project (Nano Datacenters)

NaDa is a FP7 project that paved the way for the Cloud Edge concept.

More information here: http://www.nanodatacenters.eu/

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Connected Devices: A connected or smart device can be an advanced device located at home, such as a set top box and multimedia device (including advanced TVs), PCs, storage (NAS like), indoor handset (home/advanced DECT), or game consoles. Furthermore, mobile devices, such as mobile/smart phones (GSM/3-4G), tablets, netbooks, on-board units, (in-car devices) or information kiosks are connected devices, too. It is very likely that new devices will appear and fall into this “smart devices” category during the project execution (femto cells, etc.).
  • Cloud Proxy: A device encompassing broadband connectivity, local connectivity, routing and networking functionalities as well as service enabling functionalities supported by a modular software execution environment (virtual machines, advanced middleware). The “Cloud Proxy” or “Home Hub” is powerful enough to run local applications (for example home automation related tasks such as heating control or content related ones such as Peer to Peer (P2P) or content backup). It will also generally include local storage and may be an enabler for controlling privacy as some content or data could be stored locally and could be controlled only by the user without having the risk of seeing his/her data controlled by third parties under consideration of the overall security architecture.
  • Open Networking: Open networking is a concept that enables network nodes to provide intelligent network connectivity by dynamic configuration via open interfaces. Examples for provided features are the fulfillment of bandwidth or quality requirements, seamless mobility, or highly efficient data transport optimised for the application (e. g., with minimum network resource or energy consumption).
  • Network Service: Network Service is a control and policy layer/stratum within the network architecture of a service provider. The Network Service provides access to capabilities of the telecommunication network, accessed through open and secure Application Programming Interfaces (APIs) and other interfaces/sub-layers. The Network Service concept aims at providing stratum that serves value-added services and applications at a higher application and service layer and exploits features of the underlying transport and technology layer (e. g. via NetIC interfaces).


Personal tools
Create a book