Wireless network performance optimization system and method
The wireless network performance optimization system addresses inefficiencies in traditional drive tests by automating and standardizing procedures with a common database and AI-driven geospatial intelligence, improving network performance and reducing costs.
Patent Information
- Application Number
- JP2023527339
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-10-31
- Filing Date
- 2020-12-30
- Publication Date
- 2025-08-15
- Estimated Expiration
- 2040-12-30
AI Technical Summary
Traditional drive test procedures for wireless network deployment are labor-intensive, non-standardized, prone to human error, and lack integration with diverse data sources, leading to inefficiencies, increased costs, and environmental impact.
A wireless network performance optimization system that includes a field process automation module, network performance data analysis module, and management module, utilizing a common database and vendor-agnostic data collection, real-time data analysis, and AI-driven geospatial intelligence to standardize and automate drive tests.
Reduces human error, optimizes network performance, lowers costs, and enhances data accuracy and integration with diverse data sources, enabling real-time insights and efficient drive test procedures.
Smart Images

Figure 0007724285000001 
Figure 0007724285000002 
Figure 0007724285000003
Abstract
Description
[Technical Field]
[0001] The present subject matter relates generally to facilitating the transmission of high quality signals to mobile phone users, and more particularly to systems and methods for wireless network rollout and performance optimization by improving drive test procedures. [Background technology]
[0002] Wireless network deployment and performance evaluation are core to delivering a quality experience to mobile subscribers. Drive testing is one of the key steps in this process, but the effectiveness of this process is declining exponentially. Traditional drive testing procedures are highly labor-intensive, requiring multiple teams from multiple vendors to work on different aspects of the same task using different drive test solutions. This results in absolute non-standardization of the process, making it a nightmare when it comes to data collection and / or processing. The various processes in traditional systems, including field processes, drive test solutions, and centralized processes, do not represent an integrated approach and occur in silos. Non-integrated, siloed operations lead to significant time inefficiencies, resulting in the industry-wide search for alternatives to drive testing.
[0003] Typically, the drive test process involves multiple teams from multiple vendors, employing different drive test solutions for the same task. The entire process is manual and involves a high amount of human intervention, raising the possibility of human error and data tampering. The existing process lacks standardization to accommodate multiple standards, resulting in inefficient data analysis and an ineffective extension of the acceptance timeline, affecting the overall project economics. Furthermore, the existing systems and processes do not allow for real-time visualization of the complete set of KPIs / data or context-sensitive drill-downs. This leads to inaccuracies in on-site decision-making, resulting in the rejection of activities already performed, the reworking of planned activities, and timeline delays. This makes the overall process ineffective, leading key stakeholders to consider alternatives. Activity rejections, inaccurate rerun decisions, and the inability to use guided shortest paths due to close monitoring all increase the time and distance required to complete a task. For example, assume a single operator performs approximately 250 drive tests, with various teams performing on-ground data collection. If each team drives just one extra hour per day, at an average speed of 30km / h, that amounts to an extra 7,500km each day. This equates to an extra 750L of fuel consumed each day. At an average cost of 80 rupees per litre, this translates to an extra cost of 60,000 rupees per day, or approximately 21.6 million rupees per year. Taking into account global driving tests, this figure rises exponentially with each test passed.
[0004] Globally, governments are promoting clean energy and fuel consumption reduction in an attempt to reduce pollution and carbon footprints. Traditional drive test processes do not allow for setups that support carbon footprint reduction. Furthermore, business and carrier needs change frequently over time. Typically, carriers require a 360-degree view of network performance. However, drive tests performed with traditional systems are based solely on network performance optimization and are limited to field drive test data. There is currently no solution in the art that can integrate field drive tests with additional data sources, such as crowdsourced data and open-source data.
[0005] One of the challenges with the traditional process is ensuring that all key stakeholders give the drive test process the right and appropriate importance and attention. Over the years, due to inefficient operations and stakeholders exploring other options, the traditional process has been deemed non-technical, ineffective, and not adding value. Traditional processes involve on-site processes, centralized processes, and solutions, with large gaps in thought processes, experiences, and expectations among the people involved. Furthermore, there is a complete lack of consideration for these differences, as well as the problems faced by others involved in the process.
[0006] Furthermore, every vendor involved in the process has its own file formats, databases, post-processing solutions, etc. Even within the same solution provider, there is no universal, one-size-fits-all database, making it nearly impossible to tackle artificial intelligence and machine learning for predictive analytics, etc.
[0007] Therefore, there is a well-felt need for a system and method that overcomes the above and other related challenges, while providing automation and real-time insight into drive test data and then building analytical insights thereon. Summary of the Invention [Problem to be solved by the invention]
[0008] overview The purpose of the present subject matter is to provide a common database and file format for drive test procedures.
[0009] Another object of the present subject matter is to provide a hyper-scalable database architecture configured to handle multi-vendor and multi-source data.
[0010] Yet another objective of the present subject matter is to build an adaptation layer that converts vendor data from different file formats into a common database format and changes the data storage / structure to meet the needs and requirements of big data analytics and Artificial Intelligence (AI) / Machine Learning (ML) root cause analysis and prediction.
[0011] It is yet another object of the present subject matter to substantially reduce human error and artificial inefficiencies in drive test procedures.
[0012] It is yet another object of the present subject matter to provide a system and method for wireless network performance optimization that can be adopted by almost any region and country with great ease and a user-friendly Graphical User Interface (GUI).
[0013] It is yet another object of the present subject matter to provide a user-friendly process and system for accurately recording every on-site activity from start to finish in a highly detailed manner during the drive test process.
[0014] It is yet another object of the present subject matter to generate and present accurate, real-time reports for each completed activity in the drive test process. [Means for solving the problem]
[0015] The present invention is designed to improve network performance field processes, network performance solutions, network performance data analysis as well as management information, thereby leading to significant savings in total cost of ownership while improving the quality of drive test procedures.
[0016] The subject matter relates to a wireless network performance optimization system comprising: a field process automation module configured to automate field processes in a drive test procedure; a network performance data analysis module configured to perform centralized automated analysis on data obtained from the field process automation module; and a management module configured to manage the field process automation module and the network performance data analysis module.
[0017] In one embodiment of the present subject matter, the field process automation module further includes a hardware check module, a license validation and setup module, a route determination module, a geofencing module, a vendor agnostic module, and a data collection module.
[0018] In another embodiment of the present subject matter, the hardware check module is configured to evaluate all necessary components and, if corrections are required, issue an alarm even before the field team begins action.
[0019] In yet another embodiment of the present subject matter, the license validation and setup module includes multiple pre-build scripts and is configured to check software versions and set compatible settings from a central location.
[0020] In yet another embodiment of the present subject matter, the route determination module is configured to determine the shortest path or route to the starting point of the drive test, providing route MAP automation / centralization.
[0021] In yet another embodiment of the present subject matter, the geofencing module is configured to prevent the drive test team from diverting to undesirable locations and starting data collection before they should.
[0022] In yet another embodiment of the present subject matter, the vendor agnostic module is configured to standardize the field data collection process in a common database.
[0023] In yet another embodiment of the present subject matter, the data collection module is configured to automate data collection by creating a series of test cases, and to create and automatically upload data for each unit test case.
[0024] In yet another embodiment of the present subject matter, the network performance data analysis module includes an integrated crowd-sourced data module, an automated analysis platform, and a network performance scoring module.
[0025] In yet another embodiment of the present subject matter, the integrated crowdsourced data module is configured to provide a real 360-degree view of Geospatial Intelligence of network performance data with associated customer experience data.
[0026] In yet another embodiment of the present subject matter, the automated analysis platform is configured to provide correlated, context-sensitive Layer 3 (L3) message drill-down to address related issues.
[0027] In yet another embodiment of the present subject matter, the network performance scoring module is configured to compare the gold standard performance with the current performance, thereby generating a rank for the operator.
[0028] In yet another embodiment of the present subject matter, the system further comprises a network performance data repository for trending network performance.
[0029] In yet another embodiment of the present subject matter, the system employs a machine learning (ML) and artificial intelligence (AI) driven approach with geospatial intelligence driven algorithms to store data in the network performance data repository.
[0030] In yet another embodiment of the present subject matter, the system further comprises a big data architecture configured to rapidly scan and capture data of interest.
[0031] The present subject matter also provides a wireless network performance optimization method that includes automating field processes in a drive test procedure; performing centralized automated analysis on data obtained from the automated field processes; and managing the field process automation module and the network performance data analysis module.
[0032] The invention, both as to its organization and method of operation, together with further objects and advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings, in which: These and other details of the invention will be described in relation to the accompanying drawings, which are given for illustration purposes only and not for limitation of the invention: [Brief explanation of the drawings]
[0033] [Figure 1]1 shows a block diagram of a wireless network performance optimization system according to a preferred embodiment of the present subject matter; [Figure 2] FIG. 2 is a block diagram of a network performance data analysis module according to a preferred embodiment of the present subject matter. [Figure 3] FIG. 2 is a block diagram of a network performance data analysis module according to a preferred embodiment of the present subject matter. [Figure 4] 1 illustrates an architecture of a wireless network performance optimization system according to one embodiment of the present subject matter. [Figure 5] FIG. 2 illustrates a flowchart of a site task allocation process in a wireless network performance optimization system according to one embodiment of the present subject matter. [Figure 6] 1 is a flowchart illustrating pre-checks performed before data collection in a wireless network performance optimization system in accordance with one embodiment of the present subject matter. [Figure 7] 1 is a flowchart illustrating a data collection process in a wireless network performance optimization system according to one embodiment of the present subject matter. [Figure 8] 1 is a flowchart illustrating data processing in a wireless network performance optimization system according to one embodiment of the present subject matter. [Figure 9] 1 is a flowchart illustrating a 360-degree analysis of a wireless network performance optimization system in accordance with one embodiment of the present subject matter. DETAILED DESCRIPTION OF THE INVENTION
[0034] Detailed explanation Detailed descriptions of various embodiments of the present subject matter are provided below with reference to the accompanying drawings.
[0035] The embodiments of the present subject matter will be described in detail with reference to the accompanying drawings. However, the present subject matter is not limited to these embodiments, which are merely provided to more clearly explain the present subject matter to those skilled in the art of the present disclosure. In the accompanying drawings, like reference numerals are used to indicate like components.
[0036] In some places in this specification, reference may be made to "an," "one," "different," or "some" embodiment(s). This does not necessarily mean that each such reference is to the same embodiment(s) or that the feature applies only to a single embodiment. Single features of different embodiments may be combined to provide other embodiments.
[0037] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless expressly stated otherwise. It is further understood that as used herein, the terms "includes," "comprises," "including," and / or "comprising" identify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or additional of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. When an element is described as being "attached" or "connected" or "coupled" or "mounted" to other elements, it is understood that it can be directly attached, connected, or coupled to the other elements, or intervening elements may be present. As used herein, the term "and / or" includes any and all combinations and arrangements of one or more of the associated listed items.
[0038] The diagram is a simplified structure showing only some elements and functions, and all are logical units, and the implementation may differ from the illustration.
[0039] The present invention provides a system and method for globally optimizing the entire drive test procedure, improving wireless network performance and ensuring the highest level of customer experience through improved quality and reduced total cost of ownership (TCO). Not only does the present invention improve quality and reduce TCO, but a constant communication link with on-site technicians ensures that any necessary corrective actions are taken immediately. The present invention can reduce the end-to-end time required to perform a drive test procedure through process optimization, including, but not limited to, reducing the number of re-drives, by closely monitoring the activities of one or more on-site drive test technicians. By reducing the number of re-drives, the present invention contributes to reducing the number of miles traveled during the drive test, thereby optimizing fuel consumption. In this way, the present invention contributes to the telecommunications industry's carbon footprint reduction goals.
[0040] The present invention is configured to holistically integrate field and centralized processes, provide a broad view, and provide integrated, correlated, and contextual geospatial analysis that encompasses a wide range of methodologies, including over-the-air (OTA) app-based data collection, crowd-sourced data collection, and operational support system (OSS) data, along with drive test data.
[0041] For the purposes of this specification, the terms "drive test team" and "field team" will be used interchangeably hereinafter. Also, the terms "drive test" and "field test" will be used interchangeably hereinafter.
[0042] 1 is a block diagram of a wireless network performance optimization system 10 in accordance with a preferred embodiment of the present subject matter. System 10 in accordance with the present invention includes multiple modules or subsystems. For example, without limiting the scope of the present invention, the main modules of the system include a field process automation module 100, a network performance data analysis module 200, and a management module 300.
[0043] The on-site process automation module 100 is configured to automate on-site processes in a drive test procedure. In a preferred embodiment, the on-site process automation module 100 further comprises, but is not limited to, a hardware check module 102, a license validation and setup module 104, a route determination module 106, a geofencing module 108, a vendor agnostic module 110, and a data collection module 112.
[0044] In a preferred embodiment, the hardware check module 102 is configured to evaluate all necessary components and, if any corrections are necessary, the hardware check module 102 is configured to raise an alarm even before the team departs for the field test activity. This can be handled at the local site, so the team does not lose time in the field, especially for hardware-related issues, while performing the field test activity. In one embodiment, the license validation and setup module 104 includes, but is not limited to, multiple pre-built scripts. The license validation and setup module 104 is configured to verify the software versions of all handsets and systems. This module 104 is configured to perform compatible configuration from a central location, thereby ensuring that the data used during the data collection activity is nearly 100% correct and complete, and that there are no delays in the execution of the data collection activity.
[0045] In a preferred embodiment, the route determination module 106 is configured to determine the shortest path or route to the starting point and provide route map automation / centralization. The time it takes for the field team to arrive at the starting point where data collection activities begin is an important aspect of the drive test procedure. The route determination module 106 is configured to assign tasks to the field team while plotting their current location and providing them with an automated route map. This automated route map serves as the shortest path to reach the starting point from their current location. The route determination module 106 not only provides the shortest path to the field team, but also tracks whether the field team is following the shortest path. In this way, a central team in constant communication with the field team can immediately alert the field team and bring them back on the desired route.
[0046] In a preferred embodiment, the geofencing module 108 is configured to prevent drive test teams or field teams from detouring to undesirable locations and starting to collect data before they should. As soon as the drive test team following the shortest route arrives at the starting location, the geofencing module 108 triggers an alarm and the central team unlocks data collection from the field teams. This minimizes junk data collection and the significant overhead associated with processing and analyzing junk data.
[0047] To overcome the challenges of data collection being prone to human error and non-standardization of the same activity from different locations, a vendor-agnostic module 110 is provided. In a preferred embodiment, the vendor-agnostic module 110 is configured to standardize the field data collection process in a common database, thereby improving the quality of data collection and enabling more efficient processing of such data.
[0048] The size of data collected for uploading at the end of each activity varies greatly. With a sudden influx of many large files, data processing can become plagued by resource-related issues, resulting in significant delays. Sometimes, file imports can even fail. Furthermore, if log processing is performed locally by field teams, the process is again non-standardized and prone to human error. Furthermore, the overall manual effort leaves room for data manipulation. To optimize data collection and standardization, the data collection module 112 not only automates data collection by creating sequences of test cases that run serially or in parallel, but also creates and automatically uploads data for each unit test case. This significantly reduces the size of data entering the central server, largely avoids backhaul-related issues, and ensures that the central server, which processes these log files virtually in real time, is always in a healthy state. This also ensures that end-to-end data is available to customers in a very short timeframe, preferably within 5-8 minutes of activity completion, and allows rolling data from ongoing tests to be viewed in custom-built Tableau dashboards and / or web portal views, preferably with a maximum lag of approximately 5-8 minutes in some embodiments.
[0049] In one embodiment, users access a Tableau dashboard via their application server login. This limited-access dashboard provides access to reports configured under the user's access rights. In one embodiment, the dashboard automatically presents a report with a cover sheet containing activity details (if the activity passed all criteria, if any criteria failed, and any possible reasons for failure) and an overall ACCEPT / REJECT status. When such a report becomes available on the Tableau dashboard, the user receives an email with a link to the specific report. In one embodiment, such a report is available to the user within 10 minutes of the completion of the field data collection activity. In one embodiment, access to the same Tableau dashboard is granted to operators, OEMs, and SI personnel, allowing everyone to view the report on a common platform, eliminating guesswork, doubt, and enabling immediate acceptance of the activity. If the report reveals that further activity is required on-site, the field team can be notified and a conclusion can be reached immediately without the need for re-driving.
[0050] 2 illustrates a block diagram of a network performance data analysis module 200 according to a preferred embodiment of the present subject matter. In a preferred embodiment, the network performance data analysis module 200 is configured to perform centralized automated data analysis and minimize the number of drive test engineers per test team required for the drive test procedure, thereby significantly reducing costs associated with components and man-hours in the overall drive test procedure. The network performance data analysis module 200 includes, but is not limited to, an integrated crowd-sourced data module 202, an automated analysis platform 204, and a network performance scoring module 206, as illustrated in FIG. 3, which illustrates a block diagram of the network performance data analysis module 200 according to a preferred embodiment of the present subject matter.
[0051] The network performance data analysis module 200 is configured to perform all health checks and other checks, as described above. The network performance data analysis module 200 allows a central network operations center (NOC) engineer or team of engineers to have a real-time view of the drive test screen to ensure near-100% accurate data collection. In one embodiment, the central NOC engineer is provided with a consolidated view of the paths being taken by all drive test teams on one unified screen. In a preferred embodiment, multiple alarms are provided that are triggered if any team violates the shortest path or if any test case execution encounters any issues in the field. The central NOC engineer is provided with all the tools and equipment necessary to easily monitor and manage multiple teams in the field on the ground. In one embodiment, the central NOC engineer can monitor and manage approximately 10 teams. However, the number of teams monitored and managed by the central NOC engineer may be greater or less without departing from the scope of the present invention.
[0052] In one embodiment, the network performance data analysis module 200 is also configured to process short log files to create views of key performance indicator (KPI) violation alarms with context-sensitive drill-down. This helps NOC engineers make informed decisions about changes to be implemented at specific sites and / or re-drives to be performed with focused reasoning. In a preferred embodiment, NOC engineers have at least one simple graphical user interface (GUI)-driven screen for customizing test scripts and uploading customized scripts on each drive test technician solution. This ensures that every drive test activity is perfect in every respect, has optimal KPI values, and significantly improves the first-time correct rate of activities performed.
[0053] As industry trends change, it is essential to have a 360-degree view of the network that provides not only network performance information but also a customer experience view. In this regard, in a preferred embodiment, network performance data analysis module 200 includes an integrated crowdsourced data module 202 that includes integrated open source software (OSS) datasets that include highly flexible map-based analysis and field drive test data. Integrated crowdsourced data module 202 is configured to provide a real 360-degree view of geospatial intelligence of network performance data with associated customer experience data.
[0054] In a preferred embodiment, network performance data analysis module 200 includes an automated analysis platform 204. In one embodiment, automated analysis platform 204 is configured to provide correlated, context-sensitive Layer 3 (L3) message drill-down to address any relevant issues while saving significant time and improving quality. In one embodiment, automated analysis platform 204 is configured to provide a deeper understanding of any KPI violations.
[0055] In one embodiment, the network performance data analysis module 200 further comprises a network performance scoring module 206. In a preferred embodiment, the network performance scoring module 206 comprises an ETSI 103.559 compliant network performance scoring platform. In a preferred embodiment, the network performance scoring module 206 is configured to compare current performance to a gold standard performance and thereby generate a rank for the operator. This module 206 allows operators to fast track the acceptance process of tasks provided by vendors. A simple GUI and dashboard-driven visibility allows for easy checking of any single activity. This ensures the system 10 has visibility and the ability to make informed, error-free decisions, thereby directly impacting the customer experience.
[0056] To anticipate customer needs and understand network performance trends, the system 10, in one embodiment, further comprises a network performance data repository. In a preferred embodiment, the system employs a machine learning (ML) and artificial intelligence (AI)-driven approach with geospatial intelligence-driven algorithms to store data in the network performance data repository extremely efficiently, thereby allowing users to retain data for much longer periods of time. In a preferred embodiment, a big data architecture is provided that is configured to quickly scan and capture data of interest from large data repositories. The big data architecture also enables the construction of complex, custom-built GUI-driven queries for visualizing and analyzing network performance, addressing the needs of each customer's time, deployment, and operational strategy. A custom query builder allows for the construction of queries across data sets from any type of source, thereby helping customers improve network performance and verifying benefits by directly correlating improved customer experience to improved network performance. Thus, the system 10 of the present invention combines the power of network performance improvement initiatives and customer experience improvement initiatives.
[0057] In one embodiment, the network performance data analytics module, also referred to as the solution and analytics platform of the present embodiment, is built with algorithms that enable a 360-degree view of data (including but not limited to crowd-sourced data, field drive test / IBS / Walktest / BM data, Over the Air (OTA) app-generated data, and Operational Support System (OSS) data, where custom-defined bin sizes of up to 10m x 10m bins are used for each type of data individually, or a mix of data with context-sensitive linking of data from all sources), and provides distance and time-based zoom in / out capabilities.
[0058] In a preferred embodiment, the management module 300 is configured to provide deep visibility and control over the entire process. In particular, in one embodiment, the management module 300 is configured to perform vendor scoring, team scoring, site scoring, cluster scoring, and drill-down from the entire network to specific sites to provide a greater understanding of bottlenecks in network performance improvement. In a preferred embodiment, the management module 300 includes a backhaul map. In a preferred embodiment, the backhaul map includes a fiber backhaul or fiber layout map. In another embodiment, the backhaul map may include microwave. The integrated backhaul map visualization allows operators to make informed decisions about investments, thereby resulting in an improved return on investment (ROI). In a preferred embodiment, the management module 300 provides details of the adherence score for each market area broken down into efficiency improvement trends, gas and carbon credit savings, market area benchmarks on cost vs. customer experience improvement, network performance improvement, NPS improvement, consolidated view of network performance activity / spending plan vs. marketing plan and demographic change plan, project initiation~rollout-efficiency trends, resource utilization trends-CAPEX / OPEX, human resources, solution resources, adherence score for market lead and adherence score for vendor.
[0059] FIG. 4 illustrates the architecture of a wireless network performance optimization system 400 according to one embodiment of the present subject matter. The system 400 is configured to holistically integrate field and centralized processes using the solution. While providing holistic integration, the system 400, with its broad perspective, provides integrated, correlated, and context-sensitive geospatial analysis covering a wide range of methodologies, including over-the-air (OTA) app-based data collection, crowdsourced data collection, and open-source data, all integrated with drive test data. In one embodiment, the system 400 allows users to assign tasks to teams with deterministic test scripts, shortest routes from bases to starting points, route maps for activities to be performed, and expected test completion times. The system 400 not only provides real-time visualization of the paths the field teams are following, but is also configured to generate alarms if the field teams deviate from the assigned shortest route. Furthermore, in one embodiment, the system is configured to generate geofencing alarms as soon as the field teams arrive at their starting points. Furthermore, Occupational Health and Safety (OHS) compliance for vehicles and field teams ensures that vehicles are operated in accordance with OHS compliance requirements of local laws. Additionally, working at height requires OHS certification and special OHS gear. In a preferred embodiment, in accordance with one embodiment of the present invention, the system is configured to track all activity and raise an alarm if any OHS violations are observed.
[0060] In a preferred embodiment, the main components of the system 400 include, but are not limited to, a centralized database setup 402, a centralized web portal 404, and a drive test setup 406. The centralized database setup 402 is provided in a central location and controlled by a central team. In one embodiment, the central team may include one or more experts. The central team is in constant communication with a field team operating the drive test setup 406 with vehicles. In one embodiment, the central team commands the field team based on observations received by the field team through the centralized web portal 404. In one embodiment, the drive test setup 406 includes at least one NUC, at least one communication device, at least one battery, etc. required for the field test. In another preferred embodiment, the drive setup also includes one or more Android / iOS platforms in the communication device. In a preferred embodiment, the communication device includes, but is not limited to, one or more of a mobile handset, a tablet computer, etc.
[0061] The centralized database setup 402 includes a database containing information about the types of tests required by field teams at specific locations. Based on this information, the centralized database setup 402 automatically generates the desired scripts and sends these scripts to the drive test setup 406 via a centralized web portal 404. In one embodiment, the scripts include, but are not limited to, test scripts, data upload scripts, pre-check scripts, test start / stop commands, etc.
[0062] In one embodiment, the system includes vendor- and solution-agnostic test scripts for different types of test requirements, such as voice call tests from traditional short calls and long calls to typical MOS measurement cases and more advanced CFSB and VoLTE test cases; data tests from typical FTP, HTTP, and Ping tests to video streaming tests and customized application tests. These scripts are vendor-agnostic because they are result- and test-case-oriented. Scripted testing standardizes test setup and test case ordering, eliminating the need for human intelligence to define the types of tests required in the field and the need to spend additional time in the field setting up the required test solutions. Furthermore, these scripts address and are optimized for various test scenarios. In one embodiment, a repository of such scripts is stored in a CVMS. In another embodiment, appropriate test scripts are assigned to field teams according to the test activities they are required to perform.
[0063] In one embodiment, the test script provides a maximum sample of the collected drive test data. Furthermore, the log file is uploaded within a predefined time period, ensuring seamless availability of data for immediate processing. Furthermore, in some embodiments, the size of the log file is defined by time, file size, or activity completion, whichever comes first. For example, if a user programs a log file to rotate every 10 seconds and sets a maximum file size of 10 MB, the script ensures that a log file is created and uploaded to a centralized server every 10 seconds. If the log file size reaches the 10 MB limit before 10 seconds have elapsed, the log file size limit takes precedence, and the file is uploaded to the central server. If the test script is fully executed and the nature of the test case does not generate a log file larger than 10 MB or takes less than 10 seconds to complete, the log file is uploaded when the test case is completed. In this way, the script is intelligent enough to ensure that log files are always generated at the predefined maximum file size. This allows for standardization of testing activities across all vendors and all drive test campaigns, obtaining required KPIs / parameters for each individual drive test campaign, and near real-time visibility of data. Furthermore, data uploads can be completed as activities are completed. This means no time is wasted uploading data, and no data is lost due to file sizes that are too large to upload. Furthermore, infrastructure processing can be better planned with known loads and kept healthy at all times. Furthermore, there are no delays associated with queuing in report generation, and reports are delivered faster due to more efficient activities.
[0064] In a preferred embodiment, the centralized database setup 402 automatically assigns sites or tasks to the drive test team or field team with the drive test setup 406. In another embodiment, route maps and shortest paths are also communicated by the centralized database setup 402 to the drive test team or field team with the drive test setup 406.
[0065] Upon completion of the drive test, the data received from the drive test setup 406 is converted into a desired common format suitable for processing in the centralized database 408 and then transmitted to the centralized database 408. In one embodiment, one or more data adapters 410 including software terminals are provided to convert the data received from the drive test setup 406 into the desired format. Once the data is stored in the centralized database 408 in the desired format, a data processing and KPI population module 412 performs data processing. A machine learning module 414 is configured to detect violations in the system. A central team is configured to monitor multiple drive test teams. A threshold check module 416 is provided to perform real-time monitoring of all parameters and details of each drive test. As data is collected in each drive test and processing of the collected data begins, the threshold check module 416 checks all parameters collected in each drive test. If a parameter collected in a drive test does not meet a threshold, the threshold check module 416 triggers an alarm 418 to the central team to enable the central team to take corrective action. Violations in parameters identified by the threshold check module 416 are analyzed by the machine learning module 414 and fed to an AI-based root cause analysis (RCA) engine 420. In one embodiment, the RCA engine 420 is configured to identify the root cause of the violation, prompt potential causes, and suggest corrective actions to the central team to remediate the violation in the parameter. Meanwhile, the context drill-down module 422, in one embodiment, identifies all other parameters related to the violating parameter that led to the violation. In a preferred embodiment, the context drill-down module 422 displays detailed information about all related parameters to the central team in real time. In one embodiment, information from the context drill-down module 422 is sent directly to the central team for remediation of the violation.In another embodiment, information from the context drill-down module 422 is provided to the RCA engine 420 for further processing before being sent to the central team. In yet another embodiment, information from the context drill-down module 422 is sent directly to the central team as well as to the RCA engine 420. In one embodiment, the central team performs additional testing to identify possible causes and corrective actions to take to fix the violation. Once possible causes and corrective actions are identified, the central team communicates with the field team to fix the violation. In one embodiment, the system allows for the identification and analysis of cause and corrective actions in less than 24 hours, as information gathering and violation correction occurs in real time, instead of the weeks that traditional drive tests would take.
[0066] In one embodiment, these 360-degree analyses can be performed once the analyzed data is available in the centralized database 408. In another embodiment, access to the processed data is given to one or more users or customers through a Tableau web portal 424. In yet another embodiment, users can access the processed data through one or more dashboards, which can be depicted through graphs, charts, text, etc. In a preferred embodiment, the system is configured to give users access to the processed data in real time. Information from the RCA engine 420, the Tableau web portal 424, as well as alarm information, is also sent to a central team through a centralized web portal 426.
[0067] In a preferred embodiment, OSS data is collected in an OSS data server 428 and provided to the centralized database 408 through an OSS data adapter 430. In another preferred embodiment, crowdsourced and over-the-top (OTT) data is collected in a crowdsourced and OTT data server 432 and provided to the centralized database 408 through a crowdsourced and OTT data adapter 434. In yet another embodiment, the system 400 includes multiple staging servers, including a drive test staging server 436, an OSS staging server 438, and a crowdsourced and OTT staging server 440, as temporary hosting and staging servers.
[0068] FIG. 5 illustrates a flowchart of a site task assignment process 500 in a wireless network performance optimization system according to one embodiment of the present subject matter. The site task assignment process 500 begins with step 502, which collects master site data obtained from the OSS data server 428. In a preferred embodiment, the master site data includes network configuration information, such as information about the antenna height, the downward tilt applied to the antenna, the power at which the antenna operates, etc. This is followed by step 504, which integrates the collected master site data with data present in the system's centralized database 408. In this step, the master site data is converted, in one embodiment, into a common format suitable for processing in the centralized database 408. In another embodiment, only necessary information from the master site data is collected in the centralized database 408, while other irrelevant data is rejected in this step. Once the necessary data in the appropriate format has been stored in the centralized database 408, the system checks 506 for any new sites or new towers assigned by the project team. This is followed by comparing information 508 about potential new sites with the data available in the centralized database 408. If new site information is not available in the centralized database 408, the system treats the likely new site as a new site in step 510. The system then integrates 512 the likely new site information with the data available in the centralized database 408 in a manner similar to that performed in step 504. Data integrated by the system in the centralized database 408 includes, but is not limited to, the location and specifications for the new tower. The system then checks 514 whether a neighborhood plan for the site is available and shared. In one embodiment, the neighborhood plan includes, but is not limited to, information about nearby sites or nearby towers, as well as other surrounding information such as driving and network conditions that may affect data collection, etc.If the neighborhood plan is not available and shared in the centralized database 408, the system collects 516 the neighborhood plan and integrates 512 information about the neighborhood plan with the data available in the centralized database 408 in a manner similar to that performed in step 504.
[0069] On the other hand, if the comparison in step 508 determines that there is likely new site information in the centralized database 408, the system treats this information as a revisit of an existing site 518 and transmits this information for further processing. Similarly, if the comparison in step 514 determines 520 that a neighborhood plan is available and shared in the centralized database 408, the system transmits this information for further processing.
[0070] In step 522, the system checks whether a route plan for data collection has been prepared and shared. If a route plan has already been shared, the system uploads 524 the route plan for the drive test. On the other hand, if a route plan is not prepared, the system, in one embodiment, develops 526 a new route plan to share with the field team and then uploads 524 the plan for the drive test. In another embodiment, a route plan is developed 526 and uploaded 524 for the drive test by the central team. Next, the system assigns 528 the shortest route for the field team from their current location or base to the test site and shares this shortest route with the field team. The system also assigns 530 the test script required to perform the drive test to the field team. The system then assigns a site and a task to the drive test team to begin the drive test procedure.
[0071] Before the drive test process begins, the system performs several pre-checks to ensure smooth data collection during the drive test. FIG. 6 is a flowchart depicting pre-checks 600 performed before data collection in a wireless network performance optimization system according to one embodiment of the present subject matter. Sites and tasks are assigned to the drive test team by the central team 602, and in one embodiment, a hardware check is first performed 604. The system checks whether the correct number of handsets are present with the drive test team 606. If it is determined that not enough handsets are available, the system prompts the central team to obtain handsets from the local site 608. Once a sufficient number of handsets are obtained, the system checks the performance of electronic devices such as laptops and NUCs 610. If the performance of at least one electronic device is insufficient, the system, in one embodiment, performs corrective action at the local site 612. In another embodiment, the system prompts the central team to perform corrective action on the electronic devices. Next, the system checks the cable and Internet connections in step 614. If the connections are poor, the system corrects them or prompts the central team to do so in step 616. This completes the hardware health check.
[0072] In one embodiment, hardware health checks include power-on checks at the site, power-on performance checks of the computing system's hard disk, RAM, and BIOS, and periodic monitoring of storage utilization, CPU utilization, RAM utilization, and battery status to ensure healthy system performance through drive test activities. The system performs checks to ensure healthy interconnectivity of all necessary components and checks whether the required number of test handsets are connected to the test system. The number of test handsets can, in one embodiment, be derived from the activities required to be performed at the test location. Hardware health checks ensure 100% uptime of the test system while the data collection team is on-site. This ensures the accuracy of data collection, as inaccuracies in collected data due to test system unhealthiness are addressed by hardware health checks. While improving the accuracy of data collection, hardware health checks with 100% test system uptime can help prevent costly delays in task completion due to system failures. They also result in cost savings because they eliminate the need for additional investment in expensive test systems and prevent wear and tear on the test system.
[0073] Once the hardware sanity check is complete, the system begins a software sanity check 618. In step 620, the system checks the electronics for new software releases and licenses. It is important to ensure that all devices have compatible software installed and healthy network connectivity. It is also important to ensure that all required software licenses are in place and enabled to avoid delays due to software features not being available on the test system. Purchasing and delivering software licenses is a time-consuming task, sometimes leading to delays of many weeks and the need for re-drives. The configuration of drive test solutions continues to change frequently due to a host of other reasons, such as changing project requirements, changing on-site teams, and on-site team rotations. On-site teams are often seen working together for days to ensure that the necessary components are able to communicate with each other healthily. Gaps in the required licenses can lead to further delays.
[0074] If any updates are required in step 620, the system installs the correct software releases and / or licenses in step 622. The system then checks whether the correct open source, firmware and licenses are available for the handset 624. If these licenses are not available, the system installs the correct firmware and licenses on the handset in step 626.
[0075] In one embodiment, the system includes one or more built-in processes that check the software version of the main application, the compatibility of the application software version with the software version of the processing infrastructure, the software version deployed on the test device for compatibility with the required ODM version, etc. Additionally, in one embodiment, the system tests handset communication with a centralized database. In another embodiment, the system checks the preparation and correctness of test scripts, the correctness of data upload scripts, connectivity with the centralized database, and the deployment of unnecessary software applications.
[0076] This comprehensive software check process ensures 100% utilization of each and every drive test on-site resource, delivers projects well ahead of the end date, and increases data collection accuracy while simultaneously achieving data collection efficiency. It also avoids the loss of data that doesn't appear on the back-end data server due to network connection issues. All of this increases data collection accuracy, maximizes drive test resources, reduces drive test costs, and captures the unique benefits of drive testing that traditional systems overlook due to inherent inefficiencies and process delays. Once the software check is complete, the system gives the on-site team permission to begin data collection.
[0077] FIG. 7 shows a flowchart depicting a data collection process 700 in a wireless network performance optimization system according to one embodiment of the present subject matter. The data collection process 700 begins by step 702, in which a drive test vehicle is operated for data collection. Next, the system checks 704 whether the assigned sites and tasks are visible to the field team in the drive test vehicle. In a preferred embodiment, the assigned sites and tasks are available in the field on a centralized vendor management system platform available to the field team's mobile handsets. In another preferred embodiment, the screens of the field team's mobile handsets are replicated to the central team at a central location. If this information is not visible to the field team, the system notifies 706 the central team for remediation. Next, in step 706, the system checks 708 whether the status in the centralized vendor management system platform has been updated to "START." If the status has not been updated, the system notifies 710 the central team for remediation. The system then checks 712 whether the shortest route to the destination is visible to the field team. If not, the system notifies 714 the central team for remediation. Once the shortest route is displayed on the central vendor management system platform, the field team begins driving toward the destination 716. At all stages, the central team, in a preferred embodiment, tracks the vehicle driven by the field team. If the drive test vehicle deviates from the predetermined shortest route, the system identifies it and prompts the central team to communicate with the field team to take corrective action. Just before the drive test vehicle is about to approach the site location, the system activates a geofencing alarm 718. If the geofencing alarm does not activate at the desired moment, the system prompts the central team for correction 720. After the geofencing alarm is activated closer to the site location 718, the central team grants permission for data collection to the field team. In this regard, a script for data collection is enabled in step 722 and uploaded to the system.If the script is not activated and uploaded in time, the system prompts the central team for correction 724. Once the system starts collecting data from the sites, the system status changes to "Working" in step 726. If the status does not change in this step, the system prompts the central team for correction 728. The system then checks whether the entire route was completed as planned 730. If the route is not completed, the system prompts the driver to continue driving 732. Once the route is complete, the status changes to "Complete" and the drive test ends in step 734. At the same time, while the drive test vehicle is on the route, the system checks whether the data upload process is running 736. If the data has not been uploaded, the system prompts the central team for correction 738. Once the data is uploaded, the system checks whether the data is available on the staging server 740. If the data is not available, the system prompts the central team for correction 742. As soon as the data is available on the staging server, the system starts the adaptation layer 744. In one embodiment, the adaptation layer involves finding new data along the vehicle's route. If this step is not initiated, the system prompts the central team to correct it 746. The system then sends the data for processing in step 748.
[0078] FIG. 8 shows a flowchart depicting data processing 800 in a wireless network performance optimization system according to one embodiment of the present subject matter. Data processing 800 begins by checking whether an automatic data processing (ADP) or data adapter is prepared and enabled 802. Next, the system checks whether data is available on a staging server 804. If data is available on the staging server, the system initiates an adaptation layer in step 806. The available data is then converted into a common database format 808. After the data is converted into the common database format, the system checks whether web portal access has been granted to the user 810, and then checks whether all KPIs are visible in the web portal 812. Next, the system checks whether all web portal functions are operational 814 and simultaneously identifies whether any KPI violation alarms have been triggered 816. If no KPI violation alarms have been triggered, the system continues monitoring them in step 818. However, if a KPI violation alarm is triggered, the system initiates a context-sensitive drill-down in step 820, runs the AI / ML-based RCA engine in step 822, makes decisions regarding on-site optimization or re-drive in step 824, and communicates with the drive test team or on-site team in step 826.
[0079] In one embodiment, simultaneously with step 810, the system checks whether Tableau database access has been granted to the customer in step 828 immediately after the data has been converted in a common format. Next, the system checks whether a custom dashboard available to the customer has been populated 830, and then generates a customized report according to the customer's requirements 832. Finally, the system automatically sends the report generated in step 832 to the customer via email or any other communication means 834. In one embodiment, the system outputs a prompt 836 to the central team to rectify if the steps described in 802, 804, 806, 808, 810, 812, 814, 828, and 830 shown in FIG. 8 are not performed.
[0080] In one embodiment, data processing and analysis are performed on an intelligent centralized processing platform that automatically imports all uploaded logs. A data upload test script automatically uploads log files to a centralized database or central server according to configurable time / file size parameters. All imported logs are processed and stored in a unified, common database. In one embodiment, users / central team members log in to an application server that includes a visualization portal. The visualization portal is a web portal where users get near-real-time visualization of KPIs collected from field data collection tools. The web portal also provides integrated visualization of KPIs collected from crowdsourced data, OTA data, and, in one embodiment, field data collection data. Context-sensitive drill-down capabilities enable integrated, context-sensitive analysis of network performance to reach logical conclusions. Users / central team members can then make informed field optimization decisions. The portal allows users / central team members to modify test scripts, direct field data collection teams to re-drive smaller areas, or run specific tests according to the new script for more detailed analysis. As part of a larger network of mobile systems that integrates customer complaints, crowdsourced data, OTA data, OSS data, and field drive test data, the system can identify regions suffering from poor customer experience through a combination of crowdsourced and OTA data and match this with OSS data for those regions. If both the OSS and crowdsourced / OTA data confirm poor performance, users can prioritize detailed troubleshooting drives in the field to address the identified issues.If the OSS data shows no issues but the crowdsourced and OTA data show poor KPIs, the system can check the impact on VIP performance and assign priorities and necessary test scripts to address the issues accordingly. Furthermore, if the OSS data shows no issues and the OTA data shows no issues for outdoor subscribers, but the crowdsourced and OTA data show poor KPIs for indoor / stationary subscribers, this can prompt the user to determine IBS-related tests and set priorities and tests accordingly. Furthermore, integrated analytics also helps users drill down into information at different levels and analyze the results for RCA. The system's context-sensitive L3 drilldown helps identify specific issues down to the protocol level and recommends soft parameter optimization, resource reconfiguration, and more. This leads to improved customer experience, increased spectral efficiency, and maximized bits per Hz without additional investment in network expansion. The machine learning platform learns from issues, different sets of KPI combinations that lead to the issues, parameter settings in the configuration database, and various other pointers to help provide recommendations for automated RCA. The artificial intelligence platform enables predictive intelligence, providing a 360-degree view of network performance with ML-based RCA along with AI-based predictions and recommendations to resolve issues before they happen to your network.
[0081] FIG. 9 shows a flowchart depicting a 360-degree analysis 900 of a wireless network performance optimization system according to one embodiment of the present subject matter. According to one embodiment, the 360-degree analysis 900 is performed simultaneously with the data processing 800. However, in another embodiment, the 360-degree analysis 900 may be performed separately from the data processing 800. The 360-degree analysis 900 begins at step 902, in which the system checks whether all adaptation scripts are prepared and valid. Next, the system checks whether the crowd-sourced data, OTA data, and OSS data are available on the staging server 904. The system then invokes the adaptation layer to convert the data to a common format 908. Once the data is converted to a common format, the system checks whether the user is authorized to access the web portal 910 and whether the combined KPIs are displayed on the web portal 912. The system then checks whether all web portal functions are operational 914 and simultaneously checks whether any KPI violation alarms have been triggered 916. If no KPI violation alarms have been triggered, the system continues monitoring them at step 918. However, if a KPI violation alarm is triggered, the system initiates a context-sensitive drill-down in step 920, runs an AI / ML-based RCA engine in step 922, makes decisions regarding field optimization and re-drives in step 924, and communicates with the drive test team or field team in step 926. In one embodiment, the system outputs a prompt 928 to the central team to rectify if the steps described in 902 to 914 shown in Figure 9 are not performed.
[0082] Therefore, the system provides a futuristic, scalable, common database architecture capable of handling multi-vendor and multi-source data, converting all vendor data coming from different file formats into a common database format, and building an adaptation layer to change data storage / structure to meet the needs and demands of big data analytics and AI / ML-driven root cause analysis and prediction.
[0083] A 360-degree view of network performance is important for improving customer experience, optimal resource utilization, and spectral efficiency. A unified common database serves as a key building block by importing crowd-sourced data and converting it into a pre-defined architecture for data storage. The OTA app collects network performance data from every single mobile subscriber who has the app installed, without revealing any confidential subscriber information. The unified database stores measurements from the OTA app in the same data storage architecture. The unified database has the capability to import network performance counters, configuration data, and fault / alarm data from OSS systems and store them within the common database data storage.
[0084] The system combines RAN performance information from test-script-driven field data collection campaigns, supplemented by OTA and crowdsourced data, to provide detailed information on wireless network performance. Binned KPI values report not only customer-experienced KPIs, but also KPI values presented by specific, detailed field data collection activities. A next-generation, hyperscalable big data architecture can quickly search data from the database by time, location, or other dynamics, providing important geospatial analytics capabilities. As data becomes increasingly important, the system's data lake architecture, with its north-south APIs, can integrate the system's data with other value-added solutions, consolidating strengths, increasing profits, and providing the support needed to drive digitalization.
[0085] As can be seen, the present invention provides 100% automation and process standardization for drive test procedures and includes multi-technology drives. The present invention is fully scalable to 2G, 3G, 4G, 5G, SSV, cluster, IBS, and BM drives. By reducing manual human intervention, the present system enables fully autonomous drives. By employing the present system and method, complete automation of field processes and field data collection can be achieved. Furthermore, the present invention enables scripted data testing and scripted log upload. The present invention provides instant data visibility, enabling users to make immediate, on-site decisions with high accuracy. In one embodiment, the present invention enables end-to-end report generation within a short timeframe, preferably within five minutes of the completion of the drive test activity. Because the entire process is automated and requires no human intervention, the possibility of data tampering is significantly reduced. With maps, tables, graphs, KPI exception analysis, and context-sensitive L3 drill-down, the present invention provides near-real-time RCA and recommendations. Dashboard-based report visualization, KPI exception reporting, and ETSI scoring for activities ensure immediate process acceptance. Furthermore, the present invention ensures that junk data is not collected and processed. The present invention allows users to make informed decisions about re-drives, thereby reducing the number of re-drives by more than 60%. Reduced driving requirements, controlled travel using the shortest route, and other remote management functions significantly shorten on-site driving time, resulting in cost savings and improved carbon credits. Therefore, the present invention ensures significant time efficiency by technically supporting on-site teams to arrive at the starting point using the shortest route. It also ensures improved data collection accuracy by defining route maps, test cases, and geofencing. Furthermore, autonomous driving can assist society as a whole, even during pandemic situations such as COVID-19.
[0086] While preferred embodiments of the present invention have been described herein, it should be understood that various changes, adaptations, and modifications may be made therein without departing from the spirit of the invention and the scope of the appended claims. It will be apparent to those skilled in the art that the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive.
Claims
1. 1. A wireless network performance optimization system comprising: an on-site process automation module configured to automate an on-site process in a drive test procedure; a network performance data analysis module configured to perform centralized automated analysis on data obtained from the field process automation module; and a management module configured to provide managing the field process automation module and the network performance data analysis module; The field process automation module includes a system: a hardware check module, wherein the hardware check module is configured to evaluate all necessary components and raise an alarm if correction is required, even before the field team begins their activities; a license verification and setup module, wherein the license verification and setup module is configured to verify the software versions of all handsets and systems; a route determination module, wherein the route determination module is configured to determine a shortest path or route to a starting point of the drive test and configured to provide automation / centralization of a route map; a geofencing module, wherein the geofencing module is configured to prevent the drive test team from diverting to undesirable locations and starting data collection before they should; a vendor-agnostic module, wherein the vendor-agnostic module is configured to standardize field data collection processes in a common database; and a data collection module, wherein the data collection module is configured to automate data collection by creating a series of test cases, and to create and automatically upload data for each unit test case;
2. The license verification and setup module: further comprising a plurality of pre-build scripts; and 10. The system of claim 1, configured to verify software versions and configure compatible settings from a central location.
3. The system of claim 1 or 2, further comprising a big data architecture configured to scan and capture data of interest.
4. A method for optimizing wireless network performance, comprising: automating field processes in a drive test procedure by the field process automation module of the system of claim 1; performing centralized automated analysis on data obtained from the automated field process by the network performance data analysis module of the system of claim 1; and 10. The system of claim 1, wherein the field process automation module and the network performance data analysis module are managed by a management module.
Citation Information
Patent Citations
Travel route searching support system, travel route searching support device, and program
JP2004085537A
Network test system and method
JP2007534208A
Network testing method, its data collection method, network testing device, and system
JP2016527786A
Public fare market simulation system and public fare market display method
JP2020518087A
Quality-directed adaptive analytic retraining
US20160371601A1