System and method for network workflow planning

Abstract

Systems and methods for autonomous workflow planning in a communication network. A mission intention is processed using a large language model to generate a mission graph, which specifies actions for performing the mission and their interdependencies. Similar historical or sample mission graphs can be retrieved and customized. The mission intention can be decoupled into a sub-intention graph, and the constituent sub-intentions can be modified as appropriate. Sub-mission graphs for the sub-intentions can be generated and customized. The sub-mission graphs can be chained together according to the sub-intention graph to generate the mission graph, which can be stored as a further historical mission graph. The customization can be based on the mission intention and other available contextual information.

Description

SYSTEM AND METHOD FOR NETWORK WORKFLOW PLANNING

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to United States Provisional Patent Application No. 63 / 696,643, filed September 19, 2024, the contents of which are incorporated herein by reference.TECHNICAL FIELD

[0003] The present disclosure generally pertains to automatic communication network configuration and, in particular, to a system and a method for network workflow planning.BACKGROUND

[0004] In existing telecommunication / network standards, e.g., 3rd Generation Partnership Project (3GPP) for 4G / 5G, all network workflows / procedures (e.g., Figure 4.2.2.2.2-1 in 3GPP TS 23.502 “Procedures for the 5G System, ” V 18.2.0, June 2023, describes a network workflow / procedure for registration) are defined in fixed way. The fixed network workflow has no flexibility to be adapted / changed according to different user intentions, network environments, or a combination thereof. In order to cover as much potential cases as possible, massive workflow / procedures with high complexity are defined in standard documents.

[0005] A mission management (MM) framework for future network has been proposed. In the MM framework, mission execution function (MEF) is defined as mission level controller, service control function (SCF) , task control function (TCF) are defined as anything-as-a-service (XaaS) level controller. The MEF has the following functionalities in MM framework. Intention resolution: MEF can resolve the user intention into a mission slice template. Mission establishment: MEF can instantiate a mission slice template as a mission instance by selecting and configuring available network functions (NFs) and network resources (e.g., computing, communication, storage, power resources) . Mission execution control: MEF can manage the execution process of a mission instance by monitoring the performance of NFs and resources involved in the mission instance, and coordinating their execution behaviors through control messages.

[0006] Detailed solutions for intention resolution need to be described for the workflows / procedures for mission establishment and mission execution.

[0007] Retrieve-augment-generation (RAG) based large language model (LLM) related research is an emerging technique. In a RAG system, there are formatted knowledge data samples (prepared by us manually) embed in a vector dataset, an LLM / Artificial Intelligence (AI) (e.g., Llama LLM, chatGPT) can interact with the vector dataset to retrieve useful data for answering user queries. A typical RAG workflow includes the following steps. Retrieve: For each user query, a RAG controller / agent searches the vector dataset and select matched knowledge data samples. Augment: the RAG controller augments the user query with selected knowledge data sample to form LLM prompts for LLM inferencing. Generate: the RAG controller sends the augmented LLM prompts to the LLM. The LLM generates the answer according to the prompts.

[0008] However, to date, developments in network / procedure workflow planning that incorporate RAG techniques are absent or are subject to improvement.

[0009] Therefore, there is a need for a system and method for network workflow planning that obviates or mitigates one or more limitations in the prior art.

[0010] This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.SUMMARY

[0011] Embodiments of this disclosure provide for systems and methods for network workflow planning.

[0012] Leveraging the emerging RAG / LLM techniques, embodiments of the present disclosure provide a method which is able to realize the autonomous generation / plan of the network workflow according to various user intentions. Embodiments of the proposed autonomous network workflow planning can potentially resolve the nonflexible and complexity issues caused by fixed network workflow defined in existing standards.

[0013] Embodiments of the present disclosure pertain to a network function (e.g. an A-CAP controller) or a combination of network functions, which operate to receive a mission intention from a user and produce a corresponding configuration for network capabilities. Thus, network provisioning automation is supported. The mission intention can be provided using natural language. The network capability configuration can be used to subsequently configure various network capabilities, thus preparing the network to operate according to the mission intention. The controller can leverage a LLM as well as a knowledge dataset to generate the network capability configuration. RAG may be used to improve or augment the mission intention for processing by the LLM. The knowledge dataset can include historical information on prior network configurations, graph information, and other contextual information.

[0014] Embodiments of the present disclosure pertain to a process by which the network functions as described above operate to produce a network capability configuration based on a mission intention. The process can further include the configuration and implementation of the network configuration.

[0015] Embodiments of the present disclosure pertain to a process by which network capabilities register for subsequent participation in network capability configurations for example as described above. This can include validating and modifying network capabilities as required to avoid redundancy, conflicts, or the like.

[0016] According to embodiments of the present disclosure, there is provided a method for autonomous network workflow planning in a communication network, comprising receiving, from a user device, a mission intention indicative of a mission to be performed by the network, decoupling the mission intention into a sub-intention graph comprising a plurality of sub-intentions along with interdependencies between the sub-intentions, wherein executing the sub-intentions according to the interdependencies achieves the mission intention. The method further comprises generating, for each of the sub-intentions, a corresponding sub-mission graph comprising one or more actions and corresponding action interdependencies, generating a mission graph based on the sub-mission graphs and the sub-intention graph, and providing, based on the mission graph, a set of network capability configurations for configuring network capabilities of the network to perform the mission.

[0017] In an embodiment, the indication of the mission is expressed using natural language. The method further comprises using a large language model (LLM) and a knowledge dataset to process the mission intention into the one or more actions. The decoupling of the mission intention includes generating intention-decoupled prompts for the user intention and sending the intention-decoupled prompts to the LLM. The decoupling further includes retrieving, through interacting between the LLM and the knowledge dataset, a graph dataset in the knowledge dataset for a sample / historical mission graph having an associated intention which is semantically or contextually similar or related to the user intention. The decoupling further includes outputting, from the LLM, an intention-decoupled result including a matched / generated intention / sub-intention graph.

[0018] In an embodiment, the retrieving of the graph dataset includes comparing the generated mission graph to one or more mission graphs in the graph dataset of sample / historical mission intention and identifying a mission graph with a highest similarity / relationship score to the mission intention in terms of semantics or contexts.

[0019] In an embodiment, the decoupling further includes requesting confirmation indicative of whether or not the intention-decoupled result is acceptable by a user, and, when the intention decoupled result unacceptable, modifying the intention-decoupled result.

[0020] According to an embodiment, the generating of the intention-decoupled prompts includes concatenating the user intention with pre-defined prompt words or context.

[0021] According to an embodiment, the generating the sub-mission graph includes resolving the sub-intention. The resolving of the sub-intention includes sending the sub-intention to a knowledge dataset, conducting one or more rounds of semantic-similarity based search in the knowledge dataset to retrieve the one or more actions, where the one or more actions are based on current user / network conditions, and chaining the one or more actions based on their inter-dependencies to generate one of the corresponding sub-mission graphs, corresponding to the sub-intention.

[0022] In an embodiment, the method further includes sending a dependency resolve request to the LLM to determine whether two of the actions can be chained or not.

[0023] In embodiment, the generating of the mission graph includes chaining the sub-mission graphs.

[0024] In an embodiment, the generating of the mission graph includes performing path optimization to remove cyclic routes from the mission graph.

[0025] According to an embodiment, the method further includes validating the generated mission graph prior to providing the set of network capability configurations, where the validating includes removing one or more redundant action from the mission graph, when the one or more redundant actions are present, and resolving one or more conflicting action in the mission graph, when said one or more conflicting actions are present.

[0026] According to an embodiment, the resolving of conflicting action includes re-executing the generating of the corresponding sub-mission graph and the generating of the mission graph to incorporate therein one or more alternative actions.

[0027] In an embodiment, the method further includes storing the generated mission graph information to the knowledge dataset.

[0028] In an embodiment, the method further includes configuring or initiating configuration of the network capabilities according to the set of network capability configurations.

[0029] In accordance with embodiments of the present disclosure, there is provided a method for registering new or updated candidate actions in a knowledge dataset for autonomous network workflow planning. The method includes receiving, by a controller, a request to register one or more new / updated candidate actions associated with a network capability (NC) . The method includes notifying a knowledge dataset to receive the one or more candidate actions from the network capability, with the network capability to transmit the one or more candidate actions to the knowledge dataset. Furthermore according to or accompanying the method, the network capability transmits the one or more candidate actions to the knowledge dataset. Further according to or accompanying the method, a validator validates the one or more candidate actions in the knowledge dataset. The validated one or more candidate actions are stored in the knowledge dataset for retrieval in future mission graph generation.

[0030] In an embodiment, the validating the one or more candidate actions includes receiving, by the validator, the one or more candidate actions from the network capability, determining, by the validator, whether the one or more candidate actions contain any redundant candidate actions or conflict candidate actions, and outputting validation results to the knowledge dataset.

[0031] According to an embodiment, the method further includes modifying the one or more candidate actions upon detection of redundancies or conflicts, and initiating re-execution of the validation of the one or more candidate actions until the one or more candidate actions are determined to be valid.

[0032] In accordance with embodiments, there is provided an electronic apparatus in a communication network, the apparatus comprising a processor, a network interface and a memory and configured to perform one or more of the methods as described herein. In accordance with embodiments, there is provided a system of such electronic apparatuses, networked together and configured to interact to perform one or more of the methods as described herein.

[0033] In accordance with an embodiment of the present disclosure, there is provided a computer program product comprising a (e.g. non-transitory) computer readable medium having statements and instructions stored thereon which, when executed by one or more computer processors, cause the computer processors to perform the method as set forth above. The computer processors may be parts of one or more electronic apparatuses (e.g. network entities) as described herein.

[0034] Embodiments have been described above in conjunctions with aspects of the present invention upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described, but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are otherwise incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0036] FIG. 1A shows a system, including a controller, for network workflow planning and configuration, according to some embodiments of the present disclosure.

[0037] FIG. 1B is a table showing lists of features grouped under Action Information, Mission Graph Information and Network State Memory, respectively.

[0038] FIG. 2 shows a system, including an associated agent and its actions, in support of network workflow planning and configuration, according to some embodiments of the present disclosure.

[0039] FIGs. 3A, 3B and 3C show operations in support of network workflow planning and configuration, according to some embodiments of the present disclosure.

[0040] FIGs. 4A and 4B show operations in support registering and configuring network capabilities to a knowledge dataset, in support of network workflow planning and configuration, according to some embodiments of the present disclosure.

[0041] FIG. 5 illustrates an example of a sub-intention graph, according to an embodiment of the present disclosure.

[0042] FIG. 6 illustrates an electronic device which may be configured to perform operations according to embodiments of the present disclosure.

[0043] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.DETAILED DESCRIPTION

[0044] Embodiments of the present disclosure pertain to automatic network workflow planning, including receiving a mission intention and generating an appropriate network workflow to satisfy the mission intention, and a set of network capability configurations for implementing the network workflow. The workflow can be generated by modifying an existing workflow based on available (e.g. contextual) information, mission intention, etc. Embodiments pertain to registration and modification, where necessary, of network capabilities to facilitate such network workflow planning. Embodiments can be implemented in 3GPP sixth generation networks.

[0045] A sixth generation (6G) wireless network structure is described below, by way of context. This structure can be applicable to various embodiments of the present disclosure, for example with embodiments configured to operate within, with, or both within and with such a network structure.

[0046] The 6G System leverages service-based architecture and XaaS concept. XaaS services in the 6G System are categorized into three layers, namely the infrastructure layer, control and management layer, and service layer.

[0047] The Infrastructure Layer includes infrastructures supporting 6G services. Among them may be included: wireless networks (RAN, CN) infrastructures, Cloud / data center infrastructures, satellite networks, storage / database infrastructures, and sensing networks, and etc. These infrastructures can be provided by a single provider or by multiple providers.

[0048] The Control and Management (C / M) layer includes control and management services of the 6G System. They may be developed and deployed by using network slicing techniques and utilizing resource provided by infrastructure layer. 6G services in Control and Management (C / M) layer may include some or all of the following.

[0049] Resource Management (RM) as a Service provides a capability of life-cycle management of a variety of slices and over-the-air resource assignment to wireless devices.

[0050] A 6G mission is defined as a service provided to customers by the 6G System. A mission can be a type of service (s) which is provided by a single 6G XaaS service or a type of services that needs contributions from multiple XaaS services.

[0051] Mission Management (MM) as a Service provides a capability to program provisioning of XaaS services at Service Layer to provide mission services.

[0052] Confederation Network (CONET) as a Service provides a capability to enable multiple partners to jointly provide 6G services. This capability is provided by confederation formation, mutual authentication, mutual authorization among partners and negotiation of agreement on recording and retracing of selected actions performed by partners, in order to assure a trustworthy environment of 6G System operations.

[0053] Service Provisioning Management (SPM) as a Service provides a capability of control and management of 6G service access by customers and provisioning of requested services. The capability is provided by unified mutual authentication, authorization and policy, key management, QoS assurance and charging between any pair of XaaS service provider and customer. The customers include end-customers not only in physical world, but also digital representatives in digital world.

[0054] Connectivity Management (CM) as a Service leverages 5G connectivity management functions, but with extension to include digital world.

[0055] Protocol as a Service provides a capability to design service customized protocol stacks for identified interfaces. The protocol stacks could be pre-defined for on-demand selection, or they may be on-demand designed.

[0056] Network Security as a Service provides a capability for owners of infrastructures to detect potential security risks of their infrastructures.

[0057] XaaS services in C / M Layer support control and management of the 6G System itself and also provide support to verticals if requested. One example is that RM service can serve RAN for over-the-air resource management and can also provide service to a vertical for the vertical’s over-the-air resource allocation to its end-customers. The XaaS in C / M layer can be deployed by using slicing technique.

[0058] The Service Layer includes 6G services which provide services to customers. In the 6G System conceptual structure, the service layer may include one or more of the following.

[0059] AI service, which is denoted as NET4AI as a Service. Artificial Intelligence service provides AI capability to support a variety of AI applications.

[0060] Service of data collection, data sanitization, data analysis and data delivery, which are denoted as DAM as a Service, this service provides a capability of lifecycle management of statistic data, including acquisition, de-privatization, analysis and delivery of data which are information statistic data from any types of sensors, devices, network functions, and etc.

[0061] Service of storage and sharing of data, which is denoted as NET4Data as a Service, this service provides a capability to trustworthily storage and share data under the control of owners of data and following recognized authorities’ regulations on control of identified data.

[0062] Service to provide digital world, which is denoted as NET4DW as a Service. The Digital World service provides a capability to construct, control and manage digital world. Digital world is defined as digital realization of physical world.

[0063] 6G block chain service, which is denoted as NET4BC as a Service.

[0064] 6G connectivity service, which is denoted as NET4Con as a Service. This service provides a capability to support 6G block chain services.

[0065] Enhanced connectivity service, e.g., network for connectivity (NET4CON) as a service may be provided. This service provides a capability to support exchange of messages and data among new 6G services.

[0066] All XaaS services at this Layer are developed and deployed by using resource provided in infrastructure and utilizing Network Function Virtualization and Slicing techniques. The capability of each of 6G services is provided by its control and management functions and service specific data process functions.

[0067] Each XaaS service mentioned above is provided by new defined 6G logical functions or by enhanced 5G logical functions or a combination of both.

[0068] FIG. 1A illustrates a system architecture for autonomous network workflow planning, according to embodiments of the present disclosure. Various network functions (NFs) involved in the system architecture are as described below, including for example A-CAP NFs, NC NFs, A-CAP controller NFs.

[0069] Automatic network capability programming (A-CAP) user 110 (or user in short) is shown in FIG. 1A. This may include any NFs, or external application functions (AFs)  / devices that requires the 6G system to achieve / solve specific goal (s) or computational problem (s) . The goal / problem is called a mission / user intention 112 (or intention in short) . The mission intention can be described in natural language.

[0070] Network capability (NC) 114 is shown in FIG. 1A. A basic Network capability (e.g., a XaaS is defined as a network capability) provides a specific capability to enable 6G system control and management (C / M) and 6G service provisioning. Each capability may be composed of one or multiple NFs, and can be operated to support different tasks by executing different NFs with different orders / inter-dependencies. For example, the network operation related NCs on C / M plane include Resource management (RM) , Connectivity management (CM) , etc. ; the service related NCs on both C / M and data planes include NET4AI, DAM, etc.

[0071] A-CAP controller 118 (or A-CAP in short) is shown in FIG. 1A. This may be a special NC that supports NC provisioning automation on both C / M and data planes. As shown in FIG. 1A, the A-CAP controller receives the mission intention 112 from A-CAP user, and autonomously resolve the mission intention into a mission graph (i.e., intention resolution) . This mission graph generation procedure realizes the autonomous network workflow planning.

[0072] Embodiments of the present disclosure provide for the generation and use of a mission graph. The mission graph may specify a set of network capabilities (e.g. as graph nodes) along with their interdependencies or interconnections (e.g. as graph edges) . The mission graph as a whole may represent the overall execution process of the network capabilities to carry out the mission. In some cases, nodes of the mission graph, or else parts of the mission graph, can themselves represent sub-mission graphs. As used herein, the term "graph" refers to a structure comprising a set of objects and relationships, such as interdependencies, between the objects. The objects can be interpreted as nodes or vertices of the graph and the relationships can be interpreted as edges linking nodes or vertices. Although a graph can be depicted in diagrammatic form, this is not necessary. Example graphs of this type include a mission graph for example comprising actions, a sub-intention graph for example comprising actions, sub-missions, or a combination thereof, and a sub-mission graph for example comprising actions, sub-missions or a combination thereof.

[0073] According to the determined mission graph, the A-CAP 118 can configure a set of NFs and network resources (e.g., computing, communication, storage, power resources) for all involved NCs to form a mission instance (i.e., mission establishment) . The A-CAP can further manage the execution process of the mission instance to achieve the goal (s) , solve the problem (s) indicated in the mission intention (i.e., mission execution control) , or a combination thereof. The A-CAP can perform the configuration for mission establishment, or else cause the configuration to be performed for example by another entity or entities.

[0074] The mission graph (or mission specification as described for example in International Patent Application Publication No. WO 2024 / 197822A1) includes selected Action (s) with their inter-dependencies to achieve the goal (s)  / solve the problem (s) indicated in the intention. The inter-dependencies describe the execution order / sequence of two or more actions in a mission graph. For example, the inter-dependencies between action A and action B can be: A must be executed (i.e., complete its execution) before B in a mission graph; A must be executed together with B, or the like.

[0075] An action corresponds to a pre-defined computational step toward achieving the goal (s)  / solving the problem (s) indicated in the intention. Each action may be supported by an NC, or a data network (DN) . Each NC / DN should expose / register its supported action (s) to the network (e.g., in the NC description language (NCDL) dataset) for A-CAP 118 to retrieve.

[0076] The following NFs involved in the system architecture are leveraged by A-CAP 118 as tool NFs for mission graph generation.

[0077] A LLM 120 is an NF instantiating an LLM. A-CAP leverages the LLM to resolve the nature language described mission intention and action features.

[0078] A Knowledge dataset 122 stores useful information for A-CAP to retrieve when A-CAP 118 is generating the mission graph. In some embodiments, some or all of the following datasets and memory (e.g., running memory (RAM) ) can be instantiated as separated NFs: Graph dataset 124, NC / NCDL dataset 126, User profile dataset 128, Topology dataset 130, and Network state memory 132. The knowledge dataset includes these other datasets.

[0079] The Graph dataset 124 stores the information of sample (pre-determined manually) historical mission graphs, or both. To improve the effectiveness and accuracy of LLM / AI enabled intention resolution, mission graph information may include some or all of the features listed in Mission Graph Information column in the table shown in the FIG. 1B and also described below.

[0080] A Graph identifier (ID)  / name, e.g., G1 may be included in the mission graph information.

[0081] Associated intention may be included in the mission graph information. The associated intention can be described in natural language. For example, G1's associated intention can be: Static inter-cell interference coordination (ICIC) based radio access network (RAN) resource allocation map.

[0082] Intention category may be included in the mission graph information. The intention type / category may indicate where the associated intention is classified. E.g., the Intention category for G1 may be "wireless network management" . The available intention categories for each A-CAP can be pre-determined by the network operator or service provider. For each mission graph added to the graph dataset, the A-CAP may be configured to categorize its associated intention into an available intention category by pre-defined scheme / algorithm.

[0083] Sub-intention graph may be included in the mission graph information, and this may be optional. A sub-intention graph resembles a condensed form of a mission graph, where graph nodes may either be actions or sub-missions. In some cases, if the sub-mission includes only one action, the sub-mission node in the sub-intention graph turns to an action. For a complex mission / mission graph composed by (or comprising) multiple sub-mission graphs (each sub-mission corresponds to another mission graph) , the inter-dependencies among these sub-mission graphs can be described by the sub-intention graph where each sub-intention is the associated intention of a sub-mission graph.

[0084] For example, a sub-intention graph of G1 can be: G1S1: obtain necessary data (RAN area, base station (BS) locations) from DAM 'G1S2: divide RAN area into BS coverage areas (BCAs) 'G1S3: allocate resource set among BCAs (ICIC) 'G1S4: determine radio bears (RBs) to be scheduled for each BCA 'G1S5: form the map. G1S1 -G1S5 are sub-mission graph IDs, 'indicates the sequential execution relationship between two sub-mission graphs.

[0085] Accordingly, embodiments of the present disclosure are hierarchical in nature, with mission graphs and their corresponding intentions on one level potentially forming sub-mission graphs and corresponding sub-intentions of a higher level. Two, three or more such levels of hierarchy may be present and handled. At some finite bottom layer of the hierarchy, the sub-mission graphs will not contain any further sub-mission graphs, but instead will be composed of associated actions.

[0086] Associated action (s) with their inter-dependencies may be included in the mission graph information. This feature describes the ID (s) of action (s) composing the mission graph and their inter-dependencies.

[0087] The NC / NCDL dataset 126 (action dataset) stores the registered actions from multiple NCs. One action of a NC can be represented as an Application Programming Interface (API) which can be independently called (as a receiver) , A-CAP 118 can retrieve these actions to form a detailed mission graph. To improve the effectiveness and accuracy of LLM / AI enabled intention resolution, the NCDL based format is applied to the action information of each action stored in the NC dataset. Each action information may include some or all of the features listed in Action Information column in the table shown in FIG. 1B and described below.

[0088] Associated NC name (e.g., NET4AI) and NC provider name may be included in the action information.

[0089] Action name / ID may be included in the action information.

[0090] Purpose may be included in the action information. This pertains to the goal / computing-step / problem to be achieved / processed / solved by executing the action. This information can be described in nature language. Purpose is used to calculate similarity (e.g., context similarity or semantic similarity) between user intention and the action, therefore the matched / related action (s) to the user intention can be retrieved.

[0091] Post-condition may be included in the action information. This pertains to the effect that can be achieved by executing the action (e.g., a specific state / action / problem has been reached / done / solved) . This information can be described in nature language. In some embodiments, the purpose information can be integrated with the post-condition info.

[0092] Pre-condition may be included in the action information. This may pertain to any condition / requirement (s) (e.g., a specific state / action / problem has been reached / done / solved) that must be met before the action can be executed. This information can be described in nature language.

[0093] NCDL metadata may be included in the action information. This may describe the metadata (parameters / capabilities) of an action.

[0094] The pre-condition and post-condition information are used to determine inter-dependencies between actions in a mission graph. E.g., for action B whose pre-condition matches the post-condition of action A, the action B must be executed after the completion of action A in any mission graph.

[0095] The User profile dataset 128 stores static / stable information / features of the A-CAP user. This may include, for example, subscribed NCs and / or actions by the user; type of the user (e.g., a NF, AF, wireless device, non-wireless device) , or the like.

[0096] The Topology dataset 130 stores static / stable info / features of the network. For example, the Topology dataset may store entity / resource topology of a RAN / core network (CN) (where the mission graph will be instantiated and executed) .

[0097] The Network state memory 132 is also included. In addition to preceding databases which stores relatively stable / static information. The Network state memory may store some or all of the information listed in Network State Memory column in the table shown in FIG. 1B and described below, which may dynamically change.

[0098] The network state memory may store real-time information indicative of NCs, the network, or both. This may include, for example: mission execution status, NC resource availabilities (e.g., idle resources that can be configured / used for establish / execute a mission graph) , network connection (wire / wireless) conditions (e.g., bandwidth consumption, outage probability, delay) , etc. This information can be collected / sensed by A-CAP 118 from NCs / network.

[0099] The network state memory may store real-time information of the user. This may include, for example, device connectivity status (RB, Session, NC connection) , device mobility status (active / idle) , etc. This information can be collected by A-CAP 118 from user or connectivity management NF (e.g., CM or access and mobility management function (AMF) ) .

[0100] A-CAP 118 may retrieve the network state memory during the mission graph generation procedure to dynamically generate mission graph according to network / user status varieties.

[0101] A Validator NF 134 is also shown in FIG. 1A. This NF is configured to verify whether the generated mission graph and / or the registered actions are valid or not. Existing algorithms / schemes, e.g., social, legal, ethical, empathetic and cultural (SLEEC) rule, can be available for validator to validate actions in semantic or contextual level.

[0102] According to various embodiments, a valid mission graph is configured to exclude redundant actions or conflict actions (where the execution effects of two actions are mutually exclusive) . In a mission graph, a redundant action can be an action whose post-conditions had all be met / achieved (in terms of semantic or context) before (e.g. right before) (i.e., a state where no other action will be executed) its execution. A conflict action can be an action whose pre-condition (s) are mutually exclusive (e.g., in semantic or contextual level) with the post-condition (s) of one or more other action (s) executed before it. For example, a first action may have a pre-condition which requires condition X to be TRUE, while a second action, executed before it, may have a post-condition which results in condition X being FALSE. In this case, the two actions may be in conflict. To resolve the conflict, one of the two actions might be replaced with another action which is not in conflict with the other.

[0103] In various embodiments, the valid actions are provided so as to not be redundant (e.g., in semantic or contextual level of both pre-conditions and post-conditions) with any existing actions in the action dataset. A valid action should not contain any conflict (e.g., in semantic or contextual level) pre-condition (s) and post-condition (s) .

[0104] In some embodiments, the aforementioned tool NFs can be integrated with the A-CAP 118 to form an A-CAP AI agent (A-CAP agent) 200 with a pre-defined workflow / working logic inside. In the agent based architecture, the user / environment input is user intention to the A-CAP agent, the A-CAP agent has A-CAP controller 118 as its agent core to leverage tools like LLM, knowledge dataset, and validator for resolving the user intention. The outputs of the A-CAP agent (to the NCs or environment) can be the detailed NC configurations determined according to the generated and validated mission graph.

[0105] FIG. 2 illustrates the pre-defined working logic in the A-CAP agent 200 (for example) for autonomous network workflow planning, according to an embodiment. The logic can be integrated into a method or computer-implemented process, or corresponding apparatus or computer program product. The logic may be as follows. Where dependencies permit, operations can be parallelized. FIG. 2 also illustrates a system architecture including the A-CAP agent.

[0106] Given the received user intention (mission intention) 112, A-CAP agent retrieves 210 the sample / historical mission graphs stored in the knowledge dataset to find similar / related mission intention (s)  / graph (s) 211, i.e. information that is similar to the user intention. In some embodiments, details of this can be realized by the intention decoupling operation 302 in FIG. 3A.

[0107] Given the retrieved similar / related mission intention (s)  / graph (s) , A-CAP agent, using LLM, operates 212 to decouple / resolve the user intention into a matched mission intention from the retrieved mission intentions, or generate a sub-intention graph composed by multiple retrieved mission intentions with inter-dependencies. The matched / generated intention and sub-intention graph are collectively illustrated 213. In some embodiments, details of this can be realized by the intention decoupling operation 302 in FIG. 3A. The intention decoupling may involve separating, where required, an intention into multiple sub-intentions. Each sub-intention may match to a sub-mission graph stored in the knowledge dataset. Thus, the output of operation 302 may include a number of sub-intentions and their interdependencies, and this output may correspond to a graph, e.g. composed at least in part of sub-intention graphs.

[0108] Given the matched / generated intention / sub-intention graph 213, A-CAP agent retrieves 214 the registered actions stored in the knowledge dataset to find similar / related action (s) 215, i.e. which are similar to the matched intention or each sub-intention in the sub-intention graph. In some embodiments, details of this can be realized by the sub-intention resolution operations 303.1 to 303.3 in FIG. 3B.

[0109] Given the retrieved actions 215, A-CAP agent chains these actions into a sub-mission graph for each sub-intention in the sub-intention graph, or for the matched intention. In some embodiments, details of this can be realized by the sub-intention resolution operation 303.4 in FIG. 3B. These operations also correspond to the resolve sub-intention 216 of FIG. 2. A-CAP agent may leverage the LLM to resolve and determine inter-dependencies between actions in the sub-mission graph 217.

[0110] A-CAP agent chains the generated sub-mission graph (s) into a mission graph, thus generating 218 the mission graph. The inter-dependencies between sub-mission graphs in the mission graph are determined by their corresponding sub-intentions'inter-dependencies in sub-intention graph. If only one sub-mission graph is generated in operation 216, the generated mission graph 219 in operation 218 will be as same as the sub-mission graph 217.

[0111] A-CAP uses the validator to validate 220 the generated mission graph 219 in order to, or to facilitate, removal or modifying of redundant and conflict actions. This results in a validated mission graph 221.

[0112] A-CAP determines 222 the detailed NC configurations according to the validated mission graph 221, then, outputs the determined NC configurations 223 to corresponding NCs 114.

[0113] FIGs. 3A, 3B and 3C illustrate an autonomous mission graph generation procedure, according to embodiments of the present disclosure. The procedure is described as follows.

[0114] In operation 301, A-CAP user 110 sends an intention resolution request to A-CAP 118. The request includes description / information of the intention, e.g., “Please generate a radio resource allocation solution for a RAN area, the resource allocation result can adapt to the spatial and temporal environment varieties. ”

[0115] An intention decoupling process 302 follows. The intention decoupling process may be as described below.

[0116] According to pre-defined / maintained prompts templates, in a prompt generation operation 302.1, the A-CAP 118 concatenates user intention with pre-defined prompt words / contexts to form the intention-decoupled prompts for the user intention. In some embodiments, A-CAP may select different prompts templates for different user types and different intention categories. The user type information can be retrieved from user profile dataset. The intention category can be determined according to the user intention by pre-defined scheme / algorithms. The A-CAP may thus generate a prompt which includes the user intention and other information, such as contextual information about the user, intention, intention category, network state, etc.

[0117] In operation 302.2, A-CAP 118 sends the generated intention-decoupled prompts to LLM 120 for resolution.

[0118] According to a decouple intention operation 302.3, LLM 120 retrieves or interacts with the graph dataset for a sample / historical mission graph whose associated intention are similar / related to the user intention in terms of semantics or contexts. The graph dataset is part of the knowledge dataset 122. A particular and appropriate sample / historical mission graph may be retrieved by the LLM from the graph dataset in this action. The LLM may apply the following chain of thoughts / rules / actions when it retrieves the graph dataset.

[0119] In more detail, the user intention may corresponds to one or multiple sub-intentions retrieved from a dataset. Intention decoupling can be interpreted as “decoupling” the user intention into multiple sub-intention (s) supported by the system. For example, the multiple sub-intentions can be generated based on the user intention, such that the sub-intentions when implemented also implement or satisfy the user intention. The sub-intentions can be related to one another via the sub-intention graph, which is retrieved here.

[0120] LLM queries the graph dataset by the user intention to identify / retrieve a mission graph. Compared with other mission graphs in graph dataset, the associated intention of the identified mission graph should have highest similarity / relationship score to the user intention in terms of semantics or contexts.

[0121] Accordingly, in embodiments, the LLM interacts with the knowledge dataset to retrieve a stored mission graph, which may be an artificial sample mission graph, a historic mission graph used in the past, or the like. This retrieval can be based on how appropriate the mission graph is for satisfying the user intention. Such appropriateness can be determined at least in part based on a (e.g. semantic or contextual) comparison of a mission intention (associated with the stored mission graph) with the user intention. The stored mission graph, once retrieved, can be modified so that it is appropriate for satisfying the user intention, within the current context and conditions of the user and network. This modification can include replacing actions or sub-missions specified in the mission graph with other actions or sub-missions that are determined by the LLM, controller, or a combination thereof.

[0122] If the identified mission graph has no sub-intention graph info, the LLM outputs its associated intention as intention decoupling result 302.4.

[0123] If the identified mission graph has sub-intention graph info, the LLM further retrieves, interacts with or queries the graph dataset for potential alternative sub-intention (s) with higher similarity / relationship score (s) to the user intention. Specifically, for each original sub-intention in sub-intention graph, the LLM queries a sub-set of the graph dataset by the user intention. The sub-set of graph dataset (that is queried by the LLM) is composed by / of all mission graphs whose intention category is as same as the intention category associated to the original sub-intention. If LLM identifies an alternative sub-intention that has higher similarity / relationship score to user intention than the original sub-intention has, the LLM replaces the original sub-intention by the alternative sub-intention in the sub-intention graph. After checking all sub-intentions, the LLM outputs the sub-intention graph as intention decoupling result 302.4. An example pertaining to operation 303 (e.g. operation 303.2 via interaction between the LLM and the knowledge dataset) is described below.

[0124] The user intention may be: “Please generate a radio resource allocation solution for a RAN area, the resource allocation result can adapt to the spatial and temporal environment varieties in the RAN. ” The user intention may correspond to a UE wanting to connect to a network, in which case the network controller may be required to allocate radio resource blocks, establish appropriate PDU sessions between network entities, etc.

[0125] Given this, LLM 120 identifies G1 (the name of the mission graph) from LLM which is most similar to the user intention. G1 intention is: Static ICIC based RAN resource allocation map. G1's sub-intention graph is: G1S1 to G1S5 (sub-intentions) as defined precedingly.

[0126] For each sub-intention G1S1 to G1S5, LLM 120 retrieves the graph dataset to find an alternative sub-intention. Two alternatives were found:

[0127] An alternative sub-intention for G1S2 is G2: "Using clustering-based algorithms, divide a geo-area into zones according to one or multiple specific features associated to each geo-location. The specific features of different zones can indicate the spatial varieties of the geo-area. " This G2 matches the "adapt to spatial varieties" mentioned in user intention.

[0128] Another alternative sub-intention for G1S4 is G3: "Using RL to determine different resource unit sizes for a resource set. The determined resource unit sizes can adapt to real-time varieties of resource requirements. " This G3 matches the "adapt to temporal varieties" mentioned in user intention.

[0129] Based on the above, LLM 120 re-forms the sub-intention graph by replacing G1S2, G1S4 with G2, G3, respectively. The re-formed sub-intention graph turns to be: G1S1 → G2 → G1S3 → G3 → G1S5.

[0130] Because the sub-intentions in the sub-intention graph may not be highly related to the user intention, the above operation allows the system to replace a sub-intention in the sub-intention graph with an alternative sub-intention that is more similar / related to both the user intention and the original one.

[0131] Thus, in some embodiments, for a given sub-intention graph of a mission graph (to be adapted to the current mission) , the LLM, in association with the knowledge dataset, may identify all mission graphs in a same intention category as the sub-intention graph. The LLM may then determine whether to replace the sub-intention graph with one of these mission graphs. This determination can be made based on an evaluation of the associated sub-intentions of these candidate mission graphs. E.g. if the sub-intention of a candidate mission graph has a higher similarity to the user intention than the original sub-intention, then this candidate mission graph may replace the original sub-intention graph. The candidate mission graph selected to replace the original sub-intention graph may be the one with the highest, or substantially highest, similarity of sub-intention to user intention.

[0132] Accordingly, in embodiments, one or more nodes of an initial (e.g. sample or historical) sub-intention graph can be replaced with more appropriate nodes. Each such node may represent an action or a sub-mission. The replacement may be based on contextual information, mission intention, etc. Thereby, the initial sub-intention graph can be customized to current conditions, requirements, etc. The eventual resultant mission graph, which is based on the sub-intention graph, is similarly customized.

[0133] As previously stated, LLM 120 sends the intention decoupling result 302.4 to A-CAP 118.

[0134] In some embodiments, in what may be an optional operation, A-CAP 118 sends the intention decoupling result 302.4 to user 110 to ask user to confirm whether the identified intention or sub-mission graph are acceptable. If the user responses with no issue, the intention decoupling procedure stops. If the user responds with a revision request, the operations 302.1 -302.4 (and potentially also operation 302.5) may be repeated for modifying the intention decoupling result until the user responds with no issue, or a predetermined number of times, or the like.

[0135] A sub-intention resolution process 303 follows the intention decoupling process 302. The sub-intention resolution process may be as described below. Sub-intention resolution may include the process of generating a sub-mission graph for carrying out a sub-intention. Sub-intention resolution may also include determining component actions to include in the sub-mission graph. The actions may be determined based for example on a sample or historic mission graph or sub-mission graph retrieved from the knowledge database. Determining the actions to include in the sub-mission graph can be performed by consulting the knowledge dataset. The determination can be based at least in part on contextual information such as what actions are currently available in the network and to the user. The determination can be based at least in part on semantic or contextual similarity between sub-intention information and action information (e.g. labels or associations with the action) .

[0136] For each intention, or sub-intention in the sub-intention graph received in intention decoupling result, A-CAP triggers execution of operations 303.1 to 303.4 for resolving it. Note that although the determined intention / sub-intention in intention decoupling result 302.4 is associated with a sample / historical mission graph with detailed action (s) information stored in graph dataset. For each user intention, the A-CAP 118 may still perform this sub-intention resolution procedure to retrieve detailed action (s) suitable for current user conditions, network conditions, or both. The relevant information may be stored / maintained in the knowledge dataset 122.

[0137] In operation 302.1, A-CAP 118 sends the intention / sub-intention information and the user ID to the knowledge dataset 122 for retrieving actions composing the mission graph / sub-mission graph.

[0138] The knowledge dataset 122 may conduct a semantic-similarity based search to find candidate action (s) . One example of similarity based search can be to find out all actions whose purpose / post-condition feature is semantically similar with the intention / sub-intention description. When searching the candidate action (s) , the knowledge dataset may keep checking the user profile dataset to ensure the selected candidate action (s) are subscribed by the user and / or can be applied for the user type. Additionally, the knowledge dataset may keep checking the topology dataset to ensure the selected candidate action (s) can be instantiated in the target network. Additionally, the knowledge dataset may keep checking the network state memory to ensure the selected candidate action (s) can be applied in current user / network status.

[0139] In operation 302.3 the knowledge dataset 122 sends, e.g. in a response message, the retrieved candidate action (s) to A-CAP 118.

[0140] A-CAP chains the candidate action (s) to generate 303.4 (form) a sub-mission graph for the intention / sub-intention. The inter-dependencies of actions in the sub-mission graph may be determined by their pre-condition and post-condition features. In some embodiments where the pre-condition and post-condition of two actions are not well defined / aligned, the A-CAP 118 may send a dependency resolve request 303.5 to LLM 120 to query whether the two actions can be chained or not. For example, pre-condition of action B may be "CM_session_established" , and post-condition of action A may be "a control plane session is available" . A-CAP 118 may utilize LLM 120 to resolve that the pre-condition of action B matches the post-condition of action A.

[0141] A generate mission graph process 304 follows the sub-intention resolution process 303. The generate mission graph process may be as described below.

[0142] Given all sub-mission graph (s) generated in operation 303, the A-CAP 118 chains / concatenates the sub-mission graphs 304.1 to form a complete mission graph. The inter-dependencies of sub-mission graphs is determined by the received sub-intention graph, as well as the pre-condition and post-condition features of each sub-mission graph's start and end actions. If the intention decoupling result only contains one intention, the output of operation 303 will only be one sub-mission and this operation 304.1 can be bypassed.

[0143] In operation 304.2, A-CAP 118 may run specific algorithms (e.g., shortest path search, path optimization) to remove potential cyclic routes (i.e., the post-condition of an action A is the pre-condition of the action B who should be executed before action A in the graph) in the generated mission graph. Other path optimizations may also be performed, e.g. to shorten paths. Removing cyclic routes can be performed so that circular dependencies (e.g. where a first action depends on a second action, and the second action in turn depends directly or indirectly on the first action) between actions is removed. Restructuring of actions or even adding new actions can be required in order to avoid such circular dependencies in some cases.

[0144] A mission graph validation process 305 follows generate mission graph process 304. The mission graph validation process may be as described below and may include graph redundancy removal, as appropriate. In some embodiments, if appropriate, mission graph validation may be omitted.

[0145] In operation 305.1, the A-CAP 118 sends the mission graph validator request to validator 134 for validating the generated mission graph. In the request, the mission graph can be described as a set of action (s) with their inter-dependencies.

[0146] In operation 305.2, the validator validates the received mission graph. If redundant action (s) were / are found, the A-CAP may be configured to directly remove the redundant action (s) from the mission graph. If conflict action pairs were / are found, the validator may inform A-CAP in the mission graph validation result. To resolve the conflict actions, the A-CAP may re-execute operation 303 (then 304) to retrieve alternative candidate action (s) . That is, corresponding sub-mission graph (s) including one or more of the conflict actions may be re-generated with restrictions that inhibit the conflict actions or replace them with non-conflicting, alternative actions. Subsequently, the overall mission graph can also be re-generated and re-optimized / re-validated.

[0147] In operation 305.3, the validator 134 sends the mission graph validation result to A-CAP 110.

[0148] For a generated mission graph that passes the validation, the A-CAP completes its mission graph information and stores 306 it in the graph dataset (knowledge dataset 122) for future retrieval. Specifically, for the mission graph info: Graph ID / name can be directly assigned by the A-CAP; associated intention is the user intention; intention category can be determined during operation 302.1; the sub-intention graph is determined in operation 302; the associated action with their inter-dependencies are determined after operations 303 and 304. The storing operation 306 may be optional or omitted in some embodiments. However, it is considered that storing the information may be useful as it allows embodiments to grow / improve and adapt over time, to be able to handle more scenarios in the future. Stored mission graphs can be subsequently used as the basis for historical mission graphs, historical sub-mission graphs, historical sub-intention graphs, or the like, from which subsequent mission graphs can be generated.

[0149] Subsequently, and in some embodiments, A-CAP 118 sends notification 307 to the user 110 about completion of the user intention resolution.

[0150] According to the generated mission graph, the A-CAP may further establish the mission graph, and control its configurations and executions in operation 308.

[0151] In view of the above, it can be seen that embodiments of the present disclosure provide for a method and corresponding apparatus (e.g. A-CAP controller) and system for network workflow planning. A mission intention indicative of a mission to be performed by a network is received from a user device, e.g. according to operation 301. Based on the mission intention, a sub-intention graph may be generated, e.g. according to an intention decoupling operation 302. The sub-intention graph includes multiple sub-intentions and their interdependencies. The sub-intentions, when collectively executed according to the interdependencies, achieves the mission intention. In a sub-intention resolution operation, e.g. according to operation 303, for each of the sub-intentions, a corresponding sub-mission graph can be generated. This sub-mission graph may include actions (which may themselves be sub-missions) and corresponding interdependencies. Then, e.g. according to operation 304, a mission graph can be generated based on the sub-mission graphs and the sub-intention graph. This can involve chaining the sub-mission graphs together according to the interdependencies as expressed in the sub-intention graph. The mission graph, once generated, can be provided for use in configuring appropriate network capabilities to perform the mission. That is, the network capabilities can be configured (or can self-configure) to implement the operations and interconnections between actions as expressed in the mission graph.

[0152] FIGs. 4A and 4B show the NC action registration procedure used by each network capability (NC) to register its newly added or updated actions to the NC dataset, according to an embodiment. After the NC action registration, these added / updated actions can be retrieved by the A-CAP to generate new mission graphs. Registration is used to manage the addition of network capabilities as they become available. This may include curating the network capabilities to avoid redundancy, and to avoid potential conflicts between incompatible network capabilities. Registration may also be used to modify actions or network capabilities if required.

[0153] Referring now to FIG. 4A, in operation 401, NC provider 140 (e.g., the NC itself or the AF associated with the NC) sends a request to A-CAP 118 for registering new action (s) or updating existing action (s) .

[0154] In operation 402, A-CAP 118 notifies the NC dataset (knowledge dataset 122) to receive action information from the NC provider 140. The interface / address information of the NC provider may be included in the action update notification. After receiving the action update notification, the action dataset (knowledge dataset 122) may respond to the A-CAP 118 with the interface information of the action dataset for the NC provider 140 to access, and the action format requirements for NC to describe the action (e.g., . json format) . The knowledge dataset 126 may include the various component datasets such as the graph dataset, NC dataset, user profile dataset, topology dataset and network state memory, as illustrated in FIG. 1A.

[0155] In operation 403, A-CAP 118 notifies the NC provider 140 to transmit action (s) to the action dataset. The interface information of the action dataset for NC provider to access, and the action format requirements are forwarded in this action transmission notification.

[0156] In operation 404, the NC provider 140 transmits the new (added)  / updated action (s) to action dataset (knowledge dataset 122) according to the interface and requirements received in operation 403.

[0157] Operation 405 pertains to added / updated action validation, and includes sub-operations 405.1 to 405.3.

[0158] In operation 405.1, after receiving all added / updated action (s) from NC provider 140, the action dataset (knowledge dataset 122) sends all added / updated action (s) to the validator 134 to check potential redundancies and conflicts between them and all existing actions.

[0159] In operation 405.2 the validator validates the received added / updated action (s) . Since all existing actions are assumed to be validated by the validator before they were stored in the action dataset, the validator may be configured to maintain the action information of all existing actions.

[0160] In operation 405.3 the validator outputs the validation result to the action dataset (knowledge dataset 122) .

[0161] According to operation 406, if any redundancies / conflicts were found in the received validation result, the action dataset (knowledge dataset 122) sends an action modification request 406 to NC provider 140 for modifying action (s) . After modification according to modify actions (operation 407) , the NC provider can re-execute operation 404 to send modified action (s) for validation. Operations 404 to 407 may be repeated 420 one or multiple times until all added / updated actions are valid.

[0162] Operation 407 show the modify actions. That is, the NC provider 140 may modify actions according to the action modification request 406, for example to remove or resolve redundancies or conflicts relative to other actions.

[0163] Referring now to FIG. 4B, in operation 408, following operation 407, the action dataset (knowledge dataset 122) stores the newly added / updated action (s) .

[0164] In operation 409 the action dataset (knowledge dataset 122) notifies A-CAP 118 about the completion of added / updated action registration.

[0165] In operation 410 the A-CAP 118 notifies the NC provider 140 about the completion of added / updated action registration.

[0166] FIG. 5 illustrates an example of a sub-intention graph 500. The sub-intention graph includes nodes 501, 502, 503, 504 and 505, each of which may be a sub-mission or an action. The sub-intention graph includes edges 506, 507, 508, 509, 510, each of which indicates dependencies between nodes. For example, node 503 requires output from node 501 due to dependency 506 and output from node 502 due to dependency 508. Nodes which are sub-missions may correspond to sub-mission graphs. Sub-mission graphs and mission graphs may have a similar structure to the sub-intention graph 500, while (according to at least some embodiments) any nodes in a sub-mission graph or mission graph can only be actions. Generating a mission graph may include replacing nodes that are sub-missions by their corresponding sub-mission graphs, thus representing the graph as a non-hierarchical collection of nodes and their interdependencies. This can correspond to the chaining of sub-mission graphs together to generate the mission graph. Interdependencies may be determined based on pre-conditions and post-conditions of associated actions or sub-missions.

[0167] In view of the above, it is noted that embodiments of the present disclosure provide for AI (especially LLM) friendly action defined with purpose, pre-condition, and other features is easy to be understood and retrieved by LLM with simple prompt engineering. Using multiple features to describe an action improves the probability of LLM to figure out (determine) inter-relationship between different actions.

[0168] Also in view of the above, it is noted that embodiments of the present disclosure provide for AI (especially LLM) friendly training / fine-tuning / RAG LLM with raw standard document contents is straight-forward but less effective than our method. LLM needs (takes advantage of) extra efforts / capabilities to decouple procedures, and discovers hidden inter-relationship between "actions" (e.g., procedure steps) and "graphs" (e.g., sub-procedures) .

[0169] Also in view of the above, it is noted that embodiments of the present disclosure may facilitate or enable 6G NEW service provisioning. For example, following the action / graph formats, all NC providers can easily define new actions and register them into knowledge dataset. The newly defined actions will be automatically retrieved and used by A-CAP to form new mission graphs to support new services. It is also noted here that training / fine-tuning / RAG LLM with existing standard documents (e.g., 5G standards) cannot (or cannot be reasonably expected to) enable LLM to accurately create new steps / procedures.

[0170] Also in view of the above, it is noted that embodiments of the present disclosure may facilitate or enable fully automated network management. For example, since the action / graph formats can clearly expose the hidden relationship between actions / sub-missions from different NCs, the LLM enabled A-CAP can automatically create network management procedure (s) according to real-time network conditions and user intentions, without manual / human intervention.

[0171] Also in view of the above, it is noted that embodiments of the present disclosure may facilitate or enable simplified standards and fast deployment. For example, a (or any) new capability / procedure of future network can be expressed as mission graphs composed of old and newly-defined actions. The A-CAP can automatically generate and deployment them on demand without being pre-described in standards.

[0172] FIG. 6 is a schematic diagram of an electronic device 1400 that may perform any or all of operations of the above methods and features explicitly or implicitly described herein, according to different embodiments of the present disclosure. For example, a computer equipped with network function may be configured as an electronic device 1400. Such an electronic device may be used as part of one or more of: a controller, an edge server, a processing device, a bounding region module, an AV, an RSU, etc.

[0173] The apparatus may be a device (e.g. a device representing the A-CAP user) , a network node such as RAN, any components in RAN, CN or any Network Function (e.g., A-CAP controller, LLM, validator in the previous implementations or any network functions in the 6G service of the present disclosure) , or an apparatus includes one or more of the network functions (as mentioned above) .

[0174] As shown, the device includes a processor 1460, such as a Central Processing Unit (CPU) or specialized processors such as a Graphics Processing Unit (GPU) or other such processor unit, memory 1465, non-transitory mass storage 1470, I / O interface 1485, network interface 1475, and a transceiver 1490, all of which are communicatively coupled via bi-directional bus 1480. According to certain embodiments, any or all of the depicted elements may be utilized, or only a subset of the elements. Further, the device 1400 may contain multiple instances of certain elements, such as multiple processors, memories, or transceivers. Also, elements of the hardware device may be directly coupled to other elements without the bi-directional bus. Additionally or alternatively to a processor and memory, other electronics, such as integrated circuits, may be employed for performing the required logical operations. An antenna 1476 for the network interface and networks 1477 coupled to the network interface are also shown.

[0175] The memory 1465 may include any type of non`-transitory memory such as static random access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , any combination of such, or the like. The mass storage element 1470 may include any type of non-transitory storage device, such as a solid state drive, hard disk drive, a magnetic disk drive, an optical disk drive, USB drive, or any computer program product configured to store data and machine executable program code. According to certain embodiments, the memory 1465 or mass storage 1470 may have recorded thereon statements and instructions executable by the processor 1460 for performing any of the aforementioned method operations described above.

[0176] It will be appreciated that, although specific embodiments of the technology have been described herein for purposes of illustration, various modifications may be made without departing from the scope of the technology. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention. In particular, it is within the scope of the technology to provide a computer program product or program element, or a program storage or memory device such as a magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine, for controlling the operation of a computer according to the method of the technology and / or to structure some or all of its components in accordance with the system of the technology.

[0177] Acts associated with the method described herein can be implemented as coded instructions in a computer program product. In other words, the computer program product is a computer-readable medium upon which software code is recorded to execute the method when the computer program product is loaded into memory and executed on the microprocessor of the wireless communication device.

[0178] Further, each operation of the method may be executed on any computing device, such as a personal computer, server, PDA, or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, or the like. In addition, each operation, or a file or object or the like implementing each said operation, may be executed by special purpose hardware or a circuit module designed for that purpose.

[0179] Through the descriptions of the preceding embodiments, the present invention may be implemented by using hardware only or by using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present invention may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM) , USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present invention. For example, such an execution may correspond to a simulation of the logical operations as described herein. The software product may additionally or alternatively include a number of instructions that enable a computer device to execute operations for configuring or programming a digital logic apparatus in accordance with embodiments of the present invention.

[0180] Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.

[0181] Embodiments have been described above in conjunctions with aspects of the present invention upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described, but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are otherwise incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.

Claims

1.A method for autonomous network workflow planning in a communication network, the method comprising:receiving, from a user device, a mission intention indicative of a mission to be performed by the network,decoupling the mission intention into a sub-intention graph comprising a plurality of sub-intentions along with interdependencies between the sub-intentions, wherein executing the sub-intentions according to the interdependencies achieves the mission intention,for each of the sub-intentions, generating a corresponding sub-mission graph comprising one or more actions and corresponding action interdependencies,generating a mission graph based on the sub-mission graphs and the sub-intention graph, andproviding, based on the mission graph, a set of network capability configurations for configuring network capabilities of the network to perform the mission.2.The method of claim 1, wherein the indication of the mission is expressed using natural language, the method further comprises using a large language model (LLM) and a knowledge dataset to process the mission intention into the one or more actions, wherein the decoupling of the mission intention comprises:generating intention-decoupled prompts for the user intention and sending the intention-decoupled prompts to the LLM,retrieving, through interacting between the LLM and the knowledge dataset, a graph dataset in the knowledge dataset for a sample / historical mission graph having an associated intention which is semantically or contextually similar or related to the user intention, andoutputting, from the LLM, an intention-decoupled result including a matched / generated intention / sub-intention graph.3.The method of claim 2, wherein the retrieving of the graph dataset comprises comparing the generated mission graph to one or more mission graphs in the graph dataset of sample / historical mission intention and identifying a mission graph with a highest similarity / relationship score to the mission intention in terms of semantics or contexts.4.The method of claim 2, wherein the decoupling further comprises requesting confirmation indicative of whether or not the intention-decoupled result is acceptable by a user, and, when the intention decoupled result unacceptable, modifying the intention-decoupled result.5.The method of claim 2, wherein generating of the intention-decoupled prompts comprises concatenating the user intention with pre-defined prompt words or context.6.The method of claim 1, wherein generating the sub-mission graph comprises resolving the sub-intention, the resolving of the sub-intention comprising:sending the sub-intention to a knowledge dataset,conducting one or more rounds of semantic-similarity based search in the knowledge dataset to retrieve the one or more actions, wherein the one or more actions are based on current user / network conditions, andchaining the one or more actions based on their inter-dependencies to generate one of the corresponding sub-mission graphs, corresponding to the sub-intention.7.The method of claim 6, further comprising sending a dependency resolve request to the LLM to determine whether two of the actions can be chained or not.8.The method of claim 7, wherein generating of the mission graph comprises chaining the sub-mission graphs.9.The method of claim 8, wherein generating of the mission graph comprises performing path optimization to remove cyclic routes from the mission graph.10.The method of claim 1, further comprising validating the generated mission graph prior to providing the set of network capability configurations, wherein the validating comprises:removing one or more redundant action from the mission graph, when said one or more redundant actions are present, andresolving one or more conflicting action in the mission graph, when said one or more conflicting actions are present.11.The method of claim 10, wherein the resolving of conflicting action comprises re-executing the generating of the corresponding sub-mission graph and the generating of the mission graph to incorporate therein one or more alternative actions.12.The method of claim 1, further comprising storing the generated mission graph information to the knowledge dataset.13.The method of claim 1, further comprising configuring or initiating configuration of the network capabilities according to the set of network capability configurations.14.A method for registering new or updated candidate actions in a knowledge dataset for autonomous network workflow planning, the method comprising:receiving, by a controller, a request to register one or more new / updated candidate actions associated with a network capability (NC) ,notifying a knowledge dataset to receive the one or more candidate actions from the network capability, the network capability to transmit the one or more candidate actions to the knowledge dataset, whereinthe network capability transmits the one or more candidate actions to the knowledge dataset,a validator validates the one or more candidate actions in the knowledge dataset, andthe validated one or more candidate actions are stored in the knowledge dataset for retrieval in future mission graph generation.15.The method of claim 14, wherein validating the one or more candidate actions comprises:receiving, by the validator, the one or more candidate actions from the network capability,determining, by the validator, whether the one or more candidate actions contain any redundant candidate actions or conflict candidate actions, andoutputting validation results to the knowledge dataset.16.The method of claim 14, further comprising:modifying the one or more candidate actions upon detection of redundancies or conflicts, andinitiating re-execution of the validation of the one or more candidate actions until the one or more candidate actions are determined to be valid.17.An apparatus for autonomous network workflow planning in a communication network, the apparatus comprising a network controller having processing electronics and a network interface, the apparatus configured to:receive, from a user device, a mission intention indicative of a mission to be performed by the network, (step 301)decouple the mission intention into a sub-intention graph comprising a plurality of sub-intentions along with interdependencies between the sub-intentions, wherein executing the sub-intentions according to the interdependencies achieves the mission intention, (step 302)for each of the sub-intentions, generate a corresponding sub-mission graph comprising one or more actions and corresponding action interdependencies, (step 303)generate a mission graph based on the sub-mission graphs and the sub-intention graph, and (step 304)provide, based on the mission graph, a set of network capability configurations for configuring network capabilities of the network to perform the mission. (step 223, initial part of step 308)18.The apparatus of claim 17, wherein the indication of the mission is expressed using natural language, the apparatus further comprising or using a large language model (LLM) and a knowledge dataset configured to process the mission intention into the one or more actions, wherein the decoupling of the mission intention comprises:generating intention-decoupled prompts for the user intention and sending the intention-decoupled prompts to the LLM,retrieving, through interacting between the LLM and the knowledge dataset, a graph dataset in the knowledge dataset for a sample / historical mission graph having an associated intention which is semantically or contextually similar or related to the user intention, andoutputting, from the LLM, an intention-decoupled result including a matched / generated intention / sub-intention graph.19.The apparatus of claim 18, wherein the retrieving of the graph dataset comprises comparing the generated mission graph to one or more mission graphs in the graph dataset of sample / historical mission intention and identifying a mission graph with a highest similarity / relationship score to the mission intention in terms of semantics or contexts.20.The apparatus of claim 18, wherein the decoupling further comprises requesting confirmation indicative of whether or not the intention-decoupled result is acceptable by a user, and, when the intention decoupled result unacceptable, modifying the intention-decoupled result.21.The apparatus of claim 18, wherein generating of the intention-decoupled prompts comprises concatenating the user intention with pre-defined prompt words or context.22.The apparatus of claim 17, wherein generating the sub-mission graph comprises resolving the sub-intention, the resolving of the sub-intention comprising:sending the sub-intention to a knowledge dataset,conducting one or more rounds of semantic-similarity based search in the knowledge dataset to retrieve the one or more actions, wherein the one or more actions are based on current user / network conditions, andchaining the one or more actions based on their inter-dependencies to generate one of the corresponding sub-mission graphs, corresponding to the sub-intention.23.The apparatus of claim 22, further configured to send a dependency resolve request to the LLM to determine whether two of the actions can be chained or not.24.The apparatus of claim 23, wherein generating of the mission graph comprises chaining the sub-mission graphs.25.The apparatus of claim 24, wherein generating of the mission graph comprises performing path optimization to remove cyclic routes from the mission graph.26.The apparatus of claim 17, further comprising a validator configured to validate the generated mission graph prior to providing the set of network capability configurations, wherein the validating comprises:removing one or more redundant action from the mission graph, when said one or more redundant actions are present, andresolving one or more conflicting actions in the mission graph, when said one or more conflicting actions are present.27.The apparatus of claim 26, wherein the resolving of conflicting action comprises re-executing the generating of the corresponding sub-mission graph and the generating of the mission graph to incorporate therein one or more alternative actions.28.The apparatus of claim 17, further configured to store the generated mission graph information to a knowledge dataset.29.The apparatus of claim 17, further configured to: configure or initiate configuration of the network capabilities according to the set of network capability configurations.30.An apparatus for registering new or updated candidate actions in a knowledge dataset for autonomous network workflow planning in a communication network, the apparatus comprising a controller having processing electronics and a network interface, the apparatus configured to:receive, by the controller, a request to register one or more new / updated candidate actions associated with a network capability (NC) ,notify a knowledge dataset, of or operatively coupled to the apparatus, to receive the one or more candidate actions from the network capability, the network capability to transmit the one or more candidate actions to the knowledge dataset, whereinthe network capability transmits the one or more candidate actions to the knowledge dataset,a validator, of or operatively coupled to the apparatus, validates the one or more candidate actions in the knowledge dataset, andthe validated one or more candidate actions are stored in the knowledge dataset for retrieval in future mission graph generation.31.The apparatus of claim 30, wherein validating the one or more candidate actions comprises:receiving, by the validator, the one or more candidate actions from the network capability,determining, by the validator, whether the one or more candidate actions contain any redundant candidate actions or conflict candidate actions, andoutputting validation results to the knowledge dataset.32.The apparatus of claim 30, further configured to:modify the one or more candidate actions upon detection of redundancies or conflicts, andinitiate re-execution of the validation of the one or more candidate actions until the one or more candidate actions are determined to be valid.33.A non-transitory computer-readable medium having stored thereon instructions that, when executed by one or more processors of a controller in a network, cause the controller to execute a method for autonomous network workflow planning in a communication network according to any one of claims 1 to 16.

Images