Wireless Network Quality Poor Analysis and Processing Methods, Devices and Media

Abstract

This disclosure provides a method, apparatus, and medium for analyzing and processing poor wireless network quality, relating to the field of network technology. The method includes: identifying the query intent regarding poor wireless network quality in a user's question; obtaining a number of poor-quality wireless network cells that need to be analyzed to answer the user's question; compiling a quality defect root cause diagnosis chain to answer the user's question, the quality defect root cause diagnosis chain including several diagnostic sub-tasks for each poor-quality wireless network cell; obtaining several diagnostic results from the several diagnostic sub-tasks, each diagnostic result including anomaly judgment, anomaly root cause, and processing suggestions for each diagnostic sub-task; obtaining a comprehensive quality defect root cause and comprehensive quality defect processing suggestions for the several poor-quality wireless network cells based on the several diagnostic results; and outputting an answer to the user's question based on the comprehensive quality defect root cause and comprehensive quality defect processing suggestions. This disclosure employs a large-scale intelligent agent model to provide a highly intelligent network optimization auxiliary tool.

Description

Technical Field

[0001] This disclosure relates at least to the field of network technology, and in particular to a method for analyzing and processing poor wireless network quality, a device for analyzing and processing poor wireless network quality, and a computer-readable storage medium. Background Technology

[0002] Current analyses of poor wireless network quality often rely on traditional data analysis experience and manual intervention by network optimization (RO) personnel. This results in insufficient intelligence in network optimization analysis, with the optimization level depending on the skill level of the optimization staff. Consequently, network optimization work is inefficient, inaccurate, and fails to meet the requirements of large-scale network optimization. Summary of the Invention

[0003] The technical problem to be solved by this disclosure is to address the above-mentioned shortcomings by providing a method, apparatus, and computer-readable storage medium for analyzing and processing poor wireless network quality, so as to solve the problem of how to improve the efficiency of analyzing and optimizing poor-quality cells through automation and intelligent methods.

[0004] In a first aspect, this disclosure provides a method for analyzing and processing poor wireless network quality, which is applied to an AI agent and includes utilizing a large network model:

[0005] Identify the user's inquiry intent regarding poor wireless network quality in the question, and obtain several poor wireless network quality cells that need to be analyzed to answer the user's question;

[0006] A quality poor root cause diagnostic chain is developed to answer user questions. The quality poor root cause diagnostic chain includes several diagnostic sub-tasks for each poor quality cell in the wireless network.

[0007] Obtain several diagnostic results from several diagnostic subtasks. Each diagnostic result includes the anomaly judgment, root cause of the anomaly, and handling suggestions for each diagnostic subtask.

[0008] Based on several diagnostic results, obtain the root causes and solutions for several poor-quality wireless network cells, and output answers to user questions based on the root causes and solutions.

[0009] Furthermore, identify the user's inquiry intent regarding poor wireless network quality, and obtain several poor-quality wireless network cells that need to be analyzed to answer the user's question, specifically including:

[0010] Receive user questions and extract the inquiry time, inquiry region, and inquiry category from the user questions using keywords;

[0011] If the inquiry category includes inquiries about wireless network services and / or metrics, determine whether there are any poor-quality wireless network cells in the inquiry area during the inquiry period;

[0012] If present, determine that the user's question includes an intent to inquire about poor wireless network quality, and obtain the identifiers of several poor wireless network quality cells in the inquiry area within the inquiry time and the real-time wireless network quality category.

[0013] Furthermore, determining whether there are poor-quality wireless network cells in the query area during the query period specifically includes:

[0014] Obtain the regional-level wireless network service indicators for the query area within the query period, and determine whether the query area within the query period is a poor wireless network quality area based on the regional-level wireless network service indicators, as well as the several real-time poor wireless network quality categories.

[0015] If the query area is a poor wireless network quality area, obtain the cell-level wireless network service indicators of each wireless network cell in the query area within the query time relative to the several real-time poor wireless network quality categories, and obtain several poor wireless network quality cells in the query area within the query time based on the cell-level wireless network service indicators.

[0016] Furthermore, the method also includes a pre-trained large network model, specifically including:

[0017] The API interface for collecting historical wireless network data, categories of poor historical wireless network quality, diagnostic work orders for poor historical wireless network quality, expert knowledge on poor wireless network quality diagnosis, diagnostic results for poor historical wireless network quality, and obtaining historical wireless network data.

[0018] The control network big model extracts the thought chain question-and-answer prompts from the diagnostic process in the historical poor wireless network quality diagnostic work orders. It combines historical wireless network data, historical poor wireless network quality categories, thought chain question-and-answer prompts, and wireless network poor quality diagnostic expert knowledge to output historical poor wireless network quality diagnostic results. The parameters of the network big model are then fine-tuned until the network big model accurately outputs historical poor wireless network quality diagnostic results.

[0019] Obtain the thought chain question-and-answer prompts corresponding to different historical wireless network quality poor categories and the wireless network API interfaces corresponding to abnormal historical wireless network data in the final network model.

[0020] Furthermore, a diagnostic chain for the root causes of poor quality is developed to answer user questions. This chain includes several diagnostic sub-tasks for each poor-quality cell in the wireless network, specifically including:

[0021] Based on the real-time wireless network quality poorness category of each poor wireless network quality cell, obtain the corresponding thought chain question and answer prompt words;

[0022] Based on the question-and-answer prompts in the mind chain, a root cause diagnosis chain for poor quality is developed, which includes several diagnostic sub-tasks for each poor-quality cell in the wireless network.

[0023] Determine the wireless network API interfaces that each diagnostic subtask needs to call.

[0024] Furthermore, among which:

[0025] Several diagnostic sub-tasks include at least one of the following: fault diagnosis, parameter diagnosis, coverage diagnosis, quality diagnosis, interference diagnosis, capacity diagnosis, and latent fault diagnosis;

[0026] The wireless network API interfaces include at least one of the following: base station alarm API interface, cell performance KPI indicator API interface, base station main control board API interface, cell CM configuration file API interface, cell performance KPI indicator API interface, MR indicator API interface, uplink interference diagnosis small model API interface, and cell B domain service traffic indicator API interface.

[0027] Furthermore, obtain several diagnostic results from several diagnostic subtasks, specifically including:

[0028] Several diagnostic subtasks are processed sequentially according to the order in the poor quality root cause diagnostic chain;

[0029] Call the wireless network API interface corresponding to each diagnostic subtask to obtain the corresponding real-time wireless network data;

[0030] By combining real-time wireless network data, real-time wireless network quality poorness categories, thought chain question-and-answer prompts, and wireless network quality poorness diagnosis expert knowledge, the system outputs real-time wireless network quality poorness diagnosis results for each diagnostic subtask.

[0031] Furthermore, based on several diagnostic results, the root causes and solutions for several poor-quality wireless network cells are obtained. Based on these root causes and solutions, answers to user questions are output, specifically including:

[0032] Based on the sequence of the poor quality root cause diagnosis chain, the abnormal root cause and processing suggestions of the diagnosis subtask are integrated into the diagnosis results. The voice and / or text results of the poor quality root cause and poor quality processing suggestions of several wireless network poor quality cells are output.

[0033] Several poor-quality wireless network cells are displayed on a map, and their root causes are marked. Based on the suggestions for handling poor quality, page instructions for fixing the root causes of poor quality are generated and executed automatically or when triggered by the user.

[0034] Secondly, this disclosure provides a wireless network quality poor analysis and processing device, the device including an AI Agent, the AI ​​Agent including a large network model, the large network model including:

[0035] The intent recognition module is used to identify the user's query intent regarding poor wireless network quality and to obtain several poor wireless network quality cells that need to be analyzed in order to answer the user's question.

[0036] The chained orchestration module, connected to the intent recognition module, is used to compile a poor quality root cause diagnosis chain to answer user questions. The poor quality root cause diagnosis chain includes several diagnostic sub-tasks for each poor quality cell in the wireless network.

[0037] The diagnostic analysis module, connected to the chained orchestration module, is used to obtain several diagnostic results from several diagnostic subtasks. Each diagnostic result includes the anomaly judgment, root cause of the anomaly, and handling suggestions for each diagnostic subtask.

[0038] The summary output module, connected to the diagnostic analysis module, is used to obtain the root causes and handling suggestions for several poor-quality wireless network cells based on several diagnostic results, and output answers to user questions based on the root causes and handling suggestions.

[0039] Thirdly, this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the wireless network quality poor analysis and processing method described above.

[0040] This disclosure provides a method, apparatus, and computer-readable storage medium for analyzing and processing poor wireless network quality. It employs a large-scale intelligent agent model to provide a highly intelligent network optimization auxiliary tool. By recognizing the user's problem intent, it initiates root cause diagnosis of poor wireless network quality. By compiling a root cause diagnosis chain, it decomposes the diagnostic tasks and then synthesizes the diagnostic results to obtain the root causes of poor wireless network quality and processing suggestions. This tool can be used to assist network optimization engineers in completing network optimization work and improve network optimization efficiency. Attached Figure Description

[0041] Figure 1 This is a flowchart of a wireless network quality poor analysis and processing method according to an embodiment of the present disclosure;

[0042] Figure 2 This is a schematic diagram of the structure of a wireless network quality poor analysis and processing device according to an embodiment of the present disclosure;

[0043] Figure 3 This is an architecture diagram of a wireless network quality poor analysis and processing system according to an embodiment of this disclosure;

[0044] Figure 4 This is a flowchart of another wireless network quality poor analysis and processing method according to an embodiment of the present disclosure;

[0045] Figure 5 This is an example diagram of a poor quality root cause diagnostic chain according to an embodiment of this disclosure;

[0046] Figure 6 These are example diagrams showing the alarm diagnosis and analysis results of two embodiments of this disclosure;

[0047] Figure 7 These are example diagrams showing the diagnostic analysis results of two parameters according to embodiments of this disclosure;

[0048] Figure 8 These are example diagrams showing the results of five types of coverage diagnostic analysis according to embodiments of this disclosure;

[0049] Figure 9 These are example diagrams showing the results of three quality diagnostic analyses according to embodiments of this disclosure;

[0050] Figure 10 This is an example 1 of a cell hourly PRB-level waveform diagram according to an embodiment of this disclosure;

[0051] Figure 11 This is an example 2 of a cell hourly PRB-level waveform diagram according to an embodiment of this disclosure;

[0052] Figure 12 This is an example 3 of a cell hourly PRB-level waveform diagram according to an embodiment of this disclosure;

[0053] Figure 13 Example 4 is a cell hourly PRB-level waveform diagram according to an embodiment of this disclosure;

[0054] Figure 14 Example 5 is a cell-level hourly PRB-level waveform diagram according to an embodiment of this disclosure;

[0055] Figure 15 These are example diagrams showing the results of six types of interference diagnostic analysis according to embodiments of this disclosure;

[0056] Figure 16 These are example diagrams showing the results of four capacity diagnostic analyses according to embodiments of this disclosure;

[0057] Figure 17 These are example diagrams showing the results of diagnostic analysis of two types of latent faults according to embodiments of this disclosure;

[0058] Figure 18 This is a flowchart illustrating the execution method of the execution body according to an embodiment of this disclosure;

[0059] Figure 19 This is a schematic diagram of a page illustrating a quality difference analysis auxiliary tool according to an embodiment of this disclosure;

[0060] Figure 20 This is a page example diagram of a quality difference analysis auxiliary tool according to an embodiment of this disclosure. Detailed Implementation

[0061] To enable those skilled in the art to better understand the technical solutions of this disclosure, the embodiments of this disclosure will be further described in detail below with reference to the accompanying drawings.

[0062] It is understood that the specific embodiments and accompanying drawings described herein are for illustrative purposes only and are not intended to limit the scope of this disclosure.

[0063] It is understood that, without conflict, the various embodiments and features in the embodiments of this disclosure can be combined with each other.

[0064] It is understood that, for ease of description, only the parts relevant to this disclosure are shown in the accompanying drawings, while parts unrelated to this disclosure are not shown in the drawings.

[0065] It is understood that each module or unit involved in the embodiments of this disclosure may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple modules or units may be integrated into one entity structure.

[0066] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this disclosure may occur in a different order than that marked in the accompanying drawings.

[0067] It is understood that the flowcharts and block diagrams of this disclosure illustrate the architecture, functions, and operations of possible implementations of systems, apparatuses, devices, and methods according to various embodiments of this disclosure. Each block in a flowchart or block diagram may represent a module, unit, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagrams and flowcharts may be implemented using hardware-based devices to implement the specified function, or using a combination of hardware and computer instructions.

[0068] It is understood that the modules and units involved in the embodiments of this disclosure can be implemented by software or by hardware, for example, the modules and units can be located in a processor.

[0069] Example 1:

[0070] like Figure 1 As shown, this disclosure provides a method for analyzing and processing poor wireless network quality. This method is applied to an AI agent and includes utilizing a large network model.

[0071] S1. Identify the user's inquiry intent regarding poor wireless network quality in the question, and obtain several poor wireless network quality cells that need to be analyzed to answer the user's question;

[0072] S2. Compile a diagnostic chain for the root causes of poor quality to answer user questions. The diagnostic chain for the root causes of poor quality includes several diagnostic sub-tasks for each poor-quality cell in the wireless network.

[0073] S3. Obtain several diagnostic results from several diagnostic sub-tasks. Each diagnostic result includes the anomaly judgment, root cause of the anomaly, and handling suggestions for each diagnostic sub-task.

[0074] S4. Based on several diagnostic results, obtain the root causes and solutions for several poor-quality wireless network cells, and output answers to user questions based on the root causes and solutions.

[0075] In this embodiment, a highly intelligent network optimization auxiliary tool is provided using a large-scale intelligent agent model. By recognizing the user's intent to address the problem, it initiates a root cause diagnosis of poor wireless network quality. Through the development of a root cause diagnosis chain, the diagnostic task is decomposed, and the diagnostic results are synthesized to obtain the root causes of poor wireless network quality and corresponding solutions. This tool can assist network optimization engineers in completing network optimization work, improving network optimization efficiency. A corresponding device is described below. Figure 2 As shown, it includes an intent recognition module 1 for performing step S2, a chain arrangement module 2 for performing step S2, a diagnostic analysis module 3 for performing step S3, and an inductive output module 4 for performing step S4.

[0076] Specifically, this invention provides a method and apparatus for handling poor-quality voice service cells in wireless networks based on an AI Agent. The AI ​​Agent refers to an intelligent agent, a system driven by a large language model, possessing the ability to autonomously understand, perceive, plan, remember, and use tools, and can automatically execute complex tasks. This embodiment applies the AI ​​Agent to locate and analyze poor-quality cells in a wireless network and proposes suggestions for handling and repair. A poor-quality cell refers to a cell with one or more quality issues in its network communication. These issues involve multiple aspects, such as voice service connection rate, call drop rate, packet loss rate, data service disconnection rate, access success rate, and user-perceived speed. The network large model in this embodiment, based on the large language model in the AI ​​Agent, is specially pre-trained and suitable for analyzing poor-quality cells in wireless networks, locating the root causes of poor quality, and providing suggestions for handling these root causes. In other words, the AI ​​Agent is an intelligent agent based on a large network model, which is a large language model trained according to wireless network problems.

[0077] Currently, the identification of problem types in poor-quality cells mainly adopts traditional network optimization (or network optimization) methods. Specifically, this involves first collecting key performance indicators (KPIs) for the cell, then network optimization staff using their knowledge and experience to set thresholds for each KPI. Based on these thresholds and the cell's overall KPIs, the type of poor-quality problem is determined. Then, network optimization staff analyze the data, manually troubleshooting various network issues such as coverage, interference, and capacity, and using experience to conduct root cause analysis and develop optimization solutions to improve network performance. However, current practices in wireless network problem root cause analysis largely rely on manual experience combined with various software tools. This approach presents several problems: a shortage of personnel with specialized skills, resulting in a bottleneck in optimization; complex network problems with numerous causes, making problem localization difficult; repetitive problem handling, poor timeliness, and long processing cycles; limitations in network problem discovery, unclear identification of the true pain points, high manpower costs, and low efficiency.

[0078] With the continuous advancement and development of the mobile communication network industry, high-speed and high-quality network applications are placing higher demands on network operations. Network operators aim to "detect problems before users do." Beyond the conventional method of manually analyzing cell KPIs and periodically identifying poor-quality cells according to manually defined rules, designing and applying machine learning-guided methods for locating and analyzing poor-quality cells in mobile communication networks is beneficial for identifying network quality issues. It allows for the prediction of the degree of network quality degradation and whether it will affect user experience. Leveraging machine learning to comprehensively analyze and locate poor-quality cells in mobile communication networks, enabling timely and proactive handling of network problems, and providing users with a better service experience, has significant practical value.

[0079] Therefore, this embodiment proposes the concept of an intelligent AI Agent, which constructs an intelligent agent for analyzing and processing poor wireless quality cells based on a large model AI Agent architecture. Frontline network optimization engineers raise actual problems with poor wireless quality cells in natural language. After the Agent reads the problem, the LLM (Large Language Model), acting as the central component, uses long short-term memory to plan the problem. After understanding the intent of analyzing and processing poor wireless quality cells, the Agent decomposes the task objectives and coordinates the execution of a set of tools, including real-time data acquisition of various key indicators, expert knowledge base cases, and decision-making small models. Then, these tools are called in sequence to obtain the root cause analysis results and intelligent diagnostic solutions for poor quality cells. After integrating all the information, the Agent summarizes and considers the results to generate the final answer, which is then returned to the network optimization engineer. This ultimately constructs a closed-loop capability for analyzing and processing poor wireless quality cells based on natural language input, improving the work efficiency of frontline network optimization engineers and reducing network operation and maintenance costs.

[0080] The overall system architecture is as follows: Figure 3 As shown, the network optimization expert agent categorizes and diagnoses the results to train the large language model in the diagnostic agent, making it the large network model in this embodiment. The diagnostic agent connects to wireless network tools and can access data such as wireless network metrics, logs, configurations, and reports. The diagnostic agent has memory and planning capabilities, can decompose sub-goals through thought chains, and has the ability to automatically call tools to execute instructions. In use, the user raises the actual wireless network voice service quality problem in natural language. After reading the problem, the AI ​​Agent (diagnostic agent) uses long short-term memory to identify and plan the intent of the problem. The generated plan includes which tools need to be called, and then calls these tools in sequence to obtain the results (content and execution instructions). After integrating all the information, it summarizes them into two types of instructions: visual instructions and page instructions. The executor executes the instructions and finally presents the complete answer to the user. Taking the analysis of poor wireless voice service quality as an example, the overall design process of the solution is as follows: Figure 4 As shown, this will be explained in detail later. Figure 4 Each step in the process.

[0081] In one embodiment, S1, identifying the user's inquiry intent regarding poor wireless network quality, and obtaining a number of poor-quality wireless network cells that need to be analyzed to answer the user's question, specifically including:

[0082] Receive user questions and extract the inquiry time, inquiry region, and inquiry category from the user questions using keywords;

[0083] If the inquiry category includes inquiries about wireless network services and / or metrics, determine whether there are any poor-quality wireless network cells in the inquiry area during the inquiry period;

[0084] If present, determine that the user's question includes an intent to inquire about poor wireless network quality, and obtain the identifiers of several poor wireless network quality cells in the inquiry area within the inquiry time and the real-time wireless network quality category.

[0085] In this embodiment, as Figure 4 As shown, S101: Using the network big model as the interaction entry point, the user's wireless voice service quality problem in the cell is input into the dialog box.

[0086] The problem of poor quality wireless voice service in a cell that front-line users need to analyze and process can be input into the dialog box through natural language interaction. After being decomposed by the cell-level voice service perception index, if a certain quality poor definition condition is met, the big model will perform further quality poor analysis and enter S102: After the network big model submits the user's problem to the AI ​​Agent for reading, it uses the plug-in tool to extract the intent parameters and then submits them to the network big model for intent recognition.

[0087] After receiving a user's question, the network big data model submits it to the AI ​​Agent. The Agent then calls the "Capability Orchestration Engine" plugin to perform intent recognition and parameter extraction. By identifying the user's question intent category (such as indicator query, quality difference analysis, etc.), the key parameters in the question are extracted, including time, location, and indicator type.

[0088] Intent recognition and parameter extraction are achieved by calling plugin methods. This is primarily done by defining tool functionality through filling in the operationId (unique identifier), summary, and description, and defining the usage of the tool by filling in the name, namedescription, required, and default values ​​for each parameter under parameters. For example, the "SuiXinCe" indicator query (a system developed based on this disclosed method) is divided into two fine-grained intents: road indicators (geographically defined areas) and community indicators. The system extracts two parameters: road + indicator and poor-quality community name + indicator, respectively.

[0089] The results of the plugin parameter extraction are parsed. Enumerable parameters can be accurately extracted by configuring a thesaurus in the dictionary, configuring regular expressions, contextual parameter extraction rules, etc., and configuring them in the parameter pattern field.

[0090] Commonly used parameter types can be extracted relatively accurately using various built-in Named Entity Recognition (NER) models. Typical examples include time / time period, address, person's name, organization name, mobile phone number, email address, etc. If the parameter description contains entity trigger words, the corresponding entity extraction will be triggered.

[0091] Based on the parameters configured in the plugin, the large model extracts parameters by grouping prompts (such as extracting the "city" field) and assembles them into a request JSON (JavaScript Object Notation) format that can call services. The large model then performs intent recognition. After completion, proceed to step 103.

[0092] Here is an example of how intent recognition is used to obtain data:

[0093] type: string

[0094] title: "Indicators"

[0095] -in:query

[0096] name: road

[0097] required: True

[0098] Description: Address, Road

[0099] schema:

[0100] type: string

[0101] default: "None"

[0102] responses:

[0103] '200'

[0104] Description: Report found successfully

[0105] paths:

[0106] / communityIndexSearch:

[0107] get:

[0108] operationId: Querying metrics in the SuiXinCe system

[0109] Summary: Querying Indicators in the SuiXinCe system

[0110] Description: Querying Community Indicators using the Casual Measurement System

[0111] parameters:

[0112] -in:query

[0113] name: Index

[0114] required: True

[0115] description:|

[0116] Operator base station indicators

[0117] schema:

[0118] default: "None"

[0119] type: string

[0120] title: "Indicators"

[0121] -in:query

[0122] name: community

[0123] required: True

[0124] description:|

[0125] Address, neighborhood

[0126] schema:

[0127] type: string

[0128] default: "None"

[0129] responses:

[0130] '200':

[0131] Description: Report found successfully

[0132] In one implementation, determining whether there are poor-quality wireless network cells in the query area during the query time specifically includes:

[0133] Obtain the regional-level wireless network service indicators for the query area within the query period, and determine whether the query area within the query period is a poor wireless network quality area based on the regional-level wireless network service indicators, as well as the several real-time poor wireless network quality categories.

[0134] If the query area is a poor wireless network quality area, obtain the cell-level wireless network service indicators of each wireless network cell in the query area within the query time relative to the several real-time poor wireless network quality categories, and obtain several poor wireless network quality cells in the query area within the query time based on the cell-level wireless network service indicators.

[0135] In this embodiment, the relevant indicator types (network quality poor categories) and the definition of quality poorness for wireless voice services are as follows:

[0136] Table 1. Examples of poor wireless network quality categories and judgment criteria.

[0137]

[0138]

[0139] The table includes voice service perception indicators for all network standards across a given region (e.g., provincial or municipal administrative regions). While this is sufficient for grasping the overall network perception, further design and breakdown are needed to decompose the indicators into cell-level voice perception indicators for different network standards. After analyzing the components of the overall indicators, further breakdown into cell-level voice service perception indicators is possible. After decomposing the cell-level voice service perception indicators, users can ask the network model dialog box about poor-quality cells based on the definitions of different indicator categories, such as "connection success rate," "fast connection," "clear hearing," and "no dropped calls." The model's response will vary depending on the specific indicator type asked. For example, asking about the "connection success rate" indicator will result in a "connection success rate" response, as in the following query: "What are the voice service perception indicators for **City** District on July 19th?" The voice perception status includes the statistical results for "connection success rate," "fast connection," "clear hearing," and "no dropped calls." If any indicator meets the definition of poor quality, the model will perform further quality difference analysis.

[0140] In one embodiment, the method further includes a pre-trained large network model, specifically comprising:

[0141] The API interface for collecting historical wireless network data, categories of poor historical wireless network quality, diagnostic work orders for poor historical wireless network quality, expert knowledge on poor wireless network quality diagnosis, diagnostic results for poor historical wireless network quality, and obtaining historical wireless network data.

[0142] The control network big model extracts the thought chain question-and-answer prompts from the diagnostic process in the historical poor wireless network quality diagnostic work orders. It combines historical wireless network data, historical poor wireless network quality categories, thought chain question-and-answer prompts, and wireless network poor quality diagnostic expert knowledge to output historical poor wireless network quality diagnostic results. The parameters of the network big model are then fine-tuned until the network big model accurately outputs historical poor wireless network quality diagnostic results.

[0143] Obtain the thought chain question-and-answer prompts corresponding to different historical wireless network quality poor categories and the wireless network API interfaces corresponding to abnormal historical wireless network data in the final network model.

[0144] In this embodiment, the large network model used is a large language model trained and fine-tuned for the quality difference analysis task, that is, the thinking chain ability of the large network model is mainly achieved through incremental pre-training and SFT (Supervised Fine-Tuning) instruction fine-tuning.

[0145] Incremental pre-training: New knowledge is learned from a large-scale "unlabeled" text corpus through training. More than ten types of first-line business corpora and data, including wireless network air interface side, core network side, base station transmission side, bearer network, IP (Internet Protocol) network, backbone network, complaint handling, road testing, service quality analysis, network maintenance, etc., are collected and organized. Text purification is performed, PPL (Perplexity) is calculated to filter low-quality text, forming a network private professional knowledge dataset. The basic model is then incrementally pre-trained to infuse network expert knowledge.

[0146] SFT instruction fine-tuning: For the specific task of analyzing poor voice service quality cells, the system cleans and integrates labeled data such as voice service quality poor quality cell diagnosis work orders, voice service fault diagnosis knowledge graphs, and voice service performance indicators (KPIs) and perception indicators (KQIs) into specialized private domain data (network private professional knowledge datasets) for the voice service quality poor quality cell analysis process. This includes the responses to voice service diagnosis work orders, forming a structured voice service quality poor quality diagnosis process text. Subsequently, this text is used in conjunction with a large model and Prompt Engineering to form a thought chain capability. Based on intent understanding, the task is decomposed into sub-objectives, enabling the large model to possess ReAct-Agent capabilities for analyzing, diagnosing, perceiving, and making flexible decisions regarding voice service quality poor quality cell issues.

[0147] More specifically, the following empirical knowledge is used to design large-scale network models:

[0148] I. Experience in judging and handling poor-quality residential areas:

[0149] 1. Approach to handling poor-quality residential areas

[0150] First, define relevant indicators and design KPI monitoring templates on the network management system according to the assessment requirements. Then, filter out problematic cells based on call statistics data. Next, classify and handle different problems, track and record the process, and track and compare the results after the process is completed. The loop can only be closed after the problem is solved.

[0151] In LTE (Long Term Evolution) networks, the common approach to handling poor-quality cells involves addressing the following six categories. In daily operations, priority is given to voice / data service performance analysis, resource assessment, network structure analysis, and neighbor cell parameter verification, as shown in Table 2 below:

[0152] Table 2 Examples of Poor Quality Community Analysis and Processing Types

[0153]

[0154]

[0155] 2. Suggested thresholds for judging poor-quality residential areas:

[0156] 2.1) RRC (Radio Resource Control) establishment failure: The number of RRC connection establishment failures is greater than 50, and the RRC connection establishment success rate is less than 95%;

[0157] 2.2) E-RAB (Evolved Radio Access Bearer) establishment failure: The number of E-RAB establishment failures is greater than 50, and the E-RAB establishment success rate is less than 95%;

[0158] 2.3) Drop rate: If the number of abnormal releases of the UE Context (User Equipment Context) is greater than 50, the drop rate is greater than 5%.

[0159] 2.4) Handover success rate: The number of cell handover failures is greater than 300, and the handover success rate is less than 80%;

[0160] 2.5) Capacity Resources: Sites involved in key areas.

[0161] Condition 1: The average utilization rate of downlink PRB (Physical Resource Block) is greater than 50%, the average number of effective RRC connections is greater than 30, and the downlink busy-hour throughput of the cell is greater than 5G (gigabytes, GB).

[0162] Condition 2: The average uplink PRB utilization is greater than 50%, the average number of effective RRC connections is greater than 30, and the cell uplink busy-hour throughput is greater than 1 G (gigabytes, GB).

[0163] Condition 3: The maximum number of valid RRC connections is greater than 200;

[0164] Note: Take the average data of the busiest time of the system in the community over 7 days, and it is acceptable if any one of the conditions is met.

[0165] 3. Suggestions for parameter verification in poor-quality residential areas:

[0166] Table 3. Parameter Verification Table for Poor-Quality Communities

[0167]

[0168]

[0169] 4. Problem identification approach and steps in poor-quality residential communities:

[0170] Poor-quality cells typically fall into three main categories: radio-side parameter configuration issues, core network-side configuration issues, and channel environment influences. Therefore, when encountering a problematic cell, the following steps can be generally followed for troubleshooting.

[0171] 4.1) Confirm whether the network-wide indicators have deteriorated. If the network-wide indicators have deteriorated, it is necessary to check whether there are any network changes or upgrades in the operation and alarms.

[0172] 4.2) If the indicators of some sites deteriorate, affecting the overall network indicators, it is necessary to find the TOP poor quality cells (the worst quality cells).

[0173] 4.3) Query the top cells (the worst quality cells) with low RRC connection establishment success rate, low ERAB establishment success rate, low handover success rate, and high drop rate, and the time periods in which the top cells are most frequently affected (the time periods in which the poor quality occurs most frequently).

[0174] 4.4) Check the alarms of the TOP cell site, check the status of the board, the status of the RRU (Remote Radio Unit), the cell operation status, and whether the OMC (Operation & Management Center) operation configuration is normal.

[0175] 4.5) Extract CHR logs (log files reflecting problems from base stations), analyze the channel quality and SRS (Sounding Reference Signal) SINR (Signal to Interference plus Noise Ratio) during access to see if they are poor (weak coverage), and whether there are TOP users (users with the worst SINR).

[0176] 4.6) Perform targeted standard signaling tracing and interference detection analysis on TOP cell sites. If no anomalies are found in the standard signaling and interference detection, return the one-click logs, standard port tracing, and interference detection results to the developers for analysis.

[0177] 4.7) Based on the analysis results of all the above data, front-line network optimization engineers will analyze and eliminate each problem one by one, formulate optimization solutions based on expert experience, and then arrange RF optimization personnel and tower engineers to implement the optimization solutions until the problem of poor quality TOP cells is finally resolved.

[0178] II. Experience in designing machine learning algorithms:

[0179] 1. Algorithm level

[0180] Machine learning-driven localization of poor-quality cells in mobile communication networks requires, at the algorithmic level, integration of network service perception KQI data with comprehensive analysis of service perception profiles. Machine learning-driven algorithms effectively improve the accuracy of these profiles, constructing a machine learning-driven system for locating poor-quality cells and providing comprehensive user perception assessment and analysis. User profiles are created using quantitative data such as telephone follow-ups, user experience, and network satisfaction, and iteratively optimized. This process gradually identifies user groups and poor-quality content, further optimizing the location of poor-quality cells and analyzing the root causes of poor user satisfaction, ultimately providing optimization solutions for these cells. Machine learning pushes the analysis results to network maintenance units and integrates with network data analysis, including network performance indicators, network complaint data, coverage and drive test quality data, equipment failure rates, and impact duration, facilitating the mapping of basic customer perception elements and network elements.

[0181] 1.1) Business perception-related feature profile

[0182] The characteristic profile of service perception is mainly based on service models and time models. Mobile communication network services mainly include streaming media, web browsing, and instant messaging. Streaming media services primarily include video and games. Poor perception scenarios mainly include inability to access the internet, video buffering, game buffering, and slow webpage loading, which have the highest frequency of occurrence in current network complaints, accounting for approximately 90% of all complaints. Different services often correspond to different perception factors W. The time model implements hourly quantitative comprehensive scoring of user perception at different stages of the internet user's service process to accurately describe the specific situation of user perception.

[0183] 1.2) Basic Quantization Algorithm for Mobile Communication Network Sensing Based on Machine Learning

[0184] By conducting correlation analysis on user sample data through methods such as online KQI and online surveys, and using machine learning as the basic algorithm to effectively construct the indicator set, the user business perception coupling is realized, which leads to the initial formation of the profile model. Data verification analysis and model optimization are carried out to finally form a complete perception profile model, enabling quantitative assessment and effective identification of root causes of problems under customer perception.

[0185] 2. Identify users with poor quality.

[0186] 2.1) Identify poor-quality services

[0187] For business scenarios such as game lag, video lag, inability to access the internet, and slow webpage loading, perception indicators are determined separately to quantitatively define poor-quality services. For services related to inability to access the internet, control plane indicators are used for rapid definition. For video lag-related perception-level services, corresponding algorithms are introduced manually; for example, playback lag caused by insufficient data loading rate in the client buffer contains many perception indicators. Guided by logistic regression machine learning, the thresholds output by the iterative algorithm are calibrated, and combined with these thresholds, service identification is performed based on user perception. For example, if the actual number of video lags is 0.3 times / minute, the actual video playback waiting time is more than 5 seconds, and the total video lag time accounts for 30%, it can be determined that a user has experienced a poor user experience.

[0188] 2.2) User Perception Rating Model

[0189] Based on the basic model of perceived quality quantification for wireless internet access, the actual number of perceived differences experienced by current network users per unit time is obtained. Different dimensions of scoring are applied to different types of services with varying quality, resulting in the final user perception score. The formula is as follows:

[0190] S = ∑(K1W1 + K2W2 + K3W3)

[0191] S represents the user perception score; K1 represents the web browsing service score, and W1 represents the weight of the web browsing service; K2 represents the streaming media service score, and W2 represents the weight of the streaming media service; K3 represents the instant messaging service score, and W3 represents the instant messaging service weight.

[0192] Statistical analysis reveals that user perception varies, with most users falling into an intermediate state—meaning average or good perception—which aligns with a normal or chi-square distribution. In this typical distribution pattern, the focus is on the probability distribution. The horizontal axis represents the total number of failures per user across various scenarios at the hourly level, while the vertical axis represents the actual percentage of users corresponding to each failure. The vertical axis is a one-dimensional variable X, representing the probability of the total number of failures at the hourly level. By analyzing the probability density function curve of the random variable X, we can see that the number of failures can be divided into different intervals, each corresponding to a different user perception score. We can project user scores onto five different intervals to obtain the perception scores of current users. For example, we can filter and output users with perception scores below 3 as having poor perception quality.

[0193] 3. Identifying poor-quality residential areas

[0194] 3.1) Basic Model for Community Perception Scoring

[0195] By combining the number of poor-quality services received from users, and aggregating the users' frequently visited communities, and inputting the actual number of poor-quality services received by different users in each community, we can obtain the actual number of perceived poor services received by each user and the total number of such services. This allows us to understand that the proportion of users with perceived poor service is higher than X (users with perceived poor service). Statistical analysis of the number of users with perceived poor service Ki and the total number of users Mi in each community yields the proportion of users with perceived poor service as Zi = Ki / Mi.

[0196] 3.2) The proportion of users with poor perception can be divided into five different intervals.

[0197] The perception scores of users in each corresponding interval differ. Based on the perception algorithm, the cell score is effectively mapped to 5 different intervals to obtain the cell score, that is, 5 points is the best perception and 0 points is the worst perception.

[0198] 3.3) Identifying poor-quality residential areas

[0199] Based on this model, cell scores are obtained, and cells with low perception scores below 3 are filtered out as poor-quality cells.

[0200] 4. Identify the root causes of poor-quality communities and develop solutions.

[0201] Network quality and user experience are interdependent. Evaluating user experience can be comprehensively assessed based on factors such as network availability, stable connection speed, and high data rate. When a cell exhibits issues like low access speed, high dropout rate, or low data rate, it is considered a poor-quality cell negatively impacting user experience. While these poor-quality cells can be identified through metrics like dropout rate, wireless access success rate, and data rate, the diverse and often multifaceted causes affecting user experience make pinpointing the root causes of poor-quality cells extremely difficult for frontline personnel. Currently, the primary approach relies on expert experience, categorizing network problems into types such as coverage, interference, capacity, and faults. This is combined with data from Configuration Management (CM), Performance Management (PM), and Measurement Reports (MR) to develop root cause analysis algorithms for identifying the root causes of poor-quality cells.

[0202] 4.1) Coverage-based root cause localization algorithm

[0203] Wireless network coverage issues are caused by unreasonable network coverage. In general, in macro base station scenarios, network coverage problems can be divided into weak coverage, over-coverage, and overlapping coverage. Overlapping coverage and weak coverage problems can be located by jointly using indicators such as RSRP (Reference Signal Received Power), TA (Time Advanced), and overlapping coverage rate.

[0204] ① Overcoverage Root Cause Analysis

[0205] The large-scale deployment of 4G (fourth-generation mobile communication technology) networks has matured, but the coverage areas of planned sites vary across different scenarios, such as urban areas, suburbs / counties, and towns / rural areas. Urban sites are densely packed, suburban / county sites have larger spacing, and town / rural sites are planned for wide coverage. Therefore, when developing root cause analysis algorithms, different TA (Target Acquisition) thresholds need to be set according to different coverage scenarios. Urban sites are generally planned to cover within 1km. Considering the differences in the wireless environment within urban areas, a TA > 1km ratio > 25% is used as a prerequisite for determining over-coverage in urban areas. Suburban / county sites, due to their larger spacing, should not have excessively long coverage areas, but also not too short. A TA > 2.5km ratio > 25% is used as a prerequisite for determining over-coverage in suburban / county areas. While town / rural sites have wider coverage, considering wireless propagation loss—signal attenuation increases with distance and signal penetration weakens—the coverage distance should not be too wide. A TA > 3.5km ratio > 25% is used as a prerequisite for determining over-coverage in town / rural areas.

[0206] ② Overcoverage Root Cause Analysis

[0207] Coverage too close refers to signal coverage being significantly below the planned coverage area. Examples include excessive antenna downtilt angle in poor-quality cells, obstructions in the coverage direction, and hidden faults in the antenna feeder system. This can be comprehensively assessed using metrics such as TA (Target Aspect Ratio) and RSRP (Recovery Support Ratio). Using a single metric to determine the root cause of poor signal quality has low accuracy. Therefore, by combining metrics such as TA and MR (Mean Mitigation Ratio) with factors like inter-cell spacing and average cell coverage distance in different scenarios, root cause localization algorithms can be developed for weak coverage, overlapping coverage, over-coverage, and coverage too close, as shown in the table below.

[0208] Table 4. Criteria for Judging Coverage Issues

[0209]

[0210] ③ Optimize solution output

[0211] For coverage issues such as weak or excessive coverage of macro base stations, assuming the base station and antenna system are functioning normally and the parameters are set reasonably, there are generally five solutions: adjusting antenna height, adjusting antenna downtilt and azimuth angles, adjusting RS (Reference Signal) power, relocating the site, and adding RRUs. Among these, adjusting antenna downtilt and azimuth angles is the preferred solution.

[0212] 4.2) Interference-type root cause localization algorithm

[0213] Wireless network interference problems generally include external interference and internal interference. In the root cause algorithm proposed in this paper, interference problems are identified by using the average interference noise power per PRB, which is an indicator of interference intensity.

[0214] ① External interference

[0215] Generally referred to as external interference, it is caused by external interference sources. External interference is continuous and persistent. When judging external interference, it is necessary to exclude situations where interference increases during the day due to factors such as user activity. Generally, the interference index at 03:00, the off-peak time for business, is considered for evaluation.

[0216] ②Interference within the system

[0217] This refers to interference caused by co-channel interference within the system, GPS (Global Positioning System) malfunctions, data configuration errors, etc. The time period for interference within the system is not fixed and is greatly affected by factors such as user behavior; generally, interference indicators for the entire day are considered. The root cause localization algorithms for external and internal system interference are shown in the table below:

[0218] Table 5. Basis for Locating Interference Problems

[0219]

[0220] ③ Optimize solution output

[0221] For interference-related issues, assuming the base station and antenna system are functioning normally and the parameters are set appropriately, there are generally five solutions: troubleshooting external interference sources, adjusting antenna height, adjusting antenna downtilt and azimuth angles, and adjusting RS power. Among these, troubleshooting external interference sources should be given priority.

[0222] 4.3) Root Cause Localization Algorithm for Poor Quality

[0223] Wireless network quality indicators directly characterize network quality. For example, CQI (Channel Quality Indicator) represents channel quality, and MCS (Modulation and Coding Scheme) represents resource scheduling. In macrocell scenarios, poor network quality is generally caused by weak coverage, over-coverage, and overlapping coverage. In root cause analysis based on expert experience, CQI, MCS, and TA (Transmission and Coding Scheme) indicators can be jointly used to pinpoint quality issues.

[0224] ① Quality difference analysis based on coverage type

[0225] For poor-quality issues, the coverage decision conditions for urban, suburban / county, and township / rural sites are consistent with the coverage analysis process. In the root cause localization algorithm for poor-quality cells, CQI, MCS, TA index, average cell coverage distance, and average inter-site spacing under different scenarios are combined to locate the root causes of poor-quality cells, as shown in the table below:

[0226] Table 6. Basis for Coverage Type Quality Poor Analysis

[0227]

[0228] ②Optimize solution output

[0229] Solving quality issues is similar to solving coverage issues. Under the premise of ensuring that the base station and antenna feeder system are working properly and the parameters are set reasonably, optimization can be achieved by adjusting the antenna height, antenna downtilt angle and azimuth angle, and RS power.

[0230] 4.4) Capacity-based root cause localization algorithm

[0231] High load directly affects various network indicators. In the root cause algorithm based on expert experience, load-related problems such as inter-carrier traffic load imbalance and inter-sector traffic load imbalance are jointly located by indicators that characterize the load, such as PRB utilization and RS power.

[0232] ① Load imbalance analysis

[0233] Under the same RRU, if two logical cells with the same bandwidth but different frequency points have the same maximum power, and their PRB utilization difference is greater than 20%, then there is a load imbalance. In reality, under the same physical cell, two logical cells with the same coverage may not have the same maximum power due to interference avoidance and other factors, but under normal circumstances, the difference will not exceed 3dB. Based on practical considerations, PRB utilization and RS power are used together to locate inter-carrier load balancing issues. This method is also applicable to inter-sector load balancing decisions.

[0234] Based on indicators such as PRB utilization, CCE (Control Channel Element) utilization, number of users, traffic, RS power, and cell merging, root cause algorithms were developed for issues such as inter-carrier traffic load imbalance, inter-sectoral traffic load imbalance, large number of users, insufficient bandwidth, high load in merged logical cells, license-limited inter-sectoral traffic load imbalance, and high CCE utilization, as shown in the table below:

[0235] Table 7. Basis for Quality Defect Analysis of Volume Category

[0236]

[0237] ②Optimize solution output

[0238] To address the high load issue of macro base stations, assuming the base station and antenna feeder system are functioning normally and the parameters are set reasonably, there are generally five solutions: cell expansion, cell splitting and merging, inter-carrier load balancing, inter-site load balancing, and expansion license. Among these, inter-carrier load balancing and inter-site load balancing are preferred.

[0239] 5. Optimization effect verification

[0240] The effectiveness of the root cause localization algorithm was verified by conducting an application experiment in the pilot area.

[0241] In one embodiment, S2, a poor quality root cause diagnostic chain is established to answer user questions. The poor quality root cause diagnostic chain includes several diagnostic sub-tasks for each poor-quality cell in the wireless network, specifically including:

[0242] Based on the real-time wireless network quality poorness category of each poor wireless network quality cell, obtain the corresponding thought chain question and answer prompt words;

[0243] Based on the question-and-answer prompts in the mind chain, a root cause diagnosis chain for poor quality is developed, which includes several diagnostic sub-tasks for each poor-quality cell in the wireless network.

[0244] Determine the wireless network API interfaces that each diagnostic subtask needs to call.

[0245] In this embodiment, as Figure 4 As shown, S103: Utilize the thinking chain capability of the large network model to plan and arrange the tasks after intent recognition, determine the analysis tools to be called, the thinking chain capability of the large network model has been obtained based on the above pre-training, and determine the API (Application Programming Interface) interface for each sub-task to obtain real-time data.

[0246] In one embodiment, wherein:

[0247] Several diagnostic sub-tasks include at least one of the following: fault diagnosis, parameter diagnosis, coverage diagnosis, quality diagnosis, interference diagnosis, capacity diagnosis, and latent fault diagnosis;

[0248] The wireless network API interfaces include at least one of the following: base station alarm API interface, cell performance KPI indicator API interface, base station main control board API interface, cell CM configuration file API interface, cell performance KPI indicator API interface, MR indicator API interface, uplink interference diagnosis small model API interface, and cell B domain service traffic indicator API interface.

[0249] In this embodiment, after the network model receives the intent result after the Agent calls the plugin to complete parameter extraction, it utilizes the thought chain capability after incremental pre-training and SFT instruction fine-tuning to plan the analysis task of the poor voice service quality cell problem, such as... Figure 5 As shown, the task planning is decomposed mainly from the following aspects: fault diagnosis, parameter diagnosis, coverage diagnosis, quality diagnosis, interference diagnosis, capacity diagnosis, and hidden fault diagnosis. This is cell-level diagnosis. After analyzing regional indicators, if a regional indicator exceeds a certain threshold, analysis of cells within that region is triggered—a macro-to-micro analysis method. Then, step S104 is used to analyze the root causes of poor quality.

[0250] In one embodiment, S3 acquires several diagnostic results from several diagnostic subtasks, specifically including:

[0251] Several diagnostic subtasks are processed sequentially according to the order in the poor quality root cause diagnostic chain;

[0252] Call the wireless network API interface corresponding to each diagnostic subtask to obtain the corresponding real-time wireless network data;

[0253] By combining real-time wireless network data, real-time wireless network quality poorness categories, thought chain question-and-answer prompts, and wireless network quality poorness diagnosis expert knowledge, the system outputs real-time wireless network quality poorness diagnosis results for each diagnostic subtask.

[0254] In this embodiment, as Figure 4 As shown in S104: After subtask planning and decomposition, quality control analysis is performed on the calling tools specified in each subtask, and the analysis and diagnostic results are fed back to the AI ​​Agent. Quality control analysis is performed on different subtasks planned according to the thought chain of the large network model, and on the calling tools specified in each subtask. Specifically, this includes:

[0255] 1. Fault Diagnosis Subtask:

[0256] 1.1) Calling the tool:

[0257] ① Base station side alarm API interface

[0258] ② Community performance KPI indicator API interface

[0259] ③ Base station main control board API interface

[0260] 1.2) Quality Problem Analysis Process (e.g.) Figure 6 As shown):

[0261] ① Normal analysis results (6-a)

[0262] Example: In the alarm diagnosis analysis, the analysis results are normal.

[0263] Does the cell have real-time wireless alarms or LST ALMAF (command for querying currently active alarms in the LTE network) alarms associated with real-time network management? No.

[0264] ②Analysis of abnormal results (6-b)

[0265] Example: Does the cell have real-time wireless alarms and network management real-time associated LST ALMAF alarms? Yes

[0266] The diagnosis revealed that the community became unavailable at 18:15:20 on April 20, 2024. It is recommended that the maintenance engineer handle the fault and investigate the cause.

[0267] Based on the results of calling multiple API interfaces in the fault diagnosis subtask, the AI ​​Agent is then fed back to diagnose, classify, and summarize the problems.

[0268] 2. Parameter Diagnosis Subtask:

[0269] 2.1) Calling the tool:

[0270] ① Community CM configuration file API interface (including timer parameters, handover parameters, and other data)

[0271] ② Community performance KPI indicator API interface

[0272] 2.2) Quality Poor Problem Analysis Process (e.g.) Figure 7 As shown):

[0273] ① Normal analysis results (7-a)

[0274] Example: In the parameter diagnostic analysis, the analysis results are normal.

[0275] a) T300 = 1000 (reasonable range 0-1000ms), parameter configuration is normal.

[0276] b) T304 = 500 (reasonable range 500-2000ms), parameter configuration is normal.

[0277] c) N310 = 10 (reasonable range 6-20), parameter configuration is normal.

[0278] d) N311 = 1 (reasonable range 1-2), parameter configuration is normal.

[0279] e) Minimum access level = -126 (reasonable range -110 to -128), parameter configuration is normal.

[0280] f) A2 event RSRP threshold (inter-system data) = -120 (reasonable range -107 to -118), parameter configuration is normal.

[0281] g) Event B2 RSRP threshold 1 (data) = -122 (reasonable range -110 to -118), parameter configuration is normal.

[0282] h) Event B2 RSRP threshold 2 (data) = -118 (reasonable range -110 to -118), parameter configuration is normal.

[0283] ②Analysis of abnormal results (7-b)

[0284] Example: Abnormal analysis results in parameter diagnostic analysis.

[0285] a) T300 = 2000 (reasonable range 0-1000ms), parameter configuration abnormal.

[0286] b) T304 = 500 (reasonable range 500-2000ms), parameter configuration is normal.

[0287] c) N310 = 10 (reasonable range 6-20), parameter configuration is normal.

[0288] d) N311 = 1 (reasonable range 1-2), parameter configuration is normal.

[0289] e) Minimum access level = -126 (reasonable range -110 to -128), parameter configuration is normal.

[0290] f) A2 event RSRP threshold (inter-system data) = -120 (reasonable range -107 to -118), parameter configuration is normal.

[0291] g) Event B2 RSRP threshold 1 (data) = -122 (reasonable range -110 to -118), parameter configuration is normal.

[0292] h) Event B2 RSRP threshold 2 (data) = -118 (reasonable range -110 to -118), parameter configuration is normal.

[0293] The diagnosis revealed that the T300 cell parameter configuration was outside the reasonable range, which had a certain impact on the success rate of RRC establishment and voice service perception. It is recommended to reset it to a reasonable range.

[0294] Based on the parameter diagnosis subtask, multiple API interfaces are called to diagnose the results, which are then fed back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0295] 3. Cover diagnostic subtasks:

[0296] 3.1) Calling the tool:

[0297] ①MR index API interface

[0298] ② Community performance KPI indicator API interface

[0299] 3.2) Quality Poor Problem Analysis Process (e.g.) Figure 8 As shown):

[0300] ① Normal analysis results (8-a)

[0301] Example: In the coverage diagnostic analysis, the analysis results are normal.

[0302] a) Weak coverage ratio (RSRP <= -105 ratio) = 12.6% (reasonable range 0-20%), indicator is normal.

[0303] b) Total number of tadv sampling points = 9426

[0304] c) Number of over-coverage sampling points = 2465

[0305] d) Over-coverage rate = 16.15% (reasonable range 0-20%), indicator is normal.

[0306] e) Number of near-coverage sampling points = 25

[0307] f) Near coverage rate = 1.28% (reasonable range 0-20%), indicator is normal.

[0308] ②Analysis of abnormal results

[0309] Example 1: In coverage diagnostic analysis, the analysis results are abnormal (8-b). (When the proportion of weak coverage is outside the reasonable range, while the overcoverage and near-coverage rates are within the normal range)

[0310] a) Weak coverage rate (RSRP <= -105) = 22.6% (reasonable range 0-10%), indicating weak coverage issues exist.

[0311] b) Total number of tadv sampling points = 9426

[0312] c) Number of over-coverage sampling points = 2465

[0313] d) Over-coverage rate = 6.15% (reasonable range 0-20%), indicator is normal.

[0314] e) Number of near-coverage sampling points = 25

[0315] f) Near coverage rate = 1.28% (reasonable range 0-20%), indicator is normal.

[0316] Diagnosis revealed weak coverage in the cell, which negatively impacts RRC establishment success rate and voice service experience. Cell parameters were checked.

[0317] (a) Station height = 50 meters

[0318] (b) Mechanical downtilt angle = 2 degrees, electronic downtilt angle = 0 degrees, azimuth angle = 60 degrees. It is recommended to improve signal strength by appropriately optimizing the downtilt angle and azimuth angle.

[0319] The diagnostic subtasks above call multiple API interfaces to diagnose the results, and then feed them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0320] Example 2: In coverage diagnostic analysis, the analysis results are abnormal (8-c). (When the weak coverage rate exceeds the reasonable range, the overcoverage rate also exceeds the reasonable range, but the near coverage rate is within the normal range)

[0321] a) Weak coverage rate (RSRP <= -105) = 22.6% (reasonable range 0-10%), indicating weak coverage issues exist.

[0322] b) Total number of tadv sampling points = 9426

[0323] c) Number of over-coverage sampling points = 2465

[0324] d) Over-coverage rate = 26.15% (reasonable range 0-20%), indicator abnormal.

[0325] e) Number of near-coverage sampling points = 25

[0326] f) Near coverage rate = 1.28% (reasonable range 0-20%), indicator is normal.

[0327] Diagnosis revealed a weak coverage issue in the cell. Excessive coverage distance resulted in users at the coverage edge being unable to access the network, impacting RRC establishment success rates and voice service experience. Cell parameters were checked.

[0328] (a) Station height = 50 meters

[0329] (b) Mechanical downtilt angle = 2 degrees, electronic downtilt angle = 0 degrees, azimuth angle = 60 degrees. It is recommended to optimize the downtilt angle and azimuth angle to control coverage and enhance signal strength.

[0330] The diagnostic subtasks above call multiple API interfaces to diagnose the results, and then feed them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0331] Example 3: In coverage diagnostic analysis, the analysis results are abnormal (8-day). (When the weak coverage rate exceeds the reasonable range, the near coverage rate also exceeds the reasonable range, but the overcoverage rate is within the normal range)

[0332] a) Weak coverage rate (RSRP <= -105) = 22.6% (reasonable range 0-10%), indicating weak coverage issues exist.

[0333] b) Total number of tadv sampling points = 9426

[0334] c) Number of over-coverage sampling points = 2465

[0335] d) Over-coverage rate = 6.15% (reasonable range 0-20%), indicator abnormal.

[0336] e) Number of near-coverage sampling points = 25

[0337] f) Near coverage rate = 21.28% (reasonable range 0-20%), indicator abnormal.

[0338] Diagnosis revealed a weak coverage issue in the cell, potentially caused by obstructions from objects, resulting in weak signal access for users with excessively close coverage. This negatively impacts RRC establishment success rate and voice service experience. Cell parameters were checked.

[0339] (a) Station height = 50 meters

[0340] (b) Mechanical tilt angle = 2 degrees, electronic tilt angle = 0 degrees, azimuth angle = 60 degrees

[0341] It is recommended to conduct an on-site inspection to check if the antenna is obstructed, and to adjust the azimuth angle or modify the antenna position to improve signal strength.

[0342] The diagnostic subtasks above call multiple API interfaces to diagnose the results, and then feed them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0343] Example 4: In coverage diagnostic analysis, the analysis results are abnormal (8-e). (When the proportion of weak coverage exceeds the reasonable range, and the overcoverage and near-coverage rates also exceed the reasonable range.)

[0344] a) Weak coverage rate (RSRP <= -105) = 22.6% (reasonable range 0-10%), indicating weak coverage issues exist.

[0345] b) Total number of tadv sampling points = 9426

[0346] c) Number of over-coverage sampling points = 2465

[0347] d) Over-coverage rate = 26.15% (reasonable range 0-20%), indicator abnormal.

[0348] e) Number of near-coverage sampling points = 25

[0349] f) Near coverage rate = 21.28% (reasonable range 0-20%), indicator abnormal.

[0350] Diagnosis revealed weak coverage issues in the cell, primarily due to coverage being too close or too far away. This negatively impacts RRC establishment success rate and voice service experience. Cell parameters were checked.

[0351] (a) Station height = 50 meters

[0352] (b) Mechanical tilt angle = 2 degrees, electronic tilt angle = 0 degrees, azimuth angle = 60 degrees

[0353] Recommendation 1: Enhance signal strength by optimizing downtilt and azimuth angles to control coverage.

[0354] Recommendation 2: It is recommended to conduct an on-site inspection to check if the antenna is obstructed, and to adjust the azimuth angle or modify the antenna position to improve signal strength.

[0355] The diagnostic subtasks above call multiple API interfaces to diagnose the results, and then feed them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0356] 4. Quality Diagnosis Subtask:

[0357] 4.1) Calling the tool:

[0358] ①MR index API interface

[0359] ② Community performance KPI indicator API interface

[0360] 4.2) Quality Problem Analysis Process (e.g.) Figure 9 As shown):

[0361] ① Normal analysis results (9-a)

[0362] Example: In the quality diagnostic analysis, the analysis results are normal.

[0363] a) The percentage of sampling points with MRO-SINR ≥ 0 is 98.87% (reasonable range 90%–100%), indicating a normal index.

[0364] b) Overlap coverage ratio (RSRP = -105) = 14.78% (reasonable range 0% to 20%)

[0365] c) Total MR samples = 9553

[0366] d) Number of MOD30 interference sampling points = 893, MOD30 interference rate = 9.34% (reasonable range 0%~10%)

[0367] ②Analysis of abnormal results

[0368] Example 1: In quality diagnostic analysis, the analysis results are abnormal (9-b). (When the proportion of sampling points with MRO-SINR ≥ 0 exceeds the reasonable range, and the overlap coverage ratio exceeds the reasonable range, but the MOD30 interference rate is within the normal range)

[0369] a) The percentage of sampling points with MRO-SINR ≥ 0 is 87.25% (the reasonable range is 90% to 100%), indicating a downlink quality issue.

[0370] b) Overlap coverage ratio (RSRP = -105) = 24.78% (reasonable range 90%–100%)

[0371] c) Total MR samples = 9553

[0372] d) Number of MOD30 interference sampling points = 893, MOD30 interference rate = 9.34% (reasonable range 0%~10%)

[0373] Diagnosis revealed a downlink quality issue in the cell. Overlapping coverage caused co-channel interference, impacting RRC establishment success rate and voice service experience. Cell parameters were checked.

[0374] (a) Station height = 50 meters

[0375] (b) Mechanical tilt angle = 2 degrees, electronic tilt angle = 0 degrees, azimuth angle = 60 degrees

[0376] If the station is too high or the antenna is mounted too high, it may cover too far and cause interference to surrounding stations. If the stations are too close or too far apart, the main serving cell may not be clear. Due to the superposition of multiple signals, overlapping coverage may occur. It is recommended to solve the downlink quality problem by optimizing the downtilt angle and azimuth angle of the station and surrounding stations.

[0377] The diagnostic subtasks above call multiple API interfaces to diagnose the results, and then feed them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0378] Example 2: In quality diagnostic analysis, the analysis results are abnormal (9-c). (When the proportion of sampling points with MRO-SINR≥0 exceeds the reasonable range, and the MOD30 interference rate exceeds the reasonable range, but the overlap coverage ratio is within the normal range)

[0379] a) The percentage of sampling points with MRO-SINR ≥ 0 is 87.25% (the reasonable range is 90% to 100%), indicating a downlink quality issue.

[0380] b) Overlap coverage ratio (RSRP = -105) = 14.78% (reasonable range 90%–100%)

[0381] c) Total MR samples = 9553

[0382] d) Number of MOD30 interference sampling points = 1280, MOD30 interference rate = 13.39% (reasonable range 0%~10%)

[0383] Diagnosis revealed a downlink quality issue in the cell, caused by MOD30 interference, which negatively impacts RRC establishment success rate and voice service experience. Cell parameters were checked.

[0384] (a) Station height = 50 meters

[0385] (b) Mechanical tilt angle = 2 degrees, electronic tilt angle = 0 degrees, azimuth angle = 60 degrees

[0386] Recommendation 1: High station height or high antenna mounting can easily lead to excessive coverage and cause MOD30 interference to surrounding sites. It is recommended to solve the downlink quality problem by optimizing the downtilt angle and azimuth angle of this station and surrounding sites.

[0387] Recommendation 2: By optimizing beam coordination strategies, network coverage performance and user service experience can be further improved.

[0388] Recommendation 3: Avoid MOD30 interference by optimizing the scrambling code of neighboring cells.

[0389] The results of calling multiple API interfaces for the quality diagnosis subtask above are then fed back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0390] 5. Interference Diagnosis Subtask:

[0391] 5.1) Calling the tool:

[0392] ① Uplink Interference Diagnosis Small Model API Interface

[0393] ② Community performance KPI indicator API interface

[0394] 5.2) Interference problem analysis process (e.g.) Figure 10-15 As shown):

[0395] ① Normal analysis results

[0396] Example: In the interference diagnostic analysis, the analysis results are normal.

[0397] The average interference noise power per prb (dBm) is -108 (reasonable range <= -105dBm), which is normal.

[0398] ②Analysis of abnormal results

[0399] Example 1: In interference diagnostic analysis, the analysis results are abnormal (15-a). (When the average interference noise power per prb exceeds the reasonable range, and the uplink interference type is none)

[0400] a) Average interference noise power per prb (dBm) = -98.5 (reasonable range <= -105dBm), an abnormal indicator.

[0401] b) Uplink interference type = None

[0402] Diagnosis revealed uplink interference in the cell (uplink interference type = none), which negatively impacts RRC establishment success rate and voice service perception. The hourly PRB-level waveform diagram for this cell was retrieved (achieved by calling the uplink interference diagnosis mini-model API interface). Figure 10 As shown.

[0403] It is recommended to conduct a frequency scan on-site to identify the source of interference, eliminate the interference, and then observe whether the 5G (fifth-generation mobile communication technology) wireless connection rate index returns to normal.

[0404] The above interference diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0405] Example 2: In interference diagnostic analysis, the analysis results are abnormal (15-b). (When the average interference noise power per prb exceeds the reasonable range, and the uplink interference type equals spurious interference)

[0406] Diagnosis revealed uplink interference in the cell, classified as spurious interference, which negatively impacts the success rate of RRC establishment and voice service perception. The hourly PRB-level waveform diagram for this cell was retrieved (achieved by calling the uplink interference diagnosis mini-model API interface). Figure 11 As shown.

[0407] We recommend following these steps to troubleshoot interference:

[0408] a) Investigate the system isolation between the interfering cell and the interfering source base station. Generally, horizontal isolation should be changed to vertical isolation, requiring a spatial distance of at least 3m horizontally or at least 1m vertically.

[0409] b) Check if the interference source has a filter installed. Spurious interference can be reduced by adding a bandpass filter to the interference source.

[0410] The above interference diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0411] Example 3: In interference diagnostic analysis, the analysis results are abnormal (15-c). (When the average interference noise power per prb exceeds the reasonable range, and the uplink interference type equals blocking interference)

[0412] Diagnosis revealed uplink interference in the cell, classified as congestion interference, which negatively impacts the success rate of RRC establishment and voice service perception. The hourly PRB-level waveform diagram for this cell was retrieved (achieved by calling the uplink interference diagnostic mini-model API interface). Figure 12 As shown.

[0413] We recommend following these steps to troubleshoot interference:

[0414] a) Investigate whether the affected base station has installed a filter, and reduce interference by installing a filter.

[0415] b) Investigate the isolation level between the two systems and change horizontal isolation to vertical isolation.

[0416] c) Investigate the anti-interference capability of the equipment in the affected cell, and replace the affected RRU with equipment that has stronger anti-blocking capabilities.

[0417] The above interference diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0418] Example 4: In interference diagnostic analysis, the analysis results are abnormal (15-day). (When the average interference noise power per prb exceeds the reasonable range, and the uplink interference type equals GPS lock-out interference)

[0419] Diagnosis revealed uplink interference in the cell, specifically GPS lock-off interference, which negatively impacts RRC establishment success rate. The hourly PRB-level waveform diagram for this cell was retrieved (achieved by calling the uplink interference diagnostic small model API interface). Figure 13 As shown.

[0420] We recommend following these steps to troubleshoot interference:

[0421] a) Investigate the cell where the base station clock synchronization alarm coincides with the time of widespread interference and service disruption in the surrounding area.

[0422] b) Check whether the frame offset configuration of the problematic cell is consistent with that of surrounding base stations.

[0423] c) If the frame offset is consistent, then it is necessary to check for base station clock faults and collect the main control board logs for further investigation.

[0424] The above interference diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0425] Example 5: In interference diagnostic analysis, the analysis results are abnormal (15-e). (When the average interference noise power per prb exceeds the reasonable range, and the uplink interference type is equal to long-distance co-channel interference)

[0426] Diagnosis revealed uplink interference in the cell, specifically long-distance co-channel interference, which negatively impacts RRC establishment success rate. The hourly PRB-level waveform diagram for this cell was retrieved (achieved by calling the uplink interference diagnosis mini-model API interface). Figure 14 As shown.

[0427] We recommend following these steps to troubleshoot interference:

[0428] 1) Check whether the existing network has completed frequency clearing, and clear any frequencies that have not been completely cleared.

[0429] 2) Investigate the base station antenna type and replace it if necessary.

[0430] 3) Check the parameter configuration of co-channel interfering cells. This can be done by adjusting the antenna transmit power, adjusting the co-channel neighbor cell reuse distance, adjusting the antenna downtilt angle, azimuth angle, and lowering the antenna platform.

[0431] The above interference diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0432] 6. Capacity Diagnosis Subtask:

[0433] 6.1) Calling the tool:

[0434] ① API interface for traffic metrics in Community B domain

[0435] ② Community performance KPI indicator API interface

[0436] 6.2) Capacity problem analysis process (e.g.) Figure 16 As shown):

[0437] ① Normal analysis results

[0438] Example: In the capacity diagnostic analysis, the analysis results are normal (16-a).

[0439] a) Uplink PRB utilization rate = 8.52% (reasonable range 0-50%, taking the maximum value of the entire network in 24 hours), the indicator is normal.

[0440] b) Downlink PRB utilization rate = 2.28% (reasonable range 0-50%, take the maximum value of the entire network in 24 hours), the indicator is normal.

[0441] c)arfcn=636664

[0442] d) Average number of 5G (fifth-generation mobile communication technology) users = 515

[0443] e) 5G (fifth-generation mobile communication technology) data traffic (5G uplink traffic + 5G downlink traffic) = 8.2Gb

[0444] f) Total traffic of China Unicom (uplink traffic + downlink traffic) = 6Gb

[0445] g) Total telecommunications traffic (uplink telecommunications traffic + downlink telecommunications traffic) = 2.2Gb

[0446] ②Analysis of abnormal results

[0447] Example 1: In capacity diagnostic analysis, the analysis results are abnormal (16-b). (When the uplink PRB utilization rate is outside the reasonable range, but the downlink PRB utilization rate is within the normal range)

[0448] a) Uplink PRB utilization rate = 88.56% (reasonable range 0-50%, take the maximum value of the entire network in 24 hours), indicator abnormal.

[0449] b) Downlink PRB utilization rate = 12.49% (reasonable range 0-50%, taking the maximum value of the entire network in 24 hours), the indicator is normal.

[0450] c)arfcn=636664

[0451] d) Average number of 5G users = 928

[0452] e) 5G data traffic (5G uplink traffic + 5G downlink traffic) = 86.2Gb

[0453] f) Total traffic of China Unicom (uplink traffic + downlink traffic) = 50.1Gb

[0454] g) Total telecommunications traffic (uplink telecommunications traffic + downlink telecommunications traffic) = 36.1 Gb

[0455] The diagnosis revealed that the cell has excessive uplink load, which is affecting 5G voice sensing services. Optimization and adjustments are recommended in the following aspects:

[0456] a) Check if the uplink dynamic scheduling algorithm is enabled.

[0457] b) Load balancing parameter verification, mainly from three aspects: power parameters, handover and reselection parameters, and MLB (Mobility Load Balance) parameters, and reasonable parameter configuration.

[0458] c) Neighbor cell integrity verification, mainly analyzed from three aspects: the integrity of inter-frequency points, the accuracy of external neighbor cell definitions, and the integrity of internal neighbor cell additions.

[0459] d) Structural rationality analysis, mainly checking from four aspects: accuracy of engineering parameters, azimuth angle, downtilt angle, and rationality of TA coverage.

[0460] The above capacity diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0461] Example 2: In capacity diagnostic analysis, the analysis result is abnormal (16-c). (When the downstream PRB utilization rate is outside the reasonable range, but the upstream PRB utilization rate is within the normal range)

[0462] a) Uplink PRB utilization rate = 9.33% (reasonable range 0-50%, taking the maximum value of the entire network in 24 hours), the indicator is normal.

[0463] b) Downlink PRB utilization rate = 82.49% (reasonable range 0-50%, take the maximum value of the entire network in 24 hours), indicator abnormal.

[0464] c)arfcn=636664

[0465] d) Average number of 5G users = 1008

[0466] e) 5G data traffic (5G uplink traffic + 5G downlink traffic) = 109.5Gb

[0467] f) Total traffic of China Unicom (uplink traffic + downlink traffic) = 80.2Gb

[0468] g) Total telecommunications traffic (uplink telecommunications traffic + downlink telecommunications traffic) = 29.3Gb

[0469] The diagnosis revealed that the cell has excessive downlink load, which is affecting 5G voice sensing services. Optimization and adjustments are recommended in the following aspects:

[0470] a) Check if the downlink dynamic scheduling algorithm is enabled.

[0471] b) Load balancing parameter verification, mainly checking three aspects: power parameters, switching and reselection parameters, and MLB parameters, and configuring appropriate parameters.

[0472] c) Expansion of cells operating at the same or different frequencies

[0473] d) Newly built base stations share the load

[0474] The above capacity diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0475] Example 3: In capacity diagnostic analysis, the analysis results are abnormal (16-day). (When both uplink and downlink PRB utilization rates are outside the reasonable range)

[0476] a) Uplink PRB utilization rate = 85.50% (reasonable range 0-50%, take the maximum value of the entire network in 24 hours), indicator abnormal.

[0477] b) Downlink PRB utilization rate = 72.85% (reasonable range 0-50%, take the maximum value of the entire network in 24 hours), indicator abnormal.

[0478] c)arfcn=636664

[0479] d) Average number of 5G users = 1180

[0480] e) 5G data traffic (5G uplink traffic + 5G downlink traffic) = 509.8Gb

[0481] f) Total traffic of China Unicom (uplink traffic + downlink traffic) = 428.5Gb

[0482] g) Total telecommunications traffic (uplink telecommunications traffic + downlink telecommunications traffic) = 81.3Gb

[0483] The diagnosis revealed that the cell has excessive downlink load, which is affecting 5G voice sensing services. Optimization and adjustments are recommended in the following aspects:

[0484] a) Check if the uplink and downlink dynamic scheduling algorithms are enabled.

[0485] b) Load balancing parameter verification, mainly checking three aspects: power parameters, switching and reselection parameters, and MLB parameters, and configuring appropriate parameters.

[0486] c) Neighbor cell integrity verification, mainly analyzed from three aspects: the integrity of inter-frequency points, the accuracy of external neighbor cell definitions, and the integrity of internal neighbor cell additions.

[0487] d) Structural rationality analysis, mainly checking from four aspects: accuracy of engineering parameters, azimuth angle, downtilt angle, and rationality of TA coverage.

[0488] e) Expansion of cells operating at the same or different frequencies

[0489] f) New base stations share the load

[0490] The above capacity diagnosis subtask calls multiple API interfaces to diagnose the results, and then feeds them back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0491] 7. Hidden Fault Diagnosis Subtask:

[0492] 7.1) Calling the tool:

[0493] ① API interface for business traffic metrics in Community B domain (business support system)

[0494] ② Community performance KPI indicator API interface

[0495] ③ Base station side alarm API interface

[0496] ④ MR index API interface

[0497] 7.2) Latent fault analysis process (e.g.) Figure 17 As shown):

[0498] ① Normal analysis results

[0499] Example: In the analysis of latent fault diagnosis, the analysis results are normal (17-a).

[0500] All indicators in the residential area are normal, and no hidden faults have occurred.

[0501] ②Analysis of abnormal results

[0502] Example 1: In the analysis of hidden fault diagnosis, the analysis results are abnormal (17-b). (When the uplink PRB utilization rate exceeds the reasonable range, but the downlink PRB utilization rate is within the normal range)

[0503] Based on the diagnosis, there is a suspected hidden fault in the community. It is recommended to check one by one according to the following steps:

[0504] a) If the RRU software crashes, it is recommended to run the RRU in the background, then power it off and reset it in the foreground before observing the indicators.

[0505] b) If the problem persists after resetting, an on-site inspection of the antenna and feeder system is required, including whether the antenna placement is reasonable, whether the waterproof tape on the antenna feeder cable is damaged, and whether the feeder cable is damaged.

[0506] c) Replace or swap antenna feeders.

[0507] d) If no hidden faults are found during on-site investigation, it is recommended to use an end-to-end analysis method to obtain relevant indicators of DNS (Domain Name System), CDN (Content Delivery Network), core network and SP (Service Provider) servers, and analyze them segment by segment to find problems on the wireless air interface side and above.

[0508] e) Check the base station terminal compatibility parameters and change the base station SRS reconfiguration mode switch to 0 (OFF).

[0509] The results of calling multiple API interfaces for the above implicit diagnostic subtasks are then fed back to the AI ​​Agent for problem diagnosis, classification, and summarization.

[0510] In one embodiment, S4, based on several diagnostic results, obtain the root causes and handling suggestions for several poor-quality wireless network cells, and output answers to user questions based on the root causes and handling suggestions, specifically including:

[0511] Based on the sequence of the poor quality root cause diagnosis chain, the abnormal root cause and processing suggestions of the diagnosis subtask are integrated into the diagnosis results. The voice and / or text results of the poor quality root cause and poor quality processing suggestions of several wireless network poor quality cells are output.

[0512] Several poor-quality wireless network cells are displayed on a map, and their root causes are marked. Based on the suggestions for handling poor quality, page instructions for fixing the root causes of poor quality are generated and executed automatically or when triggered by the user.

[0513] In this embodiment, as Figure 4 As shown in S105: The AI ​​Agent comprehensively summarizes and processes the diagnostic results to obtain two types of instructions: visual instructions and page instructions (both types of instructions exist simultaneously, one is for the interface to be presented, and the other is for the instruction operation). After receiving the instructions, the executor executes them. The RPA (Robotic Process Automation) intelligent agent performs the action and finally presents the complete answer to the user.

[0514] In the overall architecture, the executor is responsible not only for using external tools but also for executing client commands. After identifying and planning the user's intent, AIAgent further identifies and plans the processing results, determining the type and object of the operation involved. It then extracts the unique identifier of the object from the command library and processes all data according to the format agreed upon with the command execution SDK (Software Development Kit), resulting in two types of command data: page commands and visual commands. For example... Figure 18 As shown.

[0515] Page instructions are the specific steps that the intelligent agent plans to perform on behalf of the user on the existing system page. After the client receives the user's instructions, it uses the page instructions to execute the SDK tool ("to complete the user's query / operation goal through a question"). According to the received page instructions, the SDK tool executes them in the order of the instructions. There is an error correction mechanism to ensure the correct and complete execution of the instructions. If the instruction execution fails, the error correction mechanism will use a backup plan to correct the error and execute the instruction, ensuring that every instruction can be executed completely.

[0516] Visualization commands are used to visualize the content of large-scale intelligent agent planning and summarization on the client side. The client extracts the corresponding components from the visualization component library according to the visualization type, inputs the visualization content, and forms a user-friendly visualization page.

[0517] After all instructions are executed, the client provides feedback to the AI ​​Agent, including the operation results and any anomalies. The AI ​​Agent learns from this feedback, continuously optimizing the operation steps and the accuracy of intent recognition. Simultaneously, this process ensures that the entire workflow complies with data protection regulations and business compliance requirements, protecting user data security. All instruction types and operation objects are stored in the instruction library.

[0518] Command Library: This includes command operation types, operable objects, and visual components. The operable objects in the command library contain all operable objects on the system pages. Initially, all operable objects were stored in the command library using automated tools to assist manual input. Each operable object has a precise semantic mapping with the business operation process or function name, facilitating intent recognition by the intelligent agent.

[0519] After the AI ​​Agent plans the operation steps (detailed down to each specific action), it performs intent recognition based on specific terms within those steps, queries the instruction library to retrieve the unique object identifier corresponding to that semantic meaning, assembles it into a data format agreed upon with the client, and returns it to the client. Upon receiving the instruction data, if the instruction is a page instruction, the client will locate the object to be operated on on the page based on the unique object identifier and execute the corresponding action on the object according to the agent operation type.

[0520] The instruction library contains two main categories of instructions: page instructions and visual instructions.

[0521] Page instructions are instructions given by the agent to the user to operate on the page. The entire instruction consists of agent operation type (required) + agent operation object (required) + agent content (optional). Among them, agent operation type and agent operation object are required, while agent content is optional.

[0522] Proxy operation types include: 1) Click: Using the mouse to click a specific object on the webpage, including left-click, right-click, and double-click. 2) Text Fill: Entering text in an editable control, mimicking keyboard behavior. 3) Copy. 4) Cut. 5) Paste. 6) Get Text: Retrieving the content of the manipulated object. 7) Get Object: Retrieving the manipulated object. 8) Scroll: Scrolling a control item vertically or horizontally, mimicking the behavior of a mouse wheel, making obscured content visible. 9) Drag and Drop: Mimicking the user's behavior of dragging components. 10) Jump: Mimicking the user's page jump, including jumping to the current page, opening a new tab, and opening a new window. 11) Page Matching: Matching to determine if the current page is the target page. 12) Screenshot: Taking a screenshot of the current screen / browser view interface. 13) Confirmation Prompt: Can be used to provide secondary confirmation prompts before performing some irreversible or high-risk operations as a protection mechanism.

[0523] The objects to be manipulated by the agent include: 1) All operable component objects on the system page: radio buttons, checkboxes, input boxes, dates, maps, charts, icons, tables, buttons, etc. 2) Page scrollbars: horizontal scrollbars and vertical scrollbars.

[0524] Proxy content: This consists of data used to populate and assign values ​​to the proxy operation object. The proxy operation types, proxy operation objects, and proxy content can be freely combined according to business needs.

[0525] Visualization instructions include visualization type and visualization content.

[0526] Visualization types include: 1) Chart commands, which can be further divided into: bar charts, line charts, line graph bar charts, pie charts, cube charts, etc.; 2) Tables, which can be further divided into: no pagination, front-end pagination, and remote pagination; supporting filtering, with filter types including single selection, multiple selection, text, date, labels, etc.; ... 3) Single selection. 4) Multiple selection. 5) Buttons. 6) Lists. 7) Text. 8) Download. 9) Images...

[0527] Visualized content is generally transmitted in JSON format, and the specific data fields and hierarchical relationships are related to the visualization type.

[0528] The specific page composition is as follows Figure 19 As shown, the page presentation is as follows Figure 20 As shown.

[0529] This embodiment utilizes the definition of poor-quality cells in 4G / 5G wireless network voice perception services and constructs an intelligent agent for analyzing and processing poor-quality wireless cells based on a large-model AI Agent architecture. This method can be designed on the basis of voice perception services in any network or even higher evolved networks.

[0530] Example 2:

[0531] like Figure 2 As shown, this disclosure provides a wireless network quality poor analysis and processing device. The device includes an AI Agent, which includes a large network model. The large network model includes:

[0532] The intent recognition module 1 is used to identify the user's query intent regarding poor wireless network quality in the question and to obtain several poor wireless network quality cells that need to be analyzed in order to answer the user's question.

[0533] The chain orchestration module 2, connected to the intent recognition module 1, is used to compile a poor quality root cause diagnosis chain to answer user questions. The poor quality root cause diagnosis chain includes several diagnostic sub-tasks for each poor quality cell in the wireless network.

[0534] The diagnostic analysis module 3, connected to the chained orchestration module 2, is used to obtain several diagnostic results from several diagnostic subtasks. Each diagnostic result includes the anomaly judgment, root cause of the anomaly, and handling suggestions for each diagnostic subtask.

[0535] The summary output module 4, connected to the diagnostic analysis module 3, is used to obtain the root causes and handling suggestions for several poor-quality wireless network cells based on several diagnostic results, and output answers to user questions based on the root causes and handling suggestions.

[0536] In one embodiment, the intent recognition module 1 specifically includes:

[0537] The extraction unit is used to receive user questions and extract the inquiry time, inquiry area, and inquiry category from the user questions using keywords.

[0538] The judgment unit, connected to the extraction unit, is used to determine whether there are poor-quality wireless network cells in the query area within the query time if the query category includes queries about wireless network services and / or indicators.

[0539] The acquisition unit, connected to the judgment unit, is used to determine, if present, that the user's question includes an intent to inquire about poor wireless network quality, and to acquire the identifiers of several poor wireless network quality cells in the inquiry area within the inquiry time and the real-time poor wireless network quality category.

[0540] In one embodiment, the determination unit specifically includes:

[0541] The regional-level judgment subunit is used to obtain the regional-level wireless network service indicators of the query area within the query time, and to determine whether the query area within the query time is a poor wireless network quality area, as well as several real-time poor wireless network quality categories, based on the regional-level wireless network service indicators.

[0542] A cell-level judgment subunit, connected to a region-level judgment subunit, is used to obtain, within the query time, the cell-level wireless network service indicators of each wireless network cell in the query area relative to the several real-time wireless network quality poor categories if the query area is a wireless network quality poor area, and to obtain several wireless network quality poor cells in the query area within the query time based on the cell-level wireless network service indicators.

[0543] In one embodiment, the apparatus further includes a large network model pre-training module, specifically comprising:

[0544] The data acquisition unit is used to collect historical wireless network data, historical wireless network quality poor category, historical wireless network quality poor diagnosis work order, wireless network quality poor diagnosis expert knowledge, historical wireless network quality poor diagnosis results, and wireless network API interface for obtaining historical wireless network data.

[0545] The fine-tuning unit, connected to the acquisition unit, is used to control the network model. It extracts the thought chain question-and-answer prompts of the network model based on the diagnostic process in the historical poor wireless network quality diagnostic work order. It combines historical wireless network data, historical poor wireless network quality categories, thought chain question-and-answer prompts, and wireless network poor quality diagnostic expert knowledge to output the historical poor wireless network quality diagnostic results. It fine-tunes the parameters of the network model until the network model accurately outputs the historical poor wireless network quality diagnostic results.

[0546] The corresponding unit, connected to the fine-tuning unit, is used to obtain the thought chain question-and-answer prompts corresponding to different historical wireless network quality poor categories and the wireless network API interfaces corresponding to abnormal historical wireless network data in the final large network model.

[0547] In one embodiment, the chain arrangement module 2 specifically includes:

[0548] Chained word units are used to obtain corresponding thought chain question-and-answer prompt words based on the real-time wireless network quality poorness category of each poor wireless network quality cell;

[0549] Chained task units, connected to chained word units, are used to compile a chain of diagnostic subtasks for the root causes of poor quality in each poor-quality cell of a wireless network, based on thought chain question-and-answer prompts.

[0550] The interface call unit, connected to the chained task unit, is used to determine the wireless network API interface that each diagnostic subtask needs to call.

[0551] In one embodiment, wherein:

[0552] Several diagnostic sub-tasks include at least one of the following: fault diagnosis, parameter diagnosis, coverage diagnosis, quality diagnosis, interference diagnosis, capacity diagnosis, and latent fault diagnosis;

[0553] The wireless network API interfaces include at least one of the following: base station alarm API interface, cell performance KPI indicator API interface, base station main control board API interface, cell CM configuration file API interface, cell performance KPI indicator API interface, MR indicator API interface, uplink interference diagnosis small model API interface, and cell B domain service traffic indicator API interface.

[0554] In one embodiment, the diagnostic analysis module 3 specifically includes:

[0555] The diagnostic sequence unit is used to process several diagnostic subtasks sequentially according to the order in the poor quality root cause diagnostic chain.

[0556] The real-time data unit, connected to the diagnostic sequence unit, is used to call the wireless network API interface corresponding to each diagnostic subtask to obtain the corresponding real-time wireless network data.

[0557] The diagnostic output unit, connected to the real-time data unit, is used to combine real-time wireless network data, real-time wireless network quality poorness categories, thought chain question-and-answer prompts, and wireless network quality poorness diagnostic expert knowledge to output the real-time wireless network quality poorness diagnostic results for each diagnostic subtask.

[0558] In one embodiment, the summary output module 4 specifically includes:

[0559] The language output unit is used to output the abnormal root causes and processing suggestions of several poor quality cells in wireless networks by synthesizing the diagnostic results into abnormal diagnostic subtasks according to the order in the poor quality root cause diagnosis chain.

[0560] The instruction output unit, connected to the language output unit, is used to display several poor-quality wireless network cells on a map and mark their root causes of poor quality. Based on the suggestions for handling poor quality, it generates page instructions to repair the root causes of poor quality and executes the page instructions automatically or when triggered by the user.

[0561] Example 3:

[0562] Embodiment 3 of this disclosure provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it implements the wireless network quality poor analysis and processing method as described in Embodiment 1, or the wireless network quality poor analysis and processing device as described in Embodiment 2.

[0563] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program units, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.

[0564] Additionally, this disclosure may also provide a computer device including a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the wireless network quality poor analysis processing method as described in Embodiment 1. This computer device may be the wireless network quality poor analysis processing apparatus as described in Embodiment 2.

[0565] The memory is connected to the processor. The memory can be flash memory, read-only memory or other types of memory. The processor can be a central processing unit or a microcontroller.

[0566] Embodiments 1-3 of this disclosure provide a method, apparatus, and computer-readable storage medium for analyzing and processing poor wireless network quality. Employing a large-scale intelligent agent model, it provides a highly intelligent network optimization auxiliary tool. By recognizing the user's problem intent, it initiates root cause diagnosis of poor wireless network quality. Through the compilation of a root cause diagnosis chain, it decomposes the diagnostic tasks and then synthesizes the diagnostic results to obtain the root causes of poor wireless network quality and processing suggestions. This tool can assist network optimization engineers in completing network optimization work and improve network optimization efficiency.

[0567] It is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of this disclosure, and this disclosure is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this disclosure, and these modifications and improvements are also considered to be within the scope of protection of this disclosure.

Claims

1. A method for analyzing and processing poor wireless network quality, characterized in that, The method is applied to intelligent agent AI agents, including the use of large network models: Identify the user's inquiry intent regarding poor wireless network quality in the question, and obtain several poor wireless network quality cells that need to be analyzed to answer the user's question; A quality poor root cause diagnostic chain is developed to answer user questions. The quality poor root cause diagnostic chain includes several diagnostic sub-tasks for each poor quality cell in the wireless network. Obtain several diagnostic results from several diagnostic subtasks. Each diagnostic result includes the anomaly judgment, root cause of the anomaly, and handling suggestions for each diagnostic subtask. Based on several diagnostic results, obtain the root causes and solutions for several poor-quality wireless network cells, and output answers to user questions based on the root causes and solutions. The method also includes a pre-trained large network model, specifically including: The API interface for collecting historical wireless network data, categories of poor historical wireless network quality, diagnostic work orders for poor historical wireless network quality, expert knowledge on poor wireless network quality diagnosis, diagnostic results for poor historical wireless network quality, and obtaining historical wireless network data. The control network big model extracts the thought chain question-and-answer prompts from the diagnostic process in the historical poor wireless network quality diagnostic work orders. It combines historical wireless network data, historical poor wireless network quality categories, thought chain question-and-answer prompts, and wireless network poor quality diagnostic expert knowledge to output historical poor wireless network quality diagnostic results. The parameters of the network big model are then fine-tuned until the network big model accurately outputs historical poor wireless network quality diagnostic results. Obtain the thought chain question-and-answer prompts corresponding to different historical wireless network quality poor categories and the wireless network API interfaces corresponding to abnormal historical wireless network data in the final network model.

2. The method according to claim 1, characterized in that, Identify the user's intent to inquire about poor wireless network quality, and obtain several poor-quality wireless network cells that need to be analyzed to answer the user's question, specifically including: Receive user questions and extract the inquiry time, inquiry region, and inquiry category from the user questions using keywords; If the inquiry category includes inquiries about wireless network services and / or metrics, determine whether there are any poor-quality wireless network cells in the inquiry area during the inquiry period; If present, determine that the user's question includes an intent to inquire about poor wireless network quality, and obtain the identifiers of several poor wireless network quality cells in the inquiry area within the inquiry time and the real-time wireless network quality category.

3. The method according to claim 2, characterized in that, Determining whether there are poor-quality wireless network cells in the query area within the query period includes: Obtain the regional-level wireless network service indicators for the query area within the query period, and determine whether the query area within the query period is a poor wireless network quality area based on the regional-level wireless network service indicators, as well as the several real-time poor wireless network quality categories. If the query area is a poor wireless network quality area, obtain the cell-level wireless network service indicators of each wireless network cell in the query area within the query time relative to the several real-time poor wireless network quality categories, and obtain several poor wireless network quality cells in the query area within the query time based on the cell-level wireless network service indicators.

4. The method according to any one of claims 1-3, characterized in that, A diagnostic chain for addressing the root causes of poor quality issues is developed to answer user questions. This chain includes several diagnostic sub-tasks for each poor-quality cell in the wireless network, specifically: Based on the real-time wireless network quality poorness category of each poor wireless network quality cell, obtain the corresponding thought chain question and answer prompt words; Based on the question-and-answer prompts in the mind chain, a root cause diagnosis chain for poor quality is developed, which includes several diagnostic sub-tasks for each poor-quality cell in the wireless network. Determine the wireless network API interfaces that each diagnostic subtask needs to call.

5. The method according to claim 4, wherein: Several diagnostic sub-tasks include at least one of the following: fault diagnosis, parameter diagnosis, coverage diagnosis, quality diagnosis, interference diagnosis, capacity diagnosis, and latent fault diagnosis; The wireless network API interfaces include at least one of the following: base station alarm API interface, cell performance KPI indicator API interface, base station main control board API interface, cell CM configuration file API interface, cell performance KPI indicator API interface, MR indicator API interface, uplink interference diagnosis small model API interface, and cell B domain service traffic indicator API interface.

6. The method according to claim 4, characterized in that, Obtain several diagnostic results from several diagnostic subtasks, specifically including: Several diagnostic subtasks are processed sequentially according to the order in the poor quality root cause diagnostic chain; Call the wireless network API interface corresponding to each diagnostic subtask to obtain the corresponding real-time wireless network data; By combining real-time wireless network data, real-time wireless network quality poorness categories, thought chain question-and-answer prompts, and wireless network quality poorness diagnosis expert knowledge, the system outputs real-time wireless network quality poorness diagnosis results for each diagnostic subtask.

7. The method according to claim 6, characterized in that, Based on several diagnostic results, obtain the root causes and remedial suggestions for several poor-quality wireless network cells. Then, based on these root causes and remedial suggestions, output answers to user questions, specifically including: Based on the sequence of the poor quality root cause diagnosis chain, the abnormal root cause and processing suggestions of the diagnosis subtask are integrated into the diagnosis results. The voice and / or text results of the poor quality root cause and poor quality processing suggestions of several wireless network poor quality cells are output. Several poor-quality wireless network cells are displayed on a map, and their root causes are marked. Based on the suggestions for handling poor quality, page instructions for fixing the root causes of poor quality are generated and executed automatically or when triggered by the user.

8. A wireless network quality poor analysis and processing device, characterized in that, The device includes an AI agent, which includes a large network model, which includes: The intent recognition module is used to identify the user's query intent regarding poor wireless network quality and to obtain several poor wireless network quality cells that need to be analyzed in order to answer the user's question. The chained orchestration module, connected to the intent recognition module, is used to compile a poor quality root cause diagnosis chain to answer user questions. The poor quality root cause diagnosis chain includes several diagnostic sub-tasks for each poor quality cell in the wireless network. The diagnostic analysis module, connected to the chained orchestration module, is used to obtain several diagnostic results from several diagnostic subtasks. Each diagnostic result includes the anomaly judgment, root cause of the anomaly, and handling suggestions for each diagnostic subtask. The summary output module, connected to the diagnostic analysis module, is used to obtain the root causes and handling suggestions for several poor-quality wireless network cells based on several diagnostic results, and output answers to user questions based on the root causes and handling suggestions. The device also includes a large network model pre-training module, specifically comprising: The data acquisition unit is used to collect historical wireless network data, historical wireless network quality poor category, historical wireless network quality poor diagnosis work order, wireless network quality poor diagnosis expert knowledge, historical wireless network quality poor diagnosis results, and wireless network API interface for obtaining historical wireless network data. The fine-tuning unit, connected to the acquisition unit, is used to control the network model. It extracts the thought chain question-and-answer prompts of the network model based on the diagnostic process in the historical poor wireless network quality diagnostic work order. It combines historical wireless network data, historical poor wireless network quality categories, thought chain question-and-answer prompts, and wireless network poor quality diagnostic expert knowledge to output the historical poor wireless network quality diagnostic results. It fine-tunes the parameters of the network model until the network model accurately outputs the historical poor wireless network quality diagnostic results. The corresponding unit, connected to the fine-tuning unit, is used to obtain the thought chain question-and-answer prompts corresponding to different historical wireless network quality poor categories and the wireless network API interfaces corresponding to abnormal historical wireless network data in the final large network model.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the wireless network quality poor analysis and processing method as described in any one of claims 1-7.

Images