DESC:
FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

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

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

FIELD OF THE INVENTION
[0001] The present invention relates to the field of communication network management and, more specifically, to a system and a method for gathering performance data like alarm and counter data from a network inventory and sending the performance data to related micro-services via a dedicated interface to run a network function.
BACKGROUND OF THE INVENTION
[0002] A communication network comprises of many network elements which are configured to operate in specific manners to improve credibility of the communication network. The communication network incorporates inventories to safe-keep resources and mechanism to efficiently distribute resources to all Network Functions (NFs) in the communication network so as to process service requests. Inventory Management (IM) service maintains a virtual inventory and a limited physical inventory. The IM service maintains the relation between physical and virtual resources with respect to overlay to manage storage memory allocation. Also, the IM service describes the physical and virtual resources in view of different attributes (e.g., subscription status, version information, error logs or the like) using updates from external micro-service. Thus, the data accuracy of the inventory depends on the micro-services which create, update, and delete the resources (e.g., network link, bandwidth, network node information or the like) and at the same time, the inventory updated an event with the IM service. Other services can query IM relations, attributes etc. using query Application Programming Interface (API) provided by the IM service.
[0003] To optimize network performance, new network function like container network functions (CNF) and/or container network function components (CNFC), virtual network function (VNF) and/or virtual network function components (VNFC) are incorporated by dedicated micro-services which are allocated with the resources from the inventory by an inventory manager (e.g., physical and virtual inventory manager (PVIM) or the like). When any network function is initiated or terminated, there is an alarm which lets the communication network know that the certain new function has been introduced or a certain ongoing function has ceased. The inventory also gets updated each time some operational changes occur in the communication network. These changes and associated parameters, the value of those parameters, alarm data, counter data are updated and stored in the inventory. The inventory manager sends these data when requested by concerned micro-services for performance analysis. An assessment and performance analysis can be carried out properly and efficiently using the inventory manager, but there is a need for a dedicated mechanism for communication with the inventory manager.
[0004] There is a requirement of a system having an interface which enables efficient data exchange in between the inventory manager and other related micro-service which assesses the data provided to analyze the performance and implement self-healing.
SUMMARY OF THE INVENTION
[0005] One or more embodiments of the present disclosure provide a system and a method to enrich data of one or more microservices.
[0006] In one aspect of the present invention, the method to enrich the data of the one or more microservices is disclosed. The method includes receiving, by one or more processors, a notification from an Inventory Manager (IM) to retrieve at least one of: alarms, performance counters and performance metrics of one or more network functions upon instantiation of the one or more network functions. Further, the method includes retrieving, by the one or more processors, data pertaining to at least one of: the alarms, the performance counters and the performance metrics from one or more sources based on receiving the notification from the IM. Further, the method includes enriching, by the one or more processors, the one or more microservices with the retrieved data.
[0007] In an embodiment, the notification received from the IM includes at least one information required to retrieve the data pertaining to at least one of: the alarms, the performance counters and the performance metrics.
[0008] In an embodiment, the one or more sources include at least one of: the one or more network functions, cloud resources, one or more external file locations and performance metering endpoints.
[0009] In an embodiment, the step of retrieving the data pertaining to at least one of: the alarms from the one or more sources based on receiving the notification from the IM includes collecting, by the one or more processors, alarm data pertaining to at least one of: identifiable network functions or unidentifiable network functions from the one or more sources, mapping, by the one or more processors, the alarm data with the one or more network functions utilizing respective one or more network function identifiers, identifying, by the one or more processors, a status of the alarm data based on scanning an alarm dictionary of the mapped alarms, and storing, by the one or more processors, the alarm data subsequent to identifying the status of the alarm data.
[0010] In an embodiment, the status of the alarm data is based on nature of severity of the alarms, where the nature of severity of alarms includes at least one of: critical, major, minor, warning, intermediate and cleared.
[0011] In an embodiment, the step of retrieving, data of performance counters and performance metrics from the one or more sources based on receiving the notification from the IM includes the steps of: retrieving, by the one or more processors, data of the performance counters from the one or more sources including at least one the one or more external file locations, retrieving, by the one or more processors, the performance metrics from the one or more sources including at least one of performance metering endpoints, and storing, by the one or more processors, the retrieved performance counters and the performance metrics in a database.
[0012] In an embodiment, the step of enriching, the one or more microservices with the retrieved data includes the steps of transmitting, by the one or more processors, an event request to the IM to schedule tasks to enrich the one or more microservices with the retrieved data and enabling, by the one or more processors, the one or more microservices to determine implementation of at least one of, scale-in or self-heal operation upon enrichment of the one or more microservices. The event request includes information of the retrieved data.
[0013] In an embodiment, the schedule tasks include at least one periodically scheduling tasks to enrich the one or more microservices with the retrieved data.
[0014] In an embodiment, the one or more microservices are enriched with the retrieved data based on an event driven architecture including at least one of, event streams and event sourcing.
[0015] In an embodiment, the one or more processors, establishes a communication channel is between the IM and an elementary management system (EMS), wherein the communication channel is an interface.
[0016] In an embodiment, the interface is at least one of, an Inventory Manager_elementary management system (IM_EMS) interface.
[0017] In one aspect of the present invention, the system to enrich data of one or more microservices is disclosed. The system includes a transceiver, a retrieving unit and an enrichment unit. The transceiver is configured to receive a notification from an IM to retrieve at least one of: alarms, performance counters and performance metrics of one or more network functions upon instantiation of the one or more network functions. The retrieving unit is configured to retrieve data pertaining to at least one of the alarms, the performance counters and the performance metrics from one or more sources based on receiving the notification from the IM. The enrichment unit is configured to enrich the one or more microservices with the retrieved data.
[0018] In one aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions is disclosed. The non-transitory computer-readable medium causes the processor to receive a notification from an IM to retrieve at least one of: alarms, performance counters and performance metrics of one or more network functions upon instantiation of the one or more network functions. The processor retrieves data pertaining to at least one of: the alarms, the performance counters and the performance metrics from one or more sources based on receiving the notification from the IM. The processor enriches the one or more microservices with the retrieved data.
[0019] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS
[0020] 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.
[0021] FIG. 1 is an exemplary block diagram of an environment to enrich data of one or more microservices, according to various embodiments of the present disclosure.
[0022] FIG. 2 is a block diagram of a system of FIG. 1, according to various embodiments of the present disclosure.
[0023] FIG. 3 is an example schematic representation of the system of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system.
[0024] FIG. 4 illustrates an example system architecture for gathering alarm, counter data, performance meters from an inventory and sending the data to related micro-service by a dedicated interface, according to various embodiments of the present system.
[0025] FIG. 5 illustrates a workflow of the interaction in between an inventory manager (e.g., PVIM) and an EMS (elementary management system) via an IM_EMS interface, according to various embodiments of the present system.
[0026] FIG. 6 illustrates another example system architecture to enrich data of one or more microservices, according to various embodiments of the present system.
[0027] FIG. 7 illustrates an architecture framework (e.g., MANO architecture framework), in which the present invention can be implemented, in accordance with an embodiment of the present invention.
[0028] FIG. 8 is a flow diagram illustrating a method to enrich the data of the one or more microservices, according to various embodiments of the present system.
[0029] FIG. 9 illustrates a flow diagram of a method including the steps for gathering the alarm, the counter data, and the performance meters from the inventory and sending the data to related micro-service by the dedicated interface, according to various embodiments of the present system.
[0030] Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.
[0031] The foregoing shall be more apparent from the following detailed description of the invention.

DETAILED DESCRIPTION OF THE INVENTION
[0032] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0033] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0034] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0035] Before discussing example, embodiments in more detail, it is to be noted that the drawings are to be regarded as being schematic representations and elements that are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software or a combination thereof.
[0036] Further, the flowcharts provided herein, describe the operations as sequential processes. Many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of operations maybe re-arranged. The processes may be terminated when their operations are completed, but may also have additional steps not included in the figured. It should be noted, that in some alternative implementations, the functions/acts/ steps noted may occur out of the order noted in the figured. For example, two figures shown in succession may, in fact, be executed substantially concurrently, or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
[0037] Further, the terms first, second etc… may be used herein to describe various elements, components, regions, layers and/or sections, it should be understood that these elements, components, regions, layers and/or sections should not be limited by these terms. These terms are used only to distinguish one element, component, region, layer or section from another region, layer, or a section. Thus, a first element, component, region layer, or section discussed below could be termed a second element, component, region, layer, or section without departing form the scope of the example embodiments.
[0038] Spatial and functional relationships between elements (for example, between modules) are described using various terms, including “connected,” “engaged,” “interfaced,” and “coupled.” Unless explicitly described as being “direct,” when a relationship between first and second elements is described in the description below, that relationship encompasses a direct relationship where no other intervening elements are present between the first and second elements, and also an indirect relationship where one or more intervening elements are present (either spatially or functionally) between the first and second elements. In contrast, when an element is referred to as being "directly” connected, engaged, interfaced, or coupled to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., "between," versus "directly between," "adjacent," versus "directly adjacent," etc.).
[0039] The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example embodiments belong. It will be further understood that terms, e.g., those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
[0040] As used herein, the singular forms “a,” “an,” and “the,” are intended to include the plural forms as well, unless the context clearly indicates otherwise. As used herein, the terms “and/or” and “at least one of” include any and all combinations of one or more of the associated listed items. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, 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.
[0041] Unless specifically stated otherwise, or as is apparent from the description, terms such as “processing” or “computing” or “calculating” or “determining” of “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device/hardware, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[0042] Various embodiments of the present invention provide a system and method for gathering alarm, counter data, performance meters from an inventory (e.g., PVIM) and sending the data to related micro-service by a dedicated interface (IM_EMS), to assess the performance and implement relevant scaling or healing for improvement. However, the invention is not to be limited to only these embodiments.
[0043] FIG. 1 illustrates an exemplary block diagram of an environment (100) to enrich data of one or more microservices, according to various embodiments of the present disclosure. The one or more microservices are an architectural style that structures an application as a collection of loosely coupled, independently deployable services. Each microservice focuses on a specific business capability and communicates with other microservices through well-defined APIs. The environment (100) comprises a plurality of user equipment’s (UEs) (102-1, 102-2, ……,102-n). The at least one UE (102-n) from the plurality of the UEs (102-1, 102-2, ……102-n) is configured to connect to a system (108) via a communication network (106). Hereafter, label for the plurality of UEs or one or more UEs is 102.
[0044] In accordance with yet another aspect of the exemplary embodiment, the plurality of UEs (102) may be a wireless device or a communication device that may be a part of the system (108). The wireless device or the UE (102) may include, but are not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch, a computer device, and so on), 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 or Voice Over Internet Protocol (VoIP) capabilities. In an embodiment, the UEs (102) may include, but are not limited to, any electrical, electronic, electro-mechanical or an 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, where the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen and the like. It may be appreciated that the UEs (102) may not be restricted to the mentioned devices and various other devices may be used. A person skilled in the art will appreciate that the plurality of UEs (102) may include a fixed landline, and a landline with assigned extension within the communication network (106).
[0045] The communication network (106), may use one or more communication interfaces/protocols such as, for example, Voice Over Internet Protocol (VoIP), 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as Code Division Multiple Access (CDMA), CDMA2000, Wideband CDMA (WCDMA), Radio Frequency Identification (e.g., RFID), Infrared, laser, Near Field Magnetics, etc.
[0046] The communication network (106) includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The communication network (106) may include, but is not limited to, a Third Generation (3G) network, a Fourth Generation (4G) network, a Fifth Generation (5G) network, a Sixth Generation (6G) network, a New Radio (NR) network, a Narrow Band Internet of Things (NB-IoT) network, an Open Radio Access Network (O-RAN), and the like.
[0047] The communication network (106) may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The communication network (106) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, a VOIP or some combination thereof.
[0048] One or more network elements can be, for example, but not limited to a base station that is located in the fixed or stationary part of the communication network (106). The base station may correspond to a remote radio head, a transmission point, an access point or access node, a macro cell, a small cell, a micro cell, a femto cell, a metro cell. The base station enables transmission of radio signals to the UE (102) or a mobile transceiver. Such a radio signal may comply with radio signals as, for example, standardized by a 3rd Generation Partnership Project (3GPP) or, generally, in line with one or more of the above listed systems. Thus, a base station may correspond to a NodeB, an eNodeB, a Base Transceiver Station (BTS), an access point, a remote radio head, a transmission point, which may be further divided into a remote unit and a central unit. The 3GPP specifications cover cellular telecommunications technologies, including radio access, core network, and service capabilities, which provide a complete system description for mobile telecommunications.
[0049] The system (108) is communicatively coupled to a server (104) via the communication network (106). The server (104) can be, for example, but not limited to a standalone server, a server blade, a server rack, an application server, a bank of servers, a business telephony application server (BTAS), a server farm, a cloud server, an edge server, home server, a virtualized server, one or more processors executing code to function as a server, or the like. In an implementation, the server (104) may operate at various entities or a single entity (include, but is not limited to, a vendor side, a service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, a defense facility side, or any other facility) that provides service.
[0050] The environment (100) further includes the system (108) communicably coupled to the server (e.g., remote server or the like) (104) and each UE of the plurality of UEs (102) via the communication network (106). The remote server (104) is configured to execute the requests in the communication network (106).
[0051] The system (108) is adapted to be embedded within the remote server (104) or is embedded as an individual entity. The system (108) is designed to provide a centralized and unified view of data and facilitate efficient business operations. The system (108) is authorized to access to update/create/delete one or more parameters of their relationship between the requests for a microservice, which gets reflected in real-time independent of the complexity of network.
[0052] In another embodiment, the system (108) may include an enterprise provisioning server (for example), which may connect with the remote server (104). The enterprise provisioning server provides flexibility for enterprises, ecommerce, finance to update/create/delete information related to the requests for the microservices in real time as per their business needs. A user with administrator rights can access and retrieve the requests for the microservices and perform real-time analysis in the system (108).
[0053] The system (108) may include, by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a business telephony application server (BTAS), a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an implementation, system (108) may operate at various entities or single entity (for example include, but is not limited to, a vendor side, service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, ecommerce side, finance side, a defense facility side, or any other facility) that provides service.
[0054] However, for the purpose of description, the system (108) is described as an integral part of the remote server (104), without deviating from the scope of the present disclosure. Operational and construction features of the system (108) will be explained in detail with respect to the following figures.
[0055] FIG. 2 illustrates a block diagram of the system (108) provided for enriching the data of the one or more microservices, according to one or more embodiments of the present invention. As per the illustrated embodiment, the system (108) includes the one or more processors (202), the memory (204), an input/output interface unit (206), a display (208), an input device (210), and the database (214). Further the system (108) may comprise one or more processors (202). The one or more processors (202), hereinafter referred to as the processor (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. As per the illustrated embodiment, the system (108) includes one processor. However, it is to be noted that the system (108) may include multiple processors as per the requirement and without deviating from the scope of the present disclosure.
[0056] An information related to the microservices may be provided or stored in the memory (204) of the system (108). Among other capabilities, the processor (202) is configured to fetch and execute computer-readable instructions stored in the memory (204). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0057] The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like. In an embodiment, the system (108) may include an interface(s). The interface(s) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as input/output (I/O) devices, storage devices, and the like. The interface(s) may facilitate communication for the system. The interface(s) may also provide a communication pathway for one or more components of the system. Examples of such components include, but are not limited to, processing unit/engine(s) and the database (214). The processing unit/engine(s) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s).
[0058] The information related to the microservices may further be configured to render on the user interface (206). The user interface (206) may include functionality similar to at least a portion of functionality implemented by one or more computer system interfaces such as those described herein and/or generally known to one having ordinary skill in the art. The user interface (206) may be rendered on the display (208), implemented using Liquid Crystal Display (LCD) display technology, Organic Light-Emitting Diode (OLED) display technology, and/or other types of conventional display technology. The display (208) may be integrated within the system (108) or connected externally. Further the input device(s) (210) may include, but not limited to, keyboard, buttons, scroll wheels, cursors, touchscreen sensors, audio command interfaces, magnetic strip reader, optical scanner, etc.
[0059] The database (214) may be communicably connected to the processor (202) and the memory (204). The database (214) may be configured to store and retrieve the request pertaining to features, or services or workflow of the system (108), access rights, attributes, approved list, and authentication data provided by an administrator. In another embodiment, the database (214) may be outside the system (108) and communicated through a wired medium and a wireless medium.
[0060] Further, the processor (202), in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor (202). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor (202). In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by an electronic circuitry.
[0061] In order for the system (108) to enrich data of the one or more microservices, the processor (202) includes a transceiver (216), a retrieving unit (218), and an enrichment unit (220). The transceiver (216), the retrieving unit (218), and the enrichment unit (220) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor (202). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by the electronic circuitry.
[0062] In order for the system (108) to enrich data of the one or more microservices, the transceiver (216), the retrieving unit (218), and the enrichment unit (220) are communicably coupled to each other. In an embodiment, the transceiver (216) receives a notification from an IM (e.g., PVIM 406 (as shown in FIG. 4)) to retrieve at least one of: alarms, performance counters and performance metrics of one or more network functions upon instantiation of one or more network functions. Ther notification received from the IM includes information required to retrieve the data pertaining to at least one of the alarms, the performance counters and the performance metrics.
[0063] The alarms are notifications or alerts triggered when the network function encounters an issue or deviates from expected performance thresholds. The issue or deviation is related to hardware failures (e.g., CPU failures, memory errors), a network connectivity, service availability, resource allocation, and resource utilization (in an example, when servers usage or storage usage exceed a predefined usage threshold). The performance counters are quantitative measures used to monitor various aspects of network function performance. The performance counters provide data on resource usage and operational efficiency. The performance metrics are indicators that reflect the efficiency, capacity, and reliability of network functions. They are used to evaluate and optimize the performance of network functions.
[0064] In shorts, the alarms help in early detection and response to the issues. The performance counters provide detailed quantitative data on the resource usage. The performance metrics offer insights into the efficiency and effectiveness of network functions.
[0065] Further, the retrieving unit (218) retrieves data pertaining to at least one of: the alarms, the performance counters and the performance metrics from one or more sources based on receiving the notification from the IM. The one or more sources can be, for example, but not limited to the one or more network functions, cloud resources, one or more external file locations and performance metering endpoints. The performance metering endpoints are designated points in a network function, either physical or virtual, where the performance metrics are gathered. The performance metering endpoints provide data on various aspects of network function performance, such as throughput, latency, error rates, and resource utilization.
[0066] In an embodiment, the retrieving unit (218) collects the alarm data pertaining to at least one of: identifiable or unidentifiable network functions from the one or more sources. The identifiable network functions are network functions that can be uniquely recognized and distinguished based on specific attributes or identifiers (e.g. IP addresses, Media Access Control (MAC) addresses, unique function IDs, configuration details, version numbers, status information or the like). These functions have distinct characteristics or metadata that allow them to be clearly identified in a network management system (NMS). The unidentifiable network functions are network functions that lack distinct or unique attributes that allow them to be easily recognized or tracked in the network management system. In an example, the unidentifiable network functions are related to generic network traffic or anonymous services. The generic network traffic patterns or flows that are not associated with specific network functions. The anonymous services operate without explicit identification or tagging.
[0067] Further, the alarm data is required to be mapped to the network functions in order to enrich the microservices. Further, the retrieving unit (218) maps the alarm data with the one or more network functions utilizing respective one or more network function identifiers. In an example, the retrieving unit (218) efficiently maps the alarm data to the network functions using the unique identifiers. This mapping enables precise monitoring and management of network functions, facilitating quick identification and resolution of issues. By using the identifiers, the retrieving unit (218) ensures that the alarms are correctly associated with their sources, leading to effective network operations and management. Further, the retrieving unit (218) identifies a status (e.g., active, in-active, completed or the like) of the alarm data based on scanning an alarm dictionary of the mapped alarms. Further, the retrieving unit (218) stores the alarm data subsequent to identifying the status of the alarm data.
[0068] The status of the alarm data is based on the nature of severity of the alarms. The nature of the severity of alarms includes at least one of: critical, major, minor, warning, intermediate and cleared. The critical represents severe issues that cause significant impact or complete service failure. In an example, the network function failure causes service outage, and critical hardware malfunction. The major indicates serious problems that affect performance but do not completely halt operations. In an example, high CPU usage on a router that is causing performance degradation. The minor denotes less severe issues that have limited impact on network function performance. In an example, low disk space warnings on a server that does not yet impact service. The warning alerts about potential issues or thresholds nearing critical levels. In an example, warning for high bandwidth usage that is approaching maximum capacity. The intermediate indicates that often used to represent issues that are between minor and major severity; less common. The cleared indicates that an issue previously reported has been resolved or is no longer present.
[0069] In another embodiment, the retrieving unit (218) retrieves the data of the performance counters from the one or more sources including at least one external file locations. The at least one external file locations is defined by a service provider or an operator. Further, the retrieving unit (218) retrieves the performance metrics from the one or more sources including the at least one performance metering endpoints. Further, the retrieving unit stores the retrieved performance counters and the performance metrics in the database (214).
[0070] The enrichment unit (220) enriches the one or more microservices with the retrieved data. The one or more microservices are enriched with the retrieved data based on an event driven architecture including at least one of: event streams and event sourcing. The event streams refer to continuous sequences of events or records that are produced and consumed in real-time. The event streams enable the processing of these events in a scalable and efficient manner. In an example, real-time alerts and notifications about issues like high latency, hardware failures, or configuration errors.
[0071] The event sourcing is a design pattern where state changes are captured as a sequence of events rather than storing the current state directly. An application state is reconstructed by replaying these events. This approach provides a comprehensive history of changes and facilitates complex data recovery and audit capabilities. Consider, the system (108) has a cloud infrastructure consisting of various microservices that monitor the health and performance of servers, applications, and network components. These microservices need to provide real-time alerts and notifications about issues such as high latency, hardware failures, or configuration errors. To manage this efficiently, the system (108) implements the event-driven architecture using the event streams and the event sourcing. The event streams are continuous sequences of events produced and consumed in real-time. The event sourcing involves capturing changes to the system state as a sequence of events rather than storing just the current state. In the cloud infrastructure, the event-driven architecture with the event streams and the event sourcing enables scalable, efficient processing of monitoring data and provides timely alerts and notifications about critical issues.
[0072] In an example, the enriching unit (220) transmits an event request to the IM to schedule tasks to enrich the one or more microservices with the retrieved data. The schedule tasks include at least one periodically scheduling tasks to enrich the one or more microservices with the retrieved data. The event request includes information of the retrieved data. Further, the enriching unit (220) enables the one or more microservices to determine implementation of at least one of, scale-in or self-heal operation upon enrichment of the one or more microservices.
[0073] The example for enriching the data of one or more microservices is explained in FIG. 4 to FIG. 6.
[0074] FIG. 3 is an example schematic representation of the system (300) of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE (102-1) and the system (108) for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0075] As mentioned earlier, the first UE (102-1) includes one or more primary processors (305) communicably coupled to the one or more processors (202) of the system (108). The one or more primary processors (305) are coupled with a memory (310) storing instructions which are executed by the one or more primary processors (305). Execution of the stored instructions by the one or more primary processors (305) enables the UE (102-1). The execution of the stored instructions by the one or more primary processors (305) further enables the UE (102-1) to execute the requests in the communication network (106).
[0076] As mentioned earlier, the one or more processors (202) is configured to transmit a response content related to the microservices to the UE (102-1). More specifically, the one or more processors (202) of the system (108) is configured to transmit the response content to at least one of the UE (102-1). A kernel (315) is a core component serving as the primary interface between hardware components of the UE (102-1) and the system (108). The kernel (315) is configured to provide the plurality of response contents hosted on the system (108) to access resources available in the communication network (106). The resources include one of a Central Processing Unit (CPU), memory components such as Random Access Memory (RAM) and Read Only Memory (ROM).
[0077] As per the illustrated embodiment, the system (108) includes the one or more processors (202), the memory (204), the input/output interface unit (206), the display (208), and the input device (210). The operations and functions of the one or more processors (202), the memory (204), the input/output interface unit (206), the display (208), and the input device (210) are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure. Further, the processor (202) includes the transceiver (216), the retrieving unit (218), and the enrichment unit (220). The operations and functions of the transceiver (216), the retrieving unit (218), and the enrichment unit (220)are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure.
[0078] FIG. 4 illustrates an example system architecture (400) for gathering the alarm, the counter data, and the performance meters from the inventory manager (or PVIM) (406) and sending the data to related micro-service by a dedicated interface (e.g., IM_EMS (408) or the like), according to various embodiments of the present system. The PVIM (406) and the EMS (402) are exchanging information via a communication channel which is an interface. In an embodiment, the interface is at least one of, an Inventory Manager_elementary management system (IM_EMS) interface (408). The IM_EMS interface (408) is configured to receive and transmit data between the PVIM (406) and the EMS (402). FIG. 5 illustrates a workflow of the interaction in between the inventory manager (e.g., PVIM) (406) and an EMS (elementary management system) (402) via the IM_EMS interface (408), in accordance with an embodiment of the present invention.
[0079] As shown in FIG. 4 and FIG. 5, the IM_EMS interface (408) includes an assurance manager (AM) (not shown) and a performance manager (PM) (not shown). The example system architecture (400) also include the EMS (402), a PVIM (physical and virtual inventory manager) (406) (aka “inventory manager”), a CNF life cycle manger (CNFLM) (not shown) and a VNF life cycle manager (VNFLM) (not shown). The system architecture (400) may include the database (214) that is configured to interact with various network elements and micro-services like server, docker service, capacity manager and scheduler etc. The IM_EMS interface (408) by means of the AM and the PM collects the data by utilizing an open stack ceilometer (602) (as shown in FIG. 6), for any kind of the alarm or the counter when the network functions is instantiated etc.
[0080] Further, the IM_EMS interface (408) sends enrichment data which contain all required information stored in the inventory manager (406) and is essential for performance assessment and capacity monitoring. Based on the required information, a concerned micro-service decides whether there is a requirement of scaling or healing for the performance to improve the microservice. The inventory manager (406) is configured to manage and store all available data, resource, and information in the communication network (106). The inventory manager (406) communicated with the database (214) in a PVIM cluster (404).
[0081] In an example, the IM_EMS interface (408) performs all the inventory related operation and sends the alarm data, counter data etc. to concerned micro-services like capacity management service (CMP). The interface (408) is capable of generating data related to the alarm management generated by the VNF’s/CNF’s. Further, the interface (408) sends the alarm enrichment for VNFs/CNFs for the required micro-services. The interface (408) generates data related to management of counters and meter’s data of the VNF’s/CNF’s. Also, the interface (408) manages and monitors other associated parameters. All the data are needed to perform the scaling and healing of CNF/VNF by other respective micro-services to take the decision. All these data are being stored by the EMs (402) and enriched to other micro-services via the IM_EMS interface (408).
[0082] Also, the system architecture (400) is also capable of interacting with Network Function life cycle manager (NFLM), and predefined centralized Platform Operations, Administration and Maintenance Manager (POAM) which provides available PVIM instance and load balancer details, servers and other network elements in the network (106).
[0083] In another example, the inventory manger (406) sends the VNF’s and CNF’s information after instantiation to the EMS (402) for the enrichment. The interface (408) by means of the AM stores the alarms raised by the VNF in an ES (elementary system) database (622). The ES database (622) stores the alarms generated by a telemetry alarming service of the ceilometer (602). The AM informs the PVIM (406) for enrichment of alarms. That is, the alarm data received from the VNF is mapped with a VIM-Identifier, VNF-Identifier and VNF-Instance-Identifier etc.). The AM also reads the alarm dictionary of each VNF and stores it in the ES DB (622) for encoding/decoding of alarm JSON using a DMF (data management framework) (not shown) and handles the events for clearance of an alarm from the UI (206) and the VNF. The AM handles the event for clearing the alarms generated by the telemetry alarming service. Further, the AM also stores the alarms which cannot be mapped (i.e. alarms received from an unidentified VNF instance). The interface, by means of the PM (performance manager) (620) reads a counter dictionary for each VNF and stores it in the ES database (622). The PM (620) adds product information, metadata and rule into a CDI pertaining to the VNF for counter operations. The PM arranges to read the counter dump from external file location which consists of .csv files with specific file naming convention. The PM (620) arranges to store the counter information for each VNF in the ES DB (622) which can then be fetched whenever required.
[0084] The IM_EMS interface (408) collects the NFVI (network functions virtualization infrastructure) level meters. The PM (620) fetches the metering data which is generated from Openstack Ceilometer (602) and then pushed onto the PM endpoint. This metering data helps in knowing the various resource utilization of a particular infrastructure. The OpenStack Ceilometer (602) is a component of an OpenStack cloud computing platform that provides telemetry services. The OpenStack Ceilometer (602) is responsible for collecting, processing, and storing metrics and measurements related to various resources and services in the OpenStack cloud computing platform. OpenStack is an open-source cloud computing platform designed to create and manage both public and private clouds. It provides a collection of interrelated services for managing compute, storage, and networking resources. With a modular architecture, OpenStack allows users to deploy infrastructure as a service (IaaS) solutions that can scale easily based on demand. The OpenStack cloud platform is an open-source software platform for building and managing public and private clouds. It is used to provide Infrastructure as a Service (IaaS) by pooling virtualized resources such as compute, storage, and networking, which can be controlled via a web-based dashboard, command-line tools, or RESTful APIs. The meters received at the PM (620) are the following categories such as CPU, memory, disk, network, performance, compute and miscellaneous data. The PVIM (406) and the IM_EMS interface (408) sends out the enriched data in a scheduled manner at a specific time or within a specific interval which may be configured by a user. The system architecture (400) offers an adequate and suitable solution to proper alarms management system by storing unmapped alarms and related details.
[0085] In preferred embodiments, the system architecture (400) may be implemented based on a management and orchestration framework which is a teleco-cloud infrastructure interface, as a key element of the network functions virtualization (NFV) architecture. Also, the inventory manager may coordinate network resources for cloud-based applications and manage any virtual network functions (VNFs) or container network function (CNF) and/or other network services. The inventory manager may be configured to interact with various APIs (application programming interface).
[0086] The system architecture (400) may incorporate various components which may be physical or cloud based, to search and collect required information, to create of trigger events and to process requests received from the user interface (408). The sub-modules of the components of the system architecture (400) should not be considered limited only to as stated only and can be accommodating for any type of logical or physical units/modules.
[0087] FIG. 6 illustrates another example system architecture (600) to enrich data of the one or more microservices, in accordance with an embodiment of the present invention. The performance manger (620) is communicated with the ceilometer (602), an OAM (606), and the ES database (622). A Gnocchi (604) is included in the ceilometer (602). The Gnocchi (604) is a metric and time-series database service used within the OpenStack cloud computing platform, often in conjunction with the OpenStack Ceilometer (602). Specifically, the Gnocchi (604) serves as a backend storage and management system for the data (e.g., CPU, memory, disk, network, performance, compute and miscellaneous data or the like) collected by the OpenStack Ceilometer (602). The OAM (606) is communicated with a CLI-interface (206a) and a GUI-interface (206b). The performance manger (620) includes an EDGE-LB (608), a Fault, Configuration, Accounting, Performance, Security (FCAPS) management module (610), an event handling module (612), a logging service module (614), a meter collection module (616) and an ES-DB client (618).
[0088] The EDGE-load balancer (LB) (608), the FCAPS management module (610), the event handling module (612), the logging service module (614), the meter collection module (616) and the ES-DB client (618) work together to ensure effective monitoring, management, and analysis of network functions, enhancing overall network performance and reliability. The EDGE-LB (608) distributes traffic and workload to balance performance and reliability. The FCAPS management module (610) manages faults, configurations, accounting, performance, and security in network functions. The event handling module (612) processes and manages real-time events related to alarms and performance. The logging service module (614) collects and manages logs for diagnostics and performance tracking. The meter collection module (616) gathers and aggregates performance metrics and counters. The ES-DB Client (618) interfaces with a database for storing, retrieving, and querying performance data and logs.
[0089] In an embodiment, the AM is used to handle the alarms generated by the VNFs and telemetry alarming service of the ceilometer (602). the AM uses the database (622) to store the alarms. The alarms generated by the VNFs are sent for enrichment. The performance manager (620) comes under the core services of an NFV-SDN architecture to provide the performance management service. The performance manager (620) provides an interface wherein the counters can be extracted from VNF/CNF and stored in the database (622). It also provides an interface to fetch meters from the ceilometer (602) to track the NFVI level metering data. The counters and meters data which gets stored in the database (622) is ultimately fetched for displaying on UI console (e.g., CLI-interface (206a) and a GUI-interface (206b)).
[0090] FIG. 7 illustrates an architecture framework (e.g., MANO architecture framework), in which the present invention can be implemented, in accordance with an embodiment of the present invention. The system architecture (700) includes the user interface (206), a Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) design function module (702), a platform foundation service module (704), a platform core service module (706), and a platform resource adapter and utilities module (708).
[0091] The NFV and SDN design function module (702) is crucial for modernizing network infrastructure by enabling virtualized, scalable, and programmable network functions and management systems, particularly within the framework of CNFs. The platform foundation service module (704) refers to the underlying services and infrastructure components that support and enable the deployment, operation, and management of containerized network functions. The platform foundation service module (704) provides the essential capabilities and resources required for the CNF environment to function effectively.
[0092] The platform core service module (706) refers to the fundamental services and components that are essential for the core functionality and operation of containerized network functions. These services are critical for the effective deployment, execution, and management of CNFs, providing the necessary support and infrastructure for their operation. The platform resource adapter and utilities module (708) refers to a set of components and tools designed to manage and adapt various resources and services necessary for the operation of CNFs. The platform resource adapter and utilities module (708) plays a crucial role in integrating CNFs with underlying infrastructure and services, providing the necessary support for efficient operation, resource utilization, and interoperability.
[0093] The NFV and SDN design function module (702) includes a VNF lifecycle manger (702a), a VNF catalog (702b), a network service catalog (702c), a network slicing and service chaining manger (702d), a physical and virtual resource manager (702e), and a CNF lifecycle manager (702f).
[0094] The VNF lifecycle manager (702a) is responsible for managing the entire lifecycle of Virtual Network Functions (VNFs). The VNF lifecycle manager (702a) ensures that VNFs or CNFs are deployed, configured, monitored, scaled, and eventually decommissioned effectively. The VNF catalog (702b) (referred to as a CNF catalog) is a repository or registry that stores information about various containerized network functions and their configurations. The VNF catalog (702b) serves as a central reference for managing and deploying CNFs, providing details about their capabilities, requirements, and how they can be used within the network environment. The network service catalog (702c) is a comprehensive repository that organizes and manages the information related to network services composed of multiple CNFs or other network functions. The network service catalog (702c) serves as a central resource for defining, deploying, and managing these services within a containerized network environment.
[0095] The network slicing and service chaining manger (702d) is a crucial component responsible for orchestrating and managing network slicing and service chaining functionalities. These functionalities are essential for efficiently utilizing network resources and delivering tailored network services in a dynamic and scalable manner. The physical and virtual resource manager (702e) is a critical component responsible for overseeing and managing both physical and virtual resources required to support the deployment, operation, and scaling of CNFs. The physical and virtual resource manager (702e) ensures that the necessary resources are allocated efficiently and effectively to meet the performance, availability, and scalability requirements of containerized network functions.
[0096] Further, the CNF lifecycle manager (702f) is a component responsible for overseeing the entire lifecycle of containerized network functions. This includes the management of CNFs from their initial deployment through ongoing operation and maintenance, up to their eventual decommissioning. The CNF lifecycle manager (702f) ensures that the CNFs are efficiently deployed, monitored, scaled, updated, and removed, facilitating the smooth operation of network services in a containerized environment.
[0097] The platform foundation service module (704) includes a microservice elastic load balancer (704a), an identity and access manager (704b), a command line interface (704c), a central logging manger (704d) and an event routing manger (704e).
[0098] The microservice elastic load balancer (704a) is a specific type of load balancer designed to dynamically distribute network traffic across a set of microservices running in a containerized environment. Its primary purpose is to ensure efficient resource utilization, maintain high availability, and improve the performance of network services by evenly distributing incoming traffic among multiple instances of microservices. The identity and access manager (704b) is a critical component responsible for managing and securing access to containerized network functions and their resources. The identity and access manager (704b) ensures that only authorized users and systems can access specific resources, and it enforces policies related to identity verification, authentication, authorization, and auditing within the CNF ecosystem.
[0099] The central logging manger (704d) is a component responsible for aggregating, managing, and analyzing log data from various containerized network functions and associated infrastructure components. This centralized approach to logging ensures that logs are collected from disparate sources, consolidated into a single repository, and made accessible for monitoring, troubleshooting, and auditing purposes. The event routing manger (704e) is a component responsible for handling the distribution and routing of events and notifications generated by various parts of the CNF environment. This includes events related to system status, performance metrics, errors, and other operational or application-level events. The event routing manger (704e) ensures that these events are efficiently routed to the appropriate consumers, such as monitoring systems, alerting systems, or logging infrastructure, for further processing and action.
[00100] The platform core service module (706) includes an NFV infrastructure monitoring manager (706a), an assurance manager (706b), a performance manger (706c), a policy execution engine (706d), a capacity monitoring manger (706e),a release management repository (706f), a configuration manger and GCT (706g), a NFV platform decision analytics unit (706h), a platform NoSQL DB (706i), a platform scheduler and Cron Jobs module (706j), a VNF backup & upgrade manger (706k), a micro service auditor (706l), and a platform operation, administration and maintenance manager (706m).
[00101] The NFV infrastructure monitoring manager (706a) monitors the underlying infrastructure of NFV environments, including computing, storage, and network resources. The NFV infrastructure monitoring manager (706a) provides real-time visibility into resource health, performance, and utilization. Further, the NFV infrastructure monitoring manager (706a) detects and alerts on infrastructure issues. Further, the NFV infrastructure monitoring manager (706a) integrates with monitoring tools to ensure reliable operation of CNFs.
[00102] The assurance manager (706b) manages the quality and reliability of network services by ensuring compliance with service level agreements (SLAs) and operational standards. The performance manger (706c) optimizes the performance of CNFs by tracking and analyzing key performance indicators (KPIs). The policy execution engine (706d) enforces and applies policies within the CNF environment to manage operations and access. Further, the policy execution engine (706d) executes policies related to security, resource allocation, and service quality. Further, the policy execution engine (706d) executes policies translates policy rules into actionable configurations and enforces compliance across CNFs.
[00103] The capacity monitoring manger (706e) monitors and manages the capacity of resources within the CNF environment to ensure optimal usage and avoid resource shortages. The release management repository (706f) stores and manages software releases, configurations, and versions of CNFs. Further, the release management repository (706f) keeps track of different versions of CNFs.
[00104] The configuration manger and Generic Configuration Tool (GCT) (706g) manages the configuration of CNFs and related infrastructure components. The NFV platform decision analytics unit (706h) analyzes data from a NFV platform to support decision-making and strategic planning.
[00105] The platform NoSQL database (DB) (706i) is used for storing and managing large volumes of unstructured or semi-structured data within the CNF environment. The platform scheduler and Cron Jobs module (706j) manages scheduled tasks and periodic operations within the CNF environment. The VNF backup & upgrade manger (706k) oversees the backup and upgrade processes for Virtual Network Functions (VNFs) within the CNF environment.
[00106] The micro service auditor (706l) monitors and audits microservices to ensure compliance with operational and security standards. The platform operation, administration and maintenance manager (706m) manages the overall operation, administration, and maintenance of the CNF platform.
[00107] The platform resource adapter and utilities module (708) includes a platform external API adaptor and gateway (708a), a generic decoder and indexer (708b), a swarm adaptor (708c), an OpenStack API adaptor (708d) and a NFV gateway (708e).
[00108] The platform external API adaptor and gateway (708a) facilitates communication between the CNF platform and external systems or services by providing an interface for API interactions. The generic decoder and indexer (708b) decodes and indexes various types of data and logs within the CNF environment. The swarm adaptor (708c) facilitates communication between a swarm clusters and the CNF environment, including container deployment, scaling, and management.
[00109] The OpenStack API adaptor (708d) provides an interface for the CNF platform to interact with OpenStack APIs, enabling operations such as provisioning, scaling, and managing virtual resources. The NFV gateway (708e) manages and facilitates communication between NFV (Network Functions Virtualization) components and external networks or services.
[00110] FIG. 8 is a flow diagram (800) illustrating a method to enrich the data of the one or more microservices, in accordance with an embodiment of the present invention.
[00111] At 802, the method includes receiving the notification from the IM to retrieve at least one of: the alarms, the performance counters and the performance metrics of the one or more network functions upon instantiation of the one or more network functions. In an embodiment, the method allows the transceiver (216) to receive the notification from the IM to retrieve at least one of: the alarms, the performance counters and the performance metrics of one or more network functions upon instantiation of the one or more network functions.
[00112] At 804, the method includes retrieving the data pertaining to at least one of: the alarms, the performance counters and the performance metrics from the one or more sources based on receiving the notification from the IM. In an embodiment, the method allows the retrieving unit (218) to retrieve the data pertaining to at least one of: the alarms, the performance counters and the performance metrics from one or more sources based on receiving the notification from the IM.
[00113] At 806, the method includes enriching the one or more microservices with the retrieved data. In an embodiment, the method allows the enrichment unit (220) to enrich the one or more microservices with the retrieved data.
[00114] FIG. 9 illustrates a flow diagram (900) of a method including the steps for gathering the alarm, the counter data, and the performance meters from the inventory and sending the data to related micro-service by the dedicated interface, in accordance with an embodiment of the present invention.
[00115] At 902, the PVIM (406) gets the details of CNF/VNF once instantiation is completed. At 904, the PVIM (406) notifies the EMS (402) to start monitoring and taking alarms, performance counter and performance meters from the CNF/VNF. At 906, the data from the PVIM (406) is sent to the EMS (402) which contains all information needed for CNF and VNF to start taking the alarms and performance data.
[00116] At 908, all the data related to alarms, counter and performance meters are enriched by the EMS (402) to other micro-services via the PVIM (406). At 910, the EMS (402) sends http events (for example) to the concerned micro-services to enrich the data. At 912, the PVIM (406) schedules tasks by which all performance data can be enriched to other micro-services.
[00117] Below is the technical advancement of the present invention:
[00118] The proposed method provides accurate alarm and counter information for healing and scaling purposes. In the proposed method, the interface is configured to provide all start-stop data of VNFs and CNFs to the EMS (402) to start the enrichment of alarms and performance counters and meters. In an example, the proposed method fetches meters from the Ceilometer (602) to track NFVI level metering data. All these data are needed to perform the scaling and healing of CNF/VNF by other respective microservices to take the decision regarding scaling or healing in a time effective manner. Thus, results in improving network performance. The proposed method allows the async event-based implementation to utilize interface efficiently. The proposed method enables fault tolerance for any event failure, this interface works in a high availability mode and if one inventory instance went down during request processing then next available instance will take care of this request.
[00119] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIGS. 1-9) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[00120] Method steps: A person of ordinary skill in the art will readily ascertain that the illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[00121] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS
[00122] Environment - 100
[00123] UEs– 102, 102-1-102-n
[00124] Server - 104
[00125] Communication network – 106
[00126] System – 108
[00127] Processor – 202
[00128] Memory – 204
[00129] User Interface – 206
[00130] CLI-interface - 206a
[00131] GUI-interface - 206b
[00132] Display – 208
[00133] Input device – 210
[00134] Database – 214
[00135] Transceiver– 216
[00136] Retrieving unit – 218
[00137] Enrichment unit – 220
[00138] System - 300
[00139] Primary processors -305
[00140] Memory– 310
[00141] Kernel– 315
[00142] Example system – 400
[00143] EMS – 402
[00144] PVIM cluster – 404
[00145] PVIM – 406
[00146] IM_EMS interface – 408
[00147] System architecture - 600
[00148] Ceilometer – 602
[00149] Gnocchi – 604
[00150] OAM – 606
[00151] EDGE-LB – 608
[00152] FCAPS management module – 610
[00153] Event handling module – 612
[00154] Logging service module – 614
[00155] Meter collection module – 616
[00156] ES-DB client – 618
[00157] Performance manger (PM) – 620
[00158] ES database – 622
[00159] System architecture – 700
[00160] NFV and SDN design function – 702
[00161] VNF lifecycle manger - 702a
[00162] VNF catalog - 702b
[00163] Network service catalog - 702c
[00164] Network slicing and service chaining manger - 702d
[00165] Physical and virtual resource manager - 702e
[00166] CNF lifecycle manger - 702f
[00167] Platform foundation service module - 704
[00168] Microservice elastic load balancer - 704a
[00169] Identity and access manager - 704b
[00170] Command line interface - 704c
[00171] Central logging manger - 704d
[00172] Event routing manger - 704e
[00173] platform core service module – 706
[00174] NFV infrastructure monitoring manager - 706a
[00175] Assurance manager - 706b
[00176] Performance manger - 706c
[00177] Policy execution engine - 706d
[00178] Capacity monitoring manger - 706e
[00179] Release management repository - 706f
[00180] Configuration manger and GCT - 706g
[00181] NFV platform decision analytics - 706h
[00182] Platform NoSQL DB - 706i
[00183] Platform scheduler and cron Jobs module - 706j
[00184] VNF backup & upgrade manger - 706k
[00185] Micro service auditor - 706l
[00186] Platform operation, administration and maintenance manager - 706m
[00187] Platform resource adapter and utilities module – 708
[00188] Platform External API adaptor and gateway - 708a
[00189] Generic decoder and indexer - 708b
[00190] Swarm adaptor 708c
[00191] OpenStack API adaptor - 708d
[00192] NFV gateway - 708e
,CLAIMS:CLAIMS
We Claim:
1. A method to enrich data of one or more microservices, the method comprising the steps of:
receiving, by one or more processors (202), a notification from an Inventory Manager (IM) to retrieve at least one of, alarms, performance counters and performance metrics of one or more network functions upon instantiation of the one or more network functions;
retrieving, by the one or more processors (202), data pertaining to at least one of, the alarms, the performance counters and the performance metrics from one or more sources based on receiving the notification from the IM; and
enriching, by the one or more processors (202), the one or more microservices with the retrieved data.

2. The method as claimed in claim 1, wherein the notification received from the IM includes at least one of, information required to retrieve the data pertaining to at least one of, the alarms, the performance counters and the performance metrics.

3. The method as claimed in claim 1, wherein the one or more sources include at least one of, the one or more network functions, cloud resources, one or more external file locations and performance metering endpoints.

4. The method as claimed in claim 1, wherein the step of, retrieving, the data pertaining to at least one of, the alarms from one or more sources based on receiving the notification from the IM, includes the steps of:
collecting, by the one or more processors (202), the alarms pertaining to at least one of, identifiable or unidentifiable network functions from the one or more sources;
mapping, by the one or more processors (202), the alarm data with the one or more network functions utilizing respective one or more network function identifiers;
identifying, by the one or more processors (202), a status of the alarm data based on scanning an alarm dictionary of the mapped alarms; and
storing, by the one or more processors (202), the alarm data subsequent to identifying the status of the alarm data.

5. The method as claimed in claim 4, wherein the status of the alarm data is based on nature of severity of the alarms, wherein the nature of severity of alarms includes at least one of, critical, major, minor, warning, intermediate and cleared.

6. The method as claimed in claim 1, wherein the step of, retrieving, the data of performance counters and performance metrics from one or more sources based on receiving the notification from the IM, includes the steps of:
retrieving, by the one or more processors (202), data of the performance counters from the one or more sources including at least one of, the one or more external file locations;
retrieving, by the one or more processors (202), the performance metrics from the one or more sources including at least one of, the performance metering endpoints; and
storing, by the one or more processors (202), the retrieved performance counters and the performance metrics in a database (214).

7. The method as claimed in claim 1, wherein the step of, enriching, the one or more microservices with the retrieved data, includes the steps of:
transmitting, by the one or more processors (202), an event request to the IM to schedule tasks to enrich the one or more microservices with the retrieved data, wherein the event request includes information of the retrieved data; and
enabling, by the one or more processors (202), the one or more microservices to determine implementation of at least one of, scale-in or self-heal operation upon enrichment of the one or more microservices.

8. The method as claimed in claim 1, wherein the schedule tasks include at least one of, periodically scheduling tasks to enrich the one or more microservices with the retrieved data.

9. The method as claimed in claim 1, wherein the one or more microservices are enriched with the retrieved data based on an event driven architecture including at least one of, event streams and event sourcing, wherein the event streams are continuous sequences of events produced and consumed in real-time.

10. The method as claimed in claim 1, wherein the one or more processors, establishes a communication channel between the IM and an elementary management system (EMS), wherein the communication channel is an interface.

11. The method as claimed in claim 10, wherein the interface is at least one of, an Inventory Manager_elementary management system (IM_EMS) interface.

12. A system (108) to enrich data of one or more microservices, the system (108) comprising:
a transceiver (216), configured to, receive, a notification from an Inventory Manager (IM) to retrieve at least one of, alarms, performance counters and performance metrics of one or more network functions upon instantiation of the one or more network functions;
a retrieving unit (218), configured to, retrieve, data pertaining to at least one of, the alarms, the performance counters and the performance metrics from one or more sources based on receiving the notification from the IM; and
an enrichment unit (220), configured to, enrich, the one or more microservices with the retrieved data.

13. The system (108) as claimed in claim 12, wherein the notification received from the IM includes at least one of, information required to retrieve the data pertaining to at least one of, the alarms, the performance counters and the performance metrics.

14. The system (108) as claimed in claim 12, wherein the one or more sources include at least one of, the one or more network functions, cloud resources, one or more external file locations and performance metering endpoints.

15. The system (108) as claimed in claim 12, wherein the retrieving unit (218) retrieves, the data pertaining to at least one of, alarms from one or more sources based on receiving the notification from the IM, by:
collecting, alarm data pertaining to at least one of, identifiable or unidentifiable network functions from the one or more sources;
mapping, the alarm data with the one or more network functions utilizing respective one or more network function identifiers;
identifying, a status of the alarm data based on scanning an alarm dictionary of the mapped alarms; and
storing, the alarm data subsequent to identifying the status of the alarm data.

16. The system (108) as claimed in claim 15, wherein the status of the alarm data is based on nature of severity of the alarms, wherein the nature of the severity of alarms includes at least one of, critical, major, minor, warning, intermediate and cleared.

17. The system (108) as claimed in claim 12, wherein the retrieving unit (218), retrieves, data of performance counters and performance metrics from one or more sources based on receiving the notification from the IM, by:
retrieving, data of the performance counters from the one or more sources including at least one of, the one or more external file locations;
retrieving, the performance metrics from the one or more sources including at least one of, the performance metering endpoints; and
storing, the retrieved performance counters and the performance metrics in a database (214).

18. The system (108) as claimed in claim 12, wherein the enriching unit (220), enriches, the one or more microservices with the retrieved data, by:
transmitting, an event request to the IM to schedule tasks to enrich the one or more microservices with the retrieved data, wherein the event request includes information of the retrieved data; and
enabling, the one or more microservices to determine implementation of at least one of, scale-in or self-heal operation upon enrichment of the one or more microservices.

19. The system (108) as claimed in claim 12, wherein the schedule tasks include at least one of, periodically scheduling tasks to enrich the one or more microservices with the retrieved data.

20. The system (108) as claimed in claim 12, wherein the one or more microservices are enriched with the retrieved data based on an event driven architecture including at least one of, event streams and event sourcing, wherein the event streams are continuous sequences of events produced and consumed in real-time.

21. The system (108) as claimed in claim 12, wherein the one or more processors, establishes a communication channel between the IM and an elementary management system (EMS), wherein the communication channel is an interface.

22. The system (108) as claimed in claim 21, wherein the interface is at least one of, an Inventory Manager_elementary management system (IM_EMS) interface.