Resource scheduling method and device, medium and program product

Abstract

The invention provides a resource scheduling method and device, a medium and a program product. The resource scheduling method provided by the embodiment of the invention comprises the following steps: acquiring a plurality of resource requests; a feature tuple of each resource request is extracted, the feature tuple comprises at least one feature item, and each feature item represents a standardization result of one feature of the resource request; and based on the feature tuple, determining a merging strategy of the plurality of resource requests, the merging strategy being used for indicating a resource scheduling mode of the plurality of resource requests.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a resource scheduling method, device, medium, and program product. Background Technology

[0002] In various business scenarios, to achieve rich interactive functions and user experience, it is often necessary to integrate multiple computing models, such as speech recognition models, natural language processing models, and text generation models, to collaboratively process business flow data. During this collaborative processing, there is a problem of repeated resource calls. Summary of the Invention

[0003] This disclosure provides a resource scheduling method, apparatus, medium, and program product.

[0004] In a first aspect, embodiments of this disclosure provide a resource scheduling method, comprising:

[0005] Get multiple resource requests;

[0006] Extract feature tuples for each resource request, wherein each feature tuple includes at least one feature term, and each feature term represents the standardized result of a feature of the resource request;

[0007] Based on the feature tuples, a merging strategy for the multiple resource requests is determined, and the merging strategy is used to indicate the resource scheduling method for the multiple resource requests.

[0008] In a second aspect, embodiments of this disclosure provide a communication device, which includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements the resource scheduling method described in the first aspect.

[0009] Thirdly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the resource scheduling method described in the first aspect.

[0010] Fourthly, embodiments of this disclosure provide a computer program product, which includes a computer program that, when executed by a processor, implements the resource scheduling method described in the first aspect.

[0011] In this embodiment, after acquiring multiple resource requests, feature tuples for each resource request are first extracted to obtain standardized results for at least one feature of each resource request. Then, based on the feature tuples, a merging strategy for multiple resource requests is determined to determine the resource scheduling method for the multiple resource requests. In this way, even when each business entity operates independently and is unaware of each other, a unified structured modeling mechanism converts resource requests of different business types and formats into a unified structured representation, i.e., feature tuples. This achieves semantic alignment across business entities, provides opportunities for resource reuse, reduces model calls and the number of times input content is copied, improves resource utilization, lowers costs, and enhances user experience. Attached Figure Description

[0012] In the accompanying drawings of the embodiments disclosed herein:

[0013] Figure 1 This is a schematic diagram illustrating the calling relationship between resource entities and models provided in the embodiments of this disclosure.

[0014] Figure 2 This is a schematic diagram of the architecture of a communication network provided in an embodiment of this disclosure.

[0015] Figure 3 A flowchart of a resource scheduling method provided in an embodiment of this disclosure.

[0016] Figure 4 This is a block diagram of a communication device provided in an embodiment of the present disclosure.

[0017] Figure 5 This is a block diagram illustrating the composition of a computer-readable medium provided in an embodiment of the present disclosure.

[0018] Figure 6 A flowchart of a resource scheduling method provided in an embodiment of this disclosure.

[0019] Figure 7 A flowchart of a resource scheduling method provided in an embodiment of this disclosure.

[0020] Figure 8 This is an interactive schematic diagram of the resource scheduling method provided in the embodiments of this disclosure.

[0021] Figure 9 This is an interactive schematic diagram of the resource scheduling method provided in the embodiments of this disclosure.

[0022] Figure 10 This is an interactive schematic diagram of the resource scheduling method provided in the embodiments of this disclosure.

[0023] Figure 11 This is an interactive schematic diagram of the resource scheduling method provided in the embodiments of this disclosure.

[0024] Figure 12 This is an interactive schematic diagram of the resource scheduling method provided in the embodiments of this disclosure.

[0025] Figure 13 This is an interactive schematic diagram of the resource scheduling method provided in the embodiments of this disclosure. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions of this disclosure, the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0027] The present disclosure will be described more fully below with reference to the accompanying drawings; however, the embodiments shown may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will enable those skilled in the art to fully understand the scope of the disclosure.

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

[0029] Unless otherwise specified, each embodiment and feature of this disclosure may be used individually or in combination with other embodiments and features thereof.

[0030] Those skilled in the art will understand that various changes in form and detail may be made to the embodiments of this disclosure without departing from the scope of this disclosure as set forth by the appended claims.

[0031] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. The term "and / or" as used in this disclosure includes any and all combinations of one or more of the associated enumerated entries. The singular forms "a" and "the" as used in this disclosure are also intended to include the plural forms, unless the context clearly indicates otherwise. The terms "comprising," "made of," etc., as used in this disclosure specify the presence of the stated 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.

[0032] 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 defined in this disclosure.

[0033] This disclosure is not limited to the embodiments shown in the accompanying drawings, but includes modifications to the configuration based on the manufacturing process. Therefore, the areas illustrated in the drawings are schematic, and the shapes of the areas shown illustrate specific shapes of the areas of an element, but are not intended to be limiting.

[0034] In some related technologies, resource scheduling within a single business function can be achieved by selecting different model instances or invocation strategies based on request type (such as speech recognition and text generation) and system load (such as GPU / CPU utilization). However, this approach is limited to a single business function and cannot identify resource reuse across business entities. Since each business entity operates independently, unaware of each other's existence, and independently invokes underlying resources, resource waste still occurs.

[0035] Figure 1 This diagram illustrates the calling relationship between resource entities and models provided in embodiments of this disclosure. Figure 1 As shown, entities A, B, and C represent resource entities, while Automatic Speech Recognition (ASR) models, Computer Vision (CV) models, Text-to-Speech (TTS) models, and other models represent underlying resources. Entities A, B, and C can all call ASR models, CV models, TTS models, and other models. Suppose entity A needs to perform content recognition on user speech, and entity B needs to perform sentiment analysis on the same user speech. In related technologies, resource scheduling involves entities A and B calling the ASR model separately to process the same speech stream data, resulting in resource waste from repeated ASR model calls. As the number of services increases, the resource waste caused by repeated resource calls continues to grow. Furthermore, various service requests from different users often involve computationally intensive calls to underlying models, severely impacting the overall system performance and cost-effectiveness.

[0036] In this embodiment, after acquiring multiple resource requests, feature tuples for each resource request are first extracted to obtain standardized results for at least one feature of each resource request. Then, based on the feature tuples, a merging strategy for multiple resource requests is determined to determine the resource scheduling method for the multiple resource requests. In this way, even when each business entity operates independently and is unaware of each other, a unified structured modeling mechanism converts resource requests of different business types and formats into a unified structured representation, i.e., feature tuples. This achieves semantic alignment across business entities, provides opportunities for resource reuse, reduces model calls and the number of times input content is copied, improves resource utilization, lowers costs, and enhances user experience.

[0037] This disclosure can be applied to various business scenarios involving resource scheduling, such as new call scenarios or IoT scenarios involving large models. This disclosure uses an application in a 5G new call scenario as an example and is not intended to limit the application scenarios of this disclosure.

[0038] 5G New Call is a new generation of call products that breaks the limitations of traditional calls which can only be voice or simple video, and upgrades calls into a comprehensive service that integrates multimedia interaction and intelligent services. In the 5G New Call service scenario, multiple computing models such as speech recognition model, natural language processing model, and text generation model are integrated together to process business flow data collaboratively. The 5G New Call processing flow is designed with multiple business entities. Each business entity will call one or more corresponding underlying processing models according to its preset processing logic and functional requirements to realize speech recognition, subtitle processing, dynamic effect overlay, etc. The above-mentioned underlying processing models have the following characteristics: (1) The call of each model is based on its specific function, and the input and output data types are strictly corresponding. For example, the input of the Automatic Speech Recognition (ASR) model is the original speech stream data packet, and the output is the corresponding text; while the input of the Text-to-Speech (TTS) model is text data, and the output is synthesized speech. (2) Significant resource consumption: such models require a large amount of computing resources (such as GPU computing power, CPU resources, and memory bandwidth) for a single call. In scenarios such as GPU-accelerated inference, the cost of related hardware resources is particularly high. (3) Significant processing latency: Due to the complexity of the model itself, the processing latency of a single model call is usually high. (4) For the forwarding and copying of the input media stream between the terminal and the entity, the corresponding processing will occupy computing resources and bandwidth, as well as increase latency, affecting the user experience. Copying means that the media stream is transmitted during the call between users, but in order to perform business processing, a copy of the media stream needs to be made to the entity so that the model can be called for business processing.

[0039] In 5G new calls, the resource scheduling mechanisms of various services operate independently, leading to duplicate resource calls. That is, when multiple services in a session need to process the same input data, they will independently call the same model resources, resulting in serious resource waste.

[0040] This disclosed embodiment achieves semantic alignment across business entities without each other's awareness while operating independently, providing opportunities for resource reuse, creating conditions for reducing model calls and the number of times input content is copied, improving resource utilization, reducing costs, and enhancing the user experience during 5G new calls.

[0041] Figure 2 This is a schematic diagram of the architecture of a communication network provided in an embodiment of this disclosure. The resource scheduling method provided in this embodiment can be applied to this communication network for multi-service resource scheduling optimization. Figure 2 As shown, the communication network includes a client layer, a service application layer, and a Unified Media Function (UMF) scheduling layer.

[0042] The client layer contains the access side. The client layer contains multiple session clients, such as... Figure 2 The Session 1 client and Session 2 client shown are examples of session clients that can serve as entry points for user requests.

[0043] The service application layer includes service entities and call control-related network elements, used to provide application services. The service application layer contains different service entities, such as... Figure 2 The Service AS-1 and Service AS-2 shown are respectively connected to the corresponding sessions, handle business logic and forward requests to UMF.

[0044] The business application layer can also include resource entities, such as Figure 2 Entities C and D, as shown, are resource entities responsible for business processing such as media copying and ASR-to-text conversion. Depending on the business support requirements, there can be multiple resource entities in the business application layer.

[0045] The UMF scheduling layer can include resource entities. For example... Figure 2 The diagram shows entities A and B. Resource entities are responsible for business processing such as media copying and ASR-to-text conversion. Depending on the business support requirements, there can be multiple resource entities in the UMF scheduling layer.

[0046] The UMF scheduling layer can also include a cache manager. The cache manager can provide cache management, including ASR result caching, model identifier matching, audio fingerprinting, and cross-session similarity recognition.

[0047] The UMF scheduling layer can identify the similarity of resource requests, determine the merging strategy for resource requests, perform resource scheduling, and conduct dynamic monitoring.

[0048] In this embodiment of the disclosure, the scheduling function of the UMF scheduling layer may include: resource request similarity identification, resource request processing decision, resource scheduling processing, and dynamic detection. Through the unified scheduling and cache management of the UMF scheduling layer, cross-session resource reuse and merging are realized, reducing redundant calculations (such as calls to the same ASR resources) and improving resource utilization.

[0049] Firstly, this disclosure provides a resource scheduling method. This resource scheduling method can be applied to the field of 5G new voice communication, and can also be used in other fields involving resource scheduling; this disclosure does not limit its application. This resource scheduling method can be applied to UMF, for example... Figure 2 The UMF shown.

[0050] Reference Figure 3 The resource scheduling method may include:

[0051] S101, retrieve multiple resource requests.

[0052] Resource requests can be used to request resources, such as model resources. For example, a resource request can be a raw business request. In this embodiment, multiple resource requests can originate from the same business or from different businesses. When multiple resource requests originate from different business entities, these businesses can originate from the same session or from different sessions. This embodiment does not limit the source of resource requests. Furthermore, the business types and formats of multiple resource requests can be the same or different.

[0053] Resource requests come from different business entities and come in various formats, including JSON API requests, XML configuration requests, HTTP protocol messages, and function calls.

[0054] S102, extract the feature tuples for each resource request.

[0055] In this embodiment of the disclosure, the feature tuple includes at least one feature term, each feature term representing the standardized result of a feature of the resource request. In one example, the at least one feature term includes one or more of a request feature, a response feature, and a metadata feature. The request feature corresponds to the input of the resource request and can represent the standardized result of the resource request input information; the response feature corresponds to the output of the resource request and can represent the standardized result of the resource request output information; the metadata feature corresponds to the metadata of the resource request and can represent the standardized result of the resource request metadata information.

[0056] UMF can first identify the request format type, then select the corresponding parser based on the request format type, and then parse the key information fields. For example, it can use predefined parsing rules or parsers to: extract business type identifiers, such as extracting speech-to-text from the JSON's service field, extracting ASR from the XML's type attribute, and extracting speech recognition from the HTTP URL; extract the format information of the original input data, such as audio_stream, voice_stream, etc.; extract the format information of the original output data, such as text, TEXT, subtitles, etc.; extract QoS parameters, such as P0, high, etc.; and extract metadata, such as session ID, business entity identifier, and timestamp, etc. Finally, it outputs a set of extracted key information fields. In this embodiment, key information fields may include one or more of the following: input-related information, output-related information, and metadata information. One or more of the standardized results of the input-related information, the standardized results of the output-related information, and the standardized results of the metadata information can be used as feature terms to form feature tuples.

[0057] S103, Based on the feature tuple, determine the merging strategy for the multiple resource requests.

[0058] The merging strategy can be used to indicate how multiple resource requests should be scheduled. In one example, the merging strategy can instruct multiple resource requests to be merged into one resource request, in which case resource scheduling can be performed according to the merged resource request. In another example, the merging strategy can instruct that multiple resource requests remain independent, in which case resource scheduling can be performed separately for each resource request.

[0059] UMF can determine the similarity between resource requests by measuring the similarity between their feature tuples. Resource requests with high similarity are merged into a single request, while those with low similarity remain independent. In one example, UMF can first calculate one or more of the similarities between request features, response features, and metadata features, and then perform a weighted sum of these similarities to obtain the overall similarity between feature tuples.

[0060] UMF can perform resource scheduling according to the merging strategy, or it can send the merging strategy to other network elements for resource scheduling. This disclosure does not limit this.

[0061] In this embodiment, after acquiring multiple resource requests, feature tuples for each resource request are first extracted to obtain standardized results for at least one feature of each resource request. Then, based on the feature tuples, a merging strategy for multiple resource requests is determined to determine the resource scheduling method for the multiple resource requests. In this way, even when each business entity operates independently and is unaware of each other, a unified structured modeling mechanism converts resource requests of different business types and formats into a unified structured representation, i.e., feature tuples. This achieves semantic alignment across business entities, provides opportunities for resource reuse, reduces model calls and the number of times input content is copied, improves resource utilization, lowers costs, and enhances user experience.

[0062] The process of extracting feature tuples from resource requests is explained below.

[0063] In some embodiments, step S102, extracting the feature tuple for each resource request, may include:

[0064] S1021, extract input-related information from the resource request, and determine one or more request features based on the standardization results of the input-related information.

[0065] The input-related information can refer to information related to the input of the resource request. In one example, the input-related information may include one or more of the following: original service type, format information of the original input data, content information of the original input data, original quality of service parameters, and processing mode of the original input data.

[0066] For example, the original business types include, but are not limited to, speech-to-text, speech recognition, and ASR.

[0067] For example, the format information of the raw input data includes, but is not limited to, text, audio, video, images, streaming, files, and batch processing.

[0068] For example, the content information of the raw input data can include a data description of the raw input data, such as the number of bytes and the sampling rate, or it can include the actual data content of the raw input data, such as the audio stream and pixel values.

[0069] For example, the original service quality parameters include, but are not limited to, level 0 and high.

[0070] The standardization process for the original business type is described below. In one possible implementation, the resource scheduling method provided in this disclosure embodiment may further include:

[0071] S201, Obtain a business type mapping table, which includes multiple standard business types and non-standard business types corresponding to each standard business type.

[0072] S202, in the business type mapping table, find the standard business type corresponding to the original business type.

[0073] S203, in response to finding a standard business type corresponding to the original business type, the found standard business type is determined as the standardization result of the original business type.

[0074] S204, in response to the absence of a standard business type corresponding to the original business type, the standard business type with the highest semantic similarity to the original business type in the business type mapping table is determined as the standardization result of the original business type.

[0075] The business type mapping table can include multiple standard business types, as well as non-standard types corresponding to each standard business type. In one example, standard business types can be set based on a business type dictionary. The business type dictionary contains a set of standard business types, including ASR, TTS, Natural Language Processing (NLP), EMOTION, and FRAUD_DETECTION, among others.

[0076] After obtaining the original business type, UMF looks up the business type mapping table and performs type mapping, mapping the original business types of different business entities to standard business types. If the original business type is found in a non-standard type in the business type mapping table, then the standard type corresponding to that non-standard type is the standard business type corresponding to the original business type. For example, non-standard business types such as speech-to-text, speech recognition, and ASR are mapped to the standard business type ASR; non-standard business types such as emotion recognition, sentiment analysis, and EMOTION are mapped to the standard business type EMOTION; and non-standard business types such as anti-fraud recognition and fraud detection are mapped to the standard business type FRAUD_DETECTION.

[0077] If the original business type is not found among the non-standard business types in the business type mapping table, semantic similarity can be used for matching. The standard business type with the highest semantic similarity to the original business type in the business type mapping table is determined as the standardized result of the original business type. At this time, the business type mapping table can be updated using this original business type, making the original business type the non-standard business type with the highest speech similarity to it. In this way, dynamically updating the business type mapping table can improve the accuracy of subsequent matching.

[0078] As one embodiment of this disclosure, the original business type is converted into standard business types such as ASR and EMOTION through the above-described standard processing procedure, thereby enabling semantic alignment of resource requests from different business entities in terms of business type.

[0079] The standardization process for the format information of the original input data is described below. In one possible implementation, the resource scheduling method provided in this disclosure embodiment may further include:

[0080] S205, convert the format information of the original input data into a first format type according to the data type dimension, data format dimension, and encoding format dimension.

[0081] S206, search for the standard format type corresponding to the first format type in the type compatibility rule table, and determine the standard format type as the standardization result of the format information of the original input data. The type compatibility rule table includes multiple standard format types and format types compatible with each standard format type.

[0082] First, UMF can convert the format information of the original input data into a first format type according to the data type dimension, data format dimension, and encoding format dimension.

[0083] UMF establishes a data type classification system, including one or more of the following dimensions: data type, data format, and encoding format. The data type dimension includes, but is not limited to, text, audio, video, and image. The data format dimension includes, but is not limited to, stream, file, and batch. The encoding format dimension includes, but is not limited to, PCM, AAC, H264, and MP3.

[0084] UMF performs type mapping and transformation based on a data type classification system, converting the format information of the original input data into a standard format type, i.e., the first format type, according to the data type classification system. For example, audio_stream, voice_stream, and audio streams are converted to AUDIO_STREAM; text, text, and subtitles are converted to TEXT; and video_stream and video streams are converted to VIDEO_STREAM.

[0085] Next, UMF searches the type compatibility rule table for the standard format type corresponding to the first format type, and determines the found standard format type as the standardized result of the original input data's format information. The type compatibility rule table includes multiple standard format types and the format types compatible with each standard format type. For example, audio tracks in audio and video streams can be unified as AUDIO_STREAM, meaning the standard format type AUDIO_STREAM is compatible with audio tracks in audio and video streams. When the first format type is an audio stream, the corresponding standardized result is AUDIO_STREAM; similarly, when the first format type is an audio track in a video stream, the corresponding standardized result is also AUDIO_STREAM. Similarly, text streams and text files can be unified as TEXT, meaning the standard format type TEXT is compatible with text streams and text files. When the first format type is a text stream, the corresponding standardized result is TEXT; similarly, when the first format type is a text file, the corresponding standardized result is also TEXT.

[0086] As one embodiment of this disclosure, the format information of the original input data is standardized through the above-described process, which converts the format information of the original input data into standard business types such as AUDIO_STREAM and TEXT, thereby achieving semantic alignment of resource requests from different business entities in terms of the format information of the input data.

[0087] The standardization process for the content information of the original input data is described below. In one possible implementation, the resource scheduling method provided in this disclosure embodiment may further include:

[0088] S207, perform a hash operation on the content information of the original input data to obtain a data fingerprint.

[0089] S208, the data fingerprint is determined as the standardized result of the content information.

[0090] In one example, the content information includes the actual data content and / or data description information of the original input data. After obtaining the content information of the original input data, UMF performs a hash operation on the content information, such as using MD5 or SHA256 to calculate the hash value of the content information, thereby generating a data fingerprint. It should be noted that if the content information is streaming, hash operations can be performed on data blocks or keyframes of the content information to generate a data fingerprint, such as hash_abc123.

[0091] The data fingerprint of content information can be used to represent key features of the input data. These key features include, but are not limited to, data size, sampling rate, resolution (width), resolution (height), duration, and encoding format. For example, data size can be the number of bytes, sampling rate can be 16kHz or 44.1kHz for audio, resolution can be 1920 (height resolution) x 1080 (width resolution) for video, duration can be the number of seconds, and encoding format can be PCM, AAC, H.264, etc.

[0092] UMF can use the above key features to construct feature vectors as a standardized result of content information.

[0093] As one embodiment of this disclosure, the content information of the original input data is standardized through the above-described process, which converts the content information of the original input data into a data fingerprint, thereby enabling semantic alignment of resource requests from different business entities in terms of the content information of the input data.

[0094] The standardization process for the original quality of service parameters is described below. In one possible implementation, the resource scheduling method provided in this disclosure embodiment may further include:

[0095] S209, find the service quality level that matches the original service quality parameter in the service quality level mapping table, and determine the service quality level as the standardized result of the original service quality parameter.

[0096] The service quality level mapping table can include multiple service quality levels and the parameter range corresponding to each service quality level.

[0097] Raw service quality parameters can be textual descriptions, numerical ratings, or numerical indicators. Textual descriptions can be high, medium, low, etc. Numerical ratings can be P0, P1, P2, etc. Numerical indicators can be latency requirements of less than 100ms, latency requirements of greater than 500ms, etc.

[0098] First, a service quality level mapping table is established to define a standard service quality level system. In one example, in the standard service quality level system, service quality level 0 is the highest priority, corresponding to raw service quality parameters such as P0, high, urgent, and critical; service quality level 1 is the medium priority, corresponding to raw service quality parameters such as P1, medium, normal, and standard; and service quality level 2 is the low priority, corresponding to P2, low, background, and best-effort.

[0099] Then, a service quality level mapping is performed. By querying the service quality level mapping table, the original service quality parameters with different representations are unified into a standard service quality level. For example, the textual description "high" is mapped to 0, "medium" to 1, and "low" to 2; the numerical level "P0" is mapped to 0, "P1" to 1, and "P2" to 2; the numerical indicator "less than or equal to 100ms" is mapped to 0, "greater than 100ms and less than 500ms" is mapped to 1, and others are mapped to 2. It should be noted that for numerical service quality parameters such as latency requirements and throughput requirements, this embodiment establishes a mapping rule from numerical range to service quality level. For example, latency less than or equal to 100ms is mapped to level 0, latency greater than 100ms and less than 500ms is mapped to level 1, and latency greater than or equal to 500ms is mapped to level 2.

[0100] In one example, UMF can also dynamically adjust the Quality of Service (QoS) level mapping table based on system load and historical performance. For instance, it can increase the QoS level requirement when the system load is high and decrease the QoS level requirement when the system load is low.

[0101] In one example, UMF can output a service quality level of 0, 1, or 2 as a standardized result of the original service quality parameters.

[0102] As one embodiment of this disclosure, the original service quality parameters are converted into a unified service quality level through the standardization process described above, thereby enabling semantic alignment of resource requests from different business entities in terms of service quality parameters.

[0103] In one example, the processing mode of the raw input data can include streaming (STREAM) or batch processing (BATCH). The processing mode of the raw input data can be obtained from the format information of the raw input data.

[0104] In some embodiments, step S102, extracting the feature tuple for each resource request, may include:

[0105] S1022, extract output-related information from the resource request, and determine one or more response features based on the standardization results of the output-related information.

[0106] The output-related information can represent information related to the output of the resource request. In one example, the output-related information may include one or more of the following: format information of the original output data, output content identifier of the original output data, and processing mode of the original output information.

[0107] The standardization process for the format information of the original output data is described below. In one possible implementation, the resource scheduling method provided in this disclosure embodiment may further include:

[0108] S301, convert the format information of the original output data into a second format type according to the data type dimension, data format dimension, and encoding format dimension.

[0109] S302, search for the standard type corresponding to the second format type in the type compatibility rule table, and determine the standard format type as the standardization result of the format information of the original output data. The type compatibility rule table includes multiple standard format types and format types compatible with each standard format type.

[0110] UMF performs type mapping transformation based on the data type classification system, converting the format information of the original output data into a standard format type, i.e., the second format type, according to the data type classification system. Then, UMF looks up the standard format type corresponding to the second format type in the type compatibility rule table, and determines the found standard format type as the standardized result of the original output data's format information.

[0111] The data type classification system and type compatibility rule table can be referenced from the standardized processing of the format information of the original input data, which will not be elaborated here.

[0112] As one embodiment of this disclosure, the format information of the original output data is standardized through the above-described process, which converts the format information of the original output data into standard business types such as AUDIO_STREAM and TEXT, thereby achieving semantic alignment of resource requests from different business entities in terms of the format information of the output data.

[0113] In one example, the output content identifier of the raw output data may include the output channel identifier or the result identifier, such as output_channel_1, output_channel_2, etc. The output content identifier can be obtained from the scheduling request.

[0114] In one example, the processing mode of the raw output data can include streaming or batch processing. The processing mode of the raw output data can be obtained from the format information of the raw output data.

[0115] In some embodiments, step S102, extracting the feature tuple for each resource request, may include:

[0116] S1023, extract metadata information from the resource request, and determine one or more metadata features based on the standardization results of the metadata information.

[0117] In one example, the metadata information includes one or more of the following: resource request identification information, business entity identification information, and request time information. The resource request identification information can be used to uniquely identify the resource request and to trace its origin; examples include session IDs and stream IDs. The business entity identification information can be used to identify the business entity that sent the resource request, i.e., the source of the resource request, such as AS-1, AS-2, etc. The request time information is a timestamp. The metadata information can be obtained from the resource request.

[0118] UMF can convert resource request identification information in metadata into standard format identifiers, such as session identifier + flow identifier; convert business entity identification information into standard format identifiers, such as AS-1, AS-2, etc.; and convert request time information into standard format timestamps, such as Unix timestamps, etc.

[0119] As one embodiment of this disclosure, the metadata information is converted into standard metadata through the above-described metadata information standardization process, thereby enabling semantic alignment of resource requests from different business entities in terms of metadata information.

[0120] UMF receives multiple resource requests. These requests originate from different business entities and vary in format. Resource requests may be JSON-formatted API requests, such as requests containing service type, input data, and QoS parameters, like {"service": "speech-to-text", "input": "audio_stream", "qos": "P0"}; or they may be XML-formatted configuration requests, such as requests containing request type, media type, and priority, like... <request type="ASR" media="voice_stream" priority="high" / >It could also be carried in the URL or body in the HTTP protocol message format. When receiving a resource request, UMF can also receive the resource request's metadata and context information. The metadata information includes, but is not limited to, business entity identifiers, session identifiers, timestamps, and resource request source information. The context information includes the system's current load status, historical request patterns, and descriptions of the business entity's capabilities. Subsequently, UMF obtains one or more of the input-related information, output-related information, and metadata information from the resource request and uses their normalized results to construct a feature tuple for the resource request.

[0121] UMF first assembles the request feature (Request_ID) tuple, combining the input information into a unified structure. The request feature tuple can include one or more request features, such as the original service type, the format information of the original input data, the content information of the original input data, the original quality of service parameters, or the standardized result of the original input data. Specifically, the request feature tuple can include one or more of the following: standard service type, standard format type of input data, data fingerprint, processing mode, and quality of service level. The standard service type is output through steps S201 to S204, such as ASR; the standard format type of input data is output through steps S205 to S206, such as AUDIO_STREAM; the data fingerprint is output through steps S207 to S208, such as hash_abc123; the processing mode is either streaming (STREAM) or batch processing (BATCH); and the quality of service level is output in step S209, such as 0, 1, or 2.

[0122] UMF then assembles the response feature (Response_ID) tuple, combining the output-related information into a unified structure. The response feature tuple can include one or more response features, which are the standardized results of the original output data. Specifically, the response feature tuple can include one or more of the following: the standard format type of the output data, the output content identifier, and the processing mode. The standard format type of the output data is the output of steps S301 and S302, such as TEXT; the output content identifier is the output channel identifier or result identifier, such as output_channel_1; and the processing mode is streaming or batch processing.

[0123] UMF then merges the metadata information. The metadata information includes one or more of the following: resource request identification information, business entity identification information, and request time information.

[0124] UMF ultimately outputs a unified format of feature tuples. For example, request features include the standard business type ASR, the standard input data format type AUDIO_STREAM, the data fingerprint hash_abc123, the input processing mode STREAM, and the service quality level 0. Response features include the standard output data format type TEXT, the output content identifier output_channel_1, and the output processing mode STREAM. Metadata features include the resource request identifier req_001, the business entity identifier AS-1, and the request time information 2025-11-06 10:00:00. The final output is a unified structured feature tuple, which can be used for subsequent similarity calculations and merging decisions.

[0125] Thus, by extracting the feature tuples of each resource request, semantic alignment of each resource request was achieved, providing an opportunity for resource request merging, which is conducive to resource reuse and improving resource utilization.

[0126] The process of determining the merging strategy for multiple resource requests based on feature tuples is explained below.

[0127] In some embodiments, step S103, based on the feature tuple, determining the merging strategy for the multiple resource requests may include:

[0128] S1031, Based on the feature tuples, determine multiple resource requests to be merged from the multiple resource requests, wherein the similarity between the feature tuples of any two resource requests to be merged is greater than a preset threshold.

[0129] Here, "resource requests to be merged" can represent resource merging requests to be merged. The number of resource requests to be merged can be two or more. A preset threshold can be used to measure the similarity between feature tuples. If the similarity between feature tuples is greater than the preset threshold, it indicates that the corresponding resource requests are semantically similar and have the potential to be merged. The corresponding resource request can then be identified as a resource request to be merged for further evaluation. The preset threshold can be set as needed, for example, it can be set to 90% or 95%. This embodiment of the disclosure does not impose any limitations on the preset threshold.

[0130] In one example, a resource request can be selected as a reference resource request from multiple resource requests. For each remaining resource request, the similarity between the feature tuples of that resource request and the reference resource request is calculated. Resource requests whose similarity to the feature tuples of the reference resource request is greater than a preset threshold, along with the reference resource request, are identified as resource requests to be merged. For example, the multiple resource requests include resource request 1, resource request 2, ..., resource request 10. Assuming resource request 1 is the reference resource request, and the similarity between resource request 2 and resource request 3 and the feature tuples of resource request 1 is greater than a preset threshold, and the similarity between resource request 4 to resource request 10 and the feature tuples of resource request 1 is greater than a preset threshold, then resource request 1, resource request 2, and resource request 3 are identified as resource requests to be merged.

[0131] In another example, multiple resource requests can be clustered based on the similarity between feature tuples, and the resource requests in each cluster result can be identified as a group of resource requests to be merged.

[0132] S1032, Obtain system status parameters, which are used to characterize the impact of merging the multiple resource requests to be merged into one resource request.

[0133] In some embodiments, the system status parameters include one or more of the following: quality score, latency change, resource cost change, and system load. The quality score, latency change, and resource cost change respectively represent the changes in quality, latency, and resource cost after the multiple resource requests to be merged are merged into one resource request. The system load is used to reflect the current system load status.

[0134] S1033, Determine the merging strategy based on the system status parameters.

[0135] The merging strategy can be used to instruct multiple resource requests to be merged into one resource request or to keep multiple resource requests independent.

[0136] If merging multiple resource requests into one would result in a significant decrease in quality, a significant increase in latency, and minimal resource cost savings, or if the current system load is low, then the multiple resource requests can be kept independent. Conversely, if merging multiple resource requests into one would have a minor impact on quality, a minor impact on latency, a significant resource cost saving, or if the current system load is high, then the multiple resource requests can be merged into one.

[0137] In one possible implementation, step S1033, determining the merging strategy based on the system state parameters, may include:

[0138] S10331, a weighted sum is performed on one or more of the quality score, the delay change, the resource cost change, and the system load to obtain a combined score.

[0139] In this embodiment, a multi-dimensional merged score is constructed, which supports dynamic weight configuration and triggers subsequent processing by combining threshold grading (i.e., similarity grading, such as high similarity, medium similarity, and low similarity) to achieve fine-grained identification and reuse opportunities.

[0140] S10332, Determine the merging strategy based on the merging score.

[0141] In one example, step S10332, which determines the merging strategy based on the merging score, may include: merging the plurality of resource requests to be merged into one resource request in response to the merging score being greater than or equal to a first threshold; and / or, keeping the plurality of resource requests to be merged independent in response to the merging score being less than the first threshold.

[0142] The first threshold can be used to measure the merging score. If the merging score is greater than or equal to the first threshold, it indicates that merging multiple resource requests into one resource request has little impact on quality and latency, and the current system load is high. Therefore, multiple resource requests can be merged into one resource request to save resources. If the merging score is less than the first threshold, it indicates that merging multiple resource requests into one resource request may significantly decrease quality and significantly increase latency, and the current system load is low. Therefore, multiple resource requests can remain independent. The first threshold can be set as needed, and this embodiment does not limit the first threshold.

[0143] The step of keeping the multiple resource requests to be merged independent in response to the merge score being less than the first threshold includes: starting a timer in response to the merge score being greater than or equal to a second threshold and less than the first threshold; keeping the multiple resource requests to be merged independent in response to the timer not reaching a third threshold; reacquiring the system status parameters in response to the timer reaching the third threshold; and / or, keeping the multiple target resource requests independent in response to the merge score being less than the second threshold until the change in the system status parameters is greater than a fourth threshold.

[0144] As an embodiment of this disclosure, keeping multiple resources to be merged independent can be further subdivided into two cases: those with merging potential and those without. A second threshold can be used to measure the merging score to determine whether the multiple resources to be merged have merging potential. The second threshold can be set as needed, and it should be understood that the second threshold is less than the first threshold.

[0145] If the merge score is greater than or equal to the second threshold but less than the first threshold, a delayed decision can be made, and the decision can be made again after a certain period of time. Therefore, if the merge score is greater than or equal to the second threshold but less than the first threshold, a timer can be started. Before the timer reaches the third threshold, multiple resource requests to be merged remain independent; after the timer reaches the third threshold, system parameters are reacquired, and the merge score is recalculated based on the reacquired system parameters. When recalculating the merge score, the system load may decrease, resulting in an increase in the merge score, thus enabling the merging of multiple resource requests to be merged.

[0146] The third threshold can be used to measure the waiting time for reassessment. The third threshold can be set as needed, and there is no limitation on the third threshold in this embodiment.

[0147] The fourth threshold measures whether the change in system status parameters is excessive. The fourth threshold can be set as needed. When the change in system status parameters exceeds the fourth threshold, it indicates that there may have been significant changes in audio / video quality, latency, resource consumption, and system load. The probability of a change in the merging strategy is high; for example, it may be necessary to split multiple merged resource requests into independent resource requests, or to merge multiple independent resources into a single resource request. Therefore, the merging strategy should be redefined in this case. When the change in system status parameters is less than or equal to the fourth threshold, it indicates that the changes in audio / video quality, latency, resource consumption, and system load may be minor. The probability of a change in the merging strategy is low; therefore, it is not necessary to redefine the merging strategy.

[0148] It should be understood that each item in the system state parameters can correspond to a fourth threshold. When the change of any item parameter is greater than its corresponding fourth threshold, it can be determined that the change of the system state parameter is greater than the fourth threshold.

[0149] In this embodiment, the merge scoring system incorporates factors such as quality, latency, cost, load, and switching costs to dynamically determine whether to merge, delay, reject, or split. Thus, the merge decision is not a one-time static decision but rather supports a dynamic and reversible decision-making mechanism. First, an initial decision is made: based on the merge score, similar requests to be merged are decided to merge, delay the merge, or reject the merge. Then, a dynamic monitoring loop is entered: after the merge is executed, changes in parameters such as quality, latency, cost, load, and switching costs are continuously monitored. Reversible operations can be implemented in dynamic monitoring: when parameter changes are detected that cause the decision to be no longer optimal, the system can be dynamically split and resume independent processing. Re-decision can also be implemented in dynamic monitoring: after splitting or after the delay decision times out, the merge decision is re-performed. This mechanism overcomes the problem that static rules cannot adapt to complex operating environments and achieves adaptive resource scheduling.

[0150] In some embodiments, the resource scheduling method provided in this disclosure may further include:

[0151] S104, in response to the change in the system state parameter being greater than the fourth threshold, the merged score is re-determined based on the re-acquired system state parameter;

[0152] Step S104 can be referred to step S10331, and will not be repeated here.

[0153] S105, in response to the re-determined merge score being less than the second threshold, the merged resource request is split into multiple independent resource requests.

[0154] After recalculating the merge score, if the merge score is less than the second threshold, it indicates that the merged resource requests no longer meet the merging conditions and therefore need to be split into multiple independent resource requests.

[0155] After recalculating the merge score, if the merge score is greater than or equal to the first threshold, it indicates that the resource requests that remain independent can be merged into one resource request, and therefore multiple resource requests need to be merged.

[0156] As one embodiment of this disclosure, by monitoring changes in system status parameters and dynamically adjusting the merging strategy, resource requests are split and merged in a timely manner, which reduces the impact on quality and saves resources.

[0157] In this embodiment of the disclosure, merged resource requests are dynamically split according to changes in the operating state, allowing them to resume independent processing, thus ensuring system robustness.

[0158] In some embodiments, the resource scheduling method provided in this disclosure may further include:

[0159] S106, schedule local resources according to the resource scheduling method described above.

[0160] If there are resources that need to be scheduled locally in UMF, then UMF can schedule the local resources according to the resource scheduling method.

[0161] In some embodiments, the resource scheduling method provided in this disclosure may further include:

[0162] S107, the merging strategy is sent to the external network element so that the external network element can schedule resources according to the resource scheduling method.

[0163] If the UMF does not have the resources to be scheduled locally, the UMF can send a merging policy to external network elements, such as service entities, so that the external network elements can schedule resources according to the resource scheduling method known in the merging policy.

[0164] This disclosure supports a closed-loop control mechanism for unified scheduling and status feedback of internal and external resources, collaboration between local and external resources (such as business AS control entities), and the ability to re-evaluate and trigger splitting operations at runtime, thereby achieving dynamic elasticity and reversibility of resource scheduling and improving system robustness.

[0165] The resource scheduling method provided in this disclosure can be applied in scenarios involving resource calls, including new call scenarios and Internet services involving large models (such as speech recognition, problem consultation, etc.).

[0166] Secondly, referring to Figure 4 This disclosure provides a communication device including one or more processors and a memory storing one or more computer programs, wherein when the one or more computer programs are executed by the one or more processors, the one or more processors implement any of the resource scheduling methods of this disclosure.

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

[0168] Thirdly, referring to Figure 5 This disclosure provides a computer-readable medium storing a computer program that, when executed by a processor, implements any of the resource scheduling methods of this disclosure.

[0169] Fourthly, embodiments of this disclosure provide a computer program product, which includes a computer program that, when executed by a processor, implements any of the resource scheduling methods of embodiments of this disclosure.

[0170] The resource scheduling method provided in this disclosure consists of two stages: a semantic alignment stage and a merging decision stage. In this disclosure, when multiple business entities operate independently and are unaware of each other's existence, resource reuse across business entities is achieved through these two stages. In the semantic alignment stage, this disclosure provides a unified modeling mechanism. Resource requests from different business entities are modeled uniformly, identifying the characteristics of resource requests and achieving semantic alignment across business entities. This mechanism addresses the issue of identifying resource reuse opportunities when business entities are unaware of each other and resource request formats differ. In the merging decision stage, this disclosure provides a dynamic merging decision mechanism. Based on the results of unified modeling, i.e., feature tuples, factors such as quality, latency, cost, and load are comprehensively considered to dynamically determine merging, delaying, rejecting, or splitting, and supports reversible operations at runtime, adapting well to dynamically changing environments. The two stages are described below with reference to Examples 1 and 2.

[0171] Example 1

[0172] Reference Figure 6 The resource scheduling method provided in this disclosure may include:

[0173] The S600 receives multiple resource requests.

[0174] Among them, the business types, formats, and sources of multiple resource requests can be the same or different.

[0175] S601: For each resource request, parse the resource request and extract the key information fields of the resource request.

[0176] The key information fields include one or more of the following: input-related information, output-related information, and metadata information. Input-related information includes one or more of the following: original business type, original input data format, original input data content, original service quality parameters, and original input data processing mode. Output-related information includes one or more of the following: original output data format, original output data output content identifier, and original output information processing mode. Metadata information includes one or more of the following: resource request identifier, business entity identifier, and request time information.

[0177] S602 standardizes the original business type to obtain a standard business type.

[0178] S603 standardizes the format information of the original input data to obtain the standard format type of the input data; standardizes the format information of the original output data to obtain the standard format type of the output data.

[0179] S604 standardizes the content information of the original input data to obtain a data fingerprint.

[0180] S605 standardizes the original service quality parameters to obtain the service quality level.

[0181] S606 constructs feature tuples for resource requests based on standard business types, standard format types of input data, standard format types of output data, data fingerprints, and service quality levels.

[0182] S607 outputs the feature tuples for each resource request.

[0183] In this embodiment of the disclosure, resource requests of different business types and formats are transformed into a unified structured representation to achieve semantic alignment across business entities.

[0184] Related technologies include solutions that use semantic similarity and content fingerprinting to identify similar content. For example, pre-trained models like BERT are used to calculate text similarity, and hash values ​​or feature vectors are used to identify duplicate data. However, these methods are only used to identify similarity and are not integrated with resource scheduling and merging decision mechanisms, making them unsuitable for cross-business entity resource scheduling. In contrast, this embodiment quantifies the similarity of resource requests from different businesses to the same media stream using feature tuples, achieving semantic alignment of requests across functional entities. This allows potential resource reuse opportunities to be identified without the business entities being aware of each other.

[0185] Example 2

[0186] Reference Figure 7 The resource scheduling method provided in this disclosure may include:

[0187] S700 retrieves feature tuples for multiple resource requests from the request pool.

[0188] In the merge decision phase, the similarity of resource requests in the request pool is first calculated, and then a merge decision is made for resource requests with high similarity. The input to the merge decision phase is a uniformly structured set of resource requests, i.e., feature tuples of resource requests. The request pool contains feature tuples of multiple resource requests. Resource requests in the request pool are labeled according to the merge decision results: new requests, merged requests, and requests with delayed decisions.

[0189] S701, determine whether the similarity between feature tuples is greater than a preset threshold. If yes, proceed to step S702; otherwise, end the process.

[0190] The system is based on unified structured modeling, extracts feature tuples from resource requests, and calculates their similarity. Similarity calculation includes comparing request type matching, input content similarity, and calculating QoS levels based on the feature tuples. Finally, it outputs request feature vectors and then compares the similarity of these feature vectors.

[0191] S702 determines the combined score based on system status parameters.

[0192] The system calculates various scoring indicators based on the request feature vector and system status parameters. The quality score M assesses the impact on audio and video quality after merging, ranging from 0 to 5. The latency change ΔT reflects the latency change after merging, ranging from -1 to 1, normalized to 200 milliseconds. The resource cost change ΔRC represents the resource cost change after merging, ranging from -2 to 2. The system load L reflects the current system load status, ranging from 0 to 1. The switching cost SC is calculated based on traffic and media type, ranging from -1 to 0. The system applies weights to calculate the comprehensive score. The formula is: quality weight multiplied by quality score, plus latency weight multiplied by latency change, plus resource cost weight multiplied by resource cost change, plus load weight multiplied by system load, plus switching cost weight multiplied by switching cost. The final output is the comprehensive score, i.e., the merged score.

[0193] S703: If the merged score is greater than or equal to the first threshold, the immediate merge process is triggered, i.e., S706 is executed.

[0194] The immediate merge process is used to immediately merge multiple resource requests into one resource request.

[0195] Taking a first threshold of 1.48 as an example, when the merge score is greater than or equal to 1.48, the immediate merge process is triggered. The system requests the resources required for merging, such as ASR model instances, allocates multiple resource requests to the same merge processing group, establishes a mapping relationship between resource request identifiers and merge groups, and records the merge status and start time. During resource scheduling, if the resource is within the UMF (Unified Management Function), the system directly allocates the internal resources; if the resource is external, such as if it is controlled by a business AS (Application Service), the system sends a merge request to the business AS. Finally, the merge result is output, and the system enters the dynamic monitoring loop.

[0196] S704: If the merged score is greater than or equal to the second threshold and less than the first threshold, the delayed merging process is triggered. That is, S707 is executed.

[0197] The delayed merging process is used to start a timer. Before the timer reaches the third threshold, multiple resource requests to be merged remain independent. When the timer reaches the third threshold, the system status parameters are retrieved again and the merging score is re-determined.

[0198] Taking a first threshold of 1.48 and a second threshold of 1.2 as an example, when the merged score is greater than or equal to 1.2 and less than 1.48, the resource request to be merged is added to the delay decision queue. The feature tuples of the resource request and the current merged score are recorded. A delay timer is set, for example, thirty seconds (i.e., the third threshold), and the reason for the delay is recorded, such as high system load waiting for the load to decrease. Finally, the delay decision status is output, and the delay decision monitoring loop begins.

[0199] S705: If the merged score is less than the second threshold, the merge rejection process is triggered. That is, S708 is executed.

[0200] The refuse-to-merge process is used to keep multiple resource requests to be merged independent.

[0201] Taking a second threshold of 1.2 as an example, when the merge score is less than 1.2, if it is a merged resource request, it will be split (that is, the merged resource request will be restored into multiple independent resource requests to be merged). Otherwise, the system will maintain the original independent processing flow and will not perform the merge operation (that is, keep the resource requests to be merged independent), and record the reason for rejection, such as insufficient merge benefits, and finally output the merge rejection status.

[0202] S706 merges multiple resource requests into a single resource request.

[0203] S707 adds multiple resource requests to the pending delay decision queue.

[0204] S708, split merged resource requests or keep pending resource requests independent.

[0205] S709, monitor changes in system status parameters to determine if the conditions for re-decision are met. If yes, proceed to step S701; otherwise, end the process.

[0206] The system continuously monitors changes in system status parameters. If the change exceeds a fourth threshold, a new decision is made. Monitored system status parameters may include real-time monitoring of the merged audio and video quality (M), monitoring the difference between actual and expected processing latency (ΔT), monitoring actual resource consumption (ΔRC), and monitoring system load changes (L), etc. The monitoring cycle is set according to business needs, for example, monitoring every five seconds.

[0207] In this embodiment, the merging decision is not a one-time static decision, but rather supports a dynamic and reversible decision-making mechanism. Specifically, it includes: initial decision, i.e., immediately merging, delaying merging, or rejecting merging for similar resource requests; dynamic monitoring, i.e., continuously monitoring changes in parameters such as quality after merging execution; reversible operation, i.e., dynamically splitting and resuming independent processing when changes in system state parameters are monitored; and re-decision: after splitting or after the delay decision times out, a new merging decision is made.

[0208] In some related technologies, resource reuse is achieved through configuration, such as pre-configuring service A and service B to share a certain ASR model resource. However, this static configuration method cannot cope with dynamic changes in service requests, such as QoS requirements changing with network conditions and real-time fluctuations in system load. Furthermore, this static configuration method requires prior knowledge of which services can be reused and cannot automatically discover potential reuse opportunities between different service entities. Additionally, once configured, this static configuration method is difficult to dynamically adjust based on actual conditions at runtime. The dynamic and reversible decision-making mechanism provided in this disclosure solves the problem of static configuration's inability to cope with dynamically changing environments. This disclosure embodiment achieves adaptive resource scheduling through dynamic monitoring and reversible operation.

[0209] In this disclosure, the merging strategies are divided into immediate merging, delayed merging, and rejection merging. Example 3 illustrates the scenario of immediate merging, and Example 4 illustrates the scenario of delayed merging. It should be noted that in a real network, there are different service entities such as service ASs and capability network elements; this disclosure uses service ASs as an example for illustration.

[0210] Example 3

[0211] This example illustrates a scenario where resource requests are highly similar and are merged immediately after a merge decision is made.

[0212] Reference Figure 8 The interaction process of the resource scheduling method provided in this embodiment may include:

[0213] S800, Terminal A makes a video call to Terminal B.

[0214] S801, Terminal A initiates a subtitle service to Service AS-A.

[0215] S802, Service AS-A initiates a media copy request 1.1 to UMF.

[0216] S803, Service AS-A sends a text conversion request to UMF 1.2.

[0217] Based on the user's subscription (or user-initiated subtitle service), Service AS-A initiates Media Copy Request 1.1 and Text Conversion Request 1.2 to prepare for the implementation of the subtitle service.

[0218] S804, UMF received media copy request 1.1, prepared to copy the audio media stream of terminal B, and replied successfully.

[0219] S805, UMF receives and converts to text request 1.2, performs speech recognition to extract text, and performs subtitle synthesis processing.

[0220] S806, Terminal A initiates an emotion recognition service to Service AS-B.

[0221] S807, Service AS-B initiates a media copy request to UMF 2.1.

[0222] S808, Business AS-B initiates an emotion recognition request to UMF 2.2.

[0223] S809, UMF received media copy request 2.1, prepared to copy the audio media stream of terminal B, and replied successfully.

[0224] S810, UMF receives the emotion recognition request 2.2, performs speech recognition to extract text and recognize emotions.

[0225] S811, UMF performs similarity calculations on media copy request 1.1, convert to text request 1.2, media copy request 2.1, and emotion recognition request 2.2 in the request pool; for convert to text request 1.2 and emotion recognition request 2.2 whose similarity is greater than a preset threshold, a merging decision is made. If the merging score is greater than the first threshold, the decision result is to merge immediately.

[0226] S812, UMF reuses entity A to achieve text and emotion recognition, freeing up entity B resources.

[0227] Example 4

[0228] This example illustrates a scenario where resource requests are highly similar and the merge is delayed after a merge decision has been made.

[0229] Reference Figure 9 The interaction process of the resource scheduling method provided in this embodiment may include:

[0230] S900, Terminal A makes a video call to Terminal B.

[0231] S901, Terminal A initiates a subtitle service to Service AS-A.

[0232] Based on the user's subscription (or user-initiated subtitle service), Service AS-A initiates Media Copy Request 1.1 and Text Conversion Request 1.2 to prepare for the implementation of the subtitle service.

[0233] S902, Service AS-A initiates a media copy request 1.1 to UMF.

[0234] S903, Service AS-A initiates a text conversion request to UMF 1.2.

[0235] S904, UMF received media copy request 1.1, prepared to copy the audio media stream of terminal B, and replied successfully.

[0236] S905, UMF receives and converts to text request 1.2, performs speech recognition to extract text, and performs subtitle synthesis processing.

[0237] S906, Terminal A initiates an emotion recognition service to Service AS-B.

[0238] S907, Service AS-B initiates a media copy request 2.1 to UMF.

[0239] S908, Business AS-B initiates an emotion recognition request to UMF 2.2.

[0240] S909, UMF received media copy request 2.1, prepared to copy the audio media stream of terminal B, and replied successfully.

[0241] S910, UMF receives the emotion recognition request 2.2, performs speech recognition to extract text and recognize emotions.

[0242] S911, UMF performs similarity calculations on media copy request 1.1, convert to text request 1.2, media copy request 2.1, and emotion recognition request 2.2 in the request pool; for convert to text request 1.2 and emotion recognition request 2.2 whose similarity is greater than a preset threshold, a merging decision is made. If the merging score is greater than the second threshold and less than the first threshold, the decision result is delayed merging.

[0243] S912, UMF sets a timer. After the timer expires, it makes another decision on whether to merge and convert it into text request 1.2 and emotion recognition request 2.2, and processes it according to the decision result.

[0244] The embodiments disclosed herein can make dynamic merging decisions. The following example, in conjunction with Example 5, illustrates a scenario where merged resource requests are split after a period of time.

[0245] Example 5

[0246] This example illustrates a scenario where resource requests have already been merged and reused, and a decision needs to be made to split them again.

[0247] Reference Figure 10 The interaction process of the resource scheduling method provided in this embodiment may include:

[0248] S1000, Terminal A makes a video call to Terminal B.

[0249] S1001, Terminal A initiates a subtitle service to Service AS-A.

[0250] Based on the user's subscription (or user-initiated subtitle service), Service AS-A initiates Media Copy Request 1.1 and Text Conversion Request 1.2 to prepare for the implementation of the subtitle service.

[0251] S1002, Service AS-A initiates a media copy request 1.1 to UMF.

[0252] S1003, Service AS-A sends a text conversion request to UMF 1.2.

[0253] S1004, UMF received media copy request 1.1, preparing to copy the audio media stream of terminal B, and replied successfully.

[0254] S1005, UMF receives and converts to text request 1.2, performs speech recognition to extract text, and performs subtitle synthesis processing.

[0255] S1006, Terminal A initiates an emotion recognition service to Service AS-B.

[0256] S1007, Service AS-B initiates a media copy request 2.1 to UMF.

[0257] S1008, Business AS-B sends an emotion recognition request to UMF 2.2.

[0258] S1009, UMF received media copy request 2.1, preparing to copy the audio media stream of terminal B, and replied successfully.

[0259] S1010, UMF receives the emotion recognition request 2.2, performs speech recognition to extract text and recognize emotions.

[0260] S1011, UMF performs similarity calculations on media copy request 1.1, convert to text request 1.2, media copy request 2.1, and emotion recognition request 2.2 in the request pool; for convert to text request 1.2 and emotion recognition request 2.2 whose similarity is greater than a preset threshold, a merging decision is made. If the merging score is greater than the first threshold, the decision result is to merge immediately.

[0261] S1012, UMF reuses entity A to achieve text and emotion recognition, freeing up the resources of entity B.

[0262] S1013, UMF monitors the system status parameters. When the change in the system status parameters exceeds the fourth threshold, a merging decision is made again, and the decision result is splitting.

[0263] S1014, UMF begins splitting the process, requests resources for entity B, resumes the processing of entity B, and no longer reuses entity A.

[0264] This disclosure allows for the scheduling of resources from external sources. Examples 6 and 7 below illustrate scenarios where external support and non-external support are provided for resource scheduling during the merging of highly similar external decisions.

[0265] Example 6

[0266] This example illustrates a scenario where resource requests are highly similar, are merged and reused after a decision is made, and the resources are scheduled externally.

[0267] Reference Figure 11 The interaction process of the resource scheduling method provided in this embodiment may include:

[0268] S1100, Terminal A makes a video call to Terminal B.

[0269] S1101, Terminal A initiates a subtitle service to Service AS-A.

[0270] Based on the user's subscription (or user-initiated subtitle service), Service AS-A initiates Media Copy Request 1.1 and Text Conversion Request 1.2 to prepare for the implementation of the subtitle service.

[0271] S1102, Service AS-A initiates a media copy request 1.1 to UMF.

[0272] S1103, Service AS-A sends a text conversion request to UMF 1.2.

[0273] S1104, UMF received media copy request 1.1, preparing to copy the audio media stream of terminal B, and replied successfully.

[0274] S1105, UMF receives and converts to text request 1.2, performs speech recognition to extract text, and performs subtitle synthesis processing.

[0275] S1106, Terminal A initiates an emotion recognition service to Service AS-B.

[0276] S1107, Service AS-B initiates a media copy request 2.1 to UMF.

[0277] S1108, Business AS-B sends an emotion recognition request to UMF 2.2.

[0278] S1109, UMF received media copy request 2.1, prepared to copy the audio media stream of terminal B, and replied successfully.

[0279] S1110, UMF receives the emotion recognition request 2.2, performs speech recognition to extract text and recognize emotions.

[0280] S1111, UMF performs similarity calculations on media copy request 1.1, convert to text request 1.2, media copy request 2.1, and emotion recognition request 2.2 in the request pool; for convert to text request 1.2 and emotion recognition request 2.2 whose similarity is greater than a preset threshold, a merging decision is made. If the merging score is greater than the first threshold, the decision result is to merge immediately.

[0281] S1112, UMF starts the reuse process. In response to the resource being external, it initiates a merge request to business AS-A.

[0282] S1113, Service AS-A returned success, Service AS-A controls the reuse entity A.

[0283] S1114, UMF notifies the AS-B business to release entity B resources.

[0284] S1115, Business AS-B releases entity B resources.

[0285] Example 7

[0286] This example illustrates a scenario where resource requests are highly similar, are merged and reused after a decision is made, and the scheduled resources are external and not supported by external resources.

[0287] Reference Figure 12 The interaction process of the resource scheduling method provided in this embodiment may include:

[0288] S1200, Terminal A makes a video call to Terminal B.

[0289] S1201, Terminal A initiates a subtitle service to Service AS-A.

[0290] Based on the user's subscription (or user-initiated subtitle service), Service AS-A initiates Media Copy Request 1.1 and Text Conversion Request 1.2 to prepare for the implementation of the subtitle service.

[0291] S1202, Service AS-A initiates a media copy request 1.1 to UMF.

[0292] S1203, Service AS-A sends a text conversion request to UMF 1.2.

[0293] S1204, UMF received media copy request 1.1, preparing to copy the audio media stream of terminal B, and replied successfully.

[0294] S1205, UMF receives and converts to text request 1.2, performs speech recognition to extract text, and performs subtitle synthesis processing.

[0295] S1206, Terminal A initiates an emotion recognition service to Service AS-B.

[0296] S1207, Service AS-B initiates a media copy request 2.1 to UMF.

[0297] S1208, Business AS-B sends an emotion recognition request to UMF 2.2.

[0298] S1209, UMF received media copy request 2.1, preparing to copy the audio media stream of terminal B, and replied successfully.

[0299] S1210, UMF receives the emotion recognition request 2.2, performs speech recognition to extract text and recognize emotions.

[0300] S1211, UMF performs similarity calculations on media copy request 1.1, convert to text request 1.2, media copy request 2.1 and emotion recognition request 2.2 in the request pool; for convert to text request 1.2 and emotion recognition request 2.2 whose similarity is greater than a preset threshold, a merging decision is made. If the merging score is greater than the first threshold, the decision result is to merge immediately.

[0301] S1212, UMF starts the reuse process. In response to the resource being external, it initiates a merge request to business AS-A.

[0302] S1213, Service AS-A return is not supported.

[0303] S1214, UMF requests local resources, uses local resources, and merges and processes them into text request 1.2 and emotion recognition request 2.2.

[0304] S1215, UMF notifies business AS-A to release entity A resources.

[0305] S1216, UMF notifies the AS-B business to release entity B resources.

[0306] S1217, Business AS-A releases resources of entity A.

[0307] S1218, Business AS-B releases entity B resources.

[0308] In this embodiment of the disclosure, the merged resource scheduling requests can originate from the same session or from different sessions. Examples 3 to 7 above illustrate the scenario of the same session. The merging strategy for different session scenarios will be described below with reference to Example 8.

[0309] Example 8

[0310] Reference Figure 13 The interaction process of the resource scheduling method provided in this embodiment may include:

[0311] S1300, Terminal A makes a video call to Terminal B to form Session 1.

[0312] S1301, Terminal A initiates a subtitle + translation service to Service AS-1.

[0313] Based on the user's subscription (or user-initiated trigger) to subtitle + translation service, business AS-1 initiates media copy request 1.1 and ASR to text conversion request 1.2 to prepare for the implementation of subtitle + translation service.

[0314] S1302, Service AS-1 initiates a media copy request 1.1 to UMF.

[0315] S1303, Service AS-1 sends an ASR to UMF to convert to text request 1.2.

[0316] S1304, UMF received media copy request 1.1, preparing to copy the audio media stream of terminal B, and replied successfully.

[0317] S1305, UMF receives and converts to text request 1.2, performs speech recognition to extract text.

[0318] S1306, the UMF cache manager caches the ASR results of session 1, including model identifier, audio fingerprint, and ASR text results.

[0319] S1307, Terminal C video calls Terminal D to form Session 2.

[0320] S1308, Terminal C initiates a subtitle + translation service to Service AS-2.

[0321] Based on the user's subscription (or user-initiated subtitle + translation), business AS-2 initiates a media copy request 2.1 and an ASR to text conversion request 2.2 to prepare for the implementation of the subtitle + translation business.

[0322] S1309, Service AS-2 initiates a media copy request 2.1 to UMF.

[0323] S1310, Service AS-2 sends an ASR to UMF to convert to text request 2.2.

[0324] S1311, UMF receives media copy request 2.1, prepares to copy the audio media stream of user D, and replies successfully.

[0325] S1313, UMF receives ASR to text request 2.2, performs speech recognition to extract text.

[0326] S1314, UMF performs cross-session similarity calculation for requests from Session 1 and Session 2: it detects that ASR-to-text request 1.2 and ASR-to-text request 2.2 use the same ASR model, audio feature matching, and determines that they are reusable.

[0327] S1315, UMF decision is to reuse the ASR cached result of session 1, and session 2 directly uses the cached ASR text result, skipping duplicate recognition.

[0328] S1312, UMF performs TTS translation output processing on two sessions separately. The two sessions share the ASR result but perform translation output independently.

[0329] Different business entities have varying request formats and naming conventions, making semantic alignment difficult. This embodiment of the disclosure uses a feature tuple modeling approach to define multi-dimensional features such as input data type, output data type, input data content, processing mode, and QoS, achieving cross-entity semantic pairing.

[0330] Resource scheduling decisions are typically unidirectional and static, and once made, they are difficult to reverse. This disclosure addresses this issue by supporting reversible operations such as merging, delaying, rejecting, and splitting, and by dynamically monitoring and re-evaluating these operations at runtime, thus achieving dynamically reversible decision-making.

[0331] To address the situation where potential resource reuse opportunities cannot be identified when business entities are unaware of each other, this disclosure, through a unified modeling mechanism and similarity calculation, enables the automatic identification of potential reuse opportunities even when business entities are unaware of each other.

[0332] Furthermore, the embodiments disclosed herein improve resource efficiency and reduce costs. Speech recognition services serve as the foundation for many other services, and the embodiments disclosed herein achieve this reuse, resulting in significant savings in model resources. By reusing the model once per user subscription, at least 50% of resource calls are reduced; the more services used, the greater the benefit.

[0333] The embodiments disclosed herein significantly reduce system load and improve system performance while ensuring service quality. The reduced number of media stream replications significantly reduces network bandwidth usage and media forwarding overhead; the reduced number of model calls significantly reduces GPU / CPU computing resources and memory usage; and, by avoiding repetitive preprocessing and post-processing operations, the overall system processing capacity is improved.

[0334] The embodiments disclosed herein enhance system robustness. The dynamic and reversible merging and splitting mechanism enables the system to adaptively adjust according to changes in operating status, avoiding system rigidity caused by static configuration. In dynamic scenarios such as system load fluctuations and changes in QoS requirements, the system can automatically adjust resource reuse strategies, ensuring high availability and robustness.

[0335] The embodiments disclosed herein achieve adaptive cross-business collaboration, enabling automatic identification and adaptive decision-making capabilities even when business entities are unaware of each other, resource request formats vary, and the operating environment changes dynamically.

[0336] Those skilled in the art will understand that all or some of the steps, systems, and devices disclosed above, as functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0337] In hardware implementations, the division between functional modules / units mentioned in the above description 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 executed by several physical components working together.

[0338] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), 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 and communication media. In embodiments of this disclosure, computer storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, and any other media that can be used to store desired information and can be accessed by a computer. In embodiments of this disclosure, 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.

Claims

1. A resource scheduling method, comprising: Get multiple resource requests; Extract feature tuples for each resource request, wherein each feature tuple includes at least one feature term, and each feature term represents the standardized result of a feature of the resource request; Based on the feature tuples, a merging strategy for the multiple resource requests is determined, and the merging strategy is used to indicate the resource scheduling method for the multiple resource requests.

2. The method according to claim 1, wherein, The at least one feature includes one or more of request features, response features, and metadata features, and the extraction of feature tuples for each resource request includes: Extract input-related information from the resource request, and determine one or more request features based on the standardization results of the input-related information; And / or, Extract output-related information from the resource request, and determine one or more response features based on the standardization results of the output-related information; And / or, Metadata information is extracted from the resource request, and one or more metadata features are determined based on the standardization results of the metadata information.

3. The method according to claim 2, wherein, The input-related information includes one or more of the following: original service type, format information of original input data, content information of original input data, original service quality parameters, and processing mode of original input data.

4. The method according to claim 3, wherein, The method further includes: Obtain a business type mapping table, which includes multiple standard business types and non-standard business types corresponding to each standard business type; In the business type mapping table, find the standard business type corresponding to the original business type; In response to finding a standard business type corresponding to the original business type, the found standard business type is determined as the standardization result of the original business type; In response to the absence of a standard business type corresponding to the original business type, the standard business type with the highest semantic similarity to the original business type in the business type mapping table is determined as the standardization result of the original business type.

5. The method according to claim 3, wherein, The method further includes: The format information of the original input data is converted into a first format type according to one or more of the data type dimension, data format dimension, and encoding format dimension; The standard format type corresponding to the first format type is found in the type compatibility rule table, and the standard format type is determined as the standardization result of the format information of the original input data. The type compatibility rule table includes multiple standard format types and format types compatible with each standard format type.

6. The method according to claim 3, wherein, The method further includes: A hash operation is performed on the content information of the original input data to obtain a data fingerprint, wherein the content information includes the actual data content and / or data description information of the original input data; The data fingerprint is determined as the standardized result of the content information.

7. The method according to claim 3, wherein, The method further includes: The service quality level is searched in the service quality level mapping table to find the service quality level that matches the original service quality parameters, and the service quality level is determined as the standardized result of the original service quality parameters. The service quality level mapping table includes multiple service quality levels and the parameter range corresponding to each service quality level.

8. The method according to claim 2, wherein, The output-related information includes one or more of the following: the format information of the original output data, the output content identifier of the original output data, and the processing mode of the original output information.

9. The method according to claim 8, wherein, The method further includes: The format information of the original output data is converted into a second format type according to one or more of the data type dimension, data format dimension, and encoding format dimension; The standard format type corresponding to the second format type is found in the type compatibility rule table, and the standard format type is determined as the standardization result of the format information of the original output data. The type compatibility rule table includes multiple standard format types and format types compatible with each standard format type.

10. The method according to claim 2, wherein, The metadata information includes one or more of the following: resource request identification information, business entity identification information, and request time information.

11. The method according to claim 1, wherein, The step of determining the merging strategy for the multiple resource requests based on the feature tuples includes: Based on the feature tuples, multiple resource requests to be merged are determined from the multiple resource requests, wherein the similarity between the feature tuples of any two resource requests to be merged is greater than a preset threshold. Obtain system status parameters, which are used to characterize the impact of merging the multiple resource requests to be merged into one resource request; The merging strategy is determined based on the system status parameters.

12. The method according to claim 11, wherein, The system status parameters include one or more of the following: quality score, latency change, resource cost change, and system load. The quality score, latency change, and resource cost change respectively represent the changes in quality, latency, and resource cost after multiple resource requests to be merged into one resource request. The system load is used to reflect the current system load status. Determining the merging strategy based on the system state parameters includes: A weighted sum is obtained by summing one or more of the quality score, the latency change, the resource cost change, and the system load; The merging strategy is determined based on the merging score.

13. The method according to claim 12, wherein, The merging strategy is used to instruct the multiple resource requests to be merged into one resource request or to keep the multiple resource requests independent. Determining the merging strategy based on the merging score includes: In response to the merge score being greater than or equal to a first threshold, the multiple resource requests to be merged are merged into one resource request. And / or, In response to the merge score being less than the first threshold, the multiple resource requests to be merged are kept independent.

14. The method according to claim 13, wherein, The step of keeping the multiple resource requests to be merged independent in response to the merge score being less than the first threshold includes: In response to the merge score being greater than or equal to the second threshold and less than the first threshold, a timer is started; in response to the timer not reaching the third threshold, the multiple resource requests to be merged remain independent; in response to the timer reaching the third threshold, the system status parameters are reacquired. And / or, In response to the merged score being less than the second threshold, the multiple target resource requests remain independent until the change in the system state parameter is greater than the fourth threshold.

15. The method according to claim 14, wherein, The method further includes: If the change in the system state parameter is greater than the fourth threshold, the merged score is re-determined based on the re-acquired system state parameter. In response to a recalculated merge score being less than the second threshold, the merged resource request is split into multiple independent resource requests.

16. A communication device comprising a memory and a processor; the memory storing a computer program executable by the processor, wherein the computer program, when executed by the processor, implements the resource scheduling method according to any one of claims 1 to 15.

17. A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the resource scheduling method according to any one of claims 1 to 15.

18. A computer program product comprising a computer program that, when executed by a processor, implements the resource scheduling method according to any one of claims 1 to 15.

Images