Handling radio access network (RAN) application performance metrics by non-real time ran intelligent controller framework

Abstract

Disclosed herein is an apparatus. The apparatus is configured to receive, from one or more network applications, a first information. The first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with the performance metrics in the list of performance metrics. The apparatus is further configured to obtain, based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner. The apparatus obtains the one or more performance metrics by one or more network application management functions via an R1 interface. Further, the apparatus obtains the one or more performance metrics to enable monitoring of performance of the one or more network applications.

Description

HANDLING RADIO ACCESS NETWORK (RAN) APPLICATION PERFORMANCE METRICS BY NON-REAL TIME RAN INTELLIGENT CONTROLLER FRAMEWORKCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to India Provisional Application No. 202411089128, filed on November 18, 2024, and India Non-Provisional Application No. 202411089128, filed on May 27, 2025, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to handling Radio Access Network (RAN) Application (rApp) performance metrics by Non-Real Time RAN Intelligence Controller (Non-RT RIC) framework.BACKGROUND

[0003] The information disclosed in this background section is only for an enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgment or any form of suggestion that this information forms the prior art already- known to a person skilled in the art.

[0004] Open Radio Access Network (O-RAN) alliance is a global community of mobile network operators, vendors, and research and academic institutions focused on open RAN standards and interoperability. The O-RAN alliance has defined a set of use cases and applications that a RAN Intelligent Controller (RIC) supports. The RIC is divided into non-real-time and near-real-timecomponents. A Non-Real Time RIC (Non-RT RIC) architecture (ARCH) has two primary requirements. First, in order to ensure continuous performance monitoring, REQ-NRTFWK-FUN25 (defined in 0-RAN.WG2.Non-RT-RIC-ARCH-R004-v06.00) requires the Non-RT RIC framework to support functionality that allows RAN Applications (rApps) to provide performance information if such functionality is not supported in a Service Management and Orchestration (SMO) framework. Second, Section 6.1 of the 0-RAN.WG2.Non-RT-RIC-ARCH-R004-v06.00 requires rApp management functions to enable management of the rApps within the context of the SMO framework or a Non-RT RIC framework.SUMMARY

[0005] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the present disclosure nor is it intended to determine the scope of the disclosure.

[0006] The present disclosure addresses the technical problem associated with obtaining information about a Radio Access Network (RAN) Application's (rApp’s) performance in a Service Management Orchestration (SMO) framework or a Non-Real Time RAN Intelligent Controller (Non-RT RIC) framework.

[0007] According to one embodiment of the present disclosure, an apparatus is disclosed. The apparatus is configured to receive, from one or more network applications, a first information. The first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with the performance metrics in the list of performance metrics. The apparatus is further configured to obtain, based on the received first information, one or more performance metrics among the list of performance metrics in aperiodic manner. The apparatus obtains the one or more performance metrics by one or more network application management functions via an R1 interface. Further, the apparatus obtains the one or more performance metrics to enable monitoring of performance of the one or more network applications.

[0008] According to another embodiment of the present disclosure, a method is disclosed. The method includes receiving, by one or more Service Management and Orchestration (SMO) components and from one or more network applications, a first information. The first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with the performance metrics in the list of performance metrics. The method also includes obtaining, based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner. The method includes obtaining the one or more performance metrics by one or more network application management functions within the one or more SMO components via an R1 interface. The method includes obtaining the one or more performance metrics to enable monitoring of performance of the one or more network applications.

[0009] According to another embodiment of the present disclosure, a non-transitory computer-readable medium is disclosed. The non-transitory computer-readable medium stores instructions that, when executed by one or more processors at one or more Sendee Management and Orchestration (SMO) components, cause the one or more processors to receive, from one or more netw ork applications, a first information. The first information comprises a list of performance metrics supported by the one or more network applications and a periodicity' associated with the performance metrics in the list of performance metrics. The one or more instructions also cause the one or more processors to obtain, based on the received firstinformation, one or more performance metrics among the list of performance metrics in a periodic manner. The one or more processors obtain the one or more performance metrics by one or more network application management functions via an R1 interface. The one or more processors obtain the one or more performance metrics to enable monitoring of performance of the one or more network applications.BRIEF DESCRIPTION OF DRAWINGS

[0010] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:FIG. 1 illustrates a general Open Radio Access Network (O-RAN) architecture associated with a RAN Intelligent Controller (RIC), according to related art;FIG. 2 illustrates a block diagram of an example environment for handling RAN Applications' (rApps’) performance metrics by a Non-Real Time (Non-RT) RIC, in accordance with an embodiment of the present disclosure;FIG. 3 illustrates a sequence flow diagram depicting an end-to-end rApp performance metrics flow, according to an embodiment of the present disclosure;FIG. 4 illustrates a block diagram of an example environment for registration of a data ty pe with a Data Management and Exposure (DME) function, in accordance with an embodiment of the present disclosure;FIG. 5 illustrates a block diagram of an example environment for registration of the data type with an rApp Management Function, in accordance with an embodiment of the present disclosure;FIG. 6 illustrates a block diagram of an example environment for configuration of the rApp using a PMMetricJob data model, in accordance with an embodiment of the present disclosure;FIG. 7 illustrates a block diagram of an example environment for initiating a data subscription request by the rApp Management Function, in accordance with an embodiment of the present disclosure;FIG. 8 illustrates a block diagram of an example environment for initiating the data subscription request by the DME Function, in accordance with an embodiment of the present disclosure;FIG. 9 illustrates a sequence flow diagram depicting an rApp interaction using an rApp descriptor and an rApp management service, in accordance with an embodiment of the present disclosure;FIG. 10 illustrates a sequence flow diagram depicting an rApp interaction using the rApp management service as an R1 service, in accordance with an embodiment of the present disclosure;FIG. 11 illustrates a sequence flow diagram depicting an rApp interaction using a DME R1 service, in accordance with an embodiment of the present disclosure;FIGS. 12A-12B illustrate a sequence flow diagram depicting an overall process for handling the rApp’s performance metrics by the Non-RT RIC, in accordance with an embodiment of the present disclosure;FIG. 13 illustrates a flowchart depicting a method for handling the rApp’s performance metrics by a Non-RT RIC framework, in accordance with an embodiment of the present disclosure;FIG. 14 illustrates a flowchart depicting a method for obtaining one or more performance metrics, in accordance with an embodiment of the present disclosure; and FIG. 15 illustrates an embodiment of a device, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION

[0011] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0012] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, software, or a combination of hardware and software. The actual specialized control hardw are or software code used to implement these systems and / or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific softw are code. It is understood thatsoftware and hardware may be designed to implement the systems and / or methods based on the description herein.

[0013] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0014] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a'’ and ’an" are intended to include one or more items, and may be used interchangeably with ‘“one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B.

[0015] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0016] It should be noted that the terms “metrics” and “performance metrics” have been used interchangeably throughout the description and drawings and imply similar meanings.Similarly, the terms “rApp” and “rApps” have been used interchangeably throughout the description and drawings.

[0017] FIG. 1 illustrates a general Open Radio Access Network (O-RAN) architecture 100 associated with a RAN Intelligent Controller (RIC), according to related art. The O-RAN alliance, which is a global community of mobile network operators, vendors, and research and academic institutions focused on open RAN standards and interoperability, has defined a set of use cases and applications that the RIC supports. The RIC is divided into non-real-time and near-real-time components. A Non-Real Time RIC (Non-RT RIC) 104 is an element of operator’s centralized Service Management and Orchestration (SMO) framework 102, as defined by the O-RAN alliance. On the other hand, a Near-Real Time (Near-RT) RIC 108 resides within a telecom edge or regional cloud and generally enables network optimization actions that take between ten milliseconds to one second to complete.

[0018] TheNon-RT RIC 104 acts as acontrol point of a non-real-time control loop and operates on a timescale greater than 1 second within the SMO framework 102. The functionalities of the Non-RT RIC 104 may be implemented through one or more applications called RAN Applications (rApps) 106. The Non-RT RIC 104 may be connected to the Near-RT RIC 108 over an Al interface. The Near-RT RIC 108 operates on a timescale between 10 milliseconds and 1 second. The functionalities of the Near-RT RIC 108 may be implemented through one or more applications called extensible applications (xApps) 110.

[0019] The Near-RT RIC 108 may further be connected to one or more E2 nodes (for instance, an Evolved Node B (eNB), a Next Generation Node B (gNB)) over an E2 interface. The SMO framework 102 may also be connected to one or more E2 nodes over an 01 interface. The SMO framework 102 may manage and orchestrate various RAN elements. For instance, the SMOframework 102 may orchestrate an O-RAN Cloud (O-Cloud) 112. The SMO framework 102 may also be connected to the O-Cloud 112 over an 02 interface. The O-Cloud 112 may refer to a collection of physical RAN nodes that host the RICs, O-Centralized Units (O-CUs), O-Distributed Units (0-DUs), etc., along with the supporting environments and components.

[0020] The Non-RT RIC architecture (ARCH) has two primary requirements. First, REQ-NRTFWK-FUN25 (defined in 0-RAN.WG2.Non-RT-RIC-ARCH-R004-v06.00) requires the Non-RT RIC framework to support functionality that allows rApps 106 to provide performance information if such functionality is not supported in the SMO framework 102. Second, Section 6.1 of the REQ-NRTFWK-FUN25 requires the rApp management functions to enable the management of rApps 106 within the context of the SMO framework 102 or the Non-RT RIC framework. The rApp management functions enable, but are not limited to, a configuration of the rApps 106, access to a fault and performance-related information from the rApps 106, and support for an rApp logging functionality. Using an R1 interface, the rApp management functions may ensure consistent access to the aforesaid capabilities across all the rApps 106. Further, Section 7.8 of the REQ-NRTFWK-FUN25 defines an rApp management service. The rApp management service mentions an rApp performance service that enables the rApps 106 to report on corresponding performance or communication with other entities. However, no specific procedure has been defined for the rApps 106 to report performance information in the SMO framework or the Non-RT RIC framework. Defining such specific procedure may ensure consistency across network applications and also enhance interoperability among different network applications and systems.

[0021] The present disclosure provides solutions to the above-mentioned problem(s), as discussed in detail in the forthcoming paragraphs.

[0022] FIG. 2 illustrates a block diagram of an example environment 200 for handling rApps’ 202 performance metrics by the Non-RT RIC 204. in accordance with an embodiment of the present disclosure. It should be noted that the term “Non-RT RIC 204” has also been referred to as a “Non-RT RIC framework 204” and implies a similar meaning.

[0023] In an embodiment, one or more network applications rAppl 202-1, ... , an rAppN 202-n (collectively referred to as the “rApps” 202 or “the one or more network applications 202”) may be developed by multiple vendors. The rApps 202 may also be capable of reporting corresponding performance metrics in a uniform and consistent way. The rApps 202 may report two categories of the performance metrics. The first category may include the performance metrics which are common or generic across all the rApps 202. Examples of such performance metrics include, but are not limited to, a number of data j obs created by the rApps 202, a number of Al policies created by the rApps 202, and a number of Hypertext Transfer Protocol (HTTP) requests sent. The performance metrics of the first category may be collected by the SMO 206 or the Non-RT RIC framework 204. However, the Non-RT RIC framework 204 may be unable to collect the performance metrics related to R1 request failures, specifically when an rApp fails to send the request. The second category may include the performance metrics which are usecase specific. Examples of such performance metrics may include, but are not limited to, a Mobility Load Balancing (MLB) rApp that may report a number of load balancing attempts, and an Energy -saving rApp that may report a number of cells optimized for energy efficiency for the operator monitoring purposes. The SMO 206 or the Non-RT RIC framework 204 (and, not any other rApp(s)) may be the primary consumers of the performance metrics. Additionally, the performance metrics may ultimately be used by network operators or administrators tomonitor the behaviour or performance of the rApps 202. The SMO 206 may include a network operator monitoring service.

[0024] As shown in FIG. , the handling of the rApps’ 202 performance metrics by the Non-RT RIC 204 may be a two-step process. In the first step, an rApp 202 may inform the SMO 206 or the Non-RT RIC framework 204 about the one or more performance metrics that the rApp 202 wants to report. For this, the rApp 202 may perform a registration of the one or more performance metrics with the SMO 206 or the Non-RT RIC framework 204. This step may be a one-time step. In the second step, the rApp 202 may periodically report the one or more performance metrics to the SMO 206 or the Non-RT RIC framework 204. Alternatively, the SMO 206 or the Non-RT RIC framework 204 may periodically collect the one or more performance metrics from the rApp 202.

[0025] FIG. 3 illustrates a sequence flow diagram 300 depicting an end-to-end rApp performance metrics flow, according to an embodiment of the present disclosure. The sequence flow diagram 300 may illustrate a sequence of operations between the rApp 202, the Non-RT RIC 204, and the one or more SMO components (also referred to as “SMO(s)’’) 206. The SMO(s) 206 may include the network operator monitoring service.

[0026] At step 302, the SMO(s) 206 may transmit a request to subscribe to the rApp’s performance metrics (particularly, implementation-specific performance metrics) to the Non-RT RIC 204 (e.g., a Non-RT RIC function). At step 304, the rApp 202 may start functioning. At step 306, the rApp 202 may notify the Non-RT RIC 204 about the performance metrics that the rApp 202 intends to report. The rApp 202 may notify7the Non-RT RIC 204 over an R1 interface. At step 308, the rApp 202 may collect / report the performance metrics from or to the Non-RT RIC 204 periodically, i.e., in a loop. Finally, at step 310, the Non-RT RIC 204 maynotify the availability of rApp’s performance metrics (particularly, the implementation-specific performance metrics) to the SMO(s) 206. In one embodiment, the rApp 202, the Non-RT RIC 204, and the SMO(s) 206 may be a part of the Non-RT RIC framework. Further, the Non-RT RIC function may be a part of one or more non-anchored functions in the SMO 206 or the Non-RT RIC framework. Further, in an example embodiment, the Non-RT RIC function may represent one or combinations of more than one Non-RT RIC function to expose the performance metrics towards the SMO(s) 206.

[0027] In an embodiment, the present disclosure proposes a network operator or one or more SMO components to know about a list of performance metrics supported by the rApps 202. The one or more SMO components may include the Non-RT RIC 204. In another embodiment, the present disclosure proposes the network operator or the one or more SMO components to be able to obtain one or more performance metrics of the rApps 202 from the list of the performance metrics. The network operator or the one or more SMO components may obtain the one or more performance metrics based on respective preferences. In yet another embodiment, the present disclosure proposes that the network operator or the one or more SMO components may be able to control a set of performance metrics provided by the rApps 202. Each of these embodiments are explained in detail in the forthcoming paragraphs.

[0028] To know about the list of performance metrics supported by the rApps 202, the present disclosure proposes four options. In Option 1, the network operator and an rApp vendor may mutually decide which rApp performance metrics the rApp 202 is going to support. For this, an involvement of the Non-RT RIC framework 204 may not be required. In Option 2, the rApp 202 may inform the network operator or the one or more SMO components about the performance metrics supported by the rApp 202 during an rApp deployment using an rAppdescriptor (as explained in detail in conjunction with FIG. 9 in the forthcoming paragraphs). The rApp descriptor may include details of the performance metrics that the rApp 202 wants to report. In Option 3, the rApp 202 may register the list of performance metrics with an rApp management service. This may be achieved by two approaches. The first approach may include defining a new R1 interface Application Programming Interface (API) for metrics registration. The second approach may be a Third Generation Partnership Project (3GPP)-based approach. Particularly, the second approach may utilize a Network Function (NF) capability reporting and SupportedPerfMetricGroups mechanism, as specified in 3GPP Technical Specifications 28.532 and 28.662, respectively. The rApp management service may refer to a component within the one or more SMOs responsible for handling the full lifecycle of the rApps 202. In Option 4, advantageously, the rApp 202 may use an existing R1 Data Management and Exposure (DME) service API (for example, a dataType register request) to register the performance metrics (as explained in conjunction with FIG. 11 in the forthcoming paragraphs). The R1 DME service API may refer to a component within the R1 interface configured to facilitate a seamless data integration between the rApps and the Non-RT RIC 204. In an embodiment, the rApp 202 may register a data type with a DME function using R1 DME service APIs (as explained in detail in conjunction with FIG. 4 in the forthcoming paragraphs). The DME function may refer to a component of the Non-RT RIC 204 within the SMO configured to collect, process, and expose RAN data (such as performance, configuration, and one or more derived KPIs) to the rApps and / or other SMOs via standardized interfaces. Alternatively, the rApp 202 may register the data type with one or more network application management functions using an R1 interface (as explained in detail in conjunction with FIG. 5 in the forthcoming paragraphs). In an embodiment, the one or more network application management functions may include an rAppManagement Function. The rApp Management Function may refer to a logical function within the Non-RT RIC 204 of the SMO 206 that is responsible for onboarding, deployment configuration, lifecycle management, and monitoring of the rApps 202. Further, the R1 interface may include the R1 DME service APIs. In an embodiment, the R1 DME service APIs may be existing R1 DME service APIs. Alternatively, the R1 DME service APIs may be new R1 DME service APIs.

[0029] FIG.4 illustrates a block diagram of an example environment 400 for registration of the data type with the DME function 402, in accordance with an embodiment of the present disclosure. The environment 400 may include the rApp 202 and the Non-RT RIC 204. As shown in FIG. 4, the Non-RT RIC 204 may include the DME function 402 and the rApp Management Function 404.

[0030] At step 406a, the rApp 202 may register the data type for Performance Management (PM) data with the DME function 402 using the R1 DME service APIs. At step 406b. the rApp 202 may register the data type for other types of data (i.e., data other than the PM data) with the DME function 402 using the R1 DME service APIs. The other ty pes of data may include, but are not limited to, configuration data; fault data including infomiation about one or more errors, issues, or malfunctions encountered by the rApp 202; and data related to security aspects associated with the rApp 202.

[0031] FIG.5 illustrates a block diagram of an example environment 500 for registration of the data ty pe with the rApp Management Function 502, in accordance with an embodiment of the present disclosure. The environment 500 may include the rApp 202 and the Non-RT RIC 204. As shown in FIG. 5, the Non-RT RIC 204 may include the rApp Management Function 502and the DME function 504. In an embodiment, the rApp Management Function 502 and the DME function 504 may act as DME service providers.

[0032] At step 506a, the rApp 202 may register the data type for performance metrics (PM) data with the rApp Management Function 502 using the R1 DME service APIs. And. at step 506b. the rApp 202 may register the data type for other types of data (i.e.. data other than the PM data) with the DME function 504 using the R1 DME service APIs.

[0033] For the network operator or the one or more SMO components to be able to obtain one or more performance metrics of the rApps 202 from the list of the performance metrics, the present disclosure proposes five options. In Option 1, the rApp 202 may report one or more preagreed performance metrics periodically towards the rApp management service. For example, the rApp 202 may periodically send the one or more pre-agreed performance metrics to Non-RT RIC 204 using a new R1 API. In Option 2, another new R1 API may be defined to configure the rApp 202 with details about which performance metrics are to be reported or collected. The configuration may include one or more parameters such as the list of the performance metrics and a periodicity associated with the performance metrics in the list of performance metrics. The rApp 202 may then utilize the another new R1 API for reporting the configured performance metrics. In Option 3, the rApp 202 may be configured using the 3GPP TS 28.532 and TS 28.622 by reutilizing a PMMetricJob data model to define the one or more performance metrics to be collected (as explained in conjunction with FIG.6 in the forthcoming paragraphs). The PMMetricJob data model may refer to a data model that informs a network function or an application about the performance metrics to be collected along with the periodicity and mechanism of the collection. The rApp 202 may then report the one or more performancemetrics using 3GPP-based mechanisms, such as streaming data reporting or file transfer services.

[0034] FIG. 6 illustrates a block diagram of an example environment 600 for configuration of the rApp 202 using the PMMetricJob data model, in accordance with an embodiment of the present disclosure. The environment 600 may include the rApp 202 and the Non-RT RIC 204. The Non-RT RIC 204 may include the rApp Management Function 502 and the DME function 504. In an embodiment, the rApp Management Function 502 and the DME function 504 may act as DME service providers.

[0035] At step 602a, the rApp Management Function 502 may transmit a CreateMOI(PMJob) message to the rApp 202. The CreateMOI(PMJob) message may be transmitted for creating a Measurement Object Instance (MOI) for performance monitoring based on a PMIob configuration. The PMIob may define the one or more performance metrics to be collected, their periodicity, and other related parameters. The MOI may represent a specific instance or entity of the performance measurement. The MOI may be a real-time representation of a performance data collection job.

[0036] At step 602b, the DME Function 504 may independently transmit a request to the rApp 202 for creating a data job for other types of data (i. e. , non-rApp PM data).

[0037] In Option 4, the rApp Management Function 502 of the Non-RT RIC 204 may obtain one or more performance metrics to be produced by the rApp 202 using the R1 DME service API. For this, the rApp Management Function 502 may initiate a data subscription request by¬ creating a data job specifying, e.g., the required performance metrics (as explained in conjunction with FIG. 7 in the forthcoming paragraphs). Alternatively, the rApp 202 mayproactively create a data offer. Through the data offer, the rApp 202 may advertise available performance metrics to the rApp Management Function 502.

[0038] FIG. 7 illustrates a block diagram of an example environment 700 for initiating the data subscription request by the rApp Management Function 502, in accordance with an embodiment of the present disclosure. The environment 700 may include the rApp 202 and the Non-RT RIC 204. The Non-RT RIC 204 may include the rApp Management Function 502 and the DME function 504. In an embodiment, the rApp Management Function 502 and the DME function 504 may act as DME service providers.

[0039] At step 702a, the rApp Management Function 502 may transmit the data subscription request to the rApp 202 by creating the data job for the PM data.

[0040] At step 702b, the DME Function 504 may independently transmit a data subscription request to the rApp 202 by creating a datajob for other types of data (e.g., non-rApp PM data).

[0041] Further, in Option 5, the DME function 504 of the Non-RT RIC 204 may obtain the one or more performance metrics to be produced by the rApp 202 using the R1 DME service API. For this, the DME Function 504 may initiate the data subscription request by creating the data job specifying, e.g., the required one or more performance metrics (as explained in conjunction with FIG.8 in the forthcoming paragraphs). Alternatively, the rApp 202 may proactively create the data offer broadcasting the list of performance metrics that the rApp 202 is capable of producing. The DME Function 504 may then subscribe to or consume such performance metrics as needed.

[0042] FIG.8 illustrates a block diagram of an example environment 800 for initiating the data subscription request by the DME Function 402, in accordance with an embodiment of the present disclosure. The environment 800 may include the rApp 202 and the Non-RT RIC 204.The Non-RT RIC 204 may include the DME function 402 and the rApp Management Function 404. In an embodiment, the DME function 402 and the rApp Management Function 404 may correspond to the DME function 504 and the rApp Management Function 502, respectively.

[0043] At step 802a. the DME Function 402 may transmit the data subscription request to the rApp 202 by creating the data job for the PM data.

[0044] At step 802b. the DME Function 402 may independently transmit a data subscription request to the rApp 202 by creating a datajob for other types of data (e.g., non-rApp PM data).

[0045] Furthermore, for the network operator or the one or more SMO components to be able to control a set of performance metrics provided by the rApps 202, the present disclosure proposes five options. In Option 1, the network operator or the one or more SMO components may re-deploy a new version of the rApp 202 with an agreed set of the performance metrics. In Option 2, the rApp 202 may be configured based on the 3GPP TSs 28.532 and 28.622 by reutilizing the PMMetricJob data model. The rApp 202 may then report the performance metrics using 3GPP-based mechanisms such as the streaming data reporting or the file transfer services. In Option 3, the network operator or the one or more SMO components may define a new R1 API to configure the rApp 202 with the required one or more performance metrics to be reported by the rApp 202 or collected by the network operator or the one or more SMO components. The configuration may include the one or more parameters such as the list of the performance metrics and the periodicity associated with the performance metrics in the list of performance metrics parameters. In Option 4, the rApp Management Function 502 of the Non-RT RIC 204 may obtain the one or more performance metrics to be produced by the rApp 202 using the R1 DME service APIs. For this, the rApp Management Function 502 may initiate the data subscription request, where the rApp Management Function 502 may update an existingdata job to indicate the required one or more performance metrics. Finally, in Option 5, the DME Function 504 of the Non-RT RIC may obtain the desired one or more performance metrics from the rApp 202 using the R1 DME service APIs. For this, the DME Function 504 may create the data job through a data subscription mechanism.

[0046] Additionally, multiple embodiments for an rApp interaction are explained in detail in the forthcoming paragraphs in conjunction with FIG.9-12B.

[0047] FIG. 9 illustrates a sequence flow diagram 900 depicting an rApp interaction using the rApp descriptor and an rApp management service 902, in accordance with an embodiment of the present disclosure. The sequence flow diagram 900 may illustrate a sequence of operations between the rApp 202, the rApp management service 902. and the one or more SMO components (also referred to as “SMO(s)’ ) 206.

[0048] At step 904, the SMO(s) 206 may transmit an rApp descriptor with dayO configuration to the rAPP management service 902. The rApp descriptor may include details of the performance metrics that the rApp 202 wants to report. The dayO configuration may include, but is not limited to, one or more rApp metrics details with metricName and metadata. In an embodiment, the rApp management service 902 may receive the rApp descriptor during a deployment stage. The rApp management service 902 may be configured to keep records of the one or more rApp metrics details. At step 906, the rApp management service 902 may store the received one or more rApp metrics details, i.e., the registered metrics for the rApp 202. At step 908, the rApp 202 may already be deployed or instantiated and an rApp instance may be registered. At step 910, once the rApp instance is registered, the rApp management sen ice 902 may create a data job for rApp metrics delivery, i.e., PM data delivery7. The rApp management sendee 902 may transmit the created data job to the rApp 202 over the R1 interface. For this,the rApp management service 902 may utilize one of a PUSH, a PULL, or a Kafka streaming. In an embodiment, creating the data job may be based on or similar to PerfMetricJob mechanism defined in the 3GPP TS 28.622 for the collection of the performance metrics. Alternatively, a new R1 API may be defined. The present disclosure proposes two options for the rApp metrics delivery to the rApp management service 902. In Option 1, at step 912. the rApp 202 may report the metrics details to the rApp management service 902 over the R1 interface. In Option 2, the rApp management service 902 may collect the metrics details either periodically or when notified. For example, at step 914, the rApp management service 902 may transmit a fetch metrics request to the rApp 202 over the R1 interface. In response, at step 916. the rApp 202 may transmit the metrics details to the rApp management service 902 in a fetch metrics response, over the R1 interface. The rApp interaction explained in FIG. 9 provides various advantages, such as providing a simple process for registering the performance metrics.

[0049] FIG. 10 illustrates a sequence flow diagram 1000 depicting an rApp interaction using the rApp management service 902 as an R1 sen ice. in accordance with an embodiment of the present disclosure. The sequence flow diagram 1000 may illustrate a sequence of operations between the rApp 202 and the rApp management service 902.

[0050] At step 1002, the rApp 202 may already be deployed or instantiated and the rApp instance may be registered. At step 1004, once the rApp instance is successfully registered, the rApp 202 may transmit a metric registration request to the rApp management service 902 over the R1 interface. The rApp 202 may transmit the metric registration request using Representational State Transfer (REST) based sen ice requests. The metric registration request may include, but is not limited to, an rApp ID and the rApp metrics details with metricName and metadata. In an embodiment, the rApp 202 may transmit the metric registration requestbased on or similar to the NF metric capability reporting mechanism defined in the 3GPP TSs 28.532 and 28.662. Alternatively, a new R1 API may be defined. Steps 1006-1012 may be similar to the steps 910-916 of FIG. 9. Hence, the description of steps 1006-1012 is omitted in respect of FIG. 10 for the sake of brevity. The rApp interaction explained in FIG. 10 provides various advantages. For example, the explained rApp interaction follows service-based architecture like all other Non-RT RIC functions. Further, the explained rApp interaction is dynamically manageable by the rApp management function (e.g., on-demand data subscription and exposure to other SMOs). Additionally, in the explained rApp interaction, the 3GPP TSs 28.532 and 28.662 may be either be re-used or enhanced for the generic or common metrics. For example, the rApp interaction may use SupportedPerfMetricGroups mechanism defined in TS 28.662 to report the metrics supported by the rApps 202. Further, the rApp interaction may use the PerfMetricJob mechanism to create a measurement job. Furthermore, the rApp interfaction may utilize a subscription procedure to subscribe for data streaming.

[0051] FIG. 11 illustrates a sequence flow diagram 1100 depicting an rApp interaction using a DME R1 sen ice, in accordance with an embodiment of the present disclosure. The sequence flow diagram 1100 may illustrate a sequence of operations between the rApp 202 and a DME 1102.

[0052] At step 1104, the rApp 202 may already be deployed or instantiated and the rApp instance may be registered. Accordingly, the rApp 202 may register the metrics with the DME 1102. For example, the rApp may register produced metrics with the DME 1102. At step 1106, the rApp 202 may transmit a Data Registration request to the DME 1102 over the R1 interface. At step 1108, the DME 1102 may provide data access, i.e., data job information (info) to the rApp 202 over the R1 interface. At step 1110, the rApp 202 may transmit the metrics based ona delivery method to the DME 1102, over the R1 interface. The DME 1102 may collect the metrics using an existing DME procedure and directly expose the metrics to the other SMOs. The rApp interaction explained in FIG. 11 has various advantages. For example, the explained rApp interaction may use existing DME interfaces and APIs. In an embodiment, the DME 1102 may be a part of the non-anchored function in the SMO(s) 206 or the Non-RT RIC 204.

[0053] FIGS. 12A-12B illustrate a sequence flow diagram 1200 depicting an overall process for handling the rApp’s performance metrics by the Non-RT RIC 204. in accordance with an embodiment of the present disclosure. The sequence flow diagram 1200 may illustrate a sequence of operations between the rApp 202, the rApp management service 902, the DME 1102. and the one or more SMO components (also referred to as ”SMO(s)") 206.

[0054] At step 1202, the rApp 202 may already be deployed or instantiated and the rApp instance may be registered. At step 1204, the rApp 202 may transmit a request to the rApp management service 902, over the R1 interface, to register or report the rApp’s supported PM metrics. The request may include, but is not limited to the rApp ID and the rAPP metrics details with the metricName and the metadata. At step 1206, the rApp management service 902 may transmit a request to the DME 1102 to register as a data producer. The request may be transmitted with, e.g., a DME type “oran:rAPPmetrics:1.0”. At step 1208, the DME 1102 may receive a Query DME type (e.g. “oran:rAPPmetrics: 1.0”) from the SMO(s) 206. At step 1210, the network operator may decide one or more metrics of interest. At step 1212, the SMO(s) 206 may transmit a data request for the DME type (e.g. DME type = “oran:rAPPmetrics:1.0”, prodJobDefn with a list of rApp IDs and metrics) to the DME 1102. At step 1214, the DME 1102 may forward the data request for the DME type to the rApp management service 902. Steps 1216-1222 may be similar to the steps 910-916 of FIG. 9. Hence, the description of steps1216-1222 is omited in conjunction with FIGs. 12A-12B for the sake of brevity. Further, at step 1224, requested data may be available at the rApp management service 902. At step 1226, the rApp management service 902 may deliver the data including the rApp metrics to the DME 1102. Finally, at step 1228, the DME 1102 may deliver the data to the SMO(s).

[0055] FIG. 13 illustrates a flowchart depicting a method 1300 for handling rApp’s performance metrics by the Non-RT RIC framework 204, in accordance with an embodiment of the present disclosure. The method may be performed by the one or more SMO components 206.

[0056] At step 1302, the method 1300 may include receiving, by one or more SMO components 206 and from one or more network applications 202, a first information. The first information may include the list of performance metrics supported by the one or more network applications 202 and the periodicity associated with the performance metrics in the list of performance metrics. The first information may also include configuration data associated with the one or more network applications, fault data associated with the one or more netw ork applications, and security data associated with the one or more network applications. In an embodiment, for receiving the first information, the method 1300 may include receiving a R1 Data register request from the one or more network applications 202. The R1 Data register request may include the first information. Further, the R1 Data register request may be received at the one or more network application management functions within the one or more SMO components 206, via the R1 interface. The one or more network application management functions may include the rApp Management Function 502. Further, the R1 interface may include the R1 DME service API. The R1 DME service API may be one of an existing R1 DME sen ice API or a new' R1 DME service API.

[0057] At step 1304, the method 1300 may include obtaining, based on the received first information, the one or more performance metrics among the list of performance metrics in a periodic manner to enable monitoring of performance of the one or more network applications. The one or more performance metrics may be obtained by the one or more network application management functions (i.e., the rApp Management Function 502) within the one or more SMO components 206 via the R1 interface.

[0058] In an embodiment, the method 1300 may include controlling, by the one or more SMO components 206, the one or more performance metrics. For controlling the one or more performance metrics, the method 1300 may include controlling one of the list of performance metrics and the periodicity associated with the performance metrics in the list of performance metrics. Additionally, for controlling the one or more performance metrics, the method 1300 may include updating a datajob update procedure for data subscription associated with the one or more performance metrics. The data job may be updated by the one or more network application management functions (i.e., the rApp Management Function 502) within one or more SMO components 206. Furthermore, for controlling the one or more performance metrics, the method 1300 may include re-deploying, by the one or more SMO components, a new version associated with each of the one or more network applications.

[0059] Advantageously, the present disclosure enables implementation of the rApp Management Function not only to support the performance management of rApps, but also, to extend its capabilities to include the full Faults, Configuration, Accounting, Performance, and Security' (FCAPS) management of the rApps in the future.

[0060] FIG. 14 illustrates a flowchart depicting a method 1400 for obtaining the one or more performance metrics, in accordance with an embodiment of the present disclosure. The methodmay be performed by the one or more SMO components 206. The method 1400 may be a part of the method 1300.

[0061] At step 1402, the method 1400 may include dynamically creating, by the one or more network application management functions (i.e., the rApp management function 502) within the one or more SMO components 206. the data job for data subscription associated with the one or more performance metrics.

[0062] At step 1404, the method 1400 may include dynamically obtaining, by the one or more network application management functions (i.e.. the rApp management function 502) via an R1 DME Data access API. the one or more performance metrics using the created data job.

[0063] In an embodiment, for obtaining the one or more performance metrics, the method 1400 may include obtaining the one or more performance metrics using a DME data offer procedure created by the one or more network applications 202. The one or more performance metrics may be obtained by the one or more SMO components 206 and from the one or more network applications 202. In an example embodiment, the DME data offer procedure may correspond to the data jobs explained in FIGs. 6-8.

[0064] FIG. 15 illustrates an embodiment of a device 1500, in accordance with an embodiment of the present disclosure. As shown in FIG. 15, the device 1500 includes a processor 1510, a memory 1520, a storage component 1530, an input component 1540, an output component 1550, a communication interface 1560, and a bus 1570. The device 1500 may correspond to the one or more SMO components 206. The one or more components of the device 1500 may be configured to implement one or more operations / functionalities of the present disclosure as discussed above.

[0065] The processor 1510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1510 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 1510 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0066] The memory 1520 includes a non-transitory computer readable medium. The memory 1520 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by the processor 1510. The memory 1520 comprises machine-readable instructions which are executable by the processor 1510. These machine-readable instructions when executed by the processor 1510 cause the processor 1510 to perform one or more method steps of an embodiment described above.

[0067] The storage component 1530 stores information and / or software related to the operation and use of the device 1500. For example, the storage component 1530 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another t pe of n on -tran si to ry computer-readable medium, along with a corresponding drive.

[0068] The input component 1540 is configured to receive information, such as user input. For example, the input component 1540 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, oralternatively, the input component 1540 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0069] The output component 1550 is configured to provide output information from the device 1500. For example, the output component 1550 may be. but not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0070] The communication interface 1560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1560 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 1500 and other devices. In other words, the standard of the communication interface 1560 is not limited.

[0071] The bus 1570 acts as an interconnect between the processor 1510, the memory 1520. the storage component 1530, the input component 1540, the output component 1550, and the communication interface 1560 of the device 1500. The bus 1570 may include a wired interconnection or a wireless interconnection.

[0072] The number and arrangement of components shown in FIG. 15 are provided as an example. In practice, the device 1500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 15.Additionally, or alternatively, a set of components (e.g., one or more components) of the device 1500 may perform one or more functions described as being performed by another set of components of the device 1500. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 1500 in communication with one another.

[0073] Examples of the techniques and apparatus described herein include, but are not limited to, the following enumerated embodiments:[1] An apparatus configured to:receive, from one or more network applications, a first information, wherein the first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with each performance metrics in the list of performance metrics: andobtain, by one or more network application management functions via an R1 interface and based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner to enable monitoring of performance of the one or more network applications.[2] The apparatus as described in [1]. wherein the apparatus corresponds to one or more Service Management and Orchestration (SMO) components, and to receive the first information, the apparatus is configured to:receive, at the one or more network application management functions within the one or more SMO components, via the R1 interface, a R1 Data register request from the one or more network applications, wherein the R1 Data register request comprises the first information.[3] The apparatus as described in any one of

[0001] -[2] , wherein the apparatus corresponds to one or more SMO components, and to obtain the one or more performance metrics, the apparatus is configured to:dynamically create, by the one or more network application management functions within the one or more SMO components, a data job for data subscription associated with the one or more performance metrics; anddynamically obtain, by the one or more network application management functions via an R1 DME Data access API, the one or more performance metrics using the created data job.[4] The apparatus as described in any one of [l]-[3], wherein the apparatus corresponds to one or more SMO components, and to obtain the one or more performance metrics, the apparatus is configured to:obtain, from the one or more network applications, the one or more performance metrics using a DME data offer procedure created by the one or more network applications.[5] The apparatus as described in any one of [l]-[4], further configured to control the one or more performance metrics, wherein to control the one or more performance metrics, the apparatus is configured to:control one of the list of performance metrics and the periodicity associated with each performance metrics in the list of performance metrics.[6] The apparatus as described in any one of [l]-[5], wherein to control the one or more performance metrics, the apparatus is configured to:update, by the one or more network application management functions within one or more SMO components, a data job update procedure for data subscription associated with the one or more performance metrics.[7] The apparatus as described in any one of [l]-[6], wherein the R1 interface includes an R1 Data Management and Exposure (DME) service Application Programming Interface (API).[8] The apparatus as described in any one of L 1 J-L7J, wherein the R1 DME service API is one of an existing R1 DME service API or a new R1 DME service API.[9] The apparatus as described in any one of [l]-[8], wherein the first information further comprises configuration data associated with the one or more network applications, fault data associated with the one or more network applications, and securitv data associated with the one or more network applications.

[0010] A method comprising:receiving, by one or more Service Management and Orchestration (SMO) components and from one or more network applications, a first information, wherein the first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with each performance metrics in the list of performance metrics; and obtaining, by one or more network application management functions within the one or more SMO components via an R1 interface and based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner to enable monitoring of performance of the one or more network applications.

[0011] The method as described in

[0010] , wherein receiving the first information comprises: receiving, at the one or more network application management functions within the one or more SMO components, via the R1 interface, a R1 Data register request from the one or more network applications, wherein the R1 Data register request comprises the first information.

[0012] The method as described in any one of

[0010] -[l 1], wherein obtaining the one or more performance metrics comprises:dynamically creating, by the one or more network application management functions within the one or more SMO components, a data job for data subscription associated with the one or more performance metrics; anddynamically obtaining, by the one or more network application management functions via an R1 DME Data access API, the one or more performance metrics using the created data job.

[0013] The method as described in any one of

[0010] -

[0012] , wherein obtaining the one or more performance metrics comprises:obtaining, by the one or more SMO components and from the one or more network applications, the one or more performance metrics using a DME data offer procedure created by the one or more network applications.

[0014] The method as described in any one of

[0010] -

[0013] , further comprising controlling, by the one or more SMO components, the one or more performance metrics, wherein controlling the one or more performance metrics comprises:controlling one of the list of performance metrics and the periodicity associated with each performance metrics in the list of performance metrics.

[0015] The method as described in any one of

[0010] -

[0014] , wherein controlling the one or more performance metrics comprises:updating, by the one or more network application management functions within one or more SMO components, a data job update procedure for data subscription associated with the one or more performance metrics.

[0016] The method as described in any of

[0010] -

[0015] , wherein controlling the one or more performance metrics comprises:re-deploying, by the one or more SMO components, a new version associated with each of the one or more network applications.

[0017] The method as described in any of

[0010] -

[0016] , wherein the R1 interface includes an R1 Data Management and Exposure (DME) service Application Programming Interface (API).

[0018] The method as described in any of

[0010] -

[0017] . wherein the R1 DME service API is one of an existing R1 DME sendee API or a new R1 DME service API.

[0019] The method as described in any of

[0010] -

[0018] , wherein the first information further comprises configuration data associated with the one or more network applications, fault data associated with the one or more network applications, and security data associated with the one or more network applications.

[0020] A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by one or more processors at one or more Service Management and Orchestration (SMO), cause the one or more processors to: receive, from one or more network applications, a first information, wherein the first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with each performance metrics in the list of performance metrics; andobtain, by the one or more netw ork application management functions within the one or more SMO components via an R1 interface and based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner to enable monitoring of performance of the one or more netw ork applications.Non-RT-RIC-ARCH-R004-v06.00 mentions[REQ-NRTFWK-FUN25] The Non-RT RIC framework shall support functionality that allows obtaining, from an rApp. information about that rApp's performance, if such functionality is not supported in the SMO framework.It further mentions in section 6.1The rApp management functions enable the management of rApps within the context of the SMO / Non-RT RIC framework. Such functions enable (not limited to) the configuration of rApps, providing access to fault and performance related information from rApps, and facilitation of rApp logging functionality. Through the use of Rl, rApp management to all rApps. functions can provide access to these functionalities in a consistent manner Section 7.8 rApp management senice mentionsrApp performance service: This service allows an rApp to report on the performance of the rApp itself or its communication with other entities.But it is not mentioned any further either in GAP or UCR document about these functionalities. So, this paper is brought to discuss how we can incorporate these functionalities in SMO / Non-RT RIC framework.E2E SMO Use-cases1. Operator / other SMO service should know what metrics rApps support.2. Operator / other SMO service should be able to obtain rApps’ PMs it would like to consume.3. Operator / other SMO service should(may) be able to control the set of PMs an rApp provides. Note: this requirement maybe not supported by / applied to all rApps UC 1: Operator / other SMO service should know what metrics rApps supportOptionl: Operator and rApp vendor can mutually decide which rApp metrics it is going to support.• No involvement of Non-RT R1C framework (no standardization)Option2: rApp informs operator about the metrics it supports during the rApp deployment using the rApp descriptor.Option3 : rApp register the metrics with rApp management service.Option3.1 : Define new R1 interface APIOptions.2: 3gpp based NF capability reporting and SupportedPerJMetricGroups . Ref: 3 GPP 28.532 and 28.662Option4: rApp uses existing R1 DME service API (dataType register request) to register the metrics.• Option4.1 : rApp register the data type with DME function using R1 DME service APIs• Option4.2 : rApp register the data type with rApp management function using R1 DME sen ice APIsUC 2: Operator / other SMO senice should be able to obtain rApps' PMs it would like to consume.Optionl: rApp reports the pre-agreed metrics periodically towards rApp management service.• rApp sends periodic metrics to Non-RT RIC fwk using new R1 API.Option2: Define a new R1 API to configure rApp about which metrics to be reported / collected (metrics list, periodicity ), and rApp reports metrics using new R1 API OptionS:. rApp is configured reusing 3GPP 28.532, 28.622 (PMMetricJob), and report metric using 3GPP streaming data reporting or file transfer services (3GPP based)Option4: RIC rApp management function obtains certain PM metrics to be produced by rApp using R1 DME service API• 4.1: data subscription (rApp management creates data job)• 4.2: data offer (rApp creates data offer)Option5 : RIC DME function obtains certain PM metrics to be produced by rApp using R1 DME service API• 5.1: data subscription (DME creates data j ob)• 5.2: data offer (rApp creates data offer)UC 3: Operator / other SMO service should(may) be able to control the set of PMs an rApp providesOptionl: Re-deploy a new version of rApp with agreed set of PMsOption2: rApp is configured reusing 3GPP 28.532, 28.622 (PMMetricJob), and report metric using 3 GPP streaming data reporting or file transfer servicesOption3: Defines a new R1 API to configure rApp about which metrics to be reported / collected (metrics list, periodicity), and report metrics using new R1 API.Option4: RIC rApp management function obtains certain PM metrics to be produced by rApp using R1 DME senice API• 4.1 : data subscription (rApp management updates data j ob)Option5: RIC DME function obtains certain PM metrics to be produced by rApp using R1 DME service API• 5.1: data subscription (DME creates data j ob)Considerations with High-level end to end flowrApps developed by multiple vendors must be able to report the Performance-Metrics of the application in a uniform and consistent way.• Operators / Administrator can use these performance metrics to monitor the behaviour or performance of an rApp.• rApp may report 2 categories of performance metrics• Performance metrics which are common generic across all rApps e.g. Number of dataJobs Created by the rApp; Number of Al policies created by rApp.• These metrics can also be collected by SMO / Non-RT RICfvk. Only metrics which framework will not be able to collect are the failure to send the R1 requests by any rApp.• Performance metrics which is use-case specific e.g. an MLB rApp may report Number of load balancing attempts, an Energy-saving rApp may report Number of cells optimized for Energy efficiency for operator monitoring purposes.• Involves 2 steps procedure• One time informing SMO / Non-RT RIC framework about the metrics rApp wants to report i.e. Registration of metrics with SMO / Non-RT RIC framework. Periodic collection / reporting of metrics.Proposals for DecisionsUC 1 : Operator / other SMO service should know what metrics rApps supportPreferred Option: rApp register the data type with SMO / Non-RT RIC framework using R1 DME service APIs (e.g. rApp management function implement R1 DME sendee provider)UC2: Operator / other SMO service should be able to obtain rApps’ PMs it would like to consume.Preferred Option: SMO / Non-RT RIC framework ask certain PM metrics to be produced by rApp using R1 DME service API using Data subscription (e.g. rApp management function implement R1 DME service subscription API as data consumer).UC3: Operator / other SMO service should(may) be able to update the set of PMs it would like to consumePreferred Option: SMO / Non-RT RIC framework update certain PM metrics to be produced by rApp using R1 DME service API using Data subscription (e.g. rApp management function implement R1 DME Update service subscription API as data consumer).Advantage:Using the existing DME service APIsEnable the use of rApp management function implementation for not only rApps PM but in future to have FCAP of rApp managed by this service.

[0074] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements can be at least one of a hardw are device or a combination of hardware devices and software modules. The one or more SMO components may include respective processors, communication units, and storage units (e.g., memory). The communication units may perform functions for transmitting and receiving signals. The storage units may include executable instructions that, when executed by the corresponding processors, cause the corresponding one or more SMO components to perform the functions as described above with reference to FIGS. 2-14.

[0075] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

[0076] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.

[0077] Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

[0078] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

[0079] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readilymodify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

We claim:

1. An apparatus configured to:receive, from one or more network applications, a first information, wherein the first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with each performance metrics in the list of performance metrics: andobtain, by one or more network application management functions via an R1 interface and based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner to enable monitoring of performance of the one or more network applications.

2. The apparatus as claimed in claim 1, wherein the apparatus corresponds to one or more Service Management and Orchestration (SMO) components, and to receive the first information, the apparatus is configured to:receive, at the one or more network application management functions within the one or more SMO components, via the R1 interface, a R1 Data register request from the one or more network applications, wherein the R1 Data register request comprises the first information.

3. The apparatus as claimed in claim 1, wherein the apparatus corresponds to one or more SMO components, and to obtain the one or more performance metrics, the apparatus is configured to:dynamically create, by the one or more network application management functions within the one or more SMO components, a data job for data subscription associated with the one or more performance metrics; anddynamically obtain, by the one or more network application management functions via an R1 DME Data access API, the one or more performance metrics using the created data job.

4. The apparatus as claimed in claim 1, wherein the apparatus corresponds to one or more SMO components, and to obtain the one or more performance metrics, the apparatus is configured to:obtain, from the one or more network applications, the one or more performance metrics using a DME data offer procedure created by the one or more network applications.

5. The apparatus as claimed in claim 1, further configured to control the one or more performance metrics, wherein to control the one or more performance metrics, the apparatus is configured to:control one of the list of performance metrics and the periodicity associated with each performance metrics in the list of performance metrics.

6. The apparatus as claimed in claim 5, wherein to control the one or more performance metrics, the apparatus is configured to:update, by the one or more network application management functions within one or more SMO components, a data job update procedure for data subscription associated with the one or more performance metrics.

7. The apparatus as claimed in claim 1, wherein the R1 interface includes an R1 Data Management and Exposure (DME) service Application Programming Interface (API).

8. The apparatus as claimed in claim 7, wherein the R1 DME service API is one of an existing R1 DME service API or a new R1 DME service API.

9. The apparatus as claimed in claim 2, wherein the first information further comprises configuration data associated with the one or more network applications, fault data associated with the one or more network applications, and security’ data associated with the one or more network applications.

10. A method comprising:receiving, by one or more Service Management and Orchestration (SMO) components and from one or more network applications, a first information, wherein the first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with each performance metrics in the list of performance metrics; and obtaining, by one or more network application management functions within the one or more SMO components via an R1 interface and based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner to enable monitoring of performance of the one or more network applications.

11. The method as claimed in claim 10, wherein receiving the first information comprises:receiving, at the one or more network application management functions within the one or more SMO components, via the R1 interface, a R1 Data register request from the one or more network applications, wherein the R1 Data register request comprises the first information.

12. The method as claimed in claim 10, wherein obtaining the one or more performance metrics comprises:dynamically creating, by the one or more network application management functions within the one or more SMO components, a data job for data subscription associated with the one or more performance metrics; anddynamically obtaining, by the one or more network application management functions via an R1 DME Data access API, the one or more performance metrics using the created data job.

13. The method as claimed in claim 10, wherein obtaining the one or more performance metrics comprises:obtaining, by the one or more SMO components and from the one or more network applications, the one or more performance metrics using a DME data offer procedure created by the one or more network applications.

14. The method as claimed in claim 10, further comprising controlling, by the one or more SMO components, the one or more performance metrics, wherein controlling the one or more performance metrics comprises:controlling one of the list of performance metrics and the periodicity associated with each performance metrics in the list of performance metrics.

15. The method as claimed in claim 14, wherein controlling the one or more performance metrics comprises:updating, by the one or more network application management functions within one or more SMO components, a data job update procedure for data subscription associated with the one or more performance metrics.

16. The method as claimed in claim 14, wherein controlling the one or more performance metrics comprises:re-deploying, by the one or more SMO components, a new version associated with each of the one or more network applications.

17. The method as claimed in claim 10, wherein the R1 interface includes an R1 Data Management and Exposure (DME) service Application Programming Interface (API).

18. The method as claimed in claim 17, wherein the R1 DME service API is one of an existing R1 DME service API or a new R1 DME service API.

19. The method as claimed in claim 11, wherein the first information further comprises configuration data associated with the one or more network applications, fault data associatedwith the one or more network applications, and security data associated with the one or more network applications.

20. A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by one or more processors at one or more Service Management and Orchestration (SMO) components, cause the one or more processors to:receive, from one or more network applications, a first information, wherein the first information comprises a list of performance metrics supported by the one or more network applications and a periodicity associated with each performance metrics in the list of performance metrics: andobtain, by one or more network application management functions within the one or more SMO components via an R1 interface and based on the received first information, one or more performance metrics among the list of performance metrics in a periodic manner to enable monitoring of performance of the one or more network applications.

Images