Introduction

The Industrial Internet of Things (IIoT) is revolutionizing various sectors, including construction, by enabling seamless integration of sensor devices, applications, and business processes [1]. In the construction industry, IIoT can enhance operational efficiencies by facilitating real-time monitoring and management of critical aspects, such as equipment tracking and safety compliance [2]. A key enabler of this digital transformation is fog computing, which brings computation and storage capabilities closer to the data source, i.e., the sensor devices [3]. This proximity allows for low-latency, real-time data processing, which is essential for IIoT applications. To effectively manage these complex data processing pipelines, microservices, which are small, independently deployable software components, are orchestrated within the fog computing framework [4, 5]. Service Function Trees (SFTs) have been proposed as a structured representation to manage the interactions and dependencies among these microservices [6, 7]. For example, an SFT could represent a sequence of microservices that filter, aggregate, and analyze sensor data to detect specific events in a construction site.

Existing approaches to SFT mapping in fog networks have primarily focused on identifying valid microservice-to-device mappings [8]. While these mappings ensure functional connectivity, they often overlook critical performance metrics such as latency and fog resource utilization. This can lead to suboptimal performance in dynamic environments like construction sites, where timely data processing is paramount for safety and operational efficiency. For instance, a valid but non-optimized placement may result in high-latency communication paths, insufficient sensor coverage, or overloading of resource-constrained fog nodes, thereby delaying time-critical actions. Moreover, existing works tend to treat workflows as simple linear chains and overlook the complexity introduced by tree-structured dataflows (i.e., SFTs), where dependencies between microservices and sensor availability are more intricate [9,10,11]. These methods also fail to jointly consider heterogeneous constraints such as sensor proximity, communication hop limits, and the composition of multiple Service Function Chains within a single tree structure. Therefore, our work is motivated by the need for an optimized mapping strategy that explicitly accounts for IIoT-specific constraints and enables efficient, latency-aware, and sensor-sensitive deployment of SFTs over resource-constrained fog networks.

The core of our new SFT mapping technique is a mixed-integer linear programming (MILP) formulation that is designed to optimize microservice mappings within the fog network’s computing framework. This formulation addresses a range of operational constraints, including latency, connectivity, and the availability of sensors and resources. By calculating the optimal placement of microservices, the MILP approach ensures that data processing requirements are met with maximum efficiency and minimum resource expenditure. To achieve this, our formulation relies on comprehensive preprocessing steps that constrain the search space to feasible mappings only. The preprocessing steps include the computation of all simple paths between fog devices and the identification of feasible direct and indirect communication paths. In this context, a “direct mapping” refers to scenarios where a logical dataflow path between two microservices in a Service Function Tree is directly mapped to a physical communication link between two fog devices, where the microservices are deployed on fog devices that are directly connected. Conversely, an “indirect mapping” occurs when a logical path is mapped to a multi-hop communications link between two fog devices that do not have a direct physical connection. Such preprocessing provides the optimization solver with the necessary data to make informed decisions, immediately excluding infeasible solutions, thus allowing solutions to be found rapidly in real-time operational scenarios. The effectiveness of our approach is validated through extensive simulations, demonstrating significant performance improvements in IIoT applications.

The major contributions of this paper are as follows:

  • We formulate the SFT mapping problem as a MILP model that jointly optimizes the placement of microservices while satisfying multiple IIoT-specific constraints, including latency bounds, sensor proximity, hop limitations, and fog node capacity constraints.

  • We introduce comprehensive preprocessing steps that eliminate infeasible mappings in advance, thereby reducing the MILP solver’s search space. This step significantly improves computational efficiency and enhances the model’s scalability to larger fog networks.

  • We evaluate our proposed framework through extensive simulations in a realistic construction-site use case (concrete pouring) using different types of sensors and microservices. The results demonstrate the effectiveness of our solution in terms of feasibility and optimality when compared to traditional, non-optimized mapping methods.

In the remainder of this paper, we describe a motivational scenario (“Concrete pouring scenario” section) review related work, including existing methods for SFT mapping in fog networks (“Related work” section), formalize the problem of optimal SFT mapping (“Preliminaries” and “SFT mapping problem formulation” sections), present our new MILP solution, along with the key preprocessing steps that isolate valid microservice placements (“Optimization model” section), illustrate the difference between valid and optimal solutions (“Examples of valid and optimal mappings” section), outline our experimental setup and discuss our simulation results, highlighting the performance improvements achieved through our approach (“Practical evaluation” section), and conclude with a summary of the key findings and directions for future research (“Conclusion” section).

Concrete pouring scenario

This section illustrates the integration of real-time event processing in an Industry 5.0 scenario [12] by focusing on a concrete pouring process at a large IIoT-enabled construction site. The dynamic environment of the site, with continuous movement of machinery, workers, and fluctuating environmental conditions, presents unique challenges for managing and processing large volumes of real-time data [13]. These challenges become more complex during the concreting phase due to its high sensitivity to environmental factors such as ambient temperature, humidity, and wind speed [14, 15]. We consider a scenario where an industrial building floor slab covering approximately 2,000 square meters (sqm) is poured in sequential 50 sqm sections using mobile pouring troughs. Sensors are strategically embedded throughout the slab to support real-time data capture across all phases of the pour [16]. We estimate the number of sensors for a 2,000 sqm slab to exceed 25, informed by logic adapted from flooring moisture assessment guidelines such as ASTM F2170 [17]. This standard recommends a minimum of three sensors for the first 1,000 square feet (approx. 93 sqm) and one additional sensor for each subsequent 1,000 square feet when measuring relative humidity for flooring applications. Although ASTM F2170 is specific to moisture testing for floor installations, its deployment logic provides a practical baseline for estimating sensor density in large-scale monitoring applications. During the process, workers continuously move the troughs, smooth the poured concrete to achieve a level surface, and monitor conditions to ensure safety compliance, such as those mandated by Occupational Safety and Health Administration (OSHA) standards [18].

The concrete pouring process involves extensive monitoring to ensure concrete quality and worker safety. Sensors deployed include Geokon GK-8 T temperature sensors, Honeywell HIH6130 humidity sensors, Sentek EC5 moisture sensors, Kyowa strain gauges, and Physical Acoustics PCI-II acoustic emission sensors. Typically, each sensor transmits data at rates of 1–5 Hz [19], generating thousands of data points per minute across temperature, humidity, stress, and acoustic emission parameters. These variables are directly associated with early defect formation, such as cracking and uneven curing, which can compromise structural integrity if not addressed promptly [20].

According to the American Concrete Institute (ACI) guidelines, concreting under high ambient temperatures above 32\(^{\circ }\)C, humidity below 40%, and wind speeds over 10 km/h can lead to evaporation rates exceeding the critical threshold of 1 kg/m2/h [15]. These conditions are frequently observed in summer concreting operations across Australian sites and require sub-minute decision-making to mitigate structural risks. According to the Cement Concrete & Aggregates Australia (CCAA) Guide, delayed detection and remediation of anomalies can significantly increase the risk of pour rejection, with demolition and rework costs potentially reaching or exceeding $200 per cubic meter in site-specific contexts [21]. Therefore, real-time detection and latency-aware processing are essential to prevent structural failures and ensure compliance with construction safety standards.

Processing the large volume of data generated by these sensors poses challenges for traditional data processing methods, which often struggle to manage large-scale real-time data effectively. To mitigate this, we use the notion of a Region of Interest (RoI) within the concrete pouring process, where focused monitoring is applied to sections experiencing high-burst events (e.g., sudden temperature shifts) or anomalies (e.g., rebar displacement). Each RoI, typically spanning 50 sqm, is updated dynamically based on sensor-detected anomalies. By concentrating processing power on active RoIs, the system ensures timely corrective action. This localized, latency-aware data processing strategy ensures efficient resource allocation and optimal curing conditions, particularly when temperature-sensitive cement types are used. For instance, mixtures placed at 38\(^{\circ }\)C may set more than 2 hours earlier than those placed at 10\(^{\circ }\)C, depending on cement composition and admixture use [15].

Microservices within an SFT organize the workflow for filtering, aggregating, and event handling based on data from RoIs. For instance, data from temperature and humidity sensors can be analyzed to detect imminent risk factors, triggering alerts for immediate corrective action to ensure worker safety. Fog computing enables near real-time data analysis by processing data at the edge, closer to the sensors [22]. In this scenario, we leverage Raspberry Pi 4 microcomputers as our fog computing devices due to their high processing capabilities and compatibility with various sensor data formats, enabling rapid local data analysis. This approach reduces latency and offloads computational burden from centralized cloud systems, ensuring real-time monitoring and quick responses to potential safety hazards. Figure 1 shows the data flow from the sensors deployed across the RoI, processed locally at the fog computing layer for initial filtering and aggregation before being transmitted to the cloud for more detailed analysis and long-term storage. The fog nodes filter and aggregate the sensor data and forward it to event handlers, which compare the data against predefined thresholds for concrete curing and structural integrity risks. When risks are detected, the system triggers immediate corrective actions on-site. Figure 1 also illustrates how the processed data integrates with enterprise systems to form a digital twin of the construction site for broader risk management, such as production scheduling and emergency response planning. By employing advanced Service Function Tree mapping techniques and leveraging fog computing, we can optimize microservice placement to enhance operational efficiency and safety compliance in this IIoT-enabled concrete pouring scenario.

Fig. 1
Fig. 1

IIoT-enabled concrete pouring monitoring scenario

Full size image

Related work

In recent years, there has been a growing interest in optimizing microservice deployments in fog computing environments, particularly within the IIoT context.

Earlier, a Fog-Cloud Clustering (FCC) problem was introduced as a multi-objective optimization challenge to improve resource management within Fog-to-Cloud (F2 C) architectures [23]. This approach used a MILP model that prioritized minimizing latency and reducing transmission power, which is essential for enhancing the efficiency of data transmission and processing in distributed systems. The MILP formulation effectively addressed various operational constraints, ensuring that the clustering of fog devices aligns with the overarching goals of resource optimization and performance enhancement. Although this work provided a scalable solution through machine learning heuristics, enabling near-optimal clustering results with significantly reduced computational demands, it did not address the specific needs for managing Regions of Interest for focused sensor data analysis and optimizing the data processing pipeline within such RoIs.

Next, an IoT-driven service provisioning framework was developed to enhance managing data streams from multiple IoT sources [24]. It incorporates essential mechanisms for uploading these streams, their aggregation, and routing alongside the strategic placement of Virtual Network Functions (VNFs). This framework was designed to ensure that the data streams adhere to a specific sequence of service functions, collectively forming a Service Function Chain (SFC), which is critical for maintaining the integrity and efficiency of data transmission. A heuristic algorithm was introduced to optimize performance to minimize service response latency and operational costs associated with IoT-driven services. This algorithm effectively uses the proposed service framework to enhance resource allocation and utilization within the mobile edge computing network, ensuring that the SFC requirements of various IoT applications are met. However, a notable limitation of this framework is that it did not consider the deployment of SFCs based on the availability of sensors within the RoI, which could significantly impact the adaptability and responsiveness of the service provisioning process in real-time scenarios.

Two algorithms for service placement were developed to improve the efficiency of network services in 5G networks through Network Function (NF) virtualization [25]. These algorithms tackled the issue of optimally positioning service requests within a physical infrastructure, where NFs faced location constraints influenced by factors such as latency, regulatory requirements, and hardware specifications. An Integer Linear Programming (ILP) formulation was employed to determine the best combination of service embedding and chain composition, ensuring optimal placement of virtualized network functions and their interconnections while considering these constraints. To address large-scale challenges, a greedy chain selection heuristic was introduced. It incrementally added virtual NF chains to the service composition and embedded them concurrently, achieving a near-optimal solution with significantly reduced computation time. However, the algorithms did not take into account the necessity of mapping the leaf nodes of the service function tree to physical nodes equipped with the necessary sensors. Additionally, this approach did not consider the existence of direct or indirect paths and the capacity requirements between the mapped nodes, which could significantly affect the overall service placement effectiveness.

A two-stage algorithm was proposed to embed an SFT with minimal cost for Network Function Virtualization (NFV)-enabled multicast [26]. This method aimed to optimize the embedding of SFCs into a substrate network, focusing on reducing the overall setup costs and the link connection expenses to clients. Initially, the first stage generated a feasible solution by embedding an SFC into the substrate network. Subsequently, the second stage refined this solution to further decrease costs. This approach demonstrated significant cost savings compared to traditional methods. However, it overlooked how an SFT’s leaf nodes need to be mapped to physical nodes that have the required sensors in the communications range, which is essential for effective multicast service deployment.

A multi-objective optimization method was proposed for the dynamic service placement problem in fog computing using container-based virtualization [27]. This two-tier resource provisioning framework, leveraging Kubernetes in a fog-cloud environment, aimed to optimize service placement by balancing multiple performance metrics, including latency, resource utilization, and service reliability. The framework employed the multi-objective, Non-dominated Sorting Genetic Algorithm II (NSGA-II) to reconcile conflicting objectives and enhance the system’s ability to adapt dynamically to varying service demands. Empirical evaluations demonstrated notable improvements in service response times and resource efficiency. However, this study did not consider sensor range constraints, where an SFT node’s placement requires proximity to certain sensors, which is crucial for ensuring optimal service functionality in real-world IoT scenarios.

A framework for service-oriented architecture-based IoT systems was introduced to facilitate the integration of different software modules using multiple services and communication interfaces [28]. It allowed for the reuse of software modules across various scenarios and domains, thereby enhancing the flexibility and scalability of IoT applications. It employed a modular approach to service composition, enabling developers to build complex IoT solutions by combining reusable service components. The framework also supported dynamic service discovery and binding, which allowed IoT applications to adapt to changing environments and requirements. However, it did not address mechanisms for focusing on specific RoIs to access particular sensors’ data and optimize the data processing pipeline based on sensor availability in the RoI.

Another approach focused on reliability and availability-aware mapping of SFCs in 5G networks, leveraging NFV to deploy network functions on commodity hardware [29]. It aimed to enhance the efficiency and flexibility of 5G networks by optimizing the placement of virtual network functions to minimize overall setup costs and connection costs toward clients. The method considered key factors such as network reliability, fault tolerance, and service availability, demonstrating potential improvements in network performance and operational cost reductions through simulation results. However, this approach did not account for sensors’ ranges, link speeds, and connectivity constraints for the SFT’s embedding onto physical networks.

A study on the placement optimization of VNFs in a cloud environment proposed a multi-objective integer linear programming model [30]. It aimed to balance minimizing end-to-end latency for users against reducing the number of servers used while maximizing the connectivity of the VNFs in the network. This approach utilized Particle Swarm Optimization to solve the NP-hard problem efficiently in polynomial time. Simulations confirmed that the method provided feasible solutions close to the exact optimal solutions. However, it did not consider how an SFT’s leaf nodes need to be mapped to physical nodes with the required sensors in range.

A fog-based framework, FITOR, was proposed for IoT service provisioning, aiming to optimize the placement of IoT applications in fog environments [31]. It included an orchestration system and an optimized fog service provisioning strategy (O-FSP) to minimize provisioning costs while meeting application requirements. FITOR was designed to facilitate the integration of IoT devices with fog nodes, incorporating extensive functionality to manage dynamic service deployment and resource allocation effectively. It used a non-traditional approach leveraging a divide-and-conquer methodology to handle the orchestration of microservices across heterogeneous and volatile fog nodes. Extensive experiments demonstrated that O-FSP significantly outperformed related strategies in terms of provisioning cost, resource usage, and acceptance rate. However, despite these advancements, the framework again did not consider sensor range constraints when an SFT node’s placement requires proximity to certain sensors.

A machine learning-driven service function chain placement and scaling approach was developed in multi-access edge computing enabled 5G networks [32]. It used a neural network model to predict the number of required virtual network function instances based on traffic demand. ILP techniques were employed to solve the joint user association and SFC placement problem. This approach incorporated auto-scaling by predicting traffic demand variations and dynamically adjusting the placement of network functions to minimize end-to-end latency and maximize data rate requirements. A heuristic was also proposed to address scalability concerns in the ILP model. However, the study did not address the deployment of SFCs based on the availability of sensors within the RoI.

An adaptive framework for microservices provisioning in heterogeneous IoT environments, named AMPHI, was proposed to manage mission-critical data analytics workflows effectively [33]. It facilitated the flexible deployment of containerized microservices in combined stationary and mobile IoT settings, accommodating real-time operational demands and diverse application requirements. By leveraging a comprehensive library of operators, AMPHI optimized the execution of data analytics workflows, ensuring high levels of service quality and resource efficiency under dynamically changing conditions. The framework supported a versatile range of IoT applications, from smart firefighting to infrastructure monitoring, using both heuristic and integer linear programming approaches for optimal microservice instantiation. However, this framework did not focus on specific RoIs to access particular sensors’ data.

A recent comprehensive review of NFV and SFC implementation frameworks highlighted the field’s requirements, objectives, implementations, and open research challenges [34]. It grouped existing frameworks into three major categories: resource allocation and service orchestration, performance tuning, and resilience and fault recovery. It identified key challenges like scalability, resilience, and high-performance deployments in next-generation networks. The review also discussed the importance of network slicing as a fundamental property for next-generation networks, enabling service providers to migrate network services to a virtual infrastructure, thereby reducing both capital and operational costs. Despite offering valuable insights into the current state of NFV and SFC frameworks, the review did not propose specific solutions to address these challenges.

A personalized federated deep learning framework, MC-2PF, was proposed for load prediction in multi-edge environments, addressing challenges related to distributed resource availability and limited historical data [35]. It introduces control mechanisms to mitigate client drift in federated learning and applies a Savitzky-Golay filter for time-series noise reduction. Although aligned with fog computing contexts, the MC-2PF framework focuses solely on predictive analytics and does not consider microservice chaining, service function dependencies, or optimized placement under constrained fog resources.

A resource allocation scheme based on the Asynchronous Advantage Actor-Critic (A3 C) algorithm was proposed for dynamic scheduling in cloud datacenters [36]. It employs multiple DRL agents to asynchronously update resource allocation policies based on latency, energy efficiency, and system dynamics. The proposed system formulates the resource allocation as a Markov Decision Process (MDP) and demonstrates superior adaptability to workload fluctuations. While this work is highly relevant in the context of adaptive scheduling and heterogeneous resource provisioning, it is designed for centralized cloud datacenters and does not address the microservice-level placement constraints or dependency-aware optimization in distributed fog networks.

A robust federated deep learning framework was proposed for collaborative caching in multi-edge networks, aiming to improve cache hit rates and resilience against adversarial updates [37]. It integrates a discrete-categorical variational autoencoder for content popularity prediction and employs residual-based anomaly detection to secure federated model updates. While effective in caching scenarios, it lacks direct modeling of service dependencies or task sequences such as those found in SFTs. Moreover, it does not address the optimization of microservice placements across constrained nodes under SFT constraints.

Kumar et al. [38] proposed a Monitor-Analyze-Plan-Execute (MAPE)-based autoscaling framework that uses a multivariate Transformer (MV-Transformer) for dynamic resource allocation in cloud environments. The model predicts long-term workload patterns across metrics such as CPU, memory, disk, and network and outperforms LSTM and Bi-LSTM in provisioning accuracy and elastic speedup. However, the framework targets centralized cloud platforms and does not model microservice hierarchies, service chaining, or the resource and communication constraints of fog-based IIoT systems. It also lacks topology-aware service placement and does not account for physical deployment considerations such as sensor proximity or direct or multi-hop communication feasibility.

A Kubernetes-based proactive autoscaling framework was proposed that leverages predictive models such as ARIMA, LSTM, Bi-LSTM, and Transformer to forecast workload demand [39]. The primary objective is to overcome the limitations of reactive autoscaling, such as high latency and poor QoS, by integrating these models into Kubernetes’ custom resource definitions along with a dedicated operator reconciliation process. This framework improves responsiveness and reduces under-provisioning at the container orchestration level. However, it is limited to cloud-centric cluster management and does not consider microservice-level function chaining or the specific orchestration challenges posed by fog-based IIoT deployments.

Most recently, a novel algorithm was proposed for mapping SFTs onto a fog network topology to enhance the efficiency of sensor event processing in IIoT applications [8]. It focused on optimizing the placement of microservices within the fog network, ensuring that nodes selected for processing SFT functions had the requisite resource capacity and network speed to meet event processing deadlines. The algorithm retrofitted the event processing pipeline into a logical architecture structured as a service function tree comprising multiple service function chains. Simulations validated the algorithm’s effectiveness in achieving successful SFT mappings to a physical network, demonstrating significant improvements over single service placement strategies. However, it focused only on finding a valid mapping if one exists, without considering the factors needed for optimizing the mapping of SFTs to a physical network.

Thus, to the best of our knowledge, past research has primarily focused on deploying singular linear SFCs, with some studies exploring the deployment of composite SFTs. However, none of these studies incorporates optimization techniques for sensor availability within specific regions of interest into the service deployment process. Below, we present the first approach to finding an optimal mapping of SFTs that incorporates sensor selection, service function resource requirement, connectivity, link speed constraints, and latency in the mapping process.

Preliminaries

This section describes our physical network and Service Function Tree (SFT) models and then defines the constraint-based SFT mapping problem.

Physical network model

Consider an IIoT environment that includes physical sensors and fog devices. Let \(S = \{s_{1}, s_{2}, \ldots, s_{n}\}\) be a set of n sensors, where each sensor \(s_{i}\) has an associated modality \(\mu (s_i)\). These modalities represent the diverse types of data captured by each sensor, such as temperature, images, wind strength, physical pressure, etc. Let \(D = \{d_1, d_2, \ldots, d_p\}\) be a set of p fog devices, where each device \(d_i\) has a subset of sensors in its communication range for data acquisition. These devices form a physical network to communicate with other fog devices in their range. We model this physical network (i.e., substrate network) as an undirected graph \(PN = (D, L)\). Each node represents a fog device \(d_i \in D\), and each edge represents a communication link between any pair of fog devices \((d_i, d_j) \in L\). Sensors located within the communication range of each fog device are represented as the attributes of that node (i.e., fog device) in the physical network. Each fog device \(d_i \in D\) possesses a defined processing capacity \(C_{node}(d_i)\) and each link \((d_i, d_j) \in L\) is characterized by a maximum transmission capacity \(C_{link}(d_i, d_j)\). In our physical network model, both fog devices and sensors are statically placed within the IIoT site, and their locations are known a priori. This strategic placement is designed to optimize data collection and processing capabilities, leveraging advanced wireless communication technologies such as Zigbee and LoRa. These technologies are instrumental in monitoring and observing complex on-site operations, such as a critical concrete pouring process. Figure 2 illustrates an example of a physical network within an IIoT environment, showcasing the interconnectedness of fog devices and sensors and highlighting the operational framework that supports real-time data processing and decision-making in construction scenarios.

Fig. 2
Fig. 2

Example physical network in an IIoT site showing ten fog devices, and their communication ranges (dashed circles)

Full size image

Service function tree model

We introduce an SFT model to represent a structured network of sensors and microservices for processing sensor data. A Service Function Tree is a composition of multiple interconnected Service Function Chains [40]. Each SFC comprises a sequence of microservice nodes interconnected via data flow links, where each service function denotes a specific microservice’s functionality. The SFT is mathematically modeled as a directed acyclic graph \(SFT = (M, L')\), where \(M = \{m_1, m_2, \ldots, m_q\}\) is the set of q microservice nodes and \(L'\) is the set of directed edges that define functional dependencies among microservices.

In an SFT, we identify three types of nodes: (1) nodes with a single input and single output, (2) nodes with multiple inputs and a single output, and (3) nodes with single or multiple inputs but no output (apart from triggering actions not modeled here, such as raising alarms). We classify the microservices into three main types: Filters \(F_i\), Aggregators \(A_i\), and Event Handlers EH. Filters are responsible for processing and forwarding sensor data, aggregators combine data from multiple sources, and event handlers analyze incoming data to trigger actions and responses. Each microservice \(m_i\) in the SFT has varying resource requirements \(R_{node}(m_i)\), which can be represented numerically as a specific value or a range, e.g., a memory requirement in GBs. Similarly, each connectivity link \((m_i, m_j) \in L'\) has communication requirements \(R_{link}(m_i, m_j)\), which can be represented numerically, e.g., a data transfer rate in Gbps. Leaf nodes in the SFT always have access to a predefined set of sensors within their RoI, from which they can elect to receive data. The SFT’s root node is always an EH microservice. We assume that the SFTs, mirroring a workflow process, are designed by a domain expert to reflect the necessary data processing strategy required in the IIoT site’s environment. Figure 3 illustrates various example SFTs in the context of an IIoT site, e.g., Fig. 3c shows three distinct data flow chains forming a tree as follows: \(SFC_1 = \{F_1, A_1, A_2, EH\}\), \(SFC_2 = \{F_2, A_1, A_2, EH\}\), and \(SFC_3 = \{F_3, A_2, EH\}\).

Fig. 3
Fig. 3

Three service function tree designs in an IIoT site scenario

Full size image

Assumptions

This section outlines our fundamental assumptions regarding the SFT model and the physical environment of the IIoT site. These assumptions are paramount for ensuring the validity of the proposed framework and are as follows:

  • The network’s physical topology, including the arrangement of fog devices and sensors, remains static throughout the deployment of the IIoT network.

  • Sensors and fog devices are assumed to possess adequate energy resources to sustain their operations for the entire deployment duration.

  • The impact of radio interference and signal attenuation, potentially caused by physical obstacles such as buildings and machinery, is not taken into account.

  • Each sensor is configured to collect data at a constant frequency, ensuring a steady stream of information that is continuously transmitted to the fog devices within its communication range.

  • The communication range of the fog devices is twice the sensing range of the sensors.

  • Each microservice in the SFT is designed to produce a single data stream.

  • Each RoI corresponds to a dominant sensing modality, and the associated filter microservice is designed to process data of that specific modality. In cases where a physical sensor generates multiple data types (e.g., temperature and humidity), we model them as distinct logical sensor streams, each mapped to a separate microservice. Higher-level aggregator microservices handle multimodal integration. This approach preserves the simplicity of microservice-level filtering while allowing multimodal data integration at higher levels of the SFT.

In this study, we assume a static physical topology and continuous sensor availability throughout the deployment duration. This reflects common practices in industrial construction settings, where sensors and fog nodes are positioned and powered to remain stable during critical operational tasks such as concrete pouring. These configurations are typically maintained for extended periods to support deterministic scheduling, reliable communication, and safety monitoring [41]. However, in broader IIoT environments, nodes may exhibit transient behavior or failures. Addressing such dynamics through resilient remapping strategies or stochastic optimization models is beyond our current scope but is an essential area for future work.

SFT mapping problem formulation

The problem of mapping an SFT onto a physical network is as follows.

Given a physical network PN and a service function tree SFT, the objective is to identify a total mapping \(S2P: SFT \rightarrow PN\) of the SFT’s nodes, representing microservices, to physical network nodes, representing fog devices, that optimizes resource usage and preserves data flow continuity for each service function chain in the tree.

The core challenge in finding such a mapping lies in satisfying the following stringent constraints.

  • Sensor Selection Constraint. We denote the sensors by unique identifiers within their RoIs in an SFT. Sensors within each RoI share the same modality (i.e., sensor type). For a given microservice type \(m_i \in M\), only sensors of a specific modality from the designated RoI for \(m_i\) can be chosen. We denote this constraint as follows:

    $$\begin{aligned} S_{sel}(m_i) = \{s_i \in S \,|\, (\exists r \in ROI: (s_i, r) \in SR) \wedge \mu (s_i) = \mu (m_i)\}, \end{aligned}$$

    where \(S\) is the set of all sensors with their associated modalities, \(ROI\) is the set of all regions of interest, \(SR\) is a set of pairs \((s_i, r)\) indicating that sensor \(s_i\) is located within region \(r\), \(\mu (s_i)\) is the modality of sensor \(s_i\), \(\mu (m_i)\) is the required modality for microservice \(m_i\), and \(S_{sel}(m_i)\) is the function that returns the subset of sensors from which \(m_i\) can receive data.

  • Sensor Availability. Nodes in the SFT that require data from specific sensors must be mapped to nodes in the physical network capable of providing access to these sensors. In other words, for each microservice \(m_i\) in an SFT with a non-empty set of sensor requirements \(S_{sel}(m_i)\), there must exist at least one node in \(PN\) such that all required sensors are accessible. We formally define this constraint as follows:

    $$\begin{aligned} \begin{array}{l}\forall m_i \in M, \exists d_j \in PN \\ \text {such that } \displaystyle S_{sel}(m_i) \subseteq S_{sel}(d_{j}), \end{array} \end{aligned}$$

    where \(M\) represents the set of microservices, \(PN\) the physical network nodes, \(S_{sel}(m_i)\) the sensors required by microservice \(m_i\), and \(S_{sel}(d_j)\) the sensors available on physical node \(d_j\). The constraint ensures that each microservice \(m_i\) is mapped to a single node \(d_j\) in the physical network, such that all sensors in \(S_{sel}(m_i)\) are accessible through this node. If a single node \(d_j\) in \(PN\) can satisfy all sensor requirements of \(m_i\), then \(m_i\) will be mapped to \(d_j\).

  • Microservice Mapping Constraint. Each microservice node \(m_i \in M\) from the SFT (representing a node type \(F_i\), \(A_i,\) or \(EH\)) must be mapped to a fog device \(d_i \in D\) in the physical network \(PN\). This is the required total function \(S2P\).

  • Resource Allocation Constraint. Each node in the SFT has particular resource requirements and can only be mapped to nodes in the physical network that have sufficient residual resources to accommodate these requirements. Therefore, the sum of the resource requirements of the microservices allocated to any fog device \(d_i \in D\) must not exceed its capacity. We represent this constraint as follows:

    $$\begin{aligned} \forall d_i \in D, \sum \limits _{m_i \in H_{d_i}} R_{node}(m_i) \le C_{node}(d_i), \end{aligned}$$

    where \(H_{d_i}\) is the set of microservices hosted in a fog device \(d_i\), \(R_{node}(m_i)\) represents the resource requirement of a microservice \(m_i\), and \(C_{node}(d_i)\) denotes the resource capacity of the fog device \(d_i\).

  • Path Connectivity Constraint. The mapping must maintain the inherent connectivity between microservices as defined in the SFT. For any directly connected microservices \(m_i\) and \(m_j\) in \(L'\), there should be a direct or routed path in \(PN\) between their corresponding fog devices \(d_i\) and \(d_j\) to which they are mapped. The existence of such paths ensures data flow continuity.

    $$\begin{aligned} \forall (m_i, m_j) \in L', \exists \text { a valid path } p \text { in } PN \text { such that } p \text { connects } d_i \text { and } d_j. \end{aligned}$$

  • Link Capacity Constraint. The total link speed requirements of all microservices mapped to a specific link in the physical network must not exceed the physical link’s maximum transmission capacity. This constraint ensures that the requisite data flow between any mapped microservices is supported. We represent this constraint as

    $$\begin{aligned} \forall (d_i, d_j) \in L, \sum _{\begin{array}{l} _{(m_i, m_j) \in L' \text { and }}\\ _{(m_i, d_i) \in S2P \text { and }}\\ _{(m_j, d_j) \in S2P }\end{array}} R_{link}(m_i, m_j) \le C_{link}(d_i, d_j), \end{aligned}$$

    where \(L'\) represents the subset of SFT links \((m_i, m_j)\) that are mapped to the physical link \((d_i, d_j)\), \(R_{link}(m_i, m_j)\) represents resource requirements of the microservice link \((m_i, m_j)\), and \(C_{link}(d_i, d_j)\) denotes the maximum transmission capacity of the physical link \((d_i, d_j)\).

  • Latency Constraint. Communication latency is modeled using hop count, which limits the number of intermediate fog devices along each data transmission path between interconnected microservices. This abstraction is widely used in fog and IoT systems [42], and it is especially appropriate for localized deployments, such as construction sites, where network topologies and workloads remain relatively stable. This constraint helps maintain deadline-oriented placement by ensuring that end-to-end delays remain within acceptable bounds, as each additional hop introduces communication latency. Additionally, our model captures congestion-related effects implicitly through exclusive link allocation: when low-hop paths are already reserved, the optimizer selects alternative routes with higher hop counts, thereby simulating increased latency due to contention. This constraint is formally expressed as:

    $$\begin{aligned} \forall (m_i, m_j) \in L': dist(d_i, d_j) \le H_{max}, \end{aligned}$$

    where \(L'\) is the set of all connectivity links in the SFT, \(dist(d_i, d_j)\) is a function that retrieves the number of hops between fog devices \(d_i\) and \(d_j\), which host microservices \(m_i\) and \(m_j\), respectively, and \(H_{max}\) is the predefined maximum allowable number of hops for any communication path between any pair of microservices.

These constraints ensure an efficient mapping \(S2P\) of the SFT’s nodes (i.e., microservices) to the physical network’s nodes (i.e., fog devices), respecting the network’s functional aspects and facilitating optimal operation within the given resource limits and connectivity requirements.

Optimization model

This section presents our formal mathematical optimization model for mapping SFTs onto a physical network of fog devices. The model is formulated as a MILP problem, which is suitable for capturing the discrete nature of microservice placements and the continuous nature of resource and communication constraints. The objective is to minimize the overall cost while satisfying various resource, communication, and latency requirements.

At a high level, the model determines how microservices within an SFT should be deployed across the fog network while ensuring that resource capacities and communication constraints are satisfied. Each microservice is assigned to a single fog node, such that no device is overloaded. Communication between microservices occurs either through direct physical links or via multi-hop paths, provided sufficient bandwidth is available along each link. The model also ensures that necessary sensors are activated at fog nodes depending on microservice requirements. The cost function guiding the optimization accounts for the number of devices used, the activation of direct links, the use of multi-hop paths, and the involvement of intermediate forwarding nodes.

Solving this optimization problem directly can be challenging, as the search space of potential microservice-to-device mappings quickly becomes computationally intractable for non-trivial networks. To enhance the model’s computational efficiency, we introduce preprocessing steps to eliminate infeasible mappings before submitting the problem to the optimization solver. By limiting the search space to potentially feasible mappings only, we reduce the complexity of the optimization problem by predefining where SFT links can be placed in the physical network.

  • Direct Feasible Mapping: We identify direct feasible mappings where an SFT link between two microservices can be directly mapped to a physical network link between the fog devices that host these microservices. This involves checking if the corresponding fog devices are directly connected and have sufficient link capacity.

  • Indirect Mapping (Path Mapping): When direct mapping is not feasible due to insufficient capacity or lack of direct connectivity, we compute all feasible paths between devices, where each path consists of multiple physical links. All links in the path must have sufficient capacity to accommodate the SFT link. Intermediate nodes in the path act solely as data forwarding nodes to ensure connectivity without directly hosting the microservices.

Tables 1, 2, 3, and 4 describe the sets, indices, parameters, and decision variables used in the model. “Detailed” path mapping \(PMapDet\) captures the specific segments within each path, providing detailed information on how each part of the network contributes to the overall connection between the devices. This ensures that the indirect mapping process accounts for every hop and segment along the path.

Table 1 Sets used in the optimization model
Full size table
Table 2 Indices used in the optimization model
Full size table
Table 3 Parameters used in the optimization model
Full size table
Table 4 Decision variables used in the optimization model
Full size table
$$\begin{aligned} \min \left( \alpha \sum \limits _{j = 1}^{p} u_j + \beta \sum \limits _{(i, k, j, l) \in FMap } z_{ijkl} + \gamma \sum \limits _{(i, k, j, l, p) \in PMap } y_{ijklp} + \delta \sum \limits _{j = 1}^{p} v_j \right) , \end{aligned}$$
(1)
$$\begin{aligned} & \sum \limits _{i} R_{node}(m_i) \cdot x_{ij} \le C_{node}(d_j) \quad \forall j, \end{aligned}$$
(2)
$$\begin{aligned} & \sum \limits _{j} x_{ij} = 1 \quad \forall i,\end{aligned}$$
(3)
$$\begin{aligned} & u_j \ge x_{ij} \quad \forall i, j,\end{aligned}$$
(4)
$$\begin{aligned} & \sum \limits _{i,k} R_{link}(m_i, m_k) \cdot z_{ijkl} \le C_{link}(d_j, d_l) \quad \forall (j, l),\end{aligned}$$
(5)
$$\begin{aligned} & \begin{array}{r}\sum \limits _{\smash {(i, k, j, l, p, e) \in PMapDet }} R_{link}(m_i, m_k) \cdot c_{ijklpe} \le C_{link}(d_{j'}, d_{l'})\\ \forall (j', l') \in e, \forall e \in p, \forall p \in P, \end{array}\end{aligned}$$
(6)
$$\begin{aligned} & v_{j'} \ge \sum _{\begin{array}{c} (i, k, j, l, p, e) \in PMapDet \\ j' \in e \end{array}} y_{ijklp} - u_j \quad \forall j',\end{aligned}$$
(7)
$$\begin{aligned} & s_{ijk} \le x_{ij}, \quad s_{ijk} \le x_{kj}, \quad s_{ijk} \ge x_{ij} + x_{kj} - 1 \quad \forall i, k, j,\end{aligned}$$
(8)
$$\begin{aligned} & \sum \limits _{j, l} (z_{ijkl} + \sum \limits _{p \in P_{jl}} y_{ijklp}) + \sum \limits _{j} s_{ijk} = 1 \quad \forall (i, k) \in L',\end{aligned}$$
(9)
$$\begin{aligned} & \sum \limits _{s \in S \cap r} a_{isj} = req_{i} \cdot x_{ij}, \quad \forall i \forall j,\end{aligned}$$
(10)
$$\begin{aligned} & z_{ijkl} \le x_{ij} \cdot x_{kl} \quad \forall (i, k, j, l) \in FMap . \end{aligned}$$
(11)

The optimization’s objective function is defined by Eq. 1, which aims to minimize the overall cost of four primary factors: the usage of PN nodes, direct link mappings, path utilization, and intermediate node usage. The weighting of parameters \(\alpha\), \(\beta\), \(\gamma\), and \(\delta\) adjusts the relative importance of these factors, allowing for customization based on specific network priorities or operational constraints. In this study, we select these weights heuristically to illustrate how shifting the priority of one objective can influence trade-offs among sensor mapping cost, fog node usage, communication path cost, and link penalties. While a formal sensitivity analysis is beyond the scope of the current work, we plan to investigate trade-off curves and parameter tuning strategies in future research.

Equation 2 ensures that each fog device operates within its capacity. It stipulates that the total required capacity for all SFT nodes mapped to a particular fog device should not exceed the available processing capacity of that device. This constraint is fundamental to preventing the overload of fog devices, which could lead to performance degradation or service interruptions. The one-to-one mapping constraint, represented in Eq. 3, guarantees that each SFT node is mapped to exactly one fog device. This constraint is paramount for maintaining a clear and efficient mapping of processing responsibilities, ensuring that each SFT node’s data processing needs are met by a single, specific fog device.

Equation 4 serves as an auxiliary objective to activate PN nodes as necessary. For each SFT node \(m_i\) mapped to a PN node \(d_j\), this constraint ensures that the PN node \(d_j\) is marked as used. This helps track which nodes are actively involved in the network’s operation, aiding in resource management and optimization. The direct connection capacity constraint in Eq. 5 addresses the transmission capacities between fog devices. It ensures that the cumulative capacity required by all direct mappings of SFT links to PN links does not exceed the transmission capacities of the links between fog devices. This is vital for maintaining network integrity and avoiding data transmission bottlenecks. Equation 6 relates to the capacity constraints on paths used to connect SFT nodes via PN nodes. It ensures that the total capacity used by all paths through a particular network link (or segment within a path) does not exceed the link’s capacity. This constraint is essential for ensuring efficient data flow across the network without exceeding link capacities, which could lead to data loss or delays. The intermediate node usage constraint, shown in Eq. 7, ensures that any PN node used as an intermediate step in data paths (not just at the endpoints) is recognized and accounted for. This constraint is crucial for accurate resource tracking and ensures that intermediate nodes are only marked as such if they are actively routing data between other nodes.

Equation 8 models cases where two directly connected SFT nodes are mapped to the same PN node and thus do not need to use any network communication links. Equation 9 ensures that each pair of SFT nodes is connected in a manner consistent with their relationships and the physical capabilities of the network. This equation ensures that connections between SFT nodes either occur directly, through paths, or within the same PN node, but these connections do not overlap or conflict with each other. Equation 10 ensures that if a microservice requires a sensor, the corresponding sensor must be activated at the device to which the microservice is mapped, aligning sensor availability with microservice requirements. Finally, Eq. 11 restricts the activation of a direct link mapping only when the corresponding microservices are mapped to the specific devices connected by that link, ensuring logical consistency in link utilization.

A practical implementation of this model is shown in Fig. 6 and further described in “Experimental settings and datasets” section. However, it is important to note that our MILP-based optimization assumes that microservice placements remain stable throughout the operational phase. While the proposed MILP formulation supports latency-aware and resource-constrained SFT mapping, it does not currently address runtime adaptation or sudden load changes (e.g., sensor bursts or device failures). Mechanisms such as dynamic re-optimization or microservice migration are beyond the scope of this study and are identified as directions for future research (see “Conclusion” section).

Examples of valid and optimal mappings

In the context of this optimization model, here we show examples of valid and optimal mappings of SFTs to physical networks. For simplicity, without loss of generality, we assume that a device \(d_i\) can have either a ‘Big’ or ‘Small’ resource capacity. A device \(d_i\) with a ‘Big’ resource capacity can host either two microservices that require ‘Small’ resources or one microservice that requires a ‘Big’ resource. On the other hand, a \(d_i\) with a ‘Small’ resource capacity can accommodate only one microservice that requires a ‘Small’ resource. Furthermore, a ‘Fast’ link in a physical network can accommodate two ‘Slow’ links from an SFT. However, a ‘Slow’ link in a physical network can only accommodate one ‘Slow’ link from an SFT.

We consider in this section an SFT with six microservices \(M = \{m_1, m_2, \ldots, m_6\}\), with varying resource requirements and connectivity needs, where:

  • \(m_1\), \(m_2\), and \(m_3\) are filters denoted as \(F_1\), \(F_2\), and \(F_3\),

  • \(m_4\) and \(m_5\) are aggregators denoted as \(A_1\) and \(A_2\), and

  • \(m_6\) is an event handler denoted as \(EH\).

Each microservice in the SFT model has a specific resource requirement. In this example, the resource requirements for all microservices are uniform and defined as follows:

$$\begin{aligned} R_{node}(m_i) = \text {Small} \quad \forall m_i \in M. \end{aligned}$$

Similarly, each link \((m_i, m_j) \in L'\) has specific communication speed requirements. In this example, the communication speed requirements for all links are defined as:

$$\begin{aligned} R_{link}(m_i, m_j) = \text {Slow} \quad \forall (m_i, m_j) \in L'. \end{aligned}$$

Each filter service have specific sensor requirements, where \(F_1\) needs one temperature sensor from the set \(\{ts_1, ts_4, ts_9\}\), \(F_2\) requires one visual sensor from the set \(\{vs_1, vs_2, vs_3\}\), and \(F_3\) requires one wind gauge from the set \(\{ws_1, ws_2\}\).

The physical network consists of seven fog devices \(D = \{d_1, d_2, \ldots, d_7\}\) with resource capacities:

$$\begin{aligned} C_{node}(d_i) = \text {Big} \quad \forall d_i \in D. \end{aligned}$$

Furthermore, all communication links between the devices are ‘Fast,’ meaning each link can accommodate two ‘Slow’ links from the SFT. This is formally defined as:

$$\begin{aligned} C_{link}(d_i, d_j) = \text {Fast} \quad \forall (d_i, d_j) \in L. \end{aligned}$$

One possible valid mapping of this SFT to the given physical network is shown in Fig. 4. In this case, the microservices are mapped to devices as follows: \(m_1 \text { to } d_1\), \(m_2 \text { to } d_7\), \(m_3 \text { to } d_3\), \(m_4 \text { to } d_2\), \(m_5 \text { to } d_5\), and \(m_6 \text { to } d_6\). This mapping satisfies the resource and sensor requirements and the constraints on communication links. The connectivity between \(m_2\) and \(m_4\) is provided through \(d_4\), while the connectivity between \(m_4\) and \(m_5\) is provided through \(d_3\). However, while this mapping is valid, it may not be optimal with respect to minimizing resource usage or latency.

Fig. 4
Fig. 4

A valid, but non-optimal, mapping of an SFT to a physical network

Full size image

In contrast to the valid mapping, we now present an optimal mapping for the same SFT that minimizes resource usage and communication delay. One possible optimal mapping is shown in Fig. 5, where microservices are allocated to devices as follows: \(m_1 \text { and } m_2 \text { to } d_1\), \(m_3 \text { and } m_5 \text { to } d_3\), and \(m_4 \text { and } m_6 \text { to } d_2\). This mapping reduces the number of hops between the communication links, thus minimizing delay. The resource allocation is also optimized, avoiding the inefficient use of individual fog devices.

Fig. 5
Fig. 5

MILP-optimized mapping reduces hop count by 42.9%, fog device usage by 50%, and link usage by 66.7% compared to its corresponding valid mapping (Fig. 4)

Full size image

The key difference between the valid and optimal mappings lies in the efficient use of network resources. While the valid mapping satisfies all the primary constraints of the SFT mapping problem, the optimal mapping enhances performance by reducing delays and better utilizing fog devices across the network.

To quantify the benefits of MILP optimization, we compare the valid and optimized mappings in Figs. 4 and 5 based on hop count, fog device usage, and communication link utilization. As summarized in Table 5, the optimized mapping significantly reduces total communication cost and resource footprint.

Table 5 Comparison of valid, but not optimized vs. optimal SFT mappings
Full size table

Practical evaluation

In this section, we evaluate the effectiveness of our optimization model designed for mapping SFTs to a physical network of fog devices (“Optimization model” section). Due to the complexities of deploying large-scale networks in real-world IIoT scenarios, we used a simulation-based approach. This evaluation method aligns with prevailing practices in digital construction and IIoT research validation, as suggested by existing literature [43, 44]. Existing case studies inform our simulations on sensor types and coverage in concrete pouring scenarios [45], creating a realistic and controlled environment.

Experimental settings and datasets

Our experiments used the NetworkX Python library to simulate a physical network that replicates the infrastructure required for a concrete pouring setup in industrial construction sites. The simulated area ranges from 300 to 1000 square meters and is divided into 50 m2 sections, consistent with concrete pouring activities as discussed in “Concrete pouring scenario” section and supported by industry standards [15, 21]. The area of focus, designated as the RoI, was targeted for enhanced sensor coverage to ensure effective real-time data processing of structural and environmental conditions.

The simulation incorporated various sensor types that monitor critical aspects of construction site safety and structural integrity. Structural monitoring uses visual sensors, strain gauges, and movement sensors to track the condition of concrete pouring components, while environmental factors are monitored through temperature and wind sensors. To simplify our experimental validation, we focused on temperature and wind sensors for environmental monitoring and visual sensors for detecting structural anomalies [16].

Figure 6 illustrates the architecture of our overall simulation environment. Each module replicates a specific step in solving the microservice-to-fog node mapping problem, including the generation of direct and path mappings, feasibility checking, and optimization. The Physical Network Processor processes the fog device and sensor data, which the Network Graph Constructor then generates an undirected graph network. The Service Function Tree Processor processes the SFT nodes and links, providing this information to the Direct Link Mapping Generator and Path Mapping Generator. These modules compute the potential mappings, which are then validated for feasibility by the Mapping Feasibility Checker. Finally, the Mapping Optimizer produces the optimized mapping, minimizing resource consumption while satisfying network and service constraints.

Fig. 6
Fig. 6

Simulation environment architecture

Full size image

We implemented our optimization model using Pyomo, a Python-based modeling language for MILP formulations, and solved the resulting problems using IBM CPLEX. We configured fog networks with 6–20 nodes and SFTs with 3–10 microservices. As discussed in “Concrete pouring scenario” section, these values reflect realistic network densities and service complexity levels found in IIoT construction deployments [17]. For each generated network, we enforced the following rules: (1) each device must maintain connectivity with at least one neighboring device, (2) all devices should have access to at least one type of sensor, (3) devices can support multiple sensor types to ensure diversified monitoring, and (4) some sensors require overlapping coverage by multiple devices for comprehensive monitoring.

The SFTs employed in our experiments consist of nodes representing microservices with specific resource requirements. These nodes are interconnected, requiring particular link speeds, and range in complexity from simple configurations with a single SFC to more complex structures involving multiple interconnected SFCs.

Experiments were conducted on an Intel Core i7-1255U processor (1.70 GHz, 16 GB RAM). The experimental variables are detailed in Table 6. The implementation details are available elsewhere.

Table 6 Experimental variables
Full size table

Evaluation and discussion

The experimental results validate the effectiveness of our optimization model from “Optimization model” section in mapping SFTs to physical fog networks in an IIoT-enabled concrete pouring scenario. Our model optimizes microservice placement, enhances communication efficiency, and improves mapping accuracy, particularly for detecting critical events like drying and structural defects. These events are detected using varied sensor types, with sensor data being processed in real time to ensure accurate and timely event identification. The model focuses data processing on specific Regions of Interest, applying resources where critical events are most likely to occur while avoiding unnecessary data coverage across the entire site. Our model effectively manages resource constraints, communication requirements, sensor coverage, and the associated physical network limitations by minimizing the number of physical nodes and communication paths. It optimizes microservice placement by ensuring proximity to sensors and facilitating effective environmental and structural monitoring based on available resources.

Figures 7, 8, 9, 10 and 11 visually differentiate the states and roles of nodes and links within the physical network and the SFT through color coding. In the physical network on the right, light blue nodes represent the default state of physical network nodes with no microservices mapped and light green nodes denote nodes hosting microservices. Orange nodes represent intermediate nodes utilized in multi-hop paths, while light gray nodes serve dual roles as both intermediate nodes and microservice hosts. These colors illustrate how the model allows devices to assume multiple roles within the network based on SFT and sensor requirements. Sensors that meet microservice requirements in the RoIs are marked in yellow. The light yellow text box in each figure shows how SFT links are mapped to physical network links: directly, indirectly (via multi-hop paths), or with no mapping needed if the end nodes are co-located on the same physical node. Link consumption, depicted as ‘Cons: 1’ or ‘Cons: 2,’ indicates the number of SFT links mapped onto a physical link, while ‘Rem: 1’ or ‘Rem: 0’ indicates the remaining link capacity.

Fig. 7
Fig. 7

SFT to PN mapping, three microservices and six fog nodes; MILP-optimized mapping reduces hop count by 60%, fog device usage by 33.33%, and link usage by 66.67% compared to its corresponding valid, but not optimized mapping

Full size image
Fig. 8
Fig. 8

SFT to PN mapping, four microservices and six fog nodes; MILP-optimized mapping reduces hop count by 66.67%, fog device usage by 25%, and link usage by 60% compared to its corresponding valid, but not optimized mapping

Full size image
Fig. 9
Fig. 9

SFT to PN mapping, six microservices and ten fog nodes; MILP-optimized mapping reduces hop count by 54.55%, fog device usage by 16.67%, and link usage by 63.64% compared to its corresponding valid, but not optimized mapping

Full size image
Fig. 10
Fig. 10

SFT to PN mapping, eight microservices and fifteen fog nodes; MILP-optimized mapping reduces hop count by 37.5%, fog device usage by 0%, and link usage by 23.08% compared to its corresponding valid, but not optimized mapping

Full size image
Fig. 11
Fig. 11

SFT to PN mapping, ten microservices and twenty fog nodes; MILP-optimized mapping reduces hop count by 33.33%, fog device usage by 10%, and link usage by 29.41% compared to its corresponding valid, but not optimized mapping

Full size image

On the left-hand side of each figure, the SFT illustrates the resource requirements of each microservice, with ‘Cap: Small’ or ‘Cap: Big’ indicating whether a small or large capacity is needed. Physical network nodes can accommodate one small, one big, or two small microservices, with two small requirements equal to a big one in resource usage. Similarly, communication links in the physical network can accommodate either one fast link or two slow links, as indicated by ‘L: Slow’ or ‘L: Fast’ in the SFT. ‘Req: 1’ indicates that a microservice requires one sensor from the RoI to be within the communication range of a physical network node for successful mapping.

The range of network topologies, from simpler configurations in Fig. 7 to more complex ones in later figures, highlights the model’s robustness in handling different deployment scales. Figures 7 and 8 illustrate the initial microservice mappings onto a smaller physical network with six fog devices. By minimizing the number of nodes required, the model reduces resource bottlenecks, improves communication efficiency, and maintains network resilience. Figure 9 expands on this by illustrating the model’s capability to maintain essential connectivity through multi-hop paths, optimizing the flow of communication while minimizing hop count and transmission delays. These multi-hop paths are crucial when direct links are unavailable and for scenarios requiring rapid responses, such as detecting shifts in concrete integrity or environmental conditions.

Figure 10 reveals instances where certain physical network links become fully utilized, indicated by ‘Rem: 0.’ This saturation highlights the importance of careful resource planning in high-demand situations. Despite the resource constraints, our model prioritizes direct mappings to avoid unnecessary use of intermediate nodes and ensure communication stays within capacity limits. Figure 11 showcases the model’s ability to optimize mappings based on sensor requirements across the RoI. Though the model operates statically, it optimally places microservices closer to the network edge, considering sensor proximity and link capacity. The model processes critical data without overwhelming the network by allocating resources to the most critical areas. The selective data processing strategy maximizes the efficiency of the fog computing layer and prevents unnecessary data overload. These results confirm our optimization model’s effectiveness in mapping SFTs to physical networks in IIoT-enabled construction sites.

Beyond evaluations, we demonstrate how our simulated SFT mappings correspond to real-world event triggers through a case where Geokon GK-8 T sensors detect a rapid increase in ambient temperature exceeding 38\(^{\circ }\)C within a 50 sqm RoI. This elevated temperature reading indicates a high risk of early curing defects [15] and triggers a predefined SFT for environmental risk mitigation. The SFT includes a temperature filter microservice (\(F_1\)), an aggregator microservice (\(A_1\)), and an event handler microservice (EH). These microservices are mapped onto fog devices, as shown in Fig. 8. While \(F_1\) is placed on device \(d_2\) due to its proximity to the sensor source, \(A_1\) and EH, which are not constrained by direct sensor attachment, are mapped onto devices \(d_3\) and \(d_4\), respectively, based on hop count minimization and resource availability. This optimized placement enables low-latency processing and supports timely decisions, such as initiating misting procedures to mitigate surface evaporation. While this case illustrates how real-time sensing triggers SFT mappings, it also highlights the need for efficient communication paths and minimal delay - both of which are influenced by intermediary node usage.

As noted in “Optimization model” section, our optimization model includes a \(\delta\)-weighted penalty for intermediary fog nodes used solely to forward data between microservices. This discourages multi-hop communication chains that could increase latency or create bottlenecks, especially in resource-constrained fog environments. While the model does not explicitly simulate performance impacts such as queuing or congestion at intermediary nodes, these effects are implicitly captured through hop count and path cost penalties. This abstraction ensures tractable optimization and supports our focus on SFT placement.

To assess the computational impact of preprocessing, Table 7 summarizes the candidate mapping space and total computation times with and without preprocessing for the scenarios illustrated in Figs. 7 to 11. The results show that preprocessing prunes up to 75.54% of infeasible mappings and reduces the size of the optimization problem. This leads to 18–95% reductions in computation time. For instance, in the largest configuration (20 fog nodes and 10 SFT nodes), the number of mapping candidates dropped from 65,790 to 23,533 (a 64.23% reduction), and computation time was reduced from 7282.19 seconds to 784.05 seconds, achieving an 89.24% speedup. These results demonstrate the practical benefits of our preprocessing design for scaling to larger deployments.

Table 7 Impact of preprocessing on computation time and candidate mapping space
Full size table

To directly compare our MILP-optimized mappings with valid, but not optimized mappings obtained in prior work [8], Table 8 summarizes the resource and communication metrics across the five evaluated scenarios. On average, the MILP approach reduces total hop count by up to 66.67%, the number of fog devices used by up to 33.33%, and link usage by up to 66.67%. These results validate the performance gains of our model over prior valid mapping strategies.

Table 8 Comparison of valid, but not optimized mappings (baseline from prior experiments [8]) and our MILP-optimized mappings
Full size table

While our MILP-based formulation offers optimal SFT mappings for mid-scale fog networks (e.g., up to 20 nodes), scaling to larger networks with 50+ nodes may introduce computational overheads that hinder real-time responsiveness. To mitigate this, our proposed preprocessing steps can serve as a modular foundation for hybrid strategies, where heuristic or metaheuristic algorithms (e.g., greedy search, genetic algorithms, or NSGA-II) are applied after pruning the search space. These methods can yield near-optimal mappings with significantly reduced runtime. As part of future work, we intend to integrate such heuristics into our framework, perform large-scale simulations, and benchmark their performance relative to the MILP baseline.

Conclusion

We have presented an optimization model designed to enhance microservice placement within IIoT networks, particularly addressing the challenges of deploying interdependent microservices across fog computing infrastructures. Traditional strategies often struggle with complex event-processing requirements, where function chains are interdependent and require precise execution orders aligned with sensor availability in their respective Regions of Interest. Our model optimizes resource allocation, communication links, and microservice placement by handling the complexities of event processing in high-stakes, business-critical scenarios like concrete pouring. Utilizing a MILP formulation and strategic preprocessing steps, the model ensures feasible mappings between Service Function Trees and physical network components, enhancing data processing efficiency and resource utilization. The model’s performance was evaluated through simulations involving both simple and complex scenarios, demonstrating its ability to deploy multiple interconnected microservices while minimizing the use of physical nodes and communication paths. This represents a substantial improvement over manual placement strategies, which are often inefficient and error-prone, particularly in complex scenarios.

The computational demand of our model grows with the complexity and size of the Service Function Trees. While our MILP model offers exact solutions for moderately sized networks, we plan to explore heuristic-based alternatives that approximate optimality while ensuring tractability for larger or dynamic deployments. These methods, when combined with our existing preprocessing steps, could enable scalable and time-sensitive decision-making in broader IIoT contexts. Additionally, while the current configurations primarily focus on integrating data streams from similar sensor modalities within the communication range of a single fog device, future enhancements will aim to incorporate data from varied modalities across multiple devices for refining the model’s adaptability to more complex IIoT environments. We also plan to extend the model’s capabilities to dynamically adjust to real-time changes in network conditions and workload fluctuations to enhance its utility in highly dynamic operational contexts.