Key principles

The INPUT Project aimed to move cloud services much closer to end-users and smart-devices at the edge of telecommunication network infrastructure. This evolution has been accomplished by introducing intelligence and flexibility (“in-network” programmability) into network edge devices, and by enabling them to host cloud applications (Service_Apps) capable of cooperating with and of offloading corresponding applications residing in the users’ smart objects (User_Apps) and in datacenters (DC_Apps), to realize innovative personal cloud services. The conceptual approach of the INPUT Project, including the Service_Apps operating at the edge network level, is shown in the figure below. 

Logical and physical view of the INPUT network and functional architectures.


The presence of such Service_Apps allow user requests to be manipulated before crossing the network and arriving at remote datacenters in ways that enhance performance. Moreover, the Service_Apps take advantage of a vertical integration in the network environment, where applications can benefit from network-cognitive capabilities to intercept traffic or to directly deal with network setup configurations and parameters. The integration of Service_Apps at the network edge level is a fundamental aspect for upcoming 5G specifications, since this level is the one where the Telecom Operator terminates the user network access, and a direct trusting/control on user accounts and services is performed. Therefore, this level has been the natural candidate to host personal Service_Apps, and to provide novel network-integrated capabilities to the cloud environment in a secure and trusted fashion.

To this end, the INPUT Project also focused and contributed to the evolution of network devices acting at this level beyond the latest state-of-the-art Software-Defined Networking (SDN) and Network Function Virtualization (NFV) technologies, and to design how to interface them with the “in-network” programmability. The experimental results obtained in the demonstration activites exhibited how this approach is able to reduce the reaction times of cloud applications and to improve the scalability of the entire network/cloud ecosystem.

The INPUT Project designed a multi-layered framework that allows, on the one hand, multiple Personal Cloud Providers to request IT (e.g., in terms of computing, storage, caching, etc.) and network resources of the Telecom Infrastructure Provider via an extended Service Layer Agreement. On the other hand, in order to minimize the OPEX and increase the sustainability of its programmable network infrastructure, advanced Consolidation criteria to dynamically allocate and seamlessly migrate/split/join on a subset of the available hardware resources have been made available to Telecom Operators.  The presence of these power management criteria and schemes is one of the key aspects for maximizing the return of investment of the INPUT technology to Telecom Infrastructure Providers.

The INPUT architecture also provides additional degrees of freedom and ground-breaking capabilities to design innovative personal cloud services, which can be substituted for (and/or can integrate the hardware capabilities of) smart objects usually placed in users’ homes (e.g., set-top-boxes, network-attached storage servers, etc.). This has been achieved using “virtual images” of these objects, making them always and everywhere available to users through a virtual personal network. These virtual images obviously contribute in providing services to end-users in a cheaper way, avoiding the costs of buying physical smart objects and enabling continuous evolution of object performance and capabilities. On the other hand, the presence of the virtual personal network gives users the perception of a familiar personal environment with well-known legacy network and application protocol interfaces (e.g., Samba folder sharing and DLNA– Digital Living Network Alliance – streaming from a NAS server) usually applied in the home Local Area Networks (LANs). In this respect, Personal Networks have been specifically designed to provide the same perceived levels of security, privacy and trust as in today’s home networks, and have to expose these primitives to overlying cloud services.


The platform

The INPUT platform has been designed as a modular ecosystem of modules acting at both the control and the data layers of Edge Computing system. The main modules and their interfaces among themselves and towards the INPUT stakeholders are depicted in the following image.

The dataplane architecture of the INPUT platform is composed of computing servers and SDN switches. While the presence of SDN switches is optional, the INPUT platform requires a number of computing servers running KVM as virtualization platfom. The servers should be configured to run in one or more points of presence inside the network architecture. Despite third-party (open-source dependencies - e.g., KVM), the INPUT platform provides some native dataplane functional blocks to be installed on the aforementioned servers. Such blocks are provided by the OpenVolcano Caldera framework. The most relevant dataplane building blocks provided by OpenVolcano Caldera are the Quake SDN software switch and the virtual home gateway for interconnectivity with Personal Networks, which includes high performance virtual network functions, such as NAT and firewall. Such network functions have been designed upon the multi-context paradigm: one single instance is able to run multiple user context.

The control and the management processes of the programmable computing and network infrastructure are composed of two main building blocks: the Network and Service Management (NS-MAN) and the Network and Service Operating System (NS-OS).

The NS-MAN is responsible for the long-term configuration of the network, the administrative configuration of the infrastructure, the overlaying cloud services and personal networks, and for the monitoring of the resources utilisation and power consumption of the INPUT infrastructure. In addition, it is in charge of reserving/releasing and managing the network and computing resources to properly satisfy bandwidth and quality levels required by the different cloud services instantiated over time. Finally, it is in charge of monitoring faults, intrusions and attacks in the system and use trend analysis to predict errors and guarantee that deployed services are always available. In this respect, the following table reports the Key Performance Indicators (KPIs) monitored and optimised by the NS-MAN. 

The NS-MAN is also in charge of storing historical data received from the NS-OS and the network and computing elements (e.g., network/servers usage, users’ mobility, Service_Apps computational resources, etc.), for performing data analytics and providing trend estimates. To this goal, the NS-MAN is equipped with the required tools to support big data storage and the proper business logic, like analytics algorithms, to get insights and to decide which policy needs to be applied to optimise resource usage. In the current form, the NS-MAN is able to trace, store and correlate:

  • the network and computing available resources;
  • the actual user service requirements.

The goal of these correlations is to get insights on the overall operating behaviour of network devices and computing facilities, in order to predict service demand, plan the resource provisioning, prevent congestion, possible failures, and maximize energy saving. The NS-MAN optimises the overall cost by looking for a local minimum of a cost function and suggesting a new consolidation strategy to the NS-OS. The NS-MAN also offers a user interface (UI) towards Telecom Operator for infrastructure monitoring, and policy configuration. 

The INPUT NS-MAN has been developped by extending the Ericsson Network Manager, and its presence is optional.

Differently, the NS-OS drives the real-time configuration of the programmable resources and the dynamic instantiation and migration of Service_Apps and Net_Functions according to users’ locations. In more detail, the NS-OS performs the following three main tasks: Consolidation, Orchestration and Monitoring. The Consolidation task is in charge of calculating the optimal re-configuration of the infrastructure (e.g., the topology of the Personal Networks and the matching and action rules of the SDN switches) in terms of network paths/overlays and of the Service_Apps and Net_Functions locations, with the objective to match the required QoE/QoS and the estimated workload/traffic volumes with the minimum possible level of energy consumption . The Orchestration mechanism takes the re-configured set-up coming from the consolidation process as an input and instantiates/migrates Service_Apps and Net_Functions to the identified subset of devices/hardware resources, by changing the network configuration accordingly, without causing any service interruption or performance degradation . Finally, the Monitoring task collects performance measurements and alerts, which include network-, App-, and power-aware performance indexes.  

The NS-OS is a mandatory component and it has been realized through the OpenVolcano StratoV framework.

Both the INPUT NS-MAN and NS-OS functional blocks control and manage the programmable resources through specific South and North Bound Interfaces, listed in the following table.


SouthBound Interfaces

Interface IDs




It interfaces the NS-MAN with the network and computing resources. It enables the NS-MAN to collect traffic, resource utilisation and power consumption statistics from the network and computing equipment and the NS-OS.




It is the communication interface between the NS-MAN and NS-OS. Information flowing through this interface regards the configuration of the SDN infrastructure, the reservation/release of the network and computing resources, and the management of the fault alarms.



It is the communication interface between the NS-OS and the physical/virtual SDN switches. Information flowing through this interface regards the configuration of the users’ Personal Networks according to their locations and the routing rules of the users’ traffic to Net_Functions, Service_Apps and vice versa.

OpenFlow 1.4


It is the interface between the NS-OS and the virtualisation platform residing in the computing facilities (i.e., the Hypervisor) hosting the Service_Apps. Information flowing through this interface regards the management and monitoring of the server’s local resources and the instantiation and migration of Service_Apps.

libvirt 1.2.14


It is the communication interface between the NS-OS and the NFV servers. Information flowing through this interface regards the configuration and instantiation of the Net_Functions.



It is the interface between the NS-OS and the power saving capabilities of the programmable resources of the INPUT architecture. Information flowing through this interface regards the configuration of the energy-aware hardware, the discovery of the power saving capabilities and monitoring of the energy consumption of the network and computing appliances.

Green Abstraction Layer (GAL)


NorthBound Interfaces

Interface IDs




This interface enables the NS-MAN to expose monitored performance statistics and APIs to the Telecom Operator through a Graphical User Interface – GUI. The GUI will allow the Telco Operator manually configure the INPUT infrastructure and monitor its behavior.

 Web Portal


This interface will allow Cloud Service Providers to define their cloud services, the definition or updating of the Service_Apps, the type of data to be maintained, and their operative requirements and features (e.g., Service Level Agreements – SLAs).

OpenStack APIs


This interface will allow users define and update their Personal Network, e.g., the IP addressing rules and the list of connected virtual/physical SDs.

 Web Portal


Further details on the INPUT platform architecture internals and design principles can be found in the section 6 of the D2.1 report.


The INPUT Consortium released all the mandatory components (i.e., the NS-OS + the data-plane components) of its platform through the open-source OpenVolcano platform.

  Get OpenVolcano » See the INPUT demo videos »


The INPUT project is funded by the European Commission DG-Connect in the Horizon 2020 Framework Programme. The content of this web site publication is the sole responsibility of the project partners.The information provided on this website has been prepared exclusively for the purpose of providing information about the INPUT project and related activities.The INPUT consortium has tried to ensure that all information provided in this website is correct at the time it was included. However, no representation is made or warranty given as to the completeness, accuracy and constant update of the information contained in this website.By accessing this website, you agree that the INPUT consortium will not be liable for any direct or indirect damage or any consequential loss arising from the use of the information contained in this website or from your access to any other information on the internet via hyperlinks.The copyright in the material contained in this website belongs to the INPUT consortium. The technology or processes described in this website may be subject to other intellectual property rights reserved by the INPUT consortium or by other third parties in various countries. No license is granted in respect of those intellectual property rights.No information contained in this website can be considered as a suggestion to infringe patents. The INPUT consortium disclaims any liability that may be claimed for infringement or alleged infringement of patents. This website is an offer of information by the INPUT project team.