DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
METHOD AND SYSTEM FOR DETECTING ONE OR MORE ANOMALIES IN CALL RELEASE REASON (CRR) DATA
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3. PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to detection of one or more anomalies, more particularly relates to a method and a system for detecting one or more anomalies in Call Release Reason (CRR) data.
BACKGROUND OF THE INVENTION
[0002] Generally, in the communication network, the call release or call disconnection may occur due to various reasons. One of the main reasons may be due to anomaly such as deviation from the normal or expected behavior of the network devices in the communication network.
[0003] In the communication network, the calls may be monitored by the network operators or consumers in order to detect the anomaly. In some scenarios, the process of determining tolerance levels for network failures and the process of anomaly detection also involves creating policies, applying policies to incoming data, and alerting consumers when anomalies are detected. Furthermore, the policy needs to be updated whenever data patterns change or when there is a requirement to adjustment in relation to threshold values. This process of detecting anomaly in the communication network may be complex as it is performed manually which may eventually lead to more time consumption and may be error prone.
[0004] In view of the above, there is a dire need for an efficient system and method for detecting anomalies by using Call Release Reason (CRR) data, which ensures enhancement in the efficiency of anomaly detection.
SUMMARY OF THE INVENTION
[0005] One or more embodiments of the present disclosure provide a method and system for detecting one or more anomalies in Call Release Reason (CRR) data.
[0006] In one aspect of the present invention, the system of detecting the one or more anomalies in the CRR data is disclosed. The system includes a retrieving unit, configured to retrieve historical CRR data of one or more network components from a probing unit. The system further includes a training unit, configured to train, a model utilizing the retrieved CRR data to analyze the CRR data. The system further includes a determining unit, configured to determine one or more threshold values of each of the one or more network components based on the analyzed CRR data. The system further includes an updating unit, configured to, update, one or more policies and the one or more threshold values of the one or more network components based on the determined one or more threshold values. The system further includes a receiving unit, configured to receive real-time CRR data of the one or more network components from the probing unit. The system further includes a comparing unit, configured to compare the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model. The system further includes a detecting unit, configured to, detect, one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components.
[0007] In an embodiment, on retrieving the data, the system comprises a preprocessing unit, configured to preprocess the retrieved CRR data by at least one of normalizing, cleaning, and transforming the retrieved CRR data.
[0008] In an embodiment, the model is trained to identify patterns pertaining to the retrieved data of the one or more network components.
[0009] In an embodiment, the one or more threshold values are determined based on at least one of, time and geographical location.
[0010] In an embodiment, on determining the one or more threshold values, the system comprises a storing unit, configured to store, the determined one or more threshold values of the one or more network components.
[0011] In an embodiment, the probing unit is communicably coupled to the retrieving unit and the receiving unit to enable communication of the historical CRR data therebetween.
[0012] In an embodiment, on detecting the one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values, the system comprises a triggering unit, configured to, trigger, one or more actions in response to detecting the one or more anomalies in the one or more network components.
[0013] In an embodiment, the one or more actions includes at least one of, rerouting network traffic, adjusting network resources, or triggering automated recovery procedures to mitigate the detected one or more anomalies.
[0014] In another aspect of the present invention, the method of detecting one or more anomalies in the CRR data is disclosed. The method includes the step of retrieving historical CRR data of one or more network components from a probing unit. The method further includes the step of training a model utilizing the retrieved CRR data to analyze the CRR data. The method further includes the step of determining one or more threshold values of each of the one or more network components based on the analyzed CRR data. The method further includes the step of updating one or more policies and the one or more threshold values of the one or more network components based on the determined one or more threshold values. The method further includes the step of receiving real-time CRR data of the one or more network components from the probing unit. The method further includes the step of comparing the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model. The method further includes the step of detecting one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components.
[0015] In another aspect of the invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions is disclosed. The computer-readable instructions are executed by a processor. The processor is configured to retrieve historical CRR data of one or more network components from a probing unit. The processor is configured to train a model utilizing the retrieved CRR data to analyze the CRR data. The processor is configured to determine one or more threshold values of each of the one or more network components based on the analyzed CRR data. The processor is configured to update, one or more policies and the one or more threshold values of the one or more network components based on the determined one or more threshold values. The processor is configured to receive real-time CRR data of the one or more network components from the probing unit. The processor is configured to compare the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model. The processor is configured to detect one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components.
[0016] 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
[0017] 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.
[0018] FIG. 1 is an exemplary block diagram of an environment of detecting one or more anomalies in Call Release Reason (CRR) data, according to one or more embodiments of the present invention;
[0019] FIG. 2 is an exemplary block diagram of a system of detecting the one or more anomalies in the CRR data, according to one or more embodiments of the present invention;
[0020] FIG. 3 is an exemplary block diagram of an architecture implemented in the system of the FIG. 2, according to one or more embodiments of the present invention;
[0021] FIG. 4 is a flow diagram for detecting the one or more anomalies in the CRR data, according to one or more embodiments of the present invention; and
[0022] FIG. 5 is a schematic representation of a method for detecting the one or more anomalies in the CRR data, according to one or more embodiments of the present invention.
[0023] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0024] 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.
[0025] 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.
[0026] 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.
[0027] The present disclosure aims at enhancing the efficiency of the anomaly detection process and consumers experience. In particular, the present invention provides a unique approach of dynamically detecting anomalies in real time, eliminating the need for repetitive policy changes and threshold modifications, enabling consumers to proactively respond to potential network issues before they escalate. The streamlined approach enhances the efficiency of the anomaly detection process and allows consumers to take immediate action to prevent major network disruptions or failures.
[0028] FIG. 1 illustrates an exemplary block diagram of an environment 100 of detecting one or more anomalies in Call Release Reason (CRR) data, according to one or more embodiments of the present disclosure. In this regard, the environment 100 includes a User Equipment (UE) 102, a server 104, the network 106 and a system 108 communicably coupled to each other for detecting the one or more anomalies in the CRR data.
[0029] In an embodiment, the one or more anomalies refer to deviations from expected or established patterns in the CRR data that could indicate irregularities, faults, or potential issues in the network 106. The one or more anomalies includes, but not limited to, unusual call termination rates, irregular call release reasons, geographically or temporally atypical behavior, threshold exceedances. The Call Release Reason (CRR) data refers to information collected by the network 106 on the specific reasons why calls or connections are terminated. The CRR data includes, but is not limited to, reason codes, call duration and timing, network component information, geographical information, user or device data. The CRR data helps network operators understand and monitor call performance, detect potential issues, and improve overall network quality.
[0030] As per the illustrated embodiment and for the purpose of description and illustration, the UE 102 includes, but not limited to, a first UE 102a, a second UE 102b, and a third UE 102c, and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the UE 102 may include a plurality of UEs as per the requirement. For ease of reference, each of the first UE 102a, the second UE 102b, and the third UE 102c, will hereinafter be collectively and individually referred to as the “User Equipment (UE) 102”.
[0031] In an embodiment, the UE 102 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 a smartphone, 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.
[0032] The environment 100 includes the server 104 accessible via the network 106. The server 104 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.
[0033] The network 106 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 106 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.
[0034] The network 106 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 106 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.
[0035] The environment 100 further includes the system 108 communicably coupled to the server 104 and the UE 102 via the network 106. The system 108 is configured to detect the one or more anomalies in the Call Release Reason (CRR) data. As per one or more embodiments, the system 108 is adapted to be embedded within the server 104 or embedded as an individual entity.
[0036] Operational and construction features of the system 108 will be explained in detail with respect to the following figures.
[0037] FIG. 2 is an exemplary block diagram of the system 108 for detecting one or more anomalies in the CRR data, according to one or more embodiments of the present invention.
[0038] As per the illustrated embodiment, the system 108 includes one or more processors 202, a memory 204, a user interface 206, and a database 208. Further, the one or more processors 202 is communicably coupled with a probing unit 230.
[0039] For the purpose of description and explanation, the description will be explained with respect to one processor 202 and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the system 108 may include more than one processor 202 as per the requirement of the network 106. The one or more processors 202, hereinafter referred to as the processor 202 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.
[0040] As per the illustrated embodiment, the processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204. The memory 204 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 204 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0041] In an embodiment, the user interface 206 includes a variety of interfaces, for example, interfaces for a graphical user interface, a web user interface, a Command Line Interface (CLI), and the like. The user interface 206 facilitates communication of the system 108. In one embodiment, the user interface 206 provides a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, the UE 102 and the database 208.
[0042] The database 208 is one of, but 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 208 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0043] In order for the system 108 to detect the one or more anomalies in the CRR data, the processor 202 includes one or more modules. In one embodiment, the one or more modules includes, but not limited to, a retrieving unit 210, a preprocessing unit 212, a training unit 214, a determining unit 216, a storing unit 218, a updating unit 220, a receiving unit 222, a comparing unit 224, a detecting unit 226, and a triggering unit 228 communicably coupled to each other for detecting the one or more anomalies in the CRR data.
[0044] In one embodiment, each of the one or more modules may be used in combination or interchangeably for detecting the one or more anomalies in the CRR data.
[0045] The retrieving unit 210, the preprocessing unit 212, the training unit 214, the determining unit 216, the storing unit 218, the updating unit 220, the receiving unit 222, the comparing unit 224, the detecting unit 226, and the triggering unit 228 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 202. 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 202 may be processor-executable 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 204 may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system 108 may comprise the memory 204 storing the instructions and the processing resource to execute the instructions, or the memory 204 may be separate but accessible to the system 108 and the processing resource. In other examples, the processor 202 may be implemented by electronic circuitry.
[0046] In one embodiment, the retrieving unit 210 is configured to retrieve historical CRR data of one or more network components. The one or more network components refers to the physical and virtual elements within the network 106 that facilitate and manage communication, data transfer and service delivery. The one or more network components includes, but are not limited to, base stations, routers and switches, gateways, User Plane Function (UPF), Access and Mobility Management Function (AMF), Session Management Function (SMF).
[0047] The historical CRR data of the one or more network components is retrieved from a probing unit 230. The probing unit 230 is a component responsible for collecting, monitoring, and retrieving data from the one or more network components for analysis related to CRR data. The historical CRR data refers to archived records of past call terminations within the network 106 including the reasons for these terminations. The historical CRR data includes, but is not limited to, past CRR codes, trends over time, geographical patterns, performance of network components, user behavior and device trends. The past CRR codes are the records of the codes that indicated why calls ended, providing insight into frequent causes of call terminations such as user hangups, network drops or signal issues. The trend over time refers to the data on how call release reasons have changed over periods (For example, hours, days, months) which helps to understand time-based patterns and seasonal or peak-period impacts. The geographical patterns refer to the information on call release reasons across different locations, allowing for the identification of region-specific issues that may have persisted or varied over time. The performance of network components refers to the historical CRR data associated with network components, useful for identifying whether certain equipment or segments have had higher instances of call drops. The user behavior and device trends refer to the aggregated data on call release by device types, network types or other specific metrics which can help identify device or demographic trends in call terminations.
[0048] Upon retrieving the historical CRR data, the preprocessing unit 212 is configured to preprocess the retrieved CRR data. The retrieved CRR data is preprocessed by at least one of normalizing, cleaning and transforming. The normalizing refers to the adjusting the CRR data values to a common scale without distorting the difference in the ranges of values. In particular, in the case of CRR data the standardization fields like call durations, signal strength or error codes are adjusted so that the fields of the CRR data are compared. For example, the historical CRR data with a feature for call duration is recorded as 10, 50, and 20 seconds. By using normalization, the call duration records are normalized between 0 and 1. The call duration records are normalized by identifying the minimum (10) and maximum (50) values. Upon identifying the minimum and maximum value, the normalized values for 10, 50, and 20 are calculated as 0.0, 1.0, and 0.25, respectively by applying formulas. After normalization, the data looks like this: [0.0, 1.0, 0.25]. The cleaning refers to removing or correcting inaccurate, incomplete or inconsistent data entries within the CRR data set. For example, the cleaning might involve filling in missing call release reasons by removing entries with errors or correcting erroneous timestamps. The transforming refers to the modifying of the CRR data to fit a specific structure or format that facilitates analysis. The transformations might include encoding categorical data (e.g., different call release codes) into numerical representations for machine learning models, aggregating data by time or geographic region, or creating new features from existing data (e.g., calculating average call release rates by location).
[0049] Upon preprocessing the retrieved CRR data, the training unit 214 is configured to train a model. The model is trained using the historical CRR data. The historical data represents past call release events, including details such as cause codes for call termination (e.g., network-initiated release, user-end disconnection) and associated metadata like timestamps, geographical locations. The model is trained to identify patterns pertaining to the retrieved data of the one or more network components. The model refers to a machine learning or statistical model that has been trained on the historical CRR data to recognize patterns, trends, or anomalies in the data from the one or more network components. The patterns refer to recurring trends, behaviors, or characteristics in the CRR data across the one or more network components that the model can learn and recognize. The pattern in the CRR data includes, but not limited to, call termination reasons, time-based patterns, geographical patterns, network component behavior, user and device trends. The call termination reasons refer to regularly observed reasons for call release such as user-initiated hang-ups, network-driven disconnections or handover failures. The time-based patterns refer to variations in call release reasons or rates that follow time trends like peak traffic hours where higher call drops may be normal or highly maintenance windows that result in temporary call interruptions. The geographical patterns refer to the differences in the CRR data based on location, where certain areas might have different call release patterns due to variations in network infrastructure, population density, or environmental factors. The network component behavior refers to typical operational metrics for specific network components (e.g., base stations, routers) that may influence call releases, such as signal strength ranges, handover success rates, or equipment load levels. The user and device trends refer to common behaviors among specific user groups or device types, such as higher call drops in certain device models or network types, which the model uses to set expectations for similar user demographics. Further, based on the nature of the data and the type of patterns being identified, a suitable machine learning (ML) or statistical model is chosen. The machine learning model is at least one of supervised learning models, unsupervised learning models, time-series models. Upon identifying the suitable machine learning model, the historical CRR data is fed into the machine learning model to analyze the patterns of the CRR data.
[0050] Further, the model analyzes the CRR data and identifies normal and abnormal behaviors related to call releases, facilitating proactive network management and anomaly detection. The normal behaviors refer to typical or expected patterns in the CRR data based on historical data patterns under usual network conditions. The abnormal behaviors are deviations from established patterns that may indicate issues within the network 106. The abnormal behaviors include, but not limited to, unusual call release reasons, spikes in call drops, geographical or temporal anomalies, component-related deviations, device or network segment failures.
[0051] Upon training the model, the determining unit 216 is configured to determine one or more threshold values of each of the one or more network components. The threshold value is a predefined limit or boundary established for various metrics within the CRR data of network components. The one or more threshold values are determined based on at least one of, time and geographical location. The time refers to the different time of the day (e.g., peak vs. off-peak hours) may have varying thresholds, as call drops might be more acceptable during peak traffic periods compared to off-peak hours. The geographical location refers to the thresholds that can differ by region, as network conditions and usage patterns vary across areas (e.g., urban vs. rural areas might experience different call drop rates or signal quality). The one or more threshold values are used to monitor metrics related to CRR data, such as call drop rate, signal strength, handover success rate etc. The call drop rate refers to the maximum allowable percentage of call terminations due to drops in a specific location or time. The signal strength refers to the minimum acceptable signal level before considering it a potential cause for call termination. The handover success rate refers to the acceptable percentage of successful handovers (transfers of active calls between the one or more network components).
[0052] Upon determining the one or more threshold values of each of the one or more network components, the storing unit 218 is configured to store the determined one or more threshold values of the one or more network components. Thereafter, based on the determined one or more threshold values, the updating unit 220 is configured to update one or more policies and the one or more threshold values of the one or more network components. The one or more policies refer to predefined rules or guidelines governing the behavior, performance, and management of the one or more network components. The one or more policies dictate how the network should respond to various conditions, especially when specific metrics related to the CRR data approach or exceed established threshold values. The one or more policies include, but are not limited to, Quality of Service (QoS) policies, resource allocation policies, traffic management policies, and anomaly response policies. The QoS policies define minimum acceptable performance standards such as acceptable call drop rates or handover success rates. The resource allocation policies govern the allocation of network resources to different network components based on real-time needs. For example, if certain areas experience increased call drops, these policies could reallocate resources to those areas. The traffic management policies control network traffic distribution such as rerouting calls away from overloaded network components or prioritizing certain types of traffic in high-demand scenarios to avoid call disruptions. The anomaly response policies outline the steps to take when real-time CRR data exceeds threshold values such as generating alerts, triggering automated recovery actions or adjusting configurations to mitigate impacts.
[0053] Subsequently, the receiving unit 222 is configured to receive real-time CRR data of the one or more network components from the probing unit 230. The real-time CRR data refers to the immediate, live data collected from the one or more network components regarding the reasons for ongoing or recently terminated calls. The real-time CRR data includes, but not limited to, immediate access, up to date all release reasons, granularity by time and location, relevance to ongoing network conditions.
[0054] Upon receiving the real-time CRR data, the comparing unit 224 is configured to compare the real-time CRR data with the updated one or more threshold values of the one or more network components. The real-time CRR data is compared with the updated one or more threshold values of the one or more network components using the trained model. For example, a telecom network has set threshold values for call drop rates as 2% for an urban area during peak hours and signal strength as minimum of -95 dBm in urban locations. The real-time CRR data shows a call drop rate of 5% in the urban area, which exceeds the 2% threshold and the signal strength readings averaging 100dBm in the same area, which is weaker than the minimum threshold of 95 dBm.
[0055] Upon comparing the updated one or more threshold values and the real-time CRR data, the detecting unit 226 is configured to detect the one or more anomalies. The one or more anomalies refer to unexpected deviations or irregularities in the CRR data that indicate potential issues or abnormal behavior within the network 106. The one or more anomalies are identified when real-time CRR data exceeds or falls below the defined threshold values for the one or more network components. The one or more anomalies in CRR data includes, but not limited to, high call drop rate, signal quality degradation, unusual handover failures, increased network congestion, unexpected call release reasons. The high call drop rate refers to a call drop rate significantly higher than the threshold (e.g., a sudden increase to 5% when the acceptable threshold is 2%) in a specific location, time, or network component. The signal quality degradation refers to the signal strength consistently falling below the acceptable threshold in a particular area, suggesting possible interference or equipment malfunction. The unusual handover failures refer to a higher-than-expected rate of handover failures (transfers of calls between network cells) indicating a problem with handover procedures in specific regions. The increased network congestion refers to real-time data showing unusually high congestion rates (e.g., elevated packet loss or delays) that exceed the thresholds, potentially impacting call quality and stability. The unexpected call release reasons refer to a spike in certain call termination reasons, such as "network failure" or "signal loss," indicating a possible issue with the network infrastructure.
[0056] Upon detecting the one or more anomalies, the triggering unit 228 is configured to trigger one or more actions in response to detecting the one or more anomalies in the one or more network components. The one or more actions includes at least one of, rerouting network traffic, adjusting network resources, or triggering automated recovery procedures to mitigate the detected one or more anomalies. The rerouting network traffic refers to alleviating congestion or avoiding problematic network elements that may be experiencing issues. For example, if a high call drop rate is detected in a particular cell, the system could reroute calls through neighboring cells with stable performance, thereby maintaining call quality and reducing the load on the affected component. The adjusting network resources refers to optimizing resource distribution to areas of higher demand or where performance has dropped below thresholds. For example, if signal strength in a certain region is below acceptable levels, the system might allocate additional power or increase bandwidth to boost signal quality and reduce call drops. The triggering automated recovery procedures refers to addressing hardware, software, or network configuration issues that may have led to the detected anomalies. For example, for recurrent handover failures, automated recovery procedures may include reconfiguring parameters, resetting affected network elements, or performing fault diagnostics to identify and resolve the underlying cause.
[0057] Therefore, the system 108 helps in automatically detecting anomalies by eliminating the need for manual monitoring and detection. Thus, the system 108 saves time and effort while ensuring timely identification of potential issues. The system 108 has the ability to track anomalies in near real-time which ensures that users can promptly respond to any potential issues, mitigating their impact and minimizing downtime. The system 108 avoids manual changes to policies each time data pattern changes. Further, the system 108 maintains a high quality of service (QoS) by quickly responding to disruptions. The system 108 provides improved network resilience, automated efficiency, and optimized resource utilization by leveraging real-time data processing, anomaly detection, and responsive actions based on dynamically updated thresholds and policies.
[0058] FIG. 3 is an exemplary block diagram of an architecture 300 of the system 108 for detecting the one or more anomalies in the CRR data, according to one or more embodiments of the present invention.
[0059] The architecture 300 includes the probing unit 230, a data consumer 1 314a, a data consumer 2 314b, and a processing hub 302. The processing hub 302 includes a data integration unit 304, a data pre-processing unit 306, a model training unit 308, and a prediction unit 310. Further, the processing hub 302 is communicably coupled with user interface 206 and a data lake 312.
[0060] In an embodiment, the probing unit 230 is responsible for performing data analytics and providing insights into network behavior and performance. The probing unit 230 collects and analyzes the historical CRR data of the one or more network components. Upon collecting and analyzing the historical CRR data, the probing unit 230 transmits the collected and analyzed CRR data to the data integration unit 304.
[0061] Upon receiving the collected and analyzed CRR data, the data integration unit 304 combines or integrated the received data from different sources into a single, unified dataset. Thereafter, the integrated data is transmitted to the data preprocessing unit 306. The data preprocessing unit 306 preprocesses the integrated data. The integrated data is preprocessed by at least one of normalizing, cleaning, and transforming the integrated data. The data preprocessing removes the redundant data. Further, the preprocessed data is stored in the data lake 312. The data lake 312 is a distributed database used to the store the data.
[0062] Upon preprocessing and storing the data, the preprocessed data is transmitted to the model training unit 308. The model training unit trains the model utilizing the collected historical CRR data to analyze the CRR data. The model is trained to identify patterns pertaining to the retrieved data of the one or more network components. Upon training the model, the one or more threshold values of the each of the one or more network components are determined. The one or more threshold values are determined based on at least one of, time and geographical location. The determined one or more threshold values of the one or more network components are stored in the data lake 312. Thereafter, the one or more polices and the one or more threshold values of the one or more network components are updated based on the determined one or more threshold values.
[0063] Subsequently, the real-time CRR data of the one or more network components are received from the probing unit 230. Upon receiving the real-time CRR data, the prediction unit 310 compares the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model. Based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components, the prediction unit 310 predicts or detects the one or more anomalies.
[0064] Upon predicting or detecting the one or more anomalies, the information pertaining to the one or more anomalies is transmitted to the data consumer 1 314a and data consumer 2 314b. The data consumer 1 314a and the data consumer 2 314b are at least one of telecom operators who monitor the analyzed CRR data. Upon receiving the information pertaining to the one or more anomalies, the data consumer 1 314a and the data consumer 2 314b triggers the one or more actions. The one or more actions includes at least one of, rerouting network traffic, adjusting network resources, or triggering automated recovery procedures to mitigate the detected one or more anomalies.
[0065] FIG. 4 is a flow diagram for detecting the one or more anomalies in the CRR data, according to one or more embodiments of the present invention.
[0066] At step 402, in an embodiment, the probing unit 230 is responsible for performing data analytics and providing insights into network behavior and performance. The probing unit 230 collects and analyzes the historical CRR data of the one or more network components.
[0067] At step 404, upon collecting and analyzing the historical CRR data, the collected and analyzed data is preprocessed. The data is preprocessed by at least one of normalizing, cleaning, and transforming the data. The data preprocessing removes the redundant data. Further, the preprocessed data is split for training and testing.
[0068] At step 406, upon preprocessing the data, the model is trained using the historical CRR data to analyze the CRR data. The model is trained to identify patterns pertaining to the retrieved data of the one or more network components.
[0069] At step 408, upon training the model utilizing the historical CRR data, the threshold value of each of the one or more network components are determined. The one or more threshold values are determined based on at least one of, time and geographical location. The determined one or more threshold values of the one or more network components are stored in the data lake 312.
[0070] At step 410, the real-time CRR data of the one or more network components are received from the probing unit 230. Upon receiving the real-time CRR data, the real-time CRR data is compared with the updated one or more threshold values of the one or more network components using the trained model. Based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components, the one or more anomalies are detected.
[0071] At step 412, upon detecting the one or more anomalies, the system 108 monitors the performance of the one or more network components. Further, the one or more polices and the one or more threshold values of the one or more network components are updated.
[0072] FIG. 5 is a flow diagram of a method 500 of detecting the one or more anomalies in the CRR data, according to one or more embodiments of the present invention. For the purpose of description, the method 500 is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0073] At step 502, the method 500 includes the step of retrieving the historical CRR data of one or more network components from the probing unit 230 by the retrieving unit 210. Upon retrieving the historical CRR data, the preprocessing unit 212 is configured to preprocess the retrieved CRR data by at least one of normalizing, cleaning and transforming the retrieved CRR data.
[0074] At step 504, the method 500 includes the step of training the model utilizing the retrieved CRR data to analyze the CRR data by the training unit 214. The model is trained to identify patterns pertaining to the retrieved data of the one or more network components.
[0075] At step 506, the method 500 includes the step of determining the one or more threshold values of each of the one or more network components based on the analyzed CRR data by the determining unit 216. The one or more threshold values are determined based on at least one of, time and geographical location. Further, on determining the one or more threshold values of the one or more network components, the storing unit 218 is configured to store the determined one or more threshold values of the one or more network components.
[0076] At step 508, the method 500 includes the step of updating the one or more policies and the one or more threshold values of the one or more network components based on the determined one or more threshold values by the updating unit 220.
[0077] At step 510, the method 500 includes the step of receiving the real-time CRR data of the one or more network components from the probing unit 230 by the receiving unit 222.
[0078] At step 512, the method 500 includes the step of comparing the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model by the comparing unit 224.
[0079] At step 514, the method 500 includes the step of detecting the one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components by the detecting unit 226. Further, on detecting the one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values, the triggering unit 228 is configured to trigger the one or more actions in response to detecting the one or more anomalies in the one or more network components. The one or more actions includes at least one of, rerouting network traffic, adjusting network resources, or triggering automated recovery procedures to mitigate the detected one or more anomalies
[0080] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 202. The processor 202 is configured to retrieve the historical CRR data of one or more network components from the probing unit 230. The processor 202 is further configured to train the model utilizing the retrieved CRR data to analyze the CRR data. The processor 202 is further configured to determine the one or more threshold values of each of the one or more network components based on the analyzed CRR data. The processor 202 is further configured to update one or more policies and the one or more threshold values of the one or more network components based on the determined one or more threshold values. The processor 202 is further configured to receive the real-time CRR data of the one or more network components from the probing unit 230. The processor 202 is further configured to compare the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model. The processor 202 is further configured to detect the one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components.
[0081] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-5) 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.
[0082] The present disclosure incorporates technical advancement of automatically detecting anomalies by eliminating the need for manual monitoring and detection. Thus, by using the present invention, the processor saves time and effort while ensuring timely identification of potential issues. The present invention has the ability to track anomalies in near real-time which ensures that users can promptly respond to any potential issues, mitigating their impact and minimizing downtime. The present invention avoids manual changes to policies each time data pattern changes. Further, the present invention maintains a high quality of service (QoS) by quickly responding to disruptions. The present invention provides improved network resilience, automated efficiency, and optimized resource utilization by leveraging real-time data processing, anomaly detection, and responsive actions based on dynamically updated thresholds and policies.
[0083] 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

[0084] Environment- 100
[0085] User Equipment (UE)- 102
[0086] Server- 104
[0087] Network- 106
[0088] System -108
[0089] Processor- 202
[0090] Memory- 204
[0091] User Interface- 206
[0092] Database- 208
[0093] Retrieving Unit- 210
[0094] Pre-processing Unit- 212
[0095] Training Unit- 214
[0096] Determining Unit- 216
[0097] Storing Unit- 218
[0098] Updating Unit- 220
[0099] Receiving Unit- 222
[00100] Comparing Unit- 224
[00101] Detecting Unit- 226
[00102] Triggering Unit- 228
[00103] Probing Unit- 230
[00104] Processing hub-302
[00105] Data integration unit- 304
[00106] Data pre-processing unit-306
[00107] Model training unit-308
[00108] Prediction unit- 310
[00109] Data lake-312
[00110] Data Consumer 1- 314a
[00111] Data Consumer 2- 314b ,CLAIMS:CLAIMS:
We Claim:
1. A method (500) of detecting one or more anomalies in Call Release Reason (CRR) data, the method (500) comprising the steps of:
retrieving, by one or more processors (202), historical CRR data of one or more network components, from a probing unit (230);
training, by the one or more processors (202), a model utilizing the retrieved CRR data to analyse the CRR data;
determining, by the one or more processors (202), one or more threshold values of each of the one or more network components based on the analysed CRR data;
updating, by the one or more processors (202), one or more policies and the one or more threshold values of the one or more network components based on the determined one or more threshold values;
receiving, by the one or more processors (202), real-time CRR data of the one or more network components from the probing unit (230);
comparing, by the one or more processors (202), the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model; and
detecting, by the one or more processors (202), one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components.

2. The method (500) as claimed in claim 1, wherein on retrieving the data, the method includes the step of:
preprocessing, by the one or more processors (202), the retrieved CRR data by at least one of normalizing, cleaning, and transforming the retrieved CRR data.

3. The method (500) as claimed in claim 1, wherein the model is trained to identifying patterns pertaining to the retrieved data of the one or more network components.

4. The method (500) as claimed in claim 1, wherein the one or more threshold values are determined based on at least one of, time and geographical location.

5. The method (500) as claimed in claim 1, wherein on determining the one or more threshold values, the method includes the step of:
storing, by the one or more processors (202), the determined one or more threshold values of the one or more network components.

6. The method (500) as claimed in claim 1, wherein the probing unit (230) is communicably coupled to the one or more processors (202) to enable communication of the historical CRR data therebetween.

7. The method (500) as claimed in claim 1, wherein on detecting the one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values, the method includes the step of:
triggering, by the one or more processors (202), one or more actions in response to detecting the one or more anomalies in the one or more network components.

8. The method (500) as claimed in claim 7, wherein the one or more actions includes at least one of, rerouting network traffic, adjusting network resources, or triggering automated recovery procedures to mitigate the detected one or more anomalies.

9. A system (108) of detecting one or more anomalies in Call Release Reason (CRR) data, the system (108) comprising:
a retrieving unit (210), configured to, retrieve, historical CRR data of one or more network components from a probing unit (230);
a training unit (214), configured to, train, a model utilizing the retrieved CRR data to analyse the CRR data;
a determining unit (216), configured to, determine, one or more threshold values of each of the one or more network components based on the analysed CRR data;
an updating unit (220), configured to, update, one or more policies and the one or more threshold values of the one or more network components based on the determined one or more threshold values;
a receiving unit (222), configured to, receive, real-time CRR data of the one or more network components from the probing unit (230);
a comparing unit (224), configured to, compare, the real-time CRR data with the updated one or more threshold values of the one or more network components using the trained model; and
a detecting unit (226), configured to, detect, one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values of the one or more network components.

10. The system (108) as claimed in claim 9, wherein on retrieving the data, the system (108) comprises:
a preprocessing unit (212), configured to, preprocess, the retrieved CRR data by at least one of normalizing, cleaning, and transforming the retrieved CRR data.

11. The system (108) as claimed in claim 9, wherein the model is trained to identifying patterns pertaining to the retrieved data of the one or more network components.

12. The system (108) as claimed in claim 9, wherein the one or more threshold values are determined based on at least one of, time and geographical location.

13. The system (108) as claimed in claim 9, wherein on determining the one or more threshold values, the system (108) comprises:
a storing unit (218), configured to, store, the determined one or more threshold values of the one or more network components.

14. The system (108) as claimed in claim 9, wherein the probing unit (230) is communicably coupled to the retrieving unit (210) and the receiving unit (222) to enable communication of the historical CRR data therebetween.

15. The system (108) as claimed in claim 9, wherein on detecting the one or more anomalies based on the comparison of the real-time CRR data with the updated one or more threshold values, the system (108) comprises:
a triggering unit (228), configured to, trigger, one or more actions in response to detecting the one or more anomalies in the one or more network components.

16. The system (108) as claimed in claim 15, wherein the one or more actions includes at least one of, rerouting network traffic, adjusting network resources, or triggering automated recovery procedures to mitigate the detected one or more anomalies.