Communication method and communication device

By employing a layered distributed orchestration architecture and collaborative GSO, DSO, FLM, and SM, flexible business orchestration is achieved, addressing the lack of flexibility in existing orchestration methods and improving orchestration efficiency and data privacy and security.

CN120979969APending Publication Date: 2025-11-18HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410622487.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-05-17
Publication Date
2025-11-18

AI Technical Summary

Technical Problem

Existing service orchestration methods are not flexible enough to meet the flexible orchestration needs in complex network environments.

Method used

It adopts a hierarchical distributed orchestration architecture, supports business orchestration in script, code, and semantic form through the collaboration of GSO and DSO, and uses FLM and SM for function management and state management to realize the collaborative work of distributed orchestrators.

Benefits of technology

It enhances the flexibility and efficiency of business orchestration, especially in large-scale, sudden, and real-time business scenarios, enabling timely orchestration, resolving the bottleneck of centralized orchestration, and ensuring data privacy and security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120979969A_ABST
    Figure CN120979969A_ABST
Patent Text Reader

Abstract

Provided are a communication method and a communication device, the communication method comprising: a first functional entity sending first information to a third functional entity, the first information indicating a supported arrangement type; the first functional entity receives second information sent by the third functional entity, the second information comprises a to-be-arranged service, and the type of the to-be-arranged service belongs to the supported arrangement type; and the first functional entity arranges the to-be-arranged service. In the method, the first functional entity can provide a plurality of supported arrangement types for the third functional entity to select, so that the flexibility of service arrangement is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a communication method and a communication device. Background Technology

[0002] With the development of communication technology, distributed collaboration between endpoints, networks, and the cloud is an inevitable trend. As network applications become increasingly complex, an application may consist of multiple applications or functions. Orchestration is a common engineering practice to organize these tasks into workflows. Therefore, it is essential to properly orchestrate business processes before execution. However, existing orchestration methods lack flexibility. Therefore, improving the flexibility of business orchestration is a pressing issue that needs to be addressed in this field. Summary of the Invention

[0003] This application provides a communication method and a communication device that can improve the flexibility of service orchestration.

[0004] In a first aspect, a communication method is provided. This method is applied to a first functional entity. Unless otherwise specified, the "first functional entity" in this application may refer to the first functional entity itself (e.g., a device including a domain service orchestration (DSO), a function libmanagement (FLM), a status management (SM), and a scheduler), or a component in the first functional entity (e.g., a processor, a chip, or a chip system), or a logical module or software that can implement all or part of the functions of the first functional entity.

[0005] It should be understood that in the scenario where the first functional entity itself is capable of performing orchestration tasks in the embodiments of this application, the first functional entity may also include GSO, FLM, SM and scheduler, that is, the first functional entity may include DSO or GSO, wherein DSO and GSO can be collectively referred to as service orchestration (SO).

[0006] This application proposes a hierarchical distributed orchestration architecture, which may include a Group Service Optimizer (GSO) and a Distributed Service Optimizer (DSO). The GSO can be deployed on the core network side, network management side, etc., while one or more DSOs can be deployed on the core network side, edge side, etc. Edge side deployments include mobile edge computing (MEC) or radio access network (RAN). When a user orchestration request originates from the endpoint or edge side, the orchestration request can be directly sent to the DSO in that area for timely orchestration. When a user orchestration request originates from the cloud side, the orchestration request can be directly sent to the cloud-side DSO or cloud-side GSO for timely orchestration by the cloud-side orchestration function entity. When a user orchestration request originates from the endpoint or edge side, the orchestration request can be directly sent to the DSO in that area. During service orchestration, the DSO may find insufficient capabilities; for example, if the DSO finds that some functions in a service are not available in that area, the DSO can request the GSO to assist in completing the orchestration of that service.

[0007] The method includes: sending first information, the first information indicating a supported orchestration type; receiving second information, the second information including a service to be orchestrated, the type of the service to be orchestrated belonging to a supported orchestration type; and orchestrating the service to be orchestrated.

[0008] Specifically, the second information can be an orchestration request, in which the orchestration request interface specifies the orchestration type. For example, for script-based orchestration services, the orchestration request interface specifies the orchestration type as type1; for code-based orchestration services, the orchestration request interface specifies the orchestration type as type2; and for semantic-based orchestration services, the orchestration request interface specifies the orchestration type as type3. The third functional entity can send an orchestration request to the first functional entity based on the first information sent by the first functional entity, i.e., the orchestration types supported by the first functional entity.

[0009] In this embodiment, the first functional entity can send first information to the third functional entity to indicate the orchestration types it supports. The third functional entity can determine a suitable orchestration type from the orchestration types supported by the first functional entity according to its own capabilities or business needs, and send the service to be orchestrated of that type to the first functional entity for orchestration. The first functional entity can provide multiple supported orchestration types for the third functional entity to choose from, thus improving the flexibility of service orchestration.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, the supported orchestration types include at least one of the following: script form, code form, and semantic form.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the first information and / or the second information are carried in Non-Access Stratum (NAS) signaling or Radio Resource Control (RRC) signaling.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, receiving the second information includes: receiving the second information through a first interface, wherein the first interface is used to receive information corresponding to any type among the supported orchestration types.

[0013] Specifically, the SO in the first functional entity can provide a unified orchestration request interface to the third functional entity. For example, the first interface can support various types of orchestration requests, such as script, code, and semantic forms.

[0014] In this embodiment of the application, the first interface is used to receive information corresponding to any type among the supported orchestration types. It can be understood that the first functional entity provides a unified orchestration interface to the outside world. For example, through standardized formulation, the orchestration interface can receive information corresponding to services in script form, code form and semantic form, so that the first functional entity can flexibly support the orchestration needs of various users such as third parties, network internals or consumers, and expand the ecosystem of orchestration services.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: obtaining network environment status information; and orchestrating services, including: orchestrating the services to be orchestrated based on the network environment status information.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: obtaining third information, the third information indicating the functions required to implement the business; and orchestrating the business to be orchestrated, including: orchestrating the business to be orchestrated based on the third information.

[0017] Specifically, the SO in the first functional entity can interact with FLM, and the SO can obtain the functions required by the business from FLM.

[0018] Scenario 1: The DSO itself has the ability to orchestrate business processes, and the business processes to be orchestrated are in the form of scripts.

[0019] For example, the DSO sends a message to the FLM on the edge side to request the FD (function description) and SD (service description) files corresponding to the service based on the information obtained by parsing the orchestration request information. The message may contain the service name and the service description file name.

[0020] Furthermore, the FLM on the edge side parses the service description file name in the message sent by the DSO, queries the SD corresponding to the name in the local FLM, parses the SD information, and queries the FD that the SD depends on.

[0021] Furthermore, the FLM on the edge side sends the queried SD and FD files to the DSO.

[0022] Scenario 2: The DSO itself has the ability to orchestrate business logic, and the business logic to be orchestrated is in the form of code.

[0023] For example, the DSO sends a message to the FLM on the edge side to request the FD and SD files corresponding to the service based on the information obtained by parsing the orchestration request information. The message may contain the service name and the name corresponding to the code.

[0024] Furthermore, the FLM on the edge side parses the message sent by the DSO to obtain the name of the service and the name corresponding to the code. It then queries the local FLM for the SD and FD files corresponding to the service name and code. These SD and FD files are generated by the FLM based on the information in the service code.

[0025] Furthermore, the FLM on the edge side sends the queried SD and FD files to the DSO.

[0026] Scenario 3: The DSO itself has the ability to orchestrate business operations, and the business operations to be orchestrated are in semantic form.

[0027] For example, the DSO outputs a corresponding task plan based on the acquired status information and business orchestration request information, generating N tasks, each with corresponding functional requirements.

[0028] Furthermore, the DSO sends a request message to the local FLM. Since the DSO needs to match tasks to the corresponding functions, this request message contains the functional requirements for each task.

[0029] Furthermore, after receiving the request message, the local FLM performs a similarity matching between the task and the function. That is, it performs a similarity detection between the functional requirements corresponding to the task and the functional descriptions of each function in the FLM. The function with the highest similarity is taken as the function of the task, and finally the functions corresponding to the above N tasks are obtained.

[0030] Furthermore, the local FLM sends the matched function set, i.e. the functions corresponding to the above N tasks, to the DSO. The function set includes the function name and resource requirements (e.g., computing power, network, data, algorithm, etc.) corresponding to each task.

[0031] Optionally, the information corresponding to the service by the FLM in the first functional entity is sent to the FLM in the second functional entity (e.g., CN) described below. After receiving this information, the FLM in the second functional entity can record that the file originates from the edge side, and this information can be used in the DSO-GSO collaborative orchestration scenario described below.

[0032] In combination with the first aspect, in some implementation manners of the first aspect, the method further includes: obtaining fourth information, where the fourth information indicates the functions required for M tasks among N tasks for implementing the to-be-orchestrated service, M is an integer greater than or equal to 0, N is a positive integer, and M is less than N; sending fifth information to the second functional entity, where the fifth information is used to request sixth information, and the sixth information indicates the functions required for N-M tasks among the N tasks; receiving the sixth information sent by the second functional entity; and performing orchestration on the to-be-orchestrated service, including: performing orchestration on the to-be-orchestrated service according to the fourth information and the sixth information.

[0033] It should be understood that, without special indication, the "second functional entity" in this application can refer to the second functional entity itself (e.g., a device including global service orchestration (GSO), FLM, SM, scheduler), or a component in the second functional entity (e.g., a processor, a chip, or a chip system, etc.), or can also be a logic module or software that can implement all or part of the functions of the second functional entity.

[0034] Specifically, DSO can send an assistance orchestration request to GSO, and the request information can include some or all of the functions in the to-be-orchestrated service of the first functional entity.

[0035] Exemplarily, for an orchestration task in the form of a script or code, the functions required for the to-be-orchestrated service include N functions, and the area where DSO is located can provide M functions among the N functions. That is, after the DSO on the edge side receives the fourth information, it does not obtain the SD and FD files corresponding to the remaining N-M functions from the FLM side, so it indicates that its orchestration ability is insufficient, and directly sends an assistance orchestration request message to the cloud-side GSO. The message includes the service name and the name corresponding to the SD.

[0036] Exemplarily, for an orchestration task in the semantic form, when DSO receives a function set (including M tasks), since M < N, it indicates that the DSO ability is insufficient, and the functions corresponding to some tasks on this edge side are not in the FLM in this area. Therefore, DSO sends an assistance orchestration request to the cloud side. The request message includes N-M tasks, including the functional requirement information of each task.

[0037] In this embodiment, the first functional entity can obtain fourth information, which only indicates the functions required to implement some tasks in the service to be orchestrated, meaning the first functional entity's own orchestration capabilities are insufficient. At this point, the first functional entity can request assistance from the second functional entity and receive sixth information, which indicates the functions required to implement the remaining tasks in the service to be orchestrated. Furthermore, the first functional entity can achieve service orchestration with the assistance of the second functional entity. This distributed orchestration architecture ensures that the first functional entity can ultimately achieve service orchestration. Simultaneously, when the first functional entity has the capability, it can also implement service orchestration independently, thereby solving the bottleneck of centralized orchestration and improving service orchestration efficiency, particularly for large-scale, sudden, real-time services in the network.

[0038] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending template information; receiving seventh information, the format of which is determined according to the template information, the seventh information including: a function file associated with the business, a business description file and a function description file, or code associated with the business.

[0039] Specifically, for certain types of orchestration services, after receiving the first information, the third functional entity obtains specific type template information from the DSO in the first functional entity.

[0040] For example, for script-based orchestration requirements, the third functional entity can develop / encapsulate functional modules for all functions in the business based on script-based template information, ensuring that the function can be executed in the edge-cloud distributed network. The information corresponding to the business sent by the third functional entity can be a function file, a business description file (SD), or a function description file (FD), etc.

[0041] For example, for code-based orchestration requirements, the third functional entity can develop the standalone code corresponding to the business based on the template information in the form of code. The information corresponding to the business sent by the third functional entity can be a standalone code file, which can contain various functions corresponding to the business and the calls to each function.

[0042] In conjunction with the first aspect, in some implementations of the first aspect, the first functional entity is able to obtain the arrangement information of the region where the first functional entity is located.

[0043] In this embodiment, the first functional entity can obtain only the orchestration information of the region. For orchestration services that only require functions within the region, the first functional entity can perform the orchestration itself without reporting to the global service orchestrator, which can improve the efficiency of service orchestration, especially the orchestration efficiency of large-scale bursty real-time services in the network. In addition, deploying the first functional entity in a specific region can solve the problem of third-party services not leaving the specific region.

[0044] In conjunction with the first aspect, in some implementations of the first aspect, the first functional entity is deployed at an edge node, which includes a mobile edge computing (MEC) or a radio access network (RAN).

[0045] In this embodiment, the first functional entity is deployed on the edge node. The first functional entity can only know the orchestration information within the area of ​​the edge node, which is conducive to realizing a distributed orchestration architecture and can improve the efficiency of service orchestration, especially the orchestration efficiency of large-scale burst real-time services in the network.

[0046] Secondly, a communication method is provided, which is applied to a third functional entity. Unless otherwise specified, the "third functional entity" in this application may refer to the third functional entity itself (e.g., a device for providing user requirements), a component in the third functional entity (e.g., a processor, chip, or chip system), or a logic module or software that can implement all or part of the functions of the third functional entity. The method includes: receiving first information, the first information indicating a supported orchestration type; and sending second information, the second information indicating a service to be orchestrated, the type of which belongs to the supported orchestration type.

[0047] In conjunction with the second aspect, in some implementations of the second aspect, the supported orchestration types include at least one of the following: script form, code form, and semantic form.

[0048] In conjunction with the second aspect, in some implementations of the second aspect, the first information and / or the second information are carried in Non-Access Stratum (NAS) signaling or Radio Resource Control (RRC) signaling.

[0049] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: receiving template information; sending seventh information, the format of which is determined according to the template information, and the seventh information includes: a function file associated with the business, a business description file, and a function description file, or code associated with the business.

[0050] The technical effects of the methods shown in the second aspect and its possible designs above can be referred to the technical effects in the first aspect and its possible designs.

[0051] Thirdly, a communication device is provided, comprising: a transceiver unit for transmitting first information, the first information indicating a supported orchestration type; the transceiver unit is further configured to receive second information, the second information including a service to be orchestrated, the type of the service to be orchestrated belonging to a supported orchestration type; the device further comprising: a processing unit for orchestrating the service to be orchestrated.

[0052] In conjunction with the third aspect, in some implementations of the third aspect, the supported orchestration types include at least one of the following: script form, code form, and semantic form.

[0053] In conjunction with the third aspect, in some implementations of the third aspect, the first information and / or the second information are carried in Non-Access Stratum (NAS) signaling or Radio Resource Control (RRC) signaling.

[0054] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is also used to receive second information through the first interface, which is used to receive information corresponding to any type among the supported orchestration types.

[0055] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is also used to acquire network environment status information; the processing unit is also used to orchestrate the services to be orchestrated based on the network environment status information.

[0056] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is also used to acquire third information, which indicates the functions required to implement the business; the processing unit is also used to arrange the business to be arranged according to the third information.

[0057] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is also used to obtain fourth information, which indicates the functions required to implement M tasks out of N tasks of the service to be orchestrated, where M is an integer greater than or equal to 0, N is a positive integer, and M is less than N; the transceiver unit is also used to send fifth information to the second functional entity, which is used to request sixth information, which indicates the functions required to implement NM tasks out of N tasks; the transceiver unit is also used to receive the sixth information sent by the second functional entity; the processing unit is also used to orchestrate the service to be orchestrated based on the fourth and sixth information.

[0058] In conjunction with the third aspect, in some implementations of the third aspect, the transceiver unit is also used to send template information; the transceiver unit is also used to receive the seventh information, the format of which is determined according to the template information, and the seventh information includes: a function file associated with the business, a business description file and a function description file, or code associated with the business.

[0059] In conjunction with the third aspect, in some implementations of the third aspect, the device is able to obtain the arrangement information of the region where the first functional entity is located.

[0060] In conjunction with the third aspect, in some implementations of the third aspect, the device is deployed at an edge node, which includes a mobile edge computing (MEC) or a radio access network (RAN).

[0061] Fourthly, a communication device is provided, comprising: a transceiver unit for receiving first information, the first information indicating a supported orchestration type; the transceiver unit is further configured to transmit second information, the second information indicating a service to be orchestrated, the type of the service to be orchestrated belonging to a supported orchestration type.

[0062] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the supported orchestration types include at least one of the following: script form, code form, and semantic form.

[0063] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first information and / or the second information are carried in Non-Access Stratum (NAS) signaling or Radio Resource Control (RRC) signaling.

[0064] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the transceiver unit is also used to receive template information; the transceiver unit is also used to send seventh information, the format of which is determined according to the template information, and the seventh information includes: a function file associated with the business, a business description file and a function description file, or code associated with the business.

[0065] Fifthly, a communication system is provided, the communication system including a first functional entity provided in the first aspect, the first functional entity being used to perform the method of any one of the first aspects, the communication system further including a second functional entity provided in the first aspect, the second functional entity being capable of obtaining global orchestration information.

[0066] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the second functional entity is able to deploy and / or remove the first functional entity from the network.

[0067] A sixth aspect provides a communication device comprising: a processor coupled to a memory for storing a computer program, the processor for running the computer program such that the communication device performs the method described in the first aspect and any possible implementation thereof.

[0068] A seventh aspect provides a communication device comprising: a processor coupled to a memory for storing a computer program, the processor for running the computer program such that the communication device performs the method described in the second aspect and any possible implementation thereof.

[0069] Eighthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a computer, causes the computer to perform the communication methods that can be implemented in the first aspect and any of the first aspect, or the second aspect and any of the second aspect.

[0070] Ninthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the communication method that can be implemented in the first aspect and any of the first aspect, or the second aspect and any of the second aspect.

[0071] In a tenth aspect, a chip is provided, the chip including a processor and a data interface, the processor reading instructions stored in a memory through the data interface to execute the communication methods implemented in the first aspect and any of the first aspect, or the second aspect and any of the second aspect.

[0072] In conjunction with the tenth aspect, in one possible implementation, the processor is coupled to the memory via an interface.

[0073] In conjunction with the tenth aspect, in one possible implementation, the chip system further includes a memory in which computer programs or computer instructions are stored. Attached Figure Description

[0074] Figure 1 This is a business process diagram applicable to an embodiment of this application.

[0075] Figure 2 This is a schematic diagram of the MANO architecture.

[0076] Figure 3 This is a schematic diagram of a global service orchestration function provided in an embodiment of this application.

[0077] Figure 4 This is a schematic diagram of a regional service orchestration function provided in an embodiment of this application.

[0078] Figure 5 This is a layered distributed orchestration architecture provided in the embodiments of this application.

[0079] Figure 6 This is a schematic diagram of a function library management provided in an embodiment of this application.

[0080] Figure 7 This is a schematic diagram of a state management system provided in an embodiment of this application.

[0081] Figure 8 This is a schematic diagram of a scheduling function provided in an embodiment of this application.

[0082] Figure 9 This is a flowchart of a communication method provided in an embodiment of this application.

[0083] Figure 10 This is a schematic diagram of a script-based functional description file provided in an embodiment of this application.

[0084] Figure 11This is a schematic diagram of a script-based business description file provided in an embodiment of this application.

[0085] Figure 12 This is a business orchestration method provided in the embodiments of this application.

[0086] Figure 13 This is another service orchestration method provided in the embodiments of this application.

[0087] Figure 14 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application.

[0088] Figure 15 This is a schematic diagram of a communication architecture provided in an embodiment of this application.

[0089] Figure 16 This is a schematic diagram of a chip system 1600 provided in an embodiment of this application. Detailed Implementation

[0090] To facilitate understanding of the embodiments of this application, the following points will be explained first.

[0091] First, in this application, "for indicating" can include both direct and indirect indication. When describing an indication message as indicating A, it can include whether the indication message directly indicates A or indirectly indicates A, but does not necessarily mean that the indication message carries A.

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

[0093] Second, in this application, "at least one" refers to one or more, and "more than one" refers to two or more (including two). Furthermore, in the embodiments of this application, "first," "second," and various numerical designations (e.g., "#1," "#2," etc.) are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The sequence numbers of the processes below do not imply an order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. It should be understood that the objects described in this way can be interchanged where appropriate to describe solutions other than those in the embodiments of this application. Moreover, in the embodiments of this application, terms such as "S910" are merely identifiers for descriptive convenience and do not limit the order of execution steps.

[0094] Third, in the embodiments of this application, the words "exemplary" or "for example" are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design that is described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design options. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0095] Fourth, the term "storage" in the embodiments of this application can refer to storage in one or more memories. These memories can be separate installations or integrated into an encoder, decoder, processor, or communication device. Alternatively, some memories can be separately installed, while others are integrated into the processor or communication device. The type of memory can be any form of storage medium, and this application does not limit this.

[0096] Fifth, in the implementation of this application, "protocol" may refer to standard protocols in the field of communications, such as the NR protocol and related protocols applied in future communication systems, and this application does not limit it.

[0097] Sixth, in the embodiments of this application, the terms "of", "corresponding (relevant)", "corresponding", and "associate" can sometimes be used interchangeably. It should be noted that when their differences are not emphasized, their intended meanings are consistent.

[0098] Seventh, in the embodiments of this application, "under the circumstances", "when", and "if" can sometimes be used interchangeably. It should be noted that when the distinction is not emphasized, their intended meanings are consistent.

[0099] Eighth, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0100] Ninth, in this article, "message", "information", or "information element (IE)" can be used interchangeably. There are no restrictions on the name of the message or information, as long as it can achieve the corresponding function.

[0101] With the development of communication technology, from basic voice communication in the 1G era, to voice and text communication in the 2G era, to multimedia applications in the 3G era (such as music, graphics, and video), to mobile internet applications in the 4G era (such as live streaming, mobile shopping, and mobile social networking), and to the Internet of Things in the 5G era (such as connected vehicles, drones, industrial remote control, and smart grids), more and more applications will achieve intelligence through AI. In the future, the application scope of AI will be even wider in the era of future communication networks. Currently, AI services are mainly executed in cloud, edge, and cloud / edge environments.

[0102] With technological advancements, in future networks, to achieve the Internet of Things, massive amounts of data will originate from the terminal side. However, compared to the network side, terminal capabilities are limited, and in many scenarios, network-side computational assistance is required. Therefore, a significant amount of data needs to be transmitted between the terminal and network sides during collaboration. Furthermore, future services will include numerous AI models, and the size of AI models will grow exponentially with development. Especially with the emergence of large models, there is an urgent need for distributed computing / transmission from the perspectives of real-time performance, computational complexity, and computing power requirements. For the terminal or edge side, its computing power is increasingly enhanced and its services are diversified, thus enabling collaborative computing capabilities. For mobile communication systems, future networks possess advanced communication capabilities and collaborative transmission capabilities. Therefore, distributed collaboration between terminals, networks, and the cloud is an inevitable trend for the future.

[0103] In future network scenarios, the following main challenges will arise: 1) Applications will become increasingly complex, potentially consisting of multiple components or functions. For example, robot collaboration involves multiple steps such as data acquisition, 3D mapping, localization, and navigation, many of which may be implemented using AI algorithms. Therefore, an application faces the challenge of how to translate this into practical engineering solutions. 2) Engineering: To engineer applications, industry and academia use orchestration to structure tasks into workflows, where each task requires specific functionalities. Therefore, proper orchestration of the application before deployment on distributed computing nodes is essential.

[0104] Figure 1 This is a business process diagram applicable to embodiments of this application. The business process diagram includes N tasks, the inputs and outputs of the tasks constituting the dependencies between tasks, and the resource requirements of each task. Resource requirements may include network, computing power, algorithm, data, etc. Specific resource requirements for each task are shown in Table 1. Please refer to... Figure 1 , Figure 1 A business process diagram containing 5 tasks can be represented in the diagram.

[0105]

[0106] Table 1

[0107] In future edge-cloud collaboration scenarios, a large number of real-time services will emerge, with high real-time requirements and strong network dynamics. For example, network computing power, network transmission, and network topology will continuously change, and the network scale will be large. With edge devices participating in collaboration, nodes in the edge-cloud distributed network are widely distributed, and many service demands originate from the edge. Therefore, proper orchestration of services before deployment to computing nodes is essential. Thus, in edge-cloud distributed networks, a suitable orchestration architecture and methodology need to be designed to meet the needs of the distributed network and the services required.

[0108] However, existing orchestration methods lack flexibility. Therefore, embodiments of this application provide a communication method and apparatus, wherein the orchestrator can indicate the supported orchestration types to the requester, and the requester can send orchestration tasks of the corresponding type based on the indication, thereby improving the flexibility of service orchestration.

[0109] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0110] Figure 3 This is a schematic diagram of a global service orchestration function provided in an embodiment of this application.

[0111] Figure 4This is a schematic diagram of a regional service orchestration function provided in an embodiment of this application.

[0112] Please refer to Figure 3 and Figure 4 The technical solution of this application embodiment can be applied to edge-cloud distributed network architecture scenarios. This solution allows for the deployment of layered distributed orchestration functions, such as global service orchestration (GSO) and / or domain service orchestration (DSO). In this application embodiment, DSO and GSO can be collectively referred to as service orchestration (SO). When a user orchestration request originates from the endpoint or edge, the orchestration request can be directly sent to the DSO of that region for timely orchestration. When a user orchestration request originates from the cloud, the orchestration request can be directly sent to the cloud-side DSO or cloud-side GSO for timely orchestration by the cloud-side orchestration function entity. When a user orchestration request originates from the endpoint or edge, the orchestration request can be directly sent to the region's DSO. During the service orchestration process, the DSO may find insufficient capabilities; for example, if the DSO finds that some functions in a service are not available in that region, the DSO can request the GSO to assist in completing the orchestration of that service.

[0113] Furthermore, the above methods enable most service orchestration to be completed within the region. That is, for real-time services, service orchestration can be completed in real time. On the one hand, this can reduce the bottleneck of centralized orchestration and improve the service experience. On the other hand, for third-party services that do not leave the local area, it can better guarantee the privacy and security of their data, and provide better services for the network itself, consumers, and enterprises.

[0114] In this embodiment of the application, the "end" in the edge-cloud distributed network architecture refers to the terminal side, which may include mobile phones, computers, tablets, drones, robots, automobiles, industrial equipment, etc. The terminal side can provide certain computing resources to participate in the collaboration; the "edge" refers to the edge node, that is, the base station side in the network. Edge nodes may include terrestrial base stations or non-terrestrial base stations. Non-terrestrial base stations include satellites, temporarily deployed drone base stations, etc., or edge nodes may also include computing nodes or clusters deployed on the edge side, which have certain computing resources; the "cloud" refers to computing cloud resources in the network or computing resources deployed on the core network side, etc.

[0115] Figure 5 This is a layered distributed orchestration architecture provided in an embodiment of this application. Please refer to... Figure 5A layered distributed orchestration architecture can include GSO and DSO. GSO can be deployed on the core network side, network management side, etc., while one or more DSOs can be deployed on the core network side, edge side, etc. Edge side includes mobile edge computing (MEC) or radio access network (RAN).

[0116] In this embodiment, both the GSO and DSO have the following functions: providing a unified orchestration request interface to the network itself and external entities such as operators, third parties, and consumers, supporting service orchestration. This unified orchestration request interface supports orchestration of various service types, primarily scripts, code, and semantics. The orchestration function performs reasonable service orchestration based on the orchestration requirements of different service types and outputs corresponding service flowcharts. In addition to the above functions, when the DSO's capabilities are insufficient, it needs to send a request to the GSO, and the two collaborate to complete the service orchestration. The network side can dynamically deploy and / or delete DSOs based on service requirements.

[0117] In the edge-cloud distributed network of this application embodiment, in addition to deploying a hierarchical distributed orchestration architecture, it may also include network function management (FLM), status management (SM), and scheduler.

[0118] Figure 6 This is a schematic diagram of a function library management provided in an embodiment of this application. Please refer to it. Figure 6 For example, users such as the network itself, operators, third parties, and consumers upload information such as functions or code, function descriptions, and service descriptions to FLM. FLM checks the standardization and rationality of the received information, and while saving the functions or code, function descriptions, and service descriptions, it registers the functions, extracts features from the function descriptions and / or service descriptions, and classifies the functions or services. At the same time, FLM has the ability to manage the functions corresponding to the services, such as adding and deleting functions in FLM.

[0119] Figure 7 This is a schematic diagram of a state management system provided in an embodiment of this application. Please refer to it. Figure 7 The SM (Service Manager) can collect multi-dimensional status information in a distributed network, such as resource information of computing nodes, including network, computing power, data, algorithms, and sensing status information, as well as the execution status of services and / or tasks deployed in computing nodes. The SM can also provide various network status information for other functional nodes; for example, it can provide status information for global or regional service orchestration functions and scheduling functions deployed in the network.

[0120] Figure 8 This is a schematic diagram of a scheduling function provided in an embodiment of this application. Please refer to it. Figure 8 The scheduling function schedules each task in the business process diagram based on the multi-dimensional state information obtained from the current state management function entity, and assigns the tasks to appropriate end, edge, and cloud computing power nodes for execution. At the same time, the scheduling function is responsible for the lifecycle management of tasks. For example, the scheduling function can be responsible for tasks such as creation, deletion, and modification.

[0121] Optionally, functional entities deployed at the edge (e.g., RAN or MEC) or in the cloud (e.g., core network, CN), such as DSO, GSO, FLM, SM, and Scheduler, can send registration information to the network repository function (NRF). The NRF is an existing functional entity in the core network responsible for registering functional services and monitoring their status. The registration information may include the functional entity's type, address, and service information. Upon receiving the registration information, the NRF can manage these registered functional entities.

[0122] Figure 9 This is a flowchart of a communication method 900 provided in an embodiment of this application, as shown below. Figure 9 As shown, method 900 may include at least the following steps:

[0123] S910, the first functional entity sends first information, and correspondingly, the third functional entity receives the first information sent by the first functional entity. The first information indicates the orchestration type supported by the first functional entity.

[0124] In this embodiment of the application, the first functional entity may refer to the first functional entity itself, including DSO, FLM, SM and scheduler. In specific implementation, the first functional entity may be deployed on the core network or data network (DN) on the cloud side. In specific implementation, the first functional entity may also be deployed on the MEC or RAN on the edge side. The first functional entity may also refer to the components in the first functional entity (e.g., processor, chip, or chip system, etc.), or it may be a logical module or software that can implement all or part of the functions of the first functional entity.

[0125] For example, in the first functional entity, the FLM can be responsible for the management of the regional function library. Edge users can submit information such as services and functions to the edge FLM. The SM can be responsible for the status management of the regional network. That is, the SM can obtain status information such as the nodes and task execution in the regional network environment. The scheduler can be used to schedule tasks, that is, to reasonably schedule the tasks in the business process diagram orchestrated by the DSO or GSO.

[0126] Optionally, the first functional entity can obtain the arrangement information of the area where the first functional entity is located.

[0127] In this embodiment, the first functional entity can obtain only the orchestration information of the region. For orchestration services that only require functions within the region, the first functional entity can perform the orchestration itself without reporting to the global service orchestrator, which can improve the efficiency of service orchestration, especially the orchestration efficiency of large-scale bursty real-time services in the network. In addition, deploying the first functional entity in a specific region can solve the problem of third-party services not leaving the specific region.

[0128] Optionally, the first functional entity is deployed at an edge node, which may include a mobile edge computing (MEC) or a radio access network (RAN).

[0129] In this embodiment, the first functional entity is deployed on the edge node. The first functional entity can only know the orchestration information within the area of ​​the edge node, which is conducive to realizing a distributed orchestration architecture and can improve the efficiency of service orchestration, especially the orchestration efficiency of large-scale burst real-time services in the network.

[0130] For example, when the network itself, third parties, or consumers directly submit service orchestration requests to the DSO in the first functional entity, the DSO is responsible for the orchestration of the service. When the DSO's orchestration function is insufficient, the DSO can send an assistance orchestration request to the GSO, and the DSO and GSO jointly complete the service orchestration.

[0131] In this embodiment of the application, the service orchestration adopts a layered distributed architecture. By deploying DSO on the edge side, when the orchestration requester on the end or edge side has an orchestration requirement, it can directly send an orchestration request to the DSO on the edge side. When the network scale is large and there are many orchestration requirements, the distributed orchestration architecture can solve the bottleneck of centralized orchestration, improve orchestration efficiency, and especially improve the orchestration efficiency of large-scale bursty real-time services in the network.

[0132] In the embodiments of this application, the second functional entity mentioned below may refer to the second functional entity itself, including GSO, FLM, SM and scheduler. In specific implementation, the second functional entity may be deployed on the core network on the cloud side or the management plane on the network management side. The second functional entity may also refer to the components in the second functional entity (e.g., processor, chip, or chip system, etc.), or it may be a logical module or software that can implement all or part of the functions of the second functional entity.

[0133] For example, when edge users such as the network itself, third parties, or consumers directly submit service orchestration requests to the GSO, the GSO can be responsible for the orchestration of the service. When the DSO sends an assistance orchestration request to the GSO in the second functional entity, the GSO assists the DSO in completing the service orchestration request on the edge side based on global information.

[0134] For example, in the second functional entity, the FLM can be responsible for the management of the cloud-side function library, while the edge-side FLM will report the edge-side function library information to the global FLM. The SM can be responsible for the state management of the cloud-side network, while the edge-side SM will report the state information of each node and task execution in the edge-side network environment to the global SM. The scheduler can be used to schedule tasks, that is, to reasonably schedule the tasks in the business process diagram orchestrated by the GSO. The second functional entity may also include the NRF. The NRF is an existing functional entity in the core network, responsible for the registration and status monitoring of functional services. Therefore, each functional entity will register with the NRF after deployment.

[0135] In this embodiment, the third functional entity may refer to the requesting party that sends the orchestration request. In specific implementation, the third functional entity may be a terminal-side or edge-side user. The third functional entity may also refer to a component in the third functional entity (e.g., a processor, chip, or chip system), or it may be a logic module or software that can implement all or part of the functions of the third functional entity.

[0136] It should be understood that in the embodiments of this application, in the scenario where the first functional entity itself is capable of implementing orchestration tasks, the first functional entity may also include GSO, FLM, SM and scheduler, that is, the first functional entity may include DSO or GSO.

[0137] For example, the first functional entity configures the types of business orchestration it supports by sending first information to the third functional entity based on its own capabilities. The content of the first information is the types of business orchestration that the first functional entity can support.

[0138] Optionally, the first information is carried on non-access stratum (NAS) signaling or radio resource control (RRC) signaling.

[0139] Specifically, the first information can also be called configuration information. When the first functional entity sends the first information to the end-side user, it can be configured through NAS or RRC signaling.

[0140] For example, the orchestration types supported by the first functional entity include at least one of the following: scripts, code, and semantics.

[0141] For example, for script-based orchestration types, the first functional entity needs to submit the script and functional module to the function library management module on the network side before sending the orchestration request.

[0142] The script may include information such as a function description or a service description. The function description may include the function name, function type (e.g., application function, type), initialization data list, input information, output information, resource requirements, and environment configuration. The service description may include the service name, service function, required functions, and dependencies between functions.

[0143] The functional modules can include at least one functional module contained in the business. Each functional template can be encapsulated in code according to the platform's template requirements and can be called in the platform.

[0144] For example, for orchestration types in code form, the first functional entity needs to submit stand-alone code to the function library management module on the network side before sending the orchestration request. The stand-alone code can include multiple functions, each of which can contain annotations, specified computing resources, a function description, a function implementation, and the calling relationships between functions.

[0145] For example, for semantic orchestration types, the third functional entity does not need to provide code, and the first functional entity can simply send the semantic orchestration request in the orchestration request without submitting relevant information in advance.

[0146] Optionally, the first functional entity sends template information, and correspondingly, the third functional entity receives the template information sent by the first functional entity.

[0147] Specifically, for certain types of orchestration services, after receiving the first information, the third functional entity obtains specific type template information from the DSO in the first functional entity.

[0148] Optionally, if the third functional entity has template information of the corresponding type locally, the third functional entity may not need to obtain the specific type of template information from the DSO.

[0149] For example, for orchestration services in the form of scripts, the template information may include templates that describe functions or services.

[0150] The function description template may include the following fields: function name, function description (e.g., image recognition, 3D rendering, localization, etc.), initialization data information (e.g., dataset, weights, etc. in the AI ​​model), input information (e.g., name, type, size, offset, etc.), output information, resource requirement information (e.g., network, computing power, algorithm, data, etc.) or environment configuration information (e.g., software dependencies, runtime, etc.).

[0151] The business description template may include the following fields: business name, business description (e.g., autonomous driving, augmented reality (AR) or virtual reality (VR) games, etc.) or the dependencies of various functions in the business (e.g., each function name, resource requirements of the function, input or output information, etc.).

[0152] For example, for orchestration business in code form, the template information can include templates for various functions and business definitions.

[0153] The function template can contain the following fields: annotations / decorators for each function, specified computing resources (e.g., CPU / GPU type, CPU / GPU size, etc.), function description or function implementation.

[0154] The business definition template can include business descriptions, and the business logic can directly use code to call various functions.

[0155] Please continue to refer to this. Figure 9 Method 900 may also include:

[0156] Optionally, in S920, the third functional entity sends the seventh information, and the first functional entity receives the seventh information sent by the third functional entity. The format of the seventh information is determined according to the template information. The seventh information includes: a functional file associated with the business, a business description file, and a functional description file, or code associated with the business.

[0157] For example, the seventh information can be information corresponding to the business. S920 can be used for orchestration requirements in the form of scripts or code. For orchestration requirements in the form of scripts or code, the third functional entity needs to send the information corresponding to the business to FLM before sending the orchestration request.

[0158] For script-based orchestration requirements, the third functional entity can develop / encapsulate functional modules for all functions in the business based on script-based template information, ensuring that the function can be executed in the edge-cloud distributed network. The information corresponding to the business sent by the third functional entity can be a function file, a business description file (SD), or a function description file (FD), etc.

[0159] Figure 10 This is a schematic diagram of a script-based functional description document provided in an embodiment of this application. Please refer to it. Figure 10 A script-based function description file may include the following fields: function name, function description, initialization data information, input information, output information, resource requirements or environment configuration.

[0160] Figure 11 This is a schematic diagram of a script-based service description file provided in an embodiment of this application. Please refer to it. Figure 11 A script-based business description file may include the following fields: business name, function description, and function dependencies. The function dependencies may include information such as resource requirements, inputs, or outputs for different functions.

[0161] For code-based orchestration requirements, the third functional entity can develop standalone code corresponding to the business based on the template information in code form. The information corresponding to the business sent by the third functional entity can be a standalone code file, which can contain various functions corresponding to the business and the calls to each function.

[0162] Please continue to refer to this. Figure 9 Method 900 may also include:

[0163] Optionally, in S930, the FLM in the first functional entity performs the first processing.

[0164] For example, S930 can be used for orchestration requirements in the form of scripts or code. After receiving the information corresponding to the business, FLM performs the first processing, which may include operations such as detecting, classifying, storing and managing the information.

[0165] For example, the detection operation can be to check the standardization of information in each file. For instance, for script-based arrangement requirements, FLM can check whether the field information in each file is complete. For code-based arrangement requirements, FLM can check whether standalone code development conforms to the standards.

[0166] For example, the classification operation could be to analyze the descriptions of each function and classify them based on similarity.

[0167] For example, in storage operations, for script-based orchestration needs, FLM can directly store the functions, function descriptions, and business descriptions in the scripts. For code-based orchestration needs, FLM can parse the code and automatically encapsulate each module to generate specific function, function description, and business description files, and then FLM stores these files.

[0168] Optionally, for orchestration tasks in code form, the FLM in the first functional entity can generate corresponding SD and FD files based on the code during this process.

[0169] Optionally, for script-based orchestration tasks, FLM checks each file to determine if its information conforms to the specifications in the template. If all the files meet the requirements, the function is registered in the FLM, and relevant information is extracted from the business description and function description for feature extraction (for example, FLM extracts relevant information from the function description field of the function description, compares it with various types in the function library to determine the relevance, and the type with the highest relevance is taken as the type corresponding to the function), and the function is classified into a specific function library.

[0170] Optionally, for orchestration tasks in code form, FLM checks each file to determine if its information conforms to the specifications in the template. If all the files meet the requirements, the code with registration / decorator functions is extracted, encapsulated, and registered in FLM as a separate functional module.

[0171] Furthermore, FLM parses the function descriptions, business descriptions, and calling logic of each function in the code, and stores them as SD and FD in the local FLM.

[0172] Furthermore, FLM extracts features from the relevant information in the business description and function description files (for example, FLM extracts relevant information from the function description field of the function description, compares it with various types in the function library, determines the relevance, and takes the type corresponding to the function with the highest relevance), and classifies the functions into specific function libraries.

[0173] Optionally, during management operations, FLM can add newly generated file information to the database. If there are duplicate functions in the database, the latest function will prevail. FLM can also perform operations such as deleting old version information.

[0174] Optionally, the FLM in the first functional entity sends the SD and FD corresponding to the received service to the FLM in the second functional entity (e.g., CN). After receiving the information, the FLM in the second functional entity can record that the file originated from the edge side. This information can be used in the DSO-GSO collaborative orchestration scenario later.

[0175] Please continue to refer to this. Figure 9 Method 900 may also include:

[0176] S940, the third functional entity sends second information, and correspondingly, the first functional entity receives the second information sent by the third functional entity. The second information includes a service to be orchestrated, and the type of the service to be orchestrated belongs to the orchestration type supported by the first functional entity.

[0177] Specifically, the second information can be an orchestration request, in which the orchestration request interface specifies the orchestration type. For example, for script-based orchestration services, the orchestration request interface specifies the orchestration type as type1; for code-based orchestration services, the orchestration request interface specifies the orchestration type as type2; and for semantic-based orchestration services, the orchestration request interface specifies the orchestration type as type3. The third functional entity can send an orchestration request to the first functional entity based on the first information sent by the first functional entity in S910, i.e., the orchestration types supported by the first functional entity.

[0178] Optionally, the second information is carried in NAS signaling or RRC signaling.

[0179] In this embodiment, the first functional entity can send first information to the third functional entity to indicate the orchestration types it supports. The third functional entity can determine a suitable orchestration type from the orchestration types supported by the first functional entity according to its own capabilities or business needs, and send the service to be orchestrated of that type to the first functional entity for orchestration. The first functional entity can provide multiple supported orchestration types for the third functional entity to choose from, thus improving the flexibility of service orchestration.

[0180] Optionally, the first functional entity receives the second information through a first interface, which is used to receive information corresponding to any type among the supported orchestration types.

[0181] Specifically, the SO in the first functional entity can provide a unified orchestration request interface to the third functional entity. For example, the first interface can support various types of orchestration requests, such as script, code, and semantic forms.

[0182] Optionally, the first interface includes a type field, which can support orchestration requirements in script form, code form, or semantic form. For example, type1 represents orchestration business in script form, type2 represents orchestration business in code form, and type3 represents orchestration business in semantic form, etc.

[0183] Optionally, the first interface includes a Scripts field, which may contain information about the business in the form of scripts. For example, the Scripts field may include the business name, the name of the business description file, or a simple business description, such as the purpose of the business.

[0184] Optionally, the first interface includes a Codes field, which may contain information about the business in code form. For example, the Codes field may include the business name, a list of code names, or a simple business description, such as the purpose of the business.

[0185] Optionally, the first interface includes a Semantic field, which may contain information about semantic orchestration services. For example, the Semantic field may include semantic orchestration request information or the maximum number of tasks set by the semantic orchestration service.

[0186] Optionally, the first interface includes a QoS field, which may contain service quality information, such as latency, jitter, bandwidth requirements, or other information related to the service itself.

[0187] For example, in the second information above, the type field is type1, which indicates a script format, and the service includes the above type, Scripts, and QoS field information.

[0188] For example, in the second information above, the type field is type2, which indicates the code form, and the service includes the above type, Codes, and QoS field information.

[0189] For example, in the second information above, the type field is type3, which indicates a semantic form. The service includes the above type, Semantic, and QoS field information, where Semantic is semantic orchestration request information.

[0190] It should be understood that the names of the above fields are not specifically limited in the embodiments of this application. For example, a field containing business information arranged in script form may be called by a name other than Scripts.

[0191] In this embodiment of the application, the first interface is used to receive information corresponding to any type among the supported orchestration types. It can be understood that the first functional entity provides a unified orchestration interface to the outside world. For example, through standardized formulation, the orchestration interface can receive information corresponding to services in script form, code form and semantic form, so that the first functional entity can flexibly support the orchestration needs of various users such as third parties, network internals or consumers, and expand the ecosystem of orchestration services.

[0192] Please continue to refer to this. Figure 9 Method 900 may also include:

[0193] S950, the first functional entity, orchestrates the business to be orchestrated.

[0194] Specifically, after receiving the orchestration request information sent by the first functional entity, the SO in the first functional entity can interact with the SM and FLM to obtain the information on which the service orchestration depends and perform service orchestration. When the orchestration capability of the first functional entity itself is insufficient, the first functional entity can also request the assistance of the second functional entity to generate the flowchart corresponding to the service through DSO-GSO collaborative orchestration.

[0195] Figure 12 This is a service orchestration method 1200 provided in the embodiments of this application.

[0196] It should be understood that method 1200 can be applied to scenarios where the first functional entity itself is capable of implementing business orchestration. Method 1200 can correspond to the specific steps of S950 above. Method 1200 can also be implemented as a separate embodiment. This application embodiment does not limit this.

[0197] Method 1200 may include at least the following steps:

[0198] Optionally, after receiving the orchestration request information from the demand side, the DSO parses the orchestration request information, determines that the orchestration request type is in script form, extracts the Scripts field information, and determines information such as the business name and business description file name.

[0199] Optionally, after receiving the orchestration request information from the demand side, the DSO parses the orchestration request information, determines that the type of the orchestration request is in code form, and extracts the Codes field information to determine information such as business name and business code name.

[0200] Optionally, after receiving the orchestration request information from the demand side, the DSO parses the orchestration request information, determines that the type of the orchestration request is semantic, and extracts the Semantic field information to determine the orchestration requirements.

[0201] S1210, the first functional entity acquires network environment status information. Specifically, the SO within the first functional entity can interact with the SM to acquire information on various dimensions of the environment within the scope of the SO's jurisdiction.

[0202] For example, the aforementioned network environment status information may include information such as the network, computing power, data, algorithms, and function execution status of each node.

[0203] For example, after receiving the orchestration request information from the third functional entity, the DSO can obtain the status information of the network environment corresponding to the edge region from the SM on the edge side, such as the status of computing nodes, network status, data status, execution status of other tasks in the network, etc.

[0204] For example, the above-mentioned S950 can be used by the first functional entity to orchestrate the services to be orchestrated based on the network environment status information, that is, the first functional entity can use the network environment status information when orchestrating the services to be orchestrated.

[0205] S1220, the first functional entity obtains the third information, which indicates the functions required to implement the business.

[0206] Specifically, the SO in the first functional entity can interact with FLM, and the SO can obtain the functions required by the business from FLM.

[0207] Scenario 1: The DSO itself has the ability to orchestrate business processes, and the business processes to be orchestrated are in the form of scripts.

[0208] For example, the DSO sends a message to the FLM on the edge side to request the FD and SD files corresponding to the service based on the information obtained by parsing the orchestration request information. The message may include the service name and the service description file name.

[0209] Furthermore, the FLM on the edge side parses the service description file name in the message sent by the DSO, queries the SD corresponding to the name in the local FLM, parses the SD information, and queries the FD that the SD depends on.

[0210] Furthermore, the FLM on the edge side sends the queried SD and FD files to the DSO.

[0211] Scenario 2: The DSO itself has the ability to orchestrate business logic, and the business logic to be orchestrated is in the form of code.

[0212] For example, the DSO sends a message to the FLM on the edge side to request the FD and SD files corresponding to the service based on the information obtained by parsing the orchestration request information. The message may contain the service name and the name corresponding to the code.

[0213] Furthermore, the FLM on the edge side parses the message sent by the DSO to obtain the name of the service and the name corresponding to the code. It then queries the local FLM for the SD and FD files corresponding to the service name and code. These SD and FD files are generated by the FLM based on the information in the service code.

[0214] Furthermore, the FLM on the edge side sends the queried SD and FD files to the DSO.

[0215] Scenario 3: The DSO itself has the ability to orchestrate business operations, and the business operations to be orchestrated are in semantic form.

[0216] For example, the DSO outputs a corresponding task plan based on the acquired status information and business orchestration request information, generating N tasks, each with corresponding functional requirements.

[0217] Furthermore, the DSO sends a request message to the local FLM. Since the DSO needs to match tasks to the corresponding functions, this request message contains the functional requirements for each task.

[0218] Furthermore, after receiving the request message, the local FLM performs a similarity matching between the task and the function. That is, it performs a similarity detection between the functional requirements corresponding to the task and the functional descriptions of each function in the FLM. The function with the highest similarity is taken as the function of the task, and finally the functions corresponding to the above N tasks are obtained.

[0219] Furthermore, the local FLM sends the matched function set, i.e. the functions corresponding to the above N tasks, to the DSO. The function set includes the function name and resource requirements (e.g., computing power, network, data, algorithm, etc.) corresponding to each task.

[0220] For example, the above-mentioned S950 can be to arrange the service to be arranged according to the third information, that is, the first functional entity can use the third information when arranging the service to be arranged.

[0221] S1230, the SO in the first functional entity performs service orchestration based on the information obtained from its interaction with SM and FLM, which is the basis for service orchestration, and determines the service orchestration result.

[0222] For example, for scenario 1 or scenario 2 above, the DSO can output a flowchart corresponding to the business based on the FD, SD files and third-party information. The flowchart includes each task and the resource requirements required by the task. The resource requirements include: computing resources (e.g., processor type such as CPU / GPU, processor, memory, storage quantity, etc.), network resources (e.g., transmission rate), data resources (e.g., the required initialization data), algorithms (e.g., functional modules), etc.

[0223] For example, in scenario 3 above, the DSO can output the corresponding orchestration result, i.e., a business process diagram, based on the aforementioned third information and function set information. The business process diagram contains N tasks, the inputs and outputs of the tasks constitute the dependencies between the tasks, and the resource requirements of each task. The resource requirements may include network, computing power, algorithm, data, and other requirements.

[0224] S1240, the SO in the first functional entity sends the service orchestration results to the FLM.

[0225] For example, FLM can obtain the service orchestration results corresponding to different services by receiving the service orchestration results sent by SO. Furthermore, for the same service orchestration request, when SO interacts with FLM in S1220, it can quickly query whether the corresponding service flowchart already exists in FLM. If it exists, the flowchart can be used as the service orchestration result, thereby avoiding the computational overhead of SO when performing service orchestration.

[0226] Optionally, for scenarios 1 to 3 above, the DSO will send the service orchestration results to the FLM on the edge side and the cloud side respectively.

[0227] S1250, SO in the first functional entity sends the service orchestration result to the scheduler and triggers the scheduler to schedule each function in the service.

[0228] It should be understood that in some steps of the above methods 900 and 1200, the first functional entity is only taken as an example, which includes DSO, FLM, SM and scheduler. When the orchestration demand comes from the cloud side, the first functional entity may include GSO, FLM, SM and scheduler. At this time, the demand can also send an orchestration request to the GSO deployed on the cloud side, such as CN. The cloud-side GSO will perform service orchestration based on the orchestration request and generate a service flow diagram. The specific steps are similar to those in the above methods 900 and 1200. The embodiments of this application will not be repeated here.

[0229] Figure 13 This is another service orchestration method 1300 provided in the embodiments of this application.

[0230] It should be understood that method 1300 can be applied to scenarios where the first functional entity itself has insufficient arrangement capabilities. Method 1300 can correspond to the specific steps of S950 above. Method 1300 can also be implemented as a separate embodiment. This application embodiment does not limit this.

[0231] It should be understood that some steps or functional entities in the embodiments of this application are the same as or similar to the corresponding steps or functional entities in method 1200. The description of the steps or functional entities corresponding to method 1300 in method 1200 above can also be applied in method 1300. Method 1300 focuses on describing the technical solutions not mentioned above.

[0232] Optionally, a second functional entity is deployed on the cloud side, such as CN, which includes GSO, FLM, SM, scheduler, and NRF. A first functional entity is deployed on the edge side, such as RAN or MEC, which includes DSO, FLM, SM, and scheduler. The functional descriptions of each functional entity can be found above.

[0233] In one possible implementation, the second functional entity is able to deploy and / or remove the first functional entity from the network.

[0234] Optionally, the edge side can have multiple regions, each of which can deploy the above-mentioned functions.

[0235] For example, the third functional entity sends a service orchestration request to the DSO in its region. The orchestration request interface provided by the DSO is a unified orchestration interface that can support orchestration requests of various forms (e.g., type 1 scripts, type 2 code, type 3 semantics). After receiving the orchestration request, the DSO directly performs business orchestration. However, due to insufficient orchestration capabilities of the DSO, it sends an assistance orchestration request to the GSO in the second functional entity. After assisting in the orchestration, the GSO sends the orchestration result to the DSO. The DSO integrates the assistance orchestration result sent by the GSO with its local orchestration result to generate a business process diagram.

[0236] Specifically, method 1300 may include at least the following steps:

[0237] S1301, the first functional entity obtains network environment status information. Specifically, the DSO within the first functional entity can interact with the SM to obtain information on various dimensions of the regional environment within the jurisdiction of the DSO.

[0238] For example, the aforementioned network environment status information may include information such as the network, computing power, data, algorithms, and function execution status of each node.

[0239] For example, after the DSO in the first functional entity receives the orchestration request information from the third functional entity, it can obtain the status information of the network environment corresponding to the edge region from the SM on the edge side, such as the status of computing nodes, network status, data status, execution status of other tasks in the network, etc.

[0240] For example, the above-mentioned S950 can be used by the first functional entity to orchestrate the services to be orchestrated based on the network environment status information, that is, the first functional entity can use the network environment status information when orchestrating the services to be orchestrated.

[0241] S1302, the first functional entity obtains the fourth information, which indicates the functions required to implement M tasks out of N tasks to be orchestrated, where M is an integer greater than or equal to 0, N is a positive integer, and M is less than N.

[0242] Specifically, the DSO in the first functional entity can interact with the FLM, and the DSO can obtain some of the functions required by the business from the FLM.

[0243] Exemplarily, for an orchestration task in script form or code form, the FLM on the edge side receives a request message from the DSO on the edge side, queries whether there is an SD file corresponding to a certain function and the corresponding FD file in the SD file in the FLM. The query result may be that there is no such SD file in the FLM.

[0244] Furthermore, the FLM on the edge side sends the query result to the DSO, indicating that the SD file corresponding to this function is not found, that is, there is no function corresponding to this service on the edge side.

[0245] Exemplarily, for an orchestration task in semantic form, the FLM on the edge side sends the matched function set (for example, including M tasks, M < N) to the DSO. The function set includes the function names corresponding to each task and the information on resource requirements (such as computing power, network, data, algorithms, etc.).

[0246] S1303. The DSO in the first functional entity performs orchestration according to some functions required for the service obtained above.

[0247] Specifically, the DSO discovers that the orchestration ability is insufficient during the service orchestration process. For example, all or some of the functions required for the service in the service orchestration request are not available in this area, so the DSO cannot generate a service flow chart.

[0248] S1304. The first functional entity sends the fifth information to the second functional entity. The fifth information is used to request the sixth information, and the sixth information indicates the functions required to implement N - M tasks among the N tasks.

[0249] Specifically, the DSO can send a request for assisted orchestration to the GSO. The request information may include some or all of the functions in the service to be orchestrated by the first functional entity.

[0250] Exemplarily, in combination with S1302 and S1303, for an orchestration task in script form or code form, the functions required for the service to be orchestrated include N functions. The DSO area can provide M functions out of the N functions. That is, after the DSO on the edge side receives the fourth information, it does not obtain the SD and FD files corresponding to the remaining N - M functions from the FLM side. Therefore, it indicates that its orchestration ability is insufficient and directly sends a request message for assisted orchestration to the GSO on the cloud side. The message includes the service name and the name corresponding to the SD.

[0251] Exemplarily, in combination with S1302 and S1303, for an orchestration task in semantic form, when the DSO receives the function set (including M tasks), since M < N, it indicates that the DSO's ability is insufficient. The functions corresponding to some tasks on this edge side are not in the FLM in this area. Therefore, the DSO sends a request for assisted orchestration to the cloud side. The request message includes N - M tasks and the function requirement information for each task.

[0252] S1305, after receiving the fifth information mentioned above, the GSO in the second functional entity interacts with the global SM to obtain information on various dimensions of the environment within the scope of the GSO's jurisdiction. For example, the GSO obtains information on the network, computing power, data, algorithms, and functional execution status of each node from the SM.

[0253] S1306, the GSO in the second functional entity interacts with the global FLM to obtain the functions required by the business from the global FLM.

[0254] For example, for an orchestration task in the form of a script or code, after receiving an orchestration assistance request from the DSO, the GSO in the second functional entity forwards the message to the FLM in the second functional entity.

[0255] Furthermore, after receiving the message, FLM queries the SD file corresponding to the service. Since GSO is a global service orchestration function, it can obtain SD and FD information in the entire edge-cloud distributed network environment. Therefore, GSO can query the corresponding SD file, and after parsing the SD file, it can query the FD file required by the service.

[0256] Furthermore, FLM sends the retrieved SD and FD files to GSO.

[0257] For example, for a semantic orchestration task, after receiving an orchestration assistance request, the GSO forwards the request to the FLM in the second functional entity. The request contains functional requirement information for NM tasks to be matched.

[0258] Furthermore, after receiving the message from GSO, FLM performs task-function similarity matching. This involves detecting the similarity between the functional requirements of a task and the functional descriptions of each function in FLM, assigning functions with high similarity to those of the task, ultimately obtaining NM functions corresponding to each task.

[0259] Furthermore, FLM sends the function set information corresponding to NM tasks to GSO. The function set includes the function name and resource requirements (e.g., computing power, network, data, algorithm, etc.) of each task.

[0260] S1307, the GSO in the second functional entity outputs all or part of the functional information required by the service to be orchestrated, such as function name, function code address, function description, etc., through orchestration. This functional information is used to assist the DSO in orchestration.

[0261] S1308, the second functional entity sends the sixth information, and the first functional entity receives the sixth information sent by the second functional entity. The sixth information indicates the functions required to implement NM tasks out of N tasks.

[0262] For example, the sixth information is all or part of the functional information required by the service to be orchestrated as output by the GSO in S1307 above.

[0263] For example, for orchestration tasks in script or code form, GSO forwards SD files and FD files to DSO on the edge side.

[0264] For example, for semantic orchestration tasks, the GSO forwards the function set information corresponding to the NM tasks received to the DSO.

[0265] S1309, after receiving the sixth information mentioned above, the DSO in the first functional entity performs business orchestration and generates a complete flowchart to implement the above-mentioned orchestrated business.

[0266] For example, the above-mentioned S950 can be used by the first functional entity to arrange the service to be arranged according to the fourth information and the sixth information, that is, the first functional entity can use the above-mentioned fourth information and the sixth information when arranging the service to be arranged.

[0267] For example, for orchestration tasks in script or code form, the DSO in the first functional entity parses the received SD and FD files, performs business orchestration, and outputs a business process diagram.

[0268] For example, for semantic orchestration tasks, the DSO merges the function sets corresponding to the NM tasks sent from the GSO side and the function sets corresponding to the M tasks sent from the FLM side in this region, and outputs the corresponding business process diagrams for the N tasks.

[0269] Optionally, the first functional entity has some information about the service to be orchestrated locally. The DSO merges the local information with the information sent by the GSO to generate a service flow diagram.

[0270] Optionally, if the first functional entity does not have information about the business to be orchestrated locally, the DSO directly processes the information received from the GSO to generate a business process diagram.

[0271] S1310, the DSO in the first functional entity sends the service orchestration result, i.e. the above-mentioned service process diagram, to the local FLM and the cloud-side FLM.

[0272] For example, the FLM can obtain the service orchestration results corresponding to different services by receiving the service orchestration results sent by the DSO. Furthermore, for the same service orchestration request, when the DSO interacts with the FLM in S1302, it can quickly query whether the corresponding service flowchart already exists in the FLM. If it exists, the flowchart can be used as the service orchestration result, thereby avoiding the computational overhead of the DSO when performing service orchestration.

[0273] S1311, the DSO in the first functional entity sends the service orchestration results to the local scheduler and triggers the scheduler to schedule each function in the service.

[0274] Optionally, if the scheduler in the first functional entity finds that its capabilities are insufficient after scheduling, for example, after querying the FLM, it finds that there are only SD and FD files corresponding to the business but no corresponding functions, or that some functions in the business process diagram are not in the first functional entity, then the first functional entity sends a request for assistance in scheduling to the second functional entity, and the scheduler in the second functional entity assists in scheduling.

[0275] In this embodiment, the first functional entity can obtain fourth information, which only indicates the functions required to implement some tasks in the service to be orchestrated, meaning the first functional entity's own orchestration capabilities are insufficient. At this point, the first functional entity can request assistance from the second functional entity and receive sixth information, which indicates the functions required to implement the remaining tasks in the service to be orchestrated. Furthermore, the first functional entity can achieve service orchestration with the assistance of the second functional entity. This distributed orchestration architecture ensures that the first functional entity can ultimately achieve service orchestration. Simultaneously, when the first functional entity has the capability, it can also implement service orchestration independently, thereby solving the bottleneck of centralized orchestration and improving service orchestration efficiency, particularly for large-scale, sudden, real-time services in the network.

[0276] It is understood that the above steps are merely illustrative and are not intended to be limiting.

[0277] It is understood that some optional features in the various embodiments of this application may not depend on other features in some scenarios, or may be combined with other features in some scenarios, without limitation.

[0278] It is also understood that the sending of information is mentioned multiple times in some of the above embodiments. Taking A sending information to B as an example, A sending information to B can include A sending information directly to B, or it can include A sending information to B through other devices or network elements, and there is no limitation on this.

[0279] It is also understood that the solutions in the various embodiments of this application can be used in reasonable combinations, and the explanations or descriptions of the various terms appearing in the embodiments can be referenced or explained to each other in the various embodiments, without limitation.

[0280] The above, combined with Figures 3 to 13 The methods provided in the embodiments of this application are described in detail below. Figures 14 to 16 The apparatus provided in the embodiments of this application is described in detail. It should be understood that the description of the apparatus embodiments corresponds to the description of the method embodiments. Therefore, for content not described in detail, please refer to the method embodiments above. For the sake of brevity, it will not be repeated here.

[0281] Figure 14 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application.

[0282] The communication device 1400 includes a transceiver unit 1410 and a processing unit 1420. The transceiver unit 1410 can be used to implement corresponding communication functions, and the processing unit 1420 can be used to perform data processing.

[0283] Optionally, the transceiver unit 1410 may also be referred to as a communication interface or communication unit, including a transmitting unit and / or a receiving unit. The transceiver unit 1410 may be a transceiver (including a transmitter and / or receiver), an input / output interface (including input and / or output interfaces), pins, or circuitry, etc. The transceiver unit 1410 can be used to perform the transmitting and / or receiving steps in the above method embodiments.

[0284] Optionally, the processing unit 1420 may be a processor (may include one or more), a processing circuit with processor functions, etc., and may be used to perform other steps besides sending and receiving in the above method embodiments.

[0285] Optionally, the communication device 1400 further includes a storage unit, which may be a memory, an internal storage unit (e.g., a register, a cache, etc.), or an external storage unit (e.g., a read-only memory, a random access memory, etc.). The storage unit is used to store instructions, and the processing unit 1420 executes the instructions stored in the storage unit to cause the communication device to perform the aforementioned method.

[0286] In one design, the communication device 1400 can be used to execute the actions performed by the first functional entity in the various method embodiments described above. For example, the communication device 1400 can be used to execute the actions performed by the first functional entity in method 900, method 1200, or method 1300. In this case, the communication device 1400 can be a component of the first functional entity, the transceiver unit 1410 is used to execute the transceiver-related operations on the first functional entity side in the method embodiments described above, and the processing unit 1420 is used to execute the processing-related operations of the first functional entity in the method embodiments described above.

[0287] For example, the transceiver unit 1410 is used to send first information, which indicates the supported orchestration type; the processing unit 1420 is used to orchestrate the service to be orchestrated.

[0288] It should be understood that the transceiver unit 1410 and the processing unit 1420 can also perform other operations performed by the first functional entity in any of the above methods, which will not be described in detail here.

[0289] In one design, the communication device 1400 can be used to execute the actions performed by the second functional entity in the various method embodiments described above. For example, the communication device 1400 can be used to execute the actions performed by the second functional entity in method 900, method 1200, or method 1300. In this case, the communication device 1400 can be a component of the second functional entity, with the transceiver unit 1410 performing transceiver-related operations on the second functional entity side in the method embodiments above, and the processing unit 1420 performing processing-related operations of the second functional entity in the method embodiments above.

[0290] For example, transceiver unit 1410 is used to send the sixth message.

[0291] It should be understood that the transceiver unit 1410 and the processing unit 1420 can also perform other operations performed by the second functional entity in any of the above methods, which will not be described in detail here.

[0292] In one design, the communication device 1400 can be used to execute the actions performed by the third functional entity in the various method embodiments described above. For example, the communication device 1400 can be used to execute the actions performed by the third functional entity in method 900, method 1200, or method 1300. In this case, the communication device 1400 can be a component of the third functional entity, with the transceiver unit 1410 performing transceiver-related operations on the third functional entity side in the method embodiments above, and the processing unit 1420 performing processing-related operations of the third functional entity in the method embodiments above.

[0293] For example, transceiver unit 1410 is used to receive first information, which indicates the supported orchestration type.

[0294] It should be understood that the transceiver unit 1410 and the processing unit 1420 can also perform other operations performed by the third functional entity in any of the above methods, which will not be described in detail here.

[0295] It should also be understood that the communication device 1400 here is embodied in the form of a functional unit. The term "unit" here can refer to an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, a proprietary processor, or a group processor, etc.) and memory for executing one or more software or firmware programs, integrated logic circuitry, and / or other suitable components supporting the described functions. In an alternative example, those skilled in the art will understand that the communication device 1400 may be specifically the first functional entity in the above embodiments, and may be used to execute the various processes and / or steps corresponding to the first functional entity in the above method embodiments; to avoid repetition, these will not be described again here.

[0296] The communication device 1400 of each of the above-described schemes has the function of implementing the corresponding steps performed by the device in the above-described method, or the communication device 1400 of each of the above-described schemes has the function of implementing the corresponding steps performed by the access network device in the above-described method. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions; for example, the transceiver unit can be replaced by a transceiver (e.g., the transmitting unit in the transceiver unit can be replaced by a transmitter, and the receiving unit in the transceiver unit can be replaced by a receiver), and other units, such as processing units, can be replaced by processors, respectively executing the transceiver operations and related processing operations in each method embodiment.

[0297] In addition, the transceiver unit 1410 may also be a transceiver circuit (for example, it may include a receiving circuit and a transmitting circuit), and the processing unit may be a processing circuit.

[0298] It should be pointed out that, Figure 14 The device mentioned can be the network element or equipment in the foregoing embodiments, or it can be a chip or chip system, such as a system on chip (SoC). The transceiver unit can be an input / output circuit or a communication interface; the processing unit is a processor, microprocessor, or integrated circuit integrated on the chip. No limitations are imposed here.

[0299] Figure 15 This is a schematic diagram of a communication architecture provided in an embodiment of this application.

[0300] Figure 15The communication device 1500 shown includes: a processor 1510, optionally, a memory 1520 or a transceiver 1530, or one or more of these. The processor 1510 is coupled to the memory 1520 and is used to execute instructions stored in the memory 1520 to control the transceiver 1530 to transmit and / or receive signals.

[0301] It should be understood that the processor 1510 and memory 1520 can be combined into a single processing device, with the processor 1510 executing the program code stored in the memory 1520 to achieve the aforementioned functions. In specific implementations, the memory 1520 can be integrated into the processor 1510 or independent of it. It should also be understood that the processor 1510 can correspond to the various processing units in the aforementioned communication device, and the transceiver 1530 can correspond to the various receiving and transmitting units in the aforementioned communication device.

[0302] It should also be understood that transceiver 1530 may include a receiver (or receiver unit) and a transmitter (or transmitter unit). The transceiver may further include antennas, and the number of antennas may be one or more. The transceiver may also be a communication interface or interface circuitry.

[0303] Specifically, the communication device 1500 may correspond to a first functional entity in method 900, method 1200, or method 1300 according to embodiments of this application. The communication device 1500 may execute the steps performed by the first functional entity in method 900, method 1200, or method 1300 according to embodiments of this application. The communication device 1500 may also correspond to a third functional entity in method 900, method 1200, or method 1300 according to embodiments of this application. The communication device 1500 may execute the steps performed by the third functional entity in method 900, method 1200, or method 1300. It should be understood that the specific processes of the corresponding steps described above have been described in detail in the above method embodiments, and for the sake of brevity, will not be repeated here.

[0304] When the communication device 1500 is a chip, the chip includes an interface unit and a processing unit. The interface unit can be an input / output circuit or a communication interface; the processing unit can be a processor, microprocessor, or integrated circuit integrated on the chip.

[0305] It should be understood that the processor mentioned in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0306] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM). For example, RAM can be used as an external cache. By way of example and not limitation, RAM includes the following forms: static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0307] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) can be integrated into the processor.

[0308] It should also be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0309] Figure 16 This is a schematic diagram of a chip system 1600 provided in an embodiment of this application. The chip system 1600 (or may also be referred to as a processing system) includes logic circuitry 1610 and an input / output interface 1620.

[0310] The logic circuit 1610 can be a processing circuit in the chip system 1600. The logic circuit 1610 can be coupled to a memory unit, calling instructions from the memory unit, enabling the chip system 1600 to implement the methods and functions of the embodiments of this application. The input / output interface 1620 can be an input / output circuit in the chip system 1600, outputting processed information from the chip system 1600, or inputting data or signaling information to be processed into the chip system 1600 for processing.

[0311] As one approach, the chip system 1600 is used to implement operations performed by communication devices (such as a first functional entity, a second functional entity, or a third functional entity) in the various method embodiments described above.

[0312] For example, logic circuit 1610 is used to implement processing-related operations performed by communication devices (such as the first functional entity, the second functional entity, or the third functional entity) in the above method embodiments; input / output interface 1620 is used to implement sending and / or receiving-related operations performed by communication devices (such as the first functional entity, the second functional entity, or the third functional entity) in the above method embodiments.

[0313] This application also provides a computer-readable storage medium storing computer instructions for implementing the methods executed by a communication device (such as a first functional entity, a second functional entity, or a third functional entity) in the above-described method embodiments.

[0314] For example, when the computer program is executed by a computer, the computer can implement the methods performed by the communication device (such as the first functional entity, the second functional entity, or the third functional entity) in the various embodiments of the above methods.

[0315] This application also provides a computer program product comprising instructions which, when executed by a computer, implement the methods described above, performed by a communication device (such as a first functional entity, a second functional entity, or a third functional entity).

[0316] This application also provides a communication system, which includes a first functional entity, a second functional entity, or a third functional entity as described in the preceding embodiments. For example, the system includes... Figure 9 , Figure 12 or Figure 13 The first functional entity, the second functional entity, or the third functional entity in the process.

[0317] The explanations and beneficial effects of the relevant contents in any of the devices provided above can be found in the corresponding method embodiments provided above, and will not be repeated here.

[0318] It should be noted that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0319] This application also provides a computer-readable medium having a computer program stored thereon, which, when executed by a computer, implements the functions of any of the above method embodiments.

[0320] This application also provides a computer program product that, when executed by a computer, implements the functions of any of the above method embodiments.

[0321] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this 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. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0322] In the embodiments of this application, the words "exemplary," "for example," etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design that is described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or design options. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0323] It should be understood that the term "embodiment" used throughout this specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout this specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0324] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. All node and message names in this application are merely names set for the convenience of description, and the names in the actual network may be different. It should not be understood that this application limits the names of various nodes and messages. On the contrary, any name with the same or similar function as the node or message used in this application is regarded as the method or equivalent substitution of this application and is within the protection scope of this application.

[0325] It should also be understood that in this application, “when…”, “if” and “if” all refer to the UE or base station taking corresponding actions under certain objective circumstances, and are not time-limited, nor do they require the UE or base station to perform a judgment action, nor do they imply any other limitations.

[0326] Furthermore, the terms "system" and "network" are often used interchangeably in this paper. The term "and / or" in this paper is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A exists alone, A and B exist simultaneously, and B exists alone.

[0327] In this document, the terms "at least one of..." or "at least one of..." refer to all or any combination of the listed items. For example, "at least one of A, B, and C" can represent six possibilities: A exists alone, B exists alone, C exists alone, A and B exist simultaneously, B and C exist simultaneously, and A, B, and C exist simultaneously. "At least one" in this document means one or more. "More than one" means two or more.

[0328] It should be understood that the terms “including,” “comprising,” “having,” and their variations all mean “including but not limited to,” unless otherwise specifically emphasized.

[0329] It should be understood that in the various embodiments of this application, the terms "first," "second," and various numerical designations are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. For example, they can be used to distinguish different information.

[0330] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0331] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the descriptions of the corresponding processes and beneficial effects in the foregoing method embodiments, and will not be repeated here.

[0332] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0333] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0334] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0335] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, parts of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0336] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method, characterized in that, The method is applied to a first functional entity, and the method includes: Send a first message, which indicates the supported orchestration type; Receive second information, the second information including services to be orchestrated, wherein the type of the services to be orchestrated belongs to the supported orchestration types; The services to be orchestrated are orchestrated.

2. The method according to claim 1, characterized in that, The supported orchestration types include at least one of the following: script form, code form, and semantic form.

3. The method according to claim 1 or 2, characterized in that, The first information and / or the second information are carried in Non-Access Stratum (NAS) signaling or Radio Resource Control (RRC) signaling.

4. The method according to any one of claims 1 to 3, characterized in that, The receiving of the second information includes: The second information is received through a first interface, which is used to receive information corresponding to any one of the supported orchestration types.

5. The method according to any one of claims 1 to 4, characterized in that, Also includes: Obtain network environment status information; The orchestration of the services includes: The services to be orchestrated are arranged based on the network environment status information.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: Obtain third information, which indicates the functions required to implement the service; The orchestration of the services to be orchestrated includes: Based on the third information, the services to be orchestrated are orchestrated.

7. The method according to claim 5, characterized in that, Also includes: Obtain fourth information, which indicates the functions required to implement M tasks out of N tasks in the scheduled service, where M is an integer greater than or equal to 0, N is a positive integer, and M is less than N; Send a fifth message to the second functional entity, the fifth message being used to request a sixth message, the sixth message indicating the functions required to implement NM tasks out of the N tasks; Receive the sixth information sent by the second functional entity; The orchestration of the services to be orchestrated includes: The services to be orchestrated are orchestrated based on the fourth and sixth information.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: Send template information; Receive a seventh message, the format of which is determined according to the template information, and the seventh message includes: The functional files, business description files, and functional description files associated with the aforementioned business, or Code associated with the aforementioned business.

9. The method according to any one of claims 1 to 8, characterized in that, The first functional entity can obtain the arrangement information of the area where the first functional entity is located.

10. The method according to claim 9, characterized in that, The first functional entity is deployed at an edge node, which includes a mobile edge computing (MEC) or a radio access network (RAN).

11. A communication method, characterized in that, The method is applied to a third functional entity, and the method includes: Receive first information, which indicates the supported orchestration types; Send a second message indicating a service to be orchestrated, wherein the type of the service to be orchestrated belongs to the supported orchestration types.

12. The method according to claim 11, characterized in that, The supported orchestration types include at least one of the following: script form, code form, and semantic form.

13. The method according to claim 11 or 12, characterized in that, The first information and / or the second information are carried in Non-Access Stratum (NAS) signaling or Radio Resource Control (RRC) signaling.

14. The method according to any one of claims 11 to 13, characterized in that, Also includes: Receive template information; Send a seventh message, the format of which is determined according to the template information, and the seventh message includes: The functional files, business description files, and functional description files associated with the aforementioned business, or Code associated with the aforementioned business.

15. A communication system, characterized in that, The system includes a first functional entity for performing the method as described in any one of claims 1 to 10, and the communication system further includes a second functional entity as described in claim 7, the second functional entity being capable of obtaining global orchestration information.

16. The communication system according to claim 15, characterized in that, The second functional entity can deploy and / or remove the first functional entity from the network.

17. A communication device, characterized in that, The communication device is used to perform the method according to any one of claims 1 to 10 or 11 to 14.

18. A communication device, characterized in that, The communication device includes at least one processor and at least one memory, the at least one memory being used to store computer programs or instructions, and the at least one processor being used to execute the computer programs or instructions in the memory, such that the method of any one of claims 1 to 10 is performed, or that the method of any one of claims 11 to 14 is performed.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when the computer program or instructions are run on a computer, execute the method as described in any one of claims 1 to 10, or execute the method as described in any one of claims 11 to 14.

20. A computer program product, characterized in that, When the computer program product is run on a computer, the method as described in any one of claims 1 to 10 is performed, or the method as described in any one of claims 11 to 14 is performed.