Cloud video conference resource scheduling management method and system based on decentralized oracle network

Abstract

The application discloses a cloud video conference resource scheduling management method and system based on a decentralized oracle network, and belongs to the technical field of cloud video conference resource management and credible data processing. Link state, conference service level and edge node resource operation data are acquired to form resource scheduling state data; the resource scheduling state data is chained after being verified by the decentralized oracle network consensus; a smart contract determines a resource reconfiguration trigger condition, calculates bandwidth and computing quota, and determines a target edge node according to a service level, a resource utilization state and a resource scheduling cost optimization model, and generates a resource reconfiguration management scheme; the scheme is converted into a visual scheduling list and a task work order, and is issued to an edge resource pool through cross-link routing to perform resource locking, routing adjustment and computing task migration and return results. The application can reduce the coexistence of resource idling and overload, and improve resource utilization and management efficiency.

Description

Technical Field

[0001] This invention relates to the field of cloud video conferencing resource management and trusted data processing technology, specifically to a cloud video conferencing resource scheduling and management method and system based on a decentralized oracle network. Background Technology

[0002] Cloud video conferencing typically operates across different carriers, geographical regions, and edge resource pools, requiring the platform to continuously manage the bandwidth and computing resources used by each meeting. Existing resource scheduling often relies on centralized servers to collect the resource status of edge nodes and allocate nodes during meeting creation based on static requests or reserved quotas. Some solutions write allocation rules into smart contracts to record the cross-domain resource locking and allocation process. While these solutions can solidify the rules, the primary management object remains the static resource requests made during meeting creation.

[0003] During continuous operation, the business level, interaction activity, and link resource requirements of different meetings are constantly changing, and the available bandwidth, available computing power, and service status of edge nodes also fluctuate in real time. Existing smart contracts cannot simultaneously obtain reliable off-chain link status, meeting business level, and cross-domain node resource operation status, thus lacking a reliable triggering mechanism based on real-time operational status; fixed quotas cannot be adjusted in a timely manner according to changes in resource demand, which can easily lead to some nodes being idle for a long time while others are overloaded, reducing cross-domain resource utilization and scheduling management efficiency.

[0004] Furthermore, existing solutions typically output flow tables, routing, or migration instructions directly. Resource requirements, candidate node selection criteria, resource locking status, and execution results are scattered across different systems, making it difficult to create visualized scheduling solutions and task orders for operations management. The management platform cannot fully track the lifecycle of a resource reconfiguration from triggering, decision-making, locking to execution and release, nor can it continuously adjust scheduling strategies based on actual resource utilization and execution results, leading to insufficient operational cost control and scheduling effectiveness evaluation. Summary of the Invention

[0005] The purpose of this invention is to provide a cloud video conferencing resource scheduling and management method and system based on a decentralized oracle network, so as to solve the problems of cross-domain cloud video conferencing lack of reliable real-time operational status triggering, coexistence of resource idleness and overload, invisible management schemes, and difficulty in closed-loop feedback of execution results.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A cloud video conferencing resource scheduling and management method based on a decentralized oracle network includes: acquiring link status data, meeting service level data, and edge node resource operation data of the cloud video conferencing; extracting video stream bitrate jitter features and packet loss rate features from the link status data as underlying features of resource requirements; and associating the underlying features of resource requirements with the meeting service level data and the edge node resource operation data to form resource scheduling status data.

[0008] The resource scheduling status data is input into a decentralized oracle network, which performs multi-node cross-comparison consensus verification on the resource scheduling status data, and writes the resource scheduling status data into the blockchain after the verification is successful.

[0009] The smart contract on the blockchain reads the resource scheduling status data, determines whether to trigger resource reconfiguration based on the resource dynamic adjustment threshold logic associated with the meeting service level data, and calculates the bandwidth allocation quota and the resource allocation quota according to the resource quota mapping relationship when triggered.

[0010] The smart contract filters candidate edge nodes that meet the bandwidth allocation quota and the computing resource allocation quota based on the edge node resource operation data, and determines the target edge node from the candidate edge nodes according to the preset resource scheduling cost optimization model, and generates a resource reconfiguration management scheme that includes the target edge node identifier, bandwidth allocation quota, computing resource allocation quota and execution priority.

[0011] The resource reconfiguration management scheme is converted into a visual scheduling list and resource scheduling task work orders. The execution parameters of the resource scheduling task work orders are sent to the edge resource pool corresponding to the target edge node through a cross-link protocol. The edge resource pool completes resource locking, video stream routing adjustment and computation task migration according to the execution parameters and sends back the execution results. The status of the visual scheduling list and the resource scheduling task work orders is updated according to the execution results.

[0012] Preferably, forming the resource scheduling status data includes: performing differential calculation on the bitrate fluctuation data in the link status data within a preset time sliding window to generate a bitrate jitter change rate matrix;

[0013] Extract the timestamps and source address identifiers of packet loss events from the link status data to construct a spatial distribution matrix of packet loss rate; obtain meeting service management features including meeting priority, interaction frequency features, and keyframe request frequency features;

[0014] The bitrate jitter change rate matrix and the packet loss rate spatial distribution matrix are concatenated to generate a multi-dimensional joint feature matrix. The multi-dimensional joint feature matrix is ​​then associated with the conference service management features and the edge node resource operation data according to the conference identifier and collection timestamp to form the resource scheduling status data.

[0015] Preferably, the decentralized oracle network performs multi-node cross-comparison consensus verification on the resource scheduling status data, including: multiple oracle nodes in the decentralized oracle network digitally sign the resource scheduling status data respectively to generate a status signature share;

[0016] The state signature share is broadcast among the multiple oracle nodes;

[0017] Each oracle node verifies the received state signature share and aggregates the verified state signature shares based on a threshold consensus mechanism, including: obtaining the historical verification accuracy of each oracle node in the historical consensus process in the decentralized oracle network;

[0018] Dynamic weight values ​​are assigned to each oracle node based on the historical verification accuracy.

[0019] In the threshold consensus mechanism, the state signature share of each oracle node is multiplied by the corresponding dynamic weight value to obtain the weighted signature share;

[0020] Accumulate all weighted signature shares and determine whether the accumulation result reaches the preset consensus threshold.

[0021] If this is achieved, the weighted signature shares are aggregated.

[0022] Abnormal state signature shares with deviations exceeding a preset deviation threshold are removed, and the verified resource scheduling state data is recovered based on the aggregated state signature shares.

[0023] Preferably, determining whether to trigger resource reconfiguration based on the resource dynamic adjustment threshold logic associated with the conference service level data includes: pre-deploying a dynamic threshold function associated with the conference service level in the smart contract;

[0024] The underlying characteristics of the resource requirements and the meeting service level data are input into the dynamic threshold function, and the adaptive trigger threshold value is calculated and output through the dynamic threshold function.

[0025] Compare the adaptive trigger threshold value with the actual feature value of the underlying resource demand feature;

[0026] If the actual feature value is greater than or equal to the adaptive trigger threshold value, it is determined that the trigger condition of the resource dynamic adjustment threshold logic is met, and the execution priority of the resource reconfiguration management scheme is determined according to the meeting service level.

[0027] Preferably, the smart contract generates the resource reconfiguration management scheme, including: establishing a first mapping relationship between bitrate jitter characteristics and bandwidth compensation amount, a second mapping relationship between packet loss rate characteristics and computational redundancy amount, and a resource scheduling cost optimization model within the smart contract;

[0028] The bitrate jitter feature is input into the first mapping relationship to calculate the bandwidth allocation quota.

[0029] The packet loss rate feature is input into the second mapping relationship to calculate the computing resource allocation quota.

[0030] Based on the edge node resource operation data, candidate edge nodes that meet the bandwidth allocation quota and the computing resource allocation quota are screened. The resource scheduling cost optimization model calculates the resource scheduling cost index based on the resource occupancy ratio, network latency, task migration requirements, sub-chain to which the candidate edge node belongs, and historical service quality. The candidate edge node that meets the quota requirements and has the smallest resource scheduling cost index is determined as the target edge node.

[0031] Preferably, the execution parameters of the resource scheduling task work order are sent to the edge resource pool corresponding to the target edge node through the cross-link protocol, including: generating a resource scheduling task work order associated with the scheme identifier according to the resource reconfiguration management scheme, and broadcasting a resource locking request associated with the work order identifier to the sub-chain corresponding to the edge resource pool where the target edge node is located through the cross-link protocol;

[0032] The subchain verifies the resource locking request, and after successful verification, locks the resources in the edge resource pool corresponding to the bandwidth allocation quota and the computing resource allocation quota, and fills the locking result back into the resource scheduling task work order;

[0033] After receiving the resource lock confirmation message returned by the sub-chain, the execution parameters, work order identifier and resource lock confirmation identifier in the resource scheduling task work order are encapsulated into a cross-chain transaction data structure;

[0034] The cross-chain transaction data structure is routed to the sub-chain via the cross-chain routing protocol. The sub-chain parses the execution parameters and sends them to the edge resource pool for execution. At the same time, the status of the resource scheduling task work order is updated according to the execution results returned by the edge resource pool.

[0035] Preferably, before associating the multi-dimensional joint feature matrix with the conference business management features and the edge node resource operation data, the method further includes: calculating the covariance matrix of the multi-dimensional joint feature matrix and extracting the eigenvalues ​​and eigenvectors of the covariance matrix;

[0036] Arrange the eigenvectors in descending order of their eigenvalues, and select a predetermined number of the eigenvectors at the top of the sort to construct the principal component projection matrix;

[0037] The multi-dimensional joint feature matrix is ​​projected onto the principal component projection matrix, and feature dimensions with variance contribution rates lower than a preset contribution threshold are filtered out to generate a dimensionality-reduced joint feature matrix.

[0038] The reduced-dimensional joint feature matrix is ​​used as the underlying feature of the resource requirement and associated with the meeting business management feature and the edge node resource operation data.

[0039] Preferably, determining the conference service level includes: real-time collection of interaction frequency characteristics and keyframe request frequency characteristics within the cloud video conference;

[0040] The interaction frequency characteristics and the keyframe request frequency characteristics are input into the smart contract, and a dynamic priority score is calculated through the priority evaluation function.

[0041] The meeting service level is updated using the dynamic priority score. The updated meeting service level is then input into the dynamic threshold function to recalculate the corresponding adaptive trigger threshold value and execution priority.

[0042] Preferably, it further includes: after the resource scheduling task work order is executed in the edge resource pool, collecting actual scheduling effect data, the actual scheduling effect data including actual link recovery status data, target edge node resource utilization rate, original edge node resource release amount, migration time and work order execution status;

[0043] The actual link recovery status data, the bit rate jitter feature, and the bandwidth compensation amount are used to construct the first training sample. The actual link recovery status data, the packet loss rate feature, and the computational redundancy amount are used to construct the second training sample. The target edge node resource utilization rate, the original edge node resource release amount, the migration time, the work order execution status, the conference service level, and the corresponding resource scheduling cost indicators are used to construct the cost model correction sample.

[0044] The first training sample and the second training sample are input into the smart contract, and the first mapping relationship and the second mapping relationship are corrected by gradient descent. The weights of the resource scheduling cost optimization model are updated according to the cost model correction sample.

[0045] This invention also provides a cloud video conferencing resource scheduling and management system based on a decentralized oracle network, used to implement the method, including:

[0046] The data acquisition and feature formation module is used to acquire link status data, conference service level data, and edge node resource operation data, and form resource scheduling status data.

[0047] The oracle consensus verification module is used to perform multi-node cross-comparison consensus verification on the resource scheduling status data and write it into the blockchain after the verification is successful.

[0048] The smart contract scheduling decision module is used to determine whether to trigger resource reconfiguration based on the resource dynamic adjustment threshold logic associated with the conference service level, calculate the bandwidth allocation quota and the resource allocation quota, and determine the target edge node based on the resource scheduling cost optimization model.

[0049] The management scheme and task work order module is used to generate resource reconfiguration management schemes and convert the resource reconfiguration management schemes into visual scheduling lists and resource scheduling task work orders.

[0050] The cross-chain execution module is used to reliably send the execution parameters of the resource scheduling task work order to the target edge resource pool to complete resource locking, video stream routing adjustment and computing task migration;

[0051] The feedback optimization module is used to correct the resource quota mapping relationship and the resource scheduling cost optimization model based on the link recovery status, resource utilization, resource release amount, migration time and work order execution status returned by the target edge resource pool.

[0052] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0053] 1. This invention integrates link demand characteristics, meeting service level data, and edge node resource operation data into unified resource scheduling status data. After verification by multi-node consensus in a decentralized oracle network, the data is written into the blockchain, enabling smart contracts to trigger resource reconfiguration with a reliable real-time operational status, thus avoiding the impact of a single node forging a resource shortage status on cross-domain resource allocation.

[0054] 2. Based on the original bandwidth and computing quota mapping, this invention uses resource consumption, cross-domain latency, migration requirements and historical service quality to form a resource scheduling cost index, and selects the target node from the candidate nodes that meet the quota; thereby taking into account the conference service level and cross-domain resource utilization, reducing the coexistence of resource idleness and overload, and improving resource utilization and scheduling management efficiency.

[0055] 3. This invention transforms resource reconfiguration management schemes into visual scheduling lists and resource scheduling task work orders, and forms a closed loop through cross-chain resource locking, trusted distribution, execution status feedback, and model correction. The management side can track the entire process of resources from scheme generation, locking, activation to release, while the underlying layer still completes the actual execution through routing adjustment and computation task migration, thereby improving the auditability, execution reliability, and long-term operational effectiveness of cross-domain resource scheduling. Attached Figure Description

[0056] Figure 1 This is a general flowchart of the method of the present invention. Detailed Implementation

[0057] In one embodiment, the cloud video conferencing resource scheduling and management system comprises a conference operation management platform, a main chain network, a decentralized oracle network, multiple edge resource pool sub-chains, and conference terminals distributed across different geographical regions. The conference operation management platform maintains conference identifiers, conference service levels, and resource scheduling task work orders; the main chain network adopts an Ethereum-compatible blockchain architecture and deploys resource management smart contracts and cross-link routing contracts; the decentralized oracle network consists of multiple oracle nodes distributed across different autonomous systems, with each oracle node establishing data connections with at least three different data monitoring points; the edge resource pool sub-chains correspond to edge computing node clusters of different operators or geographical regions, with each sub-chain maintaining the resource capacity, resource usage, resource locking status, service quality records, and scheduling execution logs of edge nodes within its region. Conference terminals access the corresponding edge nodes via the internet to achieve video stream encoding, transmission, and decoding.

[0058] refer to Figure 1 The cloud video conferencing resource scheduling and management method based on decentralized oracle networks provided by this method includes:

[0059] Acquire link status data, meeting service level data, and edge node resource operation data of cloud video conferencing; extract video stream bitrate jitter features and packet loss rate features from the link status data as underlying features of resource requirements, and associate the underlying features of resource requirements with the meeting service level data and the edge node resource operation data to form resource scheduling status data;

[0060] The resource scheduling status data is input into a decentralized oracle network, which performs multi-node cross-comparison consensus verification on the resource scheduling status data, and writes the resource scheduling status data into the blockchain after the verification is successful.

[0061] The smart contract on the blockchain reads the resource scheduling status data, determines whether to trigger resource reconfiguration based on the resource dynamic adjustment threshold logic associated with the meeting service level data, and calculates the bandwidth allocation quota and the resource allocation quota according to the resource quota mapping relationship when triggered.

[0062] The smart contract filters candidate edge nodes that meet the bandwidth allocation quota and the computing resource allocation quota based on the edge node resource operation data, and determines the target edge node from the candidate edge nodes according to the preset resource scheduling cost optimization model, and generates a resource reconfiguration management scheme that includes the target edge node identifier, bandwidth allocation quota, computing resource allocation quota and execution priority.

[0063] The resource reconfiguration management scheme is converted into a visual scheduling list and resource scheduling task work orders. The execution parameters of the resource scheduling task work orders are sent to the edge resource pool corresponding to the target edge node through a cross-link protocol. The edge resource pool completes resource locking, video stream routing adjustment and computation task migration according to the execution parameters and sends back the execution results. The status of the visual scheduling list and the resource scheduling task work orders is updated according to the execution results.

[0064] In this embodiment, the cloud video conferencing resource scheduling and management method first acquires three types of basic resource scheduling data: the first type is link status data between the conferencing terminal and the edge node, including the actual bitrate of the video stream, data packet transmission and reception timestamps, data packet sequence numbers, and source and destination addresses; the second type is conferencing service level data, including pre-registered conferencing priorities and conferencing service management characteristics formed by interaction frequency and keyframe request frequency; the third type is edge node resource operation data, including total bandwidth capacity, used bandwidth, total computing power, used computing power, network latency, historical service quality, and resource locking status. The data processing unit extracts video stream bitrate jitter characteristics and packet loss rate characteristics from the link status data and associates them with the conferencing service level data and edge node resource operation data to form resource scheduling status data for resource allocation decisions.

[0065] The data processing unit adds meeting identifiers, data source identifiers, and collection timestamps to the resource scheduling status data before sending it to the decentralized oracle network. Multiple oracle nodes cross-compare and digitally sign the link status, meeting service level, and edge node resource operation summaries from different monitoring points, generating status signature shares and broadcasting them within the oracle network. Each node verifies the received status signature shares, aggregating verified signature shares based on a threshold consensus mechanism and removing abnormal shares with deviations exceeding a preset deviation threshold. When the aggregation result reaches the preset consensus threshold, the verified resource scheduling status data is restored and written to the main chain network, thus providing a reliable real-time operational status trigger for cross-domain resource scheduling.

[0066] The resource management smart contract on the mainnet listens for resource scheduling status data write events. Upon detecting new data, the smart contract reads the meeting service level, link demand characteristics, and edge node resource operation status, matching the link demand characteristics with the dynamic resource adjustment threshold logic. When the triggering condition is met, the resource demand quota is calculated based on the bandwidth-computing quota mapping relationship, and candidate edge nodes are ranked using a preset resource scheduling cost optimization model. The cost optimization model uses the candidate nodes' resource consumption, cross-domain latency, task migration requirements, and historical service quality to form a resource scheduling cost index, determining the target edge node among the candidate nodes that meet the resource quota.

[0067] The resource management smart contract generates a resource reconfiguration management plan based on the target edge node, bandwidth allocation quota, computing resource allocation quota, meeting service level, and execution priority. This plan is then converted into a visual scheduling list and resource scheduling task work orders. The visual scheduling list displays the plan identifier, source node, target node, resource quota, resource locking status, and execution status on the meeting operation management platform. Resource scheduling task work orders carry machine-readable parameters that can be parsed by the cross-link contract. The cross-link contract reliably distributes the work order parameters to the target edge resource pool sub-chain. After the edge resource pool completes resource locking, routing adjustments, and computing task migration, it sends back the execution results, which the meeting operation management platform then updates the work order status accordingly.

[0068] Specifically, the network monitoring module at the edge node collects link status data at 100-millisecond sampling intervals. For video stream bitrate, it counts the number of successfully transmitted video data bytes within each sampling interval; for packet loss rate, it continuously records the number of lost packets and their timestamps based on packet sequence numbers. The raw link status data is stored in a local circular buffer that can hold the most recent 60 seconds of sampled data. The conference operation management platform synchronizes conference service level data according to the conference identifier, and the edge resource pool synchronizes the total amount, usage, lockout, network latency, and historical service quality of bandwidth and computing resources according to a preset period, ensuring a unified time benchmark for technical status, service level, and resource operation status.

[0069] The data processing unit reads link status data within a preset time window for feature extraction. The time window length is set to 5 seconds, and the sliding step size is set to 1 second. At each sliding step, differential calculation is performed on the bitrate fluctuation data to generate a bitrate jitter change rate matrix. Simultaneously, the timestamp and source address identifier of the packet loss event are extracted to construct a packet loss rate spatial distribution matrix, which is then concatenated into a multi-dimensional joint feature matrix. This matrix serves as the underlying quantitative feature of resource demand status. After being associated with the meeting service level data and edge node resource operation data corresponding to the same meeting identifier, it forms resource scheduling status data.

[0070] The decentralized oracle network consists of 21 independently operating oracle nodes, each with a unique public-private key pair. After receiving resource scheduling state data, each oracle node calculates a feature hash value from the joint feature matrix, meeting service level digest, edge node resource operation digest, meeting identifier, and collection timestamp. It then digitally signs the feature hash value using its own private key, generating a state signature share, and broadcasts the state signature share along with its node identifier to the entire oracle network.

[0071] Each oracle node uses the public key of the sending node to verify the legitimacy of the received state signature shares and stores the verified shares in its local signature pool. When the number of verified shares reaches a preset number, a threshold consensus process is initiated, aggregating state signature shares and removing abnormal shares whose deviations from the state values ​​of the majority of nodes exceed a preset threshold. After the effective shares reach the preset consensus threshold, the verified resource scheduling state data is restored and jointly written to the main chain network by the nodes that have reached a consensus.

[0072] The mainnet network employs a proof-of-stake consensus mechanism, with a block generation time set to 3 seconds. The resource management smart contract internally maintains network state characteristic storage mappings, meeting business level records, resource dynamic adjustment threshold parameters, edge node registration lists, resource scheduling cost models, resource reconfiguration management scheme records, task order status, and resource scheduling history records. The smart contract monitors resource scheduling status data written by the oracle network in real time through an event listening mechanism; upon detecting a new event, it triggers internal resource scheduling management logic and records the data version used in this decision.

[0073] The smart contract matches the link demand characteristics in the resource scheduling status data with the dynamic resource adjustment threshold logic. This dynamic threshold logic includes a dynamic threshold function associated with the meeting service level; the meeting service level can be determined by pre-registered meeting priorities or dynamically adjusted by interaction frequency and keyframe request frequency. The smart contract calculates an adaptive trigger threshold and compares it with the actual characteristic value of the link demand characteristics; when the actual characteristic value reaches the threshold, a resource reconfiguration management scheme record is created and its status is set to "pending calculation".

[0074] Once the solution calculation phase begins, the smart contract calculates the bandwidth allocation quota based on the first mapping relationship between bitrate jitter characteristics and bandwidth compensation, and calculates the computing resource allocation quota based on the second mapping relationship between packet loss rate characteristics and computing redundancy. Thus, bitrate jitter and packet loss rate, as underlying indicators reflecting changes in conference resource requirements, participate in quota quantification, while the conference service level is used to adjust trigger thresholds and execution priorities, avoiding indiscriminate resource additions based solely on physical network conditions.

[0075] The smart contract iterates through the edge node registration list, calculating allocable resources for each node based on its total bandwidth capacity, used bandwidth, locked bandwidth, total computing power, used computing power, and locked computing power. It then filters candidate edge nodes whose allocable bandwidth is not less than the bandwidth allocation quota and whose allocable computing resources are not less than the computing resource allocation quota. This candidate filtering first ensures the management plan is executable before proceeding to the resource scheduling cost optimization step.

[0076] For each candidate edge node, the smart contract calculates the resource scheduling cost index based on the resource utilization ratio, the subchain to which the node belongs, network latency, the quota of computing resources to be migrated, the conference service level, and the node's historical service quality. It then selects the node with the lowest cost index from among the candidate nodes that meet the quota requirements as the target edge node. The smart contract encapsulates the target edge node identifier, source edge node identifier, bandwidth allocation quota, computing resource allocation quota, execution priority, and expected resource release amount into a resource reconfiguration management scheme, assigning a unique scheme identifier.

[0077] A cross-link resource lock request is generated by the contract based on the management scheme and associated with the scheme identifier. This request is then broadcast across the link to the edge resource pool sub-chain where the target edge node resides via the cross-link protocol. The resource lock request includes the target edge node identifier, bandwidth allocation quota, computational resource allocation quota, execution priority, and request identifier. After verifying the validity of the request, the sub-chain locks the corresponding resource and writes the locking result to the task work order status record, thereby preventing the same available resource from being repeatedly occupied by multiple scheduling schemes.

[0078] After the edge resource pool completes resource locking, it returns a confirmation message containing the request identifier, locking result, and executable timestamp. The cross-chain contract receives the confirmation message, converts the resource reconfiguration management scheme into a resource scheduling task work order, and encapsulates the target node, resource quota, resource lock confirmation, and execution parameters into a cross-chain transaction data structure. The meeting operation management platform synchronously displays the "resource locked" status of the work order; administrators can view it but do not need to manually modify the underlying execution parameters.

[0079] The cross-chain transaction data structure is routed to the target edge resource pool subchain by the contract. After the subchain verifies the transaction signature and resource lock confirmation, it sends the machine-readable execution parameters in the task order to the edge resource pool. The edge resource pool performs video stream routing adjustment and computing task migration according to the bandwidth allocation quota and computing resource allocation quota, and gradually sends back the status of "in execution", "execution completed" or "execution failed" and the actual resource usage data to form an auditable cross-domain resource scheduling closed loop.

[0080] In this embodiment, a seamless switching mechanism is adopted for adjusting the video stream routing. The edge resource pool first establishes a new link between the target edge node and the conference terminal, while maintaining the original link transmission. After the new link passes testing, the video stream is gradually switched. After completion, the original link is closed and the original node resources are released. The task work order records four nodes: new link establishment, dual link verification, switching completion, and original resource release, enabling the operation and management side to distinguish between resource locking, resource activation, and resource release statuses.

[0081] The computing task migration adopts a containerized migration approach. The edge resource pool generates snapshots of the video conferencing-related containers on the original edge nodes and transmits them to the target edge node. The target edge node restores the video stream decoding state, participant connection state, and meeting data cache state. After successful restoration, the computing task migration is completed, and the corresponding computing resources of the original edge node are released. The migration results, migration time, and released resource amount are backfilled into the resource scheduling task work order as feedback data for the subsequent resource scheduling cost model.

[0082] This embodiment implements cloud video conferencing resource scheduling and management based on a decentralized oracle network. The decentralized oracle network reliably imports link requirements, conferencing service levels, and edge node resource operation status onto the blockchain. Smart contracts then use this information to complete trigger judgments, resource quota quantification, candidate node selection, and cost optimization. The resource reconfiguration management scheme, after being organized through a visualized scheduling list and task work orders, is executed reliably across links and the results are transmitted back. This process, while retaining the original routing adjustment and computation task migration techniques, establishes an operational management closed loop focused on cross-domain resource utilization and scheduling efficiency.

[0083] In one embodiment, to ensure that resource scheduling and management decisions are based on quantifiable meeting resource demand status, the data processing unit extracts video stream bitrate jitter and packet loss rate features from the link status data. The data processing unit first removes outliers and noisy data: it applies a sliding window mid-range filter to the bitrate data, and marks continuous large-scale packet loss events caused by terminal restarts or brief network interruptions to prevent such events from being directly interpreted as persistent resource shortages. The processed features serve as the underlying demand features for the resource scheduling status data and are used in conjunction with the meeting service level and resource operating status.

[0084] After preprocessing, the data processing unit performs differential calculations on the bit rate fluctuation data in the link status data within a preset time window. (Preset time window) The length is There are sampling intervals, each sampling interval is . Within the time sliding window, the bitrate sequence is represented as... ,in They represent the 1st, 2nd, ..., The actual bitrate within each sampling interval. The data processing unit performs first-order difference calculation on the bitrate sequence to obtain the bitrate change sequence. ,in for The 1st, 2nd, ... One element, , , , Indicates the first The actual bit rate within each sampling interval Indicates the first The actual bit rate within each sampling interval.

[0085] To more comprehensively describe the characteristics of bitrate jitter, the data processing unit performs second-order difference calculations on the bitrate change sequence to obtain the bitrate change rate sequence. ,in For No. 1, 2,…, One element, , , , , , Indicates the first The actual bit rate within each sampling interval Indicates the first The actual bitrate within each sampling interval. Simultaneously, the data processing unit calculates the statistical characteristics of the bitrate sequence, including the mean, variance, maximum, minimum, and peak-to-peak value. These statistical characteristics are combined with the first-order and second-order difference sequences to generate a bitrate jitter rate matrix.

[0086] The dimension of the bitrate jitter rate change matrix J is Where M is the number of sampling points within the time sliding window. The feature dimension corresponding to each sampling point. In this embodiment, The value is 5, corresponding to the actual bitrate, first-order difference, second-order difference, sliding window mean, and sliding window variance, respectively. The mathematical expression for the bitrate jitter rate matrix J is:

[0087]

[0088] in, , , ..., They represent the 1st, 2nd, ..., The average bitrate within a sliding window centered on each sampling point. , , ..., They represent the 1st, 2nd, ..., The variance of the bit rate within a sliding window centered on a sampling point. The length of the sliding window is set to 5 sampling intervals.

[0089] While generating the bitrate jitter rate change matrix, the data processing unit extracts the timestamps and source address identifiers of packet loss events from the link status data to construct a spatial distribution matrix of packet loss rate. The data processing unit then applies a preset time sliding window... Divide into L equal time slices, each time slice having a length of L. Meanwhile, the data processing unit divides the network into S different areas based on the network segment information of the source IP address.

[0090] For each time slice For each region s (s=1,2,...,S), the data processing unit counts the total number of data packets from that region within that time slice. and the number of lost data packets Calculate the packet loss rate for this region within this time slice. Combine the packet loss rates of all time slices and regions to generate a spatial distribution matrix P of the packet loss rate.

[0091] The spatial distribution matrix P of the packet loss rate has a dimension of L×S, and its mathematical expression is:

[0092]

[0093] , , ..., These represent the first, second, ..., elements in the first row of P. Column elements; , , ..., These represent the first, second, ..., elements in the first row of P. Column elements; , , ..., They represent the first in P. Lines 1, 2, ... The elements of the column.

[0094] The data processing unit concatenates the bitrate jitter rate change matrix J with the packet loss rate spatial distribution matrix P to generate a multi-dimensional joint feature matrix F. The matrix concatenation uses a horizontal concatenation method, that is, each row of the packet loss rate spatial distribution matrix is ​​extended to the corresponding row of the bitrate jitter rate change matrix. The multi-dimensional joint feature matrix F has the following dimensions: ×( +S), its mathematical expression is:

[0095]

[0096] in, It transforms the spatial distribution matrix P of packet loss rate into The matrix after multiplying by S dimensions. This is due to the number of rows in the bitrate jitter rate matrix J. The number of rows L in the packet loss rate spatial distribution matrix P may differ from the number of rows L in the data processing unit. The data processing unit uses a linear interpolation method to adjust the number of rows in P to... ,get .

[0097] Before inputting the multi-dimensional joint feature matrix F as network state features into the decentralized oracle network, the data processing unit performs principal component analysis (PCA) dimensionality reduction on F to reduce data transmission volume and computational overhead. The PCA dimensionality reduction process is as follows.

[0098] The data processing unit first calculates the covariance matrix C of the multi-dimensional joint feature matrix F. The covariance matrix C has dimensions D×D, where D= +S represents the dimension of the joint features. Elements of the covariance matrix C. Let represent the covariance between the i-th feature dimension and the j-th feature dimension, and its calculation formula is:

[0099]

[0100] in, Let represent the element in the k-th row and i-th column of the multi-dimensional joint feature matrix F. Let represent the mean of the i-th feature dimension. Represents the k-th row and i-th element in the multi-dimensional joint feature matrix F. Column elements, Indicates the first The mean of each feature dimension.

[0101] After calculating the covariance matrix C, the data processing unit solves for the eigenvalues ​​and eigenvectors of the covariance matrix C. The eigenvalues ​​are the 1st, 2nd, ..., Dth eigenvalues. Arranged in descending order, the corresponding feature vectors are as follows: Each eigenvalue represents the variance contribution rate of the corresponding principal component. The larger the variance contribution rate, the more original information the principal component contains.

[0102] The data processing unit calculates the cumulative variance contribution rate of the first m principal components. The formula for calculating the cumulative variance contribution rate is:

[0103]

[0104] For the 1st, 2nd, ..., Each feature value.

[0105] When the cumulative variance contribution rate When the preset contribution threshold is reached, the first m eigenvectors are selected to construct the principal component projection matrix W. The principal component projection matrix W has a dimension of D×m, and its column vectors are the first m eigenvectors.

[0106] The data processing unit projects the multi-dimensional joint feature matrix F onto the principal component projection matrix W to generate a dimensionality-reduced joint feature matrix. Dimensionality reduction joint feature matrix The dimension is ×m, its calculation formula is:

[0107]

[0108] The data processing unit will reduce the dimensionality of the joint feature matrix. The network state features are input into the decentralized oracle network. Through principal component analysis (PCA) dimensionality reduction, the dimensionality of the network state features is significantly reduced while retaining most of the original information, thereby reducing data transmission volume and the computational overhead of consensus verification in the decentralized oracle network.

[0109] In this embodiment, Table 1 is a comparison table of cumulative variance contribution rate and data volume under different dimensionality reduction degrees.

[0110] Table 1 Comparison of Dimensionality Reduction Effects of Principal Component Analysis

[0111]

[0112] As shown in Table 1, when 10 principal components are retained, the cumulative variance contribution rate reaches 82.7%, and the data volume is reduced by 9.1%. When 15 principal components are retained, the cumulative variance contribution rate reaches 91.3%, which can retain most of the information of the original data. In this embodiment, the preset contribution threshold is set to 90%, so the first 15 principal components are selected to construct the principal component projection matrix and generate the dimensionality-reduced joint feature matrix.

[0113] This embodiment details the extraction and dimensionality reduction process of underlying features of resource requirements. The bitrate jitter rate change matrix and packet loss rate spatial distribution matrix are used to quantify the resource pressure on different conference links. Principal component analysis reduces the data volume and computational overhead of oracle consensus while retaining key state information. The dimensionality-reduced joint feature matrix does not determine routing independently, but rather, together with conference service level data and edge node resource operation data, constitutes the input for resource scheduling and management decisions.

[0114] In one embodiment, the process of a decentralized oracle network performing multi-node cross-comparison consensus verification of network state features is as follows. The decentralized oracle network consists of... It consists of 1,000 independently operating oracle nodes, and the node set is represented as . . No. 1, 2,…, Oracle nodes Possess a unique public-private key pair ,in For private key, This is the public key. All oracle nodes' public keys are publicly available on the network, and any node can obtain the public keys of other nodes for signature verification.

[0115] When a certain oracle node Upon receiving the network state feature F from the data processing unit, the system first performs a hash calculation on the network state feature F to generate a feature hash value h. The hash calculation uses the SHA-256 hash algorithm, and its calculation formula is as follows:

[0116]

[0117] in, This represents the SHA-256 hash function.

[0118] Then, the oracle node Use your own private key Digitally sign the feature hash value h to generate a feature signature share. The digital signature uses the Elliptic Curve Digital Signature Algorithm (ECDSA), and its calculation formula is as follows:

[0119]

[0120] This is the ECDSA signature function.

[0121] Oracle nodes The generated feature signature share The signature share, along with its own node identifier i and characteristic hash value h, is broadcast to the entire oracle network. The broadcast uses a flooding method, where each node forwards the received signature share to all its neighboring nodes, ensuring that all nodes receive the signature shares from other nodes.

[0122] Upon receiving a signature share broadcast by other nodes, each oracle node first verifies the validity of the signature share. This verification process uses the public key of the sending node. Signature share The verification is performed using the following formula:

[0123]

[0124] This is the signature verification function.

[0125] If the verification result is True, it means that the signature share was generated by the node. Valid signatures are stored in the local signature pool. If the verification result is False, the signature share is discarded.

[0126] When the number of verified signature shares collected by an oracle node reaches a preset number o, the threshold consensus process is initiated. The preset number o is set to the smallest integer greater than K / 2, i.e. In this embodiment, K=21, therefore o=11.

[0127] During the threshold consensus process, each oracle node assigns dynamic weight values ​​to other nodes based on their historical verification accuracy. Each oracle node maintains a record of the historical verification accuracy of all other nodes. Represents a node in the past During this consensus process, the proportion of signatures submitted is determined to be valid. Historical verification accuracy. The calculation formula is:

[0128]

[0129] in, Represents a node in the past The number of valid signatures during the consensus process.

[0130] Based on historical verification accuracy For each node Assign dynamic weight values Dynamic weight values The calculation formula is:

[0131]

[0132] It can be seen that the sum of the dynamic weights of all nodes is 1, that is... .

[0133] In the threshold consensus mechanism, each oracle node multiplies the collected signature share by its corresponding dynamic weight value to obtain a weighted signature share. For nodes... Feature signature share Its weighted signature share is .

[0134] Then, each oracle node sums up all the verified weighted signature shares and calculates the sum. Cumulative result The calculation formula is:

[0135]

[0136] Where V represents the set of nodes that have passed verification.

[0137] Each oracle node judges the cumulative result Has the preset consensus threshold T been reached? The preset consensus threshold T is set to 0.5, meaning that when the accumulated result... A value ≥ 0.5 indicates consensus has been reached. If the cumulative results... If a preset consensus threshold is reached, the weighted signature shares are aggregated to generate an aggregated signature. .

[0138] During the aggregate signature generation process, each oracle node first calculates the average of the feature hash values ​​corresponding to all valid feature signature shares. Then, calculate the hash value for each feature. with the mean Deviation between If the hash value of a certain feature deviates... Exceeding the preset deviation threshold If the signature share of the node is found to be abnormal, it will be removed from the valid set V.

[0139] Preset deviation threshold The settings are based on the distribution characteristics of hash values. Since a SHA-256 hash value is a 256-bit binary number, its value ranges from 0 to... In this embodiment, a preset deviation threshold is used. Set to 10% of the average hash value.

[0140] After removing signatures with abnormal characteristics, each oracle node recalculates the dynamic weight values ​​of the remaining valid nodes and re-accumulates and aggregates the weighted signature shares. When the final accumulation result reaches the preset consensus threshold, an aggregated signature is generated. And recover the verified network state characteristics. .

[0141] Validated network state features It is the weighted average of the network state features submitted by all valid nodes, and its calculation formula is:

[0142]

[0143] in, This represents the set of valid nodes after removing abnormal nodes. This represents the recalculated dynamic weight value. Represents a node Submitted network state characteristics.

[0144] When aggregate signature With verified network state characteristics After generation, nodes that have reached a consensus jointly write it into the main chain network. The writing process uses a multi-signature transaction method, requiring at least o nodes' signatures to write the data into the main chain. The main chain network verifies the multi-signature transaction, and upon successful verification, it records the network state characteristics. With aggregate signature Stored in blocks.

[0145] In this embodiment, Table 2 is a table of dynamic weight allocation for nodes under different historical verification accuracies.

[0146] Table 2. Dynamic Weight Allocation of Oracle Nodes

[0147]

[0148] As shown in Table 2, nodes with higher historical verification accuracy are assigned larger dynamic weight values. Dynamic weight allocation gives nodes with good historical performance greater influence in the consensus process, while reducing the impact of abnormal nodes on resource scheduling status data, thus establishing a traceable and reliable data foundation for cross-domain resource allocation decisions.

[0149] This embodiment details the multi-node cross-comparison consensus verification process of a decentralized oracle network. Dynamic weighted threshold consensus based on historical verification accuracy can eliminate interference from abnormal nodes, ensuring that resource scheduling status data written to the blockchain has a verifiable source. This prevents a single edge node from influencing resource allocation by forging resource shortages or link anomalies, thereby improving the credibility and fairness of cross-domain resource management decisions.

[0150] In one embodiment, the smart contract takes consensus-verified resource scheduling status data as input, first determines whether resource reconfiguration needs to be initiated based on dynamic threshold logic associated with the meeting service level, and then generates a resource reconfiguration management plan based on quota mapping and a resource scheduling cost optimization model. The meeting service level is divided into three levels: high, medium, and low. High level corresponds to corporate board meetings or important client meetings, medium level corresponds to departmental meetings or project discussions, and low level corresponds to ordinary communication meetings. The level differences are used to adjust trigger thresholds, execution priorities, and service quality loss weights, rather than directly replacing the underlying resource demand measurement.

[0151] Dynamic threshold function Taking the meeting priority p and network state features F as inputs, the output is an adaptive trigger threshold T. The mathematical expression for the dynamic threshold function is:

[0152]

[0153] in, The mean of the network state characteristic F is represented by... The standard deviation of the network state characteristic F is represented by... and This is a coefficient related to the meeting priority p.

[0154] In this embodiment, the coefficients corresponding to different meeting priorities are as follows:

[0155] High priority: (Height) = 1.0 (Height) = 1.5;

[0156] Medium priority: (middle) = 1.2, (China) = 2.0;

[0157] Low priority: (Low) = 1.5 (Low) = 2.5;

[0158] It can be seen that the higher the service level of a conference, the lower the adaptive trigger threshold, and the easier it is for resource reconfiguration to be triggered. This setting embodies the differentiated service strategy in resource scheduling management: when resources are limited, the resource demands of high-level conferences are prioritized, while the quantitative quota of bandwidth and computing resources is still determined by the actual link demand characteristics.

[0159] The smart contract inputs the read network state feature F into the dynamic threshold function, and calculates and outputs the adaptive trigger threshold T corresponding to the network state feature. Then, the smart contract calculates the actual feature value of the network state feature F . The actual feature value is the weighted average of all elements in the network state feature F, and its calculation formula is:

[0160]

[0161] where, represents the i-th principal component of the network state feature F, represents the weight coefficient of the i-th principal component, and the weight coefficient is proportional to the variance contribution rate of the principal component.

[0162] The smart contract compares the adaptive trigger threshold T with the actual feature value . If ≥ T, it is determined that the network state feature satisfies the trigger condition of the resource dynamic adjustment threshold logic, and the resource reconfiguration process is started. If < T, the resource reconfiguration is not triggered, and the writing of the next network state feature is continued to be waited for.

[0163] In an optional embodiment, the conference operation management platform counts in real time the interaction frequency feature and the key frame request frequency feature in the cloud video conference, which are used as conference service management features and written onto the chain after being verified by the oracle node. The interaction frequency is obtained by counting the number of audio data packets and video data packets sent by the conference terminal, and the key frame request frequency is obtained by counting the number of key frame request messages; both are used to dynamically correct the conference service level, so as to avoid relying only on the static level at the conference creation stage.

[0164] A priority evaluation function is deployed inside the smart contract , which takes the interaction frequency feature I and the key frame request frequency feature as inputs, and outputs a dynamic priority score . The mathematical expression of the priority evaluation function is:

[0165]

[0166] where, and are weight coefficients. In this embodiment, .

[0167] The smart contract will calculate the dynamic priority score. The dynamic priority of the meeting is determined by comparing it with a preset priority threshold. The preset priority thresholds are as follows:

[0168] like If the value is ≥0.8, it is considered a high priority.

[0169] If 0.5≤ If the value is less than 0.8, it is considered a medium priority.

[0170] like If the value is less than 0.5, it is considered a low priority.

[0171] Smart contracts replace the original meeting priorities with dynamic priorities. The dynamic priorities are input into a dynamic threshold function to recalculate the adaptive trigger threshold value corresponding to the dynamic priorities. This replaces the original adaptive trigger threshold T. This dynamic priority adjustment mechanism can adjust the triggering conditions for resource reconfiguration in real time according to the actual interaction of the meeting, making resource scheduling more flexible and reasonable.

[0172] When the resource reconfiguration trigger conditions are met, the smart contract enters the resource reconfiguration management scheme calculation phase. The smart contract first calculates bandwidth and computing resource quotas based on the first mapping relationship between bitrate jitter characteristics and bandwidth compensation, and the second mapping relationship between packet loss rate characteristics and computational redundancy. Then, it uses the edge node registration list and the resource scheduling cost optimization model to determine the target node. Thus, quota mapping addresses the question of "how many resources are needed," while the cost optimization model addresses the question of "which node should bear the load at the lowest operating cost."

[0173] The first mapping relationship is expressed as: Where B is the bandwidth compensation amount and J is the bit rate jitter rate matrix. The first mapping relationship adopts a piecewise linear function, and its mathematical expression is:

[0174]

[0175] in, The first bitrate jitter threshold, This is the second bitrate jitter threshold. The slope coefficient, This is the maximum bandwidth compensation amount. In this embodiment, .

[0176] The second mapping relationship is expressed as follows: ,in To calculate redundancy, P is the spatial distribution matrix of packet loss rate. The second mapping relationship also uses a piecewise linear function, and its mathematical expression is:

[0177]

[0178] in, The first packet loss rate threshold, This is the second packet loss rate threshold. The slope coefficient, This represents the maximum computational redundancy. In this embodiment, .

[0179] The smart contract inputs the video stream bitrate jitter characteristics into the first mapping relationship to obtain the bandwidth compensation amount. The bandwidth allocation quota is equal to the sum of the original bandwidth quota and the bandwidth compensation amount. It inputs the packet loss rate characteristics into the second mapping relationship to obtain the computational redundancy amount. The computational resource allocation quota is equal to the sum of the original computational resource quota and the computational redundancy amount. These quotas serve as requirement constraints for the resource reconfiguration management scheme and are written into the scheme record along with the execution priority corresponding to the meeting service level.

[0180] After calculating the bandwidth allocation quota and computing resource allocation quota, the smart contract reads the edge node registration list. This list stores node identifiers, geographical locations, affiliated subchains, total bandwidth capacity, used bandwidth, total computing power, used computing power, and network latency, as well as locked resource amounts, historical average response times, service availability, and resource scheduling success rates. The smart contract uses this existing operational data to calculate the real-time resource operating cost metrics for candidate nodes.

[0181] The smart contract first calculates the allocable bandwidth and allocable computing resources for each edge node, where allocable resources are the total capacity minus the used and locked resources. Then, it filters nodes whose allocable bandwidth is not less than the bandwidth allocation quota and whose allocable computing resources are not less than the computing resource allocation quota. This filtering step serves as an executability constraint before cost optimization, preventing nodes with low cost indicators but insufficient resources from being included in the management scheme.

[0182] For a candidate edge node n, the smart contract calculates the resource scheduling cost index Cn = αCocc,n + βCcross,n + γCmig,n + δCsla,n according to a preset resource scheduling cost optimization model. Here, Cocc,n is determined by the resource occupancy ratio, Ccross,n by the node's subchain and network latency, Cmig,n by the computing resource quota to be migrated, and Csla,n by the meeting service level and the node's historical service quality. α, β, γ, and δ are preset weights. The smart contract selects the node that meets the quota requirements and has the lowest resource scheduling cost index as the target edge node. This model only performs a management-side ranking of the original candidate node selection results and does not change the bandwidth quota, computing quota, or the underlying migration execution method.

[0183] In one optional embodiment, when the difference in resource scheduling cost metrics among multiple candidate nodes is less than a preset threshold, the smart contract uses a comprehensive service quality score for secondary ranking. The comprehensive service quality score is formed by average response time, service availability, and resource scheduling success rate; if the scores are still the same, the node with the shorter cross-chain coordination path is selected. This ranking result, the data version used, and the model weights are all written into the resource reconfiguration management scheme for easy subsequent auditing and model correction.

[0184] In this embodiment, Table 3 provides examples of resource quota calculations under different conference service levels and link demand states. The bandwidth quota and calculation quota in the table are used for candidate node feasibility screening; when actually generating a management plan, the target edge node also needs to be determined in conjunction with resource scheduling cost indicators.

[0185] Table 3 Example of Resource Scheduling Quota Management

[0186]

[0187] As shown in Table 3, with the increase of bitrate jitter and packet loss rate characteristics, the bandwidth compensation and computational redundancy increase accordingly; the conference service level affects the trigger threshold and execution priority. Combining demand quotas, service levels, and real-time resource operation costs of candidate nodes can reduce local overload caused by simply adding resources and ensure that idle nodes are prioritized for utilization when service constraints are met.

[0188] After the smart contract identifies the target edge node, it generates a resource reconfiguration management plan. The plan includes at least a plan identifier, meeting identifier, meeting service level, source edge node, target edge node, bandwidth allocation quota, computing resource allocation quota, execution priority, expected resource release amount, and current status. The meeting operation management platform presents the plan as a visual scheduling list and generates resource scheduling task work orders; cross-link communication is handled by the protocol to transmit machine-readable parameters from the work orders.

[0189] After receiving a resource scheduling task work order across links, the contract queries the routing mapping table based on the target edge node identifier to determine the edge resource pool subchain to which the target node belongs, and updates the work order status to "resources to be locked". The routing mapping table stores the correspondence between edge node identifiers and subchain identifiers, and the work order identifier is associated with the resource reconfiguration management scheme identifier.

[0190] A cross-link contract broadcasts a resource lock request to the target edge resource pool subchain. The request includes a work order identifier, the target edge node identifier, bandwidth allocation quota, computing resource allocation quota, execution priority, request identifier, and a cross-link contract signature. By including the work order identifier in the lock request, a correspondence can be established between the management-side task status and the underlying resource reservation behavior.

[0191] After verifying the signature of the request, the edge resource pool subchain queries the local resource status of the target node to confirm whether its allocable resources still meet the work order quota. If they do, a resource locking instruction is sent to the edge resource pool to lock the corresponding bandwidth and computing resources. If the resource status changes after the scheme is generated and the quota cannot be met, the reason for the locking failure is returned, and the smart contract re-executes the candidate node screening and cost ranking accordingly.

[0192] The edge resource pool reserves specified bandwidth and computing resources to prevent them from being occupied by other scheduled tasks. After a successful lock, the edge resource pool returns a confirmation message to the sub-chain containing the work order identifier, request identifier, and lock success identifier; the sub-chain sends the confirmation message to the main chain, and the meeting operation management platform updates the visual scheduling list and task work orders to "resource locked" accordingly.

[0193] After receiving the resource lock confirmation from the cross-chain contract, the task order is converted into a cross-chain transaction data structure. This data structure includes the transaction hash, order identifier, scheme identifier, sender address, receiver subchain identifier, target edge node identifier, bandwidth allocation quota, computing resource allocation quota, execution priority, resource lock confirmation identifier, and cross-chain contract signature, realizing the traceable conversion from management scheme to trusted execution data.

[0194] The cross-chain transaction data structure is routed to the target edge resource pool subchain by the contract. After verifying the transaction signature, resource lock confirmation, and work order status, the subchain parses the machine-readable execution parameters and sends them to the edge resource pool, while updating the work order status to "in execution". Thus, the external output is a visual scheduling list and task work order, while internally, automated control is still achieved through cross-chain transactions and execution parameters.

[0195] The edge resource pool adjusts the video stream transmission bandwidth according to the bandwidth allocation quota in the work order, allocates computing resources according to the computing resource allocation quota, and performs video stream routing adjustment and computing task migration. After completion, the edge resource pool returns the actual activated quota, migration time, amount of resources released by the original node, bitrate jitter value after scheduling, packet loss rate value, and execution result; the conference operation management platform updates the work order to "execution completed" or "execution failed" accordingly.

[0196] In one optional embodiment, the smart contract performs online corrections to the first mapping relationship, the second mapping relationship, and the resource scheduling cost optimization model. After the edge resource pool performs scheduling, it collects actual scheduling effect data, including the bitrate jitter value, packet loss rate value, average opinion score of the video stream, target node resource utilization, original node resource release amount, migration time, and work order execution success status.

[0197] The smart contract constructs the first training sample from the actual link recovery status, bitrate jitter characteristics, and bandwidth compensation amount; and constructs the second training sample from the actual link recovery status, packet loss rate characteristics, and computational redundancy amount. It also constructs the cost model correction sample from the target node resource utilization, migration time, scheduling success status, conference service level, and resource scheduling cost indicators. Each sample is associated with a scheme identifier and a work order identifier, forming a traceable record of scheduling performance.

[0198] The first objective of gradient descent optimization is to minimize the error between the actual link recovery state and the desired link recovery state, in order to correct the bandwidth and computational quota mapping. The second objective is to reduce the deviation between actual resource utilization, migration time, and scheduling success results and the preset management objectives, in order to correct the weights of the resource scheduling cost model. For the link recovery state, the error function is the mean squared error, and its calculation formula is:

[0199]

[0200] in, The mean square error of the link recovery status. This represents the actual link recovery status value. The expected link recovery status value. This represents the number of training samples.

[0201] The smart contract adjusts the parameters of the first and second mapping relationships through gradient descent, reducing the link recovery error function; and adjusts the weights of resource occupancy costs, cross-domain coordination costs, migration costs, and service quality loss costs based on the cost model correction samples. Thus, the system can continuously optimize quota calculation and candidate node ranking based on historical work order effects without changing the underlying execution link.

[0202] This embodiment details the dynamic threshold logic for association of meeting service levels, resource quota calculation, resource scheduling cost optimization, generation of resource reconfiguration management schemes, conversion of visual scheduling lists and task work orders, cross-chain execution, and effect feedback process. This closed loop transforms real-time technical status into auditable resource management decisions, taking into account meeting service priorities, cross-domain resource utilization, and execution reliability, while retaining the original oracle consensus, resource locking, routing adjustment, and computation task migration techniques.

[0203] In one embodiment, a cloud video conferencing resource scheduling and management system based on a decentralized oracle network is also provided. The system includes a data acquisition and feature formation module, an oracle consensus verification module, a smart contract scheduling decision module, a management scheme and task order module, a cross-chain execution module, and a feedback optimization module. The data acquisition and feature formation module acquires link status data, conferencing service level data, and edge node resource operation data to form resource scheduling status data; the oracle consensus verification module performs multi-node cross-comparison and threshold consensus verification on the resource scheduling status data and writes it to the blockchain; the smart contract scheduling decision module performs dynamic threshold judgment, resource quota calculation, candidate node screening, and resource scheduling cost optimization.

[0204] The management scheme and task order module generates a resource reconfiguration management scheme that includes target edge nodes, bandwidth quotas, computing quotas, and execution priorities, and converts it into a visual scheduling list and resource scheduling task orders. The cross-chain execution module handles resource locking, trusted transmission of task order parameters, route adjustment, and computing task migration. The feedback optimization module recovers actual resource utilization, resource release amount, migration time, link recovery status, and task execution status, and corrects quota mapping and resource scheduling cost models. Each module can be deployed in the meeting operation management platform, main chain smart contracts, oracle nodes, and edge resource pools, and its processing steps correspond one-to-one with the above method embodiments.

Claims

1. A cloud video conferencing resource scheduling and management method based on a decentralized oracle network, characterized in that, include: Acquire link status data, meeting service level data, and edge node resource operation data of cloud video conferencing; extract video stream bitrate jitter features and packet loss rate features from the link status data as underlying features of resource requirements, and associate the underlying features of resource requirements with the meeting service level data and the edge node resource operation data to form resource scheduling status data; The resource scheduling status data is input into a decentralized oracle network, which performs multi-node cross-comparison consensus verification on the resource scheduling status data, and writes the resource scheduling status data into the blockchain after the verification is successful. The smart contract on the blockchain reads the resource scheduling status data, determines whether to trigger resource reconfiguration based on the resource dynamic adjustment threshold logic associated with the meeting service level data, and calculates the bandwidth allocation quota and the resource allocation quota according to the resource quota mapping relationship when triggered. The smart contract filters candidate edge nodes that meet the bandwidth allocation quota and the computing resource allocation quota based on the edge node resource operation data, and determines the target edge node from the candidate edge nodes according to the preset resource scheduling cost optimization model, and generates a resource reconfiguration management scheme that includes the target edge node identifier, bandwidth allocation quota, computing resource allocation quota and execution priority. The resource reconfiguration management scheme is converted into a visual scheduling list and resource scheduling task work orders. The execution parameters of the resource scheduling task work orders are sent to the edge resource pool corresponding to the target edge node through a cross-link protocol. The edge resource pool completes resource locking, video stream routing adjustment and computation task migration according to the execution parameters and sends back the execution results. The status of the visual scheduling list and the resource scheduling task work orders is updated according to the execution results.

2. The method according to claim 1, characterized in that, The process of generating the resource scheduling status data includes: performing differential calculation on the bit rate fluctuation data in the link status data within a preset time window to generate a bit rate jitter rate change matrix; Extract the timestamps and source address identifiers of packet loss events from the link status data to construct a spatial distribution matrix of packet loss rate; obtain meeting service management features including meeting priority, interaction frequency features, and keyframe request frequency features; The bitrate jitter change rate matrix and the packet loss rate spatial distribution matrix are concatenated to generate a multi-dimensional joint feature matrix. The multi-dimensional joint feature matrix is ​​then associated with the conference service management features and the edge node resource operation data according to the conference identifier and collection timestamp to form the resource scheduling status data.

3. The method according to claim 2, characterized in that, The decentralized oracle network performs multi-node cross-comparison consensus verification on the resource scheduling status data, including: multiple oracle nodes in the decentralized oracle network digitally sign the resource scheduling status data respectively to generate a status signature share; The state signature share is broadcast among the multiple oracle nodes; Each oracle node verifies the received state signature share and aggregates the verified state signature shares based on a threshold consensus mechanism, including: obtaining the historical verification accuracy of each oracle node in the historical consensus process in the decentralized oracle network; Dynamic weight values ​​are assigned to each oracle node based on the historical verification accuracy. In the threshold consensus mechanism, the state signature share of each oracle node is multiplied by the corresponding dynamic weight value to obtain the weighted signature share; Accumulate all weighted signature shares and determine whether the accumulation result reaches the preset consensus threshold. If this is achieved, the weighted signature shares are aggregated. Abnormal state signature shares with deviations exceeding a preset deviation threshold are removed, and the verified resource scheduling state data is recovered based on the aggregated state signature shares.

4. The method according to claim 1, characterized in that, Determining whether to trigger resource reconfiguration based on the resource dynamic adjustment threshold logic associated with the conference service level data includes: pre-deploying a dynamic threshold function associated with the conference service level in the smart contract; The underlying characteristics of the resource requirements and the meeting service level data are input into the dynamic threshold function, and the adaptive trigger threshold value is calculated and output through the dynamic threshold function. Compare the adaptive trigger threshold value with the actual feature value of the underlying resource demand feature; If the actual feature value is greater than or equal to the adaptive trigger threshold value, it is determined that the trigger condition of the resource dynamic adjustment threshold logic is met, and the execution priority of the resource reconfiguration management scheme is determined according to the meeting service level.

5. The method according to claim 4, characterized in that, The smart contract generates the resource reconfiguration management scheme, including: establishing a first mapping relationship between bitrate jitter characteristics and bandwidth compensation amount, a second mapping relationship between packet loss rate characteristics and computational redundancy amount, and a resource scheduling cost optimization model within the smart contract; The bitrate jitter feature is input into the first mapping relationship to calculate the bandwidth allocation quota. The packet loss rate feature is input into the second mapping relationship to calculate the computing resource allocation quota. Based on the edge node resource operation data, candidate edge nodes that meet the bandwidth allocation quota and the computing resource allocation quota are screened. The resource scheduling cost optimization model calculates the resource scheduling cost index based on the resource occupancy ratio, network latency, task migration requirements, sub-chain to which the candidate edge node belongs, and historical service quality. The candidate edge node that meets the quota requirements and has the smallest resource scheduling cost index is determined as the target edge node.

6. The method according to claim 1, characterized in that, The execution parameters of the resource scheduling task work order are sent to the edge resource pool corresponding to the target edge node through the cross-link protocol, including: generating a resource scheduling task work order associated with the scheme identifier according to the resource reconfiguration management scheme, and broadcasting a resource locking request associated with the work order identifier to the sub-chain corresponding to the edge resource pool where the target edge node is located through the cross-link protocol. The subchain verifies the resource locking request, and after successful verification, locks the resources in the edge resource pool corresponding to the bandwidth allocation quota and the computing resource allocation quota, and fills the locking result back into the resource scheduling task work order; After receiving the resource lock confirmation message returned by the sub-chain, the execution parameters, work order identifier and resource lock confirmation identifier in the resource scheduling task work order are encapsulated into a cross-chain transaction data structure; The cross-chain transaction data structure is routed to the sub-chain via the cross-chain routing protocol. The sub-chain parses the execution parameters and sends them to the edge resource pool for execution. At the same time, the status of the resource scheduling task work order is updated according to the execution results returned by the edge resource pool.

7. The method according to claim 2, characterized in that, Before associating the multi-dimensional joint feature matrix with the conference business management features and the edge node resource operation data, the method further includes: calculating the covariance matrix of the multi-dimensional joint feature matrix and extracting the eigenvalues ​​and eigenvectors of the covariance matrix. Arrange the eigenvectors in descending order of their eigenvalues, and select a predetermined number of the eigenvectors at the top of the sort to construct the principal component projection matrix; The multi-dimensional joint feature matrix is ​​projected onto the principal component projection matrix, and feature dimensions with variance contribution rates lower than a preset contribution threshold are filtered out to generate a dimensionality-reduced joint feature matrix. The reduced-dimensional joint feature matrix is ​​used as the underlying feature of the resource requirement and associated with the meeting business management feature and the edge node resource operation data.

8. The method according to claim 4, characterized in that, Determining the meeting service level includes: real-time collection of interaction frequency characteristics and keyframe request frequency characteristics within the cloud video conference; The interaction frequency characteristics and the keyframe request frequency characteristics are input into the smart contract, and a dynamic priority score is calculated through the priority evaluation function. The meeting service level is updated using the dynamic priority score. The updated meeting service level is then input into the dynamic threshold function to recalculate the corresponding adaptive trigger threshold value and execution priority.

9. The method according to claim 5, characterized in that, Also includes: After the resource scheduling task work order is executed in the edge resource pool, actual scheduling effect data is collected. The actual scheduling effect data includes actual link recovery status data, target edge node resource utilization rate, original edge node resource release amount, migration time and work order execution status. The actual link recovery status data, the bit rate jitter feature, and the bandwidth compensation amount are used to construct the first training sample. The actual link recovery status data, the packet loss rate feature, and the computational redundancy amount are used to construct the second training sample. The target edge node resource utilization rate, the original edge node resource release amount, the migration time, the work order execution status, the conference service level, and the corresponding resource scheduling cost indicators are used to construct the cost model correction sample. The first training sample and the second training sample are input into the smart contract, and the first mapping relationship and the second mapping relationship are corrected by gradient descent. The weights of the resource scheduling cost optimization model are updated according to the cost model correction sample.

10. A cloud video conferencing resource scheduling and management system based on a decentralized oracle network, characterized in that, The method for implementing any one of claims 1 to 9 includes: The data acquisition and feature formation module is used to acquire link status data, conference service level data, and edge node resource operation data, and form resource scheduling status data. The oracle consensus verification module is used to perform multi-node cross-comparison consensus verification on the resource scheduling status data and write it into the blockchain after the verification is successful. The smart contract scheduling decision module is used to determine whether to trigger resource reconfiguration based on the resource dynamic adjustment threshold logic associated with the conference service level, calculate the bandwidth allocation quota and the resource allocation quota, and determine the target edge node based on the resource scheduling cost optimization model. The management scheme and task work order module is used to generate resource reconfiguration management schemes and convert the resource reconfiguration management schemes into visual scheduling lists and resource scheduling task work orders. The cross-chain execution module is used to reliably send the execution parameters of the resource scheduling task work order to the target edge resource pool to complete resource locking, video stream routing adjustment and computing task migration; The feedback optimization module is used to correct the resource quota mapping relationship and the resource scheduling cost optimization model based on the link recovery status, resource utilization, resource release amount, migration time and work order execution status returned by the target edge resource pool.

Images