## 2 Related Works
### ICN and ICN-Based Computing Network  
As a new network architecture, ICN aims to address scalability, flexibility, and security limitations in traditional TCP/IP network caused by IP semantic overload. Some of the currently successful implementations include DONA [39], CCN [40], NetInf [41], NDN [42], PURSUIT [43], Mobility First [44], SEANet [45], and others. Existing ICN architectures can be categorized into two types based on their implementation approaches: evolutionary and revolutionary. Evolutionary ICN architectures aim to incrementally improve the current network architecture, enhancing network functionalities by introducing ICN concepts and mechanisms within the existing IP network framework. This is typically achieved by adding new protocol layers, utilizing middleware, or extending existing TCP/IP protocols. As a result, they can be relatively easily deployed in current network environments, reducing the need for extensive infrastructure replacement [46; 47]. On the other hand, revolutionary ICN architectures advocate for a fundamental redesign of the network, with content-centric concepts as the foundation of network construction. This approach often requires the development of entirely new network protocols and infrastructures, which may include new routing algorithms, data naming schemes, caching mechanisms, etc. Therefore, the implementation of revolutionary ICN architectures tends to be more complex, challenging, and costly. The computing resource scheduling architecture proposed in this paper is based on the evolutionary ICN architecture, which facilitates its subsequent implementation in the real world at a lower cost. ICN adopts an information-centric communication approach, replacing the traditional host-centric model, and routes based on information or content names rather than host addresses. Different ICN architectures may employ various naming schemes for content, which are primarily categorized into hierarchical and flat naming schemes. For instance, NDN uses a human-readable hierarchical structure similar to the URL for naming content. PURSUIT employs a flat Rendezvous Identifier (RID) and a Scope identifier (SID) as a pair for content naming. Mobility First uses flat, globally unique identifiers (GUIDs) for this purpose. However, existing research demonstrates that flat naming schemes offer superior advantages in terms of security, scalability, and flexibility compared with hierarchical schemes [48]. Consequently, the ICN architecture described in this paper also utilizes flat identifiers (IDs) for content naming, akin to the aforementioned flat naming schemes, which facilitates routing within the ICN environment based on these IDs. Since ICN routes based on content names rather than host addresses, it necessitates a name resolution service that matches or translates content names to the locators of content providers. This enables content requests to route to the content provider's location based on content names or locators [49]. The name resolution process and the content request routing can be coupled (performing name resolution during the routing process). In this scenario, content requests route directly by content names, and content providers respond along the reverse path of the content request route. This approach is known as the Name-Based Routing (NBR) method, with NDN being a typical example. Alternatively, name resolution can be an independent process, separate from message routing. Content requests first obtain locators through an independent name resolution system, then route based on those locators. This method is referred to as the Standalone Name Resolution (SNR) method, with typical examples including DONA, PURSUIT, MobilityFirst, SEANet, and others. However, NBR methods are often found in revolutionary ICN architectures, requiring substantial modifications to the existing network infrastructure and presenting high deployment challenges.