Trailblazer: A proactive caching,blockchain,minimum content retrieval latency,and energy cost-aware resource and job orchestration scheme for publisher-subscriber based 6G ICN services

Abstract

With the rise of information-centric networks (ICN), the user can access the caching content from nearby caching nodes rather than the remote content server through in-network caching facilities. The existing articles did not look into minimum caching content retrieval latency, user energy consumption, user financial cost, and maximum service provider profit-aware proper resource orchestration and job scheduling policies all at once, taking into account multiple publishers and subscriber-based caching jobs, blockchain, user-owned and service provider cache, pre-caching, neighbor collaboration, and available resources. To suppress these challenges, this article offers a proactive pre-caching, collaboration, blockchain, minimum latency-aware resource, and job scheduling policy for 6G ICN services that takes into account publishers’ and subscribers’ caching job requests, user-owned and service provider cache, available resources, and deadline. The experimental results visualized that at least 16% content retrieval delay, 66% energy, and 22% service provider profit gain are attained in the proposed scheme over the existing techniques.

Keywords

Resource orchestration information-centric network (ICN)job scheduling mobile-edge computing publisher and subscriber blockchain collaboration mean content retrieval latency cache hit ratio user welfare service provider profit

1. Introduction

With the rise of new communication technology, devices, and techniques, global internet data traffic is expected to reach 150.7 exabytes (EB) per month in 2023, and video content will account for around 82 percent of total internet traffic in 2021 (Tariq et al. [80], Gitnux blog [30]). To ensure a better quality of service for this large amount of video content delivery over the internet, a new internet architecture (i.e., based on content name-based routing and in-network caching) is proposed by the academic and research community, which is referred to as information-centric networking (ICN) (Ahlgren et al. [2]). In the ICN, the users are more interested in the content itself than the content location or content access procedure.

One of the main features of the ICN is the in-network caching facility that can be deployed within the nearby router or caching server (Xylomenos et al. [97], Wu et al. [89]). In in-network caching, ICN users can access the caching content from nearby servers or routers. Thus, by reducing the communication overhead and improving the content distribution efficiency, in-network caching-based ICN can be referred to as a suitable candidate for the 6 G-based communication system (Liao et al. [49]).

The ICN network with in-network caching capability offers several benefits to ICN users, different content providers, or CPs, and internet service providers, or ISPs. First of all, by providing the caching content near the user location at the router or local cache, the in-network caching-based ICN reduces network traffic and ISP bandwidth usage for the users. Moreover, the in-network caching facility can reduce network congestion, improve robustness by providing caching content near the user’s location, and minimize the load on the remote content providers, or CP (Duan et al. [25]).

Different from the current IP-based internet, which is a host address-based internet, the ICN works on content-name-based routing. By using both name-based routing and in-network caching features, the ICN network can overcome the high network resource usage, heavy traffic load, and content response time issues of the current IP-based network. This is because by using the ICN, the user can access the caching content from a nearby router or cache (replica) rather than the source or the remote content server (Nguyen et al. [64]). However, one crucial issue with the promising in-network caching-based ICN is the energy consumption of networks. Due to the lack of a proper job scheduling scheme, unused network device energy consumption, and cache selection, ICN-based content caching may suffer from huge energy consumption by both user devices and network devices (Nguyen et al. [64]). The selection of proper communication links by examining wireless and wired links is another crucial issue for ICN-based caching policies. Moreover, the existing works did not develop any appropriate resource allocation scheme for both content publishers and subscribers by taking into account lower content retrieval delay, lower energy consumption, lower communication delay, user QoS requirement satisfaction, maximization of service provider revenue, minimization of user financial cost, and security issues (Fayyaz et al. [29]). It can be noted that one of the crucial issues for ICN users is the financial cost, and for service providers, it is the profit. At present, the existing works on ICN (Ravindran et al. [70], Xu et al. [96]) did not investigate a proper financial model or caching content buying and selling policy for not only the users (publishers and subscribers) but also for both the ISP and content providers (i.e., service providers). It can be noted that ISPs are responsible for content transmission, and CPs are responsible for content distribution to the nearby edge routers or cache.

Currently, several ICN-based architectures have been proposed by researchers, focusing on location-independent content or data access facilities. For example, domain-specific ICN networks for vehicles (Grewe et al. [31]), CCN or content-centric networking model based on grey relational analysis (Cui et al. [20]), NetInf or network of information architecture (Dannewitz et al. [21]), NDN or named data networking for vehicular ad-hoc networks (Khelifi et al. [45]), and probability-based caching-based ICN networks (Naeem et al. [60]). However, they did not investigate the content popularity based on the in-network caching strategy for ICN. Moreover, different types of cache for ICN, such as user-owned cache and service provider-owned cache, are out of their consideration. They did not investigate the energy and blockchain-aware caching job execution performance for publisher-subscriber-based ICN networks.

In the ICN, generally, three types of data structures are used. They are a content store, or CS; a pending interest table, or PIT table; and a forwarding information base, or FIB table. First, the users send the interest request to the nearest router based on the FIB table. If there is a match on the local cache content store for the content, then the content can be accessed and the interest packet is dropped. Then, the requested content or data can be sent to the users. Otherwise, the interest packet is forwarded to the potential content provider or server node via the intermediate node or routers based on their FIB table entry. If there is a match in the intermediate node (content node) that can satisfy the user interest request, the interest request is stored in the PIT table. Next, the content can be sent to the user based on the same path (user to content source) and forwarding interface (Jacobson et al. [40], Islam et al. [39], Thar et al. [81]). The intermediate router can keep the information about the forwarded interest packet in the PIT table. This information can be used to transfer the data to the users. If the intermediate router or node receives a data packet without any entry in the PIT table, the data packet can be dropped. To get satisfactory performance, different types of users, resources, and caching jobs need to be considered. For instance, in Islam et al. [39], the authors investigated the performance of CCN-based ICN by using the delay-tolerant network (DTN) environment. However, they did not consider both delay-sensitive and delay-tolerant caching requests for CCN-based ICN networks. The work in Asadi et al. [8] investigated the publish-subscriber-based ICN networks based on D2D communication using cellular networks. The work in Casetti et al. [15] presented the performance of D2D communication-based content caching using wifi direct architecture. However, they did not investigate the network architecture for 6G-based ICN services by taking different 6G application requirements, different communication technology, different computation technology, and different security requirements, among others.

Another crucial issue for ICN is the use of cloud technology for different publisher-subscriber applications. Every day, huge amounts of content are added to the internet through different platforms such as YouTube, Google, Facebook, and Flicker. Thus, to access content properly, different content delivery frameworks have been proposed by the researchers, such as peer-to-peer networks (Mastorakis et al. [54], Mastorakis et al. [55]), edge computing, and information-centric networking (ICN).

Earlier, all requests were forwarded to the core network. However, with the invention of edge computing, content requests can be addressed by the nearby cloud or content cache. To improve the communication latency associated with remote server-based content access, lower data rates, and higher congestion, Ullah et al. [84], Mtibaa et al. [59], and Mastorakis et al. [56] investigated the content delivery performance improvement by integrating both edge computing technology and ICN. However, they did not investigate several issues like pre-caching-based content delivery, user profit, and blockchain-aware resource assignment for publisher-subscriber-based ICN networks. The work in Cai et al. [14] investigated the performance of traditional full forwarding, random forwarding, and shortest path-based forwarding schemes with SDN (software-defined controller)-aware routing for CCN-based content delivery. In Zhang et al. [102], the authors examined the edge caching performance (e.g., content access delay, task offloading ratio) in the content-centric ICN network by using an auction-based caching policy in 5G networks. However, they did not investigate the service provider revenue and energy cost of users for both publisher-subscriber caching request-based ICN networks. The work in Hoang et al. [38] proposed a caching policy in which a matrix factorization scheme is used for user caching request prediction and caching content update in the content server.

Qin et al. [67] formulated a convex optimization problem for cache space allocation and management in service prioritization in ICN networks. The work in Fang et al. [28] described that the ICN network is different from traditional IP networks in several ways. For example, the ICN network-based naming, routing, caching, and security are based on an in-network content-centric policy, whereas the IP network is based on a host-centric policy for naming, routing, caching, and security issues. The existing works did not present a proper resource allocation scheme for ICN by taking computing, caching, and communication issues into account. In He et al. [37], they proposed a novel deep reinforcement learning-based resource allocation approach for ICN-based vehicular networks. In Naeem et al. [63], the authors discussed that the NDN-based ICN network can minimize the end-to-end caching content retrieval delay of IP networks by incorporating intermediate node-based caching (in-network caching) and name-based forwarding, routing, and security policy. In the IP network, when a user changes his or her location, the user needs to establish a new E2E connection for content access. Whereas, in the ICN network (i.e., NDN, CCN), the user can access the remaining content from the nearby cache or intermediate node (Ullah et al. [84], Arshad et al. [7], Amadeo et al. [3]). Amadeo et al. [3] and Hahm et al. [34] utilized edge networks for IoT data processing and caching in the ICN/NDN network. However, the aforementioned works did not present any resource allocation scheme and did not consider the multiple job execution requirements (e.g., minimum content retrieval latency, minimum energy consumption, minimum financial cost) of publisher-subscriber users in the ICN networks. To guarantee the QoS, the work in Liao et al. [49] formulated a Stackelberg game for optimal cache index selection in 6G-based VR/AR application execution. The work in Ben-Ammar et al. [11] proposed a Markov chain model to determine the cache hit ratio for the CCN/ICN-based content caching scheme. Ben-Ammar et al. [12] formulated a multi-objective cache placement problem and presented a meta-heuristic solution for the cache placement problem for the NFV-based ICN networks. However, all of these works mainly investigated service provider-owned cache selection for ICN-based content caching problems rather than both service provider and user-owned cache.

Zhou et al. [108] formulated a joint optimization problem for virtual resource allocation by taking into account both computation and in-network caching in the ICN-based network. To solve the formulated optimization problem, the authors also discussed a direction method for multipliers. To minimize the content request rejection rate, Tran et al. [82] devised a mixed-integer non-linear program, or MINLP-based optimization problem, for the virtualized resource allocation in the multiple BS-based wireless network.

However, they did not investigate a proper resource allocation scheme by taking into account the service execution requirements of both publisher users and subscriber users. Moreover, the usage of user-owned and service provider-owned caches is also out of their investigation. Meddeb et al. [57] discussed the performance of different caching policies and suitable caching policy selection for different IoT-based application execution. The authors of Djama et al. [22] presented a survey regarding different ICN architectures for IoT application execution, performance comparisons of different caching policies in the IoT domain, and different research challenges for iCN-based IoT application execution.

To ensure the powering of smart homes through the ICN networks, the work in Xu et al. [95] discussed the usage of intelligent/programmable home routers in the ICN architecture. Gui et al. [32] investigated a user preference-based content distribution in different regions (global and local regions) of the NDN/ICN network based on compound popularity (content and node popularity).

The authors also showed that their compound popularity-based content caching model offers a better cache hit ratio and link load performance than the existing leave copy down (LCD), leave copy everywhere (LCE), centrality caching (CL4M), and weighted probability-based caching (ProbCache) schemes. In Hao et al. [36], the authors presented a multi-arm bandit or MAB theory-based online cognitive caching scheme for a D2D network with edge cloud facilities that selects suitable content servers. The fine-grained caching indicators include both user (e.g., time, location, age, device, network connection) and content caching-aware indicators (e.g., content size and popularity). However, they did not investigate several main objectives, like minimizing the energy cost for users, maximizing the service provider’s profit, and minimizing the financial cost for users. Silva et al. [77] compared the performance of four cache replacement policies in the NDN/ICN network, such as the random caching policy, least recently used or LRU policy, LFU or least frequently used policy, and FIFO (first-in first-out) policy.

Wang et al. [87], Zheng et al. [106], and Jeong et al. [41] mentioned that with the rise of mixed reality applications (e.g., AR, VR), artificial intelligence, robotics, automation, and IoT-based applications, several emerging mobile applications (e.g., ubiquitous healthcare, personal assistants) may require higher computation speed, memory, and power cost requirements. Local mobile device-based computation and caching task execution cannot satisfy the time and energy requirements of many delay-sensitive applications. To solve this problem, collaborative remote cloud, edge cloud, or fog computing are some of the suitable solutions to meet the requirements (e.g., execution time, financial cost, energy cost) of many computation and caching applications (Fan et al. [27], Ren et al. [72]). However, the selection of proper computation and caching nodes by taking into account task execution requirements is a major challenge for the fog-cloud collaboration-based computation and caching task execution in the mobile edge caching and computing (MEC) framework. In Xing et al. [92], the authors mentioned that pushing the caching content near mobile users or end users is a common trend nowadays. However, most of the existing research works (Xing et al. [92], Wang et al. [88], Zhang et al. [100], Xing et al. [93], Riya et al. [73], Pfender et al. [66]) did not properly investigate the suitability of edge caching by taking into account different traffic load, different user requests, caching content distribution, content update, content replacement, and delivery policy, different task types, user ownership, and service provider ownership, different task execution criteria (e.g., time, energy, and financial cost minimization), network link availability, channel condition, caching resource availability, among others. The question of how to optimize the caching content access latency with proper route and cache selection is out of their jurisdiction. Further, most existing studies on edge caching-enabled ICN networks are limited to either mobile core networks, edge networks, or mobile devices rather than considering all.

At present, some research studies focus on different types of objectives for edge-cloud cooperation-based task offloading and service caching activities. For example, minimization of service execution delay in Chen et al. [16], minimization of energy consumption in Ji et al. [42], or minimum system cost in Tran et al. [83]. Most of the work assumed that the edge servers included all required caching services. However, this type of fixed cycle is not suitable for dynamic environments with heterogeneous user services and content requirements, among others (Liu et al. [53], Li et al. [48], Domingues et al. [23], Jmal et al. [43]). Thus, the selection of a suitable cache is still a critical research issue for both publishers and subscribers in ICN networks. Most of the works consider subscriber users. However, some users want to publish their content on the content server (i.e., publisher users). Thus, the question of how to select the proper cache and initiate a resource allocation strategy for both publisher and subscriber users is a major research challenge, taking into account different types of cache, different types of jobs, service priority, and user requirements, among others. Moreover, there is some literature on in-network caching and routing schemes for ICN-based content delivery. However, they mainly focused on resource utilization, efficiency improvement, and latency minimization. The crucial research issue of energy efficiency, along with other user service execution requirements for in-network caching over ICN, was out of their jurisdiction. To deal with the cache budget constraints and improve the network performance, the work in Zhou et al. [107] investigated an ant colony algorithm-based cache allocation scheme for heterogenous ICN. However, their work is only limited to the service provider cache rather than both user-owned and service provider-owned caches for ICN services.

From the prior literature review discussion, it is explicit that the prior works did not offer any proactive pre-content caching, blockchain, minimum content retrieval latency, or minimum energy cost-aware resource assignment scheme for publisher-subscriber-based 6G ICN services. Without a suitable resource assignment and job scheduling scheme, the 6G-based ICN services may suffer from huge content retrieval delays, energy costs for user devices, financial costs for users, less throughput, a low a low QoS guarantee ratio, and a low a low cache hit ratio. The crucial research question of how to schedule multiple caching-type jobs for both publishers and subscribers by taking into account different types of local cache and remote servers, different types of users, different network and caching resources, and different job execution or service requirements over 6G information-centric networks was out of their jurisdiction. The question of how to coordinate blockchain-aware services with caching services over 6G networks was out of the prior works investigations. The previous research works on information-centric networks did not offer any appropriate 6G network model for proactive caching, blockchain, minimum latency, energy cost-aware publisher, and subscriber job execution. Importantly, the prior literary works did not provide any performance analysis results for both publisher users caching jobs and subscriber users caching jobs execution by taking both user-owned cache and service provider cache services along with blockchain-based security enhancement services. Most importantly, the prior literary works did not offer any proper mathematical model for the performance analysis of multiple publisher-subscriber-based 6G ICN job executions by taking into account mean content retrieval latency, local cache hit ratio, server hit ratio, stretch ratio, service provider cost, throughput value, and job execution success ratio. However, the mean content retrieval delay calculation did not include different delay items such as initial network setup and registration delay, publisher-subscriber request collection delay, blockchain operation delay, communication delay, caching job work processing delay, cache search or lookup delay, waiting, and queuing delay. In addition, a detailed performance analysis model for users’ total energy cost calculation, users’ financial cost calculation, users’ total welfare, and service provider profit calculation were missing in the previous works.

To conquer the existing limitations, this paper gives a proactive pre-caching, blockchain, minimum content retrieval latency, and energy cost-aware resource assignment and job scheduling scheme for publisher-subscriber-based 6G ICN services by taking both user-owned cache and service provider-owned cache into account.

The foremost contributions of this work are discussed below:

This paper provides a minimum content retrieval latency, maximum service provider profit, and minimum users consumed energy-cost-based resource allocation policy for publisher-subscriber-based 6G ICN services by taking different caching job requests, job execution deadline, availability of cache resources and communication resources, blockchain operation, availability of users-owned cache and service provider cache resources, both edge and remote server caching, caching job data sizes, and different financial and energy costs for services into account.

This paper delivers a multiple caching job scheduling scheme and a proper worker (caching node and communication node resource) selection scheme by taking heterogenous publisher-subscriber-based caching job requests, available local and non-local cache resources, service requirements, minimum content retrieval latency, energy cost, and financial cost into account.

This paper presents an adaptive network model for 6G ICN services that includes MEC services, blockchain services, remote cloud and caching services, service provider and user-owned cache, core and access networks, 6G wired and wireless communication link services, and different user devices such as robots, vehicles, AR or VR user devices, content publisher users, and content subscription users. This paper also provides an overall job execution sequence diagram that briefly discusses the operation associated with both publisher-subscriber-based caching job execution by taking into account three phases: network setup or primary phase, cache search and job scheduling phase, caching job execution, and content access/publish-based job finalization phase.

To assess the performance of the proposed trailblazer scheme, this paper issues a brief mathematical model that includes performance metrics like mean content retrieval latency, local cache hit ratio, server hit ratio, stretch ratio, users’ total consumed energy, users’ financial cost for caching services, service provider cost and profit, job execution requirement satisfaction or success ratio, throughput ratio, user survivability ratio, and user total welfare ratio. Especially different from existing work, in this paper, the mean content retrieval delay calculation process includes different delay items such as initial network setup and registration delay, publisher-subscriber request collection delay, blockchain operation delay, computation or workload processing delay, communication delay, caching job work processing delay, cache search or lookup delay, and waiting and queuing delay. This paper also compares the performance of our work with existing schemes.

Section 2 yields the previous literature review. The proposed trailblazer scheme for 6G ICN services is detailed in Section 3, along with the proposed network diagram, algorithm discussion, and working procedure. Section 4 issues the mathematical model for the proposed trailblazer scheme. The performance analysis results of the proposed scheme, along with comparison results, are depicted in Section 5. Section 6 holds a summary of the proposed trailblazer scheme and some future research challenges.

2. Related works

This section will provide a detailed description of the existing related works on information-centric networks. To maximize revenue, the work in Duan et al. [25] developed a collaborative pricing framework for both content providers and internet service providers (ISPs). To maximize the hit ratio and minimize the cost, Araldo et al. [6] presented a greedy algorithm that offers optimal content placement and path selection features for ICN. The work in Hajimirsadeghi et al. [35] discussed a joint optimization problem for popular content caching and pricing in the ICN networks. However, all of these aforementioned schemes either investigated the suitable pricing policy for content providers (CPs) or ISPs. Hence, the research question of how to maximize the profit for both users and service providers by taking into account both content publishers and subscribers was out of their investigations. In Naeem et al. [62], the authors presented a comparative analysis of different popular content-based caching policies for NDN networks. The work in Nguyen et al. [64] investigated the adaptive link rate and priority-based content caching scheme for ICN users. To cope with network failure issues and improve power-saving issues, the authors considered a WiFi-direct-based D2D communication system for ICN users. In Fayyaz et al. [29], the authors presented a detailed survey regarding the research issues concerning ICN connectivity, routing, communication overhead, caching policy, architectural design, and deployment strategies, among others. Islam et al. [39] presented a content-centric delay-tolerant network (DTN) architecture that integrates the DTN into the native CCN networks. The work in Ullah et al. [84] presented an ICN-based edge computing network architecture with D2D communication for ICN application execution over a 5G radio access network (RAN). They also presented a dynamic content access strategy based on content popularity and hierarchical naming in the ICN. The work in Rehman et al. [71] investigated a location-aware and on-demand caching and forwarding policy for the NDN-based MANETs. To reduce the latency of different popular content access methods, in Khan et al. [44], the authors presented a priority-aware content dissemination policy for content-centric vehicular network applications. In this work, the safety message can get a higher priority than the non-safety message.

The work in Zhang et al. [102] detailed a 5G edge caching network that includes a cache-enabled mobile network, a CCN-based function and protocol implementation, and a content retrieval process. In Zhang et al. [101], the authors presented a space-efficient caching policy for content-centric mobile ad hoc networks that investigates the tradeoff between the cache hit ratio and cache space occupancy. To offer seamless connectivity and optimal content distribution, Xu et al. [94] formulated an optimal content replication problem for ICN-based 5G D2D communications. The work in Qin et al. [67] developed a priority-based cache space allocation scheme for core nodes for the heterogenous content providers in the ICN. To tackle the issues with time-sensitive content publication and distribution, the work in Xia et al. [90] proposed a secure content access control scheme for ICN-based users by taking into account both time-sensitivity issues and the lightweight encryption-decryption process. The work in Naeem et al. [63] presented a comparative analysis of different caching policies regarding ICN/NDN-based IoT application execution. To minimize the energy in the NDN networks, the work in Moeng et al. [58] developed a sleep-based caching policy that caches the most frequently used contents in the intermediate routers or nodes. To maximize the availability of caching contents to the users, the work in Naeem et al. [61] presented a periodic caching policy for the ICN-based IoT applications. The work in Naeem et al. [60] provided a comparative analysis of different probabilistic caching policies in content-centric networking. The work in Quan et al. [68] presented a V2C (vehicle to cloud communication)-based video content delivery approach for multimedia content streaming in ICN networks. In Chen et al. [17], the authors presented an energy-aware interest request forwarding mechanism for multimedia content streaming in 5G ICN networks with D2D communication capability. The work in Zhang et al. [103] formulated an optimization problem that minimizes the caching content download delay over ICN-based wireless networks. To reduce the number of broadcasted interest packets, the work in Zhang et al. [104] integer linear programming-based caching decision problem. To reduce the network latency and maximize the caching content access capability, the work in Zhang et al. [104] integrates the SDN technology with ICN for proper decision-making. The work in Chowdhury et al. [18] develops a resource orchestration scheme for 6G decentralized organization based applications. However, the aforementioned literary works (Zhang et al. [103], Chen et al. [17], Quan et al. [68], Naeem et al. [60], Zhang et al. [104]) did not consider both cache location, user-owned cache, proper scheduling scheme, proper pricing policy, and multiple users caching requirement satisfaction at the same time. The work in Shojafar et al. [76] focused on the maximum energy-saving based remote cloud server selection for multimedia content processing. However, due to remote cloud server selection, their scheme can suffer from higher communication latency. The work in Xiao et al. [91] presented a security enhancement policy for mobile edge caching by using the reinforcement learning technique. The work in Ben-Ammar et al. [13] proposed a three-queue (main cache, auxiliary cache, virtual cache)-based service caching policy in edge/fog-based ICN networks. Zhou et al. [108] formulated a joint optimization problem (with both caching and computing operation) formulation-based resource allocation policy in virtualized heterogeneous networks (HetNets) that integrates both ICN and MEC. To minimize the content request rejection rate, Tran et al. [82] formulated a joint resource allocation and content caching problem and proposed a bisection search algorithm for optimal solutions in CCN-based (content-centric) virtualized wireless networks. To improve the quality of experience, the work in Gupta et al. [33] presented a collaborative filtering-based edge content caching policy for enhanced ICN-IoT applications. The authors also compared the proposed scheme results with traditional caching policies such as cache everything everywhere (CEE), leave copy down (LCD), and probability-based (prob-cache) caching policies in terms of cache hit ratio, hop count reduction, and content retrieval latency. The work in Liu et al. [51] presented a video stream distribution scheme for ICN users in which video stream request scheduling is done by the centralized SDN controller and distribution of the video stream content is conducted by the edge-caching node, or EC node. The work in Serhane et al. [74] presented a detailed review of the recent ICN content naming schemes and recent in-network content caching solutions for ICN users. The authors also described the usefulness of ICN for 5G networks and associated applications. In Gui et al. [32], the authors showed that different on-path caching policies can offer a better cache hit ratio than off-path caching policies. The article also discussed the pros and cons of different on-path caching policies in NDN, such as Leave Copy Everywhere (LCE), Leave Copy Down (LCD), and Probability-Based Caching (ProbCache). The authors also explained the merits and demerits of some off-path caching policies, such as hash routing [78], scalable caching [85], and hierarchical caching [105]. Amadeo et al. [4] presented a popularity-aware closeness (PaC)-based caching for NDN. By using the popularity-aware closeness (PaC) metric, the authors measure the popularity of specific content for storing in an edge node. Fan et al. [27] formulated an energy optimization problem as a mixed integer nonlinear programming (MINLP) problem that jointly optimizes the selection of proper computing mode, edge computing node frequency, and local edge computing ratio by satisfying constraints such as computation power threshold or time threshold.

Hao et al. [36] presented a cognitive caching scheme for wireless mobile caching in a D2D network by learning fine-grained caching indicator metrics. Yang et al. [98] focused on improving the cache hit ratio in mobile caching networks by using location-aware caching and content popularity prediction values. To improve mobile users caching performance, the work in Liu et al. [50] focused on the network cost value. However, for optimal cache selection, both the economic cost and the energy issue need to be considered, taking into account the storage cost for content providers and the transmission cost for network service providers (Krolikowski et al. [46]). The work in Asmat et al. [9] developed an energy-efficient caching scheme for IoT environments. The work in Xing et al. [92] formulated an integer linear program (ILP) for the request screening problem and a linear program (LP) for the request routing problem. The work in Chowdhury et al. [19] developed a heuristic based resource slicing scheme for virtualized network. The work in Sun et al. [79] utilized a heuristic greedy algorithm for content caching in multi-cell wireless networks. To minimize the latency of fog computing-based users, in Riya et al. [73] the authors presented an efficient caching policy that considers D2D caching, clustering, and association rules. The work in Liu et al. [53] formulated a joint optimization problem and presented a two-level computation strategy for task offloading and service caching in the MEC system. Thar et al. [81] formulated the cache decision problem as a ski-rental problem and presented a random online caching/replacement scheme for content-centric networks. In Liu et al. [52], the authors presented a deep learning-based cache content popularity prediction scheme for caching in ICN.

The aforementioned existing research articles did not offer any suitable resource orchestration and job scheduling schemes for both publisher- and subscriber-based caching job execution. They also did not propose any suitable caching job execution scheme by taking proactive pre-caching facilities, both user-owned and service provider-owned caches, blockchain operation, minimum content retrieval latency, user consumption energy cost, financial cost, maximum service provider profit, and maximum user welfare-based caching node and communication resource allocation. To minimize content retrieval latency, user energy consumption, and financial costs, along with maximum user welfare and service provider profit, this paper delivers a proactive caching, user- and service provider-owned cache, blockchain operation-based resource orchestration, and job scheduling scheme for both publisher and subscriber-based 6G ICN services.

Fig. 1.

Proposed network model for 6G based ICN job execution.

3. Proposed trailblazer scheme for content caching over ICN-based network

3.1. Overview of the proposed network and some considerations

Figure 1 provides a systematic diagram of the proposed network for publisher-subscriber-based content caching over ICN networks. Different from existing networks, our network models include both user-owned and service provider-owned cache servers. Moreover, this network model includes different types of user devices for different publisher- and subscriber-based ICN job executions, such as mobile phones, computers, AR/VR devices, vehicles, and robot devices. By using these new enhancements, the proposed network model can be helpful to minimize the content retrieval delay, energy cost of users, and financial cost of caching job execution. Note that existing works did not provide any suitable network model with necessary user devices and network devices for the execution of different publisher and subscriber ICN jobs. They also did not divide the full network into different subparts, such as access networks, core networks, transit networks, edge networks, and remote cloud networks.

Our proposed network includes mainly four parts. The first part is access to ICN networks. The second part is the transit ICN network. The third important part is the MEC-based edge content caching system. The fourth part is the remote server for content caching and cloud services. In the access part of the ICN network, the publisher-subscriber user devices (e.g., mobile phones, computers, AR/VR devices, vehicles, and robot devices) are connected to the internet and access the internet facilities via the cellular base station. The cellular base station is connected to the core network via the edge router. The user devices can connect to the internet via both the cellular base station and the WiFi BS device. The cellular BS can connect with the original content server via the edge router and core router. The core routers are connected via the dedicated fiber link and form the transit ICN network. The original content server and remote cloud server (owned by the service provider) are connected to the core router via the dedicated fiber link. The original content server and remote cloud server are generally 4–5 hops away from the job and resource assignment manager at the cellular BS device.

For cellular link-based wireless connectivity, different types of links are available, such as the terahertz link that operates based on the IEEE 802.15.3.d standard (the bandwidth value is.6 THz and the range for the terahertz link is within 1–10 m), the microwave link that operates based on the IEEE 802.11b standard (the bandwidth is 6.8 GHz and the range for the microwave link is within 1–250 m), and the millimeter or mmWave link that operates based on the IEEE 802.11 ad standard with a bandwidth value of 1.1 GHz and communication link range is within 1–70 m. For the WiFi BS-based link, the data transfer is based on the IEEE 802.11b standard, and the radio frequency is within 5–6 GHz. The user devices under a cellular BS device (job scheduler) formed a cluster. The cellular BS devices can connect via a dedicated fiber link. In this work, multiple clusters can form a cooperative caching network, in which one cluster can share the caching content with another cluster during their assigned timeslot. The MEC device with both caching and computing facilities is connected to the cellular BS via a fiber link. In this work, the fiber connectivity-based data transfer is based on the IEEE 802.3 CD standard. Under each MEC device, there is a service provider-owned local cache, a user-owned local cache, an edge cloud server, and an edge blockchain device. In this work, the users can get caching facilities from both services that provide owned cache (SP-owned cache) and user-owned cache devices. The remote caching and cloud servers are owned by the service provider. In this work, the well-known Zips law is used for caching content distribution (Gui et al. [32]), in which the probability of ith (popular) content being utilized or accessed is $p (i) = \frac{j}{i^{α}}$ . Where $j = \sum_{s = 1}^{N} {\frac{1}{s^{α}}}^{- 1}$ . N is the total caching content category number, and the popularity variation factor is α. The cache replacement velocity is the least recently used LRU policy (Silva et al. [77]). The caching job interest generation by the users is based on the IRM, or independent caching request model. In this work, we have assumed that the local cache storage capability is at least 100 GB. The highest CPU processing speed for each MEC server, remote cloud server, or blockchain device is 3.9 GHz. The maximum CPU speed for the publisher/subscriber user device is 1000 MHz. In this work, the proactive pre-caching idea is used, in which the remote server can send the caching data (for the next users) to the edge cache devices during other users caching timeslot duration. The job schedular device (at the cellular BS) is responsible for proper local cache device or remote server device selection for each publisher-subscriber caching request by checking the content store (CS), pending interest table (PiI), and forward information base table (FIB). The best cache or server for each caching request is selected by the job schedule based on lower predicted content retrieval delay, maximum service provider profit, minimum user financial cost, and maximum user welfare value. After the selection of a suitable cache or server, the job scheduler schedules the timeslot and sends the timeslot information to the users for caching job execution. During the subscriber user timeslot, the users can access the caching content from the selected local cache or server. Whereas, during the publisher user timeslot, the respective user can transfer the caching content to the selected cache or server for storage. In this work, we assumed that the cache replacement of a cluster node is done during the timeslot of other cluster nodes. For content distribution, the Zipf law-based content popularity model is used. For cache replacement, we have used the least recently used or LRU-based cache replacement policy.

Fig. 2.

Proposed ICN based caching job execution work sequence model.

3.2. Trailblazer-based resource and job assignment scheme for publisher-subscriber based ICN networks

This section provides detail regarding the proposed resource and job assignment scheme (trailblazer) for publisher-subscriber-based ICN networks. Algorithm 1 gives the proposed trailblazer resource and job scheduling scheme for both publisher and subscriber job execution. Figure 2 gives the caching job execution work sequence model. It can be noted from Fig. 2 that the proposed trailblazer scheme consists of three sub-parts. They are the network primary formation phase (first phase), cache search and timeslot schedule phase (second phase), and caching job finalization phase (third phase) for both publisher and subscriber users. In the network primary formation phase, different activities are performed by both users and job schedulers, such as the exchange of initial beacon messages (during the NSB slot) by the job scheduler, network connectivity and service registration requests and verification work (CR and CE slots) by both user devices and the job scheduler, and the user device’s initial blockchain operation (during the IBO slot) completion (e.g., key exchange, key verification, and smart contract process setup) with the help of blockchain devices at the edge network. In the cache search and job schedule phase (second phase), different operations are performed, such as job scheduler-based primary slot assignment for users job request transfer (PAT slot), caching job request transfer by users (PRT slot), examination of local and remote cache node status by checking content search or CS, pending interest table or PIB, and forward information base or FIB table (during CFB slot), selection of suitable cache and other resources for job execution by the scheduler (during US slot), and announcement of timeslot and resources for caching jobs by the scheduler (during AT slot). In the last job finalization phase, different subscriber and publisher jobs are executed by using the assigned cache server, timeslot, and resources.

The job scheduling device at the cellular BS coordinates the resource and caching job assignment phases. During the primary network formation phase, first, the job-schedule device (at the cellular base station) dispatches the network setup or primary beacon (NSB) message to the surrounding user devices. Next, the publisher-subscriber users dispatch the network connectivity and caching service registration request (CR) message to the job-schedule device. The job scheduling device at the network edge sends the connectivity and service registration response message (CE) to the ICN network users. Next, the initial blockchain operation is conducted between the edge blockchain device and the user device (i.e., key exchange, user verification, blockchain service registration, and smart contract process setup) during the IBO duration of the time cycle. Next, the second phase will be started, which is cache search, selection, and job scheduling. In this phase, first, the job scheduler assigns a primary sub-slot to the ICN users by using the PAT message (publication of job request transfer slot schedule message). Next, the ICN users (both publisher and subscriber devices) transfer their job request message to the job scheduler devices by using the PRT message (caching job request interest message for both publisher and subscriber). After that, the job scheduler selects the appropriate local cache or server with the highest cache hit ratio during the CFB timeslot (for each caching request) by checking the CS (content store), PIT (pending information table), and forward information base (FIB) tables. For each caching request, the job scheduler then selects the best cache or server by taking into account the minimum predicted caching content retrieval delay ( $ϑ_{c r l}^{i}$ ), the minimum user energy required ( $Y_{t e c}^{i}$ ) for the services, and the highest user welfare ( $γ_{t u w v}^{i}$ ) for each caching content delivery. Next, the job scheduler device applies the earliest job execution deadline based on job, resource, and timeslot scheduling for multiple caching requests during the user slot arranging duration (US). After that, the job scheduler dispatches the job and resource scheduling information to the users by using an announcement message (AT). In this work, the job scheduler calculates the predicted caching content retrieval delay, user-required energy, and user welfare (based on job-to-resource mapping according to its scheduling technique) earlier based on the available resource information from the caching nodes. Then, by checking all resource information and precalculated delay/energy/welfare values, the job scheduler selects the best resource with the minimum predicted caching content retrieval delay ( $ϑ_{c r l}^{i}$ ), the minimum user required energy ( $Y_{t e c}^{i}$ ), and the highest user welfare ( $γ_{t u w v}^{i}$ ) for each caching job by adopting our proposed job scheduling policy.

In the proposed scheme, the proactive precaching technique is applied for content delivery. In this proactive precaching technique, the caching content from the remote server (for the next caching users) can be dispatched to the local cache for storage during the caching timeslot (cache lookup, readiness, and download operation) of previous users. By using proactive precaching, the content delivery delay can be reduced for the remaining caching users. The term “proactive” is used because suitable cache server selection with precaching facilities is performed by the job scheduler before the caching job execution phase. The term “precaching” means the caching contents are dispatched from the remote server to the local edge server before the user assigns a job execution timeslot.

In this work, the caching content subscriber-based job (i.e., caching content access from the selected local cache or server by the user) can be executed before the publisher-based caching job execution (i.e., upload caching content from the user to the selected local cache or server). The user caching job with the lowest deadline will be processed before the user caching job with the highest deadline.

During the subscriber-based caching job execution timeslot duration, first, the user’s caching job request is transferred to the job scheduler. Next, the job scheduler performs the suitable cache/server selection for the requested job. Next, the job scheduler dispatches the selected cache or server selection result with caching job execution instructions to the user device and the selected cache or server device. After that, the user device dispatches the content access permission request to the selected cache or server. Next, the selected cache or server performs a cache lookup and caching data finalization procedure for users’ content downloads. Before the caching content is downloaded, the blockchain device (primary) at the selected cache or server performs a block creation operation with hashing. Next, the block is transferred to the blockchain verifier device for verification. After content and user verification, the primary blockchain device dispatches the content access permission grant message to the user devices. The subscriber user next performs the caching content download operation from the selected cache or server. After the completion of content download, the primary blockchain device performs the add-to-ledger operation on the blockchain, which includes a cache ledger update and a monetary ledger update operation for billing.

During the caching content publisher user timeslot, initially, the caching job request is dispatched to the job schedular device from the user device. Next, the job scheduler checks the appropriate cache or server for the publishing job. After that, the job scheduler sends the caching job execution instructions to the selected local cache or server and the user device. Next, the publisher user device sends the caching content upload request to the selected cache or server. The caching content transfer grant message is sent to the user device after user verification by the blockchain devices (primary blockchain devices near the edge). After that, the user device dispatches the content or uploads the content to the selected cache or server. Next, the selected cache or server performs a cache storage lookup and caching data storage finalization procedure. Before caching content storage, the blockchain device (primary) at the selected cache or server performs a block creation operation on the uploaded content with the hashing operation. Next, the block is transferred to the blockchain verifier device for verification. After the block verification, the primary blockchain device performs the monetary and blockchain ledger update operations. The selected cache or server completes the uploaded caching data storage operation. Finally, the caching data storage operation confirmation is sent to the publisher’s user devices by the selected caching node or server.

4. Mathematical model

This section of this paper provides the mathematical model regarding the proposed scheme. The performance metrics included in this section are mean content retrieval delay, local cache hit ratio, server hit ratio, stretch ratio, users’ total consumed energy, users’ financial cost, service provider cost and profit, job execution success ratio, throughput value, users survivability ratio, and users total welfare value.

4.1. Mean content retrieval delay

First, this section will start with the mean content retrieval delay value calculation model. The content retrieval delay ( $ϑ_{c r l}^{i}$ ) measurement consists of not only the ICN network primary phase delay with setup, registration, and primary blockchain operation delay ( $Π_{p s s}^{i}$ ), publish-subscriber request collection, cache search, resource assignment phase delay ( $Π_{c s s}^{i}$ ), and publish-subscriber caching job processing finalization delay ( $Π_{c j f}^{i} = Π_{c j f, p u}^{i} + Π_{c j f, s u}^{i}$ ). $Π_{c j f, p u}^{i}$ is the publisher based caching job processing finalization delay. $Π_{c j f, s u}^{i}$ is the subscriber based caching job processing finalization delay. The mean content retrieval latency ( $ϑ_{a c r l}^{i}$ ) is determined by taking the ratio of total content retrieval delay ( $ϑ_{c r l}^{i}$ ) and total number of publisher-subscriber caching jobs (R). $ϑ_{a c r l}^{i}$ is given by:

\begin{aligned} ϑ_{a c r l}^{i} & = \frac{\sum_{i = 1}^{R} ϑ_{c r l}^{i}}{R} \\ = \frac{\sum_{i = 1}^{R} Π_{p s s}^{i} + Π_{c s s}^{i} + Π_{c j f, p u}^{i} + Π_{c j f, s u}^{i}}{R} \end{aligned}

(1)

First, this article will present the network primary phase delay $Π_{p s s}^{i}$ calculation model. $Π_{p s s}^{i}$ is given by:

\begin{aligned} Π_{p s s}^{i} & = \frac{Φ_{n s b}^{i} + Φ_{c r}^{i} + Φ_{c e}^{i} + Φ_{i b o}^{i}}{χ_{w r}} * Υ_{w r} \\ + \frac{Φ_{n s b}^{i} + Φ_{c r}^{i} + Φ_{c e}^{i} + Φ_{i b o}^{i}}{χ_{o p}} * Υ_{o p} \\ + \frac{Ω_{i b o}^{i} + Ω_{c e}^{i}}{δ_{s n}} + \frac{Ω_{i b o}^{i} + Ω_{c r}^{i}}{δ_{u s}} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(2)

Where $Φ_{n s b}^{i}$ , $Φ_{c r}^{i}$ , $Φ_{c e}^{i}$ , and $Φ_{i b o}^{i}$ , are the network initial beacon message size (from schedular to user device), message size for network connectivity and service registration request (from user to schedular), message size for network connectivity and service registration response (from schedular to users), message size for initial blockchain setup request and response (between the user and schedular for key exchange, user verification, and smart contract setup operation), respectively. $δ_{s n}$ , $δ_{u s}$ , and $δ_{c n}$ are the CPU speeds for the schedular node, user device, and caching node, respectively.

$χ_{w r}$ , $χ_{o p}$ , $Υ_{w r}$ , and $Υ_{o p}$ are the data transfer rate for the selected wireless link, the data transfer rate for the selected optical fiber link, the hop distance for wireless link-based data transfer, and the hop distance for optical link-based data transfer, respectively. $Π_{p p}^{i}$ and $Π_{q w}^{i}$ are the propagation and queue-based waiting delays for the caching job duration, respectively.

$Ω_{i b o}^{i}$ , and $Ω_{c e}^{i}$ are the job workload amounts for the initial blockchain set up at the job schedular device or edge blockchain node and network connectivity with service registration response processing work, respectively (at the job schedular node).

$Ω_{i b o}^{i}$ and $Ω_{c r}^{i}$ are the job workload amounts for the initial blockchain setup at the user node, network connectivity, and service registration request processing work at the user node, and primary caching job request message generation work at the user device, respectively.

Next, we will discuss the publisher-subscriber caching job request collection, cache search, and resource assignment phase delay ( $Π_{c s s}^{i}$ ) calculation model. $Π_{c s s}^{i}$ is measured by:

\begin{aligned} Π_{c s s}^{i} & = \frac{Φ_{p a t}^{i} + Φ_{i r}^{i} + Φ_{c f b r}^{i} + Φ_{a t}^{i}}{χ_{w r}} * Υ_{w r} \\ + \frac{Φ_{p a t}^{i} + Φ_{i r}^{i} + Φ_{c f b r}^{i} + Φ_{a t}^{i}}{χ_{o p}} * Υ_{o p} \\ + \frac{Ω_{c f b s}^{i} + Ω_{c s}^{i}}{δ_{c n}} + \frac{Ω_{u s}^{i} + Ω_{a t}^{i} + Ω_{p a t}^{i}}{δ_{s n}} + \frac{Ω_{i r}^{i}}{δ_{u s}} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(3)

$Φ_{p a t}^{i}$ , $Φ_{i r}^{i}$ , $Φ_{c f b r}^{i}$ , and $Φ_{a t}^{i}$ are the message size concerning message size for primary slot assign schedule (schedular to user), message size for users caching job request (user to schedular), cache or server node response message to schedular node regarding caching content availability by checking CS, PIT, and FIB table, job timeslot and resource assignment, and scheduling message size (generated by the schedular to the user). $Ω_{i r}^{i}$ and $Ω_{p a t}^{i}$ are the job workloads for the user device regarding caching job request generation and primary job request control slot scheduling workloads at the job schedular node, respectively.

$Ω_{c f b s}^{i}$ , $Ω_{c s}^{i}$ , $Ω_{u s}^{i}$ , and $Ω_{a t}^{i}$ are the workloads for CS, PIT, and FIB table search response generation (by the caching node), computation workload for CS, PIT, and FIB table search (by the caching node or server), workload for suitable cache or server selection (by the job schedular node), workload for resource node, and timeslot assignment message generation (by the job schedular node), respectively. $δ_{c n}$ is the computation work processing ability for the caching node. Next, this paper will discuss the subscriber-based caching job processing finalization delay ( $Π_{c j f, s u}^{i}$ ). $Π_{c j f, s u}^{i}$ is analyzed by:

\begin{aligned} Π_{c j f, s u}^{i} & = \sum_{i = 1}^{R} (Π_{c r t}^{i} + Π_{s i d}^{i} + Π_{c p f}^{i} + Π_{c a p r}^{i} + Π_{c l c r}^{i} \\ + Π_{b c r}^{i} + Π_{b t d}^{i} + Π_{b v d}^{i} + Π_{b v r t}^{i} + Π_{a t l}^{i} + Π_{c a p g}^{i} + Π_{c c d}^{i} \\ + Π_{p p}^{i} + Π_{q w}^{i}) \end{aligned}

(4)

R is the total requested caching job or interest request number. $Π_{c r t}^{i}$ is the subscriber-based caching job request dispatch delay to the job schedular at the cellular BS device.

\begin{aligned} Π_{c r t}^{i} = \frac{Φ_{i r}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{i r}^{s u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(5)

Where $Φ_{i r}^{s u}$ , $χ_{w r}$ , $χ_{o p}$ , $Υ_{w r}$ , and $Υ_{o p}$ are caching job request message size for subscriber users, data transfer rate for wireless link, data transfer rate for optical fiber link, hop distance for wireless link based data transfer, and hop distance for optical link based data transfer, respectively. $Π_{p p}^{i}$ and $Π_{q w}^{i}$ are the propagation and queue-based waiting delays for the caching job duration, respectively. The propagation delay is measured by taking the ratio of the distance (between the source and destination) and the propagation speed of the medium. The queuing delay is measured by taking into account the well-known queuing model M/D/1 (Amreen et al. [5]).

$Π_{c p f}^{i}$ is the job schedular delay for checking the content search table, pending interest table, and forward information base table for local cache or server selection and caching job instruction generated delay for the requested caching job.

\begin{aligned} Π_{c p f}^{i} = \frac{Ω_{c p f}^{s u}}{δ_{s n}} \end{aligned}

(6)

Where, $Ω_{c p f}^{s u}$ is the workload associated with checking the content search table, pending interest table, and forwarding information base table for local cache or server selection. $δ_{s n}$ is the computation or processing power (CPU) for the job-scheduling device at the network edge.

$Π_{s i d}^{i}$ is caching job instruction dispatch delay from the job schedular to the user device and selected caching job processing work node.

\begin{aligned} Π_{s i d}^{i} = \frac{Φ_{j i g}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{j i g}^{s u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(7)

Where

Φ_{j i g}^{s u}

is the message size regarding the caching job instruction for both users and the selected caching job processing work node (for the subscriber job).

$Π_{c a p r}^{i}$ is the content access permission request transfer delay from the user to the selected caching job processing node (e.g., a local cache or centralized server).

\begin{aligned} Π_{c a p r}^{i} = \frac{Φ_{c a p r}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{c a p r}^{s u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} . \end{aligned}

Where $Φ_{c a p r}^{s u}$ is the message size regarding the caching content access permission from the user’s device to the selected caching node or server.

$Π_{c l c r}^{i}$ is the cache file look-up and readiness delay associated with the selected local cache or server.

\begin{aligned} Π_{c l c r}^{i} = Ψ_{c l} + m * (Ψ_{l c}^{c d} + Ψ_{c s}^{c d}) \end{aligned}

(8)

$Π_{c l c r}^{i}$ is calculated by using the formula mentioned in the reference Drolia et al. [24]. m is the selected cache miss ratio (m = 0 to 1). h is the cache hit ratio (m = 1-h). $Ψ_{c l}$ is the cache file look up delay ( $Ψ_{c l} = a 1 + a 2 * Φ_{c d s}$ ). $a 1$ and $a 2$ are constantly associated with content search and file readiness for access, respectively. $Φ_{c d s}$ is the requested content size for caching.

$Π_{b c r}^{i}$ is the generation of block and hashing process completion delay by the selected edge blockchain node after the cache search operation.

\begin{aligned} Π_{b c r}^{i} = \frac{Ω_{b c r}^{s u}}{δ_{b c n}} \end{aligned}

(9)

Where $Ω_{b c r}^{s u}$ is the workload associated with block creation and hashing operations on the edge server or blockchain node. $δ_{b c n}$ is the CPU speed for the blockchain nodes during the block creation and hashing process.

$Π_{b t d}^{i}$ is the block data transfer delay from the block data creation node to the block data verifier node.

\begin{aligned} Π_{b t d}^{i} = \frac{Φ_{b t d}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{b t d}^{s u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(10)

$Φ_{b t d}^{s u}$ is the message size regarding the block data dispatch from the block creator node to the block data verifier node.

$Π_{b v d}^{i}$ is the block data verification delay at the verifier node.

\begin{aligned} Π_{b v d}^{i} = \frac{Ω_{b v d}^{s u}}{δ_{b v}} \end{aligned}

(11)

Where

Ω_{b v d}^{s u}

is the workload associated with block verification operations at the blockchain verifier node.

δ_{b v}

is the CPU speed for the blockchain verifier node.

$Π_{b v r t}^{i}$ is the block data verification response transfer delay from the verifier node to the original block data creator node.

\begin{aligned} Π_{b v r t}^{i} = \frac{Φ_{b v r t}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{b v r t}^{s u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(12)

$Φ_{b v r t}^{s u}$ is the message size regarding the verified block data dispatch from the block data verifier node to the original blockchain-based caching node (i.e., block creator).

$Π_{c a p g}^{i}$ is the content access grant message transfer delay by the caching node to the user device (subscriber) after content request verification, key matching, and blockchain operation.

\begin{aligned} Π_{c a p g}^{i} = \frac{Φ_{c a p g}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{c a p g}^{s u}}{χ_{o p}} * Υ_{o p} + \frac{Ω_{u v}^{s u}}{δ_{c a n}} \end{aligned}

(13)

Where

Φ_{c a p g}^{s u}

is the message size regarding the caching content access permission granted from the selected blockchain-based caching node or server to the user device after user verification.

Ω_{u v}^{s u}

is the workload for user verification operations.

δ_{c a n}

is the CPU speed for the blockchain-based caching node for verification.

$Π_{c c d}^{i}$ is the subscriber user device-based caching content download delay from the selected caching node.

\begin{aligned} Π_{c c d}^{i} = \frac{Φ_{c d s}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{c d s}^{s u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(14)

$Φ_{c d s}^{s u}$ is the downloaded content size by the user.

$Π_{a t l}^{i}$ is the monetary and blockchain ledger update delay by the primary blockchain-based caching node after block verification and user-based data download operations.

\begin{aligned} Π_{a t l}^{i} = \frac{Φ_{a t l}^{s u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{a t l}^{s u}}{χ_{o p}} * Υ_{o p} + \frac{Ω_{a t l}^{s u}}{δ_{b c n}} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(15)

$Φ_{a t l}^{s u}$ is the message size regarding the ledger update operation (for subscriber user jobs). $Ω_{a t l}^{s u}$ is the workload associated with ledger update operations (for subscriber user jobs) by the primary blockchain device at the edge server.

Next, the publisher user-based caching data storage job processing finalization delay ( $Π_{c j f, p u}^{i}$ ) will be calculated. $Π_{c j f, p u}^{i}$ is investigated by:

\begin{aligned} Π_{c j f, p u}^{i} & = \sum_{i = 1}^{R} (Π_{c r t}^{p u} + Π_{s i d}^{p u} + Π_{s s}^{p u} + Π_{c t p r}^{p u} + Π_{c t p g}^{p u} \\ + Π_{c u d}^{p u} + Π_{c l f s}^{p u} + Π_{b c r}^{p u} + Π_{b t d}^{p u} + Π_{b v d}^{p u} + Π_{b v r t}^{p u} + Π_{a t l}^{p u} \\ + Π_{c s r}^{p u} + Π_{p p}^{p u} + Π_{q w}^{p u}) \end{aligned}

(16)

Where $Π_{p p}^{p u}$ is the propagation delay for the respective publisher-based caching data storage operation. $Π_{q w}^{p u}$ is the queuing delay for the publisher-based caching data storage operation. $Π_{c r t}^{p u}$ is the publisher-based caching data storage job request dispatch delay to the job schedular at the cellular BS from the user device.

\begin{aligned} Π_{c r t}^{p u} = \frac{Φ_{i r}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{i r}^{p u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(17)

Where $Φ_{i r}^{p u}$ is the publisher’s user-based caching data storage job request message size.

$Π_{s s}^{p u}$ is the job schedular-based cache or server selection delay for caching data storage.

\begin{aligned} Π_{s s}^{p u} = \frac{Ω_{s s}^{p u}}{δ_{s n}} \end{aligned}

(18)

Where $Ω_{s s}^{p u}$ is the workload associated with cache or server selection for caching content storage based on user request. $δ_{s n}$ is the job schedular computation processing or CPU speed.

$Π_{s i d}^{p u}$ is caching job instruction dispatch delay from the job schedular to the user device and selected caching node.

\begin{aligned} Π_{s i d}^{p u} = \frac{Φ_{j i g}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{j i g}^{p u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(19)

Where

Φ_{j i g}^{p u}

is the message size regarding the caching job instruction for both users and the selected caching node (for the publisher job).

$Π_{c t p r}^{p u}$ is the content dispatch or upload permission request transfer delay from the user to the selected caching node (e.g., local cache or remote server).

\begin{aligned} Π_{c t p r}^{p u} = \frac{Φ_{c t p r}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{c t p r}^{p u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} . \end{aligned}

Where $Φ_{c t p r}^{p u}$ is the message size regarding the caching content dispatch or upload permission from the user’s device to the selected caching node or server.

$Π_{c t p g}^{p u}$ is the caching content transfer permission grant delay by the caching node to the user device after the verification operation (for the publisher job).

\begin{aligned} Π_{c t p g}^{p u} = \frac{Φ_{c t p g}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{c t p g}^{p u}}{χ_{o p}} * Υ_{o p} + \frac{Ω_{u v}^{p u}}{δ_{c a n}} \end{aligned}

(20)

Where

Φ_{c t p g}^{p u}

is the message size regarding the caching content upload permission granted from the selected blockchain-based caching node or server to the user device after user verification.

Ω_{u v}^{p u}

is the workload for publisher user verification operations.

δ_{c a n}

is the CPU speed for the blockchain-based caching node for user verification.

$Π_{c u d}^{p u}$ is the publisher-based caching data upload delay to the selected cache or server from the publisher user.

\begin{aligned} Π_{c u d}^{p u} = \frac{Φ_{c u d}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{c u d}^{p u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(21)

Where $Φ_{c u d}^{p u}$ is the publisher’s user based uploaded caching data size.

$Π_{c l f s}^{p u}$ is the cache storage look-up and storage delay associated with the selected local cache or server.

\begin{aligned} Π_{c l f s}^{p u} = Π_{c l f s}^{i} + \frac{Ω_{s t}^{s u}}{δ_{c a n}} \end{aligned}

(22)

Π_{c l c r}^{i}

is the cache look-up delay for storage capability search.

Ω_{s t}^{s u}

is the workload for cache storage search operations.

δ_{c a n}

is the work processing or CPU speed for the selected caching node.

$Π_{b c r}^{p u}$ is the block creation with hashing process completion delay by the selected blockchain capability-based caching nodes after cache storage operation (for publisher user request).

\begin{aligned} Π_{b c r}^{p u} = \frac{Ω_{b c r}^{p u}}{δ_{b c n}} \end{aligned}

(23)

Where $Ω_{b c r}^{p u}$ is the workload associated with block creation and hashing operations in the blockchain capability-based caching node. $δ_{b c n}$ is the CPU speed for the blockchain capability-based caching node.

$Π_{b t d}^{p u}$ is the block data transfer delay from the block data creation node to the block data verifier node (for publisher user jobs).

\begin{aligned} Π_{b t d}^{p u} = \frac{Φ_{b t d}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{b t d}^{p u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(24)

$Φ_{b t d}^{p u}$ is the block data dispatch message size (for publisher requests) from the block creator node to the block data verifier node.

$Π_{b v d}^{p u}$ is the block data verification delay at the verifier node (for the publisher job).

\begin{aligned} Π_{b v d}^{p u} = \frac{Ω_{b v d}^{p u}}{δ_{b v}} \end{aligned}

(25)

Where

Ω_{b v d}^{p u}

is the workload associated with block verification operations at the blockchain verifier nodes (for publisher requests).

δ_{b v}

is the CPU speed for the blockchain verifier node.

$Π_{b v r t}^{p u}$ is the block data verification response transfer delay from the verifier node to the original block data creator node at the caching device (for the publisher job).

\begin{aligned} Π_{b v r t}^{p u} = \frac{Φ_{b v r t}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{b v r t}^{p u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(26)

$Φ_{b v r t}^{p u}$ is the message size regarding the verified block data dispatch from the block data verifier node to the original blockchain-based caching node (for publisher user jobs).

$Π_{c s r}^{p u}$ is the content storage confirmation message transfer delay by the caching node to the user device (publisher job) after caching data storage or publish operation.

\begin{aligned} Π_{c s r}^{p u} = \frac{Φ_{c s r}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{c s r}^{p u}}{χ_{o p}} * Υ_{o p} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(27)

Where

Φ_{c s r}^{p u}

is the message size regarding the caching storage confirmation from the selected blockchain-based caching node or server to the user device after caching data storage.

$Π_{a t l}^{p u}$ is the monetary and blockchain ledger update delay by the blockchain capability-based caching node after block verification and caching data storage operation.

\begin{aligned} Π_{a t l}^{p u} = \frac{Φ_{a t l}^{p u}}{χ_{w r}} * Υ_{w r} + \frac{ϕ_{a t l}^{p u}}{χ_{o p}} * Υ_{o p} + \frac{Ω_{a t l}^{p u}}{δ_{b c n}} + Π_{p p}^{i} + Π_{q w}^{i} \end{aligned}

(28)

Where $Φ_{a t l}^{p u}$ is the message size regarding the ledger update operation (for publisher user-based data storage requests). $Ω_{a t l}^{p u}$ is the workload for ledger update operation (for publisher job).

4.2. Local cache hit ratio and server hit ratio

The local cache hit ratio ( $Δ_{c h r}^{i}$ ) is measured by taking the ratio of local cache hit number (i.e., number of user requests or requested content satisfied by the local cache) and total (i.e., content request satisfied by both local cache and non-local server) hit number.

$Δ_{c h r}^{i}$ is computed by:

\begin{aligned} Δ_{c h r}^{i} = \frac{\sum_{i = 1}^{R} ϱ_{l c h}}{\sum_{i = 1}^{y} (ϱ_{l c h} + ϱ_{s c h})} \end{aligned}

(29)

Where R is the total user caching request number.

ϱ_{l c h}

and

ϱ_{s c h}

are the local cache hit number and non-local server hit number (content number satisfied by the remote content server), respectively. The server hit ratio

Δ_{s h r}^{i}

is computed by taking the ratio of server hit number (remote content server) and total hit number (contents are served by both local cache and remote server). The server hit ratio is measured by:

\begin{aligned} Δ_{s h r}^{i} = \frac{\sum_{i = 1}^{R} ϱ_{s c h}}{\sum_{i = 1}^{R} (ϱ_{l c h} + ϱ_{s c h})} \end{aligned}

(30)

4.3. Stretch ratio

The stretch ratio ( $β_{s r}^{i}$ ) is calculated by taking the ratio of the required hop number for caching request satisfaction (hop distance between the consumer user and source cache) and the total hop number during the original content provider based caching request satisfaction (hop distance between the consumer user and original or remote content server).

$β_{s r}^{i}$ is computed by:

\begin{aligned} β_{s r}^{i} = \frac{\sum_{i = 1}^{R} Γ_{h r}}{\sum_{i = 1}^{y} Γ_{h t}} \end{aligned}

(31)

Where $Γ_{h r}$ is the traveled hop distance during a caching request satisfaction (hop distance between the consumer user and source cache that satisfies the request). $Γ_{h t}$ is the total hop number during original or remote content provider-based caching request satisfaction (hop distance between the consumer and original or remote content server).

4.4. Users total consumed energy

Users’ total consumed energy value $Y_{t e c}^{i}$ for both publisher and subscriber caching jobs is computed by taking into account data transmission energy cost, data reception energy cost, user device-based work processing energy cost, and idle waiting energy cost.

\begin{aligned} Y_{t e c}^{i} & = \sum_{i = 1}^{n_{s u}} Π_{d t t}^{s u} * μ_{t r} + \sum_{i = 1}^{n_{s u}} Π_{d r t}^{s u} * μ_{r e} + \sum_{i = 1}^{n_{s u}} Π_{c s o t}^{s u} * μ_{i t c} \\ + \sum_{i = 1}^{n_{s u}} Π_{w t r}^{s u} * μ_{i t w} + \sum_{i = 1}^{n_{p u}} Π_{d t t}^{p u} * μ_{t r} + \sum_{i = 1}^{n_{p u}} Π_{d r t}^{p u} * μ_{r e} \\ + \sum_{i = 1}^{n_{p u}} Π_{c s o t}^{p u} * μ_{i t c} + \sum_{i = 1}^{n_{p u}} Π_{w t r}^{p u} * μ_{i t w} \\ + \sum_{i = 1}^{n_{p u}} Π_{u w}^{p u} * μ_{u w} + \sum_{i = 1}^{n_{s u}} Π_{u w}^{p u} * μ_{u w} \end{aligned}

(32)

Where $n_{s u}$ is the total subscriber user-based caching content access request (caching data access) and $n_{p u}$ is the total publisher user (for publishing cache content to the storage server)-based content request storage request.

$Π_{d t t}^{s u}$ , $Π_{d r t}^{s u}$ , $Π_{u w}^{s u}$ , $Π_{c s o t}^{s u}$ , and $Π_{w t r}^{s u}$ are the data transmission time, data receive time, user device based work processing time, caching work processing time at the selected cache or server, and users waiting time (during resource access) for the subscriber-based caching content delivery job request execution.

$Π_{d t t}^{p u}$ , $Π_{d r t}^{p u}$ , $Π_{u w}^{p u}$ , $Π_{c s o t}^{p u}$ , and $Π_{w t r}^{p u}$ are the data transmission time, data receive time, user device-based workload processing time, caching work processing time at the selected cache or server, and users waiting time (during resource access) for the publisher-based caching content storage job request execution.

$μ_{t r}$ , $μ_{r e}$ , $μ_{u w}$ , $μ_{i t c}$ , and $μ_{i t w}$ are the users average consumed energy value (per millisecond) for data transmission time, data receive time, user device-based workload processing, caching work processing time at the selected cache or server, and users waiting time (during resource access) for different caching job executions, respectively.

4.5. Users financial cost for caching job execution

Users’ total financial cost value ( $X_{u f c}^{i}$ ) for both publisher and subscriber caching job execution is calculated by taking into account service provider-owned cache or server resource usage cost, user-owned cache or server resource usage cost, bandwidth resource usage cost, and financial cost during waiting delay (for resource).

\begin{aligned} X_{u f c}^{i} & = \sum_{i = 1}^{n_{s u}} Π_{d t t}^{i} * θ_{b w} + \sum_{i = 1}^{n_{s u}} Π_{d r t}^{i} * θ_{b w} + \sum_{i = 1}^{n_{s p c}} Π_{c s o t}^{s p c} * θ_{s p c} \\ + \sum_{i = 1}^{n_{u o c}} Π_{c s o t}^{u o c} * θ_{u o c} + \sum_{i = 1}^{n_{s u}} Π_{w t r}^{s u} * θ_{i t w} + \sum_{i = 1}^{n_{p u}} Π_{d t t}^{i} * θ_{b w} \\ + \sum_{i = 1}^{n_{p u}} Π_{d r t}^{i} * θ_{b w} - \sum_{i = 1}^{n_{s p c}} Π_{c s t}^{s p c} * θ_{s s c} \\ - \sum_{i = 1}^{n_{u o c}} Π_{c s t}^{u o c} * θ_{u s c} + \sum_{i = 1}^{n_{p u}} Π_{w t r}^{p u} * θ_{i t w} \\ + \sum_{i = 1}^{n_{p u}} Π_{u w}^{i} * θ_{u w} + \sum_{i = 1}^{n_{s u}} Π_{u w}^{i} * θ_{u w} \end{aligned}

(33)

Where $n_{s p c}$ is the number of caching jobs that utilize service providers’ cache or server, and $n_{u o c}$ is the number of caching jobs that utilize user-owned cache or server.

$n_{s u}$ is the subscriber user-based caching content access job amount, and $n_{p u}$ is the publisher user (for publishing cache content to the storage server)-based caching job request number.

$θ_{b w}$ , $θ_{s p c}$ , $θ_{u o c}$ , $θ_{i t w}$ , and $θ_{u w}$ are the subscriber users average financial cost or payment value (per millisecond) for bandwidth resource usage duration, service provider-owned cache or server resource usage for caching content access, user-owned cache or server resource usage for caching content access, users waiting time (during resource access), and user device based job processing time, respectively.

$θ_{s s c}$ and $θ_{u s c}$ are publisher users’ average selling price gain value (per millisecond) for service provider-owned cache or server-based caching content storage and user-owned cache or server-based caching content storage, respectively.

$Π_{c s o t}^{s p c}$ , $Π_{c s o t}^{u o c}$ , $Π_{c s t}^{s p c}$ , and $Π_{c s t}^{u o c}$ are the caching content search and access time from the service provider cache or server, caching content search and access time from the user owned cache or server, caching content storage time to the service provider cache or server from publisher user, and caching content storage time to the user owned cache or server from publisher user, respectively.

4.6. Service provider cost and profit

The service provider cost value ( $G_{s p c}^{i}$ ) for both publisher and subscriber caching job execution is calculated by taking into account caching resource buying, leasing, and maintenance cost, bandwidth resource buying, leasing, and maintenance cost, and financial cost during waiting delay (for resource).

\begin{aligned} G_{s p c}^{i} & = \sum_{i = 1}^{R} Π_{d t t}^{i} * θ_{s b w} + \sum_{i = 1}^{R} Π_{d r t}^{i} * θ_{s b w} \\ + \sum_{i = 1}^{n_{s p c}} Π_{c s o t}^{s p c} * θ_{s p p c} + \sum_{i = 1}^{n_{u o c}} Π_{c s o t}^{u o c} * θ_{s u o c} \\ + \sum_{i = 1}^{R} Π_{w t r}^{i} * θ_{s i t w} + \sum_{i = 1}^{R} Π_{u w}^{i} * θ_{s u w} \end{aligned}

(34)

Where R is the total caching request number. $θ_{s b w}$ , $θ_{s p p c}$ , $θ_{s u o c}$ , $θ_{s i t w}$ , and $θ_{s u w}$ are the average financial cost or payment value (per millisecond) associated with service providers for bandwidth resource service, service provider-owned caching service, user-owned caching service, waiting delay (for resource), and user device based resource usage, respectively.

$Π_{d t t}^{i}$ , $Π_{d r t}^{i}$ , $Π_{u w}^{i}$ , $Π_{c s o t}^{s p c}$ , $Π_{c s o t}^{u o c}$ , and $Π_{w t r}^{i}$ are the data transmission time for different caching jobs, data receive time for different caching jobs, user device-based workload processing time, caching work processing time at the service provider-based cache or server, caching work processing time at the user-owned cache or server, and users waiting time (during resource access) for different caching jobs, respectively.

Service provider profit for R number of caching jobs ( $Z_{S P P}^{R}$ ) can be determined as follows: $Z_{S P P}^{i} = \sum_{i = 1}^{R} X_{u f c}^{i} - \sum_{i = 1}^{R} G_{s p c}^{i}$ . Where $X_{u f c}^{i}$ is the collected revenue from users and $G_{s p c}^{i}$ is the service providers’ cost for the caching job execution.

4.7. Job execution success ratio

The job execution requirement fulfillment or success ratio ( $Q_{s r}^{i}$ ) is determined by taking into account the ratio of total caching job requests that satisfy the caching job execution deadline requirement and the total number of caching job requests that have arrived.

$Q_{s r}^{i}$ is computed by:

\begin{aligned} Q_{s r}^{i} = \frac{\sum_{i = 1}^{R} ω_{t r s}^{i}}{\sum_{i = 1}^{R} ω_{t c r}^{i}} = \frac{\sum_{i = 1}^{R} (ω_{t c r}^{i} - ω_{f r s}^{i})}{\sum_{i = 1}^{R} ω_{t c r}^{i}} \end{aligned}

(35)

Where $ω_{t r s}^{i}$ , $ω_{f r s}^{i}$ , and $ω_{t c r}^{i}$ are the total caching job requests that satisfy the deadline time requirement for caching job execution, the number of jobs that dissatisfy the deadline requirement, and the total number of caching job requests, respectively.

4.8. Throughput value

The system throughput value ( $κ_{s t v}^{i}$ ) is determined by taking into account both the total transferred data amount and the makespan delay value for caching job execution.

$κ_{s t v}^{i}$ is calculated by:

\begin{aligned} κ_{s t v}^{i} = \frac{\sum_{i = 1}^{n_{s u}} Φ_{t d s}^{i} + \sum_{i = 1}^{n_{p u}} Φ_{t d s}^{i}}{\sum_{i = 1}^{R} ξ_{m s t}^{i}} \end{aligned}

(36)

Where

Φ_{t d s}^{i}

is the total exchanged data amount from sender to receiver during caching job execution.

ξ_{m s t}^{i}

is the makespan delay for arrived multiple caching job execution. R is the total caching job number (

R = n_{s u} + n_{p u}

4.9. Users survivability ratio

User’s survivability ratio ( $η_{u s r}^{i}$ ) is investigated by taking the ratio of total alive user device after the simulation round ( $ζ_{\tan}^{i}$ ) and total number of user device number ( $ϵ_{u n}^{i}$ ) at the beginning of the simulation (both alive and dead user device).

$η_{u s r}^{i}$ is investigated by:

\begin{aligned} η_{u s r}^{i} & = \frac{\sum_{i = 1}^{R} ζ_{\tan}^{i}}{\sum_{i = 1}^{R} ϵ_{u n}^{i}} = \frac{\sum_{i = 1}^{R} ϵ_{u n}^{i} - ζ_{t d n}^{i}}{\sum_{i = 1}^{R} ϵ_{u n}^{i}} \\ = \frac{\sum_{i = 1}^{R} ϵ_{u n}^{i} - \frac{b_{1}^{i} * b_{2}^{i} * b_{3}^{i}}{c_{i n}^{i}}}{\sum_{i = 1}^{R} ϵ_{u n}^{i}} \end{aligned}

(37)

Where $b_{1}^{i}$ , $b_{2}^{i}$ , and $b_{3}^{i}$ are the total caching job number per round, total users consumed energy value for arrived caching job execution in each round, and total simulation round number, respectively. $ζ_{\tan}^{i}$ is the total alive user device number. $ϵ_{u n}^{i}$ is the total user device number at the beginning of the simulation.

$ζ_{t d n}^{i}$ is the total dead node number after the simulation round.

4.10. User total welfare value

User total welfare value ( $γ_{t u w v}^{i}$ ) for caching job execution is measured by taking the summation of user caching job execution time welfare value ( $σ_{t w}^{i}$ ), energy cost welfare value ( $σ_{e w}^{i}$ ), and financial cost welfare value ( $σ_{f c w}^{i}$ ).

\begin{aligned} γ_{t u w v}^{i} & = \sum_{i = 1}^{R} σ_{t w}^{i} + σ_{e w}^{i} + σ_{f c w}^{i} \\ = \frac{\sum_{i = 1}^{R} σ_{t d}^{i} - σ_{m d}^{i}}{\sum_{i = 1}^{R} σ_{t d}^{i}} + \frac{\sum_{i = 1}^{R} σ_{t e b}^{i} - σ_{r e v}^{i}}{\sum_{i = 1}^{R} σ_{t e b}^{i}} \\ + \frac{\sum_{i = 1}^{R} σ_{t f b}^{i} - σ_{r f v}^{i}}{\sum_{i = 1}^{R} σ_{t f b}^{i}} \end{aligned}

(38)

Where

σ_{t d}^{i}

σ_{m d}^{i}

σ_{t e b}^{i}

σ_{r e v}^{i}

σ_{t f b}^{i}

, and

σ_{r f v}^{i}

are the caching job execution deadline value, required time for caching job execution completion, energy budget by users for caching job execution, required energy cost value by the proposed scheme for caching job execution, financial budget by users for caching job execution, and required financial cost value by the proposed scheme for caching job execution, respectively.

5. Experimental results and analysis

In this section of the article, this paper provides the experimental results and analysis concerning the proposed trailblazer-based resource and job scheduling scheme for publisher- and subscriber-user-based 6G information-centric networks, or ICN services. The main features of the proposed trailblazer-based resource orchestration scheme (WPCD+PBA+WUC) are proactive pre-caching (WPCD), blockchain-empowered job execution (PBA), collaboration with the nearby network for resources with both user-owned cache and service provider cache (WUC), minimum content retrieval latency, minimum energy cost-awareness, and maximum user welfare-based resource selection (caching node and communication link). To understand the supremacy of the proposed trailblazer scheme, the proposed scheme is compared with two existing schemes. They are compared scheme one (e.g., silva et al. [77], Banerjee et al. [10], Zhou et al. [107], Ben-Ammar et al. [13]) and compared scheme two (e.g., Cai et al. [14], Naeem et al. [60], silva et al. [77], Rahim et al. [69], Yang et al. [99], Lal et al. [47]). The compared scheme one offers greedy content caching server selection (GCD), first-in-first-out (FiFo)-based caching content replacement, and resource scheduling. The compared scheme two a random-based content caching node or server selection (RCD), a whimsical cache content replacement policy, and indiscriminate timeslot scheduling for each caching request. It can be noted that there are no proactive pre-caching (NPC) facilities, no collaboration with nearby network resources (NC), and no usage of user-owned cache (i.e., relies on only service provider cache) for content caching (NUOC) in both schemes one and two.

Table 1
Experimental notations and values.

Parameters Values/Units

$Φ_{n s b}^{i}$ , $Φ_{c r}^{i}$ , $Φ_{c e}^{i}$ , $Φ_{i b o}^{i}$ , $Φ_{p a t}^{i}$ , $Φ_{i r}^{i}$ , $δ_{s n}$ , $δ_{u s}$ , $δ_{c n}$ Network initial beacon message size (192 bits), message size for network connectivity and service registration request (192 bits), message size for network connectivity and service registration response (192 bits), message size for initial blockchain setup request and response operation (160 bit), message size for primary slot assign schedule (160 bit), message size for users caching job request (1 KB), CPU speed for the schedular node (3–3.9 GHz), maximum CPU speed for user device (500–1000 MHz), and CPU speed for caching node (3–3.9 GHz)

$χ_{w r}$ , $χ_{o p}$ , $Υ_{w r}$ , $Υ_{o p}$ , $Π_{p p}^{i}$ , $Π_{q w}^{i}$ , $Ω_{i b o}^{s n}$ , $Ω_{c e}^{i}$ , $Ω_{p a t}^{i}$ , $Ω_{i b o}^{u}$ , $Ω_{c r}^{i}$ , $Ω_{i r}^{i}$ , $Φ_{c f b r}^{i}$ , $Φ_{a t}^{i}$ , $Ω_{c f b s}^{i}$ , $Ω_{c s}^{i}$ , $Ω_{u s}^{i}$ , $Ω_{a t}^{i}$ Data transfer rate for selected wireless link (8–30 Gbps for terahertz link, 3–6 Gbps for mmWave link, 30–300 Mbps for microwave link), data transfer rate for selected optical fiber link (30–50 Gbps), hop distance for wireless link based data transfer (1–8), hop distance for optical link based data transfer (1–6), propagation delay (ms), queuing delay (ms), workload amount for initial blockchain setup at the job schedular device (10 CPU cycles/bit), network connectivity and service registration response processing work (5 CPU cycles/bit), primary job request control slot scheduling work (5 CPU cycles/bit), workload amount for initial blockchain setup at the user node (5 CPU cycles/bit), network connectivity and service registration request processing work at the user node (5 CPU cycles/bit), primary caching job request generation work at the user device (5 CPU cycles/bit), caching node response message size to schedular node regarding caching content availability (160 bits), resource scheduling message size (192 bits), workload for CS, PIT, and FIB table search response generation, computation workload for CS, PIT, and FIB table search (5 CPU cycles/bit), workload for suitable cache or server selection (10 CPU cycles/bit), workload for resource assignment message generation (10 CPU cycles/bit)

$μ_{t r}$ , $μ_{r e}$ , $μ_{u w}$ , $μ_{i t c}$ , $μ_{i t w}$ , $θ_{b w}$ , $θ_{s p c}$ , $θ_{u o c}$ , $θ_{i t w}$ , $θ_{u w}$ , $θ_{s b w}$ , $θ_{s p p c}$ , $θ_{s u o c}$ , $θ_{s i t w}$ , $θ_{s u w}$ , simulation area Users average consumed energy value (per milisecond) for data transmission time (.41W), data receive time (.31W), user device based workload processing (.4W), caching work processing time at the selected cache or server (.001W), and users waiting time during resource access (.0005W), subscriber users average financial cost or payment value (per milisecond) for bandwidth resource usage duration (.3 USD), service provider owned cache or server resource usage (.6 USD), user owned cache or server resource usage or caching content access (.4 USD), users waiting time during resource access (.0003 USD), and user device based job work processing (.1 USD), average financial cost or payment value (per milisecond) associated with service providers for bandwidth resource service (.15 USD), service provider owned caching service (.5 USD), user-owned caching service (.3 USD), waiting delay for resource (.0005 USD), user device based resource usage (.05 USD), 1000 m ∗ 1000 m

Parameters	Values/Units
$Φ_{n s b}^{i}$ , $Φ_{c r}^{i}$ , $Φ_{c e}^{i}$ , $Φ_{i b o}^{i}$ , $Φ_{p a t}^{i}$ , $Φ_{i r}^{i}$ , $δ_{s n}$ , $δ_{u s}$ , $δ_{c n}$	Network initial beacon message size (192 bits), message size for network connectivity and service registration request (192 bits), message size for network connectivity and service registration response (192 bits), message size for initial blockchain setup request and response operation (160 bit), message size for primary slot assign schedule (160 bit), message size for users caching job request (1 KB), CPU speed for the schedular node (3–3.9 GHz), maximum CPU speed for user device (500–1000 MHz), and CPU speed for caching node (3–3.9 GHz)
$χ_{w r}$ , $χ_{o p}$ , $Υ_{w r}$ , $Υ_{o p}$ , $Π_{p p}^{i}$ , $Π_{q w}^{i}$ , $Ω_{i b o}^{s n}$ , $Ω_{c e}^{i}$ , $Ω_{p a t}^{i}$ , $Ω_{i b o}^{u}$ , $Ω_{c r}^{i}$ , $Ω_{i r}^{i}$ , $Φ_{c f b r}^{i}$ , $Φ_{a t}^{i}$ , $Ω_{c f b s}^{i}$ , $Ω_{c s}^{i}$ , $Ω_{u s}^{i}$ , $Ω_{a t}^{i}$	Data transfer rate for selected wireless link (8–30 Gbps for terahertz link, 3–6 Gbps for mmWave link, 30–300 Mbps for microwave link), data transfer rate for selected optical fiber link (30–50 Gbps), hop distance for wireless link based data transfer (1–8), hop distance for optical link based data transfer (1–6), propagation delay (ms), queuing delay (ms), workload amount for initial blockchain setup at the job schedular device (10 CPU cycles/bit), network connectivity and service registration response processing work (5 CPU cycles/bit), primary job request control slot scheduling work (5 CPU cycles/bit), workload amount for initial blockchain setup at the user node (5 CPU cycles/bit), network connectivity and service registration request processing work at the user node (5 CPU cycles/bit), primary caching job request generation work at the user device (5 CPU cycles/bit), caching node response message size to schedular node regarding caching content availability (160 bits), resource scheduling message size (192 bits), workload for CS, PIT, and FIB table search response generation, computation workload for CS, PIT, and FIB table search (5 CPU cycles/bit), workload for suitable cache or server selection (10 CPU cycles/bit), workload for resource assignment message generation (10 CPU cycles/bit)
$μ_{t r}$ , $μ_{r e}$ , $μ_{u w}$ , $μ_{i t c}$ , $μ_{i t w}$ , $θ_{b w}$ , $θ_{s p c}$ , $θ_{u o c}$ , $θ_{i t w}$ , $θ_{u w}$ , $θ_{s b w}$ , $θ_{s p p c}$ , $θ_{s u o c}$ , $θ_{s i t w}$ , $θ_{s u w}$ , simulation area	Users average consumed energy value (per milisecond) for data transmission time (.41W), data receive time (.31W), user device based workload processing (.4W), caching work processing time at the selected cache or server (.001W), and users waiting time during resource access (.0005W), subscriber users average financial cost or payment value (per milisecond) for bandwidth resource usage duration (.3 USD), service provider owned cache or server resource usage (.6 USD), user owned cache or server resource usage or caching content access (.4 USD), users waiting time during resource access (.0003 USD), and user device based job work processing (.1 USD), average financial cost or payment value (per milisecond) associated with service providers for bandwidth resource service (.15 USD), service provider owned caching service (.5 USD), user-owned caching service (.3 USD), waiting delay for resource (.0005 USD), user device based resource usage (.05 USD), 1000 m ∗ 1000 m

Table 2

Experimental notations and values (cont).

Parameters	Values/Units
$Φ_{j i g}^{s u} / Φ_{j i g}^{p u}$ , $Φ_{c a p r}^{s u}$ , $Ψ_{c l}$ , $Φ_{c d s}$ , $Φ_{b t d}^{s u} / Φ_{b t d}^{p u}$ , $Φ_{b v r t}^{s u} / Φ_{b v r t}^{p u}$ , $Φ_{c a p g}^{s u}$ , $Φ_{c d s}^{s u}$ , $Φ_{a t l}^{s u} / Φ_{a t l}^{p u}$ , $Φ_{i r}^{s u} / Φ_{i r}^{p u}$ , $Φ_{c t p r}^{p u}$ , $Φ_{c t p g}^{p u}$ , $Φ_{c u d}^{p u}$ , $Π_{c l c r}^{i}$ , $Φ_{c s r}^{p u}$	Message size regarding the caching job instruction for both users and selected caching job processing work node (1 KB), message size regarding the caching content access permission from the users device to the selected caching node (512 Bytes), cache file look up delay for content (ms, vary), requested content size for caching (2–100 KB), message size regarding the block data dispatch for subscriber request/publisher user request (2–100 KB), message size regarding the verified block data dispatch for subscriber/publisher job (1 KB), message size regarding the caching content access permission grant (1 KB), downloaded content size (2–100 KB), message size regarding the ledger update operation for subscriber/publisher job (1 KB), message size for subscriber/publisher user caching job request, message size regarding the caching content dispatch or upload permission (512 Bytes), message size regarding the caching content upload permission grant (1 KB), publisher user based uploaded caching content data size (10–300 KB), cache look up delay for storage capability search (ms, vary), message size regarding the caching storage confirmation (1 KB)
$Ω_{c p f}^{s u}$ , $Ω_{b c r}^{s u} / Ω_{b c r}^{p u}$ , $δ_{b c n} / δ_{b v}$ , $Ω_{b v d}^{s u} / Ω_{b v d}^{p u}$ , $Ω_{u v}^{s u}$ , $Ω_{s s}^{p u}$ , $Ω_{u v}^{p u}$ , $δ_{c a n}$ , $Ω_{s t}^{s u}$ , $Ω_{a t l}^{s u} / Ω_{a t l}^{p u}$	The workload for checking CS, PIT, and FIB table for local cache or server selection (1 K CPU cycles/bit), the workload associated with block creation and hashing operation in the primary edge blockchain node for subscriber/publisher job (500 CPU cycles/bit), maximum CPU speed for the blockchain node/verifier device (3–3.9 GHz), the workload associated with block verification operation at the blockchain verifier node for subscriber/publisher caching job (500 CPU cycles/bit), the workload for publisher user verification operation (100 CPU cycles/bit), the workload associated with cache or server selection for caching content storage (1 K CPU cycles/bit), the workload for publisher user verification operation (100 CPU cycles/bit), maximum CPU speed for the blockchain-based caching node (3–3.9 GHz), the workload for cache storage search operation (1 K CPU cycles/bit), the workload for ledger update operation by the blockchain node (500 CPU cycles/bit)
$ϑ_{a c r l}^{i}$ , $Δ_{c h r}^{i}$ , $β_{s r}^{i}$ , $Y_{t e c}^{i}$ , $X_{u f c}^{i}$ , $G_{s p c}^{i}$ , $Z_{S P P}^{R}$ , $Q_{s r}^{i}$ , $κ_{s t v}^{i}$ , $η_{u s r}^{i}$ , $γ_{t u w v}^{i}$ , user device number, total caching job request	Mean content retrieval delay (ms, vary), local cache hit ratio (0–1), stretch ratio (0–1), users total consumed energy (mJ, vary), users total financial cost (USD, vary), service provider cost (USD, vary), service provider profit (USD, vary), job execution success ratio (0–100%, vary), throughput ratio (Kbps, vary), user survivability ratio (0–100 %), users total welfare value (0–10), 400, 25–125 (vary)

In this article, the MATLAB-based simulation framework is used along with the NDN simulator (e.g., Qin et al. [67]). The total number of publisher-subscriber-based caching job amounts varies between 25 and 125. The caching job execution deadline is varied between 1500 milliseconds and 17500 milliseconds. In this work, the caching requests are generated based on an independent basis (i.e., an independent request model). The cache content distribution follows the Zipf law or probability model with a popularity variation factor of 1.1 (i.e., α = 1.1). The cache replacement policy of the proposed scheme is the least recently used LRU. The storage capacity of both the user-owned cache and the service provider-owned cache is 100 GB. We have considered one local user-owned cache and one service provider-owned cache at the edge network, whereas the original content server is located at the remote cloud, which is 3–5 hops away from the user-edge network. For each caching job, the subscriber user’s requested content amount is selected randomly from the 2–100 KB range. For each publisher user caching job, the uploaded caching content amount is selected randomly from the range of 10–300 KB. The computation workload amount for checking the CS/PIT/FIB table is 1 K CPU cycles per bit. The computation workload associated with block creation and hashing operations in the primary edge blockchain node for the subscriber/publisher job is 500 CPU cycles per bit. The workload associated with block verification operations at the blockchain verifier node for the subscriber/publisher caching job is 500 CPU cycles per bit. The workload amount for publisher/subscriber user verification operations is 100 CPU cycles per bit. The computation workload associated with cache or server selection for caching content storage is 1 K CPU cycles/bit. The workload amount for ledger update operations by the blockchain node is 500 CPU cycles per bit. The other important experimental notations or parameters (e.g., message or data size, workload, data rate, energy cost, financial cost) and values associated with simulation are given in Tables 1–2. In this work, the simulation values and parameters are used by examining the sample values mentioned in Naeem et al. [60], Hoang et al. [38], Amadeo et al. [3], Naeem et al. [62], Drolia et al. [24], silva et al. [77], Duan et al. [25], Gui et al. [32], Nguyen et al. [64], Islam et al. [39], Thar et al. [81], Elsmany et al. [26], Ullah et al. [86], Liu et al. [53], Sfiligoi et al. [75].

Figure 3(a) represents the impact of the number of publish-subscriber caching job requests on the mean content retrieval latency performance. Content retrieval latency can be defined as the time between the content request travel time and the content travel time to the destination. It can be observed from the figure that the mean content retrieval latency increases as the caching job request increases. The proposed trailblazer scheme outperforms all compared schemes (i.e., compared scheme one and compared scheme two); as a matter of fact, its mean content retrieval latency is the lowest among all compared schemes. The proposed Trailblazer scheme offers better content retrieval latency because its cache hit ratio is the highest among all compared schemes. Further, the proposed trailblazer scheme relies on not only a service provider-owned cache (i.e., owned by the content provider and ICN) but also one user device-owned cache at the edge of the network. Moreover, the proposed trailblazer scheme offers collaboration among neighboring edge cluster networks for content caching. In addition, the proposed scheme includes proactive pre-caching service or content delivery (WPCD), in which the cached content can be transferred to one of the edge cache servers from the remote content server (i.e., the cached content transfer process from the remote to the edge server can be rearranged during data transfer and the content caching process of other users). Moreover, the proposed scheme selects suitable caching servers with the highest profit-based access (PBA) and minimum predicted caching content access, waiting delay, and data transfer communication delay. The proposed scheme relies on an LRU (least recently used)-based cache content replacement policy. It also provides the earliest deadline-based timeslot scheduling process for all publish-subscriber caching job requests. The figure also shows that the compared scheme one yields the second highest mean content retrieval latency due to its greedy content caching server selection (GCD) with first-in-first-out (FiFo)-based cache content replacement policy and timeslot scheduling for each caching request. It also relies on nonproactive pre-caching (NPC), non-collaboration among nearby cluster edge networks (NC), and non-usage of user-owned cache (i.e., relies on service provider cache) for content caching (NUOC). The figure also highlights that the compared scheme two yields the highest mean content retrieval latency due to its random-based content caching server selection (RCD), whimsical cache content replacement policy, and indiscriminate timeslot scheduling for each caching request. It also relies on nonproactive pre-caching (NPC), non-collaboration among nearby cluster edge networks (NC), and non-usage of user-owned cache (i.e., relies on only service provider cache) for content caching (NUOC). For example, in Fig. 3(a), when the number of publish and subscriber caching requests is one hundred, the mean content retrieval latency for the proposed trailblazer scheme, compared scheme one, and compared scheme two are 4516 ms, 8405 ms, and 10421 ms, respectively.

Figure 3(b) gives the stretch ratio results versus caching job requests for our proposed trailblazer scheme as well as for two different compared schemes. The figure also depicts that, when the caching content request increases, the stretch ratio increases slightly in all compared schemes. The proposed trailblazer scheme outperforms the two other policies in terms of stretch ratio. The stretch ratio is defined as the ratio between the number of hops traveled (i.e., between the users or consumers and the source of the cached content or immediate cache) and the number of hops to the content server (i.e., from the consumer to the original content server). Thus, the lower value of the stretch ratio indicates a smaller traveled hop amount during cached content access and a smaller content retrieval latency. It can be seen from Fig. 3(b) that the proposed trailblazer scheme outperforms both compared schemes in terms of a lower stretch ratio. The proposed trailblazer scheme offers a lower stretch ratio because it relies on both service providers’ edge cache and user-owned edge cache, along with the content provider’s centralized cache server for cached content access, its collaboration with neighbor edge network cache servers, LRU cache replacement policies, and proactive precaching features. Whereas, due to their non-collaboration among neighbor networks and usage of only the service provider cache server rather than user-owned cache usage policies, compared scheme one (with greedy server selection, FiFo-based timeslot scheduling, and FiFo-based cache replacement policy) and compared scheme two (random based server selection, timeslot scheduling, and cache replacement policy) offer second best and third-best stretch ratios, respectively. For instance, in Fig. 3(b), when the number of publish and subscriber caching requests is seventy-five, the stretch ratio for the proposed trailblazer scheme, compared scheme one and scheme two are .49, .60, and .66, respectively.

Fig. 3.

Mean content retrieval latency and stretch ratio value.

Fig. 4.

Cache hit ratio and server hit ratio.

Figure 4(a) highlights the immediate cache hit ratio (i.e., intermediate local caches, not the centralized content server) performance of our proposed trailblazer scheme as well as the two traditional or compared schemes by varying the cached content amount. From Fig. 4(a), it can be noticed that the immediate cache hit ratio slightly decreases with the increasing cached content size. The proposed Trailblazer scheme outperforms all compared schemes in terms of a higher cache hit ratio. This is essentially due to the fact that by relying on both the service provider cache server and user-owned cache, along with the nearby collaborating neighbor caches, the proposed scheme ensures higher cached content storage than other compared schemes. Both the compared schemes, one and two offer second and worse immediate cache hit ratio results, respectively. This is because both schemes 1 and 2 rely on only the service provider cache (i.e., content provider and ICN cache) rather than the user-owned cache and nearby collaborative network cache. Moreover, the proposed scheme relies on LRU cache replacement policies, whereas the compared schemes one and two rely on FiFo and random-based cache replacement policies, respectively. For reference, in Fig. 4(a), when the amount of cached content is 2060 KB, the intermediate cache hit ratio for the proposed trailblazer scheme, compared scheme one, and scheme two are .90, .66, and .59, respectively.

Figure 4(b) represents the server hit ratio (i.e., the caching request is satisfied by the centralized content server or no local caches) performance for all compared schemes along with the proposed trailblazer scheme. It can be noticed that the lowest server hit ratio means a lower amount of content retrieval delay. Whereas, a higher server hit ratio means a higher amount of content retrieval latency. Figure 4(b) notifies that the server hit ratio slightly increases with the increased amount of cached content size in all compared schemes. Figure 4(b) portrays that the server hit ratio performance is the lowest in the proposed trailblazer scheme. This means that in the proposed trailblazer scheme, most of the cached content requests are satisfied by the local or intermediate caches (both service providers and user-owned caches) rather than the centralized server. Whereas, the server hit ratio performance is highest in the compared scheme two and second highest in the compared scheme one, respectively. This means that both schemes one and two rely more on the centralized content server for request satisfaction compared with the proposed trailblazer scheme. For instance, in Fig. 4(b), when the amount of cached content is 3090 KB, the server hit ratio for the proposed trailblazer scheme, compared to scheme one, and compared scheme two are .12, .36, and .42, respectively.

Figure 5(a) illustrates the impact of the job execution deadline on the caching job execution requirement satisfaction or success ratio. The job execution success ratio is the ratio between the number of caching jobs executed within the deadline and the total caching jobs. In this work, the job execution success ratio implies the number of caching jobs that satisfy the user’s job execution deadline. From Fig. 5(a), it can be seen that the job execution success ratio increases with a higher number of job execution deadlines. The proposed trailblazer scheme yields the highest job execution requirement satisfaction success ratio compared to schemes one and two, respectively. Recall that the proposed trailblazer scheme relies on the earliest deadline based on timeslot scheduling for caching job execution. Moreover, the proposed scheme includes proactive pre-caching, user-owned cache, and collaborative caching policies, along with an LRU-based cache replacement policy. In addition, the suitable server for the caching job is selected in the proposed trailblazer scheme based on their lowest caching request travel, content search delay, and content delivery delay. Whereas, the job execution success ratio performance is lowest in the compared scheme two and second highest in the compared scheme one, respectively. The reason behind this is that the compared scheme two relies on random-based timeslot scheduling and server selection for caching job execution, along with an indiscriminate cache replacement policy. Whereas, the compared scheme relies on FCFS-based timeslot scheduling and server selection for caching job execution, along with a FiFo-based cache replacement policy. For notification, in Fig. 5(a), when the amount of caching job is 17500 ms, the job execution success ratio for the proposed trailblazer scheme, compared to scheme one, and compared scheme two, is 100 percent, 84 percent, and 77 percent, respectively.

Figure 5(b) shows the throughput ratio performance of our proposed and compared scheme by varying the caching content size. The presented results in Fig. 5(b) show that the throughput ratio increases with the increment of caching content size in all compared schemes. The results show that for both low and high content sizes, the proposed trailblazer scheme performs better than the compared schemes one and two in terms of throughput ratio. As the proposed scheme utilizes both service provider cache and user-owned cache, offers collaboration among neighbor networks cache and precaching opportunity (transfer of cached content from a remote server to the nearby server during other edge cache-based content processing timeslots), and offers suitable cache or server selection for caching content access with a minimum predicted content retrieval latency, the throughput ratio is higher in the proposed trailblazer scheme than both compared scheme one and two. The compared schemes one and two suffer from the second highest and highest waiting latency, respectively. This is because compared schemes one and two suffer from inefficient cache server selection (e.g., FCFS-based scheduling and greedy-based server access for compared scheme one, random-based server and timeslot selection for compared scheme two), a lack of neighbor network collaboration policy for cache service access and a lack of precaching policy, and a lack of user-owned cache usage, among others. For reference, in Fig. 5(b), when the amount of cached content is 5150 KB, the throughput ratios for the proposed trailblazer scheme, compared to scheme one, and compared scheme two are 315 Kbps, 297 Kbps, and 285 Kbps, respectively.

Fig. 5.

Job execution success ratio and throughput ratio value.

Fig. 6.

Service access financial cost and users energy cost.

Fig. 7.

Service provider profit, user device survivability ratio, and overall user welfare value.

Next, this paper investigates the financial cost evaluation for both proposed trailblazer schemes, along with comparing schemes versus the caching job amount number. The results of Fig. 6(a) demonstrate that the user’s financial cost increases with the increment of the caching job amount. Our results show that the financial cost of users is minimum in the proposed trailblazer scheme rather than both compared to schemes one and two. The reason is that the proposed scheme utilizes both the service provider cache (e.g., content provider cache and ICN cache) and the user-owned cache at the edge network. Thus, the resource purchase cost is minimal in the proposed trailblazer scheme. Moreover, the proposed scheme selects a suitable cache or server for each caching job based on their lowest predicted minimum content retrieval latency. Thus, due to this lower content retrieval latency, the local cache or remote server usage time as well as the financial cost of caching services are lower in our proposed trailblazer scheme than others. On the other hand, the compared schemes one and two only use service provider-owned cache (i.e., do not use any local user-owned cache or collaborative cache). Moreover, due to an improper cache or server selection strategy along with timeslot scheduling, the compared schemes one and two suffer from the second and highest content retrieval latency, respectively. Thus, due to the second and highest amount of resource usage time, compared schemes one and two suffer from the second maximum and maximum financial cost, respectively. For notification, in Fig. 6(a), when the number of caching jobs is 125, the financial cost for the proposed trailblazer scheme, compared to scheme one and scheme two, is 2206 USD, 3095 USD, and 3214 USD, respectively.

Figure 6(b) illustrates the user-consumed energy value generated by the proposed trailblazer scheme and compared schemes. The figure highlights that the user device-based consumption energy (for job execution) value is higher for large caching content sizes and lower for small caching content sizes. In the given figure, it can be shown that the proposed trailblazer scheme offers a lower energy value for different caching job executions. Whereas, the compared schemes one and two experience the second and highest amount of consumed energy, respectively. The reason is that the content retrieval latency is lowest in the proposed Trailblazer scheme. Moreover, due to the use of a proactive precaching scheme and access of cached content at the local cache (both service provider and user-owned cache), the selection of the best cache or server based on lower predicted content retrieval latency, a suitable timeslot scheduling scheme, the overall resource usage time, cache search and access, and communication time are the lowest in the proposed trailblazer scheme. Due to this lowest resource usage time, the energy consumption at the user device is also minimal in the proposed Trailblazer scheme. The content retrieval latency is second highest in compared scheme one and highest in compared scheme two. Thus, the resource usage time, cache lookup, waiting, and communication time are also second best in compared scheme one and highest in compared scheme two, respectively. Due to this higher amount of resource usage time compared with the proposed scheme, the energy consumption at the user device is second highest in the compared scheme one and highest in the compared scheme two, respectively. For reference, in Fig. 6(b), when the cached content size is 4120 KB, the user device consumed energy for the proposed trailblazer scheme, compared scheme one, and compared scheme two are 429 mJ, 500 mJ, and 541 MJ, respectively.

The service provider profit value for both the proposed and compared schemes for different caching job executions is visualized in Fig. 7(a). It can be noticed from Fig. 7(a) that the service provider’s profit increases with a higher number of caching job requests. From Fig. 7(a), it can be shown that the proposed trailblazer scheme performs well in terms of higher service provider profit than both schemes one and two. The reason behind this is that by incorporating the efficient timeslot and resource scheduling policy, the proposed scheme reduces the waiting latency during caching job request execution. Thus, the service provider cost is minimum and profit is maximum in the proposed trailblazer scheme. Whereas, the compared scheme one suffers from the second highest waiting latency, and the compared scheme two experiences the highest waiting latency. Thus, the service provider cost is the second minimum in the compared scheme one and the maximum in the compared scheme two. Due to this higher service provider cost than the proposed scheme, the service provider profit is second highest in the compared scheme one and lowest in the compared scheme two. For example, in Fig. 7(a), when the number of caching jobs is 125, the service provider profit for the proposed trailblazer scheme, compared to scheme one, and compared scheme two are 408 USD, 318 USD, and 270 USD, respectively.

The user device survivability ratio results for both the proposed trailblazer scheme and the compared scheme by varying the simulation round are shown in Fig. 7(b). The user-device survivability ratio is obtained by taking the ratio of the live user device number after each simulation round and the total number of user devices. From Fig. 7(b), it can be seen that under different simulation rounds, the user device survivability ratio of the proposed trailblazer scheme is always the highest, followed by comparing scheme one, and comparing scheme two at last. As the simulation round number increases, the user-device survivability ratio decreases gradually in all compared schemes. However, due to the lowest amount of user device-based consumed energy value for requested caching job execution, the proposed trailblazer scheme experiences the highest number of user device survivability ratios among others. Whereas, the compared schemes one and two suffer from the second and highest amount of consumed energy for caching job execution, respectively. Thus, the user device survivability ratio values for compared schemes one and two are the second best and worst among all compared schemes, respectively. For reference, in Fig. 7(b), when the number of simulation rounds is 1500, the user device survivability ratios for the proposed trailblazer scheme, compared to scheme one, and compared scheme two are 25 percent, 13 percent, and 6 percent, respectively.

Figure 7(c) visualizes the overall user welfare value results for both trailblazer schemes and compared schemes. It can be seen from Fig. 7(c) that the overall user welfare value for caching job execution increases with the increasing caching job amount value in all compared schemes. The user welfare value includes not only the content retrieval time welfare value but also both the energy welfare value and the financial cost welfare value. The results in Fig. 7(c) hint that the proposed trailblazer scheme outperforms both compared schemes one and two in terms of higher user welfare value. The reason is that the proposed trailblazer scheme (with proactive precaching-based content delivery, collaboration among neighbors, earliest deadline-based timeslot scheduling, lowest predicted delay-based server or cache selection, and usage of both user-owned cache and service provider cache) achieves a higher amount of content retrieval time latency gain, higher consumed energy gain, and user financial cost gain in comparison with both compared scheme one and two. The figure also notifies that the compared scheme two achieves the lowest amount of user welfare value due to their lowest amount of content retrieval time latency gain, higher consumed energy gain, and user financial cost gain in comparison with both proposed schemes and compared scheme one. For example, in Fig. 7(c), when the number of publish-subscriber caching jobs is one hundred, the user’s welfare value for the proposed trailblazer scheme, compared scheme one, and compared scheme two are 2.87, 1.40, and 1.08, respectively.

Table 3

Experimental results comparison for total caching job 125.

Scheme name	Mean content retrieval latency	Throughput ratio	Service financial cost (users)	Users consumed energy	Service provider profit
Compared first (GCD+NPC+NC+NUOC+fifo) scheme (Silva et al. [77])	10536 ms	297 Kbps	3095 USD	658 mJ	318 USD
Compared second (RCD+NPC+NC+NUOC+random) scheme (Ni et al. [65])	13640 ms	285 Kbps	3214 USD	736 mJ	270 USD
Compared third (NSS+NUOC+NPC+NC+shortest job first) scheme (Cai et al. [14])	11704 ms	292 Kbps	3135 USD	680 mJ	303 USD
Compared fourth (HPS+NUOC+NPC+NC+longest job first) scheme (Abdullahi et al. [1])	12520 ms	288 Kbps	3187 USD	711 mJ	282 USD
Proposed trailblazer (WPCD+PBA+WUC+LRU) scheme	5712 ms	315 Kbps	2206 USD	566 mJ	408 USD

5.1. Comprehensive comparison among different job scheduling techniques

Table 3 depicts the comparison results among different scheduling schemes with our proposed trailblazer scheme. The existing schemes are compared scheme (GCD+NPC+NC+NUOC+fifo) one (e.g., Silva et al. [77]), compared scheme (RCD+NPC+NC+NUOC+random) two (e.g., Ni et al. [65], Naeem et al. [60]), compared scheme three (NSS+NUOC+NPC+NC+shortest job first) three (e.g., Cai et al. [14]), and compared scheme (HPS+NUOC+NPC+NC+longest job first) four (e.g., Abdullahi et al. [1]). From the Table 3 results, it can be seen that the proposed trailblazer scheme gains better mean content retrieval latency, throughput ratio, user service access financial cost, consumed energy of users, and service provider profit than the other four state-of-the art schemes. The compared schemes one (GCD+NPC+NC+NUOC+fifo), two (RCD+NPC+NC+NUOC+random), three (NSS+NUOC+NPC+NC+shortest job first), and four (HPS+NUOC+NPC+NC+longest job first) secure the second, fifth, third, and fourth positions, respectively, for the evaluated content retrieval delay, throughput, user financial cost, consumed energy, and service provider profit results.

The crucial reason behind such results is that the proposed trailblazer scheme relies on proactive pre-caching service (WPCD), highest profit-based caching server access (PBA), and both user-retained and service provider-retained cache servers for caching job execution (WUC). The proposed trailblazer scheme provides minimum predicted content retrieval delay, maximum welfare, and a low job deadline first-based resource scheduling policy for both subscriber- and publisher-based caching job execution. Thus, the caching job execution related latencies (workload processing delay, communication latency, and waiting latencies), consumer energy cost, and financial cost are minimal in the proposed trailblazer scheme. Whereas, all four compared schemes rely on only a service provider-owned cache without any user-owned cache (NUOC) for caching job execution. Differing from the proposed trailblazer scheme, they also did not include collaboration among cache servers (NC) and proactive pre-caching policies (NPC). For job scheduling, the compared schemes one, two, three, and four rely on fifo, random, shortest job first, and longest job first-based scheduling policies, respectively.

Moreover, the compared scheme one relies on greedy-based caching server selection without looking into all communication, waiting, and computation delays. Due to these reasons, the waiting delay for resources is much longer in compared scheme one than in the proposed scheme. The caching server selection process in compared scheme two is random, thus suffering from worse content retrieval delay, throughput, user financial cost, consumed energy, and service provider profit results. The compared scheme 3 relies on nearby server-first (NSS)-based caching server selection. Thus, they can provide better communication delays. However, the computation workload and waiting delays are higher (third highest) in the compared scheme three. The compared scheme 4 relies on a highly powerful cache server-based resource selection policy (HPS). Thus, the communication and waiting delays are the fourth highest in the compared scheme 4 among all compared schemes.

Table 3 examines that for the caching job number of 125, the mean content retrieval latency in the proposed trailblazer scheme, compared scheme one, compared scheme two, compared scheme three, and compared scheme four are 5712 ms, 10536 ms, 13640 ms, 11704 ms, and 12520 ms, respectively. Table 3 also notifies that for the caching job number of 125, the service financial cost for users in the proposed trailblazer scheme, compared scheme one, compared scheme two, compared scheme three, and compared scheme four are 2206 USD, 3095 USD, 3214 USD, 3135 USD, and 3187 USD, respectively. Table 3 results also hinted that for the same amount of 125 job execution, the energy cost for users in the proposed trailblazer scheme, compared scheme one, compared scheme two, compared scheme three, and compared scheme four are 566 mJ, 658 mJ, 736 mJ, 680 mJ, and 711 mJ, respectively. Thus, from the above discussions, it can be concluded that the proposed trailblazer scheme can provide better delay, energy, and financial cost gain than other compared schemes.

6. Conclusion

This article inaugurates a proactive pre-caching, blockchain, minimum content retrieval latency, and minimum energy cost-aware resource orchestration scheme for publisher-subscriber-based 6G information-centric networks by taking different caching job requests, user-owned and service provider-owned cache and server resources, different job execution deadlines, and communication link resources into account. This article also integrates a caching job scheduling policy and an appropriate caching node selection scheme (for caching content access and publishing) by taking both the publisher’s caching job and subscribers’ caching job requests, the earliest deadline of the caching job requests, and the minimum predicted caching content retrieval latency into account. To illustrate the working sequence of different phases associated with caching job execution, this paper gives a job execution sequence diagram by taking into account the network setup phase, cache search, job scheduling phase, and caching job final job execution phase. This paper also provides a unique network model for 6G ICN services by taking into account different types of communication links, different types of user devices (robot, vehicle, AR/VR), blockchain and MEC services, local and remote cache servers, and wired and wireless communication technologies. To analyze the performance of the proposed trailblazer scheme, this article provides a mathematical model that includes content retrieval delay, local cache and server hit ratio, stretch ratio, users’ total consumed energy, the financial cost of users, job execution success ratio, throughput value, user survivability ratio, user total welfare value, and service provider profit performance metrics. To exhibit the benefits of the proposed Trailblazer scheme, this article gives simulation results of the proposed scheme in comparison with existing scheme one (greedy content caching server selection, FiFo-based caching, no precaching, and collaboration) and existing scheme two (randomly based content caching server selection, no precaching, and collaboration, whimsical caching policy). The experimental results visualize that for the caching job of one hundred and twenty-five, the proposed trailblazer scheme offers 16% mean caching content retrieval delay gain and 66% users consumed energy gain than the existing scheme one policy (GCD+NPC+NC+NUOC+fifo). The experimental reveals that for the caching job of one hundred and twenty-five, the proposed trailblazer scheme offers 30% mean caching content retrieval delay gain and 112% users consumed energy gain than the existing scheme two policy (RCD+NPC+NC+NUOC+random). For the one hundred and twenty-five caching jobs, the proposed trailblazer scheme gives 16% and 23% more job execution success ratio than the existing scheme one and existing scheme two policies, respectively. However, for the same amount of caching job amount, the proposed trailblazer scheme produces 22% and 33% more service provider profit than the existing scheme one and existing scheme two policies, respectively.

However, some research challenges are out of the scope of this work and can be considered as future extensions of the proposed work, such as the inclusion of other 6G applications along with the caching job execution for 6G ICN networks. Moreover, a machine learning-based predictive resource allocation scheme can be investigated for 6G ICN networks by taking into account both IP and ICN networks. If the number of users is very high, our system may require more user-owned cache along with service provider cache to satisfy the caching job requirements and get better delay gains. Moreover, the performance analysis with the cache missing issue with the cost factor would be investigated in the future. Different challenging issues, like users with diverse requirements and a higher number of users with limited cache servers, need to be investigated in the future. In addition, deep reinforcement learning (DRL), game theory, federated learning-based security threat identification, suitable caching server or local cache selection with maximized profit for service providers and users, and cache server failure identification can be investigated for the publisher-subscriber-based 6G ICN networks.

Footnotes

Conflict of interest

The authors have no conflict of interest to report.

References

Abdullahi

et al., Scheduling criteria evaluation with longer job first in information centric network, in: Emerging Trends in Intelligent Computing and Informatics, Advances in Intelligent Systems and Computing, Vol. 1073, Springer, Cham, 2020, pp. 604–614.

Ahlgren

et al., A survey of information-centric networking, IEEE Commun. Mag. 50(7) (2012), 26–36. doi:https://doi.org/10.1109/MCOM.2012.6231276.

Amadeo

et al., Iot data processing at the edge with named data networking, in: European Wireless 2018; 24th European Wireless Conference, VDE, 2018, pp. 1–6.

Amadeo

et al., Popularity-aware closeness based caching in NDN edge networks, Sensors 2022 22(9) (2020), 3460. doi:https://doi.org/10.3390/s22093460.

Amreen

Ms.

et al., Performance evaluation in cloud computing model using queuing models, International Journal of Grid and Distributed Computing 10(3) (2017), 15–24. doi:https://doi.org/10.14257/ijgdc.2017.10.3.02.

Araldo

et al., Cost-aware caching: Optimizing cache provisioning and object placement in ICN, in: Proc. IEEE Global Commun. Conf. (GLOBECOM), Austin, TX, USA, Dec. 2014, 2014, pp. 1108–1113.

Arshad

et al., Recent advances in information-centric networking-based Internet of things (icn-iot), IEEE Internet of Things Journal 6(2) (2018), 2128–2158. doi:https://doi.org/10.1109/JIOT.2018.2873343.

Asadi

et al., A survey on device-to-device communication in cellular networks, IEEE Commun. Surveys Tuts. 16(4) (2014), 1801–1819. doi:https://doi.org/10.1109/COMST.2014.2319555.

Asmat

et al., Energy-efficient centrally controlled caching contents for information-centric Internet of things, IEEE Access 8 (2020), 126358–126369. doi:https://doi.org/10.1109/ACCESS.2020.3008193.

10.

Banerjee

et al., Greedy caching: An optimized content placement strategy for information-centric networks, Comput. Netw. 140 (2018), 78–91. doi:https://doi.org/10.1016/j.comnet.2018.05.001.

11.

Ben-Ammar

et al., A versatile Markov chain model for the performance analysis of CCN caching systems, in: IEEE Global Communications Conference, Dec. 2018, 2018, pp. 1–6.

12.

Ben-Ammar

et al., A GRASP-based approach for dynamic cache resources placement in future networks, Journal of Network and Systems Management (2020), 1–21.

13.

Ben-Ammar

et al., An ICN-based approach for service caching in edge/fog environments, in: IEEE Global Communications Conference, Taipei, Taiwan, 2020, pp. 1–6. doi:https://doi.org/10.1109/GLOBECOM42002.2020.9322305.

14.

Cai

et al., Software defined status aware routing in content-centric networking, in: 2018 International Conference on Information Networking (ICOIN), Chiang Mai, Thailand, 2018, pp. 283–288. doi:https://doi.org/10.1109/ICOIN.2018.8343126.

15.

Casetti

et al., Content-centric routing in Wi-Fi direct multi-group networks, in: Proc. IEEE 16th Int. Symp. World Wireless, Mobile Multimedia Netw. (WoWMoM), Jun. 2015, 2015, pp. 1–9.

16.

Chen

et al., Dependency-aware computation offloading for mobile edge computing with edge-cloud cooperation, IEEE Trans. Cloud Comput. 99(01) (2020), 2451–2468.

17.

Chen

et al., Energy-aware fast interest forwarding for multimedia streaming over ICN 5G-D2D, in: Proc. Int. Conf. Image Graph., Sep. 2017, Springer, Cham, Switzerland, 2017, pp. 353–365. doi:https://doi.org/10.1007/978-3-319-71589-6_31.

18.

Chowdhury

et al., Kaizen: A street smart low latency-aware resource choreography scheme for decentralized autonomous organization (DAO) and non-DAO based application execution over blockchain and MEC empowered 6 G network, International Journal of Networked and Distributed Computing, 2024, 1–29. doi:https://doi.org/10.1007/s44227-024-00033-0.

19.

Chowdhury

M.H.

et al., Accelerator: An intent-based intelligent resource-slicing scheme for SFC-based 6G application execution over SDN- and NFV-empowered zero-touch network, Frontiers in Communications and Networks 5(1385656) (2024), 1–27. doi:https://doi.org/10.3389/frcmn.2024.1385656.

20.

Cui

X.-D.

et al., Design of in-network caching scheme in CCN based on grey relational analysis, J. China Universities Posts Telecommun. 21(2) (2014), 1–8. doi:https://doi.org/10.1016/S1005-8885(14)60279-X.

21.

Dannewitz

et al., Network of information (NetInf) – an information-centric networking architecture, Comput. Commun. 36(7) (2013), 721–735. doi:https://doi.org/10.1016/j.comcom.2013.01.009.

22.

Djama

et al., Information-centric networking solutions for the Internet of things: A systematic mapping review, Computer Communications 159(1) (2020), 37–59. doi:https://doi.org/10.1016/j.comcom.2020.05.003.

23.

Domingues

et al., Enabling opportunistic search and placement in cache networks, Comput. Netw. 119 (2017), 17–34. doi:https://doi.org/10.1016/j.comnet.2017.03.005.

24.

Drolia

et al., Cachier: Edge-caching for recognition applications, in: Proc. IEEE ICDCS, 2021, pp. 276–286. arxiv preprint.

25.

Duan

et al., A collaborative pricing framework for in-network caching in information-centric networking, IEEE Access 6 (2018), 40485–40493. doi:https://doi.org/10.1109/ACCESS.2018.2849103.

26.

Elsmany

et al., EESRA: Energy efficient scalable routing algorithm for wireless sensor networks, IEEE Access 7 (2019), 96974–96983. doi:https://doi.org/10.1109/ACCESS.2019.2929578.

27.

Fan

et al., Optimal design of hierarchical cloud-fog and edge computing networks with caching, Sensors 20(1582) (2020), 1–16. doi:https://doi.org/10.3390/s20061582.

28.

Fang

et al., A survey of green information-centric networking: Research issues and challenges, IEEE Communications Surveys and Tutorials 17(3) (2015), 1455–1472. doi:https://doi.org/10.1109/COMST.2015.2394307.

29.

Fayyaz

et al., Information-centric mobile networks: A survey, discussion, and future research directions, IEEE Access, 11 (2023), 40328–40372. doi:https://doi.org/10.1109/ACCESS.2023.3268775.

30.

Gitnux blog, https://blog.gitnux.com/internet-traffic-statistics/, last accessed on June 2023, 2023.

31.

Grewe

et al., A domain-specific comparison of information-centric networking architectures for connected vehicles, IEEE Commun. Surveys Tuts. 20(3) (2018), 2372–2388. doi:https://doi.org/10.1109/COMST.2018.2817653.

32.

Gui

et al., A cache placement strategy based on compound popularity in named data networking, IEEE Access 8 (2020), 196002–196012. doi:https://doi.org/10.1109/ACCESS.2020.3034329.

33.

Gupta

et al., Edge caching based on collaborative filtering for heterogeneous ICN-IoT applications, Sensors (Basel) 21(16) (2021), 5491. doi:https://doi.org/10.3390/s21165491.

34.

Hahm

et al., Low-power Internet of things with ndn and cooperative caching, in: Proceedings of the 4th ACM Conference on Information Centric Networking, 2017, pp. 98–108. doi:https://doi.org/10.1145/3125719.3125732.

35.

Hajimirsadeghi

et al., Joint caching and pricing strategies for popular content in information centric networks, IEEE Journal on Selected Areas in Communications 35(3) (2017), 654–667. doi:https://doi.org/10.1109/JSAC.2017.2672161.

36.

Hao

et al., Cognitive-caching: Cognitive wireless mobile caching by learning fine-grained caching-aware indicators, IEEE Wireless Communications 27(1) (2020), 100–106. doi:https://doi.org/10.1109/MWC.001.1900273.

37.

et al., Resource allocation in software-defined and information-centric vehicular networks with mobile edge computing, in: IEEE 86th Vehicular Technology Conference (VTC-Fall), Toronto, ON, Canada, 2017, pp. 1–5. doi:https://doi.org/10.1109/VTCFall.2017.8288203.

38.

Hoang

D.T.

et al., A dynamic edge caching framework for mobile 5G networks, IEEE Wireless Commun. 25(5) (2018), 95–103. doi:https://doi.org/10.1109/MWC.2018.1700360.

39.

Islam

H.M.A.

et al., Boosting the performance of content centric networking using delay tolerant networking mechanisms, IEEE Access 5 (2017), 23858–23870. doi:https://doi.org/10.1109/ACCESS.2017.2765379.

40.

Jacobson

et al., Networking named content, in: Proc. 5th Int. Conf. Emerg. Netw. Experim. Technol., 2009, pp. 1–12.

41.

Jeong

H.J.

et al., Lightweight offloading system for mobile edge computing, in: Proceedings of the IEEE PerCom Workshops, Kyoto, Japan, 11–15 March 2019, 2019, pp. 451–452.

42.

et al., Energy-efficient computation offloading in mobile edge computing systems with uncertainties, IEEE Trans. Wirel. Commun. 21 (2022), 5717–5729. doi:https://doi.org/10.1109/TWC.2022.3142685.

43.

Jmal

et al., An OpenFlow architecture for managing content-centric-network (OFAM-CCN) based on popularity caching strategy, Comput. Stand. Inter. 51 (2017), 22–29. doi:https://doi.org/10.1016/j.csi.2016.10.016.

44.

Khan

et al., Priority-based content dissemination in content centric vehicular networks, in: 2nd IEEE Advanced Information Management, Communicates, Electronic and Automation Control Conference (IMCEC), Xi’an, China, 2018, pp. 2005–2009. doi:https://doi.org/10.1109/IMCEC.2018.8469332.

45.

Khelifi

et al., Named data networking in vehicular ad hoc networks: Stateof-the-art and challenges, IEEE Commun. Surveys Tuts. 22(1) (2020), 320–351. doi:https://doi.org/10.1109/COMST.2019.2894816.

46.

Krolikowski

et al., Optimal cache leasing from a mobile network operator to a content provider, in: Proc. IEEE INFOCOM, 2018, pp. 2744–2752.

47.

Lal

K.N.

et al., A centrality-measures based caching scheme for content-centric networking (CCN), Multimedia Tools Appl. 77(14) (2018), 17625–17642. doi:https://doi.org/10.1007/s11042-017-5183-y.

48.

et al., RBC-CC: RBC-based cascade caching scheme for content centric networking, J. Netw. Syst. Manage. 25(2) (2017), 375–396. doi:https://doi.org/10.1007/s10922-016-9394-8.

49.

Liao

et al., Information-centric massive IoT-based ubiquitous connected VR/AR in 6G: A proposed caching consensus approach, IEEE Internet of Things Journal 8(7) (2021), 5172–5184. doi:https://doi.org/10.1109/JIOT.2020.3030718.

50.

Liu

et al., Caching at the wireless edge: Design aspects, challenges, and future directions, IEEE Commun. Mag. 54(9) (2016), 22–28.

51.

Liu

et al., Video stream distribution scheme based on edge computing network and user interest content model, IEEE Access 8 (2020), 30734–30744. doi:https://doi.org/10.1109/ACCESS.2020.2971025.

52.

Liu

W.-X.

et al., Content popularity prediction and caching for ICN: A deep learning approach with SDN, IEEE access 6 (2018), 5075–5089.

53.

Liu

et al., Collaborative task offloading and service caching strategy for mobile edge computing, Sensors 22(6760) (2022), 1–18. doi:https://doi.org/10.3390/s22186760.

54.

Mastorakis

et al., nTorrent: Peer-to-peer file sharing in named data networking, in: 26th International Conference on Computer Communication and Networks (ICCCN), 2017, pp. 1–10.

55.

Mastorakis

et al., Peer-to-peer data sharing in named data networking, Ph.D. thesis, UCLA, 2019.

56.

Mastorakis

et al., ICedge: When edge computing meets information-centric networking, IEEE Internet of Things Journal 7(5) (2020), 4203–4217. doi:https://doi.org/10.1109/JIOT.2020.2966924.

57.

Meddeb

et al., How to cache in icn-based iot environments?, in: 2017 IEEE/ACS 14th International Conference on Computer Systems and Applications (AICCSA), 2017, pp. 1117–1124.

58.

Moeng

et al., Weighted-tuple: Fast and accurate synchronization for parallel architecture simulators, IEEE Transactions on Parallel and Distributed Systems 27(8) (2015), 2462–2474. doi:https://doi.org/10.1109/TPDS.2015.2494589.

59.

Mtibaa

et al., Towards edge computing over named data networking, in: IEEE International Conference on Edge Computing (EDGE), 2018, pp. 117–120. doi:https://doi.org/10.1109/EDGE.2018.00023.

60.

Naeem

M.A.

et al., Performances of probabilistic caching strategies in content centric networking, IEEE Access 6 (2018), 58807–58825. doi:https://doi.org/10.1109/ACCESS.2018.2872614.

61.

Naeem

M.A.

et al., A periodic caching strategy solution for the smart city in informationcentric Internet of things, Sustainability 10(7) (2018), 2576. doi:https://doi.org/10.3390/su10072576.

62.

Naeem

M.A.

et al., A comparative performance analysis of popularity-based caching strategies in named data networking, IEEE Access 8 (2020), 50057–50077. doi:https://doi.org/10.1109/ACCESS.2020.2980385.

63.

Naeem

M.A.

et al., Caching content on the network layer: A performance analysis of caching schemes in ICN-based Internet of things, IEEE Internet of Things Journal 9(9) (2022), 6477–6495. doi:https://doi.org/10.1109/JIOT.2021.3110977.

64.

Nguyen

Q.N.

et al., A context-aware green information-centric networking model for future wireless communications, IEEE Access 6 (2018), 22804–22816. doi:https://doi.org/10.1109/ACCESS.2018.2828462.

65.

et al., An ICN-based on-path computing resource scheduling architecture with user preference awareness for computing network, Electronics 13(5) (2024).

66.

Pfender

et al., Content delivery latency of caching strategies for information-centric IoT, 2019, 1–10. arxiv preprint.

67.

Qin

et al., Service prioritization in information centric networking with heterogeneous content providers, IEEE Transactions on Network and Service Management 18(4) (2021), 4476–4488. doi:https://doi.org/10.1109/TNSM.2021.3105198.

68.

Quan

et al., ICN based vehicle-to-cloud delivery for multimedia streaming in urban vehicular networks, China Commun. 13(9) (2016), 103–112. doi:https://doi.org/10.1109/CC.2016.7582302.

69.

Rahim

et al., An intelligent content caching protocol for connected vehicles, Trans Emerging Tel Tech. 32(4) (2021), 1–14.

70.

Ravindran

et al., 5G-ICN: Delivering ICN services over 5G using network slicing, IEEE Commun. Mag. 55(5) (2017), 101–107. doi:https://doi.org/10.1109/MCOM.2017.1600938.

71.

Rehman

R.A.

et al., LOMCF: Forwarding and caching in named data networking based MANETs, IEEE Transactions on Vehicular Technology 66(10) (2017), 9350–9364. doi:https://doi.org/10.1109/TVT.2017.2700335.

72.

Ren

et al., Collaborative cloud and edge computing for latency minimization, IEEE Trans. Veh. Technol. 68 (2019), 5031–5044. doi:https://doi.org/10.1109/TVT.2019.2904244.

73.

Riya

Ms.

et al., Efficient caching method in fog computing for Internet of everything, Peer-to-Peer Netw. Appl. 14 (2021), 439–452. doi:https://doi.org/10.1007/s12083-020-00952-z.

74.

Serhane

et al., A survey of ICN content naming and in-network caching in 5G and beyond networks, IEEE Internet of Things Journal 8(6) (2021), 4081–4104. doi:https://doi.org/10.1109/JIOT.2020.3022243.

75.

Sfiligoi

et al., Managing cloud networking costs for data-intensive applications by provisioning dedicated network links, Practice and Experience in Advanced Research Computing (PEARC) (2021), 1–8.

76.

Shojafar

et al., Adaptive computing-plus-communication optimization framework for multimedia processing in cloud systems, IEEE Trans. Cloud Comput. 8(4) (2020), 1162–1175. doi:https://doi.org/10.1109/TCC.2016.2617367.

77.

Silva

et al., NDN content store and caching policies: Performance evaluation, Computers, MDPI 11(37) (2022), 1–17.

78.

Sourlas

et al., Efficient hash-routing and domain clustering techniques for information-centric networks, Comput. Netw. 103 (2016), 67–83. doi:https://doi.org/10.1016/j.comnet.2016.04.001.

79.

Sun

et al., Delay analysis and optimization in cache-enabled multi-cell cooperative networks, in: Global Communications Conference (GLOBECOM), 2016, pp. 1–7.

80.

Tariq

et al., A speculative study on 6G, IEEE Wireless Communications 27(4) (2020), 118–125. doi:https://doi.org/10.1109/MWC.001.1900488.

81.

Thar

et al., Online caching and cooperative forwarding in information centric networking, IEEE Access 6 (2018), 59679–59694. doi:https://doi.org/10.1109/ACCESS.2018.2874448.

82.

Tran

T.D.

et al., Joint resource allocation and content caching in virtualized content-centric wireless networks, IEEE Access 6 (2018), 11329–11341. doi:https://doi.org/10.1109/ACCESS.2018.2804902.

83.

Tran

T.X.

et al., Joint task offloading and resource allocation for multi-server mobile-edge computing networks, IEEE Trans. Veh. Technol. 68 (2019), 856–868. doi:https://doi.org/10.1109/TVT.2018.2881191.

84.

Ullah

et al., Icn with edge for 5g: Exploiting in-network caching in icn based edge computing for 5g networks, Future Generation Computer Systems 111 (2020), 159–174. doi:https://doi.org/10.1016/j.future.2020.04.033.

85.

Ullah

et al., Management of scalable video streaming in information centric networking, Multimedia Tools Appl. 76(20) (2017), 21519–21546. doi:https://doi.org/10.1007/s11042-016-4008-8.

86.

Ullah

et al., Robust and efficient energy harvested-aware routing protocol with clustering approach in body area networks, IEEE Access 7 (2018), 33906–33921. doi:https://doi.org/10.1109/ACCESS.2019.2904322.

87.

Wang

et al., When sensor-cloud meets mobile edge computing, Sensors 19(5324) (2019), 1–17.

88.

Wang

et al., Edge caching at base stations with device-to-device offloading, IEEE Access 5 (2017), 6399–6410. doi:https://doi.org/10.1109/ACCESS.2017.2679198.

89.

et al., Could end system caching and cooperation replace in-network caching in CCN?, ACM SIGCOMM Comput. Commun. Rev. 45(4) (2015), 101–102. doi:https://doi.org/10.1145/2829988.2790006.

90.

Xia

et al., TSLS: Time sensitive, lightweight and secure access control for information centric networking, in: IEEE Global Communications Conference (GLOBECOM), Waikoloa, HI, USA, 2019, pp. 1–6. doi:https://doi.org/10.1109/GLOBECOM38437.2019.9014220.

91.

Xiao

et al., Security in mobile edge caching with reinforcement learning, IEEE Wireless Commun. 25(3) (2018), 116–122. doi:https://doi.org/10.1109/MWC.2018.1700291.

92.

Xing

et al., Collaborative content distribution with an end-to-end caching framework, IEEE Access, 8 (2020), 54345–54360. doi:https://doi.org/10.1109/ACCESS.2020.2981665.

93.

Xing

et al., Collaborative content distribution in 5G mobile networks with edge caching, in: Proc. ICC – IEEE Int. Conf. Commun. (ICC), 2021, pp. 1–6.

94.

et al., Optimal information centric caching in 5g device-to-device communications, IEEE Trans. Mobile Comput. 17(9) (2018), 2114–2126. doi:https://doi.org/10.1109/TMC.2018.2794970.

95.

et al., Powering smart homes with information-centric networking, IEEE Communications Magazine 57(6) (2019), 40–46. doi:https://doi.org/10.1109/MCOM.2019.1800732.

96.

et al., Distributed caching via rewarding: An incentive caching model for ICN, in: Proc. IEEE Global Commun. Conf. (GLOBECOM), Singapore, Dec. 2017, 2017, pp. 1–6.

97.

Xylomenos

et al., A survey of information-centric networking research, IEEE Commun. Surveys Tuts. 16(2) (2014), 1024–1049. doi:https://doi.org/10.1109/SURV.2013.070813.00063.

98.

Yang

et al., Content popularity prediction towards location-aware mobile edge caching, IEEE Trans. Multimedia 21(4) (2019), 915–929. doi:https://doi.org/10.1109/TMM.2018.2870521.

99.

Yang

et al., MEETS: Maximal energy efficient task scheduling in homogeneous fog networks, IEEE IoT Journal 5(5) (2018), 4076–4087.

100.

Zhang

et al., Cost-effective cache deployment in mobile heterogeneous networks, IEEE Trans. Veh. Technol. 66(12) (2017), 11264–11276. doi:https://doi.org/10.1109/TVT.2017.2724547.

101.

Zhang

et al., Cache space efficient caching scheme for content–centric mobile ad hoc networks, IEEE Syst. J. 13(1) (2019), 530–541.

102.

Zhang

et al., Content-centric mobile edge caching, IEEE Access 8 (2020), 11722–11731. doi:https://doi.org/10.1109/ACCESS.2019.2962856.

103.

Zhang

et al., Scalable video caching for information centric wireless networks, IEEE Access 8 (2020), 77272–77284. doi:https://doi.org/10.1109/ACCESS.2020.2989532.

104.

Zhang

et al., An SDN based caching decision policy for video caching in information-centric networking, IEEE Trans. Multimedia 22(4) (2020), 1069–1083. doi:https://doi.org/10.1109/TMM.2019.2935683.

105.

Zhang

et al., Smart proactive caching: Empower the video delivery for autonomous vehicles in ICN based networks, IEEE Trans. Veh. Technol. 69(7) (2020), 7955–7965. doi:https://doi.org/10.1109/TVT.2020.2994181.

106.

Zheng

et al., SWIPT-aware fog information processing: Local computing vs. fog offloading, Sensors 18(3291) (2018), 1–16.

107.

Zhou

et al., An ant colony inspired cache allocation mechanism for heterogeneous information centric network, IEEE Access 9 (2021), 55485–55496. doi:https://doi.org/10.1109/ACCESS.2021.3071734.

108.

Zhou

et al., Resource allocation for information-centric virtualized heterogeneous networks with in-network caching and mobile edge computing, IEEE Transactions on Vehicular Technology 66(12) (2017), 11339–11351. doi:https://doi.org/10.1109/TVT.2017.2737028.