## 5 Proposed Multi-EC Enabled Air-Ground VN Scenarios
### ML for Computation Offloading in Multi-Service Multi-EC Vehicular Environments  
#### 5.2.1 Scenario Description  
In multi-service multi-vehicular environments, several VUs randomly distributed over large coverage areas generates different kinds of vehicular services requests. In general a service request can be represented by a tuple \(\langle D_{s,m},\Omega_{s,m},T_{s,m}\rangle\) where, \(s\) is the particular service type, \(m\) is the index VU requesting \(s\), \(D_{s,m}\) is the service task size in Byte, \(\Omega_{s,m}\) are the requested CPU execution cycles and \(\widehat{T}_{s,m}\) is the maximum latency of the requested service. With limited onboard resources, VUs alone cannot handle such requests and require computation offloading services from different EC platforms over joint T-NTN, allowing them to offload a complete/certain portion of their workload towards EC nodes. This allows VUs to share their workload with EC nodes for halving the overall task processing costs (e.g., task processing latency energy). However, in the case of a Multi-EC multi-service vehicular environment, for handling a large number of service requests of different kinds, the selection of a proper EC platform and its individual EC node/nodes for offloading can be a challenging problem to be solved. This is due mainly because of different natures of services, varying coverage limits transmission distances, and available resources of EC platform layers. Moreover, selecting the wrong EC platform can add larger latency and energy overheads or might even create service failures. For example, if the requested service is a critical latency service, such as autonomous driving or drivers safety-related services (i.e., small \(\widehat{T}_{s,m}\)), selecting a BS-EC or HAP-EC platform can not be a practical solution due to longer transmission delays (see Table 3). On the other hand, if the requested service is data-intensive, requiring larger computation resources (i.e., large \(\Omega_{s,m}\)), selecting \begin{table}
\begin{tabular}{p{42.7 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt}} \hline \hline
**FL Platform** & **VUs Computation Latency/Energy** & **VUs Communication Latency/Energy** & **Data Privacy** & **VUs Participation** & **Possible Challenges** \\ \hline
**Hierarchical FL** & High on-device computation cost & Reduced VUs communication delay/energy due to short-distance communication between VUs and LAP/RSUs & Reduced VUs communication other nodes (privacy-preserving). & FL model training process is performed by VUs alone without sharing data with any other nodes (privacy-preserving). & High on device training latency and energy cost can limit the number of VUs participants in the FL process. & Selection of proper LAP/RSU node (for mid-layer processing) is required for avoiding additional handover costs. & Selection of proper LAP/RSU node (for mid-layer processing) is required for avoiding additional handover costs. & Selection of proper LAP/RSU node (for mid-layer processing) is required for avoiding additional handover costs. & Selection of proper LAP/RSU node (for mid-layer processing) is required for avoiding additional handover costs. & Selection of proper LAP/RSU node (for mid-layer processing) is required for avoiding additional handover costs. \\ \hline
**Computation Offloading based** & Offloading process reduces the computation time and energy during the training process, & High Communication Delay/Energy Cost due to Long Distance Communication & VUs Data Needs to be Shared with the Out-Side World. & Large Number of VUs can Participate into FL Process. & Selection of a Proper Edge Node and Offloading Amount During Offloading, Requires VUs data to be Send to the Outside World. \\ \hline \hline \end{tabular}
\end{table} 
Table 4: The characteristics of the proposed solutions for the cost efficient FL platform. Figure 8: Computation Offloading for FL. RSU-EC or LAP-EC might not be a good idea. With their limited computation capabilities, overall computation latency can become very high.