Operation and maintenance apparatus, system and method

Abstract

The present application belongs to the technical field of network operation and maintenance. Disclosed are an operation and maintenance apparatus, system and method. The operation and maintenance apparatus comprises: an access module, which is configured to receive a user intent for indicating the performing of a network change on a target network; a change agent, which is configured to acquire a plurality of steps for implementing the user intent and an execution sequence of the steps, wherein the plurality of steps comprise a first step for verifying change content of the network change and a second step for executing the network change on the target network, and the change agent is configured to execute the first step on the basis of the execution sequence, and then output to a digital twin module a verification instruction for verifying the change content of the network change; the digital twin module, which is configured to acquire, in response to the verification instruction, a verification result corresponding to the network change and output same to the change agent; and the change agent, which is configured to execute the second step on the basis of the verification result. The operation and maintenance apparatus can replace cumbersome manual operations in conventional network operation and maintenance, thereby improving the degree of automation of network operation and maintenance.

Description

Maintenance equipment, systems and methods

[0001] This application claims priority to Chinese Patent Application No. 202510323847.1, filed on March 18, 2025, entitled "Operation and Maintenance Device, System and Method", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of network operation and maintenance technology, and in particular to an operation and maintenance device, system and method. Background Technology

[0003] Network operations and maintenance (O&M) play a crucial role in network construction, serving as the foundation for ensuring stable, efficient, and secure network operation. O&M encompasses a full range of tasks, from network planning and network equipment management to network monitoring, troubleshooting, and network security maintenance.

[0004] Currently, network operations and maintenance (O&M) leverages the automation and intelligence capabilities of intelligent agents to improve efficiency, reduce errors, and enable predictive maintenance and rapid fault response. Predictive maintenance, in particular, involves monitoring device status data in real time to predict potential failure times, thereby allowing for proactive maintenance and prevention of malfunctions.

[0005] However, in complex scenarios such as network changes, intelligent agents still require human intervention to ensure the correctness of these changes, resulting in insufficient automation. Network changes refer to the process of adjusting and updating network configurations, devices, topology, or policies to optimize network performance, meet business needs, or resolve issues. Summary of the Invention

[0006] This application provides an operation and maintenance device, system, and method. The operation and maintenance device can replace the tedious manual operations in traditional network operation and maintenance, thereby improving the automation level of network operation and maintenance.

[0007] The technical solution provided in this application is as follows.

[0008] Firstly, this application provides an operation and maintenance device, comprising an access module, a change agent, and a digital twin module. The access module receives a user intent, which instructs the user to perform a network change on a target network. The change agent acquires multiple steps to fulfill the user intent and their execution order. These steps include a first step and a second step. The first step verifies the content of the network change, and the second step executes the network change on the target network. The change agent, based on the execution order, determines that after executing the first step, it outputs a verification command to the digital twin module. This verification command verifies the content of the network change. The digital twin module, in response to the verification command, acquires a verification result corresponding to the network change and outputs it to the change agent. The change agent then executes the second step based on the verification result.

[0009] The operation and maintenance device provided in this application enables the decomposition of user intents into tasks through a change agent in network change operation and maintenance scenarios. It then uses technologies such as digital twin modules to simulate network device and protocol behavior, verifying the logical correctness of the network change indicated by the user intent and the syntactic correctness of the configuration messages used to implement the network change. Based on the verification results, it executes the network change indicated by the user intent on the target network. For example, the network change indicated by the user intent is only executed on the target network if the verification is successful. Therefore, the operation and maintenance device provided in this application not only eliminates the need for manual intervention in network change operation and maintenance scenarios but also ensures the correctness of network changes. In other words, the operation and maintenance device provided in this application improves the automated simulation verification of various network protocols and service configurations in network change operation and maintenance scenarios. These various network protocols and service configurations include, but are not limited to, border gateway protocol (BGP) configuration, virtual private network (VPN) configuration, and cross-domain traffic engineering configuration.

[0010] In one possible design approach, the digital twin module is also used to obtain optimization suggestions for network changes based on the verification results. The change agent is further used to perform network optimization on the target network based on the optimization suggestions.

[0011] Through this possible design, the operations and maintenance (O&M) device can also provide one or more optimization suggestions when the verification of network changes indicated by the user's intent fails, such as suggested values ​​for the configuration parameters of the network changes indicated by the user's intent. Thus, the O&M device can perform network change O&M operations according to the optimization suggestions without manual intervention, thereby achieving network optimization of the target network during network changes.

[0012] In another possible design, the digital twin module is also used to obtain optimization suggestions for network changes based on the verification results. The access module is also used to output these optimization suggestions. Furthermore, the access module is used to receive user confirmation of the optimization suggestions, which indicates whether to optimize the target network according to the suggestions. The change agent is also used to optimize the target network based on the confirmation and the optimization suggestions.

[0013] With this possible design, when the operation and maintenance device fails to verify the network change indicated by the user's intent and provides one or more optimization suggestions, the user can confirm whether to apply the optimization suggestions to make network changes, thus improving the user experience.

[0014] In another possible design approach, the access module is specifically used to: receive work orders sent by the work order system through the northbound interface, the work orders being used to indicate user intent; or, receive user intent input by the user through a graphical user interface (GUI).

[0015] Through this possible design, the operation and maintenance device provided in this application can provide multiple interfaces to receive user intents.

[0016] In another possible design, the access module is also used to verify whether the operation and maintenance device allows processing of the user intent received by the access module, and, if it is determined that the operation and maintenance device allows processing of the user intent, to output the user intent to the change agent.

[0017] This design allows for restrictions on maintenance devices from processing user intents that lack the appropriate permissions. This avoids security threats to the target network posed by maintenance operations based on such intents, thus ensuring the security of the target network.

[0018] In another possible design approach, the change agent is specifically used to: send a task decomposition request to a device deploying a large language model (LLM), the task decomposition request being used to request the determination of multiple steps to realize the user's intent and the execution order of the multiple steps; and receive the multiple steps and the execution order of the multiple steps sent by the device.

[0019] In another possible design, the maintenance device also includes an LLM (Local Management Module). The change agent is also used to parse the user intent and output the parsed user intent to the LLM. The LLM is used to obtain multiple steps and their execution order based on the parsed user intent. The change agent is also used to obtain the multiple steps and their execution order from the LLM.

[0020] Through the two possible design approaches described above, the change agent, by interacting with the LLM, achieves the goal of decomposing the task corresponding to the user's intent into multiple steps using the reasoning capabilities of the LLM.

[0021] Secondly, this application provides an operation and maintenance device, which includes an access module, a fault intelligence agent, and a fault management module. The access module receives user intents, which instruct the handling of faults in a target network. The fault intelligence agent outputs fault diagnosis instructions to the fault management module based on the user intents. The fault management module, in response to the fault diagnosis instructions, obtains a first diagnostic result and a first repair suggestion and outputs them to the fault intelligence agent. The fault intelligence agent, based on the first diagnostic result and the first repair suggestion, obtains a first fault repair instruction and outputs it to the fault management module. The fault management module repairs the fault in response to the first fault repair instruction.

[0022] The operation and maintenance device provided in this application combines a fault intelligence agent and a fault management module (such as incident fault management). When the fault management module handles network fault operation and maintenance, the fault intelligence agent replaces the operation and maintenance personnel in manually calling the interface provided by the fault management module to perform fault root cause diagnosis and fault repair, thus avoiding the human-computer interaction required by the fault management module when handling network fault operation and maintenance. Therefore, this application improves the automation level of network fault operation and maintenance.

[0023] In another possible design, the first fault repair instruction includes a fault identifier (ID), which corresponds to the first diagnostic result and the first repair suggestion.

[0024] With this possible design, the fault agent and the fault management module only need to transmit the fault ID, which can reduce the communication overhead between the fault agent and the fault management module.

[0025] In another possible design approach, the fault agent is also used to: obtain the repair results fed back by the fault management module, the repair results indicating that the fault repair has failed or the fault has not been completely repaired; obtain at least one step to achieve the repair objective and the execution order of the at least one step based on the repair results; and execute at least one step in the execution order to complete the fault repair.

[0026] Through this possible design, the operation and maintenance device provided in this application can further diagnose and repair the fault when the repair result after the fault management module performs fault repair is a failure or a partial failure, thereby improving the fault repair rate.

[0027] In another possible design, the fault agent is specifically used to: determine the diagnostic results and repair objectives of unrepaired faults based on the repair results; send a task decomposition request to a device with an LLM deployed, the task decomposition request being used to request the determination of at least one step and the execution order of at least one step to achieve the repair objectives based on the diagnostic results of unrepaired faults; and receive at least one step and the execution order of at least one step returned by the device.

[0028] In another possible design, the maintenance device also includes an LLM (Local Management Module). Specifically, the fault agent is used to determine the diagnostic results and repair goals for unrepaired faults based on the repair results, and outputs these results to the LLM. The LLM is used to determine at least one step and the execution order of that step to achieve the repair goals based on the diagnostic results of the unrepaired faults. The fault agent is also specifically used to obtain at least one step and the execution order of that step from the LLM.

[0029] Through the two possible design approaches described above, the fault agent, by interacting with the LLM, achieves the goal of using the LLM's reasoning capabilities to decompose the repair targets corresponding to unrepaired faults into tasks.

[0030] In another possible design, the fault agent is also used to: query historical maintenance records based on the fault root cause indicated by the first diagnostic result to determine whether there is a target maintenance record in the historical maintenance records that caused the fault root cause; and if it is determined that there is a target maintenance record in the historical maintenance records, optimize the LLM that provides inference services to the device based on the fault root cause and the target maintenance record.

[0031] Through this possible design, the operation and maintenance device of this application realizes the use of network fault diagnosis results as feedback information of historical operation and maintenance, and optimizes the LLM that provides inference services for the operation and maintenance device based on the feedback information, so that the LLM can provide more accurate inference services in subsequent network operation and maintenance.

[0032] In another possible design approach, the access module is specifically used to: receive work orders sent by the work order system through the northbound interface, the work orders being used to indicate user intent; or, receive user intent input by the user through the GUI.

[0033] Through this possible design, the operation and maintenance device provided in this application can provide multiple interfaces to receive user intents.

[0034] In another possible design, the access module is also used to verify whether the operation and maintenance device allows processing of the user intent received by the access module, and, if it is determined that the operation and maintenance device allows processing of the user intent, to output the user intent to the fault agent.

[0035] This design allows for restrictions on maintenance devices from processing user intents that lack the appropriate permissions. This avoids security threats to the target network posed by maintenance operations based on such intents, thus ensuring the security of the target network.

[0036] In another possible design, the maintenance unit also includes a digital twin module. The fault intelligence agent is further used to send business analysis instructions to the digital twin module after receiving a fault event reported by the fault management module. The digital twin module, in response to the business analysis instructions, analyzes the business affected by the fault event reported by the fault management module and returns business information of the affected business to the fault intelligence agent. The fault intelligence agent is also used to request the work order system to create a work order based on the fault event and business information reported by the fault management module.

[0037] Through this possible design, the operation and maintenance device provided in this application can monitor fault events in the target network by leveraging the fault management module's (such as an incident fault management module) ability to discover potential faults. It can also request the creation of work orders based on the fault events and the service information they affect. These work orders are the ones received by the operation and maintenance device through the northbound interface, indicating the user's intent. Therefore, the operation and maintenance device of this application achieves self-discovery, self-analysis, and self-troubleshooting of network fault risks, reducing manual intervention and improving the automation level of network troubleshooting.

[0038] Thirdly, this application provides an operation and maintenance system, comprising: an access module, a main intelligent agent, a change intelligent agent as described in the first aspect and any possible design of the first aspect, and a fault intelligent agent as described in the second aspect and any possible design of the second aspect. The access module is used to receive user intents and output the user intents to the main intelligent agent. The main intelligent agent is used to parse the user intents and obtain task objectives and task parameters. The main intelligent agent is also used to output task objectives and task parameters to the change intelligent agent after determining that the user intent indicates a network change to the target network, and / or, the main intelligent agent is used to output task objectives and task parameters to the fault intelligent agent after determining that the user intent indicates handling a fault in the target network.

[0039] In one possible design approach, the change agent and the master agent are made to the same agent, and / or the faulty agent and the master agent are made to the same agent.

[0040] Fourthly, this application provides an operation and maintenance method, the method comprising: receiving a user intent, the user intent being used to instruct network changes to a target network; obtaining multiple steps to implement the user intent and the execution order of the multiple steps, the multiple steps including a first step and a second step, the first step being used to verify the content of the network change, the second step being used to perform the network change on the target network; after determining to execute the first step based on the execution order, verifying the content of the network change to obtain a verification result; and executing the second step based on the verification result.

[0041] In one possible design approach, the above method further includes: obtaining optimization suggestions for network changes based on the verification results; and performing network optimization on the target network based on the optimization suggestions.

[0042] In another possible design approach, the above method further includes: obtaining optimization suggestions for network changes based on the verification results; outputting optimization suggestions; receiving user confirmation of the optimization suggestions, the confirmation results indicating whether to optimize the target network according to the optimization suggestions; and optimizing the target network based on the confirmation results and optimization suggestions.

[0043] In another possible design approach, receiving user intent as described above includes: receiving a work order sent by a work order system via a northbound interface, the work order being used to indicate the user intent; or receiving user intent input by the user via a GUI.

[0044] In another possible design approach, obtaining the multiple steps for realizing the user intent and the execution order of the multiple steps includes: sending a task decomposition request to the device deploying the LLM, the task decomposition request being used to request the determination of the multiple steps for realizing the user intent and the execution order of the multiple steps; and receiving the multiple steps and the execution order of the multiple steps sent by the device.

[0045] In another possible design approach, the above method is executed by an operation and maintenance device, which includes an LLM (Local Management Module). The process of obtaining the multiple steps for realizing the user intent and the execution order of these steps includes: parsing the user intent; and, through the LLM, obtaining the multiple steps and their execution order based on the parsed user intent.

[0046] Fifthly, this application provides an operation and maintenance method, which is applied to an operation and maintenance device, the device including a fault management module. The method includes: receiving a user intent, the user intent being used to instruct the handling of a fault in a target network; obtaining a first diagnostic result and a first repair suggestion obtained by the fault management module based on the user intent, the first diagnostic result being a diagnosis of the fault, and the first repair suggestion being a suggestion to repair the fault; and repairing the fault based on the first diagnostic result and the first repair suggestion.

[0047] In one possible design approach, the above method further includes: obtaining a repair result, which indicates that the fault repair has failed or the fault has not been completely repaired; obtaining at least one step to achieve the repair objective and the execution order of the at least one step based on the repair result; and executing at least one step in the execution order to complete the fault repair.

[0048] In another possible design approach, the above-mentioned acquisition of at least one step and the execution order of at least one step to achieve the repair objective based on the repair results includes: determining the diagnostic results and repair objectives of the unrepaired fault based on the repair results; sending a task decomposition request to the device deployed with LLM, the task decomposition request being used to request the determination of at least one step and the execution order of at least one step to achieve the repair objective based on the diagnostic results of the unrepaired fault; and receiving at least one step and the execution order of at least one step returned by the device.

[0049] In another possible design, the maintenance device also includes an LLM (Local Management Module). The aforementioned process of obtaining at least one step and the execution order of at least one step to achieve the repair objective based on the repair results includes: determining the diagnostic results and repair objectives of unrepaired faults based on the repair results; and determining at least one step and the execution order of at least one step to achieve the repair objective based on the diagnostic results of unrepaired faults using the LLM.

[0050] In another possible design approach, the above method further includes: querying historical maintenance records based on the root cause of the fault indicated by the first diagnostic result to determine whether there is a target maintenance record in the historical maintenance records that leads to the root cause of the fault; if it is determined that there is a target maintenance record in the historical maintenance records, optimizing the LLM that provides inference services for the maintenance device based on the root cause of the fault and the target maintenance record.

[0051] In another possible design approach, receiving user intent as described above includes: receiving a work order sent by a work order system via a northbound interface, the work order being used to indicate the user intent; or receiving user intent input by the user via a GUI.

[0052] In another possible design approach, the above method further includes: after receiving a fault event reported by the fault management module, analyzing the services affected by the fault event reported by the fault management module; and requesting the creation of a work order based on the fault event and the service information of the services.

[0053] Sixthly, this application provides an operation and maintenance method applied to an operation and maintenance system, the operation and maintenance system including a change agent as described in the first aspect and any possible design of the first aspect, and a fault agent as described in the second aspect and any possible design of the second aspect. The method includes: receiving a user intent; parsing the user intent to obtain a task objective and task parameters; after determining that the user intent indicates a network change to the target network, outputting the task objective and task parameters to the change agent, and executing the method provided in the fourth aspect and any possible design of the fourth aspect, excluding the method of receiving the user intent; and / or, after determining that the user intent indicates handling a fault in the target network, outputting the task objective and task parameters to the fault agent, and executing the method provided in the fifth aspect and any possible design of the fifth aspect, excluding the method of receiving the user intent.

[0054] In a seventh aspect, this application provides a computing device or computer system, comprising: a memory, a communication interface, and one or more processors. The one or more processors receive or transmit data through the communication interface, and are configured to read program instructions stored in the memory to execute a method as provided by any of the fourth to sixth aspects and any possible design of any of the aspects.

[0055] Eighthly, this application provides a computer-readable storage medium that is a non-volatile computer-readable storage medium, the computer-readable storage medium including computer program instructions that, when executed by a processor, a computing device including a processor, or a computer system, perform the methods provided by any of the fourth to sixth aspects and any possible design of any of the aspects.

[0056] Ninthly, this application provides a computer program product containing instructions that, when executed by a processor, a computing device including a processor, or a computer system, cause the processor, the computing device including a processor, or the computer system to perform the methods provided by any of the fourth to sixth aspects and any possible design of any of the aspects.

[0057] In a tenth aspect, this application provides a chip including a processor for executing program instructions or code. The chip or a device including the chip can be used to perform methods provided by any of the fourth to sixth aspects and any possible design embodiments of any of those aspects. Exemplarily, the chip further includes an input interface, an output interface, and a memory. The chip's input interface, output interface, processor, and memory are connected via internal interconnection paths. The memory in the chip stores program instructions or code executed by the processor, and the input and output interfaces are used for communication and connection between the chip and other chips or devices.

[0058] It is understood that any of the operation and maintenance systems, operation and maintenance methods, computing devices, computer systems, computer-readable storage media, computer program products or chips provided above can be applied to the operation and maintenance devices provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the operation and maintenance devices, and will not be repeated here.

[0059] In this application, the names of the aforementioned operation and maintenance devices, operation and maintenance systems, etc., do not limit the devices or functional modules themselves. In actual implementation, these devices or functional modules may appear under other names. As long as the functions of each device or functional module are similar to those in this application, they all fall within the protection scope of this application. Attached Figure Description

[0060] Figure 1 is a schematic diagram of the functional framework of an LLM-based intelligent agent;

[0061] Figure 2 is a schematic diagram of an instance architecture of a network digital twin as defined in the standard document;

[0062] Figure 3 is a schematic diagram of an implementation environment for the method provided in the embodiments of this application;

[0063] Figure 4 is a schematic diagram of another implementation environment of the method provided in the embodiments of this application;

[0064] Figure 5 is a schematic diagram of another implementation environment of the method provided in the embodiments of this application;

[0065] Figure 6 is a schematic diagram of the architecture of an operation and maintenance device provided in an embodiment of this application;

[0066] Figure 7 is a schematic diagram of the architecture of another operation and maintenance device provided in an embodiment of this application;

[0067] Figure 8 is a schematic diagram of the architecture of another operation and maintenance device provided in an embodiment of this application;

[0068] Figure 9 is a schematic diagram of the architecture of another operation and maintenance device provided in an embodiment of this application;

[0069] Figure 10 is a flowchart illustrating an operation and maintenance method provided in an embodiment of this application;

[0070] Figure 11 is a schematic diagram of a maintenance method provided in an embodiment of this application;

[0071] Figure 12 is a flowchart illustrating another operation and maintenance method provided in an embodiment of this application;

[0072] Figure 13 is a flowchart illustrating another operation and maintenance method provided in an embodiment of this application;

[0073] Figure 14 is a flowchart illustrating another operation and maintenance method provided in an embodiment of this application;

[0074] Figure 15 is a flowchart illustrating another operation and maintenance method provided in an embodiment of this application;

[0075] Figure 16 is a flowchart illustrating another operation and maintenance method provided in an embodiment of this application;

[0076] Figure 17 is a schematic diagram of another process of the operation and maintenance method provided in the embodiment of this application;

[0077] Figure 18 is a schematic diagram of another process of the operation and maintenance method provided in the embodiments of this application;

[0078] Figure 19 is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0079] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0080] To facilitate understanding, the technologies and background involved in the embodiments of this application will be explained below.

[0081] 1. Intelligent agent

[0082] An intelligent agent, also known as an artificial intelligence agent (AI agent) or AI intelligent agent, is an intelligent entity capable of perceiving its external environment and responding through built-in logic or learning mechanisms. Intelligent agents can exhibit human-like intelligent behavior in specific domains or tasks, such as problem-solving, decision-making, interacting with users, or collaborating with other systems.

[0083] An intelligent agent is specifically an artificial intelligence system that simulates human intelligent behavior, using LLM as its core engine. As an example, referring to Figure 1, Figure 1 shows a functional framework diagram of an LLM-based intelligent agent.

[0084] As shown in Figure 1, the intelligent agent possesses the ability to plan tasks. For example, for complex tasks, the agent can invoke the LLM (Limited Learning Model) and utilize its chain of thought (COT) capability for task decomposition and planning. In the agent's system architecture, task decomposition and planning are achieved based on the capabilities of the LLM. The chain of thought capability of the large model prompts the model to think step by step, decomposing large tasks into smaller, manageable sub-goals (i.e., subgoal decomposition) to efficiently handle complex tasks. Furthermore, the agent can continuously improve its task planning capabilities based on reflection and self-criticism. For example, the agent can self-criticize and reflect on past behaviors, learn from mistakes, and analyze, summarize, refine, and improve future actions, thereby improving the quality of the final result. Reflection and self-criticism enable the agent to correct previous decisions, thus continuously optimizing. Therefore, reflection and self-criticism can help the agent improve its intelligence and adaptability.

[0085] An agent's memory capabilities include short-term memory and long-term memory. The input information of the agent is called its short-term memory, and all contextual learning generally relies on this short-term memory. Typically, short-term memory is limited by the model's context window length (e.g., the number of question-and-answer interactions between the user and the agent), and the limitation of the context window varies between different models. It should be understood that an LLM-based agent typically has a fixed context window when processing input, meaning the agent can only "remember" and utilize information within that window. Long-term memory refers to the external vector database (such as the knowledge base described below in the embodiments of this application) that the agent needs to query when completing a target task. Long-term memory enables the agent to store and retrieve unlimited information over a long period. Specifically, the agent can access the external vector database through rapid retrieval.

[0086] The agent also has the ability to invoke external tools. That is, the agent can use external tool application programming interfaces (APIs) to obtain capabilities and information beyond the LLM. For example, the agent can invoke APIs for custom or standard functions, or invoke function calls, to perform tasks such as scheduling, setting up pending events for network devices, and querying network device operational data. Furthermore, based on its ability to automatically invoke tools, the agent can determine whether each step obtained from task planning requires invoking an external tool for execution (action). When it determines that an external tool is needed, it invokes the tool's API to execute the corresponding step and retrieves the information returned by the API (such as the execution result) back to the LLM so that the LLM can proceed to the next step.

[0087] 2. Network digital twin

[0088] A network digital twin, also known as a digital twin for networks or network digital twin, refers to a virtual mapping of a network constructed using network modeling technology. Network digital twins help operations and maintenance personnel monitor the status, performance, and network topology of network devices in real time, enabling real-time mapping and dynamic updates of the physical network. Operations and maintenance personnel can leverage the simulation capabilities of network digital twins to simulate different network configurations and optimization schemes within the network digital twin system and evaluate the impact of these configurations and optimizations on network performance.

[0089] In other words, network digital twins can provide users with a wealth of functions, such as network performance optimization, fault management, capacity planning, and configuration simulation verification, by building a real-time replica of the network. Furthermore, network digital twins can provide APIs (including input and output interfaces) to external applications, allowing them to call and access the services provided by the network digital twin.

[0090] Referring to Figure 2, which illustrates a schematic diagram of an instance architecture for a network digital twin as defined in the standard document, a network digital twin instance includes components such as a data repository, a service mapping model, function models, basic models, and digital twin network management.

[0091] The data warehouse is a core component of the network digital twin system, used to store and manage various types of data (including network configuration data, performance data, and fault data). It can be applied to scenarios such as data analysis, trend prediction, and fault backtracking. The service mapping model maps physical entities, functions, or services in the network to the network digital twin system, ensuring a one-to-one correspondence between the physical and digital worlds. The service mapping model can be applied to scenarios such as network device monitoring, configuration management, and fault location. The functional model describes the behavior and logic of various functional modules in the network, such as routing, traffic management, and security policies. The functional model can be applied to scenarios such as network performance optimization, functional testing, and fault diagnosis. The basic model is the fundamental component of the network digital twin system used to describe the network infrastructure, such as devices, links, and nodes. The basic model can be applied to scenarios such as network topology management, resource allocation, and capacity planning. Network digital twin management is the core control module of the network digital twin system, responsible for coordinating and managing all components of the network digital twin to achieve full lifecycle management of the network. Network digital twin management can be applied to scenarios such as automated network operation and maintenance, intelligent monitoring, and fault prevention.

[0092] Furthermore, the network digital twin instance enables external applications to call and access the services provided by the network digital twin instance through input and output interfaces.

[0093] 3. Network configuration simulation verification

[0094] Network configuration simulation verification is a technology that uses virtualization technology and simulation tools to test and verify network configurations. It allows users to simulate the operating state of a real network in a virtual environment to verify the correctness, performance, and stability of the network configuration, thereby reducing the risks and costs of deploying the network in practice. In one example, a network digital twin can provide users with network configuration simulation verification capabilities.

[0095] 4. Incident Fault Management

[0096] An incident typically refers to an event, accident, or sudden occurrence. In a network context, an incident can refer to an unexpected network service outage, a decline in network service quality, or a suboptimal network service performance caused by an alarm or anomaly. An incident is generally a root cause alarm generated by the aggregation of multiple alarms, primarily serving to help operations and maintenance personnel promptly identify and address network problems to ensure normal network operation. Alarms, on the other hand, serve a similar purpose to incidents but with finer granularity. Multiple alarms may often be correlated. Alarms are generally generated by network devices or network management systems and are used to indicate an anomaly or event requiring attention within the network device or network.

[0097] The Internet Engineering Task Force (IETF) standard documents define standardized interfaces for the YANG model for identifying, reporting, diagnosing, querying, and resolving incidents in networks. Incident management can aggregate a small number of root causes (i.e., incidents) from various data sources (such as alarms, various network performance metrics, and / or anomaly data) through data correlation and service impact analysis. The YANG model is a data modeling language used to define network configuration and state data, widely applied in network management systems (such as software-defined networking (SDN) and network functions virtualization (NFV)) and automated operation and maintenance tools.

[0098] 5. Ticket system (work order system) and ticket (work order)

[0099] A work order system, also known as a work order management system or information technology service management (ITSM) system, is a software tool used to track, manage, and resolve user requests or issues. Work order systems are widely used in information technology (IT) support, customer service, and operations management, and are a core tool for organizations and enterprises to efficiently handle tasks and optimize workflows.

[0100] The specific objects managed by the work order system can be called work orders. Specifically, a work order, as the basic unit of work order system management, refers to a record of a specific task or request, typically used to track and resolve user problems, equipment malfunctions, or service requests. Work orders usually contain the following information: a problem description, i.e., the problem or request reported by the user or system; a priority level based on the urgency or scope of the problem; a status, such as "New," "Processing," or "Resolved"; and a timestamp, such as the work order's creation time and update time.

[0101] It should be understood that, as a platform or tool for managing work orders, a work order system is responsible for the creation, allocation, tracking, and archiving of work orders. Therefore, by managing work orders, a work order system can achieve standardized, streamlined, and data-driven problem handling, making it one of the core tools of modern operations and maintenance.

[0102] Currently, one related technology improves operational efficiency by introducing intelligent agents into network operations and maintenance (O&M) scenarios. However, while intelligent agents have been initially applied in conversational O&M, they still struggle to automate network O&M in complex scenarios such as fault diagnosis and network changes. For example, human intervention is still required in complex O&M scenarios to ensure the correctness of operations. After handling complex faults and anomalies, the intelligent agent may not accurately perceive the true state of the network, necessitating further manual optimization and verification. For instance, since network changes are directly related to business operations, any successful network change must not only ensure the smooth launch of new services but also ensure that existing services are not affected or experience problems. Therefore, before making any network changes, O&M personnel need to review the solution design and assess the impact of all changes. Furthermore, after a network change, O&M personnel need to manually monitor the network on-site for a continuous period to ensure that the changes achieve the expected results.

[0103] Another related technology utilizes network digital twins for network operations and maintenance (O&M). In this technology, the northbound interface (a machine-to-machine interface) of the network digital twin allows network applications to input requirements (such as O&M needs) into the network digital twin system, which then performs network O&M based on the received requirements. The northbound interface of the network digital twin can play a crucial role in network O&M and optimization, network visualization, and intent verification. Currently, standard documents define that the aforementioned northbound interface can be implemented using RESTful interfaces, but the data and content transmitted by the northbound interface of the network digital twin are complex, resulting in a high learning cost for O&M personnel. RESTful interfaces are APIs designed based on the representational state transfer architectural style, widely used in building Web services, and are a common interface design approach in modern distributed systems. Here, the Web refers to an information system accessed via the Internet, composed of hypertext and multimedia resources (such as images and videos), which users can access and browse through a browser.

[0104] Another related technology involves using network configuration simulation verification to check and verify device / network configurations during network configuration maintenance. However, current mainstream network configuration management protocols (such as the Network Configuration Protocol (NETCONF)) used for network configuration simulation verification, while supporting configuration checks, generally only involve checking the syntax and semantics of YANG, and cannot verify the logical functions implemented based on YANG. For example, when a device supports the validate:1.1 capability, <edit-config>The operation supports carrying a test option parameter, the value of which can be: "set", indicating that the configuration is set directly without any verification test; "test-then-set", indicating that a verification test is performed first, and if no verification error is found, the setting is attempted; "test-only", indicating that only a verification test is performed without any setting operation. The validate:1.1 capability refers to the device's capability identifier in NETCONF that supports configuration verification functionality. <edit-config>It is an operational element in NETCONF used to modify the configuration of network devices. NETCONF is a protocol for managing network devices, typically used for automating network configuration and management.

[0105] Furthermore, some YANG models in the IETF also define similar network configuration simulation verification functions, enabling verification testing of configurations to be deployed during network configuration operation and maintenance. However, these verification tests are only used for configuration simulation verification (such as simulating traffic function tunnel calculation, IP / VLAN / routing resource allocation, etc.), and do not provide methods for repairing / optimizing the configuration when verification fails.

[0106] Another related technology uses incident fault management for network operation and maintenance. However, while incident fault management can achieve a certain degree of automation and intelligence in network operation and maintenance, it only provides interfaces for functions such as root cause diagnosis and fault repair, which still require manual confirmation by operation and maintenance personnel. Due to the time-consuming human-computer interaction, the degree of automation of incident fault management is limited.

[0107] Based on this, embodiments of this application provide an operation and maintenance device. This device combines network configuration simulation verification and / or incident fault management with intelligent agents in operation and maintenance scenarios, thereby achieving a higher degree of automation in network operation and maintenance. Therefore, the operation and maintenance device provided in this application can replace the cumbersome manual operations in traditional network operation and maintenance, establishing an "intent-perception-analysis-decision-execution" paradigm, thereby realizing intelligent perception of operation and maintenance intent, autonomous decision-making on operation and maintenance tasks, and automatic execution of operation and maintenance tasks. The core idea of ​​this paradigm is to describe a basic framework, pattern, or way of thinking.

[0108] Referring to Figure 3, Figure 3 illustrates a schematic diagram of an implementation environment for the method provided in this application. As shown in Figure 3, the implementation environment includes an operation and maintenance device and a target network. The target network is any network that requires operation and maintenance, including but not limited to carrier networks and campus networks, such as enterprise networks and campus networks. The infrastructure of the target network includes various types of network devices, including but not limited to routers, switches, gateways, edge devices, etc. The operation and maintenance device is used to perform operation and maintenance on network devices in the target network and user networks.

[0109] As shown in Figure 3(a), the maintenance device can be deployed outside the target network and communicate with network devices in the target network through the network. As shown in Figure 3(b), the maintenance device can be deployed inside the target network and communicate with network devices in the target network through the target network's intranet.

[0110] In one exemplary embodiment, referring to FIG4, FIG4 illustrates another implementation environment schematic diagram of the method provided in this application. Referring to FIG3, as shown in FIG4, the operation and maintenance device for operating and maintaining network devices is deployed in the management and analysis module of the operations support system (OSS), which is not limited in this embodiment. The management and analysis module has management, control, and analysis functions for the target network and network devices within the target network. Here, the management function is used to handle the configuration distribution and maintenance of network devices, the control function is mainly responsible for network traffic scheduling and policy execution, and the analysis function is mainly responsible for the real-time collection and analysis of network data.

[0111] In another exemplary embodiment, referring to FIG5, FIG5 illustrates another implementation environment of the method provided in the embodiments of this application. Referring to FIG3 or FIG4, as shown in FIG5, the maintenance device for operating and maintaining network devices also communicates with a work order system. Thus, the maintenance device can obtain work orders from the work order system and perform maintenance on the target network and network devices within the target network based on the work orders. Optionally, the work order system can be a functional module in OSS, and this is not limited. In one example, the work orders in the work order system can be work orders created after users of the target network file complaints about problems occurring in the target network; in another example, the work orders in the work order system can be work orders created based on alarms or abnormal events occurring in the target network monitored by the maintenance device.

[0112] It should be understood that the above content is an exemplary description of the implementation environment of the method provided in the embodiments of this application, and does not constitute a limitation on the implementation environment of the method. As those skilled in the art know, as business needs change, the implementation environment can be adjusted according to application requirements, and the embodiments of this application do not list them one by one.

[0113] This application also provides an operation and maintenance device, which is the operation and maintenance device in the above-described implementation environment. By executing the operation and maintenance method provided in this application, the device can achieve more automated network operation and maintenance.

[0114] Referring to Figure 6, Figure 6 shows a schematic diagram of the architecture of an operation and maintenance device provided in an embodiment of this application. As shown in Figure 6, in an operation and maintenance scenario involving network changes, the operation and maintenance device includes an access module, a change agent, and a digital twin module.

[0115] The access module receives user intents, which instruct the user to make network changes to the target network. The change agent acquires multiple steps to fulfill the user intent and their execution order. These steps include a first step and a second step. The first step verifies the content of the network change, and the second step executes the network change on the target network. The change agent, based on the execution order, determines that after executing the first step, it outputs a verification command to the digital twin module, instructing the verification of the network change content. The digital twin module, in response to the verification command, acquires the verification result corresponding to the network change and outputs it to the change agent. The change agent then executes the second step based on the verification result. For example, the digital twin module can be a network digital twin system simulating the target network, an electronic map of the target network, etc., but is not limited to these.

[0116] The operation and maintenance device shown in Figure 6 enables the digital twin module to verify the changes (such as specific network configurations) before the change agent performs network changes on the target network. Only when the verification result is successful does the change agent execute the network changes as instructed by the user. This improves the accuracy of network changes without requiring manual intervention.

[0117] It should be noted that the detailed functions and uses of the access module, the change agent, and the digital twin module shown in Figure 6 can be found in the description of the method embodiments below, and will not be repeated here.

[0118] Referring to Figure 7, which shows a schematic diagram of the architecture of another operation and maintenance device provided in an embodiment of this application. As shown in Figure 7, in a network fault operation and maintenance scenario, the operation and maintenance device includes an access module, a fault intelligence agent, and a fault management module.

[0119] The access module receives user intents, which instruct the handling of faults in the target network. A fault intelligence agent outputs fault diagnosis instructions to the fault management module based on the user intent. The fault management module, in response to the fault diagnosis instructions, obtains a first diagnostic result and a first repair suggestion, and outputs these to the fault intelligence agent. The fault intelligence agent, based on the first diagnostic result and the first repair suggestion, obtains a first fault repair instruction and outputs it to the fault management module. The fault management module repairs the fault in response to the first fault repair instruction. For example, the fault management module could be an incident fault management module.

[0120] The maintenance device shown in Figure 7 enables the automatic triggering of fault diagnosis and repair interfaces provided by the fault management module through the fault intelligence agent. This allows the fault management module to handle network faults indicated by user intent, thus avoiding the need for maintenance personnel to manually call these interfaces to handle network faults. This improves the automation level of network fault maintenance and increases maintenance efficiency.

[0121] It should be noted that the detailed functions and uses of the access module, fault intelligence agent, and fault management module shown in Figure 7 can be found in the description of the method embodiments below, and will not be repeated here.

[0122] Referring to Figure 8, Figure 8 shows a schematic diagram of the architecture of another operation and maintenance device provided in an embodiment of this application. As shown in Figure 8, the operation and maintenance device includes an access module, a digital twin module, a change agent, a fault management module, a fault agent, and a main agent.

[0123] Detailed descriptions of the access module, digital twin module, change agent, fault management module, and fault agent can be found in Figures 6 and 7, as well as in the descriptions of the method embodiments below, and will not be repeated here. The main agent is used to parse the user intent received by the access module to obtain the task objective and task parameters indicated by the user intent. The main agent is also used to output the task objective and task parameters indicated by the user intent to the change agent after determining that the user intent received by the access module indicates network modification of the target network, and / or, the main agent is used to output the task objective and task parameters indicated by the user intent to the fault agent after determining that the user intent received by the access module indicates fault handling in the target network. It should be noted that a detailed description of the functions and uses of the main agent can be found in the descriptions of the method embodiments below, and will not be repeated here.

[0124] In one example, the master agent is an independent agent, as shown in Figure 8, that is separate from the changing agent and the faulty agent.

[0125] In another example, the primary agent and the changing agent are the same agent (not shown in the figure), and / or, the primary agent and the faulty agent are the same agent (not shown in the figure).

[0126] The operation and maintenance device shown in Figure 8 can provide operation and maintenance for network changes and network faults. It can improve the correctness of network changes without the need for manual intervention by operation and maintenance personnel, and can avoid the need for operation and maintenance personnel to manually call the interface provided by the fault management module to handle network faults. This improves the automation level of network fault operation and maintenance and increases operation and maintenance efficiency.

[0127] It is understandable that the operation and maintenance device shown in Figure 8 may also include intelligent agents with other capabilities, such as query intelligent agents with the ability to query information, optimization intelligent agents with the ability to optimize network performance, and so on.

[0128] It should be noted that in this embodiment, when the operation and maintenance device includes multiple intelligent agents, these multiple intelligent agents can be multiple intelligent agents based on capability settings, such as the change intelligent agent, fault intelligent agent, query intelligent agent, optimization intelligent agent, etc., as mentioned above. Of course, these multiple intelligent agents can also be multiple intelligent agents based on application areas, such as a single-domain intelligent agent for operation and maintenance of networks and network devices within a single autonomous system, or a cross-domain intelligent agent for operation and maintenance of end-to-end networks and network devices, and are not limited to these.

[0129] Optionally, some or all of the aforementioned agents may share a single LLM. Of course, each agent may also correspond to a different LLM, and the comparison is not limited.

[0130] Optionally, the aforementioned multiple agents can be configured with their own knowledge bases (corresponding to the long-term memory capabilities of the agents described above) and memory engines, based on their respective capabilities or application areas. Of course, these multiple agents can also share a knowledge base and memory engine. The comparison is not limited.

[0131] The knowledge base includes, but is not limited to, information such as domain expert experience, operation and maintenance manuals, network equipment product documentation, and user preferences. The role of the knowledge base is to provide the agent with enhanced retrieval capabilities (e.g., through retrieval-augmented generation, RAG). This allows the agent to incorporate information from the knowledge base when answering questions, thereby reducing the agent's "illusion" problem and improving the accuracy and traceability of its answers. Here, the agent's "illusion" problem refers to the agent outputting information that is inconsistent with the facts, logically flawed, or fabricated when generating content or completing tasks. Furthermore, the knowledge base can be continuously updated in real time based on user feedback, the latest knowledge, and the corresponding operational effects of historical operation and maintenance records, thus compensating for the agent's deficiencies in domain-specific knowledge and real-time information. For example, the agent can correct erroneous information in the knowledge base using data from human feedback. It is understandable that information such as operation and maintenance manuals and network equipment product documentation in the knowledge base can also be used as content in the LLM training process.

[0132] The memory engine includes, but is not limited to, historical operation and maintenance records. It should be understood that in the architecture of an agent, the memory engine is a module or mechanism used to enhance the agent's understanding of context and long-term dependencies. It is mainly used to solve the problem of information forgetting caused by the limitation of the context window (corresponding to the short-term memory capability of the agent mentioned above) when the agent is processing long texts or complex tasks.

[0133] In this application, the storage method for the knowledge base and memory engine is not specifically limited. For example, the data of the knowledge base and memory engine can be stored and organized based on any of the following methods: vector database, key-value (KV) storage, graph database, knowledge graph, etc.

[0134] Optionally, the aforementioned multiple intelligent agents can exchange knowledge and experience information through APIs. For example, a single-domain intelligent agent can exchange information with a cross-domain intelligent agent.

[0135] Referring to Figure 9, which illustrates the architecture of another maintenance device provided in this application embodiment, the maintenance device includes an access module, a digital twin module, a fault management module, and an intelligent agent. This intelligent agent possesses at least the capability of a change intelligent agent as shown in Figure 6 or Figure 8, and at least the capability of a fault intelligent agent as shown in Figure 7 or Figure 8. That is, the intelligent agent included in the maintenance device shown in Figure 9 possesses multiple capabilities simultaneously, or it can be understood that the change intelligent agent and the fault intelligent agent shown in Figures 6 to 8 can be implemented through the same intelligent agent. Therefore, the intelligent agent shown in Figure 9 includes at least a change module for implementing the change intelligent agent capability shown in Figure 6 or Figure 8, and a fault module for implementing the fault intelligent agent capability shown in Figure 7 or Figure 8. Detailed descriptions of the access module, digital twin module, change intelligent agent, fault management module, and fault management module can be found in Figures 6, 7, and 8, as well as the method examples below, and will not be repeated here.

[0136] Optionally, the maintenance device shown in any of Figures 6 to 9 can be implemented using a computing device, a functional module within a computing device, or a cluster of multiple computing devices. In one example, the computing device includes, but is not limited to, general-purpose computers, laptops, and other computing devices. In another example, the computing device is implemented as a network device such as a server or cloud platform.

[0137] Those skilled in the art will readily recognize that, based on the modules / units and algorithm steps described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0138] It should be noted that the module / unit division in any of the operation and maintenance devices shown in Figures 6 to 9 is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. For example, two or more functions can be integrated into one processing module. The functions implemented by the integrated modules can be implemented either in hardware or as software functional modules.

[0139] The operation and maintenance methods provided in the embodiments of this application are described in detail below according to different operation and maintenance scenarios.

[0140] Operation and maintenance scenario 1: Network change.

[0141] Referring to Figure 10, which illustrates a flowchart of an operation and maintenance method provided in an embodiment of this application, the method can be applied to any of the implementation environments shown in Figures 3 to 5 and executed by an operation and maintenance device with the architecture shown in Figure 6 or 8. As shown in Figure 10, the method includes the following steps 101 to 104.

[0142] Step 101: Receive user intent, which is used to instruct network changes to be made to the target network.

[0143] In this embodiment, the access module of the operation and maintenance device is used to receive user intents. The user intents include task objectives and task parameters related to those objectives.

[0144] In one possible implementation, the access module includes a GUI. In this case, the access module can receive user intents described in natural language by the user inputting them on the GUI. For example, the access module receives user intent 1 input on the GUI: "Please create a new virtual local area network (VLAN) for me on network device NE1, with the VLAN ID VLAN 10, and assign interface GigabitEthernet 0 / 1 to this VLAN, while configuring the Internet Protocol (IP) address 192.168.10.1 / 24 for this interface."

[0145] In another possible implementation, the access module includes a northbound interface. In this case, the access module can receive user intents in code form through the northbound interface. In one example, the maintenance device communicates with a work order system (as shown in Figure 5). The access module can then receive work orders in code form through the northbound interface communicating with the work order system. This work order indicates the user intent. Taking user intent 1 as an example again, the user intent 1 received by the access module through the northbound interface, represented as a code, is shown below:

[0146] Optionally, the operation and maintenance device can extract key information based on the received user intent, including the task objective to be achieved by the user intent and the task parameters carried by the user intent.

[0147] In one example, taking user intent 1, described in natural language, received by the maintenance device through the GUI, the access module can extract the key information of user intent 1: intent = [create "VLAN"], parameters = {"vlan_id":10,"interface":"GigabitEthernet0 / 1","ip_address":"192.168.10.1","subnet_mask":"255.255.255.0"}. Here, intent is the task goal that user intent 1 aims to achieve, and parameters are the task parameters carried by user intent 1.

[0148] In another example, taking user intent 1 received by the maintenance device through the northbound interface as an example, the access module can extract the key information of user intent 1: request type = [create "VLAN"], request parameters = {"vlan_id":10,"interface":"GigabitEthernet0 / 1","ip_address":"192.168.10.1","subnet_mask":"255.255.255.0"}, and token information. The request type based on the user intent received through the northbound interface includes, but is not limited to: GET, POST, PUT, and DELETE. The request type represents the task objective that user intent 1 aims to achieve, and the request parameters represent the task parameters carried by user intent 1.

[0149] Optionally, when the access module extracts token information from the user's intent, it can also verify the validity of the token (such as whether it has expired or been tampered with), and if the token is found to be valid, extract the user role (such as administrator, ordinary user, read-only user, etc.) and permissions of the user role corresponding to the token.

[0150] Optionally, the access module of the operation and maintenance device can also be used to verify whether the operation and maintenance device allows processing the user intent. In this case, the access module of the operation and maintenance device includes an access control unit, which stores access control policies. Thus, the access module can determine whether the operation and maintenance device allows processing each received user intent based on the access control policies. That is, the access control unit manages the access permissions of users accessing the operation and maintenance device to ensure that the operation and maintenance device only performs operation and maintenance operations permitted by the access control policies.

[0151] Access control policies are used to indicate the scope of permissions for different roles of operations and maintenance (O&M) personnel. These roles include, but are not limited to, regular O&M personnel, administrators, and super administrators. It should be understood that different O&M personnel have different permissions. In one example, O&M personnel's permissions are related to the type of O&M operation. For example, regular O&M personnel have permissions to perform O&M operations corresponding to basic prompts (e.g., read-only, query, or retrieve), while administrators have permissions to perform O&M operations corresponding to advanced prompts (e.g., query, create, modify, delete), including basic prompts. In another example, O&M personnel's permissions are related to the O&M object. For example, regular O&M personnel have permissions to perform simple and / or low-risk business O&M operations, such as routine equipment inspections and simple troubleshooting, while administrators have permissions to perform not only simple, low-risk O&M operations but also complex and / or high-risk business O&M operations, such as leased line O&M and VPN O&M. Therefore, the scope of administrator permissions includes the scope of regular O&M personnel permissions. In another example, taking the relationship between the permissions of operations and maintenance personnel and the type of operations performed as an example, the access control policy can be represented as: {"Administrator":["Execute","Read","Write"],"Regular User":["Read"],"Read-Only User":["Read"]}. Here, the administrator's permissions include "Execute", "Read", and "Write", the regular user's permission is "Read", and the read-only user's permission is "Read".

[0152] In this scenario, upon receiving a user intent, the access module can optionally, if the permissions of the operations and maintenance personnel are related to the operations and maintenance object, query the access control policy based on the operations and maintenance object of the user intent and the role of the user who entered the intent, thereby determining whether the operations and maintenance device is allowed to process the user intent. Specifically, the access module can determine the operations and maintenance object of the user intent by parsing it. Regarding the role of the user who entered the intent, optionally, in scenario 1 where the access module receives user intent 1 via the northbound interface, the user intent may include token information corresponding to the user role. Therefore, when determining the role of the user who entered the intent, the access module can extract the token information from the user intent and determine the user role based on the token information. Optionally, when the access module receives a user intent via the GUI, the input module can determine whether the user who entered the intent is a registered operations and maintenance personnel or an unregistered visitor based on whether the user is logged into an operations and maintenance account. Furthermore, if the access module determines that the user is a registered operations and maintenance personnel who is logged into an operations and maintenance account, it can determine the user's specific role, such as administrator or ordinary user, based on the user's logged-in account information.

[0153] Optionally, if the permissions of the maintenance personnel are related to the type of maintenance operation, the access module can query the access control policy based on the operation type indicated by the user intent and the role of the user who entered the intent, thereby determining whether the maintenance device allows processing the user intent. The operation type indicated by the user intent can be reflected by the prompt words included in the user intent; therefore, the access module can directly extract the prompt words included in the user intent. The method for obtaining the role of the user who entered the intent is as described above and will not be repeated here.

[0154] In one example, after the access module receives the user intent 1 mentioned above, the access control unit of the access module extracts the prompt word "create" from the user intent 1, determines that the user role of the user who entered the user intent 1 is an administrator, and the access control policy indicates that the administrator's permissions are to allow the execution of maintenance operations corresponding to advanced prompt words (such as query, create, modify, delete, etc.), including basic prompt words. Therefore, by querying the access control policy, the access control unit can determine that the maintenance device is allowed to process user intent 1.

[0155] In another example, after the access module receives the user intent 1 mentioned above, the access control unit of the access module extracts the prompt word "create" from the user intent 1, and determines that the user role of the user who entered the user intent 1 is a regular maintenance personnel. The access control policy indicates that the permissions of the regular maintenance personnel are only allowed to perform maintenance operations corresponding to the basic prompt words (such as read-only, query or get, etc.). Therefore, by querying the access control policy, the access control unit can determine that the maintenance device does not allow processing of user intent 1.

[0156] Optionally, in addition to instructing whether to allow the execution of user-inputted intents based on the permissions corresponding to different user roles, access control policies can also combine information such as the input time of the user intent and the frequency of access to the target object of the user intent to determine whether to allow the execution of the user-inputted intent. For example, access control policies can also instruct that the maintenance operations corresponding to advanced prompt words can only be executed during non-working hours, and are not allowed to be executed during working hours, thus avoiding the execution of maintenance operations corresponding to advanced prompt words on the network during busy working hours. As another example, access control policies can also instruct that if the frequency of access to the target object of a user intent exceeds a threshold within a preset time period, the user intent cannot be processed, thus preventing maintenance devices from performing operations similar to distributed denial-of-service (DDoS) attacks on network devices.

[0157] In one example, when the access control unit extracts the prompt "create" from user intent 1 and determines that the user's role is an administrator, and the access control policy indicates that the administrator's permissions are to allow the execution of maintenance operations corresponding to advanced prompts (such as query, create, modify, delete, etc.), including basic prompts, and that maintenance operations corresponding to advanced prompts are only allowed to be executed outside of working hours, then when the access control unit determines that user intent 1 was received during working hours, it can determine, after querying the access control policy, that the maintenance device does not allow the execution of user intent 1. Conversely, when the access control unit determines that user intent 1 was received outside of working hours, it can determine, after querying the access control policy, that the maintenance device allows the execution of user intent 1.

[0158] In some exemplary embodiments, the access control policy indicating that the operation and maintenance device is not allowed to process user intents includes, but is not limited to: the token carried by the user intent being invalid (e.g., expired or tampered with); the user role not containing the permissions for the operation requested by the user intent; the request type or parameters corresponding to the user intent being invalid (e.g., parameters exceeding the allowed upper limit); and the user intent being abnormal. An abnormal user intent may be: the frequency of the user entering the user intent accessing the operation and maintenance device exceeds a threshold, or the frequency of the operation and maintenance object corresponding to the user intent being operated and maintained within a preset time period exceeds a threshold. Accordingly, the access control policy may indicate that the operation and maintenance device is allowed to process user intents that do not satisfy the aforementioned policies.

[0159] It should be understood that, by setting access control policies in the access module, the embodiments of this application can allow different user intents entered by the same maintenance personnel during multiple rounds of conversations / prompt feedback with the maintenance device to have different processing permissions. For example, regarding the user intent 1 currently entered by maintenance personnel 1, the access module determines, after querying the access control policy, that user intent 1 is allowed to be processed by the maintenance device. However, if maintenance personnel 1 subsequently adds additional descriptions or corrects user intent 1 and enters user intent 2, the access module determines, after querying the access control policy, that user intent 2 is not allowed to be processed by the maintenance device.

[0160] Optionally, the access module can also establish records of user access to the operation and maintenance device, such as recording user access logs, to facilitate subsequent analysis and tracing. These user access logs include, but are not limited to, information such as: user ID, user access intent, user access time (the time the user intent was received), user access object (the operation and maintenance object corresponding to the user intent), and access result (the operation and maintenance result).

[0161] Step 102: Obtain multiple steps to realize the above user intent and the execution order of the multiple steps. The multiple steps include a first step and a second step. The first step is used to verify the change content of the network change indicated by the user intent, and the second step is used to perform the network change on the target network.

[0162] After the access module of the operation and maintenance device receives a user intent and / or determines that the operation and maintenance device allows processing the user intent, the access module can output the user intent to the change agent of the operation and maintenance device. Alternatively, after the access module of the operation and maintenance device receives a user intent and / or determines that the operation and maintenance device allows processing the user intent, the access module can output the task objective and task parameters extracted from the user intent to the change agent.

[0163] Optionally, when the access module transmits the user intent to the change agent, the change agent also needs to parse the user intent in order to extract the task objective and task parameters of the user intent.

[0164] Subsequently, the steps for the intelligent agent to obtain and realize the aforementioned user intent are changed, as well as the execution order of these steps.

[0165] In one possible implementation, the change agent sends a task decomposition request to the device deploying the LLM. The task decomposition request requests the determination of multiple steps to achieve the user intent and their execution order. In response, the device deploying the LLM receives the task decomposition request, determines the multiple steps to achieve the user intent and their execution order using its own deployed LLM, and sends the determined steps and their execution order to the change agent. In response, the change agent receives the multiple steps to achieve the user intent and their execution order from the device deploying the LLM. The task decomposition request carries the task objective to be achieved by the user intent and the task parameters carried by the user intent. Therefore, the LLM can determine the multiple steps to achieve the user intent and their execution order based on its own reasoning ability, the task objective carried in the task decomposition request, and the task parameters.

[0166] As can be seen, in this implementation, the maintenance device and the LLM are deployed on different devices.

[0167] In another possible implementation, when the maintenance device includes an LLM (Local Management Module), the change agent outputs the parsed user intent to the LLM. In response, the LLM obtains multiple steps to achieve the user intent and their execution order based on the parsed user intent. For example, the LLM determines the multiple steps to achieve the user intent and their execution order based on its reasoning ability, the task objective obtained from parsing the user intent, and the task parameters. Then, the LLM outputs the obtained multiple steps and their execution order to the change agent. In response, the change agent obtains the multiple steps to achieve the user intent and their execution order from the LLM.

[0168] Understandably, in the process of LLM determining multiple steps to achieve the user intent and their execution order based on its reasoning ability, the task objective obtained by parsing the user intent, and the task parameters, the LLM can optionally complete the task decomposition of the user intent and obtain multiple steps and their execution order all at once. Then, the agent can execute these steps sequentially according to the execution order. In other words, in this approach, the agent can obtain the complete task decomposition steps to achieve the user intent through a single interaction with the LLM. Alternatively, the LLM can return each step to the agent after reasoning it out, and the agent can execute that step and send the execution result back to the LLM. The LLM can then reason out the next step based on the user intent's task objective, task parameters, and the execution result, and return that next step to the agent for execution. This process continues until the user intent is achieved. In other words, in this approach, the agent needs to interact with the LLM after each step, allowing the LLM to adjust subsequent reasoning steps based on real-time feedback.

[0169] For simplicity, the embodiments of this application will be described below using the example of LLM completing the task decomposition of user intent in one go and obtaining multiple steps and the execution order of the multiple steps.

[0170] For example, taking the user intent as user intent 1 mentioned above as an example, based on its own reasoning ability, the LLM determines the multiple steps to implement user intent 1 and the execution order of these multiple steps at once, according to the task objectives and task parameters obtained by parsing user intent 1: Step 1, generate a configuration message that can be sent to the network device according to the task parameters contained in user intent 1; Step 2, perform configuration simulation verification on the configuration message; Step 3, after the configuration message is successfully verified, send the configuration message to the network device so that the network device can respond to the configuration message and perform the corresponding configuration; Steps 1 to 3 are executed sequentially.

[0171] Step 1 can be understood as the preparatory step for the first step mentioned above, Step 2 is the first step mentioned above, and Step 3 is the second step mentioned above. It should be understood that the module performing simulation verification in this embodiment is a digital twin module. In this case, since the network device is configured in response to received configuration messages, and the digital twin module needs to simulate and verify the network device's configuration operations, the steps for realizing the user intent determined by the LLM include step 1, which generates a configuration message based on the task parameters contained in the user intent.

[0172] In addition, configuration messages include, but are not limited to, those in NETCONF. <edit-config>Configuration messages can include configuration editing requests, RESTCONF (Representational State Transfer Configuration Protocol) and HTTP (Hypertext Transfer Protocol) configuration change requests, and command-line interface (CLI) configuration commands. It's understandable that the type of configuration message generated in step 1 depends on the actual configuration transmission protocol used between the maintenance device and the network equipment.

[0173] For example, taking user intent 2, where the user intent is to establish a network connection between autonomous system a and autonomous system b, as an example, since the task objective of user intent 2 is relatively coarse compared to user intent 1, and user intent 2 does not specify the specific devices to be connected, their IP addresses, and the port information of the devices to be connected, in this case, the LLM, based on its own reasoning ability and by parsing the task objective and task parameters obtained from user intent 2, can determine the multiple steps to implement user intent 2 and the execution order of these multiple steps at once as follows: Step a, determine the device information that can establish a network connection between regions a and b; Step b, generate a configuration message that can be sent to the network device based on the device information determined in step 1 and the task objective of user intent 2; Step c, perform configuration simulation verification on the configuration message; Step d, after successful verification of the configuration message, send the configuration message to the network device so that the network device can respond to the configuration message and perform the corresponding configuration; Steps a to d are executed sequentially.

[0174] Step 103: Based on the above execution order, after determining the execution of the first step, verify the changes to the network changes indicated by the user's intent, and obtain the verification results.

[0175] After the change agent of the operation and maintenance device obtains the multiple steps to realize the user's intention and the execution order of the multiple steps, it executes the multiple steps in sequence. After determining that the first step needs to be executed according to the execution order of the multiple steps, it verifies the change content of the network change executed by the user's intention and obtains the verification result.

[0176] Specifically, the change agent of the operation and maintenance device outputs a verification command to the digital twin module of the operation and maintenance device. This verification command verifies the content of the network change indicated by the user's intent. The digital twin module, in response to the received verification command, obtains the verification result corresponding to the network change and outputs the verification result to the change agent. For example, the change agent can output the verification command to the digital twin module through the API interface provided by the digital twin module. Similarly, the digital twin module can output the verification result to the change agent through its own API interface.

[0177] Taking the user intent as User Intent 1 as described above, and the digital twin module as a network digital twin system as an example, when the change agent obtains the multiple execution steps for realizing User Intent 1, which are steps 1 to 3 as described above, and steps 1 to 3 are executed sequentially, the change agent can send the task objective and task parameters of User Intent 1 (such as {"vlan_id":10,"interface":"GigabitEthernet 0 / 1","ip_address":"192.168.10.1","subnet_mask":"255.255.255.0"}) to the change management module of the network digital twin system through the API interface provided by the change management function of the network digital twin system. In response, after receiving the task objective and task parameters of User Intent 1 based on the API interface, the change management module of the network digital twin system generates a configuration message that can be sent to the network device based on the task objective and task parameters of User Intent 1. It should be noted that if the task parameters contained in User Intent 1 are insufficient to generate a configuration message, the change management module of the network digital twin system can interact with the change agent via API to request the change agent to communicate with the user through the access module, thereby obtaining sufficient task parameters. After generating the configuration message, the change management module of the network digital twin system feeds the configuration message back to the change agent through its own provided API interface. Alternatively, after generating the configuration message, the change management module of the network digital twin system can send a notification message to the change agent through its own provided API interface to inform the change agent that the configuration message has been generated.

[0178] Subsequently, after receiving feedback from the change management module of the network digital twin system, the change agent confirms that step 1 has been completed and that step 2 needs to be executed; that is, the change agent determines that the first step needs to be performed. At this point, the change agent instructs the change management module in the network digital twin system to verify the changes indicated by user intent 1 through the online configuration simulation verification API provided by the change management function in the network digital twin system. Here, the changes indicated by user intent 1 can be implemented by applying the configuration message generated by the change management module in step 1 within the network digital twin system. Therefore, the change management module performs simulation verification operations (including configuration language verification, service, protocol, and resource verification, etc.) in the network digital twin system based on the aforementioned configuration message, generates a verification report indicating success / failure, and sends the verification report to the change agent through the API interface.

[0179] Step 104: Perform the second step based on the verification results.

[0180] Specifically, after the change agent of the operation and maintenance device obtains the verification result from the digital twin module, it performs the second step mentioned above based on the verification result.

[0181] In one possible scenario, the verification result is successful. In this case, the change agent will send a configuration message generated based on the task parameters carried by the user intent to the network device, so that the network device can respond to the configuration message and perform corresponding configuration. For example, the change agent can execute the task of sending the configuration message to the network device through the control and analysis unit.

[0182] In another possible scenario, the verification result is failure. In this case, the digital twin module also obtains the reason for the verification failure and optimization suggestions based on the verification result for the network change indicated by the user's intent.

[0183] Based on the above example, if the verification result of the simulation verification operation performed by the change management module of the network digital twin system based on the configuration message in the network digital twin system fails, then the network digital twin system will also analyze and determine the reason for the verification failure of the network change indicated by user intention 1 and at least one optimization suggestion based on the task objective and task parameters of user intention 1. In one example, the process by which a network digital twin system analyzes and determines the reasons for verification failures and provides optimization suggestions for network changes indicated by user intent 1 may include: the network digital twin system collecting real-time data from the physical network (including network device status, traffic data, latency, bandwidth utilization, etc.), constructing a digital twin model based on the collected data, and using the digital twin model to simulate the behavior and characteristics of the physical network; then, the network digital twin system running simulations on the digital twin model to analyze the current network's performance bottlenecks, potential problems, and the reasons for the aforementioned verification failures, as well as simulating different configurations, traffic loads, and fault scenarios to evaluate the network's performance under different conditions; then, the network digital twin system using AI algorithms (such as reinforcement learning, deep learning) to analyze the simulation results and generate optimization suggestions, or, based on predefined optimal times and rules, providing configuration optimization suggestions (such as routing optimization, bandwidth allocation, etc.) for specific problems.

[0184] Since the relevant management protocol interface does not support the transmission of configuration parameters for optimization suggestions, this application embodiment extends the relevant interface to transmit configuration parameters for optimization suggestions through the extended interface.

[0185] One example extends the NETCONF / RESTCONF interface. Specifically, it adds error tags for specific verification scenarios (corresponding to the bolded and underlined content in example code 1 below) and configuration optimization suggestions for network changes (corresponding to the bolded and un-underlined content in example code 1 below) to the remote procedure call (RPC) error response. The RPC error response is a standard mechanism for handling errors in NETCONF and RESTCONF. Example code 1 is as follows:

[0186] As can be seen, in example code 1, the reason for the failure of the verification of the network change indicated by user intent 1 (i.e., the error tag) is an IP address conflict, and the optimization suggestion given by the digital twin module is: replace the conflicting interface address (i.e., 192.168.10.1 / 24 carried by user intent 1) with the IP version 4 (IPv4) address 192.168.2.2 / 24, or replace it with the IP version 6 (IPv6) address 2001:db8:11::1 / 48.

[0187] Another example involves extending the HTTP protocol interface. Specifically, it involves adding configuration optimization suggestions for network changes to the HTTP response message (corresponding to the bolded content in example code 2). Example code 2 is as follows:

[0188] As can be seen, in example code 2, the verification failure reason (i.e., error reason) for the network change indicated by user intent 1 is "IP address conflict detected. Conflicting device: 00:1A:2B:3C:4D:5E IP conflict". The optimization suggestion given by the digital twin module is to replace the conflicting interface address (i.e., 192.168.10.1 / 24 carried by user intent 1) with the IP version 4 (IPv4) address 192.168.2.2 / 24, or with the IP version 6 (IPv6) address 2001:db8:11::1 / 48.

[0189] In one possible implementation, for the optimization suggestions obtained by the digital twin module based on the verification results, the digital twin module sends the obtained verification failure reasons and / or at least one optimization suggestion to the change agent. In response, the change agent performs network modifications on the target network based on one of the received optimization suggestions, thereby optimizing the target network. Specifically, the change agent can randomly select an optimization algorithm from the at least one optimization suggestion to modify the target network, or it can use LLM (Limited Linear Modulation) to perform reasoning analysis on the at least one optimization suggestion and the user intent, and then select the optimal optimization algorithm to modify the target network.

[0190] Optionally, the change agent can also output the received verification failure reason and / or optimization suggestion to the access module, which then outputs the verification failure reason and / or optimization suggestion to the user. Optionally, the input module can then receive the user's confirmation result for the optimization suggestion, indicating whether to perform network changes to the target network according to the optimization suggestion. When the access module outputs multiple optimization suggestions to the user, the confirmation result also indicates the target optimization suggestion selected by the user from among the multiple suggestions. Next, the access module also outputs the received confirmation result to the change agent. Upon receiving the user's confirmation result for the optimization suggestion, and if the confirmation result indicates that network changes to the target network should be performed according to the optimization suggestion / target optimization suggestion, the change agent performs network changes to the target network according to the optimization suggestion / target optimization suggestion, thereby achieving network optimization of the target network. For example, the change agent can send a configuration message of the optimization suggestion to the network device through the control and analysis unit.

[0191] In another possible implementation, the digital twin module directly outputs the acquired verification test reasons and / or optimization suggestions to the access module of the operation and maintenance device, and the access module outputs the verification failure reasons and / or optimization suggestions to the user. Optionally, the input module can then receive the user's confirmation of the optimization suggestions, indicating whether to make network changes to the target network according to the optimization suggestions. Next, the access module outputs the received confirmation to the change agent. In response, the change agent receives the user's confirmation of the optimization suggestions, and if the confirmation indicates that network changes should be made to the target network according to the optimization suggestions, it performs the network changes according to the optimization suggestions, thereby achieving network optimization of the target network. For example, the change agent can send configuration messages of optimization suggestions to network devices through the control and analysis unit.

[0192] Subsequently, the change agent can also obtain the configuration execution result after the network device responds to the configuration message through the control and analysis unit, and return the execution result to the user who initiated the user intent through the input module. Optionally, the change agent can also record operation and maintenance logs in the memory engine, including but not limited to user intents, the time of receiving user intents, and the processing result of user intents.

[0193] Optionally, the user can also score the execution of this user intent based on the execution result. After the agent obtains this score, it can analyze the inference performance of the LLM in processing this user intent, and update the LLM with the user intent and the score of the user intent as new corpus to improve the LLM's ability to process such user intents in the future.

[0194] The operation and maintenance method described in steps 101 to 104 enables the decomposition of user intents into tasks through a change agent in network change operation and maintenance scenarios. It also allows for the simulation of network device and protocol behavior using technologies such as digital twin modules. This verifies the logical correctness of the network change indicated by the user intent and the syntactic correctness of the configuration messages used to implement the change. Only when verification is successful is the network change indicated by the user intent executed on the target network. Furthermore, this method not only verifies the correctness of the network change but also provides one or more optimization suggestions when verification fails, such as suggested values ​​for the configuration parameters of the network change indicated by the user intent. Therefore, this method can automate the simulation and verification of various network protocols and service configurations in network change operation and maintenance scenarios without manual intervention. These various network protocols and service configurations include, but are not limited to, BGP configuration, VPN configuration, and cross-domain traffic engineering configuration.

[0195] To deepen the understanding of the method shown in Figure 10, the method described in Figure 10 will be further introduced below with specific examples.

[0196] Referring to Figure 11, Figure 11 illustrates a process diagram of the operation and maintenance method provided in this application embodiment. As shown in Figure 11, the access module of the operation and maintenance device includes a northbound interface for communicating with the work order system in OSS, a GUI for communicating with operation and maintenance personnel, and an access control unit. When the access module receives a user intent (such as user intent 1 as described above) through the northbound interface or GUI, the access control unit determines whether the operation and maintenance device allows processing the user intent 1 (refer to the relevant description of step 101). Then, if the access control unit of the access module determines that the operation and maintenance device allows processing the currently received user intent 1, it outputs user intent 1 to the change agent. After obtaining user intent 1, the change agent interacts with the LLM and uses the inference capability of the LLM to obtain the three steps for implementing the user intent and the execution order of these three steps (refer to step 102). Then, the change agent executes step 1 according to the execution order: the change agent interacts with the change management module through the interface provided by the change management module in the digital twin module, thereby obtaining the configuration message generated by the change management module based on the task parameters of the user intent. Next, the change agent executes step 2 in the execution sequence: the change agent interacts with the change management module through the interface provided by the change management module in the digital twin module, thereby instructing the change management module to perform configuration simulation verification on the configuration message and obtain the verification result. Then, if the verification result is successful, the change agent executes step 3: the control and analysis unit in the operation and maintenance device sends the configuration message to the network device to complete the configuration distribution of the network device. If the verification result fails, the change agent can still obtain the optimization suggestions output by the change management module. The change agent can output these optimization suggestions through the access module and receive the user's confirmation result of the optimization suggestions. If the confirmation result indicates that network changes should be made to the target network according to the optimization suggestions, the change agent executes the configuration changes indicated by the optimization suggestions on the network device according to the optimization suggestions and through the control and analysis unit in the operation and maintenance device. Then, the change agent can also record the configuration changes performed on the network device for this user intent in the memory engine for later querying. After the network changes to the target network are completed, the change agent can also output the change result (i.e., the operation and maintenance result) through the access module.

[0197] Operation and maintenance scenario 2: Network failure.

[0198] Referring to Figure 12, Figure 12 shows a flowchart of another operation and maintenance method provided in an embodiment of this application. Optionally, this method can be applied to any of the implementation environments shown in Figures 3 to 5, and executed by an operation and maintenance device with the architecture shown in Figure 7 or Figure 8. As shown in Figure 12, the method includes the following steps 201 to 203.

[0199] Step 201: Receive user intent, which is used to instruct on how to handle a fault in the target network.

[0200] Specifically, the operation and maintenance device receives user intents via the access module, indicating instructions to handle faults in the target network. For details on how the access module receives user intents and processes them, please refer to the description in step 101; it will not be repeated here.

[0201] It should be noted that the difference between step 201 and step 101 is as follows: after the access module of the operation and maintenance device receives the user intent and / or determines that the operation and maintenance device allows the processing of the user intent, the access module outputs the user intent to the fault agent of the operation and maintenance device; or, after the access module of the operation and maintenance device receives the user intent and / or determines that the operation and maintenance device allows the processing of the user intent, the access module outputs the task target and task parameters extracted from the user intent to the change agent.

[0202] For example, in a network failure scenario, the user's intent task objective could be to diagnose the root cause of a failure or to repair a failure. The user's intent task parameters include, but are not limited to, the time of failure occurrence, the frequency of failure occurrence, and / or the performance indicators that the network / / devices need to achieve after failure repair, etc. It is understood that the failure indicated by the user intent in step 201 is usually a failure / risk already existing in the target network. Diagnosing the root cause of a failure means: by diagnosing the failure, accurately locating the source of the failure and identifying the root cause of the network failure, thereby helping maintenance personnel quickly understand the root cause of the failure. Repairing a failure means: automatically repairing potential or existing failures and risks in the target network, such as by performing repair operations in the target network, such as adjusting network configuration, restarting devices, or notifying maintenance personnel to replace hardware components, so that the target network system returns to normal operation.

[0203] Step 202: Based on user intent, obtain the first diagnostic result and the first repair suggestion.

[0204] The first diagnostic result is the diagnostic result of the fault indicated by the user's intent, and the first repair suggestion is the suggestion to repair the fault indicated by the user's intent.

[0205] It should be understood that when a user's intended task goal is to repair a certain fault, the processing of that user's intention by the maintenance device includes: first diagnosing the root cause of the fault, then determining repair suggestions based on the root cause, and finally repairing the fault according to the repair suggestions. Therefore, after the maintenance device's fault intelligence agent obtains the user's intention or the task goal and task parameters contained in the user's intention from the access module, when the fault intelligence agent determines that the user's intended task goal is to diagnose the root cause of the fault and / or repair the fault, the fault intelligence agent outputs a fault diagnosis instruction to the fault management module. This fault diagnosis instruction is used to instruct the fault indicated by the user's intention to be diagnosed in order to determine the root cause of the fault. For example, when the fault management module is implemented by the incident fault management module shown above, the fault intelligence agent can output a fault diagnosis instruction to the incident fault management module through the incident fault management API provided by the incident fault management module.

[0206] Optionally, if the user intent obtained by the fault is the user intent received by the access module through the GUI, the fault agent can determine the task objective by parsing the user intent, and output a fault diagnosis instruction to the fault management module when the task objective is to diagnose the root cause of the fault or repair the fault.

[0207] Optionally, if the user intent obtained from the fault is a user intent indicated by a work order received by the access module through the northbound interface, and this work order is a work order created by the work order system based on a fault reported by the fault management module, then the user intent indicated by the work order generally includes a status field of the fault used to create the work order. This status field is used to record whether the fault has been diagnosed or repaired. Therefore, the fault agent parses the status field of the fault carried in the user intent, and outputs a fault diagnosis instruction to the fault management module when the status field indicates that the fault has not been diagnosed.

[0208] In one example, if the fault agent obtains a user intent from the access module, the fault agent first parses the user intent to obtain the task objective and task parameters of the user intent. After determining that the task objective of the user intent is to diagnose the root cause of the fault and / or repair the fault, the fault agent outputs a fault diagnosis instruction to the fault management module through the API interface provided by the fault management module. At this time, the fault diagnosis instruction includes the task objective and task parameters of the user intent.

[0209] In another example, if the fault agent obtains the user's intention task objective and task parameters from the access module, and determines that the user's intention task objective is to diagnose the root cause of the fault and / or repair the fault, then the fault agent directly outputs a fault diagnosis instruction to the fault management module through the API interface provided by the fault management module, and the fault diagnosis instruction includes the user's intention task objective and task parameters.

[0210] In another example, if the user intent is a work order received from the northbound interface of the operation and maintenance device access module, and this work order is a work order created by the work order system based on a fault reported by the fault management module, then the user intent received by the operation and maintenance device from the work order also includes the IDs of one or more faults used to create the work order. Therefore, when the fault agent receives the user intent or the task objective and task parameters contained in the user intent, it can also receive the IDs of one or more faults used to create the work order. In this case, since the fault management module contains relevant information about the monitored faults, when the fault agent determines that the task objective of the user intent is to diagnose the root cause of the fault and / or repair the fault, the fault diagnosis instruction output to the fault management module through the API interface provided by the fault management module includes the fault ID carried by the user intent. In this embodiment, the fault management module can receive alarms reported by network devices in the target network, aggregate faults from the received alarms, generate an ID for the fault, and record the fault and the fault ID in the fault record. For example, the fault management module is the incident fault management module mentioned above.

[0211] Next, the fault management module receives the fault diagnosis command and, in response to the fault diagnosis command, obtains the first diagnosis result and the first repair suggestion.

[0212] In one example, the fault management module is the incident fault management module mentioned above. The incident fault management module can collect log files of the devices, applications or services involved in the fault corresponding to the task target and search for abnormal records through the control and analysis unit based on the task target and task parameters indicated by the fault diagnosis instruction. It can also query the alarms of the target network (such as performance degradation, connection interruption, log error and other alarms) to determine the scope of the fault impact (such as a single user, a specific device or the entire target network). Subsequently, the incident management module locates the fault through layered troubleshooting. For example, at the hardware layer, it checks the physical status of network devices related to the task objective (such as the physical status of power supplies, network cards, and hard drives); at the network layer, it uses the control and analysis unit to test network connectivity and performance (e.g., based on one or more operations such as ping, traceroute, iperf, network performance measurement, bandwidth utilization measurement, telemetry data acquisition, and / or target network configuration checks); at the system layer, it checks the operating system status of network devices related to the task objective (such as the utilization of the central processing unit (CPU), memory, and disk); and / or, at the application layer, it verifies the health of applications related to the task objective (such as whether the application is running and whether the application configuration file is correct). This process achieves fault location. Ping and traceroute are commonly used command-line tools in network fault diagnosis, used to test network connectivity and analyze packet transmission paths. iperf is an open-source tool for testing network bandwidth performance, which can be used to measure metrics such as network throughput, latency jitter, and packet loss rate. In this way, based on the collected data and the inspection results of each layer, the incident fault management module can determine the diagnostic result of the fault indicated by the user's intent (i.e., the first diagnostic result), and provide repair suggestions (i.e., the first repair suggestion) based on the root cause of the fault indicated by the first diagnostic result. Here, the first repair suggestion refers to one or more repair operations performed on the target network in response to the root cause of the fault indicated by the first diagnostic result. These one or more repair operations include, but are not limited to, adjusting the configuration of the target network, restarting one or more network devices in the target network, or notifying the operation and maintenance personnel to replace the hardware components of the network devices.

[0213] After obtaining the first diagnostic result and the first repair suggestion, the fault management module outputs these to the fault agent. For example, if the fault management module is an incident fault management module, it can output the first diagnostic result and the first repair suggestion to the fault agent through its own standard API interface.

[0214] Step 203: Based on the first diagnostic result and the first repair suggestion, repair the fault.

[0215] In the first possible scenario, after receiving the first diagnostic result and the first repair suggestion output by the fault management module, the fault intelligence agent of the operation and maintenance device repairs the fault indicated by the user's intent.

[0216] Optionally, the fault-fault intelligent agent distributes the configuration corresponding to the first repair suggestion to network devices in the target network through the southbound interface of the control and analysis unit (such as NETCONF / RESTCONF / CLI interface, etc.), so as to perform the repair operations indicated by the first repair suggestion on the network devices in the target network, such as restarting a network device or modifying the configuration of a network device. In this way, the root cause of the fault indicated by the first diagnostic result can be repaired, thereby achieving the repair of the fault indicated by the user intent.

[0217] Optionally, the fault intelligence agent is used to obtain a first fault repair instruction based on the first diagnostic result and the first repair suggestion, and output the first fault repair instruction to the fault management module. For example, taking the incident fault management module as an example, the fault intelligence agent can output the first fault repair instruction to the incident fault management module through the incident fault management API provided by the incident fault management module. It should be understood that the first fault repair instruction is generated based on the first diagnostic result and the first repair suggestion, which are determined by the incident fault management module after diagnosing the fault indicated by the user intent. Furthermore, the incident fault management module generally records fault records when processing faults, including fault IDs, fault diagnostic results, and repair suggestions. Therefore, when the fault intelligence agent outputs the first fault repair instruction to the incident fault management module through the incident fault management API, the first fault repair instruction carries the fault IDs of one or more faults for which the first diagnostic result was obtained. These fault IDs can then be used to query the first repair suggestion corresponding to the first diagnostic result. That is, the first fault repair instruction includes the ID of the fault indicated by the user intent, which corresponds to the first diagnostic result and the first repair suggestion. Of course, optionally, the first repair instruction may also carry the first repair suggestion.

[0218] In response, the fault management module responds to the first fault repair command and repairs the fault indicated by the user's intent. For example, the fault management module obtains a first repair suggestion from the first fault repair command, or it obtains a fault ID from the first fault repair command and queries the fault record based on that fault ID to find the first repair suggestion from the fault record. Then, the fault management module distributes the configuration corresponding to the first repair suggestion to the network devices in the target network through the southbound interface of the control and analysis unit (such as NETCONF / RESTCONF / CLI interface, etc.) to perform the repair operation indicated by the first repair suggestion on the network devices in the target network, such as restarting a network device or modifying the configuration of a network device. In this way, the root cause of the fault indicated by the first diagnostic result can be repaired, thereby repairing the fault indicated by the user's intent.

[0219] In the second possible scenario, after receiving the first diagnostic result and the first repair suggestion output by the fault management module, the fault intelligence agent of the operation and maintenance device judges the rationality and accuracy of the first diagnostic result and the first repair suggestion based on the knowledge base and memory engine mentioned above, so as to determine whether further diagnosis is needed for the fault indicated by the user's intent.

[0220] For example, the fault-fault agent combines expert experience and product manuals from the knowledge base with the fault thought chains and historical troubleshooting records (i.e., historical maintenance records related to network faults) embedded in the memory engine to assess the rationality and accuracy of the first diagnostic result and the first repair suggestion, in order to determine whether further diagnosis of the fault indicated by the user's intent is necessary. For instance, if the fault-fault agent determines that the first diagnostic result is a complete diagnosis and contains key diagnostic information for the fault indicated by the user's intent, then it determines that further judgment of the fault indicated by the user's intent is not necessary. Similarly, if the fault-fault agent determines that there is a similar fault troubleshooting record in the historical troubleshooting records, and the diagnostic result in that record is similar to the first diagnostic result, then it determines that further judgment of the fault indicated by the user's intent is not necessary. Furthermore, if the fault-fault agent determines that there is a similar fault in the knowledge base (such as expert experience), and the first diagnostic result is one of the fault causes given by the expert experience, then it determines that further judgment of the fault indicated by the user's intent is not necessary.

[0221] Optionally, when the fault agent determines that further diagnosis of the fault indicated by the user intent is unnecessary, in addition to repairing the fault indicated by the user intent based on the first diagnostic result and the first repair suggestion (as described in the first possible case), the fault agent can also report the first diagnostic result and the first repair suggestion through the access module. For example, the first diagnostic result, the first repair suggestion, and other relevant information can be displayed to the user through the GUI of the access module. This other relevant information includes, but is not limited to, the specific time the fault occurred, information about the specific faulty device (such as device type, device ID, IP address, etc.), and the expected repair time. Alternatively, the first diagnostic result, the first repair suggestion, the work order ID, and other relevant information can be reported to the work order system through the northbound interface of the access module.

[0222] Optionally, when the fault agent determines that further diagnosis of the fault indicated by the user intent is required, the fault agent can obtain one or more steps and their execution order through interaction with the LLM. These one or more steps are used to diagnose the fault indicated by the user intent, thereby obtaining diagnostic results and repair suggestions. It should be understood that the process by which the fault agent obtains these one or more steps through interaction with the LLM can be referred to in step 102 above, which describes changing the agent's interaction with the LLM to obtain multiple steps to realize the user intent and their execution order, and will not be repeated here. Subsequently, the fault agent executes these one or more steps according to their execution order and communicates with the target network through the control and analysis unit to obtain the diagnostic results and repair suggestions for the fault indicated by the user intent.

[0223] Subsequently, the fault-faulting agent repairs the fault indicated by the user's intent based on further confirmed diagnostic results and repair suggestions. For details, please refer to the description in the first possible scenario.

[0224] Optionally, if the fault agent determines that the repair operation indicated by the repair suggestion (such as the first repair suggestion or the repair suggestion obtained from further diagnosis) is to change the network configuration, the fault agent can also interact with the digital twin module through the interface provided by the digital twin module (the digital twin module shown in Figure 8), thereby realizing the simulation verification of the network configuration change indicated by the repair operation, and if the verification is successful, repairing the fault indicated by the user intent according to the successfully verified repair suggestion. For details, please refer to the description in the first possible case, which will not be repeated here.

[0225] Optionally, the fault-fault agent can also report further confirmed diagnostic results and repair suggestions via the access module. For example, the access module's GUI can display the diagnostic results, repair suggestions, and other relevant information to the user. This other relevant information includes, but is not limited to, the specific time the fault occurred, information about the faulty device (such as device type, device ID, IP address, etc.), and the expected repair time. Alternatively, the access module's northbound interface can be used to report the diagnostic results, repair suggestions, work order ID, and other relevant information to the work order system.

[0226] In the third possible scenario, if the user intent obtained by the fault agent in step 202 is a user intent indicated by a work order received by the access module through the northbound interface, and this work order is created by the work order system based on a fault reported by the fault management module, then the user intent indicated by the work order generally includes a status field of the fault used to create the work order. This status field is used to record whether the fault has been diagnosed or repaired. Therefore, the fault agent parses the status field of the fault carried in the user intent, and if the status field indicates that the fault has been diagnosed, outputs a fault repair instruction to the fault management module through the interface provided by the fault management module. Optionally, this fault repair instruction may carry a fault ID, so that the fault management module can query the fault record based on the ID to determine the diagnosis result and repair suggestion of the fault, and perform the repair operation indicated by the repair suggestion on the network device in the target network.

[0227] In the fourth possible scenario, if the user intent obtained by the fault agent in step 202 is a user intent indicated by a work order received by the access module through the northbound interface, and this work order is created by the work order system based on a fault reported by the fault management module, then the user intent indicated by the work order includes, in addition to the status field of the fault used to create the work order, a status field used to record whether the fault has been diagnosed or repaired, etc. Therefore, by parsing the status field of the fault carried in the user intent, and if the status field indicates that the fault has been diagnosed, the user intent obtained by the fault agent from the access module can also include the fault diagnosis result and repair suggestions.

[0228] Therefore, optionally, the fault-fault agent can output a fault repair command to the fault management module through the interface provided by the fault management module, and the fault repair command carries a repair suggestion contained in the user intent. In this way, the fault management module can perform the repair operation indicated by the repair suggestion on the network devices in the target network based on the repair suggestion, so as to complete the repair of the fault indicated by the user intent.

[0229] Optionally, the fault-faulting agent can directly perform the repair operations indicated by the repair suggestions carried in the user intent on the network devices in the target network through communication between the control and analysis unit and the target network, thereby completing the repair of the fault indicated by the user intent.

[0230] By employing the methods described in steps 201 to 203, this embodiment of the application combines a fault intelligence agent and a fault management module (such as incident fault management). This allows the fault intelligence agent to replace maintenance personnel in manually calling the interfaces provided by the fault management module to perform root cause diagnosis and fault repair during network fault maintenance. This avoids the human-computer interaction required by the fault management module when handling network fault maintenance, thus improving the automation level of network fault maintenance. Furthermore, this embodiment of the application can further optimize the fault diagnosis results and repair suggestions obtained by the fault management module through the fault intelligence agent, thereby improving the efficiency of fault repair.

[0231] In some embodiments, referring to FIG13, FIG13 shows a flowchart of another operation and maintenance method provided by an embodiment of the present application. Optionally, the method can be applied to any of the implementation environments in FIG3 to FIG5 and executed by an operation and maintenance device having the architecture shown in FIG7 or FIG8. As shown in FIG13, after executing steps 201 to 203, the method further executes the following steps 204 to 205.

[0232] Step 204: Obtain the repair results.

[0233] Optionally, the fault management module can also obtain the repair results after performing the repair operation indicated by the first repair suggestion on the target network.

[0234] In one example, the fault management module can determine the repair result by querying the status of the fault indicated by the user intent in the fault record. It should be understood that the fault management module records fault records (i.e., the fault records mentioned above) during the fault handling process. These fault records include the fault status, such as fault diagnosed, fault not diagnosed, fault repaired and cleared, fault repaired but not cleared, fault repaired but not completely cleared, etc. Specifically, "fault repaired and cleared" indicates successful fault repair, "fault repaired but not cleared" indicates failed fault repair, and "fault repaired but not completely cleared" indicates that part of the fault repair was successful while the other part failed.

[0235] In another example, after executing the first repair suggestion, the fault management module can determine whether the fault indicated by the user's intent has been resolved based on alarms reported by network devices in the target network within a preset time period, thereby obtaining the repair result of the first repair suggestion. This application embodiment does not limit this aspect.

[0236] After the fault management module obtains the repair result of the first repair suggestion, it can output the repair result to the fault agent through its provided interface. This repair result may include the fault ID of the repaired fault and the fault repair status, such as repair successful, repair failed, or partial repair successful. Optionally, the repair result may also include detailed fault repair information. Optionally, when the fault repair status is repair failed or partial repair successful, the detailed fault repair information may also include the diagnostic results of the failed repair.

[0237] In one example, the fault management module is implemented as an incident fault management module. The incident fault management module can output the repair results to the fault agent by calling its own standardized API.

[0238] In response, the fault agent receives the repair results output by the fault management module and parses the repair results.

[0239] When the fault agent determines that the repair result indicates successful fault repair, it outputs the repair result through the access module. For example, the access module displays the repair result to the user via a GUI. Alternatively, the access module sends the repair result to the work order system via the northbound interface. The work order system then updates the fault status in the work order based on the received repair result carrying the fault ID, such as updating the fault status to "repaired." At this point, it indicates that the work order has been completed.

[0240] When the fault agent determines that the repair result indicates that the fault repair has failed or the fault has not been completely repaired, step 205 is executed.

[0241] Step 205: When the repair result indicates that the fault repair has failed or the fault has not been completely repaired, obtain at least one step to achieve the repair objective and the execution order of the at least one step based on the repair result, and execute the at least one step in the execution order to complete the repair of the fault that failed to be repaired and the fault that was not completely repaired.

[0242] If the repair result indicates that the fault repair failed, then the repair target is the task target of the user intent described in step 201. If the repair result indicates that the fault was not completely repaired, then the repair target is the unrepaired part of the task target of the user intent in step 201.

[0243] Specifically, when the fault agent determines that the obtained repair results indicate that the fault repair has failed or the fault has not been completely repaired, it can obtain at least one step to achieve the repair goal and the execution order of the at least one step by interacting with the LLM.

[0244] In one example, the fault agent first determines the diagnostic results and repair goals for the unrepaired faults indicated by the user intent, based on the detailed fault repair information carried in the repair results. Then, the fault agent sends a task decomposition request to the device deployed with LLM. This request requests the determination of at least one step and its execution order for achieving the repair goals based on the diagnostic results of the unrepaired faults. The task decomposition request includes the diagnostic results of the unrepaired faults and the repair goals. In response, the device deployed with LLM receives the task decomposition request and, based on its own reasoning capabilities and the diagnostic results of the unrepaired faults, determines at least one step and its execution order for achieving the repair goals, and sends the determined steps and their execution order to the fault agent. The fault agent then receives the at least one step and its execution order returned by the device deployed with LLM.

[0245] In another example, where the maintenance device also includes an LLM (Limited Management Library), the fault agent first determines the diagnostic results and repair goals for the unrepaired faults indicated by the user intent, based on the detailed fault repair information carried in the repair results. Then, the fault agent outputs the diagnostic results and repair goals for the unrepaired faults to the LLM. In response, the LLM utilizes its reasoning capabilities and, based on the diagnostic results of the unrepaired faults, determines at least one step to achieve the repair goal and the execution order of that at least one step, and outputs the determined at least one step and its execution order to the fault agent. Thus, the fault agent obtains from the LLM at least one step to achieve the repair goal and its execution order.

[0246] Once the fault-fault agent obtains at least one step for achieving the repair objective and the execution order of that step, it can execute each step sequentially according to the execution order and through communication between the control and analysis unit and network devices in the target network, thereby achieving the repair objective. After the fault-fault agent completes the repair of the repair objective, it signifies that the repair of the fault indicated by the user intent in step 201 has been completed.

[0247] Using the methods described in steps 201 to 205, this embodiment of the application combines a fault intelligence agent and a fault management module (such as incident fault management). When the fault management module handles network fault maintenance, the fault intelligence agent replaces the maintenance personnel in manually calling the interface provided by the fault management module to perform fault root cause diagnosis and fault repair. Furthermore, if the fault management module fails to repair the fault or partially fails to repair it, the fault intelligence agent uses the inference capability of LLM to repair the unrepaired fault. This not only improves the automation level of network fault maintenance but also increases the fault repair rate.

[0248] In other embodiments, referring to FIG14, FIG14 shows a flowchart of another operation and maintenance method provided by an embodiment of the present application. Optionally, the method can be applied to any of the implementation environments in FIG3 to FIG5 and executed by an operation and maintenance device having the architecture shown in FIG7 or FIG8. As shown in FIG14, after executing steps 201 to 202, the method further executes the following steps 206 to 207.

[0249] Step 206: Based on the root cause of the fault indicated by the first diagnostic result, query the historical operation and maintenance records to determine whether there is a target operation and maintenance record in the historical operation and maintenance records that caused the root cause of the fault.

[0250] Each operation and maintenance record in the historical operation and maintenance records is used to record relevant information for a network operation and maintenance, including but not limited to: task ID (i.e., the task objective contained in the user's intent), task occurrence time, device information of the network devices involved in the task, task content (such as modifying a certain configuration parameter, etc.).

[0251] After obtaining the first diagnostic result from the fault management module, the fault intelligence agent, in addition to executing steps 203 to 205 as described above to repair the fault indicated by the user's intent, can also query the historical maintenance records in the memory engine based on the root cause of the fault recorded in the first diagnostic result to determine whether there is a target maintenance record in the historical maintenance records that caused the root cause of the fault. The content recorded in the target maintenance record may include the root cause of the fault recorded in the first diagnostic result, or the content recorded in the target maintenance record may contain information that caused the root cause of the fault recorded in the first diagnostic result to occur.

[0252] For example, if the fault agent determines that the root cause of the fault recorded in the first diagnostic result is exactly the task content recorded in a certain maintenance record in the historical maintenance records, this means that the maintenance task corresponding to that maintenance record is the root cause of the fault indicated by the user intent in step 201. Therefore, the fault agent can identify that maintenance record as the target maintenance record.

[0253] Step 207: If it is determined that there is a target maintenance record in the historical maintenance records that leads to the above-mentioned root cause of the failure, optimize the LLM that provides inference services for the maintenance device based on the root cause of the failure and the target maintenance record.

[0254] If the fault agent determines that a target maintenance record exists in the historical maintenance records, it can submit the target maintenance record and the root cause of the fault as negative samples to the LLM that provides inference services for the maintenance device, so that the LLM can be trained based on the negative samples to obtain an optimized LLM.

[0255] In this way, the embodiments of this application realize the use of network fault diagnosis results as feedback information of historical operation and maintenance, and optimize the LLM that provides inference services for operation and maintenance devices based on the feedback information, so that the LLM can provide more accurate inference services in subsequent network operation and maintenance.

[0256] In some other embodiments, referring to FIG15, FIG15 shows a flowchart of another operation and maintenance method provided by an embodiment of the present application. Optionally, the method can be applied to any of the implementation environments in FIG3 to FIG5 and executed by an operation and maintenance device having the architecture shown in FIG7 or FIG8. As shown in FIG15, the method includes the following steps 301 to 302.

[0257] Step 301: Monitor alarms in the target network and determine fault events based on the monitored alarms.

[0258] In this embodiment, the fault management module in the operation and maintenance device can receive alarms reported by network devices in the target network in real time via the control and analysis unit. Furthermore, the fault management module can also receive network operation status data and network event notifications reported by network devices in the target network via the control and analysis unit. The transmission of alarms, network operation status data, and network event notifications between the fault management module and the control and analysis unit, and between the control and analysis unit and network devices, includes, but is not limited to: Simple Network Management Protocol (SNMP) interface, System Log Protocol (SYSLOG) interface, YANG-push interface, or other API interfaces.

[0259] By performing cluster analysis on the received data, the fault management module can identify fault events, which can be ongoing or potential fault events. In other words, in this way, the fault management module can discover potential risks in the target network.

[0260] In some exemplary embodiments, the process by which the fault management module performs cluster analysis on various received data to determine fault events may include the following steps S1 to S4.

[0261] S1. The fault management module preprocesses the received data.

[0262] The fault management module performs data preprocessing operations including but not limited to: removing duplicate, erroneous, or incomplete data, and standardizing the format of data reported by different network devices and different protocol interfaces.

[0263] S2. The fault management module aggregates the preprocessed data to obtain aggregated data.

[0264] The embodiments of this application do not specifically limit the specific implementation method of data aggregation.

[0265] In one example, the fault management module can aggregate data received within the same time window into a group of aggregated data. The time window can be a pre-set clustering period. This application does not specifically limit the value of the period; for example, the period can be set based on expert experience, or it can be determined based on machine learning after historical data clustering using different time windows of varying lengths.

[0266] In another example, the fault management module can aggregate data based on the device reporting the data; for instance, it can aggregate data reported by the same device as a group. Alternatively, the fault management module can aggregate data based on the service to which the reported data belongs; for instance, it can aggregate data reported by the same service in the target network as a group.

[0267] In another example, the fault management module can aggregate data according to alarm type, such as aggregating alarms of the same type into a set of aggregated data.

[0268] S3, the fault management module performs correlation analysis on each group of aggregated data obtained.

[0269] Optionally, the fault management module can analyze the correlation of alarms in each set of aggregated data to determine the root cause in each set of aggregated data.

[0270] For example, the fault management module identifies that alarm 1 contained in aggregate data 1 is an alarm that device 1 interface is disconnected, and identifies that alarm 2 contained in aggregate data 2 is an alarm that the neighbor relationship between a pair of BGP neighbors is disconnected. If the disconnected device 1 interface in alarm 1 is the interface of one of the devices in the disconnected BGP neighbor relationship in alarm 2, then alarm 1 is the root cause of alarm 2.

[0271] Optionally, the fault management module can also analyze the background of alarms based on the context associated with the alarms in each set of aggregated data. The context associated with the alarm includes, but is not limited to, information such as the operating status of the network device that reported the alarm, configuration changes, historical operating data, and historical behavior.

[0272] S4, the fault management module identifies fault events based on the correlation of aggregated data.

[0273] Optionally, the fault management module can identify faults based on preset rules. For example, a rule might be that if a device's performance metrics (such as CPU utilization or memory utilization) exceed a threshold, a fault event is identified.

[0274] Optionally, the fault management module can perform machine learning-based predictions on the aggregated data to predict potential fault events. For example, machine learning algorithms can be used to identify anomalous data in the aggregated data to predict potential faults. Alternatively, the performance metric trends of the aggregated data can be analyzed to predict resource shortages or performance degradation.

[0275] Step 302: Create a work order based on the fault event.

[0276] Among them, the work order created based on the fault event is the work order that the access module receives through the northbound interface in step 201, which indicates the user's intention.

[0277] In one possible implementation, after identifying a fault event, the fault management module can directly report the fault event to the work order system. In response, the work order system can create a work order based on the fault event. The fault event reported by the fault management module can include at least one of the following information: fault ID, fault type, fault severity, fault reporting time, network resources affected by the fault, fault description information, descriptions of other faults related to the current fault, fault status (including diagnosed, undiagnosed, cleared (indicating the fault has been repaired), not cleared (indicating the fault has not been repaired), etc.), suggested processing priority, and additional data.

[0278] In another possible implementation, after the fault management module identifies a fault event, it can report the fault event to the work order system sequentially via the fault agent and the access module. In response, the work order system can create a work order based on the received fault event.

[0279] In another possible implementation, the fault management module can first report the aforementioned fault events to the fault agent. For example, the fault management module can report fault events to the fault agent based on its own standardized interface.

[0280] After receiving a fault event reported by the fault management module, the fault intelligence agent sends a business analysis command to the digital twin module. This command requests analysis of the business impact indicated by the fault event. The business analysis command includes at least the fault description information from the fault event. For example, the fault intelligence agent sends the business analysis command to the digital twin module by calling an interface provided by the digital twin module.

[0281] Upon receiving a service analysis command, the digital twin module responds by analyzing the services affected by the fault event. After determining the affected services, it returns service information about the affected services to the fault agent. For example, upon receiving the service analysis command, the digital twin module responds by analyzing the services affected by the fault event based on the fault description information, target network topology, and services carried by the target network, as carried in the command. The digital twin module identifies the services affected by the fault event, obtains their service information, and outputs this information to the fault agent through its provided interface.

[0282] Subsequently, the fault-aware agent requests the work order system to create a work order based on the alarm events reported by the fault management module and the service information affected by the alarm events output by the digital twin module. For example, the fault-aware agent reports alarm events and affected service information to the work order system via the access module. The work order system then creates a work order based on the received alarm events and affected service information.

[0283] Subsequently, the work order system can issue work orders to the access module of the operation and maintenance device in sequence according to the priority of the work orders, so that the operation and maintenance device can perform the work order processing described in steps 201 to 207 above based on the user intent indicated by the work order.

[0284] Through the methods described in steps 301-302, the operation and maintenance device can establish a solution for self-discovery, self-analysis, and self-troubleshooting of network fault hazards by leveraging the ability to discover potential faults provided by the fault management module (such as the incident fault management module) and the fault handling thought chain of the fault intelligence agent. The fault handling thought chain of the fault intelligence agent is the fault handling process of the fault intelligence agent, which can replace the operation and maintenance personnel in manually calling the interface provided by the fault management module to perform fault root cause diagnosis and fault repair. Therefore, the solution provided in this application embodiment reduces manual intervention and further improves the automation level of network troubleshooting.

[0285] The above section described solutions for maintenance devices that include only change agents or only fault agents. When a maintenance device includes both change agents and fault agents, these agents can be implemented by one agent or by two agents.

[0286] When the change agent and the fault agent are implemented through the same agent (as shown in Figure 9), it is equivalent to the agent including a change module with change agent capabilities and a fault module with fault agent capabilities. In this case, after the agent obtains the user intent from the access module of the maintenance device, optionally, the agent can first parse the user intent to obtain the task objective and task parameters, and then output the task objective and task parameters to the module corresponding to the maintenance task indicated by the user intent for processing. For example, if the maintenance task indicated by the user intent is to handle a fault, the agent will output the task objective and task parameters obtained from parsing the user intent to the fault module for processing. As another example, if the maintenance task indicated by the user intent is a network change, the agent will output the task objective and task parameters obtained from parsing the user intent to the change module for processing. Optionally, the agent can also first output the user intent to the corresponding model for processing based on the maintenance task indicated by the user intent. For example, if the maintenance task indicated by the user intent is to handle a fault, the agent will output the user intent to the fault module for processing. For example, if the user's intent indicates a network change as the operational task, the agent will output the user's intent to the change module for processing. Further details are omitted.

[0287] When the change agent and the fault agent are implemented through two agents, the process executed by the change agent after obtaining the user's intent can refer to the process executed by the change agent in the method described above, and the process executed by the fault agent after obtaining the user's intent can refer to the process executed by the fault agent in the method described above. Further details are omitted. Referring to Figure 16, Figure 16 shows a flowchart of another operation and maintenance method provided by an embodiment of this application. Optionally, this method can be applied to any of the implementation environments in Figures 3 to 5 and executed by an operation and maintenance device with the architecture shown in Figure 8. As shown in Figure 16, this method replaces steps 101 and 201 described above with the following step 401.

[0288] Step 401: Receive the user intent and determine the agent to process the user intent based on the user intent.

[0289] The maintenance device receives user intents through the access module. For details, please refer to the description of receiving user intents in step 101 or step 201.

[0290] After receiving a user intent, or after determining that the maintenance device allows processing the user intent, the access module outputs the user intent as the main intelligent agent, such as the main intelligent agent shown in Figure 8. It should be understood that the main intelligent agent is the agent that receives user intents from the access module by default.

[0291] After receiving a user intent, the main agent parses it to obtain the task objective and parameters. Based on the maintenance task indicated by the user intent and the capabilities of other agents within the maintenance device, the main agent outputs the obtained task objective and parameters to the corresponding agents for further processing.

[0292] For example, when the main agent determines that the operation and maintenance task indicated by the user's intent is to perform network changes on the target network, it outputs the task objective and task parameters obtained by parsing the user's intent to the change agent used to handle the network change task. After the change agent obtains the task objective and task parameters, the operation and maintenance device executes subsequent processing steps, such as steps 102 to 104.

[0293] For example, when the main agent determines that the operation and maintenance task indicated by the user's intent is to handle a fault in the target network, it outputs the task objective and task parameters obtained by parsing the user intent to the fault agent used to handle the network fault task. After the fault agent obtains the task objective and task parameters, the operation and maintenance device executes subsequent processing steps, such as steps 202 to 207.

[0294] The method shown in Figure 15 enables the operation and maintenance device to process user intents through a multi-agent architecture.

[0295] To deepen the understanding of the methods shown in Figures 10 to 16, the methods described in Figures 10 to 16 will be further described below with specific examples. Referring to Figure 17, Figure 17 shows another process diagram of the operation and maintenance method provided in the embodiment of this application.

[0296] As shown in Figure 17, the access module of the maintenance device includes a northbound interface for communicating with the work order system in OSS, a GUI for communicating with maintenance personnel, and an access control unit. When the access module receives a user intent through the northbound interface or the GUI, the access control unit determines whether the maintenance device allows processing the user intent (refer to the relevant description in step 201). Then, if the access control unit of the access module determines that the maintenance device allows processing the currently received user intent, it outputs the user intent to the fault agent.

[0297] After receiving the user's intent, the fault agent determines whether the fault indicated by the user's intent has been diagnosed. If the fault has not been diagnosed, the agent instructs the fault management module to diagnose the fault indicated by the user's intent through the interface provided by the fault management module, and obtains the diagnosis results and repair suggestions obtained by the fault management module (refer to step 202). The fault agent uses the reasoning ability of the LLM, the knowledge base, and the information contained in the memory engine to comprehensively judge the rationality and correctness of the diagnosis results, thereby determining whether further diagnosis is needed. If further diagnosis is needed, the fault agent uses the reasoning ability of the LLM to perform diagnosis and obtain new diagnosis results and repair suggestions. The fault agent also outputs the diagnosis results and repair suggestions through the access module. Furthermore, based on the diagnosis results and repair suggestions, the fault agent instructs the fault management module to perform fault repair through the interface provided by the fault management module (refer to step 203).

[0298] The fault-fault agent also obtains the repair results fed back by the fault management module, and when the repair result is successful, it outputs the repair result through the access module, which is the operation and maintenance result. In addition, when the repair result is a complete failure or a partial failure, it uses the inference capability of LLM to repair the unrepaired faults, and outputs the repair result through the access module (refer to the description of step 205).

[0299] After receiving the diagnostic results from the fault management module, the fault agent queries historical maintenance records based on the root cause indicated by the diagnostic results to determine whether the root cause is caused by historical maintenance. If the root cause is caused by historical maintenance, the root cause and the maintenance records that caused the root cause are used as negative feedback to optimize LLM, so as to adjust the accuracy of LLM inference capabilities (see steps 206 to 207).

[0300] In addition, the fault management module can detect alarms in the target network, identify fault events based on the detected alarms, and report the fault events to the fault agent. Subsequently, the work order system can create work orders based on the fault events and issue work orders to the operation and maintenance equipment, so that the operation and maintenance equipment can handle the fault described in the work order (refer to steps 301 to 302).

[0301] Referring to Figures 11 and 17, and further to Figure 18, Figure 18 illustrates another process diagram of the operation and maintenance method provided in the embodiments of this application. As shown in Figure 18, the functions and execution steps of changing the intelligent agent, digital twin module, fault intelligent agent, and fault management module can all be referred to the description above.

[0302] The difference in Figure 18 is that the operation and maintenance device also includes a master intelligent agent, which is used to distribute the user intent obtained from the access module to the corresponding intelligent agent (such as the fault intelligent agent, the change intelligent agent, etc.) for processing according to the capabilities of other intelligent agents (see the method description in step Figure 16 for details).

[0303] It should be noted that the maintenance device shown in Figure 18 may also include more intelligent agents, such as a query agent (not shown in Figure 18) for retrieving information from the knowledge base and memory engine. When the maintenance device also includes a query agent, when the query agent receives a user's intent to query information through the access module and the main agent, it can obtain the query results by accessing the knowledge base and memory engine, generate an answer based on the user's intent and the query results, and output the answer to the user through the access module.

[0304] This application also provides an operation and maintenance system, which includes: an access module, a main intelligent agent, a change intelligent agent as described in the method embodiments, and a fault intelligent agent as described in the method embodiments. The access module receives user intents and outputs these intents to the main intelligent agent. The main intelligent agent parses the user intents to obtain task objectives and task parameters. After determining that the user intent indicates a network change to the target network, the main intelligent agent outputs the task objectives and task parameters to the change intelligent agent, so that the change intelligent agent performs the portion executed by the change intelligent agent in the method embodiments described above. And / or, after determining that the user intent indicates handling a fault in the target network, the main intelligent agent outputs the task objectives and task parameters to the fault intelligent agent, so that the fault intelligent agent performs the portion executed by the fault intelligent agent in the method embodiments described above.

[0305] Optionally, the intelligent agent and the master intelligent agent can be changed to the same intelligent agent, and / or the faulty intelligent agent and the master intelligent agent can be changed to the same intelligent agent.

[0306] This application provides a computing device for implementing some or all of the functions of the method provided in this application. Alternatively, the computing device may be used to implement the operation and maintenance device provided in this application, or it may be used to implement one or more modules / units of the operation and maintenance device described in this application. This application does not limit the scope of the application.

[0307] Referring to Figure 19, which is a schematic diagram of a computing device according to an embodiment of this application, the computing device 1900 includes a processor 1901, a memory 1902, a communication interface 1903, and a bus 1904. The processor 1901, memory 1902, and communication interface 1903 are interconnected via the bus 1904. The computing device 1900 also includes an input / output interface 1905, which is interconnected with the processor 1901, memory 1902, and communication interface 1903 via the bus 1904.

[0308] Processor 1901 may include a general-purpose processor and / or a dedicated hardware chip. The general-purpose processor may include a CPU, a microprocessor, or a graphics processing unit (GPU). The CPU may be a single-core processor or a multi-core processor. The dedicated hardware chip is a high-performance processing hardware module. The dedicated hardware chip includes at least one of the following: digital signal processing (DSP), data processing unit (DPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, neural processing unit (NPU), tensor processing unit (TPU), artificial intelligence chip, or network processor (NP). Processor 1901 may also be an integrated circuit chip with signal processing capabilities. In implementation, some or all of the functions of the methods provided in this application embodiment may be implemented through the integrated logic circuitry of the hardware in processor 1901 or through software instructions.

[0309] Memory 1902 is used to store computer programs, including operating system 1902a and executable code (i.e., program instructions) 1902b. Memory 1902 is, for example, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other types of static storage devices that can store static information and instructions; it is also such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), and synchronous linked dynamic random access memory (SDRAM). DRAM (SLDRAM) or other types of dynamic storage devices capable of storing information and instructions, such as read-only optical discs or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired executable code in the form of instructions or data structures and accessible by a computer, but not limited thereto. For example, memory 1902 is used to store a knowledge base, memory engine, access control policies, etc. Memory 1902 may exist independently and be connected to processor 1901 via bus 1904. Alternatively, memory 1902 and processor 1901 may be integrated. Memory 1902 can store executable code. When the executable code stored in memory 1902 is executed by processor 1901, processor 1901 performs some or all of the functions of the method provided in the embodiments of this application. The implementation of processor 1901 performing this process is described in the relevant descriptions in the foregoing embodiments. The memory 1902 may also include software modules and data required by other running processes, such as the operating system.

[0310] Communication interface 1903 uses transceiver modules, such as, but not limited to, transceivers, to enable communication with other devices or communication networks. For example, communication interface 1903 can be any one or any combination of the following devices: network interfaces (such as Ethernet interfaces), wireless network cards, and other devices with network access capabilities. Communication interface 1903 includes a receiving unit for receiving data / messages and a sending unit for sending data / messages.

[0311] Bus 1904 is any type of communication bus used to interconnect internal devices (e.g., memory 1902, processor 1901, communication interface 1903) of computing device 1900. For example, a system bus. This embodiment illustrates the interconnection of the aforementioned devices within computing device 1900 via bus 1904. Optionally, the aforementioned devices within computing device 1900 can also communicate with each other using other connection methods besides bus 1904; for example, the aforementioned devices within computing device 1900 can be interconnected via internal logic interfaces.

[0312] Input / output interface 1905 is used to realize human-computer interaction between the user and computing device 1900. For example, it enables text or voice interaction between the user and computing device 1900. Input / output interface 1905 includes an input interface for the user to input information to computing device 1900, and an output interface for the computing device 1900 to output information to the user. As an example, the input interface includes, but is not limited to, a touchscreen, keyboard, mouse, or microphone, and the output interface includes, but is not limited to, a display screen, speaker, etc. The touchscreen, keyboard, or mouse is used to input text / image information, the microphone is used to input voice information, the display screen is used to output text / image information, and the speaker is used to output voice information. As an example, the input interface is used to receive user intent input, and the output interface is used to output maintenance results to the user.

[0313] It should be noted that the aforementioned devices can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices. Furthermore, the descriptions of the processes corresponding to the various figures above each have their own emphasis; for parts of a process not described in detail in one figure, please refer to the relevant descriptions of other processes.

[0314] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product providing the program development platform includes one or more computer instructions, which, when loaded and executed on the computing device 1900, implement some or all of the functions of the methods provided in the embodiments of this application.

[0315] Furthermore, computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium stores computer program instructions that provide a program development platform.

[0316] This application also provides a computer-readable storage medium, which is a non-volatile computer-readable storage medium. The computer-readable storage medium includes computer program instructions. When the computer program instructions are executed by a processor, a computing device including the processor, or a computer system, the processor, the computing device including the processor, or the computer system performs the operation and maintenance method provided in this application.

[0317] This application also provides a computer program product containing instructions that, when executed by a processor, a computing device including a processor, or a computer system, cause the processor, the computing device including a processor, or the computer system to implement the operation and maintenance method provided in this application.

[0318] A computer system is a system with computing capabilities. A computer system generally includes a processor and memory. The processor retrieves and executes instructions stored in memory to enable the computer system to implement the operation and maintenance methods described above. Optionally, a computer system may also include at least one of an input interface or an output interface. The processor, memory, input interface, and output interface of the computer system are interconnected through internal connection paths.

[0319] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing the relevant hardware to implement them. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0320] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0321] This application also provides a chip that includes a processor for running program instructions or code. The chip or a device containing the chip can be used to execute the operation and maintenance methods provided in this application. Exemplarily, the chip further includes an input interface, an output interface, and a memory. The chip's input interface, output interface, processor, and memory are connected via internal interconnection paths. The memory in the chip stores program instructions or code executed by the processor, and the input and output interfaces are used for communication between the chip and other chips or devices.

[0322] In the embodiments of this application, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The term "at least one" refers to one or more, and the term "multiple" refers to at least two, unless otherwise expressly defined.

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

[0324] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms "a" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0325] It should be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0326] It should be understood that the term "comprising" (also known as "includes", "including", "comprises" and / or "comprising") as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0327] It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0328] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the concept and principles of this application should be included within the protection scope of this application.

[0329] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention 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 protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. An operation and maintenance device, characterized by comprising: This includes an access module, a change agent, and a digital twin module; The access module is used to receive user intent, which is used to instruct network changes to the target network. The change agent is used to obtain multiple steps to realize the user's intent and the execution order of the multiple steps. The multiple steps include a first step and a second step. The first step is used to verify the change content of the network change, and the second step is used to execute the network change on the target network. The change agent is used to output a verification instruction to the digital twin module after determining the execution of the first step based on the execution order. The verification instruction is used to verify the change content of the network change. The digital twin module is used to respond to the verification command, obtain the verification result corresponding to the network change, and output it to the change agent; The modified agent is used to perform the second step based on the verification result.

2. The apparatus according to claim 1, characterized in that, The digital twin module is also used to obtain optimization suggestions for the network changes based on the verification results; The modified intelligent agent is also used to perform network optimization on the target network based on the optimization suggestions.

3. The apparatus according to claim 1, characterized in that, The digital twin module is also used to obtain optimization suggestions for the network changes based on the verification results; The access module is also used to output the optimization suggestions; The access module is further configured to receive a user's confirmation of the optimization suggestion, the confirmation result being used to indicate whether to optimize the target network according to the optimization suggestion; The modified agent is also used to perform network optimization on the target network based on the confirmation result and the optimization suggestions.

4. The apparatus of any one of claims 1 to 3, wherein, The access module is specifically used for: The system receives work orders sent by the work order system via the northbound interface; these work orders are used to indicate the user's intent. Alternatively... The user intent is received through a graphical user interface (GUI).

5. The apparatus of any one of claims 1 to 4, wherein, The modified intelligent agent is specifically used for: Send a task decomposition request to the device deploying the Large Language Model (LLM), the task decomposition request being used to request the determination of multiple steps to achieve the user intent and the execution order of the multiple steps; Receive the plurality of steps and the execution order of the plurality of steps sent by the device.

6. The apparatus of any one of claims 1 to 4, wherein, The device also includes an LLM; The modified intelligent agent is also used to parse the user intent and output the parsed user intent to the LLM; The LLM is used to obtain the multiple steps and the execution order of the multiple steps based on the parsed user intent; The modified intelligent agent is also used to obtain the plurality of steps and the execution order from the LLM.

7. An operation and maintenance device, characterized by It includes an access module, a fault intelligence agent, and a fault management module; The access module is used to receive user intents, which are used to instruct the handling of faults in the target network. The fault intelligence agent is used to output fault diagnosis instructions to the fault management module based on the user intent; The fault management module is used to respond to the fault diagnosis command, obtain a first diagnosis result and a first repair suggestion, and output them to the fault intelligent agent; The fault intelligence agent is used to obtain a first fault repair instruction based on the first diagnostic result and the first repair suggestion, and output it to the fault management module; The fault management module is used to repair the fault in response to the first fault repair command.

8. The apparatus of claim 7, wherein, The first fault repair instruction includes the fault ID, which corresponds to the first diagnostic result and the first repair suggestion.

9. The apparatus of claim 7 or 8, wherein, The fault-fault intelligent agent is also used for: Obtain the repair result fed back by the fault management module, the repair result being used to indicate that the fault repair failed or the fault was not completely repaired; Based on the repair results, at least one step for achieving the repair objective and the execution order of the at least one step are obtained; The at least one step is executed in the specified execution order to complete the fault repair.

10. The apparatus of claim 9, wherein, The fault-fault intelligent agent is specifically used for: Based on the repair results, the diagnostic results of the unrepaired faults and the repair objectives are determined; Send a task decomposition request to the device with a Large Language Model (LLM) deployed, the task decomposition request being used to request the determination of at least one step to achieve the repair objective and the execution order of the at least one step based on the diagnostic results of the unrepaired fault; Receive the at least one step and the execution order of the at least one step returned by the device.

11. The apparatus of claim 9, wherein, The device also includes an LLM; The fault agent is also specifically used to determine the diagnostic results of the unrepaired faults and the repair target based on the repair results, and output the diagnostic results of the unrepaired faults and the repair target to the LLM; The LLM is used to determine at least one step to achieve the repair objective and the execution order of the at least one step based on the diagnostic results of the unrepaired fault; The fault agent is also specifically used to obtain the at least one step and the execution order of the at least one step from the LLM.

12. The apparatus of any one of claims 7-11, wherein, The fault-fault intelligent agent is also used for, Based on the fault root cause indicated by the first diagnostic result, query historical operation and maintenance records to determine whether there is a target operation and maintenance record in the historical operation and maintenance records that caused the fault root cause. If the target maintenance record is found in the historical maintenance records, the LLM that provides inference services to the device is optimized based on the root cause of the fault and the target maintenance record.

13. The apparatus of any one of claims 7-12, wherein, The access module is specifically used for, The system receives work orders sent by the work order system via the northbound interface; these work orders are used to indicate the user's intent. Alternatively... The user intent is received through a graphical user interface (GUI).

14. The apparatus of any one of claims 7-13, wherein, The device also includes a digital twin module. The fault intelligence agent is also used to send a business analysis instruction to the digital twin module after receiving a fault event reported by the fault management module. The digital twin module is used to respond to the business analysis command, analyze the business affected by the fault events reported by the fault management module, and return business information of the affected business to the fault agent. The fault intelligence agent is also used to request the work order system to create a work order based on the fault events reported by the fault management module and the business information.

15. An operation and maintenance system, characterized by include: The system comprises an access module, a main intelligent agent, a changing intelligent agent as described in any one of claims 1 to 6, and a faulty intelligent agent as described in any one of claims 7 to 14; wherein, The access module is used to receive user intent and output the user intent to the main intelligent agent; The main intelligent agent is used to parse the user intent and obtain the task objective and task parameters; The master agent is used to determine that the user intention indicates to make network changes to the target network, and outputs the task objective and the task parameters to the change agent, and / or, the master agent is used to determine that the user intention indicates to handle faults in the target network, and outputs the task objective and the task parameters to the fault agent.

16. The system of claim 15, wherein, The change agent and the main agent are the same agent, and / or the faulty agent and the main agent are the same agent.

17. An operation and maintenance method, characterized by, include: Receive a user intent, which is used to instruct a network change to be made to the target network; The method obtains multiple steps to achieve the user intent and the execution order of the multiple steps, including a first step and a second step. The first step is used to verify the changes in the network change, and the second step is used to perform the network change on the target network. After determining the execution of the first step based on the execution order, the changes made to the network are verified to obtain the verification results; The second step is performed based on the verification results.

18. The method of claim 17, wherein, The method further includes: Based on the verification results, optimization suggestions for the network changes are obtained; Based on the optimization suggestions, network optimization is performed on the target network.

19. The method of claim 17, wherein, The method further includes: Based on the verification results, optimization suggestions for the network changes are obtained; Output the optimization suggestions; Receive user confirmation of the optimization suggestion, the confirmation result being used to indicate whether to optimize the target network according to the optimization suggestion; Based on the confirmation results and the optimization suggestions, the target network is optimized.

20. The method of any one of claims 17-19, wherein, The receiving of user intent includes: The system receives work orders sent by the work order system via the northbound interface; these work orders are used to indicate the user's intent. Alternatively... The user intent is received through a graphical user interface (GUI).

21. The method according to any one of claims 17 to 20, characterized in that, The steps for obtaining the user intent and the execution order of the steps include: Send a task decomposition request to the device deploying the Large Language Model (LLM), the task decomposition request being used to request the determination of multiple steps to achieve the user intent and the execution order of the multiple steps; Receive the plurality of steps and the execution order of the plurality of steps sent by the device.

22. The method of any one of claims 17-20, wherein, The method is executed by an operation and maintenance device, which includes an LLM; the step of obtaining multiple steps to realize the user intent and the execution order of the multiple steps includes: Analyze the user intent; The LLM is used to obtain the multiple steps and their execution order based on the parsed user intent.

23. An operation and maintenance method, characterized by, The method is applied to an operation and maintenance device, the operation and maintenance device including a fault management module, and includes: Receive user intent, which is used to instruct the handling of a fault in the target network; The fault management module obtains a first diagnostic result and a first repair suggestion based on the user intent, wherein the first diagnostic result is the diagnostic result of the fault, and the first repair suggestion is a suggestion to repair the fault; Based on the first diagnostic result and the first repair suggestion, the fault is repaired.

24. The method of claim 23, wherein, The method further includes: Obtain the repair result, which indicates that the fault repair failed or the fault was not completely repaired; Based on the repair results, at least one step for achieving the repair objective and the execution order of the at least one step are obtained; The at least one step is executed in the specified execution order to complete the fault repair.

25. The method of claim 24, wherein, The step of obtaining at least one step for achieving the repair objective and the execution order of the at least one step based on the repair result includes: Based on the repair results, the diagnostic results of the unrepaired faults and the repair objectives are determined; Send a task decomposition request to the device with a Large Language Model (LLM) deployed, the task decomposition request being used to request the determination of at least one step to achieve the repair objective and the execution order of the at least one step based on the diagnostic results of the unrepaired fault; Receive the at least one step and the execution order of the at least one step returned by the device.

26. The method of claim 24, wherein, The device further includes an LLM; the step of obtaining at least one step for achieving the repair objective based on the repair result and the execution order of the at least one step includes: Based on the repair results, the diagnostic results of the unrepaired faults and the repair objectives are determined; The LLM determines at least one step to achieve the repair objective and the execution order of the at least one step based on the diagnostic results of the unrepaired fault.

27. The method of any one of claims 23-26, wherein, The method further includes: Based on the fault root cause indicated by the first diagnostic result, query historical operation and maintenance records to determine whether there is a target operation and maintenance record in the historical operation and maintenance records that caused the fault root cause. If the target maintenance record is found in the historical maintenance records, the LLM that provides inference services for the maintenance device is optimized based on the root cause of the fault and the target maintenance record.

28. The method of any one of claims 23-27, wherein, The receiving of user intent includes: The system receives work orders sent by the work order system via the northbound interface; these work orders are used to indicate the user's intent. Alternatively... The user intent is received through a graphical user interface (GUI).

29. The method of any one of claims 23-28, wherein, The method further includes: After receiving a fault event reported by the fault management module, analyze the services affected by the fault event reported by the fault management module; Based on the fault event and the business information of the service, a work order is requested to be created.

30. An operation and maintenance method, characterized by, The method is applied to an operation and maintenance system, wherein the operation and maintenance system includes a change agent as described in any one of claims 1 to 6 and a fault agent as described in any one of claims 7 to 14; the method includes: Receive user intent; Parse the user intent to obtain the task objective and task parameters; After determining that the user intent indicates a network change to the target network, the task objective and the task parameters are output to the change agent, and the method described in any one of claims 17 to 22, excluding the method of receiving the user intent, is executed; and / or, after determining that the user intent indicates a fault in the target network, the task objective and the task parameters are output to the fault agent, and the method described in any one of claims 23 to 29, excluding the method of receiving the user intent, is executed.

Images