Cloud Native 5G Virtual Network Functions:
Design Principles and Use Cases
Soﬁane Imadali, Ayoub Bousselmi
Orange Labs Networks
44 Avenue de la R´
epublique, 92320 Chˆ
Abstract—The advent of 5G and its ever increasing stringent
requirements for bandwidth, latency, and quality of service
pushes the boundaries of legacy Mobile Network Operators’
technologies. Network Function Virtualization is one promising
attempt at solving those challenges. At its essence, NFV is about
running network functions as software workloads on commodity
hardware to optimize deployment costs and simplify the life-cycle
management of network functions. However, with the advent of
open source cloud native tools and architectures, early VM-based
NFV designs may need to be upgraded to better beneﬁt from new
trends. We propose to review current NFV management solutions
and a deﬁnition of the cloud native toolbox in the context of NFV.
We then present a cloud native software platform allowing MNOs
to expose their assets: networking resources, mobile services,
and cloud computing to Over-The-Top players: 5GaaS. We also
introduce our open source Cloud Native VNF API design as an
application of the proposed design principles and describe from
a standard perspective the feasibility of our prototype.
Index Terms—Cloud-native Computing, 5G, Network Function
Next generation of mobile networks (5G) will provide new
type of applications, services, and use cases from 3 domains:
Enhanced Mobile Broadband (eMBB), Ultra Reliable and Low
Latency Communications (URLLC) and massive Machine
Type Communications (mMTC) . The 5G leverages a set of
technologies such as Cloud computing, Network Function Vir-
tualization (NFV), Software Deﬁned Networking (SDN), New
Radio (NR), Artiﬁcial Intelligence (AI), and large scale or-
chestration and deployment to name few. The NFV paradigm,
in particular, enables the decoupling of software components
of mobile network functions from their respective dedicated
hardware . Thus, the mobile network is transformed into
a chain of modular network functions deployed on the cloud
rather than a large monolithic system with legacy hardware.
This new NFV paradigm will accelerate the deployment of
different processing sites used according to the orchestrating
services needs. We can distinguish between two categories:
edge clouds or central clouds. The central cloud typically
comprises multiple powerful computing and storage resources
which may be several hundred kilometers apart. It can be used
for compute-intensive delay tolerant virtualized workloads. On
the other hand, the edge cloud is located in the vicinity of the
RAN reducing the delays and the jitter at the cost of reduced
computational and storage resources. ETSI’s Mobile Edge
Computing (MEC) API will support new services with high
bandwidth, low latency, and/or distributed compute require-
ments hosted at these new operator points of presence (PoP).
It also allows a more ﬁne grained control of the resources pool
by offering an on-demand and elastic VNF deployment. The
dominant requirements for the fronthaul connectivity between
an edge cloud data center and the radio access point at the
antenna site are low latency and high capacity .
Depending on the use case, VNFs may be used with differ-
ent conﬁgurations (or ﬂavors) to achieve 5G Slicing. In fact,
the 5G connectivity will be provided in the form of network
slices where each slice is an aggregate of multiple domains
from the cloud to the device with a speciﬁc conﬁguration for
each speciﬁc use case . Since early virtualization techniques
do not solve issues such as scalability, availability and feature
velocity, the creation of slices at the level of the VNF may
be problematic. The Cloud Native (CN) approach offers a
promising potential to tackle this issues by re-deﬁning design
principles of the network functions themselves. Moreover, the
shift from legacy infrastructure to a CN one is not only a
new way of developing VNFs by removing the dependencies
on emulating hardware, applying a modular design, integrating
observability, communicating using APIs, but also a brand new
architecture with requirements such as: distribution, automa-
tion, loose coupling, stateless, and self healing .
Mobile Network Operators (MNO) are actively working
in standard development bodies to deﬁne 5G NFV building
blocks: orchestration, life cycle management, deployment re-
quirements, performance and security requirements. In this
paper, we propose a brief review of these activities and provide
an insight of the Cloud Native design principles and use
cases. The key challenges to the evolution of NFV systems
towards Cloud Native design are identiﬁed. We also introduce
a proposal of 5G VNFs framework to support multi-radio
access technologies and to provide a slice of connectivity
to Over-The-Top (OTT) players and Mobile Virtual Network
Operators (MVNOs). Our proposal leverages commodity open
source software and CN design to achieve efﬁcient and multi-
tenant access to MNO’s mobile cloud resources. Main contri-
butions of this paper are two fold: (i) the identiﬁcation of the
challenges and opportunities of moving from the legacy NFV
design to the new Cloud Native design in the the mobile cloud
network, (ii) and our open source development framework we
used to implement for our Cloud Native VNFs.
The remainder of this paper is organized as follows. Sec-
2018 IEEE 8th International Symposium on Cloud and Service Computing (SC2)
978-1-7281-0236-8/18/$31.00 ©2018 IEEE
tion II reviews the efforts in 5G from an NFV architecture
speciﬁcation and implementation point of view. Section III
provides an insight into the CN design and its impact on the
telco world. Section IV introduces our proposal of a 5G as a
Service architecture following the CN design. Finally, Section
V provides conclusions and perspectives of this work.
II. NFV SPECIFICATION AND IMPLEMENTATION
NFV is about decoupling software components of network
functions from their respective dedicated hardware . In the
following, we provide insights on the NFV speciﬁcations and
review some of the open source projects that implement them.
A. Standard Speciﬁcations
The work on the NFV area was initially started at the Eu-
ropean Telecommunications Standards Institute (ETSI) NFV
ISG working group in 2012 with more contributions from
other Standard Development Organizations (SDOs) to provide
design perspectives and use cases. The established architecture
for NFV was the ETSI NFV Management and Orchestration
(NFV-MANO) framework proposed in . This framework
deﬁnes 3 main functional blocks:
•Virtualized Infrastructure Manager (VIM): is the entity
responsible for the management of the underlying NFV
Infrastructure (NFVI) of the mobile networking system;
•VNF Manager (VNFM): is the entity responsible for
managing the life cycle of VNFs, i.e. create, start, stop,
scale, and update operations. The VNFM communicates
with the NFVI to execute those management tasks;
•NFV Orchestrator (NFVO): has a larger view of the
resources and orchestrates VNFs on top of multiple VIMs
to deliver a global networking service and execute the
Four data repositories are also deﬁned by the NFV-MANO
•Network Service (NS) Catalog: is a static store of de-
ployment templates and recipes of network services;
•VNF Catalog: is a static repository of VNF-related
software packages, deployment templates and recipes,
manifest ﬁles, etc.;
•NFV Instances repository: is a dynamic metadata
database that holds information on the running VNFs and
NSs. This repository provides the needed information to
manage the life cycle of the running instances;
•NFVI Resources repository: is a dynamic metadata
database that gathers information on the NFVI assets.
All these blocks are mapped to each others using Reference
Points: for example, the reference point between VNF and
VNFM is called Ve-Vnfm-vnf.
Multiple open source projects propose an implementation of
the NFV-MANO framework with different levels of maturity
(e.g. Open Source MANO - OSM, Open Networking Automa-
tion Platform - ONAP, OpenBaton). Some of these projects
are the fruit of an industrial collaboration with guarantees on
the support and maintainability of the project. Most of these
projects use OpenStack as their default VIM and some of them
started recently introducing extensions to Kubernetes. Table I
summarizes the main projects and their respective use cases.
B. Industry-grade Implementations
Open Source MANO (OSM), introduced in 2016, is an ETSI
open source project implementing the NVF-MANO standard.
OSM gathers a diversiﬁed ecosystem (Cloud Providers, Soft-
ware Companies, telcos, equipment manufacturers) of more
than 100 participating organizations from both industrial and
academic worlds. OSM is currently on its 4th release 
which provides a common NorthBound Interface (NBI) for
future integration with different clients. The OSM components
follow a cloud native design for smaller footprint and faster
deployment. OSM focuses on use cases such service chaining
and slicing, orchestration in MEC architecture and 5G vertical
The Linux Foundation’s Open Network Automation Plat-
form (ONAP) project is an open source project impulsed by
an MNO (AT&T) and currently gaining momentum among
Telco industry. ONAP aims at simplifying the design, cre-
ation, orchestration, monitoring, and life cycle management of
VNFs, SDNs, and higher level services . ONAP provides
two different frameworks: Design Time (DT) and Run time
(RT). The DT framework provides 3 components for Service
Design and Creation, Closed Loop Automation Management,
and a VNF SDK to enable service chaining and network
services integration. The RT framework provides a global view
of the topology and the allocated resources with integration
to the VNFM, VIM and NFVI providing end-to-end service
control and management with analytics to monitor the system.
ONAP focuses on use cases such as virtual Customer Premises
Equipment (vCPE) and Voice over LTE (VoLTE).
Cloudify1is an NFV orchestration project that relies on
the Topology and Orchestration Speciﬁcation for Cloud Ap-
plications (TOSCA) standard to life cycle manage and control
VNFs and the underlying NFVI. The Cloudify orchestration
engine is composed of Topology, Workﬂow, and Policy en-
gines. The system provides a set of design tools such as the
Deployment Management UI and the Blueprint Composer for
The Open Platform for Network Function Virtualization
(OPNFV) is an open source collaboration platform to evaluate
the integration and deployment of VNFs and the underly-
ing infrastructure of the future 5G. Launched by the Linux
Foundation in 2014 to bring together most of the telecom
players, vendors and operators as well as major IT players,
OPNFV is primarily focused on integrating NFVIs and on-
boarding VNFs. Projects such as OpenDaylight, OpenStack,
KVM, Open vSwitch, and Linux are integrated and tested.
Currently, the project is on its 6th release, Fraser, in which
the project pushes forward the concept of Cloud Native VNFs
 initially introduced in the previous release.
SUMMARY OF THE NFV PROJECTS AND THEIR MAIN USE CASES
Projects ETSI NFV-MANO Open Source License Maintainer Supported VIMs Use Cases
OSM NFVO, VNFM, VIM, NFVI, VNF Catalog,
NS Catalog, reference points Apache v2 ETSI OpenStack, VMware,
- 5G slicing
ONAP NFVO, VNFM, VIM, NFVI, VNF
Catalog, NS Catalog Apache v2 Linux Foundation OpenStack -vCPE
OPNFV NVFI Apache v2 (with
possible exceptions) Linux Foundation OpenStack, Kubernetes -vEPC
Cloudify NFVO, VNFM, VIM, NFVI Apache v2 (community edition)
Proprietary (entreprise edition) Cloudify Platform Ltd. OpenStack, VMware,
Open Baton NFVO, VNFM, VIM, NFVI Apache v2 Fraunhofer FOKUS and TU Berlin OpenStack, Docker
SONATA NFVO, VNFM, VIM, NFVI, VNF
Catalog, NS Catalog Apache v2 5G PPP 5GTANGO OpenStack, OpenVIM
C. European Projects Implementations
Open Baton is an open source project launched by Fraun-
hofer FOKUS and TU Berlin to provide an NFV environment
based on the NFV-MANO speciﬁcations. For instance, it
provides an NFVO for managing and orchestrating VNFs.
Multiple VNFMs are used by the NFVO to manage the life
cycle of VNFs and a Software Development Kit (SDK) is
provided to help implementing new VNFMs. In , a new
VIM driver for Open Baton was developed to integrate Docker
containers. Open Baton focuses on extensibility to be able to
integrate with different VIMs and allow multi-site scenarios.
SONATA is a 5GPPP H2020 project that provides an
implementation of the NFV-MANO architecture speciﬁcations
 with multiple software components from the 5GPPP
5GTANGO project. In addition to the basic functional modules
of NFV-MANO (NFVO, VNFM, VIM), SONATA provides a
rich ecosystem around data repositories (e.g. network func-
tions and services, monitoring, infrastructure assets’ alloca-
tion). An SDK is also provided for VNFs packaging, service
management and monitoring. SONATA is one of the most
advanced implementations of the NFV-MANO speciﬁcations
within 5GPPP projects. SONATA is oriented towards use cases
such as Internet of Things (IoT) to monitor and optimize
network trafﬁc, virtual Content Delivery Network (vCDN) to
improve the scalability and apply automatic conﬁguration, and
virtual Evolved Packet Core (vEPC) to improve scalability,
resiliency, optimize placement.
The FP7 Mobile Cloud Networking (MCN) project builds
the foundation of  a Cloud-RAN architecture that follows
the SOA design patterns where services are autonomous,
loosely coupled and communicate through APIs. This design
provides service chaining by composing multiple services
based on 3 main elements: a Service Manager exposing an
end user API; a Service Orchestrator responsible for the
composition of services; and a Cloud Controller connecting
to multiple cloud providers and compliant to the Open Cloud
Computing Interface standard. The project recommends the
use of Cloud Native design to architect the mobile edge cloud
and optimize network functions for cloud environment .
III. CLOUD NATIVE DESIGN
Previous section described the NFV ecosystem within stan-
dards and open source and new trends towards cloud native
designs. The recent surge of interest in containers, Service-
Oriented and Micro-services Architectures, and orchestration
related topics is fueled by the need for industry developers
to share applications that will scale and run in a consistent
manner across many different environments. The CN tool-
box: containers, micro-services, and orchestration tools (e.g.
Kubernetes) provide such assurance. In this context, ”Cloud-
nativeness” is an approach to build, ship, and run computing
workloads that exploit the beneﬁts of this cloud computing
model and beneﬁt from the reproducibility guarantees pro-
vided by these tools. Confronted to the need of standardization
of such a disruptive environment with a rapidly changing
ecosystem, the Cloud Native Computing Foundation (CNCF)
from the Linux foundation has recently been created .
A. Cloud Native Computing Principles
Authors of  deﬁne the cloud as a distributed architecture
of individual cloud-native services where resources are pro-
vided as services in a tiered fashion (layering) to construct a
full technology stack from hardware (IaaS) to middleware plat-
forms (PaaS) to applications (SaaS). This SOA is completed
with communication interfaces between layers, encapsulating
implementation details (APIs) and loose coupling between
these modules (or dependencies) and the use of asynchronous
communication and statelessness when possible (event-driven
design). In order to leverage open source cloud-native tools,
the CNCF organized these tools at the disposal of developers
in its landscape . The beneﬁts come as follow:
•Reproducibility comes from the use of containerization
and automation tools. With a standardized common de-
ployment format (the container) and a predictable recipe
of build and deployment (CI/CD), the application will be
built and delivered in a consistent predictable manner.
•Composition of services along with orchestration and
dependency management leverage the maturity of the
Kubernetes ecosystem. With a set of CNCF certiﬁed
Kubernetes platforms, application deployments can be
described once and run across different cloud providers.
•Observability and analysis tools put the monitoring,
tracing, and logging as a commodity at the disposal
of developers with often the promise to work without
application rewrite. These tools (e.g. Envoy, Linkerd) are
deployed as an additional dependency in the Kubernetes
Pod (referred to as a sidecar).
•Provisionning tools (e.g. Ansible) helps describing the
infrastructure as code and ﬁnalize the application speci-
ﬁcation from the infrastructure to the software itself.
B. Application to VNFs
The cloud-native ecosystem tooling within CNCF is recent.
A number of tools backed by industrial partners can be consid-
ered stable and following a healthy set of development prin-
ciples: stable API endpoints, retro-compatibility, predictable
changes, and long term support. Still, most of the tooling
while providing interesting features can suffer from quickly
changing priorities, APIs, and dependencies.
The VNF design on the other hand follows the guidelines set
by ETSI’s management and orchestration framework (MANO)
. Most notably, MANO provides standardized functional
blocks connected through well deﬁned reference points and
dependencies. From an operational perspective, this design
challenges the previous communication standards and estab-
lishes new requirements to achieve carrier grade performances.
•Network function chaining. Lifecycle operations of ser-
vices (e.g. eNodeB) may involve the conﬁguration and
deployment of several interconnected components.
•Data plane enhancements. In order to guarantee low
latency and minimize jitter for network packet processing,
infrastructure operators need to employ packet processing
acceleration stacks (DPDK and VPP) and specify hard-
ware and operating system parameters for the deployment
(e.g. NUMA nodes, huge page memory conﬁguration,
and CPU pinning for real time).
•Distributed deployment site support. To minimize latency
and enable mobile edge computing for 5G, certain VNFs
need to be distributed across PoPs close to clients.
With recent advances within CNCF and effort from man-
ufacturers, Cloud-native VNFs (CN-VNFs) may now run in
a container rather than a Virtual Machine, their lifecycle
orchestrated by a container orchestration engine (Kubernetes),
and their observability enhanced by advanced monitoring
tools (Promotheus). With regards to the CN-VNF design, the
following projects are relevant.
•Ligato is a Golang framework intended for development
of custom management/control plane agents for CN-
VNFs . The framework includes a set of speciﬁc
functionalities: logging, health checks, messaging, REST
and gRPC APIs. Ligato is part of the ”Runtime - Cloud-
Native Network” CNCF category.
•Gohan is an industry open source project that proposes
schema-driven micro-services development framework.
This framework proposes code generation to ease the
service-related policy, conﬁguration, and API boilerplate
code creation. The practical uses of the framework in-
clude Service catalog or orchestration on top of public
cloud and uniﬁcation of legacy VIM with cloud 
•Tack e r is an ofﬁcial OpenStack project for building
generic VNF manager and orchestrator, as well as a
catalog. The idea is to ease the adoption of the OpenStack
ecosystem for multi-site deployment of MANO compat-
ible designs. Using Tacker, VNFs can be deployed using
virtual machines and containerized workloads through
Kubernetes as a VIM described in TOSCA.
C. Impact of VNF design on RAN evolution
The CN design of VNFs may beneﬁt the Telco operators
in different operational areas. For instance, scalability and
quality of data intensive applications may beneﬁt from ease
of scaling lifecycle operations integrated with orchestration
engines. Resiliency and zero down time design for mobile edge
also comes with a design of a solid networking, virtualization,
observability, and automation. Also, with the business models
around connectivity and asset providers for anything-as-a-
service (XaaS), principles such as reproducibility, multi-VIM
deployments, and identical conﬁgurations with heterogenous
providers is of paramount importance. Such design also bene-
ﬁts introduction of new actors for RAN evolution: MEC appli-
cations, distributed CDN deployments, and BBU hostels .
Another advanced use could be prototyping and demonstrating
wide-scale pilots similar to A/B testing or Canary deployments
well known in IT industry .
IV. OVERVIEW OF 5G AS A SERVICE
The NGMN  describes new business models expected
with 5G among which asset providers, connectivity providers
and partner service providers following a ﬂexible XaaS asset
provider model. The key requirement is that service providers
should be able to conﬁgure and manage the service, while
operators will manage and evolve the network . We intro-
duce the 5G as a service software platform (5GaaS). 5GaaS
supports multi-radio access technologies through VNFs and
provide a slice of connectivity to OTT players and MVNOs.
Our platform could also be used in a RAN sharing scenario
and participate to the global RAN evolution. Our proposal
leverages commodity hardware and open source software in
a CN design to achieve multi-tenant access to MNO’s mobile
cloud resources. This paper provides the CN architecture for
a mobile cloud network, and our open source development
framework used to implement our CN-VNFs .
Figure 2 represents the overall architecture of the 5GaaS
software platform. Different OTTs can design their 3rd party
applications by designing their share of the MNO assets
(compute, SDN, cellular). Once the tenants of the 5GaaS
authenticated, they can make use of the geographic map
representing the MNO assets and the PoPs for the compute.
The points of interests on the map (antennas from different
URLLC application (Slice 1)
eMBB application (Slice 2)
mMTC application (Slice 3)
NFVO+VNFM+VIM NFVO+VNFM+VIM NFVO+VNFM+VIM
NFVI NFVI NFVI
Design Deployment Provisioning
Fig. 1. 5G as a Service overall architecture overview.
technologies) are described using a GEOJSON format with
open datasets for the antennas. The availability of resources,
their update per tenant, and the placement are all responsibil-
ities of the Location Manager (LM) software component.
A tenant can select a geographic area for the deployment
ﬁeld available to the application; we call this step the slice
creation based on the user interface (UI) or the user API NBI.
Once the additional deployment conﬁguration is setup (QoS,
duration, SLAs), the tenant can proceed to the deployment
phase. The Service Manager (SM) responsible for the slice
level information and conﬁguration, will set up a new Service
Orchestrator converting the SLA to a deployment manifest for
the NFV-MANO interfaces: Or-Vi and Or-Vnfm of .
Once the slice deployed and provisioned, the tenant’s clients
through their provisioned SIM cards, can have access to the
tenant’s share of the network over the MNO’s assets. The data
originating from these client’s terminals or objects connect to
the Internet through the Core Network slice that the MNO has
designed for the tenant. The description of this data path is
out of scope for this paper.
For our prototyping purposes, the Cloud Native NFVI
interface used was that of the Docker daemon API. Current
prototyping efforts are related to migrating this interface to
Kubernetes (through a Helm chart). For the radio part, we
use the OpenAirInterface eNodeB implementation with an
additional CN-VNF API described in subsection IV-C and
an unchanged Core Network also from the OpenAirInterface
foundation. We also use a dockerized version of DHCPd and
HostAPd for the CN-VNF WiFi with the previous API.
B. Slice-related procedures
Depending on the tenant’s application, the slice-related
procedure can be: creation, healthcheck, or decommissioning.
When the tenant is authenticated on the 5GaaS platform,
he/her is presented with the current status on the consumed
resources and other available resources accessible to him. The
latter is done by update through the LM element.
To create a new slice, the tenant uses the NBI to interact
with the resources map and specify the area where a slice of
Status on consumed resources
decommissioning Service stop
Fig. 2. User to system to infrastructure interactions within 5GaaS.
cellular network should be reserved. Once the conﬁguration
completed with SLAs, QoS, and duration of the slice, the
SM receives a JSON contract with this information. The SM
proceeds to create a new SO for this conﬁguration. SO with
the appropriate infrastructure driver with convert the JSON
contract into a deployable instance that will be provisioned on
the PoP infrastructure. Resources on the LM are then updated
by the SM to account for this new deployment.
Slice deletion is triggered by the end of a deployment dura-
tion as speciﬁed in the contract or at the initiative of the tenant.
The SO will trigger the appropriate lifecycle management
operations for the VNF (stop or kill) in coordination with the
infrastructure. The LM is notiﬁed of new available resources.
From a standardization viewpoint, a new slice in the RAN
is subject to spectrum usage rights and management in co-
operation between MNOs and national regulatory authorities.
5G should introduce within the MNO domain ”Spectrum
assignment coordination” where the entity (the MNO) utilizing
information from various databases and spectrum sharing
enablers if applicable, is responsible for spectrum assignment.
The functional spectrum management architecture is further
described in . For our prototyping purposes, a new slice
means a new instance of the OAI eNodeB in its own docker
container, whereas in a standardization scenario the deﬁnition
of a slice at the RAN level can involve scheduler conﬁgu-
ration, tenant speciﬁc RAN functions instances, cross-layer
optimizations, and dedicated transport planes per slice. At the
time of writing, this is still an open standardization work not
yet implemented within OAI .
C. CN-VNF design framework
To take full advantage of the MNO’s assets, VNFs need to
be cloud-native and the VNFM should only interact with their
APIs to manage their lifecycle. We propose  a modular
and extensible framework for cloud-native VNFs design. Our
CN-VNF framework emulates slicing to VNFs that are not
multi-tenant by design. Our framework allows an orchestrator
to interact with the CN-VNF through its HTTP REST API to:
•Create, update and remove sessions identiﬁed by a unique
user ID (UUID). A session allows the isolation of tenants
on the same NFVI.
•Create, update, remove conﬁgurations per session. Each
VNF can have several conﬁguration templates.
•Start, stop, and terminate VNF instances per session. An
instance is associated with a conﬁguration in the session.
•Get a status of sessions or given VNF instances (created,
started, stopped, load average, network consumption).
To demonstrate this concept, we implemented CN-VNFs for
the OpenAirInterface eNodeB and WiFi (based on Hostapd
and Dhcpd). Both CN-VNFs can run on top of the Docker-
based VIM or on the host operating system (i.e. Linux), the
only NFVIs we currently provide. Our framework adds the
following interfaces and behavior to those two VNFs:
•A conﬁguration interface that accepts conﬁguration from
ﬁles, environment variables, and command line interface.
•A logging interface to standard output, ﬂat ﬁles, and
Logstash as its recipients. This allows streaming logs to
logging as a service platforms (e.g. elastic stack).
•A scheduler interface. This supports different scheduling,
by default the underlying Linux system and Docker.
•Templates interface that supports conﬁguration version-
ning to comply with the VNF version.
•Storage interface to store the state of the CN-VNF to
recover from failures and support migration from one
NFVI to another.
V. C ONCLUSION AND PERSPECTIVES
In this paper, we proposed a practical use case, 5GaaS,
implementing open source components and following, when
possible, the cloud native approach for design and deployment.
We brieﬂy reviewed relevant activities in the standard and
open source communities to provide an insight into the NFV
industry and tried to redeﬁne their requirements using some of
the CN design principles. We also introduced a proposal for
5G CN-VNF framework that we applied to support multi-radio
access technologies leveraging open source software. Future
work should address the application of Kubernetes orchestra-
tion at the VIM layer and updated CN-VNF framework with
better support for the OpenAirInterface FlexRAN Agent API
(for monitoring and reconﬁguration in particular).
This work was partly funded by the European Commission
under the European Union’s Horizon 2020 programme - grant
agreement number 815074 (5G EVE project). The paper solely
reﬂects the views of the authors. The Commission is not
responsible for the contents of this paper or any use made
 M Series, “Imt vision - framework and overall objec-
tives of the future development of imt for 2020 and
beyond,” Recommendation ITU, pp. 2083–0, 2015.
 J. G. Andrews et al., “What will 5g be?” IEEE Journal
on Selected Areas in Communications, vol. 32, no. 6,
pp. 1065–1082, 2014.
 A. Checko et al., “Cloud ran for mobile networks; a
technology overview,” IEEE Communications Surveys
Tutorials, vol. 17, no. 1, pp. 405–426, 2015.
 N. Alliance, “5g white paper,” Next generation mobile
networks, white paper, pp. 1–125, 2015.
 D. S. Linthicum, “Cloud-native applications and cloud
migration: The good, the bad, and the points between,”
IEEE Cloud Computing, vol. 4, no. 5, pp. 12–14, 2017.
 ETSI, “Network Functions Virtualisation (NFV) Man-
agement and Orchestration, ETSI GS NFV-SWA 001
 A. Hoban et al., “Osm release four,” 2018.
 What is ONAP?, ofﬁcial onap developer wiki, https :
//wiki. onap.org/display /DW/Developer+Wiki. (visited
 OPNFV Release notes, https://www.opnfv.org/software.
(visited on 07/31/2018).
 G. A. Carella et al., “Prototyping nfv-based multi-
access edge computing in 5g ready networks with
open baton,” in 2017 IEEE Conference on Network
Softwarization (NetSoft), 2017, pp. 1–4.
 S. Dr¨
axler et al., “Sonata: Service programming and or-
chestration for virtualized software networks,” in Com-
munications Workshops (ICC Workshops), 2017 IEEE
International Conference on, IEEE, 2017, pp. 973–978.
 MCN, http://mobile-cloud-networking.eu/site/,
 A. Edmonds, T. M. Bohnert, et al.,Final overall archi-
tecture deﬁnition, release 2, 2015. [Online]. Available:
 The CNCF announcement, https : / / www . cncf . io /
announcement / 2015 / 06 / 21 / new - cloud - native -
computing - foundation - to - drive - alignment - among -
container-technologies/, Accessed: 2018-07-23.
 C. Pahl, P. Jamshidi, and O. Zimmermann, “Archi-
tectural principles for cloud software,” ACM Trans.
Internet Technol., vol. 18, no. 2, 17:1–17:23, Feb. 2018.
 The CNCF landscape, https://landscape . cncf . io /
grouping=landscape, Accessed: 2018-07-23.
 Ligato, https://github. com/ligato, Accessed: 2018-02-
 The Gohan framework, https : / / gohan . cloudwan . io,
 P. Marsch, ¨
O. Bulakci, O. Queseth, and M. Boldi, 5g
system design: Architectural and functional considera-
tions and long term research. John Wiley & Sons, 2018.
 P. Bellavista, “Mobile cloud networking: Lessons learnt,
open research directions, and industrial innovation op-
portunities,” in 2016 4th IEEE International Conference
on Mobile Cloud Computing, Services, and Engineering
(MobileCloud), 2016, pp. 79–80.
 C-OAI, https:// github.com /soﬁaninho /c - oai, Accessed: