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 FOR MANAGING COMMUNICATION BETWEEN EXTERNAL SYSTEMS AND MANO FRAMEWORKS

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 invention and the manner in which it is to be performed.

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

TECHNICAL FIELD
[0002] The present disclosure relates generally to event routing in wireless communication systems. More particularly, the present disclosure relates to providing an interface for managing communication between external systems and a Management and Orchestration (MANO) framework for resource provision.

DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression ‘Management and Orchestration (MANO) framework’ used hereinafter in the specification refers to a framework that manages and orchestrates virtualized network functions and resources in a Network Functions Virtualization (NFV) environment.
[0005] The expression ‘Event Routing Manager (ERM)’ used hereinafter in the specification refers to an intermediary component that facilitates communication between external systems and the MANO framework, routing service requests and responses of network slice allocations and resources allocation and management.
[0006] The expression ‘Network Slice Management Platform (NSMP)’ used hereinafter in the specification refers to a system responsible for creating, configuring, monitoring, and managing network slices and resources dynamically in a virtualized network environment.
[0007] The expression ‘Support Ticket System (STS)’ used hereinafter in the specification refers to a system that receives data from customers (e.g., an end-user or a subscriber) for any issue.
[0008] The expression ‘Subscriber Support System (SSS)’ used hereinafter in the specification refers to a system that allows subscribers or service users to manage their accounts, make payments, update information, upgrade subscriptions, and provision and access resources without a need for direct interaction with a customer service.
[0009] The expression ‘Performance Manager (PM)’ used hereinafter in the specification refers to a system that is configured to monitor application performance using a set of performance counters. The set of performance counters tracks various metrics related to the application behavior and resource utilization.
[0010] The expression ‘Network Management System (NMS)’ used hereinafter in the specification refers to a system responsible for the centralized management, monitoring, and control of the infrastructure of a network (e.g., a Fifth Generation (5G) network). The NMS provides a comprehensive set of tools and features for network operators (or network administrators) to manage and optimize network resources, including routers, switches, servers, and other network devices.
[0011] The expression ‘Container Network Infrastructure Monitoring System (CNIS)’ used hereinafter in the specification refers to a system configured to collect and monitor the resource utilization of containers and containerized applications.
[0012] The expression ‘Network Functions Virtualization (NFV)’ used hereinafter in the specification refers to a network architecture concept that uses virtualization technologies to manage core networking functions via software rather than hardware.
[0013] The expression ‘Virtualized Network Function (VNF)’ used hereinafter in the specification refers to a software implementation of a network function that runs on an NFV infrastructure and can be deployed on a virtual machine.
[0014] The expression ‘Orchestrator’ used hereinafter in the specification refers to a component of the MANO framework responsible for the orchestration and lifecycle management of physical and software resources.
[0015] The expression ‘Container Network Function (CNF) manager’ used hereinafter in the specification refers to a network function designed and implemented for a cloud-native environment, packaged as a container, and configured to determine the lifecycle of CNF instances.
[0016] The expression ‘Virtualized Infrastructure Manager (VIM)’ used hereinafter in the specification refers to a component of the MANO framework responsible for controlling and managing the NFV infrastructure computation, storage, and resources (i.e., network resources).
[0017] The expression ‘NFV Infrastructure (NFVI)’ used hereinafter in the specification refers to a totality of hardware and software components that build an environment in which VNFs are deployed, managed, and executed.
[0018] The expression ‘event’ used hereinafter in the specification refers to a specific action that can trigger a network element or a system to take a particular action. In an example, the event may include service requests, network traffic, system configuration changes, security incidents, and the like.
[0019] These definitions are in addition to those expressed in the art.

BACKGROUND
[0020] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0021] In a realm of Network Function Virtualization (NFV) and Management and Orchestration (MANO) frameworks, integrating external systems into the MANO framework environment is crucial for achieving optimal performance, scalability, and functionality. Examples of the external systems may include a Network Slicing Management Platform (NSMP), a Support Ticket System (STS), a Subscriber Support System (SSS), a Performance Manager (PM), a Network Management System (NMS), and the like. In telecommunications, the MANO frameworks are designed to orchestrate and manage network resources and services effectively by leveraging Virtualized Network Functions (VNFs) and infrastructure. However, when the external systems are not inherently integrated into the MANO framework, several challenges arise, impacting both operational efficiency and system effectiveness. These challenges include limited functionality and automation, interoperability challenges, operational inefficiencies, scalability limitations, enhanced risks and complexities, limited operational insights, etc.
[0022] For example, when the external systems are not integrated with the MANO framework, the external systems rely on manual processes for interaction, leading to slower response times, increased potential for human error, and reduced operational efficiency. These manual processes delay service delivery, elevate error rates, and escalate operational costs due to the need for additional human intervention. In addition, a lack of integration of the external systems with the MANO framework hampers scalability by causing operational bottlenecks and inefficiencies in handling increased network demands, leading to suboptimal resource utilization and compromised performance. Moreover, these challenges that occur due to the non-integration of the external systems with the MANO framework impact the functionality, efficiency, and scalability of the external systems.
[0023] Therefore, there is a need to provide a method and a system that provides connectivity between the external systems and the MANO framework and for efficiently serving ever-rising traffic demand.

SUMMARY
[0024] In an exemplary embodiment, a method for managing communication associated with a network services framework is disclosed. The method includes receiving at least one service request from at least one external system via an associated service interface of a set of service interfaces. The method includes performing a check to determine whether the at least one service request is a valid service request or an invalid service request. The method includes, upon determining the at least one service request to be the valid service request, routing the at least one service request to a target microservice associated with the network services framework via an associated microservice interface of a set of microservice interfaces for processing of the at least one service request. The method includes receiving an acknowledgment corresponding to the at least one service request from the target microservice via the associated microservice interface. The method includes forwarding the acknowledgement to the at least one external system via the associated service interface.
[0025] In an embodiment, the method further includes discarding the at least one service request, upon determining the at least one service request to be the invalid service request.
[0026] In an embodiment, the at least one external system corresponds to a Container Network Infrastructure Monitoring System (CNIS), and the associated service interface of the set of service interfaces corresponds to a Container Network Infrastructure Monitoring System Event routing Manager (CNIS_EM) interface.
[0027] In an embodiment, the at least one service request comprises a resource onboarding and instantiation request, a resource recovery request, a resource termination request, a resource scaling request, and a resource maintenance request.
[0028] In an embodiment, the set of service interfaces comprises a Network Management System Event routing Manager (NMS_EM) interface, a Performance Monitoring System Event routing Manager (PM_EM) interface, a Support Ticket System Event routing Manager (STS_EM) interface, a CNIS_EM interface, a Subscriber Support System Event routing Manager (SSS_EM) interface, and a Network Slicing Management Platform Event routing Manager (NSMP_EM) interface.
[0029] In an embodiment, the set of microservice interfaces comprise an Event routing Manager Orchestrator (EM_Or) interface, an Event routing Manager Container Network Function Manager (EM_Cnfm) interface, and an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.
[0030] In an embodiment, the at least one service request is determined to be the valid service request or the invalid service request based on a presence or an absence of the at least one service request within a memory associated with an Event Routing Manager (ERM), respectively.
[0031] In an embodiment, the acknowledgement is one of a positive acknowledgement indicating a successful fulfillment of the at least one service request and a negative acknowledgement indicating a failure in fulfillment of the at least one service request.
[0032] In another exemplary embodiment, a system for managing communication associated with a network services framework is disclosed. The system includes a processing engine and a memory coupled to the processing engine and configured to store instructions executable by the processing engine causes the processing engine to receive at least one service request from at least one external system via an associated service interface of a set of service interfaces. The processing engine is configured to perform a check to determine whether the at least one service request is a valid service request or an invalid service request. The processing engine is configured to upon determining the at least one service request to be the valid service request, route the at least one service request to a target microservice associated with the network services framework via an associated microservice interface of a set of microservice interfaces for processing of the at least one service request. The processing engine is configured to receive an acknowledgment corresponding to the at least one service request from the target microservice via the associated microservice interface. The processing engine is configured to forward the acknowledgement to the at least one external system via the associated service interface.
[0033] In an embodiment, the processing is configured to discard the at least one service request, upon determining the at least one service request to be the invalid service request.
[0034] In an embodiment, the at least one external system corresponds to a Container Network Infrastructure Monitoring System (CNIS), and the associated service interface of the set of service interfaces corresponds to a Container Network Infrastructure Monitoring System Event routing Manager (CNIS_EM) interface.
[0035] In an embodiment, the at least one service request includes a resource onboarding and instantiation request, a resource recovery request, a resource termination request, a resource scaling request, and a resource maintenance request.
[0036] In an embodiment, the set of service interfaces comprises a Network Management System Event routing Manager (NMS_EM) interface, a Performance Monitoring System Event routing Manager (PM_EM) interface, a Support Ticket System Event routing Manager (STS_EM) interface, a CNIS_EM interface, a Subscriber Support System Event routing Manager (SSS_EM) interface, and a Network Slicing Management Platform Event routing Manager (NSMP_EM) interface.
[0037] In an embodiment, the set of microservice interfaces comprises an Event routing Manager Orchestrator (EM_Or) interface, an Event routing Manager Container Network Function Manager (EM_Cnfm) interface, and an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.
[0038] In an embodiment, the at least one service request is determined to be the valid service request or the invalid service request based on a presence or an absence of the at least one service request within a memory associated with an Event Routing Manager (ERM), respectively.
[0039] In an embodiment, the acknowledgment is one of a positive acknowledgement indicating a successful fulfillment of the at least one service request and a negative acknowledgement indicating a failure in fulfillment of the at least one service request.
[0040] The present disclosure discloses a User Equipment (UE) communicatively coupled with a network. The coupling includes a step of receiving, by the network, a connection request from the UE. The coupling includes a step of sending, by the network, an acknowledgment of the connection request to the UE. The coupling includes a step of transmitting a plurality of signals in response to the connection request. Based on the connection request, a management of communication associated with a network services framework within the network is performed.
[0041] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

OBJECTS
[0042] Some of the objects of the present disclosure, which at least one embodiment herein satisfies, are as follows.
[0043] An object of the present disclosure is to manage communication between external systems and a Management and Orchestration (MANO) framework via an Event Routing Manager (ERM). The ERM is a crucial intermediary, connecting the external systems and the MANO framework.
[0044] The object of the present disclosure is to provide advanced automation features and improved scalability to existing MANO frameworks by facilitating new functionalities and capabilities for the existing MANO frameworks using the ERM.
[0045] An object of the present disclosure is to promote interoperability between the external systems and the MANO framework, making it easier for the external systems and the MANO framework to work seamlessly together.
[0046] An object of the present disclosure is to support the external systems to enhance operations of the external systems and seamlessly integrate with the MANO framework by utilizing interfaces associated with the ERM. This integration of the external systems and the MANO framework enables the external systems to access a wide range of functions supported by the MANO framework.
[0047] An object of the present disclosure is to enable a Network Function Virtualization Management and Orchestration (NFV MANO) framework (same as the MANO framework) to leverage this interaction between the external systems and the MANO framework to augment capabilities of the MANO framework with additional functionalities that might be absent in a specific NFV MANO implementation.
[0048] Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0049] 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.
[0050] FIG. 1 illustrates an exemplary network architecture for implementing a system for managing communication associated with a network services framework, in accordance with an embodiment of the present disclosure.
[0051] FIG. 2 illustrates an exemplary block diagram of the system configured for managing communication associated with the network services framework, in accordance with an embodiment of the present disclosure.
[0052] FIG. 3A illustrates an exemplary block diagram depicting communication between external systems and a Management and Orchestration (MANO) framework via interfaces associated with an Event Routing Manager (ERM), in accordance with an embodiment of the present disclosure.
[0053] FIG. 3B illustrates an exemplary system architecture depicting communication between a Container Network Infrastructure Monitoring System (CNIS) and the MANO framework via the ERM, in accordance with an embodiment of the present disclosure.
[0054] FIG. 4 illustrates a MANO framework architecture, in accordance with embodiments of the present disclosure.
[0055] FIG. 5 illustrates an exemplary flow diagram of a process depicting management of communication between the external systems and the MANO framework via the ERM, in accordance with an embodiment of the present disclosure.
[0056] FIG. 6 illustrates an example flow diagram depicting processing of at least one service request, in accordance with an embodiment of the present disclosure.
[0057] FIG. 7 illustrates a detailed flow diagram of a method for managing communication associated with the network services framework, in accordance with embodiments of the present disclosure.
[0058] FIG. 8 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0059] The foregoing shall be more apparent from the following more detailed description of the disclosure.

LIST OF REFERENCE NUMERALS
100 – Network architecture
102-1, 102-2…102-N – Plurality of Users
104-1, 104-2…104-N – Plurality of User Equipments
106 – Network
108 – System
200 – Block Diagram
202 – Processor(s)
204 - Memory
206 – Plurality of Interfaces
208 – Processing Engine
210 – Database
212 - Event Routing Manager (ERM)
300A – Exemplary Block Diagram
302A-2 - Network Slicing Management Platform (NSMP)
302A-4 - Support Ticket System (STS)
302A-6 - Subscriber Support System (SSS)
302A-8 - Performance Manager (PM)
302A-10 - Network Management System (NMS)
302A-12 - Container Network Infrastructure Monitoring System (CNIS)
304A - ERM
306A - Management and Orchestration (MANO) framework
308A – Orchestrator
310A – Container Network Function (CNF) manager
312A – Virtual Infrastructure Manager (VIM)
314A – CNF catalogue management
316A – Network service catalogue
318A – Policy execution engine
320A - CNF lifecycle manager
322A – Orchestration adapter
300B - Exemplary System Architecture
302B- Network elements
302B- 1 – Network element 1
302B-2 – Network element 2
400 – MANO framework architecture
402 - User interface layer
404 - Network Functions Virtualization (NFV) and Software-Defined Networking SDN design function
406 - Platform foundation service
408 – Platform core service
410 – Platform operation, administration, and maintenance manager
412 – Platform resource adapters and utilities
500 – Flow Diagram
600 – Flow Diagram
700 – Flow Diagram
800 – Computer System
810 – External Storage Device
820 – Bus
830 – Main Memory
840 – Read Only Memory
850 – Mass Storage Device
860 – Communication Port
870 – Processor

DETAILED DESCRIPTION
[0060] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0061] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0062] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0063] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0064] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0065] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0066] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
[0067] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.
[0068] Further, the user device may also comprise a “processor” or “processing engine” includes processing engine, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.
[0069] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in the order of Second Generation (2G), Third Generation (3G), Fourth Generation (4G), and now Fifth Generation (5G), and more such generations are expected to continue in the forthcoming time.
[0070] Radio Access Technology (RAT) refers to the technology used by mobile devices/ user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include a Global System for Mobile Communications (GSM), a Code Division Multiple Access (CDMA), a Universal Mobile Telecommunications System (UMTS), a Long-Term Evolution (LTE), and 5G network. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
[0071] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when a 2G technology was introduced. A 3G technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. A 4G technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, a 5G technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (IoT) connectivity, and more efficient use of network resources. A Sixth Generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way we connect and interact with technology.
[0072] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0073] An Event Routing Manager (ERM) is a component or a system responsible for directing events (service requests) or messages from a source to their intended recipients. The ERM plays a crucial role in managing and directing a flow of data or the events in event-driven architectures, ensuring that messages are delivered efficiently and reliably to an appropriate consumer or a system. A Management and Orchestration (MANO) framework is a framework for managing and orchestrating all network resources in a cloud. The MANO framework includes computing, networking, storage, containers, and Virtual Machine (VM) resources. The ERM plays a vital role in providing an interface between an external system and the MANO framework to establish communication between the external system and the MANO framework.
[0074] To connect the external system and the MANO framework in a telecommunication network, various interfaces are employed. However, these interfaces have a hardcore design and are limited to a specific microservice only. Therefore, several interfaces are required to provide connectivity according to the network requirements, yielding a complex and costly solution.
[0075] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by promoting interoperability between the external systems and the MANO framework, and also between internal microservices within the MANO framework, such that it is easier for the external systems and the MANO framework to work seamlessly together. In an aspect, the present disclosure may be configured to provide the ERM that is configured to provide seamless data communication between the external systems and the MANO framework.
[0076] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0077] The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1- FIG. 8.
[0078] FIG. 1 illustrates an exemplary network architecture 100 of a system 108 for managing communication associated with a network services framework, in accordance with an embodiment of the present disclosure. The network services framework may be implemented as a Management and Orchestration (MANO) framework. The system 108 may include an Event Routing Manager (ERM). The ERM may be configured for managing communication between the external systems and the MANO framework. As illustrated in FIG. 1, the network architecture 100 may include one or more User Equipments (UEs) 104-1, 104-2…104-N associated with one or more users 102-1, 102-2…102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2…102-N may be collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2…104-N may be collectively referred to as the UE 104 or the UEs 104. Although only three UE 104 are depicted in FIG. 1, however, any number of the UE 104 may be included without departing from the scope of the ongoing description.
[0079] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UE 104 may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users 102 and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but not limited to, intelligent, multi-sensing, network-connected devices, that may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0080] Additionally, in some embodiments, the UE 104 may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, the UE 104 may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user 102 or an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.
[0081] In FIG. 1, the UE 104 may communicate with the system 108 through the network 106. In particular, the UE 104 may be communicatively coupled with the network 106. The coupling including steps of receiving, by the network 106, a connection request from the UE 104. Upon receiving the connection request, the coupling including steps of sending, by the network 106, an acknowledgment of the connection request to the UE 104. Further, the coupling including steps of transmitting a plurality of signals in response to the connection request. The plurality of signals is responsible for communicating with the system 108 to manage the communication between the external systems and the MANO within the network 106.
[0082] In an embodiment, the network 106 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 106 may also include, by way of example but not limitation, one or more of the RAN, a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0083] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture 100 may perform functions described as being performed by one or more other components of the network architecture 100.
[0084] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for managing communication associated with the network services, in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1. The network services framework may be implemented as the MANO framework.
[0085] In an embodiment, the system 108 may include one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 108. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.
[0086] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (I/O), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, a processing engine 208 and a database 210. In one embodiment, the processing engine 208 may include an ERM 212. The ERM 212 may be configured to manage communication between the external system and the MANO framework. In some embodiment, the processing engine 208 may include the MANO framework.
[0087] In an embodiment, the ERM 212 is configured to receive at least one service request (also referred as an event) from at least one external system via an associated service interface of a set of service interfaces. Examples of the at least one service request may include, but are not limited to, a resource onboarding and instantiation request, a resource recovery request, a resource termination request, a resource scaling request, and a resource maintenance request. Examples of the set of service interfaces may include a Network Management System Event routing Manager (NMS_EM) interface, a Performance Monitoring System Event routing Manager (PM_EM) interface, a Support Ticket System Event routing Manager (STS_EM) interface, a Container Network Infrastructure Monitoring System Event routing Manager (CNIS_EM) interface, a Subscriber Support System Event routing Manager (SSS_EM) interface, and a Network Slicing Management Platform Event routing Manager (NSMP_EM) interface. Further, examples of the at least one external system may include, but are not limited to, a Network Slicing Management Platform (NSMP), a Support Ticket System (STS), a Subscriber Support System (SSS), a Performance Monitoring (PM) System, a Network Management System (NMS), and a Container Network Infrastructure Monitoring System (CNIS). Upon receiving the at least one service request, the ERM 212 is further configured to perform a check to determine whether the at least one service request is a valid service request or an invalid service request. In an example, if the at least one service request exists within a memory (e.g., the memory 204) associated with the ERM 212, then the at least one service request is the valid service request. If the at least one service request does not exist within the memory associated with the ERM 212, then the at least one service request is the invalid service request.
[0088] Upon determining the at least one service request to be the valid service request, the ERM 212 is configured to route the at least one service request to a target microservice associated with the MANO framework via an associated microservice interface of a set of microservice interfaces for processing the at least one service request. Examples of the set of microservice interfaces may include, but are not limited to, an Event routing Manager Orchestrator (EM_Or) interface, an Event routing Manager Container Network Function Manager (EM_Cnfm) interface, and an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface. Further, the ERM 212 is configured to receive an acknowledgment corresponding to the at least one service request from the target microservice via the associated microservice interface. The acknowledgement is one of a positive acknowledgement indicating a successful fulfillment of the at least one service request and a negative acknowledgement indicating a failure in fulfillment of the at least one service request. Further, the ERM 212 is configured to forward the acknowledgement to the at least one external system via the associated service interface. This complete method performed by the ERM 212 for managing the communication between the external systems and the MANO framework is further explained in detail in conjunction with FIGS. 3 – 7.
[0089] In an embodiment, the system 108 may include the processing engine 208 that may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine 208. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine 208 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine 208 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine 208. In such examples, the system 108 may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system 108 and the processing resource. In other examples, the processing engine 208 may be implemented by electronic circuitry.
[0090] In an embodiment, the system 108 may include a database 210 that includes data (e.g., the at least one service request, a result of performing the check to validate the at least one service request, etc.) that may be either stored or generated as a result of functionalities implemented by any of the components of the processor 202 or the processing engine 208.
[0091] FIG. 3A illustrates an exemplary block diagram 300A depicting communication between the external systems and the MANO framework (i.e., a MANO framework 306A) via interfaces associated with the ERM (i.e., an ERM 304A), in accordance with an embodiment of the present disclosure. The ERM 304A may correspond to the ERM 212. FIG. 3A is explained in conjunction with FIGS. 1 and 2.
[0092] As depicted via the block diagram 300A, the external systems may include an NSMP 302A-2, an STS 302A-4, an SSS 302A-6, a PM 302A-8, an NMS 302A-10, and a CNIS 302A-12. In an aspect, the external systems may be configured to collect and monitor the resource utilization of containers and containerized applications. In the MANO framework 306A, the containers, such as docker containers or pods, are lightweight, standalone, and executable software packages that encapsulate applications and their dependencies. Further, the containerized applications are applications, such Virtual Network Functions (VNFs) or monitoring tools, that are deployed and managed within the containers to ensure scalability and efficient resource utilization.
[0093] The external systems may be configured to analyze metrics to extract data related to the behavior of the containers and containerized applications and the corresponding resource utilization. If the external systems detect any abnormal performance metrics or identify a surge in traffic demand, the external systems are configured to send alerts to a network operator promptly. In an example, the external systems may be integrated with the ERM 304A, and therefore, the external systems may be able to make informed decisions, such as spawning additional resources or taking necessary actions. The external systems integrated with the ERM 304A may be configured to initiate service requests (i.e., the at least one service request) to spawn the resources on the MANO framework 306A. The spawning of the resources on the MANO framework 306A corresponds to a process of creating or provisioning new resources, such as virtual machines, containers, or network functions, based on incoming service requests, i.e., the at least one service request. This process of the spawning involves initializing and configuring the resources, so they are ready for use within the MANO framework 306A.
[0094] The NSMP 302A-2 is a system designed to control and oversee network slicing in the 5G network. The NSMP 302A-2 may provide tools and capabilities to create, configure, monitor, and manage network slices. The NSMP 302A-2 enables network operators to allocate resources, manage resources by setting Quality of Service (QoS) parameters, and ensure the isolation and security of each network slice.
[0095] The STS 302A-4 is a system that receives data from customers (e.g., an end-user or a subscriber) for any issue. For any reported issue, the STS 302A-4 may generate a ticket for troubleshooting based on the data.
[0096] The SSS 302A-6 is a system that allows subscribers or service users to manage their accounts, make payments, update information, upgrade subscriptions, and provision and access resources without a need for direct interaction with customer service.
[0097] The PM 302A-8 may be configured to monitor the application performance using a set of performance counters. Examples of the set of performance counters may be a Central Processing Unit (CPU) usage, a response time, a memory usage, and the like. The set of performance counters tracks various metrics related to the application's behavior and resource utilization. If the PM 302A-8 detects any issues or identifies a surge in the traffic demand, the PM 302A-8 promptly alerts the network operator. The network operator can make informed decisions, such as spawning additional resources or taking necessary actions to address any emerging performance challenges.
[0098] The NMS 302A-10 is a system that is responsible for the centralized management, monitoring, and control of an infrastructure (e.g., the NFV infrastructure) of a network (e.g., the 5G network). The NMS 302A-10 provides a comprehensive set of tools and features for the network operators (or network administrators) to manage and optimize the resources (also known as network resources), including routers, switches, servers, and other network devices. The CNIS 302A-12 may be configured to collect and monitor the resource utilization of the containers and the containerized applications. These metrics may be related to the application's behavior and resource utilization. During execution of at least one service request (or during an event), if the CNIS 302A-12 detects any abnormal performance of the metrics or identifies a surge in traffic demand, the CNIS 302A-12 promptly alerts the network operators.
[0099] In an implementation, the NSMP 302A-2, the STS 302A-4, the SSS 302A-6, the PM 302A-8, the NMS 302A-10, and the CNIS 302A-12 may interact with the ERM 304A using respective service interfaces, i.e., the associated service interface of the set of service interfaces. For example, the NSMP 302A-2 may interact with the ERM 304A via the NSMP_EM interface. The NSMP 302A-2 may use the NSMP_EM interface to initiate the at least one service request to allocate or manage necessary network resources in the MANO framework 306A. The STS 302A-4 may interact with the ERM 304A via the STS_EM interface. In an example, using the STS_EM interface, the STS 302A-4 may send data (i.e., information submitted by the subscribers about issues they are experiencing) to the ERM 304A. The ERM 304A receives the data and routes the data to a specified microservice (i.e., the target microservice) in the MANO framework 306A for trouble ticket generation. The SSS 302A-6 may interact with the ERM 304A via the SSS_EM interface. The SSS 302A-6 may use the SSS_EM interface to initiate the at least one service request to allocate or manage necessary resources using the MANO framework 306A. The PM 302A-8 may interact with the ERM 304A via the PM_EM interface. The NMS 302A-10 may interact with the ERM 304A via the NMS_EM interface. The CINS 302A-12 may interact with the ERM 304A via the CNIS_EM interface.
[00100] In an aspect, the ERM 304A exposes its associated service interface (e.g., the NMS_EM interface) to the NSM 302A-10 in case the network operator wishes to use a single Graphical User Interface (GUI) for all kinds of faults, configuration, accounting, performance and security (FCAPS) (virtual + functional). Also, for any application issue (virtual), the network operator can spawn the resource using this interface.
[00101] In an aspect, the ERM 304A may be configured to enhance the operations of the external systems such that the external systems have access to a wide range of functions supported by the MANO framework 306A. The ERM 304A may serve as the crucial intermediary, connecting the external systems and the MANO framework 306A.
[00102] In an aspect, the ERM 304A may be associated with a processing module (i.e., the processing engine 208) and a memory (i.e., the memory 204). The memory is configured to store program instructions and data corresponding to a plurality of service requests. The memory is configured to store the data received from the external systems, a list of registered service requests, a list of a status of each received service request, and a list of microservices corresponding to each registered service request. The program instructions include a program that implements a method for providing enhanced connectivity for managing data communication between the external systems and the MANO framework 306A in accordance with embodiments of the present disclosure and may implement other embodiments described in this specification. The memory may include any computer-readable medium known in the art, for example, volatile memory, such as a Static Random Access Memory (SRAM) and a Dynamic Random Access Memory (DRAM) and/or nonvolatile memory, such as a Read Only Memory (ROM), an erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The processing module may be configured to fetch and execute computer-readable instructions stored in the memory. The processing module may be configured to execute a sequence of instructions of the method to route the received service requests, which may be embodied in a program or software. The instructions can be directed to the processing engine, which may subsequently program or otherwise be configured to implement the methods of the present disclosure. In some examples, the processing module is configured to control and/or communicate with large databases, perform high-volume transaction processing, and generate reports from large databases. The processing module may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing engine(s), state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions.
[00103] As shown in FIG. 3, the MANO framework 306A includes microservices, such as an orchestrator 308A, a Container Network Function (CNF) manager 310A, and a Virtual Infrastructure Manager (VIM) 312A. The orchestrator (also known as a Network Functions Virtualization (NFV) orchestrator (NFVO)) 308A may be configured to cooperate with a CNF catalogue management 314A, a network service catalogue 316A, and a policy execution engine 318A. The orchestrator 308A may be configured to perform the orchestration of the resources of a Network Functions Virtualization Infrastructure (NFVI) and lifecycle management of Network Service (NS) instances (e.g., instantiation, update, query, scaling, termination, etc. of the NS instances). The CNF manager 310A may be configured to determine the lifecycle of the CNF instances (for example, the instantiation, the update, the query, the scaling, the termination, etc.). The CNF manager 310A may be configured as a CNF lifecycle manager 320A. The VIM 312A may be configured as an orchestration adapter 322A. The VIM 312A may be configured to manage computation, storage, and the resources of the NFVI, monitor a failure of the NFVI, and monitor the resources of the NFVI.
[00104] In one aspect, the MANO framework 306A may be configured to integrate with the ERM 304A and augment its capabilities with additional functionalities that provide enhanced container infrastructure monitoring, management, and analytics.
[00105] The ERM 304A may interact with the MANO framework 306A via the set of microservice interfaces. Each of the set of microservice interfaces may also be referred to as an Event routing Manager Microservice (EM_MS) interface. The set of microservice interfaces may provide new functionalities and capabilities to the MANO framework 306A. The set of microservice interfaces provides advanced automation features and improved scalability. The set of microservice interfaces further promotes interoperability between the external systems and the MANO framework 306A, making it easier for them to work seamlessly together. The external systems may enhance their own operations, which provides access to a wide range of functions supported by the MANO framework 306A. By leveraging this interaction, the MANO framework 306A may augment its capabilities with additional functionalities that might be absent in a specific MANO implementation.
[00106] In examples, the set of microservice interfaces may include the EM_Or interface, the EM_Cnfm interface, and the EM_Vi interface. In examples, the ERM 304A may interact with the microservices of the MANO framework 306A via the set of microservice interfaces. The ERM 304A may interact with the orchestrator 308A via the EM_Or interface. The ERM 304A may interact with the CNF manager 310A via the EM_Cnfm interface. The ERM 304A may interact with the VIM 312A via the EM_Vi interface.
[00107] In an aspect, the ERM 304A may be configured to receive a plurality of service requests (events), i.e., each of the at least one service request, and may be further configured to publish the plurality of service requests. The plurality of service requests may be subscribed to a specific microservice, i.e., the target microservice (also referred to as a subscriber microservice).
[00108] In some embodiments, the ERM 304A may be configured to provide a deferred delivery of the acknowledgement corresponding to the at least one microservice in case the specific microservice fails. In such a scenario, the ERM 304A may be configured to store the acknowledgement in the memory and may communicate the acknowledgement to the specific microservice after a predefined time (e.g., after 1 hour).
[00109] In an operative aspect, if an event (i.e., the at least one service request) is received by the ERM 304A, then the ERM 304A may be configured to check the memory to determine whether the received event exists or not within the memory. If the received event does not exist, the ERM 304A will discard the received event. If the event exists, then the ERM 304A may be configured to identify the target microservice corresponding to the received event.
[00110] In an embodiment, the ERM 304A may be configured to efficiently distribute events to multiple microservices based on a type of the event. Further, the ERM 304A may add multiple events without affecting functionality or performance of the system 108. The ERM 304A supports dynamic routing in event-driven systems by enabling a system to adapt to changing requirements. The ERM 304A provides various mechanisms (e.g., retry mechanism) to handle errors or failures during the routing of the events and to ensure reliable delivery of the events even in the presence of transient failures or network issues. The ERM 304A may incorporate service discovery mechanisms in a distributed system to dynamically locate and route the events to the target microservice. In an aspect, the ERM 304A may be configured to provide advanced automation features and improved scalability.
[00111] In an operative aspect, the ERM 304A may operate on a combination of an event-based architecture and a publish/subscribe architecture and take advantage of both architectures. The ERM 304A may combine event-based messaging with a publish/subscribe pattern and act as a router responsible for receiving the events in the form of a Hypertext Transfer Protocol (HTTP) format, extracting information of the events, and routing the events to the target microservices based on the type of the events. Further, other microservices can subscribe to specific events and receive and process them accordingly.
[00112] In operation, the ERM 304A may accept the event (i.e., the at least one service request) from the external system (e.g., the NMS 302A-10) on the associated service interface (e.g., the NMS_EM interface) and route the event to the target microservice (e.g., the orchestrator 308A) of the MANO framework 306A for processing the event. The ERM 304A may route the event to the target microservice via the EM_MS interface (e.g., the EM_Or interface). In an example, the event may be a resource onboarding and instantiation request (for example, for resource onboarding and instantiation), a resource recovery request (for example, for resource recovery or resource restoration), a resource termination request (for example, for resource termination), a resource scaling request (for example, for resource scaling request), or a resource maintenance request (for example, for resource maintenance). Once the event is processed successfully, the ERM 304A may receive a response, i.e., the acknowledgement from the target microservice of the MANO framework 306A. In examples, after processing the event, whether successful or failed, the acknowledgment (also referred as an event acknowledgment) is sent to the ERM 304A by the target microservice of the MANO framework 306A via the associated microservice interface (e.g., the EM_Vi interface). Further, the ERM 304A forwards the acknowledgement to the NMS 302A-10 over the NMS_EM interface.
[00113] FIG. 3B illustrates an exemplary system architecture 300B depicting communication between the CNIS 302A-12 and the MANO framework 306A via the ERM 304A, in accordance with an embodiment of the present disclosure. FIG. 3B is explained in conjunction with FIGS. 1, 2, and 3A.
[00114] As shown in FIG. 2B, the system architecture 300B includes a plurality of network elements (e.g., a network element 1 302B-1 and a network element 2 302B-2) (collectively referred to as network elements 302B, and individually referred to as a network element 302B), the CNIS 302A-12 (interchangeably referred to as the at least one external system), the ERM 304A, and the MANO) framework 306A (interchangeably referred to as the network service architecture). In an example, the plurality of network elements 302B is a logical entity or a physical entity within the network 106 that is being managed or controlled. Each network element 302B is designed with built-in instrumentation, which allows for collecting relevant information that may be subsequently used to determine control actions to be applied to the network element 302B.
[00115] In an embodiment, the ERM 304A plays a significant role in event-driven systems where the plurality of service requests (i.e., the events) are required to be delivered from the network elements 302B (event sources) to a specific event consumers or downstream services (also referred to as the one or more network services). The ERM 304A acts as an intermediary connecting interface between the CNIS 302A-12 and the MANO framework 306A. The MANO framework (224) manages and orchestrates network functions and resources in a virtualized network environment, such as in the NFVI. The ERM 304A provides event distribution by efficiently distributing the events to multiple network services (also referred to as the microservices) based on the type of the event. The ERM 304A facilitates the decoupling and scalability of the event-driven systems by allowing a system (e.g., the system 108) to scale independently. Further, the ERM 304A assists in adding multiple event producers and consumers in the event-driven systems without affecting the overall system’s functionality or performance. The ERM 304A supports dynamic routing in event-driven systems by enabling the system to adapt to changing requirements, providing error handling and retry mechanisms in the event-driven systems. The ERM 304A provides various mechanisms (e.g., the retry mechanism) to manage the errors or the failures during event routing and ensure reliable delivery of the events, even in transient failures or network issues. Further, in a distributed system, the ERM 304A incorporates service discovery mechanisms to locate dynamically and route events to the specific/dedicated service instances.
[00116] The ERM 304A provides a centralized and efficient mechanism for event routing and distribution in the event-driven architectures. The ERM 304A offers advantages such as decoupling, scalability, dynamic routing, error handling, and visibility, contributing to the overall flexibility, reliability, and maintainability of the system 108.
[00117] As shown in FIG. 2B, the CNIS 302A-12 retrieves data from the network elements 302B, e.g., the network element 1 302B-1. The CNIS 302A-12 uses the retrieved data to make decisions regarding resource allocation service requests. The CNIS 302A-12 initiates the at least one service request related to an event (e.g., resource allocation) based on the data towards the ERM 304A using the CNIS_EM interface (i.e., the associated service interface). The ERM 304A accepts the at least one service request from the CNIS 302A-12 and sends the at least one service request using the EM_MS interface (i.e., one of the set of service interfaces) towards the MANO framework 306A, which is configured for processing the at least one service request. In particular, the ERM 304A may send the at least one service request to the target microservice associated with one of the orchestrator 308A, the CNF manager 310A, or the VIM 312A. The target microservice of the MANO framework 306A analyses the at least one service request and provides the provisioning and initiating of the event related to the requested resource. In other words, the MANO framework 306A forwards the at least one service request to the target microservice to fulfil the event (e.g., the resource creation). When the event is processed successfully by the target microservice, the ERM 304A receives at least one acknowledgment signal associated with the acknowlegement from the target microservice via the EM_MS interface. The ERM 304A transmits the at least one acknowledgement signal including the acknowledgement, via the associated service interface (i.e., the CNIS_EM interface), towards the CNIS 302A-12, indicating a status (the successful fulfillment or the failure in the fulfillment) of the at least one service request.
[00118] In an embodiment, the CNIS 302A-12 continuously monitors the data of the network elements 302B. When the CNIS 302A-12 detects any issue with the network elements 302B, such as over-utilization or underutilization of the resources from the data, the CNIS 302A-12 decides for the resource creation or generates an event to troubleshoot. The CNIS 302A-12 or the user (e.g., the network operator) may use the CNIS_EM interface to initiate the at least one service request to allocate or manage the necessary network resources.
[00119] In an embodiment, the present disclosure provides an asynchronous event-based implementation to utilize the CNIS_EM interface efficiently. In fault tolerance for any event failure, the CNIS_EM interface works in the high availability mode, ensuring continuity of each of the at least one service request processing. If one ERM instance goes down during the resource allocation service request processing, then next available instance takes care of the resource allocation request.
[00120] Further, the CNIS_EM interface provides advanced automation features and improved scalability. The CNIS_EM interface promotes interoperability between the CNIS 302A-12 and the MANO framework 306A, thus making it easier for the CNIS 302A-12 and the MANO framework 306A to work seamlessly together.
[00121] FIG. 4 illustrates a MANO framework architecture 400, in accordance with embodiments of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1, 2, and 3.
[00122] As depicted in FIG. 4, the MANO framework architecture 400 may comprise several interconnected modules that work together to enable efficient resource allocation and management. These modules may include a user interface layer 402, NFV and Software-Defined Networking (SDN) design functions 404, platform foundation services 406, platform core services 408, a platform operation, administration, and maintenance manager 410, and platform resource adapters and utilities 412.
[00123] The user interface layer 402 may serve as a primary point of interaction for the network operators and the network administrators. Through the user interface layer 402, various parameters associated with the ERM 304A may be configured and adjusted based on specific requirements. These parameters may include a number of microservices associated with ERMs, a number of ERMs that can be deployed simultaneously, and other relevant settings.
[00124] The NFV and SDN design functions 404 may work in conjunction with the platform core services 408 to analyze and route the service requests received by the ERM 304A. These modules may be responsible for determining the target microservice within the MANO framework 306A based on a type of resource allocation required. These modules may utilize a mapping of service request types to target microservices maintained by the ERM 304A to ensure accurate routing. The NFV and SDN design functions 404 may include a virtualized network function (VNF) lifecycle manager (compute) that is a specialized component focused on managing the compute resources associated with VNF throughout their lifecycle. The NFV and SDN design functions 404 may include a VNF catalog that is a repository that stores and manages metadata, configurations, and templates for VNF, facilitating their deployment and lifecycle management. The NFV and SDN design functions 404 may include network services catalog, network slicing and service chaining manager, physical and virtual resource manager and CNF lifecycle manager. The network services catalog serves as a repository for managing and storing detailed information about network services, including their specifications and deployment requirements. The network slicing & service chaining manager is responsible for orchestrating network slices and service chains, ensuring efficient allocation and utilization of network resources tailored to various services. The physical and virtual resource manager oversees both physical and virtual resources, handling their allocation, monitoring, and optimization to ensure seamless operation across the network infrastructure. The CNF lifecycle manager manages the complete lifecycle of the CNF, including onboarding, instantiation, scaling, monitoring, and termination, thereby facilitating the efficient deployment and operation of network functions in a cloud-native environment.
[00125] The platform foundation services 406 may support an asynchronous event-based processing model implemented by the ERM 304A, enabling concurrent handling of multiple service requests. They may also facilitate bi-directional communication interfaces (NSMP_EM interafce and EM_Or Interface, STS_EM interface and EM_Or interface, etc.) used by the ERM 304A to interact with the external systems (e.g., the NSMP 302A-2, the STS 302A-4, etc.) and the MANO framework 306A microservices. The platform foundation services 406 may include microservices elastic load balancer, identity & access manager, a Command Line Interface (CLI), a central logging manager, and an ERM (i.e., the ERM 304A). The microservices elastic load balancer ensures that incoming traffic is evenly distributed across multiple microservices, enhancing performance and availability. The identity & access manager handles user identity management and access control, enforcing permissions and roles to secure resources and services. The CLI offers a text-based method for users to interact with the platform, enabling command execution and configuration management. The central logging manager consolidates log data from various system components, providing a unified view for effective monitoring, troubleshooting, and data analysis.
[00126] The platform core services 408 are central to the processing and fulfillment of the service requests (i.e., at least one service request). The platform core services 408 may work together to allocate network slices, manage virtualized network functions, and orchestrate the underlying infrastructure resources based on each of the at least one service request routed by the ERM 304A. The platform core services 408 may include an NFV infrastructure monitoring manager, an assurance manager, a performance manager, a policy execution engine, a capacity monitoring manager, a release management repository, a configuration manager & Global Control Tower (GCT), an NFV platform decision analytics platform, Not Only Structured Query Language database (NoSQL DB), a platform schedulers & jobs, a VNF backup & upgrade manager, and a microservice auditor. The NFV infrastructure monitoring manager tracks and oversees the health and performance of NFV infrastructure. The assurance manager ensures service quality and compliance with operational standards. The performance manager monitors system performance metrics to optimize efficiency. The policy execution engine enforces and executes policies across the platform. The capacity monitoring manager tracks resource usage and forecasts future needs. The release management repository manages software releases and version control. The configuration manager handles system configurations, ensuring consistency and automation. The GCT provides centralized oversight and management of platform operations. The NFV platform decision analytics platform utilizes data analytics to support decision-making. The NoSQL DB stores unstructured data to support flexible and scalable data management. The platform schedulers and jobs automate and schedule routine tasks and workflows. The VNF backup and upgrade manager oversees the backup and upgrading of VNFs. The microservice auditor ensures the integrity and compliance of microservices across the platform.
[00127] The platform operation, administration, and maintenance manager 410 may oversee operational aspects of the MANO framework architecture 400. The platform operation, administration, and maintenance manager 410 may be responsible for implementing a load balancing mechanism used by the ERM 304A to distribute the service requests across multiple instances of the MANO framework 306A microservices.
[00128] The platform resource adapters and utilities 412 may provide necessary tools and interfaces for interacting with an underlying network infrastructure, i.e., the NFV architecture. These components may be crucial in translating the service requests into actionable commands for the resources (also referred to as the network resources) allocation and management. The platform resource adapters and utilities 412 may work closely with the platform core services 408 to ensure that allocated resources meet specified requirements. Together, these modules create a cohesive and efficient system for managing resource allocation. The platform resource adapters and utilities 412 may include a platform external API adapter and gateway, a generic decoder and indexer, an orchestration adapter, an API adapter, and an NFV gateway. The platform external API adapter and gateway facilitates seamless integration with external APIs and manages data flow between external systems and the platform. The generic decoder and indexer processes and organizes data from various formats such as XML, comma-separated values (CSV), and JSON, ensuring compatibility and efficient indexing. The orchestration adapter manages interactions with clusters, enabling container orchestration and scaling. The API adapter interfaces with services, allowing integration and management of cloud resources. The NFV gateway acts as a bridge for NFV communications, coordinating between NFV components and other platform elements.
[00129] The ERM 304A may interact with all these modules to facilitate an end-to-end process of a service request handling. The ERM 304A may receive the service requests through the user interface layer 402, utilize the NFV and SDN design functions 404 for the service requests analysis, leverage the platform core services 408 for the service requests fulfillment, and use the platform resource adapters and utilities 412 for actual resources allocation for each of the service requests. The platform operations, administration and maintenance manager 410 may oversee this entire process, ensuring efficient operation and fault tolerance. This integrated approach may enable the MANO framework 306A to efficiently manage a complex process of resource allocation and management, potentially providing a flexible and responsive system capable of meeting diverse service requirements in a dynamic network environment.
[00130] FIG. 5 illustrates an exemplary flow diagram 500 of a process depicting the management of communication between the external systems and the MANO framework 306A via the ERM 304A, in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1, 2, 3, and 4.
[00131] To manage the communication between the external systems and the MANO framework 306A, at step 502, the at least one external system may generate and send the at least one service request (also referred to as the event) to the ERM 304A. In an example, the at least one external system may be one of the NSMP 302A-2, the STS 302A-4, the SSS 302A-6, the PM 302A-8, the NMS 302A-10, and the CNIS 302A-12. Further, the at least one service request may encompass various resource-related actions, including but not limited to, the resource onboarding and instantiation request, the resource recovery request, the resource termination request, the resource scaling request, and the resource maintenance request.
[00132] Further, at step 504, the ERM 304A may be configured to receive the at least one service request from the at least one external system over the associated service interface from the set of service interfaces. Examples of the set of service interfaces may include, the NSMP_EM interface, the STS_EM interface, the SSS_EM interface, the PM_EM interface, the NMS_EM interface, or the CNIS_EM interface. By way of an example, when the at least one external system is the STS 302A-4, then the at least one service request (e.g., the resource recovery request) may be sent over the STS_EM interface. In an embodiment, the ERM 304A may receive the at least one service request as an input from a user (e.g., the network operator) through the UI associated with the at least one external system using the associated service interface. In some embodiments, the at least one external system may correspond to the CNIS 302A-12, and the associated service interface of the set of service interfaces corresponds to the CNIS_EM interface. In another embodiment, the network operator may provide the at least one service request as the input to the ERM 304A by using a UE associated with the network operator that is in communication with the at least one external system. In some embodiments, the at least one external system may be integrated with the UE associated with the network operator.
[00133] Further, at step 506, the ERM 304A is configured to perform the check to determine whether the at least one service request is the valid service request or the invalid service request. In an example, if the at least one service request exists within a memory (e.g., the memory 204) associated with the ERM 304A, then the at least one service request is the valid service request. The memory associated with the ERM 304A may contain a repository of valid service request templates (i.e., the list of valid service request templates) or identifiers, serving as a reference for this validation process. In some embodiments, the memory including the repository of valid service request templates, or the identifiers may be present within the ERM 304A. If the at least one service request is the invalid service request valid, then the flow diagram 500 proceeds to step 508. At step 508, the ERM 304A may discard the invalid service request, upon determining that the at least one service request does not exist in the memory of the ERM 304A.
[00134] Further, based on the check performed at step 506, upon determining the at least one service request to be the valid service request, at step 510, the at least one service request may be routed to an appropriate microservice (i.e., an appropriate MS). The appropriate MS may correspond to the target microservice. To route the at least one request to the appropriate MS, a detailed analysis of the at least one service request may be performed by the ERM 304A. The detailed analysis is performed to determine the appropriate MS within the MANO framework 306A that should be assigned to handle the at least one service request. For example, if the at least one service request is the resource onboarding and instantiation request, i.e., an onboarding and instantiation event 512, then a specific microservice, e.g., a MANO MS 514 is assigned for the onboarding and instantiation event 512. The MANO MS 514 may be configured to process the onboarding and instantiation event 512. By way of another example, if the at least one service request is the resource recovery request, i.e., a resource healing event 516, then a specific microservice, e.g., a MANO MS 518 is assigned for the resource healing event 516. The MANO MS 518 may be configured to process the resource healing event 516. By way of yet another example, if the at least one service request is the resource maintenance request, i.e., a resource maintenance event 520, then a specific microservice, e.g., a MANO MS 522 is assigned for the resource maintenance event 520. The MANO MS 522 may be configured to process the resource maintenance event 520. As will be appreciated, in some embodiments, a plurality of service requests may be received at an instance. Further, the ERM 304A may be configured to cater to each of the plurality of service requests simultaneously.
[00135] Further, each of the appropriate MS may be configured to process the at least one service request and generate the acknowledgement corresponding to the at least one service request. For example, the MANO MS 514, the MANO MS 518, and the MANO MS 522 may be configured to process the onboarding and instantiation event 512, the resource healing event 516, and the resource maintenance event 520, respectively, and generate a corresponding acknowledgment. The acknowledgment may be one of the positive acknowledgement indicating the successful fulfillment of the at least one service request or the negative acknowledgement indicating a failure in fulfillment of the at least one service request.
[00136] Further, at step 524, the appropriated MS may transmit the acknowledgement (also referred to as a response) to the ERM 304A over the associated microservice interface. The associated microservice interface may be one of the EM_Or interface, the EM_Cnfm interface, or the EM_Vi interface. Upon receiving the acknowledgement, the ERM 304A forwards the acknowledgement to the at least one external system over the associated service interface.
[00137] FIG. 6 illustrates an example flow diagram 600 depicting processing of the at least one service request, in accordance with an embodiment of the present disclosure. FIG. 6 is explained in conjunction with FIGS. 1, 2, 3, 4, and 5. For example, FIG. 6 shows various steps of processing the at least one service request received from the at least one external system.
[00138] Initially, at step 612, the at least one service request (for example, a provision resource request) may be received by an ERM 604 (same as the ERM 304A) from an external system 602. The ERM 604 may receive the at least one service request from the external system 602 over the associated service interface from the set of service interfaces. The external system 602 may be one of the NSMP 302A-2, the STS 302A-4, the SSS 302A-6, the PM 302A-8, the NMS 302A-10, and the CNIS 302A-12. Examples of the set of service interfaces may include, the NSMP_EM interface, the STS_EM interface, the SSS_EM interface, the PM_EM interface, the NMS_EM interface, or the CNIS_EM interface. In some embodiments, the external system 602 corresponds to the CNIS 302A-12, and the associated service interface of the set of service interfaces corresponds to the CNIS_EM interface. In an embodiment, the ERM 604 may receive the at least one service request as the input from the user (e.g., the network operator) through the UI associated with the at least one external system using the associated service interface.
[00139] Further, at step 614, the provision resource request may be forwarded by the ERM 604 to an orchestrator 606 (same as the orchestrator 308A) of the MANO framework 306A. In an example, the MANO framework 306A may include an orchestrator 606, an CNF manager 608 (same as the CNF manager 310A), and a VIM 610 (same as the VIM 312A). In an example, the ERM 604 may be configured to analyze the at least one service request, i.e., the provision resource request to allocate a specific microservice (i.e., the target microservice) associated with the MANO framework 306A accordingly. For example, based on the analyses, if the ERM 604 determined that the at least one service request is the provision resource request, then the ERM 604 may forward the at least one service request to the orchestrator 606. The orchestrator 606 may be configured to perform resource orchestration and network service orchestration. The orchestrator 606 may be configured to receive the provision resource request from the ERM 604 to generate a process service request. In an aspect, the process service request may include a set of instructions to be followed by the CNF manager 608.
[00140] Further, at step 616, the orchestrator 606 may be configured to store the received provision resource request in a database associated with the MANO framework 306A. In an embodiment, when the MANO framework 306A is present within the processing engine 208, then the database may correspond to the database 210. Further, at step 618, the orchestrator 606 may communicate the process service request towards the ERM 604.
[00141] At step 620, the ERM 604 may forward the process service request to the CNF manager 608. In an example, the CNF manager 608 may be configured to automate development, deployment, maintenance, and operation of a network (e.g., the 5G network) to effectively handle escalating demand, accelerate deployments, and reduce complexity. Upon receiving the process resource request from the ERM 604, the CNF manager 608 may be configured to analyze the process service request.
[00142] Further, based up the analysis, the CNF manager 608 may be configured to generate an infrastructure orchestration request. The CNF manager 608 may be configured to generate an instruction regarding onboarding, instantiation, or termination of this process, or the infrastructure based on the received process resource request as mentioned via step 622. In an aspect, the infrastructure orchestration request may include information of an infrastructure to be assigned, created, updated, or deleted. Further, at step 624, the CNF manager 608 may communicate the infrastructure orchestration request to the ERM 604.
[00143] At step 626, the ERM 604 may be configured to directly forward the received infrastructure orchestration request to the VIM 610. Further, at step 628, the VIM 610 may be configured to process the infrastructure orchestration request to analyze the infrastructure orchestration request for generating an acknowledgement. Once the acknowledgement is generated, at step 630, the acknowledgement may be forwarded by the VIM 610 to the ERM 604. Further, at step 632, the ERM 604 may forward the acknowledgement to the external system 602 indicating a status of the infrastructure orchestration request after processing the infrastructure orchestration request. In an example, the status may be one of a success, i.e., the positive acknowledgment, or a failure, i.e., the negative acknowledgement corresponding to the at least one service request.
[00144] FIG. 7 illustrates a detailed flow diagram of a method 700 for managing communication associated with the network services framework, in accordance with embodiments of the present disclosure. FIG. 7 is explained in conjunction with FIGS. 1, 2, 3, 4, 5 and 6. In particular, the managing of the communication between the external systems and the network services framework is performed based on the method 700. The network services framework may correspond to the MANO framework 306A. Examples of the external systems may include, but are not limited to, NSMP 302A-2, the STS 302A-4, the SSS 302A-6, the PM 302A-8, the NMS 302A-10, and the CNIS 302A-12. Each step of the method 700 may be executed by the ERM 212 (same as the ERM 304A) present within the processing engine 208.
[00145] To manage the communication between the external systems and the MANO framework, at step 702, the at least one service request (also referred as the event) may be received from the at least one external system via the associated service interface from the set of service interfaces. In an embodiment, the at least one service request may encompass various resource-related actions, including but not limited to, the resource onboarding and instantiation request, the resource recovery request, the resource termination request, the resource scaling request, and the resource maintenance request. The at least one external system may be one of the NSMP 302A-2, the STS 302A-4, the SSS 302A-6, the PM 302A-8, the NMS 302A-10, and the CNIS 302A-12. Examples of the set of service interfaces may include, the NSMP_EM interface, the STS_EM interface, the SSS_EM interface, the PM_EM interface, the NMS_EM interface, and the CNIS_EM interface. In some embodiments, the at least one external system corresponds to the CNIS 302A-12, and the associated service interface of the set of service interfaces corresponds to the CNIS_EM interface.
[00146] By way of an example, when the at least one external system is the SSS 302A-6, then the at least one service request (e.g., the resource scaling request) may be received over the SSS_EM interface (i.e., the associated service interface). In an embodiment, the ERM 212 may receive the at least one service request as an input from the user (e.g., the network operator) through the UI associated with the at least one external system using the associated service interface. In other words, the network operator may provide the at least one service request as the input to the ERM 212 by using the UI or one or more input devices associated with the at least one external system. Examples of the one or more input devices may include, a keyboard, a mouse, a joystick, and the like. In another embodiment, the network operator may provide the at least one service request as the input to the ERM 212 by using the UE associated with the network operator that is in communication with the at least one external system.
[00147] Upon receiving the at least one service request, at step 704, the check is performed to determine whether the at least one service request is the valid service request or the invalid service request. In an embodiment, the at least one service request is the valid service request if the at least one service request exists within the memory (e.g., the memory 204) associated with the ERM 212. In other words, when the presence of the at least one service request within the memory is detected, then the at least one service request is determined to be the valid service request. The memory associated with the ERM 212 may contain the repository of the valid service request templates or the identifiers, against which incoming service requests are checked. In other words, in some embodiments, the ERM 212 may include a memory configured for storing the repository of the valid service request templates or the identifiers. Further, when the at least one service request is not present within the memory associated with the ERM 212, the at least one service request may be determined as the invalid service request. In other words, when the absence of the at least one service request within the memory is detected, then the at least one service request is determined to be the invalid service request. In an embodiment, upon determining the at least one service request to be the invalid service request, the at least one service request may be discarded.
[00148] Upon determining the at least one service request to be the valid service request, at step 706, the at least one service request may be routed towards the target microservice associated with the MANO framework 306A. The at least one service request may be routed towards the target microservice via the associated microservice interface of the set of microservice interfaces. The set of microservice interfaces may include, but are not limited to, the EM_Or, the EM_Cnfm, and the EM_Vi. Each of the set of microservice interfaces may also be referred the EM_MS interface. The routing process may involve a detailed analysis of the at least one service request to determine a most appropriate microservice (i.e., the target service) within the MANO framework 306A. This analysis may be based on the type of resource allocation required, as specified in the at least one service request. The ERM 212 may maintain the mapping of service request types to target microservices, enabling efficient and accurate routing of each service request. In other words, the target microservice may be determined based on the type of resource (e.g., the switches, the routers, the servers, the network devices, etc.) allocation required for processing the at least one service request. For this, the ERM 212 may utilize the mapping of service request types to target microservices maintained by the ERM 212 to ensure accurate routing. The target microservice of the MANO framework (i.e., the MANO framework 306A) may include at least one of the orchestrator 308A, the CNF manager 310A, or the VIM 312A. Each of these microservices may be specialized in handling specific aspects of the resource’s allocation and management. The routing process may also involve translating each of the at least one service request into a format (e.g., the HTTP format) compatible with the MANO framework 306A. In an embodiment, the target microservice may be configured to process the at least one service request and generate the acknowledgement based on the processing of the at least one service request.
[00149] Further, at step 708, the acknowledgment may be received corresponding to the at least one service request from the target microservice via the associated microservice interface. In other words, the ERM 212 may be configured to receive the acknowledgment corresponding to the at least one service request from the target microservice of the MANO framework via the associated microservice interface. The acknowledgment is one of the positive acknowledgement indicating the successful fulfillment of the at least one service request and the negative acknowledgement indicating the failure in fulfillment of the at least one service request. Upon receiving the acknowledgement, at step 710, the acknowledgement may be forwarded to the at least one external system via the associated service interface. In other words, upon receiving the acknowledgment, the ERM 212 may be configured to forward the acknowledgement to the at least one external system via the associated service interface.
[00150] FIG. 8 illustrates an exemplary computer system 800 in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 8, the computer system 800 may include an external storage device 810, a bus 820, a main memory 830, a read-only memory 840, a mass storage device 850, communication port(s) 860, and a processor 870. A person skilled in the art will appreciate that the computer system 800 may include more than one processor and communication ports. The processor 870 may include various modules associated with embodiments of the present disclosure. The communication port(s) 860 may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 860 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 800 connects.
[00151] The main memory 830 may be Random-Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 840 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor 870. The mass storage device 850 may be any current or future mass storage solution, which can be used to store information and/or instructions. The mass storage device 850 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, a Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.
[00152] The bus 820 communicatively couples the processor 870 with the other memory, storage, and communication blocks. The bus 820 may be, e.g. a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 870 to the computer system 800.
[00153] Optionally, operator and administrative interfaces, e.g. a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus 820 to support direct operator interaction with the computer system 800. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 860. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 800 limit the scope of the present disclosure.
[00154] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skills in the art.
[00155] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
[00156] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.
[00157] The present disclosure provides technical advancement related to management of communication between external systems and a MANO framework. This advancement addresses the limitations of existing solutions by introducing an ERM that acts as an intelligent intermediary between the external systems and the MANO framework. By introducing the ERM, the present disclosure promotes interoperability between the external systems and the MANO framework, making it easier for the external systems and the MANO framework to work seamlessly together. The present disclosure provides intelligent service requests routing to specific microservices of the MANO framework, ensuring optimal resource allocation and improving overall network performance.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00158] The present disclosure provides a method and a system for managing communication between external systems and a Management and Orchestration (MANO) framework via an Event Routing Manager (ERM). The ERM serves as a crucial intermediary, connecting the external systems and the MANO framework.
[00159] The present disclosure provides advanced automation features and improved scalability to MANO frameworks by facilitating new functionalities and capabilities to existing MANO frameworks using the ERM.
[00160] The present disclosure promotes interoperability between the external systems and the MANO framework, making it easier for the external systems and the MANO framework to work seamlessly together.
[00161] The present disclosure implements intelligent request routing to specific MANO framework microservices, ensuring optimal resource allocation and improving overall network performance.
[00162] The present disclosure supports the external systems to enhance their operations and seamlessly integrate with the MANO framework by utilizing interfaces associated with the ERM. This integration of the external systems and the MANO framework enables the external systems to access a wide range of functions supported by the MANO framework.
[00163] The present disclosure enables a Network Function Virtualization Management and Orchestration (NFV MANO) framework (same as the MANO framework) to leverage this interaction between the external systems and the MANO framework to augment its capabilities with additional functionalities that might be absent in a specific NFV MANO implementation.
,CLAIMS:CLAIMS
We claim:
1. A method (700) for managing communication associated with a network services framework, the method (700) comprising:
receiving (702), by a processing engine (208), at least one service request from at least one external system via an associated service interface of a set of service interfaces;
performing (704), by the processing engine (208), a check to determine whether the at least one service request is a valid service request or an invalid service request;
upon determining the at least one service request to be the valid service request, routing (706), by the processing engine (208), the at least one service request to a target microservice associated with the network services framework via an associated microservice interface of a set of microservice interfaces for processing of the at least one service request;
receiving (708), by the processing engine (208), an acknowledgment corresponding to the at least one service request from the target microservice via the associated microservice interface; and
forwarding (710), by the processing engine (208), the acknowledgement to the at least one external system via the associated service interface.

2. The method (700) as claimed in claim 1, further comprising:
upon determining the at least one service request to be the invalid service request, discarding, by the processing engine (208), the at least one service request.

3. The method (700) as claimed in claim 1, wherein the at least one service request comprises a resource onboarding and instantiation request, a resource recovery request, a resource termination request, a resource scaling request, and a resource maintenance request.

4. The method as claimed in claim 1, wherein the at least one external system corresponds to a Container Network Infrastructure Monitoring System (CNIS), and wherein the associated service interface of the set of service interfaces corresponds to a Container Network Infrastructure Monitoring System Event routing Manager (CNIS_EM) interface.

5. The method (700) claimed as in claim 1, wherein the set of service interfaces comprises a Network Management System Event routing Manager (NMS_EM) interface, a Performance Monitoring System Event routing Manager (PM_EM) interface, a Support Ticket System Event routing Manager (STS_EM) interface, a CNIS_EM interface, a Subscriber Support System Event routing Manager (SSS_EM) interface, and a Network Slicing Management Platform Event routing Manager (NSMP_EM) interface.

6. The method (700) as claimed in claim 1, wherein the set of microservice interfaces comprises an Event routing Manager Orchestrator (EM_Or) interface, an Event routing Manager Container Network Function Manager (EM_Cnfm) interface, and an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.

7. The method (700) as claimed in claim 1, wherein the at least one service request is determined to be the valid service request or the invalid service request based on a presence or an absence of the at least one service request within a memory associated with an Event Routing Manager (ERM) (212), respectively.

8. The method (700) as claimed in claim 1, wherein the acknowledgement is one of:
a positive acknowledgement indicating a successful fulfillment of the at least service request, and
a negative acknowledgement indicating a failure in fulfillment of the at least service request.

9. A system (108) for managing communication associated with a network services framework, the system (108) comprising:
a memory (204); and
a processing engine (208) coupled to the memory (204), configured to:
receive (702) at least one service request from at least one external system via an associated service interface of a set of service interfaces;
perform (704) a check to determine whether the at least one service request is a valid service request or an invalid service request;
upon determining the at least one service request to be the valid service request, route (706) the at least one service request to a target microservice associated with the network services framework via an associated microservice interface of a set of microservice interfaces for processing of the at least one service request;
receive (708) an acknowledgment corresponding to the at least one service request from the target microservice via the associated microservice interface; and
forward (710) the acknowledgement to the at least one external system via the associated service interface.

10. The system (108) as claimed in claim 8, wherein processing engine (208) is configured to:
upon determining the at least one service request to be the invalid service request, discard the at least one service request.

11. The system as claimed in claim 8, wherein the at least one external system corresponds to a Container Network Infrastructure Monitoring System (CNIS), and wherein the associated service interface of the set of service interfaces corresponds to a Container Network Infrastructure Monitoring System Event routing Manager (CNIS_EM) interface.

12. The system (108) as claimed in claim 8, wherein the at least one service request comprises a resource onboarding and instantiation request, a resource recovery request, a resource termination request, a resource scaling request, and a resource maintenance request.

13. The system (108) claimed as in claim 8, wherein the set of service interfaces comprises a Network Management System Event routing Manager (NMS_EM) interface, a Performance Monitoring System Event routing Manager (PM_EM) interface, a Support Ticket System Event routing Manager (STS_EM) interface, a CNIS_EM interface, a Subscriber Support System Event routing Manager (SSS_EM) interface, and a Network Slicing Management Platform Event routing Manager (NSMP_EM) interface.

14. The system (108) as claimed in claim 8, wherein the set of microservice interfaces comprises an Event routing Manager Orchestrator (EM_Or) interface, an Event routing Manager Container Network Function Manager (EM_Cnfm) interface, and an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.

15. The system (108) as claimed in claim 8, wherein the at least one service request is determined to be the valid service request or the invalid service request based on a presence or an absence of the at least one service request within a memory associated with an Event Routing Manager (ERM) (212), respectively.

16. The system (108) as claimed in claim 8, wherein the acknowledge is one of:
a positive acknowledgement indicating a successful fulfillment of the at least service request, and
a negative acknowledgement indicating a failure in fulfillment of the at least service request.

17. A user equipment (UE) (104) communicatively coupled with a network (106), the coupling comprises steps of:
receiving, by the network (106), a connection request from the UE (104);
sending, by the network (106), an acknowledgment of the connection request to the UE (104); and
transmitting a plurality of signals in response to the connection request, wherein based on the connection request, managing of communication associated with a network services framework within the network (106) is performed by a method (700) as claimed in claim 1.