## 3 Federated Learning for Space-Air-Ground Integrated Networks
### Privacy-Preserving Federated Learning
#### 3.5.2 Local Aggregation at Edge Nodes  
In space-air-ground integrated networks, terminal devices (such as UAVs, ground user terminals, etc.) train models based on local data, while edge nodes are responsible for aggregating these local models from terminal devices to form a more accurate global model. Due to the challenges faced by space-air-ground integrated networks, such as high latency, bandwidth limitations, dynamic network topology, and device heterogeneity, the role of edge nodes is crucial. Edge nodes not only need to select devices to participate in aggregation but also need to optimize the aggregation process according to device characteristics such as computational capability, bandwidth, and availability. In privacy-preserving federated learning for space-air-ground integrated networks, edge nodes need to collect status information from terminal devices to determine which devices are suitable for participating in the current round of model aggregation. Device status information includes computational capability, bandwidth, data volume, connection status (whether stable), etc., which helps edge nodes assess device participation. The status information of device \(i\), \(S_{i}\), as shown in Equation (19), includes the computational capability \(C_{i}\), bandwidth \(B_{i}\), connection status \(connection\_status_{i}\), time of last model update upload \(last\_update\_time_{i}\), and other status information of device \(i\). When edge nodes perform local model aggregation, they select suitable devices to participate in local model aggregation. In privacy-preserving federated learning for space-air-ground integrated networks, due to factors such as bandwidth limitations, unstable device connections, and high communication latency, communication between devices may be interrupted, which can lead to some devices being unable to upload their locally trained model parameters to edge nodes in a timely manner. Therefore, designing an effective caching mechanism is one of the key strategies to address these issues. The caching mechanism ensures the continuity of the model and the integrity of device updates, and can cope with the instability of device connections. After device \(i\) completes local training, it uploads its trained model parameters \(\theta_{i}\) to the edge node. The upload depends on the device's network connection status. If the device connection is stable, the model parameters are directly uploaded to the edge node for aggregation. When communication between the device and the edge node is interrupted (for example, periodic interruption of the connection between the satellite and the edge node), the device cannot immediately upload the model parameters. At this time, the device caches the locally trained model parameters \(\theta_{i}\) until the network recovers. The cache queue \(Q_{\text{cache},i}\) is used to store model parameters that have not been successfully uploaded, specifically represented as:  
\[Q_{\text{cache},i}=\left\{\theta_{i,t_{1}},\theta_{i,t_{2}},\ldots,\theta_{i, t_{k}}\right\} \tag{42}\]  
where \(\theta_{i,t_{k}}\) represents the cached model parameters of device \(i\) at time \(t_{k}\). The cache queue \(Q_{\text{cache},i}\) stores device model updates in timestamp order. The cache time \(cache\_time_{i}\) represents the caching time of device \(i\) since the last upload failure, i.e., the waiting time of model parameters since the upload failure, specifically represented as  
\[cache\_time_{i}=t_{\text{current}}-t_{\text{upload},i} \tag{43}\]  
where \(t_{\text{current}}\) is the current time, and \(t_{\text{upload},i}\) is the time when device \(i\) last successfully uploaded the model. The cache time directly affects device selection and model update priority. The longer the device's cache time, the higher its upload priority.