Coded Caching Method in the Cooperative Scenario of Internet of Vehicles Users Based on Grouping Strategy
By building a decentralized coding cache system in the scenario of Internet of Vehicles users' cooperation, using grouping strategies and grouping accuracy adjustment, the expected code rate of the system is optimized, the problem of failure to effectively reduce network peak load in the existing technology is solved, and more efficient network resource utilization is achieved.
Patent Information
- Application Number
- CN202411278093.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-12
- Publication Date
- 2025-07-22
- Estimated Expiration
- 2044-09-12
AI Technical Summary
The existing coding cache system failed to effectively reduce the load during the peak period of network when considering user cooperation, and the upper bound of the code rate of the multi-access coding cache system is relatively loose, and it failed to make full use of communication opportunities between users.
In the scenario of Internet of Vehicles user cooperation, a coding cache method based on grouping strategy is adopted. By building a decentralized coding cache system, users can connect multiple roadside units and adjust user grouping and packet accuracy in the service stage to mine multicast opportunities and reduce the load of a single roadside unit.
Through user grouping and packet accuracy adjustment, the expected code rate of the system is optimized, the transmission rate required by the system is reduced, the utilization rate of network resources is improved, and the system performance is enhanced.
Smart Images

Figure CN119109951B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of vehicle-to-everything (V2X) communication, and more particularly to an encoding cache method in a vehicle-to-everything user cooperation scenario based on a grouping strategy. Background Art
[0002] Caching is a technology that pre-positions some content close to users to reduce the peak rate during network peak periods. By transferring some of the content that needs to be transmitted during peak periods to off-peak periods, the network load during peak periods can be reduced while the utilization rate of network resources during off-peak periods is improved. Encoding cache further reduces the peak rate by encoding the information placed and sent.
[0003] In the prior art, there is a classic encoding cache model, which includes a central server storing all N files each of size F bits, a noiseless multicast shared link connecting the server and all users, and K users equipped with caches. The cache size of each user is equal, all being MF bits. And assuming that the N files are requested with the same probability, such an encoding cache system is called a uniform system. The operation of the encoding cache system is divided into two phases. First is the placement phase, which occurs during the off-peak period of the network. In this phase, users pre-cache a part of the file content into their own cache spaces. According to the strategy of caching files in this phase, the encoding cache system is divided into two types. One is the centralized system, that is, the central server determines the content pre-cached by users; the other is the decentralized system, where users independently and randomly select the content to be pre-cached. After the placement phase ends, the system enters the service phase, which occurs during the peak period of the network. In this phase, users send file requests to the server, the server sends information to users according to the requests of all users, and users obtain the requested files based on the received information and the content pre-cached in the placement phase.
[0004] The expected code rate R(M) is used to describe the performance of a decentralized encoding cache scheme, that is, in the case of fixed system parameters N and K, the relationship between the expected code rate on the noiseless shared link and the user cache size. The expected code rate is the sum of the expected lengths of the information sent by the server on the noiseless shared link. The expected code rate of the above-mentioned decentralized encoding cache scheme is
[0005]
[0006] The multi-access code caching (MACC) system is an encoding cache system that allows users to access multiple cache spaces. In the MACC system, user i can access a total of L cache spaces, namely cache i, <i + 1>, …, <i + L - 1>, where
[0007]
[0008] As Figure 1 shown, a MACC system model with L = 2 is given. Additionally, when L = 1, the MACC system degrades to the above-mentioned classical coded caching system.
[0009] A rate upper bound for the decentralized MACC system
[0010]
[0011] Since this upper bound does not consider the case where the information generated by some user cooperation sets is invalid for the users therein, this upper bound is relatively loose. Summary of the Invention
[0012] The object of the present invention is to provide a coded caching method in a vehicle-to-everything (V2X) user cooperation scenario based on a grouping strategy to solve the problems existing in the above-mentioned background technology.
[0013] To achieve the above object, the present invention provides a coded caching method in a vehicle-to-everything (V2X) user cooperation scenario based on a grouping strategy, including the following steps:
[0014] S1. Construct a system model including a number of roadside units, and each roadside unit accesses a file set containing all N files The size of each file is F bits. Each roadside unit is connected to a number of users, and each user is equipped with a cache for caching M files. Each user can be connected to one or more roadside units during the service phase. At the same time, adjacent users can communicate with each other, that is, each user can access the caches of its two adjacent users. We focus on a roadside unit in the system and the users connected to it, and assume the number of users connected to the roadside unit is K;
[0015] S2. Construct and run a decentralized coded caching system, including
[0016] The placement phase, where each user independently and randomly selects a part of each file for caching;
[0017] The service phase, where each user connects to a number of roadside units according to its own conditions, synchronizes its cache information, request information, and connection information with the roadside unit, the roadside unit generates corresponding coded information based on the above information and sends it to the user, and the user decodes the received coded information and obtains the required file content.
[0018] Preferably, in the service phase, each user connects to a number of roadside units, adjacent users communicate with each other, and each user can access the caches of its two adjacent users.
[0019] Preferably, since each user may be connected to a different number of roadside units, a user grouping strategy and grouping precision adjustment are adopted in the service phase. Among them, the user grouping strategy is to divide users into different groups according to the number of roadside units to which the users are connected. The number of roadside units to which the users in each group are connected is the same, and multicast opportunities are mined within each user group; the grouping precision adjustment is to reduce the grouping precision so that some users with different but close numbers of connected roadside units are grouped into the same group for mining more multicast opportunities. In the service phase, users connected to multiple roadside units can evenly send requests to different roadside units to reduce the load on a single roadside unit. That is, the number of bits requested by user k in the service phase is F(1 - M / N). Let the number of roadside units to which user k is connected be I k , then the number of bits requested by it from each roadside unit is F(1 - M / N) / I k . For roadside units, since the number of bits requested by users connected to different numbers of roadside units is different, we group users according to the number of roadside units to which they are connected and mine multicast opportunities within each user group. Let the number of users connected to i roadside units among the users connected to the roadside unit be K i , i ∈ {1, 2, …, I}, where I is the number of roadside units to which the user with the largest number of connected roadside units is connected. We divide users into I groups. The users in the i-th group are connected to P i = i roadside units, denoted as The number of users in each user group is K i .
[0020] Considering that adjacent users can share their caches, and there are adjacent or non-adjacent users in each user group. Let the users in a user group be According to whether these users are continuously adjacent in the system, they can be further divided into multiple user subgroups. Let all continuously adjacent users be divided into one group. That is, after numbering users by location in the service phase, all users with consecutive integer numbers are divided into one subgroup. If the user group can be divided into J i user subgroups, denote these user subgroups as
[0021] In the service phase, we generate a piece of information for each user cooperation set and send it to the users in it, except for those user cooperation sets composed of only several adjacent users, because the users in them can always obtain the corresponding information from their adjacent users.
[0022] Preferably, the user grouping strategy is specifically as follows: Let the number of users connected to i roadside units among the users connected to the roadside unit be K i, where \(i\in\{1,2,\ldots,I\}\), and \(I\) is the number of roadside units connected by the user who is connected to the largest number of roadside units; the users are divided into \(I\) groups, and the users in the \(i\)-th group are connected to \(P \) i \(=i\) roadside units, denoted as The number of users in each user group is \(K \) i ; Since adjacent users share their caches, and there are adjacent or non - adjacent users in each user group, assume that the users in a user group are According to whether these users are continuously adjacent in the system, they are further divided into several user subgroups. Let all continuously adjacent users be divided into one group. After numbering the users by position in the service stage, all users with consecutive integer numbers are divided into one subgroup. If the user group is divided into \(J \) i user subgroups, denote these user subgroups as
[0023] In the service stage, generate a piece of information for each user cooperation set and send it to the users in it, except for the user cooperation sets composed of only several adjacent users.
[0024] Preferably, the upper bound of the expected code rate of the coded caching system in step S2 is:
[0025]
[0026] where \(p \) i \((s)\) and are respectively the number of invalid user cooperation sets of size \(s\) that span multiple user subgroups in the user group and the number of invalid user cooperation sets of size \(s\) in the user subgroup .
[0027] Preferably, since the information lengths corresponding to user cooperation sets of different sizes are also different, the number of invalid user cooperation sets needs to be calculated separately for all possible user cooperation set lengths \(s\). After selecting \(h\) user subgroups, denote the \(a\)-th user subgroup among them as Allocate the user cooperation set size \(s\) to each user subgroup. The length allocated to the \(a\)-th user subgroup is denoted as \(l \) a , which is
[0028]
[0029] For each user subgroup, the number of invalid user cooperation sets of length \(l \) a is Then the number of invalid user cooperation sets of size \(s\) that span multiple user subgroups contributed by these \(h\) user subgroups is
[0030]
[0031] For all h and other choices, and for all ways of distributing the lengths of the user cooperation sets, sum up the results to obtain the number p of invalid user cooperation sets of size s across multiple user groups i (s);
[0032] Therefore, the total number of valid user cooperation sets of size s is
[0033]
[0034] For all user cooperation set sizes s ∈ {K i , K i - 1, …, 2}, obtain the length of the information sent by the server
[0035]
[0036] When s = 1, each user cooperation set is the user itself, and the server transmits to user k That is, the part that none of the users have cached. There are K i users, and the total size of this part of the information is
[0037]
[0038] Preferably, the grouping precision adjustment is specifically as follows:
[0039] For user groups with a relatively small P i , it is more inclined to maintain the status quo. For user groups with a relatively large P i , we are more inclined to merge them with neighboring user groups to explore more multicast opportunities. Specifically, define a grouping precision function Δ(i) to determine which user groups will be merged. The input of the function is the user group number i, and all user groups with the same output will be merged. Through three different grouping precision functions, they are respectively
[0040] Δ original (i) = i,
[0041]
[0042] Δ non-grouping (i) = 1
[0043] Among them, Δ original (i) maintains the original grouping without any merging; Δ α (i) is a logarithmic grouping function, and α is an adjustable parameter used to adjust the grouping precision. The larger α is, the lower the grouping precision, that is, more user groups will be merged; Δ non-grouping (i) is Δ α(i) In the case where α approaches infinity, all user groups are combined without any grouping; after combining the user groups, the users within the user subgroup are divided into different user subgroups to explore multicast opportunities, but P i needs to be recalculated, that is, P i is the minimum value of the number of roadside units to which the users in the combined user group are connected.
[0044] Therefore, the present invention adopts the above-mentioned coding cache method in the vehicle-to-everything (V2X) user cooperation scenario based on the grouping strategy. Compared with the prior art, this application considers the situation of communication between users in the V2X scenario and also considers the case where a vehicle can be connected to multiple roadside units, making it more in line with the actual application scenario. And a service phase strategy based on user grouping is proposed. For all users connected to a roadside unit, the users are divided into different groups according to the number of roadside units to which the users are connected, so that the users connected to multiple roadside units can send requests to each roadside unit simultaneously, thereby reducing the rate required for a single roadside unit to transmit. In each user group, a calculation method for the invalid user cooperation set is given, thereby obtaining an upper bound of the system code rate. On the other hand, since user grouping will result in the loss of multicast opportunities, several grouping strategies are proposed. By adjusting the grouping accuracy and combining some user groups, a trade-off is sought between the consistency of the length of the coded information in the user cooperation set and the multicast opportunities, thereby obtaining a lower system code rate. Generally speaking, corresponding optimizations are made according to the characteristics of the proposed system model, reducing the expected code rate R(M) required by the system and obtaining better system performance.
[0045] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Description of the Drawings
[0046] Figure 1 It is a schematic diagram of the multi-access coding cache system model with L = 2 in the background technology of the present invention;
[0047] Figure 2 It is a schematic diagram of the system model of the present invention;
[0048] Figure 3 It is a schematic diagram of the results of N = 100, M = 30 in the system model simulation of the present invention;
[0049] Figure 4 It is a schematic diagram of the number of times that the three grouping strategies have the best performance at different user cache sizes M in 1000 simulations of the embodiment of the present invention;
[0050] Figure 5 It is a schematic diagram of the average code rate under the three grouping strategies in 1000 simulations of the embodiment of the present invention;
[0051] Figure 6 In the 1000 simulations of the embodiment of the present invention, it is a schematic diagram of the influence of the parameter α in the logarithmic grouping strategy on the system performance;
[0052] Figure 7 In the 1000 simulations of the embodiment of the present invention, it is a schematic diagram of the number of times when the parameter α in the logarithmic grouping strategy has the best performance at different user cache sizes M. Detailed implementation manners
[0053] Embodiment
[0054] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Usually, the components of the embodiments of the present invention described and illustrated in the accompanying drawings here can be arranged and designed in various different configurations. Figure 4 In the 1000 simulations of Embodiment 1 of the present invention, for the three grouping strategies at different user caches, the technical solutions in the embodiments of the present invention will be clearly and completely described. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Usually, the components of the embodiments of the present invention described and illustrated in the accompanying drawings here can be arranged and designed in various different configurations.
[0055] An encoding cache method in a vehicle-to-everything (V2X) user cooperation scenario based on a grouping strategy, comprising:
[0056] 1. System model
[0057] This embodiment considers a system model in a decentralized, multi-server adjacent user cooperation scenario, as Figure 2 shown, which includes a number of roadside units, each of which can access a file set containing all N files The size of each file is F bits. Each roadside unit is connected to a number of users, and each user is equipped with a cache capable of caching M files. Each user can be connected to one or more roadside units during the service phase. At the same time, adjacent users can communicate with each other, that is, each user can access the caches of its two adjacent users. This embodiment focuses on a roadside unit in the system and the users connected to it, and assumes that the number of users connected to the roadside unit is K. Considering a decentralized encoding cache system, that is, during the placement phase, each user independently and randomly selects a part of each file for caching. During the service phase, each user can connect to one or more roadside units according to its own conditions, and synchronize its cache information, request information, and connection information with the roadside unit. The roadside unit generates corresponding encoded information based on these information and sends it to the user, and the user decodes the received encoded information and obtains the required file content.
[0058] 2. Design of service phase
[0059] 2.1 User grouping strategy
[0060] Since each user may be connected to a different number of roadside units, a grouping strategy is considered in the service phase, that is, users are divided into different groups according to the number of roadside units they are connected to. Users within each group are connected to the same number of roadside units, and multicast opportunities are exploited within each user group.
[0061] In the service phase, users connected to multiple roadside units can evenly send requests to different roadside units to reduce the load on a single roadside unit. That is, the number of bits requested by user k in the service phase is F(1 - M / N). Let the number of roadside units that user k is connected to be I k , then the number of bits requested by it from each roadside unit is F(1 - M / N) / I k . For roadside units, since users connected to different numbers of roadside units request different numbers of bits, we group users according to the number of roadside units they are connected to, and exploit multicast opportunities within each user group. Among the users connected to a roadside unit, let the number of users connected to i roadside units be K i , i ∈ {1, 2, …, I}, where I is the number of roadside units that the user connected to the most roadside units is connected to. We divide users into I groups. Users in the i-th group are connected to P i = i roadside units, denoted as the number of users within each user group is K i .
[0062] Considering that adjacent users can share their caches, and there are adjacent or non - adjacent users within each user group. Let a user group have users According to whether these users are continuously adjacent in the system, they can be further subdivided into multiple user subgroups. Let all continuously adjacent users be grouped together. That is, after numbering users by position in the service phase, all users with consecutive integer numbers are grouped into one subgroup. If user group can be subdivided into J i user subgroups, denote these user subgroups as
[0063] In the service phase, generate a piece of information for each user cooperation set and send it to the users in it, except for those user cooperation sets composed of only several adjacent users, because the users in them can always obtain the corresponding information from their adjacent users. Table 1 shows the specific implementation process in the service phase.
[0064] Table 1
[0065]
[0066] Here, an upper bound on the expected code rate of the system proposed in this embodiment is given:
[0067]
[0068] where p i (s) and are the number of invalid user cooperation sets of size s that span multiple user subgroups and the number of invalid user cooperation sets of size s in the user subgroup respectively, as follows:
[0069] For a user cooperation set in a user group satisfying When the file size F is large enough, its expected length is server transmission information
[0070]
[0071] Considering the existence of adjacent users in the user group, when the user cooperation set consists of only several adjacent users, the information generated by this user cooperation set is useless for all users in it. Specifically, in a user subgroup, the number of invalid user cooperation sets of length s is
[0072]
[0073] Among them
[0074]
[0075] The users in the invalid user cooperation set may also span multiple user subgroups. In a user group, select any h ∈ {2, 3,..., J i}, and from each user subgroup, select an invalid user cooperation set arbitrarily. Then the union of these invalid user cooperation sets is also an invalid user cooperation set. Since the information lengths corresponding to user cooperation sets of different sizes are also different, we need to calculate the number of invalid user cooperation sets for each possible user cooperation set length s. That is, after selecting h user subgroups, denote the a-th user subgroup as Allocate the user cooperation set size s to each user subgroup, and denote the length allocated to the a-th user subgroup as l a , that is
[0076]
[0077] For each user subgroup, the number of invalid user cooperation sets of length l a is Then we can obtain the number of invalid user cooperation sets of size s that span multiple user groups contributed by these h user groups as
[0078]
[0079] For all h and possible selections, as well as all possible ways of distributing the lengths of user cooperation sets, summing up the results can obtain the number p(s) of invalid user cooperation sets of size s that span multiple user groups. The specific calculation process is given in Algorithm \ref{alg:ch4_p}. i (s), and the specific calculation process is given in Algorithm \ref{alg:ch4_p}.
[0080]
[0081] In summary, the total number of valid user cooperation sets of size s is
[0082]
[0083] For all user cooperation set sizes s ∈ {K i , K i - 1, …, 2}, the length of the information that the server needs to send can be obtained.
[0084]
[0085] When s = 1, each user cooperation set is the user itself. The server transmits to user k i.e., the part that none of the users have cached. There are K i users, and the total size of this part of the information is
[0086]
[0087] Thus, for all user groups, the above upper bound of the normalized system expected code rate in the service phase can be obtained.
[0088] In addition, denotes the number of invalid user cooperation sets of length s in a user group , that is, all users in it are adjacent to at least one other user in the cooperation set. In fact, this problem can be described as a combinatorial problem, that is, among consecutive integers, select s integers to form a set For each number k in , there is at least one adjacent integer, that is, k - 1 or k + 1 exists in the set . Our goal is to obtain the number of all possible sets . This problem is equivalent to inserting s elements into In each of the gaps, at least two elements need to be inserted into each gap to meet the above conditions. We divide the s elements into i groups. Each group contains at least two elements, thus transforming the problem into inserting i elements into gaps, and only one element can be inserted into each gap. For this problem, there are
[0089]
[0090] ways of insertion, which is the first term in the formula.
[0091] Secondly, we also need to determine how many choices there are when dividing l users into i groups. The result of this problem is the function f, which calculates the number of feasible choices when putting b elements into a positions, and any number of elements can be placed in each position. Obviously, when a = 1, we have only one choice, that is
[0092] f(1, b) = 1.
[0093] When a > 1, we solve this problem recursively. First, focus on the first position. If no element is placed in this position, then all b elements need to be placed in the remaining a - 1 positions, that is, there are f(a - 1, b) choices. If 1 element is placed in this position, then the remaining b - 1 elements need to be placed in the remaining a - 1 positions, that is, there are f(a - 1, b - 1) choices, and so on until all b elements are placed in the first position. We can get
[0094]
[0095] Note that f(j - 1, 0) = f(j - 2, 0) =... = f(1, 0) = 1, which gives the number of choices when all elements are placed in the first position.
[0096] Returning to the problem of calculating how many choices there are when dividing l users into i groups, since at least two elements are required in each group (i.e., each position), we need to place two elements in each position first, and then place the remaining s - 2i elements, that is, calculate the number of choices of placing s - 2i elements in i positions, that is, f(i, s - 2i), which is the second term in the formula. Thus, it is proved.
[0097] 2.2 Grouping Precision Adjustment
[0098] In fact, the grouping method will cause us to lose some multicast opportunities during the service phase. That is, we can only explore multicast opportunities within user groups, while the multicast opportunities between user groups are lost. In the above discussion, we divided users connected to different numbers of roadside units into different groups. This grouping method will result in the largest number of groups, ensuring that the information lengths corresponding to the user cooperation sets within the user subgroups are equal. However, it may result in the loss of many inter-group multicast opportunities. Therefore, we consider reducing the grouping precision so that some users connected to different but close numbers of roadside units are grouped together, thereby exploring more multicast opportunities and further reducing the system code rate.
[0099] It is easy to know that the more roadside units a user is connected to, the closer the information lengths corresponding to the user cooperation sets in the user groups connected to a similar number of roadside units will be. That is, when P i and P j are close in value, the larger P i and P j are, the closer their ratio is to 1. At this time, dividing the users in these two user groups into one group will result in less loss due to different information lengths. For example, when P i =1 and P j =2, their ratio P i / P j is 0.5, while when P i =5 and P j =6, their ratio is 0.83, which is closer to 1.
[0100] Therefore, for user groups with a smaller P i , we are more inclined to maintain the status quo, while for user groups with a larger P i , we are more inclined to merge them with nearby user groups to explore more multicast opportunities. Specifically, we define a grouping precision function Δ(i) to determine which user groups will be merged. The input of the function is the user group number i, and all user groups with the same output will be merged. We give three different grouping precision functions, which are
[0101] Δ original (i)=i,
[0102]
[0103] Δ non-grouping (i)=1.
[0104] Among them, Δ original (i) maintains the original grouping, that is, no merging is performed; Δ α (i) is a logarithmic grouping function, where α is an adjustable parameter used to adjust the grouping precision. The larger α is, the lower the grouping precision, that is, more user groups will be merged; Δnon-grouping (i) is for Δ α The case where α approaches infinity in (i), that is, all user groups are merged, which means no grouping is performed. After merging the user groups, we still divide the users within the user subgroups into different user subgroups according to the original method to explore multicast opportunities. However, at this time, the value of P in the formula code rate i needs to be recalculated, that is, P i is the minimum value of the number of roadside units to which the users in the merged user group are connected.
[0105] 3. Simulation Results
[0106] First, an intuitive result is presented. The system parameters are N = 100, K = 30, and users are connected to at most 7 roadside units. The specific connection situation and user grouping are as follows:
[0107]
[0108] As Figure 3 shown, the system code rates under different grouping strategies are presented, where Δ original is the original grouping strategy, that is, no merging is performed, Δ α is the logarithmic grouping strategy, where α is 2, \Δ non-grouping is no grouping, that is, all users are merged into one group. It can be seen from the figure that the grouping scheme has better performance than the non-grouping scheme in the region where M is smaller. As M increases, the scheme with lower grouping accuracy has better performance until the non-grouping scheme has the best performance.
[0109] When M is small, since the caches of adjacent users that each user can access are also small, the performance loss caused by the loss of inter-group multicast opportunities is small. We can consider that this part of the performance loss is due to not considering the caches of users outside the group that some users can access when generating information for some user cooperation sets. However, at this time, the load balancing effect brought by the grouping strategy has a greater impact on the system performance. Therefore, the original grouping strategy has better performance. As M increases, this part of the information volume gradually increases, and the impact on the system performance also gradually increases. Therefore, the strategy with low grouping accuracy has better performance at this time. As M further increases, the impact of this part of the information volume on the system performance gradually dominates. Therefore, the non-grouping strategy has the best performance.
[0110] Next, we perform multiple simulations on the same system settings. The system parameter settings are as follows: the number of files N = 50, the number of users K = 20, the maximum value I max = 7 of the number of roadside units to which each user is connected, and the number of roadside units to which each user is connected is randomly generated and follows a normal distribution, that is
[0111]
[0112] Take the absolute value of the result, round it, and limit it within the range of [1, I max to obtain the number of roadside units connected by the user. Since N > K, we assume that each user requests a different file. The following results are obtained from 1000 simulations of this system parameter.
[0113] Figure 4 Shows the number of times that among 1000 simulations, the three grouping strategies Δ original , Δ α , Δ non-grouping have the best performance on different user cache sizes M. The same as the conclusion above, when M < 0.02N approximately, the performance of the original grouping strategy is generally the best; when 0.02N < M < 0.14M approximately, the logarithmic grouping strategy with α = 2 can sometimes achieve the best performance; when M > 0.14N, the non-grouping strategy generally has the best performance.
[0114] Figure 5 Shows the average code rate under the three grouping strategies obtained after 1000 simulations. It can be seen that in terms of the average code rate, the performance of the logarithmic grouping strategy with α = 2 is worse than that of the original grouping strategy and the non-grouping strategy. In addition, since in each user group, the number of user cooperation sets grows exponentially with the number of users, as the grouping precision decreases, the computational overhead required by the system in the service phase will also increase, which may lead to an increase in communication delay in practical applications. Therefore, even though the non-grouping strategy has better performance in terms of code rate when M is large, in practical applications, the computational overhead and communication overhead can be comprehensively considered to select an appropriate grouping strategy.
[0115] Next, show the influence of the parameter α on the system performance in the logarithmic grouping strategy. To better show its influence, let the maximum value I of the number of roadside units connected by the user max = 24, and also conduct 1000 simulations.
[0116] Figure 6 Shows the average code rate of the logarithmic grouping strategy with different α after 1000 simulations, Figure 7 Shows the number of times that the logarithmic grouping strategy with different α has the best performance on different user cache sizes M. It can be seen from the figure that when M is small, the logarithmic grouping strategy with a smaller α has better performance. As M increases, the logarithmic grouping strategy with a larger α has better performance, which is consistent with the conclusion above. The difference is that the strategy with a larger α does not necessarily have better performance, but only has better expected performance in terms of probability, indicating that in practice, an appropriate α value needs to be selected according to specific system parameters, such as user connection conditions, user cache sizes, etc.
[0117] Therefore, the present invention adopts the above-mentioned coding cache method in the vehicle-to-everything (V2X) user cooperation scenario based on the grouping strategy, considering the communication situation among users in the V2X scenario and the situation where a vehicle can be connected to multiple roadside units simultaneously, making it more consistent with the actual application scenario.
[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that they can still modify or equivalently replace the technical solutions of the present invention, and these modifications or equivalent replacements cannot make the modified technical solutions deviate from the spirit and scope of the technical solutions of the present invention.
Claims
1. A coded caching method in a vehicle-to-everything (V2X) user cooperation scenario based on a grouping strategy, characterized in that Including the following steps: S1. Build a system model, which includes several roadside units. Each roadside unit accesses a file set containing all files, and the size of each file is bits. Each roadside unit is connected to several users, and each user is equipped with a cache for caching files; S2. Construct and run a decentralized coded caching system, including a placement phase, where each user independently and randomly selects a part of each file for caching; a service phase, where each user connects to several roadside units according to its own conditions, synchronizes its cached information, request information, and connection information with the roadside units, the roadside units generate corresponding coded information based on the above information and send it to the users, and the users decode according to the received coded information and obtain the required file content; In the service stage, a user grouping strategy and grouping precision adjustment are adopted, so that each user is connected to a different number of roadside units. The user grouping strategy is specifically as follows: Among the users connected to the roadside unit, the number of users connected to roadside units is , where is the number of roadside units connected by the user with the largest number of connected roadside units; the users are divided into groups. The users in the th group are connected to roadside units, denoted as . The number of users in each user group is ; Since adjacent users share their caches, and there are adjacent or non - adjacent users in each user group. Let the users in a user group be . According to whether these users are continuously adjacent in the system, they are further subdivided into several user subgroups. Let all continuously adjacent users be divided into one group. After numbering the users by location in the service stage, all users with consecutive integer numbers are divided into one subgroup. If the user group is subdivided into user subgroups, denote these user subgroups as ; In the service phase, generate a piece of information for each user cooperation set and send it to the users in the non-adjacent user cooperation sets; The upper bound of the expected coding rate of the coded caching system is: ; Among them, and are respectively the number of invalid user cooperation sets of size spanning multiple user subgroups in the user group and the number of invalid user cooperation sets of size in the user subgroup; where the invalid user cooperation set refers to a user cooperation set composed of several adjacent users.
2. The encoding cache method in the vehicle networking user cooperation scenario based on the grouping strategy according to claim 1, wherein: In the service phase, each user connects to several roadside units, and adjacent users communicate with each other, and each user can access the caches of its two adjacent users.
3. The coded caching method in the vehicle-to-everything (V2X) user cooperation scenario based on the grouping strategy according to claim 1, wherein: The user grouping strategy is to divide users into different groups according to the number of roadside units connected by the users. The number of roadside units connected by the users in each group is the same, and multicast opportunities are exploited within each user group; the grouping precision is adjusted to reduce the grouping precision so that some users with different but close numbers of connected roadside units are grouped into the same group for exploiting more multicast opportunities.
4. The coded caching method in the vehicle-to-everything (V2X) user cooperation scenario based on a grouping strategy according to claim 1, wherein: Since the information lengths corresponding to user cooperation sets of different sizes are also different, the lengths of all user cooperation sets are respectively calculated for the number of invalid user cooperation sets. After selecting user groups, denote the th user group among them as . Allocate the user cooperation set size to each user group. The length allocated to the th user group is denoted as . There is the following calculation formula between and the user cooperation set size: ; For each user group, the number of invalid user cooperation sets with a length of is . Then, the number of invalid user cooperation sets with a size of that span multiple user groups and are contributed by these user groups is ; For all user groups, and all ways of distributing the lengths of user cooperation sets, sum the results to obtain the number of invalid user cooperation sets of size across multiple user groups ; Therefore, the effective user cooperation set of size totally has ; For all user cooperation set sizes , obtain the message length sent by the server ; When each user cooperation set is the user himself, and the server transmits to user k, where represents the part that none of the users have cached. There are users in total, and the total size of this part of the information is 。 5. The encoding cache method in the vehicle networking user cooperation scenario based on a grouping strategy according to claim 3, wherein The adjustment of the grouping precision is specifically: Define a grouping precision function , which is used to determine which user groups will be merged. The input of the function is the user group number . All user groups with the same output will be merged. Through three different grouping precision functions, namely ; Among them, Keep the original grouping without any merging; is the logarithmic grouping function, is an adjustable parameter used to adjust the grouping precision; is in the case where tends to infinity, all user groups are merged without any grouping; after merging the user groups, the users within the user subgroups are divided into different user subgroups to explore multicast opportunities, but the value of needs to be recalculated .
Citation Information
Patent Citations
Code caching method under adjacent user cooperation scene based on code pre-storage
CN117336695A