System for assigning workflow approval paths in a network and a method thereof

Abstract

The present disclosure may relate to a system (102) for automatically performing workflow approval in a radio access network. The system may comprise a memory (204) and one or more processors (202) coupled to the memory. The processors may be configured to execute instructions to: receive a request from an requesting entity via a requester module (212); select a service server from multiple servers (214a, 214b, 214c) using a first load balancer (302); process the request and assign a workflow by the selected server; select a change engine from multiple engines (216a, 216b) using a second load balancer (304); communicate the workflow to the selected engine; execute the workflow; and determine its execution status. The system efficiently manages network optimization tasks through automated workflow assignment, load-balanced processing, and status tracking. This approach may streamline approval processes, enhance resource utilization, and improve overall management of radio access network operations.

Description

SYSTEM FOR ASSIGNING WORKFLOW APPROVAL PATHS IN A NETWORK AND A METHOD THEREOFFIELD OF THE DISCLOSURE

[0001] The embodiments of the present disclosure generally relate to telecommunications networks. In particular, it relates to assigning workflow approval paths in radio access networks (RANs).DEFINITION

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

[0003] Radio access network" refers to the part of a mobile telecommunications system that connects individual devices to other parts of the network through radio connections.

[0004] "Workflow" refers to a sequence of processes through which a piece of work passes from initiation to completion in the context of network optimization tasks.

[0005] Load balancer" refers to a device or software that distributes network or application traffic across different servers to ensure no single server bears too much demand.

[0006] Service server" refers to a server responsible for processing requests and assigning appropriate workflows in the system.

[0007] "Change engine " refers to a component responsible for executing the assigned workflows and implementing the requested changes in the network.

[0008] Remote Electrical Tilt (RET)" refers to an adjustable parameter that controls the vertical angle of an antenna beam in the base station of a cell, allowing for remote adjustment of the antenna's coverage area without physical manipulation.

[0009] "Key Performance Indicator (KPI)" refers to a measurable value that demonstrates how effectively the network is achieving key operational objectives.

[0010] "Project type" refers to a category of network optimization task, such as network coverage improvement or capacity enhancement.

[0011] "Activity type" refers to a specific action within a project type, such as antenna adjustment or power optimization.

[0012] "Approval flow" refers to the process of obtaining necessary permissions before implementing changes in the network, which may involve single or multiple levels of approval.BACKGROUND OF THE DISCLOSURE

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

[0014] In telecommunications, particularly in radio access networks (RANs), efficient workflow management is crucial for optimizing network performance and resource utilization. Various teams within an organization work on different operations related to network maintenance, optimization, and expansion. Synchronizing these teams and their activities is essential to optimizing resource utilization and process efficiency.

[0015] Conventional workflow approval systems in RANs face several challenges. For instance, when a network engineer needs to add an antenna, the engineer must initiate an approval workflow. This process typically involves the engineer submitting a request online to activate a corresponding service approval workflow. However, this approach becomes problematic when the approval processrequires dynamic updates to the workflow structure. Such updates often lead to increased time consumption and higher operational costs.

[0016] Furthermore, when multiple users (e.g., network engineers) initiate numerous requests simultaneously, maintaining individual workflows for each request becomes cumbersome and inefficient. Due to the complexity of managing multiple parallel workflows, this situation can lead to bottlenecks in the approval process, delays in implementation, and potential errors.

[0017] Existing solutions often lack the flexibility to adapt to different types of requests, such as problem-specific, activity-specific, or project-specific workflows. This limitation results in a one-size-fits-all approach that may not adequately address the unique requirements of various network optimization tasks. Moreover, conventional systems typically lack automated validation of key performance indicators (KPIs) following the execution of approved changes. This deficiency can result in undetected performance degradations or inefficiencies in the network, as there is no systematic way to verify the impact of implemented changes.

[0018] Additionally, existing workflow management systems in RANs often struggle with resource allocation, particularly when dealing with complex approval hierarchies or requiring multiple approval levels for certain types of requests.

[0019] Conventional systems and methods face difficulty in providing a comprehensive, flexible, and automated approach to workflow approval, execution, and validation in radio access networks. These systems struggle to efficiently handle multiple simultaneous requests, adapt to different project types, and integrate approval processes with execution and performance validation.

[0020] There is, therefore, a need in the art to provide a method and a system that can overcome the shortcomings of the existing prior arts.SUMMARY OF THE DISCLOSURE

[0021] In an exemplary embodiment, a system for assigning workflow approval paths in a radio access network is described. The system comprises a requester module configured to receive at least one request from at least one requesting entity. The system further comprises a first load balancer configured to select a service server from a plurality of service servers for forwarding the received at least one request, wherein the selection is based on server load distribution parameters comprising current request volume per server, server availability status, and predefined request handling thresholds. The selected service server is configured to process the received at least one request and assign at least one workflow corresponding to the received at least one request. The system also comprises a second load balancer configured to select a change engine from a plurality of change engines and communicate the assigned at least one workflow to the selected change engine for execution. The selected change engine is configured to execute the at least one workflow assigned to the selected change engine. The selected change engine is further configured to determine a status of the executed at least one workflow.

[0022] In some embodiments, the requester module is further configured to receive a selection of an activity type and a project type as part of the at least one request, wherein the activity type is a categorization defining a specific network optimization action to be performed, selected from a predefined set comprising antenna adjustment, power optimization, and frequency retuning, wherein the project type is a categorization defining a broader optimization objective, selected from a predefined set comprising coverage improvement, capacity enhancement, and interference reduction, and wherein the selection of the activity type and the project type corresponds to a radio access network optimization task assigned to the requesting entity.

[0023] In some embodiments, the selected service server is further configured to assign an approval workflow for the assigned workflow based on atleast one of the project type and the activity type, wherein the approval workflow defines a sequence of authorization steps required before execution of the assigned workflow, wherein the approval workflow comprises either a single level approval requiring authorization from one designated approver or a multiple level approval requiring sequential authorization from two or more designated approvers in a predetermined hierarchy.

[0024] In some embodiments, the selected change engine is further configured to validate key performance indicators (KPIs) for a cell associated with the project type after execution of the at least one assigned workflow, wherein the cell is a geographical area served by a base station in the radio access network.

[0025] In some embodiments, the selected change engine is further configured to execute a predefined action based on the validated KPIs, wherein the predefined automatic action is associated with the selected project type or the selected activity type and is executed only if the validated KPIs meet a predetermined criteria specified for each of the selected project type or the selected activity type.

[0026] In some embodiments, the selected change engine is further configured to calculate updated key performance indicators (KPIs) after completion of a network parameter adjustment in the cell, wherein the network parameter adjustment comprises a remote electrical tilt (RET) change execution, and wherein the RET change execution is an implementation of at least one activity type related to antenna configuration. The selected change engine is further configured to revert an RET value to a previous setting if the updated KPIs indicate a degradation in performance of the cell or sites associated with the cell, wherein the degradation is determined by comparing the updated KPIs to a set of predetermined performance thresholds.

[0027] In some embodiments, the at least one workflow assigned to the selected change engine comprises an approval workflow that defines authorization requirements and approver roles for the requested network changes, an executionworkflow that defines the sequence of technical operations to implement the authorized network changes, and a validation workflow that defines procedures for measuring and evaluating network performance after implementation of the changes.

[0028] In some embodiments, the determined status comprises an executed status and an unexecuted status.

[0029] In some embodiments, the selected change engine is further configured to mark the at least one assigned workflow as complete when the determined status is the executed status. The selected change engine is further configured to retry an execution of the at least one assigned workflow after a predefined time interval when the determined status is the unexecuted status, wherein the retrying is performed for a predetermined maximum number of retry attempts, and wherein upon reaching the maximum number of retry attempts without successful execution, the selected change engine marks the workflow with a terminal failure status and generates a notification for manual intervention.

[0030] In some embodiments, the selected change engine is further configured to generate a response comprising the determined status and an execution response.

[0031] In another exemplary embodiment, a method for assigning workflow approval paths in a radio access network is described. The method comprises receiving, by a requester module, at least one request from at least one requesting entity. The method further comprises selecting, by a first load balancer, a service server from a plurality of service servers for forwarding the received at least one request, wherein the selection is based on server load distribution parameters comprising current request volume per server, server availability status, and predefined request handling thresholds. The method also comprises processing, by the selected service server, the received at least one request to assign at least one workflow corresponding to the received at least one request. The method further comprises selecting, by a second load balancer, a change engine from a plurality ofchange engines. The method also comprises communicating, by the second load balancer, the assigned at least one workflow to the selected change engine for execution. The method further comprises executing, by the selected change engine, the at least one workflow assigned to the selected change engine. The method also comprises determining, by the selected change engine, a status of the executed at least one workflow.

[0032] In some embodiments, the method further comprises receiving, by the requester module, a selection of an activity type and a project type as part of the at least one request, wherein the activity type is a categorization defining a specific network optimization action to be performed, selected from a predefined set comprising antenna adjustment, power optimization, and frequency retuning, wherein the project type is a categorization defining a broader optimization objective, selected from a predefined set comprising coverage improvement, capacity enhancement, and interference reduction, and wherein the selection of the activity type and the project type corresponds to a radio access network optimization task assigned to the requesting entity.

[0033] In some embodiments, the method further comprises assigning, by the selected service server, an approval workflow for the assigned workflow based on at least one of the project type and the activity type, wherein the approval workflow defines a sequence of authorization steps required before execution of the assigned workflow, wherein the approval workflow comprises either a single level approval requiring authorization from one designated approver or a multiple level approval requiring sequential authorization from two or more designated approvers in a predetermined hierarchy.

[0034] In some embodiments, the method further comprises validating, by the selected change engine, key performance indicators (KPIs) for a cell associated with the project type after execution of the at least one assigned workflow, wherein the cell is a geographical area served by a base station in the radio access network.

[0035] In some embodiments, the method further comprises executing, by the selected change engine, a predefined action based on the validated KPIs, wherein the predefined automatic action is associated with the selected project type or the selected activity type and is executed only if the validated KPIs meet a predetermined criteria specified for each of the selected project type or the selected activity type.

[0036] In some embodiments, the method further comprises calculating, by the selected change engine, updated key performance indicators (KPIs) after completion of a network parameter adjustment in the cell, wherein the network parameter adjustment comprises a remote electrical tilt (RET) change execution, and wherein the RET change execution is an implementation of at least one activity type related to antenna configuration. The method further comprises reverting, by the selected change engine, an RET value to a previous setting if the updated KPIs indicate a degradation in performance of the cell or sites associated with the cell, wherein the degradation is determined by comparing the updated KPIs to a set of predetermined performance thresholds.

[0037] In some embodiments, the at least one workflow assigned to the selected change engine comprises an approval workflow that defines authorization requirements and approver roles for the requested network changes, an execution workflow that defines the sequence of technical operations to implement the authorized network changes, and a validation workflow that defines procedures for measuring and evaluating network performance after implementation of the changes.

[0038] In some embodiments, the determined status comprises an executed status and an unexecuted status.

[0039] In some embodiments, the method further comprises marking, by the selected change engine, the at least one assigned workflow as complete when the determined status is the executed status. The method further comprises retrying, by the selected change engine, an execution of the at least one assigned workflow aftera predefined time interval when the determined status is the unexecuted status, wherein the retrying is performed for a predetermined maximum number of retry attempts, and wherein upon reaching the maximum number of retry attempts without successful execution, the selected change engine marks the workflow with a terminal failure status and generates a notification for manual intervention.

[0040] In some embodiments, the method further comprises generating, by the selected change engine, a response comprising the determined status and an execution response.

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

[0042] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.

[0043] An object of the present disclosure is to provide a system and a method that automatically performs workflow approval in a radio access network.

[0044] An object of the present disclosure is to handle multiple activities simultaneously, allowing for efficient management of various network optimization tasks.

[0045] An object of the present disclosure is to enable a single-level approval, or a multi-level approval based on the project type, ensuring appropriate oversight for different types of network changes.

[0046] An object of the present disclosure is to validate key performance indicators (KPIs) after executing a workflow, ensuring that network changes result in improved performance.

[0047] An object of the present disclosure is to manage and route various types of requests to the appropriate teams and workflows, streamlining the process of network optimization.

[0048] An object of the present disclosure is to provide a user-friendly interface where at least one requesting entity can submit their requests, selecting appropriate activity types and project types.

[0049] An object of the present disclosure is to implement automatic assignment of workflows based on the selected project type, reducing manual intervention and potential errors.

[0050] An object of the present disclosure is to integrate approval, execution, and validation processes into a cohesive workflow, ensuring seamless progression from request to implementation.

[0051] An object of the present disclosure is to provide automatic calculation and monitoring of KPIs following network changes, particularly after remote electrical tilt (RET) adjustments.

[0052] An object of the present disclosure is to implement automatic corrective actions, such as reverting RET settings, when KPIs indicate performance degradation.

[0053] An object of the present disclosure is to improve the efficiency and effectiveness of radio access network optimization processes through automation and intelligent workflow management.BRIEF DESCRIPTION OF DRAWINGS

[0054] 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 notnecessarily 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 the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0055] FIG. 1 illustrates an exemplary network architecture for implementing a system for automatically performing workflow approval in a radio access network (RAN), in accordance with embodiments of the present disclosure.

[0056] FIG. 2 illustrates an exemplary micro service-based architecture of the system, in accordance with embodiments of the present disclosure.

[0057] FIG. 3 illustrates an exemplary block diagram of the system for automatically performing workflow approval, in accordance with embodiments of the present disclosure.

[0058] FIG. 4 illustrates an exemplary flow diagram for a method for automatically performing workflow approval in the RAN, in accordance with embodiments of the present disclosure.

[0059] FIG. 5 illustrates another exemplary flowchart of the method for automatically performing workflow approval, in accordance with embodiments of the present disclosure.

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

[0061] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture102 - System104 - Network106 - Centralized server108-1, 108-2... 108-N - User equipment(s)110-1, 110-2... 110-N - Users202 - One or more processor(s)204 - Memory206 - I / O interface(s)208 - Processing module(s)210 - Database212 - Requester module214 (214a, 214b, 214c) - Plurality of service servers216 (216a, 216b) - Plurality of change engines218-Other module(s)300 - Block diagram302 - First load balancer304 -Second load balancer610 - External Storage Device620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port670 - ProcessorDETAILED DESCRIPTION OF THE DISCLOSURE

[0062] 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 oneanother or with any combination of other features. An individual feature may not address all 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.

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

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

[0065] Also, it is noted that individual embodiments may be described as a process which 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.

[0066] 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 constmed 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 in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.

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

[0068] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. 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 and all combinations of one or more of the associated listed items.

[0069] The aspects of the present disclosure are directed to a system and method for automatically performing workflow approval in a radio access network. The invention primarily focuses on streamlining the process of managing multiple network optimization tasks through intelligent workflow assignment, automated approval processes, and performance validation, thereby enhancing operational efficiency and network performance.

[0070] In the realm of telecommunications, particularly within radio access networks (RANs), organizations operate with diverse teams engaged in a spectrum of tasks. For instance, one team may focus on implementing new antenna installations while another concentrates on optimizing existing processes. Additionally, other teams address customized complaints, integrate new carriers, and handle similar tasks. To streamline these varied activities, a system is required where the at least one requesting entity can categorize their tasks, and the system can automatically assign relevant workflows.

[0071] Consider a team responsible for introducing new antennas, sectors, and carriers at specific sites. This team requires a streamlined process for submitting their requests, which would trigger an approval flow involving senior management, such as a circle head. Upon approval, tasks would proceed for execution, followed by pre- and post-implementation analysis, adhering to predefined criteria. Such a system would ensure efficiency, accountability, and thorough evaluation throughout the task lifecycle.

[0072] The present disclosure introduces a system and method for automatically performing workflow approval in a radio access network. To efficiently handle the multiple activities and projects that occur daily in a RAN, the system employs a common tag called "Project type". Each project type is assigned its own approval flow, execution flow, validation flow, and auto-action flow, simplifying the management of processes associated with each project. The system is configured to assign an appropriate workflow based on the at least one requesting entity’s selection of the project type, ensuring that each project is handled with asuitable workflow. This approach streamlines the overall process, making it more efficient and reducing the likelihood of errors or inconsistencies in network optimization tasks.

[0073] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGS. 1-6.

[0074] FIG. 1 illustrates an exemplary network architecture (100) for implementing a system (102) for automatically performing workflow approval in a radio access network (RAN), in accordance with embodiments of the present disclosure.

[0075] As illustrated in FIG. 1, one or more user equipments (108-1, 108- 2...108-N) may be connected to the system (102) for automatically performing workflow approval in the RAN through a network (104). A person of ordinary skill in the art will understand that the one or more user equipments (108-1, 108-2... 108- N) may be collectively referred to as user equipments (108) and individually referred to as a user equipment (108). One or more users (110-1, 110-2... 110-N) may provide one or more requests to the system (102). A person of ordinary skill in the art will understand that the one or more users (110-1, 110-2... 110-N) may be collectively referred as users (110) and individually referred as a user (110).

[0076] In an embodiment, the user equipment (108) may include, but not be limited to, a mobile phone, a tablet, etc. Furthermore, the user equipment (108) may include a smartphone, virtual reality (VR) devices, augmented reality (AR) devices, a general-purpose computer, a desktop, a personal digital assistant, and a laptop computer.

[0077] In an embodiment, the network (104) 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. Thenetwork (104) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a 2G network, a 3G network, a 4G network, a 5G network, a 6G network, or some combination thereof. The system (102) may be connected to backend servers.

[0078] In an embodiment, the network 104 is further configured with a centralized server (106) including a database, where all data related to the deployment and operation of the system is stored. This data can be retrieved whenever there is a need to reference it in the future.

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

[0080] FIG. 2 illustrates an exemplary micro service-based architecture (200) of the system (102) for automatically performing workflow approval in the radio access network (RAN), in accordance with an embodiment of the present disclosure. The RAN may be defined as the part of a mobile telecommunications system that connects individual devices to other parts of the network through radio connections.

[0081] Referring to FIG. 2, in an embodiment, the system ( 102) may include one or more processor(s) (202), a memory (204), and a requester module (212). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s)(202) may be configured to fetch and execute computer-readable instructions stored in the memory (204) of the system (102). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to automatically perform workflow approval in the radio access network. The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.

[0082] In an embodiment, the system (102) may include an interface(s) (206). The interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output devices (RO), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (102). The interface(s) (206) may also provide a communication pathway for one or more components of the system (102). Examples of such components include but are not limited to, a processing module(s) (208), a plurality of service servers (214), a plurality of change engines (216), and a database (210) for storing workflow and approval data. Further, the processing module(s) (208) may include a requester module (212) and other modules (218).

[0083] The other module(s) (218) may encompass various additional functionalities that support the overall operation of the system (102) for automatic workflow approval. These may include, but are not limited to, a Key Performance Indicator (KPI) validation module, a remote electrical tilt (RET) adjustment module, a reporting module for generating performance reports, and a network analysis module. These modules work in concert with the primary modules to enhance the robustness, efficiency, and reliability of the system.

[0084] In an embodiment, the processing module(s) (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of theprocessing module(s) (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing module(s) (208) may be processorexecutable instructions stored on a non-transitory machine -readable storage medium and the hardware for the processing module(s) (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing module(s) (208). In such examples, the system may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing module(s) (208) may be implemented by electronic circuitry.

[0085] The requester module (212) may receive requests from the at least one requesting entity. The at least requesting entity may include but is not limited to an operator, a machine, a program unit, a device, a bot, and the like . The plurality of service servers (214) may process requests and assign workflows. The plurality of change engines (216) may execute assigned workflows and determine their status. The load balancer may distribute requests and workflows across multiple service servers and change engines.

[0086] In an alternative embodiment, the requesting entity may be an automated network management component such as a network monitoring system, an analytics engine, or a scheduling system. In this embodiment, the automated component may analyze network performance data, identify optimization needs, and automatically generate appropriate requests with the corresponding activity types and project types without human intervention. For example, a network monitoring system detecting signal degradation in a particular cell may automatically submit a request with 'antenna adjustment' as the activity type and'coverage improvement' as the project type. This automated request generation enables proactive network optimization based on real-time performance metrics.

[0087] The requester module (212) is configured to receive at least one request from at least one requesting entity. The requester module (212) may provide a user interface that allows the at least one requesting entity to submit requests related to various RAN optimization tasks. In an aspect, the RAN optimization tasks involve various activities having objective of improving network performance and user experience. These tasks include adjusting antenna tilt and cell coverage to enhance signal strength and reduce interference, optimizing frequency planning and load balancing to distribute traffic efficiently, fine-tuning handovers and neighbor cell lists to ensure seamless connections, and configuring carrier aggregation and quality of service settings to boost data throughput and prioritize services. Additionally, tasks may involve managing cells to handle network load dynamically, mitigating interference, and analyzing traffic patterns to identify areas needing improvement. For example, at least one requesting entity might submit a request to adjust the antenna tilt of a specific cell to improve coverage. Through this interface, the at least one requesting entity may be able to select an activity type and a project type for each request. The activity type might include options such as "antenna adjustment", "power optimization", or "frequency retuning", while project types may include "coverage improvement", "capacity enhancement", or "interference reduction".

[0088] Upon receiving the request, a first load balancer of the system (102) may be configured to select a service server from the plurality of service servers (214a, 214b, 214c) for forwarding the received request. The load balancer may be defined as a device that distributes network or application traffic across different servers to ensure no single server bears too much demand. This load balancing mechanism may contribute to the system's ability to handle multiple activities simultaneously, which may be particularly beneficial in managing the diverse range of tasks typically encountered in radio access network optimization.

[0089] The selected service server may be configured to process the received request to assign at least one workflow corresponding to the received at least one request. In an aspect, the processing may involve analyzing the request details, including the selected activity type and project type. For instance, if the activity type is "antenna adjustment" and the project type is "coverage improvement", the service server may interpret this as a request to optimize the antenna tilt for better coverage. For example, if the activity type is "Signal Testing" and the project type is "Coverage Expansion," the service server may interpret this as a workflow that involves conducting signal strength evaluations across newly expanded areas to verify that the coverage meets the required standards. Alternatively, if the activity type is "Hardware Upgrade" and the project type is "Capacity Enhancement," the service server may interpret this as a workflow involving replacing existing antennas with higher-capacity models to improve the network's ability to handle increased traffic. Based on this analysis, the selected service server may assign at least one workflow corresponding to the received request. A workflow in this context may be defined as a sequence of processes through which a piece of work passes from initiation to completion.

[0090] The system (102) may be configured to automatically assign an approval flow for the at least one assign workflow based on the project type. The approval flow may comprise a single level approval or a multi-level approval, depending on the nature and complexity of the project. For example, a simple parameter change might require only a single level of approval. In contrast, a major reconfiguration of cell sites might require a multi-level approval involving both technical and management teams.

[0091] After the workflow assignment, a second load balancer of the system (102) may be configured to select a change engine from a plurality of change engines (216a, 216b). The change engine may be defined as a component responsible for executing the assigned workflows and implementing the requested changes in the network.

[0092] The selected change engine may be configured to execute the received assigned workflow. Execution may involve carrying out the specific tasks associated with the workflow. For example, in the case of the antenna tilt adjustment, the change engine might send commands to the relevant base station to physically adjust the antenna tilt to the specified angle.

[0093] After execution, the selected change engine may determine a status of the executed workflow. The status may be categorized as either an executed status or an unexecuted status. An executed status may indicate that all steps of the workflow were successfully completed, while an unexecuted status may suggest that one or more steps encountered issues during execution.

[0094] In cases where the determined status is the executed status, the change engine may mark the workflow as complete. Conversely, if the determined status is unexecuted, the change engine may be configured to retry execution of the received assigned workflow after a predefined time. For instance, if a network element was temporarily unavailable during the first execution attempt, a retry after a short delay might succeed.

[0095] The system (102) may also include functionality for validating key performance indicators (KPIs) for a cell associated with the project type after execution of the workflow. KPIs in a radio access network context might include metrics such as signal strength, data throughput, or the number of dropped calls. The cell may refer to a geographical area served by a base station in the radio access network.

[0096] To facilitate this validation, the change engine may be configured to automatically calculate updated KPIs after the completion of certain types of network changes. For example, after a RET change execution in the cell, the system may calculate updated KPIs to assess the impact of the change. RET may be defined as an adjustable parameter that controls the vertical angle of an antenna beam in the base station of the cell, allowing for remote adjustment of the antenna's coverage area without physical manipulation.

[0097] Based on the validated KPIs, the system (102) may be capable of executing predefined automatic actions, such as adjusting configuration settings, rebalancing network loads, or reverting changes to ensure optimal performance and maintain service quality. In an example, the predefined automatic action is associated with the selected project type or the selected activity type and is executed only if the validated KPIs meet a predetermined criteria specified for each of the selected project type or the selected activity type. The predetermined criteria may include specific performance thresholds, target values, or operational limits defined for each project or activity type. For instance, the criteria may involve minimum acceptable throughput levels, maximum allowable latency, or predefined error rates that must be met before the system initiates the corresponding automatic action.

[0098] Furthermore, the system may be configured to automatically revert, by the selected change engine, an RET value to its previous setting if the updated KPIs indicate a degradation in the performance of the cell or sites associated with the cell. The degradation is determined by comparing the updated KPIs to a set of predetermined performance thresholds. The set of predetermined performance thresholds includes specific benchmarks used to evaluate the performance of a cell or network site. For instance, if the updated KPIs indicate a degradation in the performance of the cell or sites associated with the cell, the change engine may automatically revert the RET value to its previous setting. Performance degradation might be indicated by metrics such as a significant increase in dropped calls or a decrease in average data throughput.

[0099] To maintain a record of all activities, the selected service server may be configured to store data associated with the received requests in the database (210). This data storage may facilitate future audits, trend analysis, and continuous improvement of the workflow approval process. The stored data might include details such as the type of request, the assigned workflow, execution status, and before -and-after KPI measurements.

[0100] The change engine may also be configured to generate a response comprising the determined status and an execution response. This response might include details such as the specific changes, any issues encountered during execution, and a summary of the impact on relevant KPIs.

[0101] The system (102) is configured to handle multiple activities simultaneously, therefore significantly enhancing the efficiency of radio access network optimization processes. For example, it might simultaneously process requests for antenna tilt adjustments in one area, frequency retuning in another, and power optimization in a third, all while managing the associated approval workflows and KPI validations.

[0102] The system (102) is configured to automatically calculate and monitor KPIs following network changes, which may provide valuable insights into the effectiveness of optimization efforts. For instance, it might reveal that a particular antenna tilt adjustment improved signal strength but unexpectedly increased interference in neighboring cells.

[0103] The ability to implement automatic corrective actions, such as reverting RET settings when KPIs indicate performance degradation, may help maintain network performance even in the face of potentially detrimental changes. This automated safeguard may reduce the risk of prolonged performance issues.

[0104] By providing a user-friendly interface for request submission and automating much of the subsequent process, the system (102) may significantly reduce the administrative burden on network the at least one requesting entity. For example, instead of manually tracking approval statuses, executing changes, and validating results, the at least one requesting entity might submit a request and receive a comprehensive report of the outcomes.

[0105] The load balancing mechanisms implemented in the system (102) may contribute to its scalability, allowing it to handle increasing numbers of requests and workflows as the network grows or optimization activities intensify.This scalability may be particularly valuable in the context of evolving radio access networks, such as the transition from 4G to 5G networks, where the pace and complexity of optimization tasks may increase significantly.

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

[0107] FIG. 3 illustrates a block diagram (300) of the system (102), in accordance with an embodiment of the present disclosure.

[0108] As shown in FIG. 3, the system (102) may include the requester module (212), a first load balancer (302), the plurality of service servers (214a, 214b, 214c), a second load balancer (304), the database (210), and the plurality of change engines (216a, 216b).

[0109] The requester module (212) may be configured to receive the at least one request from the at least one requesting entity. In another example, the requester module (212) may be a user interface. In one example, the at least one requesting entity may be configured to generate the request by using, for example, a workflow mobile application installed in a user equipment. In some examples, the workflow mobile application may be a software or a mobile application from an application distribution platform. Examples of application distribution platforms. In an aspect, the requester module (212) may be embedded with the user equipment. In some examples, the at least one requesting entity may be configured to generate the request based on, for example, at least the RAN operations.

[0110] A memory, associated with the requester module (212), is configured to store program instructions. In an aspect, the requester module (212) may be configured to, via a processor, fetch and execute computer-readableinstructions stored in the memory. The memory is configured to store the requests received from the at least one requesting entity. The program instructions include a program that implements a method to initiate workflow approval in accordance with embodiments of the present disclosure and may implement other embodiments described in this specification. The memory may be configured to store pre- processed data. In an aspect, the pre-processed data refers to data that has undergone various transformations or enhancements. This may encompass normalized values for uniformity, encoded features for computational compatibility, attributed data to address missing values, filtered information to remove irrelevant elements, aggregated data for summarization, and segmented data to facilitate targeted examination.

[0111] The first load balancer (302) may be configured to cooperate with the requester module (212) and receive the at least one request from the requester module (212). The first load balancer (302) may be further configured to select a service server from the plurality of service servers (214a, 214b, 214c). After selecting the service server, the first load balancer (302) forwards the received request to the selected service server. The first load balancer (302) may be configured to distribute the received request(s) across the plurality of service servers (214a, 214b, 214c), ensuring no single server is overburdened. The first load balancer (302) may be configured to distribute incoming network traffic across the service servers (214a, 214b, 214c). The first load balancer (302) may be configured to adjust the distribution of requests dynamically to ensure optimal resource utilization. The first load balancer (302) may be configured to monitor the health and performance of each service server and direct incoming data based on a set of algorithms (round-robin, least connections, etc.). The first load balancer (302) may be configured to determine the service server based on a number of parameters and forward the received data to the determined service server. For example, the number of parameters may include the number of active requests served by each service server and a threshold of requests to be served.

[0112] In an aspect, the first load balancer (302) may be a dedicated load balancer. In an example, the first load balancer (302) may configure to use POST as a request method supported by a Hypertext Transfer Protocol (HTTP) used by the World Wide Web. The POST request method requests the service server to accept the data enclosed in the body of the request message, most likely for storing it. The POST request method is often used when uploading a file or submitting a completed web form.

[0113] In another aspect, when a specific service server of the plurality of servers gets heavily loaded, the first load balancer (302) may direct the incoming request to other service servers. In another aspect, the plurality of service servers (214a, 214b, 214c) may be configured so that when a specific server fails, the other servers may take over to enable high availability (HA). In another aspect, the request / data from the plurality of service servers (214a, 214b, 214c) may be further transmitted to the database (210). In another aspect, the database (210) may transmit the received data back to the requester module through / via the plurality of servers and the first load balancer (302).

[0114] The plurality of service servers (214a, 214b, 214c) may be configured to receive the request from the first load balancer (302) and further configured to process the received request. In an aspect, the service server may be configured to store the data associated with requests in the database (210). The service server may be configured to process the received request and to assign at least one workflow corresponding to the received request. In an aspect, the service server may be configured to determine a type of the received request and based on the determined type of the request, assign at least one workflow. In an example, the service server is a server cluster adopting distributed deployment, that is, the service server includes a plurality of servers, and the plurality of servers includes a central server for load balancing. In an example, the service server may be a configuration management (CM) retry service server.

[0115] The second load balancer (304) may be configured to receive at least one assigned workflow from the plurality of service servers (214a, 214b, 214c). The second load balancer (304) may be configured to select a change engine from the plurality of change engines (216a, 216b) and communicate the assigned at least one assigned workflow to the selected change engine for execution.

[0116] The plurality of change engines (216a, 216b) may be configured to receive the communicated at least one workflow. The plurality of change engines (216a, 216b) may be configured to process the received assigned workflow(s) and may be further configured to determine a type of the received workflow. The plurality of change engines (216a, 216b) may be further configured to execute the received assigned workflow based on the type of the received workflow. In an example, the at least one assigned workflow may include an approval workflow, an execution workflow, a validation workflow, and an auto-action workflow. The plurality of change engines (216a, 216b) may be further configured to determine the status of the executed workflow and perform approval of the workflow based on the determined status. In an example, the determined status may include the executed status and the unexecuted status. If the determined status is the executed status, then the change engine (216a, 216b) may be further configured to mark the workflow as "complete". If the determined status is the unexecuted status, then the change engine (216a, 216b) may be further configured to retry the execution of the received assigned workflow after the predefined time. In an example, the predefined time refers to a specific interval set by the system or defined in the workflow configuration. This interval can vary based on the configuration parameters specified by the user or administrator.

[0117] The change engines (216a, 216b) employ a workflow classification system to determine the type of received workflow. This system utilizes a combination of metadata tags associated with each workflow and pattern recognition algorithms to categorize incoming workflows. The metadata tags may include identifiers such as "approval," "execution," "validation," or "auto-action," which correspond to the primary workflow types handled by the system.Additionally, the change engines analyze the structure and content of the workflow instructions to refine the classification further.

[0118] Once the workflow type is determined, the change engine (216a, 216b) executes the workflows using a modular execution framework. This framework consists of specialized modules designed to handle each workflow type: a. For approval workflows, the execution module interfaces with the appropriate approval authorities, routing the request through the designated approval chain and collecting necessary authorizations. b. Execution workflows are processed by a module that translates high- level instructions into specific network configuration commands, which are then applied to the relevant network elements. c. Validation workflows are handled by a module that collects and analyzes KPIs from the affected network components, comparing them against predefined thresholds. d. Auto-action workflows are managed by a module that monitors specific triggers or conditions and automatically initiates predefined actions when these conditions are met.

[0119] This approach allows the change engines to efficiently handle diverse workflow types while maintaining the flexibility to add or modify workflow execution processes as needed.

[0120] In a structural aspect, the system ( 102) may be configured to provide : a. Request submission interface: providing a user-friendly interface where the at least one requesting entity can submit their requests. This interface should allow the at least one requesting entity to select the type of problem they are encountering from a predefined list (e.g., new antenna addition, optimization tasks, customized complaints, etc.). b. Workflow Assignment: Based on the type of problem selected, the system (102) may automatically assign the request to acorresponding workflow or an operational team. This assignment can be done using a rules-based system (service server) or manually assigning requests to teams if necessary. c. Approval Flow: For requests that require approval (e.g., new antenna addition), set up an approval flow where the request is sent to the appropriate authority (e.g., circle head) for approval before proceeding with execution. d. Execution: Once approved, the request should be routed to the responsible team for execution. Ensure clear communication channels and documentation to facilitate seamless execution of tasks. e. Pre-Analysis and Post- Analysis: After the task is completed, preanalysis and post-analysis will be performed based on a set of criteria. The pre-analysis and post-analysis may involve gathering data, analyzing performance metrics, and assessing the impact of the task on the overall operation. In an aspect, the set of criteria includes scope and constraints, resources, performance metrics, and potential risks. f. Feedback mechanism: Implement a feedback mechanism where the at least one requesting entity can provide feedback on the resolution process. This will help identify areas for improvement and ensure continuous optimization of workflows. g. Documentation and reporting: maintain all requests, approvals, executions, and analysis results through documentation. The system (102) may be configured to generate reports and dashboards to provide insights into the performance and efficiency of the operational teams.

[0121] The system (102) may be configured to streamline the request management process, ensure tasks are assigned to the appropriate teams, and facilitate efficient execution and analysis of tasks across different operational areas.

[0122] The system (102) may be configured to solve various assignment tasks (problem wise, or activity wise, or project type wise). Further, the system (102) may be configured to assign an execution workflow, an approval workflow, and a validation workflow according to assignment type.

[0123] The at least one requesting entity may be able to assign various requests (activity-wise, project type-wise RET work order approval) to a defined auto-validation process adopted by the present system (102). During the process, the at least one requesting entity is required to select a project type based on the work assigned to him, and based on the selection, the system (102) may be configured to assign an approval flow (single-level approval or multi-level approval). After completion of execution, the system (102) may be configured to validate the KPI for a cell (with which the project type is associated) and take a predefined action.

[0124] For example, if the at least one requesting entity likes to perform KPI optimization activity and has selected project type KPI optimization request, then the system (102) may assign two levels of approval workflow. After completing RET change execution, the KPI will be auto calculated. If the performance of the sites (cell) gets degraded, then the system (102) may be configured to auto-restore an earlier value of the RET.

[0125] FIG. 4 illustrates an exemplary flow diagram illustrating a method (400) implemented by the system (102) for assigning workflow approval paths in the radio access network, in accordance with an embodiment of the present disclosure.

[0126] At step 402, the plurality of service servers (214a, 214b, 214c) may be configured to receive the at least one request from the requester module (212). The at least one requesting entity may be configured to send the request to the system (102), and the system (102) may be configured to initiate the steps to perform workflow approval. In an example, the at least one request may include an activity type and a project type. For instance, an activity type might be "antennaadjustment" while a project type could be "coverage improvement". In another example, the requester module (212) may be the user interface, allowing the at least one requesting entity to input their requests directly into the system (102).

[0127] At step 404, the plurality of service servers (214a, 214b, 214c) may be configured to persist details in the database (210). In an aspect, the plurality of service servers (214a, 214b, 214c) may be configured to extract the plurality of details from the received request. In an example, the plurality of details may include a priority of the request, a queue number in which the request should be served, network cell details, etc. For instance, a high-priority request for urgent network optimization might be assigned a higher queue number for faster processing. The service server may be configured to process the received request and to assign at least one workflow corresponding to the received request. A workflow, in this context, refers to a sequence of processes through which a piece of work passes from initiation to completion.

[0128] The change engines (216a, 216b) utilize a comprehensive set of criteria to determine whether a workflow execution is successful. These criteria are tailored to each workflow type and may include: a. For approval workflows: All required approvals are obtained within the defined timeframe, with no rejections or unresolved issues. b. For execution workflows: All specified changes are successfully applied to the target network elements, with confirmation received from each affected component. No error messages or conflicts are reported during the execution process. c. For validation workflows: All measured KPIs fall within the predefined acceptable ranges after implementing the changes. No significant degradation in network performance is observed. d. For auto-action workflows: The triggered actions are completed as specified, and the intended outcomes (e.g., performance improvements, error resolutions) are achieved.

[0129] The change engines also consider secondary criteria such as execution time, resource utilization, and impact on unrelated network components. A workflow execution is marked as successful only when all primary and secondary criteria are met. If any criterion is not satisfied, the workflow is flagged for review and potential re-execution. This rigorous evaluation ensures that only fully successful workflow executions are approved, maintaining the integrity and performance of the radio access network.

[0130] At step 406, the plurality of service servers (214a, 214b, 214c) may be configured to send data along with the at least one assigned workflow to the change engine for execution. The data may include all relevant information extracted from the request, such as the specific network parameters to be adjusted or the cells affected by the proposed changes.

[0131] At step 408, the plurality of service servers (214a, 214b, 214c) may be configured to receive a response from the change engine. The change engine may be configured to receive the assigned workflow. The change engine may be configured to process the received assigned workflow and may be further configured to determine a type of the received workflow. The change engine may be further configured to execute the received assigned workflow based on the type of the received workflow. In an example, the at least one assigned workflow may include the approval workflow, the execution workflow, the validation workflow, and the auto action workflow. For instance, the approval workflow might involve obtaining necessary permissions before making changes, while the execution workflow would involve actually implementing the approved changes.

[0132] The change engine may be further configured to determine a status of the executed workflow and perform approval of the workflow based on the determined status. In an example, the determined status may include the executed status and the unexecuted status. If the determined status is the executed status, then the change engine may be further configured to mark the workflow as "complete". If the determined status is the unexecuted status, then the change engine may befurther configured to retry the execution of the received assigned workflow after the predefined time. For example, if the network element was temporarily unavailable during the first execution attempt, a retry after a short delay might succeed. In an aspect, the change engine may be configured to generate the response having the determined status and the execution response.

[0133] At step 410, the plurality of service servers (214a, 214b, 214c) may be configured to determine whether all cells have been executed successfully or not. If all cells have been executed successfully, then the system (102) may be configured to mark the workflow as completed and executed (step 412). If all cells have not been executed successfully, then the system (102) may be configured to determine whether the maximum retry attempt is completed or not (step 414). If the maximum retry attempt is not completed, the system (102) may be configured to mark failed cells for retry (step 416), and the method jumps to step 408. If the maximum retry attempt is completed, then the system (102) may be configured to mark the workflow as completed executed (step 412). In some examples, maximum retry numbers may be defined by the operator or the operator system.

[0134] At step 418, the system (102) may be configured to send the execution response to the requester module (212). This response may include details of the changes made, any issues encountered during execution, and a summary of the impact on relevant KPIs.

[0135] In an aspect, the present disclosure may be configured to simplify the process of assigning and executing various tasks, activities, and projects by introducing a workflow management system. The system (102) may allow the at least one requesting entity to categorize tasks based on their type, such as projectbased, activity-based, or task-based, and assign the appropriate workflow for each category. For example, a project-based task might involve a major network upgrade, an activity-based task could be routine maintenance, and a task-based workflow might manage specific customer complaints.

[0136] In an aspect, the system (102) may be configured to manage the RET changes in telecommunications infrastructure and address the complexities of assigning tasks based on problem types, activities, or project types. RET refers to an adjustable parameter that controls the vertical angle of an antenna beam in the base station of the cell, allowing for remote adjustment of the antenna's coverage area without physical manipulation. The system (102) may enable the at least one requesting entity to categorize their requests, such as customer complaints, and provide specific cell details for the required changes. By selecting the project type, the system (102) may trigger an approval flow involving both circle head and team head approvals. This multi-level approval process ensures that critical changes undergo thorough review before implementation.

[0137] FIG. 5 illustrates another exemplary flow diagram of the method (500) implemented by the system (102) for assigning workflow approval paths, in accordance with embodiments of the present disclosure.

[0138] At step (502), the method (500) includes receiving, by the requester module (212), the at least one request from at least one requesting entity. For example, at least one requesting entity might submit a request to adjust the antenna tilt of a specific cell to improve coverage. The requester module (212) may receive a selection of the activity type and the project type in the at least one request. The selection of the activity type and the project type is based on a RAN optimization work assigned to the at least one requesting entity. For instance, an activity type might be "antenna adjustment", while a project type could be "network coverage improvement" .

[0139] At step (504), the method (500) includes selecting, by the first load balancer (302), the service server from the plurality of service servers (214a, 214b, 214c) for forwarding the received at least one request, the load balancer may be defined as a device that distributes network or application traffic across different servers to ensure no single server bears too much demand. This step helps efficiently manage multiple requests and optimize resource utilization.

[0140] At step (506), the method (500) includes processing, by the selected service server, the received at least one request. This may involve analyzing the request details, including the selected activity type and project type, to determine the appropriate workflow required for the specific optimization of task. The optimization involves analyzing the request details, including the selected activity type and project type, to determine the appropriate workflow required for the specific radio access network optimization task. At step (506), the method (500) includes assigning, by the selected service server, at least one workflow corresponding to the received at least one request. The method may further include automatically assigning the approval flow for the at least one assigned workflow based on the project type. In an example, the approval flow includes a single level approval or a multi- level approval. For example, the method may include automatically assigning the two-level approval workflow when the project type is KPI optimization.

[0141] At step (508), the method (500) includes selecting, by the second load balancer (304), the change engine from a plurality of change engines (216a, 216b). This step ensures that the workload is distributed efficiently among the available change engines.

[0142] At step (510), the method (500) includes communicating, by the second load balancer (304), the assigned at least one workflow to the selected change engine for execution. This step ensures that the assigned workflow reaches the appropriate change engine for implementation.

[0143] At step (512), the method (500) includes executing, by the selected change engine, the received assigned at least one workflow. The at least one workflow may comprise an approval workflow, an execution workflow, and a validation workflow. The approval workflow may involve obtaining authorization from designated approvers, such as requiring a network manager's confirmation for a frequency change request. The execution workflow may involve conducting the specific technical operations, such as adjusting antenna tilt parameters from 5° to8° in a particular cell sector. The validation workflow may involve measuring key performance indicators before and after the change to verify improvement, such as comparing signal-to-noise ratios and data throughput metrics. Execution may involve conducting the specific tasks associated with each of these workflows to complete the requested network optimization.

[0144] At step (514), the method (500) includes determining, by the selected change engine, the status of the executed at least one workflow. The determined status may comprise an executed status and an unexecuted status. The method may further include marking, by the selected change engine, the at least one workflow as complete when the status is the executed status, and retrying, by the selected change engine, execution of the received assigned at least one workflow after a predefined time when the determined status is the unexecuted status. The retrying is performed for a predetermined maximum number of retry attempts, typically configured based on the project type and criticality, with critical network optimizations allowed up to five retry attempts before the system marks the workflow with a terminal failure status.

[0145] In an embodiment, when the change engine encounters an unexecuted status during workflow execution, it implements a systematic retry mechanism. The system is configured with a predetermined maximum number of retry attempts, which may be set based on the proj ect type, activity type, or network criticality. For example, critical network optimizations might be configured with up to five retry attempts, while routine adjustments might be limited to three retry attempts. Each retry is initiated after a predefined time interval, which may increase progressively (such as exponential backoff) to accommodate temporary network congestion or availability issues. If all retry attempts are exhausted without achieving successful execution, the system marks the workflow with a terminal failure status in the database and generates a notification for the appropriate personnel to perform manual troubleshooting and resolution. This approach ensures that transient issues do not permanently impede workflow execution while also establishing a clear escalation path for persistent failures.

[0146] The method (500) may further include validating, by the selected change engine, key performance indicators (KPIs) for a cell associated with a project type after execution of at least one workflow, wherein the cell is a geographical area served by a base station in the radio access network. This step helps assess the impact of the implemented changes on network performance.

[0147] Additionally, the method (500) may include executing, by the selected change engine, a predefined automatic action based on the validated KPIs, wherein the predefined automatic action is associated with the selected project type or activity type and is executed only if the validated KPIs meet predetermined criteria specified for the selected project type or activity type.

[0148] The method (500) may also include automatically calculating, by the selected change engine, updated key performance indicators (KPIs) after completion of the RET change execution in the cell. Furthermore, the method may include automatically reverting, by the selected change engine, an RET value to its previous setting if the updated KPIs indicate a degradation in the performance of the cell or sites associated with the cell, wherein the degradation is determined by comparing the updated KPIs to a set of predetermined performance thresholds. The set of predetermined performance thresholds includes specific benchmarks used to evaluate the performance of a cell or network site and may include metrics such as signal-to-noise ratio (SNR) with a threshold of x dB, data transfer rates below y Mbps, round-trip time (RTT) exceeding z milliseconds, call drop rates above p%, and handover success rates falling below q%. These thresholds help in identifying performance degradation by comparing updated KPIs to these set values, triggering automatic adjustments like reverting RET settings if the metrics indicate a decline in performance.

[0149] The method (500) may further include storing, by the selected service server, data associated with the received at least one request in the database (210). This step helps in maintaining a record of all activities for future reference and analysis.

[0150] Additionally, the method (500) may include generating, by the selected change engine, a response comprising the determined status and an execution response. This response provides valuable feedback on the outcome of the executed workflow.

[0151] In another exemplary embodiment, the present disclosure discloses a user equipment (108) that is communicatively coupled to the system (102) for automatically performing workflow approval in the radio access network via the network (104). The system (102) includes the memory (204), and the one or more processors (202) configured to execute the set of instructions stored in the memory (204) to perform the method (500) as described above.

[0152] The present disclosure provides technical advancements related to workflow management in radio access networks. This advancement addresses the limitations of existing solutions by automating workflow approval and execution. The disclosure involves intelligent assignment of workflows based on project and activity types, which offer significant improvements in the efficiency and consistency of network optimization tasks. By implementing automated KPI validation and corrective actions, the disclosed invention enhances the reliability and performance of radio access networks, resulting in improved network quality and user experience.

[0153] FIG. 6 illustrates an example computer system (600) in which or with which the embodiments of the system (102) and the method (500) the embodiments of the present disclosure may be implemented.

[0154] 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(s) (660), and a processor (670). A person skilled in the art will appreciate that the computer system (600) may include more than one processor and communication ports. The processor (670) may include various modules associated with embodiments of the present disclosure. The communication port(s) (660) may be any of an RS-232 portfor use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication ports(s) (660) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects.

[0155] In an embodiment, the main memory (630) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input / output system (BIOS) instructions for the processor (670). The mass storage device (650) may be any current or future mass storage solution, which can 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 Lirewire interfaces).

[0156] In an embodiment, the bus (620) may communicatively couple 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).

[0157] In another embodiment, the at least one requesting entity and administrative interfaces, e.g., a display, keyboard, and cursor control device may also be coupled to the bus (620) to support direct the at least one requesting entity interaction with the computer system (600). Other the at least one requesting entity and administrative interfaces can be provided through network connections connected through the communication port(s) (660). Components described aboveare meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.

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

[0159] 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 to be implemented merely as illustrative of the disclosure and not as limitation.ADVANTAGES OF THE PRESENT DISCLOSURE

[0160] The present disclosure provides a system and method that automatically performs workflow approval in a radio access network, significantly reducing manual intervention and potential errors in the approval process. This automation streamlines operations and improves overall efficiency in network management.

[0161] The present disclosure enables handling of multiple activities simultaneously, allowing for efficient management of various network optimization tasks. This capability is particularly beneficial in complex radio access networks where numerous optimization activities may need to be conducted concurrently.

[0162] The present disclosure implements a flexible approval system that enables either a single-level approval or a double-level approval based on the project type. This adaptability ensures that critical changes undergo appropriate scrutiny while routine tasks can be approved more quickly, optimizing the balance between thoroughness and efficiency.

[0163] The present disclosure incorporates an automated system for validating key performance indicators (KPIs) after the execution of a workflow. This feature ensures that network changes result in the intended improvements and allows for quick identification of any unintended negative consequences.

[0164] The present disclosure efficiently manages and routes various types of requests to the appropriate teams and workflows. This intelligent routing system ensures that each task is managed by the most suitable team, reducing delays and improving the quality of executed tasks.

[0165] The present disclosure provides a user-friendly interface where the at least one requesting entity can submit their requests, select appropriate activity types and project types. This intuitive interface simplifies the process of initiating network optimization tasks, reducing the likelihood of errors in request submission and improving the at least one requesting entity productivity.

[0166] The present disclosure implements automatic assignment of workflows based on the selected project type, reducing manual intervention and potential errors in workflow selection. This feature ensures consistent handling of similar requests across the network.

[0167] The present disclosure integrates approval, execution, and validation processes into a cohesive workflow, ensuring seamless progression from request submission to implementation and verification. This integrated approach minimizes delays between different stages of the optimization process and provides a more holistic view of each network change.

[0168] The present disclosure includes automatic calculation and monitoring of KPIs following network changes, providing valuable insights into the effectiveness of optimization efforts. By immediately assessing the impact of changes, the system enables quick identification and resolution of any unintended negative consequences.

[0169] The present disclosure incorporates automatic corrective actions, such as reverting Remote Electrical Tilt (RET) settings when KPIs indicate performance degradation. This automated safeguard helps maintain network performance even in the face of potentially detrimental changes, reducing the risk of prolonged performance issues resulting from network optimizations.

Claims

CLAIMS1. A system (102) for assigning workflow approval paths in a radio access network, the system (102) comprising: a requester module (212) configured to receive at least one request from at least one requesting entity; a first load balancer (302) configured to select a service server from a plurality of service servers (214a, 214b, 214c) for forwarding the received at least one request, wherein the selection is based on server load distribution parameters comprising current request volume per server, server availability status, and predefined request handling thresholds; the selected service server configured to process the received at least one request and assign at least one workflow corresponding to the received at least one request; a second load balancer (304) configured to select a change engine from a plurality of change engines (216a, 216b) and communicate the assigned at least one workflow to the selected change engine for execution; and the selected change engine configured to: execute the at least one workflow assigned to the selected change engine; and determine a status of the executed at least one workflow.

2. The system (102) as claimed in claim 1, wherein the requester module (212) is further configured to receive a selection of an activity type and a project type as part of the at least one request, wherein the activity type is a categorization defining a specific network optimization action to be performed, selected from a predefined set comprising antenna adjustment, power optimization, and frequency retuning, wherein the project type is a categorization defining a broader optimization objective, selected from a predefined set comprising coverage improvement, capacity enhancement,and interference reduction, and wherein the selection of the activity type and the project type corresponds to a radio access network optimization task assigned to the requesting entity.

3. The system (102) as claimed in claim 2, wherein the selected service server is further configured to assign an approval workflow for the assigned workflow based on at least one of the project type and the activity type, wherein the approval workflow defines a sequence of authorization steps required before execution of the assigned workflow, wherein the approval workflow comprises either a single level approval requiring authorization from one designated approver or a multiple level approval requiring sequential authorization from two or more designated approvers in a predetermined hierarchy.

4. The system (102) as claimed in claim 2, wherein the selected change engine is further configured to: validate, by the selected change engine, key performance indicators (KPIs) for a cell associated with the project type after execution of the at least one assigned workflow, wherein the cell is a geographical area served by a base station in the radio access network.

5. The system ( 102) as claimed in claim 4, wherein the selected change engine is further configured to: execute a predefined action based on the validated KPIs, wherein the predefined automatic action is associated with the selected project type or the selected activity type and is executed only if the validated KPIs meet a predetermined criteria specified for each of the selected project type or the selected activity type.

6. The system (102) as claimed in claim 4, wherein the selected change engine is further configured to:calculate updated key performance indicators (KPIs) after completion of a network parameter adjustment in the cell, wherein the network parameter adjustment comprises a remote electrical tilt (RET) change execution, and wherein the RET change execution is an implementation of at least one activity type related to antenna configuration; and revert an RET value to a previous setting if the updated KPIs indicate a degradation in performance of the cell or sites associated with the cell, wherein the degradation is determined by comparing the updated KPIs to a set of predetermined performance thresholds.

7. The system (102) as claimed in claim 1, wherein the at least one workflow assigned to the selected change engine comprises: an approval workflow that defines authorization requirements and approver roles for the requested network changes, an execution workflow that defines the sequence of technical operations to implement the authorized network changes, and a validation workflow that defines procedures for measuring and evaluating network performance after implementation of the changes.

8. The system (102) as claimed in claim 1, wherein the determined status comprises an executed status and an unexecuted status, wherein the selected change engine is further configured to: mark the at least one assigned workflow as complete when the determined status is the executed status; and retry an execution of the at least one assigned workflow after a predefined time interval when the determined status is the unexecuted status, wherein the retrying is performed for a predetermined maximum number of retry attempts, and wherein upon reaching the maximum number of retry attempts without successful execution, the selected change engine marks the workflow with a terminal failure status and generates a notification for manual intervention.

9. A method (500) for assigning workflow approval paths in a radio access network, the method (500) comprising: receiving (502), by a requester module (212), at least one request from at least one requesting entity; selecting (504), by a first load balancer (302), a service server from a plurality of service servers (214a, 214b, 214c) for forwarding the received at least one request, wherein the selection is based on server load distribution parameters comprising current request volume per server, server availability status, and predefined request handling thresholds; processing (506), by the selected service server, the received at least one request to assign at least one workflow corresponding to the received at least one request; selecting (508), by a second load balancer (304), a change engine from a plurality of change engines (216a, 216b); communicating (510), by the second load balancer (304), the assigned at least one workflow to the selected change engine for execution; executing (512), by the selected change engine, the at least one workflow assigned to the selected change engine; and determining (514), by the selected change engine, a status of the executed at least one workflow.

10. The method (500) as claimed in claim 9, further comprising: receiving, by the requester module (212), a selection of an activity type and a proj ect type as part of the at least one request, wherein the activity type is a categorization defining a specific network optimization action to be performed, selected from a predefined set comprising antenna adjustment, power optimization, and frequency retuning, wherein the project type is a categorization defining a broader optimization objective, selected from a predefined set comprising coverage improvement, capacity enhancement, and interference reduction, and wherein the selection of the activity type andthe project type corresponds to a radio access network optimization task assigned to the requesting entity.

11. The method (500) as claimed in claim 10, further comprising assigning, by the selected service server, an approval workflow for the assigned workflow based on at least one of the project type and the activity type, wherein the approval workflow defines a sequence of authorization steps required before execution of the assigned workflow, wherein the approval workflow comprises either a single level approval requiring authorization from one designated approver or a multiple level approval requiring sequential authorization from two or more designated approvers in a predetermined hierarchy.

12. The method (500) as claimed in claim 10, further comprising validating, by the selected change engine, key performance indicators (KPIs) for a cell associated with the project type after execution of the at least one assigned workflow, wherein the cell is a geographical area served by a base station in the radio access network.

13. The method (500) as claimed in claim 12, further comprising executing, by the selected change engine, a predefined action based on the validated KPIs, wherein the predefined automatic action is associated with the selected project type or the selected activity type and is executed only if the validated KPIs meet a predetermined criteria specified for each of the selected project type or the selected activity type.

14. The method (500) as claimed in claim 12, further comprising: calculating, by the selected change engine, updated key performance indicators (KPIs) after completion of a network parameter adjustment in the cell, wherein the network parameter adjustment comprises a remote electrical tilt (RET) change execution, and wherein the RET changeexecution is an implementation of at least one activity type related to antenna configuration; and reverting, by the selected change engine, an RET value to a previous setting if the updated KPIs indicate a degradation in performance of the cell or sites associated with the cell, wherein the degradation is determined by comparing the updated KPIs to a set of predetermined performance thresholds.

15. The method (500) as claimed in claim 11, wherein the determined status comprises an executed status and an unexecuted status, the method comprising: marking, by the selected change engine, the at least one assigned workflow as complete when the determined status is the executed status; and retrying, by the selected change engine, an execution of the at least one assigned workflow after a predefined time interval when the determined status is the unexecuted status, wherein the retrying is performed for a predetermined maximum number of retry attempts, and wherein upon reaching the maximum number of retry attempts without successful execution, the selected change engine marks the workflow with a terminal failure status and generates a notification for manual intervention.

16. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors (202) of a system (102) for assigning workflow approval paths in a radio access network, cause the one or more processors (202) to perform operations comprising: receiving (502), by a requester module (212), at least one request from at least one requesting entity; selecting (504), by a first load balancer (302), a service server from a plurality of service servers (214a, 214b, 214c) for forwarding the received at least one request, wherein the selection is based on server loaddistribution parameters comprising current request volume per server, server availability status, and predefined request handling thresholds; processing (506), by the selected service server, the received at least one request to assign at least one workflow corresponding to the received at least one request; selecting (508), by a second load balancer (304), a change engine from a plurality of change engines (216a, 216b); communicating (510), by the second load balancer (304), the assigned at least one workflow to the selected change engine for execution; executing (512), by the selected change engine, the at least one workflow assigned to the selected change engine; and determining (514), by the selected change engine, a status of the executed at least one workflow.

Images