Community Research and Development Information Service - CORDIS

H2020

SUPERFLUIDITY Report Summary

Project ID: 671566
Funded under: H2020-EU.2.1.1.3.

Periodic Reporting for period 1 - SUPERFLUIDITY (Superfluidity: a super-fluid, cloud-native, converged edge system)

Reporting period: 2015-07-01 to 2016-06-30

Summary of the context and overall objectives of the project

The vision of the SUPERFLUIDITY project, in the framework of 5G, emerges from powerful drivers that are shaping our society.
The first driver is the increase of population and the still growing globalisation and physical and virtual mobility: more people (2 billion and a half in 1950, almost 7.5 billion today, half of them living in cities), and more interconnections among them.
The second driver is the proliferation of new or improved applications and services that need network connectivity: social networks, video (high definition), IoT (metering, smart home, connected cars), industry 4.0 (or the fourth industrial revolution, the current trend of automation and data exchange in manufacturing technologies), low latency services (games, virtual reality, autonomous vehicles), advanced services (face recognition and speech translation, cognitive and expert systems, big data exploitation).

Simply put, we have more connected devices, with each requiring higher data rates, lower latency, and ubiquitous coverage, with very high densities of users possible.

In addition, the importance of network connectivity and networked applications in our society and economy has the consequence of requiring significant improvements also in terms of: i) faster deployment of applications and services, so reducing their time to market and easing their evolution; ii) lower energy consumption; iii) enhanced security and privacy; iv) better reliability and dependability.
Furthermore, processing needs will be exacerbated in high capacity, dense networks. Current cloud computing solutions are not suitable for dynamic, real-time, high-bandwidth, low-latency applications because of issues such as granularity, localisation and configurability; service processing nodes should be distributed and located close to users or to routers or in local data-centres and not only in traditional data-centres.

However, in spite of, or maybe because of, the great achievements that we witnessed in ICT, revenue growth for telecom operators is expected to halve from now to 2020. This means that demand cannot be satisfied by simply increasing network capacity, especially in networks that are becoming always more diverse, dense, mobile and changing unpredictably.

The answer to the challenging and sometimes contradicting necessities summarised above, consists in reducing capital and operating costs, by using low cost technologies, reducing energy consumption, sharing and optimising resources utilisation by dynamically allocating them in time and space, and in general resort to virtualisation techniques as much as possible. Benefits of a full virtualisation of network devices, at all layers, include: i) sharing: resources divided into multiple virtual pieces used by different users; ii) isolation: sharing of a resource does not endanger security and privacy of users; iii) aggregation: if resources are not big enough to accomplish a task, they can be aggregated; iv) dynamics: reallocation of resources in space and time on demand; v) ease of management: software-based devices are easier to manage and update.
In addition, it is necessary that the network be programmable, as a function of the needs of the services that it provides. An example of the capabilities of a virtualised and programmable network is the concept of a network slice; a virtual, end-to-end network, deployed in software, which runs in parallel to other slices on a common hardware infrastructure. A network slice also allows the isolation and support of different classes of services/customers.

The overall vision is thus the one of a software network with an application/service-centric network control able to dynamically share and allocate virtualised resources, allowing to: reduce costs, simplify network management, increase flexibility, ease evolution, and dynamically deploy network services.

5G will be, then, a fully “softwarised” network providing fixed and mobile Ultra-Broadband access to a distributed

Work performed from the beginning of the project to the end of the period covered by the report and main results achieved so far

SUPERFLUIDITY builds upon the recognition, supported by a break-down analysis of use cases, that network services and functions usually comprise multiple elementary primitives or building blocks, which we generically call Reusable Functional Blocks (RFBs), and which can operate at different layers in the protocol stack. The refactoring of traditionally monolithic network services or functions in the form of a modular composition of ‘more elementary’ RFBs leads to a main key strategic advantage: decoupling of the network service or function logic (programmatically defined via a platform-agnostic configuration ‘language’ or ‘script’, formally specifying block chains and/or abstract extended state machines), from the actual underlying implementation of RFBs (vendor-specific and possibly leveraging different HW platforms and accelerations). Such main key advantage brings about a number of specific assets, including but not limiting to: i) reusability of blocks across different functions or services and hence significant cost savings in the design of such functions, ii) portability and mobility (instant deployment) of services and functions across different platforms and at different points in the network topology, iii) simplified provisioning, at RFB level rather than at the service level, iv) ability to leverage different RFB implementations on different platforms (and with different performance).

The main high-level innovative characteristics of the project so far include:
• The notion of RFB. Our definition of RFBs is on purpose very broad and not bound to a specific ‘size’ or ‘type’. By this approach, we retain generality and permit backward compatibility casting the RFB concept into already existing standards and components/functions (hence further including ‘complex’ RFBs which, even if they could in principle further benefit of a functional decomposition, they are ‘de facto’ marketed as monolithic components). This said, we concretely envision at least two ‘levels’ of RFBs: ‘higher level’ functions, such as those envisioned in the scope of current NFV standardisation and which are chained together to build complex services, and ‘lower level’ primitives which are envisioned within domain-specific network devices (such as OpenFlow-type actions for core network devices, signal processing blocks in SDR/C-RAN, etc.) and relevant standardisation bodies. In order to maximise impact, we are considering different Standards Developing Organizations (SDOs) in this scope, which range from the ETSI-NFV and MEC ISGs to the SFC working group at IETF and the NFV research group at IRTF. In our working assumptions, RFBs can be expressed in terms of other RFBs, in theory with no limits to the recursion levels. Suitable languages to support this approach needs to be defined; we are considering the use of the NEMO network modelling language to support RFB description and combination and an internet draft has been submitted.
• Controlling and placing RFBs. The identification of a suitable set of RFBs, which can act as basic building blocks is not sufficient: indeed their coordination, orchestration, and (co)operation to provide a value-added service require supplementary techniques, systems, and computational environments. Specifically, innovation and even foundational research is needed in terms of i) languages, formalisms and mechanisms to specify a desired (composed) service, and validate a given configuration (this entails the ability to semantically describe each RFB so as to guarantee functional equivalence among different implementations), ii) algorithms and data models for network resource description and functions’ placement, and iii) environments and tools to run-time enforce, provision, and reconfigure, a desired composition.
• VNF orchestration advances. Considering the ETSI-NFV architecture, the RFB concept maps into VNF and VNF components (VNFC). The work on VNF orchestration is alre

Progress beyond the state of the art and expected potential impact (including the socio-economic impact and the wider societal implications of the project so far)

In the following, we outline the project’s progress beyond the state of the art in a set of research areas that we believe are more of importance to SUPERFLUIDITY. This progress is the one expected from the whole duration of the project. More detailed and current information about the project’s progress beyond the state of the art in the first year of work, as well as the project’s innovation potential, can be found in the public deliverable D8.3: Innovation and Exploitation Plan (http://superfluidity.eu/results/deliverables/), which reports the advancements reached as of today.

• Cloud Networking: SUPERFLUIDITY will aim to meet the stringent requirements imposed by future 5G networks by designing and implementing a superfluid, converged network architecture that is location, hardware and time-independent. The work will push the boundaries of what is currently possible with virtualised, software-based packet processing (10-40Gb/s and higher, extremely fast service instantiation and migration in milliseconds, massive numbers of concurrent virtualised services on a single platform, significant power reductions, etc.). The goal is to bring the advantages of cloud and software-based networking to 5G networks so that services can be deployed whenever and wherever they are needed, and to leverage the availability of inexpensive, off-the-shelf hardware in the process.
• Network Services Decomposition and Programmability: SUPERFLUIDITY will devise programming abstractions specifically targeted to 5G functions. The API design work will address three programming levels: service, function, and processing levels, and will attempt to maximise viability by reusing existing standard (when applicable) or research community best practices. Work will on one side target the definition of 5G specific actions and events, and on the other side will address the specification of the constructs needed to combine and orchestrate a desired execution of such actions (conditioned on the arrival of events). Particularly promising and forward-looking is SUPERFLUIDITY’s approach of combining block-based composition abstractions (such as those exploited in Click routers, in some software defined radio architectures, or emerging in the ETSI NFV work on service chaining) with event-driven programming paradigms such as basic match/action based approaches or more powerful stateful abstractions based on extended finite state machines.
• RAN Cloud and Mobile Edge Computing: Beyond the current vision of a static RAN function fully located in one “edge computing” place, SUPERFLUIDITY will support the ability to modularly “hot” replace eNB functions (such as scheduling) and to permit migration of such functions between edge clouds and the antenna subsystem, so as to balance algorithmic complexity with front-haul capacity. SUPERFLUIDITY will also transcend current Mobile Edge Computing vision where non-RAN functions (local caching, CDN, etc.) are envisaged to be co-located only at the eNB by enabling their migration between the RRH and the edge cloud, to maximise their performance.
• Automated Security and Correctness: SUPERFLUIDITY will provide a two-pronged, complementary approach to security. First, it will go beyond the state of the art, providing a pre-deployment checking system that will ensure that virtualised network services do not negatively affect the network nor other tenants; unlike approaches in the literature, the system will be both scalable and stateful, able to model most types of services. Second, SUPERFLUIDITY will implement a post-deployment system that will learn the behaviour of traffic and detect any anomalies, thus providing a further security mechanism in cases where the checking system does not have information about the processing performed by a network function, or when static analysis is inaccurate.

As regards the expected potential impact of SUPERFLUIDITY, the project is at the end of its first year; therefore, m

Related information

Follow us on: RSS Facebook Twitter YouTube Managed by the EU Publications Office Top