FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR AN AUTOMATIC ROOT CAUSE ANALYSIS OF AN ANOMALY IN A NETWORK”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

METHOD AND SYSTEM FOR AN AUTOMATIC ROOT CAUSE ANALYSIS OF AN ANOMALY IN A NETWORK
FIELD OF INVENTION
5
[0001] Embodiments of the present disclosure generally relate to network performance management systems. More particularly, embodiments of the present disclosure relate to methods and systems for performing automatic root cause analysis of an anomaly in a network. 10
BACKGROUND
[0002] The following description of the related art is intended to provide
background information pertaining to the field of the disclosure. This section may
15 include certain aspects of the art that may be related to various features of the
present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.
20 [0003] Network performance management systems typically track network
elements and data from network monitoring tools and combine and process such data to determine key performance indicators (KPI) of the network. Network performance management systems provide the means to visualize the network performance data so that network operators and other relevant stakeholders are able
25 to identify the service quality of the overall network, and individual/ grouped
network elements. By having an overall as well as detailed view of the network performance, the network operators can detect, diagnose and remedy actual service issues, as well as predict potential service issues or failures in the network and take precautionary measures accordingly.
30
2

[0004] A network performance management (NPM) system is commonly known
for performing ‘Network optimization’ operation and ‘Root Cause Analysis (RCA)’
operations on networks, each of which can greatly assist in enhancing the
performance and efficiency of networks. Specifically, in such NPM systems,
5 ‘Network Optimization’ and ‘RCA’ operations are used by the network operators,
to identify and address bottlenecks, improve throughput, reduce latency, and optimize overall network performance. Notably, the NPM system deploys an indexing layer, a normalizing layer, and a distributed file database. The indexing layer may be responsible for collecting a wide range of network data, including
10 traffic patterns, device performance metrics, error logs, and configuration settings
from multiple nodes in the network. Further, the normalizing layer may be responsible for pre-processing the collected network data into meaningful and processed network data. Furthermore, the distributed file database may store the processed network data therein.
15
[0005] For performing the ‘Network optimization’ and ‘RCA’ operations, a network operator retrieves the processed network data from the distributed file database; perform Root Cause Analytics (RCA) on the processed network data; identify the pinpoint RCA parameter in processed network data; and thereafter take corrective
20 actions for Network optimization. Such manual implementation of the ‘Network
optimization’ and ‘RCA’ operations, is prone to human errors, and may utilize efficient human resources.
[0006] Thus, there exists an imperative need in the art to provide a solution that can
25 overcome these and other limitations of the existing solutions.
SUMMARY
[0007] This section is provided to introduce certain aspects of the present disclosure
30 in a simplified form that are further described below in the detailed description.
3

This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0008] An aspect of the present disclosure may relate to a method for an automatic
5 root cause analysis of an anomaly in a network. The method comprises receiving,
by a first transceiver unit at an Ingestion Layer, network-related data pertaining to one or more network nodes. The method further comprises converting, by a first analysis unit at a Normalization Layer, the network-related data into a normalized network data, wherein the normalized network data comprises one or more network
10 attributes. The method further comprises retrieving, by a retrieval unit at an ML
layer, the normalized network data. The method further comprises training, by a training unit, the ML layer based on the one or more network attributes of the normalized network data The method further comprises receiving, by a second transceiver unit at an Analyser, a request from a user, wherein the request comprises
15 the network-related data. The method further comprises transmitting, by the second
transceiver unit, the request to the ML layer. The method further comprises analysing, by a processing unit at the ML layer, the received network-related data to identify the anomaly in the network. The method further comprises performing, by the processing unit at the ML layer, a processing on the identified anomaly in
20 the network to identify one or more root causes.
[0009] In an exemplary aspect of the present disclosure, the network-related data comprises a traffic pattern, one or more device performance metric, one or more error logs and one or more configuration settings.
25
[0010] In an exemplary aspect of the present disclosure, the converting, by the first analysis unit at the Normalization Layer, the network-related data into the normalized network data comprises cleaning the network-related data, removing outliers, and extracting one or more relevant features.
30
4

[0011] In an exemplary aspect of the present disclosure, the method further
comprises retrieving, by the retrieval unit at the ML layer a Transaction Per Second
(TPS) attribute of the normalized network data from at least one of a storage
repository. The method further comprises training, by the training unit at the ML
5 layer based on the Transaction Per Second (TPS) attribute of the normalized
network data to identify an anomaly in the normalized network data.
[0012] In an exemplary aspect of the present disclosure, the method further comprises generating, by a generation unit at the ML layer, a root cause analysis
10 (RCA) report based on the identified one or more root causes. The method further
comprises generating, by the generation unit at the ML layer, an optimization report based on the identified one or more actions for the network optimization. The method further comprises displaying, by a display unit at a user interface, at least one of the root cause analysis (RCA) report and the optimization report.
15
[0013] In an exemplary aspect of the present disclosure, the method further comprises comparing, by the processing unit at the ML layer, the network-related data with a historical trend on the normalized network data to identify the one or more root causes.
20
[0014] In an exemplary aspect of the present disclosure, the one or more root causes comprises at least one of a hardware failure, a network congestion, a misconfiguration, and a software bug.
25 [0015] In an exemplary aspect of the present disclosure, the method further
comprises performing one or more actions for optimization of the network, the one or more actions comprises at least one of a network configuration adjustment, a traffic rerouting, a resource reallocation, and a manual intervention alert.
30 [0016] Another aspect of the present disclosure may relate to a system for an
automatic root cause analysis of an anomaly in a network. The system comprising
5

an ingestion layer, a normalization layer, an ML layer, and an analyser connected
to each other. The ingestion layer comprising a first transceiver unit configured to
receive network-related data pertaining to one or more network nodes. The
normalization layer comprising a first analysis unit configured to convert the
5 network-related data into a normalized network data, wherein the normalized
network data comprises one or more network attributes. The ML layer comprises a retrieval unit, a training unit, and a processing unit connected with each other. The retrieval unit is configured to retrieve the normalized network data. The training unit is configured to train the ML layer based on the one or more network attributes
10 of the normalized network data. The analyser comprising a second transceiver unit
configured to receive a request from a user, the request comprising network-related data. The second transceiver unit is configured to transmit the request to the ML layer. The ML layer further comprising a processing unit configured to analyse the received network-related data to identify the anomaly in the network. The
15 processing unit is further configured to perform a processing on the identified
anomaly in the network to identify one or more root causes.
[0017] Yet aspect of the present disclosure may relate to a network node comprising a memory, and a processor coupled to the memory. The processor is configured to
20 transmit network-related data to a system. The network-related data is used by the
system for an automatic root cause analysis of an anomaly. The automatic root cause analysis of the anomaly in the network is based on converting the network-related data into a normalized network data. The conversion of the network-related data into the normalized network data is done by a normalization layer of the system.
25 The conversion of the network-related data is based on receiving the network-
related data at an Ingestion Layer. The normalized network data comprises one or more network attributes. The automatic root cause analysis is further based on retrieving the normalized network data by a machine learning (ML) layer of the system. The automatic root cause analysis is further based on training the ML layer.
30 The ML layer is trained based on the one or more network attributes of the
normalized network data. The automatic root cause analysis is further based on
6

receiving a request from a user, the request comprises the network-related first data.
The automatic root cause analysis is further based on transmitting the request to the
ML layer by the analyser. The automatic root cause analysis is further based on
analysing, by the ML layer, the received network-related data to identify the
5 anomaly in the network. The automatic root cause analysis is further based on
performing a processing on the identified anomaly in the network to identify one or more root causes.
[0018] Yet another aspect of the present disclosure may relate to a non-transitory
10 computer readable storage medium storing instructions for an automatic root cause
analysis of an anomaly in a network, the instructions include executable code which, when executed by one or more units of a system, causes a first transceiver unit of an ingestion layer of the system to receive network-related data pertaining to one or more network nodes. Further, the instructions include executable code
15 which, when executed causes a first analysis unit of a normalization layer of the
system to convert the network-related data into a normalized network data, wherein the normalized network data comprises one or more network attributes. Further, the instructions include executable code which, when executed causes a retrieval unit of the ML layer of the system to retrieve the normalized network data. Further, the
20 instructions include executable code which, when executed causes a training unit
of the ML layer of the system to train the ML layer based on the one or more network attributes of the normalized network data. Further, the instructions include executable code which, when executed causes a second transceiver unit at an analyser of the system to receive a request from a user, the request comprising
25 network-related data. Further, the instructions include executable code which, when
executed causes the second transceiver unit to transmit the request to the ML layer. Further, the instructions include executable code which, when executed causes a processing unit at the ML layer of the system to analyse the received network-related data to identify the anomaly in the network. Further, the instructions include
30 executable code which, when executed causes the processing unit to perform a
7

processing on the identified anomaly in the network to identify one or more root causes.
OBJECTS OF THE DISCLOSURE
5
[0019] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.
[0020] It is an object of the present disclosure to provide a system and a method for
10 performing an automatic root cause analysis of an anomaly in a network.
[0021] It is another object of the present disclosure to provide a system and a method for performing an optimization and an automatic root cause analysis in a network performance management system.
15
[0022] It is another object of the present disclosure to provide a system and method for performing artificial intelligence (AI) based ‘Network Optimization’ operation and ‘Automatic Root Cause Analysis’ (RCA) operations in a network performance management system.
20
DESCRIPTION OF THE DRAWINGS
[0023] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods
25 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. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system
30 according to the disclosure are illustrated herein to highlight the advantages of the
disclosure. It will be appreciated by those skilled in the art that disclosure of such
8

drawings includes disclosure of electrical components or circuitry commonly used to implement such components.
[0024] FIG. 1 illustrates an exemplary block diagram representation of a network
5 performance management system, in accordance with the exemplary embodiments
of the present invention.
[0025] FIG. 2 illustrates an exemplary block diagram of a computing device upon
which the features of the present disclosure may be implemented in accordance with
10 exemplary implementation of the present disclosure.
[0026] FIG. 3 illustrates an architecture of an exemplary system used for performing an optimization and an automatic root cause analysis.
15 [0027] FIG. 4 illustrates an exemplary block diagram of a system for an automatic
root cause analysis of an anomaly in a network, in accordance with exemplary implementations of the present disclosure.
[0028] FIG. 5 illustrates a method flow diagram for the automatic root cause
20 analysis of the anomaly in the network, in accordance with exemplary
implementations of the present disclosure.
[0029] FIG. 6 illustrates an exemplary method flow diagram for storage and fine tuning of the ML layer. 25
[0030] FIG. 7 illustrates another exemplary method flow diagram for the automatic root cause analysis of the anomaly in the network.
[0031] The foregoing shall be more apparent from the following more detailed
30 description of the disclosure.
9

DETAILED DESCRIPTION
[0032] In the following description, for the purposes of explanation, various
specific details are set forth in order to provide a thorough understanding of
5 embodiments of the present disclosure. It will be apparent, however, that
embodiments of the present disclosure may be practiced without these specific
details. Several features described hereafter may each be used independently of one
another or with any combination of other features. An individual feature may not
address any of the problems discussed above or might address only some of the
10 problems discussed above.
[0033] The ensuing description provides exemplary embodiments only, and is not
intended to limit the scope, applicability, or configuration of the disclosure. Rather,
the ensuing description of the exemplary embodiments will provide those skilled in
15 the art with an enabling description for implementing an exemplary embodiment.
It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
20 [0034] Specific details are given in the following description to provide a thorough
understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, processes, and other components may be shown as components in block diagram form in order not to obscure the
25 embodiments in unnecessary detail.
[0035] Also, it is noted that individual embodiments may be described as a process
which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure
diagram, or a block diagram. Although a flowchart may describe the operations as
30 a sequential process, many of the operations may be performed in parallel or
concurrently. In addition, the order of the operations may be re-arranged. A process
10

is terminated when its operations are completed but could have additional steps not included in a figure.
[0036] The word “exemplary” and/or “demonstrative” is used herein to mean
5 serving as an example, instance, or illustration. For the avoidance of doubt, the
subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques
10 known to those of ordinary skill in the art. Furthermore, to the extent that the terms
“includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
15
[0037] As used herein, a “processing unit” or “processor” or “operating processor” includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. A processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality
20 of microprocessors, one or more microprocessors in association with a Digital
Signal Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of
25 the system according to the present disclosure. More specifically, the processor or
processing unit is a hardware processor.
[0038] As used herein, “a user equipment”, “a user device”, “a smart-user-device”,
“a smart-device”, “an electronic device”, “a mobile device”, “a handheld device”,
30 “a wireless communication device”, “a mobile communication device”, “a
communication device” may be any electrical, electronic and/or computing device
11

or equipment, capable of implementing the features of the present disclosure. The
user equipment/device may include, but is not limited to, a mobile phone, smart
phone, laptop, a general-purpose computer, desktop, personal digital assistant,
tablet computer, wearable device or any other computing device which is capable
5 of implementing the features of the present disclosure. Also, the user device may
contain at least one input means configured to receive an input from unit(s) which are required to implement the features of the present disclosure.
[0039] As used herein, “storage unit” or “memory unit” refers to a machine or
10 computer-readable medium including any mechanism for storing information in a
form readable by a computer or similar machine. For example, a computer-readable
medium includes read-only memory (“ROM”), random access memory (“RAM”),
magnetic disk storage media, optical storage media, flash memory devices or other
types of machine-accessible storage media. The storage unit stores at least the data
15 that may be required by one or more units of the system to perform their respective
functions.
[0040] As used herein “interface” or “user interface refers to a shared boundary
across which two or more separate components of a system exchange information
20 or data. The interface may also be referred to a set of rules or protocols that define
communication or interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.
25 [0041] All modules, units, components used herein, unless explicitly excluded
herein, may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,
30 Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array
circuits (FPGA), any other type of integrated circuits, etc.
12

[0042] As used herein the transceiver unit include at least one receiver and at least
one transmitter configured respectively for receiving and transmitting data, signals,
information or a combination thereof between units/components within the system
5 and/or connected with the system.
[0043] As discussed in the background section, the current known solutions have
several shortcomings. The present disclosure aims to overcome the above-
mentioned and other existing problems in this field of technology by providing
10 method and system of performing an optimization and an automatic root cause
analysis in a network performance management system.
[0044] FIG. 1 illustrates an exemplary block diagram of a network performance management system [100], in accordance with the exemplary embodiments of the
15 present invention. Referring to FIG. 1, the network performance management
system [100] comprises various sub-systems such as: Network performance management system [100a], normalization layer [100b], computation layer [100d], anomaly detection layer [100o], streaming engine [100l], load balancer [100k], operations and management system [100p], API gateway system [100r], analysis
20 engine [100h], parallel computing framework [100i], forecasting engine [100t],
distributed file system, mapping layer [100s], distributed data lake [100u], scheduling layer [100g], reporting engine [100m], message broker [100e], graph layer [100f], caching layer [100c], service quality manager [100q] and correlation engine[100n]. Exemplary connections between these subsystems are also as shown
25 in FIG. 1. However, it will be appreciated by those skilled in the art that the present
disclosure is not limited to the connections shown in the diagram, and any other connections between various subsystems that are needed to realise the effects are within the scope of this disclosure.
30 [0045] Following are the various components of the system [100], the various
components may include:
13

[0046] Network performance management system [100a] comprise of a 5G performance management engine [100v] and a 5G Key Performance Indicator (KPI) Engine [100z]. 5
[0047] 5G Performance Management Engine [100v]: The 5G Performance Management engine [100v] is a crucial component of the Network system, responsible for collecting, processing, and managing performance counter data from various data sources within the network. The gathered data includes metrics
10 such as connection speed, latency, data transfer rates, and many others. This raw
data is then processed and aggregated as required, forming a comprehensive overview of network performance. The processed information is then stored in a Distributed Data Lake [100u], a centralized, scalable, and flexible storage solution, allowing for easy access and further analysis. The 5G Performance Management
15 engine [100v] also enables the reporting and visualization of this performance
counter data, thus providing network administrators with a real-time, insightful view of the network's operation. Through these visualizations, operators can monitor the network's performance, identify potential issues, and make informed decisions to enhance network efficiency and reliability.
20
[0048] 5G Key Performance Indicator (KPI) Engine [100z]: The 5G Key Performance Indicator (KPI) Engine is a dedicated component tasked with managing the KPIs of all the network elements. It uses the performance counters, which are collected and processed by the 5G Performance Management engine
25 [100v] from various data sources. These counters, encapsulating crucial
performance data, are harnessed by the KPI engine [100z] to calculate essential KPIs. These KPIs might include data throughput, latency, packet loss rate, and more. Once the KPIs are computed, they are segregated based on the aggregation requirements, offering a multi-layered and detailed understanding of network
30 performance. The processed KPI data is then stored in the Distributed Data Lake
[100u], ensuring a highly accessible, centralized, and scalable data repository for
14

further analysis and utilization. Similar to the Performance Management engine,
the KPI engine [100z] is also responsible for reporting and visualization of KPI
data. This functionality allows network administrators to gain a comprehensive,
visual understanding of the network's performance, thus supporting informed
5 decision-making and efficient network management.
[0049] Ingestion layer: The Ingestion layer forms a key part of the Network Performance Management system. Its primary function is to establish an environment capable of handling diverse types of incoming data. This data may be
10 network-related data which may include Alarms, Counters, Configuration
parameters, Call Detail Records (CDRs), Infrastructure metrics, Logs, clear codes, telemetry data and Inventory data, all of which are crucial for maintaining and optimizing the network's performance. Upon receiving this data, the Ingestion layer processes it by validating its integrity and correctness to ensure it is fit for further
15 use. Following validation, the data is routed to various components of the system,
including the Normalization layer, Streaming Engine, Streaming Analytics, and Message Brokers. The destination is chosen based on where the data is required for further analytics and processing. By serving as the first point of contact for incoming data, the Ingestion layer plays a vital role in managing the data flow
20 within the system, thus supporting comprehensive and accurate network
performance analysis.
[0050] Normalization layer [100b]: The Normalization Layer [100b] serves to standardize, enrich, and store data into the appropriate databases. It takes in data
25 that's been ingested and adjusts it to a common standard, making it easier to
compare and analyse. This process of "normalization" reduces redundancy and improves data integrity. Upon completion of normalization, the data is stored in various databases like the Distributed Data Lake [100u], Caching Layer, and Graph Layer, depending on its intended use. The choice of storage determines how the
30 data can be accessed and used in the future. Additionally, the Normalization Layer
[100b] produces data for the Message Broker, a system that enables communication
15

between different parts of the performance management system through the
exchange of data messages. Moreover, the Normalization Layer [100b] supplies the
standardized data to several other subsystems. These include the Analysis Engine
for detailed data examination, the Correlation Engine [100n] for detecting
5 relationships among various data elements, the Service Quality Manager for
maintaining and improving the quality of services, and the Streaming Engine for processing real-time data streams. These subsystems depend on the normalized data to perform their operations effectively and accurately, demonstrating the Normalization Layer's [100b] critical role in the entire system.
10
[0051] Caching layer [100c]: The Caching Layer [100c] in the Network Performance Management system plays a significant role in data management and optimization. During the initial phase, the Normalization Layer [100b] processes incoming raw data to create a standardized format, enhancing consistency and
15 comparability. The Normalizer Layer then inserts this normalized data into various
databases. One such database is the Caching Layer [100c]. The Caching Layer [100c] is a high-speed data storage layer which temporarily holds data that is likely to be reused, to improve speed and performance of data retrieval. By storing frequently accessed data in the Caching Layer [100c], the system significantly
20 reduces the time taken to access this data, improving overall system efficiency and
performance. Further, the Caching Layer [100c] serves as an intermediate layer between the data sources and the sub-systems, such as the Analysis Engine, Correlation Engine [100n], Service Quality Manager, and Streaming Engine. The Normalization Layer [100b] is responsible for providing these sub-systems with the
25 necessary data from the Caching Layer [100c].
[0052] Computation layer [100d]: The Computation Layer [100d] in the Network
Performance Management system serves as the main hub for complex data
processing tasks. In the initial stages, raw data is gathered, normalized, and enriched
30 by the Normalization Layer [100b]. The Normalizer Layer then inserts this
standardized data into multiple databases including the Distributed Data Lake
16

[100u], Caching Layer [100c], and Graph Layer, and also feeds it to the Message
Broker. Within the Computation Layer [100d], several powerful sub-systems such
as the Analysis Engine, Correlation Engine [100n], Service Quality Manager, and
Streaming Engine, utilize the normalized data. These systems are designed to
5 execute various data processing tasks. The Analysis Engine performs in-depth data
analytics to generate insights from the data. The Correlation Engine [100n]
identifies and understands the relations and patterns within the data. The Service
Quality Manager assesses and ensures the quality of the services. And the Streaming
Engine processes and analyses the real-time data feeds. In essence, the Computation
10 Layer [100d] is where all major computation and data processing tasks occur. It
uses the normalized data provided by the Normalization Layer [100b], processing it to generate useful insights, ensure service quality, understand data patterns, and facilitate real-time data analytics.
15 [0053] Message broker [100e]: The Message Broker [100e], an integral part of the
Network Performance Management system, operates as a publish-subscribe messaging system. It orchestrates and maintains the real-time flow of data from various sources and applications. At its core, the Message Broker [100e] facilitates communication between data producers and consumers through message-based
20 topics. This creates an advanced platform for contemporary distributed
applications. With the ability to accommodate a large number of permanent or ad-hoc consumers, the Message Broker [100e] demonstrates immense flexibility in managing data streams. Moreover, it leverages the filesystem for storage and caching, boosting its speed and efficiency. The design of the Message Broker [100e]
25 is centred around reliability. It is engineered to be fault-tolerant and mitigate data
loss, ensuring the integrity and consistency of the data. With its robust design and capabilities, the Message Broker [100e] forms a critical component in managing and delivering real-time data in the system.
30 [0054] Graph layer [100f]: The Graph Layer [100f], serving as the Relationship
Modeler, plays a pivotal role in the Network Performance Management system. It
17

can model a variety of data types, including alarm, counter, configuration, CDR
data, Infra-metric data, 5G Probe Data, and Inventory data. Equipped with the
capability to establish relationships among diverse types of data, the Relationship
Modeler offers extensive modelling capabilities. For instance, it can model Alarm
5 and Counter data, a probing solution, and Alarm data, elucidating their
interrelationships. Moreover, the Modeler should be adept at processing steps
provided in the model and delivering the results to the system requested, whether it
be a Parallel Computing system, Workflow Engine, Query Engine, Correlation
System [100n], 5G Performance Management Engine [100v], or 5G KPI Engine
10 [100z]. With its powerful modelling and processing capabilities, the Graph Layer
[100f] forms an essential part of the system, enabling the processing and analysis of complex relationships between various types of network data.
[0055] Scheduling layer [100g]: The Scheduling Layer [100g] serves as a key
15 element of the Network Performance Management System, endowed with the
ability to execute tasks at predetermined intervals set according to user preferences.
A task might be an activity performing a service call, an API call to another
microservice, the execution of an Elastic Search query, and storing its output in the
Distributed Data Lake [100u] or Distributed File System or sending it to another
20 micro-service. The versatility of the Scheduling Layer [100g] extends to facilitating
graph traversals via the Mapping Layer to execute tasks. This crucial capability
enables seamless and automated operations within the system, ensuring that various
tasks and services are performed on schedule, without manual intervention,
enhancing the system's efficiency and performance. In sum, the Scheduling Layer
25 [100g] orchestrates the systematic and periodic execution of tasks, making it an
integral part of the efficient functioning of the entire system.
[0056] Analysis Engine [100h]: The Analysis Engine [100h] forms a crucial part
of the Network Performance Management System, designed to provide an
30 environment where users can configure and execute workflows for a wide array of
use-cases. This facility aids in the debugging process and facilitates a better
18

understanding of call flows. With the Analysis Engine [100h], users can perform
queries on data sourced from various subsystems or external gateways. This
capability allows for an in-depth overview of data and aids in pinpointing issues.
The system's flexibility allows users to configure specific policies aimed at
5 identifying anomalies within the data. When these policies detect abnormal
behaviour or policy breaches, the system sends notifications, ensuring swift and
responsive action. In essence, the Analysis Engine [100h] provides a robust
analytical environment for systematic data interrogation, facilitating efficient
problem identification and resolution, thereby contributing significantly to the
10 system's overall performance management.
[0057] Parallel Computing Framework [100i]: The Parallel Computing Framework [100i] is a key aspect of the Network Performance Management System, providing a user-friendly yet advanced platform for executing computing
15 tasks in parallel. This framework showcases both scalability and fault tolerance,
crucial for managing vast amounts of data. Users can input data via Distributed File System (DFS) [100j] locations or Distributed Data Lake (DDL) indices. The framework supports the creation of task chains by interfacing with the Service Configuration Management (SCM) Sub-System. Each task in a workflow is
20 executed sequentially, but multiple chains can be executed simultaneously,
optimizing processing time. To accommodate varying task requirements, the service supports the allocation of specific host lists for different computing tasks. The Parallel Computing Framework [100i] is an essential tool for enhancing processing speeds and efficiently managing computing resources, significantly
25 improving the system's performance management capabilities.
[0058] Distributed File System [100j]: The Distributed File System (DFS) [100j]
is a critical component of the Network Performance Management System, enabling
multiple clients to access and interact with data seamlessly. This file system is
30 designed to manage data files that are partitioned into numerous segments known
as chunks. In the context of a network with vast data, the DFS [100j] effectively
19

allows for the distribution of data across multiple nodes. This architecture enhances
both the scalability and redundancy of the system, ensuring optimal performance
even with large data sets. DFS [100j] also supports diverse operations, facilitating
the flexible interaction with and manipulation of data. This accessibility is
5 paramount for a system that requires constant data input and output, as is the case
in a robust performance management system.
[0059] Load Balancer [100k]: The Load Balancer (LB) [100k] is a vital component of the Network Performance Management System, designed to
10 efficiently distribute incoming network traffic across a multitude of backend servers
or microservices. Its purpose is to ensure the even distribution of data requests, leading to optimized server resource utilization, reduced latency, and improved overall system performance. The LB [100k] implements various routing strategies to manage traffic. These include round-robin scheduling, header-based request
15 dispatch, and context-based request dispatch. Round-robin scheduling is a simple
method of rotating requests evenly across available servers. In contrast, header and context-based dispatching allow for more intelligent, request-specific routing. Header-based dispatching routes requests based on data contained within the headers of the Hypertext Transfer Protocol (HTTP) requests. Context-based
20 dispatching routes traffic based on the contextual information about the incoming
requests. For example, in an event-driven architecture, the LB [100k] manages event and event acknowledgments, forwarding requests or responses to the specific microservice that has requested the event. This system ensures efficient, reliable, and prompt handling of requests, contributing to the robustness and resilience of
25 the overall performance management system.
[0060] Streaming Engine [100l]: The Streaming Engine [100l], also referred to as
Stream Analytics, is a critical subsystem in the Network Performance Management
System. This engine is specifically designed for high-speed data pipelining to the
30 User Interface (UI). Its core objective is to ensure real-time data processing and
delivery, enhancing the system's ability to respond promptly to dynamic changes.
20

Data is received from various connected subsystems and processed in real-time by
the Streaming Engine [100l]. After processing, the data is streamed to the UI,
fostering rapid decision-making and responses. The Streaming Engine [100l]
cooperates with the Distributed Data Lake [100u], Message Broker [100e], and
5 Caching Layer [100c] to provide seamless, real-time data flow. Stream Analytics is
designed to perform required computations on incoming data instantly, ensuring
that the most relevant and up-to-date information is always available at the UI.
Furthermore, this system can also retrieve data from the Distributed Data Lake
[100u], Message Broker [100e], and Caching Layer [100c] as per the requirement
10 and deliver it to the UI in real-time. The streaming engine's [100l] ultimate goal is
to provide fast, reliable, and efficient data streaming, contributing to the overall performance of the management system.
[0061] Reporting Engine [100m]: The Reporting Engine [100m] is a key
15 subsystem of the Network Performance Management System. The fundamental
purpose of designing the Reporting Engine [100m] is to dynamically create report layouts of API data, catered to individual client requirements, and deliver these reports via the Notification Engine. The REM serves as the primary interface for creating custom reports based on the data visualized through the client's dashboard.
20 These custom dashboards, created by the client through the User Interface (UI),
provide the basis for the Reporting Engine [100m] to process and compile data from various interfaces. The main output of the Reporting Engine [100m] is a detailed report generated in Excel format. The Reporting Engine’s [100m] unique capability to parse data from different subsystem interfaces, process it according to the client's
25 specifications and requirements, and generate a comprehensive report makes it an
essential component of this performance management system. Furthermore, the Reporting Engine [100m] integrates seamlessly with the Notification Engine to ensure timely and efficient delivery of reports to clients via email, ensuring the information is readily accessible and usable, thereby improving overall client
30 satisfaction and system usability.
21

[0062] FIG. 2 illustrates an exemplary block diagram of a computing device [200]
upon which the features of the present disclosure may be implemented in
accordance with exemplary implementation of the present disclosure. In an
implementation, the computing device [200] may also implement a method for an
5 automatic root cause analysis of an anomaly in a network utilising the system. In
another implementation, the computing device [200] itself implements the method for the automatic root cause analysis in the network using one or more units configured within the computing device [200], wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
10
[0063] The computing device [200] may include a bus [202] or other communication mechanism for communicating information, and a hardware processor [204] coupled with bus [202] for processing information. The hardware processor [204] may be, for example, a general-purpose microprocessor. The
15 computing device [200] may also include a main memory [206], such as a random-
access memory (RAM), or other dynamic storage device, coupled to the bus [202] for storing information and instructions to be executed by the processor [204]. The main memory [206] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the
20 processor [204]. Such instructions, when stored in non-transitory storage media
accessible to the processor [204], render the computing device [200] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device [200] further includes a read only memory (ROM) [208] or other static storage device coupled to the bus [202] for storing static
25 information and instructions for the processor [204].
[0064] A storage device [210], such as a magnetic disk, optical disk, or solid-state
drive is provided and coupled to the bus [202] for storing information and
instructions. The computing device [200] may be coupled via the bus [202] to a
30 display [212], such as a cathode ray tube (CRT), Liquid crystal Display (LCD),
Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for
22

displaying information to a computer user. An input device [214], including
alphanumeric and other keys, touch screen input means, etc. may be coupled to the
bus [202] for communicating information and command selections to the processor
[204]. Another type of user input device may be a cursor controller [216], such as a
5 mouse, a trackball, or cursor direction keys, for communicating direction
information and command selections to the processor [204], and for controlling cursor movement on the display [212]. The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.
10
[0065] The computing device [200] may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computing device [200] causes or programs the computing device [200] to be a special-purpose machine.
15 According to one implementation, the techniques herein are performed by the
computing device [200] in response to the processor [204] executing one or more sequences of one or more instructions contained in the main memory [206]. Such instructions may be read into the main memory [206] from another storage medium, such as the storage device [210]. Execution of the sequences of instructions
20 contained in the main memory [206] causes the processor [204] to perform the
process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.
25 [0066] The computing device [200] also may include a communication interface
[218] coupled to the bus [202]. The communication interface [218] provides a two-way data communication coupling to a network link [220] that is connected to a local network [222]. For example, the communication interface [218] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or
30 a modem to provide a data communication connection to a corresponding type of
telephone line. As another example, the communication interface [218] may be a
23

local area network (LAN) card to provide a data communication connection to a
compatible LAN. Wireless links may also be implemented. In any such
implementation, the communication interface [218] sends and receives electrical,
electromagnetic or optical signals that carry digital data streams representing
5 various types of information.
[0067] The computing device [200] can send messages and receive data, including program code, through the network(s), the network link [220] and the communication interface [218]. In the Internet example, a server [230] might
10 transmit a requested code for an application program through the Internet [228], the
ISP [226], the local network [222], a host [224] and the communication interface [218]. The received code may be executed by the processor [204] as it is received, and/or stored in the storage device [210], or other non-volatile storage for later execution.
15
[0068] Referring to FIG. 3, an architecture of an exemplary system [300] used for performing an optimization and an automatic root cause analysis. In one example, the system [300] may be implemented as a Network Performance Management (NPM) system. In such case, the system [300] may function based on the block
20 diagram as explained in conjunction with FIG. 1. In another example, the system
[300] may be implemented as the system [200].
[0069] As depicted in FIG. 3, the system [300] illustrates various modules including, a Data Record [302], an Ingestion Layer [304], a Normalization Layer
25 [100b], an Analyser [306], an Artificial Intelligence/Machine Learning layer (ML
layer) [310], a Distributed Data Lake [100u], a Distributed File System [100j], a Streaming Engine [100l], and a User Interface (UI) [308]. It may be noted that a Hyper Text Transfer Protocol (HTTP) is deployed for communication between each of: the data records [302] and the ingestion layer [304]; the ingestion layer [304]
30 and the normalization layer [100b]; the Normalization Layer [100b] and the
Analyser [306]; the Analyser [306] and the User Interface (UI) [308]; the Analyser
24

[306] and the ML layer [310]; the Analyser [306] and the Streaming Engine [100l].
While a Transmission Control Protocol (TCP) is deployed for communication
between each of the Normalization Layer [100b] and the Distributed Data Lake
[100u]; the Normalization Layer [100b] and the Distributed File System [100j]; the
5 Analyser [306] and the Distributed Data Lake [100u]; the ML layer [310] and the
Distributed Data Lake [100u]. Accordingly, the afore-defined components of the system [300] communicate with each other, in order to perform an optimization and an automatic root cause analysis.
10 [0070] In the system [300], the data records [302] stores a network data, including
traffic patterns, device performance metrics, error logs, and configuration settings, received from multiple nodes in the network. The data records [302] may store the network-related data such as alarms, counters, configuration parameters, call detail records (CDRs), Infrastructure metrics, logs, clear codes, telemetry data and
15 inventory data. The ingestion layer [304] receives the network data from the data
record [302] and provide the same to the normalization layer [100b]. The normalization layer [100b] further pre-processes the network data to convert the same into normalized network data, such that the normalized network data is stored into the distributed data lake [100u] as well as the distributed file system [100j].
20 The ML layer [310] is adapted to perform machine learning on the normalized
network data, to identify the pinpoint RCA parameter from the normalized network data while performing the RCA operation thereof. The Analyser [306] is further adapted to initiate the RCA operations. A detailed working of various components of the system [300] can be understood from explanation of the below-mentioned
25 figures.
[0071] Referring to FIG. 4, an exemplary block diagram of a system [400] for an
automatic root cause analysis (RCA) of an anomaly in a network, is shown, in
accordance with the exemplary implementations of the present disclosure. Further,
30 the system [400] may also be used for performing an optimisation of the network
in an implementation of the present disclosure. The system [400] may in some
25

implementations comprise a network performance management (NPM) system, in
an implementation along with other subunits. In such implementations, the NPM
system may be used for optimising the network and may also be used for the
automatic RCA of the anomaly in the network. The system [300] and the NPM
5 system may in an implementation function in conjunction with each other. The
system [300] may also lie within the NPM system in another implementation of the present disclosure, along with other units. The working of such NPM system has been explained in conjunction with FIG. 1.
10 [0072] In another example, the system [400] may be implemented as the computing
device [200] as explained in conjunction with FIG. 2. In yet another example, the system [400] may be implemented within the computing device [200] along with other components. In yet another example, the system [400] may be implemented as the system [300] as explained in conjunction with FIG. 3.
15
[0073] As depicted in FIG. 4, the system [400] may include at least one normalization layer [100b], at least one ingestion layer [304], at least one user interface [308], at least one ML layer [310], at least one second transceiver unit [410], at least one second analysis unit [412], and at least one user interface [308].
20 The normalisation layer [100b] comprises at least one first analysis unit [404], and
at least one storage unit [416]. The ingestion layer [304] comprises at least one first transceiver unit [402]. The ML layer [310] comprises at least one retrieval unit [406], at least one training unit [408], at least one processing unit [414], and at least one generation unit [418]. The user interface [308] comprises at least one of a
25 display unit [420] and a third transceiver unit [422]. The ML layer [310] can be part
of the system [300], the system [400] or can also be a separate entity and may also be used by utilising services offered by service providers that offers machine learning as a service (MLaaS). Also, all of the components/ units of the system [300] are assumed to be connected to each other unless otherwise indicated below.
30 As shown in the figures all units shown within the system [300] should also be
assumed to be connected to each other. Also, in FIG. 3 only a few units are shown,
26

however, the system [300] may comprise multiple such units or the system [300]
may comprise any such numbers of said units, as required to implement the features
of the present disclosure. Further, in an implementation, the system [300] may be
present in a user device/ user equipment to implement the features of the present
5 disclosure. In another implementation, the system [300] may reside in a server or a
network entity.
[0074] The system [300] is configured for the automatic root cause analysis (RCA) of the anomaly in the network, with the help of the interconnection between the
10 components/units of the system [300]. In certain implementation of the present
disclosure, the interconnection of the components/ units of the system [300] may also be used for performing optimization or automatic RCA of the anomaly in the NPM system. The optimization refers to the optimization of the network performance by solving issues and problems caused within the one or more network
15 nodes. The automatic root cause analysis refers to the automatic analysis of the root
causes behind the issues and problems in the one or more network nodes. The network performance management system is a device which is used for managing the performance of the one or more network nodes.
20 [0075] In one example, in operation, the first transceiver unit [402] at the Ingestion
Layer [304] may receive network-related data pertaining to one or more network nodes. The network-related data may refer to the data associated with a traffic pattern, one or more device performance metric, one or more error logs and one or more configuration settings of the one or more network nodes. However, it may be
25 noted that such network-related data examples are only exemplary, and in no
manner to be construed to limit the scope of the present subject matter in any manner. The network-related data may include other data as well of the network nodes, and such examples would also lie within the scope of the present subject matter. Further, the one or more network nodes may refer to an electronic device
30 attached to a network that is capable of creating, receiving, or transmitting
information over a communication channel. For example, the one or more network
27

nodes may be 5G core network functions, a radio access network (RAN), a transport, a server device, a host, a container, or components used in the infrastructure. The network-related data may be received from the one or more network nodes and may also be received from a storage or a database. 5
[0076] After the network-related data is received by the first transceiver unit [402],
the first analysis unit [404] at the normalization layer [100b] may then convert the
network-related data into a normalized network data. The normalized network data
may include one or more network attributes. The normalized network data is a data
10 which is formed by conversion of the network-related data.
[0077] In one example, for converting the network-related data into the normalized network data, the first analysis unit [206A] may clean the network-related data, remove outliers, and extract one or more relevant features from the network-related
15 data. For cleaning the network-related data, the first analysis unit [206A] identifies
the outliers present within the network-related data, and then removes the identified outliers. Further, the analysis unit [206A] may also make the network-related data to be uniform as per the rules defined. In another example, the one or more network attributes of the thus-obtained normalized data may include attributes such as TPS
20 (Transactions Per Second) attribute, traffic levels, capacity, etc. In yet another
example, the one or more network attributes of the thus-obtained normalized data may further include network attributes such as Central Processing Unit (CPU) usage, disk usage, Random-Access Memory (RAM) usage. As would be understood, the TPS attribute is an attribute which shows the number of transactions
25 done by the one or more network nodes in one second. Further, the traffic level is
the number of users [702] using the one or more network nodes and the amount of data which is being transferred by the one or more network nodes.
[0078] Continuing further, the storage unit [416] at the Normalization Layer
30 [100b], may then store the normalized network data in a storage repository. In one
example, the storage repository may include at least one of the Distributed Data
28

Lake [100u] and the Distributed File System [100j]. In another example, the storage repository may be a combination of the distributed data lake [100u] and the distributed file system [100j].
5 [0079] After the normalized network data is stored, the retrieval unit [406] at the
ML layer [310] may then retrieve the normalized network data. In an
implementation of the present disclosure, the normalized network data may be
retrieved from the storage unit [416]. In another implementation of the present
disclosure, the normalized network data may be retrieved from the storage
10 repository.
[0080] Once the normalized network data is retrieved by the ML layer [310], the training unit [408] may then train the ML layer [310] based on the one or more network attributes of the normalized network data. In one example, the training unit
15 [408] may train the ML layer [310] based on one or more training models to identify
the anomaly on the normalized network data. In one example, the ML layer may be implemented as an Artificial Intelligence layer, a Machine Learning layer, or a combination thereof. Further, the one or more training models may be AI/ML models which may be specifically made for training the ML layer [310] using one
20 or more machine learning techniques. The ML layer [310] is trained based on a
labelled dataset, and one or more optimization techniques are applied to fine-tune one or more model parameters. The labelled dataset is a set of data comprising the data associated with the one or more network attributes. The one or more optimization techniques used for fine-tuning may be such as data featuring, data
25 filtering, data imputation and data filling, Auto Correlation Function (ACF), Partial
Auto Correlation Function (PACF), seasonality plots, etc.
[0081] In one example, the retrieval unit [406] of the ML layer [310] may retrieve
a Transaction Per Second (TPS) attribute of the normalized network data from at
30 least one of a storage repository. The TPS attribute is the attribute from the one or
more network attributes. In such cases, after the TPS attribute is retrieved by the
29

retrieval unit [406], the training unit [408] of the ML layer [310] may train the ML
layer [310] based on the Transaction Per Second (TPS) attribute of the normalized
network data to identify the anomaly on the normalized network data. In an
exemplary implementation, The TPS attribute may also be accompanied with/ or
5 comprise a TPS value and a corresponding TPS label. In such case, the TPS value
will indicate the number of transactions, and the corresponding TPS label would indicate the state of the TPS attribute for example, whether the TPS attribute is steady, abnormal, etc.
10 [0082] Continuing further, the ML layer [310], when trained, may be used to
identify an anomaly in the network. Further, in certain implementation, the ML layer [310] may also predict a network performance. The anomaly may be referred to as a problem in telecommunication networks due to which something goes against expectation. The network performance is the performance of the one or
15 more network nodes in the telecommunication network, which may be predicted by
the ML layer based on the one or more network attributes.
[0083] Continuing further, in operation, the second transceiver unit [410] of the analyser [306] may receive a request from a user. The received request may include
20 the network-related data. In one example, the user may be operating a User
Equipment (UE). In such cases, the user, via the UE, may initiate and transmit the request to the system. In another example, the user, via a User Interface (UI) of the UE, may initiate the request. However, it may be noted that all such examples are only for the sake of explanation, and in no manner is to construe the scope of the
25 present subject matter in any manner. The user may initiate and transmit the request
to the system in any manner and using any techniques known to a person skilled in the art. All such examples would lie within the scope of the present subject matter.
[0084] Continuing further, on receiving the request, the second transceiver unit
30 [410] may transmit the request to the ML layer [310] for further processing.
30

[0085] In an example, it may be the case, that the ML layer [310] may have not
been trained. In another example, it may also be the case that the ML layer [310]
although trained, may not be activated. In such cases, on receiving the request from
the user [702], the system, for analysing the root cause analysis of anomaly, may
5 retrieve the normalized network data from the storage repository (which had been
stored previously while receiving network-related data pertaining to different network nodes and converting such data to normalized data), as described previously. For example, on receiving the request, the second transceiver unit [410] may transmit the received request, via a Streaming Engine [100l], to the storage
10 repository. Thereafter, the normalized network data, which was stored previously
in the storage repository, may then be retrieved. It may be noted that such retrieval of normalized network data, without the use of ML layer [310], may keep happening in real-time and may allow the system to predict an anomaly and analysis the root cause of such anomaly when the ML layer [310] has not been activated. As would
15 be further noted and appreciated, such aspect of the present disclosure may also
allow the system to perform root cause analysis and network optimization in events when the ML layer [310] of the system may be down.
[0086] It may be further noted that the aforementioned scenario is only illustrative
20 and exemplary and is only an added advantage of the approaches of the present
subject matter.
[0087] Returning to present implementation, after the request is received by the ML
layer [310], the processing unit [414] of the ML layer [310] may analyse the
25 received network-related data present within the received request. The analysis of
the network-related data is done for identification of the anomaly in the network.
[0088] After the anomaly is identified in the network based on the analysis, the
processing unit [414] performs a processing on identified anomaly in the network
30 to identify one or more root causes. In one exemplary implementation of the present
disclosure, the processing unit [414] may compare the network-related data with a
31

historical trend on the normalized network data to identify the one or more root
causes. For example, the one or more root causes refers to the reason behind the
real-time trend of the one or more network attributes. In an implementation of the
present disclosure, the one or more root causes comprises at least one of a hardware
5 failure, a network congestion, a misconfiguration, and a software bug. As may be
known, the hardware failure refers to a malfunction within the electronic circuits or
electromechanical components of the hardware. Further, the network congestion
may refer to congestion at the one or more network nodes, which may be due to
high traffic at the one or more network nodes. In an example, the misconfiguration
10 refers to an issue in the configuration or settings of the one or more network nodes.
The software bug may refer to existence of bugs or problem in the software packages which are being used by the one or more network nodes.
[0089] In another implementation of the present disclosure, the processing unit
15 [414] performs the processing of the identified anomaly and then provide one or
more actions for optimization of the network. The one or more actions are the actions which are to be performed in order to perform the optimization of the network performance. The one or more actions for the network optimization comprise at least one of a network configuration adjustment, a traffic rerouting, a
20 resource reallocation, and a manual intervention alert. The network configuration
adjustment may refer to adjustment in the configurations or settings of the one or more network nodes in case of issues. The traffic rerouting refers to handover of traffic of one network node from the one or more network nodes to the other network node from the one or more network nodes. The resource reallocation refers
25 to the reallocation of hardware or software for performing the functions of the one
or more network nodes in case of hardware failures or software bugs. The manual intervention alert is an alert or indicator for indicating that the problem/issue cannot be solved and there is a need for a human intervention by a workmen or engineer for solving the problems/issues.
30
32

[0090] The present disclosure further provides that the generation unit [418] is
configured to generate a root cause analysis (RCA) report based on the identified
one or more root causes. The RCA report is a report which illustrates the one or
more root causes that are identified from the real—time trend from the one or more
5 network attributes. The generation unit [418] is further configured to generate an
optimization report based on the identified one or more actions for the network
optimization. The optimization report is a report which illustrates the one or more
actions that are being taken for optimization of the network performance or the
network performance management system. The display unit [420] at the user
10 interface [308] is configured to display at least one of the root cause analysis (RCA)
report and the optimization report. The display unit [420] can show both the RCA report as well as the optimization report.
[0091] Referring to FIG. 5, an exemplary method flow diagram [500] for an
15 automatic root cause analysis (RCA) of an anomaly in a network, in accordance
with exemplary implementations of the present disclosure is shown. Further, the
method [500] may also be used for performing an optimisation of the network in an
implementation of the present disclosure. In another implementation the method
[500] is performed by the system [400]. Further, in another implementation, the
20 system [400] may be present in a server device to implement the features of the
present disclosure. Also, as shown in FIG. 5, the method [500] starts at step [502].
[0092] The present disclosure provides following steps in the method [500] for the automatic root cause analysis in the network. In further implementations of the
25 present disclosure, the following steps may also be provided for performing
optimization of the network. In another implementation of the present disclosure, for performing the network optimization and the automatic RCA of the anomaly in the network, the present disclosure may be implemented in a Network Performance Management (NPM) system. The optimization refers to the optimization of the
30 network performance by solving issues and problems caused within the one or more
network nodes. The automatic root cause analysis refers to the automatic analysis
33

of the root causes behind the issues and problems in the one or more network nodes. The network performance management system is a device which is used for managing the performance of the one or more network nodes.
5 [0093] At step [504], the method [500] comprises receiving, by a first transceiver
unit [402] at an Ingestion Layer [304], network-related data pertaining to one or more network nodes. The network-related data may refer to the data associated with a traffic pattern, one or more device performance metric, one or more error logs and one or more configuration settings of the one or more network nodes. However, it
10 may be noted that such network-related data examples are only exemplary, and in
no manner to be construed to limit the scope of the present subject matter in any manner. The network-related data may include other data as well of the network nodes, and such examples would also lie within the scope of the present subject matter. Further, the one or more network nodes may refer to an electronic device
15 attached to a network that is capable of creating, receiving, or transmitting
information over a communication channel. For example, the one or more network nodes may be 5G core network functions, a radio access network (RAN), a transport, a server device, a host, a container, or components used in the infrastructure. The network-related data may be received from the one or more
20 network nodes and may also be received from a storage or a database.
[0094] After the network-related data is received by the first transceiver unit [402],
thereafter at step [506], the method [500] further comprises converting, by a first
analysis unit [404] at a Normalization Layer [100b], the network-related data into
25 a normalized network data. The normalized network data may include one or more
network attributes. The normalized network data is a data which is formed by conversion of the network-related data.
[0095] In one example, for converting the network-related data into the normalized
30 network data, the method [500] further comprises cleaning, by the first analysis unit
[206A], the network-related data, removing outliers, and extracting one or more
34

relevant features from the network-related data. For cleaning the network-related
data, the first analysis unit [206A] identifies the outliers present within the network-
related data, and then removes the identified outliers. Further, the analysis unit
[206A] may also make the network-related data to be uniform as per the rules
5 defined. In another example, the one or more network attributes of the thus-obtained
normalized data may include attributes such as TPS (Transactions Per Second) attribute, traffic levels, capacity, etc. In yet another example, the one or more network attributes of the thus-obtained normalized data may further include network attributes such as Central Processing Unit (CPU) usage, disk usage,
10 Random-Access Memory (RAM) usage. As would be understood, the TPS attribute
is an attribute which shows the number of transactions done by the one or more network nodes in one second. Further, the traffic level is the number of users [702] using the one or more network nodes and the amount of data which is being transferred by the one or more network nodes.
15
[0096] Continuing further, the present disclosure discloses that the method [500] further comprises storing, by a storage unit [416] at the Normalization Layer [100b], the normalized network data on a storage repository. In one example, the storage repository may include at least one of a Distributed Data Lake [100u] and
20 a Distributed File System [100j]. In another example, the storage repository may be
a combination of the distributed data lake [100u] and the distributed file system [100j].
[0097] After the normalized network data is stored at the normalization layer
25 [100b], then at step [508], the method [500] further comprises retrieving, by a
retrieval unit [406] at an ML layer [310], the normalized network data. In an
implementation of the present disclosure, the normalized network data may be
retrieved from the storage unit [416]. In another implementation of the present
disclosure, the normalized network data may be retrieved from the storage
30 repository.
35

[0098] Once, the normalized network data is retrieved by the ML layer [310], then
at step [510], the method [500] may further comprise training, by a training unit
[408], the ML layer [310] based on the one or more network attributes of the
normalized network data. In one example, the training of the ML layer [310] may
5 be based on one or more training models for identifying the anomaly on the
normalized network data. In one example, the training unit [408] may train the ML layer [310] based on one or more training models to identify the anomaly on the normalized network data. The one or more training models may be AI/ML models which may be specifically made for training the ML layer [310] using one or more
10 machine learning techniques. The ML layer [310] is trained based on a labelled
dataset, and one or more optimization techniques are applied to fine-tune one or more model parameters. The labelled dataset is a set of data comprising the data associated with the one or more network attributes. The one or more optimization techniques used for fine-tuning may be such as data featuring, data filtering, data
15 imputation and data filling, Auto Correlation Function (ACF), Partial Auto
Correlation Function (PACF), seasonality plots, etc.
[0099] In another implementation of the present disclosure, for converting, by the Normalization Layer [100b], the network-related data into the normalized network
20 data, the method [500] further comprises retrieving, by the retrieval unit [406] at
the ML layer [310] a Transaction Per Second (TPS) attribute of the normalized network data from at least one of a storage repository. The TPS attribute is the attribute from the one or more network attributes. After the TPS attribute is retrieved by the retrieval unit [406], the method [500] further comprises training, by the
25 training unit [408] at the ML layer [310] based on the Transaction Per Second (TPS)
attribute of the normalized network data to identify an anomaly on the normalized network data. In an exemplary implementation, The TPS attribute may also be accompanied with/ or comprise a TPS value and a corresponding TPS label. In such case, the TPS value will indicate the number of transactions, and the corresponding
30 TPS label would indicate the state of the TPS attribute for example, whether the
TPS attribute is steady, abnormal, etc.
36

[0100] Continuing further, the ML layer [310], when trained, may be used to
identify an anomaly in the network. Further, in certain implementation, the ML
layer [310] may also predict a network performance. The anomaly may be referred
5 to as a problem in telecommunication networks due to which something goes
against expectation. The network performance is the performance of the one or more network nodes in the telecommunication network, which may be predicted by the ML layer based on the one or more network attributes.
10 [0101] Continuing further, at step [512], the method [500] further comprises
receiving, by the second transceiver unit [410] of the analyser [306], a request from a user. The received request may include the network-related data. In one example, the user may be operating a User Equipment (UE). In such cases, the user, via the UE, may initiate and transmit the request to the system. In another example, the
15 user, via a User Interface (UI) of the UE, may initiate the request. However, it may
be noted that all such examples are only for the sake of explanation, and in no manner is to construe the scope of the present subject matter in any manner. The user may initiate and transmit the request to the system in any manner and using any techniques known to a person skilled in the art. All such examples would lie
20 within the scope of the present subject matter.
[0102] Continuing further, at step [514], on receiving the request, the method [500] further comprises, transmitting, by the second transceiver unit [410], the request to the ML layer [310] for further processing.
25
[0103] In an example, it may be the case, that the ML layer [310] may have not been trained. In another example, it may also be the case that the ML layer [310] although trained, may not be activated. In such cases, on receiving the request from the user [702], the system, for analysing the root cause analysis of anomaly, may
30 retrieve the normalized network data from the storage repository (which had been
stored previously while receiving network-related data pertaining to different
37

network nodes and converting such data to normalized data), as described
previously. For example, on receiving the request, the second transceiver unit [410]
may transmit the received request, via a Streaming Engine [100l], to the storage
repository. Thereafter, the normalized network data, which was stored previously
5 in the storage repository, may then be retrieved. It may be noted that such retrieval
of normalized network data, without the use of ML layer [310], may keep happening
in real-time and may allow the system to predict an anomaly and analysis the root
cause of such anomaly when the ML layer [310] has not been activated. As would
be further noted and appreciated, such aspect of the present disclosure may also
10 allow the system to perform root cause analysis and network optimization in events
when the ML layer [310] of the system may be down.
[0104] It may be further noted that the aforementioned scenario is only illustrative
and exemplary and is only an added advantage of the approaches of the present
15 subject matter.
[0105] Returning to present implementation, at step [516], after the request is
received by the ML layer [310], the method [500] further comprises, analysing, by
the processing unit [414] of the ML layer [310], the received network-related data
20 present within the received request. The analysis of the network-related data is done
for identification of the anomaly in the network.
[0106] After the anomaly is identified in the network based on the analysis, at step [518], the method [500] further comprises performing, by the processing unit [414]
25 at the ML layer [310], a processing on identified anomaly in the network to identify
one or more root causes. In one exemplary implementation of the present disclosure, the processing unit [414] may compare the network-related data with a historical trend on the normalized network data to identify the one or more root causes. For example, the one or more root causes refers to the reason behind the
30 real-time trend of the one or more network attributes. In an implementation of the
present disclosure, the one or more root causes comprises at least one of a hardware
38

failure, a network congestion, a misconfiguration, and a software bug. As may be
known, the hardware failure refers to a malfunction within the electronic circuits or
electromechanical components of the hardware. Further, the network congestion
may refer to congestion at the one or more network nodes, which may be due to
5 high traffic at the one or more network nodes. In an example, the misconfiguration
refers to an issue in the configuration or settings of the one or more network nodes. The software bug may refer to existence of bugs or problem in the software packages which are being used by the one or more network nodes.
10 [0107] In another implementation of the present disclosure, the method [500]
further comprises performing, by the processing unit [414] at the ML layer [310], the processing of the identified anomaly and then provide one or more actions for optimization of the network. The one or more actions are the actions which are to be performed in order to perform the optimization of the network performance. The
15 one or more actions for the network optimization comprise at least one of a network
configuration adjustment, a traffic rerouting, a resource reallocation, and a manual intervention alert. The network configuration adjustment may refer to adjustment in the configurations or settings of the one or more network nodes in case of issues. The traffic rerouting refers to handover of traffic of one network node from the one
20 or more network nodes to the other network node from the one or more network
nodes. The resource reallocation refers to the reallocation of hardware or software for performing the functions of the one or more network nodes in case of hardware failures or software bugs. The manual intervention alert is an alert or indicator for indicating that the problem/issue cannot be solved and there is a need for a human
25 intervention by a workmen or engineer for solving the problems/issues.
[0108] The present disclosure further provides that in another implementation of
the present disclosure, the method further comprises generating, by the generation
unit [418], a root cause analysis (RCA) report based on the identified one or more
30 root causes. The RCA report is a report which illustrates the one or more root causes
that are identified from the real—time trend from the one or more network
39

attributes. The generation unit [418] generates an optimization report based on the
identified one or more actions for the network optimization. The optimization report
is a report which illustrates the one or more actions that are being taken for
optimization of the network performance or the network performance management
5 system. The display unit [420] at the user interface [308] displays at least one of the
root cause analysis (RCA) report and the optimization report. The display unit [420] can show both the RCA report as well as the optimization report.
[0109] Thereafter, at step [520] the method terminates.
10
[0110] Referring to FIG. 6, a method flow diagram [600] for data storage and fine tuning of the ML layer [310] is disclosed. At step 1, the method [600] comprises sending the network-related data (shown as data in FIG. 6) from the data records [302] and receiving the same at the ingestion layer [304], which is already disclosed
15 in step [504] of the method [500]. Then at step 2, the method [600] comprises
processing the network-related data. The processing is done to convert the network-related data into the normalized network data, which is also already disclosed at step [506] of the method [500]. Thereafter, at steps 3 and 4, the method [600] comprises storing the normalized network data in each of the distributed data lake
20 [100u] and the distributed file system [100j] at the storage repository respectively.
Thereafter, at step 5 and step 7, the ML layer [310] fetches the normalized network data from each of the distributed data lake [100u] and the distributed file system [100j] respectively, for fine-tuning the ML layer [310]. Then at step 6 and step 8, the method [600] further comprises sending by the distributed data lake [100u] and
25 the distributed file system [100j], respectively, the required normalized network
data in response to the fetching by the ML layer [310], as disclosed by step [508] in method [500]. Finally, at step 9, the method [600] comprises training the ML layer [310] based on the received normalized network data from the distributed data lake [100u] and the distributed file system [100j], the training by the ML layer [310] is
30 also already disclosed in step [510].
40

[0111] The ML layer [310], when trained, may be used for predicting an anomaly
in the network. This has been further depicted in steps in FIG. 7. Referring to FIG.
7, a method flow diagram [700] as a further implementation of the present
disclosure is disclosed. The method [700], at step S1, comprises receiving, by the
5 third transceiver unit [422] at the user interface [308], a request for performing
optimization and automatic root cause analysis from a user [702]. Such user interface, in one example, may be of a user equipment associated with and operated by the user. The request is a request received from a user [702] for performing optimization and displaying the automatic root cause analysis. 10
[0112] Thereafter, at step S2, the third transceiver unit [422] the user interface [308] sends the request, for performing optimization and automatic root cause analysis, to the analyser [306]. This has been depicted in step [512] in method [500].
15 [0113] In an example, as further depicted in FIG. 7, it may be the case, that the ML
layer [310] may have not been trained. In another example, it may also be the case that the ML layer [310] although trained, may not be activated. In such cases, on receiving the request from the user [702], the system, for analysing the root cause analysis of anomaly, may retrieve the normalized network data from the storage
20 repository (which had been stored previously while receiving network-related data
pertaining to different network nodes and converting such data to normalized data), as described previously. For example, on receiving the request, the second transceiver unit [410] may transmit the received request, via a Streaming Engine [100l], to the storage repository (as depicted by steps S3 and S4 in FIG. 7).
25 Thereafter, the normalized network data, which was stored previously in the storage
repository, may then be retrieved (as depicted by step S5 in FIG. 7). It may be noted that such retrieval of normalized network data, without the use of ML layer [310], may keep happening in real-time and may allow the system to predict the real-time trend, i.e., an anomaly and analysis the root cause of such anomaly (as depicted by
30 step S6 in FIG. 7) when the ML layer [310] has not been activated. As would be
further noted and appreciated, such aspect of the present disclosure may also allow
41

the system to perform root cause analysis and network optimization in events when the ML layer [310] of the system may be down.
[0114] Continuing further, on receiving the request, the second transceiver unit
5 [410] may transmit the request to the ML layer [310] for further processing (as
depicted by step S7 in FIG. 7). In one example, to indicate that the ML layer [310] is active and in use, there may be a ‘ML flag’ which may be set ‘true’. The ML flag being true is a runtime configurable parameter that identifies whether the forecasting is required or not.
10
[0115] After the request is received by the ML layer [310], the processing unit [414] of the ML layer [310] may analyse the received network-related data present within the received request (as depicted by step S8 in FIG. 7). The analysis of the network-related data is done for identification of the anomaly in the network.
15
[0116] After the anomaly is identified in the network based on the analysis, the processing unit [414] performs a processing on identified anomaly in the network to identify one or more root causes.
20 [0117] In another implementation of the present disclosure, the processing unit
[414] performs the processing of the identified anomaly and then provide one or more actions for optimization of the network. The one or more actions are the actions which are to be performed in order to perform the optimization of the network performance. Such output may then be transmitted to the User [702] via
25 the User Interface [308]. This has been depicted by Steps S10 and S11 in FIG. 7.
[0118] The present disclosure further provides that the generation unit [418] is
configured to generate a root cause analysis (RCA) report based on the identified
one or more root causes. The RCA report is a report which illustrates the one or
30 more root causes that are identified from the real—time trend from the one or more
network attributes. The generation unit [418] is further configured to generate an
42

optimization report based on the identified one or more actions for the network
optimization. The optimization report is a report which illustrates the one or more
actions that are being taken for optimization of the network performance or the
network performance management system. The display unit [420] at the user
5 interface [308] is configured to display at least one of the root cause analysis (RCA)
report and the optimization report. The display unit [420] can show both the RCA report as well as the optimization report.
[0119] The present disclosure further discloses a network node comprising a
10 memory, and a processor coupled to the memory. The processor is configured to
transmit network-related data to a system. The network-related data is used by the system for an automatic root cause analysis of an anomaly. The automatic root cause analysis of the anomaly in the network is based on converting the network-related data into a normalized network data. The conversion of the network-related data
15 into the normalized network data is done by a normalization layer of the system.
The conversion of the network-related data is based on receiving the network-related data at an Ingestion Layer. The normalized network data comprises one or more network attributes. The automatic root cause analysis is further based on retrieving the normalized network data by a machine learning (ML) layer of the
20 system. The automatic root cause analysis is further based on training the ML layer.
The ML layer is trained based on the one or more network attributes of the normalized network data. The automatic root cause analysis is further based on receiving a request from a user, the request comprises the network-related first data. The automatic root cause analysis is further based on transmitting the request to the
25 ML layer by the analyser. The automatic root cause analysis is further based on
analysing, by the ML layer, the received network-related data to identify the anomaly in the network. The automatic root cause analysis is further based on performing a processing on the identified anomaly in the network to identify one or more root causes.
30
43

[0120] The present disclosure further discloses a non-transitory computer readable
storage medium storing instructions for an automatic root cause analysis of an
anomaly in a network, the instructions include executable code which, when
executed by one or more units of a system [400], causes a first transceiver unit [402]
5 of an ingestion layer of the system [400] to receive network-related data pertaining
to one or more network nodes. Further, the instructions include executable code which, when executed causes a first analysis unit [404] of a normalization layer of the system to convert the network-related data into a normalized network data, wherein the normalized network data comprises one or more network attributes.
10 Further, the instructions include executable code which, when executed causes a
retrieval unit [406] of the ML layer [310] of the system [400] to retrieve the normalized network data. Further, the instructions include executable code which, when executed causes a training unit [408] of the ML layer [310] of the system [400] to train the ML layer [310] based on the one or more network attributes of the
15 normalized network data. Further, the instructions include executable code which,
when executed causes a second transceiver unit [410] at an analyser of the system [400] to receive a request from a user, the request comprising network-related data. Further, the instructions include executable code which, when executed causes the second transceiver unit [410] to transmit the request to the ML layer [310]. Further,
20 the instructions include executable code which, when executed causes a processing
unit [414] at the ML layer [310] of the system to analyse the received network-related data to identify the anomaly in the network. Further, the instructions include executable code which, when executed causes the processing unit [414] to perform a processing on the identified anomaly in the network to identify one or more root
25 causes.
[0121] As is evident from the above, the present disclosure provides a technically
advanced solution for an automatic root cause analysis in a network. Also, the
present disclosure provides a technically advanced solution for performing
30 optimization of network. The present solution provides an efficient, faster, and
effective AI-based technique for performing artificial intelligence (AI) based
44

network optimization and automatic root cause analysis (RCA) in the network
performance management system. Accordingly, by combining AI/ML techniques
with network optimization and auto RCA, i.e. by using ML layer while performing
the method for ‘network optimization’ and ‘RCA’ operations, network operators can
5 proactively identify and address performance issues, optimize network resources,
and deliver a more reliable and efficient network infrastructure of the system.
Therefore, an advanced system and the method for performing AI-based technique
for performing artificial intelligence (AI) based network optimization and
automatic root cause analysis (RCA) in the network performance management
10 system, is disclosed herein.
[0122] While considerable emphasis has been placed herein on the disclosed
implementations, it will be appreciated that many implementations can be made and
that many changes can be made to the implementations without departing from the
15 principles of the present disclosure. These and other changes in the implementations
of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.
20 [0123] Further, in accordance with the present disclosure, it is to be acknowledged
that the functionality described for the various components/units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The
25 functionality of specific units as disclosed in the disclosure should not be construed
as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.
45

We Claim:
1. A method for an automatic root cause analysis of an anomaly in a network, the
method comprising:
5 - receiving, by a first transceiver unit [402] at an Ingestion Layer [304],
network-related data pertaining to one or more network nodes;
- converting, by a first analysis unit [404] at a Normalization Layer [100b],
the network-related data into a normalized network data, wherein the
normalized network data comprises one or more network attributes;
10 - retrieving, by a retrieval unit [406] at a machine learning (ML) layer [310],
the normalized network data;
- training, by a training unit [408], the ML layer [310] based on the one or
more network attributes of the normalized network data;
- receiving, by a second transceiver unit [410] at an Analyser [306], a request
15 from a user, wherein the request comprises the network-related data;
- transmitting, by the second transceiver unit [410], the request to the ML layer [310];
- analysing, by a processing unit [414] at the ML layer [310], the received network-related data to identify the anomaly in the network; and
20 - performing, by a processing unit [414] at the ML layer [310], a processing
on the identified anomaly in the network to identify one or more root causes.
2. The method as claimed in claim 1, wherein the network-related data comprises
a traffic pattern, one or more device performance metric, one or more error logs
and one or more configuration settings.
25 3. The method as claimed in claim 1, wherein the converting, by the first analysis
unit [404] at the Normalization Layer [100b], the network-related data into the normalized network data comprises cleaning the network-related data, removing outliers, and extracting one or more relevant features. 4. The method as claimed in claim 1, further comprising:

- retrieving, by the retrieval unit [406] at the ML layer [310] a Transaction
Per Second (TPS) attribute of the normalized network data from at least one
of a storage repository; and
- training, by the training unit [408], the ML layer [310] based on the
5 Transaction Per Second (TPS) attribute of the normalized network data to
identify an anomaly in the network. 5. The method as claimed in claim 1, the method further comprising:
- generating, by a generation unit [418] at the ML layer [310], a root cause
analysis (RCA) report based on the identified one or more root causes;
10 - generating, by the generation unit [418] at the ML layer [310], an
optimization report based on the identified one or more actions for the network optimization; and
- displaying, by a display unit [420] at a user interface [308], at least one of
the root cause analysis (RCA) report and the optimization report.
15 6. The method as claimed in claim 1, the method further comprising comparing,
by the processing unit [414] at the ML layer [310], the network-related data with a historical trend on the normalized network data to identify the one or more root causes.
7. The method as claimed in claim 1, wherein the one or more root causes
20 comprises at least one of a hardware failure, a network congestion, a
misconfiguration, and a software bug.
8. The method as claimed in claim 1, wherein the method further comprises
performing one or more actions for optimization of the network, the one or more
actions comprises at least one of a network configuration adjustment, a traffic
25 rerouting, a resource reallocation, and a manual intervention alert.
9. A system [400] for an automatic root cause analysis of an anomaly, the system
[400] comprising:
- an Ingestion Layer [304] comprising a first transceiver unit [402] configured
to receive network-related data pertaining to one or more network nodes;
30 - a Normalization Layer [100b] connected at least to the ingestion layer [304],
the normalization layer [100b] comprising:

o a first analysis unit [404] configured to convert the network-related data into a normalized network data, wherein the normalized network data comprises one or more network attributes;
- a machine learning (ML) layer [310] connected at least to the normalization
5 layer [100b], the ML layer [310] comprising:
o a retrieval unit [406] configured to retrieve the normalized network data;
and o a training unit [408] connected at least to the retrieval unit [406], the
training unit [408] configured to train the ML layer [310] based on the
10 one or more network attributes of the normalized network data;
- an analyser [306] connected at least to the ML layer [310], the analyser
[306] comprising:
o a second transceiver unit [410] configured to receive a request from a
user, the request comprising network-related data;
15 o the second transceiver unit [410] further configured to transmit the
request to the ML layer [310]; and
- the ML layer [310] further comprising:
o a processing unit [414] configured to analyse the received network-
related data to identify the anomaly in the network;
20 o the processing unit [414] configured to perform a processing on the
identified anomaly in the network to identify one or more root causes.
10. The system [400] as claimed in claim 9, wherein the network-related data
comprises a traffic pattern, one or more device performance metric, one or more
error logs and one or more configuration settings.
25 11. The system [400] as claimed in claim 9, wherein:
- the retrieval unit [406] at the ML layer [310] is further configured to retrieve
a Transaction Per Second (TPS) attribute of the normalized network data
from at least one of a storage repository; and
- the training unit [408] at the ML layer [310] is further configured to train
30 the ML layer [310] based on the Transaction Per Second (TPS) attribute of
the normalized network data to identify an anomaly in the network.

12. The system [400] as claimed in claim 9, wherein the first analysis unit [206A]
is further configured to convert the network-related data into the normalized
network data, clean the network-related data, remove outliers, and extract one
or more relevant features.
5 13. The system [400] as claimed in claim 9, wherein the ML layer [310] further
comprises a generation unit [418], the generation unit [418] configured to:
- generate a root cause analysis (RCA) report based on the identified one or
more root causes;
- generate an optimization report based on the identified one or more actions
10 for the network optimization; and
wherein the system [400] further comprises a user interface [308] connected at
least to the ML layer [310], the user interface [422] comprising a display unit
[420], wherein the display unit [420] is configured to display at least one of the
root cause analysis (RCA) report and the optimization report.
15 14. The system [400] as claimed in claim 12, wherein the processing unit [414] is
configured to compare the network-related data with a historical trend on the normalized network data to identify the one or more root causes.
15. The system [400] as claimed in claim 9, wherein the one or more root causes
comprises at least one of a hardware failure, a network congestion, a
20 misconfiguration, and a software bug.
16. The system [400] as claimed in claim 9, wherein the processing unit [414] is
further configured to perform one or more actions for optimization of the
network, the one or more actions comprises at least one of a network
configuration adjustment, a traffic rerouting, a resource reallocation, and a
25 manual intervention alert.
17. A network node comprising:
a memory, and
a processor coupled to the memory, wherein the processor is configured to:

transmit network-related data to a system [400], wherein the network-related data is used by the system [400] for automatic root cause analysis of an anomaly based on:
on receiving the network-related data at an Ingestion
5 Layer [304], converting, by a normalization layer [100b] of
the system [400], the network-related data into a normalized network data, wherein the normalized network data comprises one or more network attributes;
retrieving, by a machine learning (ML) layer [310] of
10 the system [400], the normalized network data;
training, the ML layer [310], based on the one or more network attributes of the normalized network data;
receiving, by an Analyser [306] of the system [400],
a request from a user, the request comprises the network-
15 related data;
transmitting, by the Analyser [306] of the system [400], the request to the ML layer [310];
analysing, by the ML layer [310], the received
network-related data to identify the anomaly in the network;
20 and
performing, by the ML layer [310] of the system [400], a processing on the identified anomaly in the network to identify one or more root causes.