DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION

SYSTEM AND METHOD FOR MANAGING A SERVICE REQUEST IN A NETWORK

2. APPLICANT(S)
Name Nationality Address
JIO PLATFORMS LIMITED INDIAN Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 360006, 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 a system and a method for managing a service request in a network.
DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression ‘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 a Support Ticket System (STS) and the MANO framework, routing service requests and responses of a trouble ticket generation, resources allocation and management.
[0006] The expression ‘Support Ticket System (STS)’ used hereinafter in the specification refers to a system that is used by network operators or service providers to handle customer complaints, questions, and technical issues pertaining to any of a 4th Generation (4G), 5G, or 6G related services and networks.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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).
[0012] 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.
[0013] 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.
[0014] The expression ‘microservice’ used hereinafter in the specification refers to a software architecture where an application is composed of small, independently deployable services, each responsible for a specific business function. The microservices communicate over well-defined application programming interfaces (APIs) and can be developed, deployed, and scaled independently
BACKGROUND
[0015] 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.
[0016] 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 the second-generation (2G) technology was introduced. The third generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth generation (4G) technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, fifth generation (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. The 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.
[0017] A support ticket system (STS) is a system, or a procedure used by network operators or service providers to handle customer complaints, questions, and technical issues pertaining to 4G, 5G, or 6G services and networks. As the business of the network operators or service providers expands with the advent of advanced technologies, effectively managing the customer complaints and resolving technical issues in a timely manner has become increasingly challenging. The growing complexity of next-generation networks requires more sophisticated mechanisms to process, manage, and resolve service requests efficiently, making it difficult to rely solely on the conventional STS systems without an additional integration and automation.
[0018] Management and Orchestration (MANO) is a framework for managing and orchestrating all network resources in the cloud platform. The MANO framework includes computing, networking, storage, containers, and virtual machine (VM) resources. The MANO is a key element of the European Telecommunications Standards Institute (ETSI) network functions virtualization (NFV) architecture. The MANO framework is required to coordinate network resources for cloud-based applications and the lifecycle management of virtual network functions (VNFs) and network services. The MANO framework is essential for ensuring an efficient allocation and orchestration of resources, including the resolution of network-related issues.
[0019] As the next-generation networks (e.g., 5G, 6G, and future generation networks) continues to expand and change, the integration between the STS and the MANO framework is crucial to ensure the efficient management of customer issues. Current systems face challenges in troubleshooting and resolving end-customer problems without a suitable interface between the STS and MANO framework.
[0020] There is, therefore, a need in the art to provide a system and a method that can overcome the problems associated with the prior arts.
SUMMARY
[0021] In an exemplary embodiment, a method for managing a service request in a network is disclosed. The method includes receiving, by a receiving unit, at least one service request from a support ticket system (STS) via a first interface. The method includes generating, by a processing engine, a trouble ticket corresponding to the at least one received service request. The method further includes analyzing, by a processing engine, generated trouble ticket to allocate one or more network services associated with a management and orchestration (MANO) framework. The method further includes routing, by the processing engine, the generated trouble ticket towards the one or more allocated network services via one or more interfaces.
[0022] In an embodiment, the method further includes monitoring, by the processing engine, a real-time status of the generated trouble ticket, wherein the real-time status corresponds to one of a successful resolution of the at least one received service request and a non-successful resolution of the at least one received service request.
[0023] In an embodiment, the method further includes processing, by the one or more allocated network services, the generated trouble ticket to perform one or more operations associated with the at least one received service request.
[0024] In an embodiment, the one or more operations associated with the at least one received service request comprise at least one of a resource provision, a resource creation, a resource initialization, and resource termination for resolution of the at least one customer issue identified in the generated trouble ticket.
[0025] In an embodiment, the method further includes receiving, by the processing engine, at least one response message from the one or more allocated network services in response to processing the at least one received service request via one or more interfaces, and forwarding, by the processing engine, the at least one response message towards the STS via the first interface.
[0026] In an embodiment, the first interface comprises a Support Ticket System_Event routing Manager (STS_EM) interface and each of the one or more interfaces comprises an Event Routing Manager_Microservice (EM_MS) interface.
[0027] In another exemplary embodiment, a system for managing a service request in a network is disclosed. The system includes a receiving unit configured to receive at least one service request from a support ticket system (STS) via a first interface. The system further includes a memory and a processing engine. The processing engine is coupled with the receiving unit to receive the at least one service request and is further coupled with the memory to execute a set of instructions stored in the memory. The processing engine is configured to generate a trouble ticket corresponding to the at least one received service request. The processing engine is configured to analyze the generated trouble ticket to allocate one or more network services associated with a management and orchestration (MANO) framework. The processing engine is further configured to route the generated trouble ticket towards the one or more allocated network services via one or more interfaces.
[0028] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
OBJECTIVES OF THE PRESENT DISCLOSURE
[0029] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows.
[0030] An objective of the present disclosure is to manage a service request in a network by providing a communication path between a Support Ticket System (STS) and a Management and Orchestration (MANO) framework via an Event Routing Manager (ERM).
[0031] Another objective of the present disclosure is to promote interoperability between the STS and the MANO framework, making it easier for the STS and the MANO framework to work seamlessly together.
[0032] Another objective of the present disclosure is to support the STS to enhance its operations and seamlessly integrate with the MANO framework by utilizing interfaces (e.g., a Support Ticket System_Event routing Manager (STS_EM) interface and an Event Routing Manager_Microservice (EM_MS) interface) associated with the ERM. This integration of the STS and the MANO framework enables the STS to access a wide range of functions supported by the MANO framework.
[0033] Another objective of the present disclosure is to automatically generate a trouble ticket for customer issues through a defined microservice in the MANO framework, ensuring faster issue resolution and real-time tracking of the status of the service requests.
[0034] 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
[0035] 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.
[0036] FIG. 1A illustrates an exemplary network architecture for implementing a system for managing a service request in a network, in accordance with an embodiment of the present disclosure.
[0037] FIG. 1B illustrates an exemplary block diagram of the system for managing the service request in the network, in accordance with an embodiment of the present disclosure.
[0038] FIG. 1C illustrates an exemplary system architecture for managing the service request in the network via interfaces associated with an Event Routing Manager (ERM), in accordance with an embodiment of the present disclosure.
[0039] FIG. 2 illustrates an exemplary flow diagram of a method for managing the service request in the network, in accordance with an embodiment of the present disclosure.
[0040] FIG. 3 illustrates another exemplary flow diagram of a method for managing the service request in the network, in accordance with an embodiment of the present disclosure, in accordance with an embodiment of the present disclosure
[0041] FIG. 4 illustrates an exemplary Management and Orchestration (MANO) framework architecture, in accordance with an embodiment of the present disclosure.
[0042] FIG. 5 illustrates another exemplary flow diagram of a method for managing the service request in the network, in accordance with an embodiment of the present disclosure.
[0043] FIG. 6 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0044] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100A - 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
100B – Block Diagram
110 – Processor(s)
112 – Memory
114 – Plurality of Interfaces
116 – Receiving unit
118 – Processing Engine
120 – Database
100C – System architecture
122 – A Plurality of Network Elements
124 – Support Ticket System (STS)
126 – Event Routing Manager (ERM)
128 – Management and Orchestration (MANO)
200, 300, 500 – Flow Diagram
400 – Management and Orchestration (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
600 – Computer System
610 – External Storage Device
620 – Bus
630 – Main Memory
640 – Read-Only Memory
650 – Mass Storage Device
660 – Communication Ports
670 – Processor
DETAILED DESCRIPTION
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] Radio Access Technology (RAT) refers to the technology used by mobile devices/ user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and 5G. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
[0056] An Event Routing Manager (ERM) is a component or a system responsible for routing events (service requests) or messages from a source to their intended recipients. The ERM plays a crucial role in managing and routing 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. A support ticket system (STS) is a system, used by network operators or service providers to handle customer complaints, questions, and technical issues. The ERM plays a vital role in communicating with the STS to manage and troubleshoot end- customer problems.
[0057] As the network (e.g., 5G, 6G, and next generation networks) continues to expand and change, it is difficult to efficiently manage and troubleshoot the end-customer problems without a suitable interface between the STS and MANO.
[0058] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing a method and a system that employs a Support Ticket System_Event routing Manager (STS_EM) interface to provide a proper connectivity between the STS and the MANO framework and to automate the process of ticket generation, troubleshooting and real-time tracking.
[0059] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0060] FIG. 1A illustrates an exemplary network architecture (100A) for implementing a system (108) for managing a service request in a network (106), in accordance with an embodiment of the present disclosure.
[0061] As illustrated in FIG. 1A, the network architecture (100A) may include one or more user equipments (UEs) (104-1, 104-2…104-N) associated with one or more users (102-1, 102-2…102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2…102-N) may collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2…104-N) may be collectively referred to as the UE (104). Although only three UE (104) are depicted in FIG. 1A, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.
[0062] 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 is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but is not limited to, intelligent, multi-sensing, network-connected devices, which may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0063] 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 is not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.
[0064] Referring to FIG. 1A, the UE (104) may communicate with the system (108) through the network (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one of a 5G network, 6G network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100A) and/or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.
[0065] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a radio access network (RAN), a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0066] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104). The network (106) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request.
[0067] Although FIG. 1A shows exemplary components of the network architecture (100A), in other embodiments, the network architecture (100A) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1A. Additionally, or alternatively, one or more components of the network architecture (100A) may perform functions described as being performed by one or more other components of the network architecture (100A).
[0068] FIG. 1B illustrates an exemplary block diagram (100B) of the system (108) for managing the service request in the network (106), in accordance with an embodiment of the present disclosure.
[0069] Referring to FIG. 1B, in an embodiment, the system (108) may include one or more processor(s) (110), a memory (112), a plurality of interface(s) (114), a receiving unit (116), a processing engine (118), and a database (120). The one or more processor(s) (110) 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) (110) and the processing engine (118) may be configured to fetch and execute computer-readable instructions stored in the memory (112) of the system (108). The memory (112) 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 (112) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0070] In an embodiment, the interface(s) (114) 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) (114) may facilitate communication through the system (108). The interface(s) (114) 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, the processing engine (118) and the database (120).
[0071] The processing engine (118) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine (118). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (118) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine (118) 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 (118). In such examples, the system may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing engine (118) may be implemented by electronic circuitry. In an embodiment, the database (120) includes data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (110) or the processing engine (118).
[0072] To manage the service request, the receiving unit (116) may initially receive at least one service request (also referred to as an event)from the STS via a first interface. In one aspect, the at least one service request may be a request to troubleshoot one or more issues. Examples of the one or more issues may include, but are not limited to, a customer complaint, a technical issue, or a query related to a service used by the customer. The at least one customer issue may be reported through the network element associated with the UE (104).The network element may be any hardware or software component that has a measurable parameter that can be reported. . Examples of the network element include a router, a switch, a host, a modem, a terminal, a dial access server, a gateway, a port, a channel, an interface, a circuit, a process, a driver, a protocol, a service, an application, etc.
[0073] The customer complaint may pertain to issues such as, but not limited to, slow internet speeds, dropped calls, or billing discrepancies. The technical issues may involve such as, but not limited to, network failures, service outages, or hardware malfunctions impacting the customer experience. In some cases, the service request may be related to general queries about account settings, service upgrades, or troubleshooting procedures.
[0074] In another aspect, the at least one service request may be an operational request. The operational request includes at least one request associated with generating trouble tickets, real-time ticket status monitoring and tracking, and initiating or terminating resources within the network infrastructure. For example, resource-related service requests may include requests for provisioning, creating, or terminating network resources to address specific service needs or optimize performance. These resource management operational requests may include network function allocations, provisioning of additional bandwidth, or termination of redundant resources. The real-time monitoring request is to continuously track the status of generated trouble tickets to ensure prompt resolution, provide updates to support teams and trigger alerts if an issue escalates. Thus, the at least one service request may address a variety of needs in managing customer satisfaction, network performance, and service reliability.
[0075] Once the at least one service request is received, the processing engine (118) may generate a trouble ticket corresponding to the at least one received service request. The trouble ticket is a record or document created in response to the service request associated with the customer issue that requires resolution. The trouble ticket serves as a detailed log of the problem, providing essential information about the issue and tracking its progress through the troubleshooting and resolution process. In an aspect, the processing engine (118) may be implemented as an Event Routing Manager (ERM). In some embodiments, the processing engine (118) may be embedded, associated with the ERM, or coupled to the ERM (not shown in FIG. 2). The ERM may be configured to manage at least one service request by providing a communication path between the STS (124) and the MANO framework (128) via the first interface. In an embodiment, the first interface may include a Support Ticket System_Event routing Manager (STS_EM) interface.
[0076] The STS_EM interface facilitates the communication between the STS and the ERM. In particular, the STS_EM interface enables the transmission of the at least one service request from the STS to the ERM for further processing. The STS_EM interface ensures that the generated trouble ticket are efficiently routed to a defined microservice within the MANO framework for resolution. The STS_EM interface operates in high availability mode, ensuring that even if one instance of the ERM fails, another instance may take over to maintain service continuity and handle the service request. In an embodiment, the generated trouble ticket may include:
• Trouble ticket ID: A unique identifier for tracking and referencing the ticket.
• Date and Time: Timestamp indicating when the ticket was created, helping with tracking.
• Issue Description: A concise summary of the problem, often including any error codes, failure messages, or a brief description of the impact.
• Priority Level: The urgency of the issue, such as "Critical," "High," "Medium," or "Low," based on the impact on services.
• Impact Scope: Information about the scale of the issue, such as the number of affected users, services, or geographical areas, which helps in prioritizing response efforts.
• Affected Components: Specific resources involved, like the names or IDs of affected CNFs, virtual machines, network services, or other infrastructure elements associated with the MANO framework.
• Alarm/Trigger Details: Description of the specific alarm or event that triggered the ticket, including any threshold metrics that were crossed (e.g., CPU usage exceeding 80%, packet loss, or dropped connections).
• Assigned Team or Individual: The team, department, or individual responsible for addressing the ticket, ensuring clear accountability.
• Resolution Status and Timeline: Current status, such as "Open," "In Progress," "Pending," or "Resolved," along with any updates on expected resolution times.
• Escalation Path: Details on the escalation path if the issue is not resolved within the stipulated time, including contacts for higher-level support or management
[0077] The processing engine (118) may analyze the generated trouble ticket to allocate one or more network services (interchangeably referred to as one or more microservices) associated with the Management and Orchestration (MANO) framework. In an embodiment, the one or more microservices are microservices in the MANO framework that may be capable of handling the at least one service request based on the generated trouble ticket.
[0078] In an embodiment, to analyze the generated trouble ticket, the processing engine (118) may extract one or more parameters associated with the generated trouble ticket, . In an embodiment, the one or more extracted parameters include at least one of the unique Ticket ID a service request type, specific issue information, priority level, etc. The extraction is performed using predefined rules or formats that specify where these parameters are located within the trouble ticket structure. For example, if the trouble ticket is formatted in JavaScript Object Notation (JSON), the processing engine (118) extracts the one or more parameters by parsing the JSON object to retrieve values associated with keys like the ticket ID and the service request type.
[0079] Based on extracting the one or more parameters from the trouble ticket, particularly the ticket ID and service request type, the processing engine (118) may evaluate the capabilities of one or more microservices in the MANO framework and may allocate the most suitable (e.g., the defined microservice) that may be capable of handling the the specific requirements outlined in the trouble ticket. This allocation may be based on a resource availability or a specialization of each microservice. For example, if the trouble ticket indicates a particular service request type, the processing engine (118) matches this type to a microservice specifically designed to handle that category of issues, allowing for targeted troubleshooting and resolution of the reported problem.
[0080] Once the generated trouble ticket is analyzed and the one or more defined microservices are allocated, the processing engine (118) routes the generated trouble ticket toward the one or more allocated microservices via one or more interfaces. In an embodiment, each of the one or more interfaces may include an Event Routing Manager_Microservice (EM_MS) interface. In an embodiment, the EM_MS interface facilitates communication between the ERM and the allocated microservice within the MANO framework. In particular, the EM_MS interface supports a high-speed and reliable communication, allowing the ERM to transmit the service request to the one or more allocated microservices, performing the required operations. The EM_MS interface ensures efficient routing and minimizes latency, helping to resolve customer issues on time.
[0081] In an embodiment, the processing engine (118) utilizes a routing table or mapping system that associates the one or more extracted parameters with at least one microservice. In an embodiment, the processing engine (118) uses a service discovery mechanism to locate the at least one microservice dynamically. The service discovery mechanism involves querying a service registry to obtain a current address and endpoint of the one or more microservices. The endpoint of the one or more microservices refers to the specific uniform resource locator (URL) or network address where the one or more microservices listens for incoming requests.
[0082] Once the generated trouble ticket is routed to the one or more allocated microservices, the one or more allocated microservices is configured to process the generated trouble ticket to perform one or more operations associated with the at least one routed service request. To further elaborate, once the trouble ticket is generated and routed to the allocated microservice, the allocated microservice may initially assign the generated trouble ticket to a human resource for troubleshooting. Depending on the resolution i.e., whether the human resource is able to handle the at least one customer issue present in the trouble ticket, the processing engine (118) may receive a request from the STS to spawn the resources (i.e., request for assigning additional resources for the trouble ticket resolution).
[0083] In case of resource spawning, when the trouble ticket remains unresolved, the one or more allocated microservices may further process the generated trouble ticket. In such embodiment, to process the generated trouble ticket, the one or more allocated microservices may perform one or more operations corresponding to the generated trouble ticket to resolve the at least one customer issue. In an embodiment, the one or more operations associated with the at least one service request include at least one of a resource provision (e.g., allocating resources), a resource creation (e.g., establishing new resources), a resource initialization (e.g., preparing resources for use), and a resource termination (e.g., terminating the resources after use).
[0084] In an example, the resource provision operation involves allocating and making available network resources required to meet the needs specified in the at least one service request. This may include assigning bandwidth, storage, or compute resources. For example, if the at least one service request specifies additional bandwidth for at least one network element, the one or more microservices adjusts the network configuration to provide the requested bandwidth. The resource creation operation refers to establishing new network resources or entities as specified by the at least one service request. This may involve creating new virtual machines, network interfaces, or storage volumes. In an embodiment, upon receiving the at least one service request to create a new resource for the trouble ticket resolution, the one or more identified microservices initiate the creation process by provisioning the necessary infrastructure, configuring the new resource, and integrating it into the existing network environment. The resource initialization operation involves preparing and configuring newly created resources, so that these resources are ready for use. This includes setting up initial configurations, applying default settings, and ensuring the resource is operational. The one or more allocated microservices initialize the resource by applying initial configurations, performing system checks, and ensuring that the resource meets the operational requirements defined in the least one service request. For example, if a new network switch is created based on the one or more parameters of the at least one service request, the one or more allocated microservices configures the switch settings and performs tests to verify its functionality. In an example, the resource termination operation involves the systematic removal and deallocation of network resources that are no longer needed, as specified by the at least one service request. This may include releasing bandwidth, deleting storage volumes, or shutting down virtual machines. Upon receiving the at least one service request to terminate resources, the one or more allocated microservices initiates the termination process by safely deactivating any active configurations, migrating any necessary data, and ensuring that the resources are completely decommissioned. For example, if a virtual machine is no longer required, the one or more allocated microservices may first ensure that no active processes are running, then safely shut down the instance, and finally delete the associated storage and network interfaces to free up resources.
[0085] In an embodiment, upon processing the generated trouble ticket, the processing engine (118) may receive at least one response message from the one or more allocated microservices via the one or more interfaces. In an aspect, the at least one response message indicates a real-time status of the processed trouble ticket. The real-time status of the trouble ticketmay include at least one of a success status and a failure status. To further elaborate, after processing the generated trouble ticket, the one or more allocated microservices generates the at least one response message. The at least one response message is generated based on an outcome of the trouble ticket processing and includes information about the status of the generated trouble ticket. The real-time status may correspond to one of a successful resolution of the at least one received service request and a non-successful resolution of the at least one received service request. Based on the processing, the processing engine (118) provides feedback to the STS regarding the success or failure of the operations performed. The one or more interfaces (e.g., EM_MS) is a designated communication channel used specifically for receiving the service request and sending the status of the processed service request from the at least one microservice to the processing engine (118). The processing engine (118) may forward the real-time status of the processed trouble ticket towards the STS via the first interface.
[0086] In some embodiments, the processing engine (118) may be further configured to monitor the real-time status of the generated trouble ticket. In order to monitor the real-time status, the system (108) may employ the following techniques:
• Centralized Dashboard for Visualization and Tracking: The centralized dashboard is often used to visualize and track tickets in real time. The processing engine (118) may utilize a centralized dashboard, which provides a real-time view of the generated trouble tickets and their current status. This dashboard may display updates on ticket status such as “Open,” “In Progress,” “Pending,” or “Resolved.” The processing engine (118) regularly updates the dashboard with the latest status of each ticket, allowing operators to visualize active incidents, newly created tickets, and any status changes as they happen. In some embodiments, the dashboard may use third-party visualization tools or built-in analytics modules of the MANO framework to enhance monitoring with customized visualizations and alerts, helping support teams stay informed of critical issues.
• Event Streaming and Real-Time Data Aggregation: For real-time status monitoring, the processing engine (118) may utilize event-streaming services, particularly to push updates from the MANO framework to the dashboard or the STS. When the status of a trouble ticket changes, an event message (e.g., an alarm) is immediately sent from the processing engine to the streaming service. This message is then pushed to relevant monitoring systems, dashboards, or support team members subscribed to these events. Event-streaming services ensure that updates occur in real time, minimizing any delay between the status change and when the support teams are informed.
• Push Notifications and Alerts for Immediate Attention: To ensure timely action on urgent trouble tickets, the processing engine (118) may generate push notifications whenever a ticket status changes, especially if it requires immediate attention (e.g., escalated or “Critical” tickets). These notifications may be configured to alert operators via SMS, email, or messaging applications. Each notification typically includes key information from the trouble ticket, such as ticket ID, issue description, priority, and any recent updates, allowing support teams to assess and respond to the issue without delay.
• Real-Time application programming interface (API) Integration with Ticketing System: The processing engine (118) may also use APIs to facilitate real-time communication with the STS. When a trouble ticket is generated or updated, the processing engine (118) communicates with the ticketing system via the API, automatically synchronizing data on the current status of the ticket. The API integration allows for seamless data flow, ensuring that both the ticketing system and the centralized dashboard have up-to-date information without manual intervention.
• Automated Alarm Management within MANO Monitoring Tools: In cases where a trouble ticket is generated due to a specific network alarm or threshold breach, the MANO framework’s monitoring tools can continuously check the status of associated metrics (e.g., CPU utilization, memory usage, network latency). The processing engine (118) may be configured to monitor these parameters in real-time, triggering updates to the trouble ticket as the conditions change. For instance, if the initial cause of the trouble ticket was a resource overload and the issue persists, the ticket may remain open and escalate if not resolved. Alternatively, if the parameters return to normal, the ticket can automatically update its status towards resolution.
[0087] FIG. 1C illustrates an exemplary system architecture (100C) for managing the service request in the network (106), in accordance with an embodiment of the present disclosure. The system architecture (100C) includes a network element 1 (122-1) and a network element 2 (122-2) (collectively referred to as a network element (122)). The system architecture (100C) further includes the STS (124), an ERM (126), and the MANO framework 128.
[0088] In an embodiment, the network element (122) is a component responsible for managing network resources and services. The network element may be any hardware or software component that has a measurable parameter that can be reported. Examples of the network element include a router, a switch, a host, a modem, a terminal, a dial access server, a gateway, a port, a channel, an interface, a circuit, a process, a driver, a protocol, a service, an application, etc. The STS (124) receives data directly from the customers (e.g., end-users or subscribers) when the customer encounters issues or needs support. The STS (124) is the system or procedure used by network operators or service providers to handle one or more customer complaints, questions, and technical issues.
[0089] The STS (124) collects customer-related data, such as complaints or service disruptions, and sends these issues as a service request to the ERM via the STS_EM interface (e.g., the first interface). The service request may also include an operational request for trouble ticket generation, continuous real-time monitoring of the generated trouble ticket status, and resource management-related requests. The resource management requests may involve resource provisioning, resource creation, or resource termination. The STS_EM interface enhances the existing (European Telecommunications Standards Institute) ETSI MANO standard, introducing new functionalities and capabilities. The STS_EM interface enables advanced automation features, allowing for more efficient handling of service requests and improved scalability within the network management process. By employing the STS_EM interface, the STS (124) may seamlessly interact with the MANO framework (128), promoting interoperability between the two systems and ensuring smoother collaboration. Through the STS_EM interface, the STS (124) may automate critical processes, such as trouble ticket generation, troubleshooting, and real-time tracking, simplifying customer issue resolution and reducing manual intervention.
[0090] In an embodiment, the ERM (126) may be configured to manage the service request by providing communication between the STS (124) and the MANO framework (128). The ERM (126) acts as an intermediary between the STS (124) and the MANO framework (128).
[0091] In an aspect, the ERM (126) may be configured to receive a plurality of service requests (events), i.e., each service request and may be further configured to publish the plurality of service requests. The plurality of service requests may be subscribed to a defined network service, i.e., the allocated microservice (also referred to as a subscriber microservice).
[0092] In some embodiments, the ERM (126) may be configured to provide a deferred delivery of the acknowledgement corresponding to the microservice (interchangeably used as the network service) in case the specific microservice fails. In such a scenario, the ERM (126) may be configured to store the acknowledgement in the memory and may communicate the acknowledgement to the allocated microservice after a predefined time (e.g., after 1 hour).
[0093] In an operative aspect, if the event (i.e., the at least one service request) is received by the ERM (126), then the ERM (126) 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 (126) may discard the received event. If the event exists, the ERM (126) may be configured to allocate the defined microservice corresponding to the received event.
[0094] In an embodiment, the ERM (126) may be configured to efficiently distribute events to one or more microservices based on a type of the event. Further, the ERM (126) may add multiple events without affecting the functionality or performance of the system 108. The ERM supports dynamic routing in event-driven systems by enabling a system to adapt to changing requirements. The ERM (126) 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 (126) may incorporate service discovery mechanisms in a distributed system to dynamically locate and route the events to the defined microservice. In an aspect, the ERM (126) may be configured to provide advanced automation features and improved scalability.
[0095] In an operative aspect, the ERM (126) may operate on an event-based architecture and a publish/subscribe architecture and take advantage of both architectures. The ERM (126) 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 defined microservices based on the type of the events.
[0096] In operation, the ERM (126) may accept the event (i.e., the at least one service request) from the STS (124) on the STS_EM interface and route the event to the one or more allocated microservices of the MANO framework (128) via each of the one or more interfaces (e.g., EM_MS interface) for processing the event.
[0097] The EM_MS interface facilitates communication between the ERM (126) and the MANO framework (128). The EM_MS interface is responsible for routing the service request received from the ERM (126) to the one or more allocated microservices within the MANO framework (128). The EM_MS interface ensures that the one or more allocated microservices can process the routed service request effectively, allowing for the execution of tasks such as the trouble ticket generation for the routed service request and troubleshooting of the routed service request by resource provisioning, resource creation, resource initialization, or resource termination based on the service request. The EM_MS interface also provides feedback and status updates to the ERM (126) regarding the execution of these requests.
[0098] FIG. 2 illustrates an exemplary flow diagram of a method (200) for managing the service requests in the network (106), in accordance with an embodiment of the present disclosure.
[0099] At step (202), the ERM (126) accepts the at least one service request related to the customer issue from the STS (124). In an aspect, the at least one service request may be a request to troubleshoot customer-reported issues. Examples of the at least one customer issue may include, but are not limited to, a customer complaint, a technical issue, or a generic query related to a service used by the customer.
[00100] At step (204), the ERM (126) determines 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 the memory (e.g., the memory 112) associated with the ERM (126), then the at least one service request is the valid service request. The memory associated with the ERM (126) 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 stores the repository of valid service request templates, or the identifiers may be present within the ERM (126).
[00101] At step (206), if the at least one service request is the invalid service request valid, then the ERM (126) may discard the at least one service request, upon determining that the at least one service request does not exist in the memory of the ERM (126).
[00102] Further, upon determining the at least one service request to be the valid service request, at step (208), the ERM (126) may route the at least one service request to an allocated microservice (i.e., a defined MS). Once the service request is routed to the defined microservice, the defined microservice is configured to process the at least one routed service request to resolve the at least one customer issue. In an embodiment, to process the at least one routed service request, the defined microservice may generate a trouble ticket corresponding to the at least one routed service request. Once the trouble ticket is generated, the allocated microservice may assign the generated trouble ticket to a human resource for troubleshooting. Depending on the resolution i.e., whether the human resource is able to handle the at least one customer issue present in the trouble ticket, the processing engine (118) may receive a request from the STS to spawn the resources (i.e., a request for assigning additional resources for the trouble ticket resolution). The spawning of the resources on the MANO framework (128) corresponds to a process of creating, provisioning or initializing new resources, such as virtual machines, containers, or network functions, based on incoming service requests, i.e., the at least one service request. This spawning process involves initializing and configuring the resources, so that the resources are ready for use within the MANO framework (128).
[00103] In case of the resource spawning, at step (208), the ERM (126) may route the event to the defined microservice (which can handle the event efficiently). To determine the defined microservice that is best suited to handle the event, the ERM (126) may analyze the event (e.g., the service request). For example, The ERM (126) analyzes the service request by identifying the type of customer issue (e.g., resource allocation, service disruption, etc.), the urgency of the issue, and the network element involved.
[00104] To resolve the at least one customer issue corresponding to the generated trouble ticket, at step (210), the defined microservice may perform one or more operations. In an embodiment, the one or more operations include at least one of a resource provision (e.g., allocating resources), a resource creation (e.g., establishing new resources), and a resource initialization (e.g., preparing resources for use). Each microservice (MS) within the MANO framework (also referred to as the MANO MS (128)) is designed with specific capabilities. For instance, some microservices are specialized in provisioning resources, while others handle resource initialization or troubleshooting. Based on the analyzed service request, the ERM (126) allocates the defined microservice with the necessary capabilities to address the issue. For example, if the service request requires resource initialization, the ERM (126) routes the request to the microservice that handles that specific operation.
[00105] At step (212), the ERM (126) receives the response signal from the defined microservice from the MANO framework (128) (e.g., MANO MS (128)) when the resource is provisioned, created or initialized successfully by the MANO MS (128).
[00106] FIG. 3 illustrates another exemplary flow diagram of the method (300) for managing the service request in the network (106), in accordance with an embodiment of the present disclosure.
[00107] At step (302), the STS (124) sends the service request related to an event to the ERM (126) through the STS_EM interface.
[00108] At step (304), the ERM (126) transmits the received provision service request to a network functions virtualization orchestrator (NFVO) (130) as the provision service request. The NFVO (130) is a functional element of the MANO framework (128).
[00109] At step (306), the NFVO (130) stores the received provision service request for generating a processed service request.
[00110] At step (308) of the method (300), the NFVO (130) transmits the processed service request to the ERM (126) in response to the received provision service request. The NFVO (130) generates the processed service request based on the provision service request it received. The processed service request includes details about the required processing actions, such as trouble ticket generation, resource provisioning or configuration changes. The NFVO (130) validates the provision service request to ensure that the provision service request meets all required criteria and compliance with the network policies and prepares the provision service request for execution.
[00111] At step (310) of the method (300), the ERM (126) transmits the processed service request to a container network function (CNF) manager (132) of the MANO framework (128).
[00112] At step (312) of the method (300), the CNF manager (132) performs onboard, instantiation and termination functions/operations on the process service request. The onboarding operation includes loading and preparing the necessary software or configurations required for the new cloud-native function. The instantiation operation includes creating and deploying the cloud-native function instances based on the specifications in the service request. The termination operation includes removing or deactivating cloud-native function instances that are no longer needed.
[00113] At step (314), the CNF manager (132) transmits an infrastructure orchestration request to the ERM (126). The infrastructure orchestration request includes information about the current status of the onboarded, instantiated, or terminated functions and may also involve instructions for managing or adjusting infrastructure resources as needed.
[00114] At step (316), the ERM (126) transmits the infrastructure orchestration request to a virtualized infrastructure manager (VIM) (134) of the MANO framework (128).
[00115] At step (318), the VIM (134) processes the received infrastructure orchestration request. In an embodiment, the VIM (134) processes the received infrastructure orchestration request by decoding and interpreting the request details, which may involve instructions for managing virtualized resources such as servers, storage, or network elements. The VIM (134) then performs the necessary actions according to the request, such as allocating resources, adjusting configurations, or scaling infrastructure components.
[00116] At step (320), the VIM processes the received infrastructure orchestration request and transmits an acknowledgement signal to the ERM (126). In an embodiment, once the required operation is complete, the VIM (134) transmits an acknowledgment signal back to the ERM (126) to confirm that the orchestration request has been successfully processed. The acknowledgment includes status information indicating whether the request was completed as expected or if any issues were encountered.
[00117] At step (322), the ERM (126) sends a service request acknowledgement signal (response signal) to the STS (124) in response to the received acknowledgement signal from the VIM (134). The ERM (126), having received the confirmation from the acknowledgement signal, responds by sending a corresponding acknowledgment signal to the STS (124), indicating that the received service request has been successfully addressed and processed.
[00118] FIG. 4 illustrates a MANO framework architecture 400, in accordance with embodiments of the present disclosure.
[00119] 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. The interconnected 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).
[00120] 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 (126) 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 may be deployed simultaneously, and other relevant settings.
[00121] 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 (126). The modules may be responsible for determining the target microservice within the MANO framework (128) framework based on a type of resource allocation required. The modules may utilize a mapping of service request types to target microservices maintained by the ERM (126) 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.
[00122] The platform foundation services (406) may support an asynchronous event-based processing model implemented by the ERM (126), enabling concurrent handling of multiple service requests. They may also facilitate bi-directional communication interfaces (STS_EM and EM_MS) used by the ERM (126) to interact with the external systems (e.g., the STS (124)) and the MANO framework (128) framework microservices. The platform foundation services (406) may include microservices elastic load balancer, identity & access manager, command line interface (CLI), central logging manager, and the ERM. 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.
[00123] 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 (126). The platform core services (408) may include NFV infrastructure monitoring manager, assurance manager, performance manager, policy execution engine, capacity monitoring manager, release management repository, configuration manager & Golden configuration template (GCT), NFV platform decision analytics platform, Not Only SQL database (NoSQL DB), platform schedulers & jobs, VNF backup & upgrade manager, and 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.
[00124] 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 (126) to distribute the service requests across multiple instances of the MANO framework (128) microservices.
[00125] 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 platform external API adapter and gateway, generic decoder, and indexer, orchestration adapter, API adapter, and 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.
[00126] The ERM (126) may interact with all these modules to facilitate an end-to-end process of the service request handling. The ERM (126) 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 (128) 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.
[00127] FIG. 5 illustrates an exemplary flow diagram of a method (500) for managing the service request in the network, in accordance with an embodiment of the present disclosure, in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1, 2, 3, and 4.
[00128] At step 502, the method (500) includes receiving, by the receiving unit (116), at least one service request from a support ticket system (STS) via a first interface. In an embodiment, the first interface is the Support Ticket System_Event routing Manager (STS_EM) interface.
[00129] At step 504, the method (500) includes generating, by a processing engine (118), a trouble ticket corresponding to the at least one received service request. The generated trouble ticket may include the ticket ID the date and time the ticket was created, the issue description, the priority level (such as "Critical," "High," "Medium," or "Low") based on the impact, information of the number of affected users, services, or regions, alarm or trigger details (specific conditions that activated the trouble ticket, such as threshold breaches (e.g., CPU usage exceeding 80%)), and resolution status and timeline fields provide a current status update (e.g., "Open," "In Progress," "Resolved").
[00130] At step 506, the method (500) includes analyzing, by a processing engine (118), the generated trouble ticket to allocate one or more network services (also referred to as one or more microservices) associated with a management and orchestration (MANO) framework.
[00131] At step 508, the method (500) includes routing, by the processing engine (118), the generated trouble ticket towards the one or more allocated network services via one or more interfaces. In an embodiment, each of the one or more interfaces is the Event Routing Manager_Microservice (EM_MS) interface.
[00132] In an embodiment, the method (500) further includes monitoring, by the processing engine (118), a real-time status of the generated trouble ticket. In an aspect, the real-time status corresponds to one of a successful resolution of the at least one received service request and a non-successful resolution of the at least one received service request.
[00133] In an embodiment, the method (500) further includes processing, by the one or more allocated network services, the generated trouble ticket to perform one or more operations associated with the at least one received service request. In an embodiment, the one or more operations include at least one of a resource provision, a resource creation, a resource initialization, and a resource termination.
[00134] In an embodiment, the method (500) further includes receiving, by the processing engine (118), at least one response message from the one or more allocated network services in response to processing the generated trouble ticket via the one or more interfaces and forwarding, by the processing engine (118), the at least one response message towards the STS via the first interface.
[00135] FIG. 6 illustrates an exemplary computer system (600) in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 6, the computer system (600) may include an external storage device (610), a bus (620), a main memory (630), a read only memory (640), a mass storage device (650), a communication port (660), and a processor (670). A person skilled in the art will appreciate that the computer system (600) may include more than one processor (670) and communication ports (660). Processor (670) may include various modules associated with embodiments of the present disclosure.
[00136] In an embodiment, the communication port (660) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port (660) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects.
[00137] In an embodiment, the memory (630) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor (670).
[00138] In an embodiment, the mass storage (650) may be any current or future mass storage solution, which may be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).
[00139] In an embodiment, the bus (620) communicatively couples the processor(s) (670) with the other memory, storage and communication blocks. The bus (620) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (670) to the computer system (600).
[00140] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (620) to support direct operator interaction with the computer system (600). Other operator and administrative interfaces may be provided through network connections connected through the communication port (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.
[00141] 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.
[00142] 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.
[00143] 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.
[00144] The present disclosure provides technical advancement related to managing the service request between the STS and the MANO framework. This advancement addresses the limitations of existing solutions by introducing the ERM to route the service request to resolve customer issues efficiently. The disclosure involves new interface integrations, such as the STS_EM, which significantly improve automation, scalability, and interoperability between STS and MANO. By implementing the interface and advanced routing techniques, the present disclosure enhances real-time ticket generation, troubleshooting, and resource allocation, resulting in faster issue resolution, improved network management, and reduced operational overhead.
TECHNICAL ADVANTAGES OF THE PRESENT DISCLOSURE
[00145] The present disclosure provides a system and a method for managing a service request between the STS and the MANO framework through the integration of the ERM.
[00146] The present disclosure provides improved scalability and automation by enabling seamless communication between the STS and the MANO framework via enhanced interfaces i.e., the STS_EM, facilitating the real-time trouble ticket generation and troubleshooting.
[00147] The present disclosure promotes enhanced interoperability between the STS and MANO, simplifying the process of trouble ticket generation, resource provisioning, creation or initialization for resolving customer issues.
[00148] The present disclosure reduces operational overhead by introducing advanced routing capabilities that optimize service request handling and ensure continuity even in failure scenarios, improving overall network performance and management efficiency.
,CLAIMS:CLAIMS
We claim:
1. A method (500) for managing a service request in a network, the method (500) comprising:
receiving (502), by a receiving unit (116), at least one service request from a support ticket system (STS) (124) via a first interface;
generating (504), by a processing engine (118), a trouble ticket corresponding to the at least one received service request;
analyzing (506), by the processing engine (118), the generated trouble ticket to allocate one or more network services associated with a management and orchestration (MANO) framework (128); and
routing (508), by the processing engine (118), the generated trouble ticket towards the one or more allocated network services via one or more interfaces.

2. The method (500) as claimed in claim 1, further comprising:
monitoring, by the processing engine (118), a real-time status of the generated trouble ticket, wherein the real-time status corresponds to one of a successful resolution of the at least one received service request and a non-successful resolution of the at least one received service request.

3. The method (500) as claimed in claim 1, further comprising:
processing, by the one or more allocated network services, the generated trouble ticket to perform one or more operations associated with the at least one received service request.
4. The method (500) as claimed in claim 3, wherein the one or more operations associated with the at least one received service request comprise at least one of a resource provision, a resource creation, a resource initialization, and a resource termination.
5. The method (500) as claimed in claim 3, further comprising:
receiving, by the processing engine (118), at least one response message from the one or more allocated network services in response to processing the generated trouble ticket via the one or more interfaces; and
forwarding, by the processing engine (118), the at least one response message towards the STS (124) via the first interface.
6. The method (500) as claimed in claim 1, wherein the first interface comprises a Support Ticket System_Event routing Manager (STS_EM) interface, and each of the one or more interfaces comprises an Event Routing Manager_Microservice (EM_MS) interface.
7. A system (108) for managing a service request in a network (106), the system (108) comprising:
a receiving unit (116) configured to receive at least one service request from a support ticket system (STS) (124) via a first interface;
a memory (112); and
a processing engine (118) coupled with the receiving unit (116) to receive the at least one service request and is further coupled with the memory (112) to execute a set of instructions stored in the memory (112), the processing engine (118) is configured to:
generate a trouble ticket corresponding to the at least one received service request;
analyze the generated trouble ticket to allocate one or more network services associated with a management and orchestration (MANO) framework (128); and
route the generated trouble ticket towards the one or more allocated network services via one or more interfaces.

8. The system (108) as claimed in claim 7, wherein the processing engine (118) is further configured to:
monitor a real-time status of the generated trouble ticket, wherein the real-time status corresponds to one of a successful resolution of the at least one received service request and a non-successful resolution of the at least one received service request.

9. The system (108) as claimed in claim 7, wherein the one or more allocated network services is further configured to:
process the generated trouble ticket to perform one or more operations associated with the at least one received service request.
10. The system (108) as claimed in claim 9, wherein the one or more operations associated with the at least one received service request comprise at least one of a resource provision, a resource creation, a resource initialization, and a resource termination.

11. The system (108) as claimed in claim 7, wherein the processing engine (118) is further configured to:
receive at least one response message from the one or more allocated network services in response to processing the at least one received service request via the one or more interfaces; and
forward the at least one response message towards the STS (124) via the first interface.

12. The system (108) as claimed in claim 7, wherein the first interface comprises a Support Ticket System_Event routing Manager (STS_EM) interface and each of the one or more interfaces comprises an Event Routing Manager_Microservice (EM_MS) interface.