WO2025203085A1 - System and method for managing configuration updates in a network - Google Patents

Abstract

A system (108) and a method (500) for managing one or more configuration updates in a network are disclosed. The system (108) employs a retrieving module (212) to retrieve real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval. A processing module (216) stores the real-time configuration change parameters in a transient repository. The processing module (216) then processes the real-time configuration change parameters stored in the transient repository to create a single update event. Thereafter, an updating module (218) updates a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository. The system (108) maintains a single repository (e.g., the central repository) for the entire network, enabling efficient access and update of the configuration changes without the need to log into each EMS individually.

Description

SYSTEM AND METHOD FOR MANAGING CONFIGURATION UPDATES IN A NETWORK

RESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.

TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of telecommunication. More particularly, the present disclosure relates to a system and a method for managing configuration updates in a network.

DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] The expression ‘Radio node’ used hereinafter in the specification refers to a type of network node responsible for the transmission and reception of wireless signals within a radio access network (RAN). It typically includes base stations, antennas, and other equipment necessary to establish and maintain wireless communication with user devices.

[0005] The term ‘Element Management System (EMS)’ used hereinafter in the specification refers to a management system responsible for overseeing and controlling the network elements (such as the radio nodes) within a telecommunications network. The EMS provides functionalities such as configuration management, fault monitoring, and performance analysis for the network elements under its control.

[0006] The term ‘Central Repository’ used hereinafter in the specification refers to a centralized data storage system that collects and updates one or more configuration parameter changes in a single update. The repository ensures data consistency and availability for monitoring, updating, and validating network operations.

[0007] The term ‘Transient repository’ used hereinafter in the specification refers to a temporary data storage database used to hold real-time data, such as configuration changes or event updates, before processing.

[0008] The expression ‘Distributed Event Streaming Platform’ used hereinafter in the specification refers to a software platform that handles the real-time collection, processing, and distribution of data streams from various network elements. The platform facilitates the transient storage and integration of network configuration updates from multiple EMSs.

[0009] The term ‘Gateway server’ used hereinafter in the specification refers to a hardware and software component that connects different network segments, providing a bridge between internal network systems (such as application servers) and external systems (such as user-facing web portals). The gateway server also routes data and handles incoming and outgoing traffic between network elements. [0010] The term ‘Application server’ used hereinafter in the specification refers to a server responsible for executing and managing application -level services that support network management tasks. The application server handles requests from users or systems, processes them, and interacts with other components, such as databases and service modules.

[0011] The term ‘Services’ used hereinafter in the specification refers to a software component that executes specific network management functions such as monitoring, validation, and integration testing. It interacts with other system components to ensure that network operations are functioning as expected.

[0012] The term ‘Reporting server’ used hereinafter in the specification refers to a server responsible for generating, managing, and delivering reports on network performance, configuration changes, and operational metrics. The reporting server interacts with the central repository and other components to extract and compile data for analysis.

[0013] The term ‘Distributed Computing System Cluster’ used hereinafter in the specification refers to a collection of interconnected computing nodes that work together to perform large-scale data processing tasks, such as analyzing and updating network configurations. The system cluster is responsible for running distributed computing jobs, including real-time streaming and batch processing of data.

[0014] The expression ‘Database Management System (DBMS)’ used hereinafter in the specification refers to software that interacts with the database to handle data storage, retrieval, updates, and management. It ensures the integrity, security, and consistency of data stored in the database.

[0015] The term ‘Load Balancer’ used hereinafter in the specification refers to a network component that distributes incoming traffic across multiple servers to ensure optimal resource utilization and improve the overall system’s reliability and performance while avoiding overloading of any single server.

[0016] The term ‘Distributed File System (DFS)’ used hereinafter in the specification refers to a file system that allows data to be stored and accessed across multiple physical locations. In the context of this system, DFS stores large volumes of network configuration data and enables efficient data retrieval for analysis and reporting purposes.

[0017] The term ‘Web server’ used hereinafter in the specification refers to a server that handles Hypertext Transfer Protocol (HTTP) requests from users or client systems, providing an interface for network administrators to access and interact with the network management system via a web portal.

[0018] The term ‘Firewall’ used hereinafter in the specification refers to a security system designed to protect the network by monitoring and controlling incoming and outgoing traffic based on predefined security rules. The firewalls (e.g., Firewall 1 and Firewall 2) ensure that only authorized traffic can interact with critical network components such as the web server, application servers, and gateway server.

BACKGROUND

[0019] 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.

[0020] In a telecommunication network, each Element Management System (EMS) is responsible for storing configuration parameters of a plurality of network elements, such as radio nodes hosted across each of the EMS. These configuration parameters must be updated in real-time to ensure the network functions correctly. As the scale of the network grows, the challenge of accessing and managing configuration data across the plurality of radio nodes hosted on multiple EMS becomes increasingly complex. Users must log in to each EMS separately to obtain configuration update information for the radio nodes it hosts. This process is not only cumbersome but also inefficient, particularly when dealing with a large volume of data.

[0021] Another challenge is the sheer size of the configuration data and the volume of daily updates. While only a small subset of parameters typically changes each day, users are still required to access each of the EMS, retrieve the entire configuration file, and parse it to identify changes. This process of retrieving, parsing, and updating configurations that have not changed is resource-intensive and timeconsuming.

[0022] There is, therefore, a need in the art to provide a system and method that stores and updates all the configuration change information in a single repository, eliminating the need to log into multiple EMS for configuration data retrieval.

SUMMARY

[0023] In an exemplary embodiment, a method for managing one or more configuration updates in a network is disclosed. The method includes retrieving, by a retrieving module, one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval. The method further includes storing, by a processing module, the retrieved one or more real-time configuration change parameters in a transient repository. The method further includes processing, by the processing module, the one or more realtime configuration change parameters stored in the transient repository to create a single update event. The method further includes updating, by an updating module, a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository.

[0024] In an embodiment, the created single update event considers a last incremental change among one or more incremental changes that occur in at least one real-time configuration change parameter over the predefined time interval as a final value for the corresponding real-time configuration change parameter, and wherein the created single update event captures each real-time configuration change that occurs in the at least one network node of the at least one EMS over the predefined time interval.

[0025] In an embodiment, to process the one or more real-time configuration change parameters, the method includes categorizing, by a categorizing module, each of the one or more real-time configuration change parameters stored in the transient repository into a predefined category using a categorization technique; and storing, by the categorizing module (214), each of the categorized one or more real-time configuration change parameters into a Distributed File System (DFS).

[0026] In an embodiment, the one or more real-time configuration change parameters comprises one or more of operational settings, firmware updates, software version updates, node-specific settings and others.

[0027] In an embodiment, the method of retrieving the one or more real-time configuration change parameters from the at least one of the plurality of EMSs includes sending, by the retrieving module, an access request to access each of the plurality of EMSs; determining, by the retrieving module, whether the access request sent to each of the plurality of EMS is accepted; and upon determining that the access request is accepted for the at least one EMS, retrieving, by the retrieving module, the one or more real-time configuration change parameters from the at least one EMS at the predefined time interval. [0028] In an embodiment, the method includes creating, by the processing module, a record for each of the one or more incremental changes in the transient repository that occur in the at least one real-time configuration change parameter of the one or more real-time configuration change parameters over the predefined time interval; and storing, by the processing module, one or more records created for the at least one real-time configuration change parameter over the predefined time interval as a parameter history for the corresponding at least one real-time configuration change parameter in the transient repository.

[0029] In an embodiment, the method further includes sending the one or more created records from the transient repository to a user to analyze each of the one or more incremental changes that occur in the at least one real-time configuration change parameter over the predefined time interval.

[0030] In an embodiment, to process the one or more real-time configuration change parameters, the method includes collecting, by the processing module, the one or more real-time configuration change parameters from the DFS over the predefined time interval; and parsing, by the processing module, the one or more real-time collected configuration change parameters to create the single update event.

[0031] In another exemplary embodiment, a system for managing one or more configuration updates in a network is disclosed. The system includes a retrieving module configured to retrieve one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval. The system further includes a processing module configured to store the retrieved one or more real-time configuration change parameters in a transient repository. The processing module is further configured to process the one or more real-time configuration change parameters stored in the transient repository to create a single update event. The system further includes an updating module configured to update a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository.

[0032] In yet another exemplary embodiment, the present disclosure discloses a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for managing one or more configuration updates in a network. The method includes retrieving, by a retrieving module, one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval. The method further includes storing, by a processing module, the retrieved one or more real-time configuration change parameters in a transient repository. The method further includes processing, by the processing module, the one or more real-time configuration change parameters stored in the transient repository to create a single update event. The method further includes updating, by an updating module, a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository.

[0033] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

OBJECTIVES OF THE PRESENT DISCLOSURE

[0034] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows.

[0035] An objective of the present disclosure is to provide a system and a method for managing one or more incremental configuration updates in a network. [0036] Another objective of the present disclosure is to provide a system and a method that maintains a single repository (e.g., a central repository) for the entire network consisting of multiple radio nodes that belong to a plurality of Element Management Systems (EMSs), enabling efficient access and update of the configuration changes without the need to log into each EMS individually.

[0037] Another objective of the present disclosure is to reduce the volume of database update operations by aggregating real-time configuration changes over a predefined time interval, thus minimizing redundant updates and optimizing database performance.

[0038] Another objective of the present disclosure is to create a live parameter history (e.g., a record of real-time configuration changes) for each network node (e.g., radio nodes), enabling future validation and troubleshooting by maintaining an incremental record of all the configuration changes.

[0039] Another objective of the present disclosure is to debug issues and problems occurring in the network.

[0040] Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

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

[0042] FIG. 1 illustrates an exemplary network architecture for implementing a system for managing one or more configuration updates in a network, in accordance with an embodiment of the present disclosure.

[0043] FIG. 2 illustrates an exemplary block diagram of the system for managing the one or more configuration updates in the network, in accordance with an embodiment of the present disclosure.

[0044] FIG. 3 illustrates an exemplary system architecture for managing the one or more configuration updates in the network, in accordance with an embodiment of the present disclosure.

[0045] FIG. 4 illustrates an exemplary flow diagram of a method for managing the one or more configuration updates in the network, in accordance with an embodiment of the present disclosure.

[0046] FIG. 5 illustrates another exemplary flow diagram of the method for managing the one or more configuration updates in the network, in accordance with an embodiment of the present disclosure.

[0047] FIG. 6 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.

[0048] The foregoing shall be more apparent from the following more detailed description of the disclosure.

LIST OF REFERENCE NUMERALS 100 - Network Architecture

102-1, 102-2... 102-N - Plurality of Users

104-1, 104-2... 104-N - Plurality of User Equipments

106 - Network 108 - System

200 - Block Diagram

202 - Processor(s)

204 - Memory

206 - Input/Output (I/O) Interface(s) 208 - Processing Engine

210 - Database

212 - Retrieving Module

214 - Categorizing Module

216 - Processing Module 218 - Updating Module

300 - System Architecture

302 - Load Balancer

304 - Web Server

306 - Application Servers 308 - Gateway Server

310 - Reporting Servers

312 - Distributed File System (DFS)

314 - Services

316 - Database Management System

318 - Distributed Computing System Cluster

320 - Distributed Event Streaming Platform

400, 500 - Flow Diagram

600 - Computer System

610 - External Storage Device

620 - Bus

630 - Main Memory

640 - Read-Only Memory

650 - Mass Storage Device

660 - Communication Ports

670 - Processor

DETAILED DESCRIPTION

[0049] 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. 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 embodiments 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.

[0050] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0051] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0052] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as 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. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0053] 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 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 like the term “comprising” as an open transition word without precluding any additional or other elements.

[0054] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0055] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any 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 invention as defined herein.

[0056] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers 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 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-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. [0057] Further, the user device may also comprise a “processor” or “processing engine” includes processing engine, wherein processor refers to any logic circuitry for 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, 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.

[0058] 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 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.

[0059] Radio Access Technology (RAT) refers to the technology used by mobile 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 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. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.

[0060] In a telecommunication network, multiple Element Management Systems (EMSs) store configuration data of the radio nodes, which the EMSs manage. When the network is large, each EMS independently maintains configuration data for the number of radio nodes. Such a decentralized storage approach makes the process of accessing configuration data across multiple EMSs complex and time-consuming, particularly when real-time updates are required. To mitigate such complexity, there is a need to store and update all the configuration change related data in a single repository, thereby avoiding the process of logging into each EMS to get configuration data of the radio nodes hosted in the corresponding EMS. An aspect to be observed is that the size of configuration data and the volume of updates are significant.

[0061] Currently, the configurations of the radio nodes are stored on a daily basis. A user is required to go to the corresponding EMS to obtain the configuration files of the nodes. The configuration files are then shared with a system which parses those files. After parsing, the parsed information is stored in a database.

[0062] Only a small subset of parameters change every day. However, the system has to parse the complete data. So, it becomes challenging to parse and update only the configuration files whose data is changed. For example, if there are 100 parameters of the node in the EMS, 90 parameters may remain the same. The rest of the 10 parameters may have some changes. However, the system has to analyze all the parameters i.e., 100 parameters to determine changes. Accordingly, there is a need for systems and methods to parse and update only that configuration file of the EMS whose data is changed. [0063] The present disclosure aims to overcome the above-mentioned and other existing problems in the present field of technology by providing a system and a method for managing incremental configuration updates in a network. Instead of bringing the entire configuration every day, each radio node associated with a plurality of Element Management Systems (EMSs) are queried for any incremental configuration changes. The data corresponding to the incremental configuration changes is collated and stored in an incremental manner such that the user does not have to bring that entire configuration, parse it, and store it every day. So, the data stored in the database is more real-time and not on a daily basis. Further, instead of transferring a huge volume of data from the database of the EMS to a single repository, the present disclosure carry only incremental configuration change (e.g., 10%) rather than the entire database (e.g., 90%), which is not changed.

[0064] Therefore, for managing incremental configuration updates in the network. Firstly, the configuration change data is collected by querying each radio node of the plurality of EMS. Then, the collected configuration change data is stored in a transient storage (e.g., a distributed event streaming platform). The collected data is parsed and combined for a single update event over the predefined time interval (e.g., 15 minutes of time duration). The configuration change data is updated in the repository. Thus, reducing the number of updates in the repository by a huge margin. All the configuration changes (e.g., site parameter changes) are dynamically managed to be imported into the system based on user inputs. The site parameter changes are stored category-wise in partitions in the storage (e.g., distributed event streaming platform). The category wise storage of the site parameter changes allows easy retrieval and processing of the events. Further, live parameter history (e.g., a record of configuration changes) is created against each site parameter change for future validation in every fixed time interval (e.g., after every 15 minutes). In this way, a high inflow of configuration change data is managed and updated in a single repository. [0065] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0066] FIG. 1 illustrates an exemplary network architecture (100) for implementing a system (108) for managing one or more configuration updates in a network (106), in accordance with an embodiment of the present disclosure.

[0067] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2... 104-N) associated with one or more users (102-1, 102-2... 102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2... 102-N) may collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2... 104-N) may be collectively referred to as the UE (104). Although only three UE (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.

[0068] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE (104) may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not limited to, intelligent, multisensing, network-connected devices, which may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected. [0069] Additionally, in some embodiments, the UE (104) may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but is not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.

[0070] Referring to FIG. 1, the UE (104) may communicate with the system (108) through the network (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one of a 5G network, 6G network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and/or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

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

[0072] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104). The network (106) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request.

[0073] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100). [0074] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for managing the one or more configuration updates in the network (106), in accordance with an embodiment of the present disclosure. The network (106) may correspond to the telecommunication network. Examples of the network include the 4G network, the 5G network, the 6G network, and the like.

[0075] In an embodiment, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.

[0076] In an embodiment, the system (108) may include an Input/Output (RO) interface(s) (206). The I/O interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices (RO), storage devices, and the like. The I/O interface(s) (206) may facilitate communication through the system (108). The I/O interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a processing engine (208) and a database (210).

[0077] In an embodiment, the processing engine (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine (208). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non- transitory machine -readable storage medium and the hardware for the processing engine (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine- readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine (208). In such examples, the system may 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 system and the processing resource. In other examples, the processing engine (208) may be implemented by electronic circuitry.

[0078] In an embodiment, the database (210) includes data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (202) or the processing engine (208). In an embodiment, the database (210) may be indicative of including, but not limited to, a relational database, a distributed database, a cloud-based database, or the like.

[0079] In an embodiment, the processing engine (208) may include a plurality of modules. The plurality of modules of the processing engine (208) may include, but is not limited to, a retrieving module (212), a categorizing module (214), a processing module (216), and an updating module (218).

[0080] To manage the one or more configuration updates, the retrieving module (212) may initially retrieve one or more real-time configuration change parameters from at least one of a plurality of EMSs at a predefined time interval. In an embodiment, the one or more real-time configuration change parameters may include, but is not limited to, one or more operational settings, firmware updates, software version updates, or node-specific settings. The operational settings include configurations related to the day-to-day functioning of network nodes, such as radio frequency (RF) parameters, power settings, handover thresholds, and quality-of- service (QoS) priorities. Any change in these parameters can have an immediate impact on network performance, requiring constant monitoring and management to ensure optimal service quality. The firmware updates refer to changes or patches applied to the embedded software that controls the hardware of network nodes. Such updates can address hardware compatibility issues, fix bugs, or introduce new features. Managing firmware updates is crucial to maintaining the stability and security of the network. The software version updates includes updates to the software running on network elements, such as base station controllers, gateways, or core network functions. Software version updates typically introduce new features, enhance performance, or patch vulnerabilities. Tracking these updates ensures that all elements are running compatible and up-to-date software versions. The node-specific settings are unique to individual network nodes, such as site-specific configurations, IP addresses, and routing tables. Node-specific changes often involve reconfiguring how a particular node interacts with the rest of the network and thus require careful handling to avoid disruptions.

[0081] In an embodiment, to retrieve the one or more real-time configuration change parameters from the at least one of the plurality of EMSs, the retrieving module (212) may send an access request to access each of the plurality of EMSs. In an embodiment, the access request is one of an authorized request and an unauthorized request. The retrieving module (212) may further determine whether the access request sent to each of the plurality of EMSs is accepted. Upon determining that the access request is accepted (e.g., authorized request) for the at least one EMS, the retrieving module (212) may retrieve the one or more real-time configuration change parameters from the at least one EMS at the predefined time interval. [0082] Upon determining that the access request is not accepted (e.g., unauthorized request), the at least one EMS may reject the access request due to missing or invalid authentication credentials. In such cases, the retrieving module (212) may attempt reauthentication, log the failure, or escalate the issue to a network administrator. In some embodiments, if the at least one EMS is temporarily unreachable due to network congestion, maintenance activities, or system failures, the retrieving module (212) may retry the request after a predefined wait period or attempt to retrieve data from an alternative EMS if redundancy is available. If the at least one EMS does not respond within a predefined timeframe, the retrieving module (212) may trigger an alert, log the timeout event, and schedule a retry attempt at the next predefined interval.

[0083] The processing module (216) may store the retrieved one or more realtime configuration change parameters in a transient repository. In a more elaborate way, the transient repository is a temporary storage location configured to hold the realtime configuration data for short durations until it is processed further. The transient repository serves as a buffer that ensures that real-time data can be quickly accessed by other components, such as the categorizing module (214), for further processing on the one or more real-time configuration change parameters. Examples of the transient repository include, but is not limited to, an in-memory database, a local ephemeral storage, or a message queue system. The in-memory database stores data entirely in a Random Access Memory (RAM), ensuring ultra-fast read/write operations. Further, the local ephemeral storage is a light weight storage mechanism using temporary files for quick access before deletion. Additionally, the message queue system temporarily holds and distributes real-time data streams, ensuring that updates are queued for processing.

[0084] Once, the processing module (216) stores the retrieved one or more realtime configuration change parameters in the transient repository, the categorizing module (214) may be configured to categorize each of the one or more real-time configuration change parameters stored in the transient repository into a predefined category using a categorization technique. The predefined category may include, but is not limited to, an EMS category, a Service Access Point (SAP) category, and a Management Object (MO) category.

[0085] The EMS category groups configuration change parameters based on the specific EMS from which it originated. Since each EMS is responsible for managing a distinct set of network elements, categorizing parameters by EMS helps in identifying the source of the change. This classification is particularly useful in multivendor environments where different EMS manage different parts of the network, enabling more precise tracking and troubleshooting. For example, in a multi-vendor 5G network, an operator may have one EMS managing Radio Access Network (RAN) elements, another EMS handling Core Network (CN) elements, and yet another responsible for transport networks. If a configuration change such as adjusting the power levels of a radio node is detected, it is categorized under the RAN EMS. Similarly, if a user session timeout setting is modified, it is categorized under the Core Network EMS

[0086] The SAP category organizes configuration parameters based on the Service Access Point, representing an interface between different network functions or services. Grouping changes by SAP helps in understanding how configuration updates impact various services and is vital for managing service continuity and avoiding disruptions in end-to-end services, such as voice or data sessions. For example, consider a 5G Service-Based Architecture (SBA) where the Access and Mobility Function (AMF) communicates with the Session Management Function (SMF) through a SAP interface (N11). If a new policy for session continuity is introduced at this interface, the change would be categorized under the SAP category. Similarly, if a modification in the N4 interface between SMF and the User Plane Function (UPF) occurs (e.g., changing data packet forwarding rules), it is categorized under this category.

[0087] The MO are specific data structures that represent individual network elements or configurations. Categorizing parameters by MO allows for a granular view of changes at the object level, such as adjustments to specific attributes within a network element. The MO enables fine-grained control and auditing of configuration changes, ensuring that modifications are correctly applied and do not interfere with other dependent objects. For example, within an EMS managing 5G RAN elements, each gNodeB (next-generation base station) is represented as a MO. If a parameter such as Antenna Beamforming Weight is adjusted for a specific gNodeB, it is categorized under the MO category. Similarly, in 5G Core, if a modification is made to the User Equipment (UE) registration timeout value stored in the Unified Data Management (UDM), this change is also categorized under the MO category.

[0088] In an embodiment, to categorize the one or more real-time configuration change parameters, the categorizing module (214) may analyze each of the one or more real-time configuration change parameters. Further, the categorizing module (214) may group each of the one or more real-time configuration change parameters into the predefined category based on the analysis. The analysis may include mapping of each configuration change parameter to the predefined category (e.g., EMS, SAP, MO) based on information, such as a node ID, IP address, service type, or operational context. For example, if a parameter pertains to a specific radio node, the categorizing module (214) may map it to the relevant EMS managing that radio node.

[0089] Upon categorizing each of the one or more real-time configuration change parameters into the predefined category, the categorizing module (214) further stores each of the categorized one or more real-time configuration change parameters into a Distributed File System (DFS). The DFS is a system that allows files to be stored across multiple servers or nodes, ensuring redundancy, scalability, and fast access to data. In an embodiment, the DFS acts as an intermediate storage layer, providing a reliable mechanism to maintain a short-term history (e.g., 15 minutes history) of each of the categorized one or more parameter changes. The categorization ensures that each configuration change parameter is grouped appropriately before it is consolidated into the single update event.

[0090] Further, the processing module (216) may be configured to process the one or more real-time configuration change parameters to create a single update event. In an embodiment, the single update event refers to a consolidated representation of all the configuration changes that occur within a specific network node over a predefined time interval. The single update event includes all the relevant details of the individual configuration changes into a unified format, making it easier to handle, analyze, and propagate through the network management system. For example, consider a 5G gNodeB (base station) where a configuration parameter, such as maximum transmit power (Tx Power), undergoes multiple changes within a predefined five-minute interval. At the beginning of the interval, the Tx Power is initially set to 20 dBm. Within the first two minutes, it is updated to 22 dBm, followed by another change to 25 dBm at the second minute mark. A final adjustment occurs at the fourth minute, reducing the Tx Power to 23 dBm. Instead of logging each of these changes separately in the central repository, the processing module (216) consolidates them into a single update event, ensuring that only the final value (Tx Power updated from 20 dBm to 23 dBm) is recorded. This approach optimizes database efficiency by reducing unnecessary write operations while still preserving the complete change history within the transient repository for auditing and troubleshooting purposes.

[0091] In an embodiment, to process the one or more real-time configuration change parameters, the processing module (216) may collect the one or more real-time configuration change parameters from the DFS over the predefined time interval. In other words, to create the single update event, the processing module (216) may retrieve the one or more real-time configuration change parameters that are categorized in the predefined category from the DFS. Further, the processing module (216) may parse the one or more real-time collected configuration change parameters to create the single update event. Parsing of the one or more real-time collected configuration change parameters refers to the process of interpreting or analyzing configuration change parameters, such as operational settings of EMS, firmware updates, software version updates, or node-specific settings that have been updated in real time. For example, consider a scenario where an EMS sends multiple configuration change updates for a core network node managing subscriber sessions. One of the updates involves a firmware version upgrade for a specific Mobility Management Entity (MME). The retrieved configuration change parameter may be in raw format, such as: “Node: MME-1 | Config Change: Firmware Update | Old Version: 3.1.4 | New Version: 3.2.0 | Timestamp: 2025-03-22 14:05:00”. During parsing, the processing module (216) extracts key details, including the affected network node (MME-1), the type of change (Firmware Update), previous and new firmware versions (3.1.4 to 3.2.0), and the exact timestamp of change occurrence. Once parsed, this structured data enables efficient integration into the single update event mechanism, ensuring that redundant updates are minimized while maintaining an accurate history of changes.

[0092] Upon processing, once the single update event is created, the updating module (218) may be configured to update a central repository with the created single update event to reflect the real-time configuration updates in at least one network node of the at least one EMS within the central repository. The primary purpose of creating a single update event is to simplify the management of configuration changes, reduce redundancy, and enhance the overall efficiency of the network update process. In other words, by consolidating multiple changes into a single update event, the system (108) reduces the number of individual updates that need to be processed and stored. This improves processing efficiency and reduces the load on the network. Further, instead of sending multiple separate updates for each configuration change, the single update event is transmitted, reducing signaling overhead and improving the speed of updates across the network. Further, network operators can view a single, unified update event to understand all changes made to a particular node, making it easier to track changes and troubleshoot issues. Further, the single update event ensures that all changes occurring within a time interval are applied together, preventing partial updates and maintaining consistency across the network. Because the single update event contains a consolidated view of all changes, it is easier to perform impact analysis and understand the overall effect of the updates on network operations.

[0093] In an embodiment, the processing module (216) may create a record for each of the one or more incremental changes that occur in the at least one real-time configuration change parameter of the one or more real-time configuration change parameters over the predefined time interval. The processing module (216) may store one or more records created for the at least one real-time configuration change parameter over the predefined time interval as a parameter history for the corresponding at least one real-time configuration change parameter in the transient repository. In an embodiment, the created single update event considers a last incremental change among one or more incremental changes that occur in at least one real-time configuration change parameter over the predefined time interval as a final value for the corresponding real-time configuration change parameter, and the created single update event captures each real-time configuration change that occurs in the at least one network node of the at least one EMS over the predefined time interval.

[0094] For example, consider a scenario where a parameter changes from X to Y during the first interval and then from Y to Z in the subsequent interval. When creating records, the processing module (216) logs both changes (X to Y and Y to Z) in the transient repository to maintain a comprehensive history of updates.

[0095] However, while updating the central repository (e.g., the database 210), the processing module (216) optimizes these changes by only applying the final state (X to Z), rather than performing two separate updates. This approach minimizes the number of database updates, ensuring that only the cumulative effect of the parameter changes is reflected in the central repository. Consequently, the central repository is updated efficiently with the end state (X to Z) of the parameter. At the same time, the complete sequence of intermediate changes (X to Y and Y to Z) is preserved in the transient repository for historical tracking and reference purposes. This may effectively reduce the overall update load on the database while still maintaining a detailed record of incremental configuration changes in the transient repository.

[0096] In an embodiment, the processing module (216) may further send the one or more created records from the transient repository to a user to analyze each of the one or more incremental changes that occur in the at least one real-time configuration change parameter over the predefined time interval. For example, if a user (e.g., user 102) wants to analyze how the configuration parameter (Z) changed over time, the user (102) may retrieve its historical records from the transient repository. Suppose the initial version of the configuration parameter is “vl.O” (X). During the first interval, it is upgraded to “vl.5” (Y). In the subsequent interval, the parameter is further upgraded to “v2.0” (Z). The user (102) may view this incremental change history and determine when and why each update occurred, facilitating troubleshooting, performance analysis, or compliance verification.

[0097] In an embodiment, the transient repository is a temporary storage that is used to store records of one or more incremental changes that occur in the at least one real-time configuration change parameter of the one or more real-time configuration change parameters over the predefined time interval. In an embodiment, the DFS is an intermediate storage that is used to store categorized records of one or more real-time configuration change parameters after these have been processed by the categorizing module (214). The DFS maintains a short-term history of these categorized changes, ensuring efficient retrieval, redundancy, and scalability before the final updates are consolidated in the central repository. Additionally, the central repository is a long-term storage system that maintains the final state of one or more real-time configuration change parameters after processing. It stores the consolidated updates, ensuring that only the most recent and relevant configuration data is retained while minimizing redundant entries. The central repository enables efficient access, auditing, and historical analysis of configuration changes.

[0098] Although FIG. 2 shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).

[0099] FIG. 3 illustrates an exemplary system architecture (300) for managing the one or more configuration updates in the network (106), in accordance with an embodiment of the present disclosure.

[00100] The system architecture (300) may include the UE (104), a load balancer (302), a web server (304), one or more application servers (306), one or more gateway servers (308), one or more reporting servers (310), a Distributed File System (DFS) (312), one or more services (314), the database (210), a database management system (316), a distributed computing system cluster (318), and a distributed event streaming platform (320).

[00101] The UE (104) may be configured to receive at least one request to access the plurality of EMSs. For example, the UE (104) may access the plurality of EMSs through a web portal or a website. In an example, the UE (104) may include a computer, a mobile device, or any other data processing device suitable to access the plurality of EMSs. The request may be to access the plurality of EMSs to retrieve information related to a plurality of live site parameter changes (also referred to as one or more realtime configuration change parameters) corresponding to each network node (e.g., radio nodes) associated with the plurality of EMSs.

[00102] The load balancer (302) may distribute the incoming request from the UE (104) across the web server (304), one or more application servers (306), and other backend components. The load balancer (302) ensures that no single server is overloaded with traffic, optimizing performance and maintaining system availability. The load balancer (302) handles the incoming traffic from the UE (104) and directs it to the appropriate web server (304) for further processing. Further, the load balancer (302) provides high availability and reliability by managing failover and scaling up or down server resources as required. In one aspect, the load balancer (304) may be configured to use POST as a request method supported by a Hypertext Transfer Protocol (HTTP) used by the World Wide Web. The POST request method requests a web server to accept the data enclosed in the body of the request message, most likely for storing it. The POST request method is often used when uploading a file or when submitting a completed web form. In another aspect, when a specific server of the one or more servers gets heavily loaded, the load balancer (304) may direct the incoming request to other servers. In another aspect, the one or more servers may be configured in such a way that when a specific server fails, the other servers may take over to enable high availability (HA).

[00103] The web server (304) is software and hardware that uses HTTP and other protocols to respond to the request made over the World Wide Web. The main task of the web server is to display website content through storing, processing and delivering webpages to users. Besides HTTP, the web server (304) also support SMTP (Simple Mail Transfer Protocol) and FTP (File Transfer Protocol), used for email, file transfer and storage. The web server hardware is connected to the internet and allows data to be exchanged with other connected devices, while web server software controls how a user accesses hosted files. In an aspect, the web server (304) acts as an intermediary between the UE (104) and the one or more application servers (306). The web server (304) may receive the incoming HTTP request from the UE (104) and forward it to the appropriate application server for processing. The web server (304) is responsible for handling user authentication, session management, and serving the user interface through which network administrators can manage configuration updates.

[00104] The one or more application servers (306) may host the core logic for managing and processing configuration updates. The one or more application servers (306) execute processes that retrieve live parameter changes or configuration changes data from the EMS, categorize the data (such as by EMS, Service Access Point (SAP), and Management Object (MO)), and perform other essential tasks such as aggregation, validation, and generation of single update events. The one or more application servers (306) may run one or more microservices that are responsible for specific functionalities, such as parameter change retrieval, processing, and categorization.

[00105] The one or more gateway servers (308) provide connectivity between the system architecture (300) and external systems or networks. The one or more gateway servers (308) may act as the interface between the network (106), which includes the plurality of EMSs, and the internal components of the system architecture (300). The one or more gateway servers (308) handle secure communication with the EMS, ensuring that configuration change parameter data can be retrieved reliably and efficiently. In some embodiments, the one or more gateway servers (308) may use secure protocols such as Secure Shell (SSH), Transport Layer Security (TLS), or Virtual Private Network (VPN) connections to access the EMS securely.

[00106] The one or more reporting servers (310) may be responsible for generating various reports based on the processed configuration data. These reports may include historical site parameter changes (e.g., a record of the one or more realtime configuration change parameters), real-time configuration updates, error reports, and notifications regarding system failures. The reporting servers may also handle user- defined queries, allowing administrators to access specific information related to EMS configurations and changes in the real time.

[00107] The DFS (312) stores large volumes of site parameter change history in a distributed manner. The DFS (312) allows the system to handle the significant amount of data generated from retrieving the real-time configuration change parameters from the EMS. The DFS (312) provides fault tolerance and scalability, ensuring that the data remains accessible even if individual storage nodes fail. The DFS is also used for storing time -bound data (e.g., 15-minute history files), which can be processed later to generate aggregated reports.

[00108] The services (314) refer to various backend services or microservices responsible for data collection, processing, categorization, and storage tasks. These services may work asynchronously to handle the different functions of the system. For example, a dedicated service may handle the categorization of real-time configuration change parameters, while another service may process the data and generate update events. Each service is modular and can be scaled independently based on demand.

[00109] The database (210) is a central repository for storing processed and categorized configuration data. The database (210) holds the aggregated configuration change events, categorized based on the EMS, SAP, and MO. The database (210) is the main source for retrieving historical configuration data, supporting queries from reporting servers and enabling future configuration validation. The database (210) is structured to optimize both read and write operations for real-time and historical data.

[00110] The database management system (DBMS) (316) manages the database (210) and ensures data consistency, integrity, and availability. The DBMS (316) performs transaction management, query optimization, and backup and recovery tasks. The DBMS (316) also supports efficiently executing queries related to configuration changes and history retrieval. The DBMS (316) may include mechanisms for indexing the data to enable quick retrieval based on parameters like time, EMS, SAP, and MO.

[00111] The distributed computing system cluster (318) handles the computational workload for processing vast amounts of configuration change data retrieved from the EMS. The cluster consists of multiple interconnected servers working parallel to process and analyze data. This cluster allows for scalable and efficient handling of large data volumes, ensuring that the system can process millions of configuration change parameters in real time without performance degradation. The cluster supports distributed computation models, such as MapReduce or Spark, to handle batch processing and real-time stream processing.

[00112] The distributed event streaming platform (320) enables real-time data streaming and event processing within the system. It facilitates the continuous ingestion and processing of live configuration change data from the EMS and other components in the system architecture (300). The distributed event streaming platform (320) ensures that configuration change events are processed as they occur, and enables the system to react promptly to updates, notifications, and alerts. The event streaming platform supports data pipelines that allow data to flow between the different services, components, and repositories seamlessly.

[00113] Therefore, the system architecture (300) is designed to manage the collection, processing, categorization, and storage of configuration updates in a distributed and scalable manner. The architecture ensures that the network configuration is always up to date, reflecting real-time changes occurring across different EMS and that administrators can access detailed reports, configuration history, and status from the single database.

[00114] FIG. 4 illustrates an exemplary flow diagram of a method (400) for managing the one or more configuration updates in the network, in accordance with an embodiment of the present disclosure. In an embodiment, the method (400) may be implemented using various modules (e.g., the retrieving module (212), the categorizing module (214), the processing module (216), and the updating module (218)) of the system (108).

[00115] At step 402, a login operation is performed sequentially on all EMSs within a network, such as the network 106 using the UE (104). In an aspect, the UE (104) may act as a communication channel for initiating communication with the various EMS to retrieve the real-time site parameter changes (also referred to as realtime configuration changes). The login process may include authenticating the UE (104) with each EMS and establishing a secure session to enable data retrieval. Given the plurality of EMSs deployed in the network, this step ensures that the UE (104) may connect with each EMS, one by one, in a systematic manner, thereby avoiding simultaneous login attempts that could potentially overload the EMS servers.

[00116] At step 404, if the login process to each of the plurality of EMSs is successful, the retrieving module (212) collects changes in all the site parameters at a predefined time interval (e.g., every 15 minutes) from all the connected EMSs. The site parameters include configuration data, operational status, and performance metrics of various network nodes (e.g., radio nodes) managed by each EMS. The predefined time interval ensures that the processing module (216) can monitor and capture all incremental changes in near real-time without creating unnecessary load on the EMS servers. This periodic collection of site parameter changes allows for the effective tracking of network modifications, which is critical for maintaining up-to-date configuration records and ensuring smooth network operation.

[00117] At step 406, the processing module (216) generates a failure notification if the login attempt to any EMS fails due to authentication issues, network unavailability, or other technical errors. In an aspect, the processing module (216) may send a mail notification to a concerned authority, indicating the specific EMS and the reason for the failure. This alert allows administrators to take corrective action and ensure that the data collection process is not disrupted. After sending the notification, the UE (104) retries the login process on all the EMS to re-establish connectivity and resume the data collection process. This retry mechanism ensures that temporary network glitches or intermittent issues do not disrupt the continuous monitoring and collection of site parameter changes, thereby enhancing the reliability of the configuration management process.

[00118] At step 408, the processing module (216) stores all the collected site parameter changes in a database (DB). This database is a temporary repository (e.g., transient repository) for configuration data fetched from the different EMS. The purpose of storing the collected parameter change data in the database is to ensure that the parameter updates are maintained and made available for subsequent stages of the method (400). The database is structured to handle high volumes of incoming data efficiently, categorizing the parameter changes based on EMS source, site location, and parameter type to facilitate easy retrieval and processing.

[00119] At step 410, the processing module (216) reads the stored site parameter changes from the database and processed by one or more distinct processes (e.g., Process- 1, Process-2, and Process-3). In an embodiment, the number of processes may vary depending on the number of categories defined for site parameter changes. Each process is designed to categorize the collected site parameter changes into one or more categories using the categorizing module (214) based on analyzing the characteristics of each site parameter change. The one or more categories include, but are not limited to, EMS-related category, Service Access Point (SAP)-related category, and Management Object (MO)-related category. In other words, the categorization may be performed by analyzing each site parameter change and grouping it according to its type and associated network function. For example, Process- 1 may analyze specific fields or tags within the site parameters to identify whether a parameter is related to EMS operations, such as network management settings or high-level administrative configurations. Process-2, on the other hand, may handle SAP-related changes, which are associated with service-level configurations such as access policies and traffic management. Additionally, Process-3 may be responsible for processing MO-related changes, which define the operational states and specific settings of individual network nodes. The categorization allows for efficient management and retrieval of site configuration changes, ensuring that each type of change can be processed according to its specific requirements.

[00120] At step 412, the processing module (216) stores all site parameter changes processed by the individual processes in a Distributed File System (DFS) for a predefined time interval (e.g., 15 minutes). The DFS acts as an intermediate storage layer, providing a reliable mechanism to maintain a short-term history of all processed site parameter changes. The DFS stores each parameter changes in distinct partitions based on their respective categories (e.g., EMS, SAP, and MO). For example, EMS- related category changes are stored in a separate partition from SAP and MO changes. The category-wise partitioning within the DFS helps to organize the data efficiently and smooth future processing tasks, enabling quick retrieval and targeted analysis based on the specific category. By maintaining separate partitions for each category, the processing module (216) may handle large volumes of data without performance degradation, ensuring that critical updates are preserved for subsequent aggregation and analysis.

[00121] At step 414, the processing module (216) may further process the 15- minute stored site history data in the DFS to generate aggregated (e.g., parsed) records. In an aspect, the aggregation (e.g., parsing) process is performed for each category (e.g., EMS, SAP, and MO) separately, consolidating multiple updates into a single record for each parameter type. For example, multiple changes to the EMS-related category within the last 15 minutes are aggregated into a single record that captures all modifications. Similarly, SAP and MO changes are aggregated separately, reducing the total number of records and minimizing the number of database update operations. The aggregation optimizes storage efficiency and reduces the load on the main database by ensuring that only consolidated records are updated. The aggregation is performed using predefined rules defining how changes within each category should be combined, providing a simplified view of parameter updates across the network.

[00122] At step 416, the updating module (218) updates the latest processed data and stores in the elastic database (e.g., a centralized database). The elastic database is the main repository for storing processed and validated site parameter changes, providing a scalable and high-performance storage solution that may handle large volumes of network configuration data. The data stored in the elastic database is indexed based on category, site location, and parameter type, enabling real-time querying and efficient data retrieval. By maintaining an up-to-date record of all configuration changes, the elastic database provides a reliable source of information for network administrators to support decision-making, network optimization, and troubleshooting activities.

[00123] Thus, the method (400) aims to efficiently collect and process the network parameter changes from the multiple EMS deployed across the various network nodes to store the updated configuration changes in a single centralized database. The disclosed method (400) is particularly useful in scenarios where thousands of site parameters are updated frequently, requiring an organized approach to minimize errors and prevent system overloads.

[00124] FIG. 5 illustrates an exemplary flow diagram of a method (500) for managing the one or more configuration updates in the network (106), in accordance with an embodiment of the present disclosure. In an embodiment, the method (500) may be implemented using various modules (e.g., the retrieving module (212), the categorizing module (214), the processing module (216), and the updating module (218)) of the system (108).

[00125] At step 502, the method (500) includes retrieving, by a retrieving module (212), one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval. In an embodiment, the one or more real-time configuration change parameters may include, but is not limited to, one or more operational settings, firmware updates, software version updates, or node-specific settings.

[00126] In an embodiment, to retrieve the one or more real-time configuration change parameters from the at least one of plurality of EMSs, the method (500) includes sending, by the retrieving module (212), an access request to access each of the plurality of EMSs. The method (500) further includes determining, by the retrieving module (212), whether the access request sent to each of the plurality of EMS is accepted. The method (500) further includes, upon determining that the access request is accepted for the at least one EMS, retrieving, by the retrieving module (212), the one or more real-time configuration change parameters from the at least one EMS at the predefined time interval.

[00127] At step 504, the method (500) includes storing, by a processing module (216), the retrieved one or more real-time configuration change parameters in a transient repository. At step 506, the method (500) includes processing, by the processing module (216), the one or more real-time configuration change parameters stored in the transient repository to create a single update event. In an embodiment, to process the one or more real-time configuration change parameters, the method (500) further includes categorizing, by the categorizing module (214), each of the one or more real-time configuration change parameters stored in the transient repository into a predefined category using a categorization technique. The predefined category may include, but is not limited to, an EMS category, a Service Access Point (SAP) category, and a Management Object (MO) category.

[00128] The method (500) further includes storing, by the categorizing module (214), each of the categorized one or more real-time configuration change parameters into the DFS. The DFS is a system that allows files to be stored across multiple servers or nodes, ensuring redundancy, scalability, and fast access to data. In an embodiment, the DFS acts as an intermediate storage layer, providing a reliable mechanism to maintain a short-term history (e.g., 15 minutes history) of each of the one or more parameter changes.

[00129] In an embodiment, to process the one or more real-time configuration change parameters, the method (500) further includes collecting, by the processing module (216), the one or more real-time configuration change parameters from the DFS. The method (500) further includes parsing, by the processing module (216), the one or more real-time collected configuration change parameters to create the single update event.

[00130] At step 508, the method (500) includes updating, by the updating module (218), a central repository with the created single update event to reflect the one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository. In an embodiment, the created single update event considers a last incremental change among one or more incremental changes that occur in at least one real-time configuration change parameter over the predefined time interval as a final value for the corresponding real-time configuration change parameter, and wherein the created single update event captures each real-time configuration change that occurs in the at least one network node of the at least one EMS over the predefined time interval. [00131] In an embodiment, the method (500) includes creating, by the processing module (216), a record for each of the one or more incremental changes that occur in the at least one real-time configuration change parameter of the one or more real-time configuration change parameters over the predefined time interval. The method (500) further includes storing, by the processing module (216), one or more records created for the at least one real-time configuration change parameter over the predefined time interval as a parameter history for the corresponding at least one realtime configuration change parameter in the transient repository. The method (500) further includes sending, by processing module (216), the one or more created record from the transient repository to a user to analyze each of the one or more incremental changes that occur in the at least one real-time configuration change parameter over the predefined time interval.

[00132] In yet another exemplary embodiment, the present disclosure discloses a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for managing one or more configuration updates in the network. The method includes retrieving, by a retrieving module (212), one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval. The method further includes storing, by a processing module (216), the retrieved one or more realtime configuration change parameters in a transient repository. The method further includes processing, by the processing module (216), the one or more real-time configuration change parameters stored in the transient repository to create a single update event. The method further includes updating, by an updating module (218), a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository. [00133] FIG. 6 illustrates an exemplary computer system (600) in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 6, the computer system (600) may include an external storage device (610), a bus (620), a main memory (630), a read only memory (640), a mass storage device (650), a communication port (660), and a processor (670). A person skilled in the art will appreciate that the computer system (600) may include more than one processor (670) and communication ports (660). Processor (670) may include various modules associated with embodiments of the present disclosure.

[00134] In an embodiment, the communication port (660) may be any of an RS- 232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port (660) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects.

[00135] In an embodiment, the memory (630) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor (670).

[00136] In an embodiment, the mass storage (650) may be any current or future mass storage solution, which may be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays). [00137] In an embodiment, the bus (620) communicatively couples the processor(s) (670) with the other memory, storage and communication blocks. The bus (620) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (670) to the computer system (600).

[00138] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (620) to support direct operator interaction with the computer system (600). Other operator and administrative interfaces may be provided through network connections connected through the communication port (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.

[00139] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skills in the art.

[00140] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[00141] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.

[00142] The present disclosure provides technical advancement in managing configuration updates in the telecommunication networks. This advancement addresses the limitations of existing solutions by consolidating real-time configuration changes from multiple EMS into a single repository, reducing redundant updates and enhancing database performance. The disclosure involves retrieving, parsing, and aggregating configuration changes over predefined time intervals, significantly improving efficiency, scalability, and resource optimization. By implementing incremental configuration updates and live parameter history tracking, the present disclosure enhances network management operations by minimizing database hits and providing secure access through user authentication. This results in more reliable network configuration updates, reduced processing load, and improved system performance.

[00143] In an aspect, the single configuration repository for the entire network consists of data corresponding to the plurality of radio nodes belonging to the plurality of EMS. The repository is updated in real-time. A single data pool is used to perform any analysis required for network optimization. The data stored in the repository is used to debug network issues and problems.

ADVANTAGES OF THE PRESENT DISCLOSURE

[00144] The present disclosure provides a system and a method that maintains a single repository (e.g., a central repository) for the entire network consisting of multiple radio nodes that belong to a plurality of Element Management Systems (EMSs), enabling efficient access and update of the configuration changes without the need to log into each EMS individually.

[00145] The present disclosure reduces the volume of database update operations by aggregating real-time configuration changes over a predefined time interval, thus minimizing redundant updates and optimizing database performance.

[00146] The present disclosure creates a live parameter history (e.g., a record of real-time configuration changes) for each network node (e.g., radio nodes), enabling future validation and troubleshooting by maintaining an incremental record of all the configuration changes

[00147] The present disclosure provides a single data pool that allows for efficient analysis required for network optimization.

[00148] The present disclosure allows for debugging issues and problems occurring in the network, improving troubleshooting efficiency and minimizing network downtime.

Claims

1. A method (500) for managing one or more configuration updates in a network (106), the method (500) comprising: retrieving (502), by a retrieving module (212), one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval; storing (504), by a processing module (216), the retrieved one or more real-time configuration change parameters in a transient repository; processing (506), by the processing module (216), the one or more realtime configuration change parameters stored in the transient repository to create a single update event; and updating (508), by an updating module (218), a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository.

2. The method (500) as claimed in claim 1, wherein the created single update event considers a last incremental change among one or more incremental changes that occur in at least one real-time configuration change parameter over the predefined time interval as a final value for the corresponding real-time configuration change parameter, and wherein the created single update event captures each real-time configuration change that occurs in the at least one network node of the at least one EMS over the predefined time interval.

3. The method (500) as claimed in claim 1, wherein processing the one or more real-time configuration change parameters comprising: categorizing, by a categorizing module (214), each of the one or more real-time configuration change parameters stored in the transient repository into a predefined category using a categorization technique; and storing, by the categorizing module (214), each of the categorized one or more real-time configuration change parameters into a Distributed File System (DFS).

4. The method (500) as claimed in claim 1, wherein the one or more real-time configuration change parameters comprises one or more of operational settings, firmware updates, software version updates, network node-specific settings and others.

5. The method (500) as claimed in claim 1, wherein retrieving the one or more real-time configuration change parameters from the at least one of the plurality of EMSs comprises: sending, by the retrieving module (212), an access request to access each of the plurality of EMSs; determining, by the retrieving module (212), whether the access request sent to each of the plurality of EMS is accepted; and upon determining that the access request is accepted for the at least one EMS, retrieving, by the retrieving module (212), the one or more real-time configuration change parameters from the at least one EMS at the predefined time interval.

6. The method (500) as claimed in claim 1, comprising: creating, by the processing module (216), a record for each of the one or more incremental changes that occur in the at least one real-time configuration change parameter of the one or more real-time configuration change parameters over the predefined time interval; and storing, by the processing module (216), one or more records created for the at least one real-time configuration change parameter over the predefined time interval as a parameter history for the corresponding at least one real-time configuration change parameter in the transient repository.

7. The method (500) as claimed in claim 6, further comprising: sending, by processing module (216), the one or more created records from the transient repository to a user to analyze each of the one or more incremental changes that occur in the at least one real-time configuration change parameter over the predefined time interval.

8. The method (500) as claimed in claim 3, wherein processing the one or more real-time configuration change parameters further comprises: collecting, by the processing module (216), the one or more real-time configuration change parameters from the DFS over the predefined time interval; and parsing, by the processing module (216), the one or more real-time collected configuration change parameters to create the single update event.

9. A system (108) for managing one or more configuration updates in a network (106), the system (108) comprising: a retrieving module (212) configured to retrieve one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval; a processing module (216) configured to store the retrieved one or more real-time configuration change parameters in a transient repository; the processing module (216) configured to process the one or more realtime configuration change parameters stored in the transient repository to create a single update event; and an updating module (218) configured to update a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository.

10. The system (108) as claimed in claim 9, wherein the created single update event considers a last incremental change among one or more incremental changes that occur in at least one real-time configuration change parameter over the predefined time interval as a final value for the corresponding real-time configuration change parameter, and wherein the created single update event captures each real-time configuration change that occurs in the at least one network node of the at least one EMS over the predefined time interval.

11. The system (108) as claimed in claim 9, wherein to process the one or more real-time configuration change parameters, the categorizing module (214) is configured to: categorize each of the one or more real-time configuration change parameters stored in the transient repository into a predefined category using a categorization technique; and store each of the categorized one or more real-time configuration change parameters into a Distributed File System (DFS).

12. The system (108) as claimed in claim 9, wherein the one or more real-time configuration change parameters comprises one or more of operational settings, firmware updates, software version updates, and network node-specific settings.

13. The system (108) as claimed in claim 9, wherein to retrieve the one or more real-time configuration change parameters from the at least one of the plurality of EMSs, the retrieving module (212) is configured to: send an access request to access each of the plurality of EMSs; determine whether the access request sent to each of the plurality of EMSs is accepted; and upon determining that the access request is accepted for the at least one EMS, retrieve the one or more real-time configuration change parameters from the at least one EMS at the predefined time interval.

14. The system (108) as claimed in claim 9, wherein the processing module (216) is configured to: create a record for each of the one or more incremental changes in the transient repository that occur in the at least one real-time configuration change parameter of the one or more real-time configuration change parameters over the predefined time interval; and store one or more records created for the at least one real-time configuration change parameter over the predefined time interval as a parameter history for the corresponding at least one real-time configuration change parameter in the transient repository.

15. The system (108) as claimed in claim 14, wherein the processing module (216) is configured to: send the one or more created records from the transient repository to a user to analyze each of the one or more incremental changes that occur in the at least one real-time configuration change parameter over the predefined time interval.

16. The system (108) as claimed in claim 11, wherein to process the one or more real-time configuration change parameters, the processing module (216) is configured to: collect the one or more real-time configuration change parameters from the DFS over the predefined time interval; and parse the one or more real-time collected configuration change parameters to create the single update event.

17. A computer program product comprising a non -transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method (500) for managing one or more configuration updates in a network, the method (500) comprising: retrieving (502), by a retrieving module (212), one or more real-time configuration change parameters from at least one of a plurality of Element Management Systems (EMSs) at a predefined time interval; storing (504), by a processing module (216), the retrieved one or more real-time configuration change parameters in a transient repository; processing (506), by the processing module (216), the one or more realtime configuration change parameters stored in the transient repository to create a single update event; and updating (508), by an updating module (218), a central repository with the created single update event to reflect one or more real-time configuration updates in at least one network node of the at least one EMS within the central repository.