## 5 Distributed Machine Learning Algorithms
### Federated Learning  
While collaborative learning mainly relies on the exchange of information among vehicles and their co-located learning agent, in federated learning (FL), the approach is a bit different. Indeed, the exchange of data among nodes could impact the learning convergence a lot, since a large amount of data should be transferred. Despite the fact that new 5G technologies allow high data rate transfer, collaborative learning still need to transfer huge amounts of data. In FL, instead, the idea is that of exploiting, in a more inherent way, the ML algorithm's parameters. In that context, the simplest FL scenario is defined through the presence of a central unit aiming at only merging the ML parameters, where the ML agents are implemented in a distributed fashion. Such unit, which can be RSUs or vehicles, should execute a partial training process on their own data, while the partial model is uploaded to the central node. After having merged all the nodes, the central node sends the general ML model parameters back to the agents. The process is repeated several times up to achieving convergence. Such an approach is convenient in a distributed scenario, such as IoV, where multiple nodes can parallelize the ML algorithm execution, while the global model is evaluated at a central point. In addition, since only the model parameters are exchanged, privacy concerns are avoided, where only the ML parameters are exchanged among nodes. The importance of using FL in IoV scenarios is evident by looking at several papers recently published on FL application to the vehicular environment. In particular, for a better understanding of the main solutions and challenges, the interested reader could refer to [103, 104, 105]. More recently, FL has been further extended with more challenging IoV scenarios. As an example, [PERSON] et al. [106] extend the traditional two-layers model to a three-layer model, where vehicles, RSUs, and the cloud interact to create a hierarchical FL structure. In particular, the RSUs perform an intermediate aggregation to limit the burden on the cloud when several updates are sent simultaneously. [PERSON] et al. [107], propose to use a semi-synchronous approach to limit the detrimental effect of dynamicity in the vehicular scenario. In this approach, only a subset of the nodes update the model depending on their characteristics, while others can update the model while the aggregation is performed. In this way, the convergence speed would be much higher while most of the parameters coming from the vehicles are considered. The use of edge computing is also considered by [PERSON] et al. [108], where a four-layers infrastructure is supposed to be implemented. The intermediate MEC layer is deployed for computation offloading operations, while it is proposed to be used also for implementing the FL process. [PERSON] et al. [109] propose an algorithm for selecting the nodes that should participate in the FL process. An edge-computing-based joint client selection and networking scheme for IoV is proposed by assigning some vehicles as edge vehicles, employing a distributed approach, and using vehicles as FL clients to conduct the training of local models, which learns optimal behaviors based on the interaction with environments. [PERSON] et al. [110] instead consider the FL for solving the scheduling problem when trying balance the computation load among different nodes. Thanks to FL, the process can be more effectively balanced considering also the user mobility and their constraints. [PERSON] et al. [111] propose an economic framework for improving the advantages from the internet service provider point of view in helping the vehicles. This is achieved through the use of an FL platform that is able to select the best vehicles to be part of the FL process. [PERSON] et al. [112] propose instead a different approach that considers the possibility of jointly exploiting the VEC nodes for both FL and offloading process.