# A Proposal for a Federated Learning Protocol for Mobile and Management Systems
## 5 Communication Protocol Simulation  
To assess the efficacy of the communication protocol design, a simulation was implemented within the MATLAB R2022a Simulink software [23]. The simulation resources are available in ref. [24]. The simulation comprised three fundamental components: a server, a database, and clients. The operational characteristics of these components are delineated through state transitions, collectively constituting a comprehensive state graph for each. Inter-component communication is facilitated through the transmission of messages and events, grounded in the reciprocal exchange of states. The constituent elements of the simulation were constructed based on the logic proposed in the communication protocol, augmented by additional logic essential for testing all conceivable scenarios that may arise during their interaction. The simulation itself was formulated to enable the emulation of communication involving any quantity of clients with a single server through a real-time database. The structural details of the individual foundational components are explicated in the subsequent sections. The state graph corresponding to the client is illustrated in Figure 5. Upon commencement of the simulation, the client initially transitions to the INIT state, wherein it requests configuration information from the database and awaits a response. Subsequent to the configuration retrieval, the client progresses to the CONFIGURATION state, wherein it selects the server for communication. Following this, the client enters the READY state, signaling its preparedness to receive a job for processing and awaits such a job from the server. Upon receipt of a task, the client enters the GATHER_DATA state, wherein client data are collated for learning. Another state, TRAINING_MODEL, involves training the model acquired during configuration, resulting in the creation of a new local model specific to the client. Post each training round, local weights are transmitted to the server, and the client anticipates the reception of new global weights. This iterative process persists until the completion of all rounds specified in the job assignment. Subsequently, the training concludes, and the client, in the RESTORE state, obtains the newly trained global model before reverting to the READY state. This cyclic process repeats periodically, contributing to the refinement of the global model. The OFF state was incorporated into the status graph, which the client enters if it is deactivated in the simulation, thereby facilitating the simulation of random login and logout events of client devices. The state graph corresponding to the server is depicted in Figure 6. Upon activation, the server transitions to the MODEL state, where a default data model is generated for subsequent enhancement by clients. It then proceeds to the SERVER_INTERFACE state, awaiting job requests from individual clients. Upon receipt of job requests from all reg  
Figure 4: Server site logic. istered clients, jobs are dispatched to clients in the INITIALIZATION state. The server subsequently awaits local weights from clients and, upon reception, transitions to the TRAINING_GLOBAL_MODEL state, wherein these weights are amalgamated into global weights. This process iterates until the conclusion of all rounds specified in the job. Following the overall training, a novel global model is formulated and disseminated to clients. The server reverts to the SERVER_INTERFACE state, awaiting further client task applications. The state graph for the database, as delineated in Figure 7, is formulated to consist of message and event forwarding between the server and the database. It preserves information pertaining to the status and quantity of clients. Additionally, each component encompasses a state graph for KEEPALIVE messages, which is integral for sustaining the connection between the client and the server via the database.