What Is the Best Solution for Smart Buildings? A Case Study of Fog, Edge Computing and Smart IoT Devices

Abstract

This paper presents a case study of Fog Computing, Edge Computing (EC) and Intelligent EC applied to Smart Buildings, focusing on the deployment of innovative services and smart IoT devices, discussing new architecture as Software-Defined Network (SDN). Specifically, a comprehensive solution of a Smart Building case is proposed to validate main statements and conclusions are drawn, providing a general guideline to address the problems of choosing between Edge or Fog Computing and the specific category of IoT devices. The methodology employed in this study is based on field research conducted in buildings within the metropolitan region of São Paulo, Brazil, that aim to enable their transformation into Smart Buildings (SBs). Moreover, principles of Electronic Systems Engineering and Cloud Computing such as reliability, scalability and security are applied. In that way, this study integrates advanced multimedia technical services to enhancing security and communication within the SBs through centralized control. The method focuses on identifying and analyzing the most common problems observed in field research within SBs in early stages of development, prior to the intensive implementation of IoT devices and Fog or Edge Computing technologies on the state of the art. The research adopts a comparative approach, investigating the best solutions for each application category. The results are consolidated in a main table within the article, correlating solutions to the four main problems identified in the field research, such as impairments in voice over IP and video communication using IoT devices; latency and delays in communication between SBs and the Cloud center; access security issues; and the Quality of Experience of video over IP communication, both in live transmissions and recordings between SBs. Regarding applications, this study considers the use of specific IoT devices and Cloud Computing architectures, such as Fog or IEC. Furthermore, it explores the implementation of new open network and communication models, such as SDN and NFV, to optimize communication between the various SBs and the SB’s connection to the control center of a Smart City.

1. Introduction

The case study in this article and its research content is an approach to Fog Computing and Intelligent Edge Computing (IEC) as applied to Smart Buildings and Smart Cities provided with suitable automation and intelligence for the management and control of smart Internet of Things (IoT) devices of different types. Over the last two decades, a novel architecture has emerged designed to be applied in data analytics and smart IoT devices. Fog and IEC are increasing their hold around the world for constrained applications by such factors as costly bandwidth, long latency and Quality of Experience (QoE) sensitivity or even needing high processing power and large storage for structured or unstructured data close to the place where data are generated or received by IoT devices.

Smart Cities encompass a diverse range of services across numerous domains, including traffic management, public utilities, environmental sustainability, water and electricity provisioning, and the seamless integration of buildings and neighborhoods with transportation and energy distribution networks, particularly for electric vehicles (EVs).

Furthermore, the application landscape extends to Industry 4.0, encompassing smart factories and precision agriculture, aimed at enhancing agribusiness productivity through the deployment of drones, IoT-enabled machinery, LoRa, WP-MEC networks, and advanced video and security surveillance systems.

A significant portion of these broad technological advancements in IoT and Edge services is being leveraged within Smart Buildings (SBs). This includes granular control of water and electricity consumption, implementation of environmentally sustainable systems, and the utilization of LoRa, Wi-Fi 6, and Bluetooth for smart IoT devices. The integration of Edge Computing with these smart IoT devices within SBs facilitates enhanced operational efficiency and intelligent automation [1].

The core of this article is the site where the computational power is to be installed and supplied with reference to the Smart Buildings in order to make it possible to carry on the operational study. This computing power may be concentrated within the Fog or the IEC or even yet in a hybrid solution as in the two cases cited in multi-cloud, which could be extended to the traditional cloud. A parallel discussion which is entertained concerns the ideal number of cloud providers which should be contemplated. We refer to Figure 1 [2], which illustrates an SB operating under multiple solutions and implementations.

The proposed use case is a Smart Building, or some federated or non-federated SBs, considering the main challenges to run secure data and voice services for several applications on SBs with Wi-Fi or LAN networks at the edge. Moreover, there is the problem of access and mobility of actors in SB complemented with voice over IoT (VIoT) technology and even IoT using video analytics.

Furthermore, the deployment of advanced services is considered, which may be demanded by a smartphone within the Smart Building or from the outside. And, also, federated entities in the Fog or the IEC may connect such as a chatbot for communication to and from the SB virtual or real doorman, advanced audio services such as videoconference or a conference call between actors, call forwarding, etc. Also, exclusive use of the complementary intra-condominium Wi-Fi network can be made, as long as the cost can be afforded, over 4G/5G networks through authentication applications for the actors by means of a smartphone and integrated smart messaging.

A large number of studies about the integration of cloud computing, either Fog or IEC, with IoT bring forward methods and beneficial aspects targeting the evolution in the application and use of the technology, discussed in [2,3]. In addition, there is much innovation underway ranging from new network models and open communications such as SDN, or even NFV which are being adopted by telecommunications operators.

Beyond that, it is possible to adopt a micro-services architecture for Fog and IEC, with applications running in containers integrated with data analytics for the acquisition, storage, and feedback of critical data analysis. Such data acquired or processed in large volumes over a short period of time may be optimally handled by ML in real-world applications [4].

Ultimately, a key contribution of this paper is the comparative study between Fog and IEC architectures, as well as IoT device categories, considering the current state of the art.

This article is organized as follows. Section 2 describes the methodology used for this research. Section 3 describes the main concepts and models and discloses a brief vision about relevant technologies while Section 4 discusses the primary references for this research followed by a wide overview of the sources for the case study as well as its main current and future challenges and contributions.

Section 5 outlines the main challenges of integrating Fog or IEC into a Smart Building or a federation of SBs. It summarizes the key categories and services in a central, guiding table for recommended solutions, considering both IoT devices and Fog/IEC, with and without SDN adoption. Section 6 details a paradigmatic use case of an SB within a Smart City, leveraging best practices and state-of-the-art research. Finally, Section 7 concludes this study.

2. Materials and Methods

This study employed a methodology based on recent research into Cloud Computing, Edge Computing and Fog Computing, along with the categories of IoT devices examined. This provided a comprehensive overview of the current state of the art. The focus is on determining the optimal solution for Smart Cities: Edge Computing or IEC versus Fog Computing.

The discussion is specifically narrowed to address the challenges within a single Smart Building, where an Edge solution was adopted or a federation of SBs using a Fog solution with the right category of IoT devices with a main focus on network multimedia traffic.

The methodology is based on field research conducted in buildings within the metropolitan region of São Paulo that aims to enable their transformation into SBs.

3. Concepts, Models and Technologies

This section provides a concise overview of the core concepts, models and technologies essential for comprehending this study and its future development.

3.1. Fog Computing

Fog computing facilitates the management of data consistency and access controls in scenarios where two or more small, independent, distributed cloud entities share resources including files, computational resources, commands and authentication or access to local data storage within each Fog node on Figure 2. The Fog architecture [5] represents a fully distributed, multi-tier cloud computing system integrating millions of devices and a large-scale network of interconnected distributed cloud data centers. This architecture is particularly well-suited for applications requiring low latency and real-time responsiveness, such as those involving IoT devices as presented in [2,6].

3.2. Intelligent Edge Computing (IEC)

The IEC, or its origin in Edge Computing, as shown in Figure 2 and [7], serves as a local source for data processing, storage, and computational needs within a broader cloud computing strategy. The most comprehensive definition of IEC is Edge Computing with enhanced intelligence in data handling, applications and communication representing a natural evolution of network and cloud computing architectures. So, to simplify notation, the term IEC is adopted.

Similar to Fog Computing, IEC is positioned closer to the edge in the layered model and is primarily designed for applications requiring real-time responses, low latency and connectivity to IoT devices [8,9]. Many times, edge nodes [10] are often implemented on high-end IoT devices, such as boards equipped with NVIDIA GPUs (high-performance) or from other manufacturers, as well as on desktop computers and laptops.

These nodes do not necessarily depend on traditional servers, which are typically required to provide high computational power and moderate storage capacity but are often constrained by cost considerations, [10,11]. The degree of maturity and security in these implementations has advanced significantly, enabling the adoption of more sophisticated models, depending on the specific use case.

Finally, given the extensive literature on cloud over the past fifteen years, the text simplifies the discussion by omitting a redefinition of Cloud Computing, focusing on pertinent topics related to the use case.

3.3. Software-Defined Network (SDN)

An SDN, software-defined network, is by definition an emerging, dynamic, cost-effective, manageable and highly adaptable architecture; in short, an ideal solution for the dynamic and broadband nature of real-world applications. The SDN architecture separates the network control and packet forwarding functions, allowing for network control to be directly programmable on switches and routers, and the infrastructure, in turn, to be made a new abstraction for network applications and services, according to the definition of the Open Network Foundation itself.

The advent of SDN initially brought Openflow [12] a way for researchers to program the API and open network interface of switches from various worldwide manufacturers, creating a parallel research network that was later used for business or production environments in the cloud. Although SDN is present in IoT research, its adoption remains moderate, and the fundamental drivers for this gradual implementation are not well understood. Current studies tend to prioritize the technical aspects of SDN integration with Edge Computing and Fog Computing, highlighting a significant need for further research into the motivations behind SDN adoption in IoT, as seen in the articles [13,14,15].

Fog and Edge computing architectures leverage and complement their implementations with SDN technology, which offers lower costs (as it operates under an open source model) and enhanced security through separation of the data and control planes in network SDN switches. Additionally, the large-scale adoption of SD-WAN, replacing MPLS-VPN for communication between Smart Buildings (SBs) or between an SB and its operations center within a Smart City or a federated SB neighborhood, further reinforces this integration.

Thus, in the present study, the focus on SDN is not on determining superiority or inferiority between these technologies but rather on emphasizing the cooperation among integrated architectures: Fog, Edge and SDN (SD-WAN).

This integration brings several benefits, such as reduced latency, enhanced security and an open source application development platform with APIs supported by a diverse developer community using multiple and common programming languages, including Java, Python, C and C++. All these elements work in a distributed computing framework, utilizing SDN switches and cloud providers’ microservices, which enable container orchestration mechanisms within a multi-cloud and SDN environment.

3.4. Network Functions Virtualization

Network Functions Virtualization (NFV) originated from discussions among telecommunications service providers about improving network operations in response to the significant growth in multimedia traffic volume. As a result of these initial efforts, in 2012, the European Telecommunication Standards Institute (ETSI) proposed the NFV framework. In the document produced, the ETSI working group outlined the overarching goal of NFV: leveraging IT virtualization standards to consolidate various types of equipment into a new industry standard for high-volume servers, storage systems, switches, routers and other network elements. These elements can be deployed across network nodes, data centers and routers or switches referred to by operators as Customer Premises Equipment (CPE), which are installed on the client’s or end user’s premises (at the network Edge) [11].

This initiative was driven by the extensive variety of proprietary hardware and software included in CPEs, which posed several challenges for operators. These challenges included the constant reinvestment in technological upgrades (CapEx - Capital Expenditure) that could not always be passed on to enterprise and public sector clients, as well as ongoing expenditures in training and recertification of specialized human resources. These factors highlight the fundamental motivation behind the development of NFV.

Currently, the main driver of NFV is the 5G/6G cellular network. NFV is a fundamental part of the 5G/6G network and, in fact, one of the requirements of its standards.

NFV is built on the standards of machine virtualization (VM—Virtual Machines) technology as presented in Figure 3, extending its use into the network domain, such as firewalls, caching, DNS, points of presence with web content (or Content Delivery Networks, CDN), etc., decoupling them from hardware or proprietary equipment to software solutions running on VMs [16].

A comprehensive understanding of NFV architecture needs additional research. Researchers seeking to expand their knowledge are directed to [16,17,18], which provide essential discussions and architectural insights to inform further studies.

3.5. Wi-Fi Networks (5 and 6) and WSNs—Wireless Sensor Networks (WSNs)

Wireless networking technologies, widely studied and popularly known as Wi-Fi, encompass standards such as the extensively used Wi-Fi 4 and 5 (or IEEE 802.11 b/n/g) as well as the latest implementations like Wi-Fi 6—IEEE 802.11ax. These technologies culminate in a vital product that supports users’ daily activities: WSNs in the IoT ecosystem—WSNs [15], along with relevant protocols and [19]—are designed to integrate seamlessly into use cases for Smart Buildings and, with the advent of 5G-IoT, into broader Smart City infrastructure.

Moreover, considering the Smart Cities, there is a new field of research about distributed computation offloading for energy provision minimization in WP-MEC networks using multiple points obtaining the amount of energy available through radio-frequency of mobile devices [20].

IoT Protocols: CoAP, MQTT in IoT and WSN and IoT Management

Wireless networks that control and interact with IoT devices, including wireless sensors and actuators, are becoming increasingly common. WSNs are now widely adopted in Smart Factory, Smart Farm, Smart Grid and Smart Building implementations. These networks and infrastructures utilize various configurations, such as mesh and non-mesh, while advancing significantly in routing protocols tailored for WSNs. For further insights, refer to the studies in [2,21].

The Constrained Application Protocol (CoAP) protocol of the IoT world, defined by the IETF in RFC 7252 [22] and with updates in subsequent RFC 7959 and RFC 8613, is a lightweight information transfer protocol designed for the Internet and integrates with the http protocol using message exchange, supporting multicast traffic, as seen in Figure 4. These protocols are of particular interest in the case of SB use, being used in restricted environments of various types of IoT devices, that is, an inhospitable environment subject to interference, packet loss, noise, less CPU processing use and low transmission power.

The CoAP protocol supports devices with a small amount of memory, high error rates and it is used in IoT and networks with low data transfer rates. The motivation for using CoAP is to bring the RESTful (Representational State Transfer) communication paradigm to smart objects, such as the IoT. Recalling the main idea of RESTful resource representations, they are exchanged between a server and an IoT device at the edge (client on the network).

CoAP integrates with the HTTP protocol, with support for multimedia traffic and low additional overhead. This message exchange is very similar to those known from HTTP. It meets the requirements for M2M (Machine-to-Machine) Internet protocols, uses the UDP protocol with support for both multicast and optional unicast traffic, also allowing for the exchange of asynchronous messages. It has simple and low-complexity headers and allows stateless http; that is, without any state, allowing for a possible proxy to access CoAP resources through the HTTP protocol [23].

3.6. Types of IoT Devices: (1) Low-End, (2) Middle-End and (3) High-End

Memory capacity and processing units are essential characteristics of embedded IoT devices, enabling them to perform the basic tasks required for proper functionality.

The study presented in the IEEE article [24] categorizes a wide range of models and manufacturers, widely adopted in the current decade, into three distinct groups and highlights their key features, advantages and disadvantages: low-end [25] (1), middle-end (2) and high-end (3).

It is an excellent guideline to support a decision to choose the right IoT device for a specific SB engineering and SB service demand. These IoT categories are exemplified and recommended for the use case discussed in Section 6 on SBs.

3.7. Voice over IoT—VIoT and Video over IoT

Real audio and voice traffic over IP operates through applications packaged by the protocol utilizing voice over IP (VoIP) technology, running on network or Internet infrastructures. Over the years, this has expanded with IPv6, distinguishing itself through client-to-client addressing and connectivity.

Regarding IoT devices, as previously discussed, there are middle-end or high-end boards or embedded devices and applications capable of running protocols such as Real-Time Protocol (RTP), SIP, and others. Applications with robust performance are referred to as voice over IoT (VIoT), featuring VIoT gateways that internally implement an SIP client to scale it. As detailed in [26], it will be applied with main links to connect with gateways or routers on the edge of SBs.

However, the integration, availability, response time and cost-effectiveness of a VIoT implementation are not necessarily straightforward. For example, in the case of the Smart Building use case, there is significant research potential in the integration of VoIP (using SIP) with the IoT edge or, more advanced, audio and video streaming, as well as the emerging video over IoT, which involves multimedia protocols, video compression and related technologies. To simplify implementation and account for critical, simultaneous data traffic on the same network, a Quality of Service (QoS) mechanism must be deployed. This mechanism ensures an optimal Quality of Experience (QoE) for the services provided to users by the service provider.

3.8. Machine Learning (ML) and Deep Learning (DL)

Machine learning enables computers to learn from data through optimization techniques or control mechanisms by leveraging calculations and weight adjustments. ML, along with its subcategory DL, has captured significant attention in recent years, particularly in the fields of data communication networks, audio signal processing, voice and video over IP, discussed on [4,16,27]. Given that networks play a fundamental role in distributed learning systems—including collaborative learning at the edge, whether via Fog Computing or IEC—it is understandable that research in this area has seen substantial growth [28].

With the advent of cloud computing and the adoption of application architectures based on containers, companies and research centers have observed increasing complexity in network infrastructures and data centers, along with their configurations and the rapid expansion of applications operating within this new architecture. This scenario demands network intelligence with a more holistic perspective to address critical issues effectively.

The complexity is already evident in metropolitan wireless networks, large public or private spaces, and Smart Cities, particularly with the explosion of 5G and 5G-IoT networks [7]. This complex environment presents a fertile field for research, especially in the context of distributed application approaches.

3.9. Containers and Cloud Microservices Architecture

In the case of applications controlling IoT devices within a Smart City or Smart Building, as well as in Smart Grid scenarios, an important middleware software component known as the Content Broker(CB) plays a key role. The CB acts as middleware between software systems, databases and various IoT applications. On the other edge, it manages IoT devices through protocols such as CoAP, SIP/RTP or MQTT, enabling real-time data collection and transmission with low latency.

The European organization Fiware.org [29] has gained prominence in recent years for its reference architecture, which incorporates one Fiware Content Broker. In the subsequent case study on Smart Buildings, a simplified architecture will be adopted, leveraging CBs for integration with both Fog Computing and IEC.

The integration of SDN with Fog or Intelligent Edge Computing is recommended due to SDN’s decoupled control and data planes, which facilitate enhanced network flexibility and management. Extensive deployments have demonstrated the efficacy of this integration in Fog and Edge Computing environments, as evidenced by service providers’ adoption of SD-WAN [13]. Consequently, this integration represents an important decision parameter within the Smart Building study case in Section 6.

The rationale behind the research techniques proposed in this study lies in addressing the challenge of selecting the most suitable network architectures and solutions between Cloud and Edge Computing, given the current state of the art in technology. Additionally, a secondary objective is to contribute to the positioning and development of real-time multimedia applications at the network edge, using high-performance IoT devices. For example, the proposed application of VIoT gateways serves as a very interesting case study to understand its behavior on SBs [26].

4. A Comprehensive Survey and Related Works

In summary, considering the referenced research, the articles originating from IEEE studies and others related to the present study were selected, presenting the indicated references and the problems presented, as well as their respective solutions. This research will be the effective ’procedure for validating’ the solutions adopted in the cells of Table 1 of Section 6. The discussion follows with the six primary references of the chosen research and brief comments:

In their article [2], Dutta et al. explore the architecture of Fog and cloud-based systems for a Smart City, culminating in a simplified case study of a Smart Building. The authors highlight the significant volume and variety of data generated by SB sensors, advocating for the use of wireless sensor networks where feasible. Their proposed architecture, in our interpretation, leans more heavily on IEC than Fog computing—a common observation in the literature, given the frequent interchange of acronyms and architectural models. They conclude with the implementation of a small-scale system or prototype to run inside the SB, detailing the roles of both cloud and Fog layers; see also some interoperability requirements for a Smart City in [30,31].

Garcia Jordi et al. [31] conducted a significant study focused on the Smart City of Barcelona, encompassing its advanced public services and select private partnerships for citizens and visiting tourists. They recommend that other cities follow and evolve in the adoption of Fog Computing for urban environments like Barcelona.

The authors conducted an estimation and survey of the quantity of cars with on-board computers, Wi-Fi access points, routers, embedded computers, smartphones, etc.…, to quantify, through their study, the dispersed and already installed Fog or Edge Computing capacity within the city (serving as a “baseline”) and to develop a plan for future capacity expansion needed to support urban growth.

Consequently, the proposal suggests that the millions of computers present within the city could operate in a clustering configuration. This approach, when compared to the computational power of one of Amazon AWS’s largest data centers at the time, with nearly 100,000 servers, for example, leads the authors to assert that the Fog cluster of Barcelona alone would have a computational power 10 to 20 times greater than this AWS data center. This study validates the adoption of Fog Computing for a certain number of buildings and/or densely populated neighborhoods with a significant aggregate computational volume within the city.

The article [32] and secondary reference [7] offer a more structured delineation of application layers (Cloud and PaaS) residing in the cloud, the Fog layer and the IoT device layer. These works highlight key concepts such as Mobile Cloud Computing (MCC), Mobile Edge Computing (MEC), Mist computing and cloudlets, driving substantial research between 2017 and 2023. Furthermore, reference [32] delves into the design of intelligent edge systems for Smart Cities, promoting the use of data analytics to enhance urban management and decision-making. The implementation of surrogate nodes (or Fog nodes) is an important baseline for these cities, alongside the challenge of developing applications for highly dynamic environments [32]. This necessitates addressing technological gaps in existing systems designed for cloud deployment, rather than Fog or IEC environments. The authors ultimately propose a novel programming model to solve this issue.

To further clarify this discussion, K. Shafique et al. [7] complement the overview by addressing heterogeneous networks: HetNets, M2M and Narrowband IoT (NB-IoT) and the new landscape emerging with the advent of 5G cellular networks, leading to new technologies such as software-defined WSN and the use of ML and DL. Beyond the requirements for achieving optimal QoS in the proposed new 5G-IoT implementation for high data rates, based on large volumes of IoT devices [33], the authors highlight real-world applications and modules for Smart Cities, buildings, universities [34], smart grids, health, transport and smart industry, including a brief history of network evolution from 2G to the current 5G standard.

Regarding network convergence and the integration of cloud, edge and fog computing, a study [16] explores opportunities to apply DL methods across various network layers. The researchers delve into the potential of utilizing DL in Fog or Edge Computing. Recommended application areas include online content delivery, streaming, routing control, traffic control and QoS optimization. The study presents compelling results on its tables about edge optimization using DL in various application scenarios and models, showcasing the advantages of bringing decision-making closer to the network edge.

The new article of 2025, reference [35], offers a comprehensive review of the Smart Readiness Indicator (SRI) literature, analyzing the evolution, applications and limitations of the SRI framework in the context of SBs.

The study employs a systematic literature review, including qualitative analysis, to evaluate the current state of research on the SRI. The bibliometric analysis reveals a growing research interest in smart readiness, particularly concerning energy efficiency and SBs. The qualitative analysis identifies key themes in SRI research, such as its applicability across different contexts, biases due to subjectivity in assessments, alignment with other standards and its role in smart retrofitting, highlighting areas needing further exploration to advance SB evolution.

The qualitative analysis of the SRI literature reveals key themes that highlight areas for further exploration in advancing Smart Building evolution. Notably, the applicability of the SRI across diverse contexts requires nuanced consideration of climatic influences, occupant behavior, energy perspectives, economic viability and social impacts.

This review contributes to the ongoing discussion about the SRI’s role and its tool in evaluating and promoting smart, energy-efficient buildings, offering insights for future research and development in this evolving field [36].

Mohamed’s research [37] proposes a service-oriented middle-ware called Cloud of Things and Fog supporting a wide diversity of applications in the Smart City, and develops a conceptual study and the main functions of the middleware called SmartCityWare. SmartCityWare is an example of a proposed architecture, including for the SB of the present study, with the implementation of a prototype with an experiment of Java agents distributed in IoT devices and Content Broker.

The middleware application developed by the authors meets eleven requirements to develop and operate the various services of the SmartCity adopting Fog computing and distributed application in the main locations with computational intelligence. Using APIs and SOAP connected through Fog and then replicated directly with the cloud, they make an application to compare the call response time (lookup time) of an IoT service running locally on SB, with an expected success for the experimental application in Fog.

Yasmeen et al.’s 2018 study [38] aligns well with the Fog-based approach advocated in this research for a federation or geographically proximate set of Smart Buildings. The authors propose a Fog-integrated smart grid application model, dividing it into the three well-known layers: the end-user layer (or SB layer in this study), the Fog layer and the cloud-based central layer, as seen in Figure 5 [38,39]. They propose novel load-balancing algorithms and conduct response time simulations using a newly proposed tool, CloudAnalyst. This work suggests a promising avenue for future research.

Focusing on the network edge and IoT device deployment, the Italian study [24] provides a valuable overview of globally deployed devices. It presents a comprehensive review of various vendor models, categorized into low-end, middle-end and high-end devices based on features such as computational power, memory and storage. This study highlights the rapid technological advancements, including sensor technology, in embedded IoT board development. This provides a crucial informational foundation for implementations and adoption in the Smart Building use case of this research.

Moreover, as a complement to this article and with a focus on network management, there is the article [40] exploring IoT low-power network management and the client–server protocol LWM2M applied to the IoT world.

Subsequently, Camerlynck et al. [26] propose a VIoT framework, aiming to integrate VoIP with advanced services such as unified communication, collaboration and omnichannel capabilities.

This integration leverages high-performance IoT devices exceeding the capabilities of the middle-end devices described in the previous study, incorporating video calls (audio and video). The authors innovatively explore the convergence of VoIP protocols and IoT device challenges, proposing an integrated architecture by bridging the communication protocols of both domains. This approach informs the design of the virtual concierge and novel VIoT intercom system, with or without video, for security and communication within the SB case study. The authors also detail a mechanism for implementing a VIoT gateway by adding an SIP client to facilitate this integration of two worlds.

The major knowledge gap identified in the literature review of this section is that, currently, there are few studies that delve into the adoption of SDN and SD-WAN, and the NFV offered by Service Providers (current focus on NFV and 5G network) for use cases such as those of the SBs in the present study.

Furthermore, there are few studies on the integration of SDN and NFV with smart IoT devices and their communication protocols, such as WSN, LoRa, routing and mesh protocols for IoT device and VIoT, already implemented in buildings (SBs or some partially intelligent) at the edge. The following articles are focused on IoT-5G and network-slicing: [7,30,40,41,42].

It is noted that the referenced literature [2,3,10,13,41] presents many segregated studies, such as cloud solutions and their distributed microservices architecture, Fog and Intelligent Edge Computing (IEC) with advantages over the traditional on-premise Data Center, security of SBs, SDN and SD-WAN replacing MPLS-VPN in new implementations by service providers, multimedia applications (video, streaming and voice over IP) optimized for jitter, latency and packet loss in Internet communication using the protocols mentioned in Section 3 for other use cases, such as the industrial one.

However, there are some gaps in the integrated proposal and implementation of the above technologies that aims to discuss and guide towards feasible solutions and a good cost–benefit ratio for the condominiums of metropolitan buildings, an important aspect covered by the present study. For example, the review of the network and application management layer critical to this user regarding the SDNs, Fog and Intelligent Edge Computing technologies integrated with the smart IoTs of the user layer is part of the process.

5. Main Problems and Proposed Solutions Using FOG or IEC in Smart Buildings

Following the comprehensive literature review in the Section 4, this section addresses key challenges and issues related to the three-layer architecture: Cloud, Fog/IEC and the user layer with edge IoT devices. The discussion focuses on QoE for users, solution availability, some security challenges and associated problems.

The methodology described in Figure 6 follows a structured approach, beginning with the identification and prioritization of key problems in SBs. Initially, a controlled set of problems is selected from real-world cases in the metropolitan region, covering one commercial and three residential buildings (I).

To refine the problem selection process, six key factors (I) are applied: service availability and uptime (SLA), quality of service delivered, user safety, cost to residents, available technology and operational stability of service providers. This leads to the classification of main problems (II).

Among specific problems or the key challenges identified in (II), four main specific problems were selected for deeper investigation: jitter, background noise, Wi-Fi and its interference signals; latency and packet loss between SB and Fog or between Edge and Cloud; security challenges, data privacy, data governance [43]; and QoE regarding video streaming and VoIP communication (inside SB and external with Cloud).

A qualitative analysis of twenty-four potential applications is performed, converging into eight selected Application Categories, as outlined in Table 1. Each selection is based on four criteria: recent technological advances, security and reliability, ease of deployment and maintenance and usability for different SB actors.

Once the primary challenges and application categories are defined, two key research dimensions are investigated for each cell in Table 1 (III) and (IV):

(A) What category of IoT devices (low, medium or high-end) should be adopted?

(B) Which Cloud architectures (Fog or IEC) provide the most optimized design, with or without SDN and NFV integration?

These evaluations guide the selection of the most suitable technology and architecture for each specific SB scenario.

A validation procedure, (*) in Figure 6, is integrated into the methodology, ensuring the robustness of all proposed solutions. This validation involves rigorous field research and a comparative analysis of similar solutions presented in the cited literature. This final step ensures that the recommendations align with real-world constraints and operational demands.

The adopted term Application Category can be expanded to category of Hardware plus Software or platform.

Considering that, the cells in Table 1 indicate two simultaneous proposed solutions for each application category described in the rows of the table.

These main four challenges and issues are detailed as follows:

a.

Network-relevant noise and jitter: significant jitter, noise and interference from the SB’s Wi-Fi network and other unforeseen sources may negatively impact communication with the Fog or IEC [44].

b.

Cloud Communication Latency: Latency in communication between the central database, dashboard and applications within the Cloud-based Operational Control Center (CCO or OCC)—integrated with the Fog/IEC and interconnected to one SB or more federated, independent SBs—presents a challenge [44,45].

c.

QoS and QoE Optimization: Optimizing QoS and QoE, particularly for VoIP, VIoT and short-form video streaming (video over IoT), and ensuring reliable video recording for emergency situations, requires attention [41,46]. Later, in Section 6 of this study, these metrics of QoS and QoE are detailed.

d.

Security and Access Control: Enterprise clients (or federations of SBs) using the Fog layer require seamless access to multiple cloud services through a single authentication mechanism for both users and IoT devices [47,48]. Implementing robust security measures is therefore crucial for protecting the privacy of residents, employees and visitors, and ensuring secure access to SB facilities while maintaining cost-effectiveness.

Furthermore, the implementation of a robust security layer is imperative to mitigate Denial-of-Service (DoS) attacks targeting IoT devices, Wi-Fi access points within Smart Buildings (SBs) and their ingress routers or gateways connected to service providers. This security layer is a fundamental requirement for both Fog and Edge computing architectures, as such attacks are agnostic to the chosen paradigm. There are several solutions proposed and discussed in [39,48].

Figure 7 illustrates a general solution to the aforementioned issues and challenges, exemplified by a VoIP call, chosen as a representative SB and VoIP application. The Figure uses VIoT as an application example for both Fog and IEC deployments, employing machine learning algorithms at the call origin to mitigate background noise. Adaptive Real-Time Control Protocols (RTCP-IoT) [23] are also utilized during the VIoT call. Figure 7 depicts the main call flow from origin to destination, with the lines (arcs, edges, connections) representing unidirectional or bidirectional VoIP (SIP/RTP) packet streams.

The solutions presented in the cells of Table 1 directly relate to Figure 7.

Table 1, which includes a glossary of abbreviations and acronyms (e.g., Fog with SDN or NFV (FSN), FOG, IEC with SDN or NFV (ISN), IEC, and ANY [representing Any of the previous architecture alternatives], or (—) [not applicable]) further detailed in Table 2, outlines key challenges and issues in the columns (items a.–> d. previously detailed), those which must be addressed for one or more SBs and various application categories (rows of Table 1) within the proposed SB use case. The table further proposes optimal solutions based on two main implementation approaches:

(i) 

Intelligent IoT Device Selection: This approach focuses on determining the optimal IoT device category (1) low-end, (2) middle-end or (3) high-end—as detailed in Table 2—to achieve the best cost–benefit ratio. The goal is to avoid unnecessary expenses by selecting the most appropriate category for the various IoT devices deployed within the SB [49].

(ii) 

Network Architecture Selection: This approach focuses on selecting the optimal Fog or IEC network architecture for the proposed use case, based on the three-tier cloud computing model: with Fog or IEC as the intermediary layer, as detailed in the Table 2. This includes considering the adoption of open SDN and/or NFV technologies.

The decision to adopt SDN or NFV is a difficult decision and is more justifiable for federations of SBs or regional service providers serving numerous SBs within a defined geographical area (e.g., a large neighborhood or municipality).

Future work will expand upon this study and refine this central Table 1 to further aid in decision-making. The optimal implementation decision will depend on factors such as the number of SBs (one or two buildings in close proximity, or a larger geographical complex), the size of the residential/commercial complex or the scale of a clearly defined federation of SBs within a specific neighborhood; moreover, the indicated articles’ research complements this decision-making process.

6. Use Case of One Smart Building and Its Applications

This section aims to discuss a simplified real use case that applies the results from Section 5 and consolidates the research presented in Section 4. This provides a novel and comprehensive perspective on SBs, paving the way for future advancements considering emerging scientific developments in IoT, Fog and IEC.

Section 1 examines SBs within the context of Smart Cities, highlighting their rapid growth internationally, including Europe –Fiware.org [29], the USA and some eastern countries. This growth introduces significant innovations in communication engineering, cloud computing and high-performance IoT devices.

The proposed use case of just one SB with fifteen floors and sixty apartments is deemed suitable for this study due to the significant number of parameters involved in the decision-making process.

The proposed SB solution utilizes VoIP and video equipment, typically embedded within IoT devices (as detailed in Section 4 and Table 1), offering a suitable number of interfaces for easy integration into the SB’s wired and wireless local area networks.

These IoT devices, connected by VIoT gateways, integrate IP phones (replacing traditional intercoms and potentially fixed-line phones), temperature and fire sensors, actuators, RFID and biometric readers, analog-to-digital converters for actuator control, IP cameras and other typical devices adopted in a SB [50].

Overall, the SB solution aims for secure, robust and reliable applications with consistent performance and the delivery of excellent QoS, resulting in a desirable QoE for users. Finally, this use case emphasizes high availability for edge solutions, parameters that should be regularly monitored within service contracts and their SLAs, long-term contracts spanning several years.

To streamline the solution, the scope of the proposed SB is reduced to a single local server and an application running with less than five containers and a single CB, as suggested by Fiware. Only the most relevant applications, with direct connectivity to the chosen Fog or IEC architecture under discussion, and adding the recommended IoT devices category, are detailed here:

(i) 

IP telephony and VoIP [51], video recording and structured and unstructured database applications.

(ii) 

Directory applications with permissions for various user types, access levels, credentials, and a comprehensive identity and access management (IAM) system [47].

(iii) 

Centralized control and monitoring dashboards via the Operational Control Center (CCO or OCC) operating on the selected cloud platform.

(iv) 

Visitor authentication applications: biometric authentication, facial recognition, QR code or physical token access [47,52].

(v) 

Applications for SB access control and authorization, including a virtual concierge linked to the CCO or OCC. This may also include user-friendly applications such as smartphone apps, video communication [52] and intelligent chatbots, as well as internal IP telephony within the SB’s commercial or residential areas [27]. These cloud services are integrated with the local SB desktop PC or local SB server to complement the solution.

Alternative architectures could involve a centralized environment through the federation of SBs and Fog nodes, or SBs with internal IECs. The latter is generally suitable for a small number of towers in commercial or residential SBs. For simplification, this proposal and study limit the scope to one or two building towers to be exhaustive.

This results in a comprehensive suite of applications, storage and high-capacity data analytics integrated via Fog or IEC with intelligent IoT devices at the SB’s edge. These data are stored in the central cloud database, which interacts with the Fog or IEC [4].

In the single-tower scenario, an IEC infrastructure is deployed within the SB described in detail in this section. For security and high availability of data, voice and video communication (VIoT and VoIP), redundancy and a reliable fail-safe system are implemented. In the second hypothetical scenario involving multiple SBs, a Fog computing approach or a hybrid Fog and IEC model is adopted; this implementation is out of the scope of this study.

This ensures the necessary SB functionality and acceptable SLA (as contract), minimizing deployment and operational costs, and enabling rapid recovery from disasters to prevent serious problems for residents, such as prolonged power outages (several hours), partial building fires or unforeseen temporary service disruptions; for example, last-mile network outages or edge server failures, despite the proposed redundancy in a single SB.

The values in each cell of Table 1 reflect the findings from the literature review in Section 3 and represent an optimized framework based on three factors: quality, performance and cost considerations for the SB solution, resulting in the right category of IoT device, and selected Cloud solution. A glossary of abbreviations and acronyms is provided in auxiliary Table 2.

For instance, what decision was made in the cell at column 2 and row 2 of Table 1, regarding the issue of latency and packet loss in E2E communication between the SB and Fog or IEC (edge with devices IoT and Cloud) for video surveillance and virtual concierge applications using real videos and VIoT?

Considering the critical nature of video over IP and voice data within IoT systems, the recommendation is to employ video-enabled IoT smart devices (categorized as high-end IoT devices, or category 3) and to implement a Fog architecture. For a single Smart Building (SB), this Fog architecture should ideally be deployed without software-defined networking (SDN) and network functions virtualization (NFV). Conversely, for a federation of Smart Buildings, a Fog architecture incorporating both SDN and NFV is advisable. Moreover, you can validate a part of this technical decision based on references [21,23,41].

Table 1. An overview of the main issues of SBs adopting: a. the best category of IoT devices; b. preferred architecture: Fog or IEC, c. adoption or not of SDN/NFV. The methodological decision is based on research (referenced articles) and for each cell seeks the best cost–benefit ratio (see Table 2: Table below are the acronyms adopted to understand it).

Problems (Columns):	Jitter, Background	Latency and Packet Loss on	Security Challenges	QoS, QoE: Video
vs.	Noise, Wi-Fi and Its	E2E Communication	Data Privacy, Governance and	Streaming and VoIP
Application Categories (Lines I–IV):	Interference Signal (SB)	(SB<>FOG or IEC<>Cloud)	Access Entrance (SB and Cloud)	(SB<>FOG);(IEC<>Cloud)
(I) Voice over IoT (VIoT), VoIP, IP Telephony included	(2) and FSN or IEC	(2) and FSN or ISN	(2) (3) and ANY	(2) (3) and FSN or ISN
the communicaton between IoT devices and SIP Server	articles *: [26,28,47]	articles *: [16,26,28,47]	articles *: [4,17,25,47]	articles *: [4,7,18,38,41,44]
(II) Video surveillance, included Virtual concierge	(3) and ANY	(3) and FOG or FSN	(–) and FOG or FSN	(3) and FOG or FSN
(VIoT, video)	articles: [21,38,39,42]	articles: [21,23,42]	articles: [2,21,31,47]	articles: [7,23,38]
(III) Video recording (Virtual concierge w/VIoT, Vídeo)	(3) and ANY	(3) and IEC or ISN	(–) and FSN or ISN	(3) and FSN or ISN
	articles: [14,21,34,38,42]	articles: [13,23,38] [42]	articles: [2,21,38,42,47]	articles: [2,7,23,31]
(IV) Chatbot Integrated with CCO, Cloud DB/VoIP on SB	(1) (2) and FOG or FSN	(1) (2) and ANY	(1) (2) and FOG or FSN	(–) and ANY
plus Virtual Concierge	articles: [16,29,32,34,39]	articles: [5,11,29,38,42]	articles: [24,29,38,39]	articles: [4,7,18,38]
Problems (Columns):	Jitter, Background	Latency and Packet loss on	Security Challenges	QoS,QoE: Video
vs.	Noise, Wi-Fi and its	E2E Communication	Data Privacy, Governance and	Streaming and VoIP
Application Categories (Lines V–VIII):	Interference signal (SB)	(SB<>FOG or IEC<>Cloud)	Access Entrance (SB and Cloud)	(SB<>FOG);(IEC<>Cloud)
(V) Biometrics Identification and Entrance authorization	(2) (3) and FOG or FSN	(2) (3) and FOG or FSN	(2) (3) and FOG or FSN	(2) (3) and ANY
and Virtual concierge (SB)	articles *: [21,42,46],	articles *: [14,21,38,46,53]	articles *: [5,21,47,48]	articles *: [4,7,25,38]
(VI) Light control, Environment control, the water pumps	(1) and (–)	(1) (2) and (–)	(2) and (–)	(–) and (–)
(SB common facilities)	articles: [8,21,32]	articles: [15,21,24,29]	articles: [5,24,54]	articles: Not Applicable (N/A)
(VII) Wi-Fi Network, temperature/fire sensors and actuators,	(1) (2) and FOG or IEC	(1) (2) and FOG or FSN	(1) (2) and ANY	(2) and ANY
leisure area, gym, swimming pool	articles: [7,21,24]	articles: [7,21,24]	articles: [7,18,25,54]	articles: [7,21,24,44]
(VIII) Building application (SB Visitor registration, Virtual concierge	(1) (2) and FOG or FSN	(1) (2) and FOG or IEC	(1) (2) and FOG or IEC	(1) (2) and FOG or IEC
communication, Smartphone-based apps for SB access, information retrieval, and delivery+mail services.	articles: [21,29,32,38,42]	articles: [2,5,23,33]	articles: [2,7,11,18,39]	articles: [7,11,29,38,41,44]
(*) Validation Procedure: The referenced articles [n] offer
further discussion and can support the technical selection of the
solution for each table cell, in conjunction with
other factors detailed in the Smart Building Use Case.

Table 1. An overview of the main issues of SBs adopting: a. the best category of IoT devices; b. preferred architecture: Fog or IEC, c. adoption or not of SDN/NFV. The methodological decision is based on research (referenced articles) and for each cell seeks the best cost–benefit ratio (see Table 2: Table below are the acronyms adopted to understand it).

Problems (Columns):	Jitter, Background	Latency and Packet Loss on	Security Challenges	QoS, QoE: Video
vs.	Noise, Wi-Fi and Its	E2E Communication	Data Privacy, Governance and	Streaming and VoIP
Application Categories (Lines I–IV):	Interference Signal (SB)	(SB<>FOG or IEC<>Cloud)	Access Entrance (SB and Cloud)	(SB<>FOG);(IEC<>Cloud)
(I) Voice over IoT (VIoT), VoIP, IP Telephony included	(2) and FSN or IEC	(2) and FSN or ISN	(2) (3) and ANY	(2) (3) and FSN or ISN
the communicaton between IoT devices and SIP Server	articles *: [26,28,47]	articles *: [16,26,28,47]	articles *: [4,17,25,47]	articles *: [4,7,18,38,41,44]
(II) Video surveillance, included Virtual concierge	(3) and ANY	(3) and FOG or FSN	(–) and FOG or FSN	(3) and FOG or FSN
(VIoT, video)	articles: [21,38,39,42]	articles: [21,23,42]	articles: [2,21,31,47]	articles: [7,23,38]
(III) Video recording (Virtual concierge w/VIoT, Vídeo)	(3) and ANY	(3) and IEC or ISN	(–) and FSN or ISN	(3) and FSN or ISN
	articles: [14,21,34,38,42]	articles: [13,23,38] [42]	articles: [2,21,38,42,47]	articles: [2,7,23,31]
(IV) Chatbot Integrated with CCO, Cloud DB/VoIP on SB	(1) (2) and FOG or FSN	(1) (2) and ANY	(1) (2) and FOG or FSN	(–) and ANY
plus Virtual Concierge	articles: [16,29,32,34,39]	articles: [5,11,29,38,42]	articles: [24,29,38,39]	articles: [4,7,18,38]
Problems (Columns):	Jitter, Background	Latency and Packet loss on	Security Challenges	QoS,QoE: Video
vs.	Noise, Wi-Fi and its	E2E Communication	Data Privacy, Governance and	Streaming and VoIP
Application Categories (Lines V–VIII):	Interference signal (SB)	(SB<>FOG or IEC<>Cloud)	Access Entrance (SB and Cloud)	(SB<>FOG);(IEC<>Cloud)
(V) Biometrics Identification and Entrance authorization	(2) (3) and FOG or FSN	(2) (3) and FOG or FSN	(2) (3) and FOG or FSN	(2) (3) and ANY
and Virtual concierge (SB)	articles *: [21,42,46],	articles *: [14,21,38,46,53]	articles *: [5,21,47,48]	articles *: [4,7,25,38]
(VI) Light control, Environment control, the water pumps	(1) and (–)	(1) (2) and (–)	(2) and (–)	(–) and (–)
(SB common facilities)	articles: [8,21,32]	articles: [15,21,24,29]	articles: [5,24,54]	articles: Not Applicable (N/A)
(VII) Wi-Fi Network, temperature/fire sensors and actuators,	(1) (2) and FOG or IEC	(1) (2) and FOG or FSN	(1) (2) and ANY	(2) and ANY
leisure area, gym, swimming pool	articles: [7,21,24]	articles: [7,21,24]	articles: [7,18,25,54]	articles: [7,21,24,44]
(VIII) Building application (SB Visitor registration, Virtual concierge	(1) (2) and FOG or FSN	(1) (2) and FOG or IEC	(1) (2) and FOG or IEC	(1) (2) and FOG or IEC
communication, Smartphone-based apps for SB access, information retrieval, and delivery+mail services.	articles: [21,29,32,38,42]	articles: [2,5,23,33]	articles: [2,7,11,18,39]	articles: [7,11,29,38,41,44]
(*) Validation Procedure: The referenced articles [n] offer
further discussion and can support the technical selection of the
solution for each table cell, in conjunction with
other factors detailed in the Smart Building Use Case.

Table 2. Classification of IoT devices categories and recommended Cloud architecture in Table 1.

Classification of IoT and subtitles of Table 1 (IoT),

IoT devices: Category of the Embedded boards:

(1) = Low-end IoT device

(2) = Middle-end IoT device

(3) = High-end IoT device

ANY = any of 3 categories could be applied

Acronyms for Architecture, Cloud architecture and Integration:

FSN = Fog + SDN (or NFV)

FOG = Fog without SDN (or NFV)

ISN = IEC + SDN (or NFV)

IEC = IEC without SDN (or NFV)

ANY = any of above Cloud solution could be chosen

(—) = N/A Not applicable

Table 2. Classification of IoT devices categories and recommended Cloud architecture in Table 1.

Classification of IoT and subtitles of Table 1 (IoT),

IoT devices: Category of the Embedded boards:

(1) = Low-end IoT device

(2) = Middle-end IoT device

(3) = High-end IoT device

ANY = any of 3 categories could be applied

Acronyms for Architecture, Cloud architecture and Integration:

FSN = Fog + SDN (or NFV)

FOG = Fog without SDN (or NFV)

ISN = IEC + SDN (or NFV)

IEC = IEC without SDN (or NFV)

ANY = any of above Cloud solution could be chosen

(—) = N/A Not applicable

Further research is needed to evaluate the quality of service, higher uptime, SLA and security aspects, representing a promising area for future investigation of the SBs using IoT smart devices.

The network architecture, depicted in Figure 8, incorporates failover and fallback mechanisms. Failover utilizes a redundancy system, while fallback employs a secondary terrestrial communication link from a different provider (e.g., a fiber optic cable as the primary link and any available radio-link or satellite solution as failover), using 4G/5G and future 6G cellular networks in the SB’s router.

For SBs in medium and large cities, redundancy is achieved using two distinct carriers or at least a secondary local Internet service provider. In rural areas, a failover link using microwave radio/tower networks may be necessary, supplementing the primary connection (fiber optic or other technology).

The proposed SB architecture in Figure 8 includes connections to cloud computing. For simplicity, the figure does not show all Fog components in detail, although they may be included in the deployment. Figure 8 shows a general example of the SB (left side of the figure), where the proposed edge (IEC) resides within the SB and is directly connected via router R1 to the cloud. This topology is applicable to one SB or, at most, two SBs.

The SB’s router or VoIP gateway connects to the two redundant Service Providers mentioned, adopting access lists and a firewall security layer to guarantee a robust solution for internal IoT devices and SB network against theses cyberattacks: DoS, DDoS, SQL injection, malware and Man-in-the-Middle. Only in the case of integration with a geographically proximate Fog node it provides access to that Fog and enables integration with federated SBs.

However, in the second proposed IEC topology, computation and processing are handled by an IEC or Edge device deployed internally within the SB, as described in [2,42]. In this case, the last-mile router R1 connects directly to the external network or the Internet, and to the central cloud solution. While a three-layer Cloud architecture is maintained, the IEC simplifies implementation by reducing the number of accesses to the central network.

The adoption of SDN architecture with its switches, where feasible, is recommended to reduce costs through the use of open platforms for internal and external routers and switches. The manageability and administration of the solution are crucial; from security and technical point of view, billing and technical support are delegated to the local provider.

Visitor registration and scheduling will be handled by mobile applications available in smartphone app stores and through readily available market APIs, facilitating easy authorization and registration of visitors and new residents by the building’s residents.

This SB context is managed by a CCO or OCC, at the top of Figure 8 of the solution provider, shared among one or multiple SBs. Furthermore, the central databases of actors and their credentials, obtained from Directory Services (Active Directory, AD), are implemented in the cloud Database, DB (see same Figure), connected by small local or remote replicas of the Fog or the IEC itself.

Some of the SB’s functionalities under study are summarized in Table 1, Figure 8 and described in this section as a use case for these SB applications.

One of the most prominent SB solutions employing large-scale IP technology is VoIP calling within the condominium or between buildings (which may be federated within the same architectural complex). This is implemented using SIP client devices (see Table 1). The virtual concierge adopts IoT technology with integrated microphones and speakers, enabling audio and video connection with the CCO or OCC; see the call flow in Figure 8. Within the SB, an IP-PBX/SIP server controls call admission and addressing between IoT devices and SIP clients (e.g., extensions 01-999) and IP phones using or not IoT devices together (replacing traditional TDM intercom systems).

As detailed in Section 5, this study incorporates quality of experience (QoE) and quality of service (QoS) metrics. To ensure adherence to established benchmarks, this study utilizes standards and metrics promulgated by organizations such as ITU-T and IETF. The subsequent four metric groups (1–4) are specifically tailored for SB use cases and can be extended to federated SB architectures with Fog or Cloud (SDN could be included):

1.

Latency:

ITU-T G.114 [55] recommends the following latency thresholds: less than or equal to 150 ms, acceptable latency for bidirectional conversation without perceptible impact; a range of 150–300 ms, acceptable but may cause degradation in user experience; and finally, greater than 300 ms, severe impact on real-time communication and interaction.

Typical Applications: VoIP and video calls: Ideally, latency should be less than 150 ms. Furthermore, control of IoT devices in Smart Buildings: Latency less than 100 ms is recommended for real-time actuation.

2.

Jitter:

ITU-T G.1020 [56]/IETF RFC 3550 [57] standards recommend the following: Less than or equal to 30 ms: acceptable jitter for real-time applications (VoIP, video conferencing and SB automation); jitter greater than 50 ms may cause perceptible degradation in multimedia transmissions.

So, the Impact on SB: Lighting and/or climate control: Jitter less than 30 ms is recommended. Video streaming and VIoT: Jitter between 10 and 30 ms is recommended to avoid distortions and audio/video interruptions.

3.

Packet Loss:

The ITU-T G.1010 [58] and IETF RFC 2680 [59] standards recommend the following for IoT devices and other clients: less than or equal to 1%, acceptable communication for VoIP and streaming; less than 3%, perceptible impact on audio and video; greater than 5%, VoIP conversation and video conferencing become unintelligible.

Examples in Smart Buildings (SBs):

Critical automation control and sensors: Less than 0.5% is recommended to ensure reliable communication. Video streaming (CCTV, video conferencing): Less than 1% is recommended.

4.

User Satisfaction Ratings (QoE scores) [41]:

MOS (Mean Opinion Score) – ITU-T P.862 and P.862.2:

5 = Excellent (no perceptible distortion);

4 = Good (minor glitches);

3 = Fair (some perceptible distortions);

2 = Poor (difficulty in understanding);

1 = Unacceptable.

Other subjective metrics exist, such as the QoE Score ITU-T P.1501 [60]. This latter standard measures perceived video quality.

Another interesting feature is the centralized billing procedure, managed within the database and accessed by the Operational Center administrator. This billing information is sent to the condominium residents from the CCO, detailing water, electricity and gas consumption, separated by unit and measured by control devices over IoT (meters and sensors) in each condominium unit. The CCO automatically generates and sends monthly electronic invoices to each resident’s email address using their system credentials (AD users).

The important choice of adopting an IEC or Fog computing approach in the simplified SB follows the solutions chosen during the research and outlined in Table 1, along with its evolution concerning the types of IoT devices, 5G-IoT [7], VIoT, SDN, gateways, containers, deployment of security-assurance processes, etc.

The results obtained from research articles, for example, on a solitary SB, are linked to the network architecture adopted for this scenario: where Edge Computing alone reduces latency and jitter in the growing data, voice, and video traffic. It is important to note that the local integration of various networks (Wi-Fi, WSN and wired network where necessary) within the SB still needs review, given that all critical computational aspects, including computing, processing and storage, are implemented at the network edge. A review of the cells marked with IEC in Table 1 is necessary at this point.

This research culminates in Section 5 and Section 6, where quantitative evidence is presented to substantiate the efficacy of a specific architectural strategy. For standalone SBs with a limited occupancy, estimated at up to 60 units per tower, the adoption of an Edge computing (IEC) architecture, complemented by IoT devices of types (1) and (2) deployed within the building, demonstrates a quantifiable superiority. This assertion is rigorously supported by the decision-making matrix presented in Table 1, encompassing thirty-two distinct solution cells. These findings are contrasted with an alternative strategy employing Fog Computing with NFV and IoT devices of type (3).

The advent of 5G-IoT, 6G and 6G-IoT on cellular networks and massive fiber optic implementations within Smart Cities, SBs or a large group of federated SBs may bring both innovative solutions and new challenges, such as cyberattacks and new security strategies to the current landscape [49,61].Certainly, this scenario will open a field for future research adopting NFV, network slicing and SDN and SD-WAN technologies in a new scale and reducing deployment and operation costs for SBs.

7. Conclusions

This study concludes that, in the case of a federation or a group of Smart Buildings, the strategy of using Fog Computing with IoT devices of the three types mentioned as (1) to (3) in Table 2, intelligently and sparingly at the Edge, is the best solution. It is also recommended to complement this strategy with the adoption of SDN by service providers and cloud vendors.

Conversely, for standalone Smart Buildings with a limited number of properties per tower (estimated at 20–60 units), this study concludes that a strategy employing IEC and IoT devices of types (1) and (2) at the Edge, leveraging simpler technological solutions within this condominium category, represents the optimal approach. Generally, these isolated SBs are sensitive to operational costs and initial investments. The adoption of open SDN architecture by cloud providers maintains the consistency of this approach and should be strongly considered.

The information gathered from field research and state-of-the-art literature on proprietary switches [11,13] (e.g., Cisco Systems, Aruba and Fortinet) versus the costs of open source and OpenFlow SDN switches from various community manufacturers indicates that the latter are more cost-effective.

Furthermore, the labor required is less specialized, as many professionals operate as freelancers in the SDN switch market, offering reduced implementation and maintenance costs.

Additionally, the easy adoption of the international and open SDN standard mitigates the “vendor lock-in” problem, which tends to result in higher costs in the medium and long term due to the proprietary nature of closed technologies.

NFV, in agreement with telecommunication companies, can also be adopted for both scenarios, resulting in reduced operational costs and technological advancement without requiring significant hardware and software reinvestment after a certain number of years following initial Smart Building implementation. Decision-making should consider the advent of 6G, 5G, 5G-IoT cellular networks and new fiber optic implementations within Smart Cities, which may introduce both innovative solutions and new challenges to the current landscape.

The future challenge, in developing countries, will be to balance investments in innovative 6G, 5G-IoT, local manufacturing of IoT devices, SDN and NFV technologies associated with Fog and IEC. Effective service availability for enterprises, medium businesses and end users will be achieved through economies of scale coupled with innovation, leading to lower-cost solutions.

A key challenge will be to extend this strategy and the scientific advancements presented in this study of SBs to a larger scale within Smart Cities, ideally coordinated through a public–private partnership leveraging the technological progress of emerging Smart Buildings within a specific geographical area.