## 4 Experiment and Analysis  
### Simulation Environment  
In simulation environments, there are three significant phases including MLSTM-based modelling, E2E IIoT networks, and FL communications for imaging services. For the first phase, the Python programming language is used for MLSTM-based modelling experimentation [43; 44; 45]. The proposed algorithms contain specified parameters and algorithmic flow, as described above, in collaboration with the deployed system architecture. The interaction between the prediction module and the orchestration entity enhances real-time and elastic performance. The parameters, including the number of models, batch sizes, dense units, MLSTM units, and the number of testing epochs, are set to 3, 512, 4 times the number of MLSTM units, 128, and 125, respectively. The input data of \(X_{M_{n(t)}}\) is gathered through device and resource abstractions using OpenFlow-based techniques, flow monitoring, and RESTful API techniques. The overview procedures of the MLSTM-CEFL simulation are illustrated in Figure 3. The primary stage encompasses inputting the gathered FL model and network states until the evaluation of both training and testing batches is completed. Algorithm 1 demonstrates the pseudocode for implementing our proposed controller, MLSTM-CP, in TensorFlow and Keras-based functions (e.g., _SpatialDropout1D_, etc. ), integrating virtual containers at the edge and network interfaces through SDN/NFV MANO to converge with the final MLSTM-CEFL policy (lines 18-23). Utilizing general features collected, as given in Equation (5), the model selection and splitting processes are executed for training batches \(\left(X_{M_{n(t)}}^{tr},Y_{M_{n(t)}}^{tr}\right)\) and testing batches \(\left(X_{M_{n(t)}}^{te},Y_{M_{n(t)}}^{te}\right)\). The procedure begins by initializing the number of models, batch sizes, dense units, MLSTM units, and the number of epochs, denoted as \(N(m)\), \(B(s)\), \(D(u)\), \(MLSTM(u)\), and \(N(e)\), respectively. The **modelBuilder** function is executed with a subordinate computing controller, linked to the SDN database, to construct the model's structure. Parameters, hyperparameters, loss, and optimizer functions are configurable to maximize the optimality of **finalModel**. Withmultiple models, each model type is specified using the **modelBuilder** function and fitted with different batch sizes and weights. For sustained reliability, an averaging formulation is applied to each output of the **finalModel**. Two baseline approaches are employed for comparison: (1) the conventional LSTM-based congestion-aware FL aggregation scheduling and (2) MLSTM for centralized congestion-aware FL aggregation scheduling, denoted as CLSTM-CFL and MLSTM-CCFL respectively. Each method is explained as follows:  
* **MLSTM-CCFL** employs the same MLSTM architecture to predict congestion rates within a centralized FL framework. This approach capitalizes on MLSTM's proficiency in capturing temporal dependencies and adapting to dynamic input sequences. However, in this method, data from multiple participants and edge devices, along with their update statuses, are collected and transmitted to a central processing unit  
Figure 3: Overview of MLSTM-CEFL procedures for denormalizing the hidden state into congestion rate \(Y_{M_{(t)}}\). where the MLSTM model predicts congestion. The centralized feature of this approach introduces a trade-off between two factors: (1) the increased latency due to the need to transmit input features to a central server for processing and (2) the benefits of globalized and uniform decision making. * **CLSTM-CFL** relies on the capacity of traditional LSTM to recognize temporal patterns and relationships in FL input data. CLSTM-CFL can be limited by its conventional LSTM architecture, which may hinder its ability to promptly respond to real-time variations and adapt effectively to evolving state dynamics, such as multi-round participant model updates and edge aggregation.