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 method, device and system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 13, 2023, with application number 202311515280.5 and application name “Communication Methods, Devices and Systems”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technologies, and in particular to communication methods, devices, and systems. Background Art

[0003] With the advancement of communication technology, new services are being considered for introduction into wireless communication networks, such as those involving artificial intelligence (AI) and perception services. To support these new services, networks must efficiently coordinate heterogeneous resources across multiple dimensions, including connectivity, computing, data, and models (or algorithms). However, the quality of service (QoS) mechanism in fifth-generation (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, how to ensure the service quality of new services introduced into wireless communication networks is an urgent problem to be solved.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide a communication method, apparatus, and system that can support the generation of QoS policies for new services in a wireless communication network to ensure the service quality of multiple services.

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

[0008] In the first aspect, a communication method is provided. The method can be executed by a policy control function network element, or by a component of the policy control function network element (such as a processor, a chip, or a chip system, etc.), or by a logic module or software that can realize all or part of the functions of the policy control function network element. The following description takes the policy control function network element as an example of the execution subject of the method. The method includes: the policy control function network element obtains task information and requirement information of the first service; the task information includes relevant information of the task obtained by decomposing and mapping 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 the present application, the policy control function network element can generate service-level QoS parameters and further generate task-level QoS parameters, which are applicable to communication networks managed at a task granularity to ensure the quality of service of the first service. Therefore, the communication method provided in the embodiments of the present 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 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 solution, 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 of a user who triggers the first service, information of a terminal device related to the first service, or information of an application service provider.

[0013] This solution provides identification information of a variety of first 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 solution, 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 of the first service include multiple sets of QoS parameters, where each set of QoS parameters has a different priority.

[0017] Based on this solution, a set of QoS parameters for actual application can be flexibly selected 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 QoS parameters of the first service to the unified data pool network element.

[0019] Based on this solution, the policy control function network element can store the QoS parameters of the first service in the unified data pool network element, so as to facilitate reading by the policy control function network element or other network elements.

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

[0021] Based on this solution, 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 the QoS parameters of the task based on the task information and the QoS parameters of the first service, including: the policy control function network element generates policy and charging control rules based on the task information and the QoS parameters of the first service. The policy 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 an execution network element that executes the task or a task data flow.

[0023] Based on this solution, the policy control function network element can bind the task QoS parameters to at least one of the execution network element or the task data flow while generating the task QoS parameters, thereby facilitating QoS management.

[0024] In one possible design, the policies and charging rules include at least one of the following: specific QoS requirement information related to the connection, an identifier indicating the specific QoS requirement related to the connection, information about the network element executing the transmission starting point of the task's business data flow, and information about the network element executing the transmission end point of the task's business data flow.

[0025] Based on this solution, connection-related content that may be included in policies and charging rules is provided, so that QoS management can be performed on the connection dimension of the task based on the policies and charging rules.

[0026] In one possible design, the policy and charging rules also include the type of business data flow of the task, and the type of business data flow includes calculation, data or algorithm type.

[0027] Based on this solution, the business data flows of tasks can also be divided into different types according to the multiple dimensions involved in the tasks, so as to facilitate QoS management of the business data flows of tasks according to the types.

[0028] In one possible design, the policies and charging rules include at least one of the following: specific QoS requirement information related to computing, an identifier indicating specific QoS requirements related to computing, information of an execution network element used to perform computing functions, an identifier of a computing subtask, and a computing type of the computing subtask.

[0029] Based on this solution, the computing-related content that may be included in the policy and charging rules is provided, so that QoS management can be performed on the computing dimension of the task based on the policy and charging rules.

[0030] In one possible design, the policy and charging rules 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, a data type, and a data size.

[0031] Based on this solution, data-related content that may be included in policies and charging rules is provided, so that QoS management can be performed on the data dimension of the task based on the policies and charging rules.

[0032] In one possible design, the policy and charging rules include at least one of the following: specific QoS requirement information related to the algorithm, an identifier indicating the specific QoS 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 may be included in the policy and charging rules is provided, so that QoS management can be performed on the algorithm dimension of the task based on the policy and charging rules.

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

[0035] Based on this solution, the anchor network element can obtain the QoS parameters of the task and further generate resource-level QoS parameters, so that the anchor network element can directly perform QoS management on the four-dimensional resources based on the resource-level QoS parameters.

[0036] On the second aspect, a communication method is provided, which can be executed by an anchor network element, or by a component of the anchor network element (such as a processor, chip, or chip system, etc.), or by a logic module or software that can implement all or part of the functions of the anchor network element. The following is an illustration of the method using the anchor network element as the execution subject, and the method includes: the anchor network element obtains the QoS parameters of the task, and generates resource-level QoS parameters based on the QoS parameters of the task and the execution network element that executes the task. The resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computing dimension, data dimension, and algorithm dimension. The anchor network element sends the resource-level QoS parameters to the execution network element.

[0037] Based on the communication method provided in the embodiments of the present application, the anchor network element can generate resource-level QoS parameters including four dimensions, thereby enabling direct QoS management of the four dimensions, which is suitable for new services in the communication network that require the coordination of four-dimensional resources. Therefore, the communication method provided in the embodiments of the present application supports the generation of QoS policies for new services in the communication network.

[0038] In a possible design, the task is obtained by decomposing and mapping the first service, and the QoS parameters of the task are obtained according to the QoS parameters of the first service.

[0039] Based on this solution, decomposition 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 obtaining an orchestration result of the task, the orchestration result including template description information and dependency relationships of the task. The anchor network element obtains task information based on the orchestration result, the task information including at least one of deployment information or topology information of the task.

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

[0042] Based on this solution, 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 generates QoS parameters for the task.

[0043] In one possible design, the anchor network element obtains the quality of service QoS parameters of the task, including: the anchor network element obtains the policy and billing control rules, the policy and billing rules include the QoS parameters of the task, and the mapping relationship between the QoS parameters of the task and the execution network element that executes the task or at least one item in the task data flow.

[0044] Based on this solution, 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 task data flow, so that the anchor network element can generate resource-level QoS parameters according to the mapping relationship.

[0045] In one possible design, the policies and charging rules include at least one of the following: specific QoS requirement information related to the connection, an identifier indicating the specific QoS requirement related to the connection, information about the network element executing the transmission starting point of the task's business data flow, and information about the network element executing the transmission end point of the task's business data flow.

[0046] Based on this solution, connection-related content that may be included in policy and charging rules is provided, so that the anchor network element can generate connection-dimensional QoS parameters based on the policy and charging rules.

[0047] In one possible design, the policy and charging rules also include the type of business data flow of the task, and the type of business data flow includes calculation, data or algorithm type.

[0048] Based on this solution, the business data flows of tasks can also be divided into different types according to the multiple dimensions involved in the tasks, so as to facilitate QoS management of the business data flows of tasks according to the types.

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

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

[0051] In one possible design, the policies and charging rules include at least one of the following: specific QoS requirement information related to computing, an identifier indicating specific QoS requirements related to computing, information of an execution network element used to perform computing functions, an identifier of a computing subtask, and a computing type of the computing subtask.

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

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

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

[0055] In one possible design, the policy and charging rules 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, a data type, and a data size.

[0056] Based on this solution, data-related content that may be included in policies and charging rules is provided, so that the anchor network element can generate data-dimensional QoS parameters based on policies and charging rules.

[0057] In one possible design, the QoS parameters of the data dimension include at least one of the following: specific QoS requirement information related to the data, an identifier indicating the specific QoS requirements 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 the QoS parameters of the data dimension are provided, and the QoS management of the data dimension can be performed based on the QoS parameters of the data dimension.

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

[0060] Based on this solution, the algorithm-related content that may be included in the policy and charging rules is provided, so that the anchor network element can generate algorithm-dimensional QoS parameters based on the policy and charging rules.

[0061] In one possible design, the QoS parameters of the algorithm dimension 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, and an algorithm subtask identification rule; wherein the algorithm subtask identification rule is used to distinguish algorithm subtasks corresponding to different QoS requirements.

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

[0063] In one possible design, the method further includes: the anchor network element receiving notification information from the execution network element, where the notification information is used to notify the execution network element that QoS requirements related to connection, calculation, data or algorithm cannot be met.

[0064] Based on this solution, the anchor NE can determine which execution NE cannot meet the corresponding QoS requirement based on the notification of the execution NE, and thus can adjust the policy in a targeted manner to ensure that the QoS requirement can be met.

[0065] On the third aspect, a communication method is provided. The method can be executed by an executing network element, or by a component of the executing network element (such as a processor, chip, or chip system, etc.), or by a logic module or software that can realize all or part of the functions of the executing network element. The following is an example of an executing entity of the method, in which the executing network element is used as an example. The method includes: the executing network element obtains resource-level QoS parameters; the resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, computing dimension, data dimension, and algorithm dimension. The executing network element executes the task according to the resource-level QoS parameters.

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

[0067] In a possible design, resource-level QoS parameters are obtained based on task QoS parameters, wherein the task is obtained by decomposing and mapping the first service, and the task QoS parameters are obtained based on the QoS parameters of the first service.

[0068] Based on this solution, decomposition 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: specific QoS requirement information related to the connection, an identifier indicating the specific QoS requirements related to the connection, and a packet identification rule; wherein the packet identification rule is used to distinguish service data flows corresponding to different QoS requirements.

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

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

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

[0073] In one possible design, the QoS parameters of the data dimension include at least one of the following: specific QoS requirement information related to the data, an identifier indicating the specific QoS requirements 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, data-related content that may be included in policies and charging rules is provided, so that the anchor network element can generate data-dimensional QoS parameters based on policies and charging rules.

[0075] In one possible design, the QoS parameters of the algorithm dimension 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, and an algorithm subtask identification rule; wherein the algorithm subtask identification rule is used to distinguish algorithm subtasks corresponding to different QoS requirements.

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

[0077] In one possible design, the method further includes: the executing network element sending a notification message to the anchor network element, where the notification message is used to notify the executing network element that QoS requirements related to connection, calculation, data or algorithm cannot be met.

[0078] Based on this solution, 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 the policy in a targeted manner.

[0079] In a fourth aspect, a communication method is provided, which can be executed by a task orchestration network element, or by a component of the task orchestration network element (such as a processor, chip, or chip system, etc.), or by a logic module or software that can implement all or part of the functions of the task orchestration network element. The following is an example of an execution subject of the method using the task orchestration network element as an example. The method includes: the task orchestration network element obtains the QoS parameters of the first service. The task orchestration network element performs task orchestration based on the QoS parameters of the first service and obtains an orchestration result with task as the granularity; the orchestration result includes the template description information and dependency relationship of the task obtained by decomposing and mapping the first service.

[0080] Based on the communication method provided in the embodiment of the present application, the task orchestration network element can orchestrate the tasks obtained by decomposing and mapping the first service to obtain an orchestration result with task granularity, which is suitable for orchestrating tasks for new services in the communication network, especially complex new services, to achieve QoS hierarchical management from services to tasks.

[0081] In one possible design, the method further includes: the task orchestration network element sends an orchestration result to the anchor network element, and the orchestration result is used by the anchor network element to obtain task information, where the task information includes at least one of deployment information or topology information of the task.

[0082] Based on this solution, the task orchestration NE can send task information to the anchor NE, and the task information can assist the anchor NE in performing task-granular QoS management.

[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 a QoS template corresponding to the first service, the QoS template including a mapping relationship between the QoS parameters of the first service and identification information of the first service.

[0084] Based on this solution, 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 based on the mapping relationship.

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

[0086] Based on this solution, a set of QoS parameters for actual application can be flexibly selected according to the priority of each set of QoS parameters.

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

[0088] Based on this solution, the task scheduling network element can first schedule tasks according to the QoS parameters of the first priority. If the scheduling fails, it can try scheduling again according to the QoS parameters of the second priority, avoiding the situation where no scheduling results are obtained due to the failure of the initial scheduling.

[0089] In a fifth aspect, a communication device is provided for implementing the various methods described above. The communication device includes modules, units, or means corresponding to the methods described above. The modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software implementations. 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, which may also be referred to as a transceiver unit, is configured to implement the sending and / or receiving functions described in the first, second, third, or fourth aspects and any possible implementations thereof. The transceiver module may be comprised of a transceiver circuit, a transceiver, a transceiver, or a communication interface. The processing module may be configured to implement the processing functions described in 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 respectively used to implement the sending and receiving functions in the above-mentioned first aspect, second aspect, third aspect or fourth aspect and any possible implementation methods.

[0092] In a sixth aspect, a communication device is provided, comprising: a processor and a communication interface; the communication interface is used to communicate with a module outside the communication device; the processor is used to execute a computer program or instruction so that the communication device executes any of the methods described above.

[0093] In a seventh aspect, a communication device is provided, comprising: at least one processor; the processor is configured to execute a computer program or instruction stored in a memory, so that the communication device performs the method of any of the above aspects. In one possible implementation, the memory may be coupled to the processor, or may be independent of the processor. In another possible implementation, the communication device further includes the memory. Optionally, the memory and the processor are integrated.

[0094] In aspects 5 to 7, the communication device may be the policy control function network element in the first aspect or any implementation of the first aspect, or a device including 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 the anchor network element in the second aspect or any implementation of the second aspect, or a device including the anchor network element, or a device included in the anchor function network element, such as a chip. Alternatively, the communication device may be the execution network element in the third aspect or any implementation of the third aspect, or a device including the execution network element, or a device included in the execution network element, such as a chip. Alternatively, the communication device may be the task orchestration network element in the fourth aspect or any implementation of the fourth aspect, or a device including the task orchestration network element, or a device included in the task orchestration network element, such as a chip or a chip system.

[0095] In an eighth aspect, a computer-readable storage medium is provided, which stores a computer program or instruction. When the computer program or instruction is run on a communication device, the communication device can execute any of the above aspects or any of its implementation methods.

[0096] In a ninth aspect, a computer program product comprising instructions is provided, which, when executed on a communication device, enables the communication device to execute the method of any of the above aspects or any of its implementations.

[0097] In a tenth aspect, a communication device is provided (for example, the communication device may be a chip or a chip system), which includes a processor for implementing the functions involved in any of the above aspects or any of its implementation methods.

[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 a chip, or it can also include a chip and other discrete devices.

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

[0101] Among them, the technical effects brought about by any implementation method of the fifth to tenth aspects can refer to the technical effects brought about by the corresponding implementation methods of the first to fourth aspects, and will not be repeated here.

[0102] It should be noted that various possible implementations of any of the above aspects can be combined under the premise that there is no contradiction between the solutions.

[0103] In the eleventh aspect, a communication system is provided, which includes a policy control function network element that executes the method of the first aspect, an anchor network element that executes the method of the second aspect, and an execution network element that executes the method of the third aspect.

[0104] In some possible designs, the communication system may also include a task orchestration network element that executes the above-mentioned fourth aspect method. BRIEF DESCRIPTION OF THE DRAWINGS

[0105] FIG1 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

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

[0107] FIG3 is a schematic diagram of a protocol stack provided in an embodiment of the present application;

[0108] FIG4 is a schematic diagram of a communication method provided in an embodiment of the present application;

[0109] FIG5 is a schematic diagram of another communication method provided in an embodiment of the present application;

[0110] FIG6 is a schematic diagram of another communication method provided in an embodiment of the present application;

[0111] FIG7 is a schematic diagram of another communication method provided in an embodiment of the present application;

[0112] FIG8 is a schematic diagram of a possible process provided by an embodiment of the present application;

[0113] FIG9 is a schematic diagram of another possible process provided by an embodiment of the present application;

[0114] FIG10 is a schematic diagram of another possible process provided by an embodiment of the present application;

[0115] FIG11 is a schematic diagram of another possible process provided by an embodiment of the present application;

[0116] FIG12 is a schematic diagram of another possible process provided by an embodiment of the present application;

[0117] FIG13 is a schematic diagram of an end-to-end connection architecture provided by an embodiment of the present application;

[0118] FIG14 is a schematic diagram of the composition of a communication device provided in an embodiment of the present application;

[0119] FIG15 is a schematic diagram of the hardware structure of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0120] In order to facilitate understanding of the technical solutions of the embodiments of the present application, a brief introduction to the relevant technologies of the embodiments of the present application is first given as follows.

[0121] 1. New services in communication networks:

[0122] With the development of communication technology, the introduction of some new services in wireless communication networks (networks that have evolved after 5G, such as the sixth generation (6G)). For example, services involving AI and perception services. With the introduction of these new services, some new services may emerge. For example, in new services involving AI, AI is also used as a service (in this article, "AI as a service" can be simply referred to as "AI service"), and AI services such as model training, model reasoning, and model verification can be provided. In perception services, devices with perception capabilities can perceive the characteristics of the target by sending and receiving signals, and can provide perception services such as high-precision positioning, high-resolution imaging, parameter measurement, gesture / motion recognition, and vital sign monitoring. For example, 6G networks may also provide computing services (such as computing offloading) and data services (such as data collection or data recycling).

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

[0124] At the network level, the process of achieving a specific goal through the collaboration of multi-dimensional resources can be defined as a "task." In the task-centric architecture, task anchors (TA) and task executors (TE) are introduced. TA is responsible for the lifecycle management of tasks, such as deploying, launching, deleting, modifying, or monitoring tasks, and regulating four-dimensional resources for tasks. TE is responsible for the specific execution of tasks and performs data interaction based on business logic. Based on TA and TE, the task processing flow can be as follows: after the task trigger source triggers the task, the task request is sent to TA, and TA 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 status changes in real time, and implementing four-dimensional resource collaborative scheduling.

[0126] To achieve service decoupling, the core network (CN) and radio access network (RAN) can independently deploy TA and TE. For example, on the core network side, the task control function (TCF) network element can provide TA functionality, and the task process function (TPF) network element can provide TE functionality. On the access network side, the cluster node (cNode) can provide TA functionality, and the service node (sNode) can provide TE functionality.

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

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

[0129] For the four dimensions of data, calculation, algorithm and connection, a task can be split into dimension-level subtasks. Based on this, when deploying tasks, TA can deploy dimension-level subtasks to TE for execution. It can be understood that since the connection dimension of the task includes the connection path between TEs that execute different subtasks, and does not have to be specifically executed by a certain TE, there is no subtask of the connection dimension. Therefore, a task can be split into subtasks of the data dimension (hereinafter referred to as data subtasks), subtasks of the calculation dimension (hereinafter referred to as calculation subtasks) and subtasks of the algorithm dimension (hereinafter referred to as algorithm subtasks). The number of each type of subtask can be one or more.

[0130] In one possible scenario, TE performs dimension-level subtasks, which can also be referred to as TE performing corresponding functions. For example, TE performs calculation subtasks, which can also be referred to as TE performing calculation functions.

[0131] In one possible implementation, different modules within the network element that provides TA functions can be responsible for resources in different dimensions, focusing on the four dimensions of connection, computing, data, and algorithms. For example, the data controller (DC) module can manage the data dimension resources of a task, the computing controller (CC) can manage the computing dimension resources of a task, the algorithm control (HicC) module can manage the algorithm dimension resources of a task, and the network controller (NC) module can manage the connection dimension resources of a task, including the establishment, addition, deletion, and modification of connection paths between TEs.

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

[0133] In summary, after the communication network introduces new services, some new services will no longer use PDU sessions as management objects, but will evolve to use task sessions as management objects for task-granularity lifecycle management. The dimensions involved in these new services have also evolved from pure connection to four dimensions: connection, computing, data, and algorithm, and involve multiple network nodes with complex topology. The QoS policy generation mechanism in the 5G network uses PDU sessions as management objects, and can only provide QoS guarantees and differentiated services for end-to-end connections in a simple path of terminal device-RAN-CN. It is not suitable for generating QoS policies for new services. Therefore, how the QoS policy generation mechanism should be designed for new services introduced into the communication network is an urgent problem to be solved. In order to solve this problem, the embodiment of the present application provides a communication method that can support the generation of QoS policies for new services introduced into the communication network to ensure the QoS of the services.

[0134] The following is an introduction to the specific implementation of the QoS method provided in the embodiment of the present application. In the description of the embodiment of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship. For example, A / B can represent A or B; "and / or" in this application is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In addition, in the description of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers 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, c can be single or multiple. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0135] In the embodiment of the present application, "indication" may include direct indication and indirect indication, and may also include explicit indication and implicit indication. The information indicated by a certain information is called information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein there is an association relationship between the other information and the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, the indication of specific information can also be achieved by means of the arrangement order of each piece of information agreed in advance (such as specified in the protocol), thereby reducing the indication overhead to a certain extent. At the same time, the common parts of each piece of information can also be identified and indicated uniformly to reduce the indication overhead caused by indicating the same information separately.

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

[0137] In an embodiment of the present application, "pre-definition", "pre-definition", "pre-configuration" or "pre-configuration" 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 the device leaves the factory, or configured when accessing the network for the first time. The embodiment of the present application does not limit its specific implementation method. Among them, "saving" can mean saving in one or more memories. The one or more memories can be set separately or integrated in an encoder or decoder, a processor, or a communication device. The one or more memories can also be partially set separately and partially integrated in a decoder, a processor, or a communication device. The type of memory can be any form of storage medium, which is not limited by the embodiment of the present application.

[0138] The "protocol" involved in the embodiments of the present application may refer to a protocol family in the communication field, a standard protocol with a similar protocol family frame structure, or a related protocol used in future communication systems. The embodiments of the present application do not make specific limitations on this.

[0139] In the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device will perform corresponding processing under certain objective circumstances. It does not limit the time, nor does it require the device to perform judgment actions when implemented, nor does it mean that there are other limitations.

[0140] In the embodiments of the present application, "sending information to ... (taking the 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 to the anchor network element directly or indirectly. "Receiving information from ... (taking the anchor network element as an example)" can be understood as the source of the information being the anchor network element, which can include receiving information from the anchor network element directly or indirectly. The information may undergo necessary processing between the source and destination of the information, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood similarly and will not be repeated 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 evolved after 5G. In addition, 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 the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

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

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

[0145] In the RAN architecture of the communication system to which the embodiments of the present application are applicable, RAN nodes can be connected to each other wirelessly or by wire. For example, as shown in FIG1 , cNode and sNode communicate via the Y1 interface. Different sNodes communicate via the Y3 interface. Different cNodes communicate via the Y2 interface. In the RAN architecture of the communication system to which the embodiments of the present application are applicable, RAN nodes can be connected to terminal devices (not shown in FIG1 ) wirelessly. In some scenarios, terminal devices can also provide TE functions and / or TS functions.

[0146] In the RAN architecture of the communication system to which the embodiments of the present application apply, the core network element and the RAN node may be different physical devices, or may be the same physical device that integrates the core network logical functions and the radio access network logical functions. If the core network element and the RAN node are different physical devices, the RAN node may be connected to and / or communicate with the core network element via a wired or wireless method.

[0147] The RAN architecture of the communication system to which the embodiments of the present application are applicable may also include other RAN nodes, such as wireless relay equipment and / or wireless backhaul equipment (not shown in FIG1 ).

[0148] The RAN architecture shown in Figure 1 can be a cellular system related to the Third Generation Partnership Project (3GPP), such as the RAN architecture of a 6G mobile communication system. It can also be an open access network (O-RAN or ORAN), a cloud radio access network (CRAN), or a RAN architecture in a communication system that integrates two or more of the above 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 a possible, non-limiting communication system to which the embodiments of the present application are applicable, the core network architecture may be as shown in FIG2 . The TCF network element provides the TA function on the core network side. The TPF network element provides the TE function on the core network side, and in some scenarios, may also provide the TS function on the core network side. The control plane connection function (CF-C) network element and the user plane connection function (CF-U) network element provide the control plane and user plane functions of the connection, respectively. Mobility management (MM) is responsible for providing mobility management functions for terminal devices, storing location information of terminal devices, etc. The unified data management (UDM) network element is mainly responsible for user contract management, access authorization, authentication information generation, etc. The policy control function (PCF) network element is responsible for providing policy rules to network entities for implementation. The trusted anchor agent (TAA) network element is responsible for ensuring the reliability, integrity, and confidentiality of data, and protecting data from various security and privacy attacks from entities inside and outside the network.

[0151] Optionally, the core network architecture of the communication system to which the embodiments of the present application are applicable may further include other network elements. For example, a unified data repository (UDR) network element, a task orchestration network element, or a network data analytics function (NWDAF) network element may also be included. Among them, the unified data repository network element is mainly responsible for storing subscription data and policy rules. The task orchestration network element is mainly responsible for orchestrating tasks. The network data analysis function network element is mainly responsible for providing network analysis services based on the request data of the network service.

[0152] The embodiments of the present 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 a possible, non-limiting communication system applicable to embodiments of the present application, a RAN node can communicate with a terminal device via a wireless air interface (Uu interface), with its protocol stack including a control plane protocol and a user plane protocol. RAN nodes can communicate with each other via a Yn interface, with their protocol stack also including a control plane protocol and a user plane protocol. The control plane is responsible for signaling exchange, while the user plane is responsible for data exchange.

[0154] In one possible implementation, the control plane protocol stack and the user plane protocol stack between the RAN node and the terminal device can be shown in Figure 3. Among them, the task resource control (TRC) layer of the control plane can be obtained by enhancing the radio resource control (RRC) layer in the 5G protocol stack. On the basis of the functions of the existing RRC layer, additional control functions related to tasks such as AI, computing, and data processing are added. The task resource scheduler (TRS) of the user plane can be obtained by enhancing the medium access control (MAC) layer in the 5G protocol stack. For example, on the basis of the existing air interface resource scheduling function of the MAC layer, an additional computing power scheduling function is added. In addition, 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 and other functions, and the TRD sublayer can provide task data encapsulation functions. The specific functions of the remaining layers in Figure 3, such as the packet data convergence protocol (PDCP) layer, the radio link control (RLC) layer, the TRS layer, the physical (PHY) layer, and the SDAP layer, can be referred to the existing 5G communication protocol and will not be expanded here.

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

[0156] Exemplarily, the terminal device can be a drone, an Internet of Things (IoT) device (for example, a sensor, an electricity meter, a water meter, etc.), a V2X device, a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA) device, a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, an on-board device (for example, a terminal on a car, a bicycle, an electric car, an airplane, a ship, a train, a high-speed rail, etc.), a vehicle device (for example, a whole vehicle device, an on-board module, an on-board chip, an on-board unit (OBU) or a telematics box (T-BOX), etc.), a wearable device (also called a wearable smart device, such as a smart watch, a smart bracelet, a pedometer, a smart glasses, etc.), a tablet computer or a computer with wireless transceiver function, a virtual reality (VR) terminal, a wireless terminal in industrial control, an unmanned driving (self The present invention relates to wireless terminals in the fields of smart driving, remote medical, smart grid, transportation safety, smart city, smart home, vehicle-mounted terminals, vehicles with vehicle-to-vehicle (V2V) communication capabilities, intelligent connected vehicles, drones with UAV to UAV (U2U) communication capabilities, etc. The terminal device can be mobile or fixed, and this application does not make specific restrictions on this.

[0157] A RAN node, sometimes also called access network equipment, RAN entity, or access node, is a network element in a radio access network (RAN) responsible for air interface-related functions. The names of RAN nodes may vary depending on the system using different radio access technologies.

[0158] In one possible scenario, a RAN node may 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 base station (ng-eNodeB, ng-eNB), a cluster node or service node in a 6G mobile communication system, a base station in a future mobile communication system, etc. A RAN node may be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a wireless controller in a CRAN scenario. Optionally, a RAN node may also be a server, a wearable device, a vehicle or an on-board device, etc. For example, the access network device in the vehicle to everything (V2X) technology may be a road side unit (RSU). All or part of the functions of the RAN node in this application may also be implemented by software functions running on hardware, or by virtualized functions instantiated on a platform (e.g., a cloud platform). The RAN node in this application may also be a logical node, a logical module, or software that can implement all or part of the functions of a RAN node.

[0159] In another possible scenario, multiple RAN nodes collaborate to assist terminal devices in achieving wireless access, and different RAN nodes respectively implement part of the functions of the base station. For example, the RAN node can be a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The CU and DU can be set separately, or they can be included in the same network element, such as a baseband unit (BBU). The RU can be included in a radio frequency device or radio frequency unit, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH).

[0160] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0161] The communication method provided in the embodiment of the present application is described below in conjunction with the communication systems shown in Figures 1 and 2.

[0162] It should be noted that in the following embodiments of the present application, the message names, parameter names, or information names between network elements are only examples. In other embodiments, they may also be other names, and the method provided in the present application does not make specific limitations on this.

[0163] It is understood that in the embodiments of the present application, each network element or entity may perform some or all of the steps in the embodiments of the present application. These steps or operations are merely examples, and the embodiments of the present application may also perform other operations or variations of various operations. In addition, the steps may be performed in a different order than those presented in the embodiments of the present application, and it is possible that not all operations in the embodiments of the present application need to be performed.

[0164] Referring to FIG4 , the communication method provided in the embodiment of the present application includes steps S401 to S403:

[0165] S401: The policy control function network element obtains task information and requirement information of a first service.

[0166] First, the policy control function network element obtains the required information of the first service.

[0167] The requirement information of the first service includes requirements for QoS indicators related to the first service, for example, requirements for at least one indicator such as service success rate, service response delay, system energy efficiency, service coverage, or service density.

[0168] In one possible implementation, the requirement information of the first service may be determined based on an agreement signed between a user of the first service and a provider of the first service. For example, the requirement information of the first service may be service level agreement (SLA) information.

[0169] Regarding the policy control function network element obtaining the requirement information of the first service, in one possible implementation, the policy control function network element may obtain relevant information of the first service, where the relevant information of the first service includes at least one of the following: the requirement information of the first service or identification information of the first service, wherein a mapping relationship exists between the identification information of the first service and the requirement information of the first service.

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

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

[0172] In the embodiment of the present application, predefined can also be understood as preset, preconfigured, pre-set, protocol-defined or pre-agreed. This is a unified explanation, and similar expressions can be understood in the following text.

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

[0174] If the relevant information of the first service includes requirement information of the first service, optionally, the policy control function network element may determine the identification information of the first service corresponding to the requirement information of the first service based on a 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 used to jointly define the first service in combination with the requirement information of the first service. Exemplarily, the identification information of the first service can include at least one of the following: information about the user or third party that triggers the first service, information about the terminal device involved in the first service, or information about the application service provider (ASP).

[0176] For example, the third party may be a vendor of an over-the-top (OTT) service provided by an operator. The vendor of the OTT service may directly trigger the first service at the network level.

[0177] For example, the identification information of the first service may include the user identification number (identity, ID) (user ID) of the user that triggers the first service (if the user is a UE, the user ID is the UE ID), the internet protocol (IP) triplet information of the server that triggers the OTT service of the first service, information about the services provided by the network required by the OTT service manufacturer, 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 that provides the first service. The IP triplet information includes the IP address, transport layer protocol, and port.

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

[0179] Optionally, the policy control function network element may also obtain service data flow (SDF) information. Exemplarily, the SDF information may include IP quintuple information of the service data. The IP quintuple 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 may further obtain type information of the first service. The type information of the first service may indicate to which general category the first service belongs. For example, the type information of the first service may indicate whether the first service is an AI service, a computing service, a data service, or a perception service. Alternatively, the type information of the first service may further indicate to which subcategory within the general category the first service belongs. For example, assuming that the first service is an AI service, the type information of the first service may further indicate whether the first service is a model training, model inference, or model verification service.

[0181] The embodiment of the present application does not limit the specific network element from which the policy control function network element obtains the requirement information of the first service. For example, the policy control function network element may obtain the requirement information of the first service from an application function network element.

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

[0183] The first service may be decomposed and mapped to obtain one or more tasks, and the task information includes relevant information of the tasks obtained by decomposing and mapping the first service.

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

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

[0186] The task topology information may indicate the connection method between network elements involved in the task. For example, the task topology information may describe at least one of the following connection methods: RAN-RAN (RAN side, the connection between different RAN nodes), CN-RAN-UE (the connection between core network elements, RAN nodes and terminal devices), and UE-RAN-UE (the connection between different terminal devices 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 each task ID.

[0188] In the embodiments of the present application, "a network element responsible for executing a task" or similar expressions, such as "a network element that executes a task," may be referred to as an execution network element and described uniformly herein. The execution network element may provide TE functions, and the details of the TE functions can be found in the above description and will not be elaborated upon here.

[0189] In addition, in a possible scenario, the execution network element may also provide a TS function. For details of the TS function, please refer to the above introduction and will not be expanded here.

[0190] The embodiment of the present 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 the embodiment of the present application, the anchor network element is a network element that provides the TA function, which is uniformly described here. For example, the anchor network element can be a TCF or a cNode.

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

[0193] It is understandable that the process shown in Figure 4 is only a logical schematic process provided to facilitate understanding of the embodiments of the present application, and does not represent the actual timing of the embodiments of the present application. The embodiments of the present application do not limit the timing between different actions in the same step in Figure 4, and the timing between different steps in Figure 4. For example, S401 is the policy control function network element obtaining task information and requirement information of the first service, which does not mean that the policy control function network element obtains the task information and the requirement information of the first service at the same time. In one possible scenario, the policy control function network element may first obtain the requirement information of the first service, and then obtain the task information. For another example, in Figure 4, S402 is after S401, which does not mean that the policy control function network element completes S401 first and then completes S402. In one possible scenario, the policy control function network element may first obtain the requirement information of the first service, and 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 the task information and the first service requirement information, the policy control function network element may also obtain other information that can assist in generating the network policy. For example, the policy control function network element may also obtain at least one of the following information: billing-related information, data statistics or forecast information of certain network functions or network services, bandwidth requirement information, or information indicating the data format (e.g., media type information). The embodiments of the present application do not limit the specific network element or elements from which the policy control function network element obtains the above information.

[0195] S402: The policy control function network element generates QoS parameters for the first service according to the requirement information of the first service.

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

[0197] The QoS parameters of the first service may include a QoS indicator and a control strategy 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 a first service may include information indicating at least one metric, such as service success rate, service response delay, system energy efficiency, service coverage, or service density, as well as information indicating the value corresponding to each metric. Metrics such as service success rate, service response delay, system energy efficiency, service coverage, or service density are QoS metrics for the first service. The value corresponding to each metric represents the control strategy for that metric. For example, a value corresponding to service response delay of 1ms indicates that the end-to-end delay requirement for the first service is 1ms.

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

[0200] In a possible implementation, the identification information of the QoS parameters of the first service may be generated by a policy control function network element. For example, the policy control function network element may generate a different service identification number (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 may 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 service IDs predefined by the operator.

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

[0203] For example, if the first service belongs to a business that is a very important person (VIP) who has signed a contract with the operator, then the first priority QoS parameters may be a set of QoS parameters with the highest requirements. If the first service belongs to a business that is not a VIP, then the first priority QoS parameters may be a set of QoS parameters with lower requirements.

[0204] Optionally, if the policy control function network element obtains relevant information of the first service in S401, then in S402, the policy control function network element may generate a QoS template corresponding to the first service based on the relevant information of 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 how to generate the QoS template corresponding to the first service, please refer to the above description of different situations of the relevant information of the first service, which will not be elaborated here.

[0205] Optionally, after S402, the following steps may be further 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] If, in S402, the policy control function network element generates a QoS template corresponding to the first service, the policy control function network element may 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 QoS parameters of the task according to the task information and the QoS parameters of the first service.

[0209] Based on this solution, 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 task granularity and can support the generation of QoS policies for new services in communication networks.

[0210] In S403, the QoS parameters of the task include the QoS index and control strategy of the task obtained by the first service decomposition mapping. At this time, the QoS parameters of the task are at the task level.

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

[0212] Optionally, the QoS parameters of the task may include at least one of the following: QoS specific requirement information or an identifier indicating the QoS specific requirement. The identifier indicating the QoS specific requirement may have a predefined mapping relationship with the QoS specific requirement, so that the corresponding QoS specific requirement can be determined by the identifier indicating the QoS specific requirement.

[0213] For example, the QoS specific requirement information may include task indicators and values ​​corresponding to the task indicators.

[0214] Exemplarily, the identifier indicating the specific QoS requirement may be a 6G QoS identifier (6G QoS identifier, 6QI).

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

[0216] The task data flow can be understood as the data transmission generated when the executing network element executes the task. In other words, the task data flow is at the task level.

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

[0218] Optionally, the policy and charging rule may further include identification information (rule ID) of the policy and charging rule.

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

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

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

[0222] The following introduces the possible contents of the policies and charging rules generated by the policy control function network element, taking the business to which the first service belongs involving at least one dimension of connection, calculation, data or algorithm as an example.

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

[0224] Optionally, each business data flow of a task (i.e., task data flow) can be classified based on which dimension of computation, data, or algorithm the data transmitted by the task's business data flow is related to. That is, the business data flow of a task can include different types of business data flows, where the different types can include computation, data, or algorithm types. In this case, the policy and billing rules can also include information about the type of the task's business data flow.

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

[0226] Exemplarily, the information of the network element executing the transmission starting point of the task's business data flow may include at least one item of information such as the ID or IP of the network element executing the transmission starting point of the task's business data flow. The information of the network element executing the transmission ending point of the task's business data flow is similar and will not be repeated here.

[0227] Among them, exemplarily, the specific QoS requirement 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), etc.

[0228] Exemplarily, the identifier indicating the specific QoS requirements associated with the connection may be 6QI.

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

[0230] Among them, a task can be decomposed into one or more computing subtasks.

[0231] The execution network element for executing the computing function may refer to the execution network element for executing the computing subtask. For example, the information of the execution network element for executing the computing function may include at least one of the information such as the ID or IP address of the execution network element for executing each computing subtask.

[0232] In one possible scenario, the execution network element that performs the computing function may also perform the algorithm function and / or the data function. In other words, the execution network element that performs the computing function may also be the execution network element that performs the algorithm function and / or the data function.

[0233] The computing type of a computing subtask can be divided based on the computing specifications of the computing subtask (or the computing resources required by the computing subtask). For example, the computing resources may include computing power types, such as central processing units (CPUs), graphics processing units (GPUs), or field-programmable gate arrays (FPGAs), and computing power requirements, such as millions of floating-point operations per second (MFLOPS).

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

[0235] Exemplarily, the identifier indicating specific QoS requirements related to computing may be 6QI.

[0236] Exemplarily, the identifier of the computing subtask may be the ID of the computing subtask.

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

[0238] Exemplarily, the information of the execution network element for executing the data function may include at least one of the information such as the ID or IP of the execution network element for executing the data function.

[0239] Exemplarily, the data-related QoS specific requirement information may include at least one of the following: latency or ARP, etc. The latency may include at least one of data transmission delay or data processing delay.

[0240] Exemplarily, the identifier indicating the specific QoS requirement associated with the data may be 6QI.

[0241] The data type is used to indicate the dimension to which the data corresponds. For example, the data type can include at least one of calculated data, model data, or data data. Calculated data indicates the data corresponds to a calculated dimension; model data indicates the data corresponds to a model dimension; and data data indicates the data corresponds to a data dimension. For example, if the data is perception data, the data dimension can be indicated, requiring specialized processing by a data function.

[0242] Exemplarily, 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 an algorithm dimension, the policies and charging rules generated by the policy control function network element 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, the algorithm type, the algorithm level, the application method, or information of the execution network element used to execute the algorithm function.

[0244] Exemplarily, the information of the execution network element used to execute the algorithm function may include at least one of the information such as the ID or IP of the execution network element that executes the algorithm function.

[0245] The algorithm level can indicate requirements for model structure or scale. For example, the algorithm level can indicate that the model needs to be trained 100 times, or that the model parameter scale is 7 billion.

[0246] Exemplarily, the specific QoS requirement information related to the algorithm may include at least one of the following: training and inference latency, inference accuracy, or ARP, etc.

[0247] Exemplarily, the identifier indicating the specific QoS requirements associated with the algorithm may be 6QI.

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

[0249] The application mode may indicate the mode of applying the algorithm-related QoS parameters. For example, the application mode may indicate when to use the algorithm-related QoS parameters of the first priority, and whether to enable the algorithm-related QoS parameters of the second priority if the algorithm-related QoS parameters of the first priority cannot be met.

[0250] Optionally, after S403, the embodiment of the present 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 task's QoS parameters, the anchor network element can generate resource-level QoS parameters based on the task's QoS parameters. The resource-level QoS parameters include at least one of the following: connection dimension, computing dimension, data dimension, and algorithm dimension.

[0253] The specific implementation of the anchor network element generating resource-level QoS parameters based on the task QoS parameters is introduced below and will not be expanded here.

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

[0255] Referring to FIG5 , another communication method provided in an embodiment of the present application includes steps S501-S503:

[0256] S501. The anchor network element obtains QoS parameters of a task.

[0257] The QoS parameters of the task may be specifically described in the above description of the QoS parameters of the task in S403 , which will not be expanded here.

[0258] The embodiment of the present application does not limit the network element from which the anchor network element obtains the QoS parameters of the task. For example, the anchor network element can obtain the QoS parameters of the task from a policy control function network element.

[0259] In one possible implementation of S501, the anchor network element may obtain policy and charging rules. The policy and charging rules include the QoS parameters of the task and a mapping relationship between the task QoS parameters and at least one of the execution network element or task data flow that executes the task. The specific content of the policy and charging rules in this implementation can be found in the above description of the policy and charging rules in S403 and will not be elaborated here.

[0260] Optionally, the embodiment of the present application may further include the following steps: the anchor network element obtains the task orchestration result, where the orchestration result includes task template description information and task dependency relationships.

[0261] The task template description information is used to describe the task or the subtasks derived from the task decomposition. For example, it may include at least one of the following information: task type (for example, the subtask type is algorithm, computation, or data), resource requirements (this information may indicate the size of resources required for 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 (for example, the time from the start to the end of a task or subtask).

[0262] The task dependencies may include dependencies between different tasks obtained from the first service decomposition mapping. For example, assume that the first service decomposition mapping obtains Task A, Task B, and Task C. The task dependencies may be: the execution of Task A depends on the execution of Task B, and the execution of Task C depends on the execution of Task A and Task B.

[0263] Optionally, the task scheduling result may further include information of an execution network element that executes the task.

[0264] The embodiment of the present application does not limit the network element from which the anchor network element obtains the task scheduling result. For example, the anchor network element can obtain the task scheduling result from the task scheduling network element.

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

[0266] The embodiment of the present application does not limit the time sequence between the anchor network element obtaining the QoS parameters of the task and the anchor network element obtaining the task scheduling result. For example, the anchor network element can first obtain the task scheduling result and then obtain the task QoS parameters.

[0267] Furthermore, the anchor network element can obtain task information according to the orchestration result, and the task information includes deployment information and topology information of the task.

[0268] Optionally, the anchor NE may also send task information to the policy control function NE. Correspondingly, upon receiving the task information, the policy control function NE may generate QoS parameters for the task based on the task information. The details of how the policy control function NE generates QoS parameters for the task based on the task information can be found in the description of S403 above and will not be elaborated here.

[0269] In a possible implementation, when the anchor network element sends the task information to the policy control function network element, the QoS parameters of the first service may also be sent to the policy control function network element.

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

[0271] The task QoS flow can be understood as the minimum granularity for QoS management by anchor and execution NEs. Anchor and execution NEs 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 QoS parameters of the task and the execution network element that executes the task. The resource-level QoS parameters include at least one of the following: connection dimension, computing dimension, data dimension, and algorithm dimension.

[0273] In S502, the anchor network element may decompose and map the task QoS parameters according to the QoS parameters related to connection, calculation, data or algorithm in the task QoS parameters to generate resource-level QoS parameters.

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

[0275] In a possible implementation of S502, the anchor network element may determine the subtasks to be executed for each execution network element according to the differences in processing capabilities of each execution network element in various dimensions, and determine corresponding resource-level QoS parameters.

[0276] The following describes the possible contents of the resource-level QoS parameters generated by the anchor network element based on the different situations of the QoS parameters included in the task QoS parameters.

[0277] Case 1: The task's QoS parameters include connection-related QoS parameters. For example, the policy and charging rules obtained by the anchor network element include at least one of the following: specific QoS requirement information related to the connection, an identifier indicating the specific QoS requirement related to the connection, information about the network element executing the task's service data flow's transmission origin, and information about the network element executing the task's service data flow's transmission destination. For details, please refer to the description of S403 above.

[0278] In this case, 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: specific QoS requirement information related to the connection, an identifier indicating the specific QoS requirement related to the connection, 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 flows corresponding to different QoS requirements based on group identification rules. Group identification rules include specific detection rules, and different group identification rules are associated with different QoS requirements. If a service data flow is determined to match a group identification rule based on the specific detection rules, the service data flow can be determined to correspond to the QoS requirement associated with the matched group identification rule, thereby distinguishing service data flows corresponding to different QoS requirements. Furthermore, based on the QoS requirements corresponding to different service data flows, service data flows corresponding to the same QoS requirement can be classified as flows with the same task QoS.

[0280] Case 2: The task's QoS parameters include QoS parameters related to computing. For example, the policy and charging rules obtained by the anchor network element include at least one of the following: specific QoS requirement information related to computing, an identifier indicating the specific QoS requirement related to computing, information about the execution network element used to perform the computing function, an identifier of the computing subtask, or the computing type of the computing subtask. For details, please refer to the above description of S403.

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

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

[0283] Case 3: The task's QoS parameters include data-related QoS parameters. For example, the policy and charging rules obtained by the anchor network element 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, and the data type or data size. For details, please refer to the description of S403 above.

[0284] In this case, the resource-level QoS parameters generated by the anchor network element may include a data dimension. In one possible implementation, the QoS parameters of the data dimension 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 according to the data subtask identification rule, please refer to distinguishing computing subtasks corresponding to different QoS requirements according to the computing subtask identification rule, which will not be expanded here.

[0285] Case 4: The task's QoS parameters include algorithm-related QoS parameters. For example, the policy and charging rules obtained by the anchor network element include at least one of the following: specific QoS requirement information related to the algorithm, an identifier indicating the specific QoS requirement related to the algorithm, the algorithm type, the algorithm level, or the application method. For details, please refer to the description of S403 above.

[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 QoS parameters of the algorithm dimension may include at least one of the following: specific QoS requirement information related to the algorithm, an identifier indicating the specific QoS requirement 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 according to the algorithm subtask identification rule, please refer to distinguishing computing subtasks corresponding to different QoS requirements according to the computing subtask identification rule, which will not be expanded 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 the task according to the resource-level QoS parameters.

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

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

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

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

[0293] The anchor network element receives notification information from the execution network element, where the notification information is used to notify the execution network element that the corresponding QoS requirements (QoS requirements related to connection, calculation, data or algorithm) cannot be met.

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

[0295] Optionally, after receiving the notification information, the anchor network element may feedback to other network elements that the execution network element cannot meet the corresponding QoS requirement. For example, the anchor network element may feedback to the policy control function network element that the execution network element cannot meet the corresponding QoS requirement.

[0296] In addition, in a possible scenario, the anchor network element may determine whether to send the resource-level QoS parameters to the execution network element according to the functions of the modules within the execution network element.

[0297] For example, assuming that resource-level QoS parameters include data-dimensional QoS parameters, if the module responsible for executing data functions within the execution network element (hereinafter referred to as the data execution module) also integrates computing and algorithm functions, 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 executing computing functions (hereinafter referred to as the computing execution module), and the module responsible for executing algorithm functions (hereinafter referred to as the algorithm execution module) are independent modules, that is, the data execution module does not integrate computing and algorithm functions, then the computing execution module can be managed by the module responsible for controlling task computing resources within the anchor network element (hereinafter referred to as the computing control module), and the algorithm execution module can be managed by the module responsible for controlling task algorithm resources within the anchor network element (hereinafter referred to as the algorithm control module). It can also be understood that the computing and / or algorithm functions provided by the execution network element are managed by the corresponding modules in the anchor network element. In this case, after the anchor network element obtains the resource-level QoS parameters, the module responsible for controlling task data resources within the anchor network element (hereinafter referred to as the data control module) can call the corresponding computing and / or algorithm functions to the computing control module and / or algorithm control module. If the computing function is called, the data control module can send the corresponding computing-dimensional QoS parameters to the computing control module. If the algorithm function is called, the data control module can send the corresponding algorithm-dimensional QoS parameters to the algorithm control module.

[0299] For another example, assuming that the resource-level QoS parameters include algorithm-level QoS parameters, if the algorithm execution module in the execution network element also integrates computing and data functions, the anchor network element can directly send the resource-level QoS parameters to the algorithm execution module.

[0300] If, however, the data execution module, the calculation execution module, and the algorithm execution module are independent modules within the execution network element, that is, the algorithm execution module does not integrate the calculation and data functions, then the calculation execution module can be managed by the calculation 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. It can also be understood that the execution calculation and / or data functions provided by the execution network element are managed by the corresponding modules in 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 call the corresponding calculation and / or data functions to the calculation control module and / or data control module. If the calculation function is called, the algorithm control module can send the corresponding calculation dimension QoS parameters to the calculation control module. If the data function is called, the algorithm control module can send the corresponding data dimension QoS parameters to the data control module.

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

[0302] In one possible scenario of the above example, when the data control or algorithm control module calls the computing function, it can determine a new execution network element for executing the computing function, as well as the identification information of the new computing subtask (such as a 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 calls the algorithm function, it can determine the QoS parameters of 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 calls the data function, it can determine the QoS parameters of the new data dimension and send them to the data control module.

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

[0306] Referring to FIG6 , another communication method provided in an embodiment of the present application includes steps S601-S602:

[0307] S601: An executing network element obtains resource-level QoS parameters, wherein the resource-level QoS parameters include at least one of the following: connection dimension, computing dimension, data dimension, or algorithm dimension.

[0308] The resource-level QoS parameters may be specifically referred to the above introduction to the resource-level QoS parameters in S502 , which will not be elaborated here.

[0309] The embodiment of the present application does not limit the network element from which the execution network element obtains the resource-level QoS parameters. For example, the execution network element may obtain the resource-level QoS parameters from an anchor network element.

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

[0311] Based on the communication method provided in the embodiment of the present 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 executing network element may adjust policies or allocate resources based on the acquired resource-level QoS parameters to meet the resource-level QoS parameter requirements. For example, assuming that the resource-level QoS parameters include latency requirements, the executing network element may allocate computing power that can meet the latency requirements to execute the corresponding function.

[0313] In one possible scenario, when executing a task, the execution network element can have internal modules responsible for different functions execute different types of subtasks. Alternatively, when executing a task, the execution network element can have a module that integrates multiple functions execute multiple types of subtasks. For example, if the module responsible for executing the computing function within the execution network element (which can be called the computing execution module) also integrates algorithm and data functions, the computing execution module can execute the computing subtask, algorithm subtask, and data subtask.

[0314] In another possible scenario, the anchor network element may manage some modules in the execution network element, thereby scheduling corresponding functions to execute subtasks. For details, please refer to the above introduction to S503, which will not be repeated here.

[0315] Optionally, if the executing network element finds that it cannot meet the QoS requirements related to connection, calculation, data or algorithm in the obtained resource-level QoS parameters, the executing network element can send a notification message to the anchor network element, and the notification message is used to notify the executing network element that it cannot meet the QoS requirements related to connection, calculation, data or algorithm.

[0316] Referring to FIG. 7 , another communication method provided in an embodiment of the present application includes steps S701-S702:

[0317] S701: A task orchestration network element obtains QoS parameters of a first service.

[0318] The QoS parameters of the first service may be specifically referred to the above introduction to the QoS parameters of the first service in S402, which will not be elaborated here.

[0319] The embodiments of the present application do not limit the network element from which the task orchestration network element obtains the QoS parameters for the first service. For example, the task orchestration network element may obtain the QoS parameters for the first service from a unified data pool network element. Optionally, the QoS parameters for the first service stored in the unified data pool network element may be generated by a policy control function network element.

[0320] Optionally, one possible implementation of S701 may be: the task orchestration network element obtains a QoS template corresponding to the first service. The QoS template includes a mapping relationship between QoS parameters of the first service and identification information of the first service. The QoS template corresponding to the first service can be specifically described in the above description of S401 and will not be further elaborated here.

[0321] Optionally, before S701, the embodiment of the present application may further include the following steps:

[0322] The task orchestration network element is input with a use case after the instantiation of the first service, wherein the use case may include identification information of the first service or identification information of a QoS parameter of the first service.

[0323] At this time, S701 may be: the task orchestration network element obtains the corresponding QoS parameter of the first service according to the identification information of the first service or the identification information of the QoS parameter of the first service.

[0324] S702: The task orchestration network element performs task orchestration based on the QoS parameters of the first service, and obtains an orchestration result based on task granularity, wherein the orchestration result includes template description information and dependency relationships of the tasks obtained by decomposing and mapping the first service.

[0325] Based on the communication method provided in the embodiment of the present application, a task scheduling function can be provided for new services in the communication network, especially some more complex services, thereby realizing QoS hierarchical management from services to tasks.

[0326] The arrangement result can be specifically referred to the above introduction to S501 and will not be elaborated here.

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

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

[0329] Correspondingly, after receiving the orchestration result, the anchor NE can obtain task information according to the orchestration result, wherein the task information includes the deployment information and topology information of the task. The anchor NE obtains the task information according to the orchestration result. For details, please refer to the introduction of S501 above and will not be expanded 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 scheduling network element may first obtain the QoS parameters of the first priority of the first service, and perform task scheduling according to the QoS parameters of the first priority.

[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 based on the second-priority QoS parameters.

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

[0333] In one possible scenario, the above embodiments may be applied in combination, or may be applied independently.

[0334] In a scenario where the above embodiments are combined with applications, a possible exemplary process includes: a policy control function network element generates QoS parameters for a first service, further generates QoS parameters for a task, and sends the task QoS parameters to an anchor network element. The anchor network element may generate resource-level QoS parameters based on the obtained task QoS parameters and send them to the execution network element.

[0335] Assume that the policy control function network element is a PCF network element. The unified data pool network element is a UDR network element. The application function network element is an AF network element. The task orchestration network element is a NAMO network element. Anchor network elements include TCF network elements and cNodes. Execution network elements include TPF network elements, sNodes, and UEs. There can be one or more network elements of each type.

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

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

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

[0339] S802: The PCF network element classifies and merges the input from the AF network element to generate a service QoS template, and transmits the service QoS template to the UDR network element. The service QoS template includes a mapping relationship between the QoS parameters of the first service and the identification information of the first service.

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

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

[0342] For details of S802, please refer to the above introduction to S402, which will not be elaborated here.

[0343] S803. After the use case is input, the NAMO network element applies to the UDR network element for service QoS parameters corresponding to the first service based on at least one of the SDF information, ASP information, or UE information in the use case, or a service ID predefined by the operator. In one possible implementation, when applying for the first service, the NAMO network element applies for service QoS parameters of the first priority.

[0344] For details of S803, please refer to the above introduction to S701, which will not be elaborated here.

[0345] S804: The NAMO network element performs task orchestration based on the QoS parameters of the first service. If the orchestration based on the first-priority service QoS parameters fails, the NAMO network element applies to the UDR network element for the second-priority service QoS parameters and continues orchestration until an orchestration result is obtained.

[0346] S805: The NAMO network element transmits the orchestration result to the TCF network element and cNode. The orchestration result includes the task template description and task dependencies. The task template description may include the following information: task type, resource requirements, computational complexity, and runtime.

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

[0348] S806. The TCF network element and the cNode network element obtain task information according to the orchestration result, and input the task information to 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 decomposing and mapping the first service, the ID of the execution network element that executes the task, and the task topology information.

[0350] For details of S806, please refer to the above introduction to S501, which will not be elaborated here.

[0351] S807. The PCF network element completes the decomposition of the service QoS parameters into task QoS parameters, generates PCC rules, and inputs them to the TCF network element or cNode.

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

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

[0354] For details of S807, please refer to the above introduction to S403, which will not be elaborated here.

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

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

[0357] For details of S808, please refer to the above introduction to S502, which will not be elaborated here.

[0358] In a 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: connection dimension, computing dimension, data dimension, and calculation dimension. The following introduces possible exemplary processes for different dimensions.

[0360] Assume that the policy control function network element is a PCF network element. Anchor network elements include TCF network elements and cNodes. Execution network elements include TPF network elements, sNodes, and UEs. There can be one or more network elements of each type.

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

[0362] S901: The PCF network element transmits the PCC rules to the TCF network element or cNode. The connection-related content in the PCC rules includes at least one of the following: TDF template (including the ID / IP of the transmission origin execution network element, the ID / IP of the transmission destination execution network element, and the transmission type), 6QI, and connection-related QoS requirements (such as GFBR / MFBR / ARP).

[0363] For details of S901, please refer to the above introduction to S403, which will not be elaborated here.

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

[0365] Among them, among the resource-level QoS parameters, the connection-dimensional 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 (QER) to the TPF network element, sNode, or UE. The QER can indicate which set of QoS parameters to use in different situations. The TPF network element, sNode, or UE can select the QoS parameters to use based on the QER.

[0367] Optionally, the process may further include S903: when the TPF, sNode or UE finds that the corresponding QoS requirement cannot be met when performing the connection function, the process reports the situation to the TCF network element or cNode via a notification message.

[0368] Figure 10 is a schematic diagram of an exemplary process related to the computation dimension. The computation control (CC) module shown in Figure 10 is the module in a TCF network element or cNode responsible for managing and controlling the computation dimension resources for a task. The computation execution (CE) module is the module in a TPF network element, sNode, or UE responsible for executing computation functions.

[0369] It is understandable that the interaction diagram between the modules and network elements shown in FIG10 is a logical interaction diagram provided to facilitate understanding of the process, and does not represent information sent and received by the modules shown in FIG10 in actual applications.

[0370] As shown in FIG10 , the exemplary process includes the following steps:

[0371] S1001. The PCF network element transmits PCC rules to the TCF network element or cNode. The PCC rules contain computing-related content, including at least one of the following: a computing flow template (including the ID / IP of the network element performing the computing function and the computing type), 6QI, and computing-related QoS requirements (e.g., GFLOPS / MFLOPS / ARP, etc.).

[0372] For details of S1001, please refer to the above introduction to S403, which will not be elaborated here.

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

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

[0375] In one possible implementation, the 6QI included in the QoS parameters of the calculation dimension may also be referred to as 6QI-C.

[0376] In a possible implementation, the CC module in the TCF network element or the CC module in the cNode may generate the resource-level QoS parameters.

[0377] S1003. The CE module performs calculation functions according to the QoS parameters of the calculation dimension.

[0378] Specifically, the CE module in the TPF network element, sNode or UE performs the calculation function according to the QoS parameters of the calculation dimension.

[0379] Optionally, the TCF network element or cNode may also send a QER to the TPF network element, sNode or UE. The TPF network element, sNode or UE may select QoS parameters to be used according to the QER.

[0380] Optionally, the process may further include S1004: when the TPF, sNode or UE finds that the corresponding QoS requirement cannot be met when executing the computing function, the process reports the result to the TCF network element or cNode via a notification message.

[0381] Figure 11 is a schematic diagram of an exemplary process related to data dimensions. Among them, the data control DC module shown in Figure 11 is a module in the TCF network element or cNode that is responsible for the data dimension resources of the management task. For the CC module, please refer to the above introduction to Figure 10. The algorithm control HicC module is a module in the TCF network element or cNode that is responsible for the algorithm dimension resources of the management task. The data execution DA module is a module in the TPF network element, sNode or UE that is responsible for executing data functions. For the CE module, please refer to the above introduction to Figure 10. The algorithm execution HicA module is a module in the TPF network element, sNode or UE that is responsible for executing algorithm functions.

[0382] It is understandable that the interaction diagram between the modules and network elements shown in FIG11 is a logical interaction diagram provided to facilitate understanding of the process, and does not represent information sent and received by the modules shown in FIG11 in actual applications.

[0383] As shown in FIG11 , the exemplary process includes the following steps:

[0384] S1101. The PCF network element transmits PCC rules to the TCF network element or cNode. The data-related content in the PCC rules includes at least one of the following: a data level template (including data type and data size), 6QI, and data-related QoS requirements (e.g., latency / ARP, etc.).

[0385] For details of S1101, please refer to the above introduction to S403, which will not be elaborated here.

[0386] S1102, the TCF network element or cNode (e.g., the DC module therein) further splits 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 may also be referred to as 6QI-D.

[0387] Based on different situations, S1102 has two different implementations: S1102a and S1102b.

[0388] If the DA module is integrated (DA includes computing and algorithm functions in addition to data functions), and the functions integrated in 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 passes the resource-level QoS parameters directly to the DA module.

[0389] If the DA module is non-integrated, or the calculation and / or algorithm functions integrated in the DA are insufficient to meet the QoS requirements included in the resource-level QoS parameters, the exemplary process includes S1102b: the DC module in the TCF network element or cNode calls the calculation 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. Exemplarily, the QoS parameters of the calculation dimension sent to the CC module can be included in the calculation request message. The QoS parameters of the algorithm dimension sent to the HicC module can be included in the algorithm request message.

[0390] Optionally, when the DC module calls the calculation function to the CC module, it may also send the ID of the new network element that executes the calculation function and the new calculation subtask ID 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 may be QoS parameters of a new algorithm dimension.

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

[0393] As shown in FIG. 11 , if the exemplary process includes S1102 a , it also includes S1104 a : the DA module performs a data function (eg, data processing).

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

[0395] Optionally, the process may further include S1105: when the TPF, sNode or UE finds that the corresponding QoS requirement cannot be met when executing a data function, the process reports the situation to the TCF network element or cNode via a notification message.

[0396] FIG12 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 FIG12 can refer to the above description of FIG11.

[0397] It is understandable that the interaction diagram between the modules and network elements shown in FIG12 is a logical interaction diagram provided to facilitate understanding of the process, and does not represent information sent and received by the modules shown in FIG12 in actual applications.

[0398] As shown in FIG12 , the exemplary process includes the following steps:

[0399] S1201: The PCF network element transmits PCC rules to the TCF network element or cNode. The algorithm-related content in the PCC rules includes at least one of the following: a model-level template (including model type, model level, and application method), 6QI, and algorithm-related QoS requirements (such as training and inference latency, inference accuracy, or ARP).

[0400] For details of S1201, please refer to the above introduction to S403, which will not be elaborated here.

[0401] S1202: The TCF network element or cNode further splits 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 the MDR and algorithm-related QoS requirements. In one possible implementation, the 6QI included in the algorithm-level QoS parameters may also be referred to as 6QI-M.

[0402] Based on different situations, S1202 has two different implementations: S1202a and S1202b.

[0403] If the HicA module is integrated (HicA includes computing and data functions in addition to algorithm functions), and the functions integrated in 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 passes 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 computing 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. Exemplarily, the computing-dimensional QoS parameters sent to the CC module may be included in a computing request message. The data-dimensional QoS parameters sent to the DC module may be included in a data request message.

[0405] Optionally, when the HicC module calls the calculation function to the CC module, it may also send the ID of the new network element that executes the calculation function and the new calculation subtask ID to the CC module.

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

[0407] Optionally, S1203 may be further included: the TPF network element, sNode or UE requests the model and data from the DSF network element, and the DSF network element accordingly feeds back the model and data. When the TPF network element, sNode or UE obtains the model and data, data plane pre-processing is not required and the model and data can be directly obtained.

[0408] As shown in FIG. 12 , if the exemplary process includes S1202 a , it also includes S1204 a : the HicA module executes an algorithm function (eg, algorithm processing).

[0409] If the exemplary process includes S1202b, it also includes S1204b: the called CE module and / or DA module, and the HicA module execute the algorithm function (eg, algorithm processing).

[0410] Optionally, the process may further include S1205: when the TPF, sNode or UE finds that the corresponding QoS requirement cannot be met when executing the algorithm function, the process reports the result to the TCF network element or cNode via a notification message.

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

[0412] In addition, the different network elements in the above embodiments can also form a variety of end-to-end connection architectures. Figure 13 shows a possible end-to-end architecture applicable to the embodiments of the present application. As shown in Figure 13, the 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 billing-related information. The NWDAF network element can provide statistical or predictive information on 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 (for example, whether the first service is an AI service, a perception service, a computing service, or a data service), and the requirements of the first service. Based on the above information, 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 the service-level QoS parameters to obtain the orchestration results. The NAMO network element transmits the orchestration results to each TA (using the TCF network element and cNode in Figure 13 as an example). Based on the orchestration results, the TCF network element and cNode obtain task information and provide it 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, which it then passes to the TCF network element or cNode. Finally, the TCF network element and cNode determine the TE that will execute the task (using the TPF network element, sNode, and UE in Figure 13 as an example), decomposes and maps the task-level QoS parameters to generate resource-level QoS parameters, and passes them to the corresponding TPF network element, sNode, or UE.

[0415] It can be seen that the communication method provided in the embodiment of the present application can provide end-to-end QoS differentiation and guarantee services for new services in the communication network.

[0416] The above mainly introduces the solutions provided by the embodiments of the present application from the perspective of interaction between various network elements. Accordingly, the embodiments of the present application also provide a communication device, which is used to implement the various methods described above. The communication device can be each network element in the above method embodiments, or a device that includes each of the above network elements, or a component that can be used for each of the above network elements. It is understood that in order to implement the above functions, the communication device includes hardware structures and / or software modules corresponding to performing each function. Those skilled in the art should readily appreciate that, in combination with the various exemplary units and algorithm steps described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or in a hardware-driven manner by computer software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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] In the embodiment of the present application, the communication device can be divided into functional modules according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be understood that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0418] Figure 14 shows a schematic diagram of the structure 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 known as a transceiver unit, is used to implement transceiver functions and may be, for example, a transceiver circuit, a transceiver, a transceiver, or a communication interface.

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

[0420] Transceiver module 1402 is configured to obtain task information and first service requirement information; the task information includes task-related information derived from decomposition and mapping of the first service. Processing module 1401 is configured to generate QoS parameters for the first service based on the first service requirement information. Processing module 1401 is further configured to generate QoS parameters for the task based on the task information and the first service QoS parameters.

[0421] Optionally, the transceiver module 1402 obtains the requirement information of the first service, including: obtaining relevant information of the first service, the relevant information of the first service including 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 requirement information of the first service, including: generating a QoS template corresponding to the first service based on the relevant information of the first service, the QoS template including 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 further configured to send 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 policy and charging control rules based on the task information and the QoS parameters of the first service. The policy and charging rules include the QoS parameters for the task and a mapping relationship between the QoS parameters for the task and at least one of an execution network element that executes the task or a task data flow.

[0425] Optionally, the transceiver module 1402 is further configured to send the task's QoS parameters to the anchor network element, where the task's QoS parameters are used by the anchor network element to generate resource-level QoS parameters. The resource-level QoS parameters include parameters in at least one of the following dimensions: connection dimension, computing 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 a possible implementation manner:

[0427] Transceiver module 1402 is configured to obtain task QoS parameters. Processing module 1401 is configured to generate resource-level QoS parameters based on the task QoS parameters and the execution network element (NE) executing the task. Resource-level QoS parameters include parameters in at least one of the following dimensions: connection dimension, computation dimension, data dimension, and algorithm dimension. Transceiver module 1402 is also configured to send the resource-level QoS parameters to the execution network element.

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

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

[0430] Optionally, the transceiver module 1402 obtains the QoS parameters of the task, including: obtaining policies and billing control rules, the policies and billing 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 execution network element or task data flow that executes the task.

[0431] Optionally, the transceiver module 1402 is further configured to receive notification information from the execution network element, where the notification information is used to notify the execution network element that QoS requirements related to connection, calculation, data or algorithm cannot be met.

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

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

[0434] Optionally, the transceiver module 1402 is further configured to send notification information to the anchor network element, where the notification information is used to notify the execution network element that QoS requirements related to connection, calculation, data or algorithm cannot be met.

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

[0436] The transceiver module 1402 is configured to obtain the QoS parameters of the first service. The processing module 1401 is configured to perform task orchestration based on the QoS parameters of the first service, and obtain an orchestration result at the task granularity; the orchestration result includes the template description information and dependency relationships of the tasks obtained by decomposing and mapping the first service.

[0437] The transceiver module 1402 is configured to obtain the QoS parameters of the first service. The processing module 1401 is configured to perform task orchestration based on the QoS parameters of the first service, and obtain an orchestration result at the task granularity; the orchestration result includes the template description information and dependency relationships of the tasks obtained by decomposing and mapping the first service.

[0438] Optionally, the transceiver module 1402 is further configured to send an orchestration result to the anchor network element, where the orchestration result is used by the anchor network element to obtain task information, where the task information includes at least one of deployment information or topology information of the task.

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

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

[0441] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0442] Alternatively, the modules in FIG14 may also be referred to as units. For example, the processing module may be referred to as a processing unit, and the transceiver module may be referred to as a transceiver unit. In addition, in the embodiment shown in FIG14 , the names of the units may not be those shown in the figure. For example, the transceiver module may also be referred to as a communication module or a communication unit.

[0443] If the various units in Figure 14 are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (processor) to execute all or part of the steps of the method described in each embodiment of the present application. The storage medium for storing computer software products includes various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

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

[0445] In a simple embodiment, those skilled in the art may appreciate that the communication device 1400 may take the form of the communication device shown in FIG. 15 .

[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 of including a communication interface 1504 and a processor 1501), and may optionally also include a memory 1503.

[0447] The processor 1501 can be a general-purpose central processing unit (CPU), a microprocessor, an ASIC, or one or more integrated circuits for controlling the execution of the program of the present application.

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

[0449] Communication interface 1504 may be a transceiver module for communicating with other devices or communication networks, such as Ethernet, RAN, terminals, and wireless local area networks (WLANs). For example, the transceiver module may be a device such as a transceiver or a transceiver. Alternatively, communication interface 1504 may be a transceiver circuit or input / output interface within processor 1501, used to implement signal input and output to the processor.

[0450] The memory 1503 may be a device having a storage function. For example, it may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor via a communication line 1502. The memory may also be integrated with the processor.

[0451] The memory 1503 is used to store computer-executable instructions for executing the solution of the present application, and the execution is controlled by the processor 1501. The processor 1501 is used to execute the computer-executable instructions stored in the memory 1503, thereby implementing the communication method provided in the embodiment of the present application.

[0452] Alternatively, optionally, in an embodiment of the present application, the processor 1501 may also perform processing-related functions in the communication method provided in the following embodiments of the present application, and the communication interface 1504 is responsible for communicating with other devices or communication networks, which is not specifically limited in the embodiments of the present application.

[0453] Optionally, the computer-executable instructions in the embodiments of the present application may also be referred to as application code, which is not specifically limited in the embodiments of the present application.

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

[0455] In a specific implementation, as an embodiment, the communication device 1500 may include multiple processors, such as the processor 1501 and the processor 1507 in FIG15 . 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: a CPU, a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, and other types of computing devices that run software. Each computing device may include one or more cores for executing software instructions to perform calculations or processing.

[0456] In a specific implementation, as an 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 a variety of ways. For example, the output device 1505 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 1506 communicates with the processor 1501 and can receive user input in a variety of ways. For example, the input device 1506 can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0457] The communication device 1500 described above may sometimes also be referred to as a communication device, which may be a general-purpose device or a dedicated device. For example, the communication device 1500 may be the terminal device, access network device, or a device having a similar structure as shown in FIG15 . The embodiments of the present application do not limit the type of the communication device 1500.

[0458] In addition, the composition structure shown in Figure 15 does not constitute a limitation on the communication device. In addition to the components shown in Figure 15, the communication device 1500 may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0459] Optionally, the functions / implementation processes of the transceiver module 1402 and the processing module 1401 in FIG14 may be implemented by the processor 1501 in the communication device 1500 shown in FIG15 calling computer-executable instructions stored in the memory 1503. Alternatively, the functions / implementation processes of the processing module 1401 in FIG14 may be implemented by the processor 1501 in the communication device 1500 shown in FIG15 calling computer-executable instructions stored in the memory 1503, and the functions / implementation processes of the transceiver module 1402 in FIG14 may 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 the two. When any of the above modules or units is implemented in software, the software exists in the form of computer program instructions and is stored in a memory, and a processor can be used to execute the program instructions and implement the above method flow. The processor can be built into an SoC or ASIC, or it can be an independent semiconductor chip. In addition to the core used to execute software instructions to perform calculations or processing within the processor, it can 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, a microprocessor, a DSP chip, an MCU, an artificial intelligence processor, an ASIC, a SoC, an FPGA, a PLD, a dedicated digital circuit, a hardware accelerator or a non-integrated discrete device, which can run the necessary software or not rely on the software to execute the above method flow.

[0462] Optionally, an embodiment of the present application further provides a communication device (for example, the communication device may be a chip or a chip system), which includes a processor for implementing the method in any of the above method embodiments. In one possible design, the communication device also 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 method in any of the above method embodiments. Of course, the memory may not be in the communication device. When the communication device is a chip system, it may be composed of a chip, or it may include a chip and other discrete devices, which is not specifically limited in the embodiment of the present application.

[0463] Optionally, an embodiment of the present application also provides a computer-readable storage medium, which stores a computer program or instruction. When the computer program or instruction is run on a communication device, the communication device can execute the method described in any of the above method embodiments or any of its implementation methods.

[0464] Optionally, an embodiment of the present application further provides a communication system, which includes the network device described in the above method embodiment and the terminal device described in the above method embodiment.

[0465] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments can be implemented in the form of a computer program product. The 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 processes or functions according to the embodiments of the present application are 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 computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more media integrated therein. The available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid state drives (SSDs)).

[0466] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0467] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, the present application is intended to encompass such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

Claims

1. A communication method, characterized in that: The method comprises: Acquire task information and requirement information of the first service; the task information includes relevant information of the task obtained by decomposing and mapping the first service; generating a quality of service QoS parameter for the first service according to the requirement information of the first service; Generate the QoS parameters of the task according to the task information and the QoS parameters of the first service.

2. The method according to claim 1, characterized in that The obtaining the requirement information of the first service includes: Relevant information of the first service is obtained, where the relevant information of the first service includes one or more of the following: requirement information of the first service or 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.

3. The method according to claim 2, characterized in that The identification information of the first service includes at least one of the following: information of a user triggering the first service, information of a terminal device related to the first service, or information of an application service provider.

4. The method according to claim 2 or 3, characterized in that: Generating the QoS parameter of the first service according to the requirement information of the first service includes: A QoS template corresponding to the first service is generated according to the relevant information of the first service, where the QoS template includes a 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, wherein each set of QoS parameters has a different priority.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Send the QoS parameter 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 deployment information or topology information of the task.

8. The method according to any one of claims 1 to 7, characterized in that: The step of generating the QoS parameter of the task according to the task information and the QoS parameter of the first service comprises: Based on the task information and the QoS parameters of the first service, generate policy and charging control rules, the policy and charging rules including 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 flow that executes the task.

9. The method according to claim 8, characterized in that The policy and charging rules include at least one of the following: specific QoS requirement information related to the connection, an identifier indicating the specific QoS requirement related to the connection, information about the execution network element of the transmission starting point of the service data flow of the task, information about the execution network element of the transmission end point of the service data flow of the task, specific QoS requirement information related to calculation, an identifier indicating the specific QoS requirement related to calculation, information about the execution network element used to perform the calculation function, an identifier of the calculation subtask, the calculation type of the calculation subtask, specific QoS requirement information related to data, an identifier indicating the specific QoS requirement related to data, a data type, a data scale, specific QoS requirement information related to the algorithm, an identifier indicating the specific QoS requirement related to the algorithm, an algorithm type, an algorithm level, and an application method.

10. The method according to claim 9, characterized in that The policy and charging rules also include the type of business data flow of the task, and the type of business data flow includes calculation, data or algorithm type.

11. The method according to any one of claims 1 to 10, characterized in that: The method further comprises: 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, calculation dimension, data dimension and algorithm dimension.

12. A communication method, characterized in that: The method comprises: Get the QoS parameters of the task; Generate resource-level QoS parameters according to the QoS parameters of the task and the execution network element executing the task; the resource-level QoS parameters include at least one of the following: connection dimension, calculation dimension, data dimension and algorithm dimension; The resource-level QoS parameters are sent to the execution network element.

13. The method according to claim 12, characterized in that The task is obtained by decomposing and mapping the first service, and the QoS parameters of the task are obtained according to 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 of the task are obtained, including: Acquire a policy and charging control rule, wherein the policy and charging control rule includes a QoS parameter of the task, and a mapping relationship between the QoS parameter of the task and at least one of an execution network element or a task data flow that executes the task.

15. The method according to claim 14, characterized in that The policy and charging rules include at least one of the following: specific QoS requirement information related to the connection, an identifier indicating the specific QoS requirement related to the connection, information about the execution network element of the transmission starting point of the service data flow of the task, information about the execution network element of the transmission end point of the service data flow of the task, specific QoS requirement information related to calculation, an identifier indicating the specific QoS requirement related to calculation, information about the execution network element used to perform the calculation function, an identifier of the calculation subtask, the calculation type of the calculation subtask, specific QoS requirement information related to data, an identifier indicating the specific QoS requirement related to data, a data type, a data scale, specific QoS requirement information related to the algorithm, an identifier indicating the specific QoS requirement related to the algorithm, an algorithm type, an algorithm level, and an application method.

16. The method according to claim 15, characterized in that The policy and charging rules also include the type of business data flow of the task, and the type of business data flow includes calculation, data or algorithm type.

17. The method according to claim 15 or 16, characterized in that The QoS parameter of the connection dimension includes at least one of the following: the QoS specific requirement information related to the connection, the 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 flows corresponding to different QoS requirements; and / or, The QoS parameter of the computing dimension includes at least one of the following: the specific QoS requirement information related to the computing, the identifier indicating the specific QoS requirement related to the computing, and the computing subtask identification rule; wherein the computing subtask identification rule is used to distinguish computing subtasks corresponding to different QoS requirements; and / or, The QoS parameter of the data dimension includes 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 a 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 the algorithm subtasks corresponding to different QoS requirements.

18. The method according to any one of claims 12 to 17, characterized in that: The method further comprises: Notification information is received from the execution network element, where the notification information is used to notify the execution network element that a QoS requirement related to connection, calculation, data or algorithm cannot be met.

19. A communication method, characterized in that: The method comprises: Obtaining resource-level quality of service (QoS) parameters; the resource-level QoS parameters include parameters of at least one of the following dimensions: connection dimension, calculation dimension, data dimension, or algorithm dimension; The task is executed according to the QoS parameters of the resource level.

20. The method according to claim 19, characterized in that The resource-level QoS parameters are obtained based on the QoS parameters of the task, 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.

21. The method according to claim 19 or 20, characterized in that The QoS parameter of the connection dimension includes at least one of the following: the QoS specific requirement information related to the connection, the 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 flows corresponding to different QoS requirements; and / or, The QoS parameter of the computing dimension includes at least one of the following: the specific QoS requirement information related to the computing, the identifier indicating the specific QoS requirement related to the computing, and the computing subtask identification rule; wherein the computing subtask identification rule is used to distinguish computing subtasks corresponding to different QoS requirements; and / or, The QoS parameter of the data dimension includes 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 a 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 the algorithm subtasks corresponding to different QoS requirements.

22. The method according to any one of claims 19 to 21, characterized in that: The execution network element is a terminal device.

23. The method according to any one of claims 1 to 22, characterized in that: The first service is an artificial intelligence (AI) service, a computing service, a data service or a perception service.

24. A communication method, characterized in that: The method comprises: Obtaining a quality of service (QoS) parameter of the first service; Perform task orchestration according to the QoS parameter of the first service to obtain an orchestration result, wherein the orchestration result includes template description information and dependency relationships of the tasks obtained by decomposing and mapping the first service.

25. The method according to claim 24, characterized in that The method further comprises: The orchestration result is sent to the anchor network element, where the orchestration result is used by the anchor network element to obtain task information, where the task information includes at least one of deployment information or topology information of the task.

26. The method according to claim 24 or 25, characterized in that The obtaining of the QoS parameter of the first service includes: A QoS template corresponding to the first service is obtained, where the QoS template includes a mapping relationship between a QoS parameter of the first service and identification information of the first service.

27. The method according to any one of claims 24 to 26, characterized in that: The QoS parameters of the first service include multiple sets of QoS parameters, and each set of QoS parameters in the multiple sets of QoS parameters has a different priority.

28. The method according to any one of claims 24 to 27, characterized in that: The obtaining the QoS parameter of the first service and performing task scheduling according to the QoS parameter of the first service includes: Obtain a first-priority QoS parameter of the first service, and perform task scheduling according to the first-priority QoS parameter.

29. The method according to claim 28, characterized in that The method further comprises: In the case that the scheduling according to the QoS parameters of the first priority fails, the QoS parameters of the second priority of the first service are obtained, and the task scheduling is performed according to the QoS parameters of the second priority.

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

31. An anchor network element, characterized in that: The anchor network element comprises a module or unit for executing the method according to any one of claims 12-18.

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

33. A task scheduling network element, characterized in that: The task orchestration network element comprises a module or unit for executing the method according to any one of claims 24-29.

34. A communication device, characterized in that: The communication device comprises: a processor; the processor is used to execute a computer program or instruction stored in a memory, so that the communication device performs the method as described in any one of claims 1-11 or 12-18 or 19-23 or 24-29.

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

36. A computer-readable storage medium, characterized in that: A computer program or instruction is stored thereon, and when the computer program or instruction is executed by a computer, the computer is caused to execute the method according to any one of claims 1-11 or 12-18 or 19-23 or 24-29.

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

38. A communication system, characterized in that: The communication system includes a policy control function network element, an anchor network element and an execution network element; The policy control function network element is used to obtain task information and requirement information of the first service, generate a quality of service QoS parameter of the first service according to the requirement information of the first service, generate a QoS parameter of the task according to the task information and the QoS parameter of the first service, and send the QoS parameter of the task to the anchor network element; wherein the task information includes relevant information of the task obtained by decomposing and mapping the first service; The anchor network element is used to receive the QoS parameters of the task from the policy control function network element and execute the task according to the The execution network element of the task generates a resource-level QoS parameter, and sends the resource-level QoS parameter to the execution network element; the resource-level QoS parameter includes at least one of the following: a connection dimension, a calculation dimension, a data dimension, and an 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 according to claim 38, characterized in that The policy control function network element is further used to execute the method described in any one of claims 2-11, the anchor network element is further used to execute the method described in any one of claims 13-18, and the execution network element is further used to execute the method described in any one of claims 20-23.

40. The method according to claim 38 or 39, characterized in that The communication system further includes a task orchestration network element, and the task orchestration network element is used to execute the method described in any one of claims 24-29.

Images