Task scheduling method and apparatus

Abstract

Disclosed in the present application are a task scheduling method and an apparatus. The method comprises: receiving a first request, the first request being used for requesting execution of a first task; on the basis of the first request, determining an orchestration policy corresponding to a first state of the first task; and invoking an atomic service on the basis of the orchestration policy so as to process an event of the first task in the first state, wherein the orchestration policy comprises invoking an interface of the atomic service, the atomic service implementing a first mobile network function, and enabling a first interface to a service orchestrator for scheduling and orchestration. The method in the embodiments of the present application can implement decoupling between different services, thereby shortening deployment cycles for launching new functions and reducing impact on existing network functions.

Description

Task scheduling method and apparatus

[0001] This application claims priority to Chinese Patent Application No. 202411464765.0, filed on October 18, 2024, entitled “Task Scheduling Method and Apparatus”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a task scheduling method and apparatus. Background Technology

[0003] Existing technologies employ a service-based architecture (SBA) to implement mobile network function interaction. Network elements are decoupled into independent network functions (NFs), and services register and discover each other through a network repository function (NRF) and interact via the SBA bus. The SBA architecture achieves service autonomy and network automation. However, significant coupling and serialized processes still exist between services, which can lead to problems such as long deployment cycles for new functions and significant impacts on existing network functions. Summary of the Invention

[0004] This application provides a task scheduling method and apparatus, which implements the execution process of network functions by providing a service orchestrator, thereby decoupling different services, reducing the deployment cycle of new functions and reducing the impact on existing network functions.

[0005] In a first aspect, this application provides a task scheduling method, which includes: receiving a first request, the first request being used to request the execution of a first task; determining an orchestration strategy corresponding to a first state of the first task based on the first request; and invoking an atomic service based on the orchestration strategy to handle events of the first task in the first state, wherein the orchestration strategy includes an interface for invoking the atomic service, the atomic service implementing a first mobile network function, and opening a first interface to a service orchestrator for scheduling and orchestration.

[0006] In this embodiment, the first task to be executed is determined based on the received request message. Then, the first state corresponding to the first task and the orchestration strategy corresponding to the first state are confirmed. Finally, atomic services are scheduled according to the orchestration strategy corresponding to the first state to execute the events of the first task in the first state, thereby achieving the execution of the entire first task. In this process, each atomic service is scheduled independently without needing to interact with each other, achieving decoupling of the services within the task, reducing the deployment cycle of new features, and minimizing the potential impact on existing network functions.

[0007] In one feasible implementation, the orchestration strategy includes a first state, a first event in the first state, and a first state closure corresponding to the first state and the first event. Invoking an atomic service based on the orchestration strategy to process the event of the first task in the first state includes: invoking an atomic service based on the first state closure to process the first event of the first task in the first state, and obtaining the target processing result of the first event in the first state. The first state closure includes an execution file for processing the first event in the first state, and the execution file includes a processing function for calling the interface of the atomic service.

[0008] In one feasible implementation, the orchestration strategy further includes a first state configuration file corresponding to the first state and the first event. After calling an atomic service to process the event of the first task in the first state according to the orchestration strategy, the method further includes: determining the target state to which the first state is migrated based on the target processing result of the first event in the first state and the correspondence between the processing result of the first event in the first state and the migration state of the first state in the first state configuration file; the first state configuration file includes the correspondence between the target processing result and the target state.

[0009] In one feasible implementation, before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the method further includes: creating the first task based on the first request, and determining the initial state of the first task as the first state.

[0010] In one feasible implementation, before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the method further includes: matching the first task and the first state of the first task from the task instance management based on the first request, wherein the task instance management includes multiple tasks to be scheduled, and the first task is among the multiple tasks to be scheduled.

[0011] In this embodiment, a method is provided to determine the first state of the first task in two cases: when the first task can be matched from the task management instance and when the first task cannot be matched, respectively. This ensures the reliability of determining the first state of the first task and thus improves the reliability of the execution process of the first task.

[0012] In one feasible implementation, the first request includes at least one of the following: a task identifier for the first task; a message type for the first request; a user identifier; and / or a session identifier.

[0013] In one feasible implementation, determining the orchestration strategy corresponding to the first state of the first task based on the first request includes: matching the first key value in the state chain of the orchestration strategy according to the first state of the first task and the first event in the first state, and obtaining the first state closure associated with the first key value; wherein the state chain includes multiple key values ​​composed of multiple states and events, and the multiple key values ​​include the first key value.

[0014] In one feasible implementation, determining the orchestration strategy corresponding to the first state of the first task based on the first request includes: matching the first target key value in the state chain of the orchestration strategy according to the first state of the first task, and obtaining at least one state closure associated with the first target key value; wherein the state chain includes multiple target key values ​​corresponding to multiple states, the multiple key values ​​include the first target key value, and the at least one state closure includes the first state closure corresponding to the first event.

[0015] In this embodiment, key-value pairs are constructed based on the state of the first task and each event within that state, and each key-value pair is associated with a state closure. This allows for more precise matching of orchestration strategies to the first state, thereby improving the execution quality of the first task. Furthermore, constructing key-value pairs based on the state of the first task and associating each key-value pair with one or more state closures improves the efficiency of obtaining orchestration strategies for each state, thus enhancing the execution efficiency of the first task.

[0016] In one feasible implementation, the method further includes: receiving a second request for requesting an editing and arrangement strategy; and editing the editing and arrangement strategy based on the second request.

[0017] In one feasible implementation, editing the orchestration strategy based on the second request includes adding an orchestration strategy based on the second request. The second request includes a second state, a second state closure, and a second state configuration file, or it may also include a second event in the second state. Adding an orchestration strategy based on the second request includes: adding a second key value of the second state and the second event to the state chain and associating the second key value with the second state closure; or adding a second target key value of the second state to the state chain and associating it with the second state closure; and establishing an association between the second state closure and the second state configuration file.

[0018] In one feasible implementation, editing the orchestration strategy based on the second request includes modifying the orchestration strategy based on the second request. The second request includes at least one of the following: a third state, an updated third state closure, an updated third state configuration file, or a third event in the third state. Modifying the orchestration strategy based on the second request includes: modifying or replacing the third state configuration file and / or the third state closure in the third state according to the updated third state configuration file and / or the updated third state closure; or modifying or replacing the third state configuration file and / or the third state closure corresponding to the third event in the third state according to the updated third state configuration file and / or the updated third state closure.

[0019] In one feasible implementation, the method further includes: editing the orchestration strategy based on the second request, which includes deleting the orchestration strategy based on the second request, wherein the second request includes a fourth state, or includes a fourth event in the fourth state; deleting the orchestration strategy based on the second request includes: deleting the orchestration strategy corresponding to the fourth event in the fourth state; or deleting the orchestration strategy corresponding to the fourth state.

[0020] In this embodiment, the orchestration strategy is dynamically modified through the open interface of the business orchestrator. The newly added atomic service is called by adding a new orchestration strategy, so that the dynamically launched atomic service does not affect the original business, thereby ensuring the stability and reliability of the existing service functions and the efficiency of the implementation of the new business.

[0021] In a second aspect, a communication device is provided, the communication device comprising units or modules for performing any of the possible methods in the first aspect described above.

[0022] Thirdly, embodiments of this application provide a communication device, which includes at least one processor and a memory; wherein the memory is used to store computer programs or instructions; and at least one processor is used to execute the computer programs or instructions in the memory, such that any of the methods that may be implemented in the first aspect are executed.

[0023] Fourthly, embodiments of this application provide a communication system, which includes a first device for performing the method described in any one of the first aspects. The communication system may further include a terminal device or other devices.

[0024] Fifthly, embodiments of this application provide a computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, which, when executed, cause the computer to perform the method described in any of the above methods.

[0025] Sixthly, embodiments of this application provide a computer program product, the computer program product including: computer program code, which, when executed by a computer, causes the computer to perform the method described in any of the above methods.

[0026] In a seventh aspect, embodiments of this application provide a chip coupled to a memory for reading and executing program instructions in the memory, so that the device in which the chip is located implements the method described in any of the above methods. Attached Figure Description

[0027] Figure 1A shows a network architecture of a communication system provided in an embodiment of this application.

[0028] Figure 1B is a schematic diagram of an SBA provided in an embodiment of this application.

[0029] Figure 1C is a schematic diagram of network element interaction provided in an embodiment of this application.

[0030] Figure 1D is a flowchart of a registration service provided in an embodiment of this application.

[0031] Figure 2A is a flowchart of a task scheduling method provided in an embodiment of this application.

[0032] Figure 2B is a schematic diagram illustrating the working principle of a service orchestrator provided in an embodiment of this application.

[0033] Figure 3A is a user registration process interaction sequence diagram provided in an embodiment of this application.

[0034] Figure 3B is a task scheduling example diagram of the business orchestrator corresponding to the user registration process provided in the embodiments of this application.

[0035] Figure 4A is a flowchart of an arrangement strategy editing method provided in an embodiment of this application.

[0036] Figure 4B is a schematic diagram illustrating the working principle of another service orchestrator provided in an embodiment of this application.

[0037] Figure 5 is a flowchart of a dynamic editing and arrangement strategy in the user registration process provided by an embodiment of this application.

[0038] Figure 6 is a schematic diagram of the structure of a communication device provided in an embodiment of this application.

[0039] Figure 7 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0040] The technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings. The terms "system" and "network" in the embodiments of this application can be used interchangeably. Unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship; for example, A / B can represent A or B. "And / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be one or multiple. Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish between network elements and similar items with essentially the same function. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0041] References to "one embodiment" or "some embodiments" in the embodiments described in this application mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0042] The following detailed embodiments further illustrate the objectives, technical solutions, and beneficial effects of this application. It should be understood that the following are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.

[0043] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0044] The following describes the scenarios involved in the embodiments of this application.

[0045] The technical solution provided in this application can be applied to various communication systems, such as 5G mobile communication systems, future evolution systems, or multiple communication convergence systems, as well as existing communication systems. The application scenarios of the technical solution provided in this application can include various scenarios, such as machine-to-machine (M2M), macro-micro communication, enhanced mobile broadband (eMBB), ultra-reliable and low-latency communication (uRLLC), and massive machine-type communication (mMTC). These scenarios may include, but are not limited to, communication scenarios between terminal devices, communication scenarios between network devices, and communication scenarios between network devices and terminal devices. Network devices include access network devices and core network devices. The following descriptions all use the scenario of communication between network devices and terminal devices as examples.

[0046] Referring to Figure 1A, which illustrates a network architecture for a communication system according to an embodiment of this application, the network architecture may include: a terminal, a service orchestrator, a service mesh, and a database (DB). The terminal device is used to request and execute tasks. The service orchestrator receives the task request from the terminal device, obtains the orchestration strategy corresponding to the current state of the task based on the task request, and then calls atomic services in the service mesh according to the orchestration strategy. The atomic services are functionally independent, or in other words, they are used to implement independent mobile network functions. During the invocation of atomic services, operations related to data reading, storage, or modification interact with the DB.

[0047] The following is a detailed introduction to the functions involved in the network architecture:

[0048] 1. Business Orchestrator: Responsible for end-to-end business processes and status. It determines the atomic services to be invoked and orchestrated based on terminal status, subscription, location, and other information to complete the terminal business process. It provides an open programmable interface to management plane network elements or third-party applications. These applications can call the programmable interface to dynamically modify the orchestration strategy, thus ensuring that adding new atomic services or features does not affect other atomic service functions, and also keeping the business orchestrator software upgrade-free.

[0049] The business orchestrator mainly consists of four functional parts:

[0050] a. Task Scheduler: Based on the terminal's business requests, it identifies the specific tasks or processes that need to be executed, creates or matches task instances, and schedules the corresponding task instances;

[0051] b. Task Instance Management: Manages tasks that are not yet finished and may be scheduled. Provides the task scheduler with operations for creating, deleting, and modifying task instances.

[0052] c. Orchestration Strategy Management: This manages the orchestration strategy for tasks. The orchestration strategy primarily describes the state and the interface of the atomic service to be called. The orchestration strategy mainly consists of a state list, state closures, and state configuration files. Different task descriptions for atomic service scheduling can be implemented by adding or deleting state management nodes in the state list, replacing state closures, or modifying state configuration files.

[0053] d. Programmable interface: The service orchestrator provides a programmable interface to enable dynamic addition, deletion and modification of orchestration strategies, while keeping the service orchestrator software from being upgraded.

[0054] 2. Service Mesh: Provides basic message routing, distribution, and service selection capabilities, and can adopt existing technologies or distributed network components defined by future 6G networks.

[0055] 3. Atomic Services: These are services that provide independent functionality and expose interfaces to the business orchestrator. The business orchestrator schedules one interface of an atomic service to complete one function at a time. The interfaces provided by atomic services are characterized by their independence and the absence of state coupling between interfaces.

[0056] 4. DB: Provides data storage services, mainly used to store the external state and context of atomic services, and realize context sharing between atomic services. This database needs to have high reliability and high performance.

[0057] 5. The terminal involved in the embodiments of this application can also be referred to as a terminal device, user equipment (UE), etc. A terminal device is an entity on the user side used to receive or transmit signals, used to send uplink signals to network devices or receive downlink signals from network devices; its main functions include collecting data (in some terminal devices), receiving control information and downlink data from network devices, and sending electromagnetic waves to transmit uplink data to network devices. Terminal devices can communicate with one or more core networks through network devices. Terminal devices include handheld devices with wireless connectivity, other processing devices connected to wireless modems, or vehicle-mounted devices. Terminal devices can be portable, pocket-sized, handheld, computer-embedded, or vehicle-mounted mobile devices. Terminal devices can be widely used in various scenarios, such as cellular communication, D2D, V2X, point-to-point (P2P), machine-to-machine (M2M), machine-type communication (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation, autonomous delivery and mobility, etc.Examples of terminal devices include: 3GPP standard user equipment (UE), fixed equipment, mobile equipment, handheld devices, wearable devices, cellular phones, smartphones, session initiated protocol (SIP) phones, laptops, personal computers, smart books, vehicles, satellites, global positioning system (GPS) devices, drones, helicopters, aircraft, ships, remote control devices, smart home devices, industrial equipment, personal communication service (PCS) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), wireless network cameras, tablets, handheld computers, mobile internet devices (MIDs), wearable devices such as smartwatches, VR devices, AR devices, wireless terminals in industrial control, terminals in vehicle-to-everything (V2X) systems, wireless terminals in self-driving vehicles, wireless terminals in smart grids, wireless terminals in transportation safety, and smart city applications. Wireless terminals in various scenarios include smart gas pumps, high-speed rail terminals, and smart home terminals such as smart speakers, smart coffee machines, and smart printers. Terminal devices can be wireless devices in these scenarios or devices installed on wireless devices, such as communication modules, modems, or chips. Terminal devices can also be called terminals, terminal equipment, UEs, mobile stations (MS), mobile terminals (MT), etc. Terminal devices can also be used in future wireless communication systems. Terminal devices can be used in dedicated network equipment or general-purpose equipment. The embodiments of this application do not limit the specific technologies or device forms used in the terminal devices.

[0058] In this application, the communication device used to implement the functions of the terminal device can be a terminal device, a terminal device having some of the functions of the aforementioned terminal device, or a device capable of supporting the implementation of the functions of the aforementioned terminal device, such as a chip system. This device can be installed in the terminal device or used in conjunction with the terminal device. In this application, the chip system can be composed of chips or include chips and other discrete components. The technical solutions provided in this application are described using the example of a terminal device or UE as the communication device.

[0059] The prior art involved in the embodiments of this application is described below.

[0060] Referring to Figure 1B, which is a schematic diagram of an SBA structure provided in an embodiment of this application, as shown in Figure 1B, the SBA may include a core network (CN) domain, radio access network (RAN) equipment, and a UE. The network elements in the CN domain can be divided into two categories: user plane function network elements (also referred to as user plane network elements) and control plane function network elements (also referred to as control plane network elements). The control plane function network elements include access and mobility management function (AMF) network elements, network exposure function (NEF) network elements, session management function (SMF) network elements, unified data management (UDM) network elements, policy and charging rules function (PCF) network elements, and authentication server function (AUSF) network elements, etc. User plane network elements can include user plane function (UPF) network elements.

[0061] In the fifth generation (5 thIn 5G SBA (Service-Based Automation), network elements are decoupled into independent NFs. Services register and discover each other through NRFs and interact through the SBA bus. 5G SBA achieves service autonomy and network automation. However, significant coupling and process serialization issues still exist between services. Referring to Figure 1C, which is a schematic diagram of network element interaction provided in an embodiment of this application, the SMF needs to interface with the AMF, UDM, PCF, and UPF. Completing a service function requires the cooperation of these network elements. Under this coupling, an SMF upgrade may lead to coordinated upgrades of the UDM, PCF, and UPF, expanding the impact and lengthening the upgrade cycle.

[0062] Alternatively, refer to Figure 1D, which is a flowchart of a registration service provided in an embodiment of this application. As shown in Figure 1D, the AMF serially calls interfaces such as ASUF, UDM, PCF, and SMF (sending messages to these network elements and interacting with them). Simultaneously, the ASUF may further trigger interactions with the UE and AMF to complete the authentication process, while the SMF may also interact with the PCF to complete the policy update / deletion process. This process is a serial process involving multiple network elements. Here, the AMF, SMF, and ASUF are both recipients of request messages, being requested to process a certain message, and initiators of service request messages, requiring other network elements to complete a function. This serialized process design leads to more severe coupling between network elements and a more complex process. Adding messages or changing the message processing order in this serial process can lead to modifications and upgrades of multiple network elements, severely impacting the speed of new service innovation.

[0063] Example 1: Based on this, this application embodiment provides a network architecture for a communication system as shown in Figure 1A, and performs task scheduling based on the network architecture in Figure 1A. Referring to Figure 2A, Figure 2A is a flowchart of a task scheduling method provided by this application embodiment, applied to the service orchestrator in Figure 1A. As shown in Figure 2A, the method includes the following steps:

[0064] 101. Receive the first request, which is used to request the execution of the first task.

[0065] The service orchestrator in this embodiment can be a network element, entity, or function, or it can be a system composed of multiple network elements, entities, or functions. This embodiment does not limit this.

[0066] The structure of the service orchestrator is shown in Figure 1A. It may include a task scheduler, a task instance manager, an orchestration policy manager, and a programmable interface. The task scheduler, task instance manager, and orchestration policy manager may be three virtual modules, or physical structures, or a combination of virtual modules and physical structures, or chips. This embodiment does not limit the specific components.

[0067] The principle of task scheduling executed by the service orchestrator can be seen in Figure 2B. Figure 2B is a schematic diagram of the working principle of a service orchestrator provided in an embodiment of this application. As shown in Figure 2B, the service orchestrator can specifically receive a first request through the task scheduler, or distribute the first request received by the communication interface to the task scheduler, and then determine the first task through the task scheduler. This corresponds to process ① in Figure 2B.

[0068] The first request (carried information) may include a task identifier for the first task, used to identify the first task. Alternatively, the first request may include a message type and a user identifier. For example, if the message type is an authentication request and the user identifier is user 1, it indicates that the first task corresponding to the first request is to authenticate user 1. Alternatively, the first request may include a message type and a session identifier, which can also be used to identify the first task. For example, if the message type is a session creation request, it may carry a PDU session identifier.

[0069] 102. Determine the orchestration strategy corresponding to the first state of the first task based on the first request.

[0070] After determining the first task based on the information carried in the first request, the service orchestrator further determines the first state of the first task and the orchestration strategy corresponding to the first state.

[0071] For example, determining the first state of the first task can be performed through task instance management, corresponding to processes ② and ③ in Figure 2B. Process ② is used to determine the first state, and process ③ is used to read the user context from the database to make business decisions, that is, to determine the initial state of the current task based on the business attributes in the user context.

[0072] The orchestration strategy corresponding to the first state can be determined through orchestration strategy management, corresponding to processes ④ and ⑤ in Figure 2B. Process ④ is used to determine the state list corresponding to the first state and the events within it. Process ⑤ is used to determine the state closures corresponding to the state list. The state closure includes information such as the event handling function for the user in the first state, the user context, and the closure processing return code. After matching the first task to the state closure (instance) of the event in the first state, the state closure instance is loaded, and key information such as the user context and the event (message) is passed to the closure instance for processing.

[0073] For example, suppose the first task is "authentication" and the first state is "waiting for authentication". The database can store orchestration strategies corresponding to the first state. The first state may include multiple executable events, referred to as first events. The first state and first events, as shown in process ④ of Figure 2B, form a state linked list K1. K1 corresponds to state closure 1, which includes an interface for calling atomic service 3. After state closure 1 calls atomic service 3, the corresponding execution result calls state configuration file 1. K1, state closure 1, and state configuration file 1 constitute an orchestration strategy for the first state. If the first state includes other events, then the first state can also correspond to other orchestration strategies.

[0074] After determining the first task, and before determining the orchestration strategy corresponding to the first state, it is necessary to determine the first state corresponding to the first task.

[0075] Optionally, before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the method further includes: creating the first task based on the first request, and determining the initial state of the first task as the first state.

[0076] For example, after the task scheduler receives the first request, it determines the first task based on the first request. However, if the first task cannot be matched from the task instance management, it means that the first task is a newly added task and needs to be created in the task instance management. Then, the initial state of the first task is confirmed as the first state of the first task.

[0077] Optionally, before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the method further includes: matching the first task and the first state of the first task from the task instance management based on the first request, wherein the task instance management includes multiple tasks to be scheduled, and the first task is among the multiple tasks to be scheduled.

[0078] For example, after receiving the first request, the task scheduler determines the first task based on the first request and matches the first task from the task instance management (the task instance management may include multiple tasks such as the first task, the second task, the third task, etc.). Then, the first state can be determined based on the current state of the first task.

[0079] As can be seen, this embodiment provides a method for determining the first state of the first task in two cases: when the first task can be matched from the task management instance and when the first task cannot be matched, respectively. This ensures the reliability of determining the first state of the first task and thus improves the reliability of the execution process of the first task.

[0080] After determining the first state corresponding to the first task, the orchestration strategy corresponding to the first state can be further determined.

[0081] Optionally, determining the orchestration strategy corresponding to the first state of the first task based on the first request includes: matching the first key value in the state chain of the orchestration strategy according to the first state of the first task and the first event in the first state, and obtaining the first state closure associated with the first key value; wherein the state chain includes multiple key values ​​composed of multiple states and events, and the multiple key values ​​include the first key value.

[0082] For example, keys can be composed of states and events within those states and stored in a state linked list. The state linked list includes a first key corresponding to (state 1, event 1) (as shown in Figure 2B). The first state (recorded as state 1) and the first event within that state (recorded as event 1) are matched against the state linked list, and the first key is found. Since the first key is associated with the first state closure, the first state closure can be determined as the state closure corresponding to the first event within the first state.

[0083] Optionally, the first target key value in the state list of the orchestration strategy is matched according to the first state of the first task, and at least one state closure associated with the first target key value is obtained; wherein, the state list includes multiple target key values ​​corresponding to multiple states, the multiple key values ​​include the first target key value, and the at least one state closure includes the first state closure corresponding to the first event.

[0084] The state list may store key-value pairs according to their states, and associate each key-value pair with one or more state closures. See Table 1 for details.

[0085] Table 1

[0086] As shown in Table 1, each state corresponds to a target key value, and each target key value corresponds to one or more state closures. The number of state closures corresponding to a target key value corresponds to the number of events that can be executed under that target key value's state. For example, assuming that two events can be executed in the first state, then the first target key value K1 corresponding to the first state is associated with two state closures. When obtaining the orchestration strategy corresponding to the first state, all state closures corresponding to the first state are obtained, including state closure 11 and state closure 12. When the first event in the first state needs to be executed, the state closure 11 corresponding to the first event is then matched and determined. The correspondence between the first event and state closure 11 can be stored as an attribute value of state closure 11. Alternatively, a state can correspond to only one state closure. For example, the second target key value K2 of the second state corresponds to state closure 21. Then, when executing any event in the second state, state closure 21 is invoked.

[0087] As can be seen, in this embodiment, by constructing key-value pairs based on the state of the first task and each event within that state, and associating each key-value pair with a state closure, orchestration strategies can be matched to the first state with more precise granularity, thereby improving the execution quality of the first task. Furthermore, constructing key-value pairs based on the state of the first task and associating each key-value pair with one or more state closures can improve the efficiency of obtaining orchestration strategies for each state, thereby improving the execution efficiency of the first task.

[0088] 103. Based on the orchestration strategy, call the atomic service to handle the events of the first task in the first state. The orchestration strategy includes the interface for calling the atomic service. The atomic service implements the first mobile network function and opens the first interface to the service orchestrator for scheduling and orchestration.

[0089] After obtaining the first state of the first task and the orchestration strategy within that first state, atomic services can be invoked according to the orchestration strategy to enable the invocation of mobile network functions for each atomic service, thereby completing end-to-end business functions. Atomic services provide independent network functions that do not depend on other services. For example, a user registration task might include three atomic services: mobility management service, authentication service, and subscription data service.

[0090] Optionally, invoking an atomic service based on an orchestration strategy to process events of the first task in the first state includes: invoking an atomic service based on a first state closure to process a first event of the first task in the first state, and obtaining the target processing result of the first event in the first state, wherein the first state closure includes an execution file for processing the first event in the first state, and the execution file includes a processing function that calls the interface of the atomic service.

[0091] Optionally, the orchestration strategy also includes a first state configuration file corresponding to the first state and the first event. After calling the atomic service to process the event of the first task in the first state according to the orchestration strategy, the method further includes: determining the target state to which the first state is migrated based on the target processing result of the first event in the first state and the correspondence between the processing result of the first event in the first state and the migration state of the first state in the first state configuration file; the first state configuration file includes the correspondence between the target processing result and the target state.

[0092] As described above, the orchestration strategy includes state closures and calls to atomic services, which means that the interface of the atomic service is called through the processing function in the executable file corresponding to the first event in the first state of the state closure.

[0093] Alternatively, the orchestration strategy may include a state configuration file. After calling an atomic service to process the first event of the first task in the first state and obtaining the processing result, the transition state of the first state can be obtained from the state configuration file based on the processing result of the first event.

[0094] Specifically, the process by which the business orchestrator calls atomic services based on the orchestration strategy to handle events of the first task in its first state includes processes ⑥, ⑦, and ⑧ in Figure 2B. Process ⑥ is used to call the interface of the atomic service according to the processing function of the executable file in the state closure. When a state closure instance is scheduled, the processing function corresponding to the event is called to schedule the atomic service. A service call process is completed by calling the atomic service interface or sending a message to the atomic service. The processing result of the state closure is obtained. Process ⑦ is used to determine the state configuration file corresponding to the state closure. After the state closure completes a scheduling cycle, the scheduled task calls the state configuration file corresponding to this state closure. Based on the correspondence between one or more return result codes and transition states stored in the configuration file, the target state corresponding to the current target return result code (or target processing result) is determined, realizing the state transition from the first state to the target state. Process ⑧ is used to migrate the first state of the first task to the target state after executing the events of the first state. As a scheduled task, the first task records the state information after the transition and the currently scheduled state closure instance. If the state closure instance has been scheduled, no recording is required. The scheduled task is returned to the task instance management system, awaiting the next scheduling.

[0095] The processes ①②③④⑤⑥⑦⑧ in Figure 2B above describe the scheduling process of an event (message). A task will have multiple events (messages). The scheduling of a task is a sequence of multiple events (messages). The above scheduling process will be performed each time an event (message) occurs, until all events (messages) of the task have been processed.

[0096] As can be seen, this application provides a method for task scheduling. The method determines the first task to be executed based on a received request message, then confirms the first state corresponding to the first task and the orchestration strategy corresponding to the first state. Finally, it schedules atomic services according to the orchestration strategy corresponding to the first state to execute the events of the first task in the first state, thereby achieving the execution of the entire first task. In this process, each atomic service is scheduled independently without needing to interact with each other, achieving decoupling of the services in the task, reducing the deployment cycle of new features, and minimizing the potential impact on existing network functions.

[0097] Example 2: The following specific task scheduling examples will be used to further illustrate the above task scheduling method.

[0098] Referring to Figures 3A and 3B, Figure 3A is an interaction sequence diagram of the user registration process provided in an embodiment of this application, and Figure 3B is a task scheduling example diagram of the business orchestrator corresponding to the user registration process provided in an embodiment of this application. The following describes the process of task scheduling performed by the business orchestrator in the user registration process task based on Figures 3A and 3B.

[0099] The business orchestrator schedules the user registration process task in the following steps:

[0100] 1. Upon receiving a registration request message, the business orchestrator creates an initial registration task based on the message type and the user identifier carried in the message. The task is set to its initial state and added to the task instance management system. This corresponds to step 1 in Figure 3B.

[0101] 2. The scheduled task looks up the context based on the user identifier. Since this is the first time the task is created, it may not be found initially, but it will be found in subsequent processes. The scheduled task uses its current state and registration message as keys to look up the state list in the orchestration strategy management system to find the matching state closure. This corresponds to step 2 in Figure 3B.

[0102] 3. The scheduled task loads the matched state closure (instance), passing in the user identifier, registration message, current status, and other information to the state closure instance. Here, the state closure instance is the initial registration state closure instance. This corresponds to step 3 in Figure 3B.

[0103] 4. After processing the initial registration state closure instance, the processing result is returned. This state instance returns a Finished return code. The scheduled task looks up the state configuration file corresponding to this state closure and finds the target migration state (or target state) based on the Finished return code. In this example, the target migration state is the waiting-to-create-user-context state. This corresponds to steps 6 and 4 in Figure 3B.

[0104] 5. The scheduled task sets its current state to "Waiting to create user context" and looks up the state closure instance based on this state. The scheduled task loads the corresponding state closure instance and passes information such as user identifier, registration message, and current state to this state closure instance. This corresponds to step 4 in Figure 3B.

[0105] 6. The user context creation closure instance interacts with the mobility management service, sending a user context creation request to the mobility management service and returning the processing result. Here, the returned processing result is "continue". This corresponds to step 5 in Figure 3B.

[0106] 7. The scheduled task locates the state configuration file corresponding to this closure instance and, based on the return value `continue`, finds the target migration state, which is "Waiting for context creation result". The scheduled task sets its current state to "Waiting for context creation result". It exits scheduling and waits for the context creation response message. This corresponds to steps 6 and 4 in Figure 3B.

[0107] 8. After creating the user context, the Mobility Management Service sends a context creation response message. The message carries information such as the user identifier and task identifier. This corresponds to step 5 in Figure 3B.

[0108] 9. After receiving the context creation response message, the task scheduler matches the initially registered task instance based on the task identifier and user identifier, and schedules this task. This corresponds to step 2 in Figure 3B.

[0109] 10. The scheduled task searches the state list based on its current state, the waiting context creation result state, and the context creation response message. It then matches the corresponding state closure instance and loads it. After processing the context creation response message, the state closure instance returns the processing result, which is "Finished". This corresponds to step 4 in Figure 3B.

[0110] 11. The scheduled task searches the state configuration file corresponding to this state closure and finds the target migration state based on the returned value Finished. The migration state is the waiting authentication state. The scheduled task sets its current state to the waiting authentication state and searches the state linked list based on this state to match the authentication state closure. This corresponds to steps 6 and 7 in Figure 3B.

[0111] 12. The subsequent processing steps are similar to those above, until all interactions in the registration process are completed.

[0112] Example 3: The service orchestrator in Figure 2B can also be used to provide a programmable interface for editing orchestration strategies. This is described in detail in this example.

[0113] Referring to Figure 4A, which is a flowchart of an orchestration strategy editing method provided in an embodiment of this application, the method is applied to the service orchestrator in Figure 1A, and specifically to the programmable interface in the service orchestrator. As shown in Figure 4A, the method includes the following steps:

[0114] 201. Receive a second request, which is used to request editing the orchestration strategy. The orchestration strategy includes calling the interface of the atomic service. The atomic service implements the first mobile network function and opens the first interface to the service orchestrator for scheduling and orchestration.

[0115] The method in this embodiment is combined with the method in the first embodiment described above. That is to say, the method in this embodiment can be applied to the service orchestrator in Figure 1A. The service orchestrator can execute the method in Figure 2A. Furthermore, the service orchestrator can execute the method in Figure 4A in this embodiment.

[0116] Referring to Figure 4B, which is a schematic diagram illustrating the working principle of another service orchestrator provided in this embodiment, as shown in Figure 4B, this service orchestrator can also implement processes ①②③④⑤⑥⑦⑧ described in Embodiment 1 above. Simultaneously, this service orchestrator can also implement process ⑨, used to edit the orchestration strategy. That is to say, the service orchestrator provides editing operations on the state list, state closure, and state configuration file through open interfaces, enabling programmable and software-upgrade-free modification of the orchestration strategy.

[0117] Editing orchestration strategies includes adding, modifying, or deleting them. Correspondingly, the business orchestrator provides the following interfaces:

[0118] Interface 1: A new orchestration strategy interface has been added. When this interface receives a second request, the key information in the second request may include: <state, event, state closure, state profile>. The input parameters can be a single record or a list of parameters. State, state closure, and state profile are required, while event is optional. If no event is specified, it indicates that only state information can be used to match the state closure and state profile.

[0119] Interface 2: Modify Orchestration Strategy Interface. When this interface receives a second request, the key information in the second request may include: <state, event, state closure, state configuration file>. Input parameters can be a single record or a list of parameters. The state parameter is required; all others are optional.

[0120] Interface 3: Delete Orchestration Strategy Interface. When this interface receives a second request, the key information in the second request may include: <status, event>. Input parameters can be a single record or a list of parameters. The status parameter is required, and the event parameter is optional.

[0121] 202. Editing and arranging strategy based on the second request.

[0122] After receiving the second request (or instruction) through the programmable interface, the business orchestrator edits the storage orchestration strategy.

[0123] Optionally, editing the orchestration strategy based on the second request includes adding an orchestration strategy based on the second request. The second request includes a second state, a second state closure, and a second state configuration file, or it may also include a second event in the second state. Adding an orchestration strategy based on the second request includes: adding a second key value of the second state and the second event to the state chain and associating the second key value with the second state closure; or adding a second target key value of the second state to the state chain and associating it with the second state closure; and establishing an association between the second state closure and the second state configuration file.

[0124] For example, the second request is used to request the addition of a new orchestration strategy, and the information included in the second request is <second state, second state closure, second state configuration file>. After receiving the second request, the programmable interface adds the second key-value pair corresponding to the second state to the state chain, stores the second state closure and the second state configuration file, and establishes the association between the second key-value pair and the second state closure, as well as the association between the second state closure and the second state configuration file. In this case, <second state closure, second state configuration file> is only one of the contents associated with the second key-value pair. If possible, the second key-value pair may also be associated with other contents. Assuming that the second key-value pair corresponding to the second state and other contents associated with the second key-value pair already exist in the state chain, then only the association between <second state closure, second state configuration file> and the second key-value pair needs to be added, without adding the second key-value pair to the state chain.

[0125] Alternatively, assuming the second request includes the information <second state, second event, second state closure, second state configuration file>, after receiving the second request, the programmable interface adds the second key value corresponding to the second state and the second event to the state chain list, stores the second state closure and the second state configuration file, and establishes the association between the second key value and the second state closure, as well as the association between the second state closure and the second state configuration file.

[0126] As shown in Figure 4B, a key value K4 (state 4 + event 4), a state closure 4, and a state configuration file 4 are added to the state chain list to implement the function call of atomic service 4.

[0127] Optionally, editing the orchestration strategy based on the second request includes modifying the orchestration strategy based on the second request. The second request includes at least one of the following: a third state, a third state closure, a third state configuration file, or also includes a third event in the third state. Modifying the orchestration strategy based on the second request includes: modifying or replacing the state configuration file and / or the state closure corresponding to the third state according to the third state configuration file and / or the third state closure; or modifying or replacing the third state configuration file and / or the third state closure corresponding to the third event in the third state according to the third state configuration file and / or the third state closure.

[0128] For example, the second request is used to request modification of the orchestration strategy. The information included in the second request is <third state, updated third state closure, updated third state configuration file>. If the service orchestrator originally stored the information as <third state, third state closure, third state configuration file>, then after receiving the second request through the programmable interface, it will replace the originally stored information with <third state, updated third state closure, updated third state configuration file>.

[0129] Alternatively, suppose the second request includes the information <third state, third event, updated third state closure, updated third state configuration file>, while the business orchestrator originally stored the information <third state, third event, third state closure, third state configuration file>. Then, after receiving the second request, the stored content will be replaced with <third state, third event, updated third state closure, updated third state configuration file>.

[0130] As shown in Figure 4B, the migration state after event 3 is modified. The interface input parameters are modified to: <state 3, event 3, state configuration file 3 (modified)>. The modified state configuration file is shown in the figure above, adding a description that the migration to state 4 occurs when the processing result is "Finished".

[0131] Optionally, editing the orchestration strategy based on the second request includes deleting the orchestration strategy based on the second request, wherein the second request includes a fourth state, or may also include a fourth event in the fourth state; deleting the orchestration strategy based on the second request includes: deleting the orchestration strategy corresponding to the fourth event in the fourth state; or deleting the orchestration strategy corresponding to the fourth state.

[0132] For example, the second request is used to request the deletion of an orchestration policy, and the information included in the second request is "<fourth state>". The service orchestrator originally stored the orchestration policies corresponding to the fourth state, so after receiving the second request through the programmable interface, it can delete all orchestration policies corresponding to the fourth state.

[0133] Alternatively, if the second request includes information such as "fourth state, fourth event", and the service orchestrator originally stored orchestration policies corresponding to the fourth state and fourth event, then after receiving the second request through the programmable interface, the orchestration policies corresponding to the fourth state and fourth event can be deleted.

[0134] As can be seen, in this embodiment of the application, the orchestration strategy is dynamically modified through the open interface of the business orchestrator. The newly added atomic service is called by adding a new orchestration strategy, so that the dynamically launched atomic service does not affect the original business, thereby ensuring the stability and reliability of the existing service functions and the efficiency of the implementation of the new business.

[0135] Example 4: The following specific examples of editing layout strategies will be used to further illustrate the above-mentioned layout strategy editing method.

[0136] Referring to Figure 5, which is a flowchart illustrating the dynamic editing of orchestration strategies during the user registration process according to an embodiment of this application, the user registration process has been described in detail in Embodiment 2 above and will not be described in detail here, with simplified steps. The following steps have been added to the existing user registration process to enable dynamic editing of orchestration strategies:

[0137] 1. Add Orchestration Strategy 1: Call the business orchestrator's interface to add an orchestration strategy. The parameters are: <Waiting to obtain strategy status, obtaining strategy process status closure, obtaining strategy process status closure configuration file>, <Waiting to obtain strategy process response status, obtaining strategy process response message, obtaining strategy process status closure, obtaining strategy process status closure configuration file>. After receiving this interface call, the business orchestrator adds the corresponding status and event key-value indexes to the status chain and points them to the corresponding status closure. The status configuration file description is: Continue: Waiting to obtain strategy process response status; Finished: Waiting for registration completion status; Other: Process failed.

[0138] 2. Add Orchestration Strategy 2: Call the business orchestrator's new orchestration strategy interface with the following parameters: <Get strategy process end status, Get strategy process end status closure, Get strategy process end status closure configuration file>, <Wait to get strategy process end response status, Get strategy process end response message, Get strategy process end status closure, Get strategy process end status closure configuration file>. Upon receiving this interface call, the business orchestrator adds the corresponding status and event key-value indexes to the status chain and points them to the corresponding status closure. The status configuration file description is as follows: Continue: Waiting to get strategy process end response status; Finished: Process successful; Other: Process failed.

[0139] 3. Modify Orchestration Strategy 1: This step orchestrates the business process for obtaining the business strategy after the process for obtaining the contract data. The parameters are: <Waiting for user contract data response status, obtaining contract data response message, modified status configuration file>. The status configuration file description is changed to: Continue: Waiting for contract data response status; Finished: Waiting for strategy status; Other: Process failed.

[0140] 4. Modify Orchestration Strategy 2: This step orchestrates the action of notifying the business strategy service process to end after the action of notifying the contract data management service process to end. The parameters are: <Waiting for contract data process response status, contract data process end response message, modified status configuration file>. The status configuration file description is changed to: Continue: Waiting for contract data process response status; Finished: Obtaining strategy process end status; Other: Process failed.

[0141] 8. Obtaining Policy Data (Policy Service Dynamically Deployed). Based on the updated orchestration policy, after the business orchestrator completes the process of obtaining contract data, its state transitions to the "Waiting to Obtain Policy" state. Based on this state, it schedules the business processing functions within the policy acquisition process state closure, ultimately scheduling the policy service to obtain the user policy data.

[0142] 13. The business orchestrator's process ends. Based on the updated orchestration strategy, after the notification of the contract data management service process ends, the business orchestrator transitions to the end state of the strategy acquisition process. Based on this state, it schedules the business processing function in the strategy acquisition process end state closure, and finally schedules the strategy service notification process to end.

[0143] Please refer to Figure 6, which is a schematic diagram of a communication device provided in an embodiment of this application. This communication device can be used to execute any of the methods in the foregoing embodiments.

[0144] As shown in Figure 6, the communication device includes a processing module 1501 and a transceiver module 1502. The processing module 1501 may be one or more processors, and the transceiver module 1502 may be a transceiver or a communication interface. This communication device can be used to implement the functions of the first functional network element, the data analysis consumer, and the network element management system involved in any of the above method embodiments. These network elements or network functions may be network components in hardware devices, software functions running on dedicated hardware, or virtualized functions instantiated on a platform (e.g., a cloud platform). Optionally, the communication device may also include a storage module 1503 for storing the program code and data of the communication device.

[0145] The communication device can function as a first device or a chip within a first device, and execute the method steps performed by the service orchestrator in embodiments one through four described above. The transceiver module 1502 supports communication with terminal devices or atomic services. The processing module 1501 can be used to support the execution of actions performed by the first device in the above method embodiments, excluding sending and receiving.

[0146] Specifically, the transceiver module 1502 is used to receive a first request, which requests the execution of a first task; the processing module 1501 is used to determine the orchestration strategy corresponding to the first state of the first task based on the first request; and to call an atomic service based on the orchestration strategy to process the events of the first task in the first state. The orchestration strategy includes an interface for calling the atomic service, which implements a first mobile network function and opens a first interface to the service orchestrator for scheduling and orchestration.

[0147] In one feasible implementation, the orchestration strategy includes a first state, a first event in the first state, and a first state closure corresponding to the first state and the first event. Invoking an atomic service based on the orchestration strategy to process the event of the first task in the first state includes: invoking an atomic service based on the first state closure to process the first event of the first task in the first state, and obtaining the target processing result of the first event in the first state. The first state closure includes an execution file for processing the first event in the first state, and the execution file includes a processing function for calling the interface of the atomic service.

[0148] In one feasible implementation, the orchestration strategy further includes a first state configuration file corresponding to the first state and the first event. After calling an atomic service to process the event of the first task in the first state according to the orchestration strategy, the method further includes: determining the target state to which the first state is migrated based on the target processing result of the first event in the first state and the correspondence between the processing result of the first event in the first state and the migration state of the first state in the first state configuration file; the first state configuration file includes the correspondence between the target processing result and the target state.

[0149] In one feasible implementation, before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the processing module 1501 is further configured to: create the first task based on the first request, and determine the initial state of the first task as the first state.

[0150] In one feasible implementation, before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the processing module 1501 is further configured to: match the first task and the first state of the first task from the task instance management based on the first request, wherein the task instance management includes multiple tasks to be scheduled, and the first task is included among the multiple tasks to be scheduled.

[0151] In one feasible implementation, the first request includes at least one of the following: a task identifier for the first task; a message type for the first request; a user identifier; and / or a session identifier.

[0152] In one feasible implementation, determining the orchestration strategy corresponding to the first state of the first task based on the first request includes: matching the first key value in the state chain of the orchestration strategy according to the first state of the first task and the first event in the first state, and obtaining the first state closure associated with the first key value; wherein the state chain includes multiple key values ​​composed of multiple states and events, and the multiple key values ​​include the first key value.

[0153] In one feasible implementation, determining the orchestration strategy corresponding to the first state of the first task based on the first request includes: matching the first target key value in the state chain of the orchestration strategy according to the first state of the first task, and obtaining at least one state closure associated with the first target key value; wherein the state chain includes multiple target key values ​​corresponding to multiple states, the multiple key values ​​include the first target key value, and the at least one state closure includes the first state closure corresponding to the first event.

[0154] In one feasible implementation, the transceiver module 1502 is further configured to: receive a second request, the second request being for requesting an editing and arrangement strategy; the processing module 1501 is further configured to: edit the editing and arrangement strategy based on the second request.

[0155] In one feasible implementation, editing the orchestration strategy based on the second request includes adding an orchestration strategy based on the second request. The second request includes a second state, a second state closure, and a second state configuration file, or it may also include a second event in the second state. Adding an orchestration strategy based on the second request includes: adding a second key value of the second state and the second event to the state chain and associating the second key value with the second state closure; or adding a second target key value of the second state to the state chain and associating it with the second state closure; and establishing an association between the second state closure and the second state configuration file.

[0156] In one feasible implementation, editing the orchestration strategy based on the second request includes modifying the orchestration strategy based on the second request. The second request includes at least one of the following: a third state, an updated third state closure, an updated third state configuration file, or a third event in the third state. Modifying the orchestration strategy based on the second request includes: modifying or replacing the third state configuration file and / or the third state closure in the third state according to the updated third state configuration file and / or the updated third state closure; or modifying or replacing the third state configuration file and / or the third state closure corresponding to the third event in the third state according to the updated third state configuration file and / or the updated third state closure.

[0157] In one feasible implementation, the processing module 1501 is further configured to: edit the orchestration strategy based on the second request, including deleting the orchestration strategy based on the second request, wherein the second request includes a fourth state, or also includes a fourth event in the fourth state; and delete the orchestration strategy based on the second request, including: deleting the orchestration strategy corresponding to the fourth event in the fourth state; or deleting the orchestration strategy corresponding to the fourth state.

[0158] The processing module 1501 may be a processor that can execute computer execution instructions stored in the storage module to cause the chip to perform the methods involved in any of the above embodiments.

[0159] Furthermore, a processor may include a controller, an arithmetic logic unit (ALU), and registers. For example, the controller is primarily responsible for instruction decoding and issuing control signals for the operations corresponding to the instructions. The ALU is primarily responsible for performing fixed-point or floating-point arithmetic operations, shift operations, and logical operations, and can also perform address operations and translations. Registers are primarily responsible for storing register operands and intermediate operation results temporarily stored during instruction execution. In specific implementations, the processor's hardware architecture can be an ASIC architecture, a microprocessor without interlocked piped stages architecture (MIPS), an advanced reduced instruction set machine (RISC) machine (ARM) architecture, or a network processor (NP) architecture, etc. The processor can be single-core or multi-core.

[0160] The storage module can be an internal storage module of the chip, such as a register or cache. Alternatively, the storage module can be an external storage module, such as ROM or other types of static storage devices that can store static information and instructions, such as RAM.

[0161] It should be noted that the functions of the processor and interface can be implemented through hardware design, software design, or a combination of hardware and software; no restrictions are imposed here.

[0162] Figure 7 shows a schematic diagram of another communication device provided in an embodiment of this application. The communication device 1100 includes a processor 1101. Optionally, the communication device 1100 may further include an interface circuit 1102, and the processor 1101 and the interface circuit 1102 are coupled to each other. It is understood that the interface circuit 1102 may be a transceiver or an input / output interface. Optionally, the communication device 1100 may further include a memory 1103 (shown as dashed lines in the figure), which is used to store instructions executed by the processor 1101, or to store input data required by the processor 1101 to execute instructions, or to store data generated after the processor 1101 executes instructions.

[0163] For specific implementation details of the processor 1101, interface circuit 1102, and memory 1103 described above, please refer to the relevant descriptions in Embodiments 1 to 4.

[0164] When the aforementioned communication device is a chip applied in the first device, the chip implements the function of the service orchestrator in the above method embodiments. The chip receives information from other modules (such as radio frequency modules or antennas) in the first device, which is sent to the service orchestrator by network elements such as terminal devices or atomic services; or, the chip sends information to other modules (such as radio frequency modules or antennas) in the first device, which is sent to network elements such as terminal devices or atomic services by the service orchestrator.

[0165] Furthermore, it should be noted that the aforementioned transceiver unit and / or processing unit can be implemented through virtual modules. For example, the processing unit can be implemented through software functional units or virtual devices, and the transceiver unit can be implemented through software functions or virtual devices. Alternatively, the processing unit or transceiver unit can also be implemented through physical devices. For example, if the device is implemented using a chip / chip circuit, the transceiver unit can be an input / output circuit and / or a communication interface, performing input operations (corresponding to the aforementioned receiving operation) and output operations (corresponding to the aforementioned sending operation); the processing unit is an integrated processor, microprocessor, or integrated circuit.

[0166] It is understood that the processor 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, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0167] This application provides a communication device, which includes at least one processor and a memory; wherein the memory is used to store computer programs or instructions; and at least one processor is used to execute the computer programs or instructions in the memory, such that the methods corresponding to each device or network element in any of the above methods are executed.

[0168] This application provides a communication system, which includes a first device corresponding to a service orchestrator, and network elements such as terminal devices or atomic services.

[0169] This application provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, which, when executed, cause the computer to perform the method described in any of the above methods.

[0170] This application provides a computer program product, which includes computer program code. When the computer program code is run, it causes the computer to perform the method described in any of the above methods.

[0171] This application provides a chip coupled to a memory for reading and executing program instructions in the memory, so that the device containing the chip implements the method described in any of the above methods.

[0172] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a particular embodiment can be found in the relevant descriptions of other embodiments. It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0173] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above 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 devices or units may be electrical or other forms.

[0174] The units described above 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.

[0175] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A task scheduling method, characterized by, The method includes: Receive a first request, the first request being used to request the execution of a first task; Based on the first request, determine the orchestration strategy corresponding to the first state of the first task; Based on the orchestration strategy, an atomic service is invoked to process the events of the first task in the first state. The orchestration strategy includes an interface for invoking the atomic service, which implements a first mobile network function and exposes a first interface to the service orchestrator for scheduling and orchestration.

2. The method of claim 1, wherein, The orchestration strategy includes a first state, a first event in the first state, and a first state closure corresponding to the first state and the first event. The step of invoking an atomic service based on the orchestration strategy to process the event of the first task in the first state includes: Based on the first state closure, the atomic service is invoked to process the first event of the first task in the first state, and the target processing result of the first event in the first state is obtained. The first state closure includes an execution file for processing the first event in the first state, and the execution file includes a processing function that calls the interface of the atomic service.

3. The method of claim 2, wherein, The orchestration strategy also includes a first state configuration file corresponding to the first state and the first event. After invoking an atomic service to process the event of the first task in the first state according to the orchestration strategy, the method further includes: Based on the target processing result of the first event in the first state, and the correspondence between the processing result of the first event in the first state and the transition state of the first state in the first state configuration file, the target state to which the first state is transitioned is determined; the first state configuration file includes the correspondence between the target processing result and the target state.

4. The method according to any one of claims 1 to 3, characterized in that, Before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the method further includes: The first task is created based on the first request, and the initial state of the first task is determined to be the first state.

5. The method according to any one of claims 1 to 3, characterized in that, Before determining the orchestration strategy corresponding to the first state of the first task based on the first request, the method further includes: Based on the first request, the first task and the first state of the first task are matched from the task instance management. The task instance management includes multiple tasks to be scheduled, and the first task is among the multiple tasks to be scheduled.

6. The method according to claim 4 or 5, characterized in that, The first request includes at least one of the following: The task identifier of the first task; The message type of the first request, user identifier, and / or session identifier.

7. The method according to any one of claims 1 to 6, characterized in that, The orchestration strategy for determining the first state of the first task based on the first request includes: The first key value in the state list of the orchestration strategy is matched with the first state of the first task and the first event in the first state, and the first state closure associated with the first key value is obtained; wherein the state list includes multiple key values ​​composed of multiple states and events, and the first key value is included among the multiple key values.

8. The method according to any one of claims 1 to 5, characterized in that, The orchestration strategy for determining the first state of the first task based on the first request includes: Match the first target key value in the state list of the orchestration strategy to the first state of the first task, and obtain at least one state closure associated with the first target key value; wherein, the state list includes multiple target key values ​​corresponding to multiple states, the multiple key values ​​include the first target key value, and the at least one state closure includes the first state closure corresponding to the first event.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: Receive a second request, which is used to request the editing of the layout strategy; Edit the layout strategy based on the second request.

10. The method of claim 9, wherein, The orchestration strategy edited based on the second request includes adding an orchestration strategy based on the second request. The second request includes a second state, a second state closure, and a second state configuration file, or it may also include a second event in the second state. The addition of an orchestration strategy based on the second request includes: Add a second key value to the state list for the second state and the second event, and associate the second key value with the closure of the second state; or Add an association between the second target key value of the second state and the closure of the second state in the state chain; Establish the association between the second state closure and the second state configuration file.

11. The method of claim 9, wherein, The orchestration strategy editing based on the second request includes modifying the orchestration strategy based on the second request, wherein the second request includes at least one of the following: a third state, an updated third state closure, an updated third state configuration file, or further includes a third event in the third state. The modification of the orchestration strategy based on the second request includes: Modify or replace the third-state configuration file and / or the third-state closure corresponding to the third state according to the updated third-state configuration file and / or the updated third-state closure; or Modify or replace the third state configuration file and / or the third state closure corresponding to the third event in the third state according to the third state configuration file and / or the third state closure.

12. The method of claim 9, wherein, The method further includes: the editing and orchestration strategy based on the second request includes deleting the orchestration strategy based on the second request, wherein the second request includes a fourth state, or further includes a fourth event in the fourth state; The deletion orchestration strategy based on the second request includes: Delete the orchestration strategy corresponding to the fourth event in the fourth state; or Delete the orchestration strategy corresponding to the fourth state.

13. A communications device, characterized by Includes units or modules for implementing the method as described in any one of claims 1 to 12.

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

15. A communication system, characterized by The communication system includes means for performing the method as described in any one of claims 1 to 12, and an atomic service for processing events of the first task in a first state.

16. A chip system, characterized by The chip system includes at least one processor, a memory, and an interface circuit. The memory, the interface circuit, and the at least one processor are interconnected via lines. The at least one memory stores instructions. When the instructions are executed by the processor, the method described in any one of claims 1-12 is implemented.

17. A computer readable storage medium characterized by: The computer-readable storage medium stores a computer program that, when executed, enables the implementation of the method according to any one of claims 1-12.

18. A computer program product, characterised in that, The computer program product includes instructions that, when executed, implement the method of any one of claims 1-12.

Images