A prototype 5G/IoT implementation for
transforming a legacy facility to a Smart
Panagiotis Papaioannou1, Nikolaos Tzanis2, Christos Tranoris1, Spyros
Denazis1, and Alexios Birbas1
1Dept. of Electrical and Computer Engineering University of Patras Patras, Greece
2Dept of Research, Technology and Development Independent Power Transmission
Operator (IPTO) Athens, Greece
Abstract. A typical factory consists of several low functionality sensors.
This work presents an architecture that can enhance the day-to-day op-
eration of the site by combining modern IoT and legacy equipment and
transforming the site for the 5G era. Operation and security of the site
will beneﬁt from the low latency the proposed Mobile Edge Comput-
ing architecture oﬀers. Constant and uninterrupted monitoring makes
preventive maintenance decisions even more accurate. Multitier archi-
tecture allows monitoring of each site to be performed locally without
delays, while overall monitoring and control of remote sites is feasible as
Keywords: Smart Factory ·5G ·IoT.
A Smart Factory is deﬁned as a smart and reconﬁgurable network of intercon-
nected sensors, machines, and production systems, which collect, exchange and
analyze data in a uniﬁed and automated way . It is characterized by the abil-
ity to collect, store, and handle large amounts of data, originating from diﬀerent
types of sensors, and support diﬀerent applications with diverse requirements.
Actions in a Smart Factory can be divided into three broad categories: opera-
tion, security, and maintenance. Maintenance activities require support of low
cost, energy eﬃcient sensors, planted in a distributed and heterogeneous infras-
tructure. Security and operation services ask for low latency and high reliability
communication and high bandwidth for CCTV. Modern trends in network archi-
tectures and virtualization technologies such as Multi-access Edge Computing
(MEC) and Network Function Virtualization (NFV), inherently supported by
5G, will be major enablers for the development of such Factories. MEC is used
?Supported by the H2020 European Projects 5G-VINNI (grant agreement No. 815279)
and 5G-VICTORI (grant agreement No. 857201)
2 P.Papaioannou et al.
to get processing power and storage capabilities as close to the edge of the mo-
bile network as possible. No longer is there a simple base station or a cell tower
but enough computing power to run services and applications near their source.
These services can beneﬁt greatly from the local processing by minimizing the
transport delay to the core network.
NFV architecture separates network functions from the underlying infras-
tructure, providing optimized reconﬁguration, easy integration of new services,
and guaranteed isolation, through the concept of network slicing. Application
and network functionalities are deﬁned as Virtual Network Functions (VNFs)
and orchestrated by an NFV Orchestrator (NFVO), responsible for the manage-
ment of virtual resources across multiple data centers.
Through ICT-17 projects , 5G testbeds become available to verticals to
test their applications and their beneﬁt from the services provided by 5G. To
this end, the 5G-VICTORI  project conducts large-scale trials for advanced
vertical use case veriﬁcation for Transportation, Energy, Media, and Factories
of the Future related use cases.
For the Factories of the Future use case, the project’s objective is to demon-
strate how the concept of Smart Factory can be substantially improved by the
services provided by an underlying 5G ICT infrastructure. Considering that tra-
ditional factories already use legacy infrastructure (sensors, networks, industrial
protocols) for their operation, the smooth transition to a new, modern factory
model must assure backward compatibility with the legacy equipment.
This paper describes the work in related to the Factories of the Future use
case, towards the transformation and modernization of the monitoring system
of a traditional facility for the 5G era, by introducing the NFV and MEC ar-
chitectures and incorporating the legacy equipment to the solution. The rest of
the paper is organized as follows: In section II the details of the use case tri-
als are presented. Section III describes the proposed architecture while section
IV details the infrastructure of the used testbed. In sections V two speciﬁc use
scenarios for our architecture are presented. Finally, we conclude this work by
presenting the results of our approach and our future directions.
2 Speciﬁc Use Case
The trial takes place at the Independent Power Transmission Operator (IPTO)
facility located near the University of Patras, Greece. The facility consists of two
diﬀerent sites divided by sea and electrically interconnected via a High Voltage
(HV) submarine cable and is ideal for demonstrating how applications of the
three diﬀerent classes (operation, maintenance, security) can be supported by a
5G enabled infrastructure.
Operation: The two sites serve as terminal points of the submarine cable and
are equipped with several hard-wired sensors, measuring various quantities such
as oil pressure level, battery level, etc. The sensors produce thousands of mea-
surements every minute, but only at local level, and provide limited information
5G/IoT Smart Factory 3
through indication lights. A uniﬁed monitoring system, able to process data from
both sites in real-time and generate alerts or auto trip signals in case of major
problems, will lead to great improvement in power quality, and support fault pre-
diction algorithms, minimizing the power network down-time. Since the legacy
sensors are not network enabled, the ﬁrst step is to enhance them with a network
interface. In this sense, legacy sensors will be ﬁrst connected to a Modbus TCP
interface and then connected via ethernet to the rest of the network.
Preventive Maintenance: The overall infrastructure at both sites needs con-
tinuous monitoring, to schedule timely maintenance activities and prevent equip-
ment degradation and failure. Currently, inspection of equipment, buildings, etc.,
is performed by personnel, and since the facilities are spread to remote and hard
to reach locations, this is a demanding and costly task. Preventive maintenance
applications collect measurements from sensors planted in key locations of the fa-
cilities, compare them with historical data and produce useful reports regarding
the health of the infrastructure. For this reason, several wireless sensors will be
planted to the facilities. Due to the enormous number of sensors that need to be
used to cover every inch of the facilities and the diﬃculty to access many remote
locations, low-cost and low-power devices must be used. This concept is directly
related to the massive IoT (mMTC) concept, where small and infrequent data
packets are transmitted from numerous standalone devices. The network tech-
nology providing connectivity to such devices must satisfy these requirements
and support high capacity and low latency for some use cases.
Security: The two sites also serve as local warehouses for IPTO, where pieces
of equipment such as copper cables and transformers are stored and maintained.
ADMIE facilities have been the victim of copper cable theft and vandalism for
several years. An advanced security system consisting of a set of FHD cam-
eras and motion control sensors will be deployed in the facilities. The deployed
equipment should be able to stream highquality data to be used complementary
to the sensors generated data. An application will process the generated data,
recognize unauthorized access to facilities and trigger corresponding alarms.
This particular use case can greatly beneﬁt by using a MEC architecture.
Operation and Security applications can meet their strict latency requirements,
by leveraging the local processing capabilities of MEC architecture. Preventive
maintenance activities also act on local level, so local storage and processing
of the data produced by the various sensors, can lead to substantial reduction
in cloud storage and communication bandwidth at the core network. Moreover,
since a Smart Factory is a continuously evolving system, new services may be
deployed in the future, especially in the areas of Industry 4.0 and 5G. In this
sense, the proposed architecture, shown in Figure 1, is easily reconﬁgurable and
expandable with the minimum cost and eﬀort.
4 P.Papaioannou et al.
3 High Level Architecture
In order to fulﬁll the requirement for local processing and storage at each site,
while also being able to connect and remotely conﬁgure the two sites as a uniﬁed
monitoring system, the end-to-end architecture depicted in Figure 1 is consid-
ered. A multi-tier architecture will be implemented, where each site is able to
perform local processing and storage activities, and information is forwarded
to the core cloud only when necessary. At each site, except from the already
installed sensors, new types of sensors based on a diverse set of diﬀerent tech-
nologies (5G, NB-IoT etc.) will be deployed, as well as the required network
elements that provide coverage to them.
Each site will have an Edge Cloud, consisting of a server with adequate
computational capabilities to support the use case applications requirements.
The server will host an Edge IoT Platform, responsible for the collection and
storage of the measurements originating from the diﬀerent sensors. Furthermore,
the server will also host a set of Virtual Network Functions to facilitate our Use
Fig. 1. Basic Architecture
NB-IoT Proxy: To support the NB-IoT connectivity, a VNF is deployed to act
as a gateway for the NB-IoT devices. Besides being responsible for the reception
and initial handling of the data received by the NB-IoT devices it also forwards
5G/IoT Smart Factory 5
these to the Edge IoT Platform. Further functionality, like decision making or
issuing commands to the NB-IoT devices can be added.
Optical Recognition: For other aspects of the use case, VNFs like optical
recognition for the cameras is also planned to be deployed on the Edge cloud.
Time critical services: For the real-time operation case, a VNF checking the
data received from speciﬁc Intelligent Electronic Devices (IEDs) and emitting
control signals to them, in case of emergency, will be deployed.
Edge IoT platform: The deployed IoT platform is EdgeX Foundry , an
open-source, vendor-neutral, Edge IoT platform, developed under the Linux
Foundation Edge umbrella. EdgeX Foundry acts as a middleware between the
various sensors and devices, and the vertical applications that use the informa-
tion provided by these devices. The platform’s architecture is depicted in Figure
2 and is organized as a set of diﬀerent containerized microservices, each one
belonging to one service family.
Fig. 2. EdgeX Architecture with added functionality
The Device Services family provide a southbound API with the diﬀerent de-
vices, sensors, and actuators. It is a set of connectors, encapsulating the speciﬁc
6 P.Papaioannou et al.
requirements of diﬀerent open source or proprietary protocols, and providing a
uniﬁed way for the interaction with the edge devices. These connectors are used
to collect measurements from the edge devices and translate them into meaning-
ful information or take commands from the vertical applications and transform
them into protocol-speciﬁc messages understood by the edge devices. As im-
plied by the name, the Core Services family performs the core functionality of
the platform. Core data is a centralized database for data readings collected by
devices and sensors, whereas core command enables the diﬀerent microservices,
applications, or external systems to interact with the end devices. The conﬁgu-
ration and registry services are used to conﬁgure the speciﬁc deployment (e.g.
add or remove a new sensor).
In our implementation, Modbus TCP and REST device services of EdgeX
Foundry are used. Modbus device service is used for data collection and issuing
of commands to the legacy Modbus sensors. The REST device service receives
measurements from sensors using protocols not currently supported by an EdgeX
device service. In this case, the NB-IoT-Proxy will be deployed as VNF, which
receives the NB-IoT capable sensors’ measurements, packets them in appropriate
REST requests, and transmits them to the EdgeX REST device service.
Central Cloud: The two sites are interconnected through a core cloud infras-
tructure. The central cloud also hosts a set of Use case speciﬁc VNFs such as
the IoT platform responsible for the collection, processing, and storage of the
aggregated data from the two sites. It also gives remote access to the end user,
and the ability to conﬁgure centrally the overall ICT infrastructure.
4 Infrastructure / Testbed
The infrastructure used for our experimentation is the Patras5G testbed in-
frastructure  , which currently deploys one of the main 5G experimental
facilities in 5G-VINNI , a European HORIZON 2020 project. This 5G facility
is used to host verticals and applications (in the areas of Media, Gaming, Trans-
portation and Energy) from two ICT 19 European HORIZON 2020 projects
(5G-SOLUTIONS  and 5G-VICTORI ) .
The main cloud platform is located inside Patras University, and can host
among others, 5G core network components and any NFV required for services
oriented to the supported verticals. The cloud platform oﬀers a total computing
power of 212 CPUs and 768 Gigabytes of RAM and 30 TB of storage.
Furthermore, the facility can also deploy outdoor MEC units capable of sup-
porting both cloud computing and 5G or other wireless connections. The main
MEC unit of the facility is the “5G Autonomous Edge” , a mobile box, built for
on-demand 5G deployments depending on the verticals’ use case requirements.
The Autonomous Edge (Figure 3) is based on 3 INTEL Xeon based servers giving
in total 16 cores, 128 Gigabytes of RAM and 1 TB of storage. Additionally, it is
connected with a 5G Software Deﬁned Radio interface. (Ettus USRP N310 )
5G/IoT Smart Factory 7
Fig. 3. Autonomous Edge and NB-IoT setup
Software wise, both core platform and MEC platform support the ETSI NFV
architecture. A basic element of this architecture is the Management and orches-
tration (MANO), which is the framework that coordinates the network resources
and the management of VNFs. Open Source MANO (OSM)  is the MANO
used, while the virtualized environment is based on Openstack .
ETSI OSM is an ETSI initiative to create an Open Source NFV-MANO
framework aligned with its reference architecture and standards. ETSI OSM
provides an end-to-end network service orchestration functionality through the
interaction of the core components of its architecture. The module Resource Or-
chestrator (RO) of OSM, plays a fundamental role since it is the block in charge
of managing the allocation of computational resources (i.e., the compute, net-
work, and storage). This accommodates the execution over an NFVI of various
virtual network functionalities included in a network service. For this purpose,
the RO supports the interactivity with a large variety of VIM solutions such as
On top of the core platform and any number of deployed MEC devices, the
Patras5G testbed infrastructure hosts an Operations Support System (OSS),
called Openslice . It supports VNFD/NSD onboarding to OSM and Network
Service (NS) deployment management, which allows control of what applications
and services can be run and deployed on our experimentation infrastructure.
Regarding 5G connectivity, the facility can support 4G/5G core services along
with the required radio using SDR based solutions. Both open source and com-
mercial implementations can be used and deployed as required. 5G capable UEs
include mobile phones and CPEs acting as gateways to legacy devices. Further-
more, NBIoT is also supported by the facility both in deploying such a network
and providing NB-IoT enabled devices such as the Sara R410 NB-IoT developer
boards . These devices connect through a deployed NB-IoT network and can
transmit information such as location, humidity, temperature etc.
For further support of the services provided by the Patras5G also provides
monitoring solutions if required that allow the gathering of various metrics (sys-
8 P.Papaioannou et al.
tem or network related) from the deployed services and deliver them to the inter-
ested parties. The solution used is Netdata  an open-source, performance and
health monitoring system for systems and applications which can be conﬁgured
to gather metrics from various sources.
For more persistent storage and centric oriented monitoring, an IoT platform
is deployed to gather data from each of the IPTO sites. Furthermore, VPN
services are also available for secure and isolated services among the users of the
Towards a realization of the proposed architecture, in this section, two diﬀerent
operational scenarios are presented. In scenario 1, the services collect, store, and
visualize a set of measurements from an NB-IoT gateway, whereas in scenario
2, the NB-IoT gateway and the EDGEX foundry are reconﬁgured by issuing
speciﬁc commands to them.
Scenario 1: Figure 4 illustrates the complete ﬂow for a set of measurements,
originating from a Sodaq Sara R410 NB-IoT  gateway, to the end user.
Fig. 4. Sequence diagram of NB-IoT data path
The NB-IoT device is connected to the NB-IoT cellular network, deployed
by the Limenet Mini , and periodically sends the sensor’s readings (temper-
ature, humidity and location), via a custom-made UDP client. The gateway is
conﬁgured to send a new set of measurements every 1 sec. The other end of the
connection is the NB-IoT proxy deployed as VNF.
At the NB-IoT proxy, a UDP server receives the UDP packet and extracts the
needed information. For each reading, a diﬀerent HTTP request is constructed
and sent to the corresponding REST device of the EdgeX Foundry REST device
5G/IoT Smart Factory 9
service. In this scenario, three REST devices named Sara temp1,Sara hum1 and
Sara loc1 are added in the conﬁguration service of EdgeX.
When the HTTP request for a reading is received by the assigned REST
device, the device service translates the request and stores the reading at the
EdgeX database via the Core Service functionality. From there, every vertical
application can access the data via HTTP GET requests. MEC approach allows
for the readings to be locally stored and further processed on site.
For real-time monitoring of the facility at a local level, a Netdata instance can
also be deployed at the MEC whenever requested. This is achieved by instan-
tiating a NS which deploys a VNF that automatically installs and conﬁgures
Netdata. This VNF can communicate with EdgeX Foundry through periodic
HTTP GET requests to collect and visualize the stored measurements. By ac-
cessing Netdata the site health status can be monitored locally. For a holistic
monitoring of the IPTO sites, and for applications that require synchronized
measurements from both sites, each MEC can also connect to an IoT platform
on the core network allowing the monitoring of all sites on central IPTO site.
Scenario 2: Besides getting measurements from the deployed devices, the archi-
tecture also allows for on-the-ﬂy conﬁguration changes on the deployed services.
This can be performed by using the day-2 conﬁguration capabilities of the OSM,
which allows us to send appropriate commands to the Network Functions to im-
plement our services. This scenario can be seen in Figure 5.
Fig. 5. Sequence diagram of control path
In this scenario two changes are performed to the previous setup. First,
OSM’s day-2 conﬁguration capabilities can be used to add a new device en-
try at the EdgeX foundry Core service. As a second change, a modiﬁcation of
the reporting period of the UDP client in the NB-IoT gateway is required. This
10 P.Papaioannou et al.
time OSM issues a command to the NB-IoT endpoint with the new reporting
period value. The NB-IoT endpoint then translates the command and forwards
it to the respected NB-IoT gateway through their communication path. Instead
of altering the reporting period , the command could refer to other conﬁgura-
tion allowed by the software running on those devices, providing a rudimentary
over-the-air update of those devices.
6 Conclusions and Future Work
This work presents current prototype results of the transformation process of a
legacy facility to a Smart Factory, adopting a cloud-edge architecture and mod-
ern 5G/IoT solutions able to support suﬃciently the diﬀerent services deployed
in a Smart Factory (operation, security, maintenance). By leveraging the con-
cepts of NFV and MEC, and a set of open-source applications (EdgeX, Net Data,
OSM), the IoT platform and related monitoring solution is centrally reconﬁg-
ured in a ﬂexible and cost eﬀective manner, in order to support new services,
especially in the areas of Industry 4.0 and 5G. Towards this realization, two
diﬀerent services are presented, one for NB-IoT sensors’ data collection, and one
for on-the-ﬂy reconﬁguration.
Our next steps will be to enhance the solution with new functionality for
the support of diﬀerent industrial communication protocols, and new types of
sensors. We will contribute to the open source community by extending the
capabilities of the EdgeX platform. Furthermore, we will take advantage of the
local processing capabilities provided by the architecture to achieve improved
real-time equipment awareness and develop smarter control techniques.
1. Smart Factory of Industry 4.0: Key Technologies,Application Case, and Challenges,
2. Information and Communication Technologies (H2020-
ICT-2018-20) Call https://ec.europa.eu/info/funding-
3. 5G VICTORI Homepage, https://www.5g-victori-project.eu/.
4. EdgeX Foundry Homepage, https://www.edgexfoundry.org/.
5. Christos Tranoris, Spyros G. Denazis: Patras 5G: An open Source based End-to-End
facility for 5G trial. In: ERCIM News 2019(117) (2019)
6. Patras 5G homepage, https://wiki.patras5g.eu/.
7. Horizon 2020 homepage, https://www.5g-vinni.eu/.
8. 5G Solutions project homepage, https://www.5gsolutionsproject.eu/.
9. Autonomous edge Homepage, https://wiki.patras5g.eu/5g-autonomous-edge.
10. Ettus Homepage, https://www.ettus.com/all-products/usrp-n310/.
11. OSM Homepage, https://osm.etsi.org.
12. Openstack Homepage, http://www.openstack.org/.
13. Openslice Homepage, https://openslice.readthedocs.io/en/stable/.
14. Sodaq Homepage, https://support.sodaq.com/Boards/Sara AFF/.
5G/IoT Smart Factory 11
15. NetData Homepage, https://www.netdata.cloud/.
16. LimeNetMini Homepage, https://limemicro.com/products/systems/limenet-