## 3 Methodology
### VGG16 Architectures in Federated Learning (Decentralized and Centralized)
Importantly, the model's structure remains unchanged across clients and all updates are limited to model parameters, ensuring that no raw data is exchanged throughout the training process. Furthermore, the use of a frozen backbone combined with a compact classifier head enables training in resource-constrained edge environments, while also supporting efficient aggregation due to reduced parameter volume. The decentralized approach's robustness against single-point failures and its alignment with edge AI principles further validate its viability for real-world fall-detection deployment. In contrast, the centralized federated learning paradigm leverages a central server that orchestrates the aggregation of model updates. As shown in the right panel of Figure 5, each of the three clients (Client 1, Client 2, and Client 3) independently trains a local replica of the VGG16 model using its respective dataset. Upon completion of each local training session, the clients transmit their updated model parameters to the central server. The server then performs weighted Federated Averaging, a technique that accounts for the data distribution across clients by adjusting the contribution of each client based on its dataset size:  
\[W_{global}^{(t+1)}=\sum_{i=1}^{N}\frac{n_{i}}{\sum_{j=1}^{N}n_{j}}\cdot W_{i}^{( t)} \tag{4}\]  
where \(W_{i}^{(t)}\) is the model weight vector from client i at communication round t, and \(n_{i}\) represents the number of samples in the local dataset of client i. This procedure is repeated over 10 communication rounds, with each client performing 15 local training epochs per round, using a batch size of 32. The central server is responsible not only for aggregating the updates but also for distributing the new global model to all clients at the start of the next round. The centralized architecture benefits from simplified coordination and convergence behavior that is often more stable due to the synchronized updates. However, it introduces certain limitations, including the potential for network bottlenecks, increased latency at the server node, and the risk of a single point of failure. While the privacy of raw data is preserved--since only weights are exchanged--the centralization of model aggregation may not fully satisfy stringent decentralization or edge deployment requirements. Both federated learning strategies depicted in Figure 5 adhere to the core principle of privacy preservation by ensuring that no raw data is transmitted between entities. This is a critical requirement in the clinical contexts where fall-detection systems are deployed, e.g., homes, rehabilitation centers, and hospitals. The decentralized configuration demonstrates stronger alignment with edge computing paradigms, favoring resilience, peer collaboration, and minimal central infrastructure. Meanwhile, the centralized approach facilitates a more structured orchestration, with potentially faster convergence in controlled environments. Figure 5: Comparative illustration of decentralized and centralized federated learning architectures using VGG16 for fall detection. **(Left)** Decentralized setup where clients train a global VGG16 model and sequentially update it in a ring topology. The architecture includes a frozen VGG16 backbone, followed by Flatten, Batch Normalization, Dense (512), and a final sigmoid classification layer. **(Right)** Centralized setup with clients independently training local copies of the model and sending updates to a central server for aggregation. Each model uses the same classification head as the decentralized variant. Only model parameters are shared, preserving data privacy. By applying a consistent model architecture across both strategies, this study offers a rigorous comparative framework to evaluate the trade-offs between privacy, scalability, fault tolerance, and learning efficiency in federated fall-detection systems using VGG16.