Policy based coordination management in the service management and orchestration framework

Abstract

Methods and apparatuses for Open Radio Access Network (O-RAN) configuration are provided. A method is performed by a first network node in a Service Management and Orchestration, (SMO) framework for an O-RAN communication network comprising a network entity controlled by a first network parameter, wherein the SMO framework further comprises a Radio Access Network Operations, Administration and Maintenance Coordination Management (RAN OAM CM) interface configured to update the first network parameter. The method comprises receiving a first request to update a value of the first network parameter to a second value, and obtaining a first response to the first request. The first response indicates one of acceptance or rejection of the second value, or an updated second value. The method further comprises initiating transmission, to the RAN OAM CM interface, of the first response.

Description

[0001] POLICY BASED COORDINATION MANAGEMENT IN THE SERVICE MANAGEMENT AND ORCHESTRATION FRAMEWORK

[0002] TECHNICAL FIELD

[0003] [1] Embodiments of the present disclosure relate to Open-Radio Access Network (O-RAN) communication networks, and particularly to methods, apparatus and computer-readable media for configuration of O-RAN communication networks.

[0004] BACKGROUND

[0005] [2] In the Open-Radio Access Network (O-RAN) Service Management and Orchestration (SMO) Framework and Non-Real Time RAN Intelligent Controller (Non-RT RIC), SMO Services (SMOSs) and Non-RT RIC Applications (rApps) may execute Configuration Management (CM) actions towards the network, for example via a Radio Access Network Operations, Administration and Maintenance Configuration Management (RAN OAM CM) interface. For example, a client may try to up-tilt an antenna to increase cell coverage.

[0006] [3] SUMMARY

[0007] [4] There currently exist certain challenge(s).

[0008] [5] Different clients may attempt to execute CM actions that interfere with each other. For example, one client may try to up-tilt an antenna to increase cell coverage while another may try to down-tilt the same antenna to increase cell capacity.

[0009] [6] In the existing SMO decomposition architecture technical report (see O-

[0010] RAN.WG1.Decoupled-SMO-Architecture-R004-v03.00, available at https: / / specifications.o-ran.org / specifications as of 20 May 2025) and Non-RT RIC architecture technical specifications in O-RAN (see O RAN.WG2.Non-RT-RIC-ARCH-R004- v06.00, available at https: / / specifications.o-ran.org / specifications as of 20 May 2025), there is no functional entity defined which has the responsibility to coordinate and mitigate these scenarios. Figure 1 illustrates SMO capabilities represented as SMOS.

[0011] [7] This means that clients, for example, rApps, SMOS’s and other clients external to the SMO, will experience more problems in executing their use cases, as well as creating unnecessary network instability. [8] In addition, determining the appropriate mitigation action to take when these scenarios occur will depend on multiple factors and inputs. Determining these at design time is not feasible. Therefore, a coordination mechanism which is extensible at run-time is may be useful.

[0012] [9] 0-RAN.WG2.R1GAP-v09.00 (available at https: / / specifications.o-ran.org / specifications as of 20 May 2025) summarizes the R1 interface specification objectives, and also specifies principles and procedures related to the O-RAN R1 interface. O- RAN.WG10.0AM-Architecture-R004-v13.00 (available at https: / / specifications.o-ran.org / specifications as of 20 May 2025) includes a discussion of management services, functions and interfaces supported in O-RAN, as well as the interworking between service management and orchestration (SMO) and O-RAN.

[0013]

[0010] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. Embodiments of the present disclosure present a policy-based Coordination Service, wherein run-time decisions about CM changes that rApps and SMOS are attempting to make can be implemented using policies. These policies, along with any potential contextual data they may need, may be added at run-time to deal with specific scenarios and clients. The policies may reject, sequence, delay or even alter the changes being requested by the rApps.

[0014]

[0011] The policies may also provide feedback to the client requesting the change to enable the client to become aware of other clients and changes the other clients may be making that require coordination for successful network operation.

[0015]

[0012] Furthermore, the Coordination Service may be extended with new policies and new contextual data at run-time to enable it to be adapted to different kinds of coordination scenarios.

[0016]

[0013] Some embodiments disclose a policy-based coordination service that may inspect CM changes requested by clients and, for example using contextual information, make decisions on whether or how best to execute the change that will ensure that conflict scenarios are minimized, while allowing the CM changes to achieve their desired goal.

[0017]

[0014] CM changes requested by the clients towards the Radio Access Network Operations, Administration and Maintenance Configuration Management (RAN 0AM CM) interface may be inspected by the Coordination Service and a decision may be made using policies and context data regarding the change. Additionally, feedback may be returned as a part of the error response via the CM interface.

[0018]

[0015] Certain embodiments may provide one or more of the following technical advantage(s). The proposed solution is highly adaptable since new policies and context data may be added in run-time. Furthermore, it does not require clients to work towards a new interface to benefit from the coordination functionality.

[0019]

[0016] BRIEF DESCRIPTION OF THE DRAWINGS

[0020]

[0017] For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0021]

[0018] Figure 1 illustrates SMO capabilities illustrated as SMOS;

[0022]

[0019] Figure 2 illustrates part of an SMO framework for an ORAN communication network;

[0023]

[0020] Figure 3 is a flow chart illustrating a method in accordance with some embodiments;

[0024]

[0021] Figure 4 illustrates a policy decision framework according to some embodiments;

[0025]

[0022] Figure 5 is a flow chart illustrating a method in accordance with some embodiments;

[0026]

[0023] Figure 6 is a flow chart illustrating a method in accordance with some embodiments;

[0027]

[0024] Figure 7 is a signalling illustrating an example implementation of some embodiments

[0028]

[0025] Figure 8 is a signalling illustrating an example implementation of some embodiments

[0029]

[0026] Figure 9 is a signalling illustrating an example implementation of some embodiments

[0030]

[0027] Figure 10 illustrates an example architecture for an SMO comprises a Coordination Service according to some embodiments;

[0031]

[0028] Figure 11 illustrates a first network node comprising processing circuitry (or logic);

[0032]

[0029] Figure 12 illustrates a RAN OAM CM interface comprising processing circuitry (or logic);

[0033]

[0030] Figure 13 illustrates a first client comprising processing circuitry (or logic);

[0034]

[0031] Figure 14 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized; and

[0035]

[0032] Figure 15 is proposed figure 6.1-1 from Change Request 0381 rev 1 , a proposed change request for 0-RAN.WG2.Non-RT RIC-ARCH ver 06.00, which depicts the reference architecture of the Non-RT RIC as part of the SMO framework.

[0036] ADDITIONAL EXPLANATION

[0037]

[0033] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Additional information may also be found in the document(s) provided in the Appendix.

[0034] According to embodiments described herein a Coordination Service may be used by a RAN CAM CM interface to make coordination decisions regarding CM changes that are requested by clients.

[0038]

[0035] Figure 2 illustrates part of an SMO framework for an ORAN communication network. The RAN 0AM CM interface 220 is in communication with a plurality of clients, 210a, 210b and 210c, and with the Coordination Service 230. In some embodiments, the Coordination Service 230 may comprise a first network node (as will be described later with reference to Figure 3). In some embodiments, a RAN OAM SMOS may comprise the RAN OAM CM interface 220.

[0039]

[0036] Each time a client (for example, the rApps, 210a and 210b, or SMOS 210c shown in Figure 2 or another client external to the SMO) requests one or more CM parameter changes, the Coordination Service 230 may be asked for a decision regarding the requested changes. For example, a decision regarding the one or more parameter changes may be whether to allow, prevent, alter, delay, or sequence the one or more CM parameter changes. There may be more decisions regarding other actions to take the one or more CM parameter changes.

[0040]

[0037] The RAN OAM CM interface 220 may then act on the decision made by the Coordination Service 230. Therefore, the RAN OAM CM interface 220 may implement an action in the ORAN network relating to the CM parameters according to the Coordination Response the RAN OAM CM interface 220 receives from the Coordination Service 230. For example, the RAN OAM CM interface may implement the requested change if the request is accepted, or may implement the requested change after a certain time period if the request was accepted with a delay. Alternatively, if the request is rejected, the RAN OAM CM interface may indicate to the requesting client that the request failed.

[0041]

[0038] Additionally, a client (e.g. an rApp, SMOS or Administrator) may reserve a node or a cell using Coordination Management (as will be described in more detail with reference to figures 6 and 8). A reservation may create a controlled environment where only the reserving client will be permitted to request CM Changes to the node or cell under reservation. This may enable the client to observe and evaluate the impact of the requested CM Change on the network. Such a reservation may ensure that when a decision is requested by RAN OAM CM interface 220, from a client that does not own the reservation, the decision will be to prevent the requested change.

[0042]

[0039] . An ORAN network node is a node in the telecommunication network that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network, including one or more network nodes and / or core network nodes.

[0040] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1 , W1 , E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies.

[0043]

[0041] Embodiments of the present disclosure may enable a coordination mechanism, for example, the Coordination Service 230, to mitigate a client in an O-RAN communication network from scheduling one or more changes to a network parameter of a network entity that conflict and / or interfere with one or more changes to the network parameter requesting by one or more other clients. Hence, embodiments of the present disclosure may mitigate conflict between one or more clients.

[0044] Furthermore, as embodiments of the present disclosure enable a policy-based coordination mechanism to be used, the coordination mechanism may enable control, for example, by an Administrator node, of the one or more policies the coordination mechanism uses to make decisions regarding the parameter change requests associated with the one or more clients. Therefore, embodiments of the present disclosure may enable control over which requests may be accepted or rejected, and to configure when the changes are implemented at the network entity. Additionally, embodiments of the present disclosure may enable control over which clients are permitted to have their requests for a network parameter change be accepted.

[0045]

[0042] Figure 3 illustrates a method in accordance with particular embodiments. The method of Figure 3 may be performed by a first network node in a SMO framework for an O-RAN communication network. The O-RAN communication network may comprise a network entity, wherein the network entity is controlled by a first network parameter. The SMO framework may further comprise a Radio Access Network Operations, Administration and Maintenance Configuration Management, RAN OAM CM, interface configured to update the first network parameter. The RAN OAM CM interface may comprise the RAN OAM CM interface performing the method 5. The RAN OAM CM interface may comprise the RAN OAM CM interface 220 of Figure 2. It will be appreciated that the first network node may not comprise a physical node in a network, but may comprise a logical node within the SMO framework.

[0046]

[0043] In some embodiments, the network entity comprises one of a second network node, and a cell or a beam served by a network node (e.g. a base station).

[0047]

[0044] In some embodiments, the first network node comprises a Coordination Service. The first network node may comprise the Coordination Service 230 of Figure 2.

[0048]

[0045] The method begins at step 302 with the first network node receiving a first request, associated with a first client, to update a first value of the first network parameter to a second value. The first client may comprise the first client performing the method 6. The first client may comprise one of the clients 21 Oa, 21 Ob and 21 Oc of Figure 2.

[0049]

[0046] The method proceeds to step 304 with the first network node obtaining, according to one or more policies, a first response to the first request. The first response indicates one of: acceptance of the second value, rejection of the second value, and an updated second value.

[0050]

[0047] The updated second value may be based at least in part on the second value. IN other words there may be some relationship between the updated second value and the second value. For example, there may be a policy that the first network node cannot suggest an update that is greater than a particular threshold different than the requested value.

[0051]

[0048] The first response may indicate one of: acceptance of the second value by delaying the first request, and acceptance of the second value by adding the first request to a sequence of requests. A sequence of requests may be enacted by adding each request sequentially to the end of the queue. Alternatively, requested may be inserted into the queue according to some priority or hierarchy policy.

[0052]

[0049] The first response may further comprise an indication of other clients and information relating to respective requests made by the other clients.

[0053]

[0050] Within the Coordination Service, each decision may be made by executing one or more policies that each deal with various criteria that may apply to the outcome of the decision. The coordination policies themselves may utilize configuration data, internal state data or other external data that has been injected into the Coordination Service.

[0054]

[0051] Each time the RAN CAM CM interface requests a decision, it may trigger a specific Decision Type within the Coordination Service, which in turn executes specific entry point policies and their support policies.

[0055]

[0052] Figure 4 illustrates a Coordination Management policy pathway, wherein a particular policy is executed subject to either a Decision Type 410 or a higher layer policy being triggered.

[0056]

[0053] The Decision Type may comprise the Decision Type 410 of Figure 4. It will be appreciated that a decision type may, for example, be a binary yes / no (acceptance / rejection) decision type, a decision type enabling adjustment of the request, or a decision type enabling delaying or sequencing of the request.

[0054] The entry point policies may comprise the entry point policy 420 of Figure 4. The support policies may comprise at least one of the support policies 430a, 430b and 430c of Figure 4.

[0057]

[0055] For example, once a particular Decision Type 410 is triggered, the Coordination Service triggers a corresponding entry point policy 420.

[0058]

[0056] The entry point policies 420 may be responsible to trigger any necessary supporting policies, 430a, 430b and 430c, which evaluate the various criteria that may apply to the overall decision. Upon execution of the corresponding entry point policy 420, the Coordination Service may triggers execution of one or more support policies 430a, 430b and 430c. In Figure 4, the support policies 430a, 430b and 430c, may be defined by the data used by the support policies. For example, as shown in Figure 4, the one or more support policies may use external data 430a, configuration data 430b or internal state data 430c. The entry point policy 420 may then be responsible for collating the outputs of the supporting policies 430a, 430b and 430c, to generate an overall decision result.

[0059]

[0057] In some embodiments, step 304 of Figure 3 comprises the first network node triggering a network parameter Decision Type. Additionally, responsive to triggering the network parameter Decision Type, the first network node may execute a corresponding network parameter entry point policy to obtain a first decision result.

[0060]

[0058] In particular embodiments, the first network node executing the corresponding network parameter entry point policy comprises the first network node triggering execution of one or more network parameter support policies to obtain one or more respective support outputs. The first network node may determine, based on the one or more respective support outputs, the first decision result.

[0061]

[0059] In some embodiments, the first network node may determine the first response according to the first decision result. For example, a policy may state that a client is not allowed to make a change larger than X units to a particular parameter. If the client requests a change larger than this the decision result may be a rejection, or a reduction of the change to within the policy limits. It will be appreciated that there may be many different types of policies enabled by the Coordination Service than may relate to many different types of network parameter. In another example, if a client requests a change that conflicts with a change requested by another network node, there may be a policy to delay the second received request for a certain time period. In this case the first response may be an acceptance of the request but with an associated delay.

[0062]

[0060] The method of Figure 3 may then proceed to step 306 with the first network node initiating transmission, to the RAN CAM CM interface, of the first response.

[0063]

[0061] In some examples, as described in more detail with reference to Figures 6 and 8, the method of Figure 3 may further comprise receiving, from a second client, a second request to obtain a reservation of the network entity. The method may then further comprise obtaining, according to a reservation allowance policy, a second response to the second request. The second response may comprise one of an acceptance of the reservation; and a rejection of the reservation. The method may then further comprise initiating transmission, to the second client, of the second response. These reservation steps may occur prior to steps 302 to 306.

[0064]

[0062] It will be appreciated that when the second client is the first client the first response of step 304 may, responsive to the second response comprising an acceptance of the reservation, indicate acceptance of the second value. In other words, if the network entity has been reserved, the first response may indicate acceptance. However, the first response may still by a rejection of the second value if the request fails to meet some other policy.

[0065]

[0063] It will be appreciated that when the second client is the first client the first response of step 304 may, responsive to the second response comprising a rejection of the reservation, indicate rejection of the second value. In other words, as the reservation of the network entity has been rejected, the request of step 302 is rejected.

[0066]

[0064] It will also be appreciated that, when the second client is not the first client, the first response of step 304 may indicate, responsive to the second response comprising an acceptance of the reservation, rejection of the second value. In other words, other clients cannot request changes at a network entity that has been reserved by another client.

[0067]

[0065] In some examples, changes to a network entity may only be made where a reservation of that network entity has been made. However, in other cases, if no reservation is made of a network entity, then any client may request a change (so long as the request meets any other relevant policies).

[0068]

[0066] In some embodiments, the method of Figure 3 further comprises the first network node updating the one or more policies (as will be described in more detail with reference to figure 9). The first network node updating the one or more policies may comprise one of the first network node removing a first policy from the one or more policies, the first network node enabling a first policy in the one or more policies, the first network node disabling a first policy in the one or more policies, the first network node configuring a first policy in the one or more policies, and the first network node adding a first policy to the one or more policies.

[0069]

[0067] The updating of the one or more policies by the first network node may be performed online - e.g. whilst the system is running.

[0070]

[0068] Figure 5 depicts a method in accordance with particular embodiments. The method 5 may be performed by a RAN OAM CM interface in an SMO framework for an O-RAN communication network. The RAN OAM CM interface may comprise the RAN OAM CM interface 220 of Figure 2. The O-RAN communication network may comprise a network entity. The SMO framework may further comprise a first network node. The network entity is controlled by a first network parameter, and the RAN OAM CM interface is configured to update the first network parameter. The first network node may comprise the first network node performing the method 3. The first network node may comprise the Coordination Service 230 of Figure 2.

[0071]

[0069] In some embodiments, the network entity comprises one of a second network node, and a cell or a beam served by a network node.

[0072]

[0070] The method begins at step 502 with the RAN CAM CM interface transmitting, to the first network node, a first request, associated with a first client, to update a first value of the first network parameter to a second value. Step 502 of the Figure 5 may be considered to correspond to step 302 of the Figure 3. The first client may comprise the first client performing the method 6. The first client may comprise one of the clients 210a, 210b and 210c of Figure 2.

[0073]

[0071] The method proceeds to step 504 with the RAN CAM CM interface receiving, from the first network node, a first response to the first request. The first response indicates one of: acceptance of the second value, rejection of the second value, and an updated second value. Step 504 of the method 5 may be considered to correspond to step 306 of the method 3.

[0074]

[0072] In some embodiments, responsive to the first response indicating one of acceptance of the second value and an updated second value, the RAN CAM CM interface may update, according to the first response, the first network parameter. It will be appreciated that in some examples the acceptance of the second value or updated second value may be associated with a delay or a sequence of other requests. In these cases the implementation of the update may be performed according to said delay or sequence.

[0075]

[0073] In some embodiments, the RAN OAM CM may receive, from the first client, the first request.

[0076]

[0074] The method 5 may further comprise the RAN OAM CM interface receiving, from the network entity, an update response. For example, the update response may indicate either success or failure of the update. The RAN OAM CM may transmit, to the first client, the update response.

[0077]

[0075] Figure 6 depicts a method in accordance with particular embodiments. The method 6 may be performed by a first client in an O-RAN communication network. The first client may comprise one of the clients 210a, 210b and 210c of Figure 2. The O-RAN communication network may comprise a network entity. The network entity is controlled by a first network parameter. An SMO framework for the O-RAN communication network comprises a RAN OAM CM interface and a first network node, wherein the RAN OAM CM interface is configured to update the first network parameter. The first network node may comprise the first network node performing the method 3. The first network node may comprise the Coordination Service 230 of Figure 2. The RAN OAM CM interface may comprise the RAN OAM CM interface performing the method 5. The RAN OAM CM interface may comprise the RAN 0AM CM interface 220 of Figure 2.

[0078]

[0076] In some embodiments, the network entity comprises one of a second network node, and a cell or a beam served by a network node.

[0079]

[0077] The method begins at step 602 with the first client transmitting, to the first network node, a request to obtain a reservation of the network entity.

[0080]

[0078] The method proceeds to step 604 with the first client receiving an indication of whether the reservation is successful.

[0081]

[0079] In some embodiments, responsive to the reservation being successful, the first client may transmit a first request to the RAN OAM CM interface to update a first value of the first network parameter to a second value.

[0082]

[0080] Figure 7 illustrates a signalling diagram showing an example implementation of the methods of Figures 3 and 5. Some steps of Figure 7 may be performed by a CM Client.. In some embodiments, the CM client may comprise one of the clients 210a, 210b and 210c of Figure 2. Some steps of Figure 7 may be performed by a RAN OAM CM interface. The RAN OAM CM interface may comprise the RAN OAM CM interface performing the method of Figure 5. In some embodiments, the RAN OAM CM interface may comprise the RAN OAM CM interface 220 of Figure 2. Some steps of the method 400 may be performed by a Coordination Management node (also referred to herein as a Coordination Service). The Coordination Management node may comprise the first network node performing the method of Figure 3. In some embodiments, the Coordination Management node may comprise the Coordination Service 230 of Figure 2. Some steps of Figure 7 may be performed by a RAN NF (Network Function). The RAN NF may comprise the network entity as referred to above with reference to Figures 3, 5 and 6. In some examples of Figure 7, the network entity may comprise a second network node (e.g. a base station, a distributed unit or a central unit of a base station). In other examples of Figure 7, the network entity may comprise a cell or beam served by a network node. The RAN NF may be controlled by a network parameter. In some embodiments the network parameter may comprise, for example, an antenna tilt.

[0083]

[0081] In step 710 the CM Client transmits, to the RAN OAM CM interface, a request to change the network parameter of the RAN NF. In some embodiments where the request may be to change the tilt of an antenna of the RAN_NF. For example, the request may be to up-tilt or down-tilt the antenna.

[0084]

[0082] In step 720 the RAN OAM CM interface transmits, to the Coordination Management node, a request for a decision regarding the request, sent by the CM Client, to change the network parameter of the RAN_NF. Step 720 comprises an example implementation of step 502 of Figure 5 and step 302 of Figure 3.

[0083] In step 730 the Coordination Management node triggers one or more policies according to the decision requested by the RAN CAM CM interface. Step 730 comprises an example implementation of step 304 of the Figure 3. The Coordination Management node may trigger the one or more policies using a policy pathway as shown in Figure 4.

[0085]

[0084] In step 740 the Coordination Management node transmits, to the RAN OAM CM interface, a decision result. Step 740 comprises an example implementation of step 306 of Figure 3. The decision result may comprise accepting, rejecting or adjusting the proposed change to the network parameter of the RAN NF. In some embodiments, the decision result may comprise delaying the change to the network parameter or comprise adding the proposed change to a sequence of proposed changes. In this example it is assumed that the request is accepted.

[0086]

[0085] In step 750 the RAN OAM CM interface applies the accepted changes to the network parameter of the RAN NF.

[0087]

[0086] In step 760 the RAN NF transmits, to the RAN OAM CM interface, a result of the applied changes to the network parameter of the RAN NF. In this example the result is successful.

[0088]

[0087] In step 770 the RAN OAM CM interface transmits, to the CM Client, the result of the applied changes to the network parameter of the RAN NF.

[0089]

[0088] Figure 8 illustrates a signalling diagram showing an example implementation of the methods of Figures 3, 5 and 6. The entities involved in the signalling are the same as those involved in the signalling of Figure 7 with the addition of a further CM client. In this case the CM clients may be configured to perform the method as described with reference to Figure 6.

[0090]

[0089] In step 805 the CM Client 1 transmits, to the Coordination Management node, a request to obtain a reservation of the RAN NF 1. Step 805 comprises an example implementation of step 602 of the Figure 6. The request of step 805 may indicate for example a duration for which the reservation is requested, and a scope of the request that comprises at least the RAN_NF 1 but may comprise other network entities.

[0091]

[0090] In step 810 the Coordination Management node triggers one or more policies to determine if the reservation sought by the CM Client 1 can be granted. The Coordination Management node may trigger the one or more policies using a policy pathway as shown in Figure 3. For example, there may be a reservation policy indicating that only a certain duration or scope of reservation can be granted. There may also be a policy indicating that reservation cannot be granted to network entities that are already reserved. It will be appreciated that the Coordination Management node may then respond to the CM client 1 indicating whether or not, according to any relevant policies and any relevant contextual data, the reservation can be granted.

[0091] In this example, in step 815 the Coordination Management transmits, to the CM Client 1 , an indication that the CM Client 1 has successfully obtained a reservation of the RAN NF 1. Step 815 comprises an example implementation of step 604 of the method 6.

[0092]

[0092] In step 820 with the CM Client 1 transmits, to the RAN CAM CM interface, a request to update a first value of a first network parameter of the RAN NF 1 to a second value.

[0093]

[0093] In step 825 the RAN 0AM CM interface transmits, to the Coordination Management node, a request for a decision regarding the request, sent by the CM Client 1 , to change the network parameter of the RAN NF 1. Step 825 comprises an example implementation of step 302 of Figure 3 and step 502 of Figure 5.

[0094]

[0094] In step 830 the Coordination Management node triggers one or more policies to determine if the CM Client 1 has obtained a reservation of the RAN NF 1 . The Coordination Management node may trigger the one or more policies using a policy pathway as shown in Figure 3. Step 830 comprises an example implementation of step 304 of Figure 3

[0095]

[0095] It will be appreciated that, should the client have a reservation (as is the case in this example), the Coordination Management node may trigger other policies to determine whether the requested change is accepted (e.g. as described with reference to Figure 7). In this example, it is assumed that the requested change is accepted, however, if the requested change is not accepted due to some policy, the request may be rejected regardless of the fact that the CM clientl has a reservation.

[0096]

[0096] In step 835 the Coordination Management node transmits, to the RAN CAM CM interface, a decision result. Step 835 comprise an example implementation of step 306 of Figure 3 or step 504 of Figure 5. As previously discussed, a decision result may comprise accepting, rejecting or adjusting the proposed change to the network parameter of the RAN NF. In some embodiments, the decision result may comprise delaying the change to the network parameter or comprise adding the proposed change to a sequence of proposed changes. However, in this example, the decision result is to accept the request to change the network parameter of the RAN NF 1 as the CM Client 1 has previously obtained a reservation of the RAN NF 1.

[0097]

[0097] In step 840 the RAN CAM CM interface applies the accepted changes to the network parameter of the RAN NF 1.

[0098]

[0098] In step 845 the RAN NF 1 transmits, to the RAN OAM CM interface, a result of the applied changes to the network parameter of the RAN NF 1. In this example, the result is a successful change to the network parameter of the RAN NF 1 .

[0099]

[0099] In step 850 the RAN OAM CM interface transmits, to the CM Client 1 , the result of the applied changes to the network parameter of the RAN NF 1. The result is a successful change to the network parameter of the RAN NF 1.

[0100] In step 855 the CM Client 2 transmits, to the RAN 0AM CM interface, a request to change the network parameter of the RAN NF 1.

[0100]

[0101] In step 860 the RAN 0AM CM interface transmits, to the Coordination Management node, a request for a decision regarding the request, sent by the CM Client 2, to change the network parameter of the RAN NF 1. Step 860 comprises an example implementation of step 502 of the method 5 and step 302 of Figure 3.

[0101]

[0102] In step 865 the Coordination Management node triggers one or more policies to determine if a CM Client has obtained a reservation of the RAN NF 1. Ste 865 comprises an example implementation of step 304 of Figure 3. The Coordination Management node may trigger the one or more policies using a policy pathway as shown in Figure 3. If the Coordination Management node determines that a reservation of the RAN NF 1 has been obtained, then the Coordination Management node determines if the CM Client 2 is the client that has obtained the reservation of the RAN NF 1.

[0102]

[0103] In step 870 the Coordination Management node transmits, to the RAN CAM CM interface, a decision result. The decision result may comprise accepting, rejecting or adjusting the proposed change to the network parameter of the RAN NF. In this example method, the decision result is to reject the request to change the network parameter of the RAN NF 1 as the CM Client 1 has reserved the RAN NF 1 , and so there may be a policy to stop other clients making changes to RAN_NF1 whilst the reservation is in place. Step 570 comprises an example implementation of step 306 of the Figure 3 and step 504 of Figure 5.

[0103]

[0104] In step 575, the RAN CAM CM interface transmits, to the CM Client 2, the result of the request for a decision regarding the request, sent by the CM Client 2, to change the network parameter of the RAN NF 1. In this example, the result is a failure to change the network parameter of the RAN NF 1 as CM Client 1 has obtained a reservation of the RAN NF 1.

[0104]

[0105] Figure 9 is a signalling diagram showing an example method for updating policies at the Coordination Service according to some embodiments. Some steps of Figure 9 may be performed by an Administrator node or a Administrator. Some steps of Figure 9 may be performed by a Coordination Service (e.g. a first network node). The Coordination Service may comprise the first network node performing the method of Figure 3. In some embodiments, the Coordination Service may comprise the Coordination Service 230 of Figure 2. The Coordination Service may use one or more policies to respond to a decision request received from a CM Client or the RAN CAM CM interface. The one or more policies may be stored in a policy store of the Coordination Service. Each policy in the one or more policies comprises a policy state. Each policy in the one or more policies may also comprise policy configuration data. The Coordination Service may comprise records of the policy decisions.

[0105]

[0106] It will be appreciated that steps 905 to 915 provide an example adding / removing process, steps 920 to 930 provide an example enabling / disabling process, steps 935 to 945 provide an example configuring process, and steps 950 to 055 provide an example policy retrieval process. All of these processes may be performed in isolation.

[0106]

[0107] In step 905 an Administrator node transmits, to the Coordination Management node, an instruction to add or remove a policy from the one or more policies.

[0107]

[0108] In step 910 the Coordination Management node updates the policy store to add or remove the policy from the one or more policies.

[0108]

[0109] In step 915 the Coordination Management node transmits, to the Administrator node, a result. The result indicates to the Administrator node that the policy store has been updated.

[0109]

[0110] In step 920 the Administrator node transmits, to the Coordination Management node, an instruction to enable or disable a policy from the one or more policies.

[0110]

[0111] In step 925 the Coordination Management node updates the policy state of the policy to enable or disable the policy.

[0111]

[0112] In step 930 the Coordination Management node transmits, to the Administrator node, a result. The result indicates to the Administrator node that the policy state of the policy has been updated.

[0112]

[0113] In step 935 the Administrator node transmits, to the Coordination Management node, an instruction to configure a policy from the one or more policies. For example, the instruction to configure a policy may configure or update a particular parameter of the policy.

[0113]

[0114] In step 940 the Coordination Management node updates the policy configuration data of the policy.

[0114]

[0115] In step 945 the Coordination Management node transmits, to the Administrator node, a result. The result indicates to the Administrator node that the policy configuration data of the policy has been updated.

[0115]

[0116] In step 950 the Administrator node transmits, to the Coordination Management node, an instruction to retrieve the policy decision records.

[0116]

[0117] In step 955 the Coordination Management node transmits, to the Administrator node, data of the policy decision records.

[0117]

[0118] Figure 10 illustrates an example architecture for an SMO comprises a Coordination Service according to some embodiments.

[0118]

[0119] As described in the embodiments above, in the O-RAN architecture, a new SMOS may be introduced called Coordination Management (or Coordination Service). It may be part of a the Non-RT RIC. When rApps or other SMOS’s request CM changes via the RAN CAM SMOS, those changes may be coordinated via policies triggered in the Coordination Management SMOS.

[0119]

[0120] Figure 11 illustrates a first network node 1100 comprising processing circuitry (or logic) 1101. The processing circuitry 1101 controls the operation of the first network node 1100 and can implement the method described herein in relation to an first network node 1100. The processing circuitry 1101 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first network node

[0120] 1100 in the manner described herein. In particular implementations, the processing circuitry

[0121] 1101 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the first network node 1100. It will be appreciated that the first network node 1100 may comprise one or more virtual machines running different software and / or processes. The first network node 1100 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0122]

[0121] Optionally, the first network node 1100 may comprise a memory 1103. In some embodiments, the memory 1103 of the first network node 1100 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1101 of the first network node 1100 whereby the apparatus is operable to perform the method as described with reference to Figure 3.

[0123]

[0122] Alternatively or in addition, the memory 1103 of the first network node 1100, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1101 of the first network node 1100 may be configured to control the memory 1103 of the first network node 1100 to store any requests, resources, information, data, signals, or similar that are described herein.

[0124]

[0123] In some embodiments, the first network node 1100 may optionally comprise a communications interface 1102. The communications interface 1102 of the first network node 1100 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1102 of the first network node 1100 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1101 of first network node 1100 may be configured to control the communications interface 1102 of the first network node 1100 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 1102 can use any suitable communication technology.

[0125]

[0124] The first network node 1100 may be configured operate in the manner described herein in respect of a first network node.

[0126]

[0125] Figure 12 illustrates a RAN OAM CM interface 1200 comprising processing circuitry (or logic) 1201. The processing circuitry 1201 controls the operation of the RAN OAM CM interface 1200 and can implement the method described herein in relation to an RAN OAM CM interface 1200. The processing circuitry 1201 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the RAN OAM CM interface 1200 in the manner described herein. In particular implementations, the processing circuitry 1201 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the RAN OAM CM interface 1200. It will be appreciated that the RAN OAM CM interface 1200 may comprise one or more virtual machines running different software and / or processes. The RAN OAM CM interface 1200 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0127]

[0126] Optionally, the RAN OAM CM interface 1200 may comprise a memory 1203. In some embodiments, the memory 1203 of the RAN OAM CM interface 1200 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1201 of the RAN OAM CM interface 1200 whereby the apparatus is operable to perform the method as described with reference to Figure 5.

[0128]

[0127] Alternatively or in addition, the memory 1203 of the RAN OAM CM interface 1200, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1201 of the RAN OAM CM interface 1200 may be configured to control the memory 1203 of the RAN OAM CM interface 1200 to store any requests, resources, information, data, signals, or similar that are described herein.

[0129]

[0128] In some embodiments, the RAN OAM CM interface 1200 may optionally comprise a communications interface 1202. The communications interface 1202 of the RAN OAM CM interface 1200 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1202 of the RAN OAM CM interface 1200 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1201 of RAN OAM CM interface 1200 may be configured to control the communications interface 1202 of the RAN OAM CM interface 1200 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 1202 can use any suitable communication technology.

[0130]

[0129] The RAN OAM CM interface 1200 may be configured operate in the manner described herein in respect of a RAN OAM CM interface.

[0131]

[0130] Figure 13 illustrates a first client 1300 comprising processing circuitry (or logic) 1301. The processing circuitry 1301 controls the operation of the first client 1300 and can implement the method described herein in relation to a first client 1300. The processing circuitry 1301 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first client 1300 in the manner described herein. In particular implementations, the processing circuitry 1301 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the first client 1300. It will be appreciated that the first client 1300 may comprise one or more virtual machines running different software and / or processes. The first client 1300 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0132]

[0131] Optionally, the first client 1300 may comprise a memory 1303. In some embodiments, the memory 1303 of the first client 1300 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1301 of the first client 1300 whereby the apparatus is operable to perform the method as described with reference to Figure 5.

[0133]

[0132] Alternatively or in addition, the memory 1303 of the first client 1300, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1301 of the first client 1300 may be configured to control the memory 1303 of the first client 1300 to store any requests, resources, information, data, signals, or similar that are described herein.

[0134]

[0133] In some embodiments, the first client 1300 may optionally comprise a communications interface 1302. The communications interface 1302 of the first client 1300 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1302 of the first client 1300 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1301 of first client 1300 may be configured to control the communications interface 1302 of the first client 1300 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 1302 can use any suitable communication technology.

[0135]

[0134] The first client 1300 may be configured operate in the manner described herein in respect of a first client.

[0136]

[0135] There is also provided a computer program comprising instructions which, when executed on a least one processor (such as the processing circuitry 1101 of the first network node 1100 described earlier), cause the processor to carry out at least part of the method(s) described herein. According to some embodiments there is provided a carrier containing the computer program. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable medium. There is also provided a (for example, tangible and / or non-transient) computer-readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform at least part of the method(s) described herein.

[0137]

[0136] Figure 14 is a block diagram illustrating a virtualization environment 1400 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

[0138]

[0137] Applications 1402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0139]

[0138] Hardware 1404 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1408a and 1408b (one or more of which may be generally referred to as VMs 1408), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1406 may present a virtual operating platform that appears like networking hardware to the VMs 1408.

[0140]

[0139] The VMs 1408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1406. Different embodiments of the instance of a virtual appliance 1402 may be implemented on one or more of VMs 1408, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0141]

[0140] In the context of NFV, a VM 1408 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1408, and that part of hardware 1404 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1408 on top of the hardware 1404 and corresponds to the application 1402.

[0142]

[0141] Hardware 1404 may be implemented in a standalone network node with generic or specific components. Hardware 1404 may implement some functions via virtualization. Alternatively, hardware 1404 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1410, which, among others, oversees lifecycle management of applications 1402. In some embodiments, hardware 1404 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1412 which may alternatively be used for communication between hardware nodes and radio units.

[0143]

[0142] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0143] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0144]

[0144] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

[0145]

[0145] Embodiments may be implemented through modifications to O-RAN standard documents. An example modification is as set out in the following Change Request; the change request indicates proposed amendments to O-RAN. WG2.Non-RT RIC-ARCH ver 06.00, the remainder of the document may remain unmodified by the Change Request:

[0146]

[0147] ++++++++++++++++++++++++++++++

[0148] History:

[0149] V01 -Initial version

[0150] +++++++++++++++++++++++++++++++

[0151] 6 Non-RT RIC Architecture Start of Change 1>

[0152] 6.1 General

[0153] Non-RT RIC is comprised of: Non-RT RIC Framework - Functionality internal to the SMO Framework that:

[0154] Logically terminates the Al interface to the Near-RT RIC.

[0155] Exposes set of R1 services to Non-RT RIC Applications (rApps).

[0156] Non-RT RIC Applications (rApps) - Applications that leverage the functionalities available in the SMO / Non-RT RIC framework to provide value added services related to RAN operation and optimization. The scope of rApps includes, but is not limited to, RAN configuration management, data analytics, producing training services, generating Al policies, and providing enrichment information.

[0157] Figure 15 depicts the reference architecture of the Non-RT RIC as part of the SMO framework.

[0158] « End of Change 1> >

[0159] 7 R1 Service Definitions

[0160] « Start of Change2> >

[0161] 7.1 General description

[0162] A service is a set of capabilities related to each other, offered by a Service Producer to Service Consumer(s) for consumption. The capabilities within a service typically have a common purpose and can be inter-dependent. In order to improve re-usability, the mutual coupling across any two services is usually avoided or minimized. Services are produced by Service Producers and consumed by Service Consumers through service endpoints (typically APIs). The interoperability of Service Producers and Service Consumers is ensured by support of the related service endpoints, but it does not depend on the decomposition of logical functions. Being a Service Producer and / or a Service Consumer is a role of an rApp or of a logical function in the SMO or the Non-RT RIC framework (see clause 6).

[0163] The set of R1 services which can be accessed via the R1 interface includes (but is not limited to):

[0164] Service management and exposure services, which include service registration and service discovery services, authentication services, authorization services and communication support services. The service management and exposure services support extensibility of the set of R1 services.

[0165] Data management and exposure services, which deliver data created or collected by Data Producers to Data Consumers according to their needs.

[0166] Al -related services, which provide access to functionality related to Al.

[0167] AI / ML workflow services, which provide access to Al and ML workflow.

[0168] RAN OAM-related services, which provide access to RAN OAM functionality related to the 01 and open fronthaul M-plane interfaces, and to the OAM functionality related to RAN-specific network slicing in the SMO framework.

[0169] 02-related services, which provide access to functionality related to 02. rApp management services, which provide functionality for managing rApps. TE&IV-related services, which provide access to topology and inventory data.

[0170] Coordination management services, which provides policy based coordination decisions to R1 Service Producers regarding network changes (including but not limited to Configuration management changes) that are requested by R1 Service Consumers.

[0171] NOTE: A part of the services listed above may be used on other O-RAN-defined interfaces as well.

[0172] « End of Change2> >

[0173] « Start of Change3> >

[0174] 7.x Coordination management services

[0175] Coordination management service provides below capabilities

[0176] • Coordinates decision on the network changes (including but not limited to RAN OAM configuration management changes) across R1 Service Consumers

[0177] • provides the life cycle management of the policies used to implement the co-ordination decisions.

[0178] • provides mechanism to reserve the node or cell for implementing changes (including but not limited to RAN OAM configuration management changes).

[0179] R1 Service Consumers (such as rApps) can request a network configuration change to the RAN OAM-related services via the R1 interface. The R1 Service Producer (e.g. RAN OAM-related services ) should request coordination management service to coordinate decisions regarding these changes. The coordination decisions can include the following but not limited to

[0180] • whether the change can be allowed to be applied

[0181] • whether the change can be prevented

[0182] • whether the change can be queued

[0183] Once the decision has been taken by the coordination service the same is communicated to the R1 Service Producer (e.g., RAN OAM-related services) . The R1 Service Producer enforces the decision e. allow the requested configuration change to proceed.

[0184] The coordination service shall determine the decision regarding the changes based on the policies, these policies are specified by the R1 Service Producer. How these policies are implemented to make decision are implementation specific.

[0185] R1 Service Producer request a decision based on the request it receives from R1 Service Consumer, The coordination service triggers a specific decision type which in turn triggers “entry” policies and their “supporting” policies which are required to evaluate the various criteria that may apply to overall decision. The entry point policies are responsible for collating all inputs of the supporting policies to generate an overall decision result. R1 Service Consumer can reserve the cell or node by using the coordination service. The coordination service can subsequently make decisions based on that reservation (e.g. allow or deny a configuration change on a cell or node contained within the reservation). The coordination service will also verily the R1 Service Consumer eligibility for a reservation by using a policy.

[0186] « End of Change3> >

[0187] « Start of Change4> >

[0188] 8 Non-RT RIC Function Definitions

[0189] 8.1 General description

[0190] In the Non-RT RIC architecture in clause 6, R1 services are provided by a collection of logical functions in SMO / Non-RT RIC framework or rApps. These logical functions, as defined in clause 6, include (but are not limited to):

[0191] Service management and exposure functions: These functions produce service management and exposure services.

[0192] Data management and exposure functions: These functions produce data management and exposure services.

[0193] AI / ML workflow functions: These functions produce AI / ML workflow services. rApp management functions: These functions produce rApp management services.

[0194] Al-related functions: These functions produce Al-related services.

[0195] RAN OAM-related functions: These functions produce RAN OAM-related services.

[0196] 02-related functions: These functions produce 02-related services.

[0197] R1 termination: It enables the R1 Service Producers and R1 Service Consumers to exchange messages via the R1 interface.

[0198] Al termination: It enables the Non-RT RIC framework and the Near-RT RIC to exchange messages over the Al interface.

[0199] 01 termination: It enables the SMO framework to exchange messages with the Near-RT RIC / E2 nodes over the 01 interface.

[0200] Open fronthaul M-plane termination: It enables the SMO framework to exchange messages with the O-RUs over the open fronthaul M-plane interface.

[0201] 02 termination: It enables the SMO framework to exchange messages with the O-Cloud over the 02 interface.

[0202] Other SMO functions: Among other functionalities, these functions also offer RAN-specific slice management functionality.

[0203] External terminations: These functions enable the SMO / Non-RT RIC framework to exchange messages with external entities over interfaces outside the scope of 0-RAN. Coordination functions: It enables the R1 Service Producers to request to coordinate the decisions regarding the network changes requested by the R1 Service Consumers.

[0204] NOTE: The SMO functions offering the slice management services and whether these shall be considered as R1 services is for future study. End of Change4>

[0205] The following numbered statements provide additional information on the disclosure:

[0206] 1 . A method performed by a first network node in a SMO framework for an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein the SMO framework further comprises a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface configured to update the first network parameter, the method comprising: receiving a first request, associated with a first client, to update a value of the first network parameter to a second value; obtaining, according to one or more policies, a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value; and initiating transmission, to the RAN OAM CM interface, of the first response.

[0207] 2. The method of statement 1 , wherein the updated second value is based at least in part on the second value.

[0208] 3. The method of any of statements 1 to 2, wherein the first response indicates one of: acceptance of the second value by adding the first request to a queue of requests; and acceptance of the second value by adding the first request to a sequence of requests.

[0209] 4. The method of any of statements 1 to 3, wherein the first response further comprises: an indication of other clients; and information relating to respective requests made by the other clients.

[0210] 5. The method of any of statements 1 to 4, wherein obtaining, according to one or more policies, a first response to the first request comprises: triggering a network parameter Decision Type; responsive to triggering the network parameter Decision Type, executing a corresponding network parameter entry point policy to obtain a first decision result; and determining the first response according to the first decision result. The method of statement 5, further comprising: wherein executing the corresponding network parameter entry point policy comprises: triggering execution of one or more network parameter support policies to obtain one or more respective support outputs; and determining, based on the one or more respective support outputs, the first decision result. The method of any of statements 1 to 6, further comprising: receiving, from a second client, a second request to obtain a reservation of the network entity; obtaining, according to a reservation allowance policy, a second response to the second request, wherein the second response comprises one of: an acceptance of the reservation; and a rejection of the reservation; and initiating transmission, to the second client, of the second response. The method of statement 7, wherein the second client is the first client and obtaining, according to one or more policies, the first response to the first request comprises: responsive to the second response comprising an acceptance of the reservation, the first response indicates acceptance of the second value. The method of statement 7, wherein the second client is the first client and obtaining, according to one or more policies, the first response to the first request comprises: responsive to the second response comprising a rejection of the reservation, the first response indicates rejection of the second value. The method of statement 7, wherein the second client is not the first client and obtaining, according to one or more policies, the first response to the first request comprises: responsive to the second response comprising an acceptance of the reservation, the first response indicates rejection of the second value. The method of any of statements 1 to 10, further comprising: updating the one or more policies. The method of statement 11 , wherein updating the one or more policies comprises, one of: removing a first policy from the one or more policies; enabling a first policy in the one or more policies; disabling a first policy in the one or more policies; configuring a first policy in the one or more policies; and adding a first policy to the one or more policies. The method of statement 11 or 12 wherein the updating of the one or more policies is performed online. The method of any of statements 1 to 13, wherein the network entity comprises one of: a second network node; and a cell or a beam served by a network node. The method of any of statements 1 to 14, wherein the first network node comprises a Coordination Service. A method performed by a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface in a SMO for an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity and the SMO framework further comprises a first network node, wherein the network entity is controlled by a first network parameter, and wherein the RAN OAM CM interface is configured to update the first network parameter, the method comprising: transmitting, to the first network node, a first request, associated with a first client, to update a first value of the first network parameter to a second value; receiving, from the first network node, a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value. The method of statement 16 further comprising, responsive to the first response indicating one of acceptance of the second value and an updated second value, updating, according to the first response, the first network parameter. The method of statement 16 or 17, further comprising receiving, from a first client, the first request. The method of any of statements 16 to 18, further comprising: receiving, from the network entity, an update response; and transmitting, to the first client, the update response. The method of any of statements 16 to 19, wherein the network entity comprises one of: a second network node; and a cell or a beam served by a network node. A method performed by first client in an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein an SMO framework for the O-RAN communication network comprises a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface is configured to update the first network parameter and a first network node, the method comprising: transmitting, to the first network node, a request to obtain a reservation of the network entity; and receiving an indication of whether the reservation is successful. The method of statement 21 further comprising: responsive to the reservation being successful, transmitting a first request to the RAN OAM CM interface to update a first value of the first network parameter to a second value. The method of any of statements 21 to 22, wherein the network entity comprises one of: a second network node; and a cell or a beam served by a network node. A first network node in an SMO framework for an Open Radio Access Network, O- RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein the SMO framework further comprises a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface configured to update the first network parameter, the first network node comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the first network node is operable to: receive a first request, associated with a first client, to update a first value of the first network parameter to a second value; obtain, according to one or more policies, a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value; and initiating transmission, to the RAN OAM CM interface, of the first response. The first network node of statement 24 wherein the memory further contains instructions executable by the processing circuitry whereby the first network node is operable to perform the method of any one of statements 2 to 15. A Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface in an SMO framework of an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein the RAN OAM CM interface is configured to update the first network parameter, and the SMO framework further comprises a first network node, the RAN OAM CM interface processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the RAN OAM CM is operable to: transmit, to the first network node, a first request, associated with a first client, to update a first value of the first network parameter to a second value; and receive, from the first network node, a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value. The RAN OAM CM interface of statement 26 wherein the memory further contains instructions executable by the processing circuitry whereby the RAN OAM CM interface is operable to perform the method of any one of 17 to 20. A first client in an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein an SMO framework for the O-RAN communication network comprises a first network node and a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface configured to update the first network parameter, the first client comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the first client is operable to: transmit, to the first network node, a request to obtain a reservation of the network entity; and receive an indication of whether the reservation is successful. The first client of statement 28 wherein the memory further contains instructions executable by the processing circuitry whereby the first client is operable to perform the method of any one of statements 22 or 23. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of statements 1 to 23. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of statements 1 to 23. A computer program product comprising non transitory computer readable media having stored thereon a computer program according to statement 30.

Claims

32Claims1. A method performed by a first network node (1100) in a Service Management and Orchestration, SMO, framework for an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein the SMO framework further comprises a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface (1200) configured to update the first network parameter, the method comprising: receiving (302) a first request, associated with a first client (1300), to update a value of the first network parameter to a second value; obtaining (304), according to one or more policies, a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value; and initiating transmission (306), to the RAN OAM CM interface (1200), of the first response.

2. The method of claim 1 , wherein the updated second value is based at least in part on the second value.

3. The method of any of claims 1 to 2, wherein the first response indicates one of: acceptance of the second value by adding the first request to a queue of requests; and acceptance of the second value by adding the first request to a sequence of requests.

4. The method of any of claims 1 to 3, wherein the first response further comprises: an indication of other clients; and information relating to respective requests made by the other clients.

5. The method of any of claims 1 to 4, wherein obtaining, according to one or more policies, a first response to the first request comprises: triggering a network parameter Decision Type; responsive to triggering the network parameter Decision Type, executing acorresponding network parameter entry point policy to obtain a first decision result; and determining the first response according to the first decision result optionally wherein executing the corresponding network parameter entry point policy comprises: triggering execution of one or more network parameter support policies to obtain one or more respective support outputs; and determining, based on the one or more respective support outputs, the first decision result.

6. The method of any of claims 1 to 5, further comprising: receiving, from a second client, a second request to obtain a reservation of the network entity; obtaining, according to a reservation allowance policy, a second response to the second request, wherein the second response comprises one of: an acceptance of the reservation; and a rejection of the reservation; and initiating transmission, to the second client, of the second response.

7. The method of claim 6, wherein the second client is the first client (1300) and obtaining, according to one or more policies, the first response to the first request comprises: responsive to the second response comprising an acceptance of the reservation, the first response indicates acceptance of the second value, or responsive to the second response comprising a rejection of the reservation, the first response indicates rejection of the second value.

8. The method of claim 6, wherein the second client is not the first client (1300) and obtaining, according to one or more policies, the first response to the first request comprises: responsive to the second response comprising an acceptance of the reservation, the first response indicates rejection of the second value.

9. The method of any of claims 1 to 8, further comprising: updating the one or more policies, optionally wherein the updating of the one or more policies is performed online.

10. The method of claim 9, wherein updating the one or more policies comprises, one of:removing a first policy from the one or more policies; enabling a first policy in the one or more policies; disabling a first policy in the one or more policies; configuring a first policy in the one or more policies; and adding a first policy to the one or more policies.

11. The method of any of claims 1 to 10, wherein the network entity comprises one of: a second network node; and a cell or a beam served by a network node.

12. The method of any of claims 1 to 11 , wherein the first network node (1100) comprises a Coordination Service.

13. A method performed by a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface (1200) in a Service Management and Orchestration, SMO, framework for an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity and the SMO framework further comprises a first network node (1100), wherein the network entity is controlled by a first network parameter, and wherein the RAN OAM CM interface is configured to update the first network parameter, the method comprising: transmitting (502), to the first network node (1100), a first request, associated with a first client (1300), to update a first value of the first network parameter to a second value; receiving (504), from the first network node (1100), a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value.

14. The method of claim 13 further comprising, responsive to the first response indicating one of acceptance of the second value and an updated second value, updating, according to the first response, the first network parameter.

15. The method of claim 13 or 14, further comprising receiving, from a first client (1300), the first request.

16. The method of any of claims 13 to 15, further comprising: receiving, from the network entity, an update response; and transmitting, to the first client (1300), the update response.

17. The method of any of claims 13 to 16, wherein the network entity comprises one of: a second network node; and a cell or a beam served by a network node.

18. A method performed by first client (1300) in an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein a Service Management and Orchestration, SMO, framework for the O- RAN communication network comprises a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface (1200) is configured to update the first network parameter and a first network node (1100), the method comprising: transmitting (602), to the first network node (1100), a request to obtain a reservation of the network entity; and receiving (604) an indication of whether the reservation is successful.

19. The method of claim 18 further comprising: responsive to the reservation being successful, transmitting a first request to the RAN OAM CM interface (1200) to update a first value of the first network parameter to a second value.

20. The method of any of claims 18 to 19, wherein the network entity comprises one of: a second network node; and a cell or a beam served by a network node.

21. A first network node (1100) in a Service Management and Orchestration, SMO, framework for an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein the SMO framework further comprises a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface (1200) configured to update the first network parameter, the first network node (1100) comprising processing circuitry (1101) and a memory (1103), the memory (1103) containinginstructions executable by the processing circuitry (1101) whereby the first network node (1100) is operable to: receive a first request, associated with a first client (1300), to update a first value of the first network parameter to a second value; obtain, according to one or more policies, a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value; and initiating transmission, to the RAN OAM CM interface (1200), of the first response.

22. A Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface (1200) in a Service Management and Orchestration, SMO, framework of an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein the RAN OAM CM interface is configured to update the first network parameter, and the SMO framework further comprises a first network node (1100), the RAN OAM CM interface (1200) comprising processing circuitry (1201) and a memory (1203), the memory (1203) containing instructions executable by the processing circuitry (1201) whereby the RAN OAM CM (1200) is operable to: transmit, to the first network node (1100), a first request, associated with a first client (1300), to update a first value of the first network parameter to a second value; and receive, from the first network node (1100), a first response to the first request, wherein the first response indicates one of: acceptance of the second value; rejection of the second value; and an updated second value.

23. A first client (1300) in an Open Radio Access Network, O-RAN, communication network, wherein the O-RAN communication network comprises a network entity, wherein the network entity is controlled by a first network parameter, and wherein a Service Management and Orchestration, SMO, framework for the O-RAN communication network comprises a first network node (1100) and a Radio Access Network Operations, Administration and Maintenance Coordination Management, RAN OAM CM, interface (1200) configured to update the first network parameter, thefirst client (1300) comprising processing circuitry (1301) and a memory (1303), the memory (1303) containing instructions executable by the processing circuitry (1301) whereby the first client (1300) is operable to: transmit, to the first network node (1100), a request to obtain a reservation of the network entity; and receive an indication of whether the reservation is successful.

24. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of claims 1 to 20.

25. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 20.

Images