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 AUTO ROOT CAUSE ANALYSIS AND NETWORK OPTIMISATION”
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 AUTO ROOT CAUSE ANALYSIS AND
NETWORK OPTIMISATION
FIELD OF THE DISCLOSURE
[0001] The present disclosure relates generally to the field of wireless communication systems. More particularly, the present disclosure relates to methods and systems for auto root cause analysis and network optimisation for telecommunication network.
BACKGROUND
[0002] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may 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 be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0003] Wireless communication technology has rapidly evolved over the past few decades, with each generation bringing significant improvements and advancements. The first generation of wireless communication technology was based on analog technology and offered only voice services. However, with the advent of the second-generation (2G) technology, digital communication and data services became possible, and text messaging was introduced. The third-generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth-generation (4G) technology revolutionized wireless communication with faster data speeds, better network coverage, and improved security. Currently, the fifth-generation (5G) technology is being deployed, promising even faster data speeds, low latency, and the ability to

connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users.
[0004] Moreover, in the wireless communication networks there are several users having their user devices in connection with several network cells. There are chances that due to some errors at the network wireless communication and/or the network cells side, the services as provided to the users get disrupted and therefore the users might have raised complaints with the customer service team of the wireless communication networks. In order to provide seamless services to the users there is a requirement to analyze the network cells. In an instance where one or more cells are having several complaints, it is required to identify, analyze, and optimize such cells.
[0005] Further, over the period of time various solutions have been developed to improve the performance of communication devices and wireless communication networks. However, there are certain challenges with existing solutions. For instance, the existing solutions are inefficient as it requires manual intervention for root cause analysis and requires manual assignment of work force for network optimization, which can be made efficient by providing an auto root cause analysis and network optimization.
[0006] Thus, there exists an imperative need in the art to provide a method and system for auto root cause analysis and network optimisation, which the present disclosure aims to address.
OBJECTS OF THE DISCLOSURE
[0007] Some of the objects of the present disclosure, which at least one implementation disclosed herein satisfies are listed herein below.

[0008] It is an object of the present disclosure to provide a system and a method for auto root cause analysis and network optimisation in telecommunication network.
[0009] It is another object of the present disclosure to provide a solution that can overcome the limitations of the existing solutions by automatically identifying various root causes leading to network issues and then by automatically optimizing the network.
[0010] It is yet another object of the present disclosure to provide a solution that can identify if a customer complaint tagged cell and a best server plot (BSP) cell is same or not, to further provide the root cause analysis and network optimization accordingly.
[0011] It is yet another object of the present disclosure to provide a solution that identifies a serving cell of a user equipment, verifies whether the identified serving cell is identical to an optimal serving cell determined based on an analysis of the BSP and performs a plurality of network tests on the identified serving cell to identify a root cause.
SUMMARY OF THE DISCLOSURE
[0012] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0013] A first aspect of the present disclosure is related to a method for performing auto root cause analysis and network optimization for a telecommunication network. The method comprising receiving, by a receiving unit, a set of data

associated with a service request, wherein the service request is associated with a user equipment. The method further comprises correlating, by a processing unit, the received set of data with a best server plot (BSP). The method further comprises identifying, by an identification unit, a serving cell of the user equipment based at least on the set of data. The method further comprises verifying, by the processing unit, whether the identified serving cell is identical to an optimal serving cell, wherein the optimal serving cell is determined based on an analysis of the BSP. The method further comprises performing, by the processing unit [104A], a plurality of network tests on the identified serving cell to identify a root cause based at least on the plurality of network tests. The method further comprises determining, by the processing unit, if any pre-defined action item exist for the identified root cause.
[0014] Further according to an aspect of the present disclosure, the method further comprises generating, by the processing unit, a work order if no pre-defined action item exist.
[0015] Further according to an aspect of the present disclosure, the received set of data comprises information related to at least the service request, a location, and a timestamp when the service request is raised.
[0016] Further according to an aspect of the present disclosure, the method further comprising checking, by the processing unit, whether there is an outage at the BSP prior to performing the plurality of network tests.
[0017] Further according to an aspect of the present disclosure, the plurality of network tests comprises at least one of an overshooting cell test, a poor coverage test, a congestion test, a serving cell backhaul test, a performance degradation test, a physical parameter discrepancy test, a service barring test, an interference test, a Physical Cell Identifier (PCI) test, or any other network test.

[0018] Further according to an aspect of the present disclosure, the overshooting cell test comprises determining, by the processing unit, whether a geo-location of an occurrence of issue falls outside a cell radius of the serving cell; and upon determining that the geo-location of the occurrence of issue falls outside the cell radius of the serving cell, identifying, by the processing unit, an overshooting cell as a root cause analysis (RCA).
[0019] Further according to an aspect of the present disclosure, the congestion test comprises determining, by the processing unit, whether the serving cell was consistently marked as a congested cell for a pre-defined duration; and upon determining that the serving cell was consistently marked as the congested cell for the pre-defined duration, identifying, by the processing unit, a congestion as a root cause analysis (RCA).
[0020] Further according to an aspect of the present disclosure, the poor coverage test comprises determining, by the processing unit, whether a geo-location of an occurrence of issue falls within a poor coverage area; and upon determining that the geo-location of the occurrence of issue falls within the poor coverage area, identifying, by the processing unit, a poor coverage as a root cause analysis (RCA).
[0021] Further according to an aspect of the present disclosure, the serving cell backhaul test comprises determining, by the processing unit, whether the serving cell had a backhaul during a raise time of the service request; and upon determining that the serving cell had the backhaul during the raise time of the service request, identifying, by the processing unit, a backhaul congestion as a root cause analysis (RCA).
[0022] Further according to an aspect of the present disclosure, the performance degradation test comprises determining, by the processing unit, whether at least one performance degradation alarm was raised during a raise time of the service request;

and upon determining the at least one performance degradation alarm was raised during the raise time of the service request, identifying, by the processing unit, a performance degradation as a root cause analysis (RCA).
[0023] Further according to an aspect of the present disclosure, the physical parameter discrepancy test comprises determining, by the processing unit, whether there is a presence of a physical parameter discrepancy on the serving cell; and upon determining that there is the presence of the physical parameter discrepancy on the serving cell, identifying, by the processing unit, a physical parameter discrepancy as a root cause analysis (RCA).
[0024] Further according to an aspect of the present disclosure, the service barring test comprises determining, by the processing unit, whether at least one service is barred on the serving cell; and upon determining that at least one service is barred on the serving cell, identifying, by the processing unit, a regulatory barring as a root cause analysis (RCA).
[0025] Further according to an aspect of the present disclosure, the interference test comprises determining, by the processing unit, whether there is an interference on the serving cell; and upon determining that there is the interference on the serving cell, identifying, by the processing unit, the interference as a root cause analysis (RCA).
[0026] Further according to an aspect of the present disclosure, the PCI test comprises determining, by the processing unit, whether there is at least one PCI conflict on the serving cell; and upon determining that there is said at least one PCI conflict on the serving cell, identifying, by the processing unit, a PCI conflict as a root cause analysis (RCA).

[0027] Another aspect of the present disclosure relates to a system for performing auto root cause analysis and network optimization for a telecommunication network is provided. The system comprising a receiving unit, a processing unit, and an identification unit connected to each other. The receiving unit is configured to receive a set of data associated with a service request, wherein the service request is associated with a user equipment. The processing unit is configured to correlate the received set of data with a best server plot (BSP). The identification unit is configured to identify a serving cell of the user equipment based at least on the received set of data. The processing unit is further configured to verify whether the identified serving cell is identical to an optimal serving cell, wherein the optimal serving cell is determined based on an analysis of the BSP. The processing unit is further configured to perform a plurality of network tests on the identified service cell to identify root cause based at least on the plurality of network tests. The processing unit is further configured to determine if any pre-defined action item exist for the identified root cause.
[0028] Further, another aspect of the present disclosure relates to a non-transitory computer readable storage medium storing instruction for performing auto root cause analysis and network optimisation for a telecommunication network. The instruction include executable code which, when executed by one or more units of a system, causes: a receiving unit of a system to receive a set of data associated with a service request, wherein the service request is associated with a user equipment; a processing unit of the system to correlate the received set of data with a best server plot (BSP); an identification unit of the system to identify a serving cell of the user equipment based at least on the received set of data ; the processing unit of the system to verify whether the identified serving cell is identical to an optimal serving cell, wherein the optimal serving cell is determined based on an analysis of the BSP; the processing unit of the system to perform a plurality of network tests on the identified service cell to identify root cause based at least on the plurality of network

tests; and the processing unit of the system to determine if any pre-defined action item exist for the identified root cause.
BRIEF DESCRIPTION OF DRAWINGS
[0029] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary implementations of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0030] FIG. 1 illustrates an exemplary block diagram representation of 5th generation core (5GC) network architecture.
[0031] FIG.1A illustrates an exemplary block diagram of a system [100A] for performing auto root cause analysis and network optimisation for a telecommunication network, in accordance with exemplary implementations of the present disclosure.
[0032] FIG.1B illustrates an exemplary block diagram of a computing device upon which the features of the present disclosure may be implemented, in accordance with exemplary implementation of the present disclosure.
[0033] FIG.2 illustrates an exemplary method [200] flow diagram indicating a process for auto root cause analysis and network optimisation for a

telecommunication network, in accordance with exemplary implementations of the present disclosure.
[0034] FIG.3A and FIG.3B illustrates an exemplary process [300] flow diagram for auto root cause analysis and network optimisation for a telecommunication network, in accordance with exemplary implementations of the present disclosure.
[0035] The foregoing shall be more apparent from the following more detailed description of the disclosure.
DETAILED DESCRIPTION
[0036] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of implementations of the present disclosure. It will be apparent, however, that implementations of the present disclosure may be practiced without these specific details. Several features described hereafter can 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 problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example implementations of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0037] The ensuing description provides exemplary implementations only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary implementations will provide those skilled in the art with an enabling description for implementing an exemplary implementation. 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.
[0038] It should be noted that the terms "mobile device", "user equipment", "user
5 device", “communication device”, “device” and similar terms are used
interchangeably for the purpose of describing the disclosure. These terms are not
intended to limit the scope of the disclosure or imply any specific functionality or
limitations on the described implementations. The use of these terms is solely for
convenience and clarity of description. The disclosure is not limited to any
10 particular type of device or equipment, and it should be understood that other
equivalent terms or variations thereof may be used interchangeably without departing from the scope of the disclosure as defined herein.
[0039] Specific details are given in the following description to provide a thorough
15 understanding of the implementations. However, it will be understood by one of
ordinary skill in the art that the implementations may be practiced without these
specific details. For example, circuits, systems, networks, processes, and other
components may be shown as components in block diagram form in order not to
obscure the implementations in unnecessary detail. In other instances, well-known
20 circuits, processes, algorithms, structures, and techniques may be shown without
unnecessary detail in order to avoid obscuring the implementations.
[0040] Also, it is noted that individual implementations may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a
25 structure diagram, or a block diagram. Although a flowchart may describe the
operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure.
30
11

[0041] The word “exemplary” and/or “demonstrative” is used herein to mean
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
5 necessarily to be construed as preferred or advantageous over other aspects or
designs, nor is it meant to preclude equivalent exemplary structures and techniques
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
10 similar to the term “comprising” as an open transition word—without precluding
any additional or other elements.
[0042] As used herein, an “electronic device”, or “portable electronic device”, or
“user device” or “communication device” or “user equipment” or “device” refers
15 to any electrical, electronic, electromechanical and computing device. The user
device is capable of receiving and/or transmitting one or parameters, performing
function/s, communicating with other user devices and transmitting data to the
other user devices. The user equipment may have a processor, a display, a memory,
a battery and an input-means such as a hard keypad and/or a soft keypad. The user
20 equipment may be capable of operating on any radio access technology including
but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low
Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance,
the user equipment may include, but not limited to, a mobile phone, smartphone,
virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-
25 purpose computer, desktop, personal digital assistant, tablet computer, mainframe
computer, or any other device as may be obvious to a person skilled in the art for
implementation of the features of the present disclosure.
[0043] Further, the user device may also comprise a “processor” or “processing
30 unit” includes processing unit, wherein processor refers to any logic circuitry for
12

processing instructions. The processor may be a general-purpose processor, a
special purpose processor, a conventional processor, a digital signal processor, a
plurality of microprocessors, one or more microprocessors in association with a
DSP core, a controller, a microcontroller, Application Specific Integrated Circuits,
5 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 the system according to the present disclosure. More specifically, the processor is a hardware processor.
10 [0044] As portable electronic devices and wireless technologies continue to
improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The
15 development, in this respect, has been incremental in the order of second generation
(2G), third generation (3G), fourth generation (4G), and now fifth generation (5G), and more such generations are expected to continue in the forthcoming time.
[0045] Radio Access Technology (RAT) refers to the technology used by mobile
20 devices/ user equipment (UE) to connect to a cellular network. It refers to the
specific protocol and standards that govern the way devices communicate with base
stations, which are responsible for providing the wireless connection. Further, each
RAT has its own set of protocols and standards for communication, which define
the frequency bands, modulation techniques, and other parameters used for
25 transmitting and receiving data. Examples of RATs include GSM (Global System
for Mobile Communications), CDMA (Code Division Multiple Access), UMTS
(Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and
5G. The choice of RAT depends on a variety of factors, including the network
infrastructure, the available spectrum, and the mobile device's/device's capabilities.
30 Mobile devices often support multiple RATs, allowing them to connect to different
13

types of networks and provide optimal performance based on the available network resources.
[0046] As discussed in the background section, the current known solutions have
5 several shortcomings such as being inefficient and requiring manual intervention
for root cause analysis in a wireless communication network. The present disclosure aims to overcome the above-mentioned and other existing problems, as known in the art, in this field of technology by providing a solution for auto root cause analysis and network optimisation for telecommunication network (also referred as
10 telecom or wireless communication network). The solution can identify if a
customer complaint tagged cell and a best server plot (BSP) cell is same or not, to further provide the root cause analysis and network optimization accordingly. Also, the present solution can overcome the limitations of the existing solutions by automatically identifying various root causes leading to network issues and then by
15 a solution for automatically optimizing the network for the automatically identified
various root causes.
[0047] Hereinafter, exemplary implementations of the present disclosure will be described with reference to the accompanying drawings.
20
[0048] FIG. 1 illustrates an exemplary block diagram representation of 5th generation core (5GC) network architecture, in accordance with exemplary implementation of the present disclosure. As shown in FIG. 1, the 5GC network architecture [100] includes a user equipment (UE) [102], a radio access network
25 (RAN) [104], an access and mobility management function (AMF) [106], a Session
Management Function (SMF) [108], a Service Communication Proxy (SCP) [110], an Authentication Server Function (AUSF) [112], a Network Slice Specific Authentication and Authorization Function (NSSAAF) [114], a Network Slice Selection Function (NSSF) [116], a Network Exposure Function (NEF) [118], a
30 Network Repository Function (NRF) [120], a Policy Control Function (PCF) [122],
14

a Unified Data Management (UDM) [124], an application function (AF) [126], a User Plane Function (UPF) [128], a data network (DN) [130], wherein all the components are assumed to be connected to each other in a manner as obvious to the person skilled in the art for implementing features of the present disclosure. 5
[0049] The User Equipment (UE) [102] interfaces with the network via the Radio Access Network (RAN) [104]; the Access and Mobility Management Function (AMF) [106] manages connectivity and mobility, while the Session Management Function (SMF) [108] administers session control; the service communication
10 proxy (SCP) [110] routes and manages communication between network services,
enhancing efficiency and security, and the Authentication Server Function (AUSF) [112] handles user authentication; the Network Slice Specific Authentication and Authorization Function (NSSAAF) [114] for integrating the 5G core network with existing 4G LTE networks i.e., to enable Non-Standalone (NSA) 5G deployments,
15 the Network Slice Selection Function (NSSF) [116], Network Exposure Function
(NEF) [118], and Network Repository Function (NRF) [120] enable network customization, secure interfacing with external applications, and maintain network function registries respectively; the Policy Control Function (PCF) [122] develops operational policies, and the Unified Data Management (UDM) [124] manages
20 subscriber data; the Application Function (AF) [126] enables application
interaction, the User Plane Function (UPF) [128] processes and forwards user data, and the Data Network (DN) [130] connects to external internet resources; collectively, these components are designed to enhance mobile broadband, ensure low-latency communication, and support massive machine-type communication,
25 solidifying the 5GC as the infrastructure for next-generation mobile networks.
[0050] Radio Access Network (RAN) [104] is the part of a mobile telecommunications system that connects user equipment (UE) [102] to the core network (CN) and provides access to different types of networks (e.g., 5G network).
15

It consists of radio base stations and the radio access technologies that enable wireless communication.
[0051] Access and Mobility Management Function (AMF) [106] is a 5G core
5 network function responsible for managing access and mobility aspects, such as UE
registration, connection, and reachability. It also handles mobility management procedures like handovers and paging.
[0052] Session Management Function (SMF) [108] is a 5G core network function
10 responsible for managing session-related aspects, such as establishing, modifying,
and releasing sessions. It coordinates with the User Plane Function (UPF) for data forwarding and handles IP address allocation and QoS enforcement.
[0053] Service Communication Proxy (SCP) [110] is a network function in the 5G
15 core network that facilitates communication between other network functions by
providing a secure and efficient messaging service. It acts as a mediator for service-based interfaces.
[0054] Authentication Server Function (AUSF) [112] is a network function in the
20 5G core responsible for authenticating UEs during registration and providing
security services. It generates and verifies authentication vectors and tokens.
[0055] Network Slice Specific Authentication and Authorization Function
(NSSAAF) [114] is a network function that provides authentication and
25 authorization services specific to network slices. It ensures that UEs can access only
the slices for which they are authorized.
[0056] Network Slice Selection Function (NSSF) [116] is a network function
responsible for selecting the appropriate network slice for a UE based on factors
30 such as subscription, requested services, and network policies.
16

[0057] Network Exposure Function (NEF) [118] is a network function that exposes capabilities and services of the 5G network to external applications, enabling integration with third-party services and applications. 5
[0058] Network Repository Function (NRF) [120] is a network function that acts as a central repository for information about available network functions and services. It facilitates the discovery and dynamic registration of network functions.
10 [0059] Policy Control Function (PCF) [122] is a network function responsible for
policy control decisions, such as QoS, charging, and access control, based on subscriber information and network policies.
[0060] Unified Data Management (UDM) [124] is a network function that
15 centralizes the management of subscriber data, including authentication,
authorization, and subscription information.
[0061] Application Function (AF) [126] is a network function that represents
external applications interfacing with the 5G core network to access network
20 capabilities and services.
[0062] User Plane Function (UPF) [128] is a network function responsible for handling user data traffic, including packet routing, forwarding, and QoS enforcement. 25
[0063] Data Network (DN) [130] refers to a network that provides data services to user equipment (UE) in a telecommunications system. The data services may include but are not limited to Internet services, private data network related services.
17

[0064] Referring to FIG. 1A, an exemplary block diagram of a system [100A] for
performing auto root cause analysis and network optimization for a
telecommunication network is shown, in accordance with the exemplary
implementations of the present disclosure. The system [100A] comprises at least
5 one of a receiving unit [102A], a processing unit [104A] and an identification unit
[106A] which may be connected to each other. Also, all of the components/ units of the system [100A] are assumed to be connected to each other unless otherwise indicated below. Also, in Fig. 1A only a few units are shown, however, the system [100A] may comprise multiple such units or the system [100A] may comprise any
10 such numbers of said units, as required to implement the features of the present
disclosure. Further, in an implementation, the system [100A] may be present in a server device to implement the features of the present disclosure. The system [100A] may be a part of the server device / or may be independent of but in communication with the server device.
15
[0065] The system [100A] is configured for performing the auto root cause analysis and network optimisation for the telecommunication network [hereinafter also referred as telecom], with the help of the interconnection between the components/units of the system [100A]. Further, a storage unit [not shown] may
20 also be provided to store a data as required to implement the features of the present
disclosure.
[0066] Also, in order to provide the auto root cause analysis and network optimisation for the telecom, the receiving unit [102A] of the system [100A] is
25 configured to receive a set of data associated with a service request, wherein the
service request is associated with a user equipment. The set of data may be an input from the service request from a customer complaint data. The present disclosure further discloses that the set of data or the received set of data may also comprise information related to at least the complaint category a location, and a timestamp
30 when the service request is raised. The present disclosure further discloses that the
18

customer complaint data may include a complaint related information and a time
related to complaints. The auto root cause analysis may refer to the automatic
analysis of a root cause behind some issues in the telecommunication network. Said
auto root cause analysis helps in performing network optimisation for solving the
5 issues based on the analysis of the root cause. The network optimisation refers to
performing optimisation operation to solve the issues in the telecommunication network. The telecommunication network refers to a group of network nodes interconnected by a telecommunications links, wherein the telecommunication links are used to exchange messages between the group of network nodes. The links
10 may use a variety of technologies based on the methodologies of circuit switching,
message switching, or packet switching, to pass messages and signals between the group of network nodes. The variety of technologies may refer to any generation of technology such as 2G, 3G, 4G, 5G, or sixth generation (6G), etc. The receiving unit [102A] is a unit capable of receiving a data, and may also be a transceiver unit
15 that may be capable of receiving and transmission of the data. The service request
may a request seeking a service by the user equipment for correction of issues between the connection of the user equipment and the telecommunication network, and may also be the complaint raised from the user equipment for network issues existing in the telecommunication network. The location may refer to the location
20 of the user equipment which is experiencing the issues. The timestamp may be an
information related to the time period for which or from which the user equipment is suffering the issues. The user equipment may also be the device used by a subscriber for connecting with the telecommunication network.
25 [0067] The processing unit [104A] is then configured to correlate the received set
of data with a best server plot (BSP). The processing unit [104A] may also be configured to determine a correlation of the customer complaint data with the best server plot (BSP) and perform verification of a possible serving cell versus an actual server cell. For example, the processing unit [104A] identifies that a complaint
30 tagged cell and the BSP cell are same or not. The BSP indicates the best serving cell
19

for a particular location which is obtained from a planning database and may also be obtained using the received set of data.
[0068] The identification unit [106A] is then configured to identify a serving cell
5 of the user equipment based at least on the received set of data. The serving cell
refers to the set of one or more cells that are serving the user equipment, the serving cell that is being used by the user equipment is based on the received set of data.
[0069] The processing unit [104A] is then configured to verify whether the
10 identified serving cell is identical to an optimal serving cell, wherein the optimal
serving cell is determined based on an analysis of the BSP. For determination of the
BSP the location of the service request which is obtained from the received set of
data, is used to derive cell information such as a cell identifier using the planning
database or a site database. Further a best cell may also be obtained along with the
15 cell identifier from the planning database. The derived cell identifier is then
compared with another cell identifier for determining the best serving cell.
[0070] Further, the processing unit [104A] is configured to perform a plurality of network tests on the identified serving cell to identify a root cause based at least on
20 the plurality of network tests. The plurality of network tests may be various tests on
network cells i.e., the serving cell to automatically identify the network issues based on the root causes behind these network issues. The root causes for such network issues may be such as an overshooting cell, a poor coverage, a congestion, a backhaul congestion, physical parameter discrepancy, a regulatory barring, an
25 interference, a physical cell identifier conflict, and a performance degradation, etc.
The present disclosure further discloses that the plurality of network tests that are performed for identifying the root causes may be an overshooting cell test, a poor coverage test, a congestion test, a serving cell backhaul test, a performance degradation test, a physical parameter discrepancy test, a service barring test, an
20

interference test, a Physical Cell Identifier (PCI) test, or may also be any other kind of network test such as the network test known in the art.
[0071] The plurality of network tests is further disclosed in detailed as follows,
5 however the disclosure is not limited thereto.
[0072] For the overshooting cell test, the processing unit [104A] is configured to determine whether a geo-location of an occurrence of issue falls outside a cell radius of the serving cell. Further, in an event upon determination that the geo-location of
10 the occurrence of issue falls outside the cell radius of the serving cell, the processing
unit [104A] is configured to identify an overshooting cell as a root cause analysis (RCA). The geo-location refers to the location of the user equipment and the serving cell. The occurrence of issues within a particular location which is outside the BSP, shows that the serving cell is the overshooting cell. The cell radius refers to the
15 range of the transmission of the serving cell, that range for the transmission of signal
may be the radius of the cell. An overshooting refers to a situation where an antenna transmits its signal beyond its intended coverage area and the overshooting cell is the terminal/antenna that is transmitting the signal beyond its intended coverage. The root cause analysis refers to the analysis of the root cause behind the network
20 issues which are detected based on the plurality of network tests. In order to perform
network optimisation for the above issue i.e., the overshooting cell, the optimisation may be done by performing a pre-defined action item associated with the overshooting cell which may be, for example, an action for correction of tilt of an antenna associated with the serving cell. In an exemplary scenario, the pre-defined
25 action item may be determined via an overshooting module, wherein the
overshooting module may be a module configured to correct the overshooting of the cell with the help of the processing unit [104A] of the system [100A].
[0073] For Congestion Test, the processing unit [104A] is configured to determine
30 whether the serving cell was consistently marked as a congested cell for a pre-
21

defined duration. Further, in an event upon a determination that the serving cell was
consistently marked as the congested cell for the pre-defined duration, the
processing unit [104A] is configured to identify a congestion as a root cause
analysis (RCA). The congested cell refers to a network cell under which too many
5 network users or user devices are trying to access a same cell. A congestion refers
to the situation where there are too many network users or user devices are simultaneously trying to access the same network resources, such as bandwidth, spectrum, or cell towers. The pre-defined duration is a duration which may be defined by a network entity such as network functions as per needs to be for
10 example a specified number of days, or specified number of weeks, etc. For
example, the congestion test checks whether the serving cell marked consistently as the congested cell in last 7 days out of 10 days then identify the RCA as the congestion. Further, in order to perform the network optimisation for the congestion of the congested cell the pre-defined action items may be performed. For instance,
15 the pre-defined action items for the congestion may be an action to correct the
congestion by offloading certain network users or the user devices. The present disclosure further discloses that the pre-defined action item to correct the congestion may also be performed by an offloading module with the help of the processing unit [104A] of the system [100A], wherein the offloading module is
20 configured to correct the network issues relating to the congestion.
[0074] For Poor Coverage Test, the processing unit [104A] is configured to determine whether a geo-location of an occurrence of issue falls within a poor coverage area. Further, upon determination that the geo-location of the occurrence
25 of issue falls within the poor coverage area, the processing unit [104A] is configured
to identify a poor coverage as a root cause analysis. The poor coverage area refers to a geographic area that experiences a reduced signal due to factors other than being distant from a cell tower. The poor coverage refers to the absence or improper propagation of a network signal or transmissions of network signals. The poor
30 coverage area may be identified through crowd source data, and further analysis of
22

the crowd source data may be done to map the cell as a serving cell to a possible
poor coverage polygon. The crowd source data means the data sourced from the
crowd. This may include information from various subscribers related to facing
issues in connection which may be due to poor coverage area. For identification of
5 poor coverage area parameters such as signal strength/power can be received based
on the crowd source data, and if the signal strength / power is low then it is
considered as the poor coverage area. Based on cell tagging and complaint location
the RCA as the poor coverage derived for further optimizations. For performing the
network optimisation for the poor coverage issue, the pre-defined action items
10 associated with the poor coverage may be performed. For example, the pre-defined
action items for the poor coverage may be an action to correct the poor coverage polygon.
[0075] For Serving Cell Backhaul Test, the processing unit [104A] is configured to
15 determine whether the serving cell had a backhaul during a raise time of the service
request. Further, upon the determination that the serving cell had the backhaul during the raise time of the service request, the processing unit [104A] is configured to identify a backhaul congestion as a root cause analysis (RCA). A backhaul may refer to a set of telecommunication links that connect a core (or backbone) network
20 with one or more smaller subnetworks before users can access the network by
accessing the one or more smaller subnetwork. Further, the backhaul may also be used to increase an expanse of coverage area associated with the core network. The raise time of the service request refers to a time period at which the service request was received by the receiving unit [102A]. The raise time may be shown as a
25 specific time of a day or specific day. The Backhaul congestion may refer to a
situation where the amount of a backhaul traffic is high which may result in buffering, packet loss, or blocking of new connections. If the serving cell had the backhaul congestion during the raise time of the service request or in other words, the customer complaint time/day then the RCA is identified as the backhaul
30 congestion. For performing network optimisation for the backhaul congestion, the
23

pre-defined action items associated with the backhaul congestion may be performed
which may include an action to correct backhaul congestions. The action to correct
backhaul congestions may comprise raising a ticket and assigning the ticket to the
concerned team which would solve the problem of backhaul congestions. Further,
5 the action to correct backhaul congestions comprises generating alarms to correct
the backhaul congestions and clear the alarms when these alarms are corrected.
[0076] For the Performance Degradation Test, the processing unit [104A] is configured to determine whether at least one performance degradation alarm was
10 raised during a raise time of the service request. Further, upon the determination
that said at least one performance degradation alarm was raised during the raise time of the service request, the processing unit [104A] is configured to identify a performance degradation as a root cause analysis (RCA). In such a scenario, wherein the performance degradation alarm is triggered, the performance
15 degradation alarm may generate an alert that the performance of the serving cell is
degrading, and that there is a need for servicing the cell to improve the performance of the cell. The performance degradation may refer to the reduction in capabilities of the serving cell to transmit and receive signals and deterioration of the quality of the network signal associated with the serving cell. Further, if the performance
20 degradation alarm is raised during the raise time of the service request and/or the
customer complaint, then the processing unit [104A] identified the RCA as the Performance Degradation alarm. The Performance degradation alarms may raise by a Radio network element generating various warnings and alerts in terms of different alarms, with help of a live data analytics of such all identified alarms. For
25 the network optimization for the identified issue based on the performance
degradation alarm, the pre-defined action items may be performed. For example, the pre-defined action items for the performance degradation may be a service action associated with the serving cell and a clear performance action associated with performance degradation alarm.
30
24

[0077] For Physical Parameter Discrepancy Test, the processing unit [104A] is
configured to determine whether there is presence of a physical parameter
discrepancy on the serving cell. Further, upon the determination that there is
presence of the physical parameter discrepancy on the serving cell, the processing
5 unit [104A] is configured to identify a physical parameter discrepancy as a root
cause analysis (RCA). The presence of the physical parameter discrepancy refers to
the situation where the discrepancy is present in the physical parameters associated
with the serving cell. The Physical Parameters discrepancy of the serving cell may
be derived via a physical discrepancy identification and mitigation engine. An
10 example of physical parameter discrepancy associated with the serving cell may be
a master database discrepancy and an on-field implemented configuration
discrepancy, which is a major issue in any telecommunication network. For
performing network optimisation for the root cause of the physical parameter
discrepancy, the pre-defined action items may be performed. For example, the pre-
15 defined action items for the physical parameter discrepancy may be an action to
correct physical configuration associated with the on-field implemented
configuration discrepancy. Another example for the pre-defined action items is to
perform a physical parameter optimisation action and/or soft parameter
optimisation action. The physical parameter optimisation actions and the soft
20 parameter optimisation action may be done by adjusting/modifying parameters such
as tilt, azimuth, power, and intensity by providing directions to the concerned
engineer or by work order generation.
[0078] For Service Barring Test, the processing unit [104A] is configured to
25 determine whether at least one service is barred on the serving cell. Further, upon
the determination that at least one service is barred on the serving cell, the
processing unit [104A] is configured to identify a regulatory barring as a root cause
analysis (RCA). The one service may refer to any of the services provided by the
service provider for telecommunication network. The barring of said at least one
30 service may refer to stopping of the at least one service from the services of the
25

telecommunication network that may be provided by a network service provider.
The term regulatory barring may refer to as the barring of the at least one service
due to certain regulations that may be implemented by legal authorities. If such
issue persists, then the processing unit [104A] identifies the RCA as the Regulatory
5 barring and may also direct to perform the pre-defined action items associated with
the regulatory barring. Service barring may refer to barring on a time to time basis by a government to impose some restriction on the network service provided by network provider in a particular region such as to control the law and order in that particular region. In such adverse condition if in any area any service need to barred
10 by operator then such information is processed and respective network cells are
tagged as barred. In case any customer is facing issue due to the regulatory barring than the processing unit [104A] identifies the regulatory barring as the RCA and then perform the pre-defined action items associated with the regulatory barring for network optimization. For example, the pre-defined action items for the regulatory
15 barring may be to provide the network users an update along with a possible time
of resolution for the regulatory barring.
[0079] For Interference Tests, the processing unit [104A] is configured to determine whether there is an interference on the serving cell. Further, upon the
20 determination that there is the interference on the serving cell, the processing unit
[104A] is configured to identify the interference as a root cause analysis (RCA). The interference refers to an obstruction which modifies a network signal in a disruptive manner, as it travels along a communication channel between its source and receiver. If the issue of interference exists, then the processing unit [104A]
25 identifies the interference as the RCA on the serving cell. The interference may be
caused due to a multi cell environment, an external source or an environment impact on the network. For performing network optimisation for the issue associated with the interference, the pre-defined action items may be performed by the processing unit [104A]. For example, the pre-defined action items for the interference may be
30 to perform an action for correcting the interference through software and hardware
26

optimisations. Software and hardware optimisations may be done by performing actions such as up-tilting/ down-tilting of the cells, these physical optimisations may be performed either manually or remotely, assigning work orders to concerned teams, performing software upgrade, and performing software roll-back. 5
[0080] For the Physical Cell Identifier Test, the processing unit [104A] is configured to determine whether there is at least one PCI conflict on the serving cell. Further, upon the determination that there is said at least one PCI conflict on the serving cell, the processing unit [104A] is configured to identify a PCI conflict
10 as a root cause analysis (RCA). A physical cell identifier (PCI) is a unique identifier
assigned to each cell within the network to differentiate and distinguish between neighbouring cells. The PCI conflict is when two or more neighbouring cells are assigned the same PCI and this causes confusion for the user device as it can't differentiate between the cells based on the PCI leading to issues with handovers,
15 measurements, and overall network performance. The system [100A] checks
whether the serving cell is having the PCI conflict. If yes, then tags the RCA as the PCI Conflict and performs the pre-defined action items for network optimisation. The pre-defined action items which may be performed for the network optimisation may be an action to correct the planning of the PCI.
20
[0081] As disclosed by the present disclosure, the processing unit [104A] is configured to determine if any pre-defined action item exist for the identified root cause. In case no pre-defined action item is present, the processing unit [104A] is configured to generate a work order if no pre-defined action item exist. The work
25 order may be a direction for a workman or service field engineer to check manually
for issues within the telecommunication network and correct the root cause. The pre-defined action item refers to the actions which are to be performed for the network optimisation which are pre-defined based on the root cause analysis of the network issues.
30
27

[0082] The present disclosure further discloses that the processing unit [104A] may
also be configured to check an outage at the BSP prior to performing the plurality
of network tests. The outage may be a power outage at the BSP which may be a
reason for the root cause. If the root cause is caused due to the power outage then
5 in that case, the root cause analysis is tagged as the outage. Then in an event an
estimated end time associated with the outage is provided then based on the estimated end time the work order may be generated.
[0083] The solution as disclosed in present disclosure for the performing auto root
10 cause analysis and network optimization for the telecommunication network may
utilise multiple in specialised root cause analysis engine network parameters and/or the key performance indicators (KPI) associated with telecommunication network, a telecommunication network events to identify accurate the root cause and the pre¬defined action item to optimize the telecommunication network.
15
[0084] Fig. 1B illustrates an exemplary block diagram of a computing device [1000] 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 [1000] may also implement a method [200]
20 for performing auto root cause analysis and network optimization for a
telecommunication network by utilising the system [100A]. In another implementation, the computing device [1000] itself implements the method [200] for performing auto root cause analysis and network optimization for a telecommunication network using one or more units configured within the
25 computing device [1000], wherein said one or more units are capable of
implementing the features as disclosed in the present disclosure.
[0085] The computing device [1000] may include a bus [1002] or other
communication mechanism for communicating information, and a hardware
30 processor [1004] coupled with bus [1002] for processing information. The hardware
28

processor [1004] may be, for example, a general-purpose microprocessor. The
computing device [1000] may also include a main memory [1006], such as a
random-access memory (RAM), or other dynamic storage device, coupled to the
bus [1002] for storing information and instructions to be executed by the processor
5 [1004]. The main memory [1006] also may be used for storing temporary variables
or other intermediate information during execution of the instructions to be
executed by the processor [1004]. Such instructions, when stored in non-transitory
storage media accessible to the processor [1004], render the computing device
[1000] into a special-purpose machine that is customized to perform the operations
10 specified in the instructions. The computing device [1000] further includes a read
only memory (ROM) [1008] or other static storage device coupled to the bus [1002] for storing static information and instructions for the processor [1004].
[0086] A storage device [1010], such as a magnetic disk, optical disk, or solid-state
15 drive is provided and coupled to the bus [1002] for storing information and
instructions. The computing device [1000] may be coupled via the bus [1002] to a
display [1012], such as a cathode ray tube (CRT), Liquid crystal Display (LCD),
Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for
displaying information to a computer user. An input device [1014], including
20 alphanumeric and other keys, touch screen input means, etc. may be coupled to the
bus [1002] for communicating information and command selections to the
processor [1004]. Another type of user input device may be a cursor controller
[1016], such as a mouse, a trackball, or cursor direction keys, for communicating
direction information and command selections to the processor [1004], and for
25 controlling cursor movement on the display [1012]. This 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.
[0087] The computing device [1000] may implement the techniques described
30 herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware
29

and/or program logic which in combination with the computing device [1000]
causes or programs the computing device [1000] to be a special-purpose machine.
According to one implementation, the techniques herein are performed by the
computing device [1000] in response to the processor [1004] executing one or more
5 sequences of one or more instructions contained in the main memory [1006]. Such
instructions may be read into the main memory [1006] from another storage
medium, such as the storage device [1010]. Execution of the sequences of
instructions contained in the main memory [1006] causes the processor [1004] to
perform the process steps described herein. In alternative implementations of the
10 present disclosure, hard-wired circuitry may be used in place of or in combination
with software instructions.
[0088] The computing device [1000] also may include a communication interface [1018] coupled to the bus [1002]. The communication interface [1018] provides a
15 two-way data communication coupling to a network link [1020] that is connected
to a local network [1022]. For example, the communication interface [1018] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication
20 interface [1018] may be a 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 [1018] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
25
[0089] The computing device [1000] can send messages and receive data, including program code, through the network(s), the network link [1020] and the communication interface [1018]. In the Internet example, a server [1030] might transmit a requested code for an application program through the Internet [1028],
30 the ISP [1026], the local network [1022], a host [1024] and the communication
30

interface [1018]. The received code may be executed by the processor [1004] as it is received, and/or stored in the storage device [1010], or other non-volatile storage for later execution.
5 [0090] Referring to FIG. 2 an exemplary method flow diagram [200] for auto root
cause analysis and network optimisation for a telecommunication network, in accordance with exemplary implementations of the present disclosure is shown. In an implementation the method [200] is performed by the system [100A]. As shown in Fig. 2, the method [200] starts at step [202].
10
[0091] At step [204], the method [200] as disclosed by the present disclosure comprises receiving, by a receiving unit [102A], a set of data associated with a service request, and wherein the service request is associated with a user equipment. The set of data may also be an input from the service request which may also be a
15 customer complaint data. The present disclosure further discloses that the set of data
or the received set of data may also comprise information related to at least the complaint category, a location, and a timestamp when the service request is raised. The present disclosure further discloses that the customer complaint data may include a complaint related information and a time related to complaints. The auto
20 root cause analysis may refer to the automatic analysis of a root cause behind some
issues in the telecommunication network. This auto root cause analysis helps in performing network optimisation for solving the issues. The network optimisation refers to performing optimisation to solve the issues in the telecommunication network. The telecommunication network refers to a group of nodes interconnected
25 by telecommunications links that are used to exchange messages between the
nodes. The links may use a variety of technologies based on the methodologies of circuit switching, message switching, or packet switching, to pass messages and signals. The variety of technologies may refer to any generation of technology such as 2G, 3G, 4G, 5G, or sixth generation (6G). The receiving unit [102A] is a unit
30 capable of receiving data, and may also be a transceiver unit that may be capable of
31

receiving and transmission of data. The service request may a request seeking a
service of the user equipment for correction of issues between the connection of the
user equipment and the telecommunication network, and may also be a complaint
that certain issues exist in the telecommunication network. The location refers to
5 the location of the user equipment which is experiencing the issues. The timestamp
may be an information related to the time period for which the user equipment is suffering the issues. The user equipment may also be the device used by a subscriber for connecting with the telecommunication network.
10 [0092] Next at step [206] of the method [200] comprises correlating, by a
processing unit [104A], the received set of data with a best server plot (BSP). The processing unit [104A] is a unit capable of processing data and may also be a processor capable of processing data and converting input into output. The processing unit [104A] may also be configured to determine a correlation of the
15 customer complaint data with best server plot (BSP) and performs verification of
possible serving cell versus actual server cell. For example, the processing unit [104A] identifies that a complaint tagged cell and BSP cell are same or not. The BSP indicates the best serving cell for a particular location which is obtained from a planning database and may also be obtained using the received set of data.
20
[0093] Next at step [208] of the method [200], the method [200] comprises, identifying, by the identification unit [106A], a serving cell of the user equipment that is based at least on the set of data. The serving cell refers to the set of one or more cells that are serving the user equipment, the serving cell that is being used by
25 the user equipment is based on the received set of data.
[0094] Thereafter, at step [210], the method [200] further comprises, verifying, by
the processing unit [104A], whether the identified serving cell is identical to an
optimal serving cell, where the optimal serving cell is determined based on an
30 analysis of the BSP. For determination of the BSP the location of the service request
32

which is obtained from the received set of data, is used to derive cell information
such as a cell identifier using the planning database or a site database. Further a best
cell may also be obtained along with the cell identifier from the planning database.
The derived cell identifier is then compared with another cell identifier for
5 determining the best serving cell.
[0095] Further, at step [212] of the method [200], the method [200] further comprises, performing, by the processing unit [104A], a plurality of network tests on the identified serving cell to identify a root cause, the identification of the root
10 cause may be based at least on the plurality of network tests. The plurality of
network tests may be various tests on network cells to automatically identify various network issues and the root causes behind these network issues. The network issues and the root causes for such network issues may be such as an overshooting cell, a poor coverage, a congestion, a backhaul congestion, physical
15 parameter discrepancy, a regulatory barring, an interference, a physical cell
identifier conflict, and a performance degradation etc. The present disclosure further discloses that the plurality of network tests that are performed for identifying the root causes may be an overshooting cell test, a poor coverage test, a congestion test, a serving cell backhaul test, a performance degradation test, a physical
20 parameter discrepancy test, a service barring test, an interference test a physical cell
identifier (PCI) test, or may also be any other kind of network test that may be known in the art.
[0096] In an implementation, the plurality of network tests may be as follows,
25 however the disclosure is not limited thereto.
[0097] For Overshooting Cell Test, the test includes determining, by the processing
unit [104A], whether a geo-location of an occurrence of issue falls outside a cell
radius of the serving cell and then based on said determination, identifying, by the
30 processing unit [104A], an overshooting cell as a root cause analysis (RCA). The
33

geo-location refers to the location of the user equipment and the serving cell. The
occurrence of issues within a particular location which is outside the BSP, shows
that the cell is overshooting. The cell radius refers to the range of the transmission
of the serving cell, that range for the transmission of signal may be the radius of the
5 cell. Overshooting refers to a situation where an antenna transmits its signal beyond
its intended coverage area and the overshooting cell is the terminal/antenna that is transmitting the signal beyond its intended coverage. The root cause analysis refers to the analysis of the root cause behind the network issues which are detected based on the plurality of network tests. In order to perform network optimisation for the
10 above issue, the optimisation may be done by performing the pre-defined action
item which may be, for example, an action for correction of tilt of the antenna of the serving cell, which may be based on an overshooting module, where the overshooting module may be a module known in the art which may be specifically designed to correct the overshooting of the cell with the help of the processing unit
15 [104A] of the system [100A].
[0098] For Congestion Test, the test includes, determining, by the processing unit [104A], whether the serving cell was consistently marked as a congested cell for a pre-defined duration, and then based upon determination, identifying, by the
20 processing unit [104A], a congestion as a root cause analysis (RCA). The congested
cell refers to a cell under which too many users or devices are trying to access the same cell. The congestion refers to the situation where there are too many users or devices trying to access the same network resources, such as bandwidth, spectrum, or cell towers. The pre-defined duration is a duration which may be defined by a
25 network entity as per needs to be for example a specified number of days, or
specified number of weeks, etc. For example, the congestion test checks whether the serving cell marked consistently as the congested cell in last 7 days out of 10 days then tags the RCA as Congestions. For performing the network optimisation for congestion of the congested cells the pre-defined action items may be
30 performed. For example, the pre-defined action items may be to perform an action
34

to correct congestion by offloading certain users. The present disclosure further discloses that the action to correct congestion may also be performed by an offloading module with the help of the processing unit [104A] of the system [100A], which is specifically designed to correct the issues relating to congestion. 5
[0099] For Poor Coverage Test, the test includes determining, by the processing unit [104A], whether a geo-location of an occurrence of issue falls within a poor coverage area and based upon determination, identifying, by the processing unit [104A], a poor coverage as a root cause analysis. The poor coverage area refers to
10 a geographic area that experiences reduced signal due to factors other than being
distant from a cell tower. The poor coverage refers to the absence or improper propagation of signal or transmissions of signals. The poor coverage area may be identified through crowd source data and further analysis may be done to map cell as a serving cell to possible poor coverage polygon. The crowd source data means
15 the data sourced from the various subscribers. This may include information from
various subscribers related to facing issues in connection which may be due to poor coverage area. For identification of poor coverage area parameters such as signal strength/power can be received based on the crowd source data, and if the signal strength / power is low then it is considered as the poor coverage area. Based on
20 cell tagging and complaint location RCA of poor coverage is derived for further
optimizations. For performing the network optimisation for the poor coverage issue, the pre-defined action items may be performed which may be defined for correction of the poor coverage. For example, the pre-defined action items for poor coverage may be an action to correct poor coverage polygon.
25
[0100] For Serving Cell Backhaul Test, the test includes determining, by the processing unit [104A], whether the serving cell had a backhaul during a raise time of the service request, and based upon determination, identifying, by the processing unit [104A], a backhaul congestion as a root cause analysis (RCA). The backhaul
30 may refer to as the set of links that connect the core (or backbone) networks with
35

the smaller subnetworks towards the edge before users can access the network by
accessing the subnetwork, it may also be used to increase the expanse of network
coverage. The raise time of the service request refers to the time period at which the
service request was received by the receiving unit [102A]. The raise time may be
5 shown as a specific time or specific day. Backhaul congestion may refer to a
situation where the amount of backhaul traffic is high which may result in buffering, packet loss, or blocking of new connections. If the serving cell had the backhaul congestion during a raise time of the service request or in other words, the complaint time/ day then tag RCA as backhaul congestions. For performing network
10 optimisation for backhaul congestion, the pre-defined action items may be
performed which may include an action to correct backhaul congestions. The action to correct backhaul congestions may comprise raising a ticket and assigning the ticket to the concerned team which would solve the problem of backhaul congestions. Further, the action to correct backhaul congestions comprises
15 generating alarms to correct the backhaul congestions and clear the alarms when
these alarms are corrected.
[0101] For Performance Degradation Test, the test includes determining, by the processing unit [104A], whether at least one performance degradation alarm was
20 raised during the raise time of the service request, and based upon determination,
identifying, by the processing unit [104A], a performance degradation as a root cause analysis (RCA). The at least one performance degradation alarm may be an alert for alerting that the performance of the cell is degrading, and that there is a need for servicing the cell to improve the performance of the cell. The performance
25 degradation may refer to the reduction in capabilities of the cell to transmit and
receive signals and deterioration of the quality of the signal. It checks if performance degradation alarm is raised during the raise time of the service request/ the complaint time then tags the RCA as Performance Degradation alarm. The Performance degradation alarms may relate to Radio network elements generating
30 various warnings and issues in terms of different alarms, with help of live data
36

analytics of such all identified alarms. For network optimizations based on the issue of performance degradation alarm, the pre-defined action items may be performed. For example, the pre-defined action items for performance degradation may be to service the cell and clear performance degradation alarm. 5
[0102] For Physical Parameter Discrepancy Test, the test includes determining, by the processing unit [104A], whether there is a presence of a physical parameter discrepancy on the serving cell, and based upon determination, identifying, by the processing unit [104A], a physical parameter discrepancy as a root cause analysis
10 (RCA). The presence of the physical parameter discrepancy refers to the situation
where the discrepancy is present in the physical parameters. The Physical Parameters discrepancy on the serving cell may be derived from a physical discrepancy identification and mitigation algorithm. An example of physical parameter discrepancy may be a discrepancy in a master database and on field
15 implemented configuration which is a major issue in any telecom network. For
performing network optimisation for the issue of physical parameter discrepancy, the pre-defined action items may be performed. For example, the pre-defined action items for physical parameter discrepancy may be an action to correct physical configuration on site. Another example for pre-defined action items is to perform a
20 physical parameter or soft parameter optimisation. The physical parameter
optimisation actions and the soft parameter optimisation action may be done by adjusting/modifying parameters such as tilt, azimuth, power, and intensity by providing directions to the concerned engineer or by work order generation.
25 [0103] For Service Barring Test, the test includes determining, by the processing
unit [104A], whether at least one service is barred on the serving cell, and based upon determination, identifying, by the processing unit [104A], a regulatory barring as a root cause analysis (RCA). At least one service may refer to any of the services provided by the service provider for telecommunication network. The barring of
30 said at least one service may refer to the stoppage of the services of the
37

telecommunication network that may be provided by the service providers. Is any
service barred on cell. regulatory barring may refer to as the barring of the services
due to certain regulations that may be implemented by the legal authorities. If such
issue persists, then the processing unit [104A] tags RCA as Regulatory barring and
5 may also direct to perform certain pre-defined action items. Service barring may
also refer to barring on a time to time basis by the government to impose some
restriction on service provided by operator to control law and order. In such adverse
condition if any area any service need to barred by operator then such information
is processed and respective cells are tagged. In case any customer is facing issue
10 due to regulatory barring than tags such as RCA and then perform the pre-defined
action items for network optimisation. For example, the pre-defined action items for regulatory barring may be to provide users an update along with possible time to resolutions.
15 [0104] For Interference Tests, the test includes, determining, by the processing unit
[104A] whether there is an interference on the serving cell, and based upon determination, identifying, by the processing unit [104A], the interference as the root cause analysis (RCA). The interference refers to an obstruction which modifies a signal in a disruptive manner, as it travels along a communication channel
20 between its source and receiver. If the issue of interference exists, then tags RCA as
Interference on Cell. Interference may cause serious problem to user experience, interference may be due to multi cell environment, external sources or environment impact on network. The Cell may also be tagged as interference cell and corresponding RCA and certain resolution may be provided. The resolution may be
25 to perform the pre-defined action items. For example, the pre-defined action items
for interference may be to perform an action for correcting interference through software and hardware optimisations. Software and hardware optimisations may be done by performing actions such as up-tilting/ down-tilting of the cells, these physical optimisations may be performed either manually or remotely, assigning
38

work orders to concerned teams, performing software upgrade, and performing software roll-back.
[0105] For the Physical Cell Identifier Test, the test includes determining, by the
5 processing unit [104A], whether there is at least one physical cell identifier (PCI)
conflict on the serving cell, and based upon determination, identifying, by the processing unit [104A], a PCI conflict as a root cause analysis (RCA). A physical cell identifier (PCI) is a unique identifier assigned to each cell within the network to differentiate and distinguish between neighbouring cells. The PCI conflict is
10 when two or more nearby cells are assigned the same PCI and this causes confusion
for the user device as it can't differentiate between the cells based on the PCI leading to issues with handovers, measurements, and overall network performance. The system [100A] checks whether the cell is having PCI conflict. If yes, then tags RCA as PCI Conflict and performs certain action for resolutions. The certain actions may
15 be pre-defined action items which may be performed. For example, the pre-defined
action items for PCI conflict may be an action to correct the planning of PCI.
[0106] Then, at step [214] of the method [200], the method [200] further comprises
determining, by the processing unit [104A], if any pre-defined action item is present
20 for the identified network issues and root causes. In case no pre-defined action item
is present then generating, by the processing unit [104A] a work order for the identified network issues and root causes.
[0107] Further, the generation, by the processing unit [104A] is based on the work
25 order and the pre-defined action items provides the auto root cause analysis and
network optimisation. The work order may be a direction for a workman or service
field engineer to check manually for issues within the communication network and
correct the errors/issues. The pre-defined action item refers to the actions which are
to be performed for network optimisation which are pre-defined based on the root
30 cause analysis of the network issues.
39

[0108] The present disclosure further discloses checking, by the processing unit
[104A], an outage at the BSP prior to performing the plurality of network tests. The
outage may be a power outage at the BSP due to which the issue is caused. If the
5 issue is caused due to the outage then in that case, the root cause analysis is tagged
as outage. Then if an estimated time for outage to end is provided then it is checked, and based on the estimated time, the work order is generated.
[0109] Thereafter, the method terminates at step [216].
10
[0110] Moreover, in FIG. 3a and FIG. 3b (collectively referred as FIG. 3), an exemplary the process [300] for auto root cause analysis and network optimisation for a telecommunication network is shown in accordance with exemplary implementations of the present disclosure. The FIG. 3a and FIG. 3b are part of the
15 same process flow diagram and may be referred to be as a whole. However, it is
pertinent to note that the present disclosure is not limited and non-restrictive, and the scope of the present disclosure may extend to any implementation that may be obvious to a person skilled in the art for any use case in light of the present disclosure.
20 The process [300] for auto root cause analysis and network optimisation starts at
step [302].
[0111] Thereafter, at step [304], the process [300] comprises receiving input of complaints with the serving cell. [0112] Then, at step [306], the process [300] comprises finding correlation between
25 the cell at the issue location and the BSP.
[0113] Then, at step [308], the process [300] comprises checking if the complaint tagged cell and the BSP are the same. If the complaint tagged cell and the BSP cell are not same, then an outage test is performed. If the complaint tagged cell and the BSP cell are same, then, at steps [310], [310A], [310B], [310B], [310C], [310D],
30 [310E], [310F], [310G], and [310H], the plurality of network tests is performed.
40

The plurality of network test can be performed in any sequence and should not be
limited to the sequence disclosed in the present disclosure. The sequence can also
be randomly decided or pre-decided and may also be dynamically changed. Further,
any of the plurality of network tests may also be skipped and may also be performed
5 again. If the complaint tagged cell and the BSP cell are not the same, then checking,
at step [310I], whether the BSP cell is having an outage. If the result is NO, then
the plurality of network test is performed. If the result is yes, and the BSP cell is
having an outage, then at step [312I] shown in FIG. 3b, tagging that the issue is due
to the outage on BSP serving cell and also checks whether any ETA is available if
10 the outage continues. At step [322], generation of a work order is done for
correction of the issue. Thereafter, at step [326], the process is terminated.
[0114] At step [310], the overshooting cell test is performed. The process [300] comprises checking if the issue location is falling outside the cell radius of the
15 serving cell. Then based on the response of checking, if the response is no, then the
overshooting cell test [310] is ended at step [324], and thereafter, the process [300] is terminated at step [326]. If the response is yes, then at step [314], tagging the RCA as overshooting cell, and then at step [316], performing an action to correct the tilt as per some over-shooter module may be done. Then at step [318], if there
20 is any earlier action planned for this RCA, then at step [320], exclusion of the
planned action is done and then at step [322], generation of work order is done. Exclusion may refer to increasing the occurrence count for the earlier work order or increasing the severity of the work order after a certain threshold/time. Thereafter, at step [326], the process [300] is terminated.
25
[0115] At step [310A], the poor coverage test is performed. The process [300] comprises checking if the identified cell is reported consistently as a congested cell. Then based on the response of checking, if the response is no, then the poor coverage test [310A] is ended at step [324], and thereafter, the process [300] is
30 terminated at step [326]. If the response is yes, then at step [314A], tagging the RCA
41

as congestion, and then at step [316A], performing an action to correct congestion
as per offloading module may be done. Then at step [318], if there is any earlier
action planned for this RCA, then at step [320], execution of the planned action is
done and then at step [322], generation of work order is done. Thereafter, at step
5 [326], the process [300] is terminated.
[0116] At step [310B], the congestion test is performed. The process [300] comprises checking if the issue location is falling within the poor coverage polygon. Then based on the response of checking, if the response is no, then the congestion
10 test [310B] is ended at step [324], and thereafter, the process [300] is terminated at
step [326]. If the response is yes, then at step [314B], tagging the RCA as poor coverage, and then at step [316B], performing an action to correct poor coverage polygon which may be done by some module. Then at step [318], if there is any earlier action planned for this RCA, then at step [320], execution of the planned
15 action is done and then at step [322], generation of work order is done. Thereafter,
at step [326], the process [300] is terminated.
[0117] At step [310C], the serving cell backhaul test is performed. The process [300] comprises checking if the serving cell is having backhaul congestion during
20 the complaint time. Then based on the response of checking, if the response is no,
then the serving cell backhaul test [310C] is ended at step [324], and thereafter, the process [300] is terminated at step [326]. If the response is yes, then at step [314C], tagging the RCA as backhaul congestions, and then at step [316C], performing an action to correct backhaul congestions may be done. Then at step [318], if there is
25 any earlier action planned for this RCA, then at step [320], execution of the planned
action is done and then at step [322], generation of work order is done. Thereafter, at step [326], the process [300] is terminated.
[0118] At step [310D], the performance degradation test is performed. The process
30 [300] comprises checking if the performance degradation alarm is raised during the
42

complaint time. Then based on the response of checking, if the response is no, then
the performance degradation test [310D] is ended at step [324], and thereafter, the
process [300] is terminated at step [326]. If the response is yes, then at step [314D],
tagging the RCA as performance degradation alarm, and then at step [316D],
5 performing an action to clear performance degradation alarms may be done. Then
at step [318], if there is any earlier action planned for this RCA, then at step [320], execution of the planned action is done and then at step [322], generation of work order is done. Thereafter, at step [326], the process [300] is terminated.
10 [0119] At step [310E], the physical parameter discrepancy test is performed. The
process [300] comprises checking if there exists physical parameter discrepancy on cell. Then based on the response of checking, if the response is no, then the physical parameter discrepancy test [310E] is ended at step [324], and thereafter, the process [300] is terminated at step [326]. If the response is yes, then at step [314E], tagging
15 the RCA as physical parameter discrepancy, and then at step [316E], performing an
action to correct physical configurations on site may be done. Then at step [318], if there is any earlier action planned for this RCA, then at step [320], execution of the planned action is done and then at step [322], generation of work order is done. Thereafter, at step [326], the process [300] is terminated.
20
[0120] At step [310F], the service barring test is performed. The process [300] comprises checking if the service is barred on cell. Then based on the response of checking, if the response is no, then the service barring test [310F] is ended at step [324], and thereafter, the process [300] is terminated at step [326]. If the response
25 is yes, then at step [314F], tagging the RCA as regulatory barring, and then at step
[316F], updating with remarks about the barring may be done. Then at step [318], if there is any earlier action planned for this RCA, then at step [320], execution of the planned action is done and then at step [322], generation of work order is done. Thereafter, at step [326], the process [300] is terminated.
30
43

[0121] At step [310G], the interference test is performed. The process [300]
comprises checking if there is any interference on the cell. Then based on the
response of checking, if the response is no, then the interference test [310G] is
ended at step [324], and thereafter, the process [300] is terminated at step [326]. If
5 the response is yes, then at step [314G], tagging the RCA as interference on cell,
and then at step [316G], performing an action to correct interference through
software and hardware optimisation may be done. Then at step [318], if there is any
earlier action planned for this RCA, then at step [320], execution of the planned
action is done and then at step [322], generation of work order is done. Thereafter,
10 at step [326], the process [300] is terminated.
[0122] At step [310H], the physical cell identifier (PCI) conflict test is performed. The process [300] comprises checking if the cell is having a PCI conflict. Then based on the response of checking, if the response is no, then the PCI conflict test
15 [310H] is ended at step [324], and thereafter, the process [300] is terminated at step
[326]. If the response is yes, then at step [314H], tagging the RCA as PCI conflict, and then at step [316H], performing an action to correct PCI planning may be done. Then at step [318], if there is any earlier action planned for this RCA, then at step [320], execution of the planned action is done and then at step [322], generation of
20 work order is done. Thereafter, at step [326], the process [300] is terminated.
[0123] Further, an aspect of the present disclosure relates to a non-transitory computer readable storage medium storing instruction for performing auto root cause analysis and network optimisation for a telecommunication network. The
25 instruction include executable code which, when executed by one or more units of
a system, causes: a receiving unit [102A] of a system [100A] to receive a set of data associated with a service request, wherein the service request is associated with a user equipment; a processing unit [104A] of the system [100A] to correlate the received set of data with a best server plot (BSP); an identification unit [106A] of
30 the system [100A] to identify a serving cell of the user equipment based at least on
44

the received set of data; the processing unit [104A] of the system [100A] to verify
whether the identified serving cell is identical to an optimal serving cell, wherein
the optimal serving cell is determined based on an analysis of the BSP; the
processing unit [104A] of the system [100A] to perform a plurality of network tests
5 on the identified serving cell to identify a root cause based at least on the plurality
of network tests; and the processing unit [104A] of the system [100A] to determine if any pre-defined action item exist for the identified root cause.
[0124] As is evident from the above, the present disclosure provides a technically
10 advanced solution for performing auto root cause analysis and network optimisation
for a telecommunication network. The solution can identify if a customer complaint
tagged cell and a best server plot (BSP) cell is same or not, to further provide the
root cause analysis and network optimization accordingly. Also, the present solution
can overcome the limitations of the existing solutions by automatically identifying
15 various root causes leading to network issues and then by automatically optimizing
the network by automatically performing a predefined action for the identified various root causes.
[0125] While considerable emphasis has been placed herein on the disclosed
20 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
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
25 and non-limiting.
[0126] 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
30 particular functionality of these units for clarity, it is recognized that various
45

configurations and combinations thereof are within the scope of the disclosure. The
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
5 functionality described herein, are considered to be encompassed within the scope
of the present disclosure.
46

We Claim
1. A method for performing auto root cause analysis and network optimization
for a telecommunication network, comprising:
- receiving, by a receiving unit [102A], a set of data associated with a service request, wherein the service request is associated with a user equipment;
- correlating, by a processing unit [104A], the received set of data with a best server plot (BSP);
- identifying, by an identification unit [106A], a serving cell of the user equipment based at least on the set of data;
- verifying, by the processing unit [104A], whether the identified serving cell is identical to an optimal serving cell, wherein the optimal serving cell is determined based on an analysis of the BSP;
- performing, by the processing unit [104A], a plurality of network tests on the identified serving cell to identify a root cause based at least on the plurality of network tests; and
- determining, by the processing unit [104A], if any pre-defined action item exist for the identified root cause.

2. The method as claimed in claim 1, wherein the method comprises generating, by the processing unit [104A], a work order if no pre-defined action item exist.
3. The method as claimed in claim 1, wherein the received set of data comprises information related to at least the service request, a location, and a timestamp when the service request is raised.

4. The method as claimed in claim 1, further comprising checking, by the processing unit [104A], whether there is an outage at the BSP prior to performing the plurality of network tests.
5. The method as claimed in claim 1, wherein the plurality of network tests comprises at least one of an overshooting cell test, a poor coverage test, a congestion test, a serving cell backhaul test, a performance degradation test, a physical parameter discrepancy test, a service barring test, an interference test, a Physical Cell Identifier (PCI) test, or any other network test.
6. The method as claimed in claim 5, wherein the overshooting cell test comprises:

- determining, by the processing unit [104A], whether a geo-location of an occurrence of issue falls outside a cell radius of the serving cell; and
- upon determining that the geo-location of the occurrence of issue falls outside the cell radius of the serving cell, identifying, by the processing unit [104A], an overshooting cell as a root cause analysis (RCA).
7. The method as claimed in claim 5, wherein the congestion test comprises:
- determining, by the processing unit [104A], whether the serving cell was consistently marked as a congested cell for a pre-defined duration; and
- upon determining that the serving cell was consistently marked as the congested cell for the pre-defined duration, identifying, by the processing unit [104A], a congestion as a root cause analysis (RCA).
8. The method as claimed in claim 5, wherein the poor coverage test
comprises:
- determining, by the processing unit [104A], whether a geo-location of
an occurrence of issue falls within a poor coverage area; and

- upon determining that the geo-location of the occurrence of issue falls
within the poor coverage area, identifying, by the processing unit
[104A], a poor coverage as a root cause analysis (RCA).
9. The method as claimed in claim 5, wherein the serving cell backhaul test
comprises:
- determining, by the processing unit [104A], whether the serving cell had a backhaul during a raise time of the service request; and
- upon determining that the serving cell had the backhaul during the raise time of the service request, identifying, by the processing unit [104A], a backhaul congestion as a root cause analysis (RCA).
10. The method as claimed in claim 5, wherein the performance degradation
test comprises:
- determining, by the processing unit [104A], whether at least one performance degradation alarm was raised during a raise time of the service request; and
- upon determining the at least one performance degradation alarm was raised during the raise time of the service request, identifying, by the processing unit [104A], a performance degradation as a root cause analysis (RCA).
11. The method as claimed in claim 5, wherein the physical parameter
discrepancy test comprises:
- determining, by the processing unit [104A], whether there is a presence of a physical parameter discrepancy on the serving cell; and
- upon determining that there is the presence of the physical parameter discrepancy on the serving cell, identifying, by the processing unit [104A], a physical parameter discrepancy as a root cause analysis (RCA).

12. The method as claimed in claim 5, wherein the service barring test
comprises:
- determining, by the processing unit [104A], whether at least one service is barred on the serving cell; and
- upon determining that at least one service is barred on the serving cell, identifying, by the processing unit [104A], a regulatory barring as a root cause analysis (RCA).
13. The method as claimed in claim 5, wherein the interference test comprises:
- determining, by the processing unit [104A], whether there is an interference on the serving cell; and
- upon determining that there is the interference on the serving cell, identifying, by the processing unit [104A], the interference as a root cause analysis (RCA).
14. The method as claimed in claim 5, wherein the PCI test comprises:
- determining, by the processing unit [104A], whether there is at least one PCI conflict on the serving cell; and
- upon determining that there is said at least one PCI conflict on the serving cell, identifying, by the processing unit [104A], a PCI conflict as a root cause analysis (RCA).
15. A system for performing auto root cause analysis and network optimization
for a telecommunication network, comprising:
a receiving unit [102A], configured to receive a set of data associated with a service request, wherein the service request is associated with a user equipment;

a processing unit [104A] connected to at least the receiving unit [102A], the processing unit [104A] is configured to correlate the received set of data with a best server plot (BSP);
an identification unit [106A] connected to at least the processing unit [104A], the identification unit [106A] is configured to identify a serving cell of the user equipment based at least on the received set of data;
the processing unit [104A], configured to:
verify whether the identified serving cell is identical to an
optimal serving cell, wherein the optimal serving cell is
determined based on an analysis of the BSP;
perform a plurality of network tests on the identified
serving cell to identify a root cause based at least on the plurality
of network tests; and
determine if any pre-defined action item exist for the
identified root cause.
16. The system [100A] as claimed in claim 15, wherein the processing unit [104A] is configured to generate a work order if no pre-defined action item exist.
17. The system [100A] as claimed in claim 15, wherein the received set of data comprises information related to at least the service request, a location, and a timestamp when the service request is raised.
18. The system [100A] as claimed in claim 15, wherein the processing unit [104A] is further caused to check whether there is an outage at the BSP prior to performing the plurality network tests.

19. The system [100A] as claimed in claim 15, wherein the plurality of network tests comprises at least one of an overshooting cell test, a poor coverage test, a congestion test, a serving cell backhaul test, a performance degradation test, a physical parameter discrepancy test, a service barring test, an interference test, a Physical Cell Identifier (PCI) test, or any other network test.
20. The system [100A] as claimed in claim 19, wherein to perform the overshooting cell test, the processing unit [104A] is configured to:

- determine whether a geo-location of an occurrence of issue falls outside a cell radius of the serving cell; and
- upon determination that the geo-location of the occurrence of issue falls outside the cell radius of the serving cell, identify an overshooting cell as a root cause analysis (RCA).
21. The system [100A] as claimed in claim 19, wherein to perform the
congestion test, the processing unit [104A] is configured to:
- determine whether the serving cell was consistently marked as a congested cell for a pre-defined duration; and
- upon determination that the serving cell was consistently marked as the congested cell for the pre-defined duration, identify a congestion as a root cause analysis (RCA).
22. The system [100A] as claimed in claim 19, wherein to perform the poor
coverage test, the processing unit [104A] is configured to:
- determine whether a geo-location of an occurrence of issue falls within a poor coverage area; and
- upon determination that the geo-location of the occurrence of issue falls within the poor coverage area, identify a poor coverage as a root cause analysis (RCA).

23. The system [100A] as claimed in claim 19, wherein to perform the serving
cell backhaul test, the processing unit [104A] is configured to:
- determine whether the serving cell had a backhaul during a raise time of the service request; and
- upon determination that the serving cell had the backhaul during the raise time of the service request, identify a backhaul congestion as a root cause analysis (RCA).
24. The system [100A] as claimed in claim 19, wherein to perform the
performance degradation test, the processing unit [104A] is configured to:
- determine whether at least one performance degradation alarm was raised during a raise time of the service request; and
- upon determination that said at least one performance degradation alarm was raised during the raise time of the service request, identify a performance degradation as a root cause analysis (RCA).
25. The system [100A] as claimed in claim 19, wherein to perform the physical
parameter discrepancy test, the processing unit [104A] is configured to:
- determine whether there is presence of a physical parameter discrepancy on the serving cell; and
- upon determination that there is presence of the physical parameter discrepancy on the serving cell, identify a physical parameter discrepancy as a root cause analysis (RCA).
26. The system [100A] as claimed in claim 19, wherein to perform the service
barring test, the processing unit [104A] is configured to:
- determine whether at least one service is barred on the serving cell; and
- upon determination that at least one service is barred on the serving cell, identify a regulatory barring as a root cause analysis (RCA).

27. The system as claimed in claim 19, wherein to perform the interference test,
the processing unit [104A] is configured to:
- determine whether there is an interference on the serving cell; and
- upon determination that there is the interference on the serving cell, identify the interference as a root cause analysis (RCA).
28. The system as claimed in claim 19, wherein to perform the PCI test, the
processing unit [104A] is configured to:
- determine whether there is at least one PCI conflict on the serving cell; and
- upon determination that there is said at least one PCI conflict on the serving cell, identify a PCI conflict as a root cause analysis (RCA).