# Hierarchical Federated Learning-Based Intrusion Detection for In-Vehicle Networks
## 3 Materials and Methods
### Hierarchical Federated Learning Architecture  
The H-FL architecture consists of a main cloud server, several edge servers (aggregators), and numerous clients (vehicles), as depicted in Figure 2. The cloud server is connected to the edge servers, each of which interacts with vehicles in different geographical locations. In this paper, we utilize one main server, two edges, and five clients per edge. The H-FL process begins with the cloud server sending the initial model to the edge servers. Each edge server then selects a subset of clients for training using a suitable selection approach. The selected clients receive the initial model and perform edge aggregations over several rounds to generate an edge model. Once the edge servers complete their aggregations, they send their aggregated models' parameters to the cloud server. The cloud server aggregates these edge models to produce a global model, which is then sent back to the edge servers for further aggregation. A detailed description of the H-FL process is provided in Table 2. To handle the variability in CAN bus data across different vehicle makes and models, edge servers select clients based on similarities in their CAN bus data, such as make or model, within specific geographical areas. This approach ensures that the global model is trained on relevant and similar data, thereby improving accuracy. The main server, located at 127.0.0.1:8088, initiates the process by distributing the pre-trained model to its connected clients (edges). Subsequently, each edge, serving as a server at addresses 127.0.0.1:8080 and 127.0.0.1:8081, respectively, relays the pre-trained model to its connected clients (vehicles). Each edge server then starts the standard FL \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Ref.** & **Fed. Learning** & **U Attacks** & **Non-IID** &
\begin{tabular}{c} **Aggregation** \\ **Function** \\ \end{tabular} & **Dataset** & **FL Implementation** \\ \hline
[14] & Standard & x & ✓ & FedAvg & car-hacking [22] & PyTorch \\ \hline
[11] & Standard & x & x & FedAvg & HCRL CAN Intrusion Detection [23] & N/A \\ \hline
[10] & Standard & x & x & FedAvg &
\begin{tabular}{c} car-hacking [22], \\ NAIST CAN attack dataset [24] \\ \end{tabular} & Keras, TensorFlow \\ \hline
[12] & Standard & ✓ & — & FedAvg, FedProx & READ [25] & N/A \\ \hline
[9] & Standard & x & x & FedAvg &
\begin{tabular}{c} Car Hacking: Attack \& Defense \\ Challenge 2020 [26] \\ \end{tabular} & Keras, TensorFlow \\ \hline
[13] & Standard & x & ✓ & FedAvg & HCRL CAN Intrusion Detection [23] & N/A \\ \hline Our work & Hierarchical & ✓ & ✓ & FedAvg & car-hacking [22] & Flower \\ \hline \hline \end{tabular} U Attacks: Unknown Attacks.  
\end{table} 
Table 1: FL-based IDSs for in-vehicle networks. process with the clients (vehicles) in its area, resulting in an edge model. These edge servers, now operating as clients, send their models back to the main server. The main server aggregates the received edge models into a global model, which it then redistributes to the edges. Finally, the edges, again functioning as servers, transmit the new global model to their clients (vehicles) to restart the FL cycle. Figure 3 illustrates this H-FL setup as implemented in Flower.