## 1 Introduction  
In recent years, with increasing demands for high data rate applications, mass connectivity, universal internet access, Internet of Things (IoT), and wireless ad hoc networks, there has been an interest in LEO satellite mega-constellation networks, which are composed of multiple satellite orbits and hundreds of small satellites with lower delay [1, 2, 3, 4]. Due to the LEO satellite mega-constellation supporting delay-sensitive services, it has become a hotspot for B5G and 6G [2, 5, 6, 7, 8]. What is more, the LEO satellite mega-constellation network for the IoT has become a common goal in the industry and academia [9, 10, 11, 12]. On the other hand, the generated big data from IoT creates a severe challenge to the network architecture based on TCP/IP [13, 14]. The IoT needs to support mobility, content distribution, and in-network caching. As a result, academic efforts have converged on a proposal for a future IoT architecture under the name of Information-Centric Networking (ICN) [15; 16; 17]. ICN is particularly valued in B5G and 6G core networks, WANET, IoT, and other fields [18; 19; 20; 21]. Importantly, the architecture of ICN supports the high movement of satellite nodes [22], which causes the dynamic change of topology and intermittent connection between satellite nodes [19]. Meanwhile, it should be emphasized that the reasons why ICN supports the high movement of satellite nodes are because of ICN's ubiquity of caching nodes, using caches not only at the edge but also at all levels of the network. Hence, in-network caching is an important feature, and how to manage cache is a key issue for the ICN network. We explore the new concept of LEO satellite mega-constellation Information-Centric Networking for IoT, denoted by LEO-SMC-ICN-IoT in this paper and focus on in-network caching. In LEO-SMC-ICN-IoT, the LEO satellite mega-constellation not only functions as a network infrastructure, providing globally scalable connectivity with lower delay and cost, but also as a passive and host IoT access device for the physical world. Generally, the caching policy can be either proactive or reactive and solves the problem of how to cache while partially responding to when to cache [23]. In earlier proposals for ICN, the original caching scheme called the Leave Copy Everywhere (LCE) policy is described in [24; 25]. For LCE, much cache space is wasted because the content is cached on every node in ICN, and lots of redundant content is produced. Furthermore, the Leave Copy Down (LCD) scheme is proposed in [24; 26], the LCD caches the content at the downstream node of the hit node to improve the utilization of the cache space, but this approach is usually reactive. The proactive approach predicts the popularity based on user preferences and prefetches content to further lower access time [23]. A proactive caching policy can considerably reduce the delay, increase the quality of experience, and relieve the burden on transit and backhaul links. So, the proactive policy is more suited for IoT services. Identifying how to make accurate predictions is the main issue for proactive caching approaches. To improve cache efficiency and performance, the paper [27] proposes a distributed and opportunistic (OPP) on-path caching scheme, where each on-path node independently picks contents to cache, and popular content is more likely to be cached by nodes. In [24], the contents are cached with a constant probability, and the policy is named random autonomous caching. The paper [28] proposes a heuristic caching policy based on probability, which combines the predicted content popularity and the content policy benefit. The paper [29] proposes a cooperative caching framework for mobile nodes caching data according to predicted preference. Unfortunately, the works above only make predictions of content, not nodes. Hence, while the locations of nodes are changing over time, the caching policy makes it difficult to accurately predict the popularity, which lowers caching efficiency.