Toward a Reference Architecture for NFV
Abdulrahman K. Alnaim
Ahmed M. Alwakeel
Department of Computer and Electrical Engineering and Computer
Science
Florida Atlantic University
Boca Raton, USA
aalwakeel2013@fau.edu
Eduardo B. Fernandez
Department of Computer and Electrical Engineering and Computer
Science
Florida Atlantic University
Boca Raton, USA
fernande@fau.edu
Abstract— Network Function Virtualization (NFV) is an
emerging technology that has drawn the attention of the industry.
NFV aims to transform legacy network infrastructure into
virtualized networks. Instead of using dedicated hardware and
network equipment NFV relies on virtualized components to
deliver service to its users. In order to have a better
understanding of how NFV works and how can we enhance its
performance and security we must have a good understanding of
the underlying architecture of NFV. In this paper, we present a
UML class diagram for the NFV architecture, which describes
the main entities of NFV. Representing the architecture in a class
diagram is the first step toward building a Reference
Architecture (RA) for NFV, which is our final objective. A
Reference Architecture (RA) is a high-level abstraction of a
system that can be useful in the implementation of complex
systems. Moreover, we also represented some of the main
internal components as a class diagram to understand the
communication between these components and other system
components that together provide the full system. Finally, we
describe in detail some of their use cases.
Keywords- NFV, Network Function Virtualization; cloud
computing; ETSI; NFV use cases; NFV architecture.
I. INTRODUCTION
Telecommunication service providers (TSPs) need to have a
large variety of hardware appliances to provide useful services
to their users. With the increase of users’ demands for
launching new network services, TSPs have to spend time and
effort to deploy physical hardware and equipment for each
network function, in addition to the need of highly skilled
network designers and operators to deal with the complexity
of setting up and administering large networks. Furthermore,
the network life-cycle is becoming shorter due to the
acceleration of hardware continuous evolution. As a result,
this leads to increase the Operational Expense (OPEX) and
Capital Expense (CAPEX) for TSPs.
Network Function Virtualization (NFV) is a technical solution
that represents network functions in a virtualized manner by
decoupling hardware appliances (firewalls, gateways, etc.)
from the tasks running on them [1]. Instead of providing
network services to the users in a traditional way that relies on
hardware and dedicated servers, network functions in NFV are
978-1-7281-0108-8/19/$31.00 ©2019 IEEE
Department of Computer and Electrical Engineering and Computer
Science
Florida Atlantic University
Boca Raton, USA
aalnaim2017@fau.edu
built in software that is executed on a set of hosts using a
cloud infrastructure. This allows operators to provide
virtualized services such as virtualized firewalls and
virtualized gateways, as well as virtualized components for the
whole network. Providing virtual services to the users leads to
flexible network functions deployment as well as decrease the
time and effort needed to scale the network if all the functions
are provided through software instead of hardware [2]. NFV
promises the following benefits [1]:
1. Independence: software is no longer integrated with
hardware in NFV. As a result, their evolution will be
independent from each other.
2. Flexibility: the decoupling of software from hardware
helps to reassign and share the same infrastructure
resources, which allows to perform different functions at
various times. As a result, the deployment of network
functions and their connections becomes faster and more
flexible.
3. Scalability: decoupling software from hardware provides
more flexibility to dynamically scale the actual
performance of virtualized network functions with finer
granularity.
4. Reduced energy consumption: with the ability of scaling
resources up and down, TSPs will be able to reduce the
OPEX needed to run network devices.
NFV changes the telecommunication infrastructure from a
structure that mainly consists of proprietary hardware to a
more dynamic and agile structure that offers network
functions as software running on Virtual Machines (VMs).
Figure 1 shows the difference between the traditional network
approach and the NFV approach, in which the vertical
hardware boxes in the traditional approach that run network
functions are virtualized and called Virtualized Network
Functions (VNFs), running on VMs using standard hardware.
To further understand the implementation, design and security
aspects of NFV we must first understand its architecture and
how internal components interact with each other as well as
with other external components of other systems that interact
with NFV such as cloud systems. Once we have a firm
understanding of NFV architecture we can build a Reference
Architecture (RA) for NFV to represent how the system work.
The currently available architecture model in figure 2 is not
precis and vague in terms of how components interact with
each other.
Figure 1. Difference between traditional network approach and
NFV approach
Furthermore, in the future, the reference architecture could be
enhanced by adding different security blocks to evolve it into
Security Reference Architecture (SRA) that addresses some
common security concerns that may affect particular parts of
the system. In this paper, we present the general framework of
NFV provided by ETSI in [1] in a class diagram as a first step
toward building an RA for NFV. We will also represent other
main components of NFV as packages and finally, we will list
some of the main use cases for NFV as well as their main
actors whether they are internal actors from the system or
external an actors.
The rest of this paper is organized as follows: section two
provides a review of the topic of NFV architecture and use
cases. Section three discusses the architecture of NFV and its
main components. Section four discusses RA representation
for NFV as well as some use cases for NFV. Finally, section
five concludes this paper and discuss some future work.
II. RELATED WORK
The concept of NFV has been dealt with frequently in the
literature. Most work describes how and where the NFV could
be deployed, and what are the architectural requirements
needed to virtualize the network functions, conforming to the
NFV framework of the ETSI. [5] defined basic NFV
application cases using UML and explained the requirements
needed to design and deploy Network Functions-as-a-Service
(NFaaS) over a virtualized infrastructure. In their approach,
they adopted the high-level virtualization architecture of T-
978-1-7281-0108-8/19/$31.00 ©2019 IEEE
NOVA, an integrated research project focusing on NFV [6], to
define the business scenarios, roles, and stakeholders. [7]
presented a pattern for describing the general NFV
architecture; in this pattern, the service providers can build
network functions using IaaS and PaaS, and provide it as
SaaS. However, their focus was from a business and
marketplace perspective. [8] presented a pattern for Virtual
Machine Environment (VME) in which VMs can be created
and managed according to user requests. This pattern shows
how users can execute different types of operating systems
and applications in each VM; the VME can be used to
implement NFV functions. In [9] The authors presented a
more precise pattern for VME that focuses only on the NFV
system which tackled some of the main tasks for the
hypervisor of NFV and how VME for NFV differs from VME
for a normal cloud system in term of components interaction
and how the hypervisor manages networking components.
[10] considers the efficient configuration of service function
chaining to build secure customer networks using network
security patterns. This work complements ours by focusing on
a more specialized problem.
III. NFV ARCHITECTURE
In this section, we will discuss the main architectural
components of NFV. As indicated, the ETSI has defined a
general NFV architecture that includes three main components
(Figure 2) [1].
Figure 2. High-Level NFV Framework [1]
• Network Function Virtualization Infrastructure
(NFVI): is the foundation platform of NFV that
contains the hardware resources as well as the virtual
instantiations that build up the infrastructure on
which VNFs are deployed, managed and executed.
The NFVI can be part of the cloud Infrastructure-as-
a-Service (IaaS), which cloud providers use to create
Virtual Data Centers (VDCs) [11], containing all the
necessary virtualized computing, storage, and
networking to run as a physical data center. These
VDCs are provided to NFV providers, which in turn
use them to provide network services to NFV
consumers. The resources of a VDC provided to a
particular NFV provider should be isolated from
other providers; such isolation enables NFV
 providers to securely share the same cloud
infrastructure. In terms of NFV services, the VNFs
are deployed over virtual machines (VMs) within a
VDC.
As shown in figure 2, the NFVI consists of three
main components. First, the hardware resources that
contain compute facilities, which are normally
Commercial-Off-The-Shelf (COTS) appliances, the
storage hardware could be in form of direct attached
hard disks, external storage-area-networks (SAN) or
network-attached storage (NAS) [11], and the
network hardware may consist of
switches/routers that provide processing and
connectivity capabilities to VNFs through the
virtualization layer. Second, the virtualization layer,
which lies on top of the hardware resources layer and
contains the Virtual Machine Monitor (VMM) (also
known as the hypervisor), which has three main
roles: decouples the virtual resources from the
underlying physical resources, provides isolation
among VMs, and emulates the hardware resources
[12]. Third, the virtual infrastructure lies on top of the
virtualization layer and contains the virtualized
resources, which are abstractions of the hardware
resources; these abstractions are virtual machines,
diagram with some vague semantics which, as
indicated earlier, is not precise enough to be the basis
of security analysis.
• Virtual Network Functions (VNFs): are software
packages that represent the implementation of the
legacy non-virtual network functions that could be
deployed on the NFVI. A single VNF could be
composed of several internal components, such as
packet data network gateways (PGW), residential
gateways, firewalls, etc., in order to reduce
management and complexity in deploying it [1]. On
the other hand, a VNF could also contain only one
component in order to increase scalability and
reusability, as well as to have a faster response due to
its simplicity; keeping in mind that a single VNF
could be deployed and distributed across several
VMs [1]. Normally, the virtual network services
provided by TSPs are composed of several VNF
based on the users’ needs. Every VNF is connected
directly to an Element Management System (EMS),
which takes care of performing the typical
management functionality for each VNF connected to
it.
• NFV Management and Orchestration (NFV MANO):
is responsible for the management and orchestration
of all the virtualization-specific tasks required
throughout the lifecycle of the VNF, starting from
combining different services in one VNF package
until mapping this service to the users upon request.
MANO also handles faults that may occur in the
VNFs, as well as having state information about
978-1-7281-0108-8/19/$31.00 ©2019 IEEE
every VNF in the service. Furthermore, the MANO is
also responsible for setting up the communications
between different VNFs that together create the
network graph. A network graph is a set of VNF
services that combined provide the intended service
to the customer, i.e., they could configure a virtual
network based on the available VNFs. The MANO
contains three main functional blocks which are VNF
Manager, NFVI Manager and, orchestrator,
IV. NFV ARCHITECTURE MODELING
This section of the paper includes two subsections: in the first
one, we discuss NFV general architecture and some other
fundamental blocks such as NFV MANO and VNF using
UML class diagrams. Representing system component as a
class diagram is the first step toward building an RA for NFV.
In the second subsection we discuss some of the main use
cases for NFV systems as well as the main actors of the
system.
A. NFV struct modeling
We now describe the model of figure 2 in a more detailed and
precise way using a UML class diagram. Each unit present in
the ETSI’s architecture is described by a class and associations
are added between classes that show how the system units
communicate with each other. There are some additional
classes added to the class diagram of figure 2 to allow
interactions between the user and the system, such as the
Portal and the Account. We do not consider the use of brokers
in this architecture.
In figure 3, consumers access the NFV through a portal that
lets them request services and open accounts to charge the cost
of these services. The consumer class contains all the
information related to the consumer such as name and contact
information. As indicated earlier, the MANO is represented as
a package and its explained in more detailed in figure 4 noting
that the MANO controls/manages the virtualization
infrastructure as well as assigning virtualized resources to
VNFs. VNF is represented as a package as well and it is
illustrated in more details in figure 5 where Each VNF is
managed by an Element Management System (EMS), and
several VNFs form the network graph that represents the
whole network which the consumer gets.
The service and NFV infrastructure descriptions are associated
with the MANO and they provide the MANO with
information related to NFV infrastructure and service. The
Orchestrator controls user accounts in terms of privileges and
billing services as well which services belong to which users.
The VNFM manages the VNFs in the system. The VIM
manages the NFVI of the system. OSS/BSS class includes a
collection of systems/applications of NFV and it's associated
with the three main layers of NFV that are NFVI, NFV
MANO, and VNF.
Figure 4 illustrates the internal components of the MANO network. Each Network Graph represent a full
package. The VNF Manager controls each VNF in the system network service and assigned to an account in the
as well as managing the VNF catalog. VIM class takes care of system. EMS class takes control of operating the
everything related to network function virtualization VNF throughout the VNF life cycle. NFVI manages
infrastructure including hardware resource management and the resources of VNFc which include any virtual
monitoring. The NS catalog, NFV instance, VNF catalog and network component that together create VNF. NFVI
NFVI resources are all repositories that contain metadata also do several other tasks such as handling the
about different components that could be used to build an emulation process of hardware components into
NFV service orchestrator class takes care of the coordination Virtual network components. Each VNF in the
and management of different repositories that provide system is created from combining one or more
resources to create network services. Four different VNFCs combined.
repositories connected to NFV orchestrator which are NS
catalog which contain a list of usable network services as well
as a template for possible services to be provided to user ,NFV
instance which holds all details about network services
instances and how its related to VNF instances catalog which
contain description of VNF deployment and operational
processes and NFVI resources which contain all the resources
available to the system to establish NFV service. VNF
Manager is class to manage VNF through its entire life cycle.
VIM is connected to Network function.

Figure 4. Class diagram for the structure of MANO unit

Figure 3. Class diagram of the NFV

Virtualization Infrastructure (NFVI), which takes care of the

following
o Fault and performance management of
hardware, software, and virtual resources.
o Manages the life cycle of virtual resources
in an NFVI domain.
o Monitor the inventory of virtual machines
and which physical resources related to it.
o Manage the emulation of physical resources
into virtual resources.
• Figure 5 illustrate VNF package and its internal
components.
• A fundamental class is the VNF Manager which
takes control of each VNF in the system including
scaling up and down the VNF and monitoring it.
Each customer that uses the system can have access
to the requested network through a Portal; customers
can also modify the network and terminate the
Figure 5. Class diagram for the structure of VNF
B. NFV use cases
A use case represents a complete unit of interaction between
the users and the system as well as describing how the system
should respond under various conditions to a request from the
users [14]. Each main function in NFV is represented as a use
case, and each use case is associated with an actor or a set of
actors. An actor represents a user or automated system that
may interact with the system. Generally, an actor is a role
rather than being a specific person; an actor can be
distinguished through its tasks, and a single actor could be
associated with one or more use cases and vice versa. Use
cases are particularly important for security because we can

978-1-7281-0108-8/19/$31.00 ©2019 IEEE

use their scenarios to detect possible threats [2][14]. The use
case diagrams of figures 6 and 7 describe the set of main use
cases of the NFV. Note that the first two use cases (Create
VDC and Establish cloud SLA) are not different from any
other use of cloud services. These are the main actors of this
system.
B1. Actors
• NFV provider: provides complete networks and is
responsible for setting up Service Level Agreements
(SLA) with NFV consumers.
• Cloud Service Provider (Cloud SP): provides the
cloud services that act as a host for the NFV service.
The Cloud SP is responsible of setting up Service
Level Agreements (SLA) with the NFV provider.
The cloud SP may have other customers not involved
in NFV services.
• NFV consumer: is a person or institution that
receives network services from the NFV provider.
• NFV operator: responsible for the operation of the
VNFs of the NFV provider. He also adjusts the
networks offered to consumers in terms of security,
privacy, availability, and performance.
• NFV management and orchestration (MANO): in
charge of automatically controlling and managing the
resources of the service as well as the interactions of
Virtualized Network Functions (VNFs) with the
consumers. Furthermore, it manages business aspects
of the system such as billing and payment.
• Virtual Machine Environment (VME): is a unit
responsible for creating and managing all the
resources related to virtual machines in the system.
B2 Use cases
in this subsection, we list some of the main use cases for the
NFV system.
UC1- Create a VDC: NFV provider reserves hardware via
the Virtual Data Center (VDC) from the cloud provider to
compose network function virtualization infrastructures to
fulfill consumers requests as well as specifying the
interactions that take place when VNF services are composed.
Actors: NFV provider (main actor), Cloud SP.
UC2- Establish cloud SLA: set up a Service Level
Agreement between the cloud service provider and the NFV
provider that governs how cloud services are delivered and
managed, and states the level of availability, performance,
service continuity, as well as measurable target values
characterizing the levels of services.
Actors: Cloud SP (main actor), NFV provider.
UC3- Establish network SLA: set up a Service Level
Agreement between the NFV provider and the NFV consumer
that governs how communication services are delivered and
managed, and states the level of availability, performance,
service continuity, security, as well as measurable target
values characterizing the levels of services.
Actors: NFV provider (main actor), NFV consumer.
978-1-7281-0108-8/19/$31.00 ©2019 IEEE
UC4- Open account: the consumer opens an account in order
to use the network services provided by the NFV provider.
Actors: NFV consumer (main actor), NFV provider.
UC5- Close account: the consumer can close an account if he
does not need the account anymore or the account can be
closed directly by the NFV provider in case the consumer
violates terms of service or even for security reasons.
Actors: NFV consumer (main actor), NFV provider.
UC6- Manage network service: the NFV provider and
MANO manage network operations including allocation of
available resources as well as applications provisioning and
maintenance operations.
Actors: NFV provider, MANO.
UC7- Monitor network service: MANO monitors the
available and allocated resources, the status of the service, any
unauthorized or suspicious activity, and faults that impact the
service as a part or whole.
Actors: MANO.
UC8- Bill for services: The MANO charges bills for the
network services provided to the consumers.
Actors: MANO (main actor), NFV consumer.
UC9- Pay bill for services: The NFV consumer pays bills for
the service he uses.
Figure 6. Use Case model for NFV architecture (Part 1)
Actors: NFV consumer (main actor), MANO.
UC10- Request network service: NFV consumer requests a
network service, which can be handled by the NFV operator or
by the MANO.
Actors: NFV consumer (main actor), MANO, and NFV
operator.
UC11- Request network service change: NFV consumer
requests changing a service such as optimizing, configuring,
scaling the network or add a vFirewall to increase the security.
Actors: NFV consumer (main actor), MANO and NFV
operator.
UC12- Collect and forward consumers’ requests: the
MANO collects resource allocation, state information and
lifecycle management of VNFs.
Actors: MANO
UC13- Modify resources: upon the consumer requests to
change resources, the MANO modifies the virtual resources of
NFV services, such as increasing the storage of a VM.
Actors: MANO.
UC14- Consume Network service: the consumer uses the
network service provided by the NFV provider. Once the
consumer starts using the service, the MANO starts metering
its usage in order to bill the consumer for the provided
services.
Actors: NFV consumer (main actor), MANO.
UC15- Terminate network service: NFV consumer and
MANO terminate a provisioned network service either
because the consumer requested it or because the consumer
failed to pay for the intended service, or even for security
reasons.Actors: NFV consumer (main actor), MANO.
Figure 7. Use Case model for NFV architecture (Part 2)
UC16- Manage virtualized resources: MANO manages the
virtual resources, such as an inventory of hypervisors, as well
as virtual computing, storage, and network resources for the
NFV infrastructure.
Actors: MANO (main actor), VME.
UC17- Replicate VM: replicating a VM by the VME or the
MANO on the same host or another host; VM replication
provides fault tolerance.
Actors: MANO (main actor), VME.
UC18- Monitor VM: the MANO monitors the VMs’
performance and checks its status, as well as detects any
unusual activity on it, such as a VM monopolizing resources,
and trigger alerts in case of a problem facing a VM.
Actors: MANO (main actor), VME.
V. CONCLUSION AND FUTURE WORK
As mentioned earlier, NFV is a technology under
development. Looking at its literature, we found work on
specialized aspect, e.g. [15], [16] and [17], but a lack of work
where the relationships between the different components that
create NFV are exposed in detail. Consequently, the focus of
978-1-7281-0108-8/19/$31.00 ©2019 IEEE
this contribution is to understand the general architecture
components of NFV as well as illustrate the interactions
between its different stakeholders of NFV. In this paper, we
have proposed class diagrams as well as use case diagrams to
represent the NFV architecture. We also described some of the
use cases in detail to show the collaborations of actors and
objects using sequence diagrams. Having a good
understanding and representation of the components that make
NFV and how they interact with each other will help us in
creating a detailed reference architecture for NFV and can
help put in perspective specialized studies. Adding security
patterns to the RA to control the threats faced by the system
which we analyzed in [2], will lead to creating a Security
Reference Architecture (SRA), which is part of our future
work.
REFERENCES
[1] NFV, “GS NFV 002 - V1.2.1 - Network Functions Virtualisation (NFV);
Architectural Framework,” 2014.
[2] A. M. Alwakeel, A. K. Alnaim, and E. B. Fernandez, “A Survey of
Network Function Virtualization Security,” in SoutheastCon 2018, 2018, pp.
1–8.
[3] Hawilo, Hassan, et al. "NFV: State of the art, challenges and
implementation in next generation mobile networks (vepc)." arXiv preprint
arXiv:1409.4149 (2014).
[4]Mijumbi, Rashid, et al. "Network function virtualization: State-of-the-art
and research challenges." IEEE Communications Surveys & Tutorials 18.1
(2016): 236-262.
[5] A. C. Jorge Carapinha and J. Carapinha, “Requirements and Use Cases
System for Virtualized Network Functions Platforms,” J. Telecommun. Syst.
Manag., vol. 03, no. 02, pp. 1–11, Aug. 2014.
[6] “T-NOVA Project Website.” [Online]. Available: http://www.t-nova.eu/.
[Accessed: 21-Nov-2018].
[7] E. B. Fernandez and B. Hamid, “A pattern for network functions
virtualization,” in Proceedings of the 20th European Conference on Pattern
Languages of Programs, 2015, p. 47.
[8] M. H. Syed and E. B. Fernandez, “A Pattern for a Virtual Machine
Environment Virtual Machine Environment ( VME ).”
[9] A. K. Alnaim, A. M. Alwakeel, and E. B. Fernandez, “A pattern for an
NFV Virtual Machine Environment,” 2019 (accepted in the 13th annual IEEE
international systems conference 2019).
[10] A. Shameli Sendi, Y. Jarraya, M. Pourzandi, and M. Cheriet, “Efficient
Provisioning of Security Service Function Chaining Using Network Security
Defense Patterns,” IEEE Trans. Serv. Comput., pp. 1–1, 2016.
[10] E. A. – Henrik Basilier, M. Darula, and J. Wilke, “Virtualizing network
services – the telecom cloud,” 2014.
[11] SDX, “2017 NFV Report Series Part I Foundations of NFV : NFV
Infrastructure and VIM,” 2017.
[12] NFV, “GS NFV-INF 004 - V1.1.1 - Network Functions Virtualisation
(NFV); Infrastructure; Hypervisor Domain,” 2015.
[13] T. C. Lethbridge and R. Laganière, Object-oriented software
engineering: practical software development using UML and Java., McGraw-
Hill, 2001.
[14] A. M. Alwakeel, A. K. Alnaim, and E. B. Fernandez, “Analysis of NFV
Threats and Countermeasures in NFV Use Cases,” (accepted in the 13th
annual IEEE international systems conference 2019).
[15] F. Wendland and C. Banse, “Enhancing NFV Orchestration with Security
Policies,” in Proceedings of the 13th International Conference on Availability,
Reliability and Security - ARES 2018, 2018, pp. 1–6.
[16] V. Lefebvre, G. Santinelli, T. Müller, and J. Götzfried, “Universal
Trusted Execution Environments for Securing SDN/NFV Operations,” in
Proceedings of the 13th International Conference on Availability, Reliability
and Security - ARES 2018, 2018, pp. 1–9.
[17] A. Kalliola, S. Lal, K. Ahola, I. Oliver, Y. Miche, and T. Aura, “Security
Wrapper Orchestration in Cloud,” in Proceedings of the 13th International
Conference on Availability, Reliability and Security - ARES 2018, 2018, pp.
1–6.