Policy management in a network

Abstract

Provided are apparatus, method, and device for automatically manage policies a network. According to example embodiments, the apparatus may be configured to: obtain policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receive a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; identify the policy type that is supported by the target network function based on the obtained policy type registration information; provide the identified policy type; receive a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request may include the policy; and register the policy and transmit the policy to the target network function.

Description

POLICY MANAGEMENT IN A NETWORKCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 548,662, filed with the U.S. Patent and Trademark Office on February 1, 2024, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to management of policies in a telecommunication network.BACKGROUND

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

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

[0005] Open RAN (O-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, differenttypes 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

[0006] Example embodiments of the present disclosure automatically manage policies. As such, example embodiments of the present disclosure allows for effective and efficient management of all policies implemented anywhere within the network.

[0007] According to example embodiments, an apparatus is provided. The apparatus may be configured to: obtain, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receive, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identify the policy type that is supported by the target network function based on the obtained policy type registration information; provide, to the user, the identified policy type; receive, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request may include the policy; and in response to receiving the policy registration request, register the policy and transmit the policy to the target network function.

[0008] According to example embodiments, a method is provided. The method may include: obtaining, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receiving, from a user, a policy type identification request to identify a policytype that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identifying the policy type that is supported by the target network function based on the obtained policy type registration information; providing, to the user, the identified policy type; receiving, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request may include the policy; and in response to receiving the policy registration request, registering the policy and transmitting the policy to the target network function.

[0009] 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 to cause the apparatus to perform a method including: obtaining, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receiving, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identifying the policy type that is supported by the target network function based on the obtained policy type registration information; providing, to the user, the identified policy type; receiving, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request may include the policy; and in response to receiving the policy registration request, registering the policy and transmitting the policy to the target network function.

[0010] 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

[0011] 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:

[0012] FIG. 1 illustrates an 0-RAN architecture in the related art;

[0013] FIG. 2 illustrates a block diagram of an example system configuration for managing policies in a network, according to one or more example embodiments;

[0014] FIG. 3 illustrates a flow diagram of an example method 300 for managing policies, according to one or more example embodiments;

[0015] FIG. 4 illustrates a flow diagram of an example method for performing additional policy management, according to one or more example embodiments;

[0016] FIG. 5 illustrates a flow diagram of an example method for performing additional policy management, according to one or more example embodiments;

[0017] FIG. 6 illustrates a flow diagram of an example method for performing additional policy management, according to one or more example embodiments;

[0018] FIG. 7 illustrates a flow diagram of an example method for performing additional policy management, according to one or more example embodiments;

[0019] FIG. 8 illustrates a flow diagram of an example method for performing additional policy management, according to one or more example embodiments;

[0020] FIG. 9 illustrates a flow diagram of an example method for performing additional policy management, according to one or more example embodiments;

[0021] FIG. 10 illustrates a flow diagram of an example method for performing additional policy management, according to one or more example embodiments;

[0022] FIG. 11A to FIG. 11G illustrate flow diagrams of example use cases for managing policies, according to one or more example embodiments;

[0023] FIG. 12A illustrates a flow sequence of a policy creation stage within a lifecycle for managing policies, according to one or more embodiments;

[0024] FIG. 12B illustrates a flow sequence of a policy activation stage within a lifecycle for managing policies, according to one or more embodiments;

[0025] FIG. 12C illustrates a flow sequence of a policy update stage within a lifecycle for managing policies, according to one or more embodiments;

[0026] FIG. 12D illustrates a flow sequence of a policy deactivation stage within a lifecycle for managing policies, according to one or more embodiments;

[0027] FIG. 12E illustrates a flow sequence of a policy deletion stage within a lifecycle for managing policies, according to one or more embodiments;

[0028] FIG. 12F illustrates a flow sequence of a policy and policy type identification stage within a lifecycle for managing policies, according to one or more embodiments;

[0029] FIG. 12G illustrates a flow sequence of a policy status identification stage within a lifecycle for managing policies, according to one or more embodiments; and

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

[0031] 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 embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to 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 invention.

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

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

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

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

[0036] 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 EuropeanTelecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (O-RAN) Alliance standard organization, the National Institute of Standards and Technology (NIST) and the like. For instance, the terms “PAP”, “PDP”, “PEP”, “SMO”, “NFO”, “FOCOM”, “rApp”, “xApp”, 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.

[0037] 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 telecommunication system, such as a 4G LTE system, a 6G system, and the like, without departing from the scope of the present disclosure.

[0038] As described above, O-RAN technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. To this end, O-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.

[0039] FIG. 1 illustrates an O-RAN architecture. RAN functions in the 0-RAN architecture may be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability required in the 0-RAN system, as well as to automate and optimize RAN operations. As shown in FIG. 1, the RIC may be divided into two types: a non-real-time RIC (Non- RT RIC) 120 and a near-real-time RIC (Near-RT RIC) 130.

[0040] 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 a Service Management and Orchestration (SMO) framework 110. Its functionalities may be implemented through modular applications called rApps, and may include: providing policy based guidance and enrichment across the Al interface, which is the interface that enables communication between the Non-RT RIC and the Near-RT RIC; performing data analytics; Artificial Intelligence / Machine Learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions over the 01 interface, which may be the interface that connects the SMO to RAN managed elements (e.g., Near-RT RIC 130, O-RAN Centralized Unit (O-CU) 140,150, 0-RAN Distributed Unit (O-DU) 170, etc.).

[0041] The Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-DU 170, the O-CU (disaggregated into the O-CU control plane (O-CU-CP) 140 and the O-CU user plane (O-CU-UP) 150), and an open evolved NodeB (O- eNB) 160 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.The Near-RT RIC 130 may monitor, suspend / stop, override, and control the E2 nodes (O-CU140,150, O-DU 170, and O-eNB 160) via policies. For example, the Near-RT RIC 130 may set policy parameters on activated functions of the E2 nodes. Further, the Near-RT RIC 130 may host xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc.

[0042] Here, the O-CU-CP 140 and the O-CU-UP 150 may be coupled to each other via the El interface, and may be coupled to the 0-DU 170 via the Fl-c interface and Fl-u interface, respectively. Further, the 0-RU 180 may be coupled to the O-DU 170 via the Open Fronhaul (OF) Control (C), User (U), Synchronization (S), and Management (M) Planes, and may be coupled to the SMO 110 via the OF M-Plane.

[0043] The two types of RICs work together to optimize the O-RAN. For example, the Non-RT RIC 120 may provide the policies, data, and AI / ML models enforced and used by the Near-RT RIC 130 for RAN optimization, and the Near-RT RIC 130 may return policy feedback (i.e., how the policy set by the Non-RT RIC 120 works).

[0044] The Non-RT RIC 120 may be located within the SMO framework 110, which manages and orchestrates RAN elements. Specifically, the SMO 110 may manage and orchestrate what is referred to as the O-Ran Cloud (O-Cloud) 190. The O-Cloud 190 may be a collection of physical RAN nodes that host the RICs, O-CUs, and O-DUs, the supporting software components (e.g., the operating systems and runtime environments), and the SMO 110 itself. In other words, the SMO 110 may manage the O-Cloud 190 from within. The 02 interface may be the interface between the SMO 110 and the O-Cloud 190 it resides in. Through the 02 interface, the SMO 110 may provide infrastructure management services (IMS) and deployment management services (DMS).

[0045] As described above in relation to FIG. 1, the RAN may be disaggregated into multiple nodes or entities. Specifically, in the 0-RAN architecture, the RAN functions may be disaggregated into multiple logical nodes or entities, such as a central 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. A single DU may host or serve multiple network cells formed by multiple RUs. 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. In this regard, a network cell may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. To this end, since the disaggregated entities have open protocols and interfaces between them, they can be developed by different vendors.

[0046] In this regard, management of network policies is an important aspect of 0-RAN. A policy may refer to a set of rules, guidelines, conditions, and the like that govern the behavior and actions of 0-RAN resources and services. A number of policies may be used to automate various aspects of network resources and services, as well as to ensure that the network services and their resources operate in accordance with predefined rules and objectives. For example, the SMO may manage 0-RAN resources such as O-Cloud, 0-RAN nodes, and the like through the policies, in order to ensure that such resources are allocated and managed consistently and efficiently.

[0047] In the related art, the management of policies implemented via the Al interface between the Non-RT RIC and the Near-RT RIC (Al policies) has been introduced in the Al policy management network function in the SMO. However, there are no specific mechanism or architecture that allows for management of other kinds of policies implemented in the network outside of the Al interface, including creation, search, modification, enforcement, and the like of such policies. In this regard, since entities from different vendors may be involved in the 0-RAN architecture and may interact with various kinds of policies at various locations in the network, it is crucial to define and specify the management for all kinds of policies implemented in the network, such that entities from different vendors can understand the policies and operate accordingly in an effective and efficient manner.

[0048] Accordingly, apparatus, system, methods, devices, and the like, provided in the example embodiments of the present disclosure automatically manage policies.

[0049] According to example embodiments, a plurality of network functions in a network may first provide policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions to the apparatus. Then, a user may provide a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions, where the apparatus may accordingly identify the policy type that is supported by the target network function based on the obtained policy type registration information and provide the same to the user. Subsequently, the user may provide a policy registration request to register a policy to be implemented via the target network function, where the apparatus may accordingly register the policy and transmit the policy to the target network function.

[0050] Ultimately, example embodiments of the present disclosure automatically manage policies, which allows for effective and efficient management of all policies implemented anywhere within the network.

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

[0052] 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

[0053] FIG. 2 illustrates a block diagram of an example system configuration 200 for managing policies in a network, according to one or more example embodiments. As illustrated in FIG. 2, system configuration 200 may include a user 210, a policy administration point (PAP) 220, a policy decision point (PDP) 230, and a policy enforcement point (PEP) 240.

[0054] The user 210 may include an entity in a network which communicates with the PAP 220, PDP 230, and PEP 240 in order to manage policies being implemented in the network. For example, the user 210 may include a network element in the 0-RAN architecture, such as an rApp or any internal network management applications. The user 210 may also include an entity external to the 0-RAN architecture. For example, the user 210 may include a third party system which is communicating with the PAP 220, PDP 230, and PEP 240 in the SMO via the data management and exposure (DME) and service management and exposure (SME) in the SMO.

[0055] The PAP 220 may include a network element in the network which is configured to manage policies being implemented in the network. For example, the PAP 220 may include an SMO, O-CU, O-DU, O-RU, and the like. According to example embodiments, the PAP 220 may include a network function in the network, such as a policy management and information (PMI) deployed in the SMO. The PAP 220 may be configured to communicate with the user 210 in order to provide information related to policies being implemented in the network and policy types supported in the network, as well as to receive instructions / requests related to the management of the policies and the policy types. Further, the PAP 220 may be configured to communicate with the PDP 230 and PEP 240 in order to manage and implement the policies and the policy types in accordance with the instructions / requests from the user 210.

[0056] The PAP 220 may utilize any kind of suitable interface to communicate with the user 210, the PDP 230, and PEP 240. For example, the PAP 220 may utilize a Pl interface along with an application programming interface (API) to communicate with the user 210, and may utilize a P2 interface along with an API to communicate with the PDP 230 and PEP 240. The interface utilized by the PAP 220 (e.g., PMI interface) may be an open logical interface within the O-RAN architecture independent of specific implementations of the functions within the SMO, and may be defined in an extensible way that enables new services and data types to be added without needing to change the protocol stack or the procedures. In this regard, the policies transmitted over the interface may be expressed using a standardized mechanism (e.g., language, syntax, and the like). The interface may also enable a multi-vendor environment, as well as enable a policy-based guidance (e.g., event, condition, actions) of resource management internal functions / applications that are part of SMO functions, O-Cloud, O-RAN nodes, and the like.Further, the interface may be able to provide basic feedback mechanism from the PDP 230 and / or the PEP 240 that enables the user 210 to monitor the status and use of policies.

[0057] Additionally, the PAP 220 may utilize any means to communicate with the user 210. For example, the PAP 220 may communicate with input and output devices, user interfaces, and the like, such that the PAP 220 and the user 210 may communicate via such elements.

[0058] Example operations performable by the PAP 220 for managing policies are described below with reference to FIG. 3 to FIG. 10.

[0059] The PDP 230 may include a network element deployed in the network which is configured to determine actions that should be performed in accordance with the policies. According to example embodiments, the PDP 230 may include a network function in the network, such as a network function orchestrator (NFO), federated O-Cloud orchestration and management (FOCOM), RAN operation, administration, and maintenance (0AM), Al policy management, service orchestration (SO), service assurance (SA), and the like deployed in the SMO.

[0060] It is understood that a policy may have a specific network function / network element that should implement and act as a PDP for such policy. In this regard, for example, the PAP 220 may review a policy, identify which network function would act as the PDP 230 for such policy (i.e., based on the scope and actors defined in the policy), and transmit the policy to the identified network function. The PDP 230 may then be configured to evaluate the policy received from the PAP 220, determine actions that should be performed in accordance with the policy, and communicate with the PEP 240 in order to enforce the determined action.

[0061] The PEP 240 may include a network element deployed in the network which is configured to enforce the determined actions in accordance with a request from the PDP 230. Forexample, the PEP 240 may include an O-Cloud, an O-RAN radio node, the Near-RT RIC, and the like. According to example embodiments, the PEP 240 may include a network function in the network.

[0062] It is understood that an action determined by the PDP 230 may have a specific network function / network element that should enforce and act as a PEP for such action. For example, an NFO (PDP 230) may determine, in accordance with a policy, an action to reduce energy consumption of O-Cloud resources. In this regard, the O-Cloud would act as the PEP for such action, and the NFO may communicate with the O-Cloud (PEP 240) to request reduction in energy consumption. The O-Cloud would then accordingly reduce the energy consumption (enforce the action).

[0063] According to example embodiments, the functionalities of the PDP 230 and PEP 240 may be distributed across different network functions / network elements, and the PDP 230 and PEP 240 may be physically and / or logically separated from each other. Alternatively, the PDP 230 and PEP 240 may be centralized in a single network function / network element. For example, the network function orchestrator (NFO) deployed in the SMO may act as both the PDP 230 and PEP 240 for certain policies.

[0064] According to example embodiments, the PAP 220 may also define a policy (e.g., define policy rules, objectives, conditions, actions, scope, and the like) based on information received from the user 210; trigger the activation and deactivation of the policy (i.e., transitioning the policy from a stored / inactive state to an active state where the policy can influence network behavior, and vice versa); delete the policy from the memory; update the policy (i.e., modifying policy rules, objectives, conditions, actions, scope, and the like) based on information receivedfrom the user 210, the status / requirements of the network, and the like; record activities related to the policy (e.g., log activation and deactivation of the policy for auditing purposes); transmit a notification to the user 210, the PDP 230, and / or the PEP 240 regarding the status and the state of the policy (e.g., notify that the policy is now active and ready for enforcement, that the policy has been updated, and the like); retrieve and provide a list of policies and / or policy types available within the system in response to queries from the user 210 as well as any additional related information; and retrieve and provide statuses of the policy in response to queries from the user 210.

[0065] According to example embodiments, the PDP 230 may also validate the policy during its creation to avoid conflicts between the policy and other existing policies in the network and between the policy and various network conditions, as well as suggest modifications to the policy to avoid the conflicts and / or optimize the policy’s effectiveness; evaluate the policy’s conditions in real-time and decide how the policy should be applied; ensure that the policy’s rules are followed according to the current network state; adjust the policy’s application based on dynamic network conditions in order to ensure that the policy’s objectives are met without disrupting other operations in the network; review the updated policy, re-evaluate how it should be applied in order to ensure that the updated policy remains consistent with other active policies in the network, and adjust its decision-making logic to accommodate the changes in the updated policy; detect deactivation of the policy and stop making decisions based on the deactivated policy; ensure that the deactivation of the policy does not disrupt ongoing network operations, by, for example, reverting to other active policies or default behaviors; acknowledge the deletion of the policy and ensure that it no longer considers the deleted policy in any of its decision-makingprocesses; update its logic or records to reflect the deletion of the policy; and provide decisionmaking logic associated with the policy type and / or the policy (e.g., how policies are applied in real-time, decision criteria, conditions, logs of policy decisions, actions triggered by the policy, and the like) in response to a request from the PAP 220.

[0066] According to example embodiments, the PEP 240 may also manage network resources, manage traffic, allocate resources, and performs other actions according to the policy and determinations made by the PDP 230; adjust enforcement action and modify its behavior in real-time according to the updated policy; stop enforcement of the deactivated policy and revert network elements / network functions to their previous states in response to deactivation of the policy, while ensuring smoot transition back to operations before the activation of the policy; remove any configurations or actions associated with the deleted policy, while ensuring that network elements / network functions are no longer influenced by the deleted policy; and provide enforcement actions (e.g., enforcement logs that show how the policy type and / or the policy was applied in the network, including details on resource allocation, traffic management, enforcement status, and any specific actions executed based on the policy type and / or the policy).

[0067] Here, a policy may refer to a set of rules, guidelines, conditions, and the like that govern the behavior and actions of 0-RAN resources and services. The policy may also be used to manage and control the changing and / or maintaining of the state of one or more managed objects, as well as to specify actual instances of policies that are used in a service. A number of policies may be used to automate various aspects of network resources and services, as well as to ensure that the network services and their resources operate in accordance with predefined rules and objectives. For example, the SMO may manage 0-RAN resources such as O-Cloud, 0-RAN nodes,and the like through the policies, in order to ensure that such resources are allocated and managed consistently and efficiently.

[0068] According to example embodiments, the policy may include a policy defined in a topology and orchestration specification for cloud application (TOSCA) topology template as an artifact that defines a policy that can be associated with a TOSCA topology or top-level entity definition.

[0069] According to example embodiments, the policy may be in one of a plurality of states.The plurality of states may include at least one of draft, inactive, active, suspended, deactivated, deleted, and updated, although it is understood that the plurality of states may also include additional states without limitations.

[0070] The draft state may include a state where the policy is in the process of being created or modified but has not yet been activated (i.e., under construction or review). For example, a policy may be defined by a user (e.g., network operator) but is not yet activated. A policy in the draft state may be modified and / or deleted.

[0071] The inactive state may include a state where the policy exists in the system (i.e., stored in the policy database) but is not currently active or being enforced. For example, a policy designed for traffic prioritization may be defined and stored but not enforced until needed. A policy in the inactive state may have been previously deactivated or have never been activated, and said policy may be activated, updated, and / or deleted.

[0072] The active state may include a state where the policy is currently in effect and is being enforced by the PEP. For example, a bandwidth allocation policy may be active during peak hours, dynamically adjusting resources based on network conditions. A policy in the active statemay have its conditions monitored and its actions executed based on the policy rules, and may be updated, suspended, and / or deactivated.

[0073] The suspended state may include a state where the policy is temporarily stopped. For example, a policy is suspended because it conflicts with another active policy, and further evaluation is needed before reactivation. A policy in the suspended state may not have its actions taken until a certain condition is met or a certain amount of time has passed. Further, a policy in the suspended state may be reactivated and / or deactivated.

[0074] The deactivated state may include a state where the policy is stopped, and is longer active or being enforced. For example, a network policy for a particular event is no longer needed and is deactivated. A policy in the deactivated state may not have its actions taken unless an instruction to reactivate it is received. Further, a policy in the suspended state may be reactivated and / or deleted.

[0075] The updated state may include a state where the policy is modified and updated. The update state may be similar to the active state.

[0076] The deleted state may include a state where the policy is permanently removed from the system (e.g., removed from the policy database). For example, a legacy policy no longer applicable to the current network environment is deleted to free up system resources. A policy in the deleted state can no longer be enforced or reactivated, and no actions can be taken for the policy.

[0077] According to example embodiments, the policy may transition from one state to any other state in the plurality of states. For example, a policy may transition from the draft state to the inactive state when the policy is created and stored in the system, but is not yet activated)since the policy is not needed immediately. In another example, a policy may transition from the inactive state to the active state when the policy is activated (i.e., by the user via the PAP or automatically based on certain conditions, such as during peak hours). In another example, a policy may transition from the active state to the suspended state when the policy is suspended either due to conflict with another policy (e.g., make way for an emergency resource allocation policy) or an administrative decision. In another example, a policy may transition from the suspended state to the active state when the policy is reactivated after being temporarily suspended and the conflict is resolved. In another example, a policy may transition from the active state to the deactivated state when the policy is no longer needed and is deactivated (e.g., peak hours have ended, and the traffic prioritization policy is no longer needed). In another example, a policy may transition from the suspended state to the deactivated state when the policy that was previously suspended is no longer needed. In another example, a policy may transition from the deactivated state to the active state when the policy is needed again (e.g., peak hours have started, and the traffic prioritization policy is now needed). In another example, a policy may transition from the inactive state to the deleted state when the policy is deleted from the system to permanently remove all configurations. In another example, a policy may transition from the active state to the updated state when the policy is updated while active, where its rules and conditions modified while the policy is continuously being enforced (e.g., a user adjusts the bandwidth allocation rules within an active traffic prioritization policy to better handle peak traffic conditions).

[0078] The purpose of the policies is to ensure that consistent decisions are made to govern the behavior of a system. The policies may be expressed in a structured format that defines thescope, objectives, and conditional statements or constraints. Further, a policy may be defined using a policy type.

[0079] The policy type may describe a type of policy, and may define various characteristics, such as properties, targets, triggers, and the like of a particular type of policy. For example, the policy type may describe the properties (configuration parameters) that a particular type of policy can take, as well as define default values, optionality, and ranges of the properties. The policy type may also describe targets which a particular type of policy can act on, such as network element types, functions, services, resources, and the like. The policy type may also describe triggers which a particular type of policy can activate, such as event types, filtered events, scheduled triggers, conditions, and the like. Further, the policy type may describe configuration data that a particular type of policy can take.

[0080] According to example embodiments, a policy type may act as a template with predefined default properties, targets, triggers, and the like for a particular type of policy, where a policy may be created from the policy type by modifying the policy type (e.g., changing the predefined default values of a property into a specific value). Some examples of policy types may include resource management policy type, life cycle management (LCM) policy type (e.g., healing, scaling, and the like), monitoring policy type, and the like.

[0081] In this regard, different network functions in the network may support different policy types. For example, the NFO may support policy types related to deployment of network functions, network function healing, network function autoscaling, network function termination, and the like; the FOCOM may support policy types related to O-Cloud infrastructures, network function healing, network function termination, energy saving node shutdown, CPU powermanagement, and the like; the RAN OAM may support policy types related to load and traffic distribution; and Al policy management may support policy types related to energy saving and RF channel reconfigurations.

[0082] According to example embodiments, the policy type may include imperative policies, declarative policies, and intent policies.

[0083] The imperative policies may refer to policies that are structured such that they explicitly control the transitioning of one state to another state. According to example embodiments, the imperative policies may include event-condition-action (ECA) policy, which defines event, condition, and action in a policy. The event may include any important occurrence in the system being managed, and / or in the environment of the system being managed, such as time and user actions, which would activate (trigger) the policy. Examples of events may include deployment fault occurrence, node fault occurrence, request for auto scaling, and deployment relocation. The condition may be defined as a set of attributes, features, values, and the like that are to be compared with a corresponding set of known attributes, features, values, and the like to determine whether the set of actions in that (imperative) policy can be executed or not. Examples of conditions may include CPU<2%, memory <2%, and CPU > 80%. The action may be used to control and monitor the behavior of the system or component that a policy is applied to when the event and condition are satisfied. Examples of action may include a node shutdown (e.g., if CPU<2% and memory <2%), and an auto scaling (e.g., if CPU > 80%).

[0084] The declarative policies may refer to policies that are structured such that only desired outcomes are described without describing how to achieve such desired outcomes. The declarative policies allow for flexibility and adaptability in the management of the policy as thesystem can choose the most efficient way to achieve the desired outcomes based on its capabilities and context. The declarative policies may include descriptions, such as, for example, distribute network traffic across available virtual network functions (CNF / VNFs) to maintain a maximum load of 80% on each CNF / VNF, ensure 50 Mbps bandwidth and 10ms latency for the silver service slice for all users in region A, and prioritize traffic from emergency services within the public safety slice and ensure at least 99.999% availability.

[0085] The intent policies may refer to policies that are structured as a high level statements expressing the goals of the policy, without describing how to achieve such goals. Each statement in the intent policies may require translation / conversion of terms into a form which a managed functional entity can understand. Examples of statements in the intent policies may include “network performance for video streaming during peak hours” and “allocate 20% of available radio resources to high-value customers during peak hours”.

[0086] Here, the triggers described in the policy type may define an event, a condition, an action, and the like that is used to initiate execution of a policy associated with it. The definition of the triggers allows the type of events which a policy is to trigger based on to be specified, along with the filters, conditions and constraints, action to perform, and various other parameters associated with the events.

[0087] According to example embodiments, the trigger may include a trigger defined as modules in the TOSCA service template. In particular, the TOSCA defines the trigger as an artifact that defines the event, condition and action that is used to “trigger” a policy it is associated with. The definition of the triggers defined in the TOSCA may include at least one of: an event type defining a name of an event that fires the trigger (activates the policy), a schedule defining a timeinterval which the trigger is active, a target filter defining specific filters for firing specific characteristics of the nodes or relations for which the trigger should or should not fire, a condition defining extra conditions on the incoming event for firing the policy, a constraint defining extra condition on the incoming event for not firing the policy, a period defining a period used for evaluating conditions and constraints, an evaluation defining a number of evaluations that must be performed over the period to assert the conditions or constraints, a method defining a method used for evaluation of conditions and constraints, and an action defining a workflow or operations to invoke when the trigger fires.

[0088] According to example embodiments, the P2 interface utilized by the PAP 220 to communicate with the PDP 230 and PEP 240 may provide at least one of a plurality of P2 operations to the user 210 (i.e., via the PAP 220). The plurality of P2 operations may include at least one of policy type registration, policy type deregistration, policy type discover / query, policy creation, policy deletion, policy query, policy activation, policy deactivation, subscription, subscription information query, subscription termination, and notification, although it is understood that the plurality of P2 operations may also include additional operations without limitations.

[0089] The policy type registration operation may allow the user 210 and / or network functions / network elements to register its supported policy type. The policy types may be registered via the P2 interface in formats, such as Topology and Orchestration Specification for Cloud Applications (TOSCA), JavaScript Object Notation (JSON), Extensible Markup Language(XML), and the like.

[0090] The policy type deregistration operation may allow the user 210 to deregister a policy type that it has previously registered for which it is no longer supported.

[0091] The policy type discover / query operation may allow the user 210 to deregister to retrieve information on the registered policy types. The discovery of a policy type may not imply availability of policy instances of that policy type, and may simply indicate that the user 210 can request or subscribe to a policy type.

[0092] The policy creation operation may allow the user 210 to create a policy. The user 210 may use policy types to create policies. Policy type identifications may be communicated in policy creations.

[0093] The policy deletion operation may allow the user 210 to delete a policy.

[0094] The policy query operation may allow the user 210 to read and query a policy(single, multiple, or all policies).

[0095] The policy activation operation may allow the user 210 to activate a policy (single, multiple, or all policies).

[0096] The policy deactivation operation may allow the user 210 to deactivate a policy (single, multiple, or all policies).

[0097] The subscription operation may allow the user 210 to subscribe for notifications of events such as policy changes related to policies and policy types.

[0098] The subscription information query operation may allow the user 210 to query information related to subscription for notifications of events such as policy changes related to policies and policy types.

[0099] The subscription termination operation may allow the user 210 to terminate subscription for notifications of events such as policy changes related to policies and policy types.

[0100] The notification operation may allow the user 210 to receive updates about changes of the status of a policy and policy types.Example Operations for Managing Policies in the Present Disclosure

[0101] 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. 3 to FIG. 10.

[0102] FIG. 3 illustrates a flow diagram of an example method 300 for managing policies, according to one or more example embodiments. One or more operations in method 300 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0103] As illustrated in FIG. 3, at operation S310, the apparatus may be configured to obtain policy type registration information. The policy type registration information may be obtained from a plurality of network functions in a network, and may specify at least one policy type that is supported by a respective one of the plurality of network functions.

[0104] According to example embodiments, the apparatus may be configured to store the obtained policy type registration information in a memory, such that the apparatus maintains a policy type database specifying information related to which policy type is supported by each of the plurality of network functions. The method then proceeds to operation S320.

[0105] At operation S320, the apparatus may be configured to receive a policy type identification request. The policy type identification may be received from a user, and may include a request to identify a policy type that is supported by a target network function in the plurality of network functions.

[0106] In particular, for example, the user may be planning to create a policy to be implemented via the target network function. In this regard, the user may wish to identify a policy type that is supported by the target network function, such that the policy may be appropriately created for the target network function based on the policy type that is supported by the target network function. Accordingly, the user may provide a policy type identification request to identify the policy type that is supported by the target network function.

[0107] According to example embodiments, the target network function may act as a PDP.According to example embodiments, the identification of a policy type may include at least one of: a discovery of a policy type and a query of a policy type. The method then proceeds to operation S330.

[0108] At operation S330, in response to receiving the policy type identification request, the apparatus may be configured to identify the policy type that is supported by the target network function. The policy type that is supported by the target network function may be identified based on the obtained policy type registration information (i.e., policy type registration information stored in the policy type database). The method then proceeds to operation S340.

[0109] At operation S340, the apparatus may be configured to provide the identified policy type to the user. According to example embodiments, the apparatus may provide additional information related to the identified policy type to the user, such as decision-making logic,enforcement actions and the like, where the apparatus may query the PDP and / or PEP to obtain the above information. The method then proceeds to operation S350.

[0110] At operation S35O, the apparatus may be configured to receive a policy registration request. The policy registration request may be received from the user, and may include a request to register a policy to be implemented via the target network function. The policy registration request may also include the policy associated with the policy registration request.

[0111] According to example embodiments, the policy may include a policy to be implemented anywhere within the network. For example, the policy may be implemented via an 01 interface, an 02 interface, an M-Plane, and the like. In another example, the policy may be implemented via an Al interface. The method then proceeds to operation S360.

[0112] At operation S360, in response to receiving the policy registration request, the apparatus may be configured to register the policy and transmit the policy to the target network function. According to example embodiments, the apparatus may be configured to register the policy by storing information related to the policy, such as the target network function associated with the policy, the user associated with the policy, and the like. The information related to the policy may be stored in a memory, such that the apparatus maintains a policy database specifying information related to the policies that have been registered with the PAP in the network.

[0113] According to example embodiments, once the policy is transmitted to the target network function (PDP), the target network function may accordingly evaluate the policy, determine actions that should be performed in accordance with the policy, and communicate with a PEP in order to enforce the determined action.

[0114] According to example embodiments, the policy may be transmitted to the target network function at the same time as the registration of the policy. According to example embodiments, the policy may be transmitted to the target network function after the registration of the policy and in response to a trigger event. The trigger event may include, for example, receiving a request to activate the policy from the user.

[0115] According to example embodiments, the apparatus may be configured to further perform additional policy management in accordance with additional requests from the user. Examples of operations for performing additional policy management are described below with reference to FIG. 4 to FIG. 10.

[0116] FIG. 4 illustrates a flow diagram of an example method 400 for performing additional policy management, according to one or more example embodiments. One or more operations in method 400 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0117] As illustrated in FIG. 4, at operation S410, the apparatus may be configured to receive a policy type update request. The policy type update request may be received from at least one network function in the plurality of network functions, and may include a request to update a stored policy type registration information of the at least one network function.

[0118] The policy type update request may also include policy type update information specifying at least one of: a policy type newly supported by the at least one network function and a policy type that is no longer supported by the at least one network function. The method then proceeds to operation S420.

[0119] At operation S420, in response to receiving the policy type update request, the apparatus may be configured to update the stored policy type registration information of the at least one network function based on the policy type update information.

[0120] In particular, for example, the plurality of network functions may include a first network function that supports a first policy type, a second network function that supports a second policy type, and a third network function that supports the second policy type and a third policy type. The first, second, and third network functions may each transmit policy type registration information to report which policy type they support during operation S310, where such policy type registration information is stored. Then, at a later time, the first network function may be modified such that the first network function now supports both the first policy type and the second policy type. Accordingly, the first network function may transmit a policy type update request to update the stored policy type registration information of the first network function, along with a policy type update information specifying the second policy type as a policy type newly supported by the first network function during operation S410. Similarly, the third network function may be modified such that the third network function now supports only the second policy type. Accordingly, the third network function may transmit a policy type update request to update the stored policy type registration information of the third network function, along with a policy type update information specifying the third policy type as a policy type that is no longer supported by the third network function during operation S410.

[0121] Accordingly, the apparatus may be configured to update the stored policy type registration information of the first and third network functions in the policy type database based on the policy type update information, such that the stored policy type registration informationindicates that the first network function supports both the first policy type and the second policy type, and that the third network function supports only the second policy type.

[0122] According to example embodiments, the policy type identification request received during operation S320 in method 300 may be received after the stored policy type registration information has been updated during operation S420. In this regard, the policy type identified during operation S330 in method 300 may be identified based on the updated policy type registration information.

[0123] According to example embodiments, the apparatus may provide additional information related to the update to the user. For example, the apparatus may provide an update notification to the user, indicating that the policy type has been updated or the policy type has not been updated (i.e., the update has failed).

[0124] FIG. 5 illustrates a flow diagram of an example method 500 for performing additional policy management, according to one or more example embodiments. One or more operations in method 500 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0125] As illustrated in FIG. 5, at operation S510, the apparatus may be configured to receive a policy identification request. The policy identification request may be received from the user, and may include a request to identify a policy that is being implemented via at least one network function in the plurality of network functions.

[0126] According to example embodiments, the identification of a policy may include at least one of: a discovery of a policy and a query of a policy. The method then proceeds to operationS520.

[0127] At operation S520, in response to receiving the policy identification request, the apparatus may be configured to identify the policy that is being implemented via the at least one network function.

[0128] According to example embodiments, the policy that is being implemented via the at least one network function may be identified based on the policy database.

[0129] In particular, for example, the plurality of network functions may include a first network function and a second network function. The first network function may be implementing a first policy, and the second network function may be implementing a second policy and a third policy. In this regard, the user may provide a policy identification request to identify a policy that is being implemented by the second network function during operation S510. Accordingly, the apparatus may identify the second policy and the third policy as the policies that are being implemented by the second network function during operation S520.

[0130] Accordingly, the apparatus may provide the identified policy that is being implemented via the at least one network function to the user. According to example embodiments, the apparatus may provide additional information related to the identified policy to the user, such as implementation dates, an identification of a user who created the policy, decision-making logic, enforcement actions and the like, where the apparatus may further query the PDP and / or PEP to obtain the above information.

[0131] FIG. 6 illustrates a flow diagram of an example method 600 for performing additional policy management, according to one or more example embodiments. One or more operations in method 600 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0132] As illustrated in FIG. 6, at operation S610, the apparatus may be configured to receive a policy update request. The policy update request may be received from the user, and may include a request to update a policy that is being implemented via at least one network function in the plurality of network functions. The policy update request may also include update information associated with the update indicated in the policy update request. The method then proceeds to operation S620.

[0133] At operation S620, in response to receiving the policy update request, the apparatus may be configured to update the policy that is being implemented via the at least one network function based on the received update information.

[0134] In particular, for example, the plurality of network functions may include a first network function and a second network function. The first network function may be implementing a first policy, and the second network function may be implementing a second policy. In this regard, the user may provide a policy update request to update the first policy that is being implemented by the first network function during operation S610. Accordingly, the apparatus may update the first policy in accordance with the policy update request during operation S620.

[0135] According to example embodiments, the apparatus may provide additional information related to the update to the user. For example, the apparatus may provide an updatenotification to the user, indicating that the policy has been updated or the policy has not been updated (i.e., the update has failed).

[0136] According to example embodiments, once the policy has been updated, the apparatus may also update any relevant information related to the policy in the policy database.

[0137] FIG. 7 illustrates a flow diagram of an example method 700 for performing additional policy management, according to one or more example embodiments. One or more operations in method 700 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0138] As illustrated in FIG. 7, at operation S710, the apparatus may be configured to receive a policy deregistration request. The policy deregistration request may be received from the user, and may include a request to deregister a policy that is being implemented via at least one network function in the plurality of network functions. The method then proceeds to operation S720.

[0139] At operation S720, in response to receiving the policy deregistration request, the apparatus may be configured to deregister the policy that is being implemented via the at least one network function.

[0140] According to example embodiments, the apparatus may be configured to deregister the policy by updating the policy database to indicate deregistration (e.g., deletion) of the policy, and transmitting a deregistration notice to the at least one network function. It is understood that the at least one network function may include a network function acting as a PDP, and is implementing the policy.

[0141] In particular, for example, a first policy may be registered and transmitted to a first network function during operation S360 in method 300. Then, at a later time, the user may wish to no longer implement the first policy and deregister the first policy. In this regard, the user may provide a policy deregistration request to deregister the first policy that is being implemented by the first network function during operation S710. Accordingly, the apparatus may deregister the first policy during operation S720. Specifically, the apparatus may update the policy database to indicate that the first policy has been deregistered, and may transmit a deregistration notice to the first network function to indicate that the first policy has been deregistered. Accordingly, the first network function (PDP) may communicate with a corresponding PEP and stop implementation of the first policy.

[0142] According to example embodiments, the apparatus may provide additional information related to the deregistration to the user. For example, the apparatus may provide a deregistration notification to the user, indicating that the policy has been deregistered or the policy has not been deregistered.

[0143] According to example embodiments, once a policy is registered, said policy may be implemented and enforced (by the PDP and PEP) until the policy deregistration request for the policy is received from the user. According to example embodiments, the apparatus may be configured to determine when to stop implementation and enforcement of a policy and deregister such policy. Such determination may be based on context information, such as observability from O-Cloud indicating fulfillment of the policy’s objective received over 02 interface.

[0144] According to example embodiments, the apparatus may also delete the policy. The policy may be deleted by removing the policy from the memory (policy database) entirely. Theapparatus may also perform a check to ensure that the policy is fully removed from the memory and that there are no remnants of the policy remain in the memory.

[0145] FIG. 8 illustrates a flow diagram of an example method 800 for performing additional policy management, according to one or more example embodiments. One or more operations in method 800 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0146] As illustrated in FIG. 8, at operation S810, the apparatus may be configured to receive a policy status request. The policy status request may be received from the user, and may include a request to identify a status of a policy that is being implemented via at least one network function in the plurality of network functions. The method then proceeds to operation S820.

[0147] At operation S820, in response to receiving the policy status request, the apparatus may be configured to identify the status of the policy that is being implemented via the at least one network function.

[0148] According to example embodiments, the apparatus may be configured to identify the status of the policy by transmitting a status request to the at least one network function (i.e., a network function acting as a PDP and implementing the policy). The at least one network function may then obtain information related to the status of the policy (e.g., extracting relevant information from an associated PEP), and provide said information to the apparatus. The status may include, for example, enforced, not enforced, updated, running, and the like. The status may also include the state of the policy (i.e., draft, inactive, active, suspended, deactivated, deleted, and the like).

[0149] In particular, for example, a first network function may be implementing a first policy. Then, at a later time, the user may provide a policy status request to identify a status of the first policy that is being implemented by the first network function during operation S810. Accordingly, the apparatus may identify the status of the first policy during operation S820. Specifically, the apparatus may transmit a status request to the first network function, and receive information related to the status of the first policy from the first network function.

[0150] Accordingly, the apparatus may provide the information related to the status of the policy to the user.

[0151] According to example embodiments, the apparatus may be configured to continuously or periodically identify the status of all policies implemented in the network, such that the apparatus may continuously or periodically monitor the status of all policies implemented in the network.

[0152] FIG. 9 illustrates a flow diagram of an example method 900 for performing additional policy management, according to one or more example embodiments. One or more operations in method 900 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0153] As illustrated in FIG. 9, at operation S910, the apparatus may be configured to receive a notification request. The notification request may be received from the user, and may include a request to receive a notification regarding a change related to a policy type and a policy associated with at least one network function in the plurality of network functions. The method then proceeds to operation S920.

[0154] At operation S920, the apparatus may be configured to detect the change related to the policy type or the policy associated with the at least one network function.

[0155] For example, the user may provide a notification request to receive a notification regarding a change related to a policy type and a policy associated with a first network function. In this regard, the apparatus may detect that the first policy that is being implemented by the first network function has been updated during operation S620 in method 600, that the first policy has been deregistered during operation S720 in method 700, and / or that the first network function now supports both the first policy type and the second policy type during operation S440 in method 400. The method then proceeds to operation S930.

[0156] At operation S930, in response to receiving the notification request and in response to detecting the change, the apparatus may be configured to transmit the notification to the user. The notification may include information related to the change, such as the currently supported policy types of the at least one network function, the updated policy being implemented by the at least one network function, the policies currently implemented (not deregistered) by the at least one network function, and the like.

[0157] FIG. 10 illustrates a flow diagram of an example method 1000 for performing additional policy management, according to one or more example embodiments. One or more operations in method 1000 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage policies implemented in a network, and may include a PAP.

[0158] As illustrated in FIG. 10, at operation S 1010, the apparatus may be configured to receive a policy generation request. The policy generation request may be received from the user,and may include a request to generate a policy from a policy intent. The policy generation request may also include the policy intent associated with the policy generation request.

[0159] The policy intent may include at least one of: a business intent and an operational intent. The business intent may include a description of non-configuration related goals to be achieved in the network. For example, the business intent may include a description of a target to reduce energy consumption from 10am to 2pm. The operational intent may include a description of configuration related goals to be achieved in the network. For example, the operational intent may include a description of a target to improve resource utilization efficiency by 10%.

[0160] Here, the apparatus may act as an intent handler configured to receive policy intents and generate policies from such policy intents. The method then proceeds to operation SI 020.

[0161] At operation SI 020, in response to receiving the policy generation request, the apparatus may be configured to generate the policy based on the policy intent.

[0162] The apparatus may utilize any means to generate the policy based on the policy intent (convert / translate a policy intent into a policy). For example, the apparatus may utilize functions in the network, such as rApps, AI / ML models, and the like, in order to generate the policy based on the policy intent. Further, the generated policy may include any kinds of actions, configurations, and the like associated with the policy intent.

[0163] For example, the policy intent may include a description of a target to reduce energy consumption from 10am to 2pm. In this regard, the apparatus may determine where in the network can the energy consumption be reduced during 10am to 2pm, and may determine that a certain geographical area would have a low traffic during 10am to 2pm. Subsequently, the apparatus may determine that the cells associated with the above area can perform certain actions to reduce energyconsumption (e.g., shutting down certain antennas, and the like). Accordingly, the apparatus may generate a policy specifying that the above cells in the above geographical area should perform the above actions to reduce energy consumption during 10am to 2pm.

[0164] Accordingly, the apparatus may provide the generated policy to the user, as well as register the generated policy and transmit the generated policy to a corresponding PDP in order to implement such policy.

[0165] In view of the above, example embodiments of the present disclosure allow for effective and efficient management of all policies implemented anywhere within the network.

[0166] Example embodiments of the present disclosure also provide an apparatus that supports policy-driven decision processes within the O-RAN system, and allow service consumers (i.e., users) to specify and provision policies for SMOFs (e.g., the producers of NFO, FOCOM, RANOAM, and the like) as well as specify and provision Al policies for the Near-RT RIC.

[0167] Further, the PMI / PAP also allows for decoupling of policy management from the underlying entities that apply and execute them (i.e., elements acting as PDP and / or PEP).Example Use Cases for Managing Policies in the Present Disclosure

[0168] In the following, several example use cases performable by the apparatus of one or more example embodiments of the present disclosure are described with reference to FIG. 11 A to 11G.

[0169] FIG. HA illustrates a flow diagram of an example use case for managing policies, according to one or more example embodiments. As shown in FIG. 11A, the use case may involve an rApp 1110A, a PMI 1120A, an NFO / FOCOM 1130A, and an O-Cloud 1140A. Further, one ormore operations in FIG. 11A may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0170] Here, the rApp 1110A may act as a user (PMI consumer), while the PMI 1120A may act as a PAP (PMI producer) that allows the rApp 1110A to create (register), update, deregister, and delete policies for the NFO / FOCOM 1130A (as well as other network functions in the network that are implementing policies).

[0171] The NFO / FOCOM 1 130A may act as a PDP and delegate the O-Cloud 1140A as a PEP for certain policies, while the NFO / FOCOM 1130A may act as both a PDP and PEP for other policies.

[0172] The NFO / FOCOM 1130A acting as the PDP may register the policy types which it supports with the PMI 1120A acting as the PAP. Accordingly, the rApp 1110A may query the PMI 1120A regarding the policy types which the NFO / FOCOM 1130A support, create a policy for the NFO / FOCOM 1130A based on such policy types, and register the policy to the PMI 1120A in order to implement the policy in the network.

[0173] In this regard, in the case where the NFO / FOCOM I I 30A acts as a PDP and the O- Cloud 1140A acts as a PEP, the NFO / FOCOM I I 30A may communicate with the O-Cloud 1140A via the 02 interface, such that the policy is implemented and enforced via the 02 interface.

[0174] FIG. 1 IB illustrates a flow diagram of an example use case for managing policies, according to one or more example embodiments. As shown in FIG. 1 IB, the use case may involve an rApp 1 HOB, a PMI 1120B, an Al service 1130B, and a Near-RT RIC 1140B. Further, one or more operations in FIG. 1 IB may involve or may be part of one or more operations describedabove with reference to FIG. 3 to FIG. 10. Furthermore, the example use case shown in FIG. 1 IB may be considered as an Al policy function-based policy decision.

[0175] Here, the rApp 1110B may act as a user (PMI consumer), while the PMI 1120B may act as a PAP (PMI producer) that allows the rApp 1110B to create (register), update, deregister, and delete policies for the Al service 1130B (i.e., Al policies).

[0176] The Al service 1130B may act as a PDP while the Near-RT RIC 1140B may act as a PEP.

[0177] The Al service 1130B acting as the PDP may register the policy types which it supports with the PMI 1120B acting as the PAP (e.g., policy types defined in Al-TD). Accordingly, the rApp 1110B may query the PMI 1120B regarding the policy types which the Al service 1130B support, create a policy for the Al service 1130B based on such policy types, and register the policy to the PMI 1120B in order to implement the policy in the network.

[0178] In this regard, the Al service 1130B may communicate with the Near-RT RIC 1140B via the Al interface, such that the policy is implemented and enforced via the Al interface (Al policy).

[0179] It is understood that, while the rApp 1110B may also communicate with the Al service 1130B and the Near-RT RIC 1140B independently of the PMI 1120B in order to create and implement Al policies, communicating with the Al service 1130B and the Near-RT RIC 1140B via the PMI 1120B centralizes policy management within the SMO, which facilitates comprehensive policy analysis and conflict resolution between Al and other interfaces, as well as improves overall policy coherence across the network.

[0180] FIG. 11C illustrates a flow diagram of an example use case for managing policies, according to one or more example embodiments. As shown in FIG. 11C, the use case may involve an rApp 1110C, an Al service 1120C, a Near-RT RIC 1130C, and E2 nodes 1140C (i.e., O-CU, O-DU, and the like). Further, one or more operations in FIG. 11C may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10. Furthermore, the example use case shown in FIG. 11C may be considered as a Near-RT RIC -based policy decision.

[0181] Here, the rApp 1110C may act as both a user (PMI consumer) and a PAP (PMI producer) where the rApp 1110C may utilize Al policy-related data types to create policies for the Near-RT RIC 1130C. Here, the Al service 1120C may act as a transparent conduit to simply route policies to the Near-RT RIC 1 DOC.

[0182] The Near-RT RIC I I 30C may act as a PDP while the E2 nodes 1140C may act as a PEP.

[0183] The Near-RT RIC I I 30C acting as the PDP may determine which E2 Nodes will implement the policies and decides on the appropriate use cases or policies for execution over the E2 interface. The E2 nodes 1140C acting as the PEP may enforce actions for specific use case or objective determined by the Near-RT RIC 1130C over managed function within E2 Nodes.

[0184] In this regard, the Al service 1120C may communicate with the Near-RT RIC I I 30C via the Al interface, while the Near-RT RIC I I 30C may communicate with the E2 nodes 1140C via the E2 interface.

[0185] FIG. 1 ID illustrates a flow diagram of an example use case for managing policies, according to one or more example embodiments. As shown in FIG. 1 ID, the use case may involve an operational support systems (OSS)Zbusiness support system (BSS) 1110D, a PMI 1120D, anNFO / FOCOM 1130D, an O-Cloud 1140D, an Al service 1150D, and a Near-RT RIC 1160D. Further, one or more operations in FIG. 1 ID may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0186] Here, the OSS / BSS 1110D may act as a user (PMI consumer), while the PMI 1120D may act as a PAP (PMI producer) that allows the OSS / BSS 1110D to create (register), update, deregister, and delete policies for the NFO / FOCOM 1130D and the Al service 1150D.

[0187] The NFO / FOCOM 1130D and the Al service 1150D may act as PDPs while the O-Cloud 1 MOD and the Near-RT RIC 1160D may act as PEPs.

[0188] The OSS / BSS 1 HOD may transmit a policy intent to the PMI 1120D, where the PMI 1120D may process the policy intent as an intent handler, and translate the policy intent into a policy, action, and the like. Accordingly, the policy may be registered and transmitted to the NFO / FOCOM 1 BOD and / or the Al service 1150D as appropriate to implement the policy.

[0189] FIG. 1 IE illustrates a flow diagram of an example use case for managing policies, according to one or more example embodiments. As shown in FIG. 1 IE, the use case may involve an rApp 1110E, a PMI 1120E, RAN network function (NF) operation, administration, and maintenance (0AM) services 1 BOE, and O-RAN Nodes 1140E. Further, one or more operations in FIG. 1 IE may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10. Furthermore, the example use case shown in FIG. 1 IE may be considered as a RAN 0AM based policy enforcement.

[0190] Here, the rApp 1110E may act as a user (PMI consumer), while the PMI 1120E may act as a PAP (PMI producer) that allows the rApp 1110E to create (register), update, deregister, and delete policies for the RAN NF 0AM 1 BOE.

[0191] The RAN NF OAM 1130E may act as both a PDP and a PEP.

[0192] The RAN NF OAM 1130E acting as the PDP may receive imperative type of policies from the PMI 1120E. Here, the policy may contain attributes to execute actions for the O- RAN Nodes 1140E (e g., 0-DU and 0-CU), such that policy itself dictates what and how to execute the policies, and the RAN NF OAM 1130E may act as the PEP to execute said actions in accordance with the policy.

[0193] Examples of deployment scenario for such configuration may include threshold based policy management and trace retrieval, event based policy management and trace retrieval, radio coverage optimization through physical parameters, M-plane based TRX control or shared 0-RU resiliency, and the like. In particular, with regards to the M-plane based TRX control, such scenario may involve a scenario when a specific TRX control configuration needs to be activated, and the SMO function may provide the necessary configuration parameters to the network function (NF), such that the SMO is responsible for activating the TRX control configuration at the designated time, ensuring alignment with the operational requirements and network policies.

[0194] FIG. 1 IF illustrates a flow diagram of an example use case for managing policies, according to one or more example embodiments. As shown in FIG. 1 IF, the use case may involve an rApp 1110F, a PMI 1120F, RAN network function (NF) operation, administration, and maintenance (OAM) services 1130F, and 0-RAN Nodes 1140F. Further, one or more operations in FIG. 1 IF may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10. Furthermore, the example use case shown in FIG. 1 IF may be considered as an 01 based policy enforcement.

[0195] Here, the rApp 1110F may act as a user (PMI consumer), while the PMI 1120F may act as a PAP (PMI producer) that allows the rApp 1110F to create (register), update, deregister, and delete policies for the RAN NF 0AM 1130F.

[0196] The RAN NF 0AM 1130F may act as aPDP, while the 0-RAN Nodes 1140F (e.g., Near-RT RIC, 0-DU, O-CU, and the like) may act as a PEP.

[0197] The RAN NF 0AM 1130F acting as the PDP may receive declarative type of policies from the PMI 1120F, where the declarative type of policy generally does not dictate actions in the policies and objectives, or statement of policies need to be interpreted to derive actions. Accordingly, the RAN NF 0AM 1130F acting as the PDP may decide on designing 01 policies to be enforced by the 0-RAN Nodes 1140F acting as the PEP.

[0198] Examples of deployment scenario for such configuration may include energy saving policies, traffic distribution policies, AI / ML training and inferencing policies, and the like.

[0199] FIG. 11G illustrates a flow diagram of an example use case for managing policies, according to one or more example embodiments. As shown in FIG. 11G, the use case may involve an rApp 1 HOG, a PMI 1120G, a Near-RT RIC 1 BOG, and E2 Nodes 1 MOG. Further, one or more operations in FIG. 11G may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10. Furthermore, the example use case shown in FIG. 11G may be considered as a Near-RT RIC based 01 policy enforcement.

[0200] Here, the rApp 1 HOG may act as a user (PMI consumer), while the PMI 1120G may act as a PAP (PMI producer) that allows the rApp 1110G to create (register), update, deregister, and delete policies for the Near-RT RIC 1 MOG.

[0201] The Near-RT RIC 1130G may act as a PDP, while the E2 Nodes 1 MOG (e.g., O- DU, O-CU, and the like) may act as a PEP.

[0202] The RAN NF OAM 1130G acting as the PDP may register 01 policy datatypes related to Near-RT RIC enforcement, and the E2 Nodes 1140G acting as the PEP may enforce policies determined by the RAN NF OAM 1 MOG.

[0203] The above described use cases in FIG. 1 IE to FIG. 11G may allow for integration of 01 policies to the PMI in the SMO, such that 01 interfaces can adopt a standardized policy management framework to deploy policies for 0-RAN nodes.Example Lifecycle for Managing Policies in the Present Disclosure

[0204] In the following, an example lifecycle for managing policies performable by the apparatus of one or more example embodiments of the present disclosure are described with reference to FIG. 12A to 12G.

[0205] FIG. 12A illustrates a flow sequence of a policy creation stage within a lifecycle for managing policies, according to one or more embodiments. As shown in FIG. 12A, the flow sequence may involve a user 1210, a PAP 1220, a PDP 1230, and a PEP 1240. The user 1210, PAP 1220, PDP 1230, and PEP 1240 may be similar to the user 210, PAP 220, PDP 230, and PEP 240 described above in relation to FIG. 2. Further, one or more operations in FIG. 12A may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0206] Here, the user 1210, which may be an internal and / or external PMI consumer, may need to create a policy that prioritizes video traffic during peak hours to ensure quality of service (QoS). Accordingly, the user 1210 may transmit a request to create the policy to the PAP 1220 at step 1, along with relevant information.

[0207] At step 2, the PAP 1220 may define the policy (new policy) in accordance with the request, where the policy may specify that video traffic should have priority between 6 PM and 10 PM.

[0208] At step 3, the PAP 1220 may transmit a request to validate the policy to the PDP 1230, where the PDP 1230 may validate and check if this new policy conflicts with existing policies and may adjust the policy to ensure there are no conflicts at step 4.

[0209] Accordingly, at step 5, the PDP 1230 may transmit the validation results to the PAP 1220, where the validation results may indicate that the new policy has no conflict or may include modifications to the new policy such that the new policy has no conflict.

[0210] At step 6, the PAP 1220 may store the new policy in the memory, and may then transmit a notification indicating the creation of the new policy to the user 1210 at step 7.

[0211] It is understood that the PEP 1240 may not be involved in the policy creation stage.

[0212] FIG. 12B illustrates a flow sequence of a policy activation stage within a lifecycle for managing policies, according to one or more embodiments. As shown in FIG. 12B, the flow sequence may involve a user 1210, a PAP 1220, a PDP 1230, and a PEP 1240. The user 1210, PAP 1220, PDP 1230, and PEP 1240 may be similar to the user 210, PAP 220, PDP 230, and PEP 240 described above in relation to FIG. 2. Further, one or more operations in FIG. 12B may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0213] Here, the video traffic prioritization policy created during the sequence in FIG. 12A needs to be activated. Accordingly, the user 1210, which may be an internal and / or external PMI consumer, may transmit a request to activate the policy to the PAP 1220 at step 1.

[0214] At step 2, the PAP 1220 may activate the policy at 5:50 PM in preparation for the peak hours (since the policy specifies that video traffic should have priority between 6 PM and 10 PM), and may transmit a notification to the PDP 1230 that the video traffic prioritization policy is activated at step .

[0215] At step 4, the PDP 1230 may evaluate and assess the current network conditions and load, and determine how best to apply the policy without causing issues for other traffic types.

[0216] Accordingly, at step 5, the PDP 1230 may transmit the determined policy actions to the PEP 1240, where the PEP 1240 may begin enforcing the policy at 6 PM ensuring video traffic is prioritized over other types of traffic at step 6.

[0217] Subsequently, the PEP 1240 may transmit a notification that the policy is being enforced to the PDP 1230, where the PDP 1230 may then transmit a similar notification to the PAP 1220 and subsequently to the user 1210 at steps 7 to step 9.

[0218] FIG. 12C illustrates a flow sequence of a policy update stage within a lifecycle for managing policies, according to one or more embodiments. As shown in FIG. 12C, the flow sequence may involve a user 1210, a PAP 1220, a PDP 1230, and a PEP 1240. The user 1210, PAP 1220, PDP 1230, and PEP 1240 may be similar to the user 210, PAP 220, PDP 230, and PEP 240 described above in relation to FIG. 2. Further, one or more operations in FIG. 12C may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0219] Here, the user 1210 may decide to extend the video traffic prioritization policy to also include streaming audio traffic. Accordingly, the user 1210, which may be an internal and / or external PMI consumer, may transmit a request to update the policy to the PAP 1220 at step 1, along with relevant information.

[0220] At step 2, the PAP 1220 may update the policy to include audio traffic thereby ensuring both video and audio traffic are prioritized during peak hours, and may transmit a request to validate the updated policy to the PDP 1230 at step 3.

[0221] At step 4, the PDP 1230 may validate and check if the updated policy conflicts with existing policies, as well as update its decision-making process to include audio traffic in the prioritization.

[0222] Accordingly, at step 5, the PDP 1230 may transmit the change in policy actions in accordance with the updated decision making process (i.e., include audio traffic in the prioritization) to the PEP 1240, where the PEP 1240 may begin enforcing the updated policy giving both video and audio traffic higher priority during the designated time at step 6.

[0223] Subsequently, the PEP 1240 may transmit a notification that the updated policy is being enforced to the PDP 1230, where the PDP 1230 may then transmit a similar notification to the PAP 1220 and subsequently to the user 1210 at steps 7 to step 9.

[0224] FIG. 12D illustrates a flow sequence of a policy deactivation stage within a lifecycle for managing policies, according to one or more embodiments. As shown in FIG. 12D, the flow sequence may involve a user 1210, a PAP 1220, a PDP 1230, and a PEP 1240. The user 1210, PAP 1220, PDP 1230, and PEP 1240 may be similar to the user 210, PAP 220, PDP 230, and PEP 240 described above in relation to FIG. 2. Further, one or more operations in FIG. 12D may involve or may be part of one or more operations described above with reference to FIG. 3 toFIG. 10.

[0225] Here, the user 1210 may decide to deactivate the video and audio traffic prioritization policy after peak hours. Accordingly, the user 1210, which may be an internal and / or external PMI consumer, may transmit a request to deactivate the policy to the PAP 1220 at step 1.

[0226] At step 2, the PAP 1220 may deactivate the policy at 10:05 PM, and may transmit a notification that the policy has been deactivated to the PDP 1230 at step 3.

[0227] At step 4, the PDP 1230 may stop considering the policy in its decision-making reverting to standard traffic management policies, and may transmit instructions to stop actions related to the deactivated policy to the PEP 1240.

[0228] Accordingly, at step 5, the PEP 1240 may stop enforcement of the deactivated policy, return to normal operation and treat all traffic types equally after the policy is deactivated.

[0229] Subsequently, the PEP 1240 may transmit a notification that the deactivated policy has been deactivated to the PDP 1230, where the PDP 1230 may then transmit a similar notification to the PAP 1220 and subsequently to the user 1210 at steps 6 to step 8.

[0230] FIG. 12E illustrates a flow sequence of a policy deletion stage within a lifecycle for managing policies, according to one or more embodiments. As shown in FIG. 12E, the flow sequence may involve a user 1210, a PAP 1220, a PDP 1230, and a PEP 1240. The user 1210, PAP 1220, PDP 1230, and PEP 1240 may be similar to the user 210, PAP 220, PDP 230, and PEP 240 described above in relation to FIG. 2. Further, one or more operations in FIG. 12E may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0231] Here, the user 1210 may decide that the video and audio traffic prioritization policy is no longer needed in the future. Accordingly, the user 1210, which may be an internal and / or external PMI consumer, may transmit a request to delete the policy to the PAP 1220 at step 1.

[0232] At step 2, the PAP 1220 may delete the policy and remove the policy from the memory.

[0233] At step 3, the PDP 1230 may transmit a notification to the PDP 1230 that the policy has been deleted, where the PDP 1230 may then update its records to ensure the policy is no longer part of its decision-making framework at step 4.

[0234] At step 5, the PDP 1230 may transmit a request to clean up to the PEP 1240, where the PEP 1240 may then clean up and clear any remaining configurations related to the policy and return to normal operations at step 6.

[0235] Subsequently, the PEP 1240 may transmit a notification that the policy has been deleted (cleaned up) to the PDP 1230, where the PDP 1230 may then transmit a similar notification to the PAP 1220 and subsequently to the user 1210 at steps 7 to step 9.

[0236] FIG. 12F illustrates a flow sequence of a policy and policy type identification stage within a lifecycle for managing policies, according to one or more embodiments. As shown in FIG. 12F, the flow sequence may involve a user 1210, a PAP 1220, a PDP 1230, and a PEP 1240. The user 1210, PAP 1220, PDP 1230, and PEP 1240 may be similar to the user 210, PAP 220, PDP 230, and PEP 240 described above in relation to FIG. 2. Further, one or more operations in FIG. 12F may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0237] Here, the user 1210 may want to retrieve available policy types and details on how a specific Al policy was enforced during peak traffic hours. Accordingly, the user 1210, which may be an internal and / or external PMI consumer, may transmit a request to identify the policy and policy type to the PAP 1220 at step 1.

[0238] At step 2, the PAP 1220 may identify and retrieve a list of policies and policy types.

[0239] At step 3, the PAP 1220 may transmit the list of policies to the user 1210.

[0240] At step 4 and step 5, the PAP 1220 may transmit a request to obtain information on decision-making logic of the specific Al policy to the PDP 1230 and transmit a request to obtain information on enforcement actions of the specific Al policy to the PEP 1240, respectively. Accordingly, the PDP 1230 may return the decision-making logic including how the policy is applied to prioritize traffic to the PAP 1220 at step 6, and the PEP 1240 may return the enforcement actions including how the policy was enforced in the network and how traffic was prioritized based on the policy to the PAP 1220 at step 7.

[0241] Accordingly, at step 8, the PAP 1220 may consolidate the data received from the PDP 1230 and PEP 1240, and provide the consolidated data along with the list of policy types to the user 1210.

[0242] FIG. 12G illustrates a flow sequence of a policy status identification stage within a lifecycle for managing policies, according to one or more embodiments. As shown in FIG. 12G, the flow sequence may involve a user 1210, a PAP 1220, a PDP 1230, and a PEP 1240. The user 1210, PAP 1220, PDP 1230, and PEP 1240 may be similar to the user 210, PAP 220, PDP 230, and PEP 240 described above in relation to FIG. 2. Further, one or more operations in FIG. 12G may involve or may be part of one or more operations described above with reference to FIG. 3 to FIG. 10.

[0243] Here, the user 1210 may want to query the status of a traffic management policy to understand whether the policy is currently active and how it has been enforced in the past week.Accordingly, the user 1210, which may be an internal and / or external PMI consumer, may transmit a request to identify a status of the policy to the PAP 1220 at step 1.

[0244] At step 2, the PAP 1220 may identify the current status of the policy (e.g., active, inactive, suspended, and the like).

[0245] At step 3 and step 4, the PAP 1220 may transmit a request to obtain information on decision-making logic of the policy to the PDP 1230 and transmit a request to obtain information on enforcement actions of the policy to the PEP 1240, respectively. Accordingly, the PDP 1230 may return the decision-making logic including conditions and actions triggered by the policy to the PAP 1220 at step 5, and the PEP 1240 may return the enforcement actions including how the policy was applied and its impact on network performance to the PAP 1220 at step 6.

[0246] Accordingly, at step 7, the PAP 1220 may consolidate the data received from the PDP 1230 and PEP 1240, and provide the consolidated data along with the identified status of the policy to the user 1210.Various Aspects of Embodiments

[0247] According to example embodiments, an apparatus of the present disclosure allows for effective and efficient management of all policies implemented anywhere within the network.

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

[0249] 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 abovecomponents 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.

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

[0251] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to anexternal 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.

[0252] 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 wide area 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 byutilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

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

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

[0255] 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, whichcomprises 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.

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

[0257] One or more components of the system of the example embodiments (e.g., Non-RT RIC, Near-RT RIC, SMO etc.), as well as the operations associated therewith (e.g., one or more operations in FIG. 3 to FIG. 10, 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 ofa 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. 1 to FIG. 12 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, SMO, etc.) stored in a memory or a storage component of the device.

[0258] FIG. 13 illustrates an embodiment of a device 1300 for implementing one or more example embodiments. As shown in FIG. 13, the device 1300 includes a processor 1310, a memory 1320, a storage component 1330, an input component 1340, an output component 1350, a communication interface 1360, and a bus 1370.

[0259] The processor 1310, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1310 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 1310 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.

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

[0261] Storage component 1330 stores information and / or software related to the operation and use of the device 1300. For example, storage component 1330 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.

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

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

[0264] Communication interface 1360 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1360 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 acommunication network that exists between the device 1300 and other devices. In other words, the standard of the communication interface 1360 is not limited.

[0265] The bus 1370 acts as an interconnect between the processor 1310, the memory 1320, the storage component 1330, the input component 1340, the output component 1350, and the communication interface 1360 of the device 1300. The bus 1370 may include a wired interconnection or a wireless interconnection.

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

[0267] Further, according to example embodiments, the device 1300 may include one or more elements from the system architecture described above in relation to FIG. 1. For example, the device 1300 may include the SMO, or may include a network function implemented in the SMO.

[0268] 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 be configured to: obtain, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions;receive, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identify the policy type that is supported by the target network function based on the obtained policy type registration information; provide, to the user, the identified policy type; receive, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request may include the policy; and in response to receiving the policy registration request, register the policy and transmit the policy to the target network function.Item [2]: The apparatus according to item [1], wherein the policy may be implemented via an 01 interface, an 02 interface, or an M-Plane.Item [3]: The apparatus according to one of items [l]-[2], wherein the apparatus may be further configured to: receive, from at least one network function in the plurality of network functions, a policy type update request to update a stored policy type registration information of the at least one network function, wherein the policy type update request may include policy type update information specifying at least one of a policy type newly supported by the at least one network function and a policy type that is no longer supported by the at least one network function; and in response to receiving the policy type update request, update the stored policy type registration information of the at least one network function based on the policy type update information.Item [4]: The apparatus according to one of items [l]-[3], wherein the apparatus may be further configured to: receive, from the user, a policy identification request toidentify a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy identification request, identify the policy that is being implemented via the at least one network function.Item [5]: The apparatus according to one of items [l]-[4], wherein the apparatus may be further configured to: receive, from the user, a policy update request to update a policy that is being implemented via at least one network function in the plurality of network functions, wherein the policy update request may include update information; and in response to receiving the policy update request, update the policy that is being implemented via the at least one network function based on the received update information.Item [6]: The apparatus according to one of items [l]-[5], wherein the apparatus may be further configured to: receive, from the user, a policy deregistration request to deregister a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy deregistration request, deregister the policy that is being implemented via the at least one network function.Item [7]: The apparatus according to one of items [l]-[6], wherein the apparatus may be further configured to: receive, from the user, a policy status request to identify a status of a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy status request, identify the status of the policy that is being implemented via the at least one network function.Item [8]: The apparatus according to one of items [l]-[7], wherein the apparatus may be further configured to: receive, from the user, a notification request to receive anotification regarding a change related to a policy type and a policy associated with at least one network function in the plurality of network functions; and in response to receiving the notification request and in response to detecting the change, transmit the notification to the user.Item [9]: The apparatus according to one of items [l]-[8], wherein the apparatus may be further configured to: receive, from the user, a policy generation request to generate a policy based on a policy intent, wherein the policy generation request may include the policy intent; and in response to receiving the policy generation request, generate the policy based on the policy intent.Item

[0010] : A method that may include: obtaining, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receiving, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identifying the policy type that is supported by the target network function based on the obtained policy type registration information; providing, to the user, the identified policy type; receiving, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request may include the policy; and in response to receiving the policy registration request, registering the policy and transmitting the policy to the target network function.Item

[0011] : The method according to item

[0010] , wherein the policy may be implemented via an 01 interface, an 02 interface, or an M-Plane.Item

[0012] : The method according to one of items

[0010] -[l 1], wherein the method may further include: receiving, from at least one network function in the plurality of network functions, a policy type update request to update a stored policy type registration information of the at least one network function, wherein the policy type update request may include policy type update information specifying at least one of: a policy type newly supported by the at least one network function and a policy type that is no longer supported by the at least one network function; and in response to receiving the policy type update request, updating the stored policy type registration information of the at least one network function based on the policy type update information.Item

[0013] : The method according to one of items

[0010] -

[0012] , wherein the method may further include: receiving, from the user, a policy identification request to identify a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy identification request, identifying the policy that is being implemented via the at least one network function.Item

[0014] : The method according to one of items

[0010] -

[0013] , wherein the method may further include: receiving, from the user, a policy update request to update a policy that is being implemented via at least one network function in the plurality of network functions, wherein the policy update request may include update information; and in response to receiving the policy update request, updating the policy that is being implemented via the at least one network function based on the received update information.Item

[0015] : The method according to one of items

[0010] -

[0014] , wherein the method may further include: receiving, from the user, a policy deregistration request to deregister a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy deregistration request, deregistering the policy that is being implemented via the at least one network function.Item

[0016] : The method according to one of items

[0010] -[l 5], wherein the method may further include: receiving, from the user, a policy status request to identify a status of a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy status request, identifying the status of the policy that is being implemented via the at least one network function.Item

[0017] : The method according to one of items

[0010] -

[0016] , wherein the method may further include: receiving, from the user, a notification request to receive a notification regarding a change related to a policy type and a policy associated with at least one network function in the plurality of network functions; and in response to receiving the notification request and in response to detecting the change, transmitting the notification to the user.Item

[0018] : The method according to one of items

[0010] -

[0017] , wherein the method may further include: receiving, from the user, a policy generation request to generate a policy based on a policy intent, wherein the policy generation request may include the policy intent; and in response to receiving the policy generation request, generating the policy based on the policy intent.Item

[0019] : A non-transitory computer-readable recording medium that may have recorded thereon instructions executable by an apparatus to cause the apparatus to performa method including: obtaining, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receiving, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identifying the policy type that is supported by the target network function based on the obtained policy type registration information; providing, to the user, the identified policy type; receiving, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request may include the policy; and in response to receiving the policy registration request, registering the policy and transmitting the policy to the target network function.Item

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

[0019] , wherein the policy may be implemented via an 01 interface, an 02 interface, or an M-Plane.

[0269] 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.Additional Descriptions

[0270] 1. Policy Management and Information (PMI) SMOS

[0271] 1.1 Overview

[0272] A policy refers to a set of rules, guidelines, or conditions that govern the behaviour and actions of 0-RAN resources and services. Policies are used to automate various aspects of network resources and services; they ensure that the network services and their resources operate in accordance with predefined rules and objectives. Policies can typically be expressed in a structured format that defines the scope, objectives, and conditional statements or constraints.

[0273] For the SMO to ensure that 0-RAN resources such as O-Cloud, 0-RAN nodes are allocated and managed consistently and efficiently, it is important to manage these 0-RAN resources through polices. One of the most important goals of Policy Management and Information (PMI) is to support policy-driven decision processes controlled by the SMO within the 0-RAN system.

[0274] There are three different roles related to policies:

[0275] 1) Policy Administration Point (PAP), responsible for the provisioning of policies(create, update, delete, get, Query ),

[0276] (As defined in NIST Glossary here https: / / csrc.nist.gov / glossary / term / policy_administration_point)

[0277] 2) Policy Decision Point (PDP), responsible to determine where in a decision process a certain policy can be applied, (As defined in NIST Glossary here https: / / csrc.nist.gov / glossary / term / pdp)

[0278] 3) Policy Enforcement Point (PEP), responsible for the executing the actions derived from the policies. (As defined in NIST Glossary here https: / / csrc.nist.gov / glossary / term / policy enforcement point)

[0279] Depending on the use case, a SMOF can act in one or more of these roles.

[0280] The Policy Management and Information (PMI) SMOS allows service consumers to specify and provision policies for SMOFs such as the producers of NFO, FOCOM, RANOAM etc., and Al policies for the Near-RT RIC etc., hence representing the PAP role only. Policy Management and Information (PMI) SMOS decouples policy management from the underlying entities that apply and execute them, i.e., which play a PDP and / or PEP role. The PDP / PEP role can be played by SMOFs or by entities outside SMO, such as in case of Al policies by the Near- RT RIC, O-DU or O-DU in case of 01 based polices, 0-RU in case of M-Plane based policies.

[0281] The Policy Management and Information (PMI) SMOS main capabilities are listed below (non-exhaustive list):

[0282] Policy type registration and deregistration: A PMI SMOS consumer can request to create and register the policy types it supports with Policy Management and Information (PMI), also allows to delete, and deregister policy types. Some examples of policy types can be resource management, LCM such as healing and scaling, monitoring etc.

[0283] Discover and Query Policy types: A PMI SMOS consumer can request to discover, and query supported policy types.

[0284] Create, Query / Read, Update, delete policies: PMI SMOS consumers can request to create, query / read, update and delete policies for any SMOF (as well as Al policies for the near- RT RIC, 01 policies for O-DU or O-DU, M-Plane based policies for 0-RU) that is supporting the related policy types as known to the PMI.

[0285] Discover Policies: A PMI SMOS consumer can request to discover policies maintained by PMI SMOS producer.

[0286] Policy Status: PMI SMOS consumer request to query / read status of policies, such as enforced, running, not enforced , active , inactive etc. obtained by PMI SMOS producer from the PDPs and PEPs.

[0287] Subscribe / Notify: A PMI SMOS consumer can subscribe for notifications of events such as policy changes related to policies and policy types.

[0288] 2. Policy Management and information - Stage 2 Details

[0289] This stage will cover work on making PMI interoperable by defining standard services, role and responsibilities, use cases, deployment scenarios, policy object. PMI stage 2 work shall include,

[0290] 1. General Aspects

[0291] 1.1 PMI Architecture

[0292] 1.2 PMI interface general principles

[0293] 1.3 PMI Interface specification objectives

[0294] 1.4 PMI Interface capabilities

[0295] 1.5 Roles / responsibilities for various deployment scenarios (E2E use cases)

[0296] 2. Functions of PMI Interface

[0297] 2.1 Policy management

[0298] 2.1.1 Policy definitions and types

[0299] 2.1.2 Policy Model or Object

[0300] 2.1.3 Lifecycle aspects of PMI policies

[0301] 2.1.4 States and state transitions of policy management

[0302] 3. Signalling procedures of the PMI interface

[0303] 3.1 Policy related procedures.

[0304] 3.2 Procedural Use cases and call flows between PMI and consumer only (Not E2E)

[0305] 4. Requirement for PMI services which will be used to define stage 3 APIs.

[0306] 1. General Aspects

[0307] 1.1 PMI Interface Architecture

[0308] PMI API (PAP)

[0309] PMI API act as PAP for PMI consumer which manages policy and policy types of CRUD operation. It stores all policy types and policies with policy DB which is part of PMI.

[0310] Whenever PMI consumer queries policy, policy types then PMI API queries to policy DB for information. Also, all created policies and policy types to store in Policy DB

[0311] Policy Types

[0312] A Policy Type describes the properties, targets, and triggers that the policy for a feature can have.

[0313] The configuration data that the policy can take. The Policy Type describes each property that a policy of a given type can take. A Policy Type definition also allows the default value, optionality, and the ranges of properties to be defined.

[0314] The targets such as network element types, functions, services, or resources on which a policy of the given type can act.

[0315] The triggers such as the event type, filtered event, scheduled trigger, or conditions that can activate a policy of the given type.

[0316] Policy Types can be used as declarative or intent, imperative policy definitions.Consumer needs to query policy types to understand policy templates for particular policy types.

[0317] Policies

[0318] A Policy is defined using a Policy Types available with PMI producer.

[0319] 1.2 PMI interface general principles

[0320] The general principles for the specification of the PMI interface are as follows:

[0321] the PMI interface is an open logical interface within 0-RAN architecture between PMI Consumer such as other SMO Functions such as rApp, NFO / FOCOM, RAN 0AM etc and PMI producer who provides PMI services.

[0322] the PMI interface enables a multi-vendor environment and is independent of specific implementations of the functions within SMO.

[0323] the PMI interface is defined in an extensible way that enables new services and data types to be added without needing to change the protocol stack or the procedures.

[0324] the PMI interface enables policy-based guidance (event, condition, actions) of resource management internal functions or applications that are part of SMO functions, O-Cloud, 0-RAN nodes.

[0325] the PMI interface can provide basic feedback mechanism from PMI Producer or functions acting as policy decision point that enables PMI consumer to monitor the status of policies.

[0326] the policy enforcement service in SMO functions acting as PDP or PEP requires that the policies transferred over PMI interface are expressed using a standardized mechanism (language, syntax, ...);

[0327] PMI policies are created, modified and deleted by the PMI consumer.

[0328] the PMI policies are enforced until deleted. It is the responsibility of PMI consumer to create and delete policies based on context information e.g., observability from O-Cloud indicating fulfillment of objective received over 02. The PMI interface enables the PDP and PEP to provide feedback to the PMI consumer regarding enforcement status of policies;

[0329] 1.3 PMI Interface specification objectives

[0330] inter-connection of PMI producer functionality acting as PAP in the SMO with PMI consumer functionality in the SMO supplied by different manufacturers.

[0331] provision of basic feedback on policy state from PDP and PEP that enables PMI producer (PAP) to monitor the use of policies.

[0332] 1.4 PMI Interface capabilities

[0333] Transfer of policy management information from PMI produce acting as PAP to Policy consumer such as other SMO functions.

[0334] Policy feedback from SMO functions acting as PDP to PMI consumers through PMI producer acting as PAP.

[0335] Discovery of Policy types registered with PMI producer acting as PAP.

[0336] 1.5 Roles / responsibilities for various deployment scenarios (E2E use cases)

[0337] 1.5.1 PMI Functions Deployment Scenario 1

[0338] Policy functions can be deployed as abstracted roles to existing SMOFs,

[0339] rApp can act as PMI consumer and PMI SMOF as PMI Producer which is PAP which shall allow rApp to Create / Update / Delete Policies for other PDP such as NFO / FOCOM.

[0340] PEP can collocate with PDP in NFO / FOCOM or NFO / FOCOM can delegate PEP down to IMS / DMS based use cases or policy types.

[0341] SMOFs acting as PDPs such as NFO / FOCOM, RAN 0AM etc. needs to register policy type templates with PMI Producer.

[0342] Then rApp can use those policy types to create policies for SMOFs.

[0343] 1.5.2 PMI Functions Deployment Scenario 2 (Al Polices)

[0344] Policy functions can be deployed as abstracted roles within existing SMOFs(Service Management and Orchestration Functions):

[0345] rApp as PMI Consumer: The rApp can act as a PMI consumer, with the PMI SMOF serving as the PMI Producer, which fulfdls the role of the Policy Administration Point (PAP). In this setup, the rApp is granted the ability to create, update, and delete Al policies through the PMI Producer.

[0346] Scenarios for PDP and PEP Roles: There are two potential scenarios for assigning the Policy Decision Point (PDP) and Policy Enforcement Point (PEP) roles within the Al policy functions and the Near-RT RIC:

[0347] a) Al Policy Functions-Based Policy Decisions:

[0348] Roles: In this scenario, Al policy functions serve as the PDPs, while the Near-RT RIC acts as the PEP.

[0349] Implementation: While the rApp can independently create Al policies outside the PMI Producer, creating and managing these policies through the PMI Producer centralizes policy management within the SMO. This centralization facilitates comprehensive policy analysis, conflict resolution between Al and other interfaces, and overall policy coherence across the network.

[0350] b) Near-RT RIC -Based Policy Decisions:

[0351] Roles: In this scenario, the rApp, acting as the PMI Producer, utilizes Al policy- related data types to create policies for the Near-RT RIC. The Al Policy function acts as a transparent conduit, simply routing policies to the appropriate Near-RT RIC.

[0352] Implementation: The Near-RT RIC, functioning as the PDP, determines which xApp will implement the policies and decides on the appropriate use cases or E2 policies for execution over the E2 interface. E2 Nodes will act as PEP to enforce E2 actions for specific use case or objective over managed function within E2 Nodes.

[0353] 1.5.3 PMI Functions Deployment Scenario 3 (Intent Handler)

[0354] Policy functions can be deployed as abstracted roles to existing SMOFs,

[0355] External entity such as OSS / BSS acting as PMI consumer, which can push intent to PMI producer.

[0356] PMI producer as PAP, shall process intent as Intent Handler and translate it for possible policy or action. Here PMI producer may use other functions such as rApp or AIML to translate it to policy or action.

[0357] However, rApp can create Al polices independently of PMI producer but creating policies through PMI producer will help in maintain all policies for SMO in one place for further work such as analysis, conflict mitigation between Al and other interfaces.

[0358] Existing polices types defined in Al-TD needs to register with PMI producer.

[0359] 1.5.4 PMI Functions Deployment Scenario 4 (01 Policy Management)

[0360] Policy functions can be deployed as abstracted roles to existing SMOFs and O-RAN Nodes,

[0361] Policy management framework has been standardized by 3GPP in TS 28.555 (Stage 1) and TS 28.556 (Stage 2 and Stage 3) which are designed for Network policy management for 5G mobile networks. 01 interface can adopt this policy management framework to deploy policies for 0-RAN nodes / network functions such as 0-DU, 0-CU, Near-RT RIC.

[0362] However, there is need to integrate this 01 policies to PMI in SMO, in that process there could be 2 different sub scenarios for deploying PDP and PEP role as below,

[0363] a) RAN 0AM based Policy enforcement

[0364] In this scenario, PAP will be part of PMI service and PDP and PEP will be part of RAN 0AM.

[0365] RAN 0AM receives imperative type of polices from PMI as PDP and then this policy contains attributes to execute actions for 0-DU and 0-CU. So here policy itself dictates what and how to execute the policies, it means PEP in part of RAN 0AM functions.

[0366] Examples for this Deployment Scenario,

[0367] Threshold based PM / Trace retrieval

[0368] Event based PM / Trace retrieval

[0369] Radio Coverage optimization through physical parameters

[0370] M-Plane based TRx Control or Shared 0-RU resiliency etc...

[0371] When a specific TRx Control configuration needs to be activated, the ServiceManagement and Orchestration (SMO) function may provide the necessary configuration parameters to the Network Function (NF). The SMO is responsible for activating the TRx Control configuration at the designated time, ensuring alignment with the operational requirements and network policies.

[0372] b) 01 based Policy enforcement

[0373] In this scenario, PAP will be part of PMI service and PDP will be part of RAN 0AM but PEP to be part of 0-RAN nodes such as Near-RT RIC, 0-DU, O-CU.

[0374] RAN 0AM receives declarative type of polices from PMI as PDP, declarative type of policy generally does not dictate actions in the policies and objectives, or statement of policies need to interpret to derive actions.

[0375] In this RAN 0AM play role of PDP to decide on designing 01 polices towards O- RAN nodes and 0-RAN nodes plays a role of PEP here.

[0376] Examples for this Deployment Scenario,

[0377] Energy saving policies

[0378] Traffic distribution policies

[0379] AIML training and inferencing polies

[0380] c) Near-RT RIC based 01 Policy enforcement

[0381] In this scenario, PAP will be part of PMI service and PDP will be part of Near-RTRIC but PEP to be part of E2 nodes such as 0-DU, O-CU.

[0382] RAN 0AM to register 01 policy datatypes related to Near-RT RIC enforcement. Once PMI consumer creates policy for Near-RT RIC through 01 interface, RAN 0AM act as

[0383] 2. Functions of PMI Interface

[0384] 2.1 Policy management

[0385] 2.1.1 Policy definitions and types

[0386] 2.1.1.1 Policy definition

[0387] The purpose of policies is to ensure that consistent decisions are made governing the behaviour of a system.

[0388] "Policy is a set of rules that is used to manage and control the changing and / or maintaining of the state of one or more managed objects."

[0389] 2.1.1.2 Policy types

[0390] Before discussing policy model it’s important to understand types of polices to be used and its effect on system. MEF Standard MEF 95 discussed three main types of policy paradigms that are used in the PDO: imperative, declarative, and intent policies. While other types of policies are certainly possible (e.g., utility functions).

[0391] 2.1.1.2.1 Imperative Policies

[0392] policies are structured such that they explicitly control the transitioning of one state to another state. A commonly accepted and generic form of imperative policies is the EC A (Event- Condition- Action) Policy.

[0393] Event: An Event is any important occurrence in time of a change in the system being managed, and / or in the environment of the system being managed. Events include time and user actions. Events could be,

[0394] Deployment / Node fault occurred.

[0395] Request for Autoscaling

[0396] Deployment relocation

[0397] Condition: A condition is defined as a set of attributes, features, and / or values that are to be compared with a set of known attributes, features, and / or values to determine whether the set of Actions in that (imperative) Policy Rule can be executed or not. Events could be,

[0398] Node Shutdown if CPU <2%, Memory <2%

[0399] Autoscaling if CPU > 80%

[0400] Action: An action is used to control and monitor the behavior of the system or component that a Policy Rule is applied to when the event and condition clauses are satisfied.

[0401] 2.1.1.2.2 Declarative Policies

[0402] In declarative policies, there isn’t really the notion of an action. Declarative policy describes what the desired outcome is rather than how to achieve it. It focuses on specifying the "what" and leaves the "how" to the underlying system or platform. This allows for flexible and adaptable policy management as the system can choose the most efficient way to achieve the desired state based on its capabilities and context.

[0403] Declarative policies could be,

[0404] "Distribute network traffic across available virtual network functions (CNF / VNFs) to maintain a maximum load of 80% on each CNF / VNF."

[0405] "Guarantee 50 Mbps bandwidth and 10ms latency for the Silver service slice for all users in Region A."

[0406] "Prioritize traffic from emergency services within the Public Safety slice, ensuring at least 99.999% availability."

[0407] 2.1.1.2.3 Intent Policies

[0408] An intent policy is a type of declarative policy that uses statements to express the goals of the policy, but not how to accomplish those goals. Each statement in an Intent Policy may require the translation of one or more of its terms to a form that another managed functional entity can understand.

[0409] "Optimize network performance for video streaming during peak hours. "

[0410] "Allocate 20% of available radio resources to high-value customers during peak hours."

[0411] 2.1.2 Policy Model or Object

[0412] Policy model defines three concepts for Policy: Policy Type, Policy, and Trigger.

[0413] Policy Types specifies.

[0414] its properties, which define the type of configuration parameters that the policy takes

[0415] its targets, which define the node types and / or groups to which the policy type applies

[0416] its triggers, which specify the conditions in which policies of this type are fired

[0417] Policy

[0418] A Policy is used to specify the actual instances of policies that are used in a service. The parameter values of the policy and the actual entities to which it applies may be specified.

[0419] The policies that are used in a service are defined in the policies section of the TOSCA topology template as a Policy. More formally, TOSCA defines a Policy as an artifact that “defines a policy that can be associated with a TOSCA topology or top-level entity definition”. In the definition of a Policy in TOSCA, you specify:

[0420] its properties, which define the values of the configuration parameters that the policy takes

[0421] its targets, which define the node types and / or group types to which the policy type applies

[0422] Note that policy triggers are specified on the Policy Type definition and are not specified on the Policy itself.

[0423] Trigger

[0424] A Trigger defines an event, condition, and action that is used to initiate execution of a policy associated with it. The definition of the Trigger allows specification of the type of events to trigger on, the filters on those events, conditions and constraints for trigger firing, the action to perform on triggering, and various other parameters.

[0425] The triggers that are used in a service are defined as reusable modules in the TOSCA service template as a Trigger. More formally, TOSCA defines a Trigger as an artifact that “defines the event, condition and action that is used to “trigger” a policy it is associated with”. In the definition of a Trigger in TOSCA, you specify:

[0426] its event_type, which defines the name of the event that fires the policy

[0427] its schedule, which defines the time interval in which the trigger is active

[0428] its target_filter, which defines specific filters for firing such as specific characteristics of the nodes or relations for which the trigger should or should not fire

[0429] its condition, which defines extra conditions on the incoming event for firing the trigger

[0430] its constraint, which defines extra conditions on the incoming event for not firing the trigger

[0431] its period, which defines the period to use for evaluating conditions and constraints

[0432] its evaluations, which defines the number of evaluations that must be performed over the period to assert the condition or constraint exists

[0433] its method, the method to use for evaluation of conditions and constraints

[0434] its action, the workflow or operation to invoke when the trigger fires

[0435] 2.1.3 Lifecycle aspects of PMI policies

[0436] In the context of policy lifecycle management as outlined by 3GPP and ETSI, the roles of Policy Administration Point (PAP), Policy Decision Point (PDP), and Policy Enforcement Point (PEP) are critical. These roles work together to ensure that policies are effectively created, decided upon, and enforced across the network. Below is a detailed breakdown of each lifecycle management aspect, along with the roles of PAP, PDP, and PEP, and a small use case example for each.

[0437] 2.1.3.1 Policy Creation

[0438] Roles:

[0439] PAP (Policy Administration Point):

[0440] Role: The PAP is responsible for creating and defining policies. It interacts with the network operator or external systems to gather the necessary information and define the policy's rules, objectives, and conditions.

[0441] Action: Once the policy details are defined, the PAP stores the policy in the system for further processing.

[0442] PDP (Policy Decision Point):

[0443] Role: The PDP may be involved in the validation of the policy during its creation. It ensures that the policy aligns with existing policies and network conditions.

[0444] Action: The PDP can suggest modifications to avoid conflicts or optimize the policy’s effectiveness before it is activated.

[0445] PEP (Policy Enforcement Point):

[0446] Role: The PEP is not directly involved during the creation stage but will later enforce the policy once it is activated.

[0447] Use Case Example:

[0448] Scenario: An operator needs to create a policy that prioritizes video traffic during peak hours to ensure quality of service (QoS).

[0449] PAP: The operator defines the policy using the PAP, specifying that video traffic should have priority between 6 PM and 10 PM.

[0450] PDP: The PDP checks if this new policy conflicts with existing policies and adjusts it to ensure there are no conflicts.

[0451] PEP: Once activated, the PEP will enforce this policy by managing network resources accordingly during the specified hours.

[0452] 2.1.3.2 Policy Activation

[0453] Roles:

[0454] PAP:

[0455] Role: The PAP triggers the activation of the policy. This involves transitioning the policy from a stored state to an active state where it can influence network behavior.

[0456] Action: The PAP may also notify the PDP and PEP that the policy is now active and ready for enforcement.

[0457] PDP:

[0458] Role: The PDP evaluates the policy’s conditions in real-time and decides how the policy should be applied. It ensures that the policy’s rules are followed according to the current network state.

[0459] Action: The PDP may adjust the policy’s application based on dynamic network conditions, ensuring that the policy’s objectives are met without disrupting other operations.

[0460] PEP:

[0461] Role: The PEP enforces the policy as decided by the PDP. It applies the specific actions defined in the policy to the relevant network elements.

[0462] Action: The PEP manages traffic, allocates resources, or performs other actions as dictated by the policy.

[0463] Use Case Example:

[0464] Scenario: The video traffic prioritization policy created earlier needs to be activated.

[0465] PAP: The operator activates the policy at 5:50 PM in preparation for the peak hours.

[0466] PDP: The PDP assesses the current network load and determines how best to apply the policy without causing issues for other traffic types.

[0467] PEP: The PEP begins enforcing the policy at 6 PM, ensuring video traffic is prioritized over other types of traffic.

[0468] 2.1.2.3 Policy Update

[0469] Roles:

[0470] PAP:

[0471] Role: The PAP handles updates to the policy. This may involve modifying the policy’s conditions, actions, or scope to adapt to new requirements or network changes.

[0472] Action: The PAP updates the policy and ensures that the changes are communicated to the PDP and PEP.

[0473] PDP:

[0474] Role: The PDP reviews the updated policy and re-evaluates how it should be applied. It ensures that the updated policy remains consistent with other active policies.

[0475] Action: The PDP may adjust its decision-making logic to accommodate the changes in the policy.

[0476] PEP:

[0477] Role: The PEP enforces the updated policy. If the changes involve different actions or conditions, the PEP adjusts its enforcement accordingly.

[0478] Action: The PEP may need to modify its behavior in real-time to align with the updated policy.

[0479] Use Case Example:

[0480] Scenario: The operator decides to extend the video traffic prioritization policy to also include streaming audio traffic.

[0481] PAP: The operator updates the policy via the PAP to include audio traffic, ensuring both video and audio traffic are prioritized during peak hours.

[0482] PDP: The PDP checks for any potential conflicts with this change and updates its decision-making process to include audio traffic in the prioritization.

[0483] PEP: The PEP enforces the updated policy, giving both video and audio traffic higher priority during the designated time.

[0484] 2.1.2.4 Policy Deactivation

[0485] Roles:

[0486] PAP:

[0487] Role: The PAP deactivates the policy, transitioning it from an active state back to an inactive state. This halts the enforcement of the policy’s rules.

[0488] Action: The PAP may also log the deactivation event for auditing purposes.

[0489] PDP:

[0490] Role: The PDP stops making decisions based on the deactivated policy. It may revert to other active policies or default behaviors.

[0491] Action: The PDP ensures that the deactivation does not disrupt ongoing network operations.

[0492] PEP:

[0493] Role: The PEP stops enforcing the policy. It may revert network elements to their previous state before the policy was activated.

[0494] Action: The PEP ceases any actions that were specific to the deactivated policy, ensuring a smooth transition back to normal operations.

[0495] Use Case Example:

[0496] Scenario: The operator decides to deactivate the video and audio traffic prioritization policy after peak hours.

[0497] PAP: The policy is deactivated at 10:05 PM by the operator using the PAP.

[0498] PDP: The PDP stops considering the prioritization policy in its decision-making, reverting to standard traffic management policies.

[0499] PEP: The PEP returns to normal operation, treating all traffic types equally after the policy is deactivated.

[0500] 2.1.2.5 Policy Deletion

[0501] Roles:

[0502] PAP:

[0503] Role: The PAP handles the deletion of the policy when it is no longer needed. This removes the policy from the system entirely.

[0504] Action: The PAP ensures that the policy is fully removed and that no remnants of it remain in the system.

[0505] PDP:

[0506] Role: The PDP acknowledges the deletion and ensures that it no longer considers the deleted policy in any of its decision-making processes.

[0507] Action: The PDP may update its logic or records to reflect the removal of the policy.

[0508] PEP:

[0509] Role: The PEP no longer enforces the policy and removes any configurations or actions that were associated with it.

[0510] Action: The PEP ensures that the network elements are no longer influenced by the deleted policy.

[0511] Use Case Example:

[0512] Scenario: The operator decides that the video and audio traffic prioritization policy is no longer needed in the future.

[0513] PAP: The operator deletes the policy via the PAP, removing it from the system.

[0514] PDP: The PDP updates its records to ensure the policy is no longer part of its decision-making framework.

[0515] PEP: The PEP clears any remaining configurations related to the policy and returns to normal operations.

[0516] 2.1.2.6 Policy / Policy type information Query

[0517] The process of querying policies and policy types involves interactions between the PMI consumers (both internal and external) and the components of the policy management system, namely the Policy Administration Point (PAP), Policy Decision Point (PDP), and Policy Enforcement Point (PEP).

[0518] This process allows consumers to retrieve a list of policies or policy types and to obtain detailed information about specific policy types, including decision logic and enforcement actions.

[0519] Querying Policies and Policy Types:

[0520] Internal and External PMI Consumers:

[0521] Internal PMI Consumer (such as internal network management applications) and External PMI Consumer (such as third-party systems) can request details about available policies or policy types.

[0522] PAP (Policy Administration Point):

[0523] The PAP retrieves the list of policies or policy types available within the system.

[0524] It processes the queries from both internal and external consumers, providing them with the requested list and policy details.

[0525] Detailed Information Retrieval:

[0526] PAP:

[0527] Once a specific policy type is queried, the PAP requests additional details about the decision logic and enforcement actions.

[0528] PDP (Policy Decision Point):

[0529] The PDP returns the decision-making logic associated with the queried policy type.This includes how policies are applied in real-time, decision criteria, and conditions.

[0530] PEP (Policy Enforcement Point):

[0531] The PEP provides enforcement logs that show how the policy type was applied in the network, including details on resource allocation, traffic management, and any specific actions executed based on the policy.

[0532] Use Case Example:

[0533] Scenario: An internal network operator (Internal PMI Consumer) wants to retrieve the available policy types and details on how a specific Al policy was enforced during peak traffic hours.

[0534] 1. Internal PMI Consumer queries the PAP for available policies and their types.

[0535] 2. PAP retrieves the list of policies and policy types and provides the information to the Internal PMI Consumer.

[0536] 3. The PAP then requests further details from the PDP regarding the decision logic of the specific Al policy.

[0537] 4. The PDP returns the decision-making process, including how the policy is applied to prioritize traffic.

[0538] 5. The PAP requests enforcement logs from the PEP to gather data on how the policy was enforced in the network.

[0539] 6. PEP provides detailed logs showing how traffic was prioritized based on the policy.

[0540] 7. The PAP consolidates the information and returns it to the Internal PMIConsumer.

[0541] Scenario

[0542] The operator wants to review how the video and audio traffic prioritization policy was applied during peak hours.

[0543] PAP: The operator queries the PAP for details on the policy, including its activation times and conditions.

[0544] PDP: The PDP provides a log of decisions made under the policy, detailing how it managed network traffic during the policy's active hours.

[0545] PEP: The PEP provides enforcement logs, showing how traffic was prioritized and the impact on network performance.

[0546] 2.1.2.7 Policy Status information Query

[0547] Policy Status Querying Flow

[0548] The process of querying the status of a policy involves interactions between the PMI consumers (both internal and external) and the Policy Administration Point (PAP), Policy Decision Point (PDP), and Policy Enforcement Point (PEP).

[0549] This allows consumers to check the current status of a specific policy, including decision logic, enforcement status, and any actions that have been taken based on the policy.

[0550] Querying Policy Status:

[0551] Internal and External PMI Consumers:

[0552] Internal PMI Consumer (e.g., internal network management applications) and External PMI Consumer (e.g., third-party systems) request the current status of a specific policy, including whether it is active, suspended, or deactivated.

[0553] PAP (Policy Administration Point):

[0554] The PAP is responsible for retrieving the policy's status and general information.

[0555] It processes requests from both internal and external consumers, forwarding requests to the PDP and PEP for more detailed information.

[0556] Detailed Information Retrieval:

[0557] PDP (Policy Decision Point):

[0558] The PDP provides information on the decision logic used for the policy. This includes logs of policy decisions and actions triggered by the policy.

[0559] PEP (Policy Enforcement Point):

[0560] The PEP supplies enforcement logs, showing how the policy was applied in the network, including any actions taken and the current enforcement status.

[0561] Use Case Example:

[0562] Scenario: An external PMI consumer (External PMI Consumer) queries the status of a traffic management policy to understand whether the policy is currently active and how it has been enforced in the past week.

[0563] 1. External PMI Consumer queries the PAP for the status of the traffic management policy.

[0564] 2. PAP retrieves the policy's current status (active, inactive, suspended).

[0565] 3. PAP requests logs from the PDP regarding the decision logic behind the policy's actions.

[0566] 4. The PDP provides decision logs showing the conditions and actions triggered by the policy.

[0567] 5. The PAP requests enforcement logs from the PEP.

[0568] 6. PEP returns the logs, showing how the policy was applied and its impact on network performance.

[0569] 7. The PAP consolidates all the information and provides it to the External PMIConsumer.

[0570] 2.1.4 States and state transitions of policy management

[0571] 2.1.4.1 States and State Transitions of Policy Management

[0572] Policy management typically involves several states that define the lifecycle of a policy, as well as state transitions that occur as the policy moves from one state to another based on network conditions or administrative actions.

[0573] States of Policy Management:

[0574] 1. Draft (Initial)

[0575] Description: The policy is in the process of being created or modified but has not yet been activated. It’s still under construction or review.

[0576] Actions Available: Policy can be modified or deleted.

[0577] Typical Scenario: A network operator defines a new policy but does not yet activate it.

[0578] 2. Inactive

[0579] Description: The policy exists in the system but is not currently active or enforced. It may have been deactivated or never activated.

[0580] Actions Available: The policy can be activated, updated, or deleted.

[0581] Typical Scenario: A policy designed for traffic prioritization is defined but not enforced until needed.

[0582] 3. Active

[0583] Description: The policy is currently in effect and being enforced by the Policy Enforcement Point (PEP). Its conditions are monitored, and actions are executed based on the policy rules.

[0584] Actions Available: The policy can be updated, suspended, or deactivated.

[0585] Typical Scenario: A bandwidth allocation policy is active during peak hours, dynamically adjusting resources based on network conditions.

[0586] 4. Suspended

[0587] Description: The policy is temporarily halted but not deleted. It can be reactivated or deactivated. No actions are taken based on the policy during this state.

[0588] Actions Available: The policy can be reactivated or deactivated.

[0589] Typical Scenario: A policy is suspended because it conflicts with another active policy, and further evaluation is needed before reactivation.

[0590] 5. Deactivated

[0591] Description: The policy is no longer active and is not being enforced. However, it still exists in the system and can be reactivated or deleted.

[0592] Actions Available: The policy can be reactivated or deleted.

[0593] Typical Scenario: A network policy for a particular event is no longer needed and is deactivated.

[0594] 6. Deleted

[0595] Description: The policy is permanently removed from the system and can no longer be enforced or reactivated.

[0596] Actions Available: None (the policy is fully removed).

[0597] Typical Scenario: A legacy policy no longer applicable to the current network environment is deleted to free up system resources.

[0598] 2.1.4.2 State Transitions of Policy Management:

[0599] The state transitions describe how a policy moves between different states in response to actions taken by PMI consumers (e.g., rApp, operator) or system triggers.

[0600] 1. Draft to Inactive (Creation)

[0601] Trigger: The policy is created and saved in the system but not yet activated.

[0602] Example: An operator defines a traffic prioritization policy but chooses not to activate it immediately.

[0603] 2. Inactive to Active (Activation)

[0604] Trigger: The policy is activated by the PMI consumer or automatically based on conditions.

[0605] Example: The operator activates the traffic prioritization policy during peak hours.

[0606] 3. Active to Suspended (Conflict or Temporary Hold)

[0607] Trigger: The policy is suspended either due to conflict with another policy or an administrative decision.

[0608] Example: The traffic prioritization policy is suspended to make way for an emergency resource allocation policy.

[0609] 4. Suspended to Active (Reactivation)

[0610] Trigger: The policy is reactivated after being temporarily suspended.

[0611] Example: The operator reactivates the traffic prioritization policy after resolving the conflict.

[0612] 5. Active to Deactivated (Deactivation)

[0613] Trigger: The policy is no longer needed and is deactivated.

[0614] Example: The peak hours have ended, and the traffic prioritization policy is deactivated.

[0615] 6. Suspended to Deactivated (Permanent Hold)

[0616] Trigger: The policy is no longer needed and is deactivated from a suspended state.

[0617] Example: A policy that was previously suspended is now permanently deactivated.

[0618] 7. Deactivated to Active (Reactivation)

[0619] Trigger: The policy is reactivated from a deactivated state, either manually or based on system triggers.

[0620] Example: The traffic prioritization policy is reactivated for another peak hour.

[0621] 8. Inactive / Deactivated to Deleted (Permanent Removal)

[0622] Trigger: The policy is deleted from the system, permanently removing all configurations.

[0623] Example: A legacy policy that is no longer relevant is deleted from the system.

[0624] 9. Active to Updated (Policy Update):

[0625] Trigger: The policy is updated while active. The policy rules and conditions are modified, and the updated policy continues being enforced.

[0626] Example: An operator adjusts the bandwidth allocation rules within an active traffic prioritization policy to better handle peak traffic conditions.

[0627] 3. P2 Interface procedure and services

[0628] The operations provided through this interface are:

[0629] 3.1 Register Policy Types (P2 Interface procedure PDP ^PAP)

[0630] A PMI SMOS consumer such as NFO / FOCOM, RAN 0AM, Al Policy Function etc. can request to register the policy types it supports with Policy Management and Information (PMI), Some examples of policy types can be resource management, LCM such as healing and scaling, monitoring etc.

[0631] PMI SMOs Consumer can register policy types in below format,

[0632] TOSCA

[0633] JSON

[0634] XML

[0635] 3.2 Deregister Policy Types (P2 Interface procedure PDP ^PAP)

[0636] A PMI consumer acting as PDP can use this procedure to deregister a data type that it has previously registered for which it is no longer able to produce policy types.

[0637] 3.3 Discover / Query Policy Types (Pl Interface procedure PAP — > PMIConsumer)

[0638] This set of procedures enables a PMI Consumer to retrieve information on the registered policy types.

[0639] Discovery of a policy type does not imply availability of policy instances of that policy type. It is just an indication that PMI Consumers can request or subscribe to policy type.

[0640] 3.4 Create Policy

[0641] The PMI Consumer uses the Create policy procedure to create a policy. PMI consumer shall use policy types to create polices. Policy type Ids shall be communicated in policy creations.

[0642] 3.5 Delete Policy

[0643] The PMI Consumer uses the delete policy procedure to delete a policy.

[0644] 3.6 Query Policy

[0645] The Al-P Consumer uses the Query policy operation to read an Al policy. The Query policy operation is used in the querying single policy, multiple policies, all policies.

[0646] 3.7 Activate Policy

[0647] Since Stage 1 does not capture policy activation, need to figure out need of activation of policies. Use case related to it need to brainstorm.

[0648] 3.8 Deactivate Policy

[0649] Since Stage 1 does not capture policy deactivation, need to figure out need of deactivation of policies. Use case related to it need to brainstorm.

[0650] 3.9 Subscribe

[0651] A PMI SMOS consumer can subscribe for notifications of events such as policy changes related to policies and policy types

[0652] 3.10 Query Subscription Information

[0653] A PMI SMOS consumer can query information related to subscription for notifications of events such as policy changes related to policies and policy types.

[0654] 3.11 Terminate Subscription

[0655] A PMI SMOS consumer can terminate subscription for notifications of events such as policy changes related to policies and policy types.

[0656] 3.12 Notify

[0657] The PMI Producer uses the Notify policy status change operation to update the PMI Consumer about changes of the status of a policy and policy types.

Claims

What is claimed is:

1. An apparatus configured to: obtain, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receive, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identify the policy type that is supported by the target network function based on the obtained policy type registration information; provide, to the user, the identified policy type; receive, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request includes the policy; and in response to receiving the policy registration request, register the policy and transmit the policy to the target network function.

2. The apparatus according to claim 1, wherein the policy is implemented via an 01 interface, an 02 interface, or an M-Plane.

3. The apparatus according to claim 1, wherein the apparatus is further configured to:receive, from at least one network function in the plurality of network functions, a policy type update request to update a stored policy type registration information of the at least one network function, wherein the policy type update request includes policy type update information specifying at least one of: a policy type newly supported by the at least one network function and a policy type that is no longer supported by the at least one network function; and in response to receiving the policy type update request, update the stored policy type registration information of the at least one network function based on the policy type update information.

4. The apparatus according to claim 1, wherein the apparatus is further configured to: receive, from the user, a policy identification request to identify a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy identification request, identify the policy that is being implemented via the at least one network function.

5. The apparatus according to claim 1, wherein the apparatus is further configured to: receive, from the user, a policy update request to update a policy that is being implemented via at least one network function in the plurality of network functions, wherein the policy update request includes update information; andin response to receiving the policy update request, update the policy that is being implemented via the at least one network function based on the received update information.

6. The apparatus according to claim 1, wherein the apparatus is further configured to: receive, from the user, a policy deregistration request to deregister a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy deregistration request, deregister the policy that is being implemented via the at least one network function.

7. The apparatus according to claim 1, wherein the apparatus is further configured to: receive, from the user, a policy status request to identify a status of a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy status request, identify the status of the policy that is being implemented via the at least one network function.

8. The apparatus according to claim 1, wherein the apparatus is further configured to: receive, from the user, a notification request to receive a notification regarding a change related to a policy type and a policy associated with at least one network function in the plurality of network functions; andin response to receiving the notification request and in response to detecting the change, transmit the notification to the user.

9. The apparatus according to claim 1, wherein the apparatus is further configured to: receive, from the user, a policy generation request to generate a policy based on a policy intent, wherein the policy generation request includes the policy intent; and in response to receiving the policy generation request, generate the policy based on the policy intent.

10. A method comprising: obtaining, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions; receiving, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identifying the policy type that is supported by the target network function based on the obtained policy type registration information; providing, to the user, the identified policy type; receiving, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request includes the policy; andin response to receiving the policy registration request, registering the policy and transmitting the policy to the target network function.

11. The method according to claim 10, wherein the policy is implemented via an 01 interface, an 02 interface, or an M-Plane.

12. The method according to claim 10, wherein the method further comprises: receiving, from at least one network function in the plurality of network functions, a policy type update request to update a stored policy type registration information of the at least one network function, wherein the policy type update request includes policy type update information specifying at least one of: a policy type newly supported by the at least one network function and a policy type that is no longer supported by the at least one network function; and in response to receiving the policy type update request, updating the stored policy type registration information of the at least one network function based on the policy type update information.

13. The method according to claim 10, wherein the method further comprises: receiving, from the user, a policy identification request to identify a policy that is being implemented via at least one network function in the plurality of network functions; andin response to receiving the policy identification request, identifying the policy that is being implemented via the at least one network function.

14. The method according to claim 10, wherein the method further comprises: receiving, from the user, a policy update request to update a policy that is being implemented via at least one network function in the plurality of network functions, wherein the policy update request includes update information; and in response to receiving the policy update request, updating the policy that is being implemented via the at least one network function based on the received update information.

15. The method according to claim 10, wherein the method further comprises: receiving, from the user, a policy deregistration request to deregister a policy that is being implemented via at least one network function in the plurality of network functions; and in response to receiving the policy deregistration request, deregistering the policy that is being implemented via the at least one network function.

16. The method according to claim 10, wherein the method further comprises: receiving, from the user, a policy status request to identify a status of a policy that is being implemented via at least one network function in the plurality of network functions; andin response to receiving the policy status request, identifying the status of the policy that is being implemented via the at least one network function.

17. The method according to claim 10, wherein the method further comprises: receiving, from the user, a notification request to receive a notification regarding a change related to a policy type and a policy associated with at least one network function in the plurality of network functions; and in response to receiving the notification request and in response to detecting the change, transmitting the notification to the user.

18. The method according to claim 10, wherein the method further comprises: receiving, from the user, a policy generation request to generate a policy based on a policy intent, wherein the policy generation request includes the policy intent; and in response to receiving the policy generation request, generating the policy based on the policy intent.

19. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: obtaining, from a plurality of network functions in a network, policy type registration information specifying at least one policy type that is supported by a respective one of the plurality of network functions;receiving, from a user, a policy type identification request to identify a policy type that is supported by a target network function in the plurality of network functions; in response to receiving the policy type identification request, identifying the policy type that is supported by the target network function based on the obtained policy type registration information; providing, to the user, the identified policy type; receiving, from the user, a policy registration request to register a policy to be implemented via the target network function, wherein the policy registration request includes the policy; and in response to receiving the policy registration request, registering the policy and transmitting the policy to the target network function.

20. The non-transitory computer-readable recording medium according to claim 19, wherein the policy is implemented via an 01 interface, an 02 interface, or an M-Plane.

Images