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
METHOD AND SYSTEM TO MANAGE LIFECYCLE OF NETWORK FUNCTIONS
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, more particularly relates to a system and a method of manage lifecycle of network functions.
BACKGROUND OF THE INVENTION
[0002] With the increase in number of users, a communication network is rapidly evolving to accommodate the surge of request commands and improve user experience. A communication network comprises of many network elements which are configured to operate in specific manners to improve credibility of the communication network. The network incorporates inventories to safe-keep resources and mechanism to efficiently distribute resources to all NFs (Network Functions) in the network so as to process the service requests. Inventory Management (IM) service maintains the virtual inventory and limited physical inventory. It maintains the relation between physical and virtual resources with respect to overlay to manage storage memory allocation. Also, it describes physical and virtual resources in view of different attributes using updates from external micro-service. Thus, data accuracy of the inventory management service is dependent upon the micro-services which create, update, delete these resources and at the same time update these events with IM. Other services can query IM relations, attributes etc. using Query APIs (application programming interface) provided by IM. For capturing information like vendor details, VNF’s and its associated VNF components via request commands like ‘Create’, ‘Read’, and ‘Update’, by means of various APIs exposed by the VNFC service itself. The captured details are also stored by inventory service and can be further used by micro services.
[0003] However, the vender details, data related to VNFC and centralized inventory wherein VNFC data access is only for user and operational purpose. Thus, proper resource inventory management and real time communication with other MS (micro-service) is not possible for VNFC which is purely configured to comply with all create, update, get and delete operations. Any data related to VNF lifecycle and associated vendor in centralized inventory is not easily accessible and available only for user and operational purpose. Thus, initiating certain requests to intervene in the operational phases of a VNF/VNFC so as to solve resource distribution problems, for example, to terminate a VNFC that is not required or that is not working properly is time consuming. There may be issues with resource inventory management due to this.
[0004] Presently, real time communication with other microservice is not available for VNF (virtual network function) which can comply with all create, update, get and delete operations. Hierarchal data representation is also not available. There is no dedicated mechanism available for managing the VNFC (virtual network function components) life cycle details in hierarchical representation. Therefore, for achieving instantiate/terminate/scale functionality in NFV (Network Function Visualization) platform, there is a need of a dedicated mechanism which would be responsible for lifecycle management of VNF instances.
[0005] There is requirement of a micro-service for life-cycle management of VNF/VNFC which is also configured to receive instantiation request from the Network Service Chaining Manager (NSCM) micro service, and then to communicate with inventory for getting VNFC parameters like volume, network and flavor IDs etc. There is also a need for a dedicated interface for such interactions by means of which all the operations at IM can be performed.
[0006] Therefore, there is a need to introduce a system and a method to manage life cycle of a network functions by means of a dedicated interface so that a network can be operated with ease.
SUMMARY OF THE INVENTION
[0007] One or more embodiments of the present disclosure provides a method and system to manage lifecycle of network functions.
[0008] In one aspect of the present invention, the system to manage lifecycle of network functions is disclosed. The system includes a monitoring unit, configured to monitor a plurality of network functions in a network. The system further includes a checking unit, configured to check if there is a requirement for at least one of, a scale-in or a scale-out operation of one or more of the network functions based on monitoring and if determined, there is the requirement for at least one of, the scale-in or the scale out operation of the one or more network functions based on checking, the system further includes a retrieving unit, configured to retrieve from an inventory, data pertaining to one or more parameters of the one or more network functions.
[0009] In an embodiment, the monitoring unit monitors the plurality of network functions, by monitoring, at least one of, design and deployment of the plurality of network functions and traffic load in the network.
[0010] In an embodiment, the scale-in operation includes at least one of, instantiation of the one or more network functions.
[0011] In an embodiment, the scale-out operation includes at least one of, termination of the one or more network functions.
[0012] In an embodiment, the checking unit, checks, if there is the requirement for at least one of, the scale-in or the scale-out operation of the one or more of the network functions, by comparing, a number of requests with a pre-defined threshold, wherein the number of requests handled by each of the plurality of network functions. Thereafter, the checking unit infers, the scale-in operation is required of the one or more network functions when the number of requests handled by the one or more network functions is greater than the pre-defined threshold. Further, the checking unit infers the scale-out operation is required of the one or more network functions when the number of requests handled by the one or more network functions is lesser than the pre-defined threshold.
[0013] In an embodiment, the retrieving unit retrieves from the inventory, data pertaining to the one or more parameters of the one or more network functions, by transmitting, a data retrieval request to the inventory to retrieve the data pertaining to the one or more parameters from the inventory. The data retrieval request includes at least one of, identifier details of the one or more network functions which are required to be scaled-in or scaled-out, and identifier details of the one or more parameters. The retrieving unit, retrieves data pertaining to the one or more parameters of the one or more network functions based on transmitting the data retrieval request to the inventory.
[0014] In an embodiment, the one or more processors communicates with the inventory via a communication channel.
[0015] In an embodiment, the communication channel is an interface between an inventory and a Virtual Network Function (VNF) lifecycle manager.
[0016] In an embodiment, the interface is at least one of, an Inventory Manager Virtual Network Function (IM_VN) interface.
[0017] In an embodiment, the one or more parameters include at least one of, allocated or deallocated resources to the one or more network functions, configuration of the one or more network functions, reserved one or more resources for the one or more network functions when the scale-in operation is required to be performed and unreserved one or more resources for the one or more network functions when the scale-in operation is completed.
[0018] In another aspect of the present invention, a method for managing the lifecycle of network functions is disclosed. The method includes the step of monitoring a plurality of network functions in the network. The method further includes the step of checking if there is a requirement for at least one of, a scale-in or a scale-out operation of one or more of the network functions based on monitoring and if determined, there is the requirement for at least one of, the scale-in or the scale out operation of the one or more network functions based on checking, the method further includes the step of retrieving from an inventory, data pertaining to one or more parameters of the one or more network functions.
[0019] In another aspect of the invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions is disclosed. The computer-readable instructions are executed by a processor, which causes the processor to, monitor a plurality of network functions in a network. The processor is configured to check, if there is a requirement for at least one of, a scale-in or a scale-out operation of one or more of the network functions based on monitoring and if determined there is the requirement for at least one of, the scale-in or the scale out operation of the one or more network functions based on checking, the processor is configured to retrieve, from an inventory, data pertaining to one or more parameters of the one or more network functions.
[0020] 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
[0021] 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.
[0022] FIG. 1 is an exemplary block diagram of an environment to manage lifecycle of network functions, according to one or more embodiments of the present invention;
[0023] FIG. 2 is an exemplary block diagram of a system to manage lifecycle of network functions, according to one or more embodiments of the present invention;
[0024] FIG. 3a is an exemplary representation of an interface in a network environment, FIG. 3b is a block diagram of an architecture implemented in the system of the FIG. 2 to manage lifecycle of network functions, according to one or more embodiments of the present invention;
[0025] FIG. 4 is a signal flow diagram to manage lifecycle of network functions, according to one or more embodiments of the present invention; and
[0026] FIG. 5 is a flowchart of a method to manage the lifecycle of network functions, according to one or more embodiments of the present invention.
[0027] FIG. 6 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] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0029] 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.
[0030] 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.
[0031] 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.
[0032] FIG. 1 illustrates an exemplary block diagram of an environment 100 to manage lifecycle of network functions, according to one or more embodiments of the present disclosure. In this regard, the environment 100 includes a User Equipment (UE) 110, a server 115, a network 105 and a system 120 communicably coupled to each other for managing lifecycle of network functions.
[0033] As per the illustrated embodiment and for the purpose of description and illustration, the UE 110 includes, but not limited to, a first UE 110a, a second UE 110b, and a third UE 110c, and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the UE 110 may include a plurality of UEs as per the requirement. For ease of reference, each of the first UE 110a, the second UE 110b, and the third UE 110c, will hereinafter be collectively and individually referred to as the “User Equipment (UE) 110”.
[0034] In an embodiment, the UE 110 is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as a 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 computing device.
[0035] The environment 100 includes the server 115 accessible via the network 105. The server 115 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 server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors 205 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 embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise side, a defense facility side, or any other facility that provides service.
[0036] The network 105 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 network 105 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0037] The network 105 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 network 105 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.
[0038] The environment 100 further includes the system 120 communicably coupled to the server 115 and the UE 110 via the network 105. The system 120 is configured for managing the lifecycle of network functions. As per one or more embodiments, the system 120 is adapted to be embedded within the server 115 or embedded as an individual entity.
[0039] Operational and construction features of the system 120 will be explained in detail with respect to the following figures.
[0040] FIG. 2 is an exemplary block diagram of the system 120 for managing the lifecycle of network functions, according to one or more embodiments of the present invention.
[0041] As per the illustrated embodiment, the system 120 includes one or more processors 205, a memory 210, a user interface 215, and a database 220. For the purpose of description and explanation, the description will be explained with respect to one processor 205 and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the system 120 may include more than one processor 205 as per the requirement of the network 105. The one or more processors 205, hereinafter referred to as the processor 205 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.
[0042] As per the illustrated embodiment, the processor 205 is configured to fetch and execute computer-readable instructions stored in the memory 210. The memory 210 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 210 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.
[0043] In an embodiment, the user interface 215 includes a variety of interfaces, for example, interfaces for a graphical user interface, a web user interface, a Command Line Interface (CLI), and the like. The user interface 215 facilitates communication of the system 120. In one embodiment, the user interface 215 provides a communication pathway for one or more components of the system 120. Examples of such components include, but are not limited to, the UE 110 and the database 220.
[0044] The database 220 is one of, but not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 220 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0045] In order for the system 120 to manage lifecycle of network functions, the processor 205 includes one or more modules. In one embodiment, the one or more modules/units includes, but not limited to, a monitoring unit 225, a checking unit 230, and a retrieving unit 235 communicably coupled to each other for managing the lifecycle of network functions.
[0046] In one embodiment, the one or more modules includes, but not limited to, a monitoring unit 225, a checking unit 230, and a retrieving unit 235 can be used in combination or interchangeably for managing the lifecycle of network functions.
[0047] The monitoring unit 225, the checking unit 230, and the retrieving unit 235, 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 205. 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 205 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system 120 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 120 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.
[0048] In an embodiment, the monitoring unit 225 is configured to monitor a plurality of network functions in the network 105. The monitoring unit 225 monitors the plurality of network functions by monitoring, at least one of, design and deployment of the plurality of network functions and traffic load in the network 105. The plurality of network functions can be deployed as virtualized or containerized instances which includes, but not limited to, a Virtual Network Functions (VNFs) or/and a Container Network Functions (CNFs).
[0049] The design and deployment of network functions refer to two essential stages in the lifecycle of Virtual Network Functions (VNFs) and Container Network Functions (CNFs). The design phase focuses on creating the architecture and structure of the network functions, specifying the software components, resource requirements, data handling processes, and interactions with other network components. The design phase also includes, but not limited to, defining performance goals, scaling policies, and security measures to ensure that the network function operates efficiently once implemented. Deployment on the other hand, involves the actual process of installing, configuring, and launching the network functions into a live environment, either on virtual machines for VNFs or within containers for CNFs. During deployment, the network functions are configured according to the design specifications, allocated the necessary resources, and integrated with existing network services to handle real traffic and workloads. Both design and deployment are critical for ensuring that network functions meet operational objectives and perform optimally within the network infrastructure.
[0050] In an embodiment, the VNFs are software implementations of plurality of the network functions, run on a virtual machines (VMs) within a cloud or data center environment. By virtualizing traditional network hardware like, but not limited to, routers, firewalls, or load balancers, VNFs allow for more flexible and efficient use of resources. The VNFs include, but not limited to, virtual firewall and virtual evolved packed core. The CNFs are similar to VNFs but are deployed as containers rather than the VMs. The CNFs are lightweight, isolated environments which package the software and its dependencies, enabling faster startup times and more efficient resource usage compared to VMs. The CNFs are particularly suited for microservices-based architectures, which are common in modern cloud-native applications.
[0051] Monitoring the design and deployment of the plurality of network functions include monitoring design aspects of the network functions, which involves how the plurality of the network function is architected, including, but not limited to, configuration, interconnections, and resource allocations of the plurality of the network functions. Monitoring the deployment of the plurality of network functions refers to monitoring the actual instantiation of the plurality of network functions within the network 105, which could involve multiple data centers or edge locations.
[0052] In an embodiment, monitoring the traffic load refers to monitoring the amount of data being processed by the plurality of the network functions. Traffic load is essential for, but not limited to, managing network performance, scaling resources, and ensuring Quality of Service (QoS). The traffic load can vary based on one of, but not limited to, user demand, time of day, and specific applications (for example, streaming, Internet of Things (IoT)).
[0053] The checking unit 230 is configured to check, if there is a requirement for at least one of, a scale-in or a scale-out operation of the one or more of the network functions based on monitoring.
[0054] In an embodiment, the scale-in operation refers to reducing the one or more resources or number of instances allocated to the one or more network functions when the demand decreases. The scale-in operation plays a crucial role in ensuring efficient resource management and optimizing network performance.
[0055] In an embodiment, the scale-in operation includes at least one of, instantiation of the one or more network functions. The instantiation of one or more network functions during the scale-in operation plays a specific role in certain scenarios, particularly in the cloud-based infrastructures. The instantiation during the scale-in operation may include, but not limited to, rebalancing resources by creating new instances of optimized the one or more network functions, replacing underperforming functions with more efficient ones, adapting resource allocation to meet reduced demands, migrating to updated instances for better performance, decommissioning and instantiating functions in different locations or/and configurations to align with current network 105 requirements.
[0056] In an embodiment, the scale-out operation includes at least one of, termination of the one or more network functions. The termination of one or more network functions during the scale-out operation may be necessary to ensure that the network 105 remains flexible, cost-efficient, and able to meet varying levels of demand. The termination of one or more network functions during the scale-out operation is aimed at optimizing resource allocation, maintaining performance, and ensuring that critical services can be scaled out as needed. The scale-out operation approach enables the network 105 to remain agile, capable of meeting the demands of diverse applications, and efficient in use of one or more resources.
[0057] In an embodiment, the checking unit 230 checks if there is the requirement for at least one of, the scale-in or the scale-out operation of the one or more of the network functions by continuously monitoring number of requests being handled by one or more network functions in the system 120. The one or more network functions could be part of the larger set of VNFs (Virtual Network Functions) operating within the network environment, where they handle various types of data traffic and service requests.
[0058] The checking unit 225 compares the number of requests handled by each of the plurality of network functions with a pre-defined threshold. The checking unit 225 inferring the scale-in operation is required of the one or more network functions when the number of requests handled by the one or more network functions is greater than the pre-defined threshold. The inferring is the process of making decisions (conclusions or determining outcomes) based on available information, patterns, or evidence, rather than direct or explicit statements. The inferring system analyzes data patterns, such as, but not limited to, the number of requests handled by network functions, and determines that the specific action, like the scale-in or scale-out operation when necessary. Example of inferring includes, but not limited to, handling excess requests, and identifying underutilized resources. The pre-defined threshold refers to a specific value or limit set for the number of requests that a particular network function can handle efficiently. The pre-defined threshold is used as a reference point to determine whether a network function, such as, but not limited to, a Virtual Network Function (VNF) or a Container Network Function (CNF), is operating within its optimal capacity or if scaling operations are required. The examples of pre-defined threshold are some of, but not limited to, VNF for video streaming, CNF for packet core management, and VNF for network slicing. Further, the checking unit 225 infers the scale-out operation is required of the one or more network functions when the number of requests handled by the one or more network functions is lesser than the pre-defined threshold. In an embodiment, each of the network function has an associated pre-defined threshold for the number of requests that the respective network function can efficiently handle. For example, for VNFs theta process video streaming, the pre-defined threshold may be 10,000 concurrent stream. The checking unit 230 compares the actual number of requests handled by the VNF with this pre-defined threshold. If the number of requests handled by the VNF is greater than the pre-defined threshold, the checking unit 230 infers that the scale-in operation is required. Similarly, if the number of requests handled by the VNF is lesser than the pre-defined threshold, the checking unit 230 infers that the scale-out operation is required.
[0059] The scale in operation may include deallocating resources, terminate certain instances of VNFs, or reconfigure existing instances to manage the load more effectively. The scale-out operation may include allocating additional resources, instantiating new instances of VNFs, or enhance the capacity of existing ones to handle the anticipated increase in demand.
[0060] Further, the checking unit 230 continues to monitor the one or more network function to ensure the system is performing is functioning efficiently and any further deviations are noticed with respect to the pre-defined threshold, the checking unit 230 will prompt a new evaluation cycle, ensuring that the network remains responsive to changing demand conditions.
[0061] If determined, there is the requirement for at least one of, the scale-in or the scale out operation of the one or more network functions based on checking, the retrieving unit 235 is configured to retrieve from an inventory, data pertaining to one or more parameters of the one or more network functions. The retrieving unit 235 retrieves from the inventory, data pertaining to the one or more parameters of the one or more network functions by transmitting a data retrieval request to the inventory to retrieve the data pertaining to the one or more parameters.
[0062] In an embodiment, the data retrieval request includes at least one of, identifier details of the one or more network functions which are required to be scaled-in or scaled-out, and identifier details of the one or more parameters. Thereafter, the retrieving unit 235 retrieves data pertaining to the one or more parameters of the one or more network functions based on transmitting the data retrieval request.
[0063] In an embodiment, the identifier details are unique identifiers which help the system 120 to recognize and differentiate between various one or more network functions and the associated parameters. The identifier details include, but not limited to, IDs, names, tags, or other forms of identification. The one or more parameters refers to the specific characteristics or metrics of the one or more network functions that are important for the operation and management. The parameters include at least one of, but not limited to, resource allocation (example, CPU, memory), performance metrics (examples, latency, throughput), configuration settings.
[0064] In one embodiment, the parameters include aspects such as allocated and deallocated resources for network functions. When the network function needs more capacity, additional resources are allocated to the parameters. For example, if the VNF experiences higher traffic, extra CPU and memory resources are assigned to maintain performance. Conversely, when the demand decreases, and the network function no longer requires the previously allocated resources, the resources are deallocated and freed up and the process optimizes resource utilization by minimizing waste and making resources available for other network functions.
[0065] For example, if the system 120 requires to scale out the VNF which manages the IoT traffic due to increased device connections, the scale-out operation will issue the data retrieval request to gather current resource usage and performance metrics for the VNF. The process involves requesting necessary data from the inventory, which helps in making informed decisions about network function management, especially during the scale-in or scale-out operations. The inventory provides data related to CPU, memory, and bandwidth usage, among other parameters. The system 120 uses the data provided by the inventory to determine how many additional VNF instances are required and how to allocate resources for optimal performance.
[0066] In an embodiment, the configuration of the network functions involves reserving one or more resources when the scale-in operation is required. After the scale-in operation is completed, the previously reserved one or more resources are released. The approach ensures that one or more resources are appropriately allocated during scaling operations and efficiently released once the scale-in operation is completed. Reserving one or more resources for the network function prior to the scale-in operation involves setting aside the resources to facilitate the smooth reduction in capacity or instance count. Conversely, un-reserving the one or more resources after the scale-in operation involves releasing the one or more resources once the scale-in operation is completed and the network function has been reconfigured.
[0067] FIG. 3a is an exemplary representation of an interface in a network environment. FIG.3b is a block diagram of an architecture of the system of FIG. 2 to manage lifecycle of network functions utilizing an Inventory Manager (IM)_Virtual Network (VN) interface, according to one or more embodiments of the present invention.
[0068] The architecture 300 includes a VNF lifecycle manager 305, a PVIM 310, the IM_VN interface 315, and the database 220.
[0069] As shown in FIG. 3a, a communication channel is established Lifecycle Manager 305. The communication channel is an interface. In an embodiment, the interface is at least one of, an Inventory Manager Virtual Network Function (IM_VN) interface 315. The interface 315 is configured to send and receive data between the PVIM 310 and the VNF lifecycle Manager 305. The PVIM 310 is responsible for managing the virtual infrastructure, handling resource allocation, scaling operations, and interacting with the VNF lifecycle manager 305. The VNF lifecycle manager 305 manages the lifecycle of VNFs, handling the creation, updating, and deletion. The VNF lifecycle manager 305 also monitors the status and performance of VNFs, which reports to the PVIM 310. The VNF lifecycle manager 305 is used to transmit and receive the data between the UE110 and the PVIM 310 for resource allocation or deallocation based on the VNFs requirements. The UE 110 represents the user device that indirectly benefits from the one or more operations of the VNFs deployed and managed by the PVIM 310 and the VNF lifecycle manager 305 provides network services to the UE 110. The interaction between the PVIM 310 and the VNF lifecycle manager 305 ensures that the VNFs are efficiently managed, maintaining optimal performance and service availability for the UE 110.
[0070] As shown in the FIG. 3b, the VNF lifecycle manager 305 is responsible for managing the lifecycle of VNFs, including monitoring the status. The monitoring is performed by the VNF lifecycle manager 405 and informs the PVIM 310 about current status of the VNFs. The VNF lifecycle manager performs monitoring of design, deployment, and traffic load, and provides the information to the PVIM 310. The VNF lifecycle manager 305 handles the creation, updating, and deletion of VNFs, which are essential elements in network virtualization. The request may include operations like, but not limited to, setting up the new VNF, updating existing VNFs, or retrieving information on the specific VNF. The VNF lifecycle manager 305 provides status updates and performance metrics to the PVIM 310, for further analysis and decision-making. Thereafter the VNF lifecycle manager 305 accepts and processes requests from the PVIM 310 for various operations, including creating, updating, or retrieving information about VNFs. The VNF lifecycle manager communicates operational results, such as, but not limited to, successful creation or updates, and handles any issues or errors reported by the PVIM 310.
[0071] The VNF lifecycle manager 305 sends HTTP requests to the PVIM 310 to handle resource allocation for deploying VNFs or deallocation of resources when VNFs are terminated and informs PVIM 310 of any changes in resource allocation to keep PVIM 310 inventory accurate. The VNF lifecycle manager 305 requests details about VNF flavors or images from the PVIM 310 for proper VNF deployment. The VNF lifecycle manager 305 retrieves information about VNFs and VNFCs to manage the lifecycle effectively. The VNF lifecycle manager 305 notifies the PVIM 310 to release resources that are no longer needed.
[0072] The PVIM 310 is the specific manager that interacts with the VNF lifecycle manager 305. The PVIM 310 handles scaling operations, which may involve initiating or modifying VNFs. The PVIM 310 receives requests from the VNF lifecycle manager 305 for various operations, including creating, updating, and retrieving details of VNFs. The PVIM 310 processes requests to scale-out by terminating or adjusting VNFs. The PVIM 310 evaluates request counts against predefined thresholds to determine whether scale-in or scale-out operations are necessary. Based on the evaluation, the PVIM 310 initiates scaling operations either scaling-in by instantiating new VNFs or scaling-out by terminating existing VNFs. Further, the PVIM 310 interacts with database 220 to retrieve or update information about VNFs. The PVIM 310 includes accessing data relevant to VNF parameters, configurations, and status.
[0073] The database 220 interaction involves retrieving and updating parameter data as required for scaling operations. The parameters include, but not limited to resources allocated or deallocated and network function configuration. The database 220 stores the parameters. The PVIM 310 accesses the information to perform scaling operations. The database 220 contains the necessary records and information for the VNFs. The database 220 is connected to the VNF lifecycle manager 305 through the PVIM 310. The VNF lifecycle manager 305 relies on the PVIM 310 to interact with the database 220 for retrieving and updating information about the VNFs. The PVIM 310 queries the database 220 to obtain necessary data, which is used by the VNF lifecycle manager 305 to manage the lifecycle of VNFs effectively.
[0074] FIG. 4 is a signal flow diagram for managing the lifecycle of network functions, according to one or more embodiments of the present invention.
[0075] At step 405, the VNF lifecycle manager 305 sends the request to the PVIM 310 to create, update, scaling, and termination to initiate lifecycle operations for VNFs. The VNF lifecycle manager 305 sends HTTP requests to PVIM 310 to handle resource allocation for deploying VNFs or deallocation when VNFs are terminated and informs the PVIM 310 of any changes in resource allocation to keep the PVIM 310 inventory accurate. The VNF lifecycle manager 305 requests details about VNF flavors or images from the PVIM 310 for proper VNF deployment and also notifies the PVIM 310 to release one or more resources that are no longer needed.
[0076] At step 410, upon receiving the request from the VNF lifecycle manager 305, the PVIM 310 process the lifecycle management requests. The PVIM 410 checks the metrics and thresholds to decide if scaling operation is required. The PVIM 310 determines the need for scaling operations based on VNF performance and load. Further the PVIM 310 sends the data retrieval request to the database 220 for to retrieve information related to VNF parameters.
[0077] At step 415, upon receiving the data retrieval request from the PVIM 310, the database 220 obtains necessary data for executing scaling operations and provides the data to PVIM 310.
[0078] At step 420, once the data is retrieved from the database 220, the PVIM 310 initiates the scaling operation for VNFs based on the evaluation to adjust the number of VNFs as required.
[0079] At step 425, the PVIM 310 responds to the VNF lifecycle manager 305 about the result of the scaling and lifecycle operation.
[0080] FIG. 5 is a flow diagram of a method 500 to manage lifecycle of network functions, according to one or more embodiments of the present invention. For the purpose of description, the method 500 is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0081] At step 505, the method 500 includes the step of monitoring the plurality of network functions in the network 105. Further monitoring the plurality of network functions includes the step of monitoring at least one of, design and deployment of the plurality of network functions and traffic load in the network 105.
[0082] At step 510, the method 500 includes the step of checking whether there is the requirement for at least one of, the scale-in or the scale-out operation of one or more of the network functions based on monitoring results. Upon determining that the scale-in or scale-out operation is needed, the method proceeds with executing the appropriate scaling action. The scale-in operation includes at least one of, instantiation of the one or more network functions. The scale-out operation includes at least one of, termination of the one or more network functions. The step of checking involves comparing the number of requests handled by each network function with the predefined threshold to determine if the scale-in or scale-out operation is required. The scale-in operation is required when the number of requests exceed the pre-defined threshold, and the scale-out is required when the number of requests are less than the pre-defined threshold.
[0083] At step 515, the method 500 includes the step of retrieving from an inventory, data pertaining to one or more parameters of the one or more network functions. The step of retrieving data from the inventory involves transmitting the data retrieval request that includes such as but not limited to, identifier details of the network functions to be scaled and the relevant parameters. The data retrieval request retrieves the data related to parameters such as allocated or deallocated resources, the configuration of the network functions, and reserved or unreserved resources during scale-in operations.
[0084] FIG. 6 illustrates an architecture framework 600 (e.g., MANO architecture framework), in which the present invention can be implemented, in accordance with an embodiment of the present invention. The architecture framework 600 includes the user interface 215, a Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) design function module 605, a platform foundation service module 610, a platform core service module 615, and a platform resource adapter and utilities module 620.
[0085] The NFV and SDN design function module 605 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 610 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 610 provides the essential capabilities and resources required for the CNF environment to function effectively.
[0086] The platform core service module 615 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 620 refer 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 620 plays a crucial role in integrating CNFs with underlying infrastructure and services, providing the necessary support for efficient operation, resource utilization, and interoperability.
[0087] The NFV and SDN design function module 610 includes a VNF lifecycle manger 605a, a VNF catalog 605b, a network service catalog 605c, a network slicing and service chaining manger (605d), a physical and virtual resource manager 605e, and a CNF lifecycle manager 605f.
[0088] The VNF lifecycle manager 605a is responsible for managing the entire lifecycle of Virtual Network Functions (VNFs). The VNF lifecycle manager 605a ensures that VNFs or CNFs are deployed, configured, monitored, scaled, and eventually decommissioned effectively. The VNF catalog 605b (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 605b 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 605c 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 605c serves as a central resource for defining, deploying, and managing these services within a containerized network environment.
[0089] The network slicing and service chaining manger 605d 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 605e 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 605e ensures that the necessary resources are allocated efficiently and effectively to meet the performance, availability, and scalability requirements of containerized network functions.
[0090] Further, the CNF lifecycle manager 605f 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 605f ensures that the CNFs are efficiently deployed, monitored, scaled, updated, and removed, facilitating the smooth operation of network services in a containerized environment.
[0091] The platform foundation service module 610 includes a microservice elastic load balancer 610a, an identity and access manager 610b, a command line interface 610c, a central logging manger 610d and an event routing manger 610e.
[0092] The microservice elastic load balancer 610a 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 610b is a critical component responsible for managing and securing access to containerized network functions and their resources. The identity and access manager 610b 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.
[0093] The central logging manger 610d 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 manager 610e 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 610e 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.
[0094] The platform core service module 615 includes an NFV infrastructure monitoring manager 615a, an assurance manager 615b, a performance manger 615c, a policy execution engine 615d, a capacity monitoring manger 615e,a release management repository 615f, a configuration manger and GCT (615g), a NFV platform decision analytics unit 615h, a platform NoSQL DB 615i, a platform scheduler and Cron Jobs module 615j, a VNF backup & upgrade manger 615k, a micro service auditor 615l, and a platform operation, administration and maintenance manager 615m.
[0095] The NFV infrastructure monitoring manager 615a monitors the underlying infrastructure of NFV environments, including computing, storage, and network resources. The NFV infrastructure monitoring manager 615a provides real-time visibility into resource health, performance, and utilization. Further, the NFV infrastructure monitoring manager 615a detects and alerts infrastructure issues. Further, the NFV infrastructure monitoring manager (615a) integrates with monitoring tools to ensure reliable operation of CNFs.
[0096] The assurance manager 615b manages the quality and reliability of network services by ensuring compliance with service level agreements (SLAs) and operational standards. The performance manger 615c optimizes the performance of CNFs by tracking and analyzing key performance indicators (KPIs). The policy execution engine 615d enforces and applies policies within the CNF environment to manage operations and access. Further, the policy execution engine 615d executes policies related to security, resource allocation, and service quality. Further, the policy execution engine (615d) executes policies translates policy rules into actionable configurations and enforces compliance across CNFs.
[0097] The capacity monitoring manager 615e monitors and manages the capacity of resources within the CNF environment to ensure optimal usage and avoid resource shortages. The release management repository 615f stores and manages software releases, configurations, and versions of CNFs. Further, the release management repository 615f keeps track of different versions of CNFs.
[0098] The configuration manager and Generic Configuration Tool (GCT) 615g manages the configuration of CNFs and related infrastructure components. The NFV platform decision analytics unit 615h analyzes data from a NFV platform to support decision-making and strategic planning.
[0099] The platform NoSQL database (DB) 615i 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 615j manages scheduled tasks and periodic operations within the CNF environment. The VNF backup & upgrade manger 615k oversees the backup and upgrade processes for Virtual Network Functions (VNFs) within the CNF environment.
[00100] The micro service auditor 615l monitors and audits microservices to ensure compliance with operational and security standards. The platform operation, administration and maintenance manager 615m manages the overall operation, administration, and maintenance of the CNF platform.
[00101] The platform resource adapter and utilities module 620 includes a platform external API adaptor and gateway 620a, a generic decoder and indexer 620b, a swarm adaptor 620c, an openstack API adaptor 620 and a NFV gateway 620e.
[00102] The platform external API adaptor and gateway 620a facilitates communication between the CNF platform and external systems or services by providing an interface for API interactions. The generic decoder and indexer (620b) decodes and indexes various types of data and logs within the CNF environment. The swarm adaptor (620c) facilitates communication between a swarm clusters and the CNF environment, including container deployment, scaling, and management.
[00103] The openstack API adaptor 620d 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 620e manages and facilitates communication between NFV (Network Functions Virtualization) components and external networks or services.
[00104] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 205. The processor 205 is configured to monitor the plurality of network functions in the network 105. The processor 205 is further configured to check, if there is the requirement for at least one of, the scale-in or the scale-out operation of one or more of the network functions based on monitoring and if determined there is the requirement for at least one of, the scale-in or the scale out operation of the one or more network functions based on checking. The processor 205 is further configured to retrieve from the inventory, data pertaining to one or more parameters of the one or more network functions.
[00105] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-5) 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.
[00106] The present disclosure includes technical advancement offers a unified solution for managing VNFs and CNFs, featuring real-time scaling based on performance metrics, enhanced resource management with dynamic reservation. The invention gives detailed monitoring for optimal network performance, efficient data retrieval, automated lifecycle management, seamless interaction between VNF lifecycle manager and the physical and virtual infrastructure. The invention offers anomaly detection and adaptation for stability, and versatile database integration for flexible storage.
[00107] The present invention offers multiple advantages offers a unified solution for managing VNFs and CNFs, featuring real-time resource scaling based on performance metrics, enhanced and responsive resource management, detailed monitoring for precise scaling, efficient data retrieval. The invention gives anomaly detection and adaptation for stability, and versatile database integration for flexible storage.
[00108] 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
[00109] Environment- 100
[00110] User Equipment (UE)- 110
[00111] Server- 115
[00112] Network- 105
[00113] System -120
[00114] Processor- 205
[00115] Memory- 210
[00116] User interface- 215
[00117] Database - 220
[00118] Monitoring unit - 225
[00119] Checking unit - 230
[00120] Retrieving unit - 235
[00121] VNF lifecycle manager – 305
[00122] PVIM - 310
[00123] IM_VN - 315
[00124] System architecture – 600
[00125] NFV and SDN design function – 605
[00126] VNF lifecycle manger - 605a
[00127] VNF catalog - 605b
[00128] Network service catalog - 605c
[00129] Network slicing and service chaining manger - 605d
[00130] Physical and virtual resource manager - 605e
[00131] CNF lifecycle manger - 605f
[00132] Platform foundation service module - 610
[00133] Microservice elastic load balancer - 610a
[00134] Identity and access manager - 610b
[00135] Command line interface - 610c
[00136] Central logging manger - 610d
[00137] Event routing manger - 610e
[00138] Platform core service module – 615
[00139] NFV infrastructure monitoring manager - 615a
[00140] Assurance manager - 615b
[00141] Performance manger - 615c
[00142] Policy execution engine - 615d
[00143] Capacity monitoring manger - 615e
[00144] Release management repository - 615f
[00145] Configuration manger and GCT - 615g
[00146] NFV platform decision analytics - 615h
[00147] Platform NoSQL DB - 615i
[00148] Platform scheduler and cron Jobs module - 615j
[00149] VNF backup & upgrade manger - 615k
[00150] Micro service auditor - 615l
[00151] Platform operation, administration and maintenance manager - 615m
[00152] Platform resource adapter and utilities module – 620
[00153] Platform External API adaptor and gateway - 620a
[00154] Generic decoder and indexer - 620b
[00155] Swarm adaptor 620c
[00156] OpenStack API adaptor - 620d
[00157] NFV gateway - 620e
,CLAIMS:CLAIMS
We Claim:
1. A method (500) to manage lifecycle of network functions, the method (500) comprising the steps of:
monitoring, by one or more processors (205), a plurality of network functions in a network;
checking, by the one or more processors (205), if there is a requirement for at least one of, a scale-in or a scale-out operation of one or more of the network functions based on monitoring; and
if determined, there is the requirement for at least one of, the scale-in or the scale out operation of the one or more network functions based on checking, retrieving, by the one or more processors (205), from an inventory, data pertaining to one or more parameters of the one or more network functions.

2. The method (500) as claimed in claim 1, wherein the step of, monitoring a plurality of network functions, includes the step of:
monitoring, by the one or more processors (205), at least one of, design and deployment of the plurality of network functions and traffic load in the network.

3. The method (500) as claimed in claim 1, wherein the scale-in operation includes at least one of, instantiation of the one or more network functions.

4. The method (500) as claimed in claim 1, wherein the scale-out operation includes at least one of, termination of the one or more network functions.

5. The method (500) as claimed in claim 1, wherein the step of, checking, if there is a requirement for at least one of, a scale-in or a scale-out operation of one or more of the network functions based on monitoring, includes the steps of:

comparing, by the one or more processors (205), a number of requests with a pre-defined threshold, wherein the number of requests handled by each of the plurality of network functions;
inferring, by the one or more processors (205), the scale-in operation is required of the one or more network functions when the number of requests handled by the one or more network functions is greater than the pre-defined threshold; and
inferring, by the one or more processors (205), the scale-out operation is required of the one or more network functions when the number of requests handled by the one or more network functions is lesser than the pre-defined threshold.

6. The method(500) as claimed in claim 1, wherein the step of, retrieving, from an inventory, data pertaining to one or more parameters of the one or more network functions, includes the step of:
transmitting, by the one or more processors (205), a data retrieval request to the inventory to retrieve the data pertaining to the one or more parameters from the inventory, wherein the data retrieval request includes at least one of, identifier details of the one or more network functions which are required to be scaled-in or scaled-out, and identifier details of the one or more parameters; and
retrieving, by the one or more processors (205), data pertaining to the one or more parameters of the one or more network functions based on transmitting the data retrieval request to the inventory.

7. The method (500) as claimed in claim 1, wherein the one or more parameters include at least one of, allocated or deallocated resources to the one or more network functions, flavor of the one or more network functions, reserved one or more resources for the one or more network functions when the scale-in operation is required to be performed and unreserved one or more resources for the one or more network functions when the scale-in operation is completed.

8. The method (500) as claimed in claim 1, wherein the one or more processors (205) communicates with the inventory via a communication channel.

9. The method (500) as claimed in claim 8, wherein the communication channel is an interface between an inventory and a Virtual Network Function (VNF) lifecycle manager.

10. The method as claimed in claim 9, wherein the interface is at least one of, an Inventory Manager Virtual Network Function (IM_VN) interface.

11. A system (120) to manage lifecycle of network functions, the system (120) comprising:
a monitoring unit (225), configured to, monitor, a plurality of network functions in a network;
a checking unit (230), configured to, check, if there is a requirement for at least one of, a scale-in or a scale-out operation of one or more of the network functions based on monitoring; and
if determined, there is the requirement for at least one of, the scale-in or the scale out operation of the one or more network functions based on checking, a retrieving unit (235), configured to, retrieve, from an inventory, data pertaining to one or more parameters of the one or more network functions.

12. The system (120) as claimed in claim 11, wherein the monitoring unit (225), monitors the plurality of network functions, by:
monitoring, at least one of, design and deployment of the plurality of network functions and traffic load in the network.

13. The system (120) as claimed in claim 11, wherein the scale-in operation includes at least one of, instantiation of the one or more network functions.

14. The system (120) as claimed in claim 11, wherein the scale-out operation includes at least one of, termination of the one or more network functions.

15. The system (120) as claimed in claim 11, wherein the checking unit (230), checks, if there is the requirement for at least one of, the scale-in or the scale-out operation of the one or more of the network functions, by:
comparing, a number of requests with a pre-defined threshold, wherein the number of requests handled by each of the plurality of network functions;
inferring, the scale-in operation is required of the one or more network functions when the number of requests handled by the one or more network functions is greater than the pre-defined threshold; and
inferring, the scale-out operation is required of the one or more network functions when the number of requests handled by the one or more network functions is lesser than the pre-defined threshold.

16. The system (120) as claimed in claim 11, wherein the retrieving unit (225), retrieves, from the inventory, data pertaining to the one or more parameters of the one or more network functions, by:
transmitting, a data retrieval request to the inventory to retrieve the data pertaining to the one or more parameters from the inventory, wherein the data retrieval request includes at least one of, identifier details of the one or more network functions which are required to be scaled-in or scaled-out, and identifier details of the one or more parameters; and
retrieving, by the one or more processors (205), data pertaining to the one or more parameters of the one or more network functions based on transmitting the data retrieval request to the inventory.

17. The system (120) as claimed in claim 11, wherein the system communicates with the inventory via a communication channel.

18. The system (120) as claimed in claim 17, wherein the communication channel is an interface between an inventory and a Virtual Network Function (VNF) lifecycle manager.

19. The system as claimed in claim 18, wherein the interface is at least one of, an Inventory Manager Virtual Network Function (IM_VN) interface.

20. The system (120) as claimed in claim 11, wherein the one or more parameters include at least one of, allocated or deallocated resources to the one or more network functions, flavor of the one or more network functions, reserved one or more resources for the one or more network functions when the scale-in operation is required to be performed and unreserved one or more resources for the one or more network functions when the scale-in operation is completed.