WO2025017754A1

WO2025017754A1 - Method and system for identifying root cause of call failures in a network

Info

Publication number: WO2025017754A1
Application number: PCT/IN2024/051337
Authority: WO
Inventors: Aayush Bhatnagar; Ankit Murarka; Jugal Kishore Kolariya; Gaurav Kumar; Kishan Sahu; Rahul Verma; Sunil Meena; Gourav Gurbani; Sanjana Chaudhary; Chandra Kumar Ganveer; Supriya De; Kumar Debashish; Tilala Mehul
Original assignee: Jio Platforms Ltd
Current assignee: Jio Platforms Ltd
Priority date: 2023-07-20
Filing date: 2024-07-20
Publication date: 2025-01-23
Anticipated expiration: 2026-01-20

Abstract

The present disclosure relates to a system (120) and a method (400) for identifying the root cause of call failures in a network (105) is disclosed. The system (120) includes a data accessing module (220) configured to access Call Detail Record (CDR) data stored in a File System (FS) (215). The system (120) includes a data retrieval module (225) configured to retrieve data related to failed calls from the accessed CDR data. The system (120) includes an analyzing module (230) configured to analyze the retrieved failed call data to identify reasons for the call failures. The system (120) includes a clustering module (235) configured to generate clusters of the failed calls based on predefined policies or rules using an analysis engine (330). The system (120) includes a reason identification module (240) configured to identify root cause for the call failures within each cluster.

Description

METHOD AND SYSTEM FOR IDENTIFYING ROOT CAUSE OF CALL FAILURES IN A NETWORK

FIELD OF THE INVENTION

[0001] The present invention generally relates to wireless communication networks, and more particularly relates to a method and system for identifying the root cause of call failures in the wireless communication network.

BACKGROUND OF THE INVENTION

[0002] A Telecommunications Service Provider (TSP) is a communications service provider that provides telephone and similar services. For example, local exchange carriers, mobile wireless communication companies, etc. With the exponential growth and demand in telecom, there are more service providers entering the market every day. A subscriber is free to choose a telecom service provider and with number portability coming into picture, it has become even easier and convenient for the subscriber to shift from one telecom service provider to another. Different service providers may differ in terms of service quality, tariff, coverage, etc.

[0003] There may be a number of reasons for the call failure. Sometimes dropped calls are caused by known reasons such as a low battery. If the subscriber receives a huge number of calls, the network operator may realize that the calls are initiated by auto bots. The auto bots are configured to initiate and manage the calls without human intervention. When the auto bots make huge number of calls, it may lead to issues such as, network congestion, revenue loss, and customer experience degradation. The network congestion caused by the auto bots affects the experience of other subscribers in the same area. The subscribers may experience dropped calls, poor call quality, and slower data services due to the overloaded network. The network congestion results in slower network performance and poor service quality for all subscribers. [0004] Further, each call initiated by the auto hots incurs a cost, especially when the calls are terminated on other networks. Also, as an example, it may so happen that traffic coming from a First Service Provider (FSP) may be large and sometimes huge as compared to the load that the number of "Interconnection Point" or POI provided by a Second Service Provider (SSP) may take.

[0005] Each network service providers, such as the FSP and the SSP, has a fixed number of interconnection points therebetween. In certain cases, when the auto bots initiate multiple calls from the FSP to the SSP, there may be chances of network congestion in the network of the SSP. This network congestion maybe due to congestion at the interconnection points, and further leading to call failures. Also, the excessive calling by the autobots, operating at other network operator may lead to significant expenses without corresponding revenue generation, impacting the financial health of a service provider.

[0006] In other cases, your device's software may need updating to provide bug fixes. Alternatively, the device's physical hardware might be malfunctioning. If a phone's antenna or sim card has been damaged, this can make dropped calls and other problems more likely. It is desired that to know the actual reason for the call failure so that the same can be addressed. This is important both for better user experience and customer quality improvement for the telecom operators in the competitive market.

[0007] There is therefore a need for a solution that provides a system and method for identifying and detecting the actual reason/root cause for call failures in the network.

SUMMARY OF THE INVENTION

[0008] One or more embodiments of the present disclosure provide a method and a system for identifying the root cause of call failures in a network.

[0009] In one aspect of the present invention, the method for identifying the root cause of call failures in the network is disclosed. The method includes the step of accessing, by a one or more processor(s), Call Detail Record (CDR) data stored in a File System (FS). The method includes the step of retrieving, by the one or more processor(s), data related to failed calls from the accessed CDR data. The method includes the step of analyzing, by the one or more processor(s), utilizing an analysis engine, the retrieved failed call data to identify reasons for the call failures. The method includes the step of generating, by the one or more processor(s), clusters of the failed calls based on predefined policies or rules using the analysis engine, wherein each cluster represents a categorization of failed calls based on their identified reasons for failure. The method includes the step of identifying, by the one or more processor(s), root cause for the call failures within each cluster.

[0010] In one embodiment, the step of retrieving includes filtering the CDR data to isolate specific call failure indicators, including call completion status, call duration, number of calls, call frequency, and call ratio.

[0011] In another embodiment, the step of analyzing further comprises determining the call completion status for each failed call within the retrieved data.

[0012] In yet another embodiment, the step of generating includes classifying the failed calls into clusters based on the frequency of failed calls per user or entity within a specified time frame.

[0013] In yet another embodiment, the clusters are formed based on predetermined ranges of failed call occurrences.

[0014] In yet another embodiment, the step of identifying involves using the analysis engine to identify specific network issues, service provider limitations, or external factors contributing to the high incidence of failed calls in each cluster

[0015] In yet another embodiment, the step of updating the analysis engine based on the identified reasons for call failures. [0016] In yet another embodiment, the step of implementing corrective actions in the network based on the identified root causes of call failures.

[0017] In yet another embodiment, the root cause includes the step of identifying the major and actual reason for the call failures within each cluster.

[0018] In another aspect of the present invention, the system for identifying the root cause of call failures in a network is disclosed. The system includes a data accessing module configured to access Call Detail Record (CDR) data stored in a File System (FS). The system includes a data retrieval module configured to retrieve data related to failed calls from the accessed CDR data. The system includes an analysis engine configured to analyze the retrieved failed call data to identify reasons for the call failures. The system includes a clustering module configured to generate clusters of the failed calls based on predefined policies or rules using the analysis engine. Each cluster represents a categorization of failed calls based on their identified reasons for failure. The system includes a reason identification module configured to identify root cause for the call failures within each cluster.

[0019] In yet another aspect of the present invention, a non-transitory computer- readable medium having stored thereon computer-readable instructions that, when executed by a processor is disclosed. The processor is configured to access Call Detail Record (CDR) data stored in a File System (FS). The processor is configured to retrieve data related to failed calls from the accessed CDR data. The processor is configured to analyze the retrieved failed call data to identify reasons for the call failures. The processor is configured to generate clusters of the failed calls based on predefined policies or rules using the analysis engine. Each cluster represents a categorization of failed calls based on their identified reasons for failure. The processor is configured to identify the root cause for the call failures within each cluster. [0020] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all- inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0022] FIG. 1 is an exemplary block diagram of an environment for identifying the root cause of call failures in a network, according to one or more embodiments of the present disclosure;

[0023] FIG. 2 is an exemplary block diagram of a system for identifying the root cause of call failures in the network, according to one or more embodiments of the present disclosure; [0024] FIG. 3 is an architecture of the system for identifying the root cause of call failures in the network, according to one or more embodiments of the present disclosure; and

[0025] FIG. 4 is a flow diagram illustrating a method for identifying the root cause of call failures in the network, according to one or more embodiments of the present disclosure.

[0026] The foregoing shall be more apparent from the following detailed description of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0027] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.

[0028] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.

[0029] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.

[0030] The present disclosure is about identifying the root cause for call failure for a service provider in a network based upon the data in a Call Detail Record (CDR). The invention comprises an Al (Artificial Intelligence)/ ML (Machine Learning) model for monitoring and analyzing the failed calls in the network from the CDR.

[0031] FIG. 1 illustrates an exemplary block diagram of an environment 100 for identifying the root cause of call failures in the network 105, according to one or more embodiments of the present disclosure. The environment 100 includes the network 105, a User Equipment (UE) 110, a server 115, and a system 120. The UE 110 aids a user to interact with the system 120 for identifying the root cause of call failures in the network 105. In an embodiment, the user includes, but not limited to, a service provider.

[0032] As per the illustrated embodiment and for the purpose of description and explanation, the description will be explained with respect to the UE 110, or to be more specific will be explained with respect to a first UE 110a, a second UE 110b, and a third UE 110c, and should nowhere be construed as limiting the scope of the present disclosure. For ease of reference, each of the first UE 110a, the second UE 110b, and the third UE 110c connected to the network 105, will hereinafter be collectively and individually referred to as the “User Equipment (UE) 110”.

[0033] In an embodiment, the UE 110 is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device.

[0034] The network 105 includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The network 105 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.

[0035] The network 105 may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 105 may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public- Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, a VOIP or some combination thereof.

[0036] The environment 100 includes the server 115 accessible via the network 105. The server 115 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise side, a defense facility side, or any other facility that provides service.

[0037] The environment 100 further includes the system 120 communicably coupled to the server 115 and the UE 110 via the network 105. The system 120 is adapted to be embedded within the server 115 or is embedded as the individual entity.

[0038] Operational and construction features of the system 120 will be explained in detail with respect to the following figures.

[0039] FIG. 2 illustrates an exemplary block diagram of the system 120 for identifying the root cause of call failures in the network 105, according to one or more embodiments of the present disclosure. The system 120 includes one or more processors 205, a memory 210, and a file system 215. The one or more processors 205, hereinafter referred to as the processor 205 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. As per the illustrated embodiment, the system 120 includes one processor 205. However, it is to be noted that the system 120 may include multiple processors as per the requirement and without deviating from the scope of the present disclosure. In alternate embodiments, the system 120 may include more than one processor 205 as per the requirement of the network 105.

[0040] Among other capabilities, the processor 205 is configured to fetch and execute computer-readable instructions stored in the memory 210. The memory 210 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 210 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROMs, FLASH memory, unalterable memory, and the like.

[0041] The file system 215 is configured to store the Call Detail Record (CDR) data. Further, the file system 215 provides structured storage, support for complex queries, and enables efficient data retrieval and analysis. The file system 215 is one of, but is not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database types are nonlimiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.

[0042] Further, the processor 205, in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 205. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 205 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for processor 205 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor 205. In such examples, the system 120 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 120 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry. [0043] In order for the system 120 to identify and determine the root cause of call failures in the network 105, the processor 205 includes a data accessing module 220, a data retrieval module 225, an analyzing module 230, a clustering module 235, a reason identification module 240, an Artificial Intelligence/Machine Learning (AI/ML) model updating module 245, and a corrective action implementation module 250 communicably coupled to each other for identifying the root cause of call failures in the network 105.

[0044] The data accessing module 220, the data retrieval module 225, the analyzing module 230, the clustering module 235, the reason identification module 240, the AI/ML model updating module 245, and the corrective action implementation module 250 in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 205. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 205 may be processorexecutable instructions stored on a non -transitory machine-readable storage medium and the hardware for the processor may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system 120 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 120 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.

[0045] The data accessing module 220 is configured to access the Call Detail Record (CDR) data stored in the file system 215. The CDR is a data record produced by a telecommunications equipment such as base stations that documents the details of a telephone call or other telecommunications transactions (e.g., text message) that passes through that facility or equipment. The CDR includes a plurality of attributes of a call, such as time, duration, amount of data transferred, completion status, a source number, and a destination number. The CDR data contains information regarding the call completion status and thus failed call details as well. For example, the Local Routing Number (LRN), among other fields combined with P-ANI header is one of the attributes for CDR analysis. The LRN helps in routing calls accurately to a correct destination.

[0046] As per the one embodiment, the P-ANI header contains the calling party's mobile number, often used for identification purposes. When combined with LRN data, it provides a comprehensive view of call details, including the source and routing information. The combination of LRN and P-ANI data in CDR analysis can help determine the call completion status, including successful calls and failed calls due to routing issues or other factors.

[0047] Upon accessing the CDR data stored in the file system 215, the data retrieval module 225 is configured to retrieve data related to failed calls from the accessed CDR data. In an embodiment, the retrieved data include, but not limited to, time duration of the failed call, calling party information, called party information, call duration, failure reason, error codes, and the like. Further, the data retrieval module 225 is configured to filter the CDR data to isolate specific call failure indicators. In an embodiment, the specific call failure indicators include call completion status, call duration, number of calls, call frequency, and call ratio.

[0048] Upon retrieving the data related to failed calls, the analyzing module 230 is configured to analyze the retrieved failed call data to identify reasons for the call failures utilizing the analysis engine 330 (shown in FIG.3). The analysis engine 330 is further configured to determine the call completion status for each failed call within the retrieved data. The analyzing module 230 leverages advanced algorithms to process and interpret the data, enabling the identification of patterns and root causes behind the call failures. By employing machine learning techniques, the system can continuously improve its accuracy and effectiveness in diagnosing issues, ultimately enhancing the overall reliability and performance of the network. The term Al/ML model and the analysis engine can be used interchangeably without limiting the scope of the disclosure. The AI/ML model 330 utilizes a variety of ML techniques, such as supervised learning model, unsupervised learning model, and reinforcement learning model. The supervised learning model includes, but not limited to, logistic regression, decision trees, random forests, Gradient Boosting Machines (GBM), neural networks, and Support Vector Machines (SVM).

[0049] The logistic regression aids to predict the probability of the call failure based on features like call duration, call frequency, etc. The decision trees aid in segmenting the CDR data to analyze which combinations of factors lead to the call failures. The random forests aggregate multiple decision trees trained on different subsets of the data, which improves prediction accuracy. The GBM aids to learn complex patterns in the CDR data to predict the call failure. The neural network analyzes sequential dependencies or temporal patterns in the call failures. The SVM identifies outliers or complex decision boundaries in the CDR datasets.

[0050] The unsupervised learning model includes clustering algorithms. Let’s consider for example include K-means clustering, hierarchical clustering, DBSCAN, etc., used to group data points into clusters based on similarity. The reinforcement learning model is used in scenarios where an agent learns to make decisions by interacting with an environment and receiving feedback in terms of rewards or penalties.

[0051] Upon analyzing the retrieved failed call data to identify reasons for the call failures, the clustering module 235 is configured to generate clusters of the failed calls based on one or more predefined policies or rules using the Al/ML model 330. Each cluster represents a categorization of failed calls based on their identified reasons for failure. The categorization of failed calls includes, but not limited to, network related failure, hardware related failure, configuration related failure, user-related failure, service-related failure, and security related failure. For each category, the clusters can be created to group similar types of failures together. Let’s consider for an example the network related failures vary depending on the cluster. The cluster 1 provides signal dropouts in rural areas, the cluster 2 provides congestion of the services during peak hours, the cluster 3 provides routing issues due to network updates.

[0052] In an embodiment, the one or more predefined policies and rules are defined by the service provider. In another embodiment, the one or more predefined policies and rules are defined as a Session Initiation Protocol (SIP) response code. The SIP response codes are used to communicate the status of SIP requests in mobile networks. The SIP enables the users to make and receive the calls over the internet. The SIP is a protocol used for initiating, maintaining, and terminating real-time sessions that involve video, voice, messaging, and other communications applications and services. When there is an attempt of the call via the network 105 and there is failure occurs. The user receives the information of interconnection failure of the call through the SIP response code. The SIP response codes transmit the information of the interconnection failure of the call. The SIP response codes are three-digit numerical messages that contain information sent by a User Agent Server (UAS) to a User Agent Client (UAC). The SIP response codes provide the information about the status of the call.

[0053] Further, the clustering module 235 is configured to classify the failed calls into clusters based on the frequency of failed calls per user or entity within a specified time frame. The clusters are formed based on predetermined ranges of failed call occurrences. For instance, the calls are grouped into clusters like "Low Frequency," "Medium Frequency," and "High Frequency" based on the number of failures within the specified time frame. The predetermined ranges or intervals define different levels of failed call occurrences. Let’s consider for an example, Cluster 1: Low Frequency (0-10 failed calls per day), cluster 2: Medium Frequency (11-20 failed calls per day), and luster 3: High Frequency (more than 20 failed calls per day), and the like.

[0054] In an embodiment, the cluster is created utilizing the AI/ML model 330 and includes similar types of failures together. The information related to the failed calls is transmitted to the AI/ML model 330. The ratio of the failed calls is calculated based on the clusters. The AI/ML model 330 is configured to identify the frequency of the failed calls per user or entity within the specified time frame. The frequency of the failed calls is filtered out from the group of clusters. At least one of the clusters includes call duration gap for each call. If the call duration gap is less, the AI/ML model 330 is configured to calculate the call duration gap between each call. In an exemplary embodiment, the subscriber receives 1000 calls per day. Then the AI/ML model 330 is configured to identify the high probability of ratio of call from each cluster, which is initiated by the auto bots, and also identifies the specific network issues, and the service provider limitations.

[0055] Upon classifying the failed calls into clusters, the reason identification module 240 is configured to identify root cause for the call failures within each cluster. The clustered data is analyzed to identify common patterns and anomalies in the data specific to each cluster to pinpoint the underlying causes of call failures. The reason identification module 240 is configured to identify specific network issues, service provider limitations, or external factors contributing to high incidence of failed calls in each cluster utilizes the AI/ML model 330.

[0056] Upon identifying the root cause for the call failures within each cluster, the AI/ML model updating module 245 is further configured to update the AI/ML model 330 based on the identified reasons for call failures. The clear code will be captured as part of the CDRs (Call Data Records) generated by the correlation of CDRs of multiple Network Functions. To detect the root cause analysis (RCA), the AI/ML model 330 is configured to analyze the retrieved failed call data by using a clustering algorithm (e.g., KMeans) to identify the patterns in the data. The AI/ML model updating module 245 ensures that the model improves over time, incorporating new insights and trends to enhance its predictive accuracy and diagnostic capabilities.

[0057] Upon updating the AI/ML model 330 based on the identified reasons for the call failures, the corrective action implementation module 250 is configured to implement corrective actions in the network 105 based on the identified root causes of call failures. The corrective action implementation module 250 involves network configuration changes, software updates, hardware adjustments, or other remedial measures designed to address the specific issues identified. By doing so, the system 120 also provides for better customer experience and improves service quality as the actual and major reason for call failure is identified and addressed quickly thereby improving call throughput.

[0058] FIG. 3 is an architecture 300 of the system 120 for identifying the root cause of call failures in the network 105, according to one or more embodiments of the present disclosure.

[0059] The architecture 300 of the system 120 includes an ingestion layer 305, a data lake 310, a compute layer 315, a rule engine 320, a policy box 325, the AI/ML model 330, and the file system 215. The CDRs are received from the ingestion layer 305 into the data lake 310. The data lake 310 stores the hot CDRs. The hot CDRs are those which are comparatively new- about three days to a week old. The file system 215 stores the historical CDRs. The compute layer 315 continuously calculates the data in the file system 215 including the CDR data.

[0060] The rule engine 320 and the policy box 325 are configured to receive inputs from the AI/ML model 330 as well as the user. The rule engine 320 provides the inputs to the AI/ML model 330 for analysis and the compute layer 315 for processing the data in the file system 215. The policy box 325 includes definition of policies along with corresponding conditions and actions which need to be triggered as per the policy. The rule engine 320 includes rules for checking and enforcing policies which are applicable. The rule engine 320 applies the rules (as defined by the policies) on the data and also checks the rules for validation to comply with the policy. This, in turn, triggers the policy box 325 to take action based upon the corresponding defined actions. [0061] The rule engine 320 and the policy box 325 may provide inputs to the compute layer 315 to calculate the data based on failed calls and generate a report based on the exact point beyond which or at which the call could not go through. The parameters being used may include call duration, number of calls, call frequency, callgaps and call ratio using the data available in the CDR, Automatic Call Distribution (ACD) and the like. Pertinent to this invention, the CDR data contains information regarding the call completion status. The ACD automatically routes incoming calls to a specific group of terminals based on predefined rules. In an embodiment, the ACD includes, but is not limited to, call routing, queue management, call monitoring and reporting, and Interactive Voice Response (IVR). The invention provides for analyzing the exact status of the call completion and filtering out the call failure causes for failed calls. For example, the LRN number, among other fields combined with P-ANI header is one of the attributes for CDR analysis.

[0062] FIG. 4 is a flow diagram illustrating a method 400 for identifying the root cause of call failures in the network 105, according to one or more embodiments of the present disclosure.

[0063] At step 405, the method 400 includes the step of accessing the CDR data stored in the file system 215 by the data accessing module 220. The CDR includes the plurality of attributes of a call, such as time, duration, completion status, a source number, and a destination number. The CDR data contains information regarding the call completion status and thus failed call details as well. For example, the Local Routing Number (LRN), among other fields combined with P-ANI header is one of the attributes for CDR analysis. The LRN helps in routing calls accurately to a correct destination.

[0064] At step 410, the method 400 includes the step of retrieving data related to failed calls from the accessed CDR data based on accessing the CDR data stored in the file system 215 by the data retrieval module 225. Further, the data retrieval module 225 is configured to filter the CDR data to isolate specific call failure indicators. In an

Y1 embodiment, the specific call failure indicators include call completion status, call duration, number of calls, call frequency, and call ratio.

[0065] At step 415, the method 400 includes the step of analyzing the retrieved failed call data to identify reasons for the call failures utilizing Al/ML model 330 based on retrieving the data related to failed calls by the analyzing module 230. The Al/ML model 330 is further configured to determine the call completion status for each failed call within the retrieved data. The analyzing module 230 leverages advanced algorithms to process and interpret the data, enabling the identification of patterns and root causes behind the call failures. By employing machine learning techniques, the system can continuously improve its accuracy and effectiveness in diagnosing issues, ultimately enhancing the overall reliability and performance of the network. The Al/ML model 330 utilizes a variety of ML techniques, such as supervised learning model, unsupervised learning model, and reinforcement learning model.

[0066] At step 420, the method 400 includes the step of generating the clusters of the failed calls based on one or more predefined policies or rules using the Al/ML model by the clustering module 235. Each cluster represents a categorization of failed calls based on their identified reasons for failure. In an embodiment, the one or more predefined policies and rules are defined by the service provider. In another embodiment, the one or more predefined policies and rules are defined as a Session Initiation Protocol (SIP) response code. The SIP response codes are used to communicate the status of SIP requests in mobile networks.

[0067] At step 425, the method 400 includes the step of identifying the root cause for the call failures within each cluster base on classifying the failed calls into clusters by the reason identification module 240. The clustered data is analyzed to identify common patterns and anomalies in the data specific to each cluster to pinpoint the underlying causes of call failures. The reason identification module 240 is configured to identify specific network issues, service provider limitations, or external factors contributing to high incidence of failed calls in each cluster utilizes the AI/ML model

330.

[0068] The present invention discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by a processor 205. The processor 205 is configured to access Call Detail Record (CDR) data stored in a File System (FS) 215. The processor 205 is configured to retrieve data related to failed calls from the accessed CDR data. The processor 205 is configured to analyze the retrieved failed call data to identify reasons for the call failures. The processor 205 is configured to generate clusters of the failed calls based on predefined policies or rules using the AI/ML model 330. Each cluster represents a categorization of failed calls based on their identified reasons for failure. The processor 205 is configured to identify the root cause for the call failures within each cluster.

[0069] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-4) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.

[0070] The present disclosure incorporates technical advancement for identifying and determining the root cause of call failures in the network. As such, the above techniques of the present disclosure provide multiple advantages including identifying the root cause for the call failure in the network so that the same can be addressed. The present disclosure also provides for better customer experience and improves service quality as the root cause for call failure is identified and addressed quickly thereby improving call throughput.

[0071] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS

[0072] Environment - 100;

[0073] Network - 105;

[0074] User Equipment- 110;

[0075] Server - 115;

[0076] System - 120;

[0077] Processor -205;

[0078] Memory - 210;

[0079] Database- 215;

[0080] Data accessing module- 220;

[0081] Data retrieval module- 225 ;

[0082] Analyzing module- 230;

[0083] Clustering module- 235;

[0084] Reason identification module- 240;

[0085] AI/ML model updating module- 245;

[0086] Corrective action implementation module- 250;

[0087] Ingestion layer- 305;

[0088] Data lake-310;

[0089] Compute layer-315;

[0090] Rule engine- 320;

[0091] Policy box- 325;

[0092] Analysis engine - 330.

Claims

CLAIMS We Claim:

1. A method (400) for identifying root cause of call failures in a network, the method comprising the steps of: accessing, by a one or more processor(s) (205), Call Detail Record (CDR) data stored in a File System (FS) (215); retrieving, by the one or more processor(s) (205), data related to failed calls from the accessed CDR data; analyzing, by the one or more processor(s) (205), utilizing an analysis engine (330), the retrieved failed call data to identify reasons for the call failures; generating, by the one or more processor(s) (205), clusters of the failed calls based on predefined policies or rules using the analysis engine (330), wherein each cluster represents a categorization of failed calls based on their identified reasons for failure; and identifying, by the one or more processor (s), the root cause for the call failures within each cluster.

2. The method (400) as claimed in claim 1, wherein the step of retrieving includes filtering the CDR data to isolate specific call failure indicators, including call completion status, call duration, number of calls, call frequency, and call ratio.

3. The method (400) as claimed in claim 1, wherein the step of analyzing further comprises determining the call completion status for each failed call within the retrieved data.

4. The method (400) as claimed in claim 1, wherein the step of generating includes classifying the failed calls into clusters based on the frequency of failed calls per user or entity within a specified time frame.

5. The method (400) as claimed in claim 4, wherein the clusters are formed based on predetermined ranges of failed call occurrences.

6. The method (400) as claimed in claim 1 , wherein the step of identifying involves using the analysis engine (330) to identify specific network issues, service provider limitations, or external factors contributing to the high incidence of failed calls in each cluster.

7. The method (400) as claimed in claim 1, further comprising the step of updating the analysis engine (330) based on the identified root cause for call failures.

8. The method (400) as claimed in claim 1, wherein the step of identifying, the root cause for the call failures within each cluster, includes the step of, determining major and actual reason for the call failures within each cluster.

9. The method (400) as claimed in claim 1, further comprising the step of implementing corrective actions in the network based on the identified root causes of call failures.

10. A system (120) for identifying the root cause of call failures in a network (105), the system (120) comprising: a data accessing module (220) configured to access Call Detail Record (CDR) data stored in a File System (FS) (215); a data retrieval module (225) configured to retrieve data related to failed calls from the accessed CDR data; an analyzing module (230) configured to analyze the retrieved failed call data to identify reasons for the call failures; a clustering module (235) configured to generate clusters of the failed calls based on predefined policies or rules using an analysis engine (330), wherein each cluster represents a categorization of failed calls based on their identified reasons for failure; and a reason identification module (240) configured to identify root cause for the call failures within each cluster.

11. The system (120) as claimed in claim 10, wherein the data retrieval module (225) is further configured to filter the CDR data to isolate specific call failure indicators, wherein the specific call failure indicators include call completion status, call duration, number of calls, call frequency, and call ratio.

12. The system (120) as claimed in claim 10, wherein the analysis engine (330) is further configured to determine the call completion status for each failed call within the retrieved data.

13. The system (120) as claimed in claim 10, wherein the clustering module (235) is further configured to classify the failed calls into clusters based on the frequency of failed calls per user or entity within a specified time frame.

14. The system (120) as claimed in claim 13, wherein the clusters are formed based on predetermined ranges of failed call occurrences.

15. The system (120) as claimed in claim 10, wherein the reason identification module (240) is configured to identify specific network issues, service provider limitations, or external factors contributing to high incidence of failed calls in each cluster.

16. The system (120) as claimed in claim 10, further comprising an AI/ML model updating module (245) is further configured to update the AI/ML model (330) based on the identified reasons for call failures.

17. The system (120) as claimed in claim 10, further comprising a corrective action implementation module (250) configured to implement corrective actions in the network (105) based on the identified root causes of call failures.

18. The system (120) as claimed in claim 10, wherein the reason identification module (240) identifies the root cause for the call failures within the cluster, by determining major and actual reason for the call failures within each cluster.

19. A non-transitory computer-readable medium storing instructions that, when executed by a processor (205), cause the processor (205) to: access Call Detail Record (CDR) data stored in a File System (FS) (215); retrieve data related to failed calls from the accessed CDR data; analyze the retrieved failed call data to identify reasons for the call failures; generate clusters of the failed calls based on predefined policies or rules using the analysis engine (330), wherein each cluster represents a categorization of failed calls based on their identified reasons for failure; and identify the root cause for the call failures within each cluster.