Conference PaperPDF Available

Cloud Native 5G Virtual Network Functions: Design Principles and Use Cases

Authors:
Cloud Native 5G Virtual Network Functions:
Design Principles and Use Cases
Sofiane Imadali, Ayoub Bousselmi
Orange Labs Networks
44 Avenue de la R´
epublique, 92320 Chˆ
atillon, France
first.second@orange.com
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 benefit from new
trends. We propose to review current NFV management solutions
and a definition 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
Virtualization, Over-The-Top
I. INTRODUCTION
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) [1]. The 5G leverages a set of
technologies such as Cloud computing, Network Function Vir-
tualization (NFV), Software Defined Networking (SDN), New
Radio (NR), Artificial 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 [2]. 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 fine 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 [3].
Depending on the use case, VNFs may be used with differ-
ent configurations (or flavors) 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 specific configuration for
each specific use case [4]. 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-defining 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 [5].
Mobile Network Operators (MNO) are actively working
in standard development bodies to define 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 identified. 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 efficient and multi-
tenant access to MNO’s mobile cloud resources. Main contri-
butions of this paper are two fold: (i) the identification 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-
91
2018 IEEE 8th International Symposium on Cloud and Service Computing (SC2)
978-1-7281-0236-8/18/$31.00 ©2018 IEEE
DOI 10.1109/SC2.2018.00019
tion II reviews the efforts in 5G from an NFV architecture
specification 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 [2]. In the
following, we provide insights on the NFV specifications and
review some of the open source projects that implement them.
A. Standard Specifications
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 [6]. This framework
defines 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
MNO logic.
Four data repositories are also defined by the NFV-MANO
architecture framework:
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 files, 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 diversified 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 [7]
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
scenarios.
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 [8]. 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 Specification 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, Workflow, and Policy en-
gines. The system provides a set of design tools such as the
Deployment Management UI and the Blueprint Composer for
designing blueprints.
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
[9] initially introduced in the previous release.
1https://cloudify.co
92
TABLE I
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,
OpenVIM
-service chaining
- 5G slicing
- MEC
ONAP NFVO, VNFM, VIM, NFVI, VNF
Catalog, NS Catalog Apache v2 Linux Foundation OpenStack -vCPE
- VoLTE
OPNFV NVFI Apache v2 (with
possible exceptions) Linux Foundation OpenStack, Kubernetes -vEPC
- vCDN
Cloudify NFVO, VNFM, VIM, NFVI Apache v2 (community edition)
Proprietary (entreprise edition) Cloudify Platform Ltd. OpenStack, VMware,
AWS, Docker
-vCPE
- SD-WAN
Open Baton NFVO, VNFM, VIM, NFVI Apache v2 Fraunhofer FOKUS and TU Berlin OpenStack, Docker
-multi-site
- extensibility
- interoperability
- vIMS
SONATA NFVO, VNFM, VIM, NFVI, VNF
Catalog, NS Catalog Apache v2 5G PPP 5GTANGO OpenStack, OpenVIM
-IoT
- vCDN
- vEPC
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 specifications. 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 [10], 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 specifications
[11] 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 specifications
within 5GPPP projects. SONATA is oriented towards use cases
such as Internet of Things (IoT) to monitor and optimize
network traffic, virtual Content Delivery Network (vCDN) to
improve the scalability and apply automatic configuration, and
virtual Evolved Packet Core (vEPC) to improve scalability,
resiliency, optimize placement.
The FP7 Mobile Cloud Networking (MCN) project builds
the foundation of [12] 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 [13].
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 benefits of this cloud computing
model and benefit 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 [14].
A. Cloud Native Computing Principles
Authors of [15] define 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 [16]. The benefits 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 certified
Kubernetes platforms, application deployments can be
described once and run across different cloud providers.
93
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 finalize the application speci-
fication 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)
[6]. Most notably, MANO provides standardized functional
blocks connected through well defined 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.
In particular:
Network function chaining. Lifecycle operations of ser-
vices (e.g. eNodeB) may involve the configuration 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 configuration,
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 [17]. The framework includes a set of specific
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, configuration, and API boilerplate
code creation. The practical uses of the framework in-
clude Service catalog or orchestration on top of public
cloud and unification of legacy VIM with cloud [18]
Tack e r is an official 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 benefit the Telco operators
in different operational areas. For instance, scalability and
quality of data intensive applications may benefit 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 configurations with heterogenous
providers is of paramount importance. Such design also bene-
fits introduction of new actors for RAN evolution: MEC appli-
cations, distributed CDN deployments, and BBU hostels [19].
Another advanced use could be prototyping and demonstrating
wide-scale pilots similar to A/B testing or Canary deployments
well known in IT industry [20].
IV. OVERVIEW OF 5G AS A SERVICE
The NGMN [4] describes new business models expected
with 5G among which asset providers, connectivity providers
and partner service providers following a flexible XaaS asset
provider model. The key requirement is that service providers
should be able to configure and manage the service, while
operators will manage and evolve the network [19]. 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 [21].
A. Architecture
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
94
URLLC application (Slice 1)
eMBB application (Slice 2)
mMTC application (Slice 3)
NBI
CLI
UI
API
5GaaS
NFV MANO
Programmable
Infrastructure
3rd party
applications
VNF_2 VNF_3
VNF_1
VNF_3 VNF_1
Access
network
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
field 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 configuration is setup (QoS,
duration, SLAs), the tenant can proceed to the deployment
phase. The Service Manager (SM) responsible for the slice
level information and configuration, 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 [6].
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
SO
1
SM UI/API
Status
update
Infra.
3rd party
application LM
Tenant
Onboarding
Status on consumed resources
Available resources
Slice
Creation
SO
2
Service deployment
Service
Provisioning
Resources
Update
Slice
decommissioning Service stop
Service
decommissioning
Resources
Update
Slice
creation
Slice
deletion
Fig. 2. User to system to infrastructure interactions within 5GaaS.
cellular network should be reserved. Once the configuration
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 configuration. 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 specified 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 notified 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 [19]. 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 definition
of a slice at the RAN level can involve scheduler configu-
ration, tenant specific 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 [19].
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 [21] 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:
95
Create, update and remove sessions identified by a unique
user ID (UUID). A session allows the isolation of tenants
on the same NFVI.
Create, update, remove configurations per session. Each
VNF can have several configuration templates.
Start, stop, and terminate VNF instances per session. An
instance is associated with a configuration 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 configuration interface that accepts configuration from
files, environment variables, and command line interface.
A logging interface to standard output, flat files, 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 configuration 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 briefly reviewed relevant activities in the standard and
open source communities to provide an insight into the NFV
industry and tried to redefine 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 reconfiguration in particular).
ACKNOWLEDGMENT
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
reflects the views of the authors. The Commission is not
responsible for the contents of this paper or any use made
thereof.
REFERENCES
[1] 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.
[2] J. G. Andrews et al., “What will 5g be?” IEEE Journal
on Selected Areas in Communications, vol. 32, no. 6,
pp. 1065–1082, 2014.
[3] A. Checko et al., “Cloud ran for mobile networks; a
technology overview, IEEE Communications Surveys
Tutorials, vol. 17, no. 1, pp. 405–426, 2015.
[4] N. Alliance, “5g white paper,” Next generation mobile
networks, white paper, pp. 1–125, 2015.
[5] 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.
[6] ETSI, “Network Functions Virtualisation (NFV) Man-
agement and Orchestration, ETSI GS NFV-SWA 001
V1.1.1,” 2014.
[7] A. Hoban et al., “Osm release four,” 2018.
[8] What is ONAP?, official onap developer wiki, https :
//wiki. onap.org/display /DW/Developer+Wiki. (visited
on 07/31/2018).
[9] OPNFV Release notes, https://www.opnfv.org/software.
(visited on 07/31/2018).
[10] 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.
[11] 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.
[12] MCN, http://mobile-cloud-networking.eu/site/,
Accessed: 2018-02-20.
[13] A. Edmonds, T. M. Bohnert, et al.,Final overall archi-
tecture definition, release 2, 2015. [Online]. Available:
http://mobile-cloud-networking.eu.
[14] 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.
[15] 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.
[16] The CNCF landscape, https://landscape . cncf . io /
grouping=landscape, Accessed: 2018-07-23.
[17] Ligato, https://github. com/ligato, Accessed: 2018-02-
20.
[18] The Gohan framework, https : / / gohan . cloudwan . io,
Accessed: 2018-07-23.
[19] 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.
[20] 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.
[21] C-OAI, https:// github.com /sofianinho /c - oai, Accessed:
2018-07-27.
96
... SFs, which are deployed on diverse IoT physical devices such as sensor networks and actuators, serve as the organizational structure for virtual network functions (VNFs). With the NFV, proprietary hardware can be moved to software's virtual servers and integrated with the cloud [15]. NFV can be used as a microservice-based network function running in peripheral devices, sensors, actuators, and computing nodes. ...
... Delay total(c) ← Dtotal(y)//get a copy of an array of total delay (14) Sort Delay total(c)(15) if Delay total(c)[0] > δγmax then(16) Return to 1 inTable 2//service is unsuccessful ALGORITHM 3: Delay calculation and fastest candidate node selection algorithm. ...
Article
Full-text available
The increasing heterogeneity of traffic in the Internet of Things (IoT) service demands presents a challenge for computing nodes to meet the computing resources and link bandwidth required. To address this, IoT requests have been virtualized and organized in service function chaining (SFC), which requires a host among hybrid cloud-fog computing nodes. To find a suitable host for each service function (SF) request, a typical migration algorithm has been used. However, this approach delayed the response due to propagation delays in searching for a valid nearby node. Mission-critical service demands may not even be served at all. This article addresses this issue by proposing two novel approaches: nearest candidate node selection (NCNS) and fastest candidate node selection (FCNS). These approaches employ software-defined network (SDN) controllers and the Markovian arrival process, Markovian service process, and single host (M/M/1) queuing model to monitor the maximum possible latency required to meet the SF service demand by each computing node and finally assigning into one with least latency. With the use of these methods, heuristic monitoring of computing resources is made possible, allowing the selection of the most suitable host computing nodes based on proximity or minimal round-trip time. Moreover, priority-based fastest candidate node selection (PB-FCNS), an adaptation of FCNS, accounts for concurrent service requests using the general arrival process, general service process, and single host node (G/G/1) queuing model. Compared to traditional migration algorithms, NCNS and FCNS provide significant improvements in reducing round-trip time by 5% and decreasing the probability of unsuccessful service function chains by 55%. Despite the cost of installation, employing these methods in conjunction with SDN controllers can reduce latency, maximize service success rates, and guarantee the delivery of heterogeneous service functions.
... While the emerging mobile core network can enhance deployment flexibility and scalability through cloud-native environments [12,13], several challenges need to be addressed in practical deployments at multiple edge nodes close to users. First, due to limited computing and data storage resources at edge nodes, the cloud-native network functions (CNFs) should be distributed across multiple edge nodes and run in response to terminal service requests following communication protocol procedures. ...
... The physical communication methods used within the cluster are also varied, including but not limited to fiber optic, wifi, microwave, as well as different types of satellites. Moreover, despite the various underlying communication methods used, the cloud-native edgemesh [12] technology shields the complex underlying topology, enabling the platform to be agile in the allocation and scheduling of business, tasks, and resources. The majority of nodes in the system are equipped with containerized 5G base stations, and the master node deploys a containerized 5G core network, granting access to numerous 5G terminals through the platform's southbound interface. ...
Article
Full-text available
Leveraging technological advancements such as containers, microservices, and service mesh, cloud-native edge computing (CNEC) has become extensively discussed and applied in both academia and industry. The integration of mobile edge computing and communication is crucial for the future communication architecture in order to fully utilize distributed and fragmented communication resources and computing power. The potential for cloud-native integration can help merge mobile edge computing and communication, enhancing network flexibility and resource utilization. This paper investigates the implementation plan for extending cloud-native capabilities to integrated computing and communication (INCCOM) in the satellite–terrestrial network. We construct an experimental verification platform called ComEdge in a real-world setting. Subsequently, we analyze the architecture, functional characteristics, and deployment of the platform in a real-world environment. Furthermore, we explore the solution of deep reinforcement learning in the deployment of cloud-native core network and conduct a preliminary verification of the platform’s potential to enable artificial intelligence in a real production environment, which will provide guidance to both academic and industry sectors. Finally, we conduct an analysis on the challenges and opportunities encountered by the cloud-native INCCOM network system.
... They also detail the prototype's standard-based viability and provide our open-source Cloud Native VNF API design, which is an implementation of the suggested design principles [40] ...
Article
Full-text available
Recent innovations in cloud computing have prompted a sea change away from monolithic systems to cloud-native architecture, enabling developers to build adaptable, scalable, and modular applications. Key technologies such as serverless computing, containerization, and microservices architecture are used in cloud-native development, enhancing operational efficiency, flexibility, and the deployment speed of applications in dynamic business environments. While these technologies allow organizations to build applications with improved adaptability, scalability and resilience, they also introduce challenges, including managing complex service dependencies, diagnosing failures, optimizing performance, and ensuring security in highly distributed systems. Moreover, managing stateful services and ensuring data consistency in the cloud environment can be particularly challenging. In this paper, the fundamental principles of cloud-native development are explored with focus on resilience, scalability, and elasticity while addressing the challenges faced by developers. Further, best practices like continuous integration and deployment (CI/CD), infrastructure as code (IaC), and security-focused DevSecOps practices are emphasized. Furthermore, a review of essential tools and frameworks, such as Kubernetes, Prometheus, and AWS CloudWatch, that assist in orchestrating, monitoring, and optimizing cloud-native systems is provided. The insights provided aim to guide organizations in adopting cloud-native technologies to build secure, high-performance applications.
... The authors in [33] propose an MECenabled network slicing using a cloud-native 5G microservices architecture. Whereas in [34], the authors use cloud-native principles and open-source commodity software to provide effective, multi-tenant access to mobile cloud resources of the Mobile Network Operator. They identify the challenges and the potential associated with switching the 5G cloud network's architecture from the old NFV design to the new cloud-native design. ...
Preprint
Full-text available
Emerging 5G/6G use cases span various industries, necessitating flexible solutions that leverage emerging technologies to meet diverse and stringent application requirements under changing network conditions. The standard 5G RAN solution, retransmission, reduces packet loss but can increase transmission delay in the process. Random Linear Network Coding (RLNC) offers an alternative by proactively sending combinations of original packets, thus reducing both delay and packet loss. Current research often only simulates the integration of RLNC in 5G while we implement and evaluate our approach on real commercially available hardware in a real-world deployment. We introduce Flexible Network Coding (FlexNC), which enables the flexible fusion of several RLNC protocols by incorporating a forwarder with multiple RLNC nodes. Network operators can configure FlexNC based on network conditions and application requirements. To further boost network programmability, our Recoder in the Network (RecNet) leverages intermediate network nodes to join the coding process. Both the proposed algorithms have been implemented on OpenAirInterface and extensively tested with traffic from different applications in a real network. While FlexNC adapts to various application needs of latency and packet loss, RecNet significantly minimizes packet loss for a remote user with minimal increase in delay compared to pure RLNC.
... In recent years, there has been a rapid development of network failure prediction methodologies as modern network frameworks become increasingly complex and uncertain. For network services like cloud-native functions (CNFs) and network function virtualization (NFV), network failures tend to become more complex and frequent [1], making proactive operations more essential. In reality, network failures such as gradual packet loss take a certain amount of time to impact service quality, which enables us to predict failures in advance to prevent potential service damage. ...
Article
This study evaluates an extended Berkeley Packet Filter (eBPF)-based network failure prediction method using Autogluon-Tabular to process the fine-grained network information extracted by eBPF. The extracted information is considered as input features of the proposed model, which aims to predict the subsequent packet loss and determine a network failure event before it causes a huge impact. Supervised learning and semi-supervised learning are both adopted in Autogluon. The accuracy and detection time are evaluated as the main criteria. Simulation results show that F1 scores exceed 0.9 for our proposed method, and the proposed method can achieve prediction for potential failure events within 30 and 40 seconds when symptoms such as packet loss occur.
Article
Virtualized Network Function (VNF) and Service Function Chain (SFC) are the fundamental components in Network Functions Virtualization (NFV) infrastructure, which supports the evolution of modern 5G networks. For online Internet of Things (IoT) applications, characterized by dynamic and diverse requirements, achieving optimal quality of service hinges on a resource-efficient yet performant SFC caching strategy, which is a critical challenge. Besides, despite the performance boost and flexibility brought by modern cloud-native technology, it brings the cold-start problem due to the requirement for runtime image transmission and booting-up, resulting in a non-negligible launch latency. To tackle these challenges, this paper proposes CPSC (Cloud-Native Parallel SFC Caching framework), a novel approach to address the cloud-native parallel SFC caching problem in edge-cloud networks leveraging Deep Reinforcement Learning (DRL), seeking an efficient resource utilization of the edge-cloud network with consideration of SFC processing performance and cold-start suppressing. Graph Convolutional Network (GCN) -based embeddings are adopted for topology-aware feature extraction of the substrate edge-cloud network as well as the incoming SFC caching requests. Then, a Pointer Network (PN) is utilized for contextual information-aware caching decision-making. Benefiting from the online capability of DRL, CPSC makes caching decisions in an online manner with no prior knowledge requirement on future incoming requests. Extensive simulations show that CPSC manages to outperform the state-of-the-art approaches in edge network acceptance ratio and launch latency, with minimal overhead on the SFC processing performance and decision-making duration.
Article
Full-text available
A cloud is a distributed Internet-based software system providing resources as tiered services. Through service-orientation and virtualization for resource provisioning, cloud applications can be deployed and managed dynamically. We discuss the building blocks of an architectural style for cloud-based software systems. We capture style-defining architectural principles and patterns for control-theoretic, model-based architectures for cloud software. While service-orientation is agreed upon in the form of service-oriented architecture and microservices, challenges resulting from multi-tiered, distributed and heterogeneous cloud architectures cause uncertainty that has not been sufficiently addressed. We define principles and patterns needed for effective development and operation of adaptive cloud-native systems.
Article
Full-text available
Cloud Radio Access Network (C-RAN) is a novel mobile network architecture which can address a number of challenges the operators face while trying to support growing end-user's needs. The main idea behind C-RAN is to pool the Baseband Units (BBUs) from multiple base stations into centralized BBU Pool for statistical multiplexing gain, while shifting the burden to the high-speed wireline transmission of In-phase and Quadrature (IQ) data. C-RAN enables energy efficient network operation and possible cost savings on baseband resources. Furthermore, it improves network capacity by performing load balancing and cooperative processing of signals originating from several base stations. This paper surveys the state-of-the-art literature on C-RAN. It can serve as a starting point for anyone willing to understand C-RAN architecture and advance the research on C-RAN.
Article
Full-text available
What will 5G be? What it will not be is an incremental advance on 4G. The previous four generations of cellular technology have each been a major paradigm shift that has broken backwards compatibility. And indeed, 5G will need to be a paradigm shift that includes very high carrier frequencies with massive bandwidths, extreme base station and device densities and unprecedented numbers of antennas. But unlike the previous four generations, it will also be highly integrative: tying any new 5G air interface and spectrum together with LTE and WiFi to provide universal high-rate coverage and a seamless user experience. To support this, the core network will also have to reach unprecedented levels of flexibility and intelligence, spectrum regulation will need to be rethought and improved, and energy and cost efficiencies will become even more critical considerations. This paper discusses all of these topics, identifying key challenges for future research and preliminary 5G standardization activities, while providing a comprehensive overview of the current literature, and in particular of the papers appearing in this special issue.
Article
Cloud-native features in your information technology (it) systems come with many advantages, but they also come with a cost. The costs vary greatly, based upon your applications and data. Sometimes being cloud native doesn’t make economic sense, and sometimes it does.
Imt vision - framework and overall objectives of the future development of imt for 2020 and beyond
  • series
M Series, "Imt vision -framework and overall objectives of the future development of imt for 2020 and beyond," Recommendation ITU, pp. 2083-0, 2015.
Prototyping nfv-based multiaccess edge computing in 5g ready networks with open baton
  • G A Carella
G. A. Carella et al., "Prototyping nfv-based multiaccess edge computing in 5g ready networks with open baton," in 2017 IEEE Conference on Network Softwarization (NetSoft), 2017, pp. 1-4.
Final overall architecture definition
  • A Edmonds
  • T M Bohnert
A. Edmonds, T. M. Bohnert, et al., Final overall architecture definition, release 2, 2015. [Online]. Available: http://mobile-cloud-networking.eu.