Alarm management in a network

Abstract

Provided are apparatus, method, and device for automatically manage alarms in a network. According to example embodiments, the apparatus may comprise a non-real-time RAN Intelligent Controller (Non-RT RIC) that may be configured to: receive, from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validate the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmit the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).

Description

ALARM MANAGEMENT IN A NETWORKFIELD

[0001] The present disclosure relates to an alarm management in a network.BACKGROUND

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

[0003] A radio access network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-users to a core network. Traditionally, hardware and / or software of a particular RAN is vendor specific.

[0004] Open RAN (0-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based), or could be in physical hardware form (e.g., non-VM based).SUMMARY

[0005] Example embodiments of the present disclosure automatically manage alarms in a network. As such, example embodiments of the present disclosure allows for an rApp to register alarms specific to its operation, as well as provides access for the rApp to raise and / or clear any alarms generated by other entities in the network.

[0006] According to example embodiments, an apparatus is provided. The apparatus may comprise a non-real-time RAN Intelligent Controller (Non-RT RIC) that may be configured to: receive, from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validate the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmit the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).

[0007] According to example embodiments, a method is provided. The method may include: receiving, by a non-real-time RAN Intelligent Controller (Non-RT RIC) from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validating, by the Non-RT RIC, the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmitting, by the Non-RT RIC,the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).

[0008] According to example embodiments, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium may have recorded thereon instructions executable by an apparatus that may comprise a non-real-time RAN Intelligent Controller (Non-RT RIC) to cause the Non-RT RIC to perform a method including: receiving, from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validating the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmitting the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).

[0009] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE 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:

[0011] FIG. 1 illustrates an example system architecture, according to one or more example embodiments;

[0012] FIG. 2 illustrates a flow diagram of an example method for managing alarms, according to one or more example embodiments;

[0013] FIG. 3 illustrates a flow diagram of an example method for managing a request to register an alarm, according to one or more example embodiments;

[0014] FIG. 4 illustrates a flow sequence of an example use case for managing the request to register an alarm, according to one or more example embodiments;

[0015] FIG. 5 illustrates a flow diagram of an example method for managing a request to raise an alarm, according to one or more example embodiments;

[0016] FIG. 6 illustrates a flow sequence of an example use case for managing the request to raise an alarm, according to one or more example embodiments;

[0017] FIG. 7 illustrates a flow diagram of an example method for managing a request to clear an alarm, according to one or more example embodiments;

[0018] FIG. 8 illustrates a flow sequence of an example use case for managing the request to clear an alarm, according to one or more example embodiments; and

[0019] FIG. 9 illustrates a diagram of example components of a device for implementing one or more example embodiments.DETAILED DESCRIPTION

[0020] The following detailed description of example embodiments refers to the accompanying drawings. The present disclosure provides illustrations and descriptions, 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 present disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodimentmay 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 at least one of the embodiments in the present disclosure. 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). Further, the order of one or more operations may be switched, as long as these modifications may not affect the resulting scope of the disclosure.

[0021] 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 hardware or software code used to implement these systems and / or methods should not limit their implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0022] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, the particular 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. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims in the claim set.

[0023] 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” (in other words, nouns not mentioned in the plural) 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. Further still, where only one item is intended, the term “one” or similar language is used.

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

[0025] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (0-RAN) Alliance standard organization, and the like. For instance, the terms “Alarms”, “SMO”, “Non-RT RIC”, “Near-RT RIC”, “FM”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications.

[0026] Further, although some embodiments of the present disclosure may be described herein with reference specific components of 5G system, it can be understood that the scope of the present disclosure should not be limited thereto. Specifically, example embodiments of the present disclosure may also apply to any suitable network elements in any suitable telecommunications system, such as a 4G LTE system, a 6G system, and the like, without departing from the scope of the present disclosure.

[0027] As described above, 0-RAN technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. To this end, 0-RAN disaggregates the RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU may be a logical node hosting Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0028] In this regard, fault management (FM) service in a Service and Management Orchestration (SMO) is an important aspect of the 0-RAN. The FM service in the SMO allows for management of various alarms in response to unexpected errors, conflicts, and issues that occur within the network. The various alarms managed by the FM service in the SMO may include general, common, and / or predefined alarms.

[0029] Here, as described above, the 0-RAN architectures enable multiple vendors to provide hardware and / or software to a telecommunications system. In particular, multiple vendors may deploy multiple applications, such as rApps on a non-real time RAN intelligence controller, where such applications may be configured to perform various operations and functions, and may want to register, raise, and / or clear certain specific alarms in view of such operations and functions.

[0030] However, in the related art, there are currently no defined mechanism for the rApps to interact with the SMO in order to register, raise, and clear alarms in the network.

[0031] Accordingly, system, methods, devices, and the like, provided in the example embodiments of the present disclosure automatically manage alarms in a network.

[0032] According to example embodiments, an rApp may transmit at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm to a Non-RT RIC, where the Non-RT RIC may then validate the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database. In this regard, in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmit the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO), such that the SMO may accordingly register, raise, and / or clear the alarms.

[0033] Ultimately, example embodiments of the present disclosure automatically manage alarms in the network, which allows for the rApp to register alarms specific to its operation, as well as provides access for the rApp to raise and / or clear any alarms generated by other entities in the network.

[0034] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0035] Further descriptions of the features, components, configuration, operations, and implementations of the system of the present disclosure, according to one or more example embodiments, are provided in the following.Example System Architecture

[0036] FIG. 1 illustrates an example system architecture, according to one or more example embodiments. As illustrated in FIG. 1, the system architecture may include at least one Service Management and Orchestration (SMO) framework 110 that includes at least one non-real- time RAN Intelligent Controller (Non-RT RIC) 120, at least one near-real-time RIC (Near-RT RIC) 130, at least one 0-RAN Centralized Unit (O-CU) that may be disaggregated into an O-CU control plane (O-CU-CP) 140 and an O-CU user plane (O-CU-UP) 150, at least one open evolved NodeB (O-eNB), at least one 0-RAN Distributed Unit (O-DU) 170, at least one 0-RAN Radio Unit (O-RU) 180, and at least one O-RAN Cloud (O-Cloud) 190. The components may be communicatively coupled to another component(s) within the system architecture via a respective interface(s).

[0037] It is contemplated that the system architecture may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, in some implementations, the system architecture may further include a plurality of O-DUs, a plurality of O-RUs, and the like.

[0038] The RAN functions in the system may be controlled and optimized by at least oneRIC. The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability, as well as to automate and optimize RAN operations. As shown in FIG. 1, the RIC may be divided into two types, i.e., the Non-RT RIC 120 and the Near- RT RIC 130. In the following, descriptions of the Non-RT RIC 120 are provided, followed by the descriptions of the Near-RT RIC 130.

[0039] The Non-RT RIC 120 may refer to a logical function within the SMO framework 110 that drives the content carried across the Al interface to enable non-real-time control and optimization of RAN elements and resources. The Al interface may refer to a logical interface between the Non-RT RIC 120 and the Near-RT RIC 130, which enables the Non-RT RIC 120 to provide policy-based guidance (objective, resource) to the Near-RT RIC 130 and enables the Near- RT RIC 130 to provide one or more feedbacks to the Non-RT RIC 120 to monitor the status of one or more policies.

[0040] In some example, implementations, the Non-RT RIC 120 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within the SMO framework 110. The functionalities of the Non-RT RIC 120 may include, for example, providing policy-based guidance and enrichment across the Al interface, performing data analytics, Artificial Intelligence / Machine Learning (AI / ML) models training and inference for RAN optimization, and / or recommending configuration management actions. As further described below, the Non-RT RIC 120 may access or communicate with other SMO framework functionalities or components via Al interface, 01 interface, 02 interface, and one or more interfaces associated with one or more open fronthaul planes.

[0041] According to example embodiments, the functionalities of the Non-RT RIC 120 may be implemented through at least one modular, Non-RT RIC application, such as an rApp (not shown). The rApp may leverage the functionalities available in the SMO framework 110 and / or the Non-RT RIC 120 to provide value added services related to RAN operation and optimization, such as policy management, radio resource management, data analytics, and providing enrichment information. In some implementations, the Non-RT RIC 120 may implement a plurality of rApps.

[0042] According to example embodiments, the Non-RT RIC 120 may include a Non-RT RIC framework that may be configured to provide or implement one or more services to the rApp through R1 interface. The R1 interface may refer to an open logical interface between the rApp and the Non-RT RIC framework. The R1 interface supports the exchange of data or information, as well as the collection and delivery of data between the rApp and the Non-RT RIC framework. The one or more services, which may also be referred to as “R1 services” herein, may include policy management services, service registration and discovery services, authentication and authorization services, AI / ML workflow services, RAN OAM-related services, Al related services, and 02 related services. The R1 interface allows multi-vendor rApps to manage or add the R1 services, and facilitate inter-connection between rApps and Non-RT RIC framework supplied by different vendors. Additionally, the Non-RT RIC framework may also implement an rApp Manager, which may be configured to process requests and messages from the rApp and manage various operations of the Non-RT RIC framework in relation to such requests and messages.

[0043] According to example embodiments, the rApp may be configured to manage one or more policies that are provided to the Near-RT RIC 130 over the Al interface. Said policies may be referred to as “Al policies” herein, and are declarative policies that contain statements onpolicy objectives and policy resources applicable to one or more network nodes (e.g., one or moreUEs, one or more network cells, etc.). Specifically, the one or more Al policies may consist of a scope identifier and one or more policy statements. The scope identifier may represent what the policy statements are to be applied on (e.g. UEs, QoS flows, or cells). The policy statements may define the goals or objectives of the policy and may include information associated with policy objectives and policy resources. In an example, the Al policies may include Quality of Service (QoS) requirements and Energy Saving (ES) requirements, specifying, for example, new QoS Class Identifier (QCI) parameters that an xApp should follow / utilize, and energy saving aggressiveness. By including the policy objectives in the policy statements, the quality of experience can be optimized for UEs or QoS flows that are identified either explicitly by, for example, a UE identifier or a QoS identifier, or implicitly by, for example, a group identifier from which the Near-RT RIC 230 can deduce a set of UEs. On the other hand, by including the policy resources in the policy statements, UEs can be configured to avoid certain cells and / or the radio network can be optimized in specific areas.

[0044] The rApp (or the Non-RT RIC framework within the Non-RT RIC 120) may provide the one or more Al policies to the Near-RT RIC 130, thereby providing guidance to the Near-RT RIC 130 towards one or more objectives or goals defined in the RAN intent. The RAN intent may refer to the high-level operational or business goal(s) to be achieved by the RAN, which may be defined by one or more desired service level agreements (SLAs) that the RAN is to fulfill for all users or for a subset of users in a given area over at least a predefined period of time.

[0045] According to example embodiments, the rApp may be configured to perform one or more policy management operations to provision and manage one or more Al policies in theNear-RT RIC 130. Specifically, the rApp may be configured to create, update and delete one or more Al policies in the Near-RT RIC 130. For instance, the rApp may query the presence, content and run-time status of one or more Al policies in the Near-RT RIC 130.

[0046] In some example embodiments, the rApp may communicate with the Non-RT RIC 120 and the SMO 110 in order to register, raise, and / or clear alarms. For example, the rApp may communicate with the Non-RT RIC 120 and the SMO 110 in order to register a particular alarm based on requirements (e.g., quality of service (QoS) requirement s), energy saving requirement s), etc.) as part of a policy. In another example, the rApp may determine that a particular alarm should be raised and / or cleared (e.g., based on feedback received via O1 / O2 interfaces, predefined trigger conditions, input from a user, and the like), and may accordingly communicate with the Non-RT RIC 120 and the SMO 110 in order to raise and / or clear such particular alarm.

[0047] According to example embodiments, the rApp may be configured to receive, from the Near-RT RIC via the Al interface, one or more feedback associated with one or more Al policies (“Al policy feedback” herein). Similarly, the rApp may be configured to receive one or more observables (e.g., events, counters, etc.) provided by the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-DU 170, and / or the O-RU 180 over the 01 interface. Accordingly, the rApp may be configured to continuously (or periodically) manage the one or more Al policies based on the Al policy feedback(s) and / or the observables provided over the 01 interface. For instance, the rApp may continuously (or periodically) evaluate the impact or effectiveness of the one or more Al policies towards the fulfillment of the RAN intent and then configure or update the one or moreAl policies accordingly.

[0048] In addition to the communication with the Near-RT-RIC 130 via the Al interface, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may communicate with the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and the O-RU 180 via the 01 interface. In this regard, the 01 interface may refer to a logical interface between the SMO framework 110, the Near-RT RIC 130, the O-CU (O-CU-CP 140 / O- CU-UP 150), the O-eNB 160, the O-DU 170, and the O-RU 180, which enables the SMO framework 110 (as well as the Non-RT RIC 120 and the rApp implemented therein) to provide Fault, Configuration, Accounting, Performance, and Security (FCAPS) and other management operations, such as network monitoring, network discovery, and the like, to the Near-RT RIC 130, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and / or the O-RU 180. Additionally, the 01 interface enables the Near-RT RIC 130, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and / or the O-RU 180 to provide information or observable(s) that may be utilized by the Non-RT RIC 120 (or the rApp) to manage the Al policy(s), to train one or more AI / ML models, and the like.

[0049] Further, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may communicate with the O-Cloud 190 via the 02 interface. In this regard, the 02 interface may refer to a logical interface between the SMO framework 110 and the O-Cloud 190, which may be a collection of physical RAN nodes that host the Non-RT RIC 120, the Near- RT RIC 130, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, and the O-DU 170, the supporting software components (e.g., the operating systems and runtime environments), and the SMO framework 110 itself. In other words, the SMO framework 110 may manage the O-Cloud190 from within, and the 02 interface may be the interface between the SMO framework 110 andthe O-Cloud 190 it resides in. Through the 02 interface, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may provide infrastructure management services (IMS) and deployment management services (DMS) for the O-Cloud 190.

[0050] Furthermore, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may communicate with the O-RU 180 via an open fronthaul (O-FH) management plane (M-Plane) interface. In this regard, the O-FH M-Plane may enable the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) to perform one or more FCAPS operations on the O-RU 180.

[0051] Next, the descriptions of the Near-RT RIC 130 are provided. The Near-RT RIC 130 may refer to a logical function that enables near-real-time control and optimization of RAN elements and resources. For instance, the Near-RT RIC 130 may provide the near-real-time control and optimization via fine-grained (e.g., UE basis, Cell basis) data collection and actions over the E2 interface. In some example, implementations, the Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-CU (O-CU-CP 140 / O-CU- UP 150), the O-eNB 160, and the O-DU 170 via the E2 interface. The Near-RT RIC 130 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) over a near-real-time control loop.

[0052] According to example embodiments, the Near-RT RIC 130 may monitor, suspend / stop, override, and control the E2 nodes (e g., the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, and the O-DU 170, etc.) via one or more policies (e.g., Al policies). For example, the Near-RT RIC 130 may receive the one or more Al policies from the Non-RT RIC 120 (or the rApp implemented therein) and then configure or set one or more policy parameters associatedwith the one or more Al policies on activated functions of the E2 nodes. Further, the Near-RT RIC130 may host one or more applications, such as the xApp (not shown), to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, and the like.

[0053] In this regard, the xApp may consist of one or more microservices, which may be independent of the Near-RT RIC 130 and may be provided by any third party. The E2 interface enables a direct association between the xApp and other RAN functionalities (e.g., the O-CU (O- CU-CP 140 / O-CU-UP 150), the O-eNB 160, and the O-DU 170, etc.), thereby enabling the xApp to provide information or data to the RAN functionalities for further utilization. According to example embodiments, the Near-RT RIC 130 may consist of multiple xApps and a set of platform functions that are commonly used to support the specific functions hosted by the multiple xApps. In this regard, the Near-RT RIC platform may communicate with the xApp(s) via one or more application programming interfaces (APIs). Further, the Near-RT RIC platform may be configured to route Al policy management messages to the registered xApps based on Al policy type and operator policies.

[0054] According to example embodiments, the Near-RT RIC 130 may implement the xApp to configure one or more parameters associated with an operation and then provide the one or more configured parameters to the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and / or the 0-RU 180.

[0055] According to example embodiments, the xApp may be configured to adjust or configure one or more of the above-described parameters and optimize said one or more parameters according to the current Al policy(s) and the current network condition(s) (e.g., load,energy consumption, etc.), thereby providing controlling latency and throughput that fulfills the QoS requirement(s) and / or the energy saving requirement(s).

[0056] According to example embodiments, the xApp may be configured to perform the one or more control operations via the E2 interface. For instance, the xApp may be configured to perform 0-DU E2 control and send one or more associated commands to the 0-DU 170. Accordingly, the 0-DU 170 may control the associated O-RU(s) or cell(s) to perform an operation. As another example, the xApp may be configured to perform O-CU E2 control, where the O-CU (O-CU-CP 140 / O-CU-UP 150) may send the one or more associated commands to the 0-DU 170, and the 0-DU 170 may then control the associated O-RU(s) or cell(s) to perform an operation. Accordingly, the O-DU 170 may in the end shape the E2 control and policy.

[0057] Next, the descriptions of the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-DU 170, and the 0-RU 180 are provided. Generally, the O-CU (O-CU-CP 140 / O-CU-UP 150), the 0-DU 170, and the 0-RU 180 may constitute a base station, such as a gNodeB (gNB) of 5G NR or a node in Next Generation Radio Access Network (NG-RAN), an Evolved Node B (eNodeB) of a 4G LTE network, a base station of a 6G network, and the like.

[0058] The communication between the O-CU and the O-DU 170 may be performed via an Fl interface, in particular, the communication between the O-CU-CP 140 and the O-DU 170 may be performed via an Fl-c interface, while the communication between the O-CU-UP 150 and the O-DU 170 may be performed via an Fl-u interface. The communication between the O-DU 170 and the O-RU 180 may be performed via one or more O-FH Control (C), User (U), Synchronization (S), and Management (M) plane interfaces. In some implementations, the C, U, and S planes may be consolidated and referred to as the “CUS-plane”. According to exampleembodiments, the system may include a plurality of O-DUs 170, and the O-CU may be communicatively coupled to the plurality of O-DUs via the Fl interface. Similarly, the system may include a plurality of O-RUs 180, and the O-DU 170 may be communicatively coupled to the plurality of O-RUs via one or more of the O-FH C / U / S / M plane interfaces.

[0059] According to example embodiments, the O-CU (O-CU-CP 140 / O-CU-UP 150) and the O-DU 170 may be defined in software form and may be deployed in one or more network nodes. For instance, the O-CU (O-CU-CP 140 / O-CU-UP 150) and the O-DU 170 may be deployed in one or more servers in the form of virtualized network function (VNF), containerized and / or cloud-native function (CNF), and the like. According to example embodiments, the O-CU (O-CU- CP 140 / O-CU-UP 150) and the O-DU 170 may be deployed in the same network node (e.g., same server) and / or may be located at a similar geographical location (e.g., be deployed in different servers in the same data center). According to example embodiments, the O-CU (O-CU-CP 140 / O- CU-UP 150) and the O-DU 170 may be deployed in different network nodes and / or may be located at different geographical locations. For instance, the O-CU (O-CU-CP 140 / O-CU-UP 150) may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU 170 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0060] The O-DU 170 may receive radio signals from an end user (via one or more UEs and one or more cells) and may provide operation or support for lower layers of protocol stacks (e g., RLC layer, MAC layer, Physical Layer, etc.) accordingly. As an example, the O-DU 170 may perform one or more scheduling operations. The O-CU (O-CU-CP 140 / O-CU-UP 150) may communicatively couple the O-DU 170 to a core network (e.g., 4G Evolved Packet Core (EPC)network, 5G Core network, etc.) and may receive the radio signals from the O-DU 170, thereby providing operation or support for higher layers of protocol stacks (e.g., PDCP layer, RRC layer, etc.) accordingly.

[0061] As described above, according to example embodiments, the O-CU may include anO-CU control plane (O-CU-CP) 140 and an O-CU user plane (O-CU-UP) 150. The O-CU-CP 140 may refer to the logical node that hosts or implements the RRC and the control plane part of the PDCP protocol, and may be responsible for managing the signaling between the core network and the radio network, handling tasks such as session management, radio bearer control, and mobility management. On the other hand, the O-CU-UP 150 may refer to the logical node that hosts or implements the user plane part of the PDCP protocol and the SDAP protocol, and may be responsible for managing the data traffic and the transmission of user data packets. The O-CU-CP 140 and the O-CU-UP 150 may be coupled to each other via the El interface.

[0062] Further, a single O-DU 170 may host or serve multiple network cells formed by multiple O-RUs 180. According to example embodiments, the O-DU 170 may implement various radio technologies, such as massive multiple-input multiple-output (MZMO), beamforming, and the like, to optimize radio communication among the multiple cells and the O-CU (O-CU-CP 140 / O-CU-UP 150). In some implementations, the O-DU 170 may concurrently host or serve hundreds (e.g., 512, etc.) of cells at a time.

[0063] The 0-RU 180 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 170. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may includea macro cell, a micro cell, a pi co cell, a femto cell, and / or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which the O-RU 180, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein.

[0064] According to example embodiments, the 0-DU 170 may be configured to control or instruct the associated O-RU(s) via one or more of the O-FH C / U / S / M plane interfaces. For instance, the O-DU 170 may instruct the O-RU 180 to enter the sleep mode via the O-FH C / U / S plane interfaces. On the other hand, the capability exchange between the O-DU 170 and the O-RU 180 may be performed via the O-FH M-plane interface. As an example, the O-RU 180 may inform the O-DU 170 of the amount of time it requires to maintain in the sleep mode in order to save an amount of energy.Example Operations for Managing Alarms in the Present Disclosure

[0065] In the following, several example operations are performable by the apparatus of one or more example embodiments of the present disclosure are described with reference to FIG. 2 to FIG. 8.

[0066] FIG. 2 illustrates a flow diagram of an example method 200 for managing alarms, according to one or more example embodiments. One or more operations in method 200 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage alarms in a network. According to example embodiments, the apparatus may comprise a non-real-time RAN Intelligent Controller (Non-RT RIC), which may be configured to perform one or more operations in method 200.

[0067] As illustrated in FIG. 2, at operation S210, the apparatus may be configured to receive at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm. The at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm may be received from an rApp, which may be deployed at the Non-RT RIC and may be communicatively coupled to the Non-RT RIC via an R1 interface. According to example embodiments, the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm may be received via the R1 interface. The method then proceeds to operation S220.

[0068] At operation S220, the apparatus may be configured to validate the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm. The above validation may be performed based on an alarm registration database. According to example embodiments, the alarm registration database may be comprised in the Non-RT RIC, and may store information associated with alarms that have already been registered in the network.

[0069] In response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, the apparatus may determine that the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm should be forwarded to a Service Management and Orchestration (SMO), and the method proceeds to operation S230. On the other hand, in response to a failed validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, the apparatus may determine that the rApp should be notified of the failed validation, and the method proceeds to operation S240.

[0070] At operation S230, in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, the apparatus may be configured to transmit the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to the SMO. According to example embodiments, the apparatus may be configured to transmit the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a fault management (FM) service of the SMO, such that the FM service may accordingly register, raise and / or clear the alarm. According to example embodiments, the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm may be transmitted via the SMO’s application programming interface (API) gateways.

[0071] At operation S240, in response to a failed validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, the apparatus may be configured to transmit a failure notification to the rApp. The failure notification may include an indication that the validation has failed along with any associated information. According to example embodiments, the failure notification may be transmitted via the R1 interface.

[0072] Examples of operations for managing each of the request to register the alarm, the request to raise the alarm, and the request to clear the alarm are described below with reference to FIG. 3 to FIG. 8.

[0073] Upon performing operation S230 and / or S240, the method 200 may be ended or be terminated. Alternatively, method 200 may return to operation S210, such that the apparatus may be configured to repeatedly perform, for at least a predetermined amount of time, the receiving theat least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm (at operation S210), the validating the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm (at operation S220), the transmitting the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm (at operation S230), and / or the transmitting the failure notification (at operation S240).

[0074] For instance, the apparatus may first receive a request to raise the alarm, and then perform the receiving the request to raise the alarm (at operation S210), the validating the request to raise the alarm (at operation S220), the transmitting the request to raise the alarm (at operation S230), and / or the transmitting the failure notification (at operation S240).

[0075] Then, at a later time, the apparatus may receive a request to clear the alarm, and then perform the receiving the request to clear the alarm (at operation S210), the validating the request to clear the alarm (at operation S220), the transmitting the request to clear the alarm (at operation S230), and / or the transmitting the failure notification (at operation S240).

[0076] Accordingly, the above processes provide a mechanism that allows for the rApp to register alarms specific to its operation, as well as provides access for the rApp to raise and / or clear any alarms generated by other entities in the network.Example Operations for Managing a Request to Register an Alarm in the Present Disclosure

[0077] In the following, several example operations performable by the apparatus of one or more example embodiments of the present disclosure are described with reference to FIG. 3 toFIG. 4.

[0078] FIG. 3 illustrates a flow diagram of an example method 300 for managing a request to register an alarm, according to one or more example embodiments. One or more operations of method 300 may be part of operation S210 to S240 in method 200, and may be performed by the apparatus of one or more example embodiments of the present disclosure.

[0079] As illustrated in FIG. 3, at operation S310, the apparatus may be configured to receive a request to register an alarm. The request to register the alarm may be received from an rApp, which may be deployed at the Non-RT RIC and may be communicatively coupled to the Non-RT RIC via an R1 interface.

[0080] According to example embodiments, the request to register the alarm may include any additional information associated with the alarm, such as identification of the rApp (i.e., the rApp which is transmitting the request to register the alarm), name of the alarm, descriptions of the alarm, classification of the alarm, services in the network that are affected by the alarm, priority of the alarm, and the like. The method then proceeds to operation S320.

[0081] At operation S320, the apparatus may be configured to validate the request to register the alarm. The above validation may be performed based on an alarm registration database. According to example embodiments, the alarm registration database may be comprised in the Non- RT RIC, and may store information associated with alarms that have already been registered in the network.

[0082] According to example embodiments, the apparatus may be configured to validate the request to register the alarm by determining whether the alarm is already registered in the alarm registration database. For example, based on information associated with the alarm included in therequest to register the alarm (e.g., name, descriptions, and the like), the apparatus may determine whether such alarm has already been registered and specified in the alarm registration database.

[0083] In response to determining that the alarm is not already registered in the alarm registration database, the apparatus may determine that the validation is successful and the request to register the alarm should be forwarded to a Service Management and Orchestration (SMO) such that the alarm can be registered in the network, and the method proceeds to operation S33O. On the other hand, in response to determining that the alarm is already registered in the alarm registration database, the apparatus may determine that the validation is failed and the rApp should be notified of the failed validation, and the method proceeds to operation S370.

[0084] At operation S330, in response to a successful validation of the request to register the alarm, the apparatus may be configured to transmit the request to register the alarm to the SMO. According to example embodiments, the apparatus may be configured to transmit the request to register the alarm to a fault management (FM) service of the SMO, such that the FM service may accordingly register the alarm. The method then proceeds to operation S340.

[0085] At operation S340, the apparatus may be configured to receive a registration notification from the SMO. The registration notification may indicate a status of the registration of the alarm, such as successful or failed. In particular, for example, in response to receiving the request to register the alarm from the apparatus, the SMO (or the FM service of the SMO) may accordingly register the alarm, and in response to a successful registration of the alarm, the SMO (or the FM service of the SMO) may transmit the registration notification to the apparatus, where the registration notification may indicate the status of the registration of the alarm as successful.

[0086] According to example embodiments, in response to a successful registration of the alarm, the SMO (or the FM service of the SMO) may be configured to generate an alarm identification for the alarm (alarmidentifier), where such alarm identification may be included in the registration notification transmitted to the apparatus. Alternatively, according to example embodiments, in response to determining that the alarm is not already registered in the alarm registration database (i.e., in response to a successful validation of the request to register the alarm), the apparatus may be configured to generate the alarm identification for the alarm (alarmidentifier), and transmit such alarm identification to the SMO along with the request to register the alarm. The method then proceeds to operation S350.

[0087] At operation S350, the apparatus may be configured to store information associated with the alarm in the alarm registration database. The information may include the information associated with the alarm included in the request to register the alarm, as well as the alarm identification. The method then proceeds to operation S360.

[0088] At operation S360, the apparatus may be configured to transmit the registration notification to the rApp. The registration notification may indicate the status of the registration of the alarm, and may include the alarm identification.

[0089] At operation S370, in response to a failed validation of the request to register the alarm, the apparatus may be configured to transmit a failure notification to the rApp. The failure notification may include an indication that the validation has failed. In particular, the failure notification may indicate that the alarm has already been registered.

[0090] According to example embodiments, the failure notification may include an alarm identification of the alarm. In particular, as described above in relation to operations S340 andS350, once the alarm has been successfully registered, an alarm identification may be generated and stored in the alarm registration database. Accordingly, if the apparatus determines that the alarm has already been registered during operation S320, the apparatus may be configured to obtain the alarm identification of such alarm from the alarm registration database, and include such alarm identification in the failure notification transmitted to the rApp during operation S370.

[0091] FIG. 4 illustrates a flow sequence of an example use case for managing the request to register the alarm, according to one or more example embodiments. As shown in FIG. 4, the flow sequence may involve an rApp 410, a Non-RT RIC 420, and an SMO 430. The rApp 410, Non-RT RIC 420, and SMO 430 may be similar to the rApp, Non-RT RIC 120, and SMO 110 described above in relation to FIG. 1. Further, one or more operations in FIG. 4 may involve or may be part of one or more operations described above with reference to FIG. 3.

[0092] At step 1, the rApp 410 may transmit the request to register the alarm to the Non- RT RIC 420, in the similar manner as described above in relation to operation S310 in method 300. According to example embodiments, the request to register the alarm may be transmitted from the rApp 410 to the Non-RT RIC 420 via the R1 interface to an R1 termination and / or rApp Manager at the Non-RT RIC 420.

[0093] At step 2, the Non-RT RIC 420 may determine whether the alarm has already been registered, in the similar manner as described above in relation to operation S320 in method 300.

[0094] If the Non-RT RIC 420 determines that the alarm has already been registered, at step 3, the Non-RT RIC 420 may transmit a failure notification indicating that the alarm has already been registered along with an alarm identification, in the similar manner as described above in relation to operation S370 in method 300. According to example embodiments, the failurenotification may be transmitted from the Non-RT RIC 420 to the rApp 410 via the R1 termination and / or rApp Manager at the Non-RT RIC 420 through the R1 interface.

[0095] If the Non-RT RIC 420 determines that the alarm has not already been registered, at step 4, the Non-RT RIC 420 may transmit the request to register the alarm to the SMO 430, in the similar manner as described above in relation to operation S33O in method 300. According to example embodiments, the request to register the alarm may be transmitted from the Non-RT RIC 420 to the SMO 430 via SMO 430’s application programming interface (API) gateways.

[0096] At step 5, the SMO 430 may transmit a registration notification to the Non-RT RIC 420, in the similar manner as described above in relation to operation S340 in method 300. According to example embodiments, the registration notification may be transmitted from the SMO 430 to the Non-RT RIC 420 via SMO 430’ s application programming interface (API) gateways.

[0097] At step 6, the Non-RT RIC 420 may store information associated with the alarm in the alarm registration database, in the similar manner as described above in relation to operation S350 in method 300.

[0098] At step 7, the Non-RT RIC 420 may transmit the registration notification to the rApp 410, in the similar manner as described above in relation to operation S360 in method 300. According to example embodiments, the registration notification may be transmitted from the Non-RT RIC 420 to the rApp 410 via the R1 termination and / or rApp Manager at the Non-RT RIC 420 through the R1 interface.Example Operations for Managing a Request to Raise an Alarm in the Present Disclosure

[0099] In the following, several example operations performable by the apparatus of one or more example embodiments of the present disclosure are described with reference to FIG. 5 to FIG. 6.

[0100] FIG. 5 illustrates a flow diagram of an example method 500 for managing a request to raise an alarm, according to one or more example embodiments. One or more operations of method 500 may be part of operation S210 to S240 in method 200, and may be performed by the apparatus of one or more example embodiments of the present disclosure.

[0101] As illustrated in FIG. 5, at operation S510, the apparatus may be configured to receive a request to raise an alarm. The request to raise the alarm may be received from an rApp, which may be deployed at the Non-RT RIC and may be communicatively coupled to the Non-RT RIC via an R1 interface.

[0102] In particular, for example, the rApp may want to access a conflict management service at the SMO in order to ensure that a certain operation will not cause any conflict in the network. Here, the rApp may detect that the conflict management service is down and / or cannot be accessed. Accordingly, the rApp may transmit a request to raise an alarm, in order to notify the network that the conflict management service is down.

[0103] According to example embodiments, the request to raise the alarm may include an alarm identification associated with the alarm. According to example embodiments, the request to raise the alarm may also include any additional information associated with the alarm, such as identification of the rApp (i.e., the rApp which is transmitting the request to raise the alarm), probable cause of the alarm, severity of the alarm, and the like. The method then proceeds to operation S520.

[0104] At operation S520, the apparatus may be configured to validate the request to raise the alarm. The above validation may be performed based on an alarm registration database.According to example embodiments, the alarm registration database may be comprised in the Non- RT RIC, and may store information associated with alarms that have already been registered in the network.

[0105] According to example embodiments, the apparatus may be configured to validate the request to raise the alarm by determining whether the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database.

[0106] In response to determining that the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database, the apparatus may determine that the validation is successful and the request to raise the alarm should be forwarded to a Service Management and Orchestration (SMO) such that the alarm can be raised in the network, and the method proceeds to operation S530. On the other hand, in response to determining that the alarm identification comprised in the request to raise the alarm is not stored in the alarm registration database, the apparatus may determine that the validation is failed and the rApp should be notified of the failed validation, and the method proceeds to operation S560.

[0107] At operation S530, in response to a successful validation of the request to raise the alarm, the apparatus may be configured to transmit the request to raise the alarm to the SMO. According to example embodiments, the apparatus may be configured to transmit the request to raise the alarm to a fault management (FM) service of the SMO, such that the FM service may accordingly raise the alarm. For example, a notification may be displayed at a dashboard to notify a network operator regarding the alarm. The method then proceeds to operation S540.

[0108] At operation S540, the apparatus may be configured to receive an alarm raise notification from the SMO. The alarm raise notification may indicate a status of the raise of the alarm, such as successful or failed. In particular, for example, in response to receiving the request to raise the alarm from the apparatus, the SMO (or the FM service of the SMO) may accordingly raise the alarm, and in response to a successful raise of the alarm, the SMO (or the FM service of the SMO) may transmit the alarm raise notification to the apparatus, where the alarm raise notification may indicate the status of the raise of the alarm as successful. The method then proceeds to operation S550.

[0109] At operation S550, the apparatus may be configured to transmit the alarm raise notification to the rApp. The alarm raise notification may indicate the status of the raise of the alarm.

[0110] At operation S560, in response to a failed validation of the request to raise the alarm, the apparatus may be configured to transmit a failure notification to the rApp. The failure notification may include an indication that the validation has failed. In particular, the failure notification may indicate that the alarm identification comprised in the request to raise the alarm cannot be found in the alarm registration database.

[0111] FIG. 6 illustrates a flow sequence of an example use case for managing the request to raise the alarm, according to one or more example embodiments. As shown in FIG. 6, the flow sequence may involve an rApp 610, a Non-RT RIC 620, and an SMO 630. The rApp 610, Non- RT RIC 620, and SMO 630 may be similar to the rApp, Non-RT RIC 120, and SMO 110 described above in relation to FIG. 1. Further, one or more operations in FIG. 6 may involve or may be part of one or more operations described above with reference to FIG. 5.

[0112] At step 1, the rApp 610 may transmit the request to raise the alarm to the Non-RT RIC 620, in the similar manner as described above in relation to operation S510 in method 500. According to example embodiments, the request to raise the alarm may be transmitted from the rApp 610 to the Non-RT RIC 620 via the R1 interface to an R1 termination and / or rApp Manager at the Non-RT RIC 620.

[0113] At step 2, the Non-RT RIC 620 may determine whether the alarm identification (ID) comprised in the request to raise the alarm is stored in the alarm registration database, in the similar manner as described above in relation to operation S520 in method 500.

[0114] If the Non-RT RIC 620 determines that the alarm identification is not stored in the alarm registration database (alarm identification cannot be found in the alarm registration database), at step 3, the Non-RT RIC 620 may transmit a failure notification indicating that the alarm identification cannot be found, in the similar manner as described above in relation to operation S560 in method 500. According to example embodiments, the failure notification may be transmitted from the Non-RT RIC 620 to the rApp 610 via the R1 termination and / or rApp Manager at the Non-RT RIC 620 through the R1 interface.

[0115] If the Non-RT RIC 620 determines that the alarm identification is stored in the alarm registration database (alarm identification is found in the alarm registration database), at step 4, the Non-RT RIC 620 may transmit the request to raise the alarm to the SMO 630, in the similar manner as described above in relation to operation S530 in method 500. According to example embodiments, the request to raise the alarm may be transmitted from the Non-RT RIC 620 to theSMO 630 via SMO 630’s application programming interface (API) gateways.

[0116] At step 5, the SMO 630 may transmit an alarm raise notification to the Non-RT RIC 620, in the similar manner as described above in relation to operation S540 in method 500. According to example embodiments, the alarm raise notification may be transmitted from the SMO 630 to the Non-RT RIC 620 via SMO 630’ s application programming interface (API) gateways.

[0117] At step 6, the Non-RT RIC 620 may transmit the alarm raise notification to the rApp 610, in the similar manner as described above in relation to operation S550 in method 500. According to example embodiments, the alarm raise notification may be transmitted from the Non- RT RIC 620 to the rApp 610 via the R1 termination and / or rApp Manager at the Non-RT RIC 620 through the R1 interface.Example Operations for Managing a Request to Clear an Alarm in the Present Disclosure

[0118] In the following, several example operations performable by the apparatus of one or more example embodiments of the present disclosure are described with reference to FIG. 7 to FIG. 8.

[0119] FIG. 7 illustrates a flow diagram of an example method 700 for managing a request to clear an alarm, according to one or more example embodiments. One or more operations of method 500 may be part of operation S210 to S240 in method 200, and may be performed by the apparatus of one or more example embodiments of the present disclosure.

[0120] As illustrated in FIG. 7, at operation S710, the apparatus may be configured to receive a request to clear an alarm. The request to clear the alarm may be received from an rApp, which may be deployed at the Non-RT RIC and may be communicatively coupled to the Non-RTRIC via an R1 interface.

[0121] According to example embodiments, the request to clear the alarm may include an alarm identification associated with the alarm. According to example embodiments, the request to clear the alarm may also include any additional information associated with the alarm, such as identification of the rApp (i.e., the rApp which is transmitting the request to clear the alarm), and the like. The method then proceeds to operation S720.

[0122] At operation S720, the apparatus may be configured to validate the request to clear the alarm. The above validation may be performed based on an alarm registration database. According to example embodiments, the alarm registration database may be comprised in the Non- RT RIC, and may store information associated with alarms that have already been registered in the network.

[0123] According to example embodiments, the apparatus may be configured to validate the request to clear the alarm by determining whether the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database.

[0124] In response to determining that the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database, the apparatus may determine that the validation is successful and the request to clear the alarm should be forwarded to a Service Management and Orchestration (SMO) such that the alarm can be cleared in the network, and the method proceeds to operation S730. On the other hand, in response to determining that the alarm identification comprised in the request to clear the alarm is not stored in the alarm registration database, the apparatus may determine that the validation is failed and the rApp should be notified of the failed validation, and the method proceeds to operation S760.

[0125] At operation S730, in response to a successful validation of the request to clear the alarm, the apparatus may be configured to transmit the request to clear the alarm to the SMO. According to example embodiments, the apparatus may be configured to transmit the request to clear the alarm to a fault management (FM) service of the SMO, such that the FM service may accordingly clear the alarm. The method then proceeds to operation S740.

[0126] At operation S740, the apparatus may be configured to receive an alarm clear notification from the SMO. The alarm clear notification may indicate a status of the clear of the alarm, such as successful or failed. In particular, for example, in response to receiving the request to clear the alarm from the apparatus, the SMO (or the FM service of the SMO) may accordingly clear the alarm, and in response to a successful clear of the alarm, the SMO (or the FM service of the SMO) may transmit the alarm clear notification to the apparatus, where the alarm clear notification may indicate the status of the clear of the alarm as successful. The method then proceeds to operation S750.

[0127] At operation S750, the apparatus may be configured to transmit the alarm clear notification to the rApp. The alarm clear notification may indicate the status of the clear of the alarm.

[0128] At operation S760, in response to a failed validation of the request to clear the alarm, the apparatus may be configured to transmit a failure notification to the rApp. The failure notification may include an indication that the validation has failed. In particular, the failure notification may indicate that the alarm identification comprised in the request to clear the alarm cannot be found in the alarm registration database.

[0129] FIG. 8 illustrates a flow sequence of an example use case for managing the request to clear the alarm, according to one or more example embodiments. As shown in FIG. 8, the flow sequence may involve an rApp 810, a Non-RT RIC 820, and an SMO 830. The rApp 810, Non- RT RIC 820, and SMO 830 may be similar to the rApp, Non-RT RIC 120, and SMO 110 described above in relation to FIG. 1. Further, one or more operations in FIG. 8 may involve or may be part of one or more operations described above with reference to FIG. 7.

[0130] At step 1, the rApp 810 may transmit the request to clear the alarm to the Non-RT RIC 820, in the similar manner as described above in relation to operation S710 in method 700. According to example embodiments, the request to clear the alarm may be transmitted from the rApp 810 to the Non-RT RIC 820 via the R1 interface to an R1 termination and / or rApp Manager at the Non-RT RIC 820.

[0131] At step 2, the Non-RT RIC 820 may determine whether the alarm identification (ID) comprised in the request to clear the alarm is stored in the alarm registration database, in the similar manner as described above in relation to operation S720 in method 700.

[0132] If the Non-RT RIC 820 determines that the alarm identification is not stored in the alarm registration database (alarm identification cannot be found in the alarm registration database), at step 3, the Non-RT RIC 820 may transmit a failure notification indicating that the alarm identification cannot be found, in the similar manner as described above in relation to operation S760 in method 700. According to example embodiments, the failure notification may be transmitted from the Non-RT RIC 820 to the rApp 810 via the R1 termination and / or rAppManager at the Non-RT RIC 820 through the R1 interface.

[0133] If the Non-RT RIC 820 determines that the alarm identification is stored in the alarm registration database (alarm identification is found in the alarm registration database), at step 4, the Non-RT RIC 820 may transmit the request to clear the alarm to the SMO 830, in the similar manner as described above in relation to operation S730 in method 700. According to example embodiments, the request to clear the alarm may be transmitted from the Non-RT RIC 820 to the SMO 830 via SMO 830’s application programming interface (API) gateways.

[0134] At step 5, the SMO 830 may transmit an alarm clear notification to the Non-RT RIC 820, in the similar manner as described above in relation to operation S740 in method 700. According to example embodiments, the alarm clear notification may be transmitted from the SMO 830 to the Non-RT RIC 820 via SMO 830’ s application programming interface (API) gateways.

[0135] At step 6, the Non-RT RIC 820 may transmit the alarm clear notification to the rApp 810, in the similar manner as described above in relation to operation S750 in method 700. According to example embodiments, the alarm clear notification may be transmitted from the Non- RT RIC 820 to the rApp 810 via the R1 termination and / or rApp Manager at the Non-RT RIC 820 through the R1 interface.Various Aspects of Embodiments

[0136] According to example embodiments, an rApp may be allowed to register alarms specific to its operation, as well as be able to any alarms generated by other entities in the network to raise and / or clear such alarms.

[0137] 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 andvariations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0138] Some embodiments may relate to a system, a method, and / or a computer readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer readable medium and executable by at least one processor (and / or may include at least one processor). The computer readable medium may include a computer-readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out operations.

[0139] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves,electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0140] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0141] Computer readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a standalone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a widearea network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0142] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0143] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0144] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a microservice(s) module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0145] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware 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 were described herein without reference to specific software code-it being understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0146] One or more components of the apparatus of the example embodiments (e.g., Non-RT RIC, Near-RT RIC, etc.), as well as the operations associated therewith (e.g., one or more operations in FIG. 2 to FIG. 8, etc.), may be implemented in one or more systems, devices, or hardware components, such as one or more servers, and the like. In the following, descriptions of a device in which the systems or components of the example embodiments may be implemented are provided. It is contemplated that one or more operations or methods described above with reference to FIG. 2 to FIG. 8 may be performed by the device. For instance, the one or more operations or methods may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions (e.g., instructions for implementing the Non-RT RIC, etc.) stored in a memory or a storage component of the device.

[0147] FIG. 9 illustrates an embodiment of a device 700 for implementing one or more example embodiments. As shown in FIG. 9, the device 900 includes a processor 910, a memory 920, a storage component 930, an input component 940, an output component 950, a communication interface 960, and a bus 970.

[0148] The processor 910, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 910 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and one or more single core processors, a distributed processing system, or the like. The processor 910 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.

[0149] Memory 920 includes a non-transitory computer readable medium. Memory 920 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 processor 910. The memory 920 comprises machine-readable instructions which are executable by the processor 910. These machine-readable instructions when executed by the processor 910 causes the processor 910 to perform one or more method steps of an embodiment described herein.

[0150] Storage component 930 stores information and / or software related to the operation and use of the device 900. For example, storage component 930 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 type of non-transitory computer-readable medium, along with a corresponding drive.

[0151] Input component 940 is configured to receive information, such as user input. For example, the input component 940 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, or alternatively, the input component 940 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0152] Output component 950 is configured to provide output information from the device 900. For example, the output component 950 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).

[0153] Communication interface 960 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by thecommunication interface 960 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 900 and other devices. In other words, the standard of the communication interface 960 is not limited.

[0154] The bus 970 acts as an interconnect between the processor 910, the memory 920, the storage component 930, the input component 940, the output component 950, and the communication interface 960 of the device 900. The bus 970 may include a wired interconnection or a wireless interconnection.

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

[0156] Further, according to example embodiments, the device 900 may include one or more elements from the system architecture described above in relation to FIG. 1. For example, the device 900 may include the Non-RT RIC configured to implement at least one Non-RT RIC Application (rApp).

[0157] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: An apparatus that may comprise a non-real-time RAN Intelligent Controller (Non-RT RIC) that may be configured to: receive, from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validate the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmit the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).Item [2]: The apparatus according to item [1], wherein the apparatus may be configured to validate the request to register the alarm based on the alarm registration database by determining whether the alarm is already registered in the alarm registration database.Item [3]: The apparatus according to one of items [l]-[2], wherein the apparatus may be further configured to, in response to a failed validation of the request to register the alarm, transmit a failure notification indicating that the alarm has already been registered along with an alarm identification associated with the alarm to the rApp.Item [4]: The apparatus according to one of items [l]-[3], wherein the request to raise the alarm and the request to clear the alarm may each include an alarm identification associated with the alarm.Item [5]: The apparatus according to one of items [l]-[4], wherein the apparatus may be configured to validate the request to raise the alarm based on the alarm registrationdatabase by determining whether the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database, and wherein the apparatus may be configured to validate the request to clear the alarm based on the alarm registration database by determining whether the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database.Item [6]: The apparatus according to one of items [l]-[5], wherein the apparatus may be further configured to, in response to a failed validation of the request to raise the alarm, transmit a failure notification indicating that the alarm identification comprised in the request to raise the alarm cannot be found to the rApp.Item [7]: The apparatus according to one of items [l]-[6], wherein the apparatus may be further configured to, in response to a failed validation of the request to clear the alarm, transmit a failure notification indicating that the alarm identification comprised in the request to clear the alarm cannot be found to the rApp.Item [8] : A method that may include: receiving, by a non-real-time RAN Intelligent Controller (Non-RT RIC) from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validating, by the Non-RT RIC, the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmitting, by the Non-RT RIC, the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).Item [9]: The method according to item [8], wherein the validating the request to register the alarm based on the alarm registration database may include determining whether the alarm is already registered in the alarm registration database.Item

[0010] : The method according to one of items [8]-[9], wherein the method may further include, in response to a failed validation of the request to register the alarm, transmitting, by the Non-RT RIC, a failure notification indicating that the alarm has already been registered along with an alarm identification associated with the alarm to the rApp.Item

[0011] : The method according to one of items [8]-

[0010] , wherein the request to raise the alarm and the request to clear the alarm may each include an alarm identification associated with the alarm.Item

[0012] : The method according to one of items [8]-[l 1], wherein the validating the request to raise the alarm based on the alarm registration database may include determining whether the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database, and wherein the validating the request to clear the alarm based on the alarm registration database may include determining whether the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database.Item

[0013] : The method according to one of items [8]-

[0012] , wherein the method may further include, in response to a failed validation of the request to raise the alarm, transmitting, by the Non-RT RIC, a failure notification indicating that the alarm identification comprised in the request to raise the alarm cannot be found to the rApp.Item

[0014] : The method according to one of items [8]-

[0013] , wherein the method may further include, in response to a failed validation of the request to clear the alarm, transmitting, by the Non-RT RIC, a failure notification indicating that the alarm identification comprised in the request to clear the alarm cannot be found to the rApp.Item

[0015] : A non-transitory computer-readable recording medium that may have recorded thereon instructions executable by an apparatus that may comprise a non-real- time RAN Intelligent Controller (Non-RT RIC) to cause the Non-RT RIC to perform a method including: receiving, from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validating the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmitting the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).Item

[0016] : The non-transitory computer-readable recording medium according to item

[0015] , wherein the validating the request to register the alarm based on the alarm registration database may include determining whether the alarm is already registered in the alarm registration database.Item

[0017] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0016] , wherein the method may further include, in response to a failed validation of the request to register the alarm, transmitting a failure notification indicatingthat the alarm has already been registered along with an alarm identification associated with the alarm to the rApp.Item

[0018] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0017] , wherein the request to raise the alarm and the request to clear the alarm may each include an alarm identification associated with the alarm.Item

[0019] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0018] , wherein the validating the request to raise the alarm based on the alarm registration database may include determining whether the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database, and wherein the validating the request to clear the alarm based on the alarm registration database may include determining whether the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database.Item

[0020] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0019] , wherein the method may further include, in response to a failed validation of the request to raise the alarm, transmitting a failure notification indicating that the alarm identification comprised in the request to raise the alarm cannot be found to the rApp.

[0158] It is understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. An apparatus comprising: a non-real-time RAN Intelligent Controller (Non-RT RIC) configured to: receive, from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validate the at least one of the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmit the at least one of the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).

2. The apparatus according to claim 1, wherein the apparatus is configured to validate the request to register the alarm based on the alarm registration database by determining whether the alarm is already registered in the alarm registration database.

3. The apparatus according to claim 1, wherein the apparatus is further configured to, in response to a failed validation of the request to register the alarm, transmit a failure notification indicating that the alarm has already been registered along with an alarm identification associated with the alarm to the rApp.

4. The apparatus according to claim 1, wherein the request to raise the alarm and the request to clear the alarm each comprises an alarm identification associated with the alarm.

5. The apparatus according to claim 1, wherein the apparatus is configured to validate the request to raise the alarm based on the alarm registration database by determining whether the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database, and wherein the apparatus is configured to validate the request to clear the alarm based on the alarm registration database by determining whether the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database.

6. The apparatus according to claim 1, wherein the apparatus is further configured to, in response to a failed validation of the request to raise the alarm, transmit a failure notification indicating that the alarm identification comprised in the request to raise the alarm cannot be found to the rApp.

7. The apparatus according to claim 1, wherein the apparatus is further configured to, in response to a failed validation of the request to clear the alarm, transmit a failure notification indicating that the alarm identification comprised in the request to clear the alarm cannot be found to the rApp.

8. A method comprising:receiving, by a non-real-time RAN Intelligent Controller (Non-RT RIC) from an rApp, at least one of: a request to register an alarm, a request to raise the alarm, and a request to clear the alarm; validating, by the Non-RT RIC, the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmitting, by the Non-RT RIC, the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).

9. The method according to claim 8, wherein the validating the request to register the alarm based on the alarm registration database comprises determining whether the alarm is already registered in the alarm registration database.

10. The method according to claim 8, wherein the method further comprises, in response to a failed validation of the request to register the alarm, transmitting, by the Non-RT RIC, a failure notification indicating that the alarm has already been registered along with an alarm identification associated with the alarm to the rApp.

11. The method according to claim 8, wherein the request to raise the alarm and the request to clear the alarm each comprises an alarm identification associated with the alarm.

12. The method according to claim 8, wherein the validating the request to raise the alarm based on the alarm registration database comprises determining whether the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database, and wherein the validating the request to clear the alarm based on the alarm registration database comprises determining whether the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database.

13. The method according to claim 8, wherein the method further comprises, in response to a failed validation of the request to raise the alarm, transmitting, by the Non-RT RIC, a failure notification indicating that the alarm identification comprised in the request to raise the alarm cannot be found to the rApp.

14. The method according to claim 8, wherein the method further comprises, in response to a failed validation of the request to clear the alarm, transmitting, by the Non-RT RIC, a failure notification indicating that the alarm identification comprised in the request to clear the alarm cannot be found to the rApp.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus comprising a non-real-time RAN Intelligent Controller (Non-RT RIC) to cause the Non-RT RIC to perform a method comprising: receiving, from an rApp, at least one of: a request to register an alarm, a request toraise the alarm, and a request to clear the alarm; validating the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm based on an alarm registration database; and in response to a successful validation of the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm, transmitting the at least one of: the request to register the alarm, the request to raise the alarm, and the request to clear the alarm to a Service Management and Orchestration (SMO).

16. The non-transitory computer-readable recording medium according to claim 15, wherein the validating the request to register the alarm based on the alarm registration database comprises determining whether the alarm is already registered in the alarm registration database.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the method further comprises, in response to a failed validation of the request to register the alarm, transmitting a failure notification indicating that the alarm has already been registered along with an alarm identification associated with the alarm to the rApp.

18. The non-transitory computer-readable recording medium according to claim 15, wherein the request to raise the alarm and the request to clear the alarm each comprises an alarm identification associated with the alarm.

19. The non-transitory computer-readable recording medium according to claim 15, wherein the validating the request to raise the alarm based on the alarm registration database comprises determining whether the alarm identification comprised in the request to raise the alarm is stored in the alarm registration database, and wherein the validating the request to clear the alarm based on the alarm registration database comprises determining whether the alarm identification comprised in the request to clear the alarm is stored in the alarm registration database.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the method further comprises, in response to a failed validation of the request to raise the alarm, transmitting a failure notification indicating that the alarm identification comprised in the request to raise the alarm cannot be found to the rApp.

Images