# Machine Learning Techniques for Non-Terrestrial Networks
## 6 Machine Learning Techniques in NTN
### ML for NTN Service
In search and rescue, a drone can use object detection to spot people and alert the rescue team. As for the isolated areas scenario, an UAV can offload the expensive computation (e.g., image processing) to an air-space MEC or a terrestrial one. Deep learning-based object tracking can also be used to follow rescue teams and in addition to bring them connectivity; they also scan the surrounding area. **Broadcasting/Multicasting. ** ML has a significant role in optimizing cache performance. Existing network architectures struggle in handling mass content delivery with low response time. Having the contents at the edge of the network is vital to enable interactive broadcast services. To this aim, a ML framework can decide to fetch contents in advance and proactively push it to the edge reducing the delay and the network burden, especially in peak hours. The learning process in this case is based on content popularity, user access and mobility. A problem that arises by introducing caching services is the replacement strategy. Traditional cache replacement techniques, such as first-in first-out (FIFO), least frequently used (LFU) or least recently used (LRU) do not fit well in a non-deterministic scenario. To mitigate this problem, a (deep) Q-Learning RL network could be applied to take cache replacement/eviction decisions based on the Q-Value or reward obtained from the environment [41]. Concerning the performance metric, the authors measured the system throughput as a function of the cluster size under different replacement schemes. In their test-bed implementation, the adoption of a dynamic RL-powered policy improved the throughput by 4-5 times compared to a static policy. Table 4 reports some of the ML techniques that can be applied to each NTN service presented in Section 4.1. As a final remark, it is worth noting that the assessment of the deployment position of a MEC is important for two main aspects. First, a MEC cannot be placed everywhere in the NTN architecture. In fact, it is necessary to consider the protocol stack of the system since MEC has to be deployed in (terrestrial or non-terrestrial) network elements able to read the user IP address at least in order to properly route the user packets to it and to retrieve contents (see [42]). This is possible only for UPF in the 5G architecture if we look at the UP. Theoretically, it is possible to deploy a gNB and (light) UPF on-board of an NTE, even if not considered in the protocol stack architectures reported in Section 4.2. However, this bring us to the second point. Installing a MEC in a UAV can be challenging due to energy constraints, processing capacity limitation and storage issues. It may be possible on a HAPS or LEO. Proper design should be considered for deploying a MEC on board NTE. Of course, its advantages will be many in terms of latency, experienced throughput and traffic offload [43]. In Figure 13a, a possible deployment of the MEC is reported. In this case, we considered only the on-board NTE deployment, which is more challenging in terms of weight and energy consumption but at the same time better performing for all NTN services since it provides the highest data rates and the lowest delays. In Figure 13b, it is reported the general scheme of the MEC architecture [44]. The MEC hosts its applications running over virtual machines on the virtualization infrastructure. The MEC platform supports the application configuration. It is provided by the MEC host manager, which, for example, configures traffic rules, policies, and solves possible conflicts. The MEC system management is in charge of instantiating the applications requested by UEs (i.e., the customers) through the operation support system and supported by the MEC orchestrator. Finally, in order to provide the connectivity of the MEC of another mobile network operator, it should be provided by connecting the two MEC hosts through the two MEC platforms.