Jitter budget allocation method and electronic device

Abstract

The disclosure provides a jitter budget allocation method and an electronic device, and belongs to the technical field of communication. The method comprises the following steps: determining a data transmission path from a vehicle device to a cloud server, the data transmission path comprising a plurality of transmission nodes; the vehicle device is the first transmission node, and the cloud server is the last transmission node; performing reverse traversal on the data transmission path, determining a target jitter budget of a transmission node according to running state information corresponding to the transmission node currently traversed, until the target jitter budgets of the remaining transmission nodes except the vehicle device are determined; determining the target jitter budget of the vehicle device according to a total jitter budget corresponding to the data transmission path and the target jitter budgets of the remaining transmission nodes; and allocating the target jitter budget of each transmission node in the data transmission path to the corresponding transmission node. The embodiment of the disclosure can improve the comprehensive utilization rate of the link.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a jitter budget allocation method and electronic device. Background Technology

[0002] In the transmission path from the vehicular domain to the cloud domain, jitter budgets need to be allocated to each transmission node in the path. Related technologies typically employ a static jitter budget allocation method, where the jitter budget is pre-calculated and remains fixed once the transmission path is established. However, this budget allocation method is difficult to adapt to the flexible movement of vehicles in connected vehicle scenarios, resulting in a significant discrepancy between the allocated jitter budget and the actual required budget.

[0003] In addition, there is a positive jitter budget allocation method from the vehicle to the cloud. In this method, the vehicle will make allocation decisions based on the locally perceived link status. This allocation method is prone to wasting jitter resources of the front-end transmission nodes in the transmission path, while the resources of the back-end transmission nodes are congested. It also cannot well adapt to the actual jitter budget requirements. Summary of the Invention

[0004] To address this, this disclosure provides a jitter budget allocation method and electronic device, which allocates jitter budget through a reverse resource allocation method, thereby improving the overall utilization rate of the link.

[0005] To achieve the above objectives, a first aspect of this disclosure provides a jitter budget allocation method applied to a cloud server. The method includes: determining a data transmission path from a vehicle device to the cloud server, the data transmission path including multiple transmission nodes; the vehicle device being the first transmission node and the cloud server being the last transmission node; performing a reverse traversal of the data transmission path, determining the target jitter budget for each transmission node based on its operating status information, until the target jitter budgets for the remaining transmission nodes excluding the vehicle device are determined; determining the target jitter budget for the vehicle device based on the total jitter budget corresponding to the data transmission path and the target jitter budgets of the remaining transmission nodes; and allocating the target jitter budget of each transmission node in the data transmission path to the corresponding transmission node.

[0006] In one optional implementation, the plurality of transmission nodes further include base stations and roadside equipment. The step of determining the target jitter budget for each transmission node based on its operational status information includes: if the currently traversed transmission node is a cloud server, determining the target jitter budget for the cloud server based on its computing power utilization, processing latency for inference tasks, and inference task queue depth; if the currently traversed transmission node is a base station, determining the target jitter budget for the base station based on its air interface resource utilization and air interface transmission latency; and if the currently traversed transmission node is a roadside equipment, determining the target jitter budget for the roadside equipment based on its gated queue depth and forwarding latency.

[0007] In one optional implementation, determining the target jitter budget of the vehicle equipment based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes includes: determining the target jitter budget of the vehicle equipment based on the total jitter budget, the target jitter budget of the cloud server, the target jitter budget of the base station, and the target jitter budget of the roadside equipment; the total jitter budget is determined based on the preset response time of the inference task, the processing latency of the inference task by the cloud server, and the preset security time corresponding to the cloud server.

[0008] In one optional implementation, the preset security duration is determined based on the task level of the inference task. After determining the target jitter budget of the vehicle device based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes, the method further includes: obtaining the minimum jitter budget of the vehicle device; if the target jitter budget of the vehicle device is less than the minimum jitter budget, reducing the task level of the inference task, or increasing the preset response duration of the inference task to increase the total jitter budget and increase the target jitter budget of the vehicle device.

[0009] In one optional implementation, determining the data transmission path from the vehicle device to the cloud server includes: determining a first data transmission path from the vehicle device to the cloud server; the method further includes: predicting a second data transmission path from the vehicle device to the cloud server after a first time; if the first data transmission path and the second data transmission path do not match, determining a target jitter budget for each transmission node in the second data transmission path; for any transmission node in the second data transmission path, determining a target transmission node of the same type as the corresponding transmission node in the first data transmission path; determining a comprehensive jitter budget based on the target jitter budget of the any transmission node and the target jitter budget of the target transmission node; and if the first data transmission path meets the path switching conditions, allocating the comprehensive jitter budget to the any transmission node and the target transmission node.

[0010] In one optional implementation, determining the overall jitter budget based on the target jitter budget of any transmission node and the target jitter budget of the target transmission node includes: taking the maximum budget value between the target jitter budget of any transmission node and the target jitter budget of the target transmission node as the overall jitter budget.

[0011] In one optional implementation, whether the first data transmission path meets the path switching condition is determined by the following method: the distance between the vehicle equipment and the signal coverage boundary of the transmission node in the first data transmission path is not greater than a first distance threshold; or, the difference between the first signal strength of the transmission node corresponding to the location of the vehicle equipment in the first data transmission path and the second signal strength of the transmission node corresponding to the location of the vehicle equipment in the second data transmission path is not greater than a second difference threshold.

[0012] In one optional implementation, after allocating the target jitter budget for each transmission node in the data transmission path to the corresponding transmission node, the method further includes: for any transmission node in the data transmission path, under the condition of satisfying the target jitter budget adjustment, performing an integral operation based on the difference between the target jitter budget of the transmission node and the required budget of the transmission node to obtain a budget adjustment value; adjusting the target jitter budget of the transmission nodes in the data transmission path according to the budget adjustment value to obtain an adjusted target jitter budget; and allocating the adjusted target jitter budget to the corresponding transmission node in the data transmission path.

[0013] In one optional implementation, the budget status of the transmission nodes in the data transmission path is set in the interaction message. The transmission nodes in the data transmission path transmit their budget status through the interaction message. Whether any transmission node in the data transmission path meets the target jitter budget adjustment condition is determined in the following way: if the budget status of any transmission node in the data transmission path is a budget mismatch state or a congestion state, it is determined that the transmission node meets the target jitter budget adjustment condition. The budget mismatch state is used to indicate that the difference between the demand budget of the transmission node and the target jitter budget of the transmission node is greater than a preset deviation threshold; the congestion state is used to indicate that the resource utilization rate of the transmission node is greater than a preset resource utilization rate threshold.

[0014] Secondly, this disclosure provides an electronic device comprising: one or more processors; a memory storing one or more programs that, when executed by the one or more processors, cause the one or more processors to implement the jitter budget allocation method described above; and one or more I / O interfaces connected between the processors and the memory, configured to enable information interaction between the processors and the memory.

[0015] This disclosure has the following advantages:

[0016] This disclosure provides a jitter budget allocation method and an electronic device. The method is applied to a cloud server. First, a data transmission path from a vehicle device to the cloud server is determined. This data transmission path includes multiple transmission nodes; the vehicle device is the first transmission node, and the cloud server is the last transmission node. Then, the data transmission path is traversed in reverse. Based on the operating status information corresponding to the currently traversed transmission nodes, the target jitter budget for each transmission node is determined until the target jitter budgets for the remaining transmission nodes (excluding the vehicle device) are determined. Second, based on the total jitter budget corresponding to the transmission path and the target jitter budgets of the remaining transmission nodes, the target jitter budget for the vehicle device is determined. Finally, the target jitter budget for each transmission node in the transmission path is allocated to the corresponding transmission node, thus achieving jitter budget allocation for each transmission node.

[0017] Therefore, this embodiment of the disclosure involves a cloud server performing reverse jitter budget allocation from the cloud to the vehicle. This embodiment first calculates the jitter requirements of the cloud server, then calculates the jitter budgets of intermediate transmission nodes in reverse order, and finally determines the jitter budget for the vehicle equipment based on the total budget and the jitter budgets of the other transmission nodes excluding the vehicle equipment. This achieves a jitter budget allocation method where the back-end transmission nodes determine the jitter budget, and the front-end transmission nodes adaptively allocate the jitter budget, avoiding the structural mismatch between front-end budget waste and back-end resource congestion, and improving the overall utilization rate of the link.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0020] Figure 1 A flowchart of a jitter budget allocation method provided in this disclosure embodiment;

[0021] Figure 2 A schematic flowchart illustrating a jitter budget allocation method provided in an embodiment of this disclosure;

[0022] Figure 3 This is a schematic diagram illustrating the application of a jitter budget allocation method provided in an embodiment of this disclosure;

[0023] Figure 4 A block diagram of a jitter budget allocation device provided in an embodiment of this disclosure;

[0024] Figure 5 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0025] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0026] As used in this disclosure, the term "and / or" includes any and all combinations of one or more of the related enumerated entries.

[0027] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. As used in this disclosure, the singular forms “a” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0028] When the terms “comprising” and / or “made of” are used in this disclosure, they specify the presence of the said feature, integral, step, operation, element and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or groups thereof.

[0029] Unless otherwise specified, all terms used in this disclosure (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so specified in this disclosure.

[0030] In related technologies, a static jitter budget allocation method is typically used. In this method, the jitter budget is pre-calculated and remains fixed once the transmission path is established. However, the above budget allocation method is difficult to adapt to the flexible movement of vehicles in the vehicle-to-everything (V2X) scenario, resulting in a significant difference between the allocated jitter budget and the actual required budget.

[0031] In addition, there is a positive jitter budget allocation method from the vehicle to the cloud. In this method, the vehicle will make allocation decisions based on the locally perceived link status. This allocation method is prone to wasting jitter resources of the front-end transmission nodes in the transmission path, while the resources of the back-end transmission nodes are congested. It also cannot well adapt to the actual jitter budget requirements.

[0032] In view of this, embodiments of this disclosure provide a jitter budget allocation method and an electronic device. The method is applied to a cloud server. First, a data transmission path from a vehicle device to the cloud server is determined, including multiple transmission nodes; the vehicle device is the first transmission node, and the cloud server is the last transmission node. Then, the data transmission path is traversed in reverse, and the target jitter budget for each transmission node is determined based on the operating status information corresponding to the currently traversed transmission node, until the target jitter budgets for the remaining transmission nodes (excluding the vehicle device) are determined. Second, the target jitter budget for the vehicle device is determined based on the total jitter budget corresponding to the transmission path and the target jitter budgets of the remaining transmission nodes. Finally, the target jitter budget for each transmission node in the transmission path is allocated to the corresponding transmission node, thus realizing the jitter budget allocation for each transmission node.

[0033] Therefore, this embodiment of the disclosure involves a cloud server performing reverse jitter budget allocation from the cloud to the vehicle. This embodiment first calculates the jitter requirements of the cloud server, then calculates the jitter budgets of intermediate transmission nodes in reverse order, and finally determines the jitter budget for the vehicle equipment based on the total budget and the jitter budgets of the other transmission nodes excluding the vehicle equipment. This achieves a jitter budget allocation method where the back-end transmission nodes determine the jitter budget, and the front-end transmission nodes adaptively allocate the jitter budget, avoiding the structural mismatch between front-end budget waste and back-end resource congestion, and improving the overall utilization rate of the link.

[0034] In a first aspect, embodiments of this disclosure provide a jitter budget allocation method. Figure 1 A flowchart of a jitter budget allocation method provided in this disclosure embodiment is shown below. Figure 1 The method includes:

[0035] Step S110: Determine the data transmission path from the vehicle equipment to the cloud server. The data transmission path includes multiple transmission nodes; the vehicle equipment is the first transmission node, and the cloud server is the last transmission node.

[0036] The data transmission path from the vehicle equipment to the cloud server refers to the data transmission link from the vehicle equipment to the cloud server. This data transmission path includes multiple transmission nodes, each responsible for processing and forwarding the data stream.

[0037] Specifically, the data transmission path from the vehicle device to the cloud server can be determined by obtaining the current end-to-end path [Path[]. For example, the end-to-end path [Path[]] is: Therefore, the data transmission path includes the following transmission nodes: vehicle equipment, roadside unit (RSU), next generation node (gNB), and cloud server.

[0038] The vehicle terminal is the first transmission node in the data transmission path, and the cloud server is the last transmission node in the data transmission path.

[0039] Step S120: Perform reverse traversal of the data transmission path, and determine the target jitter budget of the transmission node based on the running status information corresponding to the currently traversed transmission node, until the target jitter budget of the remaining transmission nodes other than the vehicle equipment is determined.

[0040] In this context, reverse traversal of the data transmission path refers to starting from the last transmission node and proceeding node by node towards the first transmission node. Accordingly, in the data transmission path example above, the nodes traversed in sequence are the cloud server, base station, roadside equipment, and vehicle equipment.

[0041] The operational status information corresponding to the transmission node refers to operational parameters reflecting the forwarding capability and congestion level of the transmission node. For example, the operational status information corresponding to the cloud server may include computing power utilization, processing latency for inference tasks, and inference task queue depth. The operational status information corresponding to the base station may include air interface resource utilization and air interface transmission latency. The operational status information corresponding to the roadside equipment may include gating queue depth and forwarding latency; this disclosure does not impose limitations on these aspects.

[0042] Accordingly, the target jitter budget for a transmission node can be determined based on its operational status information. In this step, by traversing the data transmission path in reverse, the target jitter budgets for transmission nodes other than vehicle equipment can be determined from the cloud server. The target jitter budget for a transmission node refers to the jitter budget to be allocated to that transmission node.

[0043] In one optional implementation, the multiple transmission nodes also include base stations and roadside equipment. Based on the operational status information of the currently traversed transmission nodes, the target jitter budget for each transmission node is determined, including: if the currently traversed transmission node is a cloud server, the target jitter budget for the cloud server is determined based on its computing power utilization, processing time for inference tasks, and inference task queue depth; if the currently traversed transmission node is a base station, the target jitter budget for the base station is determined based on its air interface resource utilization and air interface transmission latency; if the currently traversed transmission node is a roadside equipment, the target jitter budget for the roadside equipment is determined based on its gated queue depth and forwarding latency.

[0044] Specifically, the target jitter budget for the cloud server can be calculated using the following formula:

[0045] Formula (1)

[0046] in, The target jitter budget for the cloud server. This refers to the jitter coefficient corresponding to the GPU of the cloud server. The value of can be adaptively set according to the actual application needs, and the embodiments disclosed herein do not impose any limitations on this. For example, The value is 1.5.

[0047] in, This refers to the processing latency of the inference task on the cloud server. The magnitude of this latency is related to the GPU load and can be obtained through dynamic measurement. This refers to the computing power utilization rate of the cloud server, specifically the real-time utilization rate of the cloud server's GPU. This computing power utilization rate can be reported by the MEC Agent module in the cloud server. For the single-server queuing model M / M / 1, the higher the computing power utilization, the larger the required jitter budget.

[0048] in, Queue jitter coefficient for cloud servers represents the additional queuing delay caused to subsequent data frames when each new frame of business data to be processed is added to the queue, under the condition that the current scheduling strategy remains unchanged. The value of can be adaptively set according to the actual application needs, and the embodiments disclosed herein do not impose any limitations on this. For example, The value is 0.1ms / frame, or... The value is determined by the pipeline parallelism, priority scheduling strategy, and memory access mode of the cloud server.

[0049] in, This refers to the inference task queue depth (i.e., the number of queued frames) on the cloud server, which can be reported by the MEC Agent module in the cloud server. For example, It is 10 frames.

[0050] Specifically, the cloud server includes an MEC Agent module and a JBA-Controller module. The MEC Agent module is used to perform inference tasks, and the JBA-Controller module is used to execute the jitter budget allocation method of this disclosure embodiment.

[0051] Specifically, the target jitter budget for a base station can be calculated using the following formula:

[0052] Formula (2)

[0053] in, For the target jitter budget of the base station, This is the air interface congestion coefficient. The value of can be adaptively set according to the actual application needs, and the embodiments disclosed herein do not impose any restrictions on it. The air interface resource utilization rate of the base station is collected and statistically analyzed by the PM-TSN performance counter built into the gNB base station. This reflects the air interface load level. The 5G NR radio time slot period is the basic time unit for gNB base stations to perform radio resource scheduling. For example... The value is 0.125ms. These are the modulation and coding coefficients, which are related to the air interface MCS, for example, The value is 1.2. Wherein, For TSN service stream frame length, This refers to the UE's instantaneous transmission rate (i.e., the air interface instantaneous rate). Characterizes the air interface transmission delay of a single frame (i.e., the air interface transmission delay of the base station in this embodiment of the present disclosure).

[0054] It should be noted that gNB base stations can report air interface measured status indicators, such as..., to TSCTSF via the gNB-TSCTSF control plane interface. MCS The TSCTSF sends the air interface status indicator values ​​to the cloud server.

[0055] Specifically, the target jitter budget for roadside equipment can be calculated using the following formula:

[0056] Formula (3)

[0057] in, For the target jitter budget of roadside equipment, This is the roadside queue coefficient, and its value can be adaptively set according to actual application needs, for example... The value is 1.0. This is the gating queue depth (i.e., the RSU queue depth), which can be obtained through the 802.1Qbv gating status.

[0058] in, The current flow gating cycle can be selected via the flow cycle P_cycle constraint. For example, It belongs to {125μs, 250μs, 500μs} and must satisfy the following conditions: , . The values ​​are as follows: Camera 33.3ms@30fps, Radar 100ms@10Hz.

[0059] in, This is the single-hop forwarding delay coefficient, and its value can be adaptively set according to the actual application needs. For example, The value is 2μs. This represents the number of hops for the roadside switch, i.e., the number of hops for the RSU switch. This refers to the single-hop forwarding delay, i.e., the single-hop processing delay of the RSU switch. Correspondingly, This refers to the cumulative multi-hop forwarding delay of the switch, which is also the forwarding delay of the roadside device in this embodiment.

[0060] in, This represents the current path hop count, which is the number of nodes in the data transmission path. This refers to the single-hop cross-domain transit delay, and its value can be adaptively set according to the actual application requirements. For example, The value is 5 μs. This is the cross-domain conversion delay coefficient, and its value can be adaptively set according to the actual application requirements. For example... The value is 1.5. That is to say, The term represents the cross-domain boundary (such as RSU). gNB, gNB Protocol conversion and queuing delay of UPF.

[0061] In this embodiment of the disclosure, the target jitter budget for each domain—cloud domain, air interface domain, and roadside domain—can be calculated specifically using the device's operating status information, thereby improving the accuracy of the target jitter budget calculation.

[0062] Step S130: Determine the target jitter budget for the vehicle equipment based on the total jitter budget corresponding to the data transmission path and the target jitter budget for the remaining transmission nodes.

[0063] The total jitter budget for the data transmission path refers to the jitter budget that can be allocated to all transmission nodes in the transmission path. The total jitter budget can be determined based on the preset response time of the inference task, the processing latency of the inference task by the cloud server, and the preset security time of the cloud server.

[0064] The target jitter budget for the vehicle equipment can be determined by the difference between the total jitter budget corresponding to the data transmission path and the target jitter budget for the remaining transmission nodes.

[0065] In one optional implementation, the target jitter budget of the vehicle equipment is determined based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes. This includes: determining the target jitter budget of the vehicle equipment based on the total jitter budget, the target jitter budget of the cloud server, the target jitter budget of the base station, and the target jitter budget of the roadside equipment; the total jitter budget is determined based on the preset response time of the inference task, the processing latency of the cloud server for the inference task, and the preset security time corresponding to the cloud server.

[0066] The target jitter budget for vehicle equipment can be determined using the following formula:

[0067] Formula (4)

[0068] in, Budget for target vibration of vehicle equipment. For the total jitter budget, The target jitter budget for the cloud server. For the target jitter budget of the base station, Budget for target vibration of roadside equipment.

[0069] Furthermore, the total jitter budget for the data transmission path is determined by the following formula:

[0070] Formula (5)

[0071] in, The preset response time for the inference task, i.e. the deadline for the inference task, such as 20ms. This refers to the processing latency of the inference task on the cloud server. This is the preset security duration for the cloud server. Its value can be dynamically adjusted according to the task level of the inference task. For example, its value is 2 ms.

[0072] In this embodiment of the disclosure, the total jitter calculation is determined by comprehensively considering the preset response time of the inference task, the processing latency of the cloud server for the inference task, and the preset security time corresponding to the cloud server. This improves the accuracy of the total jitter budget calculation. By using the total jitter budget, the target jitter budget of the cloud server, the target jitter budget of the base station, and the target jitter budget of the roadside equipment, the target jitter budget of the vehicle equipment is determined. This allows for a reasonable allocation of the jitter budget of the vehicle equipment while ensuring the jitter budget allocation of the downstream transmission nodes.

[0073] In one optional implementation, the preset security duration is determined based on the task level of the inference task. After determining the target jitter budget of the vehicle device based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes, the method further includes: obtaining the minimum jitter budget of the vehicle device; if the target jitter budget of the vehicle device is less than the minimum jitter budget, reducing the task level of the inference task, or increasing the preset response duration of the inference task to increase the total jitter budget and increase the target jitter budget of the vehicle device.

[0074] The preset safety duration is determined based on the task level of the reasoning task; the higher the task level, the longer the preset safety duration.

[0075] The minimum jitter budget for the vehicle equipment refers to the basic jitter budget of the vehicle equipment in a congestion-free scenario. That is, the minimum jitter budget for the vehicle equipment is the lowest constraint value of the jitter budget that the vehicle equipment needs to be allocated. The minimum jitter budget for the vehicle equipment can be adaptively set according to actual application needs, and this disclosure does not impose any restrictions on this. For example, the minimum jitter budget for the vehicle equipment... The duration is 50 μs.

[0076] Accordingly, if the target vibration budget of the vehicle equipment Less than minimum jitter budget This can trigger renegotiation. For example, by reducing the task level of the inference task to decrease the preset safety duration, the total jitter budget corresponding to the data transmission path can be increased. Alternatively, by requesting an extension of D_AI from the application layer to increase the preset response time of the inference task, the total jitter budget corresponding to the data transmission path can be increased. Since the total jitter budget increases, while the target jitter budget of the remaining transmission nodes remains unchanged, the target jitter budget of the vehicle equipment can also increase, thus meeting the allocation requirement of the minimum jitter budget.

[0077] In this embodiment of the disclosure, if the total jitter budget corresponding to the data transmission path is not large enough, the target jitter budget of the vehicle device may be very small after deducting the target jitter budget of the remaining transmission nodes, which may result in the vehicle device's minimum jitter budget not being met. In this case, the total jitter budget can be adjusted so that the vehicle device's target jitter budget can meet its minimum jitter budget requirement.

[0078] In one alternative implementation, the target jitter budget of the vehicle equipment can also be constrained by the flow cycle, as shown in the following formula:

[0079] Formula (6)

[0080] In other words, in this embodiment of the disclosure, even if D_AI allows a larger total budget, a single frame cannot exceed its own stream cycle P_cycle in order to avoid the phenomenon of frame stacking. Accordingly, after determining the target jitter budget of the vehicle device, if the constraint of the above formula (6) is not met, renegotiation can be triggered to request the application function AF (Application Function) to reduce the frame rate or extend P_cycle in order to meet the constraint of the above formula (6).

[0081] Step S140: Allocate the target jitter budget for each transmission node in the data transmission path to the corresponding transmission node.

[0082] In this step, after determining the target jitter budget for each transmission node in the data transmission path, the target jitter budget can be encapsulated into a YANG data model and distributed to the corresponding transmission nodes via RESTCONF (a network device configuration protocol based on HTTPS). Thus, each transmission node performs queue management and time slot scheduling based on its own target jitter budget.

[0083] This disclosure provides a jitter budget allocation method, in which a cloud server performs a reverse jitter budget allocation from the cloud to the vehicle. This method first calculates the jitter requirements of the cloud server, then calculates the jitter budgets of intermediate transmission nodes in reverse order, and finally determines the jitter budget for the vehicle equipment based on the total budget and the jitter budgets of the other transmission nodes excluding the vehicle equipment. This achieves a jitter budget allocation method where the back-end transmission nodes determine the jitter budget, and the front-end transmission nodes adaptively allocate the jitter budget, avoiding the structural mismatch between front-end budget waste and back-end resource congestion, and improving the overall utilization rate of the link.

[0084] In one optional implementation, determining the data transmission path from the vehicle device to the cloud server includes: determining a first data transmission path from the current vehicle device to the cloud server; the method further includes: predicting a second data transmission path from the vehicle device to the cloud server after a first time; if the first data transmission path and the second data transmission path do not match, determining a target jitter budget for each transmission node in the second data transmission path; for any transmission node in the second data transmission path, determining a target transmission node of the same type as any transmission node in the first data transmission path; determining a comprehensive jitter budget based on the target jitter budget of any transmission node and the target jitter budget of the target transmission node; and, if the first data transmission path meets the path switching conditions, allocating the comprehensive jitter budget to any transmission node and the target transmission node.

[0085] Specifically, a preset trajectory prediction model can be used to predict the second data transmission path from the vehicle equipment to the cloud server after the first time interval. The size of the first time interval can be adaptively set according to actual application needs; this embodiment does not limit this, for example, the first time interval can be 100ms.

[0086] The preset trajectory prediction model can be a trained LSTM (Long Short-Term Memory) model. Specifically, the vehicle's location information within a historical time interval, the roadside unit (RSU) topology information, and the load information of neighboring gNB base stations can be input into the preset trajectory prediction model to obtain the second data transmission path from the vehicle to the cloud server after the first time interval. The historical time interval refers to a historical time series window, and its size can be adaptively set according to actual application needs; this embodiment does not impose any limitations on this. For example, the historical time interval could be the past 2 seconds.

[0087] The predicted second data transmission path from the vehicle device to the cloud server after the first time interval can be one or more, and this embodiment does not limit this. For example, the top-3 target RSU / gNB combinations most likely to be accessed by the vehicle within the next 100 ms can be selected to determine multiple second data transmission paths.

[0088] Specifically, the transmission nodes in the first data transmission path and the second data transmission path can be compared. Based on the comparison result, it can be determined whether the first data transmission path and the second data transmission path match. If the first data transmission path and the second data transmission path do not match, it indicates that the vehicle equipment may switch its current data transmission path. Therefore, the temporary jitter budget value of the transmission node can be determined first, which is to say, the target jitter budget of the transmission node can be determined.

[0089] Specifically, for any transmission node in the second data transmission path, a target transmission node of the same type as that transmission node is determined in the first data transmission path. For example, the roadside equipment in the second data transmission path corresponds to the same type as the roadside equipment in the first transmission path, and the base station in the second data transmission path corresponds to the same type as the base station in the first transmission path. Accordingly, a comprehensive jitter budget can be determined based on the target jitter budget of any transmission node and the target jitter budget of the corresponding target transmission node. For example, the comprehensive jitter budget can be obtained by superimposing the two budgets. Alternatively, the comprehensive jitter budget can be obtained by taking the maximum value of the two budgets; this embodiment of the present disclosure does not limit this approach.

[0090] In cases where there are multiple second data transmission paths, a step can be performed to determine the comprehensive jitter budget corresponding to each transmission node for each data transmission path.

[0091] Accordingly, if the first data transmission path meets the path switching conditions for switching to the second data transmission path, then for each transmission node in the second data transmission path, the comprehensive jitter budget corresponding to that transmission node is allocated to that transmission node, as well as a target transmission node of the same type as that transmission node in the first data transmission path.

[0092] In this embodiment of the disclosure, by predicting the data transmission path of the vehicle equipment in the future, if the data transmission path does not match the current data transmission path of the vehicle equipment, a comprehensive jitter budget is determined. If the data transmission path switching conditions are met, the comprehensive jitter budget is allocated to the corresponding node of the current data transmission path before the switch and the corresponding node of the data transmission path after the switch, thereby eliminating the budget vacuum during the path switching period and avoiding frame loss during the path switching period.

[0093] In one optional implementation, a comprehensive jitter budget is determined based on the target jitter budget of any transmission node and the target jitter budget of the target transmission node, including: taking the maximum budget value between the target jitter budget of any transmission node and the target jitter budget of the target transmission node as the comprehensive jitter budget.

[0094] For example, the overall jitter budget is determined by the following formula:

[0095] Formula (7)

[0096] in, The overall jitter budget for any transmission node in the second data transmission path. For the target jitter budget of any transmission node in the second data transmission path. This is the target jitter budget for target transmission nodes of the same type as any transmission node in the first data transmission path and the second data transmission path. This is a budget overlay factor used to determine the budget overlay factor. and The maximum value in, as .

[0097] After determining the overall jitter budget, if the first data transmission path meets the path switching conditions for switching to the second data transmission path, the overall jitter budget is allocated to the corresponding nodes of the first data transmission path before the switch and the corresponding nodes of the second data transmission path after the switch. During the path switching, data frames from the corresponding transmission nodes of both the first data transmission path before the switch and the second data transmission path after the switch can be received simultaneously. Duplicate frames can be deduplicated according to their sequence numbers to ensure zero frame loss.

[0098] In one alternative implementation, after the data transmission path switching is completed, the steps of determining the data transmission path from the vehicle equipment to the cloud server, performing reverse traversal of the data transmission path, re-determining the target jitter budget for the transmission nodes in the switched data transmission path, and reallocating the budget can be performed.

[0099] In one optional implementation, whether the first data transmission path meets the path switching condition is determined by the following method: the distance between the vehicle equipment and the signal coverage boundary of the transmission node in the first data transmission path is not greater than a first distance threshold; or, the difference between the first signal strength of the transmission node in the first data transmission path corresponding to the location of the vehicle equipment and the second signal strength of the transmission node in the second data transmission path corresponding to the location of the vehicle equipment is not greater than a second difference threshold.

[0100] The specific value of the first distance threshold can be adaptively set according to actual application needs, and this embodiment does not impose any limitations on it. For example, the first distance threshold is 200 meters. When the distance between the vehicle equipment and the signal coverage boundary of the RSU transmission node of the first data transmission path is less than 200 meters, it indicates that the target vehicle has reached the current RSU coverage boundary in a short period of time, and at this time it can be determined that the first data transmission path meets the path switching conditions.

[0101] The specific value of the second difference threshold can be adaptively set according to actual application needs, and this embodiment does not limit it. For example, the second difference threshold is 3dB. For example, when the second signal strength (RSRP) of the target RSU in the second data transmission path corresponding to the location of the vehicle equipment is greater than the first signal strength of the current RSU in the first data transmission path − 3dB, it is determined that the first data transmission path meets the path switching condition.

[0102] In this embodiment of the disclosure, the accuracy of determining whether the first data transmission path meets the path switching conditions is improved by using signal coverage boundary and signal strength parameters.

[0103] In one optional implementation, after allocating the target jitter budget for each transmission node in the data transmission path to the corresponding transmission node, the method further includes: for any transmission node in the data transmission path, under the condition of satisfying the target jitter budget adjustment, performing an integral operation based on the difference between the target jitter budget of the transmission node and the required budget of the transmission node to obtain a budget adjustment value; adjusting the target jitter budget of the transmission nodes in the data transmission path according to the budget adjustment value to obtain the adjusted target jitter budget; and allocating the adjusted target jitter budget to the corresponding transmission node in the data transmission path.

[0104] The above process can also be called a fast budget reconstruction process. To improve the efficiency of adjusting the target jitter budget, fast budget reconstruction can be used for budget adjustment. Under the fast budget reconstruction process, the target jitter budget can be adjusted only for a portion of the transmission nodes in the data transmission path.

[0105] The budget adjustment value can be determined using the following formula:

[0106] Formula (8)

[0107] in, This is the budget adjustment value. This is a preset scaling factor for rapid response, the value of which can be adaptively set according to actual application needs. This embodiment does not limit this setting; for example, a value of 0.6 may be used. , Budget for the needs of transmission nodes, The target jitter budget for the transmission node. The preset integral coefficient is used to eliminate steady-state error. Its size can be adaptively set according to the actual application needs. This embodiment does not limit this. For example, the value is 0.1 / s.

[0108] The budget adjustment value is determined according to the above formula (8), and the target jitter budget of the transmission node in the data transmission path is adjusted based on the budget adjustment value to obtain the adjusted target jitter budget. For example, if the target jitter budget of the roadside equipment meets the adjustment conditions, its budget adjustment value is determined, and the original target jitter budget of the roadside equipment is adjusted based on the budget adjustment value to obtain the adjusted target jitter budget. The adjusted target jitter budget is then redistributed to the roadside equipment.

[0109] After the rapid budget reconstruction process is completed, the BSI status value can be set to 000, thereby transitioning to the normal BSI budget status monitoring process.

[0110] In one optional implementation, the budget status of transmission nodes in the data transmission path is set in the interaction message. The transmission nodes in the data transmission path transmit their budget status through the interaction message. Whether any transmission node in the data transmission path meets the target jitter budget adjustment condition is determined in the following way: if the budget status of any transmission node in the data transmission path is a budget mismatch state or a congestion state, it is determined that the transmission node meets the target jitter budget adjustment condition. The budget mismatch state is used to indicate that the difference between the target jitter budget and the demand budget of the transmission node is greater than a preset deviation threshold; the congestion state is used to indicate that the resource utilization of the transmission node is greater than a preset resource utilization threshold.

[0111] The BSI field can be embedded in the gPTP Follow_Up message and flow with the interaction messages to realize the transmission of the budget status of the transmission node. The BSI field represents the budget status of the transmission node.

[0112] For example, the budget status can be characterized by a three-bit BSI (Budget Status Indicator) field. For instance, a BSI of 000 indicates a normal budget status, meaning that the required budget of the transmission node is approximately equal to the target jitter budget. In this case, each transmission node in the data transmission path can execute according to its allocated target jitter budget without budget adjustment.

[0113] A BSI of 001 indicates a budget insufficiency state, also known as a budget mismatch state. In this case, the difference between the required budget of the transmission node and the target jitter budget exceeds a preset deviation threshold. Local compensation, such as increasing the gating window, can be triggered under these circumstances.

[0114] A BSI value of 010 indicates a budget overflow state, where the required budget of the transmission node is less than half of the target jitter budget. In this case, resource reclamation can be triggered, such as releasing bandwidth to other flows.

[0115] A BSI of 011 indicates that the budget state is in a topology switching state, meaning that the path switching is currently underway. In this case, the transmission node can use the allocated integrated jitter budget.

[0116] A BSI of 100 indicates a congested state, where the resource utilization of the transmission nodes exceeds a preset resource utilization threshold. In this case, global rate reduction can be implemented to ensure control flow.

[0117] A BSI of 101 indicates that the budget is in a recalculation state, meaning the cloud server is performing the aforementioned rapid budget reconstruction process. In this case, each transmission node can maintain its current gating parameters and wait for the adjusted target jitter budget.

[0118] A BSI of 110 indicates that the budget state is in a synchronized state. At this time, the gating cycle needs to be re-aligned so that each transmission node can perform TAI time alignment.

[0119] BSI is 111, which can be set as a reserved value. Its meaning can be extended according to the actual application needs, and this disclosure does not limit it.

[0120] Accordingly, the budget status transmission process for transmission nodes is as follows:

[0121] Step 1: The vehicle equipment (T-Box) embeds the BSI in the gPTP Sync / Follow_Up message and sends it to the roadside unit (RSU).

[0122] Step 2: The roadside unit (RSU) parses the gPTP BSI, updates the local gating period, and forwards the TSN frame to the base station-side TSN converter gNB-TT by encapsulating the TSN frame with the gPTPBSI.

[0123] Step 3: The base station gNB extracts the BSI carried in the message, embeds the field into the RRC signaling and reports it to the TSCF, and maps the TSN service frame to the corresponding 5G QoS data stream. When the base station performs air interface radio resource time slot scheduling, it uses the BSI as the priority reference.

[0124] Step 4: The MEC Agent module of the cloud server receives the data frame, extracts the BSI carried by it, and reports it to the JBA-Controller module of the cloud server. Accordingly, the JBA-Controller module can summarize the BSI status of the vehicle domain, roadside domain, air interface domain, and cloud domain. If there is a budget mismatch status, i.e., UNDER_BUDGET(001), or a congestion status, i.e., DEGRADE(100), it is determined that the transmission node meets the target jitter budget adjustment conditions. At this time, the above-mentioned fast budget reconstruction process can be executed.

[0125] By performing the above-described rapid budget reconstruction process, the adjusted target jitter budget can be obtained, and the adjusted target jitter budget can be allocated to the corresponding transmission nodes in the data transmission path.

[0126] For example, the JBA-Controller module of the cloud server sends the adjusted target jitter budget from the cloud server to the MEC Agent module. The JBA-Controller module then reconfigures the base station parameters and modifies the BSI status bits via 5G radio RRC signaling. Correspondingly, the base station adjusts its radio time slot scheduling rules based on the adjusted target jitter budget. The JBA-Controller module also adjusts the 802.1Qbv gating scheduling window of the roadside unit (RSU) and updates the gating list. Finally, the JBA-Controller module carries the adjusted target jitter budget of the vehicle equipment based on the clock synchronization message gPTPFollow_Up. Upon receiving the message, the vehicle equipment can modify the gating parameters and adjust the transmission phase of service frames according to the adjusted target jitter budget.

[0127] The preset deviation threshold can be adaptively set according to actual application needs, and this embodiment does not limit it. For example, the preset deviation threshold is 50 μs, thereby... In such cases, if the budget is determined to be in a mismatch state, a fast budget reconstruction process can be triggered.

[0128] The preset resource utilization threshold can be adaptively set according to actual application needs, and this embodiment does not impose any limitations on it. For example, if the preset resource utilization threshold is 85%, then when the GPU utilization of the cloud server is greater than 85% or the air interface utilization of the base station is greater than 85%, a congested state is determined, and a fast budget reconstruction process can be triggered.

[0129] In this embodiment, by embedding the budget status of transmission nodes into service interaction messages and transmitting them level by level, signaling overhead can be reduced. Furthermore, this embodiment triggers a rapid budget reconstruction process based on budget mismatch and resource congestion states, enabling timely correction of the target jitter budget for each transmission node and ensuring stable and controllable TSN service transmission latency.

[0130] In an optional implementation, the above method further includes: when the budget state is in a synchronized alignment state, determining the TAI (Time Alignment Index) index value according to the absolute clock of the base station, and sending the TAI index value to the transmission nodes in the data transmission path, so that each transmission node determines the gating start time of the transmission node according to the TAI index value and its corresponding preset phase offset.

[0131] Specifically, when the budget state is in the synchronization alignment state (010), the JBA-Controller module of the cloud server can generate the TAI index value based on the 5G base station absolute clock TgNB, as shown in the following formula:

[0132] Formula (9)

[0133] in, For example, the absolute clock of a 5G base station. This is the sum of SFN, subframes, and time slots. Where T_super is the superframe period, for example, it is 1ms. The current flow gating cycle can be selected through the flow cycle P_cycle constraint.

[0134] After the TAI index value is determined, the JBA-Controller module on the cloud server distributes it by domain. In the air interface domain, the TAI is carried in the SIB9 (System Information Block 9) system message and broadcast periodically, with a broadcast period configured to 10ms, for the base station scheduling unit to read. In the roadside domain, the gPTP Announce clock announcement message of the RSU is extended with fields, and the TAI parameter is carried in a custom TLV of type 0x8001 and sent to the RSU. In the vehicle domain, the vehicle equipment T-Box receives the SIB9 message broadcast by the base station, parses it to obtain the TAI value, and synchronizes the local gPTP clock domain based on the index to unify the transmission time slot of the service frame.

[0135] Upon receiving the TAI index value, each transmission node determines its gating start time. Specifically, the gating start time... It is calculated using the following formula:

[0136] Formula (10)

[0137] in, This refers to the preset phase offset corresponding to the transmission node. For example, the preset phase offset for vehicle equipment is 0 μs, meaning this preset phase offset is the reference phase, and the T-Box can initiate transmission gating when TAI=0. The preset phase offset for roadside equipment is +50 μs, determined based on the RSU receive window advance. The preset phase offset for the base station is T_tx+2 μs, used for gNB scheduler alignment, where T_tx is the estimated transmission delay. The preset phase offset for the cloud server is T_prop+5 μs, where T_prop is the receive window of the cloud server's MEC Agent module, which can be determined by compensating for air interface and backhaul propagation delays.

[0138] In this embodiment of the disclosure, by performing gating period alignment on each transmission node, cross-domain boundary queuing jitter can be eliminated, so that the frame arrives at each domain boundary exactly at the gating opening window.

[0139] To facilitate understanding, the following specific example illustrates the detailed implementation of the above method:

[0140] In related technologies, the allocation of jitter budget can be implemented in the following ways:

[0141] (1) Each domain manages its jitter budget independently, lacking a unified budget allocation mechanism. Under this approach, each domain reserves the maximum possible jitter, resulting in higher end-to-end latency.

[0142] (2) The static jitter budget allocation method is difficult to adapt to the flexible movement of vehicles in the vehicle-to-everything (V2X) scenario. In this method, the pre-calculated jitter budget remains fixed after the path is established. However, in the V2X scenario, vehicles move at high speeds, and an RSU / gNB handover may be triggered every 10-15 seconds. Correspondingly, the latency characteristics (hop count, link bandwidth, load) of the new path after the handover are significantly different from those of the old path. Therefore, the static budget may lead to insufficient resources for the new path or waste of resources for the old path.

[0143] (3) The jitter budget allocation method using forward allocation leads to a suboptimal situation of "waste at the front end and congestion at the back end". Under this method, budget allocation is carried out unidirectionally from the vehicle to the cloud. The vehicle makes decisions based only on the locally perceived link status and cannot know the real-time computing load and queue depth of the cloud MEC. As a result, in real-world scenarios, the vehicle often reserves too much budget, resulting in air interface resource shortage and increased queuing. Meanwhile, the cloud has insufficient remaining budget due to excessive jitter in the front-end link, forcing AI inference tasks to slow down or drop frames.

[0144] This disclosure provides a method for allocating jitter budgets. Figure 2 This is a flowchart illustrating a jitter budget allocation method provided in an embodiment of the present disclosure, with reference to... Figure 2 The method includes:

[0145] Step S201: Determine the first data transmission path from the vehicle equipment to the cloud server. The first data transmission path includes multiple transmission nodes; the vehicle equipment is the first transmission node, and the cloud server is the last transmission node.

[0146] Step S202: Perform a reverse traversal of the first data transmission path. Based on the operating status information corresponding to the currently traversed transmission nodes, determine the target jitter budget for each transmission node until the target jitter budget for the remaining transmission nodes, excluding vehicle equipment, is determined. These transmission nodes also include base stations and roadside equipment.

[0147] Step S203: Determine the target jitter budget for the vehicle equipment based on the total jitter budget corresponding to the first data transmission path, the target jitter budget of the cloud server, the target jitter budget of the base station, and the target jitter budget of the roadside equipment.

[0148] Step S204: If the target jitter budget of the vehicle equipment is less than the minimum jitter budget of the vehicle equipment, reduce the task level of the inference task, or increase the preset response time of the inference task to increase the total jitter budget and increase the target jitter budget of the vehicle equipment.

[0149] Step S205: Allocate the target jitter budget of each transmission node in the first data transmission path to the corresponding transmission node.

[0150] Step S206: For any transmission node in the first data transmission path, under the condition that the target jitter budget adjustment condition is met, perform an integral operation based on the difference between the target jitter budget of the transmission node and the required budget of the transmission node to obtain the budget adjustment value.

[0151] Step S207: Adjust the target jitter budget of the transmission nodes in the data transmission path according to the budget adjustment value to obtain the adjusted target jitter budget.

[0152] Step S208: Allocate the adjusted target jitter budget to the corresponding transmission node in the first data transmission path.

[0153] It should be noted that different priority budget adjustment trigger conditions can also be configured. For example, if J_real-J_alloc>200 μs or frame loss occurs, the P0 priority can be triggered. In this case, such as for sudden air interface interruption or GPU failure, the calculation steps of the target jitter budget for each transmission node can be re-executed and the service speed reduction can be performed.

[0154] If J_real-J_alloc>50 μs for 3 consecutive P_cycle cycles, the P1 priority is triggered. In this case, such as in response to load changes or increased congestion, a fast budget reconstruction process can be executed to determine the budget adjustment value and adjust the target jitter budget according to the budget adjustment value.

[0155] When GPU utilization or air interface utilization is greater than 85%, P2 priority is triggered. Under this condition, a fast budget rebuild process can be executed to achieve early capacity expansion during peak periods.

[0156] In addition, the target jitter budget can be periodically optimized to trigger P3 priority. Under this condition, resource reclamation and load balancing can be performed to achieve idle resource optimization.

[0157] Step S209: Predict the second data transmission path from the vehicle equipment to the cloud server after the first time.

[0158] Step S210: If the first data transmission path and the second data transmission path do not match, determine the target jitter budget for each transmission node in the second data transmission path.

[0159] Step S211: For any transmission node in the second data transmission path, determine a target transmission node of the same type as the corresponding transmission node in the first data transmission path, and use the maximum budget value between the target jitter budget of the corresponding transmission node and the target jitter budget of the target transmission node as the comprehensive jitter budget.

[0160] Step S212: If the first data transmission path meets the path switching conditions, the overall jitter budget is allocated to any transmission node and the target transmission node.

[0161] For ease of understanding, Figure 3 This diagram illustrates an application of a jitter budget allocation method provided in an embodiment of this disclosure. (Refer to...) Figure 3 The method includes:

[0162] Step S301: The JBA-Controller module on the cloud server collects parameters.

[0163] In this step, the JBA-Controller module of the cloud server receives the AF request and extracts the TSC parameters of the TSN flow identifier FlowID, such as P_cycle, L_frame, D_AI, and Class, where Class is the task level.

[0164] Step S302: Based on the path information, determine the transmission nodes in the data transmission path, perform reverse traversal of the data transmission path, and determine the target jitter budget for the remaining transmission nodes excluding vehicle equipment.

[0165] In this step, the Agent for each domain can be queried based on the path information Path[] and the total number of hops N_hop. When there are ≥4 untraversed nodes, the MEC-Agent module of the cloud server is queried to obtain the real-time load, such as ρ_gpu and Q_mec. The target jitter budget of the cloud server is calculated according to the above formula (1). .

[0166] When there are ≥3 untraversed nodes remaining, query gNB-TSCTSF to obtain the air interface status, such as... MCS The target jitter budget of the base station is calculated according to the above formula (2). .

[0167] When there are ≥2 untraversed nodes, query the RSU-Agent to obtain the roadside status, such as... , The target jitter budget for roadside equipment is calculated according to the above formula (3). .

[0168] Step S303: Select the gating period based on the flow period, and determine the target jitter budget of the vehicle equipment based on the total jitter budget corresponding to the data transmission path, the target jitter budget of the cloud server, the target jitter budget of the base station, and the target jitter budget of the roadside equipment.

[0169] Step S304: Perform a flow cycle constraint check. If the flow cycle constraint is not met, trigger a renegotiation and request AF to reduce the frame rate or extend the flow cycle.

[0170] The constraint check in this step can be referred to the above formula (6), which will not be elaborated here.

[0171] Step S305: Perform minimum jitter budget constraint verification on the target jitter budget of the vehicle equipment.

[0172] Among them, the target jitter budget of vehicle equipment Less than the minimum vibration budget of the vehicle equipment If this occurs, a renegotiation is triggered, requesting a reduction in Class priority or requesting AF to extend D_AI and re-execute step S304.

[0173] Step S306: Perform budget encapsulation and distribution.

[0174] Specifically, the JBA-Controller module can encapsulate the target jitter budget[] of the transmission nodes into a YANG data model (container: tsn-jitter-budget), and distribute it to each transmission node in parallel via RESTCONF. For example, it can... The MEC-Agent module is deployed to the cloud server. The MEC-Agent module is used to execute AI inference tasks. The JBA-Controller module is the execution entity for the jitter budget allocation method in this embodiment.

[0175] Step S307: Start the BSI budget status monitoring loop.

[0176] In this step, the JBA-Controller module can collect the demand budget J_real of each transmission node and determine the target jitter budget based on the demand budget and its allocation. The difference between the values, or the resource utilization status of the transmission node, determines whether to trigger the fast budget rebuild process. If the fast budget rebuild process is triggered, the target jitter budget of the transmission node is readjusted.

[0177] This disclosure provides a jitter budget allocation method, which has the following advantages:

[0178] (1) Adopting a global view reverse decision-making approach. The JBA-Controller aggregates cloud computing load, roadside switching status, and air interface transmission status, and allocates budgets based on the back-end priority principle. It prioritizes meeting the budget requirements of the cloud server's MEC, and then allocates the remaining budgets to the air interface domain, roadside domain, and vehicle domain in sequence. The vehicle adjusts the transmission gating based on the allocated jitter budget, achieving precise matching between back-end budget setting and front-end adaptive adjustment.

[0179] (2) The collaborative method of embedding gPTP messages based on BSI budget status eliminates information silos.

[0180] (3) By pre-calculating the jitter budget for the data transmission path of the vehicle equipment in the future, the budget vacuum during the path switching period is avoided by superimposing the budgets of the paths before and after the switch, thus achieving rapid reconstruction.

[0181] (4) By setting dynamic adjustment trigger conditions, for example, when the demand jitter of any domain deviates from the allocated target jitter budget by more than a threshold, the fast budget reconstruction process is automatically triggered. Thus, in the event of sudden air interface congestion, the budget reallocation and gating adjustment can be completed quickly, avoiding passive speed reduction or frame loss.

[0182] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0183] Secondly, embodiments of this disclosure provide a jitter budget allocation device. Figure 4 A block diagram of a jitter budget allocation device provided in an embodiment of this disclosure, with reference to... Figure 4 The device includes:

[0184] The determining module 41 is used to determine the data transmission path from the vehicle equipment to the cloud server, the data transmission path including multiple transmission nodes; the vehicle equipment is the first transmission node, and the cloud server is the last transmission node;

[0185] The traversal module 42 is used to perform reverse traversal of the data transmission path, and determine the target jitter budget of the transmission node based on the running status information corresponding to the currently traversed transmission node, until the target jitter budget of the remaining transmission nodes other than the vehicle equipment is determined.

[0186] Calculation module 43 is used to determine the target jitter budget of the vehicle equipment based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes.

[0187] The allocation module 44 is used to allocate the target jitter budget of each transmission node in the data transmission path to the corresponding transmission node.

[0188] In one optional implementation, the plurality of transmission nodes further include base stations and roadside equipment. The step of determining the target jitter budget for each transmission node based on its operational status information includes: if the currently traversed transmission node is a cloud server, determining the target jitter budget for the cloud server based on its computing power utilization, processing latency for inference tasks, and inference task queue depth; if the currently traversed transmission node is a base station, determining the target jitter budget for the base station based on its air interface resource utilization and air interface transmission latency; and if the currently traversed transmission node is a roadside equipment, determining the target jitter budget for the roadside equipment based on its gated queue depth and forwarding latency.

[0189] In one optional implementation, determining the target jitter budget of the vehicle equipment based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes includes: determining the target jitter budget of the vehicle equipment based on the total jitter budget, the target jitter budget of the cloud server, the target jitter budget of the base station, and the target jitter budget of the roadside equipment; the total jitter budget is determined based on the preset response time of the inference task, the processing latency of the inference task by the cloud server, and the preset security time corresponding to the cloud server.

[0190] In one optional implementation, the preset security duration is determined based on the task level of the inference task. After determining the target jitter budget of the vehicle device based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes, the device is further configured to: obtain the minimum jitter budget of the vehicle device; if the target jitter budget of the vehicle device is less than the minimum jitter budget, reduce the task level of the inference task, or increase the preset response duration of the inference task to increase the total jitter budget and increase the target jitter budget of the vehicle device.

[0191] In one optional implementation, determining the data transmission path from the vehicle device to the cloud server includes: determining a first data transmission path from the vehicle device to the cloud server; the device is further configured to: predict a second data transmission path from the vehicle device to the cloud server after a first time; if the first data transmission path and the second data transmission path do not match, determine a target jitter budget for each transmission node in the second data transmission path; for any transmission node in the second data transmission path, determine a target transmission node of the same type as the corresponding transmission node in the first data transmission path; determine a comprehensive jitter budget based on the target jitter budget of the any transmission node and the target jitter budget of the target transmission node; and if the first data transmission path meets the path switching conditions, allocate the comprehensive jitter budget to the any transmission node and the target transmission node.

[0192] In one optional implementation, determining the overall jitter budget based on the target jitter budget of any transmission node and the target jitter budget of the target transmission node includes: taking the maximum budget value between the target jitter budget of any transmission node and the target jitter budget of the target transmission node as the overall jitter budget.

[0193] In one optional implementation, whether the first data transmission path meets the path switching condition is determined by the following method: the distance between the vehicle equipment and the signal coverage boundary of the transmission node in the first data transmission path is not greater than a first distance threshold; or, the difference between the first signal strength of the transmission node corresponding to the location of the vehicle equipment in the first data transmission path and the second signal strength of the transmission node corresponding to the location of the vehicle equipment in the second data transmission path is not greater than a second difference threshold.

[0194] In one optional implementation, after allocating the target jitter budget for each transmission node in the data transmission path to the corresponding transmission node, the device is further configured to: for any transmission node in the data transmission path, under the condition of satisfying the target jitter budget adjustment, perform an integral operation based on the difference between the target jitter budget of the transmission node and the required budget of the transmission node to obtain a budget adjustment value; adjust the target jitter budget of the transmission nodes in the data transmission path according to the budget adjustment value to obtain an adjusted target jitter budget; and allocate the adjusted target jitter budget to the corresponding transmission node in the data transmission path.

[0195] In one optional implementation, the budget status of the transmission nodes in the data transmission path is set in the interaction message. The transmission nodes in the data transmission path transmit their budget status through the interaction message. Whether any transmission node in the data transmission path meets the target jitter budget adjustment condition is determined in the following way: if the budget status of any transmission node in the data transmission path is a budget mismatch state or a congestion state, it is determined that the transmission node meets the target jitter budget adjustment condition. The budget mismatch state is used to indicate that the difference between the demand budget of the transmission node and the target jitter budget of the transmission node is greater than a preset deviation threshold; the congestion state is used to indicate that the resource utilization rate of the transmission node is greater than a preset resource utilization rate threshold.

[0196] The apparatus provided in this disclosure can have functions or include modules that can be used to perform the methods described in the first aspect of the method embodiments above. The specific implementation and technical effects can be referred to the description of the method embodiments above. For the sake of brevity, they will not be repeated here.

[0197] It should be noted that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this disclosure, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this disclosure; however, this does not mean that other units are absent from this embodiment.

[0198] Reference Figure 5 This disclosure provides an electronic device, which includes:

[0199] One or more processors 501;

[0200] Memory 502, which stores one or more programs, which, when executed by one or more processors, cause one or more processors to implement any of the above-mentioned jitter budget allocation methods.

[0201] One or more I / O interfaces 503 are connected between the processor and the memory and configured to enable information exchange between the processor and the memory.

[0202] Among them, processor 501 is a device with data processing capabilities, including but not limited to central processing unit (CPU); memory 502 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); I / O interface (read-write interface) 503 is connected between processor 501 and memory 502, and can realize information interaction between processor 501 and memory 502, including but not limited to data bus (Bus).

[0203] In some embodiments, the processor 501, memory 502, and I / O interface 503 are interconnected via a bus, and thus connected to other components of the computing device.

[0204] This embodiment also provides a computer-readable medium having a computer program stored thereon. When the program is executed by a processor, it implements the jitter budget allocation method provided in this embodiment. To avoid repetition, the specific steps of the jitter budget allocation method will not be repeated here.

[0205] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the above-described jitter budget allocation method.

[0206] Those skilled in the art will understand that all or some of the steps, systems, or apparatuses in the methods, systems, and apparatuses described above can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0207] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0208] Those skilled in the art will understand that although some embodiments described herein include certain features that are included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this embodiment and form different embodiments.

[0209] It is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of this disclosure, and this disclosure is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this disclosure, and these modifications and improvements are also considered to be within the scope of protection of this disclosure.

Claims

1. A jitter budget allocation method, characterized in that, Applied to a cloud server, the method includes: A data transmission path is determined from the vehicle equipment to the cloud server, and the data transmission path includes multiple transmission nodes; the vehicle equipment is the first transmission node, and the cloud server is the last transmission node; The data transmission path is traversed in reverse. Based on the running status information of the transmission node currently being traversed, the target jitter budget of the transmission node is determined until the target jitter budget of the remaining transmission nodes other than the vehicle equipment is determined. The target jitter budget of the vehicle equipment is determined based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes. The target jitter budget for each transmission node in the data transmission path is allocated to the corresponding transmission node.

2. The method according to claim 1, characterized in that, The plurality of transmission nodes also includes base stations and roadside equipment. The step of determining the target jitter budget for each transmission node based on its operational status information during the current traversal includes: When the current traversal transmission node is a cloud server, the target jitter budget of the cloud server is determined based on the computing power utilization of the cloud server, the processing latency of the cloud server for inference tasks, and the depth of the inference task queue. When the currently traversed transmission node is a base station, the target jitter budget of the base station is determined based on the air interface resource utilization and air interface transmission delay of the base station. When the transmission node being traversed is a roadside device, the target jitter budget of the roadside device is determined based on the gating queue depth and forwarding latency of the roadside device.

3. The method according to claim 2, characterized in that, The step of determining the target jitter budget of the vehicle equipment based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes includes: The target jitter budget for the vehicle equipment is determined based on the total jitter budget, the target jitter budget for the cloud server, the target jitter budget for the base station, and the target jitter budget for the roadside equipment. The total jitter budget is determined based on the preset response time of the inference task, the processing latency of the inference task by the cloud server, and the preset security time corresponding to the cloud server.

4. The method according to claim 3, characterized in that, The preset safety duration is determined based on the task level of the inference task. After determining the target jitter budget of the vehicle equipment based on the total jitter budget corresponding to the data transmission path and the target jitter budget of the remaining transmission nodes, the method further includes: Obtain the minimum jitter budget for the vehicle equipment; If the target jitter budget of the vehicle equipment is less than the minimum jitter budget, the task level of the inference task is reduced, or the preset response time of the inference task is increased to increase the total jitter budget and the target jitter budget of the vehicle equipment.

5. The method according to claim 1, characterized in that, Determining the data transmission path from the vehicle equipment to the cloud server includes: determining a first data transmission path from the current vehicle equipment to the cloud server; the method further includes: Predict the second data transmission path from the vehicle equipment to the cloud server after the first time; In the case where the first data transmission path and the second data transmission path do not match, determine the target jitter budget for each transmission node in the second data transmission path; For any transmission node in the second data transmission path, a target transmission node of the same type as the corresponding transmission node is determined in the first data transmission path; a comprehensive jitter budget is determined based on the target jitter budget of the transmission node and the target jitter budget of the target transmission node. If the first data transmission path meets the path switching conditions, the comprehensive jitter budget is allocated to either of the transmission nodes and the target transmission node.

6. The method according to claim 5, characterized in that, The step of determining the comprehensive jitter budget based on the target jitter budget of any transmission node and the target jitter budget of the target transmission node includes: The combined jitter budget is the maximum budget value between the target jitter budget of any transmission node and the target jitter budget of the target transmission node.

7. The method according to claim 5, characterized in that, Whether the first data transmission path meets the path switching conditions is determined in the following way: The distance between the vehicle equipment and the signal coverage boundary of the transmission node in the first data transmission path is not greater than a first distance threshold; or... The difference between the first signal strength of the transmission node corresponding to the location of the vehicle equipment in the first data transmission path and the second signal strength of the transmission node corresponding to the location of the vehicle equipment in the second data transmission path is not greater than the second difference threshold.

8. The method according to claim 1, characterized in that, After allocating the target jitter budget for each transmission node in the data transmission path to the corresponding transmission node, the method further includes: For any transmission node in the data transmission path, under the condition that the target jitter budget adjustment condition is met, the budget adjustment value is obtained by integral calculation based on the difference between the target jitter budget of the transmission node and the required budget of the transmission node; The target jitter budget of the transmission nodes in the data transmission path is adjusted according to the budget adjustment value to obtain the adjusted target jitter budget; The adjusted target jitter budget is allocated to the corresponding transmission nodes in the data transmission path.

9. The method according to claim 8, characterized in that, The budget status of the transmission nodes in the data transmission path is set in the interaction message. The transmission nodes in the data transmission path transmit the budget status of the transmission nodes through the interaction message. Whether any transmission node in the data transmission path meets the target jitter budget adjustment conditions is determined in the following way: If the budget status of any transmission node in the data transmission path is a budget mismatch state or a congestion state, it is determined that the transmission node meets the target jitter budget adjustment condition. The budget mismatch state is used to indicate that the difference between the demand budget of the transmission node and the target jitter budget of the transmission node is greater than a preset deviation threshold; the congestion state is used to indicate that the resource utilization of the transmission node is greater than a preset resource utilization threshold.

10. An electronic device, characterized in that, include: One or more processors; A memory having stored one or more programs that, when executed by one or more processors, cause the one or more processors to implement the jitter budget allocation method according to any one of claims 1-9; One or more I / O interfaces are connected between the processor and the memory and configured to enable information interaction between the processor and the memory.

Images