Communication method, apparatus and system

Abstract

The embodiments of the present application relate to the technical field of communications. Disclosed are a communication method, apparatus and system, which can support the generation of a QoS policy for a new service in a communication network. The method comprises: a policy control function network element acquiring task information and requirement information of a first service, wherein the task information comprises information related to a task obtained by means of decomposing and mapping the first service; the policy control function network element generating a QoS parameter of the first service on the basis of the requirement information of the first service; and the policy control function network element generating a QoS parameter of the task on the basis of the task information and the QoS parameter of the first service.

Description

Communication methods, devices and systems

[0001] This application claims priority to Chinese Patent Application No. 202311515280.5, filed on November 13, 2023, entitled "Communication Method, Apparatus and System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to communication methods, apparatus and systems. Background Technology

[0003] With the development of communication technology, new services are being considered for introduction into wireless communication networks, such as those involving artificial intelligence (AI) and sensing. To support these new services, the network needs to efficiently coordinate heterogeneous resources across multiple dimensions, including connectivity, computing, data, and models (or algorithms). However, the Quality of Service (QoS) mechanism in 5G wireless communication networks, which manages Protocol Data Unit (PDU) sessions to ensure the quality of communication connections, is no longer suitable for wireless communication networks introducing new services.

[0004] Therefore, ensuring the quality of service for new services introduced into wireless communication networks is an urgent problem to be solved.

[0005] Summary of the Invention

[0006] This application provides a communication method, apparatus, and system that can support the generation of QoS policies for new services in wireless communication networks, thereby ensuring the quality of service for various services.

[0007] The embodiments of this application adopt the following technical solutions:

[0008] Firstly, a communication method is provided. This method can be executed by a policy control function network element, by a component of the policy control function network element (e.g., a processor, chip, or chip system), or by a logic module or software capable of implementing all or part of the policy control function network element's functions. The following description uses the policy control function network element as the executing entity of this method. The method includes: the policy control function network element acquiring task information and requirement information of a first service; the task information includes relevant information of the task obtained from the decomposition and mapping of the first service. The policy control function network element generates QoS parameters for the first service based on the requirement information of the first service. Further, the policy control function network element generates QoS parameters for the task based on the task information and the QoS parameters of the first service.

[0009] Based on the communication method provided in the embodiments of this application, the policy control function network element can generate service-level QoS parameters, and further generate task-level QoS parameters. This is suitable for communication networks managed at the task level to ensure the quality of service of the first service. Therefore, the communication method provided in the embodiments of this application supports the generation of QoS policies for new services in the communication network.

[0010] In one possible design, the policy control function network element obtains the requirement information of the first service, including: the policy control function network element obtains the relevant information of the first service, the relevant information of the first service includes one or more of the following: the requirement information of the first service or the identification information of the first service, and there is a mapping relationship between the identification information of the first service and the requirement information of the first service.

[0011] Based on this scheme, the policy control function network element can obtain the requirement information of the first service through the identification information of the first service, thereby saving signaling overhead.

[0012] In one possible design, the identification information of the first service includes at least one of the following: information about the user who triggered the first service, information about the terminal device involved in the first service, or information about the application service provider.

[0013] This solution provides various identification information for primary services, which can be applied to different scenarios.

[0014] In one possible design, the policy control function network element generates QoS parameters for the first service based on the requirement information of the first service, including: the policy control function network element generates a QoS template corresponding to the first service based on the relevant information of the first service, and the QoS template includes a mapping relationship between the QoS parameters of the first service and the identification information of the first service.

[0015] Based on this scheme, the policy control function network element can establish a mapping relationship between the QoS parameters of the first service and the identification information of the first service. If other network elements obtain the identification information of the first service, they can obtain the QoS parameters of the first service based on the mapping relationship.

[0016] In one possible design, the QoS parameters for the first service include multiple sets of QoS parameters, each with a different priority.

[0017] Based on this scheme, it is possible to flexibly select a set of QoS parameters for actual application according to the priority of each set of QoS parameters.

[0018] In one possible design, the method further includes: the policy control function network element sending the QoS parameters of the first service to the unified data pool network element.

[0019] Based on this scheme, the policy control function network element can store the QoS parameters of the first service in the unified data pool network element, which is convenient for the policy control function network element or other network elements to read.

[0020] In one possible design, the task information includes at least one of the task deployment information or topology information.

[0021] Based on this scheme, the policy control function network element can obtain the deployment information and / or topology information of the task, which can help the policy control function network element generate appropriate QoS parameters for the task.

[0022] In one possible design, the policy control function network element generates QoS parameters for the task based on task information and the QoS parameters of the first service. This includes: the policy control function network element generating policies and charging control rules based on the task information and the QoS parameters of the first service. The policies and charging rules include the QoS parameters of the task and a mapping relationship between the QoS parameters of the task and at least one of the execution network element executing the task or the task data stream.

[0023] Based on this scheme, the policy control function network element can bind the QoS parameters of the task to at least one of the execution network element or the task data stream while generating the QoS parameters of the task, which facilitates QoS management.

[0024] In one possible design, the policy and charging rules include at least one of the following: QoS-specific requirement information related to the connection, an identifier indicating the QoS-specific requirement related to the connection, information of the network element executing the starting point of the service data flow of the task, and information of the network element executing the ending point of the service data flow of the task.

[0025] Based on this solution, the policy and billing rules may include connection-related content, thereby enabling QoS management of the connection dimension of a task according to the policy and billing rules.

[0026] In one possible design, the strategy and billing rules also include the type of business data flow for the task, which includes computation, data, or algorithm types.

[0027] Based on this solution, the business data flow of a task can be divided into different types to accommodate the multiple dimensions involved in the task, making it easier to perform QoS management on the business data flow of the task according to the type.

[0028] In one possible design, the policy and charging rules include at least one of the following: QoS-specific requirement information related to computation, an identifier indicating the QoS-specific requirement related to computation, information of the network element used to perform the computation function, an identifier of the computation subtask, and the computation type of the computation subtask.

[0029] Based on this solution, the computation-related content that policies and billing rules may include is provided, so that QoS management of the computation dimension of a task can be performed according to the policies and billing rules.

[0030] In one possible design, the policy and billing rules include at least one of the following: QoS-specific requirement information related to the data, an identifier indicating the QoS-specific requirement related to the data, the data type, and the data size.

[0031] Based on this solution, we provide data-related content that policies and billing rules may include, so that QoS management of the data dimension of a task can be performed according to policies and billing rules.

[0032] In one possible design, the policy and billing rules include at least one of the following: QoS-specific requirement information related to the algorithm, an identifier indicating the QoS-specific requirement related to the algorithm, the algorithm type, the algorithm level, and the application method.

[0033] Based on this solution, the algorithm-related content that the policies and billing rules may include is provided, so that QoS management of the algorithm dimension of the task can be performed according to the policies and billing rules.

[0034] In one possible design, the method further includes: a policy control function network element sending QoS parameters of a task to an anchor network element, the QoS parameters of the task being used by the anchor network element to generate resource-level QoS parameters. The resource-level QoS parameters include at least one of the following: connection dimension, computation dimension, data dimension, and algorithm dimension.

[0035] Based on this scheme, the anchor network element can obtain the QoS parameters of the task and further generate resource-level QoS parameters. Thus, the anchor network element can directly perform QoS management on the four-dimensional resources according to the resource-level QoS parameters.

[0036] Secondly, a communication method is provided. This method can be executed by an anchor network element, a component of the anchor network element (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the anchor network element's functions. The following explanation uses the anchor network element as the executing entity. The method includes: the anchor network element acquiring the QoS parameters of a task, and generating resource-level QoS parameters based on the task's QoS parameters and the executing network element. The resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computation dimension, data dimension, and algorithm dimension. The anchor network element sends the resource-level QoS parameters to the executing network element.

[0037] Based on the communication method provided in this application embodiment, anchor network elements can generate resource-level QoS parameters including four dimensions, thereby enabling direct QoS management of these four dimensions. This is suitable for new services in communication networks that require coordinated four-dimensional resources. Therefore, the communication method provided in this application embodiment supports the generation of QoS policies for new services in communication networks.

[0038] In one possible design, the task is obtained by decomposing and mapping the first service, and the QoS parameters of the task are obtained based on the QoS parameters of the first service.

[0039] Based on this solution, a decomposition and mapping from services to tasks, and then from tasks to resources, can be achieved.

[0040] In one possible design, the method further includes: the anchor network element acquiring the orchestration result of the task, the orchestration result including the task's template description information and dependencies. Based on the orchestration result, the anchor network element obtains task information, the task information including at least one of the task's deployment information or topology information.

[0041] In one possible design, the method further includes: the anchor network element sending task information to the policy control function network element, the task information being used by the policy control function network element to generate QoS parameters for the task.

[0042] Based on this scheme, the anchor network element can send the obtained task information to the policy control function network element, so that the policy control function network element can generate the QoS parameters of the task.

[0043] In one possible design, the anchor network element acquires the Quality of Service (QoS) parameters of the task, including: anchor network element acquisition policies and charging control rules, the policies and charging rules including the QoS parameters of the task, and the mapping relationship between the QoS parameters of the task and at least one of the execution network element or the task data stream.

[0044] Based on this scheme, the anchor network element can obtain the mapping relationship between the QoS parameters of the task and at least one of the execution network element or the task data stream, which makes it easier for the anchor network element to generate resource-level QoS parameters according to the mapping relationship.

[0045] In one possible design, the policy and charging rules include at least one of the following: QoS-specific requirement information related to the connection, an identifier indicating the QoS-specific requirement related to the connection, information of the network element executing the starting point of the service data flow of the task, and information of the network element executing the ending point of the service data flow of the task.

[0046] Based on this scheme, the policy and charging rules may include connection-related content, so that anchor network elements can generate QoS parameters at the connection level according to the policy and charging rules.

[0047] In one possible design, the strategy and billing rules also include the type of business data flow for the task, which includes computation, data, or algorithm types.

[0048] Based on this solution, the business data flow of a task can be divided into different types to accommodate the multiple dimensions involved in the task, making it easier to perform QoS management on the business data flow of the task according to the type.

[0049] In one possible design, the QoS parameters of the connection dimension include at least one of the following: QoS-specific requirement information related to the connection, an identifier indicating the QoS-specific requirement related to the connection, and a packet identification rule; wherein the packet identification rule is used to distinguish service data streams corresponding to different QoS requirements.

[0050] Based on this solution, the possible contents of QoS parameters at the connection level are provided, and QoS management at the connection level can be performed based on these QoS parameters.

[0051] In one possible design, the policy and charging rules include at least one of the following: QoS-specific requirement information related to computation, an identifier indicating the QoS-specific requirement related to computation, information of the network element used to perform the computation function, an identifier of the computation subtask, and the computation type of the computation subtask.

[0052] Based on this scheme, the policy and charging rules provide the computation-related content that may be included, so that the anchor network element can generate QoS parameters of the computation dimension according to the policy and charging rules.

[0053] In one possible design, the QoS parameters of the computation dimension include at least one of the following: specific QoS requirement information related to computation, an identifier indicating the specific QoS requirement related to computation, and a computation subtask identification rule; wherein the computation subtask identification rule is used to distinguish computation subtasks corresponding to different QoS requirements.

[0054] Based on this solution, the possible contents of QoS parameters for the computation dimension are provided, and QoS management for the computation dimension can be performed based on these QoS parameters.

[0055] In one possible design, the policy and billing rules include at least one of the following: QoS-specific requirement information related to the data, an identifier indicating the QoS-specific requirement related to the data, the data type, and the data size.

[0056] Based on this solution, the policy and charging rules provide data-related content that may be included, so that anchor network elements can generate data-dimensional QoS parameters according to the policy and charging rules.

[0057] In one possible design, the QoS parameters of the data dimension include at least one of the following: QoS-specific requirement information related to the data, an identifier indicating the QoS-specific requirement related to the data, and a data subtask identification rule; wherein the data subtask identification rule is used to distinguish data subtasks corresponding to different QoS requirements.

[0058] Based on this solution, the possible contents of QoS parameters at the data dimension are provided, and QoS management at the data dimension can be performed based on these QoS parameters.

[0059] In one possible design, the policy and billing rules include at least one of the following: QoS-specific requirement information related to the algorithm, an identifier indicating the QoS-specific requirement related to the algorithm, the algorithm type, the algorithm level, and the application method.

[0060] Based on this scheme, the algorithm-related content that the policies and charging rules may include is provided, so that anchor network elements can generate QoS parameters at the algorithm level according to the policies and charging rules.

[0061] In one possible design, the QoS parameters at the algorithm dimension include at least one of the following: QoS-specific requirement information related to the algorithm, an identifier indicating the QoS-specific requirement related to the algorithm, and algorithm subtask identification rules; wherein the algorithm subtask identification rules are used to distinguish algorithm subtasks corresponding to different QoS requirements.

[0062] Based on this solution, the possible contents of QoS parameters at the algorithm level are provided, and QoS management at the algorithm level can be performed based on these QoS parameters.

[0063] In one possible design, the method further includes: the anchor network element receiving notification information from the execution network element, the notification information being used to notify the execution network element that it cannot meet QoS requirements related to connectivity, computation, data, or algorithms.

[0064] Based on this scheme, anchor network elements can determine which execution network element cannot meet the corresponding QoS requirements based on the notification from the execution network element, and thus can adjust the strategy accordingly to ensure that the QoS requirements can be met.

[0065] Thirdly, a communication method is provided. This method can be executed by an execution network element, by a component of the execution network element (e.g., a processor, chip, or chip system), or by a logic module or software capable of implementing all or part of the execution network element's functions. The following explanation uses the execution network element as the execution subject. The method includes: the execution network element acquiring resource-level QoS parameters; the resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computation dimension, data dimension, and algorithm dimension. The execution network element executes the task according to the resource-level QoS parameters.

[0066] Based on the communication method provided in the embodiments of this application, the execution network element can perform targeted processing on four-dimensional resources when executing tasks according to the obtained resource-level QoS parameters, thereby providing four-dimensional QoS management for new services in the communication network.

[0067] In one possible design, the resource-level QoS parameters are obtained based on the task's QoS parameters, where the task is obtained by decomposing and mapping the first service, and the task's QoS parameters are obtained based on the first service's QoS parameters.

[0068] Based on this solution, a decomposition and mapping from services to tasks, and then from tasks to resources, can be achieved.

[0069] In one possible design, the QoS parameters of the connection dimension include at least one of the following: QoS-specific requirement information related to the connection, an identifier indicating the QoS-specific requirement related to the connection, and a packet identification rule; wherein the packet identification rule is used to distinguish service data streams corresponding to different QoS requirements.

[0070] Based on this solution, the possible contents of QoS parameters at the connection level are provided, and QoS management at the connection level can be performed based on these QoS parameters.

[0071] In one possible design, the QoS parameters of the computation dimension include at least one of the following: specific QoS requirement information related to computation, an identifier indicating the specific QoS requirement related to computation, and a computation subtask identification rule; wherein the computation subtask identification rule is used to distinguish computation subtasks corresponding to different QoS requirements.

[0072] Based on this solution, the possible contents of QoS parameters for the computation dimension are provided, and QoS management for the computation dimension can be performed based on these QoS parameters.

[0073] In one possible design, the QoS parameters of the data dimension include at least one of the following: QoS-specific requirement information related to the data, an identifier indicating the QoS-specific requirement related to the data, and a data subtask identification rule; wherein the data subtask identification rule is used to distinguish data subtasks corresponding to different QoS requirements.

[0074] Based on this solution, the policy and charging rules provide data-related content that may be included, so that anchor network elements can generate data-dimensional QoS parameters according to the policy and charging rules.

[0075] In one possible design, the QoS parameters at the algorithm dimension include at least one of the following: QoS-specific requirement information related to the algorithm, an identifier indicating the QoS-specific requirement related to the algorithm, and algorithm subtask identification rules; wherein the algorithm subtask identification rules are used to distinguish algorithm subtasks corresponding to different QoS requirements.

[0076] Based on this solution, the possible contents of QoS parameters at the algorithm level are provided, and QoS management at the algorithm level can be performed based on these QoS parameters.

[0077] In one possible design, the method further includes: the executing network element sending a notification message to the anchor network element, the notification message being used to notify the executing network element that it cannot meet the QoS requirements related to connectivity, computing, data, or algorithms.

[0078] Based on this scheme, the executing network element can notify the anchor network element that it cannot meet the corresponding QoS requirements, so that the anchor network element can adjust its strategy accordingly.

[0079] Fourthly, a communication method is provided. This method can be executed by a task orchestration network element, by a component of the task orchestration network element (e.g., a processor, chip, or chip system), or by a logic module or software capable of implementing all or part of the functions of the task orchestration network element. The following description uses the task orchestration network element as the executing entity. The method includes: the task orchestration network element obtaining the QoS parameters of a first service; the task orchestration network element performing task orchestration based on the QoS parameters of the first service to obtain orchestration results at the task level; the orchestration results include template description information and dependencies of the tasks obtained from the decomposition and mapping of the first service.

[0080] Based on the communication method provided in the embodiments of this application, the task orchestration network element can orchestrate the tasks obtained from the first service decomposition mapping to obtain the orchestration result at the task granularity. This method is suitable for task orchestration of new services in the communication network, especially complex new services, so as to realize QoS hierarchical management from service to task.

[0081] In one possible design, the method further includes: the task orchestration network element sending orchestration results to the anchor network element, the orchestration results being used by the anchor network element to obtain task information, the task information including at least one of task deployment information or topology information.

[0082] Based on this scheme, the task orchestration network element can send task information to the anchor network element, which can then assist the anchor network element in performing QoS management at the task granularity.

[0083] In one possible design, the task orchestration network element obtains the QoS parameters of the first service, including: the task orchestration network element obtains the QoS template corresponding to the first service, and the QoS template includes the mapping relationship between the QoS parameters of the first service and the identification information of the first service.

[0084] Based on this scheme, the task orchestration network element can obtain the mapping relationship between the QoS parameters of the first service and the identification information of the first service. If the subsequent task orchestration network element obtains the identification information of the first service, it can determine the QoS parameters of the first service according to the mapping relationship.

[0085] In one possible design, the QoS parameters for the first service include multiple sets of QoS parameters, each with a different priority.

[0086] Based on this scheme, it is possible to flexibly select a set of QoS parameters for actual application according to the priority of each set of QoS parameters.

[0087] In one possible design, the task orchestration network element obtains the QoS parameters of a first service and performs task orchestration based on the QoS parameters of the first service. This includes: the task orchestration network element obtaining the QoS parameters of the first service with a first priority and performing task orchestration based on the QoS parameters of the first priority. If orchestration based on the QoS parameters of the first priority fails, the method further includes: the task orchestration network element obtaining the QoS parameters of the first service with a second priority and performing task orchestration based on the QoS parameters of the second priority.

[0088] Based on this scheme, the task orchestration network element can first perform task orchestration according to the first priority QoS parameters. If the orchestration fails, it can then try orchestration again according to the second priority QoS parameters, thus avoiding the situation where the orchestration fails on the first attempt and no orchestration result is obtained.

[0089] Fifthly, a communication device is provided for implementing the various methods described above. This communication device includes modules, units, or means corresponding to the methods described above, which can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0090] In some possible designs, the communication device may include a transceiver module and a processing module. The transceiver module, also referred to as a transceiver unit, is used to implement the transmission and / or reception functions of the first, second, third, or fourth aspects and any possible implementations thereof. The transceiver module may consist of transceiver circuitry, a transceiver, a transceiver unit, or a communication interface. The processing module can be used to implement the processing functions of the first, second, third, or fourth aspects and any possible implementations thereof.

[0091] In some possible designs, the transceiver module includes a sending module and a receiving module, which are used to implement the sending and receiving functions in the first, second, third, or fourth aspects and any possible implementation thereof.

[0092] A sixth aspect provides a communication device, comprising: a processor and a communication interface; the communication interface being used to communicate with a module outside the communication device; the processor being used to execute computer programs or instructions to cause the communication device to perform the methods of any of the above aspects.

[0093] A seventh aspect provides a communication device, comprising: at least one processor; the processor being configured to execute a computer program or instructions stored in a memory to cause the communication device to perform the methods of any of the preceding aspects. In one possible implementation, the memory may be coupled to the processor, or may be independent of the processor. In one possible implementation, the communication device further includes the memory. Optionally, the memory and the processor are integrated together.

[0094] In aspects five through seven, the communication device may be a policy control function network element in the first aspect or any implementation thereof, or a device containing the policy control function network element, or a device included in the policy control function network element, such as a chip. Alternatively, the communication device may be an anchor network element in the second aspect or any implementation thereof, or a device containing the anchor network element, or a device included in the anchor function network element, such as a chip. Alternatively, the communication device may be an execution network element in the third aspect or any implementation thereof, or a device containing the execution network element, or a device included in the execution network element, such as a chip. Alternatively, the communication device may be a task orchestration network element in the fourth aspect or any implementation thereof, or a device containing the task orchestration network element, or a device included in the task orchestration network element, such as a chip or chip system.

[0095] Eighthly, a computer-readable storage medium is provided that stores a computer program or instructions that, when executed on a communication device, enable the communication device to perform the methods of any of the above aspects or any implementation thereof.

[0096] Ninthly, a computer program product containing instructions is provided, which, when run on a communication device, enables the communication device to execute any of the above aspects or any implementation thereof.

[0097] In a tenth aspect, a communication device (e.g., the communication device may be a chip or a chip system) is provided, the communication device including a processor for implementing the functions involved in any of the above aspects or any implementation thereof.

[0098] In some possible designs, the communication device includes a memory for storing necessary program instructions and data.

[0099] In some possible designs, when the device is a chip system, it can be composed of chips, or it can contain chips and other discrete components.

[0100] It is understood that when the communication device provided by any of the fifth to seventh aspects is a chip, the aforementioned sending action / function can be understood as an output, and the aforementioned receiving action / function can be understood as an input.

[0101] The technical effects of any of the implementation methods in aspects five through ten can be found in the technical effects of the corresponding implementation methods in aspects one through four, and will not be repeated here.

[0102] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other.

[0103] Eleventhly, a communication system is provided, comprising a policy control function network element that performs the method of the first aspect, an anchor network element that performs the method of the second aspect, and an execution network element that performs the method of the third aspect.

[0104] In some possible designs, the communication system may also include task orchestration network elements that perform the methods described in the fourth aspect above. Attached Figure Description

[0105] Figure 1 is a schematic diagram of the architecture of a communication system provided in an embodiment of this application;

[0106] Figure 2 is a schematic diagram of the core network architecture of a communication system provided in an embodiment of this application;

[0107] Figure 3 is a schematic diagram of the protocol stack provided in an embodiment of this application;

[0108] Figure 4 is a schematic diagram of a communication method provided in an embodiment of this application;

[0109] Figure 5 is a schematic diagram of another communication method provided in an embodiment of this application;

[0110] Figure 6 is a schematic diagram of another communication method provided in an embodiment of this application;

[0111] Figure 7 is a schematic diagram of another communication method provided in an embodiment of this application;

[0112] Figure 8 is a possible flowchart provided in an embodiment of this application;

[0113] Figure 9 is a schematic diagram of another possible process provided in an embodiment of this application;

[0114] Figure 10 is a schematic diagram of another possible process provided in an embodiment of this application;

[0115] Figure 11 is a schematic diagram of another possible process provided in an embodiment of this application;

[0116] Figure 12 is a schematic diagram of another possible process provided in an embodiment of this application;

[0117] Figure 13 is a schematic diagram of an end-to-end connection architecture provided in an embodiment of this application;

[0118] Figure 14 is a schematic diagram of the composition of a communication device provided in an embodiment of this application;

[0119] Figure 15 is a schematic diagram of the hardware structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0120] To facilitate understanding of the technical solutions of the embodiments of this application, a brief introduction to the relevant technologies of the embodiments of this application is given below.

[0121] 1. New services in communication networks:

[0122] With the development of communication technology, new services are being considered for introduction into wireless communication networks (such as 6th generation (6G) and other networks evolving after 5G). These include services related to AI and sensing. The introduction of these new services may lead to the emergence of new services. For example, in AI-related services, AI itself is also offered as a service (in this article, "AI as a service" can be simply referred to as "AI service"), providing services such as model training, model inference, and model verification. In sensing services, devices with sensing capabilities can perceive the characteristics of targets by transmitting and receiving signals, providing sensing services such as high-precision positioning, high-resolution imaging, parameter measurement, gesture / action recognition, and vital sign monitoring. Furthermore, 6G networks may also provide computing services (such as computation offloading) and data services (such as data acquisition or data reprocessing).

[0123] To support these new businesses and services, the network needs to coordinate and schedule heterogeneous resources across four dimensions: connectivity, computation, data, and models (or algorithms). In this paper, "dimension" can also be referred to as "elements".

[0124] At the network level, the process of achieving a specific goal through multi-dimensional resource collaboration can be defined as a "task." In a task-centric architecture, task anchors (TAs) and task executors (TEs) are introduced. The TA is responsible for task lifecycle management, such as task deployment, startup, deletion, modification, and monitoring, and for allocating resources across the four dimensions for the task. The TE is responsible for the actual execution of the task and for data interaction related to business logic. Based on the TA and TE, the task processing flow can be as follows: after the task triggering source initiates the task, it sends the task request to the TA, which then deploys the task to one or more TEs for execution.

[0125] In one possible scenario, task scheduling (TS) can also be introduced. TS is mainly responsible for task control, establishing and maintaining task context information, sensing network state changes in real time, and realizing functions such as four-dimensional resource collaborative scheduling.

[0126] To achieve service decoupling, the core network (CN) and radio access network (RAN) can deploy TA and TE independently. For example, on the core network side, TA functions can be provided by task control function (TCF) network elements, and TE functions can be provided by task process function (TPF) network elements. On the access network side, TA functions can be provided by cluster nodes (cNodes), and TE functions can be provided by service nodes (sNodes).

[0127] In addition, in one possible scenario, the terminal device can also provide TE functionality.

[0128] In one possible scenario, an entity providing TE functionality can also provide TS functionality. For example, a TPF, sNode, or terminal device can provide both TE and TS functionality simultaneously.

[0129] Based on the four dimensions of data, computation, algorithm, and connectivity, a task can be broken down into dimension-level subtasks. Therefore, when deploying a task, a Task Analyst (TA) can assign dimension-level subtasks to Executors (TEs) for execution. It's understandable that, since the connectivity dimension of a task includes the connection paths between TEs executing different subtasks, and doesn't necessarily require a specific TE to execute them, there are no connectivity-level subtasks. Thus, a task can be broken down into data-level subtasks (hereinafter referred to as data subtasks), computation-level subtasks (hereinafter referred to as computation subtasks), and algorithm-level subtasks (hereinafter referred to as algorithm subtasks). Each type of subtask can have one or more subtasks.

[0130] In one possible scenario, the TE executes subtasks at the dimension level, which can also be referred to as the TE executing the corresponding function. For example, the TE executing a computational subtask can also be referred to as the TE executing a computational function.

[0131] In one possible implementation, for the four dimensions of connectivity, computation, data, and algorithms, the internal resources of a network element providing TA (Transmission Control) functionality can be managed by different modules responsible for resources in different dimensions. For example, the data controller (DC) module can manage the data dimension resources of the task, the computing controller (CC) module can manage the computation dimension resources of the task, the heteroarchical intelligent collaboration controller (HicC) module can manage the algorithm dimension resources of the task, and the connectivity controller (NC) module can manage the connectivity dimension resources of the task, including the establishment, addition, deletion, and modification of connection paths between TEs (Connectivity Entities).

[0132] Similarly, within a network element providing TE functionality, different modules can be responsible for different types of subtasks. For example, the data agent (DA) module can be responsible for executing data subtasks, the computing executor (CE) module can be responsible for executing computing subtasks, and the algorithm execution module (heterarchical intelligent collaboration agent (HicA) module can be responsible for executing algorithm subtasks.

[0133] In summary, after the introduction of new services into communication networks, some of these services will no longer be managed based on PDU sessions, but will evolve into task-level lifecycle management based on task sessions. The dimensions involved in these new services have also evolved from pure connectivity to four dimensions: connectivity, computing, data, and algorithms, and involve multiple network nodes, resulting in complex topologies. The QoS policy generation mechanism in 5G networks, however, manages PDU sessions and can only provide QoS guarantees and differentiated services for end-to-end connections along a simple path from terminal device to RAN to CN, making it unsuitable for generating QoS policies for new services. Therefore, how to design the QoS policy generation mechanism for new services introduced into communication networks is a pressing issue. To address this problem, embodiments of this application provide a communication method that can support the generation of QoS policies for new services introduced into communication networks, thereby ensuring the QoS of these services.

[0134] The following describes the specific implementation of the QoS method provided in the embodiments of this application. In the description of the embodiments of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. "And / or" in this application is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0135] In the embodiments of this application, "instruction" can include direct and indirect instructions, as well as explicit and implicit instructions. The information indicated by a certain piece of information is called the information to be instructed. In the specific implementation process, there are many ways to instruct the information to be instructed, such as, but not limited to, directly instructing the information to be instructed, such as the information to be instructed itself or its index. It can also indirectly instruct the information to be instructed by instructing other information, where there is a relationship between the other information and the information to be instructed. It can also instruct only a part of the information to be instructed, while the other parts are known or pre-agreed upon. For example, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing instruction overhead to some extent. At the same time, common parts of various pieces of information can be identified and uniformly indicated to reduce the instruction overhead caused by individually indicating the same information.

[0136] It should be understood that the information to be indicated can be sent as a whole or divided into multiple sub-information messages sent separately, and the sending period and / or timing of these sub-information messages can be the same or different. The specific sending method is not limited in this application embodiment. The sending period and / or timing of these sub-information messages can be predefined, for example, according to a protocol, or configured by the sending device by sending configuration information to the receiving device.

[0137] In the embodiments of this application, "predefined," "pre-configured," or "pre-configured" can be implemented by pre-saving corresponding codes, tables, or other methods that can be used to indicate relevant information in the device. For example, it can be burned into the device when it leaves the factory, or configured when it first connects to the network. The embodiments of this application do not limit the specific implementation method. "Saving" can refer to saving in one or more memories. The one or more memories can be separate settings or integrated into the encoder or decoder, processor, or communication device. The one or more memories can also be partially separate settings and partially integrated into the decoder, processor, or communication device. The type of memory can be any form of storage medium, and the embodiments of this application do not limit this.

[0138] The “protocol” mentioned in the embodiments of this application may refer to a protocol family in the field of communication, a standard protocol with a similar protocol family frame structure, or a related protocol applied to future communication systems. The embodiments of this application do not specifically limit this.

[0139] In the embodiments of this application, descriptions such as "when," "under the circumstances," "if," and "if" all refer to the device making corresponding processing under certain objective circumstances, and are not limited to a specific time. They do not require the device to make a judgment action during implementation, nor do they imply any other limitations.

[0140] In this embodiment of the application, "sending information to... (taking an anchor network element as an example)" can be understood as the destination of the information being the anchor network element. This can include sending information directly or indirectly to the anchor network element. "Receiving information from... (taking an anchor network element as an example)" can be understood as the source of the information being the anchor network element, and can include receiving information directly or indirectly from the anchor network element. Information may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood in a similar way, and will not be elaborated further here.

[0141] The technical solutions provided in this application can be used in various communication systems, such as 5G wireless communication systems and other communication systems, such as 6G communication systems and other communication systems that evolve after 5G. Furthermore, the term "system" can be used interchangeably with "network".

[0142] It should be noted that the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0143] It should be noted that the network elements mentioned in this document, such as TCF network element, TPF network element, cNode, sNode, etc., and the modules within the network elements, are only possible exemplary names. If the actual names used in subsequent communication networks (such as 6G networks) differ from those shown in this document, it will not affect the application of the communication method provided in the embodiments of this application.

[0144] In one possible, non-limiting communication system applicable to the embodiments of this application, the RAN architecture can be as shown in Figure 1. In Figure 1, for ease of task processing, RAN nodes are divided into two categories: cNodes and sNodes. A cNode is a regional-level centralized collaborative node consisting of multiple sNodes, responsible for providing RAN-side TA functions, such as signaling interaction functions related to RAN tasks. An sNode is responsible for providing RAN-side TE functions, and in some scenarios, can also provide RAN-side TS functions, such as RAN-side task scheduling and execution functions.

[0145] In the RAN architecture of the communication system applicable to this application embodiment, RAN nodes can be connected wirelessly or via wired means. For example, as shown in Figure 1, cNodes and sNodes communicate via the YI interface. Different sNodes communicate via the Y3 interface. Different cNodes communicate via the Y2 interface. In the RAN architecture of the communication system applicable to this application embodiment, RAN nodes can be connected wirelessly to terminal devices (not shown in Figure 1). In some scenarios, the terminal devices can also provide TE and / or TS functions.

[0146] In the RAN architecture of the communication system applicable to the embodiments of this application, the core network element and the RAN node can be different physical devices, or they can be the same physical device integrating core network logical functions and radio access network logical functions. If the core network element and the RAN node are different physical devices, the RAN node can be connected to and / or communicate with the core network element via wired or wireless means.

[0147] The RAN architecture of the communication system to which this application embodiment applies may also include other RAN nodes, such as wireless relay devices and / or wireless backhaul devices (not shown in Figure 1).

[0148] The RAN architecture shown in Figure 1 can be a cellular system related to the 3rd generation partnership project (3GPP), such as the RAN architecture in a 6G mobile communication system. It can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or the RAN architecture in a communication system that integrates two or more of these systems.

[0149] In one possible scenario, the RAN nodes in the 5G network can also be enhanced to provide TE functions on the RAN side.

[0150] In one possible, non-limiting communication system applicable to the embodiments of this application, the core network architecture can be as shown in Figure 2. The TCF network element provides TA (Transmission Control) functions on the core network side. The TPF network element provides TE (Transmission Equipment) functions on the core network side, and in some scenarios, it can also provide TS (Transmission Service) functions on the core network side. The connection function-control (CF-C) network element and the connection function-user (CF-U) network element provide the control plane and user plane functions for the connection, respectively. The mobility management (MM) element is responsible for providing mobility management functions for terminal devices and storing location information of the terminal devices. The unified data management (UDM) network element is mainly responsible for user subscription management, access authorization, and authentication information generation. The policy control function (PCF) network element is responsible for providing policy rules to network entities for implementation. The trust anchor agent (TAA) network element is responsible for ensuring the reliability, integrity, and confidentiality of data, preventing data from various security and privacy attacks from internal and external entities.

[0151] Optionally, the core network architecture of the communication system to which this application embodiment applies may also include other network elements. For example, it may also include a unified data repository (UDR) network element, a task orchestration network element, or a network data analytics function (NWDAF) network element. The unified data repository network element is primarily responsible for storing subscription data and policy rules. The task orchestration network element is primarily responsible for orchestrating tasks. The network data analytics function network element is primarily responsible for providing network analysis services based on network service request data.

[0152] The embodiments of this application do not limit the name of the task orchestration network element. For example, it can be called a network AI management and orchestration (NAMO) network element.

[0153] In one possible, non-limiting communication system applicable to embodiments of this application, RAN nodes can communicate with terminal devices via a wireless air interface (Uu interface), and their protocol stack includes control plane protocols and user plane protocols. RAN nodes can communicate with each other via a Yn interface, and their protocol stack may also include control plane protocols and user plane protocols. The control plane is responsible for signaling interaction, and the user plane is responsible for data interaction.

[0154] In one possible implementation, the control plane protocol stack and user plane protocol stack between the RAN node and the terminal device can be as shown in Figure 3. The task resource control (TRC) layer of the control plane can be an enhancement of the radio resource control (RRC) layer in the 5G protocol stack, adding task-related control functions such as AI, computing, and data processing to the existing RRC layer functionality. The task resource scheduler (TRS) of the user plane can be an enhancement of the medium access control (MAC) layer in the 5G protocol stack, for example, adding computing power scheduling functions to the existing air interface resource scheduling functions of the MAC layer. Furthermore, a task resource data (TRD) layer is added above the service data adaptation protocol (SDAP) layer. The TRD layer can provide task-related AI training / inference / model processing functions, and the sub-layers of the TRD can provide task data encapsulation functions. The other layers in Figure 3, such as the Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, TRS layer, Physical (PHY) layer, and SDAP layer, have specific functions that can be found in existing 5G communication protocols and will not be elaborated here.

[0155] In this application embodiment, the terminal device can refer to a user-side device with wireless transceiver capabilities. The terminal device can also be referred to as a terminal, user equipment (UE), access terminal, user unit, user station, mobile station (MS), remote station, remote terminal, mobile terminal (MT), user terminal, wireless communication equipment, user agent, or user device, etc.

[0156] For example, terminal devices can be drones, Internet of Things (IoT) devices (e.g., sensors, electricity meters, water meters, etc.), V2X devices, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistant (PDA) devices, handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices (e.g., terminals on cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), vehicle units (e.g., complete vehicle units, in-vehicle modules, in-vehicle chips, on-board units (OBUs) or telematics boxes (T-BOXs), etc.), wearable devices (also known as wearable smart devices, such as smartwatches, smart bracelets, pedometers, smart glasses, etc.), tablets or computers with wireless transceiver capabilities, virtual reality (VR) terminals, wireless terminals in industrial control, and self-driving vehicles. Wireless terminals in applications such as driving, remote medical care, smart grids, transportation safety, smart cities, smart homes, in-vehicle terminals, vehicles with vehicle-to-vehicle (V2V) communication capabilities, intelligent connected vehicles, and drones with UAV-to-UAV (U2U) communication capabilities, etc. Terminal devices can be mobile or fixed; this application does not specifically limit their location.

[0157] RAN nodes, sometimes also called access network devices, RAN entities, or access nodes, are network elements of a radio access network responsible for air interface functions. The name of the RAN node may differ depending on the system employing different radio access technologies.

[0158] In one possible scenario, a RAN node can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a next-generation evolved NodeB (ng-eNodeB), a cluster node or serving node in a 6G mobile communication system, or a base station in a future mobile communication system. A RAN node can be a macro base station, a micro base station or indoor station, a relay node or donor node, or a radio controller in a CRAN scenario. Optionally, a RAN node can also be a server, wearable device, vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the RAN node in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform). The RAN node in this application can also be a logical node, logical module, or software capable of implementing all or part of the RAN node functions.

[0159] In another possible scenario, multiple RAN nodes collaborate to assist terminal devices in achieving wireless access, with different RAN nodes each implementing a portion of the base station's functions. For example, RAN nodes can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs), etc. CUs and DUs can be set up separately or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio frequency equipment or radio frequency units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

[0160] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

[0161] The communication method provided in the embodiments of this application will now be described with reference to the communication systems shown in Figures 1 and 2.

[0162] It should be noted that in the following embodiments of this application, the message names between network elements, the names of each parameter, or the names of each piece of information are just examples. Other names may also be used in other embodiments, and the method provided in this application does not specifically limit them.

[0163] It is understood that in the embodiments of this application, each network element or entity may execute some or all of the steps in the embodiments of this application. These steps or operations are merely examples, and the embodiments of this application may also execute other operations or variations thereof. Furthermore, the steps may be executed in different orders as presented in the embodiments of this application, and it is not necessary to execute all the operations in the embodiments of this application.

[0164] Referring to Figure 4, the communication method provided in this application embodiment includes steps S401-S403:

[0165] S401, the policy control function network element obtains task information and the requirement information of the first service.

[0166] First, we will introduce the requirements for network elements with policy control functions to obtain the first service.

[0167] The requirements for the first service include QoS metrics related to the first service. For example, this may include requirements for at least one metric such as service success rate, service response latency, system energy efficiency, service coverage, or service density.

[0168] In one possible implementation, the requirements for the first service can be determined based on the agreement between the user of the first service and the provider of the first service. For example, the requirements for the first service could be service level agreement (SLA) information.

[0169] In one possible implementation of the policy control function network element obtaining the requirement information for the first service, the policy control function network element can obtain relevant information about the first service. This relevant information includes at least one of the following: the requirement information for the first service or the identification information of the first service. There is a mapping relationship between the identification information and the requirement information of the first service.

[0170] If the relevant information of the first service includes the identification information of the first service, the policy control function network element can determine the requirement information of the first service corresponding to the identification information of the first service based on the predefined mapping relationship between the identification information of the first service and the requirement information of the first service.

[0171] For example, a policy control function network element can predefine the one-to-one correspondence between the identification information of different services and the requirement information of different services. If the policy control function network element obtains the identification information of the first service, it can determine the requirement information of the service corresponding to the identification information of the first service according to the predefined correspondence, and determine the requirement information of the corresponding service as the requirement information of the first service.

[0172] In this embodiment of the application, "predefined" can also be understood as preset, pre-configured, pre-set, protocol-defined, or pre-agreed. It is hereby uniformly stated that similar expressions in the following text can also be understood in this way.

[0173] If the relevant information of the first service includes the identification information and the requirement information of the first service, the policy control function network element may optionally establish a mapping relationship between the identification information and the requirement information of the first service.

[0174] If the relevant information of the first service includes the requirement information of the first service, optionally, the policy control function network element can determine the identification information of the first service corresponding to the requirement information of the first service based on the predefined mapping relationship between the identification information of the first service and the requirement information of the first service.

[0175] The identification information of the first service can also be understood as information that can be combined with the requirements information of the first service to jointly define the first service. For example, the identification information of the first service may include at least one of the following: information of the user or third party that triggers the first service, information of the terminal device involved in the first service, or information of the application service provider (ASP).

[0176] For example, a third party could be a vendor providing over-the-top (OTT) services. OTT service providers can directly trigger the first service at the network layer.

[0177] For example, the identification information of the first service may include the user ID (if the user is a UE, then the user ID is the UE ID), the Internet Protocol (IP) triplet information of the OTT service server that triggered the first service, information about the network services required by the OTT service provider, the address of the UE involved in the first service (if a task session and / or PDU session has been established), and information about the ASP providing the first service. The IP triplet information includes the IP address, transport layer protocol, and port.

[0178] The first service is jointly defined by its identifier information and its requirement information. If two services have different identifier information and different requirement information, they can be considered different services. If two services have the same identifier information and different requirement information, they can be considered the same service. In one possible scenario, if two services have different requirement information but the same identifier information, or if two services have different identifier information but the same requirement information, they can be considered different services. In another possible scenario, if two services have different requirement information but the same identifier information, or if two services have different identifier information but the same requirement information, they can be considered the same service.

[0179] Optionally, the policy control function network element can also obtain information about the service data flow (SDF). For example, the SDF information may include the IP 5-tuple information of the service data. This IP 5-tuple information includes the source IP address, source port, destination IP address, destination port, and transport layer protocol.

[0180] Optionally, the policy control function network element can also obtain the type information of the first service. This type information can indicate which major category the first service belongs to. For example, the type information of the first service can indicate whether it is an AI service, a computing service, a data service, or a perception service. Alternatively, the type information of the first service can also indicate which subcategory within that major category the first service belongs to. For example, assuming the first service is an AI service, the type information of the first service can also indicate whether it is a model training, model inference, or model validation service.

[0181] This application does not limit the policy control function network element to obtaining the first service requirement information from any specific network element. For example, the policy control function network element may obtain the first service requirement information from the application function network element.

[0182] The following describes how the policy control function network element obtains task information.

[0183] The first service can decompose and map to obtain one or more tasks, and the task information includes relevant information of the tasks obtained by the decomposition and mapping of the first service.

[0184] Optionally, the task information may include at least one of the task's deployment information or the task's topology information.

[0185] The task deployment information may include at least one of the following: task identification information or information about the network element responsible for executing the task. For example, the task deployment information may include the task ID and the ID of the network element responsible for executing the task.

[0186] The topology information of a task can indicate the connection methods between network elements involved in the task. For example, the topology information of a task can describe at least one of the following connection methods: RAN-RAN (connection between different RAN nodes on the RAN side), CN-RAN-UE (connection between core network elements, RAN nodes and terminal equipment), and UE-RAN-UE (connection between different terminal equipment and RAN nodes).

[0187] In one possible implementation, if the task deployment information includes task identification information and information about the network element responsible for executing the task, a mapping relationship may exist between the task identification information and the information about the network element responsible for executing the task. For example, the task deployment information may include multiple task IDs and the ID of the network element responsible for executing the task corresponding to each task ID.

[0188] In this application embodiment, the term "network element responsible for performing the task" or similar expressions, such as "network element performing the task," can be referred to as the execution network element, and will be consistently described here. The execution network element can provide TE (Traffic Execution) functions, the details of which can be found in the above description and will not be elaborated upon here.

[0189] In another possible scenario, the execution network element can also provide TS functionality. For details on TS functionality, please refer to the above introduction, which will not be elaborated here.

[0190] This application does not limit the specific network element from which the policy control function network element obtains the task information. For example, the policy control function network element may obtain the requirement information of the first service from the anchor network element.

[0191] In this embodiment, the anchor network element is a network element that provides TA (Transportation Transaction) functionality, and will be described uniformly here. For example, the anchor network element can be a TCF (Transportation Functional Component) or a cNode.

[0192] Optionally, when the policy control function network element obtains task information, it can also obtain the identification information of the QoS parameters of the first service. For example, the anchor network element sends the task information and the identification information of the QoS parameters of the first service to the policy control network element. The policy control function network element can determine the QoS parameters of the first service to which the task belongs based on the identification information of the QoS parameters of the first service, thereby further generating the QoS parameters of the task. The QoS parameters of the first service and the QoS parameters of the task will be described in detail below and will not be elaborated here.

[0193] It is understood that the flowchart shown in Figure 4 is merely a logical illustration provided for ease of understanding of the embodiments of this application, and does not represent the actual timing of the embodiments of this application. The embodiments of this application do not limit the timing between different actions within the same step in Figure 4, or the timing between different steps in Figure 4. For example, S401 is for the policy control function network element to obtain task information and the requirement information of the first service, which does not mean that the policy control function network element obtains both task information and the requirement information of the first service simultaneously. In one possible case, the policy control function network element may obtain the requirement information of the first service first, and then obtain the task information. As another example, in Figure 4, S402 follows S401, which does not mean that the policy control function network element completes S401 first and then S402. In one possible case, the policy control function network element may first obtain the requirement information of the first service, then generate the quality of service (QoS) parameters of the first service based on the requirement information of the first service, and then obtain the task information.

[0194] Optionally, in addition to task information and the requirements of the first service, the policy control function network element can also obtain other information that can assist in generating network policies. For example, the policy control function network element can also obtain at least one of the following: billing-related information, data statistics or forecast information for certain network functions or network services, bandwidth requirement information, or information indicating data format (e.g., media type information). This application embodiment does not limit the policy control function network element to specifically obtaining the above information from any particular network element or network elements.

[0195] S402. The policy control function network element generates the QoS parameters of the first service based on the requirement information of the first service.

[0196] In S402, the policy control function network element can classify and merge the requirements information of the first service to generate one or more sets of QoS parameters for the first service. For example, the policy control function network element can, based on the different requirements for a certain QoS indicator in the requirements information of the first service, group the requirements that the QoS indicator must be within a certain range into one set of QoS parameters, and group the requirements that the QoS indicator must be within another range into another set of QoS parameters.

[0197] The QoS parameters of the first service may include the QoS metrics and control policies of the first service. In this case, the QoS parameters of the first service are service-level.

[0198] For example, a set of QoS parameters for the first service may include information indicating at least one metric such as service success rate, service response latency, system energy efficiency, service coverage, or service density, as well as information indicating the value corresponding to each metric. Among these, service success rate, service response latency, system energy efficiency, service coverage, and service density are the QoS metrics for the first service. The value corresponding to each metric represents the control policy for that metric; for example, a value of 1ms for service response latency means that the end-to-end latency requirement for the first service is 1ms.

[0199] Optionally, the QoS parameters of the first service can be identified by identification information, and one set of identification information can uniquely identify a set of QoS parameters.

[0200] In one possible implementation, the identification information of the QoS parameters of the first service can be generated by the policy control function network element. For example, the policy control function network element can generate a different service ID for each set of QoS parameters of the first service.

[0201] In another possible implementation, the identification information of the QoS parameters of the first service can be predefined. For example, the policy control function network element selects a different service ID for each set of QoS parameters of the first service from the operator's predefined service IDs.

[0202] Optionally, if the first service has multiple sets of QoS parameters, each set of QoS parameters can have different priorities.

[0203] For example, if the first service belongs to a high-priority user (VIP) with a contract with the operator, then the first priority QoS parameters can be the set of QoS parameters with the highest requirements. If the first service does not belong to a VIP, then the first priority QoS parameters can be a set of QoS parameters with lower requirements.

[0204] Optionally, if the policy control function network element obtains relevant information about the first service in S401, then in S402, the policy control function network element can generate a QoS template corresponding to the first service based on the relevant information. The QoS template includes the mapping relationship between the QoS parameters of the first service and the identification information of the first service. How to generate the QoS template corresponding to the first service can be referred to the above description of different cases of relevant information about the first service, and will not be elaborated here.

[0205] Optionally, following S402, the following steps may also be included:

[0206] The policy control function network element sends the QoS parameters of the first service to the unified data pool network element. Correspondingly, after receiving the QoS parameters of the first service, the unified data pool network element can store the QoS parameters of the first service.

[0207] In S402, if the policy control function network element generates a QoS template corresponding to the first service, the policy control function network element can send the QoS template corresponding to the first service to the unified data pool network element.

[0208] S403, the policy control function network element generates the QoS parameters of the task based on the task information and the QoS parameters of the first service.

[0209] Based on this scheme, the policy control function network element can generate service-level QoS parameters and further generate task-level QoS parameters, which is suitable for new services managed at the task granularity and can support the generation of QoS policies for new services in the communication network.

[0210] In S403, the QoS parameters of a task include the QoS metrics and control policies of the task obtained from the first service decomposition mapping. At this point, the QoS parameters of the task are task-level.

[0211] For example, a task's QoS parameters may include information indicating at least one metric such as task success rate, task response latency, system energy efficiency, task coverage, or task density, as well as information indicating the value corresponding to each metric. Among these, task success rate, task response latency, system energy efficiency, task coverage, and task density are the task's QoS metrics. The value corresponding to each metric represents the control strategy for that metric; for example, a value of 1ms for task response latency means that the end-to-end latency requirement for the task is 1ms.

[0212] Optionally, the QoS parameters of a task may include at least one of the following: specific QoS requirement information or an identifier indicating specific QoS requirements. The identifier indicating specific QoS requirements may have a predefined mapping relationship with the specific QoS requirements, thus allowing the corresponding specific QoS requirements to be determined using the identifier indicating specific QoS requirements.

[0213] For example, specific QoS requirements may include task metrics and the corresponding values ​​for those metrics.

[0214] For example, an identifier that indicates a specific QoS requirement could be a 6G QoS identifier (6QI).

[0215] In one possible implementation of generating QoS parameters for a task, the policy control function network element can generate a policy and charging control (PCC) rule based on the task information and the QoS parameters of the first service. The policy and charging rule includes the task's QoS parameters and a mapping relationship between the task's QoS parameters and at least one of the executing network element or task data flow (TDF) that performs the task.

[0216] In this context, task data stream can be understood as the data transmission generated by the network element when executing a task. In other words, task data stream is at the task level.

[0217] In one possible scenario, if the business to which the first service belongs involves one or more of the four dimensions (connectivity, computing, data, and algorithms), the task data flow can be understood as the data transmission generated when the execution network element executes data subtasks, computing subtasks, or algorithm subtasks.

[0218] Optionally, policies and billing rules may also include policy and billing rule identification information (rule ID).

[0219] Optionally, if in S401, the policy control function network element obtains the mapping relationship between the task's identification information and the information of the execution network element executing the task, then when generating the task's QoS parameters, the policy control function network element can generate the mapping relationship between the task's QoS parameters and the execution network element executing the task based on the obtained mapping relationship.

[0220] In one possible scenario, if the business to which the first service belongs involves multiple dimensions, then the QoS parameters of the task generated by the policy control function network element can include QoS parameters related to the dimensions involved.

[0221] For example, if the business to which the first service belongs involves four dimensions: connectivity, computing, data, and algorithms, the QoS parameters of the task generated by the policy control function network element may include: QoS parameters related to connectivity, QoS parameters related to computing, QoS parameters related to data, and QoS parameters related to algorithms.

[0222] The following section uses the example of the business of the first service involving at least one dimension of connection, computing, data or algorithm to introduce the possible contents of the policies and billing rules generated by the policy control function network element.

[0223] If the service to which the first service belongs involves the connection dimension, the policies and charging rules generated by the policy control function network element may include at least one of the following: QoS specific requirements information related to the connection, identifiers indicating QoS specific requirements related to the connection, information of the network element executing the starting point of the service data flow of the task, and information of the network element executing the ending point of the service data flow of the task.

[0224] Optionally, each business data stream of a task can be categorized based on which dimension of computation, data, or algorithm the data transmitted in the task's business data stream (i.e., task data stream) is related to. In other words, a task's business data stream can include different types of business data streams, where different types can include computation, data, or algorithm types. In this case, policies and billing rules may also include information about the type of the task's business data stream.

[0225] Specifically, the starting execution network element of the task's business data flow is the starting execution network element on the transmission path of the task's business data flow, and the ending execution network element is the ending execution network element on the transmission path of the task's business data flow. Optionally, the transmission paths of each business data flow of the task can be the same or different.

[0226] For example, the information of the network element executing the starting point of the task's business data flow transmission may include at least one of the following: the ID or IP address of the network element executing the starting point of the task's business data flow transmission. The information of the network element executing the ending point of the task's business data flow transmission is similar and will not be described again.

[0227] For example, the QoS-specific requirements information related to the connection may include at least one of the following: guaranteed flow bit rate (GFBR), maximum flow bit rate (MFBR), or allocation and retention priority (ARP).

[0228] For example, an identifier indicating specific QoS requirements related to a connection could be 6QI.

[0229] If the business to which the first service belongs involves the computing dimension, the policies and billing rules generated by the policy control function network element may include at least one of the following: specific QoS requirements related to computing, an identifier indicating specific QoS requirements related to computing, information of the execution network element used to perform the computing function, an identifier of the computing subtask, or the computing type of the computing subtask.

[0230] One task can be broken down into one or more computational subtasks.

[0231] The execution network element used to perform computing functions can refer to the execution network element that performs the computing sub-task. For example, the information of the execution network element used to perform computing functions may include at least one of the following: the ID or IP address of the execution network element that performs each computing sub-task.

[0232] In one possible scenario, the network element performing computational functions can also perform algorithmic and / or data functions. In other words, the network element performing computational functions can also be the network element performing algorithmic and / or data functions.

[0233] The computation type of a computational subtask can be categorized based on its computational specifications (or the computational resources required by the subtask). For example, computational resources can include computing power types, such as a central processing unit (CPU), a graphics processing unit (GPU), or a field-programmable gate array (FPGA), and computing power requirements, such as millions of floating-point operations per second (MFLOPS).

[0234] For example, specific QoS requirements related to computing may include at least one of the following: giga floating-point operations per second (GFLOPS), MFLOPS, or ARP, etc.

[0235] For example, an identifier indicating specific QoS requirements related to computation could be 6QI.

[0236] For example, the identifier of a computation subtask can be the ID of the computation subtask.

[0237] If the business to which the first service belongs involves the data dimension, the policies and billing rules generated by the policy control function network element may include at least one of the following: specific QoS requirements related to the data, identifiers indicating specific QoS requirements related to the data, data type, data scale (also known as data volume), or information of the execution network element used to perform the data function.

[0238] For example, the information of the network element performing the data function may include at least one of the following: the ID or IP address of the network element performing the data function.

[0239] For example, specific QoS requirements related to data may include at least one of the following: latency or ARP. Latency may include at least one of data transmission delay or data processing delay.

[0240] For example, an identifier indicating specific QoS requirements related to data could be 6QI.

[0241] The data type is used to indicate the dimension corresponding to the data. For example, the data type can include at least one of computational data, model data, or data data. Specifically, computational data indicates that the data corresponds to a computational dimension; model data indicates that the data corresponds to a model dimension; and data data indicates that the data corresponds to a data dimension. For example, if the data is perceptual data, it can indicate that the data corresponds to a data dimension, which needs to be processed specifically through data functions.

[0242] For example, the data size may include at least one of the following: bit, byte, kilobyte (KB), megabyte (MB), gigabyte (GB), or terabyte (TB).

[0243] If the business to which the first service belongs involves the algorithm dimension, the policies and billing rules generated by the policy control function network element may include at least one of the following: QoS specific requirements information related to the algorithm, identifiers indicating QoS specific requirements related to the algorithm, algorithm type, algorithm level, application method, or information of the execution network element used to perform the algorithm function.

[0244] For example, the information of the network element used to perform the algorithm function may include at least one of the following: the ID or IP address of the network element performing the algorithm function.

[0245] The algorithm level can indicate the requirements for the model's structure or size. For example, the algorithm level can indicate that the model needs to be trained 100 times, or that the model has 7 billion parameters.

[0246] For example, specific QoS requirements related to the algorithm may include at least one of the following: training and inference latency, inference accuracy, or ARP.

[0247] For example, an identifier indicating specific QoS requirements related to the algorithm could be 6QI.

[0248] For example, the algorithm type can be a recursive algorithm, a sorting algorithm, or a hash algorithm, etc.

[0249] The application method can indicate how to apply algorithm-related QoS parameters. For example, the application method can indicate when to use the first-priority algorithm-related QoS parameters, and whether to enable the second-priority algorithm-related QoS parameters if the first-priority algorithm-related QoS parameters cannot be met.

[0250] Optionally, after S403, the embodiments of this application may further include the following steps:

[0251] S404. The policy control function network element sends the QoS parameters of the task to the anchor network element.

[0252] Correspondingly, after receiving the QoS parameters of the task, the anchor network element can generate resource-level QoS parameters based on the task's QoS parameters. These resource-level QoS parameters include at least one of the following: connection dimension, computation dimension, data dimension, and algorithm dimension.

[0253] The specific implementation of how anchor network elements generate resource-level QoS parameters based on the task's QoS parameters will be described below and will not be elaborated here.

[0254] In one possible implementation of S404, the policy control function network element can send policies and charging rules to the anchor network element. The content of the policies and charging rules can be referred to the introduction of S403 above, and will not be elaborated here.

[0255] Referring to Figure 5, another communication method provided in this application embodiment includes steps S501-S503:

[0256] S501, Anchor network element obtains QoS parameters for the task.

[0257] For details regarding the QoS parameters of the task, please refer to the above introduction to the QoS parameters of the task in S403, which will not be elaborated here.

[0258] This application does not limit the anchor network element to obtaining the QoS parameters of the task from any particular network element. For example, the anchor network element may obtain the QoS parameters of the task from the policy control function network element.

[0259] In one possible implementation of S501, the anchor network element can acquire policies and charging rules. These policies and charging rules include the QoS parameters of the task and the mapping relationship between the QoS parameters of the task and at least one of the executing network element or the task data stream. For the specific content of the policies and charging rules in this implementation, please refer to the introduction of policies and charging rules in S403 above; it will not be elaborated upon here.

[0260] Optionally, embodiments of this application may further include the following steps: the anchor network element obtains the orchestration result of the task, the orchestration result including task template description information and task dependencies.

[0261] The task template description information is used to describe the task or the subtasks obtained from the task decomposition. For example, it may include at least one of the following information: task type (e.g., the type of subtask is algorithm, computation, or data), resource requirements (this information may indicate the amount of resources required by the task or subtask), computational complexity (this information may indicate the complexity of the operations required to execute the task or subtask), and runtime description (e.g., the time from start to finish of a task or subtask).

[0262] The dependencies between tasks can include the dependencies between different tasks obtained from the first service decomposition mapping. For example, suppose the first service decomposition mapping yields task A, task B, and task C. The dependencies between tasks could be: the execution of task A depends on the execution of task B, and the execution of task C depends on the execution of both task A and task B.

[0263] Optionally, the task orchestration results may also include information about the network elements that perform the tasks.

[0264] This application does not limit which network element the anchor network element obtains the task orchestration result from. For example, the anchor network element may obtain the task orchestration result from the task orchestration network element.

[0265] Optionally, when the anchor network element obtains the orchestration results of the task, it can also obtain the identification information of the QoS parameters of the first service. For example, the task orchestration network element sends the identification information of the QoS parameters of the first service and the orchestration results to the anchor network element together.

[0266] This application does not limit the timing between the anchor network element acquiring the QoS parameters of the task and the anchor network element acquiring the orchestration result of the task. For example, the anchor network element may first acquire the orchestration result of the task and then acquire the QoS parameters of the task.

[0267] Furthermore, anchor network elements can obtain task information based on the orchestration results. This task information includes task deployment information and topology information. For details on the task information in S401, please refer to the previous section on task information; further details will not be elaborated upon here.

[0268] Optionally, the anchor network element can also send task information to the policy control function network element. Correspondingly, after receiving the task information, the policy control function network element can generate QoS parameters for the task based on the task information. For details on how the policy control function network element generates QoS parameters for the task based on the task information, please refer to the above introduction to S403; it will not be elaborated upon here.

[0269] In one possible implementation, when the anchor network element sends task information to the policy control function network element, it can also send the QoS parameters of the first service to the policy control function network element.

[0270] Furthermore, after obtaining the QoS parameters of the task, the anchor network element can bind the task session to the QoS parameters. The anchor network element can also classify the task data stream according to the task's QoS parameters to obtain a task QoS flow, and then bind the task's QoS parameters to the task QoS flow. A task QoS flow can include one or more task data streams with the same QoS requirements.

[0271] In this context, the task QoS flow can be understood as the smallest granularity for QoS management by anchor network elements and execution network elements. Anchor network elements and execution network elements can provide QoS guarantees and differentiated services based on the task QoS flow.

[0272] S502. The anchor network element generates resource-level QoS parameters based on the task's QoS parameters and the executing network element. These resource-level QoS parameters include at least one of the following: connection dimension, computation dimension, data dimension, and algorithm dimension.

[0273] In S502, anchor network elements can decompose and map task QoS parameters based on the QoS parameters related to connectivity, computation, data, or algorithms in the task's QoS parameters, and generate resource-level QoS parameters.

[0274] For the execution network element performing the task, in one possible implementation, the anchor network element can be determined based on the obtained task orchestration results. In another possible implementation, the anchor network element can determine the task itself. For example, the anchor network element can select the execution network element to perform the task based on the capabilities of the execution network elements.

[0275] In one possible implementation of S502, the anchor network element can determine the sub-tasks to be executed for each execution network element based on the differences in processing capabilities of each execution network element in various dimensions, and determine the corresponding resource-level QoS parameters.

[0276] The following section introduces the possible contents of resource-level QoS parameters generated by anchor network elements, based on different situations of QoS parameters included in the task's QoS parameters.

[0277] Scenario 1: The QoS parameters of the task include connection-related QoS parameters. For example, the policies and charging rules obtained by the anchor network element include at least one of the following: connection-related QoS specific requirement information, identifiers indicating connection-related QoS specific requirements, information of the network element executing the starting point of the task's service data flow, and information of the network element executing the ending point of the task's service data flow. Please refer to the above introduction to S403 for details.

[0278] In this scenario, the resource-level QoS parameters generated by the anchor network element may include a connection dimension. In one possible implementation, the connection-dimensional QoS parameters may include at least one of the following: connection-related QoS specific requirement information, an identifier indicating the connection-related QoS specific requirements, or a packet detection rule (PDR). The packet detection rule is used to distinguish service data flows corresponding to different QoS requirements.

[0279] The following describes a possible implementation method for distinguishing service data streams corresponding to different QoS requirements based on packet identification rules. Packet identification rules include specific detection rules, and different packet identification rules are associated with different QoS requirements. If a service data stream is determined to match a packet identification rule according to the specific detection rules, then the QoS requirement associated with the matched packet identification rule can be determined, thereby distinguishing service data streams corresponding to different QoS requirements. Furthermore, based on the QoS requirements corresponding to different service data streams, service data streams corresponding to the same QoS requirement can be divided into the same task QoS stream.

[0280] Scenario 2: The QoS parameters of the task include QoS parameters related to computation. For example, the policies and charging rules obtained by the anchor network element include at least one of the following: specific QoS requirement information related to computation, an identifier indicating the specific QoS requirements related to computation, information of the network element used to perform the computation function, and an identifier of the computation subtask or the computation type of the computation subtask. Please refer to the above introduction to S403 for details.

[0281] In this case, the resource-level QoS parameters generated by the anchor network element may include a computation dimension. In one possible implementation, the QoS parameters of the computation dimension may include at least one of the following: specific QoS requirement information related to computation, an identifier indicating the specific QoS requirements related to computation, or a computational subtask identification rule (CDR). The computational subtask identification rule is used to distinguish computational subtasks corresponding to different QoS requirements.

[0282] The following describes a possible implementation method for distinguishing computational subtasks corresponding to different QoS requirements based on computational subtask identification rules. The computational subtask identification rules include specific detection rules, and different computational subtask identification rules are associated with different QoS requirements. If a computational subtask is determined to match a computational subtask identification rule based on the specific detection rules, then it can be determined that the computational subtask corresponds to the QoS requirement associated with the matched computational subtask identification rule, thereby distinguishing computational subtasks corresponding to different QoS requirements.

[0283] Scenario 3: The QoS parameters of the task include data-related QoS parameters. For example, the policies and charging rules obtained by the anchor network element include at least one of the following: specific QoS requirements related to the data, an identifier indicating the specific QoS requirements related to the data, and the data type or data size. Please refer to the introduction to S403 above for details.

[0284] In this scenario, the resource-level QoS parameters generated by the anchor network element may include a data dimension. In one possible implementation, the data dimension QoS parameters may include at least one of the following: specific QoS requirement information related to the data, an identifier indicating the specific QoS requirement related to the data, or a data subtask identification rule (DDR). The data subtask identification rule is used to distinguish data subtasks corresponding to different QoS requirements. For details on distinguishing data subtasks corresponding to different QoS requirements based on the data subtask identification rule, please refer to "Distinguishing Computational Subtasks Corresponding to Different QoS Requirements Based on Computational Subtask Identification Rules," which will not be elaborated upon here.

[0285] Scenario 4: The QoS parameters of the task include QoS parameters related to the algorithm. For example, the policies and charging rules obtained by the anchor network element include at least one of the following: specific QoS requirements related to the algorithm, an identifier indicating the specific QoS requirements related to the algorithm, the algorithm type, the algorithm level, or the application method. Please refer to the introduction to S403 above for details.

[0286] In this case, the resource-level QoS parameters generated by the anchor network element may include an algorithm dimension. In one possible implementation, the algorithm-level QoS parameters may include at least one of the following: specific QoS requirement information related to the algorithm, an identifier indicating the specific QoS requirements related to the algorithm, or an algorithm subtask identification rule (model detection rule, MDR). The algorithm subtask identification rule is used to distinguish algorithm subtasks corresponding to different QoS requirements. For details on distinguishing algorithm subtasks corresponding to different QoS requirements based on the algorithm subtask identification rule, please refer to "Distinguishing Computational Subtasks Corresponding to Different QoS Requirements Based on Computational Subtask Identification Rules," which will not be elaborated upon here.

[0287] S503, the anchor network element sends resource-level QoS parameters to the execution network element.

[0288] Correspondingly, after receiving the resource-level QoS parameters, the execution network element can execute tasks according to the resource-level QoS parameters.

[0289] Based on the communication method provided in the embodiments of this application, QoS parameters including four dimensions of resources can be generated. New services in the communication network also need to coordinate four-dimensional resources. Therefore, the communication method provided in the embodiments of this application can support the generation of QoS policies for new services in the communication network.

[0290] In one possible implementation of S503, the anchor network element can send the corresponding resource-level QoS parameters to the execution network element of each subtask obtained from task decomposition.

[0291] In one possible scenario, the information carrying resource-level QoS parameters sent by the anchor network element to the execution network element can have different names depending on the execution network element. For example, if the execution network element is a terminal device, the information carrying resource-level QoS parameters can also be called a QoS rule, or in other words, the QoS parameters are included in the QoS rule. As another example, if the execution network element is a TPF network element or an sNode, the information carrying resource-level QoS parameters can be called a QoS profile, or in other words, the resource-level QoS parameters are included in the QoS profile. However, the embodiments of this application do not limit the name used for the information carrying resource-level QoS parameters.

[0292] Optionally, after S503, the embodiments of this application may further include the following steps:

[0293] The anchor network element receives notification information from the execution network element. The notification information is used to inform the execution network element that it cannot meet the corresponding QoS requirements (QoS requirements related to connectivity, computing, data, or algorithms).

[0294] Optionally, after receiving the notification information, the anchor network element can schedule network resources to ensure that the execution network element can meet the corresponding QoS requirements.

[0295] Optionally, after receiving the notification, the anchor network element can report to other network elements that the executing network element cannot meet the corresponding QoS requirements. For example, the anchor network element can report to the policy control function network element that the executing network element cannot meet the corresponding QoS requirements.

[0296] In another possible scenario, the anchor network element can determine whether to send resource-level QoS parameters to the execution network element based on the functions of the modules within the execution network element.

[0297] For example, suppose resource-level QoS parameters include data-level QoS parameters. If the module responsible for executing data functions (hereinafter referred to as the data execution module) within the execution network element also integrates computing and algorithm functions, then the anchor network element can directly send the resource-level QoS parameters to the data execution module.

[0298] If, within the execution network element, the data execution module, the module responsible for performing computational functions (hereinafter referred to as the computational execution module), and the module responsible for performing algorithmic functions (hereinafter referred to as the algorithm execution module) are independent modules—that is, the data execution module does not integrate computational and algorithmic functions—then the computational execution module can be managed by the module within the anchor network element responsible for managing task computational resources (hereinafter referred to as the computational control module), and the algorithm execution module can be managed by the module within the anchor network element responsible for managing task algorithmic resources (hereinafter referred to as the algorithm control module). This can also be understood as the computational and / or algorithmic functions provided by the execution network element being managed by the corresponding modules within the anchor network element. In this case, after the anchor network element obtains the resource-level QoS parameters, the module within the anchor network element responsible for managing task data resources (hereinafter referred to as the data control module) can call the corresponding computational and / or algorithmic functions to the computational control module and / or algorithm control module. If a computational function is called, the data control module can send the corresponding computational-dimensional QoS parameters to the computational control module. If an algorithmic function is called, the data control module can send the corresponding algorithm-dimensional QoS parameters to the algorithm control module.

[0299] For example, suppose resource-level QoS parameters include algorithm-level QoS parameters. If the algorithm execution module within the execution network element also integrates computation and data functions, then the anchor network element can directly send the resource-level QoS parameters to the algorithm execution module.

[0300] If the data execution module, computation execution module, and algorithm execution module within the execution network element are independent modules—meaning the algorithm execution module does not integrate computation and data functions—then the computation execution module can be managed by the computation control module within the anchor network element, and the data execution module can be managed by the data control module within the anchor network element. This can also be understood as the computation and / or data execution functions provided by the execution network element being managed by the corresponding modules within the anchor network element. In this case, after the anchor network element obtains the resource-level QoS parameters, the algorithm control module within the anchor network element can invoke the corresponding computation and / or data functions to the computation control module and / or data control module. If a computation function is invoked, the algorithm control module can send the corresponding computation-dimensional QoS parameters to the computation control module. If a data function is invoked, the algorithm control module can send the corresponding data-dimensional QoS parameters to the data control module.

[0301] For example, if the resource-level QoS parameters include the computation-level QoS parameters, the anchor network element can directly send the computation-level QoS parameters to the computation execution module.

[0302] In one possible scenario of the above example, when the data control or algorithm control module invokes the computing function, it can identify a new execution network element that performs the computing function, as well as the identification information of the new computing subtask (e.g., the new computing subtask ID), and send it to the computing control module.

[0303] In one possible scenario of the above example, when the data control module invokes the algorithm function, it can determine the QoS parameters for the new algorithm dimension and send them to the algorithm control module.

[0304] In one possible scenario of the above example, when the algorithm control module invokes the data function, it can determine the QoS parameters of the new data dimension and send them to the data control module.

[0305] In this application embodiment, the description of the interaction between internal modules of the network element is for the purpose of understanding the technical solution of this application. The description of the logical interaction between internal modules does not mean that there must be actual interaction steps between internal modules when the network element executes the communication method of this application embodiment.

[0306] Referring to Figure 6, another communication method provided in this application embodiment includes steps S601-S602:

[0307] S601, Execute the network element to obtain resource-level QoS parameters. The resource-level QoS parameters include at least one of the following: connection dimension, computation dimension, data dimension, or algorithm dimension.

[0308] For details on resource-level QoS parameters, please refer to the above introduction to resource-level QoS parameters in S502, which will not be elaborated here.

[0309] This application does not limit the execution network element to which network element it obtains resource-level QoS parameters. For example, the execution network element may obtain resource-level QoS parameters from the anchor network element.

[0310] S602. The network element executes the task according to the resource-level QoS parameters.

[0311] Based on the communication method provided in the embodiments of this application, tasks can be executed according to resource-level QoS parameters, thereby realizing QoS management of the four-dimensional resources of the task.

[0312] In one possible implementation of S602, the execution network element can adjust its strategy or allocate resources based on the acquired resource-level QoS parameters to meet the requirements of those parameters. For example, assuming that the resource-level QoS parameters include latency requirements, the execution network element can allocate computing power that meets those latency requirements to execute the corresponding function.

[0313] In one possible scenario, when an execution network element performs a task, different types of subtasks can be executed separately by internal modules responsible for different functions. Alternatively, when an execution network element performs a task, multiple types of subtasks can be executed by an internal module that integrates multiple functions. For example, suppose that within the execution network element, the module responsible for performing computational functions (which can be called the computational execution module) also integrates algorithm and data functions; then the computational execution module can execute computational subtasks, algorithmic subtasks, and data subtasks.

[0314] In another possible scenario, the anchor network element can manage and execute certain modules within the execution network element, thereby scheduling the corresponding functions to execute subtasks. For details, please refer to the above introduction to S503; further details will not be repeated here.

[0315] Optionally, if the executing network element finds that it cannot meet the QoS requirements related to connectivity, computing, data, or algorithms in the obtained resource-level QoS parameters, the executing network element can send a notification message to the anchor network element. The notification message is used to inform the executing network element that it cannot meet the QoS requirements related to connectivity, computing, data, or algorithms.

[0316] Referring to Figure 7, another communication method provided in this application embodiment includes steps S701-S702:

[0317] S701, the task orchestration network element obtains the QoS parameters of the first service.

[0318] For details on the QoS parameters of the first service, please refer to the above introduction to the QoS parameters of the first service in S402, which will not be elaborated here.

[0319] This application embodiment does not limit which network element the task orchestration network element obtains the QoS parameters of the first service from. For example, the task orchestration network element can obtain the QoS parameters of the first service from the unified data pool network element. Optionally, the QoS parameters of the first service stored in the unified data pool network element can be generated by the policy control function network element.

[0320] Optionally, one possible implementation of S701 is: the task orchestration network element obtains the QoS template corresponding to the first service. The QoS template includes a mapping relationship between the QoS parameters of the first service and the identification information of the first service. For details on the QoS template corresponding to the first service, please refer to the above introduction to S401; it will not be elaborated upon here.

[0321] Optionally, prior to S701, the embodiments of this application may further include the following steps:

[0322] The task orchestration network element is input into the use case after the first service is instantiated. The use case may include the identification information of the first service or the identification information of the QoS parameters of the first service.

[0323] At this time, S701 can be: The task orchestration network element obtains the corresponding QoS parameters of the first service based on the identification information of the first service or the identification information of the QoS parameters of the first service.

[0324] S702. The task orchestration network element performs task orchestration based on the QoS parameters of the first service, obtaining orchestration results at the task level. The orchestration results include template descriptions and dependencies of the tasks obtained from the decomposition and mapping of the first service.

[0325] Based on the communication method provided in the embodiments of this application, task orchestration can be provided for new services in the communication network, especially some more complex services, thereby enabling QoS hierarchical management from service to task.

[0326] For details on the arrangement results, please refer to the above introduction to S501, which will not be elaborated here.

[0327] Optionally, after S702, the embodiments of this application may further include the following steps:

[0328] The task orchestration network element sends the orchestration result to the anchor network element.

[0329] Correspondingly, after receiving the orchestration results, the anchor network element can obtain task information based on the orchestration results. This task information includes task deployment information and topology information. For details on how the anchor network element obtains task information based on the orchestration results, please refer to the above introduction to S501; further details will not be elaborated here.

[0330] Optionally, if the QoS parameters of the first service include multiple sets of QoS parameters, and each set of QoS parameters has a different priority, the task orchestration network element can first obtain the first priority QoS parameters of the first service, and then perform task orchestration based on the first priority QoS parameters.

[0331] Furthermore, if the orchestration based on the first priority QoS parameters fails and no orchestration result is obtained, the task orchestration network element can obtain the second priority QoS parameters of the first service and perform task orchestration according to the second priority QoS parameters.

[0332] Similarly, if orchestration based on the second priority QoS parameters fails, the task orchestration network element can obtain the second priority QoS parameters of the first service and perform task orchestration until the orchestration result is obtained.

[0333] In one possible scenario, the above embodiments can be applied in combination. Alternatively, they can be applied independently.

[0334] In the application scenario described in the above embodiments, a possible exemplary process includes: the policy control function network element generates QoS parameters for a first service, further generates QoS parameters for a task, and sends the QoS parameters of the task to the anchor network element. The anchor network element can generate resource-level QoS parameters based on the obtained QoS parameters of the task and send them to the execution network element.

[0335] Assume the policy control function network element is the PCF network element. The unified data pool network element is the UDR network element. The application function network element is the AF (application function) network element. The task orchestration network element is the NAMO network element. Anchor network elements include TCF network elements and cNode. Execution network elements include TPF network elements, sNode, and UE. Each type of network element can have one or more elements.

[0336] Figure 8 is a schematic diagram of a possible exemplary process. As shown in Figure 8, this exemplary process includes the following steps:

[0337] S801, the AF network element inputs the service requirements information and the identification information of the first service to the PCF network element. The identification information includes at least one of the following: the use ID of the user who triggered the first service, the UE IP of the UE involved in the first service, the SDF information, and the ASP information of the first service.

[0338] For details on S801, please refer to the above introduction to S401, which will not be elaborated here.

[0339] Based on the input from the AF network element, the S802 and PCF network elements classify and merge data to generate a service QoS template, which is then passed to the UDR network element. The service QoS template contains a mapping relationship between the QoS parameters and identification information of the first service.

[0340] UDR network element stores the received service QoS template.

[0341] Optionally, each QoS class of the first service can be identified by a unique Service ID.

[0342] For details on S802, please refer to the above introduction to S402; it will not be elaborated upon here.

[0343] After a use case is input, the S803 and NAMO network elements request the corresponding first service QoS parameters from the UDR network element based on at least one of the following information in the use case: SDF information, ASP information, or UE information, or the service ID predefined by the operator. In one possible implementation, the NAMO network element requests the first priority service QoS parameters upon its initial request.

[0344] For details on S803, please refer to the above introduction to S701; it will not be elaborated upon here.

[0345] The S804 and NAMO network elements perform task orchestration based on the QoS parameters of the first priority service. If the orchestration performed by the NAMO network element based on the first priority service QoS parameters fails, it requests the second priority service QoS parameters from the UDR network element and continues orchestration until an orchestration result is obtained.

[0346] The S805 and NAMO network elements transmit the orchestration results to the TCF network elements and cNode. The orchestration results include task template descriptions and task dependencies. The task template descriptions may include the following information: task type, resource requirements, computational complexity, and runtime.

[0347] For details on S804-S805, please refer to the above introduction of S702, which will not be elaborated here.

[0348] Based on the orchestration results, the S806, TCF, and cNode network elements obtain task information and input the task information into the PCF network element.

[0349] The task information includes: the Service ID of the QoS parameters of the first service, the ID of the task obtained by the decomposition and mapping of the first service, the ID of the network element executing the task, and the task topology information.

[0350] For details on S806, please refer to the above introduction to S501; it will not be elaborated upon here.

[0351] S807 and PCF network elements decompose service QoS parameters into task QoS parameters, generate PCC rules, and input them to TCF network elements or cNodes.

[0352] The PCC rule includes rule ID, TDF detection, TDF template, 6QI, and QoS requirements.

[0353] The TDF detection and TDF template are used to characterize the mapping relationship between the TDF and the QoS parameters of the task. The task QoS parameters include 6QI and QoS requirement information. 6QI is an identifier indicating the specific QoS requirements, and the QoS requirement information is the specific QoS requirement.

[0354] For details on S807, please refer to the above introduction to S403; it will not be elaborated upon here.

[0355] Furthermore, the TCF network element or cNode completes the binding of task QoS parameters with task QoS flow according to PCC rules.

[0356] The S808, TCF network element, or cNode completes the mapping of task QoS parameters to resource-level QoS parameters and transmits the four-dimensional resource-level QoS parameters to the TPF, sNode, or UE. The resource-level QoS parameters transmitted to the UE can be included in a QoS rule. The resource-level QoS parameters transmitted to the TPF or sNode can be included in a QoS profile.

[0357] For details on S808, please refer to the above introduction to S502; it will not be elaborated upon here.

[0358] In the scenario where the above embodiments are combined and applied, another possible exemplary process includes: the policy control function network element sends the QoS parameters of the task to the anchor network element. The anchor network element generates resource-level QoS parameters based on the obtained task QoS parameters and sends them to the execution network element. The execution network element executes the task based on the resource-level QoS parameters.

[0359] Resource-level QoS parameters include four dimensions: connectivity, computation, data, and computation. The following sections will introduce possible exemplary processes for each dimension.

[0360] Assume the policy control function network element is the PCF network element. Anchor network elements include the TCF network element and the cNode. Execution network elements include the TPF network element, the sNode, and the UE. Each type of network element can be one or more.

[0361] Figure 9 is a schematic diagram of an exemplary process related to the connection dimension. As shown in Figure 9, this exemplary process includes the following steps:

[0362] S901, PCF network elements transmit PCC rules to TCF network elements or cNodes. Among them, the PCC rules include connection-related content including at least one of the following: TDF template (including the ID / IP of the network element executing at the transmission origin, the ID / IP of the network element executing at the transmission destination, and the transmission type), 6QI, and connection-related QoS requirements (such as GFBR / MFBR / ARP, etc.).

[0363] For details on S901, please refer to the above introduction to S403; it will not be elaborated upon here.

[0364] The S902, TCF network element, or cNode further breaks down the task QoS parameters into resource-level QoS parameters and sends them to the TPF network element, sNode, or UE.

[0365] Among the resource-level QoS parameters, the connection-level QoS parameters include PDR and QoS configuration / QoS rules (such as 6QI, ARP, GFBR / MFBR, etc.).

[0366] Optionally, the TCF network element or cNode can also send QoS enforcement rules (QERs) to the TPF network element, sNode, or UE. QERs indicate which set of QoS parameters to use under different circumstances. The TPF network element, sNode, or UE can select the QoS parameters to use based on the QERs.

[0367] Optionally, it may also include S903: If the TPF, sNode, or UE finds that the corresponding QoS requirements cannot be met when performing connection functions, it shall report to the TCF network element or cNode through a notification message.

[0368] Figure 10 is a schematic diagram of an exemplary process related to the computing dimension. The Computation Control (CC) module shown in Figure 10 is the module in the TCF network element or cNode responsible for managing the computing dimension resources for tasks. The Computation Execution (CE) module is the module in the TPF network element, sNode, or UE responsible for executing computing functions.

[0369] It is understood that the interaction diagram between the modules and network elements shown in Figure 10 is a logical interaction diagram given to facilitate understanding of the process, and does not represent the actual application of information transmission and reception by the modules shown in Figure 10.

[0370] As shown in Figure 10, this exemplary process includes the following steps:

[0371] S1001, PCF network elements transmit PCC rules to TCF network elements or cNodes. Among them, the PCC rules include at least one of the following computation-related contents: computing flow template (including the ID / IP of the network element performing the computing function, computing type), 6QI, and computing-related QoS requirements (such as GFLOPS / MFLOPS / ARP, etc.).

[0372] For details on S1001, please refer to the above introduction to S403; it will not be elaborated upon here.

[0373] S1002, TCF network element or cNode further breaks down the task QoS parameters into resource-level QoS parameters and sends them to TPF network element, sNode or UE.

[0374] Among the resource-level QoS parameters, the QoS parameters in the calculation dimension include CDR and QoS configuration / QoS rules (such as 6QI, ARP, GFLOPS or MFLOPS, etc.).

[0375] In one possible implementation, the QoS parameters of the computational dimension include 6QI, which can also be called 6QI-C.

[0376] In one possible implementation, the resource-level QoS parameters can be generated by the CC module in the TCF network element or the CC module in the cNode.

[0377] The S1003 and CE modules perform calculations based on the QoS parameters of the calculation dimension.

[0378] Specifically, the CE module in the TPF network element, sNode, or UE performs calculation functions based on the QoS parameters of the calculated latitude.

[0379] Optionally, the TCF network element or cNode can also send a QER to the TPF network element, sNode, or UE. The TPF network element, sNode, or UE can select the QoS parameters to use based on the QER.

[0380] Optionally, it may also include S1004: If the TPF, sNode, or UE finds that the corresponding QoS requirements cannot be met when performing calculation functions, it shall report to the TCF network element or cNode through a notification message.

[0381] Figure 11 is a schematic diagram of an exemplary process related to data dimensions. The Data Control (DC) module shown in Figure 11 is the module in the TCF network element or cNode responsible for managing data dimension resources. The CC module is described in Figure 10 above. The Algorithm Control (HicC) module is the module in the TCF network element or cNode responsible for managing algorithm dimension resources. The Data Execution (DA) module is the module in the TPF network element, sNode, or UE responsible for executing data functions. The CE module is described in Figure 10 above. The Algorithm Execution (HicA) module is the module in the TPF network element, sNode, or UE responsible for executing algorithm functions.

[0382] It is understood that the interaction diagram between the modules and network elements shown in Figure 11 is a logical interaction diagram given to facilitate understanding of the process, and does not represent the actual application of information transmission and reception by the modules shown in Figure 11.

[0383] As shown in Figure 11, this exemplary process includes the following steps:

[0384] S1101, PCF network elements transmit PCC rules to TCF network elements or cNodes. Among them, the PCC rules include at least one of the following data-related contents: data level template (including data type and data size), 6QI, and data-related QoS requirements (such as latency / ARP).

[0385] For details on S1101, please refer to the above introduction to S403; it will not be elaborated upon here.

[0386] S1102, the TCF network element, or the cNode (e.g., its DC module) further breaks down the task QoS parameters into resource-level QoS parameters and sends them to the TPF network element, sNode, or UE. Among the resource-level QoS parameters, the data-dimensional QoS parameters include DDR and data-related QoS requirements. In one possible implementation, the 6QI included in the data-dimensional QoS parameters can also be referred to as 6QI-D.

[0387] Depending on the circumstances, S1102 has two different implementations: S1102a and S1102b.

[0388] If the DA module is integrated (in addition to data functions, the DA also includes computing and algorithm functions), and the integrated functions of the DA module are sufficient to meet the QoS requirements included in the resource-level QoS parameters, then the exemplary process includes S1102a: the TCF network element or cNode directly passes the resource-level QoS parameters to the DA module.

[0389] If the DA module is non-integrated, or if the integrated computation and / or algorithm functions of the DA are insufficient to meet the QoS requirements included in the resource-level QoS parameters, then the exemplary process includes S1102b: The DC module in the TCF network element or cNode calls the computation and / or algorithm functions to the CC module and / or HicC module (i.e., calls the CE module and / or Hic A module), and passes the corresponding QoS parameters to the CC module and / or Hic C module. For example, the computation-level QoS parameters sent to the CC module can be included in the computation request message. The algorithm-level QoS parameters sent to the HicC module can be included in the algorithm request message.

[0390] Optionally, when the DC module calls the computing function to the CC module, it can also send the ID of the new network element performing the computing function, as well as the ID of the new computing subtask, to the CC module.

[0391] Optionally, when the DC module calls the algorithm function to the HicC module, the QoS parameters sent to the HicC module can be QoS parameters of a new algorithm dimension.

[0392] Optionally, it may also include S1103: The TPF network element, sNode, or UE requests data from the data storage function (DSF) network element, and correspondingly, the DSF network element feeds back the data. The DSF network element is responsible for storing data and / or models.

[0393] As shown in Figure 11, if the exemplary process includes S1102a, it also includes S1104a: the DA module performs data functions (e.g., data processing).

[0394] If the exemplary process includes S1102b, it also includes S1104b: the invoked CE module and / or HicA module, and the DA module perform data functions (e.g., data processing).

[0395] Optionally, it may also include S1105: If the TPF, sNode, or UE finds that the corresponding QoS requirements cannot be met when performing data functions, it shall report to the TCF network element or cNode through a notification message.

[0396] Figure 12 is a schematic diagram of an exemplary process related to the algorithm dimension. The DC module, CC module, HicC module, DA module, CE module, HicA module, or DSF network element shown in Figure 12 can be referenced in the above description of Figure 11.

[0397] It is understood that the interaction diagram between the modules and network elements shown in Figure 12 is a logical interaction diagram given to facilitate understanding of the process, and does not represent the actual application of information transmission and reception by the modules shown in Figure 12.

[0398] As shown in Figure 12, this exemplary process includes the following steps:

[0399] S1201, PCF network elements transmit PCC rules to TCF network elements or cNodes. Among them, the PCC rules include at least one of the following algorithm-related contents: model level template (including model type, model level and application method), 6QI, algorithm-related QoS requirements (such as training and inference latency, inference accuracy or ARP, etc.).

[0400] For details on S1201, please refer to the above introduction to S403; it will not be elaborated upon here.

[0401] The S1202, TCF network element, or cNode further breaks down the task QoS parameters into resource-level QoS parameters and sends them to the TPF network element, sNode, or UE. Among the resource-level QoS parameters, the algorithm-level QoS parameters include MDR and algorithm-related QoS requirements. In one possible implementation, the 6QI included in the algorithm-level QoS parameters can also be referred to as 6QI-M.

[0402] Depending on the circumstances, S1202 has two different implementations: S1202a and S1202b.

[0403] If the HicA module is integrated (in addition to algorithm functions, HicA also includes computing and data functions), and the integrated functions of the HicA module are sufficient to meet the QoS requirements included in the resource-level QoS parameters, then the exemplary process includes S1202a: the TCF network element or cNode directly transmits the resource-level QoS parameters to the HicA module.

[0404] If the HicA module is non-integrated, the exemplary process includes S1202b: The HicC module in the TCF network element or cNode calls the computation and / or data functions (i.e., calls the CE and / or DA modules) to the CC module and / or DC module, and passes the corresponding QoS parameters to the CC module and / or DC module. For example, the computation-dimensional QoS parameters sent to the CC module can be included in the computation request message. The data-dimensional QoS parameters sent to the DC module can be included in the data request message.

[0405] Optionally, when the HicC module calls the computing function to the CC module, it can also send the ID of the new network element performing the computing function, as well as the ID of the new computing subtask, to the CC module.

[0406] Optionally, when the HicC module calls the data function to the DC module, the QoS parameters sent to the DC module can be QoS parameters for a new data dimension.

[0407] Optionally, it may also include S1203: The TPF network element, sNode, or UE requests the model and data from the DSF network element, and correspondingly, the DSF network element returns the model and data. When the TPF network element, sNode, or UE obtains the model and data, no data plane preprocessing is required; they can obtain it directly.

[0408] As shown in Figure 12, if the exemplary process includes S1202a, it also includes S1204a: the HicA module performs algorithm functions (e.g., algorithm processing).

[0409] If the exemplary process includes S1202b, it also includes S1204b: the invoked CE module and / or DA module, and the HicA module perform algorithm functions (e.g., algorithm processing).

[0410] Optionally, it may also include S1205: If the TPF, sNode, or UE finds that the corresponding QoS requirements cannot be met when performing the algorithm function, it shall report to the TCF network element or cNode through a notification message.

[0411] In one possible scenario, multiple processes shown in Figures 8, 9, 10, 11, and 12 can be applied in combination. Alternatively, processes shown in Figures 8, 9, 10, 11, or 12 can also be applied independently.

[0412] Furthermore, the different network elements in the above embodiments can also form various end-to-end connection architectures. Figure 13 shows a possible end-to-end architecture applicable to the embodiments of this application. As shown in Figure 13, connected network elements can communicate with each other.

[0413] Based on the architecture shown in Figure 13, a possible QoS parameter generation mechanism could be:

[0414] The PCF network element can obtain information from the Charging Function (CHF) network element, the NWDAF network element, and the AF network element. The CHF network element can provide charging-related information. The NWDAF network element can provide statistical or predictive information for certain network functions or services. The AF network element can provide user ID, UE IP, media type, bandwidth requirements, ASP information, SDF information, the type of the first service (e.g., AI service, sensing service, computing service, or data service), and the requirements of the first service. Based on the information obtained, the PCF network element can generate service-level QoS parameters and store them in the UDR network element. After receiving the use case input from the AF network element, the NAMO network element can obtain the corresponding service-level QoS parameters from the UDR network element and perform task orchestration based on these parameters to obtain the orchestration result. The NAMO network element transmits the orchestration result to each TA (taking the TCF network element and cNode in Figure 13 as an example). The TCF network element and cNode obtain task information based on the orchestration result and provide this information to the PCF network element. Based on the task information, the PCF network element decomposes and maps the service-level QoS parameters to generate task-level QoS parameters, and then transmits the task-level QoS parameters to the TCF network element or cNode. Finally, the TCF network element and cNode determine the TE (taking the TPF network element, sNode, and UE in Figure 13 as an example) to execute the task, decompose and map the task-level QoS parameters to generate resource-level QoS parameters, and then transmit them to the corresponding TPF network element, sNode, or UE.

[0415] As can be seen, the communication method provided by the embodiments of this application can provide end-to-end QoS differentiation and guarantee services for new services in the communication network.

[0416] The above mainly describes the solutions provided by the embodiments of this application from the perspective of interaction between various network elements. Correspondingly, the embodiments of this application also provide a communication device for implementing the various methods described above. This communication device can be any of the network elements in the above method embodiments, or a device containing the aforementioned network elements, or a component usable by the aforementioned network elements. It is understood that, in order to achieve the above functions, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0417] This application embodiment can divide the communication device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be understood that the module division in this application embodiment is illustrative and is only a logical functional division. In actual implementation, there may be other division methods.

[0418] Figure 14 shows a schematic diagram of a communication device 1400. The communication device 1400 includes a processing module 1401 and a transceiver module 1402. Optionally, the communication device 1400 may also include a storage module 1403. The transceiver module 1402, also referred to as a transceiver unit, is used to implement transceiver functions; for example, it may be a transceiver circuit, transceiver, transceiver unit, or communication interface.

[0419] Taking the communication device 1400 as an example of the policy control function network element in the above embodiment, in one possible implementation:

[0420] The transceiver module 1402 is used to acquire task information and the requirement information of the first service; the task information includes relevant information of the task obtained from the decomposition and mapping of the first service. The processing module 1401 is used to generate QoS parameters for the first service based on the requirement information of the first service. The processing module 1401 is also used to generate QoS parameters for the task based on the task information and the QoS parameters of the first service.

[0421] Optionally, the transceiver module 1402 obtains the requirement information of the first service, including: obtaining relevant information of the first service, wherein the relevant information of the first service includes one or more of the following: the requirement information of the first service or the identification information of the first service, and there is a mapping relationship between the identification information of the first service and the requirement information of the first service.

[0422] Optionally, the processing module 1401 generates QoS parameters for the first service based on the requirements of the first service, including: generating a QoS template corresponding to the first service based on the relevant information of the first service, wherein the QoS template includes a mapping relationship between the QoS parameters of the first service and the identification information of the first service.

[0423] Optionally, the transceiver module 1402 is also used to send the QoS parameters of the first service to the unified data pool network element.

[0424] Optionally, the processing module 1401 generates QoS parameters for the task based on the task information and the QoS parameters of the first service, including: generating policies and charging control rules based on the task information and the QoS parameters of the first service. The policies and charging rules include the QoS parameters of the task and a mapping relationship between the QoS parameters of the task and at least one of the execution network element or task data stream.

[0425] Optionally, the transceiver module 1402 is further configured to send the QoS parameters of the task to the anchor network element, wherein the QoS parameters of the task are used by the anchor network element to generate resource-level QoS parameters. The resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computation dimension, data dimension, and algorithm dimension.

[0426] Taking the communication device 1400 as the anchor network element in the above embodiment as an example, in one possible implementation:

[0427] The transceiver module 1402 is used to acquire the QoS parameters of the task. The processing module 1401 is used to generate resource-level QoS parameters based on the QoS parameters of the task and the execution network element executing the task; the resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computation dimension, data dimension, and algorithm dimension. The transceiver module 1402 is also used to send the resource-level QoS parameters to the execution network element.

[0428] Optionally, the transceiver module 1402 is further configured to obtain the orchestration result of the task, the orchestration result including the template description information and dependencies of the task. The processing module 1401 is further configured to obtain task information based on the orchestration result, the task information including at least one of the task deployment information or topology information.

[0429] Optionally, the transceiver module 1402 is also used to send task information to the policy control function network element, the task information being used by the policy control function network element to generate QoS parameters for the task.

[0430] Optionally, the transceiver module 1402 acquires the QoS parameters of the task, including: acquiring policy and charging control rules, the policy and charging rules including the QoS parameters of the task, and the mapping relationship between the QoS parameters of the task and at least one of the execution network element or the task data stream.

[0431] Optionally, the transceiver module 1402 is also configured to receive notification information from the execution network element, the notification information being used to notify the execution network element that it cannot meet the QoS requirements related to connectivity, computing, data, or algorithms.

[0432] Taking the communication device 1400 as an example of the execution network element in the above embodiment, in one possible implementation:

[0433] The transceiver module 1402 is used to acquire resource-level QoS parameters; the resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computation dimension, data dimension, or algorithm dimension. The processing module 1401 is used to execute tasks based on the resource-level QoS parameters.

[0434] Optionally, the transceiver module 1402 is also used to send notification information to the anchor network element, the notification information being used to notify the execution network element that it cannot meet the QoS requirements related to connectivity, computing, data, or algorithms.

[0435] Taking the communication device 1400 as an example of the task orchestration network element in the above embodiments, in one possible implementation:

[0436] The transceiver module 1402 is used to obtain the QoS parameters of the first service. The processing module 1401 is used to perform task orchestration based on the QoS parameters of the first service to obtain orchestration results at the task level; the orchestration results include template description information and dependencies of the tasks obtained from the decomposition and mapping of the first service.

[0437] The transceiver module 1402 is used to obtain the QoS parameters of the first service. The processing module 1401 is used to perform task orchestration based on the QoS parameters of the first service to obtain orchestration results at the task level; the orchestration results include template description information and dependencies of the tasks obtained from the decomposition and mapping of the first service.

[0438] Optionally, the transceiver module 1402 is also used to send orchestration results to the anchor network element. The orchestration results are used by the anchor network element to obtain task information, which includes at least one of the task deployment information or topology information.

[0439] Optionally, the transceiver module 1402 obtains the QoS parameters of the first service, including: obtaining the QoS template corresponding to the first service, wherein the QoS template includes a mapping relationship between the QoS parameters of the first service and the identification information of the first service.

[0440] Optionally, the transceiver module 1402 obtains the QoS parameters of the first service, including obtaining the QoS parameters of the first service with a first priority. The processing module 1401 performs task orchestration based on the QoS parameters of the first service, including performing task orchestration based on the QoS parameters of the first priority. If the orchestration based on the QoS parameters of the first priority fails, the transceiver module 1402 is further configured to obtain the QoS parameters of the first service with a second priority, and the processing module 1401 is further configured to perform task orchestration based on the QoS parameters of the second priority.

[0441] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0442] Alternatively, the modules in Figure 14 can also be referred to as units. For example, a processing module can be called a processing unit, and a transceiver module can be called a transceiver unit. Furthermore, in the embodiment shown in Figure 14, the names of the various units may not be those shown in the figure. For example, a transceiver module can also be called a communication module or a communication unit.

[0443] If the units in Figure 14 are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. Storage media for storing computer software products include: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0444] In this embodiment, the communication device 1400 is presented in an integrated manner, divided into various functional modules. Here, "module" may refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory that executes one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the above-mentioned functions.

[0445] In a simple embodiment, those skilled in the art will realize that the communication device 1400 can take the form of the communication device shown in FIG15.

[0446] As shown in Figure 15, the communication device 1500 includes one or more processors 1501, a communication line 1502, and at least one communication interface (Figure 15 is only an example illustrating the inclusion of a communication interface 1504 and a processor 1501), and optionally may also include a memory 1503.

[0447] The processor 1501 may be a general-purpose central processing unit (CPU), a microprocessor, an ASIC, or one or more integrated circuits used to control the execution of programs according to the present application.

[0448] The communication line 1502 may include a path for connecting different components.

[0449] The communication interface 1504 can be a transceiver module used to communicate with other devices or communication networks, such as Ethernet, RAN, terminals, and wireless local area networks (WLAN). For example, the transceiver module can be a transceiver or similar device. Optionally, the communication interface 1504 can also be a transceiver circuit or input / output interface located within the processor 1501, used to implement signal input and signal output for the processor.

[0450] The memory 1503 can be a device with storage functionality. For example, it can be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions; random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage; optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory can exist independently and be connected to the processor via communication line 1502. The memory can also be integrated with the processor.

[0451] The memory 1503 stores computer execution instructions for implementing the scheme of this application, and its execution is controlled by the processor 1501. The processor 1501 executes the computer execution instructions stored in the memory 1503, thereby implementing the communication method provided in the embodiments of this application.

[0452] Alternatively, in this embodiment, the processor 1501 may execute the processing-related functions of the communication method provided in the following embodiments of this application, and the communication interface 1504 may be responsible for communicating with other devices or communication networks. This embodiment does not specifically limit this.

[0453] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0454] In a specific implementation, as one example, processor 1501 may include one or more CPUs, such as CPU0 and CPU1 in FIG15.

[0455] In a specific implementation, as one embodiment, the communication device 1500 may include multiple processors, such as processors 1501 and 1507 in FIG. 15. Each of these processors may be a single-core processor or a multi-core processor. The processors here may include, but are not limited to, at least one of the following: CPU, microprocessor, digital signal processing (DSP) processor, microcontroller unit (MCU), or artificial intelligence processor, etc., various computing devices that run software, and each computing device may include one or more cores for executing software instructions to perform calculations or processing.

[0456] In a specific implementation, as one embodiment, the communication device 1500 may further include an output device 1505 and an input device 1506. The output device 1505 communicates with the processor 1501 and can display information in various ways. For example, the output device 1505 may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 1506 communicates with the processor 1501 and can receive user input in various ways. For example, the input device 1506 may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0457] The aforementioned communication device 1500 may sometimes be referred to as a communication equipment, which can be a general-purpose device or a special-purpose device. For example, the communication device 1500 may be a terminal device, an access network device, or a device with a similar structure to that in Figure 15, as described above. The embodiments of this application do not limit the type of the communication device 1500.

[0458] Furthermore, the composition shown in FIG15 does not constitute a limitation on the communication device. In addition to the components shown in FIG15, the communication device 1500 may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0459] Optionally, the functions / implementation processes of the transceiver module 1402 and processing module 1401 in FIG14 can be implemented by the processor 1501 in the communication device 1500 shown in FIG15 calling computer execution instructions stored in the memory 1503. Alternatively, the functions / implementation processes of the processing module 1401 in FIG14 can be implemented by the processor 1501 in the communication device 1500 shown in FIG15 calling computer execution instructions stored in the memory 1503, and the functions / implementation processes of the transceiver module 1402 in FIG14 can be implemented by the communication interface 1504 in the communication device 1500 shown in FIG15.

[0460] It should be understood that one or more of the above modules or units can be implemented by software, hardware, or a combination of both. When any of the above modules or units are implemented by software, the software exists as computer program instructions and is stored in memory. The processor can be used to execute the program instructions and implement the above method flow. The processor can be built into a SoC or ASIC, or it can be a separate semiconductor chip. In addition to the core that executes the software instructions for computation or processing, the processor may further include necessary hardware accelerators, such as FPGAs, programmable logic devices (PLDs), or logic circuits that implement dedicated logic operations.

[0461] When the above modules or units are implemented in hardware, the hardware can be any one or any combination of a CPU, microprocessor, DSP chip, MCU, artificial intelligence processor, ASIC, SoC, FPGA, PLD, dedicated digital circuit, hardware accelerator or non-integrated discrete device, which can run the necessary software or perform the above method flow independently of software.

[0462] Optionally, embodiments of this application also provide a communication device (e.g., the communication device may be a chip or a chip system), which includes a processor for implementing the methods in any of the above method embodiments. In one possible design, the communication device further includes a memory. The memory is used to store necessary program instructions and data, and the processor can call the program code stored in the memory to instruct the communication device to execute the methods in any of the above method embodiments. Of course, the memory may not be included in the communication device. When the communication device is a chip system, it may be composed of chips or may include chips and other discrete devices; embodiments of this application do not specifically limit this.

[0463] Optionally, embodiments of this application also provide a computer-readable storage medium storing a computer program or instructions that, when run on a communication device, enable the communication device to execute the methods described in any of the above method embodiments or any implementation thereof.

[0464] Optionally, embodiments of this application also provide a communication system, which includes the network device and the terminal device described in the above method embodiments.

[0465] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0466] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0467] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of the application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Thus, if such modifications and modifications fall within the scope of the claims and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A communication method characterized by comprising: The method includes: Obtain task information and the requirements information of the first service; the task information includes relevant information of the task obtained by the decomposition and mapping of the first service; Based on the requirements of the first service, generate the QoS parameters for the first service; The QoS parameters for the task are generated based on the task information and the QoS parameters of the first service.

2. The method of claim 1, wherein, The step of obtaining the request information for the first service includes: Obtain relevant information about the first service, which includes one or more of the following: the requirement information of the first service or the identification information of the first service, wherein there is a mapping relationship between the identification information of the first service and the requirement information of the first service.

3. The method of claim 2, wherein, The identification information of the first service includes at least one of the following: information about the user who triggered the first service, information about the terminal device involved in the first service, or information about the application service provider.

4. The method according to claim 2 or 3, characterized in that, The step of generating QoS parameters for the first service based on the request information of the first service includes: Based on the relevant information of the first service, a QoS template corresponding to the first service is generated. The QoS template includes the mapping relationship between the QoS parameters of the first service and the identification information of the first service.

5. The method according to any one of claims 1 to 4, characterized in that, The QoS parameters of the first service include multiple sets of QoS parameters, each with a different priority.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Send the QoS parameters of the first service to the unified data pool network element.

7. The method according to any one of claims 1 to 6, characterized in that, The task information includes at least one of the task's deployment information or topology information.

8. The method according to any one of claims 1 to 7, characterized in that, The step of generating the QoS parameters for the task based on the task information and the QoS parameters of the first service includes: Based on the task information and the QoS parameters of the first service, a policy and charging control rule are generated. The policy and charging rule includes the QoS parameters of the task and a mapping relationship between the QoS parameters of the task and at least one of the execution network element or task data stream executing the task.

9. The method of claim 8, wherein, The strategy and billing rules include at least one of the following: QoS specific requirements information related to connection, an identifier indicating the QoS specific requirements related to connection, information of the network element executing the starting point of the service data flow of the task, information of the network element executing the ending point of the service data flow of the task, QoS specific requirements information related to computation, an identifier indicating the QoS specific requirements related to computation, information of the network element executing the computation function, an identifier of the computation subtask, the computation type of the computation subtask, QoS specific requirements information related to data, an identifier indicating the QoS specific requirements related to data, data type, data size, QoS specific requirements information related to algorithm, an identifier indicating the QoS specific requirements related to the algorithm, algorithm type, algorithm level, and application method.

10. The method of claim 9, wherein, The strategy and billing rules also include the type of business data flow for the task, which includes computation, data, or algorithm types.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: The QoS parameters of the task are sent to the anchor network element; the QoS parameters of the task are used by the anchor network element to generate resource-level QoS parameters, and the resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computing dimension, data dimension, and algorithm dimension.

12. A communication method characterized by comprising: The method includes: Obtain the Quality of Service (QoS) parameters for the task; Based on the QoS parameters of the task and the network element executing the task, resource-level QoS parameters are generated; the resource-level QoS parameters include at least one of the following: connection dimension, computation dimension, data dimension, and algorithm dimension. Send the resource-level QoS parameters to the execution network element.

13. The method of claim 12, wherein, The task is obtained by decomposing and mapping the first service, and the QoS parameters of the task are obtained based on the QoS parameters of the first service.

14. The method according to claim 12 or 13, characterized in that, The Quality of Service (QoS) parameters for the task being acquired include: The policy and charging control rules are obtained, including the QoS parameters of the task and the mapping relationship between the QoS parameters of the task and at least one of the execution network element or task data stream that executes the task.

15. The method of claim 14, wherein, The strategy and billing rules include at least one of the following: QoS specific requirements information related to connection, an identifier indicating the QoS specific requirements related to connection, information of the network element executing the starting point of the service data flow of the task, information of the network element executing the ending point of the service data flow of the task, QoS specific requirements information related to computation, an identifier indicating the QoS specific requirements related to computation, information of the network element executing the computation function, an identifier of the computation subtask, the computation type of the computation subtask, QoS specific requirements information related to data, an identifier indicating the QoS specific requirements related to data, data type, data size, QoS specific requirements information related to algorithm, an identifier indicating the QoS specific requirements related to the algorithm, algorithm type, algorithm level, and application method.

16. The method of claim 15, wherein, The strategy and billing rules also include the type of business data flow for the task, which includes computation, data, or algorithm types.

17. The method according to claim 15 or 16, characterized in that, The QoS parameters for the connection dimension include at least one of the following: the connection-related QoS specific requirement information, the identifier indicating the connection-related QoS specific requirements, and a packet identification rule; wherein the packet identification rule is used to distinguish service data streams corresponding to different QoS requirements; and / or, The QoS parameters for the computation dimension include at least one of the following: the specific QoS requirement information related to computation, the identifier indicating the specific QoS requirements related to computation, and the computation subtask identification rule; wherein the computation subtask identification rule is used to distinguish computation subtasks corresponding to different QoS requirements; and / or, The QoS parameters of the data dimension include at least one of the following: the specific QoS requirement information related to the data, the identifier indicating the specific QoS requirement related to the data, and the data subtask identification rule; wherein the data subtask identification rule is used to distinguish data subtasks corresponding to different QoS requirements; and / or, The QoS parameters of the algorithm dimension include at least one of the following: the specific QoS requirement information related to the algorithm, the identifier indicating the specific QoS requirement related to the algorithm, and the algorithm subtask identification rule; wherein, the algorithm subtask identification rule is used to distinguish algorithm subtasks corresponding to different QoS requirements.

18. The method according to any one of claims 12-17, characterized by, The method further includes: The system receives a notification from the execution network element, which is used to notify the execution network element that it cannot meet the QoS requirements related to connectivity, computing, data, or algorithms.

19. A method of communication, comprising: The method includes: Obtain resource-level Quality of Service (QoS) parameters; the resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computation dimension, data dimension, or algorithm dimension; The task is executed based on the resource-level QoS parameters.

20. The method of claim 19, wherein, The resource-level QoS parameters are obtained based on the task's QoS parameters, wherein the task is obtained by decomposing and mapping the first service, and the task's QoS parameters are obtained based on the first service's QoS parameters.

21. The method of claim 19 or 20, wherein, The QoS parameters for the connection dimension include at least one of the following: the connection-related QoS specific requirement information, the identifier indicating the connection-related QoS specific requirements, and a packet identification rule; wherein the packet identification rule is used to distinguish service data streams corresponding to different QoS requirements; and / or, The QoS parameters of the computation dimension include at least one of the following: the specific QoS requirement information related to computation, the identifier indicating the specific QoS requirements related to computation, and the computation subtask identification rule; wherein, the computation subtask identification rule is used to distinguish computation subtasks corresponding to different QoS requirements; and / or, The QoS parameters of the data dimension include at least one of the following: the specific QoS requirement information related to the data, the identifier indicating the specific QoS requirement related to the data, and the data subtask identification rule; wherein the data subtask identification rule is used to distinguish data subtasks corresponding to different QoS requirements; and / or, The QoS parameters of the algorithm dimension include at least one of the following: the specific QoS requirement information related to the algorithm, the identifier indicating the specific QoS requirement related to the algorithm, and the algorithm subtask identification rule; wherein, the algorithm subtask identification rule is used to distinguish algorithm subtasks corresponding to different QoS requirements.

22. The method of any one of claims 19-21, wherein, The execution network element is a terminal device.

23. The method of any one of claims 1-22, wherein, The first service is an artificial intelligence (AI) service, a computing service, a data service, or a perception service.

24. A method of communication, comprising: The method includes: Obtain the Quality of Service (QoS) parameters for the first service; Task orchestration is performed based on the QoS parameters of the first service to obtain orchestration results. The orchestration results include template description information and dependencies of the tasks obtained from the decomposition and mapping of the first service.

25. The method of claim 24, wherein, The method further includes: The orchestration result is sent to the anchor network element, and the orchestration result is used by the anchor network element to obtain task information, the task information including at least one of the task's deployment information or topology information.

26. The method of claim 24 or 25, wherein, The process of obtaining the QoS parameters of the first service includes: Obtain the QoS template corresponding to the first service, wherein the QoS template includes a mapping relationship between the QoS parameters of the first service and the identification information of the first service.

27. The method of any one of claims 24-26, wherein, The QoS parameters of the first service include multiple sets of QoS parameters, each with a different priority.

28. The method of any one of claims 24-27, wherein, The step of obtaining the QoS parameters of the first service and performing task orchestration based on the QoS parameters of the first service includes: Obtain the QoS parameters of the first priority of the first service, and perform task orchestration based on the QoS parameters of the first priority.

29. The method of claim 28, wherein, The method further includes: If orchestration based on the first priority QoS parameters fails, the second priority QoS parameters of the first service are obtained, and task orchestration is performed based on the second priority QoS parameters.

30. A policy control function network element, characterized by, The policy control function network element includes a module or unit for performing the method according to any one of claims 1-11.

31. An anchor network element, characterized by The anchor point network element includes a module or unit for performing the method according to any one of claims 12-18.

32. An execution network element, characterized by The execution network element includes a module or unit for executing the method of any one of claims 19-23.

33. A task orchestration network element, the task orchestration network element comprising: The task orchestration network element includes modules or units for performing the method of any one of claims 24-29.

34. A communications device, characterized by The communication device includes a processor; the processor is configured to execute a computer program or instructions stored in a memory to cause the communication device to perform the method as described in any one of claims 1-11, 12-18, 19-23, or 24-29.

35. A chip system, characterized by include: Processor and interface circuitry; The interface circuit is used to receive computer execution instructions and transmit them to the processor; The processor is configured to execute the computer execution instructions to cause the communication device to perform the method as described in any one of claims 1-11, 12-18, 19-23, or 24-29.

36. A computer readable storage medium, characterized in that, It stores computer programs or instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1-11, 12-18, 19-23, or 24-29.

37. A computer program product, characterised in that, The computer program product includes instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1-11, 12-18, 19-23, or 24-29.

38. A communication system, characterized by The communication system includes a policy control function network element, an anchor point network element, and an execution network element; The policy control function network element is used to acquire task information and requirement information of the first service, generate QoS parameters for the first service based on the requirement information of the first service, generate QoS parameters for the task based on the task information and the QoS parameters of the first service, and send the QoS parameters of the task to the anchor network element; wherein, the task information includes relevant information of the task obtained by the decomposition and mapping of the first service. The anchor network element is used to receive QoS parameters of the task from the policy control function network element, and to execute the task according to the specified parameters. The network element executing the task generates resource-level QoS parameters and sends the resource-level QoS parameters to the network element; the resource-level QoS parameters include at least one of the following: connection dimension, computation dimension, data dimension, and algorithm dimension; The execution network element is used to receive the resource-level QoS parameters from the anchor network element and execute tasks according to the resource-level QoS parameters.

39. The method of claim 38, wherein, The strategy control function network element is also used to execute the method of any one of claims 2-11, the anchor point network element is also used to execute the method of any one of claims 13-18, and the execution network element is also used to execute the method of any one of claims 20-23.

40. The method of claim 38 or 39, wherein, The communication system further includes a task orchestration network element, which is used to execute the method of any one of claims 24-29.

Images