DESC:FORM 2
THE PATENTS ACT, 1970 (39 OF 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)

SYSTEM AND METHOD FOR PERFORMING DATA RECONCILIATION IN A COMMUNICATION NETWORK

Jio Platforms Limited, an Indian company, having registered address at 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.

TECHNICAL FIELD
[0001] The embodiments of the present disclosure generally relate to a field of wireless communication networks and systems. More particularly, the present disclosure relates to a system and a method for performing data reconciliation in the communication networks.
BACKGROUND OF THE INVENTION
[0002] The subject matter disclosed in the background section should not be assumed or construed to be prior art merely because of its mention in the background section. Similarly, any problem statement mentioned in the background section or its association with the subject matter of the background section should not be assumed or construed to have been previously recognized in the prior art.
[0003] A wireless communication network comprises large number of wireless and wired nodes hosting one or more telecom functions. Some of the nodes are deployed in data centers to provide centralized services, while other nodes are positioned across a geographical area to provide telecom coverage. All of these nodes form a part of the wireless communication network and work together in cohesion for providing seamless telecom services to User Equipment (UEs) in the communication network.
[0004] Each of the nodes may be a different product type and may belong to different vendors. The nodes may generate data related to fault, alarm, configuration, accounting, performance, and security in the communication network. The data generated by the nodes of different vendors may correspond to different technologies and may be of different formats and different protocols. For maintaining an optimal performance of the wireless networks and an optimal quality of service across the communication network, the data must be processed by a telecom operator for accurate analysis of condition of the network.
[0005] However, it is a difficult task to process the enormous data corresponding to the nodes and update the data. As the data is received from multiple vendors of various nodes at same time, it is probable that some update of the data may get missed while processing the data. Traditionally, the data from the multiple vendors is aggregated and compiled in a file or as a table to ensure data integrity. The aggregated data is manually screened for any mismatch in reporting of an item in the data. For example, while aggregating and compiling alarm data corresponding to the nodes, when an alarm is serviced and clear time of the alarm is not updated, the clear time of the alarm may have to be screened and manually moved to a file comprising data of serviced alarms. Similarly, when raise time of an alarm is missed, a file comprising data of non-serviced alarms may become inconsistent as the raise time of alarm is not reflected.
[0006] Another limitation associated with the traditional method is that when the records of the data are moved from a first file to a second file, an actual time of entry of the record data in the first file may not be reflected in updated data in the second file, leading to wrong analysis of network availability. For example, in context of the alarm data, when the records of the alarm data are moved from one file to another, an actual raise time and an actual clear time may not be reflected in the updated alarm data.
[0007] Therefore, to overcome aforementioned challenges and limitations associated with the conventional approaches, there lies a need for an efficient system and a method for performing data reconciliation in the communication network.
SUMMARY
[0008] The following embodiments present a simplified summary in order to provide a basic understanding of some aspects of the disclosed invention. This summary is not an extensive overview, and it is not intended to identify key/critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
[0009] In an embodiment, disclosed herein is a method for performing data reconciliation in a communication network. The method comprises generating, by a task execution module in a first pre-defined data channel of a distributed stream processing platform, a request for performing the data reconciliation on data associated with a plurality of nodes of the communication network for a pre-defined time-period. Further, the method comprises triggering, by the distributed stream processing platform upon processing the request, an Element Management System (EMS) for providing the data for the pre-defined time-period. Furthermore, the method comprises receiving, by the distributed stream processing platform from the EMS in response to the trigger, a stream of data in a second pre-defined data channel of the distributed stream processing platform. Furthermore, the method comprises transferring, by a data management module to a distributed file system, the stream of data received in the second pre-defined data channel of the distributed stream processing platform. Furthermore, the method comprises determining, by a data processing module, one or more mismatched data entries between the stream of data transferred in the distributed file system and existing data associated with the stream of data stored in a database. Thereafter, the method comprises performing, by the data processing module, a data reconciliation operation on the existing data stored in the database by updating the one or more mismatched data entries with respect to the stream of data transferred in the distributed file system.
[0010] In one or more embodiments, the method further comprises generating, by the data management module, a file wrapper of the stream of data stored in the second pre-defined data channel of the distributed stream processing platform. Thereafter, the method comprises transferring, by the data management module, the file wrapper to the distributed file system.
[0011] In one or more embodiments, the stream of data is received in the second pre-defined data channel based on a pre-defined correlation between a logical address of the first pre-defined data channel and a logical address of the second pre-defined data channel.
[0012] In one or more embodiments, the method further comprises initiating, by the task execution module, a first Application Programming Interface (API) call to generate the request. Thereafter, the method comprises initiating, by the data management module, a second API call to transfer the received stream of data in the distributed file system.
[0013] In one or more embodiments, the data comprises one or more of active alarm data, historical alarm data, performance metrics data, fault management data, and operational data.
[0014] In one or more embodiments, the one or more mismatched data entries includes one or more of a type of an alarm, a severity of the alarm, an identifier of a node among the one or more nodes raising the alarm, a raise time of the alarm, and a clear time of the alarm.
[0015] In another embodiment, disclosed herein is a system for performing data reconciliation in a communication network. The system comprises a distributed stream processing platform, a database, a task execution module, a data management module, and a data processing module. The task execution module is configured to generate, in a first pre-defined data channel of the distributed stream processing platform, a request for performing the data reconciliation on data associated with a plurality of nodes of the communication network for a pre-defined time-period. The distributed stream processing platform is configured to trigger, upon processing the request, an Element Management System (EMS) for providing the data for the pre-defined time-period. The distributed stream processing platform is further configured to receive from the EMS in response to the trigger, a stream of data in a second pre-defined data channel of the distributed stream processing platform. The data management module is configured to transfer, to a distributed file system, the stream of data stored in the second pre-defined data channel of the distributed stream processing platform. The data processing module is configured to determine one or more mismatched data entries between the stream of data transferred in the distributed file system and existing data associated with the stream of data stored in the database. The data processing module is further configured to perform a data reconciliation operation on the existing data stored in the database by updating the one or more mismatched data entries with respect to the stream of data received in the distributed file system.
[0016] In one or more embodiment, the data management module is further configured to generate a file wrapper of the stream of data stored in the second pre-defined data channel of the distributed stream processing platform and transfer the file wrapper to the distributed file system.
[0017] In one or more embodiment, the stream of data is received in the second pre-defined data channel based on a pre-defined correlation between a logical address of the first pre-defined data channel and a logical address of the second pre-defined data channel.
[0018] In one or more embodiment, the task execution module is configured to initiate a first Application Programming Interface (API) call to generate the request. Thereafter, the data management module is configured to initiate a second API call to transfer the received stream of data in the distributed file system.
BRIEF DESCRIPTION OF DRAWINGS
[0019] Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. The accompanying drawings constitute a part of the present disclosure and illustrate certain non-limiting embodiments of inventive concepts. Further, components and elements shown in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. For consistency and ease of understanding, similar components and elements are annotated by reference numerals in the exemplary drawings.
[0020] Fig. 1 illustrates an exemplary environment of a system for performing data reconciliation in a communication network, in accordance with an embodiment of the present disclosure.
[0021] Fig. 2 illustrates a block diagram depicting exemplary components of a server, in accordance with an embodiment of the present disclosure.
[0022] Fig. 3 illustrates a flow chart depicting a method for performing the data reconciliation in the communication network, in accordance with an embodiment of the present disclosure.
[0023] Fig. 4 illustrates an exemplary logical flow between entities of the system for performing the data reconciliation in the communication network, in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION OF THE INVENTION
[0024] Inventive concepts of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Further, the one or more embodiments disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more components from one embodiment may be tacitly assumed to be present or used in any other embodiment.
[0025] The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure.
[0026] The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” which may each refer to one or more or all of the same or different embodiments. The term “some” as used herein is defined as “one, or more than one, or all.” Accordingly, the terms “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in an embodiment” refers to one embodiment and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments.”
[0027] The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise stated with limiting language. Furthermore, to the extent that the terms “includes,” “has,” “have,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.”
[0028] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features.
[0029] The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing any of the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details.
[0030] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein the description and in the appended claims, the singular forms "a", "an", and "the" include plural forms unless the context of the invention indicates otherwise.
[0031] The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the scope of the present disclosure and the appended claims. Accordingly, unless otherwise defined, all terms, and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.
[0032] In the disclosure, various embodiments are described using terms used in communication standards (e.g., 3rd Generation Partnership Project (3GPP), Extensible Radio Access Network (xRAN), and Open-Radio Access Network (O-RAN)), but these are merely examples for description. Various embodiments of the disclosure may also be modified and applied to other communication systems.
[0033] In order to facilitate an understanding of the disclosed invention, a number of terms are defined below.
[0034] The term “data reconciliation” may refer to a process of identifying and addressing inaccurate, inconsistent, or incomplete records of data. The process of data reconciliation includes synchronization of records of data by updating existing data records by removal of inconsistencies in the records of the data, deletion of existing records, or by inserting missing records of data.
[0035] A “maintenance cluster” refers to a grouping of service areas managed together by a network administrator or network operations team for maintaining operational efficiency of the communication network.
[0036] Microservices are independently deployable software in which complex applications are composed of small and independent processes. The microservice may be developed as a suite of small services, each running in its own process and communicating with lightweight mechanisms such as Application Programming Interface(s) (API). Each microservice may adhere to a well-defined API.
[0037] An object of the present disclosure is to provide an efficient system and a method for performing data reconciliation in a communication network. Another object of the present disclosure is to provide a system and a method that can ensure data integrity for enormous volume of data generated in the communication network. Yet another object of the present disclosure is to provide a system and a method that can synchronize, in real time, the data received from multiple sources.
[0038] Still another object of the present disclosure is to provide a system and method that can assist in accurate analysis of quality of the communication network and performance associated with various network elements of the communication network by reducing data loss and increasing data sanity.
[0039] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. Fig. 1 through Fig. 4, discussed below, and the one or more embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.
[0040] Fig. 1 illustrates an exemplary architecture of a system 100 for performing data reconciliation in a communication network, in accordance with an embodiment of the present disclosure. The embodiment of the system 100 shown in Fig. 1 is for illustration only. In particular, the system 100 corresponds to a distributed environment of the communication network within which the data is collected, and hereinafter may also be referred to as the “system 100”. Other embodiments of the system 100 may be used without departing from the scope of this disclosure.
[0041] As shown in Fig. 1, the system 100 includes an Element Management System (EMS) cluster 110 (alternatively called the “EMS 110”), a plurality of nodes 120-1 through 120-n (collectively referred to as “nodes 120”), a load balancer 130, server(s) 140, a distributed file system 150, and a Network Management Console (NMC) 160. Each component of the system 100 may be communicatively coupled with other components of the system 100 via a network 170.
[0042] Generally, the EMS cluster 110 may correspond to a centralized service configured to manage one or more of a specific type of network elements of the communication network. The key functions of the EMS cluster 110 may include, but not limited to, handling data related to fault, configuration, accounting, performance, and security in the communication network. Particularly, the EMS cluster 110 manages the nodes 120. The EMS cluster 110 may comprise a plurality of EMSs 110-1 through 110-n of same or different vendors of nodes 110. Each EMS of the plurality of EMSs 110-1 through 110-n is controlled by one or more EMS server(s). The nodes 120 and the EMSs cluster 110 may communicate with each other via a North Bound Interface (NBI) through a combination of wired and wireless communication protocols.
[0043] Typically, the term nodes 120 may include one of at least one Base Station (BS), at least one relay, and at least one Distributed Unit (DU). The BS may be a network infrastructure that provides wireless access to one or more terminals across a plurality of predetermined geographic areas (alternatively referred to as “cells”) based on distance over which a signal may be transmitted. Examples of the BS include, but are not limited to, a macro cell, a femtocell, wireless “Access Point (AP),” “evolved NodeB (eNodeB) (eNB),” “5th Generation (5G) node,” “next generation NodeB (gNB),” “wireless point,” “Transmission/Reception Point (TRP).” The BS may provide wireless access in accordance with wireless communication protocols, e.g., 5G/NR 3GPP New Radio interface/access (NR), LTE, LTE-A, High Speed Packet Access (HSPA), Wi-Fi 802.11a/b/g/n/ac, etc. Aspects of the present disclosure are intended to include, or otherwise cover, any technology (known or later developed) bearing same or similar characteristics as of the above-mentioned BS, without deviating from the scope of the present disclosure. The nodes 120 are deployed in a distributed manner to provide wireless access and coverage in a vast geographical area, may thus form a multi-nodal distributed communication network.
[0044] Each EMS of the EMS cluster 110 is configured to monitor, manage, and store the data generated by the nodes 120 within the system 100. For instance, nodes 120-1, 120-2, 120-3, and 120-n depicted in the Fig. 1 are managed by EMSs 110-1, 110-2, 110-3, and 110-n respectively. The data may correspond to, but not limited to, active alarm data, historical alarm data, performance metrics data, fault management data, and operational data.
[0045] In a non-limiting example, the nodes 120 may generate performance metrics data, fault data, and the alarm data. The alarm data includes alarms raised by the nodes 120 in an event of an outage, faults in the nodes 120, or a change in condition of the communication network, to indicate a change in performance of the nodes 120. The nodes 120 may thus generate service affecting alarms and non-service affecting alarms. The service affecting alarms may be generated when a malfunctioning occurs in the nodes such as software malfunctioning in the node, hardware malfunctioning in the node, backhaul issues, or other issues in the network leading to outage of the node. The non-service affecting alarms may be generated due to minor, major, and critical faults in the nodes. The alarm data may correspond to one or both of active alarms raised at the nodes 120 that are yet to be serviced and historical alarms raised at the nodes 120 that have now been cleared or resolved.
[0046] Cumulatively, the nodes 120 of the communication network may generate huge amount of data for processing with a plurality of data entries corresponding to different categories. For example, in the alarm data, the data entries may include, but not limited to, a severity of the alarm, an affected component of the nodes 120, a geographic location of the nodes 120 at which the alarm is raised, node wise details of the alarm, a raise time of the alarm, a clear time of the alarm, and a corrective action taken to service the alarm, and the like.
[0047] The server(s) 140 may include one or more servers hosted locally or over a cloud network. The server 140 may be a network of computers, a software framework, or a combination thereof, that may provide a generalized approach to create a server implementation. Examples of the server 140 may include, but are not limited to, personal computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machine that can execute a machine-readable code, cloud-based servers, distributed server networks, or a network of computer systems. The server 140 may be realized through various web-based technologies such as, but not limited to, a Java web-framework, a .NET framework, a Personal Home Page (PHP) framework, or any web-application framework.
[0048] The server 140 is configured to receive an input for performing a data reconciliation operation on an incoming stream of the data from the EMS cluster 110. Upon receiving the input, the server 140 is configured to generate a request for the data reconciliation. In one embodiment, the request may be generated based on a trigger from a scheduler at a pre-defined time interval for generating the request with pre-defined parameters, such as a pre-defined time-period for fetching the data from the EMS 110, a pre-defined geographical region of the nodes 120 for fetching the data, and a pre-defined type of data. In another embodiment, the request may be generated based upon receiving the input from the NMC 160. Upon generation of the request, the server 140 is configured to receive an incoming stream of data from the EMS 110, process the request by performing the data reconciliation operation on the data and communicates output of the processing of the data to the NMC 160.
[0049] The NMC 160 may correspond to, but not limited to, a desktop computer, a portable computing device such as a laptop, a tablet computer, a handheld computer, a mobile phone, wearable computer, or any other device suitable to provide front end services, to a network operator or an end-user. The NMC 160 enables the network operations team to monitor and configure the communication network. The NMC 160 may be utilized to identify, configure, monitor, update, and troubleshoot network devices in the communication network. Front-end services of the NMC 160 may include a User Interface (UI) 162 (alternatively referred to as “Graphical User Interface (GUI) 162” or “front-end interface 162” or “display interface 132”) for accessing different functionalities of the system 100. The GUI 162 may include options for providing input for generating the request for the data reconciliation. The GUI 162 may also facilitate the network operator to view the output of the reconciliation operation. In one embodiment, the output may include a success or failure notification to the user corresponding to the processing of the generated request.
[0050] The NMC 160 may further include a communication unit 164 for communicating with the server(s) 140. The communication unit 164 may include a plurality of antennas, a plurality of Radio Frequency (RF) transceivers, a transmit processing circuitry, and a receive processing circuitry. The communication unit 164 enables the NMC 160 to receive from the server 140 the output corresponding to the request.
[0051] In a non-limiting example, the request may be associated with reconciliation of the data generated by the nodes 120 in a specific time-period. The request may include the time-period for receiving the data via the EMSs 110-1 to 110-n of the EMS cluster 110. The request may also include additional details such as a type of the data to be received and geographical region of the one or more nodes 120 for which the data is requested. In a non-limiting example, the request may correspond receiving active alarm data for a previous day from the nodes 120 of an ABC region of an XYZ town.
[0052] Based on the request, an EMS among the EMS cluster 110 corresponding to the nodes 120 is triggered for providing the data for the specific time-period. The data may be provided by the EMS of the EMS cluster 110 as a stream of data. The stream of data may correspond to a continuous and ordered sequence of unbounded chain of items carrying information generated continuously in time that is being received by the EMS cluster 110 from the nodes 120. The load balancer 130 acts as an intermediary between the EMS cluster 110 and the server(s) 140. The load balancer 130 is configured to distribute incoming stream of data received from the EMS cluster 110 to the server(s) 140 for efficient parallel processing. The load balancer 130 sequences and distributes the incoming stream of data from the EMS cluster 110 according to pre-defined rules.
[0053] The incoming stream of data is received and processed by the server 140 for transferring in the distributed file system 150. The distributed file system 150 is configured to provide a scalable and fault-tolerant storage system, for handling the transferred stream of data corresponding to the nodes 120 across distributed clusters of files associated with the server 140. Preferably, the distributed file system 150 may include storage medium for data storage. Examples of the storage medium include, but are not limited to, disk drives, hard-disk arrays, solid state storage devices, Network Attached Storage (NAS) devices, tape libraries or other magnetic, non-tape storage devices, and optical media storage devices. In one embodiment, the DFS 160 may be integrated within the server 110 utilizing computing resources of the server 110 for storing and managing large volume of the source data.
[0054] The server 140 then determines mismatched data entries between the stream of data transferred in the distributed file system 150 and a database storing existing data associated with the incoming stream of data. In an embodiment, the data in the database is updated based on the determination of the mismatched data entries. This enables efficient management of the data in real time and assists in improving accuracy of analysis of quality of the communication network.
[0055] In one or more embodiments, the server(s) 140 wirelessly accesses the EMS cluster 110 via the network 170. The network 170 may include wired connections, wireless connections such as a proprietary Internet Protocol (IP) network, Internet, or in accordance with other wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMAX), Wi-Fi 802.11a/b/g/n/ac, or a combination of wired and wireless connections.
[0056] Although Fig. 1 illustrates one example of the communication network, various changes may be made to Fig. 1. For example, the communication network may include any number of EMS in the EMS cluster, nodes, and servers in any suitable arrangement. Further, in another example, the server 140 may include any number of components in addition to the components shown in Fig. 1. Further, various components in FIG. 1 may be combined, further subdivided, or omitted and additional components may be added according to particular needs. Other aspects of the disclosure are described in further detail below. It is understood that alternate embodiments of the system 100 are possible wherein one or more of the components of the system 100 may communicate with each other through the network 170.
[0057] Fig. 2 illustrates a block diagram depicting exemplary components of the server 140, in accordance with an embodiment of the present disclosure. The embodiment of the server 140 as shown in Fig. 2 is for illustration only. However, the server 140 may come in a wide variety of configurations, and Fig. 2 does not limit the scope of the present disclosure to any particular implementation of the server 140.
[0058] As shown in Fig. 2, the server(s) 140 comprises one or more parsers 202 (hereinafter also referred to as the “parser 202”), a distributed stream processing platform 204, one or more database(s) 206 (hereinafter interchangeably referred to as “database 206”), an Input-Output (I/O) interface 208, a memory 210 , one or more processor(s) 212 (hereinafter also referred to as the “processor 212”), a scheduler 214, a communication interface 216, microservices 218, and a plurality of module(s) 220 (hereinafter interchangeably referred to as “module(s) 220”). Components of the server 140 are coupled to each other via a communication bus 222.
[0059] The I/O interface 208 may include suitable logic, circuitry, interfaces, and/or codes that may be configured to receive input(s) and present (or display) output(s) on the server 140. For example, the I/O interface 208 may have an input interface and an output interface. The input interface may be configured to enable the user to provide input(s) to trigger (or configure) the server 140 to execute the one or more operations for performing the data reconciliation. Examples of the input interface may include, but are not limited to, a touch interface, a mouse, a keyboard, and the output interface includes a digital display, an analog display, or a touch screen display. Aspects of the present disclosure are intended to include or otherwise cover any type of the input interface including known, related art, and/or later developed technologies without deviating from the scope of the present disclosure.
[0060] The processor 212 may include processing circuitry, logic, interface(s), and/or code(s), and may be configured to communicate with other components of the server 140 (i.e., the parser 202, the distributed stream processing platform 204, the database 206, the memory 210, the scheduler 214, the communication interface 216, the microservices 218, and the module(s) 220) via the communication bus 222. Examples of the communication bus 222 may include, but are not limited to, a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), and a Front Side Bus (FSB). Aspects of the present disclosure are intended to include or otherwise cover any type of coupling means present or related to later developed technologies, that may be configured to connect the processor 212 to the other subsystems of the server 140, as the communication bus 222, without deviating from the scope of the present disclosure.
[0061] The processor 212 may include processing circuitry configured to execute instructions 210-1 (hereinafter interchangeably referred to as “a set of instructions 210-1”) stored in the memory 210 to cause the server 140 to perform various processes (e.g. performing data reconciliation on the data associated with the nodes 120). For example, the processor 212 may be configured to execute programs and processes to execute instruction(s) or code(s) stored in the memory 210 pertaining to performing data reconciliation. The processor 212 is further configured to move data into or out of the memory 210 as required by an execution process of the server 140.
[0062] Examples of the processor 212 may include, but are not limited to, a Central Processing Unit (CPU), an Application Processor (AP), a dedicated processor, a graphics-only processing unit such as a Graphics Processing Unit (GPU), a programmable logic device, or any combination thereof.
[0063] The memory 210 is configured to store the set of instructions 210-1 required by the processor 212 for controlling overall operations of the server 140 for receiving data, processing, and/or performing the data reconciliation. A part of the memory 210 may include a RAM, a cache memory, or a ROM. The memory 210 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory 210 may, in some examples, be implemented using a non-transitory storage medium. The "non-transitory" storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory 210 is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 210 can be an internal storage unit or it can be an external storage unit of the server 140, cloud storage, or any other type of external storage. In some embodiments, when the memory 210 is external to the server 140, the memory 210 may be removably attached to the server 140. Aspects of the present disclosure are intended to include or otherwise cover any data storage medium as ‘the memory 210’, without deviating from the scope of the present disclosure.
[0064] The scheduler 214 may be connected to the processor 212 for periodically triggering the processor 212 for generating the request for data reconciliation in the distributed stream processing platform 204 at the pre-defined time interval, with the pre-defined parameters. The scheduler 214 is configured to schedule execution of analytical tasks and job workflows allocated by the processor 212, and thus ensures timely processing and reconciliation of data at the pre-defined time interval, such as at an hourly basis, daily basis, or weekly basis. Based on the trigger from the scheduler 214, the processor 212 generates the request for data reconciliation in the distributed stream processing platform 204.
[0065] Further, the server 140 may host a plurality of microservices 218 (alternatively referred to as the “microservices 218”). The server 140 may utilize a plurality of computing resources where the plurality of microservices 218 may be deployed, and a plurality of storage devices such as a database may be provided in the computing resource for each microservice. It must be understood that the microservices platform may also be hosted outside the server 140 in a similar manner utilizing the resources of a computing device separate from the server 140 itself. The module(s) 220 may make a call to the microservices 218 for synchronization of flow of the steam of data between various components of the server(s) 140.
[0066] The database 206 is configured to store data associated with the stream of data. The data may correspond to previous versions of the stream of data existing in the database 206. The data or the set of data may correspond to, but not limited to, active alarm data set, historical alarm data set, performance metrics data set, fault management data set, and operational data set associated with the stream of data. In an aspect, the data or the set of data in the database 206 may be updated periodically, however, the data or the set of data may not reflect actual changes corresponding to the data of the nodes 120 in real-time or the changes in the data corresponding to the nodes 120 on an hourly basis, daily basis or weekly basis. Thus, the data in the database 206 may have to be reconciled with the stream of data obtained from the EMS cluster 110.
[0067] For example, a first database 206-1 may be a repository that stores historical alarm data from the nodes 120 generated over time. The historical alarm data comprises details corresponding to the historical alarms raised at the nodes 120 for the one or more vendors within a geographical location. The historical alarm data may be stored in a meaningful message format in the first database 270-1. The historical alarm data may comprise, but not limited to, details related to the historical alarms raised at the nodes 120 within the geographical location, a node identifier of each of the nodes 120, an impact of each of the historical alarms at each of the nodes 120, a severity level of each of the historical alarms, a raise time of each of the historical alarms, a clear time of each of the historical alarms, and an alarm identifier of each of the historical alarms.
[0068] A second database 206-2 may be configured to store and manage active alarm data. The second database 206 is configured to maintain a comprehensive record of active/alive alarm data. The active alarm data may comprise, but not limited to, details related to the active alarms raised at the nodes 120 within the geographical location, a node identifier of each of the nodes 120, an impact of each of the active alarms at each of the nodes 120, a severity level of each of the active alarms, a raise time of each of the active alarms, and an alarm identifier of each of the active alarms.
[0069] The databases 206 may be implemented as one or more of centralized database, Relational Database Management System (RDBMS), non-relational database management system, hierarchical database management system, network database management system, an in-memory database including a distributed in-memory data storage, or a distributed database.
[0070] In an embodiment, the module(s) 220 may be implemented as a combination of hardware and software programming (for example, programmable instructions) to implement one or more functionalities of the server 140. In non-limiting examples, described herein, such combinations of hardware and software programming may be implemented in several different ways, without deviating from the scope of the present disclosure. The module(s) 220 may include suitable logic, circuitry, interfaces, and/or codes. For example, the programming for the module(s) 220 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the module(s) 220 may comprise a processing resource (for example, one or more processors), to execute such instructions. In an embodiment, the module(s) 220 may be combined to a single module or each module of the module(s) 220 may be further subdivided into different modules.
[0071] In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the module(s) 220. In such examples, the server 140 may also comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the server 140 and the processing resource. In other examples, the module(s) 220 may be implemented using an electronic circuitry.
[0072] In one or more embodiments, the module(s) 220 may include one or more modules such as a task execution module 220-2, a data management module 220-4, and a data processing module 220-6 (alternatively referred to as Change Data Capture (CDC) module 220-6). Each of the module(s) 220 is communicatively coupled with each other.
[0073] In one embodiment, based on the trigger from the scheduler 214 or an input from the NMC 160, the processor 212, using the task execution module 220-2, generates the request for performing the data reconciliation on data associated with the nodes 120 for the pre-defined time-period. The processor 212, using the task execution module 220-2 may initiate a first API call to the microservices 218 to generate the request. The request is generated in the distributed stream processing platform 204. The request is processed using the distributed stream processing platform 204 and upon processing the request, the processor 212 is configured to trigger, via the distributed stream processing platform 204, one of the EMS from the EMS cluster 110 for providing the data for the pre-defined time-period.
[0074] In response to the generated request, the processor 212 is configured to receive a response message. In particular, the processor 212 is configured to receive a stream of data in the message from the triggered EMS among the EMS cluster 110 via the parser 202. The parser 202 is configured to receive the data in a raw form from the EMS cluster 110 and extract information from the data for further processing by the server(s) 140. The parser 202 may decode a format and/or protocol of the data and transform raw data into structured records of data. For example, when an alarm data is received, the parser 202 extracts relevant information such as the alarm type, the severity, the affected component of the one or more nodes, raise time, and clear time of the alarm.
[0075] The processor 212 is further configured to utilize the distributed stream processing platform 204 for receiving the stream of data from the EMS cluster 110 via the parser 202. The distributed stream processing platform 204 may correspond to a cluster of distributed stream processing servers forming a part of the server 140 or may be a part of an external environment in communication with the server 140. The distributed stream processing platform 204 is configured to ingest the data in real-time, process the ingested data, and distribute the ingested alarm data as streams to the module(s) 220 of the processor 212. The distributed stream processing platform 204 is further configured to handle and manage incoming stream of the data and thus ensure low-latency data processing and seamless integration with downstream components.
[0076] The distributed stream processing platform 204 may process the stream of data in a log or an event driven manner. The distributed stream processing platform 204 may comprise a plurality of data channels. Each data channel of the plurality of data channels may be a logical category or a distinct queue for receiving continuous tuples or stream of data in a message corresponding to an event and from where the stream of data in the message can be retrieved. Each data channel may have a distinct logical address. The data channel may further be subdivided into the plurality of segments.
[0077] Each subdivision of the data channel denoted by a specific segment may have a unique identifier. The plurality of segments in the plurality of data channels are handled parallelly by the distributed stream processing platform 204. Each record in the stream of data may be stored in data segments of a pre-defined data channel in a round robin fashion. For an example, a first record in the stream of data may be stored in a first data segment among the plurality of data segments of a pre-defined data channel and a second record in the stream of data may be stored in a second data segment among the plurality of data segments of the pre-defined data channel. Similarly, a third record in the stream of data may be stored in the first data segment of the pre-defined data channel and a fourth record in the stream of data may be stored in the second data segment of the pre-defined data channel.
[0078] The task execution module 220-2 is configured to generate the request in a first pre-defined data channel of the plurality of data channels of the distributed stream processing platform 204. In response to the generated request, the stream of data is received from the triggered EMS in a second pre-defined data channel of the plurality of data channels of the distributed stream processing platform 204. In an embodiment, when the request for data reconciliation of alarm data is generated in the first pre-defined data channel, a stream of alarm data streamed by the EMS 110 is stored in the plurality of data segments of the second pre-defined data channel of the distributed stream processing platform 204, forming an alarm dump.
[0079] In an embodiment, the stream of data is received in the second pre-defined data channel based on a pre-defined correlation between a logical address of the first pre-defined data channel and a logical address of the second pre-defined data channel. The correlation of the first data channel and the second data channel may be stored in a relational manner such as in form of a correlation table in a third database 206-3. The distributed stream processing platform 204 may utilize the correlation table to receive the stream of data at the second pre-defined channel.
[0080] The logical address of the second pre-defined data channel may be indicated by an offset value of a logical address corresponding to the first pre-defined data channel. The correlation may be defined based on a user preference, for example based on the maintenance circle. As the nodes 120 covering various geographical locations in the communication network are segregated as part of different maintenance circles, two data channels among the plurality of data channels may be correlated to receive the stream of data from a specified maintenance circle.
[0081] The processor 212, using the data management module 220-4, is configured to initiate a second API call to the microservices 218 to transfer the stream of data received in the second pre-defined channel to the distributed file system 150. The processor 212, using the data processing module 220-6, compares the stream of data transferred in the distributed file system 150 and the existing data in the database 206 to identify inconsistencies or discrepancies between them. The data processing module 220-6 determines one or more mismatched data entries between the stream of data transferred in the distributed file system 150 and the existing data associated with the stream of data stored in the database 206.
[0082] Further, the processor 212, using the data processing module 220-6, performs the data reconciliation operation on the existing data stored in the database 206 by updating the one or more mismatched data entries with respect to the stream of data transferred in the distributed file system 150.
[0083] In an embodiment, the data processing module 220-6 may correspond to an analytics engine i.e., an information processing unit for controlling overall operation of the server 140 associated with embodiments of the present disclosure and for performing data reconciliation. The analytics engine may be configured to handle a set of tasks or computations executed by the processor 212 in a distributed computing environment. The data processing module 220-6 may be configured to identify, capture, and track changes in the existing data stored in the database 206 with respect to the stream of data in the distributed file system 150. Further, the data processing module 220-6 may be configured to resolve the inconsistencies based on the determined one or more mismatched data entries. Furthermore, the data processing module 220-6 may be configured to perform one or more of insertion of missing records, updating the existing records, and/or deleting the existing records of the data in the database 206 based on the stream of data transferred in the distributed file system 150.
[0084] For instance, when the request for performing data reconciliation with respect to historical alarm data of the nodes 120 is generated, a corresponding raise time and clear time of the alarms are received in the distributed stream processing platform 204 as active alarms gets cleared or resolved and turn into historical alarms. The processor 212, using the data processing module 220-6 may compare the historical alarm data and determine that either the record of the historical alarm is missing, or the clear time is missed to be updated in the first database 206-1.
[0085] The data processing module 220-6 flags the inconsistencies in the historical alarm data in the first database 206-1 and determine one or more mismatched data entries between the stream of historical alarm data received in the second pre-defined topic with the historical alarm data in the first database 206-1. The processor 212 performs the data reconciliation operation to input new records in the first database 206-1 that was missed to be updated with actual clear time of the history alarm. In an embodiment, the data processing module 220-6 may also flag the inconsistencies in the active alarm data in the second database 206-2 and perform the data reconciliation operation to delete records of the cleared alarms in the second database 206-2.
[0086] The communication interface 216 may manage communications with the EMS cluster 110, the network 170, and the distributed file system 150. For example, the communication interface 216 may manage the reception of the data from the EMS cluster 110. The communication interface 216 may include an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 216 is configured for communicating with external devices via one or more networks. Further, the communication interface 216 may also provide a communication pathway for one or more components of the server 140. Examples of such components include, but are not limited to, the processing unit(s)/module(s) 220 and the databases 206.
[0087] Although Fig. 2 illustrates one example of server 140, various changes may be made to Fig. 2. For example, the server 140 may include any number of components in addition to the components shown in Fig. 2. Further, various components in Fig. 2 may be combined, further subdivided, or omitted and additional components may be added according to particular needs.
[0088] Fig. 3 illustrates a flow chart depicting a method 300 for performing the data reconciliation in the communication network, in accordance with an embodiment of the present disclosure. Although method 300 shows example blocks of steps 302 to 312, in some embodiments, the method 300 may include additional steps, fewer steps or steps in different order than those depicted in Fig. 3. In other embodiments, the steps 302-312 may be combined or may be performed in parallel.
[0089] At step 302, the processor 212 generates the request for performing the data reconciliation on data associated with the nodes 120 of the communication network. The request may include the pre-defined time-period specified by the user for data reconciliation. The request may also include geographical location of the nodes 120 corresponding to which the data is to be reconciled. The request is generated in the first pre-defined data channel of a distributed stream processing platform 204.
[0090] Upon processing the generated request, at step 304, the processor 212, using the distributed stream processing platform 204, triggers an EMS among the EMS cluster 110 based on the request for providing the data for the pre-defined time-period.
[0091] At step 306, when the EMS is triggered, a stream of data is provided by the EMS to the distributed stream processing platform 204 as a response to the trigger. Thereafter, the processor 212 determines the second pre-defined data channel of the distributed stream processing platform 204 based on the correlation of the first pre-defined data channel and the second pre-defined data channel. The stream of data is received in the second pre-defined data channel of the distributed stream processing platform 204.
[0092] At step 308, the processor 212 transfers the stream of data received in the second pre-defined data channel of the distributed stream processing platform 204 to the distributed file system 150. The stream of data may be transferred in a file format compatible with the distributed file system 150.
[0093] At step 310, the processor 212 determines the one or more mismatched data entries between the stream of data transferred in the distributed file system 150 and the existing data associated with the stream of data stored in the database 206. The one or more mismatched data entries may correspond to removed data entries in the stream of data, new data entries in the stream of data, and updated data entries in the stream of data.
[0094] At step 312, the processor 212 performs the data reconciliation operation on the existing data stored in the database 206 by updating the one or more mismatched data entries with respect to the stream of data transferred in the distributed file system 150. Consequently, the data in the database 206 becomes consistent with the data in the distributed file system 150.
[0095] Fig. 4 illustrates an exemplary logical flow 400 between entities of the system 100 for performing the data reconciliation in the communication network, in accordance with an embodiment of the present disclosure. The logical flow 400 comprises a series of operations performed by entities indicated by blocks 402 through 412.
[0096] At block 402, the task execution module 220-2 initiates the first API call to the microservices 218 to generate a request for performing data reconciliation corresponding to data from the nodes 120. The microservices 218 may act as a producer of the request and publishes the request corresponding to an EMS of the EMS cluster 110 in the first pre-defined data channel. The request may include a type of the data to be received from the nodes 120, the pre-defined defined time-period for fetching the data from the nodes 120, and the pre-defined geographical region of the nodes 120 for fetching the data.
[0097] At block 404, the distributed stream processing platform 204 consumes the request placed in the first pre-defined data channel. The distributed stream processing platform 204 processes the request. In response to the processed request, an EMS of the EMS cluster 110 is triggered for providing the data for the pre-defined time-period.
[0098] At block 406, in response to the trigger, the EMS of the EMS cluster 110 may act as a producer of the data and publish the stream of data requested by the processor 212 in the distributed stream processing platform 204. The processor 212 may determine the correlation between the first pre-defined data channel and the second pre-defined data channel, and the based on the correlation, the stream of data may be received in the second pre-defined data channel of the distributed stream processing platform 204. The stream of data may be stored in the plurality of segments of the second pre-defined data channel and may be consumed by the microservices 218 for further processing.
[0099] The data management module 220-4 initiates the second API call to the microservices 218 to consume or fetch the stream of data from the plurality of segments of the second pre-defined data channel. The microservices 218 is further configured to transfer the received stream of data in the distributed file system 150. In one embodiment, the first API call and the second API call may correspond to a Representational State Transfer (REST) based API call request.
[0100] At block 408, the data management module 220-4, using the microservice 218, generates a file wrapper of the stream of data stored in the second pre-defined data channel of the distributed stream processing platform 204. The file wrapper may correspond to a Comma Separated Value (CSV) file or a file of another format accessible by the distributed file system 150. The file wrapper is transferred to the distributed file system 150 for storage of the stream of data in the distributed file system 150.
[0101] At block 410, the distributed file system 150 provides the file wrapper to the data processing module 220-6. The data processing module 220-6 is configured to read the file and compare the entries of data in the file wrapper and existing data associated with the stream of data stored in the database 206. Upon comparison, the data processing module 220-6 is configured to determine one or more mismatches between the entries of data in the database 206 and the data stored in the distributed file system 150.
[0102] At block 412, the data processing module 220-6 performs the data reconciliation operation by modifying the data in the database 206 based on the one or more mismatched entries. The data processing module 220-6 either inserts, updates, or deletes the one or more mismatched entries in the database 206 based on the data in distributed file system 150.
[0103] Now, referring to the technical abilities and advantageous effect of the present disclosure, operational advantages that may be provided by one or more embodiments is that there is no data loss during the data reconciliation as the data is received in the plurality of data channels and further stored in plurality of segments within the data channel. The present disclosure offers flexibility to network operators to undertake identification of any inconsistencies or discrepancies of data in the system while maintaining data sanity and ensuring that no entries of data go un-updated in the database.
[0104] Another potential advantage of the one or more embodiments disclosed herein include enabling the users such as network administrator or operators to fetch the data in real-time and synchronize the data within the system. The system and the method in the present disclosure may thus be utilized for maintaining data integrity within the communication network.
[0105] A further potential advantage offered by the present disclosure is that the system and the method may be utilized for troubleshooting of erroneous data entries and maintaining accurate data within the communication network. The reconciled data may be utilized by the network operators for further processing by an Operation Support System (OSS) to efficiently undertake fault management and other operational activities within the communication network.
[0106] Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the technology, and/or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and/or steps) in the flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions embodied in computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including without limitation a general-purpose computer or special purpose computer, or other programmable processing apparatus to perform a group of operations comprising the operations or blocks described in connection with the disclosed methods.
[0107] Further, these computer program instructions, such as embodied in computer-readable program code, may also be stored in one or more computer-readable memory or memory devices (for example, the memory 210) that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s).
[0108] It will further be appreciated that the term “computer program instructions” as used herein refer to one or more instructions that can be executed by the one or more processors (for example, the processor 212) to perform one or more functions as described herein. The instructions may also be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely.
[0109] Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present invention. The above-described embodiments are therefore to be construed in all aspects as illustrative and not restrictive.
[0110] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Any combination of the above features and functionalities may be used in accordance with one or more embodiments.
[0111] In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary from embodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limited in scope.
LIST OF REFERENCE NUMERALS
[0112] The following list is provided for convenience and in support of the drawing figures and as part of the text of the specification, which describe innovations by reference to multiple items. Items not listed here may nonetheless be part of a given embodiment. For better legibility of the text, a given reference number is recited near some, but not all, recitations of the referenced item in the text. The same reference number may be used with reference to different examples or different instances of a given item. The list of reference numerals is:
100 - System for performing data reconciliation in a communication network
110 - Element Management System (EMS) cluster
110-1 to 110-n - EMSs
120 - Nodes
130 – Load Balancer
140 - Server
150 – Distributed File System (DFS)
160 – Network Management Console (NMC)
162 – User Interface/GUI/front-end interface
164 – Communication Unit
170 – Network
202 – Parser(s)
204 – Distributed Stream Processing Platform
206 - Database
208 - Input-Output (I/O) interface
210 - Memory
210-1 - Instructions
212 - Processor(s)
214 – Scheduler
216 – Communication Interface
218 – Microservices
220 - Module(s)
220-2 - Task execution module
220-4 – Data Management module
220-6 – Data Processing module
222 – Communication Bus
300 - Method for performing data reconciliation in the communication network
302-312 - Operation steps of the method 300
400 - Logical flow between entities of the system for performing the data reconciliation in the communication network
402-412 – Operational blocks of the logical flow 400

,CLAIMS:WE CLAIM:
1. A method (300) for performing data reconciliation in a communication network, the method (300) comprising:
generating, by a task execution module (220-2) in a first pre-defined data channel of a distributed stream processing platform (204), a request for performing the data reconciliation on data associated with a plurality of nodes (120) of the communication network for a pre-defined time-period;
triggering, by the distributed stream processing platform (204) upon processing the request, an Element Management System (EMS) (110) for providing the data for the pre-defined time-period;
receiving, by the distributed stream processing platform (204) from the EMS (110) in response to the trigger, a stream of data in a second pre-defined data channel of the distributed stream processing platform (204);
transferring, by a data management module (220-4) to a distributed file system (150), the stream of data received in the second pre-defined data channel of the distributed stream processing platform (204);
determining, by a data processing module (220-6), one or more mismatched data entries between the stream of data transferred in the distributed file system (150) and existing data associated with the stream of data stored in a database (206); and
performing, by the data processing module (220-6), a data reconciliation operation on the existing data stored in the database (206) by updating the one or more mismatched data entries with respect to the stream of data transferred in the distributed file system (150).
2. The method (300) as claimed in claim 1, further comprising:
generating, by the data management module (220-4), a file wrapper of the stream of data stored in the second pre-defined data channel of the distributed stream processing platform (204); and
transferring, by the data management module (220-2), the file wrapper to the distributed file system (150).
3. The method (300) as claimed in claim 1, wherein the stream of data is received in the second pre-defined data channel based on a pre-defined correlation between a logical address of the first pre-defined data channel and a logical address of the second pre-defined data channel.
4. The method (300) as claimed in claim 1, further comprising:
initiating, by the task execution module (220-2), a first Application Programming Interface (API) call to generate the request; and
initiating, by the data management module (220-4), a second API call to transfer the received stream of data in the distributed file system (150).
5. The method (300) as claimed in claim 1, wherein the data comprises one or more of active alarm data, historical alarm data, performance metrics data, fault management data, and operational data.
6. The method (300) as claimed in claim 5, wherein the one or more mismatched data entries includes one or more of a type of an alarm, a severity of the alarm, an identifier of a node among the one or more nodes raising the alarm, a raise time of the alarm, and a clear time of the alarm.
7. A system (100) for performing data reconciliation in a communication network, the system (100) comprising:
a distributed stream processing platform (204);
a database (206);
a task execution module (220-4) configured to generate, in a first pre-defined data channel of the distributed stream processing platform (204), a request for performing the data reconciliation on data associated with a plurality of nodes (120) of the communication network for a pre-defined time-period,
wherein the distributed stream processing platform (204) is configured to:
trigger, upon processing the request, an Element Management System (EMS) (110) for providing the data for the pre-defined time-period;
receive from the EMS (110) in response to the trigger, a stream of data in a second pre-defined data channel of the distributed stream processing platform (204);
a data management module (220-4) configured to transfer, to a distributed file system (150), the stream of data stored in the second pre-defined data channel of the distributed stream processing platform (204); and
a data processing module (220-6) configured to:
determine one or more mismatched data entries between the stream of data transferred in the distributed file system (150) and existing data associated with the stream of data stored in the database (206); and
perform a data reconciliation operation on the existing data stored in the database (206) by updating the one or more mismatched data entries with respect to the stream of data received in the distributed file system (150).
8. The system (100) as claimed in claim 7, wherein the data management module (220-4) is further configured to:
generate a file wrapper of the stream of data stored in the second pre-defined data channel of the distributed stream processing platform (204); and
transfer the file wrapper to the distributed file system (150).
9. The system (100) as claimed in claim 7, wherein the stream of data is received in the second pre-defined data channel based on a pre-defined correlation between a logical address of the first pre-defined data channel and a logical address of the second pre-defined data channel.
10. The system (100) as claimed in claim 7, wherein
the task execution module (220-2) is configured to initiate a first Application Programming Interface (API) call to generate the request, and
the data management module (220-4) is configured to initiate a second API call to transfer the received stream of data in the distributed file system (150).
11. The system (100) as claimed in claim 7, wherein the alarm data comprises one or more of active alarm data, historical alarm data, performance metrics data, fault management data, and operational data.
12. The system (100) as claimed in claim 11, wherein the one or more mismatched data entries includes one or more of a type of an alarm, a severity of the alarm, an identifier of a node among the one or more nodes raising the alarm, a raise time of the alarm, and a clear time of the alarm.