A1 policy management

Abstract

The present disclosure relates to a method of a policy administration node (110) of communicating with a policy enforcement node (130) in a communications network (100). In an aspect, a method of a policy administration node (110) of communicating with a policy enforcement node (130a) in a communications network (100) is provided, the policy administration node (110) providing the policy enforcement node (130a) with policies based on which radio access network, RAN, performance objectives are defined. The method comprises providing (S101) the policy enforcement node (130a) with a policy to be enforced in the RAN for attaining the RAN performance objectives, wherein the policy enforcement node (130a) is configured to enforce (S102) the provided policy for policy scope target devices (201-203) identified to be within the policy enforcement area of the policy enforcement node (130a) and receiving (S104), from the policy enforcement node (130a) over an interface established directly between the policy administration node (110) and the policy enforcement node (130a), an indication that at least one policy scope target device (203) moves away from said policy enforcement area. The method further comprises updating (S105) the policy to take into account the received indication that said at least one policy scope target device (203) moves away from the policy enforcement area of the policy enforcement node (130a) and providing (S106) the policy enforcement node (130a) with the updated policy for enforcement of the updated policy to the policy scope target devices (201, 202) identified to be within the policy enforcement area of the policy enforcement node (130a).

Description

Al POLICY MANAGEMENTTECHNICAL FIELD

[0001] The present disclosure relates to a method of a policy administration node of communicating with a policy enforcement node in a communications network, and a policy administration node performing the method. The present disclosure further relates to a method of a policy enforcement node of communicating with a policy administration node in a communications network, and a policy enforcement node performing the method.BACKGROUND

[0002] The Open Radio Access Network (O-RAN) Alliance promotes a disaggregated, virtualized, and open radio access network augmented by softwarebased control components for RAN performance optimization, enabled by open and standardized multi-vendor interfaces.

[0003] Figure 1 depicts the main components of an O-RAN architecture where control applications (referred to as rApps 111 and xApps 131) execute on Non-Real Time RAN Intelligent Controllers (RICs) 110 and Near-Real Time RICs 130 respectively to proactively steer the RAN performance towards declared non- and near realtime RAN performance objectives. Such objectives maybe provided to rApps 111 in the form of standardized intents to a service management and orchestration (SMO) framework 113 that are delivered to the Non-RT RIC 111 and rApps 111 being hosted by the SMO framework 113.

[0004] In the O-RAN architecture 100, Al interface is specified as an open, multivendor interface between the Non-RT RIC 110 and the Near-RT RIC 130. The Al interface enables the Non-RT RIC 110 to perform policy-based guidance of radio resource utilization and allows for feedback mechanisms to monitor the status of the enforced Al policies. Policies are expressed in a standardized way; hence the same policy can be received, validated and enforced by different Near-RT RICs 130 (i.e., multi-vendor interoperability of Al policies is expected). The Near-RT RIC 130 can be connected to a number of E2 nodes 120. The geographical area covered by E2 nodes 120 signifies the policy enforcement scope of a Near-RT RIC 130 connected to those E2 nodes 120.

[0005] Ai policies can be specific to individual wireless communication devices (e.g. smart phones, tablets, connected vehicles, etc.), a group of wireless communication devices, RAN slices or similar identified by a policy scope identifier with appropriate policy objectives and resources. The Non-RT RIC no can estimate the impact of its created Al policies by monitoring the RAN performance data via 01 interface connecting the SMO framework 113 (and thus the Non-RT RIC 110) and the E2 node 120.

[0006] However, this is an inefficient structure for creating a feedback loop via which the Non-RT RIC no is provided with information on how the policies provided by the Non-RT RIC no to the Near-RT RIC 130 practically are enforced among the E2 nodes 120.SUMMARY

[0007] One objective is to solve, or at least mitigate, the above mentioned problem and thus to provide an improved method of a policy administration node of communicating with a policy enforcement node in a communications network.

[0008] This objective is attained in a first aspect by a method of a policy administration node of communicating with a policy enforcement node in a communications network, the policy administration node providing the policy enforcement node with policies based on which radio access network (RAN) performance objectives are defined. The method comprises providing the policy enforcement node with a policy to be enforced in the RAN for attaining the RAN performance objectives, wherein the policy enforcement node is configured to enforce the provided policy for policy scope target devices identified to be within the policy enforcement area of the policy enforcement node and receiving, from the policy enforcement node over an interface established directly between the policy administration node and the policy enforcement node, an indication that at least one policy scope target device moves away from said policy enforcement area. The method further comprises updating the policy to take into account the received indication that said at least one policy scope target device moves away from the policy enforcement area of the policy enforcement node, and providing the policy enforcement node with the updated policy for enforcement of the updated policy tothe policy scope target devices identified to be within the policy enforcement area of the policy enforcement node.

[0009] This objective is attained in a second aspect by a policy administration node configured to communicate with a policy enforcement node in a communications network, the policy administration node providing the policy enforcement node with policies based on which RAN performance objectives are defined, the policy administration node comprising a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the policy administration node is operative to provide the policy enforcement node with a policy to be enforced in the RAN for attaining the RAN performance objectives, wherein the policy enforcement node is configured to enforce the provided policy for policy scope target devices identified to be within the policy enforcement area of the policy enforcement node and receive, from the policy enforcement node over an interface established directly between the policy administration node and the policy enforcement node, an indication that at least one policy scope target device moves away from said policy enforcement area. The policy administration node is further operative to update the policy to take into account the received indication that said at least one policy scope target device moves away from the policy enforcement area of the policy enforcement node and to provide the policy enforcement node with the updated policy for enforcement of the updated policy to the policy scope target devices identified to be within the policy enforcement area of the policy enforcement node.

[0010] This objective is attained in a third aspect by a method of a policy enforcement node of communicating with a policy administration node in a communications network, the policy enforcement node receiving from the policy administration node policies based on which RAN performance objectives are defined, comprising receiving, from the policy administration node, a policy to be enforced for policy scope target devices identified to be within the policy enforcement area of the policy enforcement node in the RAN for attaining the RAN performance objectives and tracking said policy scope target devices. The method further comprises providing, to the policy administration node over an interface established directly between the policy enforcement node and the policy administration node, an indication that at least one policy scope target device moves away from said policyenforcement area and receiving, from the policy administration node, an updated policy taking into account the indication that said at least one policy scope target device moves away from the policy enforcement area of the policy enforcement node, for enforcement to the policy scope target devices identified to be within the policy enforcement area of the policy enforcement node.

[0011] This objective is attained in a fourth aspect by a policy enforcement node configured to communicate with a policy administration node in a communications network, the policy enforcement node receiving from the policy administration node policies based on which RAN performance objectives are defined, the policy enforcement node comprising a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the policy enforcement node is operative to receive, from the policy administration node, a policy to be enforced for policy scope target devices identified to be within the policy enforcement area of the policy enforcement node in the RAN for attaining the RAN performance objectives, track said policy scope target devices, provide, to the policy administration node over an interface established directly between the policy enforcement node and the policy administration node, an indication that at least one policy scope target device moves away from said policy enforcement area and to receive, from the policy administration node, an updated policy taking into account the indication that said at least one policy scope target device moves away from the policy enforcement area of the policy enforcement node, for enforcement to the policy scope target devices identified to be within the policy enforcement area of the policy enforcement node.

[0012] Advantageously, embodiments proposed herein enables a policy administration node, such as a Non-RT RIC (and rApps executing thereon), to react in a timely manner to movement of Al policy scope target devices in the RAN so that an appropriate Al policy is enforced on source and target policy enforcement nodes, such as Near-RT RICs. For instance, policy enforcement responsibility maybe handed over to an target Near-RT RIC while being updated on the source Near-RT RIC, and the Non-RT RIC may thus create new / updated Al policies on the source and target Near-RT RICs. The Al policy related feedback from the source Near-RT RIC can be used as trigger the Non-RT RIC to perform Al policy management actions in a proactive manner.

[0013] This is further advantageous since the risk is reduced for assigning Al polices that cannot be enforced by xApps / Near-RT RICs since, e.g., the policy scope targets do not exist anymore in the Near-RT RIC’s policy enforcement area (i.e. the policy scope target devices have left a Near-RT RIC’s policy enforcement area), the policy objectives are unrealistic for the current RAN status, etc.

[0014] In an embodiment, the updated policy is configured to no longer indicate an action that was present in the previously provided policy to be performed for said at least one policy scope target device moving away from the policy enforcement area, or being configured to indicate that said action is inactivated as long as the said at least one policy scope target device remains outside of the policy enforcement area.

[0015] In an embodiment, the providing of the policy enforcement node with a policy to be enforced further comprises providing a further policy enforcement node with a policy to be enforced, and the method further comprises updating, if said at least one policy scope target device is indicated to move into a policy enforcement area of said further policy enforcement node, the policy provided to said further policy enforcement node to take into account the received indication that said at least one policy scope target device moves into the policy enforcement area of said further policy enforcement node and providing said further policy enforcement node with the updated policy or a newly created policy for enforcement of the updated policy or the newly created policy to the policy scope target devices identified to be within the policy enforcement area of said further policy enforcement node.

[0016] In an embodiment, the updated or newly created policy provided to said further policy enforcement node is configured to further indicate one or more actions to be performed for said at least one policy scope target device moving into the policy enforcement area of said further policy enforcement node.

[0017] In an embodiment, the interface established directly between the policy administration node and the policy enforcement node is an Al interface or an 01 interface.

[0018] In an embodiment, an xApp executing on a Near-RT RIC associated with an action of an updated policy for a policy scope target device moving away from the policy enforcement area of said Near-RT RIC is either removed from or inactivated at said Near-RT RIC, while for an action of an updated or newly created policy for apolicy scope target device moving into the policy enforcement area of a Near-RT RIC, an xApp to be associated with the action is deployed on said Near-RT RIC.

[0019]

[0020] In an embodiment, the method further comprises verifying capability of the near Near-RT RIC to whose policy enforcement area the policy scope target device moves into, and providing said near Near-RT RIC with one or more xApps required for enforcing the updated or newly created policy.

[0021] In an embodiment, the tracking is based on acquiring handover information from the RAN indicating that said at least one policy scope target device moves away from said policy enforcement area, or based on acquiring policy scope target device mobility information from the RAN from which mobility information it is determined that said at least one policy scope target device moves away from said policy enforcement area.

[0022] In a fifth aspect, a computer program is provided comprising computerexecutable instructions for causing a policy administration node to perform steps recited in the method of the first aspect when the computer-executable instructions are executed on a processing unit included in the policy administration node.

[0023] In a sixth aspect, a computer program product is provided comprising a computer readable medium, the computer readable medium having the computer program according to the fifth aspect embodied thereon.

[0024] In a seventh aspect, a computer program is provided comprising computer-executable instructions for causing a policy enforcement node to perform steps recited in the method of the third aspect when the computer-executable instructions are executed on a processing unit included in the policy enforcement node.

[0025] In an eighth aspect, a computer program product is provided comprising a computer readable medium, the computer readable medium having the computer program according to the seventh aspect embodied thereon.

[0026] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a / an / the element, apparatus, component, means, step, etc.” are to be interpreted openly as referring to at least one instance of the element,apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, in which:

[0028] Figure 1 schematically illustrates a prior art O-RAN architecture in which embodiments may be implemented;

[0029] Figure 2 illustrates a handover scenario resulting in issues resolved by embodiments;

[0030] Figure 3 shows a signalling diagram illustrating a method of an embodiment;

[0031] Figure 4 shows a signalling diagram illustrating a method of a further embodiment;

[0032] Figure 5 shows a signalling diagram illustrating a method of an embodiment;

[0033] Figure 6 shows a signalling diagram illustrating a method of an embodiment;

[0034] Figure 7 illustrates a policy administration node according to an embodiment; and

[0035] Figure 8 illustrates a policy enforcement node according to an embodiment.DETAILED DESCRIPTION

[0036] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown.

[0037] These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully conveythe scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0038] Figure 1 has previously been briefly described and shows the main components of an O-RAN architecture / communi cations network 100.

[0039] Shown in Figure 1 is a service management and orchestration (SMO) framework 113, hosting a Non-RT RIC 110 and numerous rApps 111, which SMO framework 113 communicates with E2 nodes 120, for example radio base stations referred to as gNBs, via an 01 interface and provides control signals to Near-RT RICs 130 via Ai interface for instance in the form of policy-based guidance based on which the Near-RT RICs 130 controls the E2 nodes 120 of the RAN.

[0040] Applications for the Near-RT RIC 130 (also referred to as xApps 131) include handover decisions, dual connectivity, predicting quality of experience (QoE) of a wireless communication device such as a smart phone, tablet, connected vehicle, etc., while example applications for the Non-RT RIC 110 (also referred to as rApps 111) include orchestration, programmability and optimization. To execute control, an rApp 111 of the Non-RT-RIC 110 sends a recommendation for action to an xApp 131 of the Near-RT-RIC 131, e.g., updating operational parameters, changing an execution policy, deploying an updated policy, etc., over the Al interface which in its turn will be executed by the Near-Rt RIC 130 towards the E2 nodes 120 via the E2 interface. As shown, the Non-RT RIC 110 comprises rApps 111 communicating with a Non-RT RIC framework 112 over an Ri interface, while the Near-RT RIC 130 comprises xApps 131 communicating with a Near-RT RIC framework 132 via Near-RT RIC application programming interfaces (APIs).

[0041] Also illustrated in Figure 1 are functional entities included in the E2 nodes 120, the E2 nodes for instance being implemented in the form of gNBs. The above- mentioned wireless communication devices are commonly referred to as User Equipment (UE).

[0042] A gNB 120 comprises a central unit (CU) being split into a CU-CP 121 (“control plane”) and a CU-UP 122 (“user plane”) being interconnected over an El interface.

[0043] The CU-CP 121 connects to the SMO framework 113 via interface 01 and to the Near-RT RIC 130 via interface E2. The CU-CP 121 further connects to adistributed unit 123 (DU) via interface Fi-C which in its turn connects to a radio unit 124 (RU) over an open fronthaul (OFH) interface for communicating with one or more UEs (not shown in Figure 1) via the RU 124 communicating wirelessly with the UEs.

[0044] The CU-UP 122 also connects to the SMO framework 113 via interface 01 and to the Near-RT RIC 130 via interface E2. The CU-UP 122 also further connects to the DU 123 via interface Fi-U which in its turn connects to the RU 124 over the OFH interface for wirelessly communicating with the UEs via the RU 124.

[0045] Moreover, the DU 123 connects to the SMO framework 113 via interface 01 and to the Near-RT RIC 130 via interface E2.

[0046] Further shown is the SMO framework 113 connecting via 02 interface to a cloud computing platform 125 (O-Cloud) hosting a set of hardware and software components providing cloud computing capabilities to execute the RAN network functions.

[0047] As mentioned, in the 0-RAN architecture 100, the Al interface is specified as an open, multi-vendor interface between the Non-RT RIC 110 and the Near-RT RIC 130. The Al interface enables the Non-RT RIC 110 to perform policy-based guidance of radio resource utilization in the RAN served by the E2 nodes 120 and allows the Non-RT RIC 110 to monitor whether or not a provided Al policy is enforced by the Near-Rt RCI 130. Policies are expressed in a standardized way; hence the same policy can be read and enforced by different Near-RT RICs 130 (i.e., multivendor interoperability of Al policies is expected). The Near-RT RIC 130 can be connected to a number of E2 nodes 120. The geographical area covered by E2 nodes 120 signifies the policy enforcement scope of a Near-RT RIC 130 connected to those E2 nodes 120, which area will be referred to in the following as the policy enforcement area of Near- RT RIC 130.

[0048] Al policies can be specific to individual UEs, a group of UEs, RAN slices or similar identified by a policy scope identifier in Al policies, which devices in the following will be referred to as Al policy scope target devices with appropriate policy objectives and resources. The Non-RT RIC 110 can estimate the impact of its created Al policies by monitoring the RAN performance based on information provided by the E2 node 120 via the 01 interface.

[0049] An example of Al policy-based optimizations is that when the Non-RT RIC no understands that the available resources in a certain area are not enough to fulfil a service-level agreement (SLA) for all users, the Non-RT RIC no can then decide to temporarily change quality of service (QoS) targets for some users (dynamic group of users) in the area. 0-RAN specifications provides standardized Al policies covering use cases such as load-balancing, QoS, traffic steering, etc.

[0050] Lifecycle management (LCM) of Al policies is described in 0-RAN specifications. The Non-RT RIC 110 is responsible for creating an Al policy and once the policy is accepted by the Near-RT RIC 130, the Al policy is considered as enforced in the Near-RT RIC 130 from the perspective of the Non-RT RIC no. Al policies enforced in the Near-RT RIC 130 can be updated by the Non-RT RIC no. In each state, a policy and its status can be queried. A policy ends its lifecycle when it is deleted by the Non-RT RIC 110.

[0051] The Near-RT RIC 130 can host multiple xApps 131 developed by different vendors. When xApps 131 register with the Near-RT RIC framework 132 using the Near-RT RIC APIs, the xApps 131 declare which Al policy types they can enforce using E2 interface services and E2 service models. These can be 0-RAN specified Al policies or proprietary Al policies.

[0052] For Al policy enforcement, the E2 interface enables the xApps 131 to control the RAN functionality and performance. E2 services enable upstream data monitoring to the xApps 131 and downstream control and policy enforcement in the E2 nodes 120. Using the E2 interface-related services in the Near-RT RIC framework 132, the xApps 131 can collect data for analysis, use this data and even artificial intelligence (Al) and / or machine-learning (ML) algorithms to generate proposals for RAN control and optimization and exercise those proposals via direct control over the internal functionality of the E2 nodes 120. The xApps 131 may suspend, resume, and / or override the default control processes in an E2 node 120 based on standardized E2 service models (E2SMs). The 0-RAN E2SM specification provides the list of E2SMS that may be available to an xApp 131 in the Near-RT RIC 130. An xApp 131 can enforce an Al policy only within the Near-RT RIC’s policy enforcement area using available E2SMs in the Near-RT RIC 130.

[0053] There is a disconnect between rApps 111 executing on the Non-RT RIC 110 producing Al policies and xApps 131 executing on the Near-RT RIC 130 working toenforce those policies in the E2 nodes 120 using the E2 interface. The rApps 111 rely on observing the impact of its created Al policies by using the 01 interface to collect RAN performance data and acquire basic policy enforcement status information over Al interface, which currently only convey “enforced” or “not enforced” status information. An rApp 111 may compare the RAN performance before and after Al policy creation to analyze the impact of its created policies. As such, an rApp 111 considers an Al policy as enforced when the policy status is reported as enforced by the Near-RT RIC 130, i.e., rApps 111 are agnostic to the presence of xApps 131 in the Near-RT RIC 130. xApps 131 on the other hand, take the received Al policies as the provided optimization goals of the Non-RT RIC 110 and control the RAN functionality to steer it towards performance goals specified in the Al policy. xApps 131 work for enforcing Al policies but do not send policy related notifications directly via Al interface. The Near-RT RIC 130 on the other hand only sends Al policy status change notifications e.g., when policy status changes from enforced to not enforced.

[0054] This, in essence, creates two parallel control loop scenarios where the Non- RT RIC 110 observes the RAN via 01 and tries to impact the RAN performance via Al policies while the Near-RT RIC 130 observes and impacts the RAN via E2 interface while considering Al policies as optimization objectives only. These two control loops operate at different frequencies and therefore the functional isolation of these control loops can cause breaks in synchronization. This disconnect can then manifest in scenarios e.g., the Al policy being enforced is not suitable to the current RAN status, is dormant (unenforceable) because policy scope target devices has left Near-RT RIC’s enforcement area, or partially enforced.

[0055] Figure 2 illustrates a scenario where such situation arises.

[0056] As shown in Figure 2, a Non-RT RIC 110 provides two Near-RT RICs 130a, 130b with Al policies to be enforced in a respective E2 node 120a. 120b. In this example, first Near-RT RIC 130a enforces the Al policy in a first gNB 120a serving UEs 201-203, while second Near-RT RIC 130 enforces the Al policy in a second gNB 120b serving UEs 301-303. As is understood, this illustration is for exemplifying purpose only and in practice, the Non-RT RIC 101 may serve tens or even hundreds of Near-RT RICs 130a, 130b and each Near-RT RIC 130a, 130b may in its turn serve tens or hundreds of gNBs 120.

[0057] As in Figure 1, the Non-RT RIC no connects to the Near-RT RICs 130a, 130b via the Al and 01 interfaces (and to the respective gNB 120a, 120b via 01, which is not shown in Figure 2), while each Near-RT RIC 130a, 130b connects to the gNB 120a, 120b for which enforcement is to be undertaken via the E2 interface.

[0058] Assuming that the Non-RT RIC 110 provides the first Near-RT RIC 130a over the Al interface with a policy to be enforced in the first gNB 120a for serving the three UEs 201-203 while providing the second Near-RT RIC 130b over the Al interface with a policy to be enforced in the second gNB 120b for serving the three UEs 301-303. In other words, the three UEs 201-203 served by the first gNB 120a are policy enforcement target devices within the policy enforcement area of the first Near-RT RIC 130a, while the three UEs 301-303 served by the second gNB 120b are policy enforcement target devices within the policy enforcement area of the second Near-RT RIC 130b. The policy provided to the respective Near-RT RIC 130a, 130b may for instance stipulate that a certain QoS is to be provided to each set of UEs 201- 203 and 301-303. As is understood, the two policies to be enforced for the gNBs 120a, 120b are not necessarily identical, but may have different objectives for RAN control.

[0059] Further assuming that UE 203 moves away from the first gNB 120a in a direction towards the second gNB 120b (as indicated by the dotted arrow), which ultimately will result in a handover of the UE 203 from the first gNB 120a to the second, neighbouring gNB 120b.

[0060] Thus, due to mobility patterns, a UE 203 or group of UEs that are the target of an Al policy scope may move away from one Near-RT RIC’s policy enforcement area to another Near-RT RIC, in this case from the policy enforcement area of the first Near-RT RIC 130a to the policy enforcement area of the second Near- RT RIC 130b.

[0061] With the current assumption of the Non-RT RIC 110 (and the rApps 111 executing therein, not shown in Figure 2) relying on 01 interface monitoring instead of active policy specific feedback for evaluating Al policy impact, the Non-RT RIC 110 and its hosted rApps 111 may not be able to react with policy LCM actions in a timely manner to changes in the policy scope targets, in this example that the UE 203 leaves the policy enforcement area of the first Near-RT RIC 130a and moves into that of the second Near-RT RIC 130b.

[0062] AS is understood, if an Al policy scope targets a specific UE, UE group or RAN slice for enforcement in the RAN, the enforcement of that Al policy depends on whether those policy scope target devices are located in the policy enforcement area of the Near-RT RIC and whether the desired policy objectives can be realized with the real-time status of the RAN e.g., radio resource availability, load on E2 nodes, radio frequency propagation characteristics etc. For the Non-RT RIC 110 and the rApps 111 executing thereon, to observe both the relevance of the policy objectives to the RAN status and the presence of Al policy scope target devices in the policy enforcement area over the 01 interface in real time is difficult if not impossible.

[0063] Moreover, there are differences between the RAN observation capabilities of the 01 and E2 interface in both number of key performance indicators (KPIs) available to be monitored and the frequency or speed at which these interfaces can be used for RAN performance observations. The xApps 131 (not shown in Figure 2) executing on the Near-RT RICs 130a, 130b can observe both Al policy scope target devices and relevant performance KPIs faster using E2 interface than the rApps 111 of the Non-RT RIC 110 can using the 01 interface within a policy enforcement area. This may be due to e.g. different protocols used in the 01 versus E2 interface, possible distance (physical / transport) between RAN and SMO framework, number of KPIs available in respective interface standards, control plane versus management plane nature of these interface, etc.

[0064] Figure 3 shows a signalling diagram illustrating a method of a policy administration node - i.e. the Non-RT RIC 110 - of communicating with a policy enforcement node - i.e. the first Near-RT RIC 130a - according to an embodiment for resolving the issue arising in the scenario of Figure 2.

[0065] Hence, similar to the approach utilized in the prior art, the Non-RT RIC 110 initially provides an Al policy to the first Near-RT RIC 130a via the Al interface in S101. This initially provided policy to be enforced in S102 by the first Near-RT RIC 130a is based on the currently prevailing RAN conditions, i.e. that the three UEs 201- 203 are located within the policy enforcement area of the first Near-RT RIC 130a. In other words, the initially provided Al policy is enforced by the first Near-RT RIC 130a for the UEs 201-203 identified to be within its policy enforcement area.

[0066] However, in contrast to the prior art approach, the first Near-RT RIC 130a tracks in S103 any movement of the policy scope target devices (i.e. the UEs 201-203)away from the policy enforcement area of the first Near-RT RIC 130a. This may be performed by acquiring movement information of the UEs 201-203 from the first gNB 120a via the E2 interface.

[0067] In this example, the tracking of S103 indicates that the UE 203 indeed is moving away from the policy enforcement area of the first Near-RT RIC 130a and an indication thereof is sent to the Non-RT RIC 110 in S104 over the Al interface. As is understood, such indication may be sent by the first Near-RT RIC 130a to the Non- RT RIC 110 over the Al interface even before the UE 203 actually has left the policy enforcement area; it may be sufficient that the first Near-RT RIC 130a concludes from the tracking in S104 that the UE 203 is about to move out of the policy enforcement area.

[0068] Thus, with the tracking, the first Near-RT RIC 130a validates that the Al policy scope target devices embodied by the UEs 201-203 are within the policy enforcement area of the first Near-RT RIC 130a or predicts their movement away from the policy enforcement area of the first Near-RT RIC 130a.

[0069] In response to the indication of the UE 203 moving out of the policy enforcement area of the first Near-RT RIC 130a, the Non-RT RIC 110 updates the Al policy accordingly in S105 and sends the updated Al policy to the first Near-RT RIC 130a in S106. Hence, the Non-RT RIC 110 updates the Al policy based on the currently prevailing RAN conditions, i.e. that UE 203 no longer is located within the policy enforcement area of the first Near-RT RIC 130a.

[0070] While it may be envisaged that the Al policy is updated such that the first Near-RT RIC 130a takes into account that the that UE 203 no longer is located within the policy enforcement area of the first Near-RT RIC 130a, it may also be envisaged that a particular Al policy specifically targeting the UE 203 is removed altogether from the first Near-RT RIC 130a, should the UE 203 move away from the policy enforcement area of the first Near-RT RIC 130a. That may further include the Non- RT RIC 110 instructing the first Near-RT RIC 130a to remove one or more xApps 131 associated with the UE 203 moving away from the policy enforcement area. Advantageously, this avoids having xApps being idle but still deployed on a Near-RT RIC instance, since deployed but idle xApps still consumes energy and resources.

[0071] It may further be envisaged that the actual objective of the Al policy is updated (other than indicating that the UE 203 moves away from the policy enforcement area). For instance, one or more UEs moving away from the policy enforcement area of the first Near-RT RIC 130a may imply that RAN conditions substantially will change and that the updated Al policy indeed should reflect such changes. For instance, assuming that a number of UEs move away from the policy enforcement area of the first Near-RT RIC 130a thereby freeing up radio resources; it may then be envisaged that the remaining UEs for example can be assigned more bandwidth. Again, that may further include the Non-RT RIC 110 instructing the first Near-RT RIC 130a to remove or add one or more xApps 131 to comply with the updated Al policy.

[0072] As is understood, the Al policy update is not necessarily triggered by a handover (even if that particular scenario is exemplified in Figure 3). For example, it may be that the SLA(s) for the UEs the policy enforcement area of the first Near-RT RIC 130a instantly is changed, in which case the Non-RT RIC 110 swiftly may provide an updated Al policy over the Al interface reflecting such SLA change.

[0073] Advantageously, with the updated Al policy received in S106, the first Near RT-RIC 130a does not have to assign resources for accommodating and complying with an Al policy targeting the UE 203 which no longer is present in the policy enforcement area of the first Near-RT RIC 130a. As is understood, the updated Al policy may either omit the UE 203 as a policy scope target device, or indicate that the previously provided Al policy should not be enforced for the UE 203 (i.e. in practice indicating the updated Al policy is being idle rather than active for the UE 203). Potentially, any xApp(s) executing on the first Near-RT RIC 130a and targeting the UE 203 may either be set in an inactive state or removed.

[0074] Thus, updating the Al policy based on the currently prevailing RAN conditions being reported directly by the first Near-RT RIC 130a to the Non-RT RIC 110 via the Al interface, or possibly over the 01 interface, advantageously provides for far more efficient resource utilization at the first Near-RT RIC 130a.

[0075] Any RAN information being acquired by the first Near RT-RIC over the E2 as a result of the first Near RT-RIC 130a tracking movement of the UEs 201-203 via the first gNB 120a is advantageously acquired instantly by the first Near RT-RIC 130a over the E2 interface and communicated directly to the Non-RT RIC 110 via the Alinterface such that Non-RT RIC no may respond by providing an updated Al policy to the first Near RT-RIC 130a. Artificial intelligence (Al) and / or machine-learning (ML) may be implemented at the first Near RT-RIC 130a for performing the tracking.

[0076] For instance, the location and mobility direction of the UE 203 can be predicted from the different measurements that the UE 203 can perform and report to the first gNB 120a. The UE 203 may report location, velocity, signal strength and other related information to the first gNB 120a. The E2 interface can provide these measurement results in real-time to xApps 131 in the first Near-RT RIC 130a for tracking the UE 203. The Near-RT RIC 130a or the xApps 131 can thus apply AI / ML- based mobility prediction algorithms and in conjunction with information about the policy enforcement area of the first Near-RT RIC 130a, an xApp 131 can determine whether the Al policy scope target is moving away from the Near-RT RIC policy enforcement area.

[0077] xApps responsible for enforcing Al policies can also subscribe to other xApps providing these type of prediction functionalities before informing the Non-RT RIC 110 of possible changes occurring for the Al policy under management. Such an implementation will avoid the need for per-xApp data streams over E2 interface. The predictions about Al policy scope targets’ mobility are then sent via the proposed policy feedback notifications.

[0078] Hence, the above-described embodiment resolves the commonly occurring issue in the prior art,, where xApps are deployed on the Near RT-RIC but remain idle due to absence of the Al policy scope targets from the Near-RT RIC policy enforcement area.

[0079] Figure 4 shows a signalling diagram illustrating a method of the Non-RT RIC 110 communicating with both the first Near-RT RIC 130a and the second Near- RT RIC 130b according to a further embodiment.

[0080] In this embodiment, upon providing the first Near-RT RIC 130a with an Al policy to be enforced in S101, the second Near-RT RIC 130b is also provided with an Al policy to be enforced (given that the Non-RT RIC 110 is responsible for providing the second Near RT-Ric 130b with an Al policy). As previously mentioned, the Al policies provided to the first Near-RT RIC 130a and the second Near-RT RIC 130b are not necessarily the same but may defined different RAN performance objectives; oneobjective for the first Near-RT RIC 130a and another objective for the second Near- RT RIC 130b. Steps S102-S104 are identical with those previously described with reference to Figure 3 and will not be discussed further.

[0081] Now, in S105, the Non-RT RIC 110 updates the Al policy and provides the updated policy to the first Near RT-RIC 130a in S106 for enforcement as previously described, i.e. taking into account that the UE 203 is moving away from the policy enforcement area of the first Near RT-RIC 130a.

[0082] Further, in this embodiment, the Non-RT RIC 110 also updates or creates in S105 the Al policy to be enforced by the second Near-RT RIC 130b and provides the updated Al policy to the second Near-RT RIC 130b in S108 over the Al interface.

[0083] Optionally, this may be preceded by the Non-RT RIC 11 checking with the second Near RT-RIC 130b in S107 whether or not the second Near RT-RIC 130b has capability to enforce the updated / new Al policy to be provided in S108.

[0084] Thus, if the UE 203 is indicated in S104 to move away from the policy enforcement area of the first Near-RT RIC 130a and into the policy enforcement area of the second Near-RT RIC 130b, the Non-RT RIC 110 updates the Al policy to be enforced in S109 by the second Near-RT RIC 130b to reflect these new RAN conditions. The providing of the updated Al policy in S108 may include e.g. providing an xApp to be instantiated at the second Near-RT RIC 130b for managing the UE 203 moving into its policy enforcement area. The requirement for the new xApp to be instantiated is verified by the Non-RT RIC 110 in optional step S107. While in Figure 4 the Non-RT RIC 110 is shown to provide the xApp for instantiation at the second Near-RT RIC 130b in S108, some other appropriate entity of the SMO framework 113 may perform such instantiation, such as e.g. a Network Function Orchestrator (NFO).

[0085] Advantageously, the second Near-RT RIC 130b is made aware of the new RAN conditions and the updated Al policy to be enforced in view of these new RAN conditions. In practice, this may require the second Near-RT RIC 130b to implement and execute a new xApp handling the UE 203 moving into the policy enforcement area.

[0086] As is understood, should the Non-RT RIC 110 not provide the second Near-RT RIC 130b with the updated Al policy in S108, the second Near-RT RIC 130b may not be capable of enforcing an Al policy for the UE 203, at least not for sometime (i.e. until a new Al policy is in place). If in a scenario where the Non-RT RIC no does not create an Al policy for the second Near-RT RIC 130b initially in step S101 (e.g. if at that point in time another Non-RT RIC is responsible for providing the second Near-RT RIC 130b with an Al policy to be enforced), the Non-RT RIC 110 would create a new Al policy reflecting the moving of the UE 203 into the policy enforcement area of the second Near-RT RIC 130b and send the created Al policy to the second Near-RT RIC 130b for enforcement in S108, rather than sending an updated Al policy is the case for the first Near-RT RIC 130a in S106.

[0087] As shown in Figures 3 and 4, there are typically two approaches to Al policy LCM. One is where the Non-RT RIC no creates an Al policy across all Near-RT RICs 130a, 130b (not necessarily being identical for all Near-RT RICs) where the Al policy scope targets, i.e. UEs 201-203 and 301-303, may be present or potentially move. Another is where the Non-RT RIC no observes the location of Al policy scope targets in the RAN and creates Al policies only on a suitable Near-RT RIC 130a where the policy can be enforced. A Near-RT RIC instance generally indicates support for an Al policy type enforcement when an xApp that can enforce the policy exists on that Near-RT RIC. Hence, if a Non-RT RIC no creates an Al policy across all Near-RT RICs 130a, 130b, it implies that all Near-RT RIC instances may also host an xApp for that policy type enforcement.

[0088] With the scenario of Figure 4, the updating in S105 of the Al policy sent to the first Near-RT RIC 130a in S106 may include deleting an action of the Al policy initially provided in S101, in this example any action previously performed by the UE 203 leaving the policy enforcement area of the first Near-RT RIC 130a, while the updating in S105 of the Al policy sent to second Near-RT RIC 130b in S107 may include creating an action with respect to the Al policy initially provided in S101, i.e. any action to be performed by the UE 203 entering the policy enforcement area of the second Near-RT RIC 130b. This dynamic managing of Al policies is different from the prior art approach where an Al policy either is enforced or not enforced in its entirety.

[0089] The updating of the Al policy of may further include the Non-RT RIC 110 instructing the first Near-RT RIC 130a to delete one or more xApps 131 associated with the UE 203 moving into the policy enforcement area of the second Near-RT RIC 130b.

[0090] As previously mentioned, the Al policy update is not necessarily triggered by a handover even if that particular scenario is exemplified in Figure 4. For example, it may be that the SLA(s) for the UEs the policy enforcement area of the second Near- RT RIC 130b instantly is changed, in which case the Non-RT RIC 110 swiftly may provide an updated Al policy over the Al interface reflecting such SLA change.

[0091] Advantageously, the Al policy feedback notifications from the first Near- RT RIC 130a act as advance notice to the rApps 111 in the Non-RT RIC 110. The detailed feedback information, together with policy status information enable an rApp 111 to act in a timely proactive manner to make Al policy LCM decisions. For example, an rApp 111 can check whether the list of gNBs in a “predicted associations” list fall under the policy enforcement area of the first Near-RT RIC 130a that has sent the notification or in a different Near-RT RIC 130b, where a predicted associations list carries information from the Near-RT RIC to the rApps providing a list of E2 nodes with which the UE(s) may connect. An rApp 111 of the Non-RT RIC 110 can use, for example, a RAN topology and inventory information service in the SMO framework 113 to check which E2 nodes are managed by which Near-RT RIC instance.

[0092] If the Non-RT RIC 110 / rApp 111 identifies that an Al policy scope target device possibly is about move outside of the policy enforcement area of the first Near- RT RIC 130a to the second Near-RT RIC 130b, it can proactively check for the target Near-RT RIC’s enforcement capability for the required policy. If the target Near-RT RIC 130b does not have that capability, the rApp 111 can request the SMO framework 113 for xApp instantiation to instantiate an appropriate xApp on the target Near-RT RIC 130b. When the rApp 111 receives policy status update notification from the source Near-RT RIC 130a about policy non-enforcement due to policy scope target mobility, the Non-RT RIC 110 / rApp 111 can use the Al interface to submit the same policy to the target Near-RT RIC 130b where the UE 203 is predicted to move (essentially handing over Al policy from the source Near-RT RIC 130a to the target Near-RT RIC 130b). Functionally, this may be viewed as Al policy handovers across Near-RT RIC instances in line with Al policy scope target mobility in the RAN. The policy created at the target Near-RT RIC 130b may be an exact copy of the policy in the source Near-RT RIC 130a or an updated version of that policy based on the specifics of the RAN under the policy enforcement area of the target Near-RT RIC130b. The policy status notification from the source Near-RT RIC 130a conveying information about policy non-enforcement may also be used by the rApp 111 to delete the Al policy from the source Near-RT RIC 130a.

[0093] Thus, the second / target Near-RT RIC 130b may notify its the capability of Al policy enforcement to the Non-RT RIC 110, e.g. if it has an xApp 130 onboarded for enforcing that Al policy type. In the xApp registration procedure in the O-RAN standardized Near-RT RIC API specification, an xApp informs the Near-RT RIC about supported Al policy types. This implies that an xApp has to be running on a Near-RT RIC to enable an rApp to create an Al policy on that Near-RT RIC instance. For certain Al policy scope targets, such as a specific UE, it may not be feasible to have xApps running on all Near-RT RICs in anticipation of that UE coming to the policy enforcement area of a Near-RT RIC.

[0094] The policy status and feedback notifications for Al policy LCM can therefore also advantageously be used to trigger xApp LCM decisions (activate, deactivate, uninstall, etc.) in line with Al policy LCM decisions. For example, when an rApp 111 receives an Al policy feedback notification with information that enables it to determine the target Near-RT RIC 130b, it can check whether that target Near-RT RIC 130 has advertised support for that specific Al policy type. If not, the rApp 111 can use O2 related services in the SMO framework 113 to request the onboarding of an xApp from the SMO framework’s xApp repository, typically hosted in the O-Cloud 125 that can support enforcement of that Al policy type in the target Near-RT RIC 130b. Once the Al policy scope target device has moved to a specific target Near-RT RIC policy enforcement area, based on received Al policy status notification, the rApp 111 may request the removal / de-activation of an xApp from the first / source Near-RT RIC 130a. Such requests may go through an evaluation from the SMO framework 113 before actual xApp LCM actions are triggered via O2 interface.

[0095] With these embodiments, any predicted scenario where the Al policy scope targets embodied by the UEs 201-203 and 301-303 may move away from the policy enforcement area of the first Near-RT RIC 130a and the second Near-RT RIC 130b, respectively, is advantageously notified to the Non-RT RIC 110 using Al policy status and feedback notifications transmitted over the Al interface (or possibly the 01 interface).

[0096] Advantageously, this reduces the risk of having the Al policy that exists on a Near-RT RIC 130a to consume resources but which cannot be enforced by xApps implemented thereon due to absence of one or more policy scope targets in the policy enforcement area.

[0097] Further advantageous, enforcement of an Al policy is ensured to occur on a Near-RT RIC 130b where the policy scope targets are located. Thus, the Non-RT RIC 110 may use the received notifications to decide on Al policy LCM actions such as creating, deleting and updating xApps 131.

[0098] Yet further advantageous is that the proposed enhancements enable the Al interface to carry Al policy related status and feedback notifications to the rApps 111 / Non-RT RIC 110. In the art, when an Al policy is accepted by the Near-RT RIC 130, it is assumed as “enforced” by the Non-RT RIC 110 unless a subsequent policy status query returns a different enforcement status or a notification about policy status change is received from the Near-RT RIC 130. This prior art approach can only be used to convey basic policy enforcement status (“enforced”, “not enforced”) and reasons for non-enforcement (“scope not applicable ”, etc.) in Al policy status change notifications. The prior art policy status approach does not provide additional details to the Non-RT RIC 110 when the policy status is “enforced”.

[0099] In contrast, with embodiments disclosed herein, the Near-RT RIC control loop for policy enforcement is connected with the Non-RT RIC control loop for policy LCM decisions, and the Al policy notifications may be used for conveying more detailed information to the Non-RT RIC 110 from the Near-RT RIC 130 in policy type specific time-intervals. Advantageously, the Al policy feedback notifications can carry information about Al policy scope targets’ current association to the E2 nodes 120 in the Near-RT RIC policy enforcement area and their possible next associations derived from the tracking of policy scope target devices 203 using e.g. handover information and / or mobility predictions in the Near-RT RIC 130. Additional information that may be provided in the feedback may include policy related statistics such as e.g., number of policy activations, an indication of relevance of the policy objectives and resources to the status of the RAN, etc.

[0100] To support the requirement of conveying such Al policy feedback information, the Al policy status information reported to the Non-RT RIC 110 can be complemented to carry policy type specific feedback information. This can be done inboth backward-compatible and non-compatible ways to the existing specifications using appropriate structures such as e.g. JavaScript Object Notation (JSON).

[0101] Thus, with embodiments proposed herein, Al policy notifications may be used for conveying more detailed information to the Non-RT RIC no from the Near- RT RIC 130 about policy scope, objectives, and resources in a standardized or proprietary manner using e.g. JSON structures decoded by rApps at the application layer. The structure of this feedback information element may either conform to standard (e.g., if defined for standardized policy types in O-RAN) or to a specific JSON structure that can be interpreted by both xApps and rApps. Advantageously, these enhancements enable the Near-RT RIC 130 to convey detailed information to the Non-RT RIC 110 about the policy, policy scope targets, RAN status, etc.

[0102] Figure 5 shows a signalling diagram illustrating a handover of the UE 203 being undertaken. Handover information may be utilized by the first Near-RT RIC 130a tracking the UE 203 moving away from the policy enforcement area of the first Near-RT RIC 130a as discussed hereinabove with refence to step S103 of Figures 3 and 4. Reference is further made to Figure 2 showing the two gNBs 120a, 120b (i.e. the E2 nodes) involved in a handover procedure illustrated in Figure 5, where the first gNB 120a will be referred to as source gNB (i.e. the gNB from which the handover is performed) while the second gNB 120b will be referred to as target gNB (i.e. the gNB to which the handover is performed). The handover can either be a conditional handover (CHO) or a regular handover (HO). Shown in Figure 5 is a conditional handover procedure.

[0103] The handover procedure is in itself well-known and specified in 3rd Generation Partnership Project (3GPP) specifications, and will thus not be described in great detail herein.

[0104] In a first step S201, the UE 203 sends measurement reports to the source gNB 120a comprising measurement results for potential candidate target cells. In S202, the source gNB 120a requests one or more selected target gNBs 120b to acknowledge the handover request and prepare corresponding configurations to be used by the UE 203 for accessing the target cell served by the target gNB 120b. As is understood, while Figure 5 only shows a single target gNB 120b, the selection may involve multiple target gNBs.

[0105] In step S203, the source gNB 120a sends a CHO command comprising configurations and execution conditions for the cell(s) selected in S202. In S204, upon reception of CHO command, the UE 203 evaluates whether or not handover is to be performed but remains attached to the source gNB 120a until necessary CHO execution conditions are met. Finally in step S205, the UE 203 initiates the CHO execution without any further control signalling from the source gNB 120a. At this point, the target gNB 120b is aware of and is ready to serve the UE 203.

[0106] An xApp 131 of the first Near-RT RIC 130a communicating with the source gNB 120a via E2 can hook into the CHO procedure at any suitable step of Figure 5.An xApp 131 may use an E2 event trigger such as “CHO Event Trigger” that will result in an E2 report being sent to the xApp 131 from the source gNB 120a before any specific CHO steps occurring in Figure 5; an xApp 131 may even request the source gNB 130a to inform it before the initiation of CHO related measurement of the UE in S201, when the source gNB 130a initiates execution of CHO in S202 or when a CHO command is sent to the UE in S203.

[0107] An xApp 131 may subscribe to such CHO specific events (as specified in detail in the 0-RAN standardized “RIC subscription procedure”). An E2 node, i.e. in this example the source gNB 120a, will initiate CHO reporting using a RIC INDICATION message to the Near-RT RIC 130a containing information requested by the xApp 131 upon the trigger event occurring.

[0108] As is understood, support for the stated CHO monitoring and information reporting requirements may not be available in existing E2SM specifications but the 0-RAN standardized E2SM-Radio Control specification can be enhanced, for example to provide the needed functionality by extending the existing event triggers for handover specific events and extending the existing report services for including missing CHO specific information.

[0109] In other words, with reference again to Figures 3 and 4, the first Near-RT RIC 130a tracks in S103 any movement of the policy scope target devices (i.e. the UE 203) away from the policy enforcement area of the first Near-RT RIC 130a. This may be performed by acquiring movement information of the UE 203 from the first gNB 120a via the E2 interface. Hence, as a soon as a handover is triggered by any of the steps of Figure 5, the source gNB 120a informs the first Near-RT-RIC 130aaccordingly via E2, which thus in S104 sends an indication over Al to the Non-RT RIC 11 of the UE 203 moving away, and an Al policy update may thus be undertaken.

[0110] Based on the UE mobility information reported by the source gNB 130a to the first Near-RT RIC 130a over E2, an xApp 131 derives information about the potential mobility of the UE 230 away from the policy enforcement area of the first Near-RT RIC 130a. For example, if the UE mobility information reported from the source gNB 130a contains information about target gNB(s) 130b configured for CHO that are not connected to the first Near-RT RIC 130a, that may indicate that the UE 230 is possibly moving to a new Near-RT RIC policy enforcement area (e.g. that of the second Near-RT RIC 130). The list of E2 nodes connected to a Near-RT RIC is generally available to an xApp from the Near-RT RIC framework.

[0111] Similarly, in a regular handover scenario, the measurement data reported by the UE 203 may indicate a target eNB 130b for handover that may be outside the policy enforcement area of the first Near-RT RIC 130a. The xApp 131 may, based on observing CHO and HO events, decide to send an Al policy feedback notification to the Non-RT RIC 110 (and thus rApp 111) informing about potential need to update and / or subsequently remove the Al policy on the first Near-RT RIC 130a. The feedback notifications advantageously act as an advance notice to prepare the rApps 111 for policy LCM actions and further carry information about policy enforcement in the first Near-RT RIC 130a.

[0112] Figure 6 shows a signalling diagram illustrating an exemplifying embodiment where the first Near-RT RIC 130a tracks the UE 203 moving away from the policy enforcement area of the first Near-RT RIC 130a in line with embodiments described hereinabove.

[0113] In a first step S301, the source gNB 120a advertises in an E2 setup request a list of E2SMS supported, including the functionality related to handover information reporting. The xApps 131 executing on the first Near-RT RIC 130a confirms the request with an E2 setup response in S302 and makes a request for subscription in S303 to the source gNB 120a, which provides the event triggers and actions to perform upon the event triggers occurring as identified in S304. The source gNB 120a notifies the first near-RT RIC 130a in S305 when the specified event triggers are identified to occur in step S304.

[0114] In the regular handover procedure, the UE 203 is requested to measure radio channel parameters such as Reference Signals Received Power (RSRP) and / or Reference Signal Received Quality (RSRQ) for signals of the serving base station - i.e. the source gNB 120a - and the neighbouring base stations being candidates for handover - i.e. the target gNB 120b - and reports the measurements to the source gNB 120a (as discussed with reference to step S201 of Figure 5).

[0115] Depending on the received measurement results, e.g. if the reported measurements indicate that the channel parameters of the target gNB 120b are more favourable than those of the source gNB 120a, the source gNB 120b sends a handover command to the UE 203 either via default functionality of the source gNB 120a or via a control command from an xApp 131 in the first Near-RT RIC 130a. The difference between with CHO and regular HO is that in regular HO, the target gNB 120b is not pre-prepared to take over the serving of the UE 203. An xApp 131 can set event triggers on the HO preparation and / or HO execution process in the gNBs 120a, 120b to receive information about UE mobility in the RAN.

[0116] Figure 7 illustrates a policy administration node 110 in the form of a Non- RT RIC configured to communicate with a policy enforcement node in the form of a Near-RT RIC 130 in a communications network 100 according to an embodiment, where the steps of the method performed by the Non-RT RIC 110 in practice are performed by a processing unit 211 embodied in the form of one or more microprocessors arranged to execute a computer program 212 downloaded to a storage medium 213 associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit 211 is arranged to cause the Non-RT RIC 110 to carry out the method according to embodiments when the appropriate computer program 212 comprising computerexecutable instructions is downloaded to the storage medium 213 and executed by the processing unit 211. The storage medium 213 may also be a computer program product comprising the computer program 212. Alternatively, the computer program 212 may be transferred to the storage medium 213 by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program 212 may be downloaded to the storage medium 213 over a network. The processing unit 211 may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integratedcircuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. The Non-RT RIC no further comprises a communication interface 214 (wired and / or wireless) over which the Non-RT RIC 110 is configured to transmit and receive data.

[0117] Figure 8 illustrates a policy enforcement node 130 in the form of a Near- RT RIC configured to communicate with a policy administration node in the form of a Non-RT RIC no in a communications network 100 according to an embodiment, where the steps of the method performed by the Near-RT RIC 130 in practice are performed by a processing unit 311 embodied in the form of one or more microprocessors arranged to execute a computer program 312 downloaded to a storage medium 313 associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit 311 is arranged to cause the Near-RT RIC 130 to carry out the method according to embodiments when the appropriate computer program 312 comprising computerexecutable instructions is downloaded to the storage medium 313 and executed by the processing unit 311. The storage medium 313 may also be a computer program product comprising the computer program 312. Alternatively, the computer program 312 may be transferred to the storage medium 313 by means of a suitable computer program product, such as a DVD or a memory stick. As a further alternative, the computer program 312 may be downloaded to the storage medium 313 over a network. The processing unit 311 may alternatively be embodied in the form of a DSP, an ASIC, an FPGA, a CPLD, etc. The Near-RT RIC 130 further comprises a communication interface 314 (wired and / or wireless) over which the Near-RT RIC 130 is configured to transmit and receive data.

[0118] The methods according to the herein disclosed embodiments are suitable to be performed by devices residing in a cloud computational environment. All the functional elements of the devices of the embodiments disclosed herein can be realized in a distributed manner and are subject to virtualization / containerization. The SMO framework, rApps, Non-RT RIC, Near-RT RIC, xApps, and E2 nodes can all be realized as separate distributed nodes connected via standardized and proprietary interfaces.

[0119] The aspects of the present disclosure have mainly been described above with reference to a few embodiments and examples thereof. However, as is readilyappreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

[0120] Thus, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

CLAIMS1. A method of a policy administration node (no) of communicating with a policy enforcement node (130a) in a communications network (100), the policy administration node (110) providing the policy enforcement node (130a) with policies based on which radio access network, RAN, performance objectives are defined, comprising: providing (S101) the policy enforcement node (130a) with a policy to be enforced in the RAN for attaining the RAN performance objectives, wherein the policy enforcement node (130a) is configured to enforce (S102) the provided policy for policy scope target devices (201-203) identified to be within the policy enforcement area of the policy enforcement node (130a); receiving (S104), from the policy enforcement node (130a) over an interface established directly between the policy administration node (110) and the policy enforcement node (130a), an indication that at least one policy scope target device (203) moves away from said policy enforcement area; updating (S105) the policy to take into account the received indication that said at least one policy scope target device (203) moves away from the policy enforcement area of the policy enforcement node (130a); and providing (S106) the policy enforcement node (130a) with the updated policy for enforcement of the updated policy to the policy scope target devices (201, 202) identified to be within the policy enforcement area of the policy enforcement node (130a).

2. The method of claim 1, the updated policy being configured to no longer indicate an action that was present in the previously provided policy to be performed for said at least one policy scope target device (203) moving away from the policy enforcement area, or being configured to indicate that said action is inactivated as long as the said at least one policy scope target device (203) remains outside of the policy enforcement area.

3. The method of claims 1 or 2, wherein the providing (Slot) of the policy enforcement node (130a) with a policy to be enforced further comprises providing a further policy enforcement node (130b) with a policy to be enforced, the method further comprising: updating (S105), if said at least one policy scope target device (203) is indicated to move into a policy enforcement area of said further policy enforcement node (130b), the policy provided to said further policy enforcement node (130b) to take into account the received indication that said at least one policy scope target device (203) moves into the policy enforcement area of said further policy enforcement node (130b); and providing (S108) said further policy enforcement node (130a) with the updated policy or a newly created policy for enforcement of the updated policy or the newly created policy to the policy scope target devices (203, 301-303) identified to be within the policy enforcement area of said further policy enforcement node (130a).

4. The method of claim 3, the updated or newly created policy provided (S108) to said further policy enforcement node (130b) being configured to further indicate one or more actions to be performed for said at least one policy scope target device (203) moving into the policy enforcement area of said further policy enforcement node (130b).

5. The method of any one of the preceding claims, the communications network (100) being an Open Radio Access Network, ORAN, the policy administration node (110) being a Non-Real Time Radio Access Controller, Non-RT RIC, and the policy enforcement node (130a) being a Near-Real Time Radio Access Controller, Near-RT RIC.

6. The method of claim 5, the interface established directly between the policy administration node (110) and the policy enforcement node (130a) being an Al interface or an 01 interface.

7. The method of claim 5 or 6, wherein an application, xApp, executing on a Near- RT RIC (130a) associated with an action of an updated policy for a policy scope target device (203) moving away from the policy enforcement area of said Near-RT RIC (130a) is either removed from or inactivated at said Near-RT RIC (130a), while for an action of an updated or newly created policy for a policy scope target device (203) moving into the policy enforcement area of a Near-RT RIC (130b), an xApp to be associated with the action is deployed on said Near-RT RIC (130b).

8. The method of claim 7, further comprising: verifying (S107) capability of the near Near-RT RIC (130b) to whose policy enforcement area the policy scope target device (203) moves into, and providing (S108) said near Near-RT RIC (130b) with one or more xApps required for enforcing the updated or newly created policy.

9. A computer program (212) comprising computer-executable instructions for causing a policy administration node (110) to perform steps recited in any one of claims 1-8 when the computer-executable instructions are executed on a processing unit (211) included in the policy administration node (110).

10. A computer program product comprising a computer readable medium (213), the computer readable medium having the computer program (212) according to claim 9 embodied thereon.

11. A method of a policy enforcement node (130a) of communicating with a policy administration node (110) in a communications network (100), the policy enforcement node (130a) receiving from the policy administration node (110) policies based on which radio access network, RAN, performance objectives are defined, comprising: receiving (S101), from the policy administration node (110), a policy to be enforced (S102) for policy scope target devices (201-203) identified to be within the policy enforcement area of the policy enforcement node (130a) in the RAN forattaining the RAN performance objectives; tracking (S103) said policy scope target devices (201-203); providing (S104), to the policy administration node (110) over an interface established directly between the policy enforcement node (130a) and the policy administration node (110), an indication that at least one policy scope target device (203) moves away from said policy enforcement area; and receiving (S106), from the policy administration node (110), an updated policy taking into account the indication that said at least one policy scope target device (203) moves away from the policy enforcement area of the policy enforcement node (130a), for enforcement to the policy scope target devices (201, 202) identified to be within the policy enforcement area of the policy enforcement node (130a).

12. The method of claim 11, the updated policy being configured to no longer indicate an action that was present in the previously provided policy to be performed for said at least one policy scope target device (203) moving away from the policy enforcement area, or being configured to indicate that said action is inactivated as long as the said at least one policy scope target device (203) remains outside of the policy enforcement area.

13. The method of any one of claims 11 or 12, the communications network (100) being an Open Radio Access Network, O-RAN, the policy administration node (110) being a Non-Real Time Radio Access Controller, Non-RT RIC, and the policy enforcement node (130a) being a Near-Real Time Radio Access Controller, Near-RT RIC.

14. The method of claim 13, the interface established directly between the policy administration node (110) and the policy enforcement node (130a) being an Al interface or an 01 interface.

15. The method of claim 13 or 14, wherein an application, xApp, executing on a Near-RT RIC (130a) associated with an action of an updated policy for a policy scopetarget device (203) moving away from the policy enforcement area of said Near-RT RIC (130a) is either removed from or inactivated at said Near-RT RIC (130a).

16. The method of any one of claims 11-15, the tracking being based on acquiring handover information from the RAN indicating that said at least one policy scope target device (203) moves away from said policy enforcement area, or based on acquiring policy scope target device mobility information from the RAN from which mobility information it is determined that said at least one policy scope target device (203) moves away from said policy enforcement area.

17. A computer program (312) comprising computer-executable instructions for causing a policy enforcement node (130a) to perform steps recited in any one of claims 11-16 when the computer-executable instructions are executed on a processing unit (311) included in the policy enforcement node (130a).

18. A computer program product comprising a computer readable medium (313), the computer readable medium having the computer program (312) according to claim 17 embodied thereon.

19. A policy administration node (110) configured to communicate with a policy enforcement node (130a) in a communications network (100), the policy administration node (110) providing the policy enforcement node (130a) with policies based on which radio access network, RAN, performance objectives are defined, the policy administration node (110) comprising a processing unit (211) and a memory (213), said memory containing instructions (212) executable by said processing unit (211), whereby the policy administration node (110) is operative to: provide the policy enforcement node (130a) with a policy to be enforced in the RAN for attaining the RAN performance objectives, wherein the policy enforcement node (130a) is configured to enforce the provided policy for policy scope target devices (201-203) identified to be within the policy enforcement area of the policy enforcement node (130a); receive, from the policy enforcement node (130a) over an interface establisheddirectly between the policy administration node (no) and the policy enforcement node (130a), an indication that at least one policy scope target device (203) moves away from said policy enforcement area; update the policy to take into account the received indication that said at least one policy scope target device (203) moves away from the policy enforcement area of the policy enforcement node (130a); and provide the policy enforcement node (130a) with the updated policy for enforcement of the updated policy to the policy scope target devices (201, 202) identified to be within the policy enforcement area of the policy enforcement node (130a).

20. The policy administration node (110) of claim 19, the updated policy being configured to no longer indicate an action that was present in the previously provided policy to be performed for said at least one policy scope target device (203) moving away from the policy enforcement area, or being configured to indicate that said action is inactivated as long as the said at least one policy scope target device (203) remains outside of the policy enforcement area.

21. The policy administration node (110) of claims 19 or 20, further being operative to, when providing the policy enforcement node (130a) with a policy to be enforced, further providing a further policy enforcement node (130b) with a policy to be enforced, and being operative to: update, if said at least one policy scope target device (203) is indicated to move into a policy enforcement area of said further policy enforcement node (130b), the policy provided to said further policy enforcement node (130b) to take into account the received indication that said at least one policy scope target device (203) moves into the policy enforcement area of said further policy enforcement node (130b); and provide said further policy enforcement node (130a) with the updated policy or a newly created policy for enforcement of the updated policy or the newly created policy to the policy scope target devices (203, 301-303) identified to be within the policy enforcement area of said further policy enforcement node (130a).

22. The policy administration node (no) of claim 21, the updated or newly created policy provided (S108) to said further policy enforcement node (130b) being configured to further indicate one or more actions to be performed for said at least one policy scope target device (203) moving into the policy enforcement area of said further policy enforcement node (130b).

23. The policy administration node (no) of any one of claims 19-22, the communications network (100) being an Open Radio Access Network, O-RAN, the policy administration node (no) being a Non-Real Time Radio Access Controller, Non-RT RIC, and the policy enforcement node (130a) being a Near-Real Time Radio Access Controller, Near-RT RIC.

24. The policy administration node (no) of claim 23, the interface established directly between the policy administration node (no) and the policy enforcement node (130a) being an Al interface or an 01 interface.

25. The policy administration node (no) of claim 23 or 24, wherein an application, xApp, executing on a Near-RT RIC (130a) associated with an action of an updated policy for a policy scope target device (203) moving away from the policy enforcement area of said Near-RT RIC (130a) is either removed from or inactivated at said Near-RT RIC (130a), while for an action of an updated or newly created policy for a policy scope target device (203) moving into the policy enforcement area of a Near-RT RIC (130b), an xApp to be associated with the action is deployed on said Near-RT RIC (130b).

26. The policy administration node (110) of claim 25, further being operative to: verify capability of the near Near-RT RIC (130b) to whose policy enforcement area the policy scope target device (203) moves into, and providing (S108) said near Near-RT RIC (130b) with one or more xApps required for enforcing the updated or newly created policy.

27. A policy enforcement node (130a) configured to communicate with a policy administration node (110) in a communications network (100), the policy enforcement node (130a) receiving from the policy administration node (110) policies based on which radio access network, RAN, performance objectives are defined, the policy enforcement node (130a) comprising a processing unit (311) and a memory (313), said memory containing instructions (312) executable by said processing unit (311), whereby the policy enforcement node (130a) is operative to: receive, from the policy administration node (110), a policy to be enforced (S102) for policy scope target devices (201-203) identified to be within the policy enforcement area of the policy enforcement node (130a) in the RAN for attaining the RAN performance objectives; track said policy scope target devices (201-203); provide, to the policy administration node (110) over an interface established directly between the policy enforcement node (130a) and the policy administration node (110), an indication that at least one policy scope target device (203) moves away from said policy enforcement area; and receive, from the policy administration node (110) an updated policy taking into account the indication that said at least one policy scope target device (203) moves away from the policy enforcement area of the policy enforcement node (130a), for enforcement to the policy scope target devices (201, 202) identified to be within the policy enforcement area of the policy enforcement node (130a).

28. The policy enforcement node (130a) of claim 27, the updated policy being configured to no longer indicate an action that was present in the previously provided policy to be performed for said at least one policy scope target device (203) moving away from the policy enforcement area, or being configured to indicate that said action is inactivated as long as the said at least one policy scope target device (203) remains outside of the policy enforcement area.

29. The policy enforcement node (130a) of any one of claims 27 or 28, the communications network (100) being an Open Radio Access Network, O-RAN, the policy administration node (110) being a Non-Real Time Radio Access Controller,Non-RT RIC, and the policy enforcement node (130a) being a Near-Real Time Radio Access Controller, Near-RT RIC.

30. The policy enforcement node (130a) of claim 29, the interface established directly between the policy administration node (110) and the policy enforcement node (130a) being an Al interface or an 01 interface.

31. The policy enforcement node (130a) of claim 29 or 30, wherein an application, xApp, executing on a Near-RT RIC (130a) associated with an action of an updated policy for a policy scope target device (203) moving away from the policy enforcement area of said Near-RT RIC (130a) is either removed from or inactivated at said Near-RT RIC (130a).

32. The policy enforcement node (130a) of any one of claims 11-15, the tracking being based on acquiring handover information from the RAN indicating that said at least one policy scope target device (203) moves away from said policy enforcement area, or based on acquiring policy scope target device mobility information from the RAN from which mobility information it is determined that said at least one policy scope target device (203) moves away from said policy enforcement area.

Images