HRCD: A Hybrid Replica Method Based on Community Division Under Edge Computing

Abstract

With the emergence of Industry 5.0 and explosive data growth, replica allocation has become a critical issue in edge computing systems. Current methods often focus on placing replicas on edge servers near terminals, yet this may lead to edge node overload and system performance degradation, especially in large 6G edge computing communities. Meanwhile, existing terminal-based strategies struggle due to their time-varying nature. To address these challenges, we propose the HRCD, a hybrid replica method based on community division. The HRCD first divides time-varying terminals into stable sets using the community division algorithm. Then, it employs fuzzy clustering analysis to select terminals with strong service capabilities for replica placement while utilizing uniform distribution to prioritize geographically local hotspot data as replica data. Extensive experiments demonstrate that the HRCD effectively reduces data access latency and decreases edge server load compared to other replica strategies. Overall, the HRCD offers a promising approach to optimizing replica placement in 6G edge computing environments.

1. Introduction

With the continuous advancement of information technology and the widespread application of the Internet of Things (IoT) and big data, digitization and intelligence have become important trends in the development of the manufacturing industry. The European Commission put forward the concept of Industry 5.0 in 2021, aiming to promote the sustainable development of the manufacturing industry through technological innovation and industrial upgrading [1]. In terms of technology, Industry 5.0 will integrate various advanced technologies, such as artificial intelligence, Internet of Things (IoT), big data analysis, cloud computing, and others, to form an efficient and synergistic industrial ecosystem [1]. Although 5G communication technology has driven the widespread application of technologies such as artificial intelligence in the manufacturing industry, enabling the digitization and networking of production processes, it has certain limitations in certain aspects, such as network intelligence and stronger communication capabilities, which prevent it from fully meeting the requirements of Industry 5.0 [2,3]. To meet Industry 5.0, the sixth-generation networks (6G) have garnered attention from the industrial and academic communities.

Regarding 6G networks, many scholars believe that the future 6G networks will primarily evolve in two directions [2,3,4,5,6,7], first, leveraging wireless signals from ground, air, and satellite equipment to build a globally connected network, and second, providing ubiquitous artificial intelligence and services. To ensure the evolution of 6G in these two directions, edge computing under 6G (6G Edge for short) has become a research hotspot in recent years [6,8,9]. Edge computing is a distributed computing architecture that transforms large-scale services originally processed entirely by central nodes into distributed edge nodes [2,5,6]. Under 6G Edge, smartphones will still be used in 6G [2,3,4]. They will also become an important component of terminal devices. The edge servers are distributed in different geographical areas. The edge infrastructure provider (EIP) can deploy edge servers equipped with small-scale cloud-like computing resources at base stations and access points in close proximity to end-users [10]. Based on the pay-as-you-go pricing model, app vendors can hire resources on edge servers in a specific geographical area for hosting applications [11] or caching popular data [12,13] to serve their users in areas with low latency. App vendors hire resources on edge servers for caching data to serve their users within the edge servers’ coverage areas [14,15]. The distributed setup brings many beneficial functions to edge computing, such as low latency and mobility [8]. In this way, end-users’ increasingly stringent latency requirements can be fulfilled [16]. Many scholars believe that 6G Edge will achieve significant breakthroughs in areas such as Industry 5.0, autonomous mobility, etc. [2,3,4,5,6,7,8].

The pay-as-you-go pricing model is a commonly used consumption pattern in Edge [3,4,5]. This consumption pattern is also a common model for utilizing 6G edge computing services in large communities. Personnel concentration and the diversification of User Equipment (UE for short) are fundamental characteristics of large communities. To enhance the Quality of Service (QoS) for users of large communities, the EIP needs to deploy more base stations. While the adoption of 6G communication technology can effectively mitigate the issue of mutual interference among multiple base stations [17,18], the concentration of people and the diversity of devices also pose new challenges for the pay-as-you-go consumption model. Firstly, the vast amount of communication data involved in edge computing, coupled with the diversity of devices, exerts tremendous service pressure on the edge [2,3,4,6]. Secondly, UE is usually carried by users, and their locations dynamically change as users move. UE needs to access the network from different access points to improve their QoS, which undoubtedly increases the communication burden of the edge node.

The multi-replica technology can effectively alleviate the issue of excessive service pressure in the context of 6G Edge [1,2,3,4,5,6,7,17,18]. Typically, these methods involve deploying replicas on edge devices situated close to UE [10,11,12,13,14,15,16]. In large communities characterized by high personnel density, the service pressure on edge nodes remains notably elevated. Compared to Edge Service nodes (ESs for short), UE is situated closer to the data access points. By placing replicas on UE, we can not only diminish the burden on ESs but also further curtail data access latency. With the burgeoning maturity of Device-to-Device (D2D for short) communication technology, UE participation in edge services has garnered increasing attention from scholars [19,20]. However, this approach also confronts a multitude of challenges, primarily manifested as follows.

(1) The question arises regarding which UE should be served by which replicas. In Edge, replicas are positioned on ESs that are proximal and stationary relative to UE, offering data access services to UE within their communication radius. Consequently, the service target of replicas on ESs remains consistent. In contrast, the position of UE in large communities is dynamically fluid. When replicas are hosted on UE, it becomes challenging to ascertain which replicas cater to which UE. (2) The issue of replica placement location emerges. ESs possess superior service capabilities and are typically situated at the network topology’s “exit” points in Edge. Consequently, selecting ESs as the replica deployment node can enhance replica hit rates. However, in large communities, UE positions are time-varying, and the network topology is also dynamically evolving. (3) The problem of selecting data for replica creation is as follows. Data accessed by geographically dispersed users exhibits a geographical locality pattern [21,22,23]. To fulfill the data access requirements of various geographical units, traditional replica placement methodologies typically select “hotspot” data of specific types as replicas (hotspot data denotes data that has been frequently requested per unit time). However, in Edge, UE is time-varying and may be situated in diverse geographical units at different times, rendering it difficult to measure the hotspot data of specific types.

In summary, since the time-varying nature of UE under 6G edge computing for Large-Scale Communities, and with the rapid growth in the amount of UE and mobile communication volume, it is difficult to meet the needs of Edge by simply placing replicas on ESs. Therefore, this paper proposes a Hybrid Replica strategy based on the Community Division under 6G Edge, named the HRCD, aiming to further reduce access latency and improve system performance by placing replicas on ESs and UE. the HRCD uses the Label Propagation Algorithm (LPA for short) to determine whether the time-varying UE belongs to the stable service set and selects appropriate multiple pieces of UE within the stable set as replica placement nodes. Meanwhile, it uses uniform distribution to select appropriate hotspot data as replica data according to the data access situation. The main contributions of this paper are summarized as follows:

• The HRCD employs the PLA algorithm to categorize time-varying terminals into multiple stable communities and implements a hybrid replica placement strategy. This strategy involves distributing replicas across both edge nodes and end-devices, thereby achieving system load balancing and minimizing data access latency.
• The HRCD determines the stable set that time-varying UE belongs to based on its inherent properties and data access patterns. To select replica placement nodes from this set, the HRCD utilizes fuzzy clustering analysis. Here, the inherent properties of UE refer to various indicators that influence a terminal node’s capacity to serve other nodes or itself, including the node’s load, residual computational power, available storage space, and topological distance from other nodes, among others.
• The HRCD selects hotspot data for replica creation within the stable set by considering both the geographical proximity of nodes and data access patterns within the set. Based on these factors, the HRCD categorizes the data appropriately for replica creation.
• We conduct an experimental evaluation of the HRCD’s performance in comparison to similar edge replication strategies to validate its superior performance.

The rest of this paper is organized as follows. Section 2 reviews the related work. Section 3 overviews the HRCD. Section 4 presents the HRCD in detail. Section 5 theoretically analyzes the HRCD’s validity and efficiency. Section 6 experimentally evaluates the HRCD’ performance against the similar edge replication strategies. Section 7 summarizes this paper and points out future work.

2. Related Works

2.1. The Method of Placing Replicas

Placing replicas on ESs can improve the overall system capacity of Edge, reduce data access latency, and lower energy consumption [3,4,5,6]. It has received widespread attention from academia and industry, and a large number of replica placement methods have been proposed [10,11,12,13,14,15,16,23,24,25,26,27]. The related works are shown in

Table 1. Comparison of existing papers addressing replica placement problems.

Paper	Location of Replicas	Target	Method Adopted
[10]	Edge, cloud	Reducing service latency for end users	Mixed integer linear programming
[12]	Edge	Minimizing system costs	Constrained optimization
[14]	Edge	Minimizing data caching costs	Integer linear programming
[15]	Edge	Maximizing Service Provider Revenue	Integer linear programming
[23]	Edge	Relieving cloud server load	Continuously monitor data requests from edge nodes. The principle of geographic locality of data
[24]	Edge	Mitigating the integration challenges of edge computing and blockchain	Using community discovery algorithm to cluster edge devices with similar performance and geographical location into the same set
[25]	Edge	Relieving the collaborative computing problem of edge nodes in untrusted environments	Adopting an election mechanism to select nodes and using blockchain to alleviate node trust issues
[26]	Edge	Improving system performance with fewer replicas	Dynamically adjust replicas based on the relationship between data access frequency and number of replicas
[27]	Edge, cloud	Minimizing latency and bandwidth consumption	User behavior preferences
[28]	Edge, end	Optimizing cache performance	Combination optimization, search algorithm
[20]	End	Improving cache hit rate	Using deep learning to predict content popularity and dynamically adjust cache

.

All the aforementioned methods in Table 1 effectively address network transmission delays, enhance real-time performance and data processing efficiency, elevate data access speeds, improve user experience, and strengthen data privacy and security. Depending on the placement of replicas, existing schemes can be grouped into three categories: UE-based, ES-based, and hybrid placement. Among them, ES-based placement pertains to placing replicas on edge nodes, as referenced in papers [12,14,15,23,24,25,26,27]. Such algorithms typically evaluate whether content is popular and requires replica creation based on the frequency of user requests and corresponding response times. They then compute the number of replicas needed for domains lacking them and identify the most suitable node within those domains for replica placement.

UE-based placement refers to placing replicas on end-user devices, as mentioned in papers [19,20]. This research often uses prediction algorithms to forecast the content users may access and caches this content in advance onto their devices, achieving rapid data retrieval and response. These algorithms are predominantly applied in D-2-D or Peer-to-Peer (P2P) scenarios. Compared to ES-based methods, the placement of replicas is closer to the user end, resulting in faster response speeds and effective load balancing of edge nodes. However, they consume end-device storage resources, leading to lower storage utilization rates.

Hybrid placement involves placing replicas on any device from end-user devices to the cloud center, as referenced in papers [12,27,28]. This approach flexibly selects caching locations (such as the cloud center, edge nodes, or end-devices) based on user request patterns, network conditions, and resource distribution. It pushes popular content closer to users, either to the edge or their devices, to reduce access latency. Such methods often require resource scheduling algorithms (or service orchestration algorithms) for support, resulting in significant computational resource consumption. Additionally, due to the need to place replicas in multiple locations, the degree of replica redundancy is relatively high.

2.2. The Community Discovery Algorithm

Community attributes are an important characteristic of complex networks. Discovering communities in the network is dividing similar nodes into a set. Paper [26] first applied the Label Propagation Algorithm (LPA) to community discovery. The basic idea of the algorithm is to assign a unique label to every node and update the label with the propagation process. It calculates the maximum number of labels among neighboring nodes to update the node’s label and finally adds all nodes with the same label to the same community. The links between nodes within the same community are relatively dense, while the links between different communities are relatively sparse [29,30]. In recent years, community discovery has been widely applied to different types of networks, such as the World Wide Web, social networks, and biological networks. Currently, most community discovery algorithms are based on network structure partitioning, such as graph-based partitioning algorithms, edge clustering algorithms, seed diffusion methods, random walks, hierarchical clustering, and modularity [31,32,33]. However, these algorithms have high computational complexity and are not suitable for analyzing large community networks.

Paper [31] studied the discovery of overlapping communities in dynamic communities and proposed a community discovery algorithm based on label propagation probability to reveal the development trend of “high coupling” in networks. Although community discovery algorithms based on LPA have been applied in many complex network application scenarios, they are less applied in replica placement in Edge. The UE in Edge has time-varying characteristics and is a typical complex network. LPA can also be used to discover the community to which the UE belongs and place replicas. Paper [32] proposes a reliable label selection and learning algorithm to address the problem of semi-supervised deep learning in the presence of only a very small number of labeled image backgrounds.

3. The Implementation Scenarios of the HRCD

As depicted in Figure 1, the HRCD primarily addresses the communication scenarios of a large-scale community within 6G edge computing, characterized by high-density micro base stations. UE is carried by users, and their movements traverse the service areas of various base stations over time. To vividly demonstrate the implementation steps of the HRCD, let us consider UE1 as a terminal node that traverses multiple service areas. Drawing from real-world scenarios, UE1 moves sequentially through numerous US areas, as highlighted by the red line in Figure 1. For instance, if $U{E}_1$ is carried by a corporate employee, its movement pattern is likely to adhere to a regular route between home and the workplace.

The specific implementation steps are as follows:

Step 1: Initialization Phase. $U{E}_1$ determines its label based on the categories of its historical access data, while ESs determine its label based on the categories of the historical access data of all terminal nodes within its service area. The labels for both UE and ESs are not fixed but rather constitute a set of labels.

Step 2: Label Exchange Phase. As shown in Figure 1, when $U{E}_1$ moves into the service area of $E{S}_E$, it exchanges labels with $E{S}_E$, meaning that $E{S}_E$ distributes its labels to $U{E}_1$. When exchanging labels among UE, the HRCD assumes that the UE within the service scope of the edge server remains constantly online and that the D2D link remains consistently accessible.

Step 3: Determining the Stable Set Belonging to $U{E}_1$. As shown in Figure 1, within $E{S}_E$’s service area, $U{S}_E$ employs the HRCD method to assess the similarity of data access patterns and inherent attributes between $U{E}_1$ and other UE, thereby determining the stable service set to which $U{E}_1$ belongs.

Step 4: Selecting Replica Placement Nodes within the Stable Set. the HRCD selects appropriate sets of terminal devices as replica placement nodes from each community, based on the predefined stable community sets. It considers multiple factors that influence data access and load balancing, and employs fuzzy clustering analysis to select node sets from within the stable set for replica placement.

Step 5: Selecting Replica Objects within the Stable Set. The HRCD creates replicas based on the categories of data in the candidate placement nodes and the hotspot data within each category. When creating replicas, the HRCD first allocates them uniformly according to the proportion of requests for each category of data within the replica placement node set in the stable set, determining the category of replica to be created. It then selects data for replica creation uniformly, based on the proportion of requests for hotspot data under different data categories. $U{E}_1$ selects hotspot data for replica creation.

Step 6: Data Access Phase. When accessing data, the HRCD prioritizes requests for data from within the stable set. If the request fails, it proceeds to request data from edge devices. Similarly, when accessing data, $U{E}_1$ prioritizes selecting replica data from the replica placement node set within the stable set. If the request is unsuccessful, $U{E}_1$ obtains replica services from $E{S}_E$.

The HRCD prioritizes fetching data from the stable set. In the event of failure, it shifts to requesting data from edge nodes. If those attempts also fall through, it resorts to sourcing data from the cloud. This hybrid replica placement method stands out from traditional hybrid approaches. Instead of relying on predictive algorithms to pre-cache data on end devices, the HRCD leverages community detection algorithms and fuzzy clustering analysis to identify terminal nodes for replica placement, based on observed data access patterns. Moreover, when it comes to creating replicas, the HRCD takes a different tack from the traditional approach of prioritizing popular (or hotspot) data. Instead, it creates replicas based on data categories, taking into account access patterns within stable sets. This innovative approach helps enhance the success rate of replica access.

4. The HRCD Algorithm

This section will provide a comprehensive explanation of the algorithm steps involved in the HRCD. Previously, Section 4.2 introduced the detailed steps for obtaining a stable set of UE. Section 4.3 delved into the challenge of determining the set of replica placement nodes. Furthermore, Section 4.4 elaborated on the selection process for a replica creation object. Lastly, Section 4.5 detailed the steps required for placing replicas on the UEs.

4.1. The Table of Partial Parameters for the HRCD

Some of the parameters involved in the HRCD are shown in

Table 2. Key notations.

Notations	Meanings
$U{E}_i$	The i-th UE.
$E{s}_i$	The i-th ES, assuming there are M ESs under 6G Edge, denoted as $\{E{s}_1,E{s}_2,\dots E{s}_M\}$
$Sd{r}_i$	The $E{s}_i$ service area, assuming there are N pieces of UE under $E{s}_i$, denoted as $Sd{r}_i=\{U{E}_1,U{E}_2,\dots ,U{E}_N\}$
$f_i$	The requesting data, assuming there are L different file under 6G Edge, denoted as $\{f_1,f_2,\dots ,f_L\}$
$K_i$	Data category, assuming there are k different category under 6G Edge, denoted as $\{K_1,K_2,\dots ,K_k\}$
	Given data $f_i$, it belongs to $K_i$, $f_i\in K_i$
m	Constant, $U{E}_i$ can record the number of labels.
$C{r}_i$	The number of new label been recorded.
$d_{i,j}$	The backhaul distance between $U{E}_i$ and $E{s}_i$.
$q_i$	The load of $U{E}_i$.
$R{s}_i$	$U{E}_i$’s remaining storage space for replicas.
$R{w}_i$	The remaining bandwidth of $U{E}_i$.

.

4.2. Algorithm for Obtaining Stable Set of Nodes

The core of the HRCD lies in accurately identifying which UE is served by the replicas. The requested data exhibits geographical locality characteristics at the edge [23], meaning that nodes within the service area of an edge server share similar data access requirements. In simpler terms, UE served by the same edge server has a higher likelihood of accessing identical data. Consequently, this UE develops stronger connections due to its shared data access patterns. Leveraging Complex Network Community Theory [29,30], we can characterize the relationships among UE at the edge by analyzing data access similarity. Thus, through community discovery, we can ascertain the community to which a piece of time-varying UE belongs. In other words, based on complex network community theory, we can identify the stable service sets that various UE is affiliated with.

The HRCD determines the relationship between time-varying nodes based on their inherent properties and the actual situation of data access. The inherent properties of UE are measured from the perspective of UE users. For example, assume $U{E}_1$ and $U{E}_2$ are used by $Use{r}_1$ and $Use{r}_2$, and assume that users have three inherent attributes, workplace, unit, and gender, expressed as $\{addr,unit,sex\}$. So, the inherent properties of $Use{r}_1$ and $Use{r}_2$ are represented as $U{E}_1=\{add{r}_1,uni{t}_1,se{x}_1\}$, $U{E}_2=\{add{r}_2,uni{t}_2,se{x}_2\}$. If $add{r}_1=add{r}_2$ and $add{r}_1=add{r}_2$; then, when $U{E}_1$ and $U{E}_2$ move to the same service area of an ES, compared to other UE, they have a higher probability of accessing the same data category due to some of their properties being the same; that is, compared to other UE, $U{E}_1$ and $U{E}_2$ are closely connected and have a high probability of belonging to the same “community”. However, judging the data category accessed by UE solely based on the same attributes still has limitations, and other factors need to be considered. For example, since there is an attribute difference between $U{E}_1$ and $U{E}_2$, the data categories that they are concerned about may be different. To find similarities in accessing data, it is also necessary to pay attention to their historical access information.

According to the above considerations, the HRCD determines the stable services set as follows: Firstly, the HRCD defines node labels and ES labels. Then, UE periodically records the labels of encountering ESs in a decentralized adaptive manner. Finally, according to the recording labels and inherent attributes of UE, the stable set to which UE belongs is determined through the similarity degree.

4.2.1. The Method of Obtaining the UE’s Label

We assume that $f_i$ has a unique data type. $U{E}_i$ records the requested data in its log. the HRCD obtains the recent $k1$ accessing records from the log and counts the frequency of each data category in $k1$, expressed as follows:

$$Fd{k}_j={\displaystyle \frac{\sum K_j}{{\sum }_{i=1}^{k1}{K}_i}}$$

(1)

$Fd{k}_j$ represents the frequency of $K_j$ class data appearing in $k1$. In the initial state, $U{E}_i$ takes the top $Le{n}_i$ data category with the highest frequency as its label, expressed as follows:

$$R{l}_i=\{K_1,K_2,\dots ,K_m\}m=Le{n}_{i}andm<=k$$

(2)

4.2.2. The Method of Obtaining the ES’s Label

According to the principle of geographic locality in edge computing [23], for simplicity, we use the data category of hotspots within the ES service area as the label for ESs. The method is as follows.

ESs periodically count the data requests within the area of the service in descending order according to the request count, obtain the top $k2(k2\gg k1)$ data with the highest number of requests, and count the frequency of each category of data in $k2$. $E{S}_i$ takes the top $k3$ data category with the highest frequency as its label, in which, $k3=\beta \times \overline{Le{n}_i}\beta >=2$. Here, $Le{n}_i$ represents the average number of UE labels in the current service area, and $\beta$ is a custom constant.

4.2.3. The Method of Label Propagation

UE can move within different ES service areas. If UE requests data on ESs (or other nodes within the ES service area that place replicas), then it records ES labels related to the requested data; i.e.,the  ES propagates its label to the UE. UE can save the fixed number of labels and replace them with the longest unused algorithm [34]. Meanwhile, UE records the accessed data information in a log. When UE records labels, if the recorded label is a new label in the UE label record, update the number of label records, expressed as $C{R}_i=C{R}_i+1$. If the requested data does not exist in the ES, it is necessary to request data from the remote cloud through the ESs. At this time, the UE still records the accessed data category as its historical access data.

4.2.4. Determine the Stable Service Set to Which the UE Belongs According to the Membership Degree

The HRCD takes into account both the inherent properties and historical access information of UE and determines the stable service set to which the UE belongs based on the membership degree of the UE. Here, the membership function is shown in Equation (3) as follows:

$$Si{m}_{i,j}={\gamma }_1\times s{d}_{i,j}+{\gamma }_2\times s{p}_{i,j}{\gamma }_1+{\gamma }_2=1$$

(3)

Here, ${\gamma }_1$ and ${\gamma }_2$ are weight coefficients. $s{d}_{i,j}$ and $s{p}_{i,j}$ are data access similarity and intrinsic attribute similarity for $U{E}_i$ and $U{E}_j$, respectively.

The method of obtaining $s{d}_{i,j}$ is as follows:

Using $Sd{r}_i$ as the domain of discourse ($Sd{r}_i$ indicates UE within $E{S}_i$ service area). Use every UE recorded label as an indicator; that is, $U{E}_i=\{R{l}_{i,1},R{l}_{i,2},\dots ,R{l}_{i,m}\}$ are indicators. The proportion $R{l}_{i,k},$ of the k-th data type label on $U{E}_i$ is represented as

$$R{l}_{k,i}={\displaystyle \frac{{\sum }_{K_k\in K}Bp{l}_{k,i}}{m}}\sum R{l}_{i,k}=100\%$$

(4)

Given $U{E}_i$ and $U{E}_j$, the similarity of their access data can be obtained by the following Equation (5):

$$S{d}_{i,j}={\displaystyle \frac{{\sum }_{k=1}^{m}R{l}_{i,k}\times R{l}_{j,k}}{\sqrt{R{l}_{i,k}^2}\times \sqrt{R{l}_{j,k}^2}}}$$

(5)

The method of obtaining $S{p}_{i,j}$ is as follows:

Using $p{n}_{i,k}$ to denote the k-th attribute of $U{E}_i$, and using n to denote the number of attributes. The fixed attribute set of $U{E}_i$ is represented as $P{n}_i=\{p{n}_{i,1},p{n}_{i,2},\dots ,Pp{n}_{i,n}\}$. Given $U{E}_j$, the similarity of their intrinsic attributes can be obtained by the following Equation (6):

$$S{p}_{i,j}={\displaystyle \frac{1}{n}}\times \sum _{k=1}^n\delta (p{n}_{i,k},p{n}_{j,k})$$

(6)

where $\delta (p{n}_{i,k},p{n}_{j,k})=1$ when $p{n}_{i,k}=p{n}_{j,k}$. $\delta (p{n}_{i,k},p{n}_{j,k})=0$ when $p{n}_{i,k}\ne p{n}_{j,k}$. For example, $U{E}_1=\{add{r}_1,uni{t}_1,female\}$, $U{E}_2=\{add{r}_2,uni{t}_2,female\}$, if $add{r}_1=add{r}_2$, $uni{t}_1=uni{t}_2$, it indicates that users of $U{E}_1$ and $U{E}_2$ have the same work unit and residential unit; then, its inherent attribute similarity is $s{p}_{1,2}={\displaystyle \frac{2}{3}}$.

Given $E{S}_i$, when dividing the stable service set to which the UE belongs, the HRCD firstly defines a threshold $2=<\gamma$ according to the actual situation. Given $E{S}_j(U{E}_j\in Sd{r}_i)$, it obtains its membership degree with other nodes within its service area according to Formula (3). Take the node set that satisfies $Si{m}_{i,j}>\gamma \overline{Si{m}_{i,j}}$ as the stable service set to which $U{E}_j$ belongs, expressed as $Cp{s}_i$. Here,

$$\overline{Si{m}_{i,j}}=\sum _{i=1}^N{\displaystyle \frac{Si{m}_{i,j}}{N}}$$

(7)

It indicates the average membership degree of other UE within $Sd{r}_i$ and $U{E}_j$.

According to the above description, the pseudocode for the HRCD to obtain the stable service set to which a node belongs is shown in Algorithm 1.    

Algorithm 1: The algorithm for obtaining stable set of UE

Input: $Sd{r}_i$, $U{E}_i=\{R{l}_{i,1},R{l}_{i,2},\dots ,R{l}_{i,m}\}$, $P{n}_i=\{p{n}_{i,1},p{n}_{i,2},\dots ,Pp{n}_{i,n}\}$, ${\gamma }_1,{\gamma }_2,\gamma$ Output: The stable set $Cp{s}_i$ to which $U{E}_i$ belongs Obtaining the proportion of k-th class labels according to (4); Obtaining $S{d}_{i,j}$ between $U{E}_i$ and other nodes in $Sd{r}_i$ according to (5); Obtaining $S{p}_{i,j}$ between $U{E}_i$ and other nodes in $Sd{r}_i$ according to (6); Obtaining $Si{m}_{i,j}$ between $U{E}_i$ and other nodes in $Sd{r}_i$ according to (3); Obtaining the average membership degree of other UE in $Sd{r}_i$ and $U{E}_i$ according to (7); Obtaining $Cp{s}_i$ according to $Si{m}_{i,j}>\gamma \overline{Si{m}_{i,j}}$;

4.3. The Algorithm for Obtaining Replica Placement Nodes

Determining the optimal replica placement node is pivotal in the process of replica placement. Various factors, including a node’s service capacity, topological position, and load, must be taken into account when selecting replicas. Typically, replica placement algorithms opt for a single “optimal” node for replica deployment. However, given the dynamic nature of UE in edge computing, selecting a single “optimal” node may result in that node being relocated outside the service area of an ES, thereby rendering it unable to continue serving other UE.

To tackle this challenge, the HRCD employs fuzzy clustering analysis to identify a comprehensive set of replica placement nodes. The detailed steps involved are outlined below.

4.3.1. The Evaluation Indicators

Assuming any stable service set $Cp{s}_k$ under $E{S}_i$, select any node $U{E}_j$ from $Cp{s}_k$, and consider its following indicators: the number of records for new label $C{r}_j$, the backhaul $d_{i,j}$ with $E{S}_j$, the node load $q_j$, the remaining space $R{s}_j$ for placing replicas and the remaining bandwidth $R{w}_j$ for nodes. HRCD uses $\{C{r}_j,d_{i,j}{q}_j,R{s}_j,R{w}_j\}$ as the evaluation indicator.

4.3.2. Building the Optimal Virtual Placement Node

If there exists a virtual UE, denoted as $U{E}_{vr}$, in $Cp{s}_k$ with the following indicators:

$$U{E}_{vr}=\{C{r}_{vr},d_{i,vr},q_{vr},R{s}_{vr},R{w}_{vr}\}.$$

$$C{r}_{vr}=min\{C{r}_1,C{r}_2,\dots ,C{r}_{k3}\}.$$

$$d_{i,vr}=min\{d_{i,1},d_{i,2},\dots ,d_{i,k3}\}.$$

$$q_{vr}=min\{q_1,q_2,\dots ,q_{k3}\}.$$

$$R{s}_{vr}=max\{R{s}_1,R{s}_2,\dots ,R{s}_{k3}\}.$$

$$R{w}_{vr}=max\{R{w}_1,R{w}_2,\dots ,R{w}_{k3}\}.$$

where $k3=Cp{s}_k.Length$. That is, $U{E}_{vr}$ has the smallest backhaul, the smallest load, the largest remaining storage space, and the largest remaining bandwidth. Meanwhile, $C{r}_{vr}$ represents the number of times a new data type has been received. According to the principle of data locality under Edge, there is a higher probability of accepting the new data type when the UE moves to a new ES. Therefore, $C{r}_{vr}$ can serve as the frequency at which the UE moves in and out under different ESs. That is, $U{E}_{vr}$ has the minimum movement frequency. It is obvious that $U{E}_{vr}$ is the “optimal” replica placement node in $Cp{s}_k$. But it is a virtual node and cannot place replicas. So, the HRCD uses fuzzy clustering analysis to find UE with high similarity to $U{E}_{vr}$ from $Cp{s}_k$ as a candidate set of replica placement nodes.

4.3.3. Building the Initial Matrix

The HRCD takes $Cp{s}_{all}$ as the domain, $\{C{r}_j,d_{i,j},q_j,R{s}_j,R{w}_j\}$ as the evaluation indicators to construct the initial matrix $R_{init}$ (The initial matrix is shown in

Table 3. The initial matrix.

${\mathit{Cps}}_{\mathit{all}}$	The Evaluation Indicators
	${\mathit{Cr}}_{\mathit{j}}$	${\mathit{d}}_{\mathit{i},\mathit{j}}$	${\mathit{q}}_{\mathit{j}}$	${\mathit{Rs}}_{\mathit{j}}$	${\mathit{Rw}}_{\mathit{j}}$
$U{E}_1$	$C{r}_1$	$d_{i,1}$	$q_1$	$R{s}_1$	$R{w}_1$
$U{E}_2$	$C{r}_2$	$d_{i,2}$	$q_2$	$R{s}_2$	$R{w}_2$
…	…	…	…	…	…
$U{E}_{k3}$	$C{r}_{k3}$	$d_{i,k3}$	$q_{k3}$	$R{s}_{k3}$	$R{w}_{k3}$
$U{E}_{vr}$	$C{r}_{vr}$	$d_{i,vr}$	$q_{vr}$	$R{s}_{vr}$	$R{w}_{vr}$

), in which $Cp{s}_{all}=U{E}_{vr}\bigcup Cp{s}_k$.

The HRCD uses the quantity product method to normalize the dimensions of different indicators in $R_{init}$ and establishes the fuzzy similarity matrix $R_1$. The quantity product method is shown in Formula (8):

$$r_{i,j}=\left\{\begin{array}{cc}1,\hfill & i=j\hfill \\ {\displaystyle \frac{1}{M}}\times \sum _{k=1}^5{x}_{i,k}\times x_{j,k},\hfill & i\ne j\hfill \end{array}\right.$$

(8)

where $r_{i,j}$ represents the similarity between $U{E}_i$ and $U{E}_j$ in $UCp{s}_{all}$. $x_{i,k}$ represents the second indicator of $U{E}_j$. $M=Ma{x}_{i\ne j}({\sum }_{k=1}^5{x}_{ik}\times x_{jk})$.

According to Formula (8), $R_{init}$ can be transformed into the following similarity matrix $R_1$:

$$\begin{array}{c}\left(\begin{array}{cccccc}1& r_{1,2}& r_{1,3}& \dots & r_{1,k3}& r_{1,vr}\\ r_{2,1}& 1& r_{2,3}& \dots & r_{2,k3}& r_{2,vr}\\ r_{3,1}& r_{3,2}& 1& \dots & r_{3,k3}& r_{3,vr}\\ \dots & \dots & \dots & \dots & \dots & \dots \\ r_{k3,1}& r_{k3,2}& r_{k3,3}& \dots & 1& r_{k3,vr}\\ r_{vr,1}& r_{vr,2}& r_{vr,3}& \dots & r_{vr,k3}& 1\end{array}\right)\end{array}$$

4.3.4. Obtaining the Node Set of Replica Placement

The HRCD uses the fuzzy clustering analysis method to cluster $Cp{s}_{all}$. According to $\lambda$-Cut set theory [35,36], $\lambda$ takes non-repeating values from $R_1$ and arranges them in descending order, expressed as follows:

$$Dt{s}_{\lambda }=\left\{\lambda \right|distinct{r}_{i,j}orderbydesc\}$$

(9)

According to the HRCD’s goals, it selects a set of nodes with high similarity to $U{E}_{vr}$ from $Cp{s}_j$ as candidate nodes for replica placement. According to $\lambda$-Cut set theory, the number of nodes in the cluster is closely related to the value of $\lambda$. A larger $\lambda$ means that there less UE in the same set as $U{E}_{vr}$. Less UE participating in replica services easily leads to these nodes’ service pressure increasing. A smaller $\lambda$ indicates that more devices are divided into the same set as $U{E}_{vr}$. Although placing replicas on more devices can effectively balance the load, it can lead to serious waste of storage resources. Therefore, the HRCD uses the Pareto distribution [37] to determine the appropriate $\lambda$ threshold. Assuming when $\lambda ={\lambda }^{\prime }$, if the number of devices in the same set as nodes in $Cp{s}_k$ and $U{E}_{vr}$ reaches 20% of the total number of $Cp{s}_{all}$, clustering will be stopped, and the cluster set at this time is expressed as $Ct{d}_{{\lambda }^{\prime }}$. Then $Ct{d}_{{\lambda }^{\prime }}$ is the candidate set for placing replicas.

Meanwhile, during clustering, the HRCD also records the node set during each iteration of $Cp{s}_k$ and $U{E}_{vr}$ clustering, expressed as

$$stat{e}_k=\{Ct{d}_{\lambda 1},Ct{d}_{\lambda 2},\dots ,Ct{d}_{{\lambda }^{\prime }}\lambda 1,\lambda 2,\dots ,{\lambda }^{\prime }\in Dt{s}_{\lambda }\}$$

According to the above description, the algorithm pseudocode for obtaining candidate sets for replica placement within a stable set is as follows in Algorithm 2.

Algorithm 2: The algorithm for obtaining candidate replica placement nodes

4.4. The Method of UE Selecting the Data to Create Replica

Given that the label record of UE can capture its historical movement patterns across different ESs, HRCD leverages this information to optimize replica placement. Additionally, by selecting popular data for replication, data access latency can be minimized and load-balanced effectively. Therefore, the HRCD identifies and replicates hotspot data, categorized by data type, based on label exchange dynamics. The process involves the following steps:

Step 1: In a decentralized and adaptive manner, the candidate replica placement nodes tally the number of data requests within their respective stable service sets.

Given nodes $U{E}_i$ and $U{E}_j$ ($U{E}_i\in Dt{s}_{{\lambda }^{\prime }},U{E}_i\in Ct{d}_k,U{E}_i\ne U{E}_j$) and assuming the replica for $f_i$ has been placed on $U{E}_i$, if $U{E}_j$ requests data $f_m$ from $U{E}_i$, the number of requests for $f_i$ is increased by 1, denoted as $r(f_m,count)$.

Step 2: $E{S}_i$ periodically obtains the data request situation.

The HRCD uses the following Formula (10) to count the request situation in $Ct{d}_k$ according to the data type.

$$r\left(f_i\right)=\sum _{f_i\in K_k}r(f_m,count)f_i\in K_k$$

(10)

Step 3: According to Formula (10), order data in a descending order based on data type, denoted by

$$Et{d}_k=\left\{Dat{a}_k\right|r\left(f_i\right)orderbycountdesc\}$$

(11)

$Et{d}_k$ is the k-th data type in descending order according to request counts.

Step 4: Select the candidate data sets for creating replicas based on data types.

Obtain the total number of requests for different data types in $Ct{d}_k$ during a unit of time according to Formula (10), denoted by $R{Q}_{All}$. So, the proportion of requests for the k-th data type, denoted by $R{Q}_k$, can be expressed as:

$$R{Q}_k={\displaystyle \frac{{\sum }_{K_k\in K}r\left(f_i\right)}{R{Q}_{All}}}\sum R{Q}_k=100\%$$

(12)

According to (13), obtain the number of candidate replicas, denoted by $lho{t}_k$, that need to be created in $Ct{d}_k$.

$$lho{t}_k=\varphi \times \overline{R{s}_k}=\varphi \times {\displaystyle \frac{{\sum }_{i=1}^{k}R{s}_i}{k}}0<\varphi <=0.5$$

(13)

where $\varphi$ is a user-defined coefficient. $\overline{R{s}_k}$ represents the average remaining storage capacity of all UE ($UE\in Ct{d}_k$. k = $Ct{d}_k$.length.

According to (14), the proportion of the k-th data type in $lho{t}_k$ is

$$LabT{e}_i^k=lho{t}_k\times R{Q}_k$$

(14)

When selecting candidate replica sets, the HRCD selects hotspot data from different data types based on the proportion of requests for each category of data to join $lho{t}_k$, forming a candidate replica set for $Ct{d}_k$, expressed as $Hot{D}_k$.

Based on above description, the pseudo code UE selects candidate data to create replicas as shown in Algorithm 3.

Algorithm 3: The algorithm for obtaining candidate replica placement nodes

Input: The data request status of $Ct{d}_i$ during a unit of time, The remaining space for nodes to place replicas Output: $Hot{D}_i$ Phase 1: $U{E}_j$ ($U{E}_j\in Ct{d}_{{\lambda }^{\prime }}$) counts the request information of its replicas in a decentralized manner. Phase 2: In $Ct{d}_i$, the number of requests is periodicly counted according to the data type by $E{s}_i$; Obtaining the proportion of requests $R{Q}_k$ for different category of data during a unit time according to (12); Arranging the number of requests for data in descending order by data category, obtaining $Et{d}_k$; Obtaining the number of replicas for $Ct{d}_i$ according to (14); Join the different categories of data to the candidate replica set $Ho{t}_k$ according to the number of requests; Return $Hot{D}_k$;

4.5. The Replica Placement Algorithm

The HRCD employs a uniform distribution approach to pick data from the candidate replica set for replication purposes. Additionally, it determines the optimal nodes for placing these replicas by considering both the load of the candidate placement nodes and the order of clustering derived from fuzzy clustering analysis. The specific steps involved are outlined below.

4.5.1. Obtaining the Priority of Placing Replicas in the $Ct{d}_k$ Node Set According to the Order of Fuzzy Clustering

When selecting the replica placement node, the HRCD prioritizes selecting UE with high similarity to $U{E}_{vr}$ as the replica placement node.

During the clustering process, as the number of iterations increases, candidate placement nodes gradually cluster into $Ct{d}_{{\lambda }^{\prime }}$. The earlier clustering into the $Ct{d}_{{\lambda }^{\prime }}$, the higher the similarity with $U{E}_{vr}$. Therefore, the HRCD obtains the priority of candidate nodes as replica placement nodes based on the order of fuzzy clustering. The method is as follows:

Assuming $stat{e}_k=\{Ct{d}_{\lambda 1},Ct{d}_{\lambda 2},\dots ,Ct{d}_{{\lambda }^{\prime }}\}$. The cluster sets corresponding to ($\lambda ,(i-1)$), ($\lambda ,\left(i\right)$), ($\lambda ,(i+1)$) are $\{Ct{d}_{\lambda ,(i-1)},Ct{d}_{\lambda ,\left(i\right)},Ct{d}_{\lambda ,(i+1)}\lambda ,(i+1)<={\lambda }^{\prime }\}$, respectively. When $\lambda =(\lambda ,i)$, $Ct{d}_{\lambda ,i}^{\prime }=Ct{d}_{\lambda ,i}\cap Ct{d}_{\lambda ,i-1}$ is the new clustering node set. When $\lambda =(\lambda ,i+1)$, $Ct{d}_{\lambda ,i+1}^{\prime }=Ct{d}_{\lambda ,i}\cap Ct{d}_{\lambda ,i+1}$ is the new clustering node set. When selecting a replica placement node, prioritize the nodes in $Ct{d}_{\lambda ,i}^{\prime }$.

4.5.2. Selecting Data Objects to Create Replicas

When creating the replica, the HRCD first determines the data type for creating the replica, and then selects the data for creating the replica. The HRCD first obtains the proportion of each type of data according to Formula (14), and then uses the uniform distribution to determine the data type for creating replicas, denoted by $D{a}_k$ ($D{a}_k\in K_k$). Then, according to Formula (15), select $f_i$ ($F_i\in Hot{D}_k$) from the $D{a}_k$ using the uniform distribution and create a replica.

$$Pe{p}_i={\displaystyle \frac{{\sum }_{f_i\in D{a}_{k}r(f_i,count)}}{\sum {\sum }_{f_i\in D{a}_{k}r(f_i,count)}}}{f}_i\in Hot{D}_k$$

(15)

At (15), the denominator represents the number of requests during a unit time for all hotspot data belonging to the $D{a}_k$ type in $Hot{D}_k$. The numerator represents the amount of $f_i$ requested during a unit time. According to (14) and (15), when selecting data to create the replica, the more times the $f_i$ in the $D{a}_k$ type data is accessed, the higher the probability of being selected as the replica data.

4.5.3. Obtaining the Number of Replicas Created According to the Node Load

Many factors can cause changes in node load. The HRCD only considers the load caused by requests. Assuming the maximum number of requests that $U{E}_i$ ($U{E}_i\in Ct{d}_i$ can handle during a unit of time is $MaxR{e}_i$. The node load is

$$q_i={\displaystyle \frac{\sum r(f_{m,k},count)}{MaxR{e}_i}}$$

(16)

where $\sum r(f_{m,k},count)$ represents the total number of requests during a unit of time for all replicas on $U{E}_i$. The average load of $Ct{d}_i$ can be expressed as

$$\overline{q_i}={\displaystyle \frac{{\sum }_{i=1}^k{q}_i}{k}}inwhichk=Ct{d}_i.length$$

(17)

The HRCD defines a threshold $\delta$($\delta >=2$) that can be dynamically adjusted according to actual situations. With the number of requests increasing during a unit of time, the node load increases too. Load balancing is one of the important goals of the HRCD. Since placing replicas on nodes is an important reason for increasing requests, the HRCD assumes that $q_i$ satisfies inequality (18) and stops placing replicas on $U{E}_i$ to reduce node load.

$$q_i>=\delta \times \overline{q_i}$$

(18)

Here, in (18), $q_i$ is called the overloaded threshold of $U{E}_i$. When the load of a replica node reaches its overloaded threshold, it needs to stop responding to data requests. Although more replicas can balance the load of ESs, more replicas can also increase the maintenance burden and waste storage space. Therefore, the HRCD sets the lightweight load of $E{s}_i$, denoted by $Es{L}_i$. When the request load of $E{s}_i$ is less than $Es{L}_i$, there is no need to create a replica within any stable set. Meanwhile, the HRCD also defines a lightweight load threshold for a stable services set, denoted by $\theta$ ($\theta <=0.5$). After placing replicas on the UE within $Ct{d}_i$, if the average load $\overline{q_{\lambda }^{\prime }}$ of $Ct{d}_i$ satisfies inequality (19), stop placing replicas on any node within $Ct{d}_i$.

$$\overline{q_{\lambda }^{\prime }}<=\theta \times {\displaystyle \frac{{\sum }_{k=1}k{q}_{\lambda }^{\prime }}{k}}inwhich,k=Ct{d}_i.length$$

(19)

According to the above description, the pseudocode of placing replicas on UE is shown in Algorithm 4.

Algorithm 4: HRCD replica Placement Algorithm

While placing replicas on UE can indeed alleviate the service burden on ESs, there are instances where UE within a stable set is unable to retrieve the requested data locally. In such cases, they still have to request data from the ES. To address this, the HRCD adopts a traditional approach of deploying replicas of hotspot data on ESs based on the frequency of requests. This strategy aims to minimize the amount of UE acting as replica hosts and to reduce data access latency for UE.

5. Performance Analysis

This section theoretically analyzes the time complexity and the efficiency of the HRCD.

5.1. The Time Complexity of the HRCD

When placing replicas on UE, the HRCD designed a total of four algorithms. The first three algorithms are all for the final replica placement service (i.e., Algorithm 4). So, we only analyze the time complexity of Algorithm 4 here. For the time complexity of Algorithm 4, there is the following Theorem 1:

Theorem 1. 

The time complexity of the the HRCD is O($N^3$).

Proof of Theorem 1. 

In Algorithm 1, line 1 computes the proportion of data labels for each node within the domain, with a time complexity that scales with the length of $Sd{r}_i$, denoted as O(N). Lines 2–4 determine the similarity between a specified node and all other nodes, exhibiting a time complexity of O($N^2$). Line 5 calculates the average similarity complexity in constant time, O(1). Line 6, leveraging given coefficients, evaluates the similarity between each node and its peers to generate distinct stable service sets, with a time complexity of O($N^2$). Consequently, the aggregate time complexity of Algorithm 1 is summarized as O($N+N^2+1+N^2$) = O($N^2$).

Algorithm 2 constructs an optimal replica placement node and employs fuzzy clustering, specifically leveraging the fuzzy C-means clustering technique, which has been applied in edge computing scenarios [35,36]. The algorithmic complexity of fuzzy C-means clustering is influenced by various factors, including the number of samples (n), the number of classifications (c), the sample dimension (d), and the number of iterations (t), and is typically denoted as O(n$c^2$dt) [35,36]. In the context of the HRCD, the sample dimension is fixed at d = 5, and the sample size is determined by k = k3 + 1. As a result, the time complexity of Algorithm 2 in this specific application can be summarized as O(5k$c^2$t).

Algorithm 3 incorporates Formulas (10)–(14), which primarily serve to tally the data access attempts by the UE within a specified service area. This process leads to the identification of hotspot data, thereby forming a replica candidate set within a given stable set. The time complexity of this algorithm is intricately tied to the number of nodes contained within the stable set that is being considered for replica placement. In scenarios where all nodes happen to be grouped into a single stable set, represented by $k=N$, the time complexity escalates to O(N).

Algorithm 4, starting from Line 5, outlines the process of placing replicas within a given stable service set. The frequency of the algorithm’s execution is directly proportional to the number of stable service sets that have been divided. In the most extreme scenario, the UE forms its own stable service set. From Line 5 onwards, the worst-case execution scenario occurs O(N) times. Lines 6–8 involve the execution of Algorithms 1,2,3, respectively, implying that the time complexity for these lines in Algorithm 4 is O(N($(N^2$)), O(N(5k$c^2$t)), and O($N^2$), respectively. Consequently, the cumulative time complexity can be expressed as O($N^3$). Lines 16 to 25 describe the process of selecting replica placement nodes from the set of candidate replica nodes and selecting replica data from the set of candidate creation replicas. According to the pseudo-code, the premise of lines 16 to 25 is to give a stable set. Meanwhile, lines 16 to 25 are a nested loop; its time complexity is O($N^2$). But, for the entire service area, the time complexity is O($N^3$). In summary, the time complexity of Algorithm 4 is O($N^3$). □

5.2. The Performance Analysis of the HRCD Algorithm

5.2.1. Analysis of the Success Rate of Replica Requests

In the application scenarios that the HRCD focuses on, compared to the method of sequentially selecting hotspot data as the target for replica creation, the approach adopted by the HRCD can effectively improve the success rate of data access. The analysis is as follows:

First, analyze by selecting the replica data category. In a large community with 6G edge computing, the time-varying nature of nodes is the main reason for the diversity of data categories within the ES service area. Since the data under ESs has geographical locality, data that conforms to the geographical characteristics of ESs has a higher access amount when given ESs. If data is selected sequentially, the type of data has a higher probability of becoming a replica, while other types of data have a lower probability of becoming replicas, resulting in an inability to meet the needs of accessing multiple types of data. the HRCD uses a uniform distribution to select data types according to the requested proportion of the data category. The higher the proportion of requests, the higher the probability of being selected, but data types with a smaller proportion also have a lower probability of becoming replicas. Therefore, this can meet the data access requirements of UE by varying time.

Second is the analysis from the perspective of selecting hotspot data. To address the issue of a single node easily moving out of the service area, it is necessary to select multiple pieces of excellent UE in Edge. If sequentially selecting hotspot data, each node in the excellent node set selects the first few hotspot data as the replica data, while the suboptimal hotspot data has a lower probability of becoming replicas. In the the HRCD method, each node in the excellent node set selects hotspot data as the replica data according to the request proportion. The higher the proportion of requests, the higher the probability of being selected, ensuring the probability of the first few hotspots becoming replica data. At the same time, data with a low proportion of requests can also become replicas, ensuring the demand for suboptimal hotspot data requests. So, we have the following, Theorem 2 (for correct verification of the conclusion, please refer to Experiment 6.3.3.).

Theorem 2. 

In the application scenarios that the HRCD focuses on, compared to sequentially selecting hotspot data as the objects for replica creation, the approach adopted by the HRCD is conducive to improving the success rate of replica access.

5.2.2. Load Balancing Analysis

In the application scenarios that the HRCD focuses on, compared to traditional methods of selecting replica placement nodes (i.e., ES-based in this paper), the HRCD can better balance the edge node load. The analysis is as follows.

Limitations of the ES-Based Method: The neighboring strategy primarily considers physical distance (or network topology distance) and neglects other factors that impact load, such as the request frequency, processing capacity, and activity level of terminal devices. This may result in some edge nodes being overloaded, while others may have lighter loads, leading to system load imbalance. Advantages of the HRCD are that the HRCD not only takes into account physical distance (or network topology distance) but also comprehensively considers multiple factors that impact load. By utilizing fuzzy clustering analysis, it selects the optimal replica placement nodes. This enables the HRCD strategy to better adapt to the mobility of terminal devices and changes in request patterns, dynamically adjusting the replica placement strategy to maintain a balanced system load. So, we have the following Theorem 3 (For correct verification of the conclusion, please refer to Experiment 6.3.1.).

Theorem 3. 

In the application scenarios that the HRCD focuses on, compared to sequentially selecting hotspot data as the objects for replica creation, the approach adopted by the HRCD is conducive to improving the success rate of replica access.

5.2.3. Data Access Latency Analysis

In the application scenarios that the HRCD focuses on, compared to methods based on ESs, the HRCD can reduce the access latency for the terminal. The analysis is as follows.

In large communities with high-density base stations, the dense distribution and time-varying characteristics of terminals result in frequent and volatile data access demands. The HRCD considers more factors (such as backhaul links, load, and bandwidth) when selecting replica placement nodes, enabling it to more accurately select optimal nodes for replica placement. Compared to ES-based methods, the data is positioned closer to the terminals with access demands. Furthermore, when selecting objects for replica creation, the HRCD prioritizes the data types to be replicated, taking into account the geographical locality features of ESs. This means that the HRCD not only focuses on the physical location of nodes but also the correlation between data types and nodes, further optimizing data access efficiency. In summary, by comprehensively considering multiple factors to select optimal replica placement nodes and creation objects, the HRCD employs more refined strategies and considers more influencing factors to optimize data access latency, thereby improving the overall performance of the system. So, we have the following Theorem 4 (For correct verification of the conclusion, please refer to Experiment 6.3.2.).

Theorem 4. 

In the application scenarios targeted by the HRCD, compared to ES-based methods, the HRCD can effectively reduce the access latency for terminals.

6. Discussion

6.1. Comparison Approaches and Experimental Settings

We compared the traditional method (named ECRP), the HRCD-O method, and the HRCD to show the superiority of the HRCD. The replica placement method for ECRP is the following: It selects hotspot data within the communication area as a replica and places the replica on ESs, such as in paper [12,14,15] in Table 1, which adopts the approach of placing replicas in ESs. The HRCD-O refers to the method of selecting replica creation objects in an ordered manner according to Theorem 2. The method of obtaining a stable set and selecting a set of replica placement nodes within the stable set is consistent with the HRCD, except for selecting replica creation objects and replica placement nodes sequentially. The HRCD-O places replicas in ESs or end through edge-end collaboration, such as in paper [28] in Table 1, which adopts the approach of placing replicas in ESs.

To verify the performance of the HRCD, we designed and implemented a simulation platform using VS according to Edge architecture. The experiment employed the publicly accessible dataset BSDS500 [38]. The simulation topology, depicting a vast community comprising numerous micro base stations, is presented in Figure 1. Each base station has a designated service area that remains fixed. Consistent with the attributes of 6G cellular networking, when the service zones of two distinct micro base stations converge, the terminal opts for the base station with the shorter topological distance to serve as its connection point. During the experiment, images were allocated to various base stations based on the edge annotations provided in the dataset, mirroring the geographically confined nature of data access in the real world. Furthermore, we postulate that each terminal node possesses a professional attribute, reflecting the occupations of actual terminal users. Depending on their professional attributes, terminals request diverse datasets from different base stations or from other terminals within the service area of a base station. Additionally, we hypothesize that each terminal node follows a “preset route” (as exemplified by UE1 tracing the red path A-B-D-E-C-A in Figure 1), simulating the movement patterns of real-world terminal users who traverse different locations due to their varying occupations.

6.2. Comparison Performance

The simulation platform was developed using Visual Studio 2015 to model the 6G edge computing environment, including cloud centers, edge servers (ESs), user equipment (UE), and UE mobility patterns. To handle fuzzy clustering analysis in the HRCD (Section 4.3), we utilized MATLAB R2020a with its built-in Fuzzy C-Means (FCM) function (fcm) for clustering terminal nodes based on their service capabilities (e.g., load, bandwidth). The BSDS50 dataset was integrated into the platform to simulate geographically localized data access patterns. The simulation code and supporting data are available as Supplementary Material. The simulation defines some user-defined variables involved in the HRCD, as shown in

Table 4. The parameter list.

Parameter	Value
$\beta$	2
$\gamma 1$	0.5
$\gamma 2$	0.5
$\gamma$	2
$\theta$	2
The overloaded threshold $q_i$	0.3 ∼ 0.9

below.

In the simulation experiment, we compared the following performance metrics:

(1) Average Load: Given that the primary objective of the HRCD is to diminish the load on ESs by deploying replicas in UE, we assessed the average load of nodes under various methodologies.

(2) Average Access Latency: Placing replicas on ESs can significantly reduce data access latency for terminals, aligning with the HRCD’s goal. Consequently, we compared the average access latency of requests across different methods.

(3) Replica Access Success Rate: As previously analyzed, the HRCD can achieve a higher success rate for accessing replicas. Therefore, we evaluated the success rate of replica access within a stable set under different methodologies.

(4) Replica Coefficient: While increasing the number of replicas can lead to lower data access latency and better load balancing, it also entails higher storage consumption and maintenance costs. Thus, finding a reasonable balance between the number of replicas and system performance is crucial. Therefore, the simulation compared the replica coefficient of different methods to confirm that the HRCD can achieve superior performance with fewer replicas.

6.3. Experimental Results

6.3.1. The Average Load

Figure 2, Figure 3, Figure 4, Figure 5, Figure 6 and Figure 7 show the average load of different methods to verify that the HRCD can balance the load of stable set nodes and ESs. Figure 5, Figure 6 and Figure 7 represent the average load of ESs.

From Figure 2, Figure 3 and Figure 4, we observe that the average load exhibits an upward trend as both the number of requests and the overload threshold increase. This is attributed to the fact that a larger number of requests translates into higher pressure on the replica node, thereby elevating the average load. Additionally, a higher overload threshold for a node implies that the replica UE can accommodate more access, leading to an increase in the node’s average load as well.

From Figure 2, it is evident that the HRCD’s average load is approximately 5% lower than that of the HRCD-O. As the number of requests increases, the difference between the two gradually narrows. This is due to the HRCD’s strategy of selecting multiple “excellent” nodes within the stable set as replica placement nodes, which prevents other nodes in the stable set from being unable to request replicas when the replica node moves out of the ES service area. Furthermore, multiple nodes providing replica services can effectively balance the load within the stable set. In contrast, the HRCD-O selects the “best” node with the highest similarity to the virtual node within the stable set as the replica placement node, without considering the involvement of other nodes in the replica service. Consequently, its ability to balance node load is inferior to the HRCD. Additionally, both methods halt the creation of replicas when the node’s load reaches a predefined threshold. As the number of requests increases, replica nodes gradually become overloaded and cease responding to data requests, leading to a gradual convergence of the average load between the two methods.

From Figure 5, Figure 6 and Figure 7, we understand that both the HRCD and the HRCD-O are capable of effectively balancing the load of ES. As the number of requests increases, the load on the ES also rises. Conversely, as the overload threshold of a node increases, the load on the ES decreases. This is because a higher number of requests leads to a higher load, while a larger overload threshold allows the replica UE to handle more access, thereby reducing the load on the ES. In other words, when the replica UE bears more load, the ES bears less load, resulting in a decrease in load on the ES as the overload threshold increases.

Compared to the HRCD-O, the HRCD exhibits superior performance with an average load reduction of approximately 2%. This is attributed to the fact that both the HRCD and HRCD-O employ the strategy of placing replicas on UE to balance the load on the ES. However, when providing replica services, the HRCD allows multiple nodes within a stable set to participate in the service, whereas the HRCD-O only selects the “optimal” node. It is well established that a greater number of service nodes participating leads to better load balancing, explaining the HRCD’s advantage over the HRCD-O.

Meanwhile, from Figure 2, Figure 3 and Figure 4, we can observe that when the number of requests is relatively low during a unit of time, there is a difference between the two methods. However, as the number of requests increases, the gap between them gradually widens. This is due to the fact that when the request volume is low, a single “optimal” node participating in the service can effectively balance the load on the ES. However, as the number of requests grows, this “optimal” node gradually becomes overloaded and ceases to respond to further requests.

In summary, the HRCD and HRCD-O identify a stable set based on data access similarity and inherent attribute similarity and select “excellent” nodes within this set to place replicas. This approach helps reduce the load on ESs. Furthermore, the HRCD’s method of selecting multiple “optimal” nodes within the stable set to participate in replica services is more effective at balancing the system’s load compared to the HRCD-O, which only selects a single “optimal” node.

6.3.2. The Average Access Delay

Figure 8, Figure 9 and Figure 10 show the average access latency of different methods to verify the HRCD can obtain the lower access latency.

From Figure 8, Figure 9 and Figure 10, it is evident that the HRCD has the lowest access latency, while the ECRP exhibits the highest latency. Specifically, the HRCD has reduced the average access latency by 6 time units compared to the ECRP, and the HRCD-O has decreased it by approximately 3.5 time units. This is because both the HRCD and HRCD-O place replicas on UE, bringing the replica closer to the access source and thereby reducing access latency. When selecting a replica placement node, the HRCD prioritizes selecting multiple nodes with a higher similarity to the optimal virtual node based on the clustering situation. This approach not only considers the “optimal” node but also takes into account the load balancing within the stable set of the UE and the time-varying nature of nodes. In contrast, the HRCD-O only selects the node with the highest similarity to the virtual “optimal” node as the replica placement node, without considering the time-varying nature of the node and the load-balancing issue of UE nodes. Consequently, the average access latency of the HRCD is lower than that of the HRCD-O.

From Figure 8, Figure 9 and Figure 10, it is apparent that there is a close correlation between latency and the number of requests within a unit time. Specifically, as the number of requests increases, the access delay also rises. This trend is characterized by rapid growth in the early stages and relatively gradual changes in the later stages. The reason for this phenomenon is that as the number of requests increases, the load on the replica nodes gradually reaches a predetermined threshold, rendering them overloaded and unable to respond to further requests. In the early stages of request growth, the HRCD and HRCD-O primarily rely on the UE that host replicas use to respond to requests. Consequently, as the number of requests increases, the average access delay also increases rapidly. However, as the number of requests continues to grow, the UE becomes unable to handle all the requests, and they are increasingly processed by ESs. This shift in responsibility results in more gradual changes in access latency.

In summary, the HRCD can effectively reduce data access latency.

6.3.3. The Success Rate of Replica Accessing

Figure 11, Figure 12 and Figure 13 show the success rates of replica access for different methods under different requests to verify that the HRCD can ensure the success rate of replica access.

From Figure 11, Figure 12 and Figure 13, it is evident that the HRCD has a higher success rate for replica requests compared to the HRCD-O, with an improvement of approximately 3%. This advantage can be attributed to the method the HRCD employs for selecting replica creation objects. Specifically, the HRCD uses a uniform distribution to select hotspot data for replication, based on the proportion of requests for each type of data. This approach ensures that not only does hotspot data have a high probability of being replicated, but also that “sub-hot” data has a chance of being selected as a replica. In contrast, the HRCD-O selects hotspot data for replication solely based on the data request situation, in a sequential order. This method does not guarantee that “sub-hot” data will be replicated, which may limit its effectiveness in handling a diverse range of data requests. Consequently, when UE within the stable set requests data, the HRCD has a higher probability of successful replica requests due to its more inclusive and balanced approach to replica selection.

From Figure 12, we can observe a trend where the success rate decreases as the number of requests grows. This is because the load on the replica nodes gradually reaches a predetermined overload threshold as the number of requests increases within a unit of time, rendering them overloaded. At this point, the replica nodes are unable to respond to further requests, resulting in a decrease in the success rate of replica requests. Furthermore, Figure 13 reveals a strong correlation between the success rate and the overload threshold. Specifically, as the overload threshold increases, the success rate also rises. Recalling the definition of the success rate, which solely considers replicas on UE, it becomes clear that a higher overload threshold allows the UE to handle more requests. Consequently, the success rate increases in tandem with the overload threshold.

Moreover, the HRCD outperforms the HRCD-O even in this context, demonstrating its superiority in managing replica requests effectively.

6.3.4. The Replica Coefficient

Figure 14, Figure 15 and Figure 16 show the replica coefficients of different methods to verify that the HRCD can achieve better system performance with fewer replicas.

From Figure 14, Figure 15 and Figure 16, we can know that the replica coefficients increase with the number of requests. Since the request amounts are increasing, the number of replicas required to meet UE data access is increasing too. The replica coefficient will increase as the number of requests increases, too.

Meanwhile, from Figure 14, Figure 15 and Figure 16, we can also know that the replica coefficient of the HRCD is lower than that of the HRCD-O, and the gap between the two gradually increases as the number of requests increases. Compared to the HRCD-O, the HRCD has decreased by about 0.2 coefficients on average. Review the previous content. Since the data under edge servers has geographical locality characteristics, the data category frequently accessed within the communication area of ESs tends to be certain data categories. The HRCD first obtains the type of replica creation according to the request situation when selecting data to create new replicas. That is, it prioritizes selecting data with local features as replicas according to the request. The HRCD-O did not consider the principle that edge data of a given ES has geographic locality features but only selected data to create a replica according to the heat of the data, resulting in the selection of replica creation objects that may not match the geographical locality characteristics of the given ES. To meet the requirement of the data requested within the stable set, the HRCD-O needs to create more replicas. Therefore, compared to the HRCD, the HRCD-O has a higher replica coefficient.

6.3.5. Experimental Summary

Summarized in Table 1 (Section 2), existing replica placement methods primarily focus on edge servers (ESs) or end-devices (UE) separately. Compared to ES-based methods [12,14,23], the HRCD reduces average access latency by 2∼5% (Figure 2 and Figure 5) by leveraging hybrid placement. Unlike UE-based methods [19,20] that rely on predictive caching, the HRCD achieves 3% higher replica hit rates (Figure 11) through community-driven stable sets. Furthermore, the HRCD’s fuzzy clustering approach balances node load more effectively than hybrid methods [27,28], as shown in Figure 5. Meanwhile, compared to ES-based methods, the HRCD can achieve better system performance with fewer replicas too.

7. Conclusions

In large-scale 6G edge computing communities, placing replicas on ESs can significantly reduce data access latency for UE. However, the rapid growth in the amount of UE and ES communications has led to a progressive increase in the service pressure on ES, adversely impacting their service performance. To mitigate this issue, this article proposes placing replicas on UE to alleviate the service pressure on ESs. However, the time-varying nature of UE under Edge presents challenges in replica placement. To address this problem, this paper draws inspiration from community discovery algorithms and introduces a hybrid replica placement method called the HRCD. The HRCD aims to place replicas on both UE and ESs to balance system load and minimize data access latency. It begins by defining labels for UE and ESs based on data access patterns. UE records the labels of ESs they encounter during their movement in a distributed and adaptive manner. Using membership functions, the HRCD divides UE within the ES service area into multiple stable service sets based on the recorded labels and inherent attributes of the UE. Next, the HRCD employs fuzzy clustering analysis to select “excellent” node candidate sets as replica placement nodes within these stable sets. When choosing the replica creation object, the HRCD prioritizes hotspot data with geographic locality characteristics based on data access patterns. the HRCD also creates an appropriate number of replicas according to the load of ESs and UE, and selects replica placement nodes from the candidate set in the order determined by fuzzy clustering. Additionally, it places hotspot data within the ES service area directly on ESs to further reduce data access latency. Compared to ES/UE-based methods in Table 1, the HRCD uniquely integrates community division and fuzzy clustering to achieve load balancing (Section 6.3.1) and low latency (Section 6.3.2) in dynamic 6G edge environments.

Although the HRCD has demonstrated relatively superior performance compared to other similar methods under 6G Edge for large-scale community, it has a notable limitation: it not only places replicas on the UE but also redundantly on the ES. This approach has a high tendency to repeatedly deploy the same replicas, leading to a significant number of redundant replicas and a considerable waste of ES storage space. Additionally, the HRCD operates as a replica placement algorithm that requires nodes to engage in label exchange, replica management, and algorithm execution during their mobility. Meanwhile, the reliability of D2D communication (such as terminal disconnections, edge node failures, or unreliable communication links) also impacts the the HRCD replication strategy. These operations consume node resources, resulting in a decrease in service capacity. Therefore, in the future, we plan to conduct in-depth research on determining which replicas should be placed on ESs, as well as examining the energy consumption of nodes, to achieve a balanced optimization between storage utilization and system performance, and we also plan to conduct an in-depth study on the impact of D2D communication reliability on replica placement to better align with the needs of real-world scenarios.